Меню

Процес на дефектна триация и начини за справяне с дефектната триажна среща

  • Основен
  • Други
  • Процес на дефектна триация и начини за справяне с дефектната триажна среща

defect triage process

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

Пълно ръководство за процес на дефектна триация и ефективни начини за справяне с дефектната триажа:

В днешната статия ще научим за срещата на Defect Triage и как да се справим с триажната среща по по-лесен и ефективен начин.

Преди да продължа по-нататък с тази статия, бих искал всички да знаят какво се разбира под Дефект, Дефектен жизнен цикъл и как да зададете приоритет и сериозност за всеки дефект . И е необходимо да се разберат тези основни понятия, свързани с дефект или грешка.

Можете също да прегледате по-ранната ми статия ' Жизнен цикъл на дефекти и Процес на управление на дефекти ' за бързо разбиране на тези понятия.

Среща за дефекти на триажа

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

Общ преглед

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

Тежестта на заболяването или нараняването е основният критерий за консултация и въз основа на това всички пациенти са категоризирани съответно. Ако нараняването или здравето на който и да е пациент е много критично, тогава лекарите обикновено третират такива пациенти като приоритет и при необходимост се приемат.

Нормалните заболявания или некритичните наранявания се считат за по-нисък приоритет и такива пациенти се лекуват по-късно.

По същия начин терминът Triage се въвежда в софтуерното тестване за дефекти в приложението или проекта. Обикновено процесът на отстраняване на дефекти се прилага в големи проекти и в много случаи не е приложим за малки проекти. Има шансове да се идентифицират огромен брой дефекти в по-големи проекти от средни или малки проекти.

Също така при по-големи проекти честотата на идентифициране на дефекти е доста по-висока.

Погледнете изображението по-долу, което показва резултата от срещата за триаж на дефекти и дава отговори на конкретни въпроси като:

Дефект триаж

Среща за дефекти на триажа

Основната цел на триажната среща е да се проследят всички дефекти и да се гарантира правилното разрешаване навреме.

По време на фазата на изпълнение на теста тестерите започват да отчитат дефекти в инструмента за управление на дефекти като HP ALM , QC и т.н. Тогава Среща за дефекти на триажа се провежда, при което разработчиците и изпитателите трябва да присъстват, тъй като тези хора ще обсъдят всички дефекти и ще предприемат необходимите по-нататъшни действия.

вид тестване в софтуерното инженерство

Основно присъствието на участниците по-долу се изисква задължително:

  • Ръководител проект
  • Тестово олово
  • Ръководител или разработчик
  • Тестер
  • Тест мениджър
  • Бизнес анализатор
  • Мениджър на околната среда

Въпреки че дадох изчерпателен списък на всички участници в срещата, не е необходимо да включваме всички тях като бизнес анализатор, мениджър на околната среда, мениджър на тестове и т.н. в ежедневната среща. Когато е необходимо, ръководителят на теста или ръководителят на проекта ги канят и те могат да споделят своите ценни отзиви и мнения относно конкретен дефект.

И целият екип е известен като a Екип за триаж . Сега ще обясня точния процес на триажната среща и как е организирана тази среща.

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

За настройване на среща Test Lead изпраща покана за среща по имейл до всички и определя конкретен график за Triage Meeting. Даденото по-долу хипотетично изображение показва поканата за събрание, изпратена от тестовия лидер чрез outlook до всички участници.

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

(Забележка:Щракнете върху всяко изображение за увеличен изглед)

Покана за триажна среща

Всеки ден преди началото на триажната среща, Test Lead изпраща списък на всички „Отворени“ дефекти е формат на електронна таблица до всички участници, за да могат да прегледат всички дефекти преди срещата и да разберат какъв точно е дефектът и какъв вид поправка се изисква за него.

Преди началото на всяка триажна среща, уверете се, че всеки дефект:

  • Има достатъчно информация, за да разбере дефекта за всички участници в срещата.
  • Отчита под правилен проект и категория.
  • Спомена приоритета и тежестта на дефектите.
  • Цялата подробна информация, предоставена в дефекта, за да я разберат правилно на всички участници.

Препоръчително четене => Пълно ръководство за процес на управление на дефекти

Шаблон за триеж на дефекти

Преди първоначалния старт на всяка среща с дефекти, Test Lead споделя доклада за дефекти на всички участници в определен формат и отчета, изваден от инструмента за управление на дефекти като HP ALM, HP QC и др. Показвам един примерен формат в изображение отдолу, което ще даде представа на високо ниво за това кои полета са споменати в шаблона за доклад за дефекти.

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

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

  • Идентификационен номер на дефект
  • Описание
  • Приоритет
  • Тежест
  • Открита дата
  • Открито от
  • Състояние

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

Обикновено форматът на електронната таблица се използва като шаблон за докладване на дефекти, поради което съм дал хипотетичните подробности за дефекти във формата на електронната таблица. Моля, обърнете внимание, че цялата информация, предоставена в горния доклад за дефекти, е само въображаема и не е свързана с никакъв проект или действително приложение.

Процес на дефектен триаж

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

Обикновено сесия за сортиране на дефекти присъства на продуктов мениджър, ръководител на разработката, тестов ръководител и понякога бизнес анализатори. В някои случаи някои други членове също могат да бъдат поканени да дадат своите мнения и перспективи относно определени дефекти. Те се наричат ​​колективно триажен екип.

Процес на дефектен триаж

Повечето системи използват приоритет като основен критерий за оценка на дефекта, но добрият процес на триаж отчита и тежестта.

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

Вторият, от друга страна, със сигурност е дефект във функционалността, но появата му е само при определени условия, които рядко се практикуват при клиентски сценарии. Поправянето му може да се нуждае от повече време и хора, което би могло да се използва по-добре за други дефекти. Следователно той би приел за по-нисък приоритет от този на първия и може би отлагане на кандидат за друго освобождаване.

По този начин процесът на триаж включва екип за триаж, който седи заедно, преглеждайки всички дефекти, включително отхвърлените дефекти. Те изготвят първоначална оценка на дефектите въз основа на съдържанието им, съответния им приоритет и настройките за тежест; като всеки човек от екипа за триаж представя своята гледна точка за това как да се определят приоритетите на дефектите.

След това продуктовият мениджър задава приоритета въз основа на всички входове и присвоява дефекта на правилната версия, т.е. в текущата версия или всяка бъдеща версия. Той също така пренасочва дефекта към правилния собственик / екип за по-нататъшни действия. Отхвърлените дефекти също се подлагат на подобен анализ. Въз основа на причината за отхвърлянето се определя футуристичното действие дали трябва да бъде отложено или отменено.

В срещата за триаж всеки дефект трябва да бъде обсъден, включително дефектите, които са категоризирани като по-нисък приоритет. Прегледът на триажния екип оценява всички дефекти и предприема необходимите действия за всеки дефект. Ако за дефект липсва информация, разработчикът възлага обратно такива дефекти на тестерите и иска исканата информация.

Триажната среща може да се проведе в заседателната зала, ако всички участници са на едно и също място. Но в много организации работата се извършва от различно място и всички екипи са разпределени на различни места, така че срещата се провежда и с помощта на телеконференция или бизнес Skype.

Участници в телеконференцията

( изображение източник )

Процедура стъпка по стъпка на срещата за сортиране на дефекти:

  • Test Lead започва срещата с доклад за дефекта, изпратен по-рано през деня.
  • Дискусията започва с действията, предстоящи от предишната триажна среща. Необходимите актуализации или действия, предприети по отношение на който и да е дефект, се обсъждат първоначално.
  • Ако има нови дефекти в доклада за дефекти, тогава тези дефекти се преглеждат и оценяват. Той също така проверява дали приоритетът и тежестта са зададени правилно, ако не, те се коригират в срещата.
  • Всички дефекти се обсъждат на срещата, а екипът за разработки обсъжда и сложността на отстраняването на дефекта. Рискът, свързан с дефекта, също се обсъжда от екипа за триаж.
  • Екипът на Triage стига до заключение, кой дефект трябва да изисква незабавно внимание и отстраняване и кой дефект трябва да изчака известно време и ако е необходимо, тези дефекти могат да бъдат отложени за бъдещи версии.
  • Всички дефекти се възлагат на съответния екип в QC или ALM едновременно по време на срещата. Подходящи коментари също се добавят в QC / ALM.
  • Всички основни актуализации и елементи за действие са отбелязани и тестовият лидер призовава за края на срещата.
  • След приключване на срещата на триажа, Test Lead изпраща протоколи от срещата на всички участници.

Роли и отговорности

Ролите и отговорностите въз основа на всяка категория са обяснени по-долу:

Тестово олово

  • Test Lead планира среща за дефектиране и изпраща официална покана за среща до необходимия екип.
  • Изпраща доклада за дефекта преди всяка триажна среща.
  • Започва срещата с предстоящите елементи за действие от предишната триажна среща.
  • Обсъдете всеки дефект и въздействие върху графика, ако някои функции са блокирани поради дефекта.
  • Помага за определяне на приоритет и тежест на всеки дефект, ако не е бил зададен правилно по-рано.
  • Актуализирайте QC / ALM с подходящи коментари.
  • Запишете всички актуализации, елементи за действие, риск, свързан с дефект и т.н.
  • Изпраща протоколи от срещата на всички участници.

Ръководител / разработчик

  • Споделяйте актуализации на елементите за действие, чакащи от последната среща за триаж
  • Обсъдете всички дефекти от техническа гледна точка.
  • Определете колко време ще е необходимо за поправяне въз основа на сложността на дефекта и функционалността.
  • Обсъдете сложността на дефекта и риска, свързан с дефекта, ако има такъв.
  • Lead Lead присвоява дефект на съответния разработчик след валидиране на цялата налична подробна информация.
  • Актуализира дефекта с очакваната дата на разрешаване.
  • Съдейства за идентифициране на основната причина за дефекта.

Ръководител проект

  • Уверете се, че ако всички представители от всяка област са на разположение за срещата.
  • Ако е необходимо, ръководителят на проекта кани Business Analyst на срещата за мнението им за конкретен дефект.
  • Ако дефектите не се движат или има някакъв основен блокер, ескалира с процеса на ескалация.
  • Ако е необходимо, действа като посредник, ако възникне спор или конфликт между екипите и взема необходимото решение.
  • Вземете потвърждението от разработчика за следващата дата на пускане за отстранени дефекти.
  • Уведомете актуализирания график и датата на пускане на проекта на всички екипи.

Понякога е добра идея да включите и останалите членове на екипа в триажното обаждане, така че те също да могат да разберат и да допринесат за срещата и ако е необходимо, те също могат да предоставят своите отзиви.

Заключение

Всеки регистриран дефект трябва да бъде обсъден на срещата за триаж.

Дори ако дефектът бъде отхвърлен, екипът за тестване трябва да знае причината за отхвърлянето. Също така, ако някой от дефектите не е възпроизводим, тогава по време на срещата на триажа разработчикът може да поиска от тестерите подробности в реално време и те да се опитат да възпроизведат дефекта.

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

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

Надявам се, че сте имали ясна представа за дефектната триажа, процеса на дефектна триация и начините за ефективно справяне със срещите на дефектните триажи!

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

^