Мени

Практично тестирање софтверског тока КА процеса (услови за објављивање)

practical software testing qa process flow

Испробајте Наш Инструмент За Елиминисање Проблема

Комплетан преглед протока процеса тестирања софтвера за КА од краја до краја:

Напомена - Поновно објављујемо овај користан пост са ажурираним садржајем.

Посао професионалца за тестирање софтвера није лак. Испуњен је изазовима, што је такође подједнако захтевно. Тестери би требали бити опрезни и ентузијастични у свакој фази животног циклуса апликације.

Иако постоје изазови, постоји и неколико огромних прилика за детаљно учење и истраживање различитих аспеката методологија, процеса и наравно софтвера тестирања.

Улога инжењера испитивања почиње врло рано. И одмах од концептуализације пројекта, тестери су укључени у дискусије са власником производа, менаџером пројекта и разним заинтересованим странама.

Захтеви за објављивање

Овај водич о „Процесу процеса тестирања софтвера“ даје вам потпун преглед различитих фаза у СТЛЦ-у, заједно са изазовима и најбољим праксама за превазилажење тих изазова на лако разумљив начин.

Шта ћете научити:

Захтев за објављивање - потпун преглед

Животни циклус тестирања софтвера

Непосредно од захтева за пуштање, свака фаза је јасно објашњена. Хајде да их детаљно погледамо.

# 1) Захтев

Пројекат не може да крене без јасног захтева. Ово је најважнија фаза у којој идеје треба написати у разумљивом и форматираном документу. Ако сте део пројекта у којем учествујете у фази прикупљања захтева, сматрајте се срећним.

како направити .јар датотеке отворене помоћу Јава

Питате се зашто? То је зато што присуствујете пројекту израде од нуле. Иако постоји понос у постојању од самог почетка, то укључује и неке одговорности и изазове.

Изазови

Не могу се замислити сви захтеви за окупљање у једном седишту. Будите довољно стрпљиви.

Догодиће се много дискусија, од којих су неке можда једноставно ирелевантне за ваш пројекат, али чак и тада могу садржавати неке виталне информације за ваш пројекат. Понекад брзина дискусије може премашити ваше могућности за схватање или једноставно не бисте обраћали пажњу на власника производа.

Слика доле истиче кључне кораке који су укључени у прикупљање захтева:

Захтеви ЛифеЦицле

Свака информација која се пропусти има огроман утицај на целокупно разумевање и тестирање пројекта. Да бисмо то превазишли, ево неколико најбољих пракси које би требало следити током ове фазе.

Најбоље праксе

  • Држите свој ум отворен и обратите пажњу на сваку реч власника производа.
  • Немојте само слушати, разјасните своју сумњу колико год изгледала мала.
  • Увек користите свеске за брзо вођење бележака. Требали бисте да користите лаптоп, само ако заиста можете да куцате приличном брзином.
  • Поновите реченице и појасните их из упутства за које мислите да сте га разумели.
  • Нацртајте блок дијаграме, текст везе итд. Да бисте у каснијим временским периодима учинили захтеве јаснијим.
  • Ако су тимови на различитим локацијама, потрудите се да направите ВебЕк или слично снимање. Увек ће вам помоћи када сумњате након завршетка дискусије.

Иако не постоји засебан зид као такав за сваку фазу, захтеви се мењају чак и врло касно у развоју. Дакле, идеја је да се ухвати за већину захтева и ово правилно документује.

Када се документују са свим потребним тачкама, распоредите и разговарајте о свим заинтересованим странама тако да се сви предлози или промене рано ухвате и пре него што крену даље, сви су на истој страници.

# 2) Тест стратегија

Тестер би требало да изађе са стратегијом тестирања која није довољна само за боље тестирање софтвера, већ би требало да улива поверење свим заинтересованим странама у квалитет производа.

Тест Стратеги

Изазови

Најважнији аспект ове фазе је стварање стратегије која би, када се ради на њој, требало да пружи софтверски производ без грешака, одржив и прихваћен од стране крајњих корисника.

Тест стратегије су нешто што нећете мењати сваки други дан. У неким случајевима морате са клијентима разговарати и о својим стратегијама тестирања. Дакле, овим делом би се требало позабавити од велике важности.

Најбоље праксе

  • Ево неколико најбољих пракси, које вам у следећем случају могу пружити велико олакшање и резултирати несметаним тестирањем.
  • Прегледајте документ захтева још једном. Означите тачке увоза с обзиром на окружење циљног софтвера.
  • Направите листу окружења у којима ће софтвер заиста бити постављен.
  • Окружења се могу схватити као врста оперативних система или мобилних уређаја.
  • Ако је Виндовс оперативни систем, наведите све верзије прозора у којима ћете тестирати свој софтвер. Ако верзије виз. Виндовс 7, Виндовс 10 или Виндовс Сервер (с) још увек нису дефинисани у документу захтева, тада је крајње време да се о њима расправља.
  • На сличан начин, набавите циљне прегледаче са верзијама о којима се расправља и документује да ли је АУТ систем заснован на мрежи.
  • Направите листу свих независних софтвера који ће апликацији требати (ако је потребан / подржан). То може укључивати Адобе Ацробат, Мицрософт Оффице, било које додатке итд.

Овде је идеја да задржимо сваку потребну и потребну платформу, уређаје и софтвер који ће наша апликација морати да функционише пре нас како би се могла формулисати свеобухватна стратегија.

Испод ће вам помоћи да разумете контуре стратегије тестирања ако радите на агилном пројекту:

Стратегија тестирања

# 3) Планирање теста

Након што се тестери наоружају свим информацијама у вези са АУТ, стратегија се примењује у фази планирања.

Попут стратегије тестирања, и планирање теста је пресудна фаза.

План испитивања

Изазови

Будући да успех (или неуспех) АУТ у великој мери зависи од тога како су изведени тестови, ова фаза постаје важан аспект целокупног животног циклуса теста. Зашто? Јер је део испитивања дефинисан у овој фази.

Да би се превазишли неки изазови, ове најбоље праксе заиста могу бити корисне.

Најбоље праксе

  • Увек имајте на уму да приликом тестирања ваше пријаве не остане камен на камену.
  • Време је да се формулише тест стратегија.
  • Направите матрицу окружења тако да се софтвер тестира на свим платформама.
  • Као, Виндовс 10 + Интернет Екплорер 11+ Виндовс Оффице 2010+.
  • Попут Андроид 4.2.2+ Цхроме прегледача.
  • Ако ваша апликација ради са више база података (ако је документовано), базе података (МиСКЛ, Орацле, СКЛСервер) задржите у матрици за тестирање на такав начин да су превише интегрисане са неким тестовима.
  • Конфигуришите тест машине према томе и дајте им имена СетУп1, СетУп2 итд.
  • СетУп1 ће имати Виндовс 7+ ИЕ 10+ Оффице 2007+.
  • СетУп2 можда има Виндовс 10+ ИЕ Едге + Оффице 2013+.
  • СетУп3 може имати Андроид телефон са инсталираном вашом .апк датотеком.
  • Честитам! Пробно подешавање је спремно, а укључили сте и сваку могућу комбинацију платформи на којима ће ваша апликација радити.

# 4) Тестирање

Проналажење буба

Коначно, ваша апликација је завршена и спремни сте да пронађете грешке! Сада је време да порадите на планирању теста и пронађете што више грешака. Неке ће фазе бити између тога ако радите у агилном окружењу, а затим једноставно следите те сцрум методе.

Испод дијаграм приказује категоризацију различитих врста испитивања:

Врсте испитивања

Изазови

Тестирање је гломазан процес који је сам подложан грешкама! Током тестирања апликације наилазимо на многе изазове. Доље су дате неке најбоље праксе за спасавање.

Најбоље праксе

Развеселити се! Покушавате да пронађете недостатке у коду. Морате обратити пажњу на целокупан рад софтвера.

  • Увек је препоручљиво да апликацију погледате свеже, БЕЗ ПРОЛАЗА КРОЗ ТЕСТНЕ СЛУЧАЈЕ.
  • Слиједите навигацијску путању вашег софтвера (АУТ).
  • Упознајте се са АУТ.
  • Сада прочитајте тест случајеве (Сви) било ког одређеног модула (можда по вашем избору).
  • Сада идите на АУТ и упоредите налазе са онима поменутим у очекиваном одељку тест случајева.
  • Идеја иза овога је тестирање сваке поменуте функције на свакој подржаној платформи.
  • Забележите свако одступање колико год се чинило тривијалним.
  • Запишите кораке како доћи до било ког одступања, направите снимке екрана, снимите евиденције грешака, евиденције сервера и било коју другу пратећу документацију која може доказати постојање недостатака.
  • Не устручавајте се да питате. Иако имате документ са захтевима, понекад ћете бити у недоумици.
  • Обратите се програмерима (ако седе поред вас или ако су доступни) у недоумици пре него што контактирате власника производа. Разумети перспективу програмера о раду софтвера. Разуме их. Ако сматрате да ова примена није у складу са захтевом, обавестите менаџера теста.

# 5) Пре пуштања

Пре него што пустимо било који производ на тржиште, мора се обезбедити квалитет производа. Софтвер се развија једном, али се заправо тестира док се не замени или уклони.

Изазови

Софтвер мора бити строго тестиран за многе његове параметре.

Параметри не морају бити ограничени на:

  • Функционалност / понашање.
  • Перформансе.
  • Прилагодљивост.
  • Компатибилан са наведеним платформама.

Изазов је такође предвидети стопу успешности апликације која зависи од многих итерација извршеног тестирања.

Најбоље праксе

  • Обавезно тестирајте све функције на свим платформама.
  • Истакните подручја која нису тестирана или она која захтевају више напора на тестирању.
  • Држите матрицу свих резултата испитивања пре објављивања. Матрица за испитивање ће дати укупну слику стабилности производа. Такође ће помоћи управи да се јави на датуме издавања.
  • Дајте своје улоге / сугестије тиму о својим искуствима током тестирања производа.
  • Ваш допринос који себе сматра крајњим корисником у великој мери ће користити софтверу.
  • Због временског ограничења или било које друге такве ситуације, пропуштамо неко тестирање или не улазимо дубоко у ово. Не устручавајте се рећи статус тестирања свом менаџеру.
  • Представите здравствену књижицу пријаве заинтересованим странама. Здравствене картице треба да имају низ свих евидентираних, отворених, затворених, повремених недостатака са њиховом тежином и приоритетом.
  • Направите документ о издању и поделите га са тимом.
  • Припремљен рад на документу о пуштању на слободу.
  • Побољшати подручја која су предложена од стране менаџмента / тима.

Доња слика приказује мапу животног циклуса издања софтвера:

Пре пуштања

# 6) Ослобађање

Коначно, долази време када производ морамо да испоручимо предвиђеним корисницима. Сви смо као тим напорно радили на одјави производа и омогућавању софтвера да помогне својим корисницима.

Изазови

Инжењери за испитивање софтвера првенствено су одговорни за издавање било ког софтвера. Ова активност захтева процес оријентисан на ток рада. Ево неколико најбољих пракси које су укључене у ову фазу.

Најбоље праксе

  • Увек имајте на уму да не радите на документу о издању на датум АКТУЕЛНОГ ИЗДАЊА.
  • Увек планирајте активност издања пре стварног датума издавања.
  • Стандардизирајте документ према политикама компаније.
  • Ваш документ о издању треба да покуша да утврди позитивна очекивања од софтвера.
  • У документу јасно наведите све софтверске и хардверске захтеве специфичне за њихове верзије.
  • Укључите све отворене недостатке и њихову тежину.
  • Не сакривајте велика погођена подручја због отворених недостатака. Дајте им место у документу о издању.
  • Нека се документ прегледа и дигитално потпише (могу се разликовати у складу са смерницама компаније).
  • Будите сигурни и пошаљите документ о издању заједно са софтвером.

Процес КА испитивања на стварном пројекту - метода водопада

Добио сам занимљиво питање од читаоца, Како се тестирање врши у компанији, тј. У практичном окружењу?

Они који се једноставно онесвијесте са факултета и почну тражити посао имају ову знатижељу - какво би било стварно радно окружење у компанији?

Овде сам се усредсредио на стварни радни процес Тестирање софтвера у компанијама .

Стварни процес испитивања у предузећима

Кад год добијемо било који нови пројекат, постоји иницијални састанак о упознавању пројеката. На овом састанку у основи разговарамо о томе ко је клијент? које је трајање пројекта и када је његова испорука? Ко је све укључен у пројекат, тј. Менаџер, технички водичи, КА потенцијални купци, програмери, тестери итд.?

Из СРС-а (спецификација софтверских захтева) развија се план пројекта. Одговорност тестера је да креирају план тестирања софтвера на основу овог СРС-а и пројектног плана. Програмери започињу кодирање од дизајна. Рад на пројекту подељен је на различите модуле и ти модули се дистрибуирају међу програмерима.

У међувремену, одговорност тестера је да креира тест сценарио и напише тест случајеве према додељеним модулима. Покушавамо да покријемо готово све случајеве функционалних тестова из СРС-а. Подаци се могу ручно одржавати у неким Екцел предлошцима за примере или алатима за праћење грешака.

Када програмери заврше појединачне модуле, ти модули се додељују тестерима. Испитивање дима се врши на овим модулима и ако не успеју на овом тесту, модули се поново додељују одговарајућим програмерима ради исправке.

За положене модуле врши се ручно тестирање из писаних тест случајева. Ако се пронађе било која грешка која се додели програмеру модула и пријави у алат за праћење грешака . Када је реч о исправци грешака, тестер врши верификацију грешака и тестирање регресије свих повезаних модула. Ако грешка прође верификацију, она се означава као верификована и означава као затворена. У супротном, горе поменути циклус грешака се понавља. (Обрадићу животни циклус грешке у другом посту)

Изводе се различити тестови на појединачним модулима и интеграционо тестирање на интеграцији модула. Ови тестови укључују тестирање компатибилности, тј. Тестирање апликација на различитом хардверу, верзијама ОС-а, софтверским платформама, различитим прегледачима итд.

Испитивање оптерећења и напрезања такође се врши према СРС. Коначно, системско тестирање се врши стварањем виртуелног клијентског окружења. Када се изврше сви случајеви испитивања, припрема се извештај о испитивању и доноси одлука о пуштању производа!

Кораци у захтевима за објављивање

У наставку су дати детаљи сваког корака тестирања који се спроводи у сваком квалитету софтвера и животном циклусу тестирања наведеним у ИЕЕЕ и ИСО стандарди.

# 1) Преглед СРС-а : Преглед спецификација софтверских захтева.

# 2) Циљеви постављени су за главна издања.

# 3) Циљани датум планирано за издања.

# 4) Детаљан план пројекта се гради. То укључује одлуку о спецификацијама дизајна.

# 5) Развити план испитивања заснива се на спецификацијама дизајна.

# 6) План испитивања: То укључује циљеве, методологију усвојену током тестирања, карактеристике које треба тестирати, а не тестирати, критеријуме ризика, распоред тестирања, подршку на више платформи и расподјелу ресурса за тестирање.

# 7) Спецификације теста: Овај документ укључује техничке детаље (софтверске захтеве) потребне пре тестирања.

# 8) Писање тест случајева

# 9) Развој: Модули се развијају један по један.

# 10) Везивање инсталатера: Инсталатери се граде око појединачног производа.

како створити низ низова у јави

#Једанаест) Процедура израде : Изградња укључује инсталатере доступних производа - више платформи.

# 12) Тестирање: Тест дима (БВТ): Основни тест примене за доношење одлуке о даљем испитивању.

  • Тестирање нових карактеристика
  • Цросс-бровсер и тестирање на више платформи
  • Тестирање напрезања и испитивање цурења меморије.

# 13) Резиме теста

# 14) Замрзавање кода

  • Тренутно се не додају нове функције.

# 15) Тестирање: Израда и регресијско тестирање.

# 16) Одлука о пуштању производа.

# 17) Сценарио након објављивања за даље циљеве.

Ово је био резиме стварног процеса тестирања у окружењу компаније.

Закључак

Посао испитивача софтвера препун је изазова, али ипак пријатних. Ово је за некога ко је подједнако страствен, мотивисан и пун ентузијазма. Проналажење грешака код некога није увек лак посао! Ово захтева много вештина и бико око за недостатке.

Поред свих квалитета, испитивач треба да буде и оријентисан на процес. Као и све друге индустрије, пројекти у ИТ-у превише се раде у фазама, где свака фаза има неке добро дефинисане циљеве. И сваки циљ има добро дефинисан критеријум прихватања. Инжењер теста мора на својим плећима носити много терета софтвера.

Током рада у било којој фази софтвера, тестери би требало да следе најбоље праксе и треба да се ускладе са процесом који је укључен у одговарајуће фазе. Праћење најбољих пракси и добро формулисаних процеса не само да олакшава рад тестера, већ помаже и у обезбеђивању квалитета софтвера.

Да ли сте били део неке од горе наведених фаза? Слободно поделите своја искуства у наставку.

Препоручено читање

^