Дефекти, їх джерела та життєвий цикл
Що розглянемо
- Що таке баги й дефекти, звідки виникають багі, що таке невідповідність очікуваного та отриманого результату.
- Життєвий цикл дефекту і що може очікувати дефект, який попав до системи трекінгу дефектів
Що таке баг?
Спочатку розберімось, чи є різниця між термінами “баг” і “дефект”.
Обидва терміни “баг” та “дефект” використовуються для зазначення помилки у програмному продукті. Однак, існує деяка різниця у їх використанні:
- Термін “баг” зазвичай належить до програмного збою, який проявляється в результаті неправильної або несподіваної реакції програми на конкретне введення або дію користувача. Цей термін часто використовується в повсякденному розмовному мовленні.
- Термін “дефект” зазвичай використовується для позначення будь-яких відхилень від вимог або специфікацій продукту, включаючи програмні помилки. Цей термін є більш офіційним і використовується частіше в індустрії якості програмного забезпечення.
В цілому, відмінності між цими термінами не дуже значні, і вони можуть бути використані як взаємозамінні в більшості випадків. Однак, якщо ви можете зіткнутися з перевагами у використанні одного терміну над іншим залежно від контексту та проєкту. Важливо пам’ятати, що важливіше, щоб Ви розуміли значення терміна, ніж його точну назву.
Баг або дефект — це або некоректна робота додатка, або коли додаток не виконує свої функції (не функціонує).
Джерела (Expected results)
Що таке “некоректна” робота?
Коли тестується додаток, тестувальник знає що додаток повинен робити, іншими словами — який має бути очікуваний результат (expected result).
Далі, тестувальник порівнює те, що отримано в результаті виконання програми (actual result) і порівнює його з очікуваним результатом. Якщо обидва результати збігаються — поведінка вважається очікуваною і ми робимо висновок, що це працює коректно. Якщо очікуваний результат не збігається з фактичним — це дефект (баг).
Звідки ми знаємо, що очікувати?
Очікувана поведінка береться з джерела очікуваної поведінки! Існує багато джерел очікуваної поведінки, серед них можуть бути:
Специфікації вимог (Requirements Specification)
Ще використовують скорочення “RS”. Це документ, який описує, що має бути реалізовано у продукті, що треба протестувати. Він містить інформацію про функціональність і поведінку, які очікуються від продукту.
Бізнес-вимоги (Business Requirements)
Це документ, який описує, як продукт використовуватиметься бізнесом. Він містить інформацію про те, як продукт має бути зручним для користувачів і як він буде генерувати прибуток для компанії.
Дизайн-документ (Design document)
Це документи, які описують, як продукт має виглядати та поводитися. Вони включають дизайн-макети, схеми, діаграми та інші документи, які показують, як повинен працювати продукт.
Знання досвідчених користувачів (Experienced users knowledge)
Це знання про те, як користувачі використовуватимуть продукт. Вони можуть бути отримані шляхом опитувань користувачів, спостереження за їх поведінкою та аналізу їхніх відгуків про попередні версії продукту.
Попередні версії продукту
Якщо продукт уже був випущений, його попередні версії можуть використовуватися як джерело очікуваного результату. Аналіз попередніх версій допоможе визначити, які функції будуть найбільш затребувані користувачами.
Схожі продукти
Поведінка продукту, який розв’язувати схожі задачі, або частина будь-якого продукту, яка робить те саме, що і наш продукт. Такі продукти називають оракулами (oracles)
Експертні знання
Це знання про продукт, які можна отримати від експертів у галузі або від розробників продукту. Експерти можуть дати цінні рекомендації щодо того, як продукт повинен поводитися і що очікувати від тестування.
Але при всьому різноманітті джерел, треба пам’ятати, що головне джерело — це вимоги в специфікаціях (чи те джерело, яке містить вимоги на конкретному проєкті). Якщо в вимогах немає опису очікуваного результату, його треба зрозуміти і узгодити з тими, хто відповідає за прийняття таких рішень з боку клієнта та команди, а потім треба додати до специфікації і узгодити це з людьми, які відповідають за вимоги на стороні клієнта та команди.
Коли ми бачимо опис якогось функціонала в, наприклад, дизайн документі, але не бачимо цього в вимогах специфікації, то треба погодити додавання цієї вимоги в специфікацію.
Специфікація — це головне джерело очікуваного результату.
Отже, тепер ми знаємо, що дефект в програмі — це коли поведінка, описана в специфікації, не збігається з поведінкою, отриманою в додатку, що працює.
Що таке некоректна робота
Що ще можна вважати “некоректною роботою”:
- збій програми, що призводить до її завершення (crash)
- зависання програми (програмою неможливо користуватися) (hang up)
- видача програмою системних повідомлень про помилки (system error)
- помилки дизайну, що заважають нормальній роботі з програмою (наприклад кнопка, яку неможливо нажати, бо вона перекрита інформаційним повідомленням)
- дрібні неточності та текстові помилки (орфографічні чи стилістичні)
Життєвий цикл дефекту (Defect Lifecycle)
Коли відхилення фактичного результату від очікуваного ідентифіковане, про це треба повідомити всі зацікавлені ролі на проєкті.
Коли така проблема ідентифікована і щоб її побачили інші ролі, вона додається до системи трекінгу дефектів:
Система відстеження дефектів (англ. bug tracking system, BTS) — прикладна програма, розроблена з метою допомогти розробникам програмного забезпечення (програмістам, тестувальникам та ін.) враховувати та контролювати помилки, знайдені у програмах, а також стежити за процесом усунення цих
Типова система відстеження помилок використовує концепцію «життєвого циклу».
Життєвий цикл — це сукупність станів дефекту/багу з моменту виявлення до моменту завершення над ним всіх дій (стану дефекту/багу від статусу New до статусу Closed).
Різні системи трекінгу дефектів мають свої стани й назви станів, але розгляньмо концептуальний набір станів, які може приймати дефект у своєму життєвому циклі.
Загальний життєвий цикл виглядає так. Одразу, як опис дефекту створюється в системі трекінгу, він попадає в статус New.
Хто може створити дефект? Будь-хто. Той, хто зацікавлений в його виправлені: тестувальник, розробник, менеджер, клієнт.
Коли дефект створений, у нього з’являється відповідальний (assignee). Це може бути безпосередньо розробник, чи хтось, хто приймає рішення про те, що робити з дефектом далі. Це може бути менеджер (PM), чи власник продукту (PO), чи хтось інший, хто приймає рішення про розвиток продукту.
Коли робота з дефектом почалася, він переходить в статус Open. А відповідальний змінюється на безпосередньо того, хто буде займатись його виправленням.
А далі все залежить від того, як assignee оцінить проблему.
Значення статусів:
Статуси Fixed / Verified Fixed
New – знайдено нову помилку
- Open – дефект був переданий на аналіз
- Fixed – помилка виправлена програмістом
- Verified Fixed – помилка перевірена тестувальником після виправлення (дійсно виправлена)
- Closed – проблема закрита (після виправлення та тестування, документування або підтвердження неможливості відтворення)
Найкраще за все, коли знайдений дефект виявився справді дефектом чи багом. Після виправлення він переходить в статус Fixed. В статусі Fixed відповідальним стає той, хто додав дефект (тестувальник). Якщо після перевірки тестувальник бачить, що дефект не було виправлено, то цей дефект знов попадає в статус Open. І знов розробник стає відповідальним і виправляє дефект. І переводить його в статус Fixed. Якщо тестувальник не згоден, то виставляє його в статус Open. Якщо дефект виправлено, тоді тестувальник переводить його в статус Verified Fixed. В статусі Verified Fixed відповідальним стає той, хто переводить дефекти в статус Open. Після цього дефект зі статусу Verified Fixed переходить в статус Closed, де його життєвий цикл завершується.
Статуси Can Not Reproduce / Verified Can Not Reproduce
- Cannot Reproduce – програміст не може відтворити дефект
- Verified Cannot Reproduce – тестувальник теж не може відтворити дефект
Рідко, але трапляються ситуації, коли дефект з’являється раз і більше не відтворюється (can’t reproduce). Це може бути викликано сукупністю кількох випадкових умов: стану пам’яті і якихось конфігурацій (наприклад). Якщо спробувати цей дефект відтворити знов, його більше не буде. В такому випадку розробник може встановити статус Can Not Reproduce. Якщо тестувальник дійсно не зможе після цього відтворити, то дефект переходить в статус Verified Cannot Reproduce. Частіше, такий результат з’являється, бо присутній недостатній опис дефекту. Якісь кроки були забути, чи не дуже явно описані. Особливості оточення, де знайдено дефект, вказані не повністю, чи вказані з помилкою. Коли тестувальник отримує дефект в статусі Can Not Reproduce, треба спочатку спробувати відтворити дефект на тому самому оточенні, де дефект був знайдений (та сама версія додатка, браузер чи операційна система) і перевірити, що всі деталі вказані в описі дефекту коректно. Якщо дефект досі можна відтворити, то статус змінюється на Open і послідовність кроків відтворення уточнюється.
Статуси Not an Issue / Verified Not an Issue
- Not an Issue – знайдена проблема не була визнана як дефект
- Verified Not an Issue – тестувальник погоджується, oj описана проблема не є дефектом
Однією з причин, чому дефект попадає в цей статус може бути пов’язане з оточенням, апаратним забезпеченням або іншими факторами, які не пов’язані безпосередньо з програмою. У такому разі розробник може вважати, що проблема не є дефектом, а скоріше зовнішнім фактором, на який не можна вплинути. Наприклад – зберігання файлу об’єм якого перевищує очікування файлової системи, чи спроба зберегти файл в шлях, довжина якого перевищує 256 символів. Все це є обмеженнями оточення, в якому працює додаток. Якщо тестувальник згоден з тим, що описана поведінка — не дефект, то такий дефект переходить в статус Verified Not an Issue
Статуси Duplicated / Verified Duplicated)
- Duplicated – опис проблеми є дублікатом іншого опису тієї ж проблеми
- Verified Duplicated – тестувальник погоджується, що заведеній дефект є дублікатом вже існуючого дефекту
Коли команда велика, то знати хто і які дефекти знайшов. Тому, буває, що тестувальник описав дефект, який вже до нього описав хтось інший. І якщо розробник прочитав ваш дефект і зрозумів, що він вже такий десь бачив, то дефект опиняється в статусі Duplicated.
Головна умова переводу дефекту в статус Duplicated – це те, що в ньому є номер дефекта, який розробник вважає дублікатом. Уважно подивись на зміст цього дефекту, чи він про те саме? Якщо ні, вертай його в статус Open. Якщо це той самий дефект – Verified Duplicated.
Статуси As Designed / Verified As Designed
- As Designed – програміст вважає, що проблема не є помилкою, а є особливістю дизайну
- Verified As Designed – тестувальник погоджується, що описана проблема – особливість дизайну
Це найсуперечливіша ситуація. Вона означає, что розробник не вважає описану проблему дефектом. Тоді такий дефект опиняється в статусі As Designed
Ситуация може виникати по багатьом причинам. Іноді навіть ліньки щось виправляти, але частіше розробники і тестувальникі по різному розуміють очікувальний результат і тому можуть чекати різну поведінку. Що тут треба зробити, це уточнити очікуваний результат у менеджера чи РО. І якщо він не такий, як очікував тестувальнік, то цей дефект переходить в статус Verified As Designed
Статус Deferred
- Deferred – помилка, можливо, буде виправлена, але виправлення помилки відкладено
Дефект в статусі Deferred значить, що опис приймається, як дефект, але цей дефект не є важливим та не потребує негайного виправлення. Або, виправлення дефекту не може бути виконано зараз через якісь технічні труднощі чи відсутність можливості виправлення.
Такі дефекти не закриваються (Сlosed), а лишаються в статусі Deferred до закінчення циклу розробки (випуску версії на ринок). Якщо продукт йде на другу версію, спочатку розглядаються дефекти, відкладені в попередній версії.
На кінецьпроекту дефекти можуть бути в двох статусах: Closed або Deferred. Ще раз проговоримо, що ми розглянули загальний набір статусів життєвого циклу дефекту, який не належить до якоїсь конкретної системи відстеження дефекту.
IT компанії на своїх проектах використовують системи відстеження дефектів, з певними статусами та перехідами (transitions) поміж цими статусами. Але загальний підхід буде той самий.
Вдалого полювання!
