З упевненістю можна сказати, що будь-яка компанія з розробки прагне до того, щоб продукт, який вона створює, був найвищої якості.

Для того, щоб цього досягти, QA фахівці повинні виявити всі недоліки ще на ранніх стадіях життєвого циклу розробки продукту. Коли ж помилку виявлено, її потрібно описати так, щоб розробники могли легко і швидко зрозуміти, в чому полягає проблема, відтворити її та оперативно виправити. Саме для цього пишуться баг-репорти.

У цій статті наш QA Engineer Denys Lichman розбере основні складові баг репорту, описує  на які моменти варто звертати увагу при їх складанні та які існують інструменти для відстеження багів.

Що являє собою баг-репорт?

Баг-репорт – це звіт, який інформує розробників про помилку у роботі продукту, додатку, фічі. Цей документ має бути добре структурованим і мати достатньо деталей, щоб читач міг легко знайти відповіді на головні питання:

• 1.Де і при яких умовах виникла проблема?
• 2.Що саме працює не так, як має працювати?
• 3.Що потрібно зробити для відтворення помилки?

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

Як правило, баг-репорт потрапляє до категорії погано складених з однієї з двох причин:

– Занадто багато непотрібних деталей
– Занадто мало корисної інформації.

Навичка не включати у звіт нічого зайвого приходить із досвідом. А щоб не пропустити нічого важливого, достатньо пам’ятати про основні елементи баг-репорту.

Основні компоненти баг-репорту.

Розглянемо кожний розділ звіту про знайдену помилку і, на що варто звертати увагу при написанні баг-репорту.

Заголовок – це частина репорту, яку розробники бачать першою. Він повинен бути коротким та ємним. Потрібно, щоб уже за заголовком можна було зрозуміти суть проблеми. 

Зазвичай заголовок складається за принципом «Що? Де? Коли?».

 У чому цей принцип? Складіть речення, в якому факти дефекту викладені в наступній послідовності:

Що?: Що відбувається або не відбувається згідно зі специфікацією або вашим уявленням про нормальну роботу програмного продукту. При цьому вказуйте на наявність або відсутність об’єкта проблеми, а не його зміст (його вказують в описі). Якщо зміст проблеми варіюється, всі відомі варіанти вказуються в описі.

Де?: В якій саме області інтерфейсу користувача або архітектури програмного продукту перебуває проблема.

Коли?: В який момент роботи програмного продукту, після настання якої події або за яких умов проблема виявляється.

Опис бага – розділ з описом помилки повинен містити докладну інформацію про те, що призвело до виникнення проблеми, який результат очікували отримати тестувальники, та що сталося насправді. Він може мати таку структуру:

• 1.Кроки для відтворення бага.
  

Дуже важливо надати розробникам чіткі вказівки, як вони можуть відтворити помилку. 

В ідеалі це має бути пронумерований список зрозумілих дій:

• 1.Перейти до сторінки входу в систему.
• 2.Ввести правильне ім’я  користувача
• 3.Ввести неправильний пароль.

Усі дієслова пишуться в інфінітиві. Не треба писати «я натиснув/натиснула кнопку». Правильніше написати «натиснути на кнопку»/«відкрити «Домашню сторінку».

Фактичні та очікувані результати.

Фактичний результат – результат, до якого приходить користувач/розробник після того, як виконає всі кроки до відтворення.”

Очікуваний результат – результат, який має бути після виконання всіх кроків до відтворення згідно специфікації.

При написанні кожного з цих підрозділів потрібно не забувати і додати всю корисну інформацію, відповідно і виключити всі непотрібні деталі однаково важливо.

Додатки – скріншоти, відеозапис екрану ТА СИСТЕМНІ ЛОГИ, прикріплені до репорту, допоможуть розробникам швидше розібратися в суті проблеми і знайти оптимальне рішення. Однак це не означає, що можна додати до звіту відео і не турбувати себе описом помилки. Додатки  лише доповнюють, але не замінюють текстову інформацію.

Критичність і пріоритет (Severity, Priority) – ці розділи вказують, наскільки серйозні наслідки може викликати виявлена помилка і як терміново її необхідно усунути. Зазвичай багам присвоюється один із 6 рівнів критичності:

S1 – Блокуючий (Blocker) – дефект повністю блокує виконання функцій, нема ніякого способу його обойти.

S2 – Критичний (Критичний) – дефект блокує частину функціональності, але є альтернативний шлях для його обходу.

S3 – Значний (Major) – дефект, що вказує на некоректну роботу частини функціональності. Найчастіше пов’язано не з тим, що функція не працює, а з тим, що вона працює неправильно. У будь-якому випадку, існує більше однієї точки входу для ініціації потрібної функціональності.

S4 – Незначний (Minor) – дефект, що не відноситься  до функціональності системи. Зазвичай серйозність Minor проставляється для тих дефектів, які відносяться до зручності використання або інтерфейсу.

S5 – Тривіальний (Trivial) – дефект, що не зачіпає функціональність системи, а також мінімально впливає на загальну якість системи. Часто не відрізняється від рівня «minor».
Зазвичай це граматичні дефекти у супровідній документації до системи. Іноді дефект відноситься до «невидимих» проблем з точки зору користувача або інтерфейсу користувача і розглядає сторонні бібліотеки або сервіси, що не відносяться до самої розробленої системи.

Залежно від критичності проблеми визначається їй середній, високий або критичний пріоритет.

P1 – Високий (High) – потрібно виправити насамперед;

P2 – Середній (Medium) – потрібно виправити у другу чергу, коли немає дефектів із високим пріоритетом;

P3 – Низький (Low) – виправляється в останню чергу, коли всі дефекти з вищим пріоритетом вже виправлені.”

Обмежитися лише одним атрибутом не можна, оскільки часто трапляються дефекти, які мають одночасно низьку серйозність, але високий пріоритет, і навпаки.

“Підсумовуючи, слід пам’ятати, що проставлення Severity та Priority є важливою частиною процесу розробки та тестування програмних продуктів, оскільки ці атрибути однозначно класифікують усі дефекти по типу: ступінь впливу на систему і послідовність їх виправлення. Як наслідок, це дозволяє проводити швидкий пошук або сортувати, формувати наочні звіти і не витрачати час на зайві комунікації.”

Denys Lichman, QA Engineer Clovertech  

• Програмно-апаратне оточення (Environment) – на різних пристроях програми можуть поводитися по-різному. Тому якісний звіт про помилку повинен також містити інформацію про операційну систему, версію програми, браузерів і девайсів, використаних у процесі тестування.
• Призначення хто повинен виправити дефект (залежно від компанії репорт може прямувати на продакт менеджера продукт оунера або відразу на розробника, все залежить від внутрішньої структури і схеми взаємодії в команді)
• Підхід до складання звітів про помилки може трохи відрізнятися у компаніях. Все залежить від використовуваних технологій, типу проекту, прийнятих робочих процесів та продуктів, що тестуються. Однак розуміння основних компонентів баг-репорту та вимог до них допоможе вам складати хороші звіти незалежно від цих факторів.

Інструменти для відстеження помилок або баг-трекерів.

Баг-трекери – це інструменти, які дозволяють командам ефективніше фіксувати та відстежувати дефекти у додатках. У їх функціонал зазвичай входить:

• 1.Створювати баг-репорти.
• 2.Надавати помилкам пріоритет.
• 3.Міняти статус бага на різних етапах його життєвого циклу (наприклад, новий, відкритий, відхилений, виправлений тощо).
• 4.Призначати відповідальних виконання тієї чи іншої завдання.
• 5.Шукати, фільтрувати та сортувати помилки за різними параметрами: за назвою, критичністю, ідентифікаційним номером тощо.

Нижче робимо короткий огляд десяти найпопулярніших інструментів для відстеження помилок.

Jira  – баг-трекер та інструмент для управління Agile-проектами.

Інструмент легко підлаштувати під потреби конкретної команди та інтегрувати практично з будь-яким іншим інструментом розробки. У нашій компанії це один з основних використовуваних інструментів, як для трекінгу багів так і для всіх завдань.

Bugzilla  – популярний баг-трекер з відкритим вихідним кодом, простий у використанні, має всі необхідні функції та надає розширені можливості пошуку.

Trello – популярна система управління проектами, дуже гнучка та дозволяє налагодити ефективний робочий процес щодо відстеження помилок для команд будь-якого розміру.

Asana – інструмент управління проектами та відстеження помилок, у ньому є готовий шаблон для таких цілей, який можна легко змінити або доповнити, залежно від потреб компанії.

Redmine – баг-трекер з відкритим вихідним кодом. Він популярний серед невеликих команд, яким потрібне просте та гнучке рішення для управління різними проектами.

FogBugz  – веб-система керування проектами з функціями для відстеження помилок, керування завданнями та врахування робочого часу.

YouTrack – це веб-система для відстеження помилок та управління проектами, яка дозволяє фіксувати дефекти, планувати спринти, керувати завданнями та складати звіти про виконану роботу.

Backlog  – проста, але потужна платформа. Розширені можливості пошуку, повна історія оновлень та змін статусів, вікі, ієрархія завдань, діаграми Ганта та безліч інших корисних функцій дозволяють легко налагодити ефективний процес відстеження помилок.

Zoho Bug Tracking – онлайн-платформа, за допомогою якої можна створювати проекти, відстежувати помилки, генерувати звіти або обмінюватися документами.

BugHerd  – інструмент, який дозволяє збирати звіти про роботу сайту безпосередньо на його сторінках.

Використання відповідних інструментів може полегшити роботу команд з відстеження багів. Однак, щоб налагодити справді ефективний процес, одних інструментів мало. Потрібно ще, щоб усі члени команди дотримувалися основних правил написання якісних баг-репортів.

Що варто пам’ятати під час складання баг-репортів?

Ось кілька принципів, яких варто дотримуватись:

1.Один звіт – одна помилка. Навіть якщо тестувальники виявили проблеми в тому самому місці, створюйте окремі репорти для кожного бага. Якщо описувати дещо в одному звіті, це тільки заплутає розробника і він може втратити якийсь дефект. Крім того, статус такого репорту неможливо буде змінити, доки розробники не виправлять усі перелічені в ньому помилки. І розібратися, як просувається робота, буде складніше.
2.Уникати дублікатів.Перш ніж створювати новий баг-репорт, необхідно перевірити, якщо проблема вже не була описана раніше.
3.Відтворити помилку кілька разів, переконатися, що не пропустили жодного важливого кроку в інструкціях для розробників. Якщо не вдається повторити проблему щоразу, варто згадати про це і вказати коефіцієнт відтворюваності (наприклад: 7/10 разів баг відтворюється).
4.Дотримуватись лише фактів і не будувати припущень про те, що могло стати причиною дефекту. Це може задати розробникам неправильний напрямок думки і відстрочити усунення помилки.
5.Завжди бути ввічливим, не звинувачувати та не критикувати колег. Робота тестувальника полягає у забезпеченні високої якості продукту, а не в оцінці чиєїсь роботи.
6.Завжди перечитуйте свій звіт, перш ніж надіслати його. Він має бути коротким, зрозумілим та містити всю необхідну інформацію.

Створення якісних баг-репортів – цінна навичка для будь-якого тестувальника. Застосовуйте свої знання практично.

How to Compose a Proper Bug Report

Every development company certainly desires to create a high-quality product. To achieve that, QA specialists must find all imperfections at the very beginning of the software development lifecycle. And when an issue is found, it should be described properly, so that developers would quickly understand what is the problem, reproduce it, and fix it swiftly. That is what bug reports are for.

In this article, our QA Engineer Denys Lichman discusses the main components of bug reports, what points are worth paying attention to while composing those, and what tools are to help track bugs.

What is a bug report?

A bug report is a summary that informs developers about an issue in the workflow of a product, application, or feature. The document must be properly structured and provide enough details so that the reader can easily find answers to the main questions:

• 1.Where and in what circumstances has the issue appeared?
  2.What exactly isn’t working properly, and how it must work instead?
  3.What steps are required to reproduce the issue?

It’s also important to remember that usually, developers do not have much time to read long reports that include numerous unessential details of a bug description. Hence, the reports must be as brief as possible, and well-structured.

Commonly, a bug report is considered a bad one due to one of the following reasons:

• -Too many unessential details
  -Too little useful information

The skill of not including excess information comes with experience. And not to lose anything important, it’s quite enough to remember the main elements of a bug report.

The main elements of a bug report

Let’s look at each element of a report on a found issue and consider what is worth paying attention to while writing the bug report.

A heading is an element of a bug report that developers see first. It must be brief and capacious. It’s crucial that the essence of the issue can be comprehended by the heading. Usually, the heading is composed following the “What? Where? When?” principle. What is this principle?

Make a sentence where the facts of the described defect are explained in the following order:

What?: What happens or doesn’t happen according to the specification or your understanding of a software’s proper workflow. Meanwhile, do indicate whether the issue’s object is present, not its essence (the essence must be stated in the description). If the issue’s essence varies, all known variations must be indicated in the description.

Where?: What is the precise area of the user interface or software’s architecture where the issue is reproduced.

When?: At what point in the software product’s operation, after what event, or under what conditions does the problem appear.

A bug description is an element where the issue is described. The description must provide detailed information about what caused the problem, what result was expected, and what happened in fact. It may be structured in the following way:
1.Steps to reproduce the bug.

It’s crucial to provide developers with precise instructions on how they can reproduce the issue.
Ideally, it must include a numbered list of comprehensive actions:

• 1.Go to the login page
  2.Enter a correct user name
  3.Enter an incorrect password

All verbs must be used in the infinitive form. Don’t write “I pressed the button”; it’s better to phrase it another way, “press the button” or “open home page”.

To make the list shorter, you can indicate some of the conditions in advance. For instance, if something doesn’t work properly on the profile editing page, it’s not necessary to describe all steps for log inning into the system in detail. Instead, you can add the following information: prerequisite – a registered user is logged in.

• Actual and expected results.

• The actual result is the one that a user or a developer gets after performing all steps to reproduce.

  The expected result is the one that is, according to specifications, expected to happen after performing all steps to reproduce.

  While writing every one of the elements, do not forget to add all useful information to the description, and remove the excess details too.

  Attachments. Screenshots, screen recordings, and SYSTEM LOGS can help developers understand the essence of the issue quicker and find a solution. However, it doesn’t mean that a single video is enough and there’s no need for a description when you attach one. The attachments are to just supplement, not to replace the text information.

  Severity and priority are the sections that indicate how severe the consequences of the found issue are and how urgently it has to be solved. Usually, bugs are assigned one of the six levels of severity:

  S1 (Blocker) – a defect completely blocks feature performance, there’s no way to avoid it.

  S2 (Critical) – a defect blocks a part of functionality; however, there is a way to avoid it.

  S3 (Major) – a defect points out an inappropriate work of a part of the functionality. Most frequently, it is not related to the fact that the function does not work, but to the fact that it works incorrectly. In any case, there is more than one entry point to initiate the desired functionality.

  S4 (Minor) – a defect that doesn’t relate to the system’s functionality. Usually, minor severity is used for the defects that relate to the usability or the interface.

  S5 (Trivial) – a defect that doesn’t affect functionality, however, influences the overall quality of the system. It often doesn’t differ from the minor severity level. Usually, it relates to grammatical defects in the accompanying documentation for the system. Sometimes a defect refers to “invisible” problems from a user or user interface perspective and considers third-party libraries or services that are not related to the developed system itself.

  Depending on the issue’s severity, it is given a medium, high or critical priority.

  P1 (High) – must be fixed first;

  P2 (Medium) – can be fixed after all high-priority issues are solved;

  P3 (Low) – can be fixed in the last place, when all other issues are fixed.

  It is not possible to limit everything to just one attribute, because there are often defects that have both low severity and high priority and vice versa.

  “Summing up, it must be remembered that assigning Severity and Priority is an important part of developing and testing software products since these attributes certainly categorize all defects by the degree of impact on the system and the sequence of their solving. As a result, it allows you to quickly search or sort, create visual reports and save some time that would be wasted on unnecessary communications”.

  Denys Lichman, QA Engineer Clovertech  

• 

Software and hardware environment. Applications may run differently on different devices. Therefore, a good bug report should also contain information about the operating system, program version, browsers, and devices used in the testing process.

Assignment. Who must fix the issue (depending on a company, the report can be assigned to a product manager or product owner, or directly to a developer, everything depends on the inner structure and the workflow of a team).

The approach to composing bug reports may slightly vary at the companies. Everything depends on the technologies that are used, project type, accepted workflow, and products that are being tested. However, understanding the main components of a bug report and requirements to those can help you compose good reports regardless of these factors.

Tools for tracking issues (bug trackers)

Bug trackers are tools that allow teams to effectively capture and track defects in the applications. Their functionality commonly includes:

• 1.Bug reports creation.
  2.Assigning priority to the issues.
  3.Changing bug status at different stages of its lifecycle (for instance, new, open, canceled, fixed, etc).
  4.Assigning a responsible person for solving a task.
  5.Searching, filtering, and sorting issues by various criteria: by name, by severity, by ID, etc.

Let’s overview ten of the most popular tools for bug tracking.

Jira is a bug tracker and a tool for managing Agile projects. This tool can be easily customized to the needs of a specific team and integrated with almost any other development tool. At our company, this tool is one of the main tools that we use, both for tracking bugs and for all tasks.

Bugzilla is a popular bug tracker with an open source code, it is easy to use, and provides all necessary features as well as extended search possibility.

Trello is a popular system for project managing, it’s very flexible and enables efficient bug tracking workflow for teams of any size.

Asana is a tool for managing projects and tracking issues, it provides a template for such purposes, which can be easily changed or supplemented, depending on the needs of the company.

Redmine is a bug tracker that has open-source code. It is popular among small teams that require a simple and flexible solution for managing different projects.

FogBugz is a web-based project management system with features for bug tracking, task management, and time tracking.

YouTrack is a web-based system for bug tracking and project management that enables capturing defects, planning sprints, managing tasks, and composing reports about the done work.

Backlog is a simple yet robust platform. Advanced search capabilities, a complete history of updates and status changes, a wiki, task hierarchy, Gantt charts, and many other useful features make it easy to set up an effective bug tracking process.

Zoho Bug Tracking is an online platform that helps create projects, track bugs, generate reports, and exchange documents.

BugHerd is a tool that allows collecting reports on the site’s work directly on its pages.

Using appropriate tools can ease bug tracking work for teams. However, tools alone are not enough to establish an actually efficient process. It is also necessary that all team members follow the basic rules of writing good bug reports.

• Things to keep in mind when writing a bug report

  Here are several principles that should be followed:

• 1.One report – one issue.Even if testers find problems in the same place, separate reports for each bug must be created. If you describe several issues in just one report, it will only confuse the developer and may cause them to miss some defects. In addition, the status of such a report cannot be changed until the developers fix all the bugs listed in it. Hence, it will be effortful to understand how the work is progressing.
  2.Avoid duplicates.Before creating a new bug report, it is necessary to check if the problem has already been described.
  3.Reproduce the bug a few times, ensuring you haven’t missed any important steps in the instructions for a developer. If it is not possible to repeat the problem every time, it is worth mentioning this and indicating the reproducibility coefficient (for example, the bug is reproduced 7/10 times).
  4.Stick only to the facts and do not make assumptions about what could have caused the defect. This can mislead developers and delay bug fixes.
  5.Always be polite, and do not blame or criticize colleagues. A tester’s job is to ensure a product’s quality, not to evaluate someone else’s work.
  6.Always proofread your report before submitting it. It should be short, clear, and contain all the necessary information.

  Creating good bug reports is a valuable skill for any tester. Apply your knowledge practically.