Критерии приёмки, составленные после завершения разработки, критериями приёмки не являются. Это мнение, сформированное при взгляде на результат, и с его помощью невозможно ничего урегулировать.
Составление критериев до начала разработки
Критерии приёмки описывают, как вы определите, что функция готова, и должны существовать до её разработки по двум причинам: разработчику нужно знать, к какому результату он стремится, а клиенту нужен стандарт, на который не повлиял итоговый результат.
Рабочий критерий должен быть конкретным и проверяемым:
- Слабый: «Поиск должен работать хорошо».
- Рабочий: «Поиск по имени клиента возвращает совпадающие записи в течение двух секунд, находит частичные совпадения имён и не зависит от регистра».
Второй критерий может проверить любой человек. Первый невозможно проверить вообще.
Проведение UAT, выявляющего реальные проблемы
Приёмочное тестирование пользователями, проводимое в формате «посмотрите и скажите, что думаете», выявляет косметические проблемы и пропускает действительно важные. Структурированный подход значительно повышает его эффективность.
- Тестируйте рабочие процессы, а не отдельные экраны. Проходите полные задачи, которые реальный пользователь выполняет от начала до конца. Ошибки возникают на стыках между экранами, а не на самих экранах.
- Используйте реалистичные данные. Длинные имена, символы с диакритикой, пустые необязательные поля, большие количества, даты на границах месяцев и годов. Чистые тестовые данные скрывают большинство проблем обработки ввода.
- Преднамеренно проверяйте сценарии с ошибками. Отправьте форму дважды. Пять раз введите неверный пароль. Прервите соединение на середине процесса. Именно в таких сценариях оказываются реальные пользователи, но тестирование редко до них доходит.
- Пусть тестируют реальные пользователи. Человек, который будет ежедневно пользоваться системой, обнаружит проблемы, которые никогда не заметит спонсор проекта, поскольку именно этот человек знает, что на самом деле включает работа.
- Фиксируйте каждую найденную проблему в одном месте, указывая шаги для воспроизведения и прикладывая снимок экрана. Проблему, которую невозможно воспроизвести, невозможно исправить.
Дефект или изменение
Каждое UAT выявляет проблемы, которые не являются дефектами, и справедливая классификация помогает не допустить превращения процесса в противостояние.
Дефект — это различие между тем, о чём договорились, и тем, что было создано. Исправляется за счёт разработчика.
Изменение — это то, что работает согласно договорённостям, но больше не соответствует текущим пожеланиям клиента. Оценивается и рассчитывается отдельно.
Клиенты часто воспринимают второй случай как дефект, потому что программа делает не то, чего они ожидали. Честная реакция — не спорить о термине, а указать на согласованный критерий и затем спросить, стоит ли вносить изменение. Во многих случаях оказывается, что нет.
Критичность: что определяет блокировку запуска
Не каждый дефект необходимо исправлять до запуска, а отношение ко всем дефектам как к блокирующим без пользы откладывает запуск. Простая трёхуровневая классификация, согласованная заранее:
- Блокирующий — невозможно завершить ключевой рабочий процесс, данные потеряны или повреждены либо существует проблема безопасности. Должен быть исправлен до запуска.
- Серьёзный — функция работает неправильно, но существует обходной путь. Исправляется до запуска, если позволяет время; в противном случае назначается дата исправления.
- Незначительный — косметические проблемы, формулировки, небольшие несоответствия. Объединяется в релиз после запуска.
Согласование этой классификации до начала UAT превращает спор о срочности в общую оценку.
К чему обязывает обе стороны подписание приёмки
Подписание приёмки должно иметь конкретное значение: согласованные критерии выполнены, оставшиеся незначительные задачи перечислены с указанием дат, а платёж по соответствующему этапу становится доступен к выплате. С этого начинается гарантийный период, в течение которого выявленные позднее дефекты исправляются бесплатно.
Это не означает, что клиент больше никогда не сможет сообщить о проблеме, и договор с таким смыслом был бы необоснованным. Гарантийный период распространяется на дефекты, которые разумное UAT не позволило бы обнаружить.
Сколько времени предусмотреть
На UAT стабильно планируют недостаточно времени. Для небольшого проекта предусмотрите одну-две недели — этого достаточно, чтобы реальные пользователи протестировали систему в рамках своих фактических задач, найденные проблемы были исправлены, а тестирование проведено повторно.
Сокращение этого срока до двух дней приводит к формальному подписанию приёмки, которое ничего не значит, а проблемы вместо этого проявляются на первой неделе эксплуатации, когда их устранение обходится дороже и они гораздо заметнее.
Услуги Manboo по теме
- Разработка приложений на Flutter для MVP под iOS и Android.
- Разработка бизнес-программного обеспечения для CRM, систем бронирования, учёта запасов и управления рабочими процессами.
- Разработка административных панелей для операционных дашбордов и управления серверной частью.
- Интеграция AI API, когда ваш продукт готов к интеллектуальному поиску, чату или автоматизации.
- Запросить анализ объёма работ и оценку проекта, когда вы готовы планировать первую версию.