Меню

Процес тріації дефектів та способи організації зустрічі з дефектом тріації

  • Головна
  • Інший
  • Процес тріації дефектів та способи організації зустрічі з дефектом тріації

defect triage process

Спробуйте Наш Інструмент Для Усунення Проблем

Повний посібник із процесу дефектної тріагії та ефективних способів проведення дефектоскопічної зустрічі:

У сьогоднішній статті ми дізнаємось про зустріч з дефектом триаж і про те, як простіше провести та провести триажну зустріч.

Перш ніж продовжувати цю статтю, я хотів би, щоб усі знали, що мається на увазі під дефектом, життєвим циклом дефекту та як встановити пріоритет і важкість для кожного дефекту . І необхідно розуміти ці основні поняття, пов'язані з дефектом або помилкою.

Ви також можете переглянути мою попередню статтю ' Життєвий цикл дефектів і Процес управління дефектами ' швидко зрозуміти ці поняття.

Зустріч дефектів

Що ви дізнаєтесь:

Огляд

Слово “Тріаж” в основному використовується в медичній галузі. Власне, це раніше вирішувало порядок лікування пацієнтів. Зазвичай, у великих лікарнях, де щодня існують тисячі підходів пацієнтів до консультацій або фактичного лікування. Але не всіх пацієнтів приймають або лікують негайно.

Тяжкість хвороби або травми є основними критеріями для консультації, і на основі цього всі пацієнти класифікуються відповідно. Якщо травма чи здоров'я будь-якого пацієнта є дуже критичними, тоді лікарі зазвичай ставляться до таких пацієнтів як пріоритет і приймаються, якщо це потрібно.

Нормальні захворювання або некритичні травми вважаються менш пріоритетними, і таких пацієнтів лікують пізніше.

Подібним чином термін Triage вводиться при тестуванні програмного забезпечення на наявність дефектів програми або проекту. Зазвичай процес дефекту Triage застосовується у великих проектах, і в багатьох випадках він не застосовується для малих проектів. Існує ймовірність виявити величезну кількість дефектів у великих проектах, ніж середні або малі.

Також у великих проектах частота виявлення дефектів є набагато вищою.

Погляньте на зображення нижче, яке показує результати зустрічі зі збору сортів дефектів і дає відповіді на конкретні питання, такі як:

Триаж дефектів

Зустріч дефектів

Головною метою сортувальної зустрічі є відстеження всіх дефектів та своєчасне забезпечення правильного вирішення.

На етапі виконання тесту тестувальники починають повідомляти про дефекти в інструменті управління дефектами, наприклад HP ALM , QC тощо. Тоді Зустріч дефектів проводиться, на якому розробники та тестувальники повинні бути присутніми, оскільки ці люди обговорюватимуть усі дефекти та прийматимуть необхідні подальші дії.

В основному присутність наведених нижче учасників обов’язково вимагається:

  • Менеджер проекту
  • Провідний тест
  • Ведучий розвитку або розробник
  • Тестер
  • Менеджер тестів
  • Бізнес-аналітик
  • Менеджер з охорони навколишнього середовища

Незважаючи на те, що я дав вичерпний список усіх учасників наради, не потрібно залучати всіх їх, таких як бізнес-аналітик, менеджер із охорони навколишнього середовища, менеджер випробувань тощо, до щоденної наради. Якщо потрібно, керівник тестування або керівник проекту запрошують їх, і вони можуть поділитися своїми цінними відгуками та думками щодо конкретного дефекту.

І вся команда відома як Команда тріажу . Зараз я збираюся пояснити точний процес семінарного зібрання та спосіб його організації.

Розглянемо один гіпотетичний приклад :У нас є один проект, пов’язаний із банківською програмою, розмір дуже великий, а частота виявлення та повідомлення про дефект висока. Отже, керівник випробування вирішує організувати зустріч з дефектами з необхідними учасниками.

Для організації зустрічі керівник тесту надсилає запрошення на зустріч по електронній пошті всім і встановлює певний час проведення зборів. Нижче наведене гіпотетичне зображення показує запрошення на зустріч, надіслане керівником тестування за допомогою прогнозу для всіх учасників.

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

(Примітка:Клацніть на будь-яке зображення, щоб збільшити його)

Приклад сортування міхурів c ++

Запрошення на збори

Щодня перед початком зібрання зібрання контрольний провідник надсилає список усіх “Відкритих” дефектів у форматі електронної таблиці всім учасникам, щоб вони могли пройти всі дефекти до наради та зрозуміти, в чому саме полягає дефект і яке виправлення для цього потрібно.

Перед початком кожного зібрання зборів переконайтеся, що кожен дефект:

  • Має достатньо інформації, щоб зрозуміти дефект для всіх учасників зустрічі.
  • Повідомляв про правильний проект та категорію.
  • Згадав пріоритет та тяжкість дефектів.
  • Вся детальна інформація, надана у дефекті, щоб правильно зрозуміти її всім учасникам.

Рекомендуємо прочитати => Повне керівництво по процесу управління дефектами

Шаблон тріації дефектів

Перед початком кожної зустрічі з дефектами, тест-провідник передає звіт про дефект усім учасникам у певному форматі, а також звіт, витягнутий із Інструменту управління дефектами, такий як HP ALM, HP QC тощо. Я показую один зразок формату в зображення нижче, яке дасть уявлення на високому рівні про те, які поля згадані у шаблоні звіту про дефекти.

Звіт про дефекти

Зазвичай поля, включені до звіту про дефекти:

  • Ідентифікатор дефекту
  • Опис
  • Пріоритет
  • Серйозність
  • Виявлена ​​дата
  • Виявлено
  • Статус

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

Зазвичай формат електронної таблиці використовується як шаблон для звітування про дефекти, отже, я надав гіпотетичні деталі дефектів у форматі електронної таблиці. Зверніть увагу, що вся інформація, наведена у вищезгаданому звіті про дефекти, є лише уявною і не пов’язана з жодним проектом чи фактичною заявкою.

Процес тріації дефектів

Ситуація, яку часто чують та досвідчують тестові групи, - обмежена доступність ресурсів. Структура дефектів - це процес, який намагається виконати певне перебалансування в результаті цього явища. Отже, коли існує багато дефектів і обмежена кількість розробників / тестувальників для їх виправлення / перевірки, аналіз дефектів допомагає вирішити якомога більше дефектів, збалансувавши технічний персонал на основі таких параметрів дефектів, як пріоритет і важкість.

Як правило, на сеанс сортування дефектів беруть участь менеджер із продуктів, керівник розробників, тест-керівник, а іноді і бізнес-аналітики. У деяких випадках деяких інших членів можуть також запросити висловити свої думки та перспективи щодо певних дефектів. Вони спільно називаються командою сортування.

Процес тріації дефектів

Більшість систем використовують пріоритет як основний критерій для оцінки дефекту, однак, хороший процес сортування враховує і ступінь важкості.

Давайте детальніше розглянемо процес сортування з двома прикладами, про які ми говорили в попередньому розділі. В обох прикладах, наведених вище, це фактично був би перший дефект, якому було б надано дуже високий пріоритет. Незважаючи на те, що це лише косметичний дефект, вплив нефіксації буде величезним.

Другий, з іншого боку, є безумовно дефектом функціональності, однак, його поява відбувається лише в певних умовах, які рідко практикуються у сценаріях клієнтів. Для його виправлення може знадобитися більше часу та людей, які могли б бути краще використані для інших дефектів. Отже, він вважатиме пріоритет нижчим, ніж у першого і, можливо, відкладеного кандидата на інше звільнення.

як стати рецензентом відеоігор

Таким чином, процес сортування включає сортувальну команду, яка сідає разом, переглядаючи всі дефекти, включаючи відхилені дефекти. Вони складають початкову оцінку дефектів на основі їх змісту, відповідного пріоритету та серйозності; з кожною людиною в колективній семінарі, яка представляє свою точку зору на те, як визначити пріоритети вад.

Потім менеджер продукту встановлює пріоритет на основі всіх входів і призначає дефект правильному випуску, тобто у поточному або будь-якому майбутньому випуску. Він також перенаправляє дефект правильному власнику / команді для подальших дій. Відхилені дефекти також проходять аналогічний аналіз. Виходячи з причини відмови, визначається футуристична дія щодо того, чи потрібно її відкладати чи скасувати.

Під час зібрання слід обговорити кожен дефект, включаючи дефекти, які віднесені до категорії нижчого пріоритету. Огляд групи сортування оцінює всі дефекти та вживає необхідних заходів щодо кожного дефекту. Якщо в дефекті бракує інформації, розробник повертає такі дефекти тестувальникам та запитує необхідну інформацію.

Зустрічне зібрання може проводитися в залі засідань, якщо всі учасники знаходяться в одному місці. Але в багатьох організаціях робота ведеться з іншого місця, і всі команди розподіляються по різних місцях, так що зустріч також проводиться за допомогою телеконференцій або ділового Skype.

Учасники телеконференції

( зображення джерело )

Покроковий процес засідання сортування дефектів:

  • Test Lead розпочинає зустріч із повідомленням про дефект, яке було надіслано раніше цього дня.
  • Обговорення починається з дій, які очікували від попередньої зібрання. Необхідні оновлення або дії щодо будь-якого дефекту обговорюються спочатку.
  • Якщо у звіті про дефекти є нові дефекти, ці дефекти перевіряються та оцінюються. Він також перевіряє, чи пріоритет і важкість присвоєні належним чином, якщо ні, то вони коригуються на засіданні.
  • Усі дефекти обговорюються на нараді, а команда розробників також обговорює складність виправлення дефекту. Ризик, пов’язаний з дефектом, також обговорюється командою сортування.
  • Комісійна команда приходить до висновку про те, який дефект повинен вимагати негайної уваги та виправлення, а який дефект потрібно почекати деякий час, і якщо потрібно, ці дефекти можна відкласти на наступні випуски.
  • Усі дефекти одночасно під час зустрічі присвоюються відповідній команді з контролю якості або контролю рівня. Відповідні коментарі також додаються до контролю якості / ALM.
  • Всі основні оновлення та пункти дій занотуються, і тест-лідер закликає до кінця наради.
  • Після завершення зібрання засідання тест-лідер розсилає протоколи засідання всім учасникам.

Ролі та обов'язки

Ролі та обов'язки на основі кожної категорії пояснюються нижче:

Провідний тест

  • Тест-лідер планує проведення зібрання дефектів і надсилає офіційне запрошення на зустріч необхідній команді.
  • Надсилає звіт про дефект перед кожним зібранням.
  • Розпочинає зустріч із завданнями, які очікують на розгляд із попередньої зібрання.
  • Обговоріть кожен дефект і вплив на графік, якщо якісь функції заблоковані через дефект.
  • Допомагає в призначенні пріоритету та серйозності кожного дефекту, якщо він був неправильно призначений раніше.
  • Оновіть QC / ALM відповідними коментарями.
  • Запишіть усі оновлення, дії, ризик, пов’язаний з дефектом тощо.
  • Надсилає протокол зустрічі всім учасникам.

Провідний розробник / розробник

  • Поділіться новинами про дії, які очікують на останньому зібранні зібрання.
  • Обговоріть усі дефекти з технічної точки зору.
  • Визначте, скільки часу йому знадобиться для виправлення, виходячи зі складності дефекту та функціональних можливостей.
  • Обговоріть складність дефекту та ризик, пов’язаний з ним, якщо такий є.
  • Провідний розробник присвоює дефект відповідному розробнику після перевірки всієї доступної детальної інформації.
  • Оновлює дефект із передбачуваною датою вирішення.
  • Допомагає у виявленні першопричини дефекту.

Менеджер проекту

  • Переконайтеся, що на зустрічі доступний весь представник з усіх областей.
  • За необхідності керівник проекту запрошує бізнес-аналітика на зустріч для висловлення думки щодо конкретного дефекту.
  • Якщо дефекти не рухаються або є якийсь основний блокувальник, це посилюється в процесі ескалації.
  • За потреби виступає посередником, якщо між командами трапляються суперечки чи конфлікти, і приймає необхідне рішення.
  • Візьміть підтвердження від команди розробників на наступну дату випуску для виправлених дефектів.
  • Поінформуйте про оновлений графік та дату випуску проекту для всіх команд.

Часом також є гарною ідеєю залучити інших учасників команди до сортування, щоб вони також могли зрозуміти та внести свій внесок у зустріч, а також, якщо потрібно, вони також могли б надати свої відгуки.

Висновок

Кожен дефект, що реєструється, повинен обговорюватися на зборі сортування.

Навіть якщо дефект відхилено, команда тестування повинна знати причину відхилення. Крім того, якщо будь-який з дефектів не відтворюється, тоді під час зібрання розробник може попросити у тестувальників деталі в режимі реального часу, і вони можуть спробувати відтворити дефект.

Тріаж дефекту важливий, оскільки всі знатимуть, коли дефект буде виправлений і буде доступний для повторного тестування. Якщо будь-який з дефектів є некритичним, і для його усунення потрібні величезні зусилля команди розробників, і рішення приймає керівник проекту.

Керівник проекту вирішить пріоритет такого дефекту, і, якщо потрібно, дефекти можуть бути перенесені на наступний випуск.

Сподіваємось, ви мали б чітке уявлення про дефектну тріагію, процес дефектної тріагії та способи ефективної організації зустрічей з дефектною тріагою!

Рекомендована література

^