Чим баг відрізняється від дефекту

Класифікація дефектів, з точки зору ступеня впливу (Severity) на працездатність ПЗ:

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

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

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

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

Trivial. Баг, який не має вплив на функціонал або роботу програми, але який може бути виявлений візуально. Наприклад, помилка в тексті.

Градація дефектів, з погляду пріоритетності виправлення (Priority):

High. Баг повинен бути виправлений якомога швидше, оскільки він критично впливає на працездатність програми.

Medium. Дефект повинен бути обов’язково виправлений, але він не робить критичний вплив на роботу програми.

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

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

• Обери курс для навчання
  • Тестування
    • Базовий модуль тестування
    • Тестування ПЗ
    • Тестування Web-сервісів
    • Тестування мобільних додатків
    • Тестування навантажання з JMETER
    • Розширений модуль з Автоматизації тестування
    • Автоматизація тестування за допомогою Selenium WebDriver (Python)
    • Автоматизація тестування за допомогою Selenium WebDriver (Java)
    • Автоматизація тестування за допомогою Selenium WebDriver (C#)
    • Автоматизація тестування на JavaScript
    • Java для автоматизаторів
    • Fullstack Web Developer
    • Java
    • Python
    • JavaScript
    • HTML5 І CSS3
    • Повний стек розробки на фреймворку Laravel
    • Розробка CMS на основі PHP
    • Git для автоматизаторів
    • Практичний SQL
    • Основи Unix та мережі
    • Web-сервери та Web-сервіси
    • Створення проекту автоматизації та написання UI тестів
    • Написання комбінованих тестів UI та API. Написання BDD тестів
    • IT Project Manager
    • HR-менеджер в ІТ-компанії
    • Як правильно скласти резюме та пройти співбесіду
    • Підготовка до сертифікації ISTQB Foundation Level на основі Syllabus Version 2018
    • Тестування
      • Базовий модуль тестування

      Чим баг відрізняється від дефекту

      Чи знали ви, що терміну “баг” офіційно немає? Цим словом помилково називають усі проблеми, що виникають у коді – але майбутнім QA інженерам цього пояснення має бути недостатньо. Озброюємось словником ISTQB та допомогою експертів EPAM і розповідаємо про чотири базові терміни, що має знати кожен тестувальник.

      Що таке “баг”?

      Баг (офіційно – “defect“, синоніми “bug”, “fault”) – це, узагальнено кажучи, будь-який недолік у продукті, через який цей продукт не відповідає вимогам. Тобто, якщо замість числа від 1 до 9 функція чомусь видає повний текст Конституції України, десь стався баг і продукт треба фіксити.

      Вимоги закладаються ще на початку роботи над проєктом; на них ґрунтується очікуваний функціонал продукту, який вже пізніше буде перевіряти тестувальник. Якесь відхилення – і QA спеціаліст “заводить” баг, який мають виправити розробники.

      Історія терміну “баг” дуже цікава: 9 вересня 1945 року вчені Гарвардського університету знайшли в обчислювальній машині справжнього метелика, що застряг в електромеханічному реле. Цю комаху вони приклеїли в технічний журнал із підписом: «Перший задокументований випадок знаходження багу».

      Що таке “помилка”?

      Помилка (офіційно – “error”, синонім “mistake”): це, згідно з ISTQB, будь-яка дія людини, що спричинила невірний результат. Це може бути як невірно введений пароль, який призвів до error 403, так і помилка в коді, якої припустився розробник, і через яку “випадково” впали сервери.

      Баг може бути результатом помилки, але помилка ≠ баг, адже, у випадку невірного паролю, це – очікувана поведінка системи. Простіше кажучи, помилка може бути результатом дефекту, або ж одною з “правильних” відповідей на неправильні дії користувача.

      Що таке “відмова”?

      Відмова (офіційно – “failure”, також трапляється варіант “interruption”). Повне визначення з ISTQB – “подія, коли система не виконує очікувану функцію” – але нащо мати окремий термін, який означає майже те саме, що й баг?

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

      Уявіть звичайного швейного майстра, який виготовляє пальто. В одному з виробів майстер випадково не пристрочив кишеню – отож, майстром було зроблено помилку (error). Пальто спокійно собі висіло на вішалці для одягу – на перший погляд, абсолютно звичайне, але в ньому “завівся” баг (defect). Дефект є непомітною на перший погляд помилкою, яка може не впливати на роботу системи у звичайному стані; однак, за умови надмірного навантаження (як один із варіантів) дефект дає про себе знати та стає причиною відмови. Зрештою, пальто з дефектом (або багом) хтось придбав і ця людина спробувала покласти в кишеню телефон, який одразу ж звідти випав. Пальто (або його кишеня) не виконало очікувану функцію – телефон мав залишитися в кишені в безпеці.

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

      Що таке “аномалія”?

      Аномалія (офіційно “anomaly”, або ж “deviation”) – це збірний термін, під яким може матися на увазі і баг, і відмова, і помилка. Аномалія є широким терміном, який можна використати у будь-якій ситуації, коли щось йде не за планом (приклади: “Я сьогодні аномально втомився, тому всі таски виконаю завтра” або “У коді сталася аномалія, і замість калькулятора у мене випадково написався штучний інтелект”).

      Вітаємо, тепер ви трохи ближче знайомі з професією тестувальника! І якщо ви точно знаєте, що пошук дефектів та удосконалення систем є вашим покликанням – приєднуйтесь до наборів за напрямом Software Testing в EPAM. Можливо, саме вас не вистачає в нашій команді!

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

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

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

      Спочатку давайте згадаємо визначення дефекту.

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

      Якщо ви виявили баг, не варто негайно заводити його в баг трекер з описом «нічого не працює!». Відтворіть дефект повторно. Знову відтворюється? А тепер мінімізуйте кількість кроків для відтворення, та переконайтесь, що немає нічого зайвого.

      Якщо використовуються певні вхідні дані, переконайтесь що вони не містять зайвої інформації.Коли ви зрозуміли, які саме дані та які ваші дії призводять до проблеми, коротко сформулюйте її суть – придумайте тему (опис) баг-репорта.

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

      Щоб заводити дефекти правильно, необхідні технічна кваліфікація та розуміння архітектури продукту, що тестується. Якщо ми говоримо про веб-тестування, то слід вказати в баг-репорті код помилки, який повертає сервер, подивитись подробиці за допомогою «Firebug» та надати детальну інформацію.

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

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

      Основні причини, чому дефект не відтворюється повторно:

      1. Дефект відтворюється тільки при першому запуску додатка. Для повторного відтворення необхідно знову виконати інсталяцію додатка.
      2. Використовуються старі дані системи, в які не були внесені зміни в процесі тестування.
      3. Швидкість відтворення дефекта. Швидкість виконання кроків для відтворення повинна бути ідентичною.

      Бувають ситуації, коли у вас дефект відтворюється з вірогідністю 100%, але розробник не може відтворити у себе даний дефект. В таких випадках необхідно звернути увагу на оточення тестованого продукта :

      Незважаючи ні на що, дефекти, які не відтворюються повторно, все ж таки потрібно заводити в баг-трекер. Важливо при цьому не забувати вказувати відповідне значення відтворюваності дефекта (Reproducibility).

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

      • Скрінкаст (англ. screen – екран, broadcasting – трансляція) – це запис відеозображення з екрана комп’ютера чи іншого цифрового пристрою. Це один із найбільш ефективних варіантів поділитися тим, що відбувається на екрані монітора. Таким чином тестувальнику легко наочно показати помилки в роботі будь-якого програмного продукту. Знімають скрінкасти спеціальними програмами, наприклад: Snagit, Movavi Screen Capture, Jing, Reflector, ADB Shell Screenrecord, AZ Screen Recorder.
      • Live-логування – це зняття системних логів в режимі реального часу. Лог-файли (журнал подій, Log) – це файли, що містять системну інформацію роботи сервера або комп’ютера в хронологічному порядку, в які вносяться певні дії користувача або програми. Для цього можуть використовуватися наступні програми: Visual Studio для Windows, iMazing для iOS, XCode для MacOS, Android Debug Monitor для Android.
      • Створюйте нотатки. Зберігайте все, що ви знаєте про дефект, який виник. Тоді вся потрібна інформація буде у вас під рукою, коли ви підключите розробників до роботи над цією проблемою.
      • Рекордер дій. Існують програми, які дозволяють повторювати всі записані рухи мишки та дії, виконані на клавіатурі ПК. Прикладом такої програми є Advanced Key and Mouse Recorder. Нажаль даний метод актуальний лише для десктопних платформ, для мобільних платформ аналогічних програм поки що немає.

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

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

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

      В цьому випадку рекомендується передивитися свою роботу і спробувати подивитися на ситуацію з нової точки зору.

      У випадках, коли здається, що помилку відтворити неможливо, необхідно:

      • відкинути теорії, які не підходять;
      • розробити нові теорії або змінити існуючі;
      • подивитись всі записи та шукати те, що було упущено або проігноровано в попередніх теоріях.

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

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

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