Дефектни животни циклус - Као што сте већ можда свесни да је извршење теста фаза у којој би испитивач заправо извршио тестне скрипте. Процес извођења тестних скрипти варира од компаније до компаније и може бити различит у различитим пројектима унутар исте компаније.
Данас су доступни алати за извршење пробних тестова, алати попут - Центар за квалитет, Мицрософт визуелни студио и тако даље. Стварни поступак извођења сваког корака ради упоређивања стварног и очекиваног резултата остаје исти за функционални испитивач без обзира на алате који се користе.
- Шта ако стварно понашање није једнако очекиваном понашању?
Када испитивач утврди да стварни резултат испитивања није једнак очекиваном, евидентира се квар.
- Како пријавити квар?
Данас је на располагању много алата, неки од алата за евидентирање кварова су ЦлеарКуест из ИБМ-а, ХП-овог Центра за квалитет, алати отвореног кода попут животног циклуса оштећења у ЈИРА-и и тако даље.
Постоје нека обавезна поља која су уобичајена за различите алате за евидентирање кварова, а та поља су -
- Опис животног циклуса дефекта Опис
- Сажетак животног циклуса
- Погрешка пријављена у
- Дефект додељен
- Дефецт Северити
- Приоритет дефекта
- Додатни снимци
- Број / име
Дефецт Лифе циклус
Животни циклус Дефекта почиње од бележења нове грешке. Кад год се забиљежи квар, прелази у ново стање.
Тестер - Нови дефект
Коме доделити нови квар?
Тестер може додијелити неисправност програмеру или развојном водичу. Ова одлука о додјели недостатка варира од пројекта до пројекта. На неким радним местима постоји процес животног циклуса оштећења да би се он доделио директно одговарајућем програмеру, а на неким местима се дефект додељује водичу за развој, а дев води заузврат додељује програмеру.
Дефецт Ассигнмент (Ново) - Девелопер Лифе Цицле Девелопер
Додјела дефекта (ново) - Дев Леада Девелопер
Анализа дефеката
Програмер ће анализирати квар да провјери је ли могуће поновити. Овде је најважнији допринос теста за укључивање свих потребних детаља у квар. Резиме дефекта, детаљан опис дефекта су поља која помажу актерима да разумију недостатак у једном потезу. Сажетак дефекта увек треба да садржи само информације о квару на високом нивоу. Истовремено треба имати довољно информација да у једном ретку опише преглед квара.
Опис дефекта је место где се очекује да испитивач садржи све потребне информације као што су окружење, сценариј, коришћени тестни подаци, очекивани резултат, стварни резултат, референца на датотеке / податке и референца на снимак.
Ево кратког прегледа различитих елемената детаљаног описа дефекта -
Животна средина
Испитна околина у којој је утврђен квар. Пројекти често имају више окружења у којима тестни тим врши тестирање. На пример - АТ (окружење за тестирање склопа), ПТ (окружење за тестирање производа), УАТ (окружење за тестирање прихвата од стране корисника) и тако даље. Сврха постојања различитих окружења је та што омогућава флексибилност унутар развојног и тестног тима како би се код распоредио у било којем од расположивих окружења како би на време започео тестирање.
Постоје случајеви када се тест производа (који се назива и системски тест) и УАТ тестирање преклапа, па је потребно вишеструко окружење да настави паралелно тестирање.
Има случајева када је развојном тиму потребно додатно окружење за уклањање погрешака у проблемима о којима је тестирао тим за тестирање. Такође тим за развој има посебно окружење за задатак јединице за тестирање.
Због више окружења мора се у квару споменути одређено окружење у којем је проблем пронађен.
Сценарио
Сценариј је скуп корака које је извршио испитивач и који су довели до оштећења. Овде се очекује да ће испитивач поменути све кораке које програмер може извршити да би репродуковао квар. Често постоје случајеви када испитивач пријави квар о грешци, али програмер није у стању да га реплицира и самим тим се квар одбија. То се може догодити због погрешних корака / недостајућих корака наведених у опису. Јасни кораци помажу свима да схвате квар и реплицирају га без потребе за приступом испитивачу како би добили уносе. Добро документовани сценарио је једноставан за читање, лако разумљив и прецизни кораци које треба слиједити да би се реплицирала оштећења.
Тест подаци
Тестер треба да наведе податке коришћене током тока испитивања што је довело до проблема. Ове информације пружају програмеру шансу да користе сличне податке да би репродуковали квар и пронашли основни узрок истог.
Постоје неки сценарији у којима испитивач нађе дефект помоћу одређених података, али исти проблем није поновљив користећи сличне податке. То се може догодити због оштећења података, па унос података даје шансу да се открије главни узрок оштећења. Програмер се можда неће копати до нивоа кода ако је у питању корупција података. Ова врста оштећења може се претворити у дефект података.
Очекивани и стварни резултат
Ово је истакнуто поље детаљног описа где испитивач доказује да је уочена грешка заиста оштећење. Јасно спомињање очекиваног резултата јасно чини ствари за сваког власника удела да грешку сматрају недостатком. Замислите да је грешка евидентирана са свим детаљима, али не одређује очекивани исход сценарија!
Обично тестер унесе само очекивани резултат може бити у линији или два, али је врло важно навести извор очекиваног резултата. Извор овде упућује на документ у којем се помиње очекивани резултат. Ово би могао бити документ са захтевима или референца на плочи с књигама.
Референца на датотеке / податке
Понекад дефект укључује стварање датотеке или унос као датотеку. У оваквим сценаријима, тестер би требао пружити информације о датотеци која је кориштена и која је узроковала проблем у апликацији. Ове се датотеке могу приложити помоћу алата за управљање оштећењима или се могу дати референце за исте. Овим референтним локацијама треба да приступе све заинтересоване стране.
Упућивање на снимку
Снимци имају врло важну улогу када желите да им покажете тачну поруку о грешци пробијања странице како је приказана на екрану или када желите да покажете детаље о навигацији на екрану. Снимка даје брзу представу о уоченом квару, екрану на којем је квар пронађен, подацима који се користе на екрану и тако даље. Свака алатка за управљање оштећењима садржи могућност приказивања снимака. Понекад тестер може да дода и Екцел прорачунске табеле или Вордове документе.
То су биле различите компоненте евидентирања кварова и најбоље праксе за сваку од њих. По повратку у животни циклус оштећења, након што је квар додељен програмеру, он ће га анализирати користећи податке наведене у ставци оштећења. Ако је, према анализи, евидентирани проблем заиста оштећен, програмер ће „отворити“ квар да би радио на његовом отклањању.
Препоручени курсеви
- Веб услуге у пакету Јава Траининг Бундле
- Тренинг о развоју игара у Ц ++
- Комплетна обука о етичком хаковању
- Вегас Про 13 курсева за обуку
Ново - Отворено
Квар у отвореном статусу показује да се налази у развојној плочици и програмери раде на његовом отклањању. Ако анализа утврди да евидентирани проблем није квар, то се може догодити када постоји јаз у разумевању очекиваног понашања система. Ако анализа каже да је квар неваљан, програмер ће га одбити. Терминологија је „Одбачена“ или „Повратак на тестирање“.
Ново - Повратак на тестирање.
Како испитивач треба да потврди да ли је оштећење заиста било неважећи?
Ово је сценарио где прецизан документ са захтевима помаже свима у тиму да дођу до закључка ако је пријављени квар неважећи или валидан. Позивање на документацију о захтевима помаже испитивачу и програмеру да дођу до истог закључка и то стварно олакшава процес дискусије.
Постоје сценарији у којима се доводи у питање исправност докумената о дизајну и захтевима приликом упућивања тих докумената у време дискусија о кваровима, а у таквим се временима повратак на Бусинесс Аналист сматра најбољом опцијом за разјашњење упита.
Као најбоља пракса, захтеви и документација за пројектовање треба да буду увек ажурирани како би се могли упућивати без икаквих нејасноћа.
У статусу „Отворено“, развојни тим ради на поправљању оштећења, након што је грешка исправљена, статус се мења у „Спреман за размештање“.
Отворено - Спремно за употребу
Примена је процес где се промене преносе на сервер тако да тим за тестирање може да ради на фиксној верзији кода. Обично сваки пројекат има посебан тим за имплементацију за овај задатак.
Дакле, на високом нивоу, софтверски тим углавном се састоји од ове 3 групе -
- Развој
- Дефектни животни циклус током испитивања
- Увођење (или се понекад назива и Буилд тим)
Једном када је састављена верзија и квар је поново доступан за поновно тестирање, додељен је одговарајућем испитивачу за задатак поновног тестирања.
Дефект додељен испитивању.
Водич за тестирање - појединачни испитивач.
Одређени дефект - Индивидуални испитивач.
На неким радним местима, дефект се прво додељује Тест олову, а он заузврат га додељује индивидуалном испитивачу, али на неким местима, дефект је директно додељен испитивачу који би га тестирао или оном који је подигао квар.
Овде се статус мења од Спреман за размештање - Спреман СИТ тестирање.
Сада је квар на плочици тестера. Тим за тестирање ће потврдити квар и постоје две могућности, или ће исправка исправно радити или се поново појављује исти проблем. Зависно од исхода исхода може прећи на следеће статусе -
Спреман СИТ тестирање - затворен
Спреман СИТ тестирање - поново отворити
У оба горња сценарија, тестер је дужан да дода коментаре извршених тестирања. Ово укључује спомињање тестираних сценарија и коришћене податке. Ако се квар поново отвори, испитивач треба да пружи тачне кораке који су опет довели до грешке.
Статус поновног отварања је исти као статус „новог“ оштећења.
Једном када се квар поново отвори, уследиће поново исти циклус.
Изазови у животном циклусу
- Одлучивање о тежини грешке - ово је једна од најчешћих тема дискусија (често се свађа) међу програмерима тестера в / с.
- Дефект се не може обновити на систему програмера.
- Дефект је постављен на основу сценарија који није поменут у захтевима и пројектним документима.
- Откривен је дефект, али исти се не може поправити јер појава сценарија о производном окружењу није изведива.
Како тестер треба да превлада изнад изазова?
- Јачина је директно пропорционална утицају који оштећење изазива на апликацију, ако испитивач не може да настави због оштећења, сигурно је означен са највећом озбиљношћу.
- Ако постоји решење за наставак тестирања, то треба означити као средњу озбиљност. Поред разматрања утицаја даљег испитивања животног циклуса оштећења, о озбиљности се такође може одлучити имајући у виду ситуацију када читав модул не успева, у овом случају иако се може извршити тестирање другог модула, али озбиљност тренутног модула је велика па дефект треба означити највећом озбиљношћу.
- Ако се квар не може репродуцирати на систему програмера, постоје шансе да развојно и тестно окружење нису усклађени. Квар који се може тестирати на систему тестирања увек се сматра валидним оштећењем.
- Постоје ситуације када се грешка евидентира узимајући у обзир целокупни пословни сценариј, али директни сценарио није наведен у захтевима или пројектном документу. Увек се сматра најбољом праксом да се узму у обзир стварни пословни сценарији уместо да се следе само кораци испитивања. Комуникација са пословним аналитичарима и осталим учесницима производа игра важну улогу за евидентирање таквих недостатака.
- Постоје сценарији када тестер утврди јаз у пословној логици током фазе тестирања. Налажење таквих празнина поново се сматра великим плусом за тестера. Празнине у дизајну обично се решавају помоћу побољшања.
- Побољшање - Ако се понашање мора променити током фазе тестирања животног циклуса софтвера, ствара се унапређење које се може узети у тренутном или следећем издању с обзиром на временске рокове и опсег развојних и тестних тимова.
- Постоје неки сценарији које тестирач може тестирати током ад-хоц тестирања који би заправо могли бити неважећи сценарији, с обзиром на могућност њихове појаве у производњи.
Ко је најбољи пријатељ тестера?
Куда треба да иде испитивач у случају нејасноћа? Одговор зависи од врсте упита, ако се упит тиче захтева, препоручљиво је прво разговарати унутар тима за исправљање разумевања система, тако што ћете се консултовати са старијим члановима. Сљедећа тачка контакта би требали бити пословни аналитичари.
Ако се упит односи на поступак тестирања, препоручљиво је контактирати водство за тестирање или руководитеља испитивања.
Ако се упит односи на разумијевање техничких карактеристика апликације, члан развојног тима могао би бити права особа којој треба приступити.
Будући да је тестирање процес који захтева свеобухватно разумевање система, комуникација помаже тестеру да добије брзи одговор на упите, само зависи од постављања правих питања правим особама. Одустајање од постављања питања у право вријеме може довести до оштећења пропуштања у производно окружење.
Колико је данас важна улога тестера у корпорацији?
Постоје пројекти где је тим за тестирање подједнако важан као и развојни тим и у неким сценаријима постоји већа зависност од испитног тима него од развојног тима. Каснији сценарио је редак, али постоји на неким радним местима. То се дешавало током времена и може бити током одређеног временског периода када развојни тим нема много искуства у поређењу са тимом за тестирање. Постоје људи који разумеју укупни ток и функционалност боље од већине осталих чланова тима. Таква особа може бити део тима за тестирање / развој. Ово је један од фактора који одлучује о зависности тима / појединца за одређени пројекат.
Какав је пут каријере за тестера?
Појединцу ће требати мало времена да разуме целокупни процес тестирања, домене и друге задатке над којима се очекује да ради у свакодневном животу. На основу овог разумевања, препоручљиво је донети одлуку за истраживање даљих подручја која би испитивач могао да заузме. Увек постоје могућности за аутоматизацију различитих токова. Стварање малих услужних програма такође може помоћи тиму на велики начин. Ако је тестер добар у програмирању, то се сматра великим плусом. Ово отвара могућности за улогу аутоматизације. Тестирање перформанси је такође један од начина каријере за тестере. Бизнис аналитичар је друга опција. Добро познавање домена са добрим комуникацијским вештинама су неопходни сетови вештина да буду пословни аналитичари. Тестирање отвара бројне могућности за тестере за рад на различитим доменима, алатима, процесима и тако даље. Само зависи од појединца да покупи и крене дубоко у једно од главних подручја тестирања. Постоји много сертификата специфичних за разне алате који су специјализовани за једну област тестирања. Имати сертификат од стандардног добављача предност је за унапређење каријере, али сам сертификат вам дугорочно не може помоћи ако није комбинован са исправним радним искуством.
Препоручени чланци
Ево неколико чланака који ће вам помоћи да сазнате више детаља о тестирању софтвера, па само пређите на линк.
- 6 најневероватнијих питања за испитивање интервјуа са софтвером
- Каријере у тестирању софтвера
- Како доћи до бољег каријерног раста у раду тестера софтвера