Техніки Тестування "З Досвіду"

Анлійську версію цієї статті опубліковано на EUROSTAR's Huddle as Experience-based Testing Strategies

 
На різних ресурсах з тестування програмного забезпечення часто згадують деякі загадкові “Experience-Based Test Techniques” (Засновані на досвіді техніки тестування). Для мене це завжди звучало як "от доростеш до наших літ, тоді й узнаєш". Але коли я сам став вчити тестуванню, то не міг нормально пояснити, що воно таке. Бо "досвіду" трохи важко навчити :-). Можна вигадати деякі практичні завдання, зроблені так, що студенти щось вивчають, але неможливо зробити так, щоб вони вивчили точно мій досвід.

Test Design Techniques by learnthebasicsofsoftwaretesting.blogspot.com

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

Хлопці (чи скоріше вже "Шановні Пани") з контекстно-керованої школи тестування ПЗ (http://context-driven-testing.com/?page_id=9) вирішили зібрати усі ці невизначені категорії  під відкритим терміном «контекст».

Я пам'ятаю пост (але не можу знайти посилання :-( ) у блозі когось із них, де намагались визначити, тестування - це як ремесло, чи більше як мистецтво.

Але навчаючи, я не можу навчити мистецтву.

Таким чином, мені подобається поетична думка, що справжнє -мистецтво- тестування є прекрасним, і неможливо для одного -художника- тестера повністю повторити шедеври інших.

Але, як учитель, я маю представити дисципліну тестування ПЗ, як ряд вправ, які можна повторити, щоб навчитись і стати кращим тестером.

Отже, нижче наведений список «типів багів», які я зустрічав у своїй роботі, з можливими способами їхнього виявлення, що також знаними як «тестові стратегії». Звичайно, цей список не є повним і ваші пропозиції щодо його розширення вітаються!


Користувацький інтерфейс

•     Перевіряйте всі назви / текст повідомлень
•     Взаємне розташування елементів
•     Перекриття динамічних елементів

UX

•     Складіть сценарії орієнтовані на кінцевих користувачів, що йдуть від початку до кінця
•     Зважайте на, можливо, зайві чи надлишкові дії протягом UX-сценаріїв
•     Ясна логіка для груповання елементів (можливі дуже суб'єктивні речі :-))
•     Час: чи є звичайні операціями досить швидкими?
•     Чи не є рухи мишкою занадто довгими та занадто точними?

Розрахунки у Таблицях з Даними

•     Щоб перевірити швидко, спробуйте провести багато обчислень, а потім порівняти підсумки (можливе накопичення помилки)
•     Зважайте на кількість знаків - для подібних розрахунків результат матиме таку ж кількістю цифр
•     Готуйте дані для тестування обсягом(volume testing), зважаючи на реалістичну варіативність: подивіться в реальні дані та виберіть найцікавіше - те що вибивається з середнього, але все ще вважається нормальним
•     Перевірте прийнятні/ неприйнятні типи чисел: як ваша система реагує на пробіл чи підкреслення всередині чисел? Чи є кома чи крапка роздільником дробів? Арифметика всередині полів?
•     Будуйте послідовності розрахунків (накопичення помилки)

Вхідні дані

•     Різні типи вхідних даних (нехай плагін для браузера BugMagnet вас надихає)
•     Валідація значень відбувається: в самому полі, на фокусуванні на полі, на зміні фокуса, на відправці даних, фронтенд / бекенд.
•     Стежте за всіма місцями, де введені дані згодом будуть показані або використані. Складіть повний список таких місць.

Ін'єкції

•     Це можна було б віднести до тестування безпеки, але часто такі баги навіть заважають користувачам ввести їхні правдиві дані.
•     JS (XSS):
•  I go plz<script>alert('JS is executed well!11')</script>
•     SQL:
•  Robert'); DROP TABLE Students;--
•  Щоб отримати помилку з SQL часто достатньо просто вставити ; або спробувати різні типи лапок ’'`   
•     Формат даних (HTML, XML, JSON):
•       <b><i><u>Hi there, </u></i></b><blink>Dear!</blink>
•       <i><b>Wrong tag order</i></b>
•       ><
•       '},

Витік пам'яті

•     Тестування обсягом даних(Data volume testing)
•     Випробування на виснаження (Soak testing)
•     Повторюйте деякі ресурсовитратні дії знову і знову, спостерігайте в системний монітор за збільшенням споживання ресурсів

Збереження/читання файлів

•     Перезапис існуючих файлів
•     Дуже часте збереження в файл
•     Спостерігайте за змінами змісту файлу під час його зміни програмою
•     Вручну міняйте зґенеровані файли (їх зазвичай називають "Не чіпай, там нічого не змінюють руками")

Інтеграції та API

•     Вимагайте незалежне тестове середовище
•     Заповнюйте всі поля (от всі-всі! Знайдіть можливі, необов’язкові поля, в тому числі в XML та JSON, та заповніть їх повністю)
•     Пронумеруйте значення у тестових полях або змініть їх по-своєму, щоб їх легко було впізнати у подальшій обробці
•     Використовуйте п́арне(pair-wise) заповнення полів(для початку)
•     Перевірте, як проходить кожна частина вихідних даних  через весь робочий процес, від одного кінця до іншого
•     Змініть формат, порядок, довжину і інші параметри у дозволених (незаборонених) межах

Взаємний вплив одночасних користувачів

•     Вводіть схожі/такі самі дані
•     Змінюйте ті ж записи
•     Відкривайте/ змінюйте ті ж файли
•     Переривайте/ Вмикайте ті ж потоки
•     Використовуйте ті ж ролі/ дозволи користувачів
•     Використовуйте різні клієнти одночасно (з-під одного облікового запису, або з декількох): настільний, мобільний, веб, API (різні рівні, якщо вони є), мобільний веб

Права доступу

•     Всі наявні в UI дії дозволені для ролі
•     Всі дії, які повинні бути дозволені, доступні в інтерфейсі для ролі
•     Недозволені дії не доступні для цієї ролі навіть за прямими посиланнями (або іншими непрямими способами, як API)
•     Набір «допустимих дій» може змінюватися під час робочого процесу. Перевірте на кожному кроці
•     Додайте/ видаліть дозвіл для активного користувача / ролі
•     Нещодавно додана функція узгоджена з політикою дозволів системи

Контроль процесу

•     Використовуйте «живі» або «схожі на живі» дані
•     Ще один крок. Ще трошечки (Просто ще один маленький клік...)
•     Закінчіть процес як би це зробив «реальний користувач»
•     Стежте за одиницями виміру по всій системі (не додавайте милі до кілометрів чи долари до відсотків)
•     Виконайте випадкову дію, яка не має вплинути на основний сценарій, у випадковий момент часу: до/під час/після «основних» кроків.