1️⃣Основні техніки тест-дизайну
Еквівалентний поділ (Equivalence Partitioning - EP)
Метод еквівалентного поділу дозволяє мінімізувати число тестів, не створюючи сценарій для кожного можливого значення, а вибравши лише одне значення з цілого класу і прийнявши за аксіому, що для всіх значень цієї групи результат буде аналогічним.
Наприклад, ми тестуємо функціональність гри, що дозволяє купувати за реальну валюту обладнання для машин. Вартість обладнання залежатиме від рівня гравця у грі. Тобто, чим більший рівень гравця, тим дорожче йому обійдеться обладнання. Уявімо, що у нас є чотири групи рівнів: менше 15, від 15 до 25, від 25 до 60 і більше 60. При цьому максимальний рівень якого може досягти гравець = 99.
QA-фахівцеві не потрібно писати 99 тестів для кожного діапазону, вистачить п'яти: по одному для кожної групи рівнів (скажімо, 10, 18, 35 та 75 рівень) та один для випадку, який перевірить, чи система не продовжує давати рівні гравцеві, якщо він досяг 99 рівня. Так, останній тест на практиці нездійсненний, та все ж не слід забувати про цю перевірку.
Аналіз граничних значень (Boundary Value Analysis - BVA)
Якщо взяти приклад вище, як значення для позитивного тестування виберемо мінімальну і максимальну межі (1 і 99 рівні), і значення більше і менше меж (0 і 100). Тобто, нам потрібно перевірити правильність даних на граничних межах: наприклад для 1 групи 1-15 рівень, нам потрібно перевірити, що рівень гравця не починається з 0, перевірити, що рівень починається з 1 рівня і вартість обладнання буде N гривень, далі що на 14 рівні теж буде N гривень, на 15 N гривень і що на рівні 16 гравець уже має заплатити M гривень. Аналіз граничних значень може бути застосований до полів, записів, файлів та інших параметрів, що мають обмеження. Щоб переконатися в правильності поведінки програми при різних вхідних даних, в ідеалі слід протестувати всі можливі значення кожного елемента цих даних.
Щоб зменшити кількість значень, що тестуються, проводиться:
2. Тестування одного будь-якого значення з кожного класу
1. Розбиття множини всіх значень вхідної змінної на підмножини (класи еквівалентності)
Якщо тест проходить успішно для одного значення класу еквівалентності, він повинен проходити успішно для всіх інших. І навпаки, якщо тест не проходить для одного значення, він не повинен проходити для решти. Таким чином, метод класів еквівалентності можна поділити на три етапи:
Тестування дозволених значень
Тестування граничних значень
Тестування заборонених значень.
Причина/Наслідки (Cause/Effect - CE).
Це введення комбінацій умов (причин) для отримання відповіді від системи (слідство). Наприклад, ви перевіряєте можливість додавати друга в гру, використовуючи окреме вікно. Для цього вам необхідно зробити кілька дій в вікні, клікнути на кнопку “Запросити”, відправити реферальне посилання через один з месенджерів - це “Причина”. Після виконання цих маніпуляцій і після того, як друг встановить гру він з'явиться у нас у вікні друзів — це «Наслідки».
Ще декілька прикладів:
Коли ми натиснемо на кнопку Банк - це “Причина”, в результаті натискання відкриється вікно з пропозиціями покупки - це “Наслідок”.
Коли ми натиснемо на кнопку Отримати в ревард вікні - це “Причина”, в результаті отримаємо реварди у вигляді монет та еліксиру - це “Наслідки”.
Для покриття тестами таких випадків слід задавати запитання: “Що я можу зробити (Причина)? Що я в результаті отримаю (Наслідки)?
Передбачення помилки (Error Guessing — EG)
Це коли тестувальник використовує свої знання системи та здатність до інтерпретації специфікації щодо того, щоб «передбачити» за яких вхідних умов система може видати помилку. Наприклад, специфікація каже: "користувач повинен ввести ім’я". Тестувальник буде думати: «Що, якщо я не введу ім'я?», «Що, якщо я введу ім'я, яке містить спеціальні символи?", “Що, якщо я введу ім'я, яке містить цілі цифри?, “Що якщо я введу ім'я, яке містить дробові цифри?” і так далі. Це і є передбачення помилки.
Вичерпне тестування (Exhaustive Testing - ET).
Використовується вкрай в поодиноких випадках. У межах цієї техніки ви повинні перевірити всі можливі комбінації вхідних значень, і в результаті це має знайти всі проблеми. Насправді застосування цього методу неможливе через велику кількість вхідних значень. Його можна і варто застосувати, коли вхідних даних невелика кількість. Наприклад, в нас є гра, яка містить івенти для різних вікових категорій, скажімо менше 16 років та більше 16 років. Коли ми запускаємо івент вперше, гра просить вибрати до якої вікової категорії ви відноситесь. В такому разі нам потрібно перевірити, який івент підтягується, якщо нам 16 і менше років, а який коли нам більше 16 років + не забуваємо протестувати граничні значення, тобто чи підтягується івент, якщо ввести 0 років, 1 рік, який івент підтягується, якщо ввести 15, 16, 17 років.
Exploratory тестування (дослідницьке тестування)
Exploratory тестування (дослідницьке тестування) - це методика тестування, при якій тестувальник виконує тестування без попереднього детального планування чи наперед заданої послідовності дій. Замість цього, тестувальник досліджує, вивчає та тестує гру одночасно, виявляючи проблеми та помилки в процесі.
Основна ідея Exploratory тестування полягає в тому, щоб дати тестувальнику велику волю дій та можливість використовувати свій досвід, інтуїцію та критичне мислення під час тестування. Тестувальник активно досліджує гру, виконуючи тестові сценарії, перевірки, введення даних, спостерігаючи результати та аналізуючи поведінку системи.
Основні принципи Exploratory тестування:
Самостійність: Тестувальник має велику відповідальність та самостійність у процесі тестування. Він вирішує, які тести виконувати, які аспекти перевірити та які дії виконати.
Природна послідовність: Тестування проводиться за природною послідовністю вивчення програми та її функціональності. Тестувальник досліджує та перевіряє різні аспекти гри в залежності від поточної ситуації та результатів попередніх тестів.
Контекстне тестування: Тестувальник зосереджений на тестуванні програми в конкретному контексті, враховуючи вимоги, користувачів, цілі тестування та потенційні ризики.
Постійний цикл вивчення та аналізу: Тестувальник постійно навчається.
Складання чек-листа: Тестувальник складає чек-лист, в якому вказує критерії, вимоги, функціональні аспекти або характеристики, які потрібно перевірити під час тестування.
Виконання тестів: Тестувальник проймає по кожному пункту чек-листа та виконує відповідні тестові сценарії або перевірки. Він відзначає результати тестування для кожного пункту чек-листа.
Відстеження результатів: Результати тестування записуються в чек-листі. Вказується, чи пройшов кожен пункт успішно, чи виявлені проблеми або помилки. Це допомагає відстежувати прогрес тестування та оцінювати стан гри, що розробляється.
Аналіз і виправлення помилок: Якщо під час тестування виявлені проблеми або помилки, вони фіксуються та передаються розробникам
Checklist-Based тестування (тестування на основі чек-листів)
Checklist-Based тестування (тестування на основі чек-листів) - це методика тестування, яка використовує попередньо складені чек-листи для перевірки функціональності, властивостей або характеристик гри. Чек-лист - це структурований список критеріїв, які необхідно перевірити або пунктів, які необхідно пройти для виконання тестування.
Основна ідея Checklist-Based тестування полягає в тому, щоб мати заздалегідь підготовлений чек-лист з розгорнутими пунктами, які потрібно перевірити. Цей чек-лист може бути створений на основі вимог до гри, документації, стандартів, кращих практик або досвіду тестувальників.
Процес Checklist-Based тестування включає наступні кроки:
Самостійність: Тестувальник має велику відповідальність та самостійність у процесі тестування. Він вирішує, які тести виконувати, які аспекти перевірити та які дії виконати.
Природна послідовність: Тестування проводиться за природною послідовністю вивчення програми та її функціональності. Тестувальник досліджує та перевіряє різні аспекти гри в залежності від поточної ситуації та результатів попередніх тестів.
Контекстне тестування: Тестувальник зосереджений на тестуванні програми в конкретному контексті, враховуючи вимоги, користувачів, цілі тестування та потенційні ризики.
Постійний цикл вивчення та аналізу: Тестувальник постійно навчається.
Аналіз і виправлення помилок: Якщо під час тестування виявлені проблеми або помилки, вони фіксуються та передаються розробникам
Last updated