#testing #criticalthinking
Отже, вам треба тестувати, а значить, треба порівняти очікуваний результат з поточним. Зазвичай очікуваний результат прописаний в самому тесті (чи в чеклисті). Але коли ми створюємо тести самостійно - треба визначити цей очікуваний результат. Але як? Допоможуть оракули.
Оракул - це джерело, завдяки якому ми можемо визначити, чи коректна поведінка системи, чи ні.
Окей, я відкрию специфікацію та візьму очікуваний результат звідти!
Якби ж то було так просто!
Не такі прості, як здається
Дуже невелика кількість тестувальників сьогодні тестує прості й тривіальні проєкти на одну сторінку. Як правило, ми тестуємо великі й складні системи. Подекуди - розподілені.
В складних системах часто дуже складно однозначно визначити коректний очікуваний результат. Чому?
👉 Система може включати компоненти с AI / ML, які мають ймовірнісну природу (не дають одної правильної відповіді)
👉 Коректна відповідь може залежати від рішення більшості учасників, як-от в блокчейнах
👉 Система може мати остаточну узгодженість (eventual consistency) - тож зміни в базі даних можуть бути недоступні усім користувачам одразу (але, можливо, колись, у майбутньому будуть доступні).
Головна проблема оракулів - що не існує ідеального оракула. Треба їх комбінувати (разом із здоровим глуздом).
Що комбінувати?
Які бувають оракули?
🧪 Оракулів може й не бути. Тестування й розробка ведуться в стилі "виглядає нічо так, деплой!" Як результат - може бути купа схованих багів та проблем. А може й не бути.
🧪 Вимоги. Священна книга усіх тестувальників. Єдина й неповторна. Як там сказано - то є правда. Але справжні тестувальники знають, що вимоги можуть бути неповними, неправильними та й взагалі застарілими. В такому випадку не забуваємо задавати собі питання: "А ця специфікація взагалі коректна?"
🧪 Консистентність (узгодженість). Можна порівняти поточні результати із подібними в інших компонентах. Або ж замість вимог можна мати інваріанти - тобто опис властивостей системи, які повинні завжди виконуватися. Наприклад - "Баланс не може бути негативним" або "Користувач завжди має імʼя та прізвище".
🧪 Статистичні оракули. Базуються на статистиці вашого домену чи типу аплікації.
Окей, оракулів багато, вони ненадійні. Що робити?
Питання для підозрілого тестувальника
Коли ви визначаєте очікуваний результат, можна задати собі (й команді) наступні питання:
💡Що означає коректний результат в контексті вашої системи? Числовий, логічний, ймовірний?
💡На яких припущеннях побудований оракул? Наприклад - "за правильними даними йдіть у базу даних". Але якщо база даних - застаріла чи пошкоджена?
💡Які властивості системи чи атрибути якості непокриті оракулом? Може, ви забули про безпеку, перформанс, доступність?
💡Наскільки надійний сам оракул? Яка ймовірність? На чому будується ваша довіра?
Завжди памʼятайте: оракули ненадійні, ба більше - коректність оракулів може залежати від контексту.
Обґрунтовано сумніватися - це робота тестувальника.