Приймання не зводиться до фінального погляду на продукт. Це звірка з тим, що було зафіксовано на етапі технічного завдання. Без такої звірки «готово» означає «у нас закінчилися сили», а не «зроблено».
Тестування застосунку перед запуском потрібне не розробникові, а власникові бізнесу. Саме він дізнається про пропущену помилку останнім: від клієнта, який не зміг оплатити, від менеджера, який побачив чужі дані, або від сервера, що не піднявся після перезавантаження. Етап 10 закриває ці ризики до того, як продукт зустрінеться з реальними користувачами та грошима.
Що перевіряється
- Тестування та виправлення інтерфейсів.
- Тестування та виправлення сценаріїв за ТЗ.
- Тестування та виправлення логіки інтеграцій.
- Тестування та виправлення процесів розгортання.
За кожним пунктом стоїть конкретна робота, а не загальне «подивилися, начебто працює».
Інтерфейси
Екрани проходять на тих пристроях і в тих браузерах, які були погоджені у вимогах. Перевіряються форми, валідації, порожні та помилкові стани, поведінка на телефоні. Окремо дивимося, що кожна роль бачить саме свої екрани й кнопки.
Сценарії за ТЗ
Кожен сценарій із технічного завдання проходимо від початку до кінця так, як його пройде жива людина: реєстрація, замовлення, оплата, скасування, повернення, зміна статусу. Сценарій або виконується за описом, або йде на виправлення. Спірні місця вирішуються за текстом ТЗ, а не за памʼяттю учасників.
Логіка інтеграцій
Платіжні системи, CRM, карти й зовнішні API перевіряються не лише на успішну відповідь. Важливіше, що відбувається під час відмови: чужа система не відповіла, повернула помилку, надіслала одне сповіщення двічі. Саме в цих місцях зазвичай губляться гроші та заявки.
Розгортання теж перевіряється
Четвертий пункт зазвичай дивує, але саме він відрізняє зданий проєкт від переданого. Продукт, який неможливо розгорнути заново без автора, Ви не отримали: Ви орендували його разом із людиною.
Тому під час приймання перевіряємо, що система піднімається з нуля за описаною процедурою: контейнери, налаштування сервера, SSL-сертифікати, фонові процеси та CI/CD з етапу деплою та інфраструктури. Якщо розгортання тримається на ручних кроках, які знає одна людина, це дефект, а не особливість.
Що Ви отримуєте на виході
- Продукт, звірений із ТЗ за кожним сценарієм, з виправленими дефектами.
- Перевірену процедуру розгортання, яку може повторити інша команда.
- Демонстрацію результату етапу, зазвичай у форматі відеопрезентації.
- Закриття етапу за умовами приймання, які погоджені в договорі заздалегідь, а не вигадані в останній день.
Скільки коштує тестування та передача
У стратегії розробки етап 10 коштує від $800 до $4700. Ціна фіксується до початку етапу, тому бюджет не зростає під час перевірки.
Місце в діапазоні визначає обсяг того, що треба перевірити: скільки в продукті інтерфейсів і ролей, скільки сценаріїв описано в ТЗ, скільки зовнішніх систем підключено й наскільки складний контур розгортання. Невеликий сервіс з однією роллю та однією оплатою ближчий до нижньої межі, корпоративна система з кількома інтеграціями ближча до верхньої. Точну суму ми називаємо після консультації, коли бачимо ТЗ і склад інтеграцій.
Якщо продукт робила інша команда й документації мало, починати варто не з приймання, а з аудиту наявної системи. Він коштує $800 за текстовий звіт або $2400 разом із раннім прототипом потрібної доробки.
Що ламається, якщо заощадити на прийманні
- Інтерфейси. Помилки знаходять клієнти, і частина з них просто йде, не написавши в підтримку.
- Сценарії. Рідкісні гілки (скасування, повернення, повторна оплата) вперше виконуються на живих грошах.
- Інтеграції. Збій на боці партнера перетворюється на втрачені замовлення, і ніхто не може сказати, де вони зникли.
- Розгортання. Перший же переїзд сервера чи відхід розробника зупиняє продукт на дні.
Кожна з цих поломок після запуску коштує дорожче, ніж її перевірка до запуску: до ціни виправлення додаються втрачені клієнти й час керівника.
Приклад із практики
У застосунку Goal Decomposer перевірку вбудовано в сам проєкт. Є швидкий смоук-тест сервера й наскрізний прогін інтерфейсу в headless Chrome: модель ШІ підміняється заглушкою, а сценарій проходить від введеної мети до готового плану й відновлення плану після перезавантаження сторінки. Такий прогін будь-який розробник повторює однією командою.
У системі для мережі медичних центрів із дванадцятьма ролями єдине джерело правди про те, що бачить кожна роль, закрите автотестом. Перелік екранів ролі перевіряється машинно, тому доступи не «розʼїжджаються» під час доробок. Це добрий приклад того, як частина приймання з часом переходить в автоматизацію тестування.
Що відбувається після передачі
Ми безкоштовно ведемо щоденну технічну підтримку після передання проєкту: збій у проєкті усуваємо ми, і він не тарифікується. Це записано в договорі, і серед конкурентів ми такого рядка не зустрічали.
Далі продукт розвивається за напрямами корпоративного блоку: від безпеки й автоматизації тестування до оптимізації під пошук. Коли користувачів стає більше, першими зазвичай підключають сповіщення та журнал дій.
Куди далі
Попередній крок: деплой та інфраструктура. Усю карту етапів зібрано в стратегії розробки застосунку.
Якщо продукт готується до запуску або вже працює, але Ви не впевнені, що його можна передати іншій команді, запишіться на безкоштовну консультацію з архітектором. Розберемо, що й як перевіряти, а після консультації надішлемо розрахунок ціни та строків за етапами.
