Сортиране на грешки/дефекти при тестване на софтуер

по: Томас Хамилтън Томас Хамилтън
Hours Обновено

⚡ Умно обобщение

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

  • 🔘 Основание: Оценявайте, приоритизирайте и разпределяйте всеки нов дефект, така че нищо важно да не се пропусне.
  • ☑️ Честота: Обикновено две или три срещи седмично, съобразени с графика на проекта и обема на дефектите.
  • ✅ Участници: Ръководителят на проекта, ръководителят на екипа за тестване, техническият ръководител и ръководителят на екипа за разработка присъстват като задължителни членове.
  • 🧪 Тежест и приоритет: Мерките за сериозност оказват влияние върху продукта, приоритетът определя реда на поправката.
  • 🛠️ Резултати от срещата: Показателите за сортиране на дефекти действат като протоколи и подават данни за следващата сесия за сортиране.
  • ⚡ Инструментална: Всяко решение се записва в бъга tracсистема king, така че одитната следа да оцелее след срещата.
Прочетете повече

Процес на сортиране на грешки и дефекти при тестване на софтуер

Какво е „триаж на дефекти“?

Сортирането на дефекти е процес, при който всяка грешка се приоритизира въз основа на нейната тежест, честота, риск и др. Терминът „сортиране“ се използва в Тестване на софтуер / QA за определяне на тежестта и приоритета на новите дефекти.

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

Защо се нуждаем от „триаж на дефекти“?

Целта на Bug Triage е да оцени, приоритизира и възложи разрешаването на дефектите. Екипът трябва да потвърди сериозността на дефекта, да направи промени според нуждите, да финализира разрешаването на дефектите и да присвои ресурси. Използва се главно при гъвкаво управление на проекти.

Без триаж, дефектите остават в tracкер с каквато и сериозност да е избрал тестващият докладчика, а разработчиците избират работа според лични предпочитания, а не според въздействието върху бизнеса. Банерът по-долу обобщава причините, поради които екипите запазват срещата в календара.

Защо е необходимо сортиране на грешки и дефекти в QA проект

Колко често трябва да се извършва „Сортиране на дефекти“ в издание?

Честотата на срещата за сортиране на дефекти не е фиксирана. Зависи от ситуацията на проекта.

Ето някои важни фактори, които определят честотата на срещите за сортиране на дефекти:

Тези важни фактори са:

  • Според графика на проекта
  • Брой дефекти в системата
  • Въздействие върху графиците за наличност на членовете на екипа
  • Цялостно здраве на проекта

Обикновено срещите за сортиране на дефекти се провеждат два или три пъти седмично.

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

Кои са задължителните и другите участници в „Триаж на дефекти“?

Задължителни участници

По-долу членовете на проекта винаги участват в срещи за сортиране на дефекти.

  • Ръководител на проекта
  • Ръководител на тестовия екип
  • Техническо ръководство
  • Ръководител на екип за развитие

Участници по избор

  • Разработчици
  • тестери
  • Бизнес анализатор

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

Роли и отговорности на участниците по време на „Сортиране на дефекти“.

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

Ръководител на тестовия екип

  • Насрочена среща за сортиране на грешки и изпращане на известие за среща за присъстващите.
  • Създайте доклад за дефекти и го изпратете до всички присъстващи преди срещата.
  • Задайте приоритет и суровост на дефектите.
  • Направете презентация, така че другите членове да разберат основната причина за дефекта.
  • Всяка бележка от срещата се записва и изпраща на участниците в срещата.

Олово за развитие

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

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

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

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

Отговорности на ръководителя на проекта по време на среща за сортиране на дефекти

СВЪРЗАНИ СТАТИИ

Какво се случва по време на срещата „Триаж на дефекти“?

  • Ръководителят на тестовия екип изпраща доклад за грешка с новите дефекти. По време на срещата за сортиране на дефекти всеки дефект се анализира, за да се види дали са му присвоени правилен приоритет и сериозност.
  • Приоритетите се пренареждат, ако е необходимо.
  • Дефектите се анализират и оценяват по степента на тяхната тежест.
  • Това включва дискусия по отношение на сложността на дефекта, рисковете, отхвърлянето, извършва се преназначаване на грешки.
  • Актуализациите са записани в бъг tracцарска система.
  • QA инженерът ще направи промените за всеки дефект и ще ги обсъди с всеки присъстващ.
  • Полето „Коментари“ се актуализира правилно, като се отбелязват основните моменти от срещата.

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

Аспект Суровост Приоритет
Какво измерва Колко сериозно дефектът уврежда продукта или неговата функционалност Колко скоро трябва да бъде отстранен дефектът в сравнение с останалата работа
Обикновено се задава от Тестерът, който докладва за дефекта Съгласувано в триаж, с ръководител на проекта и продуктово отделение
Каран от Техническо въздействие и засегнатата функционалност Въздействие върху бизнеса, видимост върху клиентите и дата на пускане
Пример за несъответствие Висока тежест, нисък приоритет: срив във функция, която никой не използва до следващото тримесечие Ниска тежест, висок приоритет: неправилно изписано име на фирмата на целевата страница

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

Какъв е резултатът от „триажа на дефектите“?

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

Докладът е моментът, в който триажът се свързва с по-широкия контекст. процес на управление на дефектиЕкипите обикновено улавят следното в него:

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

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

Въпроси и Отговори

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

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

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

Един отчет се запазва като главен, а останалите са свързани с него и се затварят като дубликати. Затварянето им безшумно губи информация, така че връзката е важна: тя запазва всяка стъпка на възпроизвеждане и детайли за средата, предоставени от докладчиците.

който и да е tracкер със запазени филтри и групово редактиране работи. Екипите обикновено сортират от a Jira дъска или MantisBT изглед, филтриран по нови дефекти, редактиране на тежест, приоритет и лице, изпълняващо правото, на живо по време на срещата.

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

Да, косвено. Копилот на GitHub може да обобщи стек tracд., да се изготви тест за възпроизвеждане и да се обясни засегнатият код, който съкращава разследването, което собственикът извършва след триаж, вместо да замества самата среща.

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

Обобщете тази публикация с: