В рамках рубрики «QA поради новачкам» ми детально розберемо принцип «Що? Де? Коли?»
Всі ми вже знаємо, що баги оформлюються в спеціальних системах відстеження помилок, так званих баг-трекерах (від англ. Bug tracker або Bug tracking system).
На сьогоднішній день існує багато програм обліку помилок, однак всі вони переслідують одну мету – максимально точно і лаконічно описати суть дефекту. Саме тому всі баг-трекери мають схожий принцип заповнення.
При оформленні баг-репорта рекомендується вказувати наступну інформацію про баг:
- Summary (короткий опис бага);
- Description (опис бага);
- Priority/Severity (пріоритетність/серйозність бага);
- Steps to reproduce (кроки відтворення);
- Attachment (скріншот/відео).
Під час оформлення баг-репорта можна помітити, що деякі поля можуть бути відзначені обов'язковими. Дана опція залежить від типу баг-трекера та від вимог на окремому проєкті.
Розглянемо більш детально, як правильно заповнювати обов'язкове поле «Опис бага» або «Summary».
Більшість тестувальників, особливо початківці, відчувають величезні труднощі саме з формулюванням суті бага. Розуміючи в чому суть проблеми, дуже важливо зуміти грамотно донести її до програміста, який буде в подальшому читати ваш звіт про помилку.
Для того, щоб уникнути плутанини, а також зберегти і без того обмежений проєктом час, в IT-практиці було вирішено уніфікувати підхід до заповнення даного поля і тим самим полегшити життя програмістам і тестувальникам, які будуть працювати з баг-репортами.
При описі помилки дуже важливо вказати на суть проблеми, в якому місці системи це сталося, а також за яких обставин. Іншими словами: поле «Summary» заповнюється за принципом «Що відбувається? Де відбувається? Коли відбувається?», відповідаючи на питання тільки в такому порядку.
Неправильне формулювання може призвести до непорозуміння з боку розробника, який візьметься за виправлення даного бага. В результаті баг буде виправлений не так, як очікувалося, або не буде виправлений взагалі. Також розробник втратить багато часу на те, щоб розібратися в чому суть даної проблеми.
Давайте на прикладах розглянемо, які основні проблеми можуть виникати при описі бага:
- Використання сленгу. Безумовно, постійне використання англомовних слів в лексиконі, а також спілкування всередині команди, не може не позначитися на роботі як такій. Однак не варто використовувати сленгові слова при заповненні звітності, так як розробник або інша людина, яка буде читати ваш баг-репорт, може неправильно зрозуміти суть проблеми.
Наприклад:
| Неправильний варіант | Правильний варіант |
|
Неправильний варіант
Виникає ексепшн на формі додавання співробітника при натисканні кнопки «Зберегти» |
Правильний варіант
Відображається помилка на формі додавання співробітника після вибору кнопки «Зберегти» |
- Не завжди вдається зрозуміти пункт «Коли?». Зазвичай дія, яка призвела до результату, що відрізняється від очікуваного, описується не зовсім зрозуміло.
Наприклад:
| Неправильний варіант | Правильний варіант |
|
Неправильний варіант
Відбувається вихід з іспиту на останньому питанні анкети при натисканні на кнопку «Попередня відповідь» |
Правильний варіант
Відбувається вихід з іспиту на останньому питанні анкети після вибору кнопки «Попередня відповідь» |
- Недотримання принципу «Що? Де? Коли?». Найсерйозніша та в той же час найпоширеніша помилка при оформленні звіту. Якщо ви зрозумієте, що даний принцип розрахований на те, щоб полегшити процес оформлення теми баг-репорта, тоді на формування звітності буде йти набагато менше часу.
«Що?» – це НЕ іменник, а те, що сталося – певною мірою ДІЄСЛОВО-уточнення («Що відбувається?» або «Що НЕ відбувається?»). Особливо добре дана проблема проглядається на прикладі англійського варіанту звіту.
Наприклад:
| Неправильний варіант | |
|
Неправильний варіант
Misinformation validation error message in the registration form during incorrect filling registration form. |
«Misinformation validation error message» – ЩО?
«.. in the registration form» – ДЕ? «.. during incorrect filling registration form» – КОЛИ? |
| Правильний варіант | |
|
Правильний варіант
Misinformation validation error message IS SHOWN in the registration form after filling the registration form with invalid data. |
«Misinformation validation error message IS SHOWN» – ЩО ВІДБУВАЄТЬСЯ?
«.. in the registration form» – ДЕ? «.. after filling the registration form with invalid data» – КОЛИ? ПІСЛЯ ЧОГО? ВНАСЛІДОК ЯКОЇ ДІЇ? В ПЕРІОД ЯКОЇ ДІЇ? |
- Додавання в темі, описі та результатах посилання на сайт. Посилання на сайт вказується завжди в першому кроці, а в зазначених атрибутах необхідно додавати інформацію про розташування бага: назва форми, сторінки, блоку.
| Неправильний варіант | Правильний варіант |
|
Неправильний варіант
Не змінюється колір товару на сайті <посилання на сайт> після вибору червоного кольору. |
Правильний варіант
Не змінюється колір товару на сторінці товару «Printed Summer Dress» після вибору червоного кольору. |
Бувають випадки, коли немає можливості помістити всю необхідну для опису бага інформацію в поле «Summary». Причиною може стати обмеження за кількістю символів у полі. У таких випадках рекомендується сформулювати опис бага таким чином, щоб в мінімальній кількості тексту максимально зрозуміло була описана суть заведеного бага. А вже в поле «Description» помістити більш детальний варіант опису бага.
Даний принцип створений для того, щоб полегшити вашу роботу. Коли ви почнете ним керуватися, тоді у вас залишиться більше часу на улюблене заняття: пошук багів та неточностей в програмному забезпеченні.
Рекомендуємо особливо уважно ознайомитися з цією інформацією слухачам наших онлайн-курсів, так як вона буде однією з опорних точок при перевірці та оцінюванні домашніх завдань.
