Помилку, яку тестувальник знайшов до релізу, часто виправляє один розробник за кілька годин. Та сама помилка на робочому сайті чи в застосунку коштує втрачених замовлень, листів у підтримку й термінової роботи, яка зупиняє все заплановане. Тестування до релізу — не перестраховка, а найдешевший спосіб тримати продукт у робочому стані.
Коротко
- Що пізніше знайдено помилку, то більше коду, людей і часу потребує її виправлення.
- Після релізу до прямих витрат додаються втрачені продажі, навантаження на підтримку, низькі оцінки в магазинах застосунків і шкода для репутації.
- Якість закладають у процес заздалегідь: критерії приймання, тест-кейси й автоматичні тести в конвеєрі релізу.
Чому помилка дорожчає з кожним етапом
Кожен етап проєкту спирається на попередній. Неточність у вимогах переходить у дизайн, дизайн — у код, а поверх цього коду пишуть інший. Що довше помилка живе в проєкті, то більше роботи на ній збудовано і то більше доводиться переробляти.
Ось як змінюється ціна виправлення однієї й тієї самої неточності, наприклад неправильного правила розрахунку знижки:
- У вимогах — виправити одне речення в документі.
- У дизайні — перемалювати кілька екранів і погодити їх знову.
- У розробці — переписати код і все, що вже встигли на ньому збудувати.
- На тестуванні — відтворити помилку, виправити, перевірити знову й переконатися, що поруч нічого не зламалося.
- Після релізу — усе перелічене, а ще знайти причину на робочому сервері, виправити дані реальних клієнтів і терміново випустити оновлення.
Є й людський чинник. Під час розробки програміст памʼятає контекст і виправляє помилку швидко. Через місяць він уже працює над іншим, і йому потрібен час, щоб просто розібратися у власному коді.
Приховані витрати після релізу
Пряма вартість виправлення — лише видима частина. Якщо зламалися кошик чи форма заявки, бізнес втрачає гроші щогодини, доки помилку не помітять, а помічають її часто не одразу.
Далі зростає навантаження на підтримку: листи, дзвінки, повідомлення в соцмережах. Кожне звернення забирає час, а дехто з незадоволених клієнтів не пише взагалі — просто більше не повертається.
Для мобільних застосунків ціна ще вища. Виправлення має пройти перевірку в App Store чи Google Play, а користувачі — оновити застосунок, тож версія з помилкою ще якийсь час лишається в людей на телефонах. Низькі оцінки й гнівні відгуки в магазині бачать усі, і вони впливають на рішення нових користувачів, чи встановлювати застосунок.
Нарешті, термінові виправлення зупиняють заплановану роботу. Команда відкладає нову функцію, щоб гасити пожежу, і реліз, на який ви розраховували, зсувається.
Які бувають перевірки
Тестування — це не одна дія, а набір різних перевірок, і кожна ловить свій тип помилок:
- Ручне дослідницьке тестування (exploratory testing). Тестувальник працює з продуктом як користувач, пробує нестандартні дії й шукає те, чого не передбачили в сценаріях.
- Регресійне тестування (regression testing). Уже готові функції перевіряють знову після кожної зміни, щоб нове не зламало старе.
- Модульні тести (unit tests). Автоматичні перевірки окремих частин коду, наприклад функції розрахунку ціни чи правил заповнення форми.
- Інтеграційні тести (integration tests). Перевіряють, як частини працюють разом: застосунок і база даних, сайт і платіжний сервіс.
- Наскрізні тести (end-to-end, E2E). Автоматично проходять увесь шлях користувача, від входу до оплати, у справжньому браузері чи застосунку.
- Тестування на реальних пристроях. Емулятор не покаже всього: слабкого процесора, нестабільної мережі, особливостей конкретного екрана.
Автоматичні тести швидко й дешево перевіряють відоме після кожної зміни. Людина знаходить те, що нікому не спало на думку автоматизувати. Потрібні обидва підходи.
Якість — це процес, а не фінальна перевірка
Забезпечення якості (quality assurance, QA) і тестування часто плутають. QA — це процес, який запобігає помилкам: як записують вимоги, як перевіряють код, що й коли тестують і що означає «готово». Тестування — частина цього процесу: конкретні перевірки, які знаходять помилки в уже створеному продукті.
Якість вбудовують у роботу з першого дня. Починають із критеріїв приймання (acceptance criteria) — конкретних умов, за яких функцію вважають готовою. Наприклад: «форма не надсилається без номера телефону й показує зрозуміле повідомлення про помилку». Їх записують до розробки, тож розробник, тестувальник і замовник однаково уявляють результат.
На основі критеріїв тестувальники складають тест-кейси (test cases) — покрокові сценарії з очікуваним результатом. Вони стають основою для регресійного тестування й не дають забути про щось важливе перед релізом.
Останній крок — автоматичні тести в конвеєрі релізу (CI/CD). Кожна зміна проходить перевірки автоматично, і якщо хоч одна з них не проходить, версія не потрапляє на робочий сайт. А кожна знайдена помилка отримує власний тест, щоб не повернутися непоміченою.
Чек-лист
- Записуйте критерії приймання для кожної функції до початку розробки.
- Складайте тест-кейси для ключових сценаріїв: реєстрації, оплати, заявки.
- Запускайте автоматичні тести в конвеєрі перед кожним релізом.
- Проводьте регресійне тестування після кожної значної зміни.
- Перевіряйте продукт на реальних пристроях і в різних браузерах.
- Додавайте тест на кожну знайдену помилку, щоб вона не повернулася.
Як ми це робимо в IANKO
Половина нашої команди з 10 фахівців працює над якістю: два QA-інженери, двоє тестувальників програмного забезпечення та інженер-тестувальник. Бізнес-аналітик формулює критерії приймання ще до розробки, тестувальники складають за ними тест-кейси й перевіряють продукт на реальних пристроях, а автоматичні тести ми вбудовуємо в конвеєр релізу з першого дня. Наша мета — знаходити помилки тоді, коли їх ще дешево виправити, а не тоді, коли про них пишуть ваші клієнти.
Підсумок
Помилку не можна скасувати, але її можна знайти тоді, коли вона ще дешева. Що раніше в проєкті зʼявляються критерії приймання, тест-кейси й автоматичні тести, то менше неприємних сюрпризів отримують ваші клієнти й ваш бюджет.