Локалізація дефектів та оформлення баг-репортів

admin

Дефект (або баг) — вад у компоненті або системі, який може призвести компонент або систему до неможливості виконати необхідну функцію. Дефект, виявлений під час виконання, може призвести до відмови компонента або системи. Наприклад: неможливо зберегти дані після заповнення анкети.

Помилка – Дія людини, яка може призвести до неправильного результату. Наприклад: введення літер у поле для введення дати (мають прийматися лише цифри) з подальшим збереженням даних.

Відмова (failure) – Відхилення компонента або системи від очікуваного результату, виконання, експлуатації. Наприклад: під час переходу на наступну сторінку анкети дані попередньої сторінки затираються.

Класифікація багів

  • Функціональні дефекти — у цьому випадку програма функціонально працює не так, як задумано. Наприклад:

– не зберігаються зміни даних у профілі;
– не працює додавання коментаря;
– не працює видалення товару із кошика;
– Не працює пошук.

  • Візуальні дефекти — у цьому випадку програма виглядає не так, як задумано.

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

  • Логічні дефекти — у цьому випадку програма працює неправильно з точки зору логіки.

– можна поставити дату народження «з майбутнього», а також неіснуючі дати – 31 лютого, 32 грудня тощо;
– можна зробити замовлення, не вказавши адресу доставки;
– Логіка пошуку працює неправильно.

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

  • Дефекти зручності використання — у цьому випадку програма незручна у використанні.

– Відсутність підсвічування або повідомлення про помилку при некоректно заповнених полях форми;
– Скидання всіх даних при помилці заповнення реєстраційної форми;
– Перевантажений інтерфейс.

  • Дефекти безпеки — у цьому випадку можуть бути порушені дані користувача, є ризик падіння системи тощо.

– можна отримати логін, пароль у результаті використання SQL-ін'єкцій;
– Необмежений час життя сесії після авторизації.

Отже, ми розглянули типи та види дефектів. Тепер розповімо, як їх документувати.

Документування помилок

Звіт про помилку (Bug Report) — це документ, який описує ситуацію або послідовність дій, що призвела до некоректної роботи об'єкта тестування, із зазначенням причин та очікуваного результату.

«Наступний етап полягає в документуванні помилок», — могли б ви подумати, але виявилися б неправими.

Не можна просто взяти та задокументувати знайдений дефект. Насамперед, важливо виконати локалізацію.

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

Перевірка дефекту

Потрібно перевірити себе ще раз: відтворити баг знову за тих самих умов.Якщо помилка не повторилася при черговому тестуванні, потрібно розібратися, чи точно були дотримані всі дії та кроки відтворення, що призвели до цього результату. Можливо, дефект з'являється лише при початковому завантаженні системи (при першому використанні). Щоб точніше визначити умови відтворення помилки, необхідно цю помилку локалізувати.

Локалізація дефекту

Щоб локалізувати баг, необхідно зібрати максимальну кількість інформації про його відтворення:

Наприклад, не відбувається відновлення пароля. Потрібно виявити, звідки надходить запит на сервер у неправильному форматі – від backend або frontend.

  • Проаналізувати можливість впливу знайденого дефекту інші області

Наприклад, в одній із форм, яку рідко використовують, виникає помилка при натисканні на кнопку «Редагувати». Якщо як тимчасовий варіант вирішення проблеми приховати кнопку, це може вплинути на аналогічну форму в іншому вікні/вкладці, до якої користувачі звертаються частіше. Для якісного аналізу необхідно знати, як працює додаток та які залежності можуть бути між його частинами.

Потрібно перевірити, чи відповідає результат тестування очікуваного результату. Подолати це завдання допомагає технічне завдання (зокрема, вимоги до продукту), де має бути задокументована інформація про тестоване ПЗ та його функціонування. Пропускати цей крок при тестуванні не слід: якщо фахівець недостатньо досвідчений, не знаючи вимог, він може помилятися і неправильно розуміти, що стосується багів, а що ні. Уважне вивчення документації дозволяє уникнути таких помилок.

Необхідно відтворити баг у різних операційних системах (iOS, Android, Windows тощо) та браузерах (Google Chrome, Mozilla, Internet Explorer та ін.). При цьому слід перевірити вимоги до продукту, щоб з'ясувати, які системи мають підтримуватись. Деякі програми працюють лише у певних ОС або браузерах, тому перевіряти інші варіанти не потрібно.

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

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

Щоб не заплутатися в реалізованих завданнях, у розробці використовують версійність ПЗ. Іноді той чи інший баг відтворюється на одній версії продукту, але з відтворюється на інший. Цей атрибут обов'язково необхідно вказувати у баг-репорті, щоб програміст розумів, у якій галузі потрібно шукати проблему.

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

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

Фіксування доказів

Докази відтворення бага потрібно фіксувати за допомогою логів, скринів або запису екрана.

  • Логи (лог-файли чи журнал) — це файли, які містять системну інформацію роботи сервера або комп'ютера, зберігають інформацію про певні дії користувача або програми. Досвідченому розробнику буває достатньо подивитися в логи, щоб зрозуміти, у чому полягає помилка. Зазвичай логи прикріплюють до баг-репорту як .txt-файла.

Live-логування – Це зняття системних логів у режимі реального часу. Для цього можна використовувати такі програми: Fiddler, Visual Studio для Windows, iTools, Xcode для iOS, Android Debug Monitor, Android Studio для Android та ін.

  • Скрин (знімок) екрану. При помилках в інтерфейсі знімок допомагає швидше розібратися у проблемі. Програм для зняття скріншотів дуже багато, кожен QA-фахівець може використовувати ті, які найбільш зручні йому: Jing, ShareX, Lightshot та ін.
  • Скринкаст (англ. screen – екран, broadcasting – трансляція) – запис відео з екрана комп'ютера або іншого цифрового пристрою. Це один із найефективніших способів поділитися тим, що відбувається на екрані монітора. У такий спосіб QA-фахівцю легко наочно показати помилки у роботі будь-якого програмного продукту. Зробити запис з екрану допоможуть незамінні інструменти будь-якого QA-фахівця: Snagit, Monosnap, Movavi Screen Capture, Jing, Reflector, ADB Shell Screenrecord, AZ Screen Recorder та ін.
  • Рекордер дій. Програмні засоби дають можливість відтворити всі записані рухи мишки та дії, які виконуються на клавіатурі комп'ютера. Приклади програм – Advanced Key and Mouse Recorder для desktop-платформ.

Оформлення баг-репорту

Усі знайдені дефекти обов'язково потрібно документувати, щоб кожен задіяний на проекті фахівець міг отримати інструкції щодо відтворення виявленого дефекту та зрозуміти, наскільки це критично. Якщо в команді прийнято усно передавати розробнику інформацію про знайдені дефекти, є ризик упустити щось із виду.

Дефекту, який не задокументовано – не знайдено!

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

Атрибути баг-репорту:

1. Назва

Баг має бути описаний коротко і ємно, мати зрозумілу назву. Це допоможе розробнику розібратися в суті помилки і в тому, чи може взяти цей випадок у роботу, якщо займається відповідним розділом системи. Також це дозволяє спростити підключення нових фахівців на проект, особливо якщо розробка ведеться багато років поспіль, а запам'ятовувати баги та відстежувати їх у таск-трекері стає дедалі складніше. Назву проекту можна складати за принципом «Де? Що? Коли? чи «Що? Де? Коли?» залежно від внутрішніх правил команди.

Де відбувається? – У картці клієнта (у якому розділі системи).

Що саме відбувається? – Не зберігаються дані.

Коли відбувається? — За збереження змін.

2. Проект (назва проекту)

3. Компонент програми

У якій частині функціональності продукту, що тестується, знайдено баг.

4. Номер версії

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

5. Критичність

Цей атрибут показує вплив дефекту на функціональність системи, наприклад:

· Blocker – Дефект, що блокує використання системи.

· Critical – Помилка, яка порушує основну бізнес-логіку роботи системи.

· Major – Помилка, яка порушує роботу певної функції, але не всієї системи.

· Minor — незначна помилка, що не порушує бізнес-логіку програми, наприклад, помилка інтерфейсу користувача.

· Trivial – Непомітна, неочевидна помилка. Це може бути друкарська помилка, неправильна іконка і т.п.

Пріоритет визначає, наскільки терміново необхідно виправити помилку. Зазвичай виділяють такі види пріоритетів:

High — помилка має бути виправлена ​​якнайшвидше, є критичною для проекту.
Medium — помилка має бути виправлена, але її наявність не є критичною для проекту.
Low — помилка має бути виправлена, але не потребує термінового вирішення.

Статус вказує стадію життєвого циклу бага, взято він у роботу чи вже вирішено. Приклади: to do, in progress, in testing (QA), done. Залежно від особливостей проекту, можливі додаткові статуси (наприклад, аналітика).

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

Де знайдено баг: операційна система, найменування та версія браузера.

11. Передумова (якщо потрібно)

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

12. Кроки відтворення

Один із найважливіших атрибутів – опис кроків, які призвели до знаходження бага. Оптимально використовувати 5-7 зрозумілих та коротких кроків для опису бага, наприклад:
1. Відкрити (. )
2. Клікнути (…)
3. Ввести в поле А значення N1
4. Ввести в поле B значення N2
5. Клікнути кнопку Calculate

13. Фактичний результат

Що сталося після відтворення вказаних вище кроків.

14. Очікуваний результат

Що має статися після відтворення кроків тестування відповідно до вимог.

15. Прикріплений файл

Логи, скріншоти, відеозапис екрану – все, що допоможе розробнику зрозуміти суть помилки та виправити її.

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

Локалізація та оформлення багів – необхідні складові роботи QA-фахівця з програмним продуктом. Запрошуємо докладніше ознайомитись з послугами тестування та забезпечення якості у SimbirSoft.

Локалізація дефектів та оформлення баг-репортів - Priroda.v.ua

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

Критичність та пріоритет бага. Атрибути баг-репорту

Необхідно розповісти про пріоритет та критичність бага. Важливо розуміти різницю між ними. Приклади наведу з власного досвіду. Об'єктом тестування моєї роботи є ПЗ приймачів цифрового телебачення.Головним завданням ПЗ приймача є розшифрування контенту, що передається в зашифрованому вигляді. Для успішної розшифровки абонент має придбати у оператора передплату на відповідний пакет телеканалів.

Критичність бага — це атрибут, який характеризує вплив бага на загальну функціональність ПЗ, що розробляється. За критичністю баги ділять на:

S1. Блокуючий (Blocker). Все тестоване програмне забезпечення не може працювати без усунення бага. Наприклад, приймач починає перезавантажуватися відразу після включення, ми не зможемо більше нічого протестувати через цей баг.

S2. Критичний (Critical). Більшість ПЗ не може коректно працювати. Наприклад, приймач не може відкривати закодовані канали. До усунення цього дефекту можна протестувати UI, а також функціональність, яка не пов'язана з розшифровуванням каналів.

S3. Значний (Major). Блокує роботу одного з основних логічних ланцюжків ПЗ. Наприклад, неправильне повідомлення про помилку за відсутності передплати пакета оператора.

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

S5. Тривіальний (Trivial). Цей ступінь присвоюється, коли баг взагалі не впливає на загальну якість ПЗ. Наприклад, незначне перетинання елементів у меню.

Пріоритет бага — це те, як потрібно вирішувати проблеми. Існує три ступені пріоритетності:

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

P2. Середній пріоритет (Medium). Точно потрібно буде виправити, баг досить важливий, але не потребує негайного вирішення. Наприклад, некоректний переклад меню меню приймача.

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

Що таке баг-репорт, його типова структура

Глосарій ISTQB говорить, що баг репорт — це документ, що містить звіт про будь-який недолік у компоненті або системі, який може призвести компонент або систему до неможливості виконати потрібну функцію.

Але можна сказати і простіше: баг репорт (bug report) – це технічний документ, який містить у собі повний опис бага, що включає інформацію як про сам баг (короткий опис, критичність, пріоритет і т. д.), так і про умови виникнення цього бага.

Склад баг репорту наведено у таблиці:

Короткий опис проблеми, що явно вказує на причину і тип помилкової ситуації.

Назва тестованого проекту

Компонент програми (Component)

Назва частини або функції продукту, що тестується

Номер версії (Version)

Версія, на якій було знайдено помилку

Найбільш поширена п'ятирівнева система критичності:

S1 Блокуючий (Blocker)

S2 Критичний (Critical)

S3 Значний (Major)

S4 Незначний (Minor)

S5 Тривіальний (Trivial)

Статус бага. Залежить від використовуваної процедури та життєвого циклу бага. Наприклад:

Призначений на (Assigned To)

Ім'я співробітника, призначеного на вирішення проблеми

Інформація про оточення, на якому було знайдено баг: операційна система, сервіс пак, ім'я та версія браузера, версія чіпа, версія бібліотеки і т.д.

Кроки, якими можна легко відтворити ситуацію, що призвела до помилки.

Прикріплений файл (Attachment)

Файл з логами, скріншот або будь-який інший документ, який може допомогти прояснити причину помилки або вказати на спосіб вирішення проблеми

Як правильно оформити баг-репорт

  1. Для початку потрібно переконатись, що знайдений баг ще не був оформлений. Слід здійснити пошук його у відповідному проекті за всіма відповідними ключовими словами та/або полями. Якщо баг є, слід оновити його опис.
  2. Якщо баг не знайдено – натискаємо на кнопку створення бага. Не варто забувати важливе правило: один дефект – один баг у трекері.
  3. Далі потрібно постаратися коротко описати, що не працює — це буде заголовок баг-репорту.
  4. Після цього перейти до детального опису бага: вказати кроки до відтворення.
  5. Вказати очікуваний результат. Ви можете додати посилання на специфікацію.
  6. Вказати отриманий результат.
  7. Вказати версію ПЗ, а також вказати версію оточення.
  8. Якщо потрібно, додати відповідні артефакти: логи, скріншоти, дампи і т.д.

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

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

Заголовок не зрозумілий. Є ризик, що ні розробник, ні колеги не звернуть увагу на досить критичну проблему.

Відсутні кроки для відтворення. Є ризик, що розробник, не зрозумівши, як повторити проблему, поверне баг зі статусом «Не відтворюється».

Неправильно призначено баг. Можливо, баг помилково був призначений не на того розробника або взагалі залишився у статусі «не призначений». Є ризик, що багу довгий час не буде приділено увагу.

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

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

Життєвий цикл бага

Отже, баг знайдено, репорт складено, що далі? Далі ведеться робота над багом відповідно до життєвого циклу, який може бути налаштований у системі багтрекінгу. Насправді це залежить від процесів у компанії.

Якщо коротко, то після створення баг-репорту статус бага може виглядати так:

  • Новий (New). Тестувальник знайшов баг, дефект успішно занесений у bug-tracking систему.
  • Відкрито (Opened). Після того, як тестувальник відправив помилку, вона або автоматично, або вручну призначається на людину, яка має її проаналізувати. Залежно від рішення, баг може бути:
  • Відкладено (Postponed). Виправлення бага відкладено, т.к. він не є критичним на даному етапі розробки чи з інших причин.
  • Відхилений (Rejected). З різних причин дефект може і не вважатися таким, що змушує його відхилити. Не баг, а фіча.
  • Дублікат (Duplicate). Якщо описана помилка вже раніше була внесена до «Bug-tracking» системи.
  • Призначений (Assigned). Якщо помилка є актуальною і має бути виправлена ​​в наступній збірці (build), відбувається призначення на розробника, який має виправити помилку.
  • Виправлено (Fixed). Відповідальний за виправлення бага розробник заявляє, що усунув дефект.
  • Перевірено (Verified). Тестувальник перевіряє, чи справді відповідальний розробник виправив дефект. Якщо бага більше немає, він набуває цього статусу.
  • Повторно відкрито (Reopened). Якщо побоювання тестувальника виправдані, і баг у новому білді не виправлений — він так само вимагатиме виправлення, тому знову відкривається.
  • Закрита (Closed). Внаслідок певної кількості повторних перевірки баг все-таки остаточно усунений і більше не вимагатиме уваги команди — він оголошується закритим.

Наочніше життєвий цикл бага можна подивитися на діаграмі:

При використанні системи тест менеджменту Test IT існує можливість інтеграції із системами баг-трекінгу: Jira, Azure DevOps, Redmine, YouTrack, ClickUp, TeamStorm.

Як приклад покажемо TeamStorm. Достатньо натиснути «Зберегти та створити баг», і ми отримуємо майже готовий баг-репорт у баг-трекері.

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

Замість ув'язнення

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

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

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

Чи була стаття корисною?