Для небольшой доработки не нужен бесконечный перечень испытаний. Нужна граница этапа и несколько наблюдаемых критериев, по которым разные участники независимо придут к одному выводу. Их лучше определить до разработки, пока ещё можно уточнить условия и ожидания.
Выберите законченный путь, а не набор экранов
Возьмём учебный кабинет сервисной компании. Клиент создаёт заявку по оборудованию, сотрудник обрабатывает её и фиксирует результат в рабочем реестре. Клиент должен увидеть завершение и относящийся к заявке итог. Доработка связывает эти действия в один путь.
Начало сценария — пользователь с разрешённым доступом заполняет заявку. Конец — результат обработки доступен тому же клиенту и связан с исходным обращением. Просто показать форму и список недостаточно: запись должна дойти до ответственного, а результат — вернуться заявителю.
В границу нашего примера не входят расчёт стоимости ремонта, склад запчастей и расписание выездов. Но проверка принадлежности заявки клиенту входит: без неё основной путь нельзя считать корректным. Если связь с реестром нужна для завершения задачи, её нельзя объявить необязательной уже при приёмке.
Подготовьте условия, в которых можно повторить проверку
До начала испытаний зафиксируйте версию приложения, состав тестовых данных, роли и доступность зависимостей. Нужны своя и чужая заявки, корректный и неполный запрос, а также возможность безопасно воспроизвести недоступность реестра.
Ожидаемый результат описывает и экран, и состояние данных. «Появилось уведомление» мало говорит о том, создалась ли заявка. «Кнопки нет» не показывает, запрещено ли действие сервером. Доказательство должно относиться к тому, что проверяется.
Если скорость важна для приёмки, укажите операцию, объём данных, условия нагрузки, предел времени и способ измерения. Конкретные значения согласуются для проекта. Они не появляются автоматически из слов «небольшая доработка» или «работает быстро».
Шесть критериев для учебной заявки
Это заполненный пример ведомости, а не отчёт о проведённых испытаниях. В последнем столбце указана роль принимающего; в рабочей версии ей соответствует конкретный участник проекта.
| Условия | Роль | Действие | Ожидаемый результат | Доказательство | Ответственный за приёмку |
|---|---|---|---|---|---|
| Своя заявка, реестр доступен | Клиент и сотрудник | Клиент отправляет заявку; сотрудник завершает обработку | Одна заявка в реестре; итог виден её автору | Связанные записи, итоговый статус и просмотр клиентом | Владелец процесса |
| Не заполнено обязательное поле | Клиент | Отправляет неполную заявку | Поле указано в ошибке; запись в реестре не создана; введённое сохранено | Ответ проверки и отсутствие записи по операции | Проверяющий сценарий |
| Есть заявка другой компании | Клиент | Открывает её прямой адрес | Чужие сведения и вложения не раскрываются | Отказ доступа в ответе сервера, без чужих данных | Ответственный за доступы |
| Первая отправка уже принята | Клиент | Повторяет ту же операцию | Второй заявки нет; показан результат первой | Идентификатор операции и единственная связанная запись | Технический принимающий |
| Реестр временно недоступен | Клиент и сотрудник | Клиент отправляет заявку, сотрудник разбирает ожидание | В примере заявка сохранена локально, но не названа принятой реестром; ответственному видна незавершённая передача | Локальная запись, состояние передачи и результат после восстановления | Ответственный за обмен |
| Есть ранее завершённая заявка | Клиент | Открывает прежний результат после доработки | История и доступный итог сохранены; новая заявка не возникает | Сравнение контрольной записи до и после | Владелец процесса |
Пятая строка содержит конкретно выбранное поведение: локальное сохранение до передачи. В другой системе допустим отказ без сохранения, но это нужно записать заранее. Главное — не показывать подтверждение, которого не было, и не оставлять судьбу заявки неопределённой для участников.
В первой строке итог подтверждается всей цепочкой, а не только ответом формы. Остальные строки показывают, что происходит при ошибке, повторе, чужом объекте и недоступной зависимости, а также что не должно сломаться рядом с изменением.
Проверьте критерий на однозначность
Дайте описание участнику, который не писал код. Сможет ли он подготовить условия, выполнить действие и понять, какое свидетельство сохранить? Если для ответа нужно спросить автора «что ты имел в виду», критерий стоит уточнить.
Например, «заявка обрабатывается корректно» заменяется связкой: зарегистрирована одна запись, у неё есть ответственный, итог принадлежит исходному обращению и доступен автору. «Старые данные сохранены» превращается в перечень нужной истории и проверку конкретных записей.
При работе внешнего модуля отдельной договорённости требует контракт API-модуля. Но технический ответ модуля не заменяет конечное действие клиента. Оба уровня должны быть связаны одним сценарием, а не двумя независимыми демонстрациями.
Несоответствие задаче и новая функция
Первый контраст. Согласовано, что клиент видит результат обработки заявки, но после завершения сотрудником статус не меняется. Это несоответствие принятому объёму. Просьба дополнительно рассчитывать стоимость ремонта — новая функция, если такого результата не было в согласованной задаче.
Второй контраст. До работ известно, что итог хранится во внешнем реестре. Выбранный способ обмена не позволяет его получить. Нельзя неожиданно выставить доплату за исправление собственного способа решения: известную зависимость следовало учесть. Подключение ещё одного независимого реестра после согласования этапа — изменение требований, которое обсуждается отдельно.
Принцип АИС Сокол: До результата — без доплат за наши ошибки. Если при приёмке наше решение не выполняет согласованную задачу — переделываем без доплаты, включая неверный выбор способа решения и повторные проверки. Новые требования согласуем отдельно; после приёмки действуют условия договора. Как организована приёмка и передача описано отдельно.
Испытание и рабочая приёмка — разные действия
Ошибки данных, чужой объект и недоступность зависимости воспроизводят в разрешённой тестовой среде. Учебное отключение интеграции не должно становиться экспериментом на действующих заказах. Проверяющий использует согласованные учётные записи и тестовые объекты.
После технических испытаний владелец процесса проверяет, подходит ли результат для реальной работы. Версия, данные и условия этой проверки фиксируются. Если часть проверки переносится в рабочую среду, отдельно согласуются безопасные действия, участники и возможность остановиться.
Результат испытания не заменяет решение о выпуске. И наоборот, сам выпуск не доказывает, что все критерии выполнены. Пройденные и непройденные пункты должны оставаться видны; замечание не закрывается одной сменой статуса в задаче.
Что остаётся у команды после этапа
Передайте исходный код изменений, описание сценариев и результаты их выполнения, необходимые настройки и инструкции. Для выпуска и восстановления нужны действия, связанные именно с этой доработкой. Известные ограничения и внешние зависимости сохраняются рядом с комплектом.
Для следующих изменений пригодятся проверки критичного рабочего пути. Они показывают, какое поведение уже согласовано и должно сохраниться. Это не обещание испытать все возможные состояния системы, а воспроизводимая опора для выбранного участка.
По теме: Контракт API-модуля · Проверки критичного рабочего пути.
Опишите один путь пользователя, его начало, итог и важное исключение. По этим вводным можно обсудить проверяемый этап, не начиная с полного переписывания системы или обязательного аудита.
