Функціональні баги пов’язані з функціональністю певного програмного продукту. Приклади: кнопка не відправляє форму, пошук не реагує на введення користувача, застосунок крашиться. Кожного разу, коли ви виконуєте дію, а сайт або застосунок не реагує так, як ви очікували, — це може бути функціональним багом. Обмежена інформація про продукти наших клієнтів і відсутність знань про їхню реалізацію ускладнює визначення того, чи є спостережувана поведінка задуманою чи це справжній баг. Обгрунтовані припущення, засновані на досвіді, та аналіз поведінки продукту через тестування різних сценаріїв можуть допомогти дійти правильного висновку.
Як визначити, чи є поведінка програми функціональною помилкою:
Спробуйте з’ясувати, чи функція реалізована саме так за задумом, чи вона дійсно зламана. Протестуйте її окремо та в комбінації з іншими функціями, щоб виявити можливі відмінності.
Подумайте, якими могли бути наміри клієнта, і врахуйте, що продукт може просто працювати так, як його реалізували.
Знайдіть докази того, що щось не працює, як повинно. Підкріпіть свою думку фактами.
Приклад: функціональність інтернет-магазину працює інакше, ніж в інших магазинах, які ви знаєте. Це не означає, що вона зламана. Клієнт має право реалізувати свій продукт так, як вважає за потрібне.
Приклад: ви вважаєте, що поле форми не проходить валідацію, і вказуєте це як баг. Чи є якісь ознаки того, що поле взагалі мало б проходити валідацію? Додайте докази: наприклад, покажіть, що в деяких випадках поле валідується, а в інших — ні. Якщо ви не надаєте доказів, це лише непідтверджене припущення.
Візуальна або контентна проблема стає функціональним багом, коли вона перешкоджає роботі функціоналу — у такому випадку її слід репортити як функціональну помилку.
Якщо певна функція послідовно працює однаково в різних сценаріях і не викликає явних проблем — найімовірніше, це так і задумано (тобто це не баг) і ви просто можете запропонувати зміну — usability-пропозицію.
Оцінка критичності (Severity Assessment)
Під час оцінки рівня критичності функціонального бага необхідно враховувати кілька факторів: функціональний вплив проблеми, її масштаб, наявність обхідних шляхів або те, чи є вона блокуючою, потенційні та значущі втрати продажів, а також можливість порівняння цього бага з іншими баґами такого ж рівня критичності.
Простий підхід — оцінити функціональний вплив бага. Подумайте, наскільки критичною є недоступність певної функції. Вторинна функціональність, як правило, не заважає користувачам досягати своєї мети — на відміну від основної функціональності. Запитайте себе, наскільки важлива ця функція в контексті всього продукту.
Питання про те, скільки людей, продуктів або елементів постраждали від функціональної проблеми, є визначальним для оцінки її масштабу. Наприклад, кнопка «Додати до кошика» не працює на всіх сторінках товарів у вебшопі чи лише на одній конкретній? Проблема стосується невеликої групи користувачів чи всіх?
Розгляньте, чи можете ви досягти своєї мети альтернативним шляхом або за допомогою іншого варіанта, чи ж функціональність залишається недоступною. Якщо ви інтуїтивно й легко знаходите спосіб обійти баг, такий так званий workaround все ще дозволяє досягти цілі. Баг, для якого існує workaround, отримує нижчий рівень критичності, ніж аналогічний баг без обходу.
Коли ж основна функціональність не працює і не існує жодного обходу, це вважається блокером або showstopper.
Оцінка потенційних втрат у продажах — це другорядний підхід, адже часто можна лише припустити, як користувачі відреагують на баг. Проте варто враховувати масштаб можливих втрат. Існує суттєва різниця між тим, якщо ціна товару відрізняється на кілька центів чи на сотні доларів.
Зрештою, ви також можете порівняти свій баг із тими, що вже були затверджені тим же тімлідом у цьому тесті, щоб переконатися, що обраний вами рівень критичності є доречним.
У нас є три рівні критичності (severity) для функціональних багів:
НИЗЬКА:
Мінімальний вплив на використання продукту.
Продукт поводиться не так, як очікується, але загальне використання не порушується.
Проблема стосується невеликої кількості користувачів, продуктів або елементів.
Функція або частина функціональності зламана чи недоступна, але існує простий workaround, який вирішує проблему.
ВИСОКА:
Серйозний вплив на використання продукту, але основна функціональність залишається доступною.
Проблема стосується великої кількості користувачів, продуктів або елементів.
Нетривіальна функціональність зламана або недоступна, і обхідного рішення не існує.
Важлива функціональність зламана або недоступна, але існує workaround (тобто це не блокер).
КРИТИЧНА:
Баг блокує основну функціональність застосунку або вебсайту.
Блокер (showstopper) не дозволяє користувачу продовжити основний процес, наприклад, оформлення замовлення.
Баг може спричинити потенційні та суттєві втрати продажів для компанії, яка керує застосунком або сайтом.
Загальні оцінки
У нас є список із фіксованими рівнями серйозності. Наведена вище схема оцінки не застосовується до випадків у цьому списку. Оскільки список буде оновлюватися з часом, перевіряйте його регулярно.
Баги граничних випадків (Edge case bugs)
Баги граничних випадків виникають тоді, коли функціональність використовується незвичним чином. При звичному введенні даних і стандартних діях користувача функція працює коректно. Ось кілька прикладів:
Миттєві дії, наприклад згортання програми після натискання кнопки
Повторно робити те саме, напр. відкриття та закриття меню
Будь-яка помилка, яка виникає лише після незвичайного набору дій
Кожен випадок оцінюється індивідуально. Баги граничних випадків, які мають значення для наших клієнтів, передаються як Low-баги. Нерелевантні випадки (а це більшість edge case багів) відхиляються.
Вимушені баги (Forced bugs)
Викликання бага шляхом нетипової поведінки або створення спеціальних умов зазвичай не входить у сферу тестування, оскільки такі баги не є релевантними для наших клієнтів. Нетипова поведінка не відображає звичайний користувацький сценарій. Приклади нетипової поведінки або спеціальних умов:
Натискання на кілька елементів одночасно
Випадкове натискання різних кнопок
Дуже швидке багаторазове натискання на одну кнопку
Зменшення вікна браузера до нетипових розмірів
Переповнення оперативної пам’яті (RAM) або внутрішньої пам’яті, що спричиняє нестабільну поведінку
Використання неофіційних, бета- або змінених версій операційної системи