Поля Bug Report

Існують обов’язкові поля для баг репорта і необов’язкові. У цій статті ми на прикладах розберемо поля, обов’язкові для Bug Report.

Обов’язкові для Bug Report поля:  

1. Summary. 
2. Priority. 
3. Severity. 
4. Description. 
5. Attachments. 

Що таке Summary?

Summary — лаконічний опис баг репорту, в якому відображається достатньо інформації для розуміння, в чому полягає проблема. Ми розглянемо два приклади: з гарним Summary і поганим. 

Гарний приклад: неможливо натиснути кнопку Save при довгому описі у полі вводу Name на сторінці Home. 

Поганий приклад: неможливо натиснути кнопку Save. 

У гарному прикладі зрозуміло, на якій сторніці знаходиться кнопка Save на відміну від поганого прикладу. Також там добре описана причина, з якої кнопку неможливо натиснути.  

Що таке Priority?

Priority — це пріоритет бага. Він показує нам, як сильно помилка впливає на проєкт і як швидко баг має бути виправлено. Саме тому пріоритет зазвичай вказують Team Lead, Project Manager або Замовнк. 

Існує 4 типи пріоритету:  

• Highest (P0): баг потрібно виправити якомога раніше.  
• High (P1): баг потрібно виправити, але не так терміново, як за найвищого пріоритету. 
• Normal (P2): баг необхідно виправити, якщо немає вищих пріоритетів.  
• Low (P3): баг було б непогано виправити, якщо немає вищих пріоритетів.  

Що таке Severity?

Severity — це показник того, наскільки баг заважає очікуваній роботі системи або компонента. І цей показник вказує тестувальник.  

Severity також поділяється на 4 типи:  

1. Blocker: баг заважає функціонувати всій системі в цілому. 
2. Critical: баг заважає функціонувати деяким частинам системи, але не всій системі.  
3. Major: баг заважає функціонувати певній ізольованій частині системи.  
4. Minor: баг не заважає функціонуванню частини системи або всієї системи.  

Приклад: припустимо, ми «розробляємо» паркан. Завтра у нас має бути демо для замовника, а сьогодні тестувальник побачив, що хтось написав на нашому новенькому паркані погане слово. Severity такого бага буде вкрай низьким (Minor), так як на основну мету паркану напис ніяк не впливає. Priority, в свою чергу, буде найвищим (Highest), оскільки рейтинг замовника порівняно з його сусідами (конкурентами) різко впаде.  

Що таке Description?

Description — це опис кроків для відтворення бага. Окрім кроків, може містити також передумови і постумови. Все це необхідно для того, щоб розробник якнайшвидше зрозумів в чому проблема і почав її вирішувати. 

Що таке Attachments?

Attachments — це файли, які доводять існування і допомагають ідентифікувати баг. Це можуть бути як запити до БД, так і скріншоти або відеозапис, як відтворюється баг.