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

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

По суті, передбачення помилки в широкому сенсі – це все, що робить тестувальник при складанні тестових сценаріїв. Це словосполучення можна використовувати для опису всіх технік тест-дизайну. Адже основна мета цього процесу і полягає в тому, щоб визначити, в якому місці і за яких обставин з найбільшою ймовірністю може виникнути помилка, а також перевірити це в процесі тестування. Для тестувальника цей навик може стати відмінною підмогою в роботі. Щоб використовувати передбачення помилки в тестуванні, зовсім необов'язково мати досвід розробки ПЗ. Важливо розуміти базову логіку написання коду і розбиратися у вимогах, які будуть пред'являтися до кінцевого продукту. Далеко не зайвим буде і досвід в тестуванні схожих проєктів. Якщо ж немає такого досвіду - як варіант, можна скористатися допомогою колег, які успішно застосовують цю техніку у повсякденній роботі. Але найкраще, в такому випадку, сконцентруватися на інших, більш відчутних техніках складання тест-кейсів, які дозволять отримати надійніший результат.

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

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

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

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

До переваг цього методу можна віднести:

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

Основний же недолік техніки передбачення помилки – покриття тестами. Якщо в ході застосування цього методу буде знайдено певну кількість помилок – неможливо гарантувати те, що весь функціонал був протестований. Наприклад, якщо був знайдений дефект верстки при зменшенні розміру вікна браузера – це не означає, що всі можливі баги верстки були виявлені. Тому, саме через відсутність повного охоплення об'єкту тестами, передбачення помилки зазвичай застосовується в поєднанні з іншими техніками тест-дизайну.

Застосування методу на реальних проєктах

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

Сортування. Тестуючи цією функцією, необхідно враховувати поширену помилку серед розробників, коли числа «10», «11», «12» і так далі до числа «19» виявляються між числами «1» і «2». Таким чином, масив виводиться в такому вигляді:
1
10
11
12
...
19
2
20
Тому при тестуванні подібних масивів не варто обмежувати діапазон даних, що вводяться одним десятком.

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

L, M, S, XL, …
Тоді як правильно вибудувати в порядку збільшення розміру:
XXS, XS, S, M, L, XL, …

«У мене в браузері все працює». Як правило, в зв'язку з нестачею часу, розробники використовують для тестування своїх продуктів тільки один браузер. Далеко не завжди його версія збігається з тією, яка є пріоритетною на проєкті. Також розробка часто відбувається на MacOS, де стандартом вважається браузер Safari, а поновлення Chrome виходять з невеликим запізненням. Через це також можуть виникати помилки, так як різні браузери можуть інакше обробляти один і той же код. Рішення просте - уточнити пріоритетність кожного браузера і виконати тест-кейси для кожного з них. Корисно тестувати сайт на декількох браузерах одночасно - так буде простіше помітити відмінності в поведінці.

Ігнорування обробки некоректних вхідних даних. Нерідкі випадки, коли розробники навмисно не витрачають час на продумування і впровадження станів, які, на їхню думку, неможливі. Але потрібно враховувати, що продуктом будуть користуватися люди з самим різним мисленням, і вони можуть вводити в систему найрізноманітніші дані, які будуть некоректно оброблятися. У цьому випадку завдання тестувальника – передбачити всі можливі варіанти поведінки користувача і перевірити їх.
Наприклад: в Україні номера телефонів мобільних операторів складаються з 12 символів, тому розробник обмежує довжину поля для введення телефону до 12. Але якщо поле не містить попередньої розмітки (рисок і дужок), то користувач може вводити номер телефону самими різними способами:

• 380yyxxxxxxx: цей варіант буде прийнятий системою, так як був передбачений розробником;
• +380yyxxxxxxx: через символ «+» номер не пройде валідацію, так як довжина поля перевищує очікувану;
• 380 yy xxxxxxx: якщо поле вважає прогалини як окремі символи – тут вже 14 символів, а не 12;
• 380-yy-xxxxxxx/380(99)xxxxxxx: ситуація аналогічна до описаної вище.

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