У кожного проєкту рано чи пізно настає момент, який я подумки називаю «страхом пʼятниці». Треба випустити невелику зміну: виправити розрахунок знижки, додати поле у форму, оновити бібліотеку. Зміна крихітна, але ніхто не хоче натискати кнопку. Бо минулого разу така сама крихітна зміна зламала оформлення замовлення, і дізналися про це лише в понеділок від розлючених клієнтів. Команда починає випускати оновлення дедалі рідше, кожне стає дедалі більшим і страшнішим, і проєкт повільно перетворюється на крихку вазу, до якої бояться торкатися. Ліки від цієї хвороби давно відомі, і називаються вони автоматизоване тестування.
Чому ручне тестування перестає працювати
Поки система маленька, її можна перевірити руками. Відкрив, клацнув, подивився, працює. Але кожен новий модуль, кожна нова функція додає сценарії, і їхня кількість росте не лінійно, а значно швидше, бо функції починають впливати одна на одну. У якийсь момент повна ручна перевірка займає дні, і її перестають робити повністю. Перевіряють «те, що змінювали». А ламається, як правило, те, що не змінювали, але що було повʼязане зі зміненим невидимою ниточкою.
Є й людський бік. Тестувальник, який усоте перевіряє ту саму форму реєстрації, на сто перший раз пропустить помилку. Не тому, що він поганий фахівець, а тому, що людський мозок не створений для монотонного повторення. Машина створена. Вона перевірить форму реєстрації і втисячне так само уважно, як уперше, о третій ночі, без кави й без вихідних.
Тести як страховий поліс
Мені подобається порівнювати автотести зі страховкою. Поки нічого не сталося, здається, що це зайві витрати. Навіщо платити за тести, якщо система й так працює? Але страховку купують не для того дня, коли все добре. Автотести окуповуються тієї миті, коли розробник вносить зміну, і за пʼять хвилин система повідомляє йому: «Ось тут ти зламав розрахунок доставки для оптових клієнтів». Не за тиждень від клієнта, не за місяць у звіті про втрачені продажі, а за пʼять хвилин, коли виправити це коштує копійки.
Добрий набір тестів перетворює страх перед змінами на рутину. А рутина, на відміну від страху, не гальмує розвиток.
Саме тому команди з добрим покриттям тестами випускають оновлення кілька разів на день, а команди без нього раз на місяць, з нарадою й молитвою. Різниця не в сміливості, а у впевненості, яку дають тести.
Рівні автоматизації
Автотести бувають різні, і кожен рівень відповідає за своє. Я зазвичай пояснюю це на прикладі автомобіля.
- Модульні тести перевіряють окремі деталі: чи правильно рахується податок, чи коректно форматується дата, чи вірно працює функція знижки. Це як перевірити кожну свічку запалювання на стенді. Таких тестів багато, вони швидкі й дешеві.
- Інтеграційні тести перевіряють, як деталі працюють разом: модуль замовлень правильно передає дані складу, склад правильно резервує товар, оплата правильно змінює статус. Це перевірка двигуна в зборі.
- Наскрізні тести імітують дії реального користувача в браузері: зайшов на сайт, знайшов товар, поклав у кошик, оплатив, отримав лист. Це тест-драйв усієї машини. Вони повільні й примхливі, тому їх небагато, але вони ловлять те, чого не видно на рівні деталей.
Поширена помилка: починати одразу з наскрізних тестів, бо вони наочніші. За кілька місяців їх стає сотні, вони йдуть по годині й ламаються від будь-якої зміни кнопки. Правильна пропорція схожа на піраміду: широка основа швидких модульних тестів, середній шар інтеграційних і вузька верхівка наскрізних для найважливіших сценаріїв.
Чого тести не замінять
Автотести перевіряють те, що Ви їм сказали перевіряти. Вони не скажуть, що інтерфейс незручний, що текст на кнопці вводить в оману, що новий сценарій узагалі не потрібен користувачам. Для цього, як і раніше, потрібна людина, яка дивиться на систему очима клієнта. Добра стратегія якості поєднує машину для повторюваних перевірок і людину для дослідницького тестування, де треба думати, сумніватися й пробувати дивне.
І ще один момент: тести це теж код, і його теж треба підтримувати. Тести, які ніхто не оновлює, за пів року починають падати без причини, команда звикає їх ігнорувати, і страховка перетворюється на папірець. Тому тести мають бути частиною процесу розробки, а не окремим проєктом, який зробили один раз.
З чого почати
Якщо у Вашому проєкті немає автотестів, не намагайтеся покрити все одразу. Випишіть три-пʼять сценаріїв, поломка яких коштує найдорожче: оформлення замовлення, оплата, розрахунок ціни, вхід у систему. Автоматизуйте перевірку саме їх. Підключіть запуск тестів до кожної зміни коду, щоб жодне оновлення не йшло на сервер без перевірки. Це вже зніме більшу частину страху пʼятниці.
У Systems тести входять у наші проєкти як обовʼязкова частина, а не як опція «якщо лишиться бюджет». Коли система генерується через Fractal за описом, типовий код однорідний, і перевіряти його значно простіше, ніж зоопарк ручних рішень. А сьогодні ШІ-агенти ще й сильно здешевили написання тестів, тож відмовка «на тести немає часу» звучить дедалі менш переконливо. Чи можна автоматизувати тестування? Можна й треба. Інакше автоматизується лише одне: страх.
