Меню

Проследяване на програмни грешки на живо, тестови показатели и тестови подписвания - Безплатно обучение за QA 6-ти ден

live project bug tracking

Опитайте Нашия Инструмент За Премахване На Проблемите

Това е заключителната част на нашата „ Обучение за тестване на софтуер по проект на живо ”Серия.

Ще става дума за дефекти, както и за няколко останали теми, които ще отбележат завършването на фазата на тестовото изпълнение на STLC.

В предишна статия , докато течеше Изпълнението на теста, срещнахме ситуация, при която очакваният резултат от тестовия случай не беше изпълнен. Също така установихме някои неочаквани поведения по време на изследователско тестване.

Проследяване на програмни грешки на живо, метрични тестове и тестово изписване

Какво се случва, когато се сблъскаме с тези отклонения?

Очевидно трябва да ги запишем и да ги проследим, за да сме сигурни, че тези отклонения ще бъдат обработени и в крайна сметка фиксирани на AUT.

# 1) Тези отклонения се наричат ​​Дефекти / грешки / проблеми / инциденти / грешки / грешки.

# две) Всички следващи случаи могат да бъдат регистрирани като дефекти

  • Липсващи изисквания
  • Неправилно работещи изисквания
  • Допълнителни изисквания
  • Несъответствия в справочния документ
  • Проблеми, свързани с околната среда
  • Предложения за подобрения

# 3) Записването на дефекти се извършва предимно в Excel листове или чрез използване на софтуер / инструмент за управление на дефекти. За информация как да се справите с дефекти чрез инструменти, опитайте да използвате следните връзки:

Какво ще научите:

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

Сега ще се опитаме да видим как да регистрираме дефектите, които сме срещнали в предишната статия, в лист на Excel. Както винаги, изборът на стандартен формат или шаблон е важен.

въпроси за интервю за селен за 4 години опит

Обикновено следните колони са част от отчета за дефекти:

  • Идентификационен номер на дефект: За уникална идентификация.
  • Описание на дефекта: Това е като заглавие за кратко описание на проблема.
  • Модул / секция на AUT: Това не е задължително, само за да се добави повече яснота, за да се посочи зоната на AUT, където е възникнал проблемът.
  • Стъпки за възпроизвеждане: Каква е точната последователност от операции, които трябва да бъдат извършени на AUT за пресъздаване на грешката, трябва да бъдат изброени тук. Също така, ако някакви входни данни са специфични за проблема, тази информация също трябва да бъде въведена.
  • Тежест: За да се посочи интензивността на проблема и евентуално въздействието, което това може да окаже върху функционирането на AUT. Указанията за това как да се присвоят и какви стойности да се присвоят в това поле могат да бъдат намерени в документа за план за изпитване. Така че, моля, обърнете се към Документ за план за изпитване от член 3 .
  • Състояние: Ще бъде обсъдено допълнително в статията.
  • Снимка на екрана: Снимка на приложението, за да се покаже грешката, когато се е случила.

Това са някои от полетата „задължително“. Този шаблон може да бъде разширен (напр. Да включва името на тестера, който е докладвал за проблема) или да бъде сключен договор ( Например, името на модула е премахнато) според нуждите.

Следвайки горните указания и използвайки шаблона по-горе, примерен дневник / доклад за дефекти може да изглежда така:

Примерен доклад за дефекти за проект OrangeHRM Live:

Доклад за дефекти на OrangeHRM

=> Щракнете тук, за да изтеглите доклад за дефекти на проект на живо

По-долу е примерният доклад за дефекти, създаден в инструмента за управление на тестове qTest: (Щракнете върху изображението, за да го увеличите)

Примерен доклад за дефекти

Дефектите не са добри, когато ги регистрираме и ги запазим за себе си. Ще трябва да ги назначим в правилния ред, за да действат съответните екипи по тях. Процесът - кого да зададете или какъв ред да следвате, също може да бъде намерен в документа за план за тестване. Той е най-вече подобен на (Щракнете върху изображението, за да го увеличите)

Цикъл на дефекти:

Жизнен цикъл на дефекти 1

От горния процес може да се отбележи, че грешките преминават през различни хора и различни решения в процеса на идентифициране се отстраняват. За да се проследи и установи прозрачност точно в какво състояние е определена грешка, в отчета за грешка се използва поле „Състояние“. Целият процес се нарича „жизнен цикъл на грешки“. За повече информация относно всички статуси и техните значения, моля, обърнете се към това Урок за жизнения цикъл на грешки .

Няколко указатели при проследяване на грешки

  • Когато сме нови за творчески екип / проект / AUT, винаги е най-добре да го направим обсъдете проблема, който срещнахме с връстник, за да се уверим, че нашето разбиране за това, което наистина прави дефект, е правилно или не.
  • Да се предоставете цялата информация това е необходимо за възпроизвеждане на проблема. Дефект, който се връща на екип за тестване със статус, зададен като „Няма достатъчно информация“, не се отразява много положително на нас. Вижте тази публикация - Как да разрешите всички грешки без етикет „Невалидна грешка“ .
  • Проверете дали е повдигнат подобен проблем, преди да създадете нов. „Дублирани“ проблеми са и лоши новини за екипа на QA.
  • Ако има проблем, който се появява произволно и ние не знаем точните стъпки / ситуации, в които можем да пресъздадем проблема - повдигнете проблема все пак. С риск въпросът да бъде настроен на „Невъзпроизводимо / недостатъчно информация“ - все още трябва да сме сигурни, че сме се справили с всички възможни неизправности във възможно най-добрата степен.
  • Общата практика е, че екипът на QA създава дефекти на всеки един в Excel лист през деня и го консолидира в края на деня.

Пълният жизнен цикъл на дефектите

За нашия проект на живо, ако трябва да следваме жизнения цикъл на дефекта за дефект 1,

шлюзът по подразбиране не е наличен windows 10 wifi
  • Когато аз (тестерът) го създам, състоянието му е 'Ново”. Когато го присвоя на предводител на QA екипа, състоянието все още е „Ново“, но собственикът вече е QA олово.
  • Възможността за осигуряване на качеството ще прегледа проблема и след като определи, че е валиден, изданието се присвоява на потенциалния разработчик. На този етап състоянието е 'Възложено' а собственикът е Dev lead.
  • След това водещият разработчик ще възложи този проблем на разработчик, който ще работи по отстраняването му. Сега състоянието ще бъде 'Работа в процес на осъществяване' (или нещо подобно на този ефект), собственикът е разработчикът.
  • За дефект 1 разработчикът не е в състояние да възпроизведе грешката, затова я възлага обратно на екипа за QA и задава състоянието като 'Не може да се възпроизвежда”.
  • Алтернативно, ако разработчикът е могъл да работи по него и да отстрани проблем, състоянието ще бъде зададено на 'разрешен' и изданието ще бъде възложено обратно на екипа за осигуряване на качеството.
  • След това екипът на QA ще го вземе, ще тества повторно проблема и ако е отстранен, ще зададе статуса на 'Затворено' . Ако проблемът все още съществува, състоянието е зададено на 'Отворете отново' и процесът продължава.
  • В зависимост от другите ситуации, състоянието може да бъде зададено като 'Отложено' , „Няма достатъчно информация“, 'Дубликат' , 'работи по предназначение' и т.н. от разработчика.
  • Този метод за регистриране на дефектите, докладване и присвояване на тях, управлението им е една от основните дейности, изпълнявани от членовете на QA екипа по време на фазата на изпълнение на теста. Това се прави ежедневно, докато определен цикъл на изпитване не завърши.
  • След като цикъл 1 приключи, екипът на разработчиците ще отнеме ден или два, за да консолидира всички корекции и да възстанови кода в следващата версия, която ще се използва за следващия цикъл.
  • Същият процес отново продължава и за цикъл 2. В края на цикъла има вероятност в приложението все пак да има някои проблеми „Отворени“ или нефиксирани.
  • На този етап - продължаваме ли все още с цикъл 3? Ако да, кога ще спрем тестването?

Критерии за изход за тестване на OrangeHRM Live Project

Тук използваме това, което бихме нарекли „критерии за изход“. Това е предварително дефинирано в документа за план за изпитване. Просто под формата на контролен списък ще се определи дали ще приключим тестването след цикъл 2 или ще преминем към още един цикъл. Изглежда по-долу, когато се попълва, като се вземат предвид някои хипотетични отговори на следните въпроси, свързани с проекта OrangeHRM:

Критерии за изход за тест

Когато разгледаме внимателно горния контролен списък, има показатели и изписване, споменати там, които не сме обсъждали по-рано. Нека поговорим за тях сега.

Тестови показатели

Установихме, че по време на фазата на тестовото изпълнение се изпращат доклади до всички останали членове на проектния екип, за да се даде ясна представа за това какво се случва във фазата за изпълнение на QA . Тази информация е важна за всички, за да получи потвърждение за цялостното качество на крайния продукт.

Представете си, че докладвам, че са преминали 10 тестови случая или са изпълнени 100 тестови случая - тези цифри са просто сурови данни и не дават много добра перспектива за това как се случват нещата.

Показателите играят жизненоважна роля за запълване на тази празнина. Метриките са с прости думи, интелигентни числа, които екипът за тестване събира и поддържа . Например, ако казах, че са преминали 90% от тестовите случаи, има по-голям смисъл, отколкото да кажа, че са преминали 150 тестови случая. Нали?

Има различни видове метрики, събрани по време на фазата на изпълнение на теста. Какви точно показатели трябва да се събират и поддържат за какви периоди от време - тази информация може да бъде намерена в документа за тестовия план.

По-долу са най-често събираните тестови показатели за повечето проекти:

  • Успешен процент на тестовите случаи
  • Плътност на дефектите
  • Процент на критичните дефекти
  • Дефекти, мъдро число за сериозност

Вижте Доклад за състоянието, приложен към тази статия за да видите как се използват тези показатели.

Отчет за тестово изписване / Довършване

Тъй като трябва да уведомим всички заинтересовани страни, че тестването е започнало, задължението на екипа за QA е да уведоми всички, че тестването е приключило, и да сподели резултатите. И така, обикновено се изпраща имейл от екипа за осигуряване на качеството (обикновено ръководителят на екипа / мениджърът за осигуряване на качеството), който показва, че екипът за осигуряване на качеството е подписал продукта, като прикачи резултатите от теста и списъка с отворени / известни проблеми.

Примерен тестов имейл за излизане:

Да се: Клиент, премиер, екип за разработчици, DB екип, BA, QA екип, Екип за околната среда (и всеки друг, който трябва да бъде включен)
Електронна поща: Здравейте екип,

Екипът на QA се подписва на софтуера OrangeHRM версия 3.0 след успешното завършване на 2-те цикъла на функционално тестване на уебсайта.

Тестовите случаи и резултатите от тяхното изпълнение са приложени към имейла. (Или споменете местоположението, където се намират. Или ако използвате софтуер за управление на тестове, предоставете подробности относно същото.)

Списъкът с известни проблеми също е прикачен към имейла. (Отново може да се добавят всякакви други препратки, които имат смисъл.)

Благодаря,
QA ръководи екип.

Прикачени файлове: Окончателен доклад за изпълнение, окончателен доклад за проблем / дефект, списък с известни проблеми

След като имейлът за тестово отписване излезе от екипа за осигуряване на качеството, ние официално приключихме с процеса на STLC. Това не означава непременно завършването на фазата „Тест“ на SDLC. Все още трябва да завършим теста на UAT, за да се случи това. намирам повече подробности за тестването на UAT тук .

След като UAT приключи, SDLC се придвижва към фазата на внедряване, където отива в действие и е на разположение на своите клиенти / крайни потребители за консумация.

Това е!

Това беше нашето усилие да предоставим най-много на живо като QA Project опит на нашите читатели. Моля, уведомете ни за вашите коментари и въпроси относно тази безплатна онлайн серия за обучение за тестване на софтуера.

Препоръчително четене

^