В процесі роботи розробники виправляють баги і реалізують новий функціонал. Різні баги і функції мають різну важливість для проекту, різний пріоритет (тобто порядок виконання).
Але у різних людей - різні погляди на те, що більш важливо, а що - менш. Те, що тестувальник або розробник вважатиме неважливим, може виявитися істотним для замовника. І навпаки.
Ну а ситуації, коли тестувальник стверджує, що помилку обов'язково потрібно виправити, а розробник з цим ніяк не погоджується, знайомі кожному з нас. На практиці через це часто виникають суперечки і нерозуміння.
Крім того. За відсутності будь-якого регулює документа, при визначенні важливості і пріоритету нам залишається покладатися тільки на власне уявлення про продукти. З огляду на масштаб і довгу історію продуктів, немає ніякої гарантії, що воно
а) буде правильним
б) співпаде у різних людей.
З цих причин створюється регламент визначення критичності і пріоритетності дефектів. Приклад такого регламенту наведено нижче.
1 Мета документа
«Регламент визначення критичності і пріоритетності дефектів» вводиться для упорядкування роботи над завданнями і помилками, уніфікації і спрощення таких завдань, як визначення черговості, в якій повинні виконуватися завдання, простановка критичності тестувальниками, запобігання суперечок про важливість і пріоритетність дефектів і завдань.
2 Правила визначення критичності
Severity. Критичність помилки. Визначається тестувальником при реєстрації помилки. Вказує на серйозність її наслідків для роботи системи, задоволеність користувачів, фінансові показники.
Помилки в backend отримують більш низький пріоритет, ніж помилки у frontend. Дефекти, для яких існує не приводить до помилки обхідний шлях виконання, отримують більш низький пріоритет, ніж не мають такого шляху.
Для визначення критичності використовується наступний перелік функціоналу системи:
Для дефектів поле «severity» є обов'язковим, для завдань - опціональним. За замовчуванням всім нових записів присвоюється значення «Minor».
Critical. Критичні дефекти, які роблять неможливим роботу тестованого функціоналу або порушують нормальну роботу критичних для бізнес-моделі функцій. Критичними визнаються стабільно відтворюються дефекти, які роблять неможливим використання базових функцій.
Major. Великі дефекти, без вирішення яких запланований функціонал не можна вважати реалізованим і працездатним. Великими визнаються дефекти, які ускладнюють використання базових функцій або роблять неможливим використання додаткових функцій.
Minor. Дрібні дефекти, що впливають на функціонал системи в незначній мірі або мають очевидні обхідні шляхи. Дрібними визнаються дефекти, які ускладнюють використання додаткових функцій.
Trivial. Трівільние дефекти, які не впливають на функціонал системи, але погіршують враження користувача про неї. Тривіальними визнаються дефекти в інтерфейсі, наприклад, помилки, граматичні, орфографічні, пунктуаційні помилки в текстах, малопомітні помилки у відображенні сторінок, що залежать від браузера та установки можуть бути і т.п.
3 Правила визначення пріоритету
Priority. Пріоритет помилки або завдання визначається менеджером проекту при передачі в розробку. Вказує на те, в якому порядку повинні робитися завдання, які повинні бути зроблені в першу чергу, а які пізніше.
Поле «priority» є обов'язковим, як для дефектів, так і для завдань. За замовчуванням всім нових записів присвоюється значення «Normal». Реєструючий запис тестувальник це значення не змінює. При необхідності збільшувати пріоритет менеджер проекту змінює значення перед передачею в розробку.
Top. Найвищий пріоритет. Присвоюється помилок, які повинні бути виправлені невідкладно. Цей пріоритет може призначатися тільки помилок, але не завданням. Призначений для екстрених ситуацій, вкрай негативно впливають на бізнес компанії і вимагають негайного виправлення. Виправлення і публікація таких помилок виконуються в першу чергу, до реалізації будь-яких нових завдань.
Зазвичай найвищий пріоритет присвоюється критичним функціональним дефектів, але можливі винятки. Наприклад, ситуація коли через тривіальної помилки в шляху до файлів на головній сторінці порталу ніколи не завантажуються логотип і кнопки меню, також повинна бути виправлена невідкладно.
High. Високий пріоритет. Присвоюється помилок і завданням, які повинні бути виправлені в першу чергу. У кожному проекті в будь-який момент часу може бути не більше 10 відкритих помилок або завдань високого пріоритету. У разі, якщо з'являється більш пріоритетне завдання, менеджер проекту може присвоїти їй пріоритет "High" тільки після того, як знизить пріоритет інший завдань.
Normal. Звичайний пріоритет. Присвоюється помилок і завданням, які слід виправити в другу чергу, в робочому порядку. Цей пріоритет обраний за замовчуванням. Більшість помилок і завдань повинні отримувати саме такий пріоритет.
Low. Низький пріоритет. Присвоюється помилок і завданням, виправлення яких не обов'язково і проводиться в останню чергу при наявності часу.