Мени

Праћење грешака у пројекту уживо, метрике тестова и одјава са теста - бесплатни КА тренинг 6. дан

  • Главни
  • Праћење Грешака
  • Праћење грешака у пројекту уживо, метрике тестова и одјава са теста - бесплатни КА тренинг 6. дан

live project bug tracking

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

Ово је завршни део нашег „ Обука за тестирање софтвера на пројекту уживо ”Серија.

Биће речи о недостацима, а такође и о неколико преосталих тема које ће обележити завршетак фазе извршења теста СТЛЦ-а.

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

Праћење грешака у пројекту уживо, тест метрика и тест одјава

Шта се дешава када наиђемо на ова одступања?

Очигледно их морамо снимити и пратити како бисмо били сигурни да ће се та одступања решити и на крају поправити на АУТ.

# 1) Ова одступања називају се Дефекти / грешке / проблеми / инциденти / грешке / грешке.

#два) Сви следећи случајеви могу се евидентирати као недостаци

  • Недостају захтеви
  • Нетачно радни захтеви
  • Додатни захтеви
  • Неусаглашености референтног документа
  • Питања везана за животну средину
  • Предлози за побољшање

# 3) Снимање квара се углавном врши у екцел листовима или помоћу софтвера / алата за управљање недостацима. За информације о начину руковања недостацима помоћу алата, покушајте да користите следеће везе:

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

Како ефикасно евидентирати недостатке

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

употребе ц ++ у стварном свету

Следеће колоне су обично део извештаја о недостацима:

  • ИД квара: За јединствену идентификацију.
  • Опис дефекта: Ово је попут наслова који укратко описује проблем.
  • Модул / одељак АУТ: Ово није обавезно, само да бисмо додали више јасноће у погледу подручја АУТ-а на којем је дошло до проблема.
  • Кораци за репродукцију: Који је тачан редослед операција које треба извршити на АУТ-у за поновно стварање грешке, биће наведени овде. Такође, ако је било који улазни податак специфичан за проблем, те информације треба такође унети.
  • Озбиљност: Да би се назначио интензитет проблема и евентуално утицај који би ово могло имати на функционисање АУТ. Смернице за додељивање и које вредности треба доделити у овом пољу могу се наћи у документу плана испитивања. Дакле, погледајте Документ плана теста из члана 3 .
  • Статус: О томе ће бити више речи у чланку.
  • Снимак екрана: Снимак апликације који приказује грешку када се догодила.

Ово су нека од „обавезних“ поља. Овај образац се може проширити (нпр. Да укључи име тестера који је пријавио проблем) или уговорити ( На пример, име модула уклоњено) по потреби.

Слиједећи горње смјернице и користећи горњи образац, узорак дневника / извјештаја о недостацима могао би изгледати овако:

Узорак извештаја о недостацима за пројекат ОрангеХРМ Ливе:

Извештај о оштећењима компаније ОрангеХРМ

=> Кликните овде да бисте преузели извештај о недостацима пројекта уживо

Испод је пример извештаја о кваровима створен у алату за управљање тестовима кТест: (Кликните на слику за увећање)

Узорак извештаја о недостацима

Дефекти нису добри кад их евидентирамо и задржимо за себе. Морат ћемо их распоредити у правом редослиједу како би дотични тимови дјеловали на њих. Процес - коме доделити или којим редоследом следити такође се може наћи у документу плана испитивања. Углавном је слично (Кликните на слику за увећање)

Циклус оштећења:

Животни циклус оштећења 1

Из горњег процеса, може се приметити да грешке пролазе кроз различите људе и да се различите одлуке у процесу идентификовања фиксирају. За праћење и успостављање транспарентности тачно у ком је стању одређена грешка, у извештају о грешци користи се поље „Статус“. Читав процес се назива „животним циклусом грешака“. За више информација о свим статусима и њиховим значењима, погледајте ово Водич за животни циклус грешака .

Неколико упута током праћења грешака

  • Када смо нови у креативном тиму / пројекту / АУТ, увек је најбоље разговарати о проблему на који смо наишли са вршњаком како бисмо били сигурни да је наше разумевање онога што заиста чини недостатак тачно или не.
  • До пружити све информације то је неопходно за репродукцију проблема. Квар који се врати тиму за тестирање са статусом постављеним као „Нема довољно информација“ не одражава се позитивно на нас. Погледајте овај пост - Како решити све грешке без ознаке „Неважећа грешка“ .
  • Пре стварања новог проверите да ли је покренут сличан проблем. Питања „дупликата“ су такође лоше вести за КА тим.
  • Ако постоји проблем, који се појављује насумично, а ми не знамо тачно кораке / ситуације у којима можемо да га поново створимо - поставите проблем свеједно. Ризикујући да се питање постави на „Непоновљиво / нема довољно информација“ - још увек морамо бити сигурни да смо све могуће кварове решили у најбољој могућој мери.
  • Општа пракса је да КА тим ствара дефекте у екцел листу током дана и консолидује их на крају дана.

Комплетни животни циклус оштећења

За наш пројекат уживо ако бисмо пратили животни циклус квара за квар 1,

бесплатан једноставан иоутубе у мп3 претварач
  • Када га ја (тестер) креирам, његов статус је 'Нова”. Када га доделим вођи КА тима, статус је и даље „Ново“, али власник је сада КА вођа.
  • КА потенцијални клијент ће прегледати проблем и када утврди да је то важећи проблем, издавање се додељује потенцијалном клијенту Дев. У овој фази статус је 'Додељен' а власник је Дев леад.
  • Водич за програмере ће затим доделити овај проблем програмеру који ће радити на решавању овог проблема. Статус ће сада бити 'Рад у току' (или нешто слично том ефекту), власник је програмер.
  • За квар 1, програмер није у могућности да репродукује грешку, па је враћа натраг КА тиму и поставља статус као 'Није у стању да се репродукује”.
  • Ако би програмер могао да ради на томе и реши проблем, статус би се поставио на 'разрешен' и издање би било враћено КА тиму.
  • КА тим ће га тада подићи, поново тестирати проблем и ако је решен, поставиће статус на 'Затворено' . Ако проблем и даље постоји, статус се поставља на 'Поново отвори' а процес се наставља.
  • У зависности од осталих ситуација, статус се може поставити као 'Одложено' , „Нема довољно информација“, 'Дупликат' , 'радећи како је предвиђено' , итд. од стране програмера.
  • Овај метод евидентирања недостатака, извештавања и додељивања истих, управљање њима је једна од главних активности коју су чланови КА тима обављали током фазе извршавања теста. То се ради свакодневно док се одређени циклус испитивања не заврши.
  • Једном када се заврши 1. циклус, развојном тиму ће требати дан или два да обједине све исправке и обнове код у следећу верзију која ће се користити за следећи циклус.
  • Исти поступак се наставља и за циклус 2. На крају циклуса постоји могућност да у апликацији још увек постоје неки проблеми „отворени“ или неисправљени.
  • У овој фази - да ли и даље настављамо са циклусом 3? Ако је одговор да, када ћемо зауставити тестирање?

Излазни критеријуми за ОрангеХРМ тестирање пројеката уживо

Овде користимо оно што бисмо назвали „критеријуми изласка“. Ово је унапред дефинисано у документу Плана испитивања. Једноставно је у облику контролне листе која ће одредити да ли ћемо завршити тестирање након 2. циклуса или ћемо ићи на још један циклус. Изгледа да је доле наведено попуњавање узимајући у обзир неке хипотетске одговоре на следећа питања која се тичу ОрангеХРМ пројекта:

Критеријуми за излаз из теста

Када пажљиво погледамо горњу контролну листу, тамо се помињу метрике и одјаве о којима раније нисмо разговарали. Хајде да разговарамо о њима сада.

Тест Метрицс

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

Замислите да пријављујем да је прошло 10 тест случајева или је извршено 100 тест случајева - ови бројеви су само необрађени подаци и не дају баш добру перспективу о томе како се ствари одвијају.

Метрике играју виталну улогу у попуњавању ове празнине. Метрике су једноставним речима, интелигентни бројеви које тест тим прикупља и одржава . На пример, ако сам рекао да је прошло 90% тест случајева, то има више смисла него рећи да је прошло 150 тест случајева. Зар не?

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

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

  • Проценат позитивних резултата
  • Густина дефеката
  • Проценат критичних недостатака
  • Дефекти, озбиљан број

Погледајте Извештај о статусу у прилогу овог чланка да бисте видели како се користе ове метрике.

Извештај о пријављивању / завршетку теста

Како морамо да обавестимо све заинтересоване стране да је тестирање започело, такође је дужност КА тима да свима стави до знања да је тестирање завршено и да деле резултате. Дакле, обично се КА тим (обично водитељ тима / менаџер квалитета) шаље е-поруку која даје назнаку да се КА тим одјавио на производу прилажући резултате теста и листу отворених / познатих проблема.

Е-адреса за пријаву са тест узорка:

До: Клијент, ПМ, Дев тим, ДБ тим, БА, КА тим, Тим за животну средину (и било ко други који треба да буде укључен)
Емаил: Поздрав тиму,

КА тим се одјављује са софтвером ОрангеХРМ верзије 3.0 након успешног завршетка два циклуса функционалног тестирања веб странице.

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

Листа познатих проблема је такође приложена уз е-пошту. (Поново се могу додати било које друге референце које имају смисла.)

Хвала,
Вођење КА тима.

Прилози: Коначни извештај о извршењу, коначно издање / извештај о квару, листа познатих проблема

Када тим за КА пошаље е-поруку за одјаву са теста, званично смо завршили са СТЛЦ поступком. То не значи нужно завршетак фазе „теста“ СДЛЦ-а. Још увек имамо завршено УАТ тестирање да би се то догодило. Пронађи више детаља о УАТ тестирању овде .

По завршетку УАТ-а, СДЛЦ прелази на фазу постављања тамо где се активира и доступан је својим купцима / крајњим корисницима.

То је то!

Ово је наш напор да нашим читаоцима пружимо највише искустава попут КА пројекта. Обавестите нас о својим коментарима и питањима о овој бесплатној серији обука за тестирање софтвера на мрежи.

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

^