Чи потрібен текст повідомлення у багрепорті?

Днями розповідав своїм студентам про те, що обов’язково треба вставляти текст повідомлень у Actual Result - наявний результат тесту у звіті про помилку. Ніби все зрозуміло і очевидно. Але потім у завданні кількох студентів побачив опис, що обурив моє почуття прекрасного:

Всі (принаймні, молоді тестери) чомусь думають, що поля Наявного (Actual Result, AR) та Очікуваного (Expected Result, ER) результату мають бути спорідненими, заповненими приблизно однаковими словами. Часто навіть бачу багрепорти, де ці поля відрізняються лише присутністю чи відсутністю частки "не". Табличка результатів тестування виходить гарна та однорідна. Я вважаю, що це "шкідлива однорідність". Бо вищенаведені поля мають принципово різну ціль, і мають бути заповнені відповідно до свого призначення, а не "для гарного візерунка".

Чому треба обов’язково додавати повідомлення в Наявний Результат?
Тому що це дозволить програмісту знайти ті місця в коді, де викликається показ саме цього повідомлення; і виправити логіку саме в тому випадку, що описаний у кроках відтворення, звісно якщо це необхідно.

Чому не варто, а часто навіть шкідливо, додавати текст повідомлення в Очікуваний Результат?
Тому, що це багрепорт - повідомлення про помилку - а значить логіка роботи системи потребує зміни. І ми дізна́ємося, які саме зміни були внесені, і яку шкоду покращення було зроблене тільки згодом. Тому зараз, коли ще навіть невідомо, чи це баг, і тим більше не відомо, як і коли його будуть фіксити, не можна диктувати програмістові з майбутнього, якими словами його логіка буде звертатися до користувачів. 
Але навіть тоді, коли логіка виправлення здається дуже ясною, як на картинці вище, багато всього залежить від контексту, який неможливо вмістити в одне речення звіту про баг. 

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

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

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

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