Попълване полета съобщения за бъгове
Lifecycle бъг
Преди започване на описанието на елементарна грешка жизнен цикъл да се разгледа следната схема, показваща основните положения и възможните преходи от състоянието, за да статус в хода на неговото съществуване:
Сега ние се обръщаме към описание на схемата.
Да речем, че открили грешка, и да го регистрира в системата за проследяване на грешки. Според нашия алгоритъм, той ще получи статута "Нова". Тестерът е отговорен за приемане на нови доклади за грешки, или на координатора на проекта (в зависимост от разпределението на ролите в екипа ви) може да го превърне в един от следните статути:
"Отхвърлени", ако грешката е невалиден или повторно, или той просто не може да се възпроизведе
"Отложете", ако грешката не е необходимо да се коригира в тази итерация
"Отвори", ако трябва да се определи за грешка
Нека сега разгледаме по реда на всяка опция.
Отхвърлени. В този случай, можете да заложите на съдбата на вашите доклади за грешки, промените статута на "преоткрият" или да го затвори - статус "Затворено"
Забавено. Открих грешка в статута на "отложи" може да се преведе до статута на "Open", когато искате да се определи или до статута на "Затворено", ако вече не е необходимо.
Отворен. Тя е в това състояние, разработчикът получава сигнал за програмна грешка за корекция. Той може да отхвърли (виж по-нататъшни действия в параграф 1), или да се определи бъг. Статус на доклад за грешка "Fixed", се прехвърля на тестер за тестване. Ако проблемът продължава да играе, задаване на състоянието на "преоткрит" и описва грешката се върне за преразглеждане на възложителя. Ако поправката е била успешна, описва грешката е преведен на статута "Затворено".
Бихме искали да отбележим, че тази схема е значително опростена. За по-голяма яснота и може би използваемост на проекта, можете да добавите допълнителни работни групи и преходи, особено след като модерна система за следене на бъгове да ви позволи да направите това. Вярно е, имайте предвид, че ненужно сложна система от преходи и ненужно статус може значително да усложни живота.
Бележка 1: В някои системи за проследяване на грешки доклад за грешка веднага създаден получава статут на "Open" без по-нататъшно утвърждаване
Забележка 2. Много системи за проследяване на грешки може да отвори отново затворените грешки, но лично аз съм против подобна практика, и по тази причина не се опише такъв преход в горната представителството на жизнения цикъл
Бележка 3: Горният жизнен цикъл се основава на факта, че отборът има някой, който е отговорен за назначаването на доклади за грешки. Ако такава роля в проекта, а не бъговете са назначени от самите и след това, за да се избегне putannitsa разработчиците, че има смисъл да се въведе още един междинен статут на "В процес на разработка" (в момента), което показва, че докладът за бъг вече е назначен и е в процес корекция. Пример за изпълнение на такъв жизнен цикъл на базата на JIRA може да се види в следната фигура:
