😱 Як ми пропускаємо баги через наші припущення

#testing #criticalthinking

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

🤔 Що таке припущення та нащо їх аналізувати?

Припущення - це неперевірене переконання, що впливає на те, як ви тестуєте. Аналіз припущень - це процес визначення, тестування та поставлення під сумнів всього, від чого система може залежати - явно чи неявно.

Кожна система, кожен продукт побудовані на купі припущень - про дані, середовище, час, користувачів, інші системи. У момент, коли припущення порушується, з’являються ті самі помилки й баги.

Припущення небезпечні, бо вони часто неявні, невидимі й перебувають поза зоною специфікацій. Ваше завдання при роботі із ними - перетворити твердження “Ця фіча працює” у щось, типу “Це працює тоді й тільки тоді, коли ось такі припущення виконуються”. У голові розробника, який пише код, вирує багато питань. Одне з них: “Ця функція повинна завжди повертати таке значення”. Тестувальник же повинен починати з питання: “А що, якщо … не завжди?”

📔 Які бувають припущення

• Припущення щодо даних. У роботі часто можна почути: “Вхідні дані завжди будуть типу Х чи формату У”. У реальності ж дані можуть бути порожніми (NULL, порожній масив) чи навіть неочікуваного типу.

• Припущення щодо середовища. Продукт не працює у вакуумі. Саме тому ніколи не можна сказати, що середовище буде “нормальним”. Мережа завжди може бути нестабільною; пакети та підключення можуть втрачатися; трапляються збої. Тож потрібно тестувати поведінку системи в таких умовах.

• Припущення щодо часу та порядку. “За івентом покупки завжди прилітає івент оплати”. В реальності події можуть приходити одночасно, або в зовсім іншому порядку. Системи працюють асинхронно. Деякі функції потребують часу для виконання. Що тестувати? Паралельні івенти, затримки у отриманні, повторні спроби обробки.

• Припущення щодо інших систем. Інші системи поза зоною нашого контролю. Вони можуть відповідати частково або ж зовсім не відповідати. Вони можуть змінювати формати та версії. Треба бути до цього готовими (та, можливо, додавати контрактні тести)

• Припущення щодо поведінки користувачів. Користувачі не завжди поводяться логічно. Користувачі можуть робити речі навмисно. Тож треба тестувати неочікувані сценарії та безпеку

• Припущення щодо масштабування. У реальності сплески в навантаженні можуть траплятися не лише на свята. Вихід нових фіч, голосування на Євробачення, збір лимонів - все це вимагає тестування перформансу вашого продукту.

• Припущення щодо ШІ. Ми припускаємо, що ШІ завжди буде працювати правильно, деградації якості відповідей не виникне ніколи. Але в реальності - нові версії LLM виходять майже кожного дня. А те, як вони будуть працювати саме із вашими даними - окреме велике питання. Можливо краще, а можливо - навпаки.

🛠 Як працювати із припущеннями

Як тестувати припущення? Знайдіть припущення та сформулюйте його. Далі - спробуйте порушити припущення. Додайте тестів, які перевірять поведінку системи при такому порушенні.

Можна застосувати такі техніки:

• Storming. Що завжди має бути дійсним? Що ми усвідомлено НЕ перевіряємо? Що ми сприймаємо як належне?
• “What If”. (Що якщо). Що якщо цей компонент не буде доступний? Що якщо респонс прийде пустий? Що якщо база буде відповідати повільно?
• Замість “Як це працює” замисліться про те “Як це може зламатись”

💡 Завжди памʼятайте

• Всі системи можуть зламатись, коли припущення порушені
• Будь-який happy path сценарій - сповнений купи припущень. Вам тільки треба їх знайти
• Тестовання edge cases - це і є перевірка припущень