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

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

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

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

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

 
Кілька варіантів з мого досвіду, що могло б піти не так у цьому короткому реченні з незаповненими полями:

• Програміст змінює існуючу логіку валідації, і це повідомлення з’являється не тільки при порожніх кількох полях, а також і коли незаповнене лише одне поле. Це робить множину "fields" у тексті граматично невірною і може заплутати користувача.
• Програміст додає нову перевірку із цим меседжем, але додає її на фронтендову валідацію, щоб юзер бачив, яке саме поле незаповнене. Але в такому разі текст знову граматично невірний із цією множиною. А ніщо так не змушує зловтішатися, як граматичні помилки :-)
• Програміст додає окрему загальну перевірку на незаповненість усіх полів (хоча це вже занадто, як на мене), але не має на цей випадок вказівок від UX- чи UI-дизайнера, і робить це таким способом, що Ви, як тестер, потім змушені будете відкривати новий тікет на його дизайнерські рішення.

Таким чином, вказування тексту в ER можна сказати "заряждене" на перевідкриття, чи створення "серійного багу", який буде "фікситись" багато спринтів, і дрейфувати з релізу в реліз. Подібні випадки змарнували дуже багато мого часу, а також набагато більше ще дорожчого часу моїх програмістів.  

Отже, цінуйте кожну ітерацію цього життя, і не пишіть зайвого.