Первую версию сервиса принимают по заранее описанным пользовательским сценариям, состоянию данных и поведению при ошибках. Для управляемого запуска также проверяют доступы, наблюдение за сбоями и восстановление. Инженерные результаты фиксируют отдельно от договорного порядка приёмки.
Демонстрация разработчика полезна, но для проверки нужен самостоятельный прогон на согласованной версии. Заказчик должен знать, какие задачи он проверяет, какой результат ожидает и какие ограничения остаются после запуска.
Опишите границу первой версии
Составьте короткий перечень ролей и основных действий. Для сервиса обработки заявок это могут быть клиент, менеджер и администратор. Клиент создаёт обращение. Менеджер видит очередь и меняет статус. Администратор управляет доступом.
Затем зафиксируйте, какие операции пока выполняются вручную. Если уведомление менеджеру остаётся ручным, это ограничение нужно учитывать в сценарии. Если функция заявлена автоматической, проверяют фактическую доставку.
Удобный критерий готовности содержит исходные условия, действия и наблюдаемый результат. Фразы «работает быстро» и «ошибок нет» замените измеряемыми условиями для конкретной нагрузки и списка функций.
Приёмочный сценарий, который можно скопировать
Ниже условный пример для формы обращения. Имена, номера и данные тестовые.
| Поле проверки | Содержание |
|---|---|
| Версия | Зафиксированная сборка и конфигурация |
| Исходное состояние | Клиент А вошёл, активных заявок теста нет |
| Действие | Заполнил обязательные поля и отправил форму |
| Видимый результат | Получил номер и статус принятого обращения |
| Результат в системе | Менеджер видит одну запись с правильными данными |
| Повтор | Обновление страницы сохраняет результат, повтор доставки не создаёт дубль |
| Доступ | Клиент Б не получает сведения о заявке А |
| Доказательство | Номер записи, время, журнал и снимки интерфейса |
Проверьте весь путь одним сценарием. Успех интерфейса может скрывать отсутствие записи в базе. Правильная запись может скрывать ошибку уведомления. Эти результаты фиксируют раздельно.
Если сценарий зависит от внешней системы, укажите тестовый режим и способ подтверждения результата. «Запрос отправлен» доказывает попытку, завершение операции проверяют по ответу или состоянию принимающей системы.
Что происходит при ошибке
Для каждого основного пути выберите несколько отказов: отсутствует обязательное поле, внешний сервис недоступен, соединение обрывается, пользователь повторяет действие. Запишите ожидаемое поведение и судьбу данных.
Сервис должен объяснять, принят ли запрос, можно ли повторить его и как обратиться за помощью. Рекомендуем проверять неизвестный результат отдельно. Если внешнее действие могло завершиться, система сначала сверяет состояние по предусмотренному правилу.
Приёмка ошибки включает отсутствие лишнего действия: дублирования заявки, отправки чужому получателю, доступа к чужой записи. Критические ограничения задают заранее вместе с ответственным специалистом.
Безопасность проверяют по выбранному объёму
Попросите технического специалиста составить применимые проверки для входа, прав доступа, хранения секретов и обработки данных. OWASP ASVS предоставляет набор требований для проверки безопасности веб-приложений. OWASP ASVS.
Выбор отдельных требований и глубина проверки зависят от сервиса. Наличие списка не является доказательством выполненного аудита. В отчёте должны быть проверенная версия, способы проверки, результаты и открытые замечания.
Заказчик может самостоятельно пройти доступные проверки ролей, но глубокую техническую оценку выполняет специалист. Для важных ограничений полезен независимый проверяющий, который не принимал решение о реализации.
Как узнать, что сервис сломался
Наблюдение должно замечать проблему пользовательского сценария. Главная страница может открываться, когда заявки уже перестали доходить до менеджера.
Google SRE выделяет четыре сигнала: задержку, поток запросов, ошибки и насыщение ресурсов. Это исходная методика наблюдения, которую можно адаптировать к сервису. Google SRE: Monitoring Distributed Systems.
Для условного сервиса заявок рекомендуем дополнить технические показатели бизнес-проверкой: сколько обращений принято, сколько обработано и как давно ждёт старейшее. Назначьте получателя уведомления и порядок его действий.
Во время приёмки создайте контролируемую ошибку в тестовой среде. Проверьте, что сообщение дошло ответственному и по журналу можно найти затронутую операцию. Секреты и лишние клиентские сведения в уведомлении не нужны.
Восстановление проверяют запуском
Уточните, что входит в резервную копию: база, файлы, конфигурация и необходимые зависимости. Затем восстановите выбранную копию в отдельной среде и выполните основной сценарий.
AWS рекомендует периодически восстанавливать данные, проверять их доступность и сопоставлять результат с целями по времени восстановления и допустимой потере данных. AWS: проверка восстановления.
Для первой версии зафиксируйте фактическое время теста и перечень найденных пропусков. Восстановленная среда должна быть отделена от рабочих отправок и платежей. Копия, которая случайно посылает уведомления клиентам, создаёт дополнительную проблему.
Тест восстановления показывает результат в выбранных условиях. Возможность восстановиться при другом отказе зависит от состава копий, инфраструктуры и доступности людей.
Реестр замечаний и решение по запуску
Разделите замечания по последствиям. Критические блокируют согласованный сценарий или создают неприемлемый доступ. Существенные требуют исправления или явно принятого ограничения. Небольшие визуальные дефекты можно включить в дальнейший план, если они не мешают работе.
У каждого пункта нужны описание, шаги воспроизведения, версия, ответственный и способ повторной проверки. После исправления проверяют исходную ошибку и связанные сценарии. Сохраняйте связь замечания с проверенным результатом. Если итоговая сборка отличается от версии прогона, повторите затронутые проверки и зафиксируйте новую версию. Это позволяет понять, к какому состоянию сервиса относится решение о готовности.
Итоговый пакет приёмки включает перечень сценариев, результаты, список ограничений, доступы компании, инструкцию запуска и восстановления. Договорные документы и последствия подписания проверяют отдельно по условиям проекта. Технический протокол помогает обосновать решение о запуске и сохранить понятную исходную точку для следующих версий.
Источники
- OWASP ASVS: требования для технической проверки безопасности приложений.
- Google SRE Monitoring: основные сигналы наблюдения за системой.
- AWS Recovery Testing: проверка восстановления и целевых ограничений. Сценарий и порядок инженерной приёмки предложены редакцией.