Що таке функціональний баг та як його знайти

Баг – дефект, помилка в програмі, що викликає її неправильну і (або) непередбачувану роботу.

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

Відповідно до видів тестування баги бувають різного походження. Більш узагальнено їх можна поділити на функціональні і нефункціональні. Для ефективного функціонального тестування дуже важливо відрізняти дефекти функціоналу від інших. Розглянемо деякі рекомендації:

1. Необхідно визначити, чи є поведінка певної функції нормальною в різних умовах. Протестувати роботу функції самостійно і в поєднанні з іншими функціями для виявлення потенційних відмінностей.
2. Визначити можливі варіанти використання системи цільовою аудиторією користувачів, що допоможе визначити побажання до системи.
3. Перевірити верстку і контент, так як це може стати функціональним дефектом, якщо вони перешкоджають функціоналу.
4. У разі зацікавленості клієнта варто включити в перевірки тестування безпеки.
5. Звернути увагу на взаємодію системи зі сторонніми розширеннями браузера або антивірусом. Так як вони можуть блокувати частину контенту або роботу функціонала.

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

Залежно від мети, функціональне тестування може проводитися:

• грунтуючись на функціональних вимогах специфікації. Для повного покриття тестами всього функціоналу описуються тестові випадки (test cases). При цьому обов'язково враховується пріоритет функцій. Такий підхід дозволяє перевірити роботу системи при позитивних і негативних сценаріях: введення валідних і невалідних даних, різні комбінації дій і та ін.
• грунтуючись на бізнес-процесах, для проведення яких призначено додаток. Важливо, щоб функціонал системи забезпечував правильність виконання операцій з точки зору сценаріїв використання системи (use cases).

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

• До тестування можна приступати вже з моменту появи перших вимог. Тут доречно складання стратегії тестування, написання чек-лістів, тест-кейсів і та ін. Найчастіше це допомагає усувати велику кількість неточностей, готувати тестове оточення.

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

Приступаючи до написання чек-ліста, задайте собі наступні запитання:

1. Що належить тестувати?
   Необхідно розуміти яка це система: чітко знати вимоги до її роботи та цільове призначення.
2. Ким буде кінцевий користувач?
   Відповідь забезпечує розуміння і планування характерних сценаріїв використання системи.
3. Як зазвичай використовується система?
   Найкраще розділити основні завдання на більш дрібні підзадачі для складання перевірок позитивного тестування.
4. Як зламати продукт?
   Теж декомпозиція основних завдань, але з метою негативного тестування.

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

Пошук шляхів для оптимізації початкової стратегії тестування допоможе знизити трудовитрати на її проведення.

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

Для форми реєстрації пропонуємо перевірити:

• валідацію всіх обов'язкових полів;

• неприпустимість введення спецсимволів в поля;

• введення букв в числові поля – в цьому випадку має відображатися відповідне повідомлення про помилку;

• валідацію високосних років (чи вік вираховується правильно);

• відображення спливаючого повідомлення: «Це поле обмежене 60 знаками», якщо введені дані перевищують кількість 60 символів в полі «Логін»;

• відображення в потрібній валюті значення вартості передплати;

• функцію завантаження файлу умов згоди;

• функцію відкриття завантаженого документа;

• видалення кукі, перебуваючи на сайті;

• видалення кукі після відвідування сайту;

• функцію перенаправлення користувача на спеціальну сторінку помилки.

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