Чому тестування це інвестиція, а не витрата
Багато власників бізнесу сприймають тестування як додаткову витрату, що подовжує проєкт і збільшує бюджет. Дані свідчать про інше: виправлення помилки, виявленої після впровадження, коштує до ста разів дорожче, ніж якщо знайти її на етапі проєктування чи розробки.
Скільки насправді коштує пропущене тестування
Розробники витрачають приблизно 20% часу на виправлення помилок. Це один день на тиждень, коли команда гасить пожежі замість того, щоб робити нові функції. Для компанії з кількома розробниками це десятки тисяч доларів на рік, витрачених на ремонт.
Але час програмістів це лише частина рахунку. Кожна помилка в CRM чи ERP-системі означає роздратованих працівників, втрачені продажі, хибні звіти, на яких керівництво ухвалює рішення, а в гіршому разі ще й втрату довіри клієнтів.
Віддача від професійного QA
За даними дослідження Forrester, віддача від інвестицій у якість користувацького досвіду сягає 9900%. Це не помилка: кожен долар, вкладений в UX і тестування зручності, може повернутися сумою до 99 доларів. Серед компаній, що впровадили автоматизацію тестування, понад 60% повідомляють про позитивну віддачу протягом першого року, а 24% бачать її майже одразу.
Для нас тестування є частиною розробки, а не додатком. Кожна система проходить дворівневу перевірку: ручне UX-тестування, яке проводять наші тестувальники, та автоматичні тести, що покривають код.
Перший рівень: ручне UX-тестування очима користувача
Машина помічає не все. Чи там стоїть кнопка «Зберегти», де її шукає людина? Чи зрозуміє бухгалтер, який не знає технічної мови, повідомлення про помилку? Чи логічна з погляду бізнесу послідовність кроків в оформленні замовлення? На такі запитання відповідають наші тестувальники.
У чому полягає ручне UX-тестування
Кваліфікований тестувальник стає на місце кінцевого користувача й проходить усіма шляхами в системі. Перевірити, що щось працює технічно, замало. Важливо, чи добре це працює для людини, яка користуватиметься системою вісім годин на день, п'ять днів на тиждень.
Тестувальник перевіряє навігацію: користувач завжди має розуміти, де він і як дістатися потрібної функції. Дивиться, чи логічно побудовані форми й чи зрозумілі підписи полів без інструкцій. Читає повідомлення про помилки, адже кожне має пояснювати, що пішло не так і як це виправити. Стежить і за єдністю інтерфейсу, щоб схожі дії в усій системі виглядали й працювали однаково.
Сценарії, побудовані на реальних процесах
Бутикову агенцію від фабрики програмного забезпечення відрізняє те, наскільки добре вона знає процеси клієнта. Перш ніж тестувальник відкриє систему, він отримує повну документацію процесів, які система має підтримувати.
Візьмімо CRM для B2B-компанії. Тестувальник не обмежується перевіркою, чи можна додати контакт. Він проходить увесь шлях: імпорт лідів із маркетингової кампанії, призначення менеджера з продажу, реєстрація подальших взаємодій, перетворення на клієнта і передача до відділу обслуговування. На кожному кроці він оцінює, чи відповідає система тому, як працює менеджер із продажу, чи змушує його до довгих обхідних шляхів.
Звітність і робота з розробниками
Кожне зауваження потрапляє в систему обліку помилок із точним описом: що зроблено, який результат очікували і що вийшло насправді. Додаємо скріншоти чи відеозаписи, щоб нікому не доводилося вгадувати, що мав на увазі тестувальник. Розробник отримує все потрібне для швидкого виправлення.
Ми регулярно зустрічаємося з розробниками й розбираємо проблеми, що повторюються. Якщо в багатьох місцях повідомлення про помилки надто технічні, разом домовляємося про єдиний стандарт зрозумілих користувачеві текстів. Так подібні вади не повертаються.
Другий рівень: автоматичні тести та покриття коду
За кожною кнопкою й формою стоять тисячі рядків коду. Вони мають працювати правильно зараз і після змін, які внесуть через місяць, пів року чи два роки. Цю стабільність забезпечують автоматичні тести.
Що таке покриття коду тестами
Покриття коду (code coverage) показує, який відсоток вихідного коду перевіряють автоматичні тести. Якщо покриття становить 80%, то чотири п'ятих шляхів виконання програми перевіряються після кожної зміни.
Автоматичні тести знаходять від 70 до 80% помилок, виявлених на етапі тестування. Вони виконуються миттєво: для тієї самої функціональності час автоматичного тесту може бути на 90% меншим, ніж ручного. Їх можна запускати сотні разів на день без додаткових витрат, тоді як кожен повтор ручного тесту забирає час людини.
Які тести ми пишемо
У проєктах ми використовуємо кілька рівнів, і кожен перевіряє своє.
Модульні тести (unit tests) перевіряють окремі функції: чи правильно рахується знижка, чи валідація ІПН відхиляє хибні дані, чи алгоритм розподілу лідів обирає потрібного менеджера. Це основа піраміди тестування, найшвидший і найчисленніший тип тестів.
Інтеграційні тести перевіряють взаємодію компонентів: чи правильно модуль замовлень «розмовляє» зі складським модулем, чи дані з веб-форми потрапляють до бази CRM в очікуваному форматі. Вони ловлять проблеми на стику частин, яких модульні тести не бачать.
End-to-end тести відтворюють повні сценарії використання, як це робить ручний тестувальник, але автоматично й повторювано. Браузер запускається сам, натискає кнопки, заповнює форми й перевіряє, чи з'явилося на екрані те, що має.
Безперервна інтеграція: тести після кожної зміни
Тести не чекають кінця проєкту. Кожна зміна в коді запускає повний набір тестів ще до того, як потрапить в основну гілку проєкту. Якщо якийсь тест не проходить, розробник одразу отримує повідомлення й виправляє помилку, поки вона не пішла далі.
Цю практику називають безперервною інтеграцією (CI). Вона скорочує час між появою помилки та її виявленням. Чим менший цей проміжок, тим дешевше виправлення: розробник ще пам'ятає, що змінював, і швидко знаходить причину.
Чому потрібні і ручні, і автоматичні тести
Можна спитати: якщо автоматичні тести швидші й дешевші в підтримці, навіщо ручні тестувальники? Або навпаки: якщо людина оцінить UX, чи варто писати автоматичні тести? Потрібні обидва види, бо кожен бачить те, чого не бачить інший.
Що ловить який вид тестів
Автоматичні тести найкраще перевіряють бізнес-логіку, розрахунки, правила валідації та інтеграції між системами. Вони безпомилково проходять тисячі комбінацій вхідних даних, які людина перевіряла б тижнями. Проте вони не оцінять, чи достатній контраст у кнопки, чи дружньо звучить повідомлення і чи інтуїтивно розташовані елементи.
Ручний тестувальник помітить, що форма вимагає забагато кліків, що термінологія в системі не збігається з мовою галузі клієнта або що якась функція захована надто глибоко в меню. Він знайде й граничні випадки, яких розробник не передбачив, бо тестувальник мислить як користувач, а не як автор системи.
Як підібрати пропорції
Галузеві дослідження показують рух до балансу: близько 73% організацій прагнуть пропорції 50:50 між ручними та автоматичними тестами або навіть нахиляють її в бік автоматизації. На практиці оптимальне співвідношення залежить від типу проєкту.
Для CRM та ERP-систем із розгалуженою бізнес-логікою ми рекомендуємо високе покриття автоматичними тестами (від 70-80%) і регулярне ручне UX-тестування перед кожним більшим релізом. Для застосунків із динамічним інтерфейсом і частими візуальними змінами співвідношення може бути рівнішим.
Процес QA крок за кроком
Покажемо це на прикладі однієї функції, від початку до кінця.
Розробка: тести пишуться разом із кодом
Розробник, який робить модуль звітів в ERP-системі, спершу пише автоматичний тест з очікуваною поведінкою: «для даних продажів за останній квартал звіт має містити суму доходів, кількість транзакцій і середню вартість замовлення». Лише потім пише код, який це виконує. Такий підхід називається test-driven development (TDD) і змушує продумати вимоги до початку кодування.
Закінчивши роботу, розробник локально запускає всі тести модуля звітів. Якщо вони проходять, код іде до репозиторію, де система CI запускає повний набір тестів проєкту. Будь-яка помилка блокує подальші кроки, і реагувати на неї треба одразу.
Ручне тестування: перевірка користувацького досвіду
Коли нова функція проходить автоматичні тести, вона потрапляє до ручного тестувальника. Він отримує сценарій на основі реального випадку: «як фінансовий директор, я хочу згенерувати квартальний звіт для правління, експортувати його в PDF і надіслати електронною поштою членам наглядової ради».
Тестувальник проходить сценарій і документує кожен крок. Перевіряє, чи читабельно відформатовані дані у звіті, чи мають графіки зрозумілі підписи осей і чи зберігає експорт у PDF макет для різних розмірів паперу. Дивиться й на дрібниці: чи легко знайти кнопку експорту, чи отримує користувач підтвердження завершення операції і чи з'являється індикатор прогресу для великих масивів даних.
Виправлення та повторна перевірка
Зауваження тестувальника потрапляють у систему тікетів із пріоритетами. Критичні баги (система не генерує звіт) блокують реліз. Середні (некоректний формат дати) треба виправити до впровадження. Пропозиції щодо покращень (додати клавіатурне скорочення) йдуть у беклог і повертаються в наступних ітераціях.
Після виправлень тестувальник робить ретести: підтверджує, що проблеми зникли і що виправлення не принесло нових дефектів. Впровадження починається лише після успішного завершення цього циклу.
Що ви отримуєте від агенції з процесом QA
Обираючи виконавця, дивляться на ціну й портфоліо, але цього мало. Те, як компанія ставиться до якості, впливає на вашу співпрацю з нею і на довгострокову цінність вкладених грошей.
Менше несподіванок після впровадження
Система, що пройшла два рівні тестування, потрапляє до користувачів готовою до роботи. Жодне тестування не гарантує повної відсутності помилок, але зменшує їхню кількість і серйозність до рівня, який не заважає щоденній роботі.
Швидші зміни надалі
Солідне покриття тестами дає впевненість під час змін. Коли за пів року ви захочете додати модуль або підключити іншу програму, розробникам не доведеться боятися «зламати те, що працювало». Тести самі перевірять, чи наявні функції й далі працюють.
Документація, яка не застаріває
Добре написані тести ще й описують, як поводиться система. Новий розробник може прочитати їх, щоб зрозуміти бізнес-правила й очікувану поведінку кожного модуля. Для багаторічної підтримки та розвитку системи це дуже корисно.
Якість будують свідомо
Тестування не гальмує впровадження, а робить його результат довговічним. Ручне UX-тестування разом з автоматичним покриттям коду дає систему, яка працює правильно і відповідає тому, як люди справді в ній працюють.
Бутикова агенція може приділити кожному проєкту більше уваги, ніж великі фабрики програмного забезпечення. Наші тестувальники вивчають специфіку вашої галузі й процесів. Розробники пишуть тести з думкою про підтримку системи роками. Результат: програмне забезпечення, яке служить компанії довго, а не породжує нові проблеми.
Якщо ви плануєте індивідуальну CRM, ERP-систему чи автоматизацію бізнес-процесів, напишіть нам. Ми розглянемо ваші потреби й запропонуємо рішення, яке пройде ретельне тестування, перш ніж потрапить до ваших працівників. Перша консультація безкоштовна.
