Заповнення полів баг репорт
Життєвий цикл бага
Перед початком опису елементарного життєвого циклу бага пропонуємо розглянути наступну блок-схему, яка показує основні статуси і можливі переходи від статусу до статусу в процесі його існування:
Тепер переходимо до опису даної схеми.
Припустимо ви знайшли баг і зареєстрували його в баг трекінг системі. Згідно з нашою блок-схемі він отримає статус "Новий". Тестувальник, відповідальний за валідацію нових баг репортів, або координатор проекту (в залежності від розподілу ролей у вашій команді) може перевести його в один з наступних статусів:
"Відхилено", якщо даний баг невалідний або повторний, або ж його просто не змогли відтворити
"Відстрочено", якщо даний баг не потрібно виправляти в даній ітерації
"Відкрито", якщо виправлення бага необхідно
Розглянемо тепер по порядку кожен з варіантів.
Відхилено. В цьому випадку ви можете або посперечатися про долю вашого багрепорта, змінивши статус на "перевідкрив" або закрити його - статус "Закрито"
Відстрочений. Баг репорт в статусі "Відстрочено" можна перевести в статус "Відкритий", коли буде потрібно виправлення або в статус "Закрито", якщо вже не буде потрібно.
Відкрито. Саме в такому стані розробник отримує баг репорт для виправлення. Він може відхилити (подальші дії дивіться в пункті 1) або виправити баг. Баг репорт в статусі "Виправлений" перекладається на тестувальника для перевірки. У разі якщо проблема все ще відтворюється, виставляється статус "перевідкрив" і баг репорт направляється назад на доопрацювання до розробника. Якщо ж виправлення було успішним, то баг репорт перекладається в статус "Закрито".
Хочемо зазначити, що дана схема сильно спрощена. Для більшої наочності і, можливо, зручності роботи на проекті, ви можете додати додаткові статуси і переходи, тим більше, що сучасні баг трекінгові системи дозволяють це робити. Правда майте на увазі, що надмірно заплутані схеми переходів і зайві статуси можуть значно ускладнити життя.
Примітка 1. в деяких системах баг трекінгу створений баг репорт відразу отримує статус "Відкритий" без додаткової валідації
Примітка 2. багато баг трекінгові системи дозволяють перевідкривати закриті баги, проте особисто я проти такої практики, тому й не описував подібний перехід в вище представленому життєвому циклі
Примітка 3. Розглянутий вище життєвий цикл заснований на тому, що в команді є хтось, відповідальний за призначення баг репортів. У разі, якщо такий ролі на проекті немає, то баги призначаються розробниками самостійно, і тоді в уникненні путанніци, є сенс ввести ще один проміжний статус "У розробці" (In progress), що показує, що даний баг репорт вже призначений і знаходиться на стадії виправлення. Приклад реалізації подібного життєвого циклу на базі JIRA можна побачити на наступному малюнку:
