Сьогодні як ніколи актуальним є питання тестування програмного забезпечення. І актуальність даної послуги полягає перш за все в щоденній необхідності аналізу різних систем і їх компонентів. Як наслідок, існує цілий ряд видів тестування.
Види тестування за позитивністю сценаріїв
Позитивне тестування – це тестування із застосуванням сценаріїв, які відповідають нормальній (штатній, очікуваній) поведінці системи. З його допомогою ми можемо визначити, що система робить те, для чого і була створена. Наприклад, множення на калькуляторі цифр 3 і 5.
Негативним називають тестування, в рамках якого застосовуються сценарії, які відповідають позаштатній поведінці тестованої системи. Це можуть бути, наприклад, виняткові ситуації або невірні дані. На прикладі калькулятора, це множення числа 3 на грушу. Значення "груша" не є дійсним для калькулятора.
Перш за все негативне тестування направлено на перевірку стійкості системи до різних впливів, валідації невірних даних, обробки виняткових ситуацій. Сценарії позитивного тестування, в свою чергу, спрямовані на перевірку роботи системи з тими типами даних, для яких вона розроблялася.
Створення позитивних сценаріїв (тест-кейсів), як правило, передує створенню негативних тест-кейсів. Спочатку ми перевіряємо роботу системи, коли наш умовний користувач працює з системою "правильно", а потім приступаємо до перевірки відгуку системи на користувача, який допускає різні помилки (введення невірних даних, наприклад). І наша система повинна бути готова відповісти на невірний запит. Це і є мета негативного тестування.
| Позитивне тестування | Негативне тестування | |
| Опис | Перевірка наявності очікуваних функцій | Перевірка наявності непередбачуваних проблем |
| Мета | Виявлення успішних сценаріїв використання | Виявлення помилок, виключень і недоліків |
| Характеристики | Додаткові вимоги до функцій, властивостей та взаємодії | Негативні тестові сценарії та граничні умови |
| Тестові дані | Спеціально створені дані для перевірки очікуваних результатів | Дані, що відповідають негативним умовам |
| Очікуваний результат | Підтвердження, що програма працює, як очікувалося | Виявлення помилок, помилкових повідомлень та інших непередбачуваних проблем |
| Приклади | Може включати сценарії коректного введення даних та отримання очікуваних результатів | Негативне тестування може включати намагання ввести неправильні дані або викликати винятки |
Сьогодні немає точної та єдиної думки про співвідношення позитивного і негативного тестування.
Існує думка, згідно з якою позитивне тестування вважається більш важливим, ніж негативне.
Уявіть собі ситуацію, при якій наш калькулятор нестійкий до введення некоректних даних (йому складно множити на груші і віднімати апельсини з цілих чисел). Критично це? Ні. Адже користувачі скоро зрозуміють, що не варто виконувати деякі дії зі звичайним калькулятором чисел і не допускатимуть операцій з фруктами і числами одночасно. Але давайте тепер уявімо, що наш калькулятор вірно відповідає на спроби множення апельсинів на цифри, але невірно веде підрахунок математичних операцій з числами, тобто не виконує свою основну функцію (бізнес-завдання).
Тому і вважається, що позитивне тестування важливіше негативного. Окремі помилки при введенні невірних даних рідкісні, а невиконання основної бізнес-функції помітно відразу.
Але не варто думати, що негативні тести нам не потрібні взагалі. Саме вони сприяють появі великої кількості заведених дефектів.
Також існує думка про те, що відділення негативного тестування від позитивного неприпустимо. Адже, по-перше, проведення двох тестів окремо займе більше часу, по-друге, існує ризик пожертвувати негативним тестуванням при нестачі часу і, по-третє, це може суперечити мисленню тестувальника.
Тепер давайте відкладемо наш віртуальний калькулятор цифр і фруктів, і розглянемо кілька реальних прикладів тестових кейсів.
Класичний приклад логіна/логаута:
- реєстрація: введення логіна і пароля, з логіном без пароля, через соціальні мережі;
- авторизація: введення логіна і пароля, вхід через соціальні мережі;
- відновлення паролю.
Позитивні сценарії:
- реєстрація через пару логін/пароль, через логін, через соціальні мережі;
- реєстрація при заповненні обов'язкових полів;
- реєстрація при заповненні всіх полів;
- перевірка можливості авторизації після реєстрації;
- реєстрація на одному браузері і вхід на іншому;
- перевірка роботи функції відновлення пароля.
Негативні сценарії:
- повторна реєстрація (ім'я/пароль вже зайняті);
- реєстрація без заповнення обов'язкових полів (всі поля порожні);
- реєстрація з введенням даних в невірному форматі;
- авторизація з невірним логіном/паролем.
І ще один приклад створення простого контакту (є можливість перегляду, редагування і видалення):
Позитивні сценарії:
- доступні функції створення, редагування, перегляду і видалення контакту;
- доступна функція створення контакту при заповненні мінімальної кількості обов'язкових форм;
- доступна функція створення контакту при заповненні всієї форми;
- перегляд контакту доступний після створення і відповідає нормам ТЗ;
- зміни вступають в силу після збереження (відображаються оновлені дані);
- після видалення контакту більше немає.
Негативні сценарії:
- створення однакових контактів неможливо;
- створення контакту без заповнення обов'язкових полів неможливо;
- і та ін.
Якщо у вас при створенні негативних тест-кейсів виникають проблеми, то можете спробувати популярні приклади:
- Внутрішні одинарні лапки в запитах SQL.У баз даних є проблема з визначенням лапок при введенні запиту. Тому потрібно переконатися в тому, що для полів, які приймають звичайний текст, введення лапок допустимо і приймається системою.
- Обов'язкові поля для введення даних.В основному поля, обов'язкові для введення даних, позначено символом "*", що говорить користувачеві про те, що ці поля необхідно обов'язково заповнити. Це і є першою перевіркою – переконатися, що всі обов'язкові поля відмічені. Друге – переконатися в тому, що відмічені поля дійсно визначаються системою як обов'язкові. В рамках даних перевірок потрібно переконатися, що такі поля дійсно не можна пропустити. Досить залишати такі поля порожніми при відправці форми і спостерігати за поведінкою системи. Якщо користувач отримує помилку про необхідність заповнення поля, то даний сценарій буде вважатися успішним. Відповідно, якщо форма відправляється навіть без заповнення обов'язкового поля, то даний сценарій неправильний і повинен бути занесений в багтрекінговую систему. Уявімо ситуацію, при якій користувач при реєстрації не вводить поштову адресу або призначене для користувача ім'я, і система все одно успішно реєструє даного користувача. Відповідно, такий користувач не зможе увійти в систему, так як раніше він не вводив дані, які обов'язково потрібні при авторизації. Зворотний бік даних перевірок – переконатися в тому, що опціональні поля не обов'язкові до заповнення і форма може бути відправлена без них.
- Типи даних в полях.При перевірці полів введення даних потрібно розуміти, що такі поля можуть відрізнятися тим, дані якого формату вони приймають. Наприклад, текстове поле має на увазі те, що воно приймає будь-який текст. Тут можна зробити кілька основних перевірок. По-перше, перевірити ліміт на введення символів. Часто розробники не виставляють ліміт на символи. Як результат, при введенні довгого імені, наприклад, такий текст буде неправильно відображатися в інших секціях додатки/сайту (виходити за межі блоку, перекривати інший текст і та ін.). Це дуже поширена проблема. По-друге, ми повинні розуміти призначення даного текстового поля. Різниця між полем нікнейму і іменем користувача істотна. Поле нікнейму може приймати будь-який набір символів, включаючи цифри і спеціальні символи. Поле ж імені повинне приймати тільки букви. Також в країнах Європи і США прийнято ім'я і прізвище об'єднувати під одним поняттям "Full name". Тому це поле повинно приймати мінімум два слова, розділені пропуском. Ще варто враховувати ринок, на який орієнтується продукт. Адже в тих же французькій та німецькій мовах в іменах використовуються додаткові символи (відомі як "умляути"). І поле введення повинно приймати ці символи. Для числових полів і полів вибору дати також працюють свої правила. Числове поле не повинно приймати інших знаків, крім чисел. Введена або обрана дата повинна відображатися в правильному форматі і та ін.
- Розмір поля.Як згадувалося вище, кожне поле введення повинно мати свій ліміт на введення символів. При введенні символів більше розміру поля вони не повинні виходити за його межі. Якщо є можливість змінювати розміри поля, то при зміні поле не повинно виходити за межі блоку, в якому воно розташоване.
- Числові граничні значення.Числові поля, в залежності від їх призначення, можуть мати обмеження по введенню чисел в допустимому діапазоні введення. Для того, щоб знати, які обмеження використовуються, необхідно ознайомитися зі специфікацією продукту. Якщо ж такої документації немає, то необхідно зробити перевірку на основну логіку поведінки числових полів. Наприклад, введення негативних чисел в основному не допускається. Наприклад, при оформленні замовлення можна додавати кількість товарів в кошик з негативним значенням. Якщо поле приймає значення, починаючи з певного числа, то введення числа менше цього значення не може прийматися.
- Числові обмеження.Відмінність цієї перевірки від попередньої полягає в тому, що тут ми перевіряємо поле введення на обмеження по введенню чисел. Наприклад, поле введення ваги приймає тризначне число. Відповідно, чотиризначне число поле вже не повинно приймати.
- Граничні значення дати.Є кілька основних перевірок при тестуванні поля введення дати. По-перше, це введення дати народження в день, який ще не наступив. По-друге, система приймає користувачів, яким виповнилося не менше, ніж 18 років. Відповідно, дата, яка менше 18 років від поточної дати, вважається не валідною.
- Валідність дати.Поле введення дати має приймати тільки числові значення в певному форматі. Введення текстових значень неприпустиме. Також неприпустима можливість вибору неіснуючої дати (високосний рік тощо)
- Веб сесії (тільки для веб додатків).В рамках цієї перевірки потрібно переконатися в тому, що певний функціонал доступний користувачеві тільки після його авторизації в системі. Тут потрібно перевіряти, що неавторизований користувач не має доступу до функціоналу, який доступний тільки авторизованому користувачеві.
На закінчення хочеться сказати, що вага позитивного і негативного тестування є досить великою, навіть в порівнянні з такими "китами" тестування як функціональне тестування або тестування взаємодії, а отже, ними не варто нехтувати.
