Як читають багрепорти?

Головною і чи не єдиною загальновживаною метрикою ефективності тестерів є кількість баг-репортів. Ну а якість цих звітів - головний результат роботи тестувальника.
Основні елементи баг-репорту приблизно однакові, незалежно від системи відстежування дефектів. Але у кожному конкретному випадку найбільш доречними для заповнення можуть бути різні поля. І, на мою думку, об’єм необхідної інформації у звіті залежить від порядку, в якому наша "цільова аудиторія" (ПО, кодер чи інші тестери) читають звіти.
Отже, як читають баг-репорт:

1. Summary

   Опис дефекту - те саме, що тема у листа. Він або викличе цікавість, і читач одразу його відкриє, щоб дізнатись деталі; або читачу стане і так все ясно.
   В Джірі (Jira) на дошці перегляду беклогу на 17’’ моніторі видно від 30 до 56 символів Summary. Цим екраном зазвичай користується ПО (Product Owner), пріоритизуючи задачі. Це не привід обмежуватись 50-ма символами. Просто треба поставити найважливішу саме для ПО інформацію на початок опису, як то: назву функціональної області чи функції, наслідки цього дефекту для функціональності.                                                                                                                  Наприклад: Player: Video played slower than Real time [приблизна межа видимості] when played from the middle

1. Screenshots

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

2. URLs

   Після швидкого перегляду візуальних доказів, наш приголомшений читач спішить-перекидається побачити усе на власні очі. Тому він швидко сканує текст звіту, шукаючи посилання, що якнайшвидше забере його туди. (Тут я згадую себе, коли мені скидають критичний баг-репорт з продакшону :-Е )
   Найчастішою відмазкою, щоб не вставляти URL-адреси є те, що, мовляв, перевіряємо на тестовому середовищі, чий вік вимірюється якщо не годинами, то днями. І за тиждень клікнувши на посилання, ви отримаєте "Server not found". Але навіть таке посилання - дуже корисне, бо насправді ім’я сервера можна легко поміняти на існуюче. Якщо Ви соромитесь вставляти неробочі URL'и, можете написати перед ним "e.g.", або вставити адресу без імені сервера.
   

3. Expected result vs. Actual result

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

4.  Preconditions & Steps, Environment, Severity

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