Проверки для разных проектов

Наш Python-стенд проверяет функции на синтетических данных. У него нет браузера, базы, уведомлений или инфраструктурного состояния. При переносе harness в другой проект набор проверок придётся дополнить теми ошибками, которые возникают именно там.

Интерфейс: запись не должна теряться

Предположим, агент добавил форму дневника. Сборка прошла, кнопка есть, но при ошибке сети введённая заметка пропадает. Unit-тест функции валидации этого не заметит.

Начните с одного полного сценария в браузере: ввести балл и заметку, отправить, увидеть сохранённую запись. Затем воспроизведите отказ API и проверьте, что текст сохранился и повторная отправка доступна. Проверьте клавиатурный фокус, подписи полей и сообщения об ошибке.

Скриншоты нужны для состояний, которые легко пропустить в коде: длинный текст ошибки, узкий экран, пустой дневник. Зафиксируйте размеры экрана и тестовые данные, чтобы сравнение имело смысл. Автоматический снимок помогает заметить отличие, но принять изменение текста или расположения элементов может потребоваться дизайнеру.

Сервер: проверяйте путь данных

Функция отчёта может корректно считать средний балл и при этом получать из API записи чужого пользователя. Добавьте интеграционный сценарий с двумя синтетическими пользователями: запрос одного не должен возвращать данные другого. Проверяйте фактический ответ и состояние хранилища.

При изменении схемы данных выполните миграцию на копии тестовой базы с предыдущей схемой. Убедитесь, что новая версия читает старые записи и что понятно, как остановить выпуск при ошибке. Откат кода не всегда отменяет изменение данных.

Для критичного запроса измерьте время на объёме данных, близком к рабочему. Один быстрый unit-тест не покажет лишний запрос к базе на каждую строку отчёта.

Мобильное приложение: повтор и фон

Если дневник должен работать без сети, сценарий начинается до подключения: создать запись офлайн, закрыть приложение, открыть его и восстановить сеть. Проверьте, что запись сохранилась и синхронизировалась один раз.

Для уведомлений воспроизведите отказ в разрешении и последующее изменение настройки. Проверка только на устройстве, где разрешение уже выдано, пропустит поведение первого запуска. Зафиксируйте версию ОС и состояние приложения перед тестом.

Эмулятор или симулятор удобен для повторяемого набора проверок. Сценарии, зависящие от реального устройства, фоновых ограничений или доставки push, могут потребовать отдельного испытания на устройстве.

Инфраструктура: сравните план и результат

Для изменения сервиса сначала получите план: какие ресурсы будут созданы, изменены и удалены. Согласование должно относиться к этому плану и целевому окружению. Если исходное состояние изменилось, старый план нужно проверить заново.

После применения недостаточно кода завершения команды. Проверьте доступность сервиса, версию, состояние зависимостей и признаки ошибок. До запуска определите, кто остановит работу и что будет восстановлено: конфигурация, образ, данные или маршрут трафика.

Права на чтение состояния и права на применение изменений выдавайте раздельно, если окружение это позволяет. Тогда диагностическая задача не получает возможность случайно изменить работающий сервис.

Соберите один профиль проверок

Выберите задачу из своего проекта и заполните таблицу. Начните с минимального набора, который ловит перечисленные ошибки.

Что определить	Пример для формы дневника
Рабочее окружение	Временная сборка, тестовый API, синтетический пользователь.
Обязательный сценарий	Запись сохранилась и видна после перезагрузки.
Проверка отказа	После сетевой ошибки введённый текст не потерян.
Проверка интерфейса	Узкий экран, длинная ошибка, управление клавиатурой.
Результаты для ревью	Вывод тестов, скриншоты выбранных состояний, ошибки консоли.
Решение человека	Изменение текста и правил использования данных.

Для серверного кода, мобильного приложения или инфраструктуры заполните те же строки своими проверками. Общими останутся постановка задачи, журнал и передача на ревью; способ доказать нужное поведение будет зависеть от проекта.