Будь-яка ІТ-компанія завжди прагне, щоб продукт ще до запуску мав найвищу якість. Далеко не останню роль у цьому відіграє робота QA фахівця. Його завдання — якомога раніше виявити помилки у ПЗ. І не тільки виявити, але й розуміти, як скласти баг-репорт, щоб розробники могли легко зрозуміти, у чому проблема, і швидко її виправити. Тобто не просто прочитали опис багу на кшталт «Функціонал працює неправильно», але й бачили пояснення, кроки відтворення та деталі перевірки.
У цій статті розбираємо складові баг репорту, інструменти баг-трекінгу, розповідаємо, як тестувальнику ПЗ скласти хороший баг-репорт, що позбавить команду зайвих зусиль, зекономить час розробникам та гроші клієнту, збереже нерви та хороші стосунки між учасниками ІТ-проєкту.
Що таке баг-репорт
Bug report — технічний документ, звіт про помилки (дефекти) у роботі об’єкту тестування (застосунку, фічі, сайту), що складає тестувальник. У ньому міститься опис ситуації чи послідовність дій, яка призвела до виникнення дефекту ПЗ, а також зазначені причини та очікуваний результат.
Такий звіт має бути структурованим, містити якомога більше важливих деталей, що описують баг. Він повинен допомогти IT-спеціалістам усунути проблему, а не викликати безлічі уточнювальних запитань. При цьому хороший баг репорт не повинен бути і занадто довгим із купою несуттєвих подробиць. Істина десь посередині: стислий опис, який дає повне розуміння проблеми і способів її виправлення.
Читач репорту має швидко та легко знайти відповіді на питання:
- Де саме і за яких умов виникла проблема.
- Що саме працює не так (і як воно має працювати відповідно до вимог до продукту).
- Що потрібно зробити, щоб відтворити помилку.
Основні складові баг репорту
Структура баг-репорту, який дійсно можна вважати грамотним, має включати наступні складові:
ID дефекту
Інструменти для відслідковування багів зазвичай автоматично присвоюють ID.
Заголовок (або тема, або Summary, короткий опис)
Це те, що програмісти бачать першим. Вже з заголовку має бути зрозумілою суть проблеми. Тому він має бути стислим, але ємним, і відповідати на питання:
- Що — що відбувається чи не відбувається відповідно до вимог до продукту.
- Де — в якій саме частині архітектури чи інтерфейсу користувача виникла проблема.
- Коли — у який момент роботи програми виникає помилка.
У заголовку QA Engineers лише коротко викладають суть дефекту. Усі деталі містяться у розділі опису багу.
Severity/Priority (Критичність/Пріоритет)
У цих розділах зазначається, наскільки серйозним є вплив дефекту на систему і як швидко їх потрібно усунути.
Severity (серйозність дефекту) розділяють за ступенем впливу на працездатність продукту на такі рівні:
- S1. Blocker (Блокуючий) — помилка повністю блокує та унеможливлює роботу застосунку, немає жодного способу обійти її. Виправлення багу необхідне для функціонування системи.
- S2. Critical (Критична помилка) блокує частину функціоналу, але є шлях для її обходу. Рішення проблеми необхідне для подальшої роботи з ключовим функціоналом.
- S3.Major (Значна) — некоректна робота частини функціональності (функція працює, але неправильно). Така помилка не критична, є можливість роботи з функціоналом із використанням інших вхідних точок.
- S4. Minor (Незначна) — незначні огріхи, помилки, які не відноситься до функціональності, не порушують бізнес-логіку. Зазвичай це помилки в UI.
- S5.Trivial (Тривіальний) — схожий на помилку «minor». Дефект не зачіпає функціональність, суттєво не впливає на загальну якість продукту, часто пов’язаний із помилкою сторонніх бібліотек або сервісів.
На деяких проєктах зазначають також додатково помилки:
- Tweak (Незручність) — проблема стосується суто інтерфейсу, необхідно «підігнати» його.
- Text (Текстова помилка) — одрук, орфографічна чи пунктуаційна помилка.
Атрибут Priority визначає рівень впливу на бізнес та на черговість усунення багу:
- P1. Високий пріоритет (High) – потрібно виправити помилку якомога швидше, адже вона є критичною, блокує тестування і може призвести до великих фінансових втрат.
- P2 – Середній (Medium) — помилка не є критичною, її можна пофіксити у другу чергу, після виправлення багів із високим пріоритетом.
- P3 – Низький пріоритет (Low) — помилка не потребує термінового усунення, нічого поганого не станеться, якщо виправити її в останню чергу.
Інколи трапляється так, що дефект має низьку серйозність та високий пріоритет і навпаки. Тож QA-інженери не повинні обмежуватися лише одним із атрибутів (Severity або Priority).
Description (опис)
Цей розділ містить більш деталізований опис багу (що призвело до появи проблеми, який результат очікували отримати тестувальники і який фактичний результат отримали.
Ці елементи баг-репорту зазвичай містять інформацію:
- Actual/Expected Result (Фактичні/Очікувані результати або поведінка)
Фактичний результат — як і Summary, відповідає на запитання «Що? Де? Коли»? Тобто що, в якому місці та за яких умов працює не так.
Очікувані результати — як саме має працювати система.
- Steps To Reproduce (Кроки для відтворення)
QA-інженер надає розробникам вказівки (дії), як відтворити цю помилку. Наприклад: перейти на сайт (посилання), натиснути на кнопку «Реєстрація».
Якщо кроків для відтворення буде більше 8, варто зазначити передумови (Preconditions), приміром: користувач авторизований, товар був доданий до кошика.
Attachments (Вкладення)
Це наступні, дуже важливі компоненти баг-репорту.
Це будь-яка корисна інформація, яка може допомогти розробникам швидко розібратися у суті проблеми. Сюди відносяться скріншоти, відеозапис з екрану, лог-файли тощо. Візуальна інформація зазвичай засвоюється краще, ніж текстова. Втім, додатки лише доповнюють текстовий опис, а не замінюють його.
Additions
Додаткова інформація, яка може стати в пригоді при роботі з багом. Приміром, ключові слова, що вказують на функціонал («UI component», «Registration Feature» тощо).
Status (Статус)
Це атрибут, який відображає життєвий цикл багу. Назви статусів можуть відрізнятися у різних системах баг трекінгу.
Так, у Mantis це:
- New – новий баг репорт
- Feedback – необхідна додаткова інформація
- Acknowledged – доведено до відома, відповідального ще не було призначено
- Accepted – дефект відтворено та підтверджено
- Assigned – баг-репорт призначений
- Resolved – питання вирішене. Потрібне підтвердження від тестувальника, що дефект усунутий
- Closed – виправлення дефекту підтверджено QA Engineer
Environment (Оточення дефекту)
Вказує, на якій платформі відтворюється дефект: назви та версії браузерів, ОС та їх версії (iOS, Android, Windows, MacOS).
Поради як скласти ефективний баг репорт
Ефективний баг-репорт — це не просто звіт, це покрокова інструкція, як саме відтворити баг. Він має бути ємним, але не занадто коротким, зрозумілим, не викликати зайвих питань, а також не містити забагато неінформативних деталей, від яких користі — нуль.
Навичка створення якісних баг-репортів прокачується із досвідом. Зверніть увагу на наступні поради:
1. Не поспішайте до баг-трекера, щойно побачили помилку
Хороший звіт має мінімізувати кількість кроків для відтворення багу і полегшувати роботу розробникам. Тож перш за все уточніть деталі та переконайтеся, що звіт не містить нічого зайвого чи, навпаки, має достатньо інформації, а вже потім заводьте його у баг-трекер.
Наприклад, ви зареєстрували нового користувача, але під час спроби залогінитися з’являється помилка «Невірне ім’я або пароль». Спробуйте відтворити цей баг, зареєструвавши ще одного користувача. Можна також повторити дії у різних браузерах та локалях, щоб переконатись, що дефект всюди проявляється однаково.
Далі зробіть додаткові перевірки. Наприклад, чи є дані про користувачів у базі після реєстрації? І тут може виявитися, скажімо, що в базі немає жодного запису про користувачів. Для заспокоєння душі спробуйте зареєструвати ще пару юзерів. Знову немає запису у БД? Отже, проблема саме з базою даних.
Тепер, після додаткових перевірок, дефект «неможливо увійти у систему з використанням облікових даних зареєстрованого користувача» трансформується у «при реєстрації нового користувача запис про нього не створюється у базі даних».
Як бачимо, нове формулювання кардинально змінює сам підхід для подальшої роботи з багом: ми не просто зафіксували наслідки, ми конкретно посилаємося на причину. Вдячність від розробника та плюс у карму вам гарантовані.
2. Правильний заголовок — половина успіху
Завжди дотримуйтесь принципу «Що? Де? Коли»? Він продиктований не тільки уніфікацією опису дефектів, але й особливостями конструкції речень в англійській мові: спочатку підмет і присудок, потім обставина місця, потім обставина часу.
Опишіть проблему детально (обов’язково у неособовій формі). Але не перетворюйте заголовок на лонгрід, адже тут є обмеження за кількістю символів.
Якщо проблема вимагає негайної уваги, додайте позначку URGENT чи CRITICAL.
У частині заголовку «Де?» зазначте конкретний розділ сайту чи сторінки, а не просто «на сайті». При описі «Коли» краще написати «після» (дії), а не «при» (якщо в момент дії — тоді так і написати: «в момент»).
Неправильний заголовок: Я клікаю на кнопку «Вхід» і нічого не відбувається.
Правильний заголовок: Не відкривається сторінка входу на сайт після натискання на кнопку «Вхід».
Неправильний заголовок: Нічого не відбувається після введення неправильних символів.
Правильний заголовок: Поле «Електронна пошта» не підкреслюється червоним кольором у вікні форми «Реєстрація» після введення неправильних символів.
Неправильний заголовок: Ламається верстка при розтягуванні полів.
Правильний заголовок: Відбувається зміщення тексту на головній сторінці сайту після збільшення масштабу до 150%.
Неправильний заголовок: Проблема з реєстрацією користувача.
Правильний заголовок: При реєстрації нового користувача запис у базі даних не формується.
3. Зробіть стислий опис дефекту
Деталізація має бути достатньою, але й без перебору.
Environment
Неправильно: Google Chrome
Правильно: Google Chrome, version: 100.0.4896.88, browser language and locale: English, project: «N».
Actual behaviour
Неправильно: Реєстрація не здійснюється.
Правильно: У момент реєстрації нового користувача отримуємо повідомлення про успішне створення нового облікового запису, але в таблиці «Користувачі» в базі запис не створюється.
Expected behaviour
Неправильно: Реєстрація здійснюється.
Правильно: У момент реєстрації нового користувача отримуємо повідомлення про успішне створення облікового запису, при цьому в таблиці «Користувачі» в базі створюється запис із даними, які відповідають введеним під час реєстрації.
Steps to reproduce
Неправильно: Зареєструвати нового користувача та залогінитись.
Правильно:
- Заходимо на сайт (посилання)
- Реєструємо нового користувача, заповнивши усі обов’язкові поля (email: 123@gmail.com, password: 123, nickname: 123) — див. скріншот 1.
- Перевіряємо, чи є повідомлення про успішну реєстрацію
- Переходимо у базу даних
- Переконуємося, що відсутні нові записи у таблиці «Користувачі» (скріншот 2).
4. Уникайте розмитих формулювань
Вирази на кшталт «правильно/неправильно», «коректно/некоректно» «можливо/неможливо», «can/can not», «layout broken», «nothing happens» тощо не дають розробникам жодної інформації, що саме відбувається. Тому потрібно дуже детально розписати поведінку системи.
5. Додайте максимально зрозумілі скріншоти/відео
Зображення не повинні містити зайві деталі. На помилку можна вказати стрілкою чи будь-яким зручним графічним елементом.
6. Оформіть звіт
- Назви основних інформаційних блоків пишіть із великої літери.
- Якщо під час відтворення дефекту потрібна взаємодія із посиланнями, кнопками, пунктами меню тощо, це обов’язково необхідно вказати, і поруч із назвою елемента, вказаною у лапках, зазначити його тип (поле, кнопка тощо).
- Пронумеруйте кроки відтворення.
- Відділяйте блоки баг-репорту відступами для полегшення візуального сприйняття.
- Дотримуйтесь однієї мови звіту. Не варто в україномовний звіт додавати англійські слова або написані транслітом — це може зменшити зручність та швидкість читання баг-репорту. Не слід також користуватися сленговими фразами. Але не перекладайте назви елементів сайту на мову звіту: приміром, якщо є кнопка «Login», то її треба вказувати саме так, а не перекладати як «Вхід».
- Перевіряйте граматику та пунктуацію. Помилки не тільки ріжуть око, але часто призводять до непорозумінь у дусі «стратити не можна помилувати». Наприклад, програмісту може бути незрозуміло, що мав на увазі QA, коли записав: «натиснути кнопку всі літери замінити на тире». Натискати кнопку «всі літери»? Чи кнопку, яка заміняє всі літери на тире? Неграмотна мова може справити враження, наче тестувальник ставиться до своєї роботи не дуже відповідально.
Інструменти баг-трекінгу
На невеликих проєктах для баг-репортингу інколи використовують Excel, Google Sheets та Google Docs. Але зі зростанням розмірів та складності ІТ-проєктів їх використання стає незручним, або навіть безглуздим. Тож рішенням стає використання БТС (баг-трекінгових систем).
Баг-трекери — це спеціальні програми, що дозволяють тестувальникам реєструвати помилки, призначати відповідальних, відслідковувати виправлення багів: як обробляються, скільки часу на це пішло тощо та генерувати звіти.
Сьогодні на ринку є десятки зручних інструментів відстеження багів. Деякі з них є профільними (як-от Mantis, Redmine, Bugzilla), інші (наприклад, Trello, Jira) мають більш широке використання.
Найпопулярніші інструменти:
- Безкоштовний та доволі простий інструмент баг-трекінгу
- Є в мобільній версії та у вигляді web-застосунку
- Сумісний з MySQL, PostgreSQL, Microsoft SQL
- Інтегрується з Git
- Підтримує time tracking
- Є налаштування полів
- Історія змін у звітах
- Баг-репорт можна призначати для будь-якого користувача, що працює на проєкті
- Необмежена кількість проєктів, користувачів та баг-репортів
Доступні атрибути баг-репорту:
- назва та опис
- категорія
- Priority
- Severity
- кроки відтворення
- додаткова інформація
- вкладення
- Опенсорсний web-додаток для керування проєктами, який, зокрема, використовується для трекінгу помилок
- Дозволяє підтримувати декілька проєктів
- Має тайм-трекер та календар
- Забезпечує контроль доступу на основі ролей
- Підтримує декілька баз даних
- Інтегрується з Git
Доступні атрибути баг-репорту:
- Вид завдання
- Тема звіту
- Опис
- Статус
- Пріоритет
- Відповідальні
- Дата створення/завершення
- Час виконання
- Додатки
- Одночасно є баг-трекером та інструментом управління проєктами
- Має вигляд інтерактивної дошки, на якій можна відстежувати переміщення тасків та контролювати їх виконання
- Доволі широкий функціонал, можна доповнювати за допомогою плагінів
- Інтегрується з Git
- Платний
Доступні атрибути баг-репорту:
- назва
- тип завдання
- тема
- опис
- Priority
- вкладення
- пов’язані задачі
- Має широкий спектр використання, баг-трекінг — одна з її додаткових можливостей
- Інтегрується з Git
- Надає спільний доступ учасникам
- Регулювання прав доступу
- Можна відстежувати зміни, робити коментарі до проєктів
- Є трекінг завдань, аналітика продуктивності, моніторинг помилок та контроль часу
Доступні атрибути баг-репорту:
- Немає налаштування полів
Ці та інші інструменти мають як переваги, так і недоліки. У цілому, принцип створення баг-репортів у них схожий. Тестувальникам ПЗ варто мати хоча б базові знання у різних БТС.
Кілька слів наостанок
У різних компаніях можуть використовуватися свої підходи до складання баг-репортів у залежності від інструментів баг трекінгу, особливостей проєкту, технології тощо. Але хороший звіт завжди має враховувати ключові моменти:
- Він не викликає купи додаткових питань. Ба більше: він взагалі не викликає запитань навіть у менш досвідчених членів команди проєкту.
- Ідеально, якщо вже Summary розкриває суть проблеми: тобто із заголовку можна зрозуміти, що працює не так, де саме та як це виправити.
- Факти, і нічого більше, крім фактів. Мінімум води, максимум корисної та важливої інформації без перевантаження деталями.
Добре складений звіт — це мало не основа репутації IT-професії тестувальника. ІТ-компанія Eastern Peak бажає вам завжди складати баг-репорти, за які подякують колеги. І якщо ви зараз перебуваєте у пошуку роботи, маємо кілька пропозицій. Відправляйте нам резюме — із задоволенням розглянемо!
Читайте також:
