Якщо Вам ще не знайомі терміни, якими користується кожен тестувальник, рекомендуємо повернутися до статті про важливі терміни для цієї професії та ознайомитись з ними. У цій статті ми поговоримо про баг-репорти та важливість вміти правильно їх складати.
Але для початку трохи передісторії. Ще в 1947 році в Гарвардському університеті інженер виявив застряглого метелика між контактами реле, що стало причиною несправності ЕОМ Mark II. Цим інженером була Грейс Хопер. Після вилучення, вона вклеїла його скотчем у технічний щоденник, вказавши, що першою помилкою в системі був жучок (з англ. bug). З того часу помилки програмних систем називали багами.
Так, з того часу тестування системи на коректність роботи та пошук несправностей удосконалювалося і набуло зовсім іншого характеру, але, загалом, основний принцип роботи залишився тим самим.
Але для початку трохи передісторії. Ще в 1947 році в Гарвардському університеті інженер виявив застряглого метелика між контактами реле, що стало причиною несправності ЕОМ Mark II. Цим інженером була Грейс Хопер. Після вилучення, вона вклеїла його скотчем у технічний щоденник, вказавши, що першою помилкою в системі був жучок (з англ. bug). З того часу помилки програмних систем називали багами.
Так, з того часу тестування системи на коректність роботи та пошук несправностей удосконалювалося і набуло зовсім іншого характеру, але, загалом, основний принцип роботи залишився тим самим.
Баг полягає в основній ідеї тестування та характеризується як невідповідність фактичної роботи програмного забезпечення очікуваному результату, тобто технічному завданню чи специфікації від замовника. Перевірка на баги відбувається не тільки безпосередньо вже на етапі тестування готового продукту, а й на етапі аналізу техзавдання. Під тестування може потрапляти як інтерфейс у зручності користування, так і точність дизайну продукту, або функціональна складова бекенду програми.
Кожна помилка системи має бути задокументована. І звіт, в якому вказані всі баги, називається баг-репорт. У ньому вказується детальний опис помилки, що сталася на етапі тестування та всі дії, що до неї призвели.
Кожна помилка системи має бути задокументована. І звіт, в якому вказані всі баги, називається баг-репорт. У ньому вказується детальний опис помилки, що сталася на етапі тестування та всі дії, що до неї призвели.
Важливо дотримуватись всіх правил написання баг-репорту, про які ми поговоримо нижче. Але головне - чим детальніше і коротко буде написано звіт, буде вказівка на ключові моменти для точного відтворення бага, тим якісніша буде робота тестувальника.
Кожен баг-репорт складається з кількох важливих атрибутів, які обов'язково вказуються у ньому:
Кожен баг-репорт складається з кількох важливих атрибутів, які обов'язково вказуються у ньому:
- Саммарі (стислий опис помилки в одному рядку) - будується за принципом: що не працює? де не працює? коли? чи за яких умов не працює? Наприклад,- "Не здійснюється оплата, після натискання на кнопку "Купити" на сторінці купівлі товару".
- Опис помилки (кроки відтворення помилки), має бути коротким і ясним програмісту. Тут вказуються всі кроки, тобто умови, виникнення бага, фактичний результат та очікуваний результат роботи програми.
- Проєкт - вказується найменування програми, сайту чи іншої програми, до якої належить наш баг, для подальшого відстеження усунення цього дефекту.
- Компонент - під ним слід розуміти частину програми, або ділянку розробки, в якій було допущено баг. Якщо у різних частинах продукту є схожі ділянки коду, рекомендується перевірити один баг на кількох ділянках розробки. Наприклад, каталог інтернет-магазину передбачає наявність фільтрів для деталізації пошуку певного товару, але також на різних категоріях товару є ймовірність ділянки розробки коду, що повторюється, для фільтрів, які можуть бути просто скопійовані розробником. Якщо є баг в одній частині, він неодмінно буде і в іншій ділянці.
- Серйозність - тобто критичність помилки, або наскільки дана помилка впливає на працездатність нашого програмного забезпечення. Найчастіше це - несуттєвий (Minor), значний (Major), критичний (Critical) чи блокуючий (Blocker).
- Пріоритет – послідовність виправлення багів, виходячи з попередньої атрибуту бага. Зазвичай це високий (High), середній (Medium) і низький (Low). Важливо відзначити, що пріоритет тестувальник не проставляє - цим займається менеджер або той, хто займається розподілом завдань на програмістів.
- Статус - це фіксація етапу усунення бага у його життєвому циклі. Наприклад, відкритий (Open), закритий (Closed), новий (New) або перевідкритий (Reopen).
- Версія білда, тобто версія нашого продукту, в якій припущена помилка. Іноді цей атрибут може бути не вказаний, якщо немає версії продукту або бага відтворюється у всіх версіях програмного забезпечення.
- Автор - той учасник команди, який вносить інформацію про баг.
- Оточення - під це поняття може потрапляти ОС, розряд системи, браузер, у якому було виявлено помилку.
Хорошим доповненням до звіту будуть скріни помилок з відмітками (наприклад, стрілками та цифрами) послідовності відтворення бага. Також, якщо баг складний, можна записати відео і прикріпити його до баг-репорту.
Найважливішими атрибутами кожної помилки в баг-репорті є серйозність і пріоритет. І якщо рівень серйозності вказує тестувальник, то за пріоритетність їх усунення відповідає PO (Product Owner) з боку замовника або проджект менеджер (PM). Оскільки є незначні помилки, які не ламають додаток, наприклад, найменування інтернет-магазину, в якому допущена помилка, але їх усунення першочергово важливе для престижу компанії замовника.
Найважливішими атрибутами кожної помилки в баг-репорті є серйозність і пріоритет. І якщо рівень серйозності вказує тестувальник, то за пріоритетність їх усунення відповідає PO (Product Owner) з боку замовника або проджект менеджер (PM). Оскільки є незначні помилки, які не ламають додаток, наприклад, найменування інтернет-магазину, в якому допущена помилка, але їх усунення першочергово важливе для престижу компанії замовника.
Розглянемо класифікації ступеня серйозності багів та його вплив на працездатність програмного забезпечення.
Для правильної назви заголовка бага в атрибуті опису можна використовувати золоте правило "що?", "де?" і "коли?". Що - що не працює коректно, Де – місце, в якому виявлено помилку, коли – за яких умов. Чим коректнішим і зрозумілішим буде опис бага, тим швидше він буде усунений. Оскільки, якщо баг буде не відтворюваний, то найімовірніше програміст відхилить цю помилку і вона не буде виправлена.
Усі баг-репорти вносяться до баг-трекінгових систем. По суті, баг-трекінгові системи створені не тільки для фіксації багів. В них також вносяться і User-стори, технічні вимоги від PM реалізації у продукті та інша документація. Найпоширенішими баг-трекінговими системами є Jira (найбільш використовувана), Asana, Redmine, Trello и Bugzilla.
- Blocker – та помилка, яка призводить до непрацездатності нашої програми. Тобто її подальше використання користувачем стає неможливим.
- Critical – є кілька варіантів: відхилення від логіки роботи програмного забезпечення, задуманого замовником; неробочий функціонал окремих елементів ПЗ (наприклад, відсутність переходу в кошик після натискання кнопки "Купити" на сайті інтернет-магазину); не збереження даних сеансу або користувача.
- Major - є схожість з критичними помилками, але в даному випадку програма працює, але не відповідає запитам замовника.
- Minor – незначний дефект, що не порушує працездатність ПЗ. Наприклад, помилка в дизайні програми.
- Trivial - найменш незначний баг програмного забезпечення, наприклад, текстова друкарська помилка. Вона ніяк не впливає на працездатність, але не відповідає бажаному результату технічного завдання.
Для правильної назви заголовка бага в атрибуті опису можна використовувати золоте правило "що?", "де?" і "коли?". Що - що не працює коректно, Де – місце, в якому виявлено помилку, коли – за яких умов. Чим коректнішим і зрозумілішим буде опис бага, тим швидше він буде усунений. Оскільки, якщо баг буде не відтворюваний, то найімовірніше програміст відхилить цю помилку і вона не буде виправлена.
Усі баг-репорти вносяться до баг-трекінгових систем. По суті, баг-трекінгові системи створені не тільки для фіксації багів. В них також вносяться і User-стори, технічні вимоги від PM реалізації у продукті та інша документація. Найпоширенішими баг-трекінговими системами є Jira (найбільш використовувана), Asana, Redmine, Trello и Bugzilla.
Після початкових усунень багів, розроблений продукт тестується повторно, окремо на відтворення бага, і окремо за функціоналом, який міг бути порушений під час виправлення помилок. Потрібно розділяти повторне тестування бага і повторне тестування суміжного компонента, щоб не дублювати фіксацію однієї помилки.
Перед написанням баг-репорту обов'язково відтворіть помилку кілька разів. Оскільки вона могла виникнути у зв'язку з нестабільною роботою мережі, або через неполадки ПК та інші причини, не пов'язані з працездатністю самого програмного забезпечення. Якщо виникнення бага повторюється, необхідно відразу зафіксувати помилку та повідомити про неї програміста. Також краще заздалегідь перевірити помилку з різних браузерів та з мобільної версії, щоб максимально точно локалізувати місця, де щось не працює. Дуже часто, можна спостерігати помилки тільки в браузері Chrome, у свою чергу, як у Firefox все буде працювати коректно. І навпаки.
Перед надсиланням баг-репорту програмістам необхідно перечитати його кілька разів, перевірити на орфографічні помилки, ще раз оцінити стислість і ясність написаного звіту. Баг-репорт є одним із найважливіших документів тестувальника, він показує вашу грамотність та кваліфікованість.
Детальніше про правила написання баг-репорту ми розповідаємо на курсі тестувальника з нуля. Приєднуйтесь до наступного потоку курсу. Ми допоможемо освоїти найпопулярнішу професію легко та отримати якісні знання.
Перед написанням баг-репорту обов'язково відтворіть помилку кілька разів. Оскільки вона могла виникнути у зв'язку з нестабільною роботою мережі, або через неполадки ПК та інші причини, не пов'язані з працездатністю самого програмного забезпечення. Якщо виникнення бага повторюється, необхідно відразу зафіксувати помилку та повідомити про неї програміста. Також краще заздалегідь перевірити помилку з різних браузерів та з мобільної версії, щоб максимально точно локалізувати місця, де щось не працює. Дуже часто, можна спостерігати помилки тільки в браузері Chrome, у свою чергу, як у Firefox все буде працювати коректно. І навпаки.
Перед надсиланням баг-репорту програмістам необхідно перечитати його кілька разів, перевірити на орфографічні помилки, ще раз оцінити стислість і ясність написаного звіту. Баг-репорт є одним із найважливіших документів тестувальника, він показує вашу грамотність та кваліфікованість.
Детальніше про правила написання баг-репорту ми розповідаємо на курсі тестувальника з нуля. Приєднуйтесь до наступного потоку курсу. Ми допоможемо освоїти найпопулярнішу професію легко та отримати якісні знання.
З усіх питань зв'яжіться з нами будь-яким зручним способом:
Телефони:
E-mail:
Ми в соцмережах: