Форма показывает «Сохранено», но запись иногда не появляется в списке. Как построить проверку, чтобы отличить успешный отклик интерфейса от фактического сохранения данных?
Нужно проверить не только сообщение интерфейса, но и наблюдаемый бизнес-результат: наличие записи в списке после обновления страницы или повторного открытия функции. Если запись не появляется, сообщение «Сохранено» нельзя считать доказательством успешной операции.
Проверка должна разделять два факта: интерфейс сообщил об успехе и данные действительно сохранились. Это позволяет обнаружить ложноположительный результат, при котором UI показывает успех, хотя сохранение завершилось ошибкой или данные недоступны для последующего чтения.
Такой подход появился из-за ограничений проверок, ориентированных только на интерфейс. В распределённых и многоуровневых системах действие пользователя проходит через UI, прикладную логику, хранилище и механизм чтения данных, поэтому успешный ответ одного слоя не гарантирует корректность всей операции.
Проверка фактического результата связана с принципом проверки постусловия: после действия тестировщик подтверждает состояние, которое должно существовать согласно требованию. Это снижает риск принять технический отклик или визуальное сообщение за доказательство выполнения бизнес-операции.
Сообщение «Сохранено» может появиться до завершения фоновой операции, после обработки только части запроса или из-за ошибки обновления списка. Если тест проверяет лишь текст уведомления, он зафиксирует успех даже тогда, когда пользователь не сможет найти или использовать созданную запись.
Неверный вывод опасен для регрессии: дефект попадёт в отчёты как пройденный, а проблема обнаружится только при последующем поиске данных или повторном обращении пользователя. Особенно рискованны сценарии с отложенной записью, кэшированием, фильтрами списка и разными правами доступа.
Сначала нужно определить ожидаемое постусловие: например, после сохранения запись должна появиться в списке с указанными значениями и доступным идентификатором. Затем проверить его независимым способом, не ограничиваясь тем же уведомлением, которое уже сообщило об успехе.
Практическая последовательность может быть такой:
Важно учитывать согласованность чтения и записи. Если система сохраняет данные асинхронно, нужно явно определить допустимую задержку и проверить результат после неё; бесконечно ждать нельзя, поскольку это замаскирует зависание. Если запись появляется только после повторного входа, это может указывать не на потерю данных, а на ошибку обновления представления, поэтому отдельно проверяют сохранённое состояние и его отображение.
Проверка через базу данных или служебный интерфейс допустима как диагностический способ, если у тестировщика есть надёжный доступ и понятное соответствие между записью и пользовательским объектом. Однако она не заменяет пользовательскую проверку: данные могут существовать в хранилище, но быть недоступными через основной сценарий из-за ошибки чтения, фильтрации или прав.
В форме создания обращения после нажатия кнопки появлялось уведомление «Сохранено». Тестировщик сразу отмечал сценарий пройденным, но пользователи сообщали, что новые обращения иногда не видны в общем списке.
Рассматривались два варианта. Проверка только уведомления была бы быстрой, но не обнаруживала бы потерю данных. Прямая проверка хранилища показывала бы, создана ли запись, но не выявляла бы ошибки отображения списка и была бы зависима от внутренних деталей реализации.
Выбрали двухуровневую проверку: сначала подтверждали появление записи в пользовательском списке после обновления и поиска по уникальному номеру, а при сбое дополнительно проверяли наличие записи в хранилище для диагностики. В результате выяснилось, что запись сохранялась, но список не обновлялся после ответа сервера; дефект был локализован в механизме обновления представления, а не в операции сохранения.
1. Достаточно ли проверить наличие записи сразу после нажатия кнопки?
Нет. Если система выполняет операцию асинхронно, мгновенная проверка может дать ложный отрицательный результат. Нужно заранее определить допустимое время завершения и проверять состояние после него, одновременно фиксируя превышение этого времени как отдельный риск или дефект.
2. Можно ли считать запись сохранённой, если она есть в базе данных, но отсутствует в пользовательском списке?
Для операции записи — возможно, но для пользовательского сценария — нет. Наличие данных в хранилище подтверждает только один слой системы; пользовательский результат остаётся некорректным, если запись нельзя найти или использовать через предусмотренный интерфейс.
3. Как отличить потерю записи от того, что её скрывает фильтр?
Нужно повторить поиск без ограничивающих фильтров, использовать уникальный идентификатор или другой однозначный признак, проверить пагинацию и права доступа. Если запись находится после снятия фильтра, проблема относится к отображению или условиям выборки, а не к сохранению; это следует отразить в доказательствах дефекта.