Принцип «Що? Де? Коли? » дуже відомий в колах ІТ сфери не тільки тестувальникам, а й іншим фахівцям. Цей принцип є загальновизнаним і, в більшості випадків, допомагає скласти вдалу тему та опис помилки.
Під час роботи з баг-репортами часто доводиться звертати увагу на необхідність чітко і коротко формулювати «Summary» дефекту. У самій темі повинна міститися достатня кількість інформації, щоб зрозуміти, про який баг йде мова. Такий опис дозволяє швидко зрозуміти і відтворити описаний баг.
Першоджерелом виникнення принципу «Що? Де? Коли? » є структура написання речення англійською мовою. Саме ця мова є формалізованою і структурованою, а можливість зміни порядку в реченні досить обмежена. Це дуже схоже на структуру опису баг-репорта. Всім відома будова речення і питання, на які мають відповідати речення в англійській мові, наведені нижче:
- Subject – Хто/що?
- Verb – Що робить?
- Object – Хто/що? доповнення
- Place – Де?
- Time – Коли?
Умовно згрупувавши Subject + Verb + Object, можна отримати частину «Що?», а всі інші питання вже продубльовані. У закінченому реченні, так само як і в темі дефекту, має бути підмет і присудок, і воно повинно висловлювати закінчену думку. Це дуже важливо для сприйняття і читабельності «Summary» дефекту, адже коректне написання дозволяє швидше обробити звіт без додаткових питань. Буває, що речення англійською мовою будують використовуючи український порядок слів, але через це складно зрозуміти сенс цього речення, не кажучи вже про успішне оформленні баг-репорту. Для сприйняття баг-репортів на різних мовах і було прийнято використовувати принцип «Що? Де? Коли?».
Основними причинами використання принципу «Що? Де? Коли? » є чітке викладення суті бага і пошук дублікатів. Принцип дозволяє чітко і коротко сформулювати опис «Summary», а також дозволяє зробити звіт унікальним. Тестувальнику необхідно приділити увагу на якість створюваних баг-репортів, чим краще він оформлений, тим менша ймовірність, що дефект буде відхилений через невірне трактування.
Якщо дотримуватися одного правила оформлення, то і пошук дублікатів НЕ викликатиме великих труднощів. Саме пошук дублікатів часто стає проблемою в роботі команди.
Хороший баг-репорт повинен володіти певними характеристиками, саме послідовні відповіді на запитання допоможуть легко і зрозуміло описати суть бага:
- Що? Що відбувається/не відбувається згідно специфікації або розумінні щодо нормальної роботи ПЗ. Слід описати поведінку програми, яка вважається не коректною, або яка не відповідає стандартам/вимогам/очікуванням.
- Де? В якій частині продукту (інтерфейсі) або системі програмного продукту відображається проблема. Це свого роду локація бага.
- Коли? За яких умов або після яких дій відтворюється дефект.
Відмінно оформлений баг-репорт повинен містити в полі «Summary» відповідь на запитання «Що відбувається?», «Де відбувається?» і «Коли відбувається, за яких умов?». Також, в українській мові важливо починати опис з дієслова. Для того, щоб навчитися лаконічно і зрозуміло описувати суть бага, необхідно трохи потренуватися застосовувати принцип «Що? Де? Коли? »:
- Що відбувається? – «Не відображається валідація поля»; «Не відцентровано плейсхолдер в полі»; «Відображається помилка 404».
- Де відбувається? – «На головній сторінці»; «У формі авторизації»; «У головному меню».
- Коли відбувається, за яких умов? – «Після введення валідних даних»; «Після натискання на кнопку»; «Після зміни розширення екрану».