На демонстрации личного кабинета пользователь открывает заявку и получает документ. Это полезный пример, но он не показывает, что произойдёт с другой ролью, при задержке обмена или повторной отправке. Перед запуском необходимо проверить согласованные маршруты и зафиксировать фактический результат каждого из них.
Описание разработки кабинетов у «Гуси-Лебеди» доступно на странице https://gusi-lebedi.ru/services-ru/razrabotka-lichnogo-kabineta/. Там представлены роли, сценарии и интеграции с внутренними системами. Для приёмки своего проекта нужны отдельные требования: какие действия реализованы, с какими данными и по каким условиям их проверяют. Перечень возможностей услуги не заменяет такой план.
Зафиксируйте версию и условия проверки
Уточните, какую версию кабинета принимаете и в каком окружении проходит проверка. Согласуйте разрешённые тестовые данные, доступы и состояние связанных систем. Если внешняя интеграция недоступна, отметьте ограничение до начала сценария, а не после объявления успешного результата.
Для каждой задачи запишите роль, начальные условия, последовательность действий и ожидаемый итог. В условном примере клиент получает документ по своей заявке. Проверка должна объяснять, какая запись используется и где находится актуальный файл. Формулировка «документы работают» не позволяет повторить проверку.
Проверьте границы каждой роли
Составьте перечень разрешённых действий для клиента, представителя организации и администратора, если такие роли предусмотрены проектом. Проверьте не только доступные кнопки, но и результат операции. Отсутствие элемента на экране само по себе не подтверждает соблюдение правил доступа к данным.
Используйте разные разрешённые тестовые записи и убедитесь, что пользователю доступны именно его данные. Уточните смену роли, приглашение участника и прекращение доступа. Не проводите эксперименты с чужими рабочими данными. Способ технической проверки полномочий должен соответствовать согласованному плану проекта.
Пройдите целые маршруты пользователя
Проверьте путь от входа до результата: найти нужную запись, выполнить действие, получить подтверждение и вернуться к результату позднее. Согласуйте, что означает завершение задачи. Уведомление на экране может подтверждать получение запроса, но не обязательно завершение обработки во внутренней системе.
Посмотрите, понятны ли связи между заявкой, документом и историей. Если пользователь вынужден угадывать, какой файл относится к обращению, запишите наблюдаемую ситуацию. Не приписывайте ей влияние на продажи или нагрузку поддержки без соответствующих данных. На приёмке важны требования и фактическое поведение.
Сверьте результат обмена данными
Для интеграции проверьте исходное действие и состояние в связанной системе. Уточните источник актуального значения, направление передачи и допустимую задержку. В условном сценарии изменение статуса в кабинете должно соответствовать согласованному результату обработки, а не только новому тексту в карточке.
Проверьте предусмотренные случаи ошибки обмена и недоступности источника. Пользователь должен видеть объяснение, соответствующее фактической ситуации. Если тестовая система отличается от рабочей, зафиксируйте границы проверки. Успех одного сообщения не доказывает работоспособность всех операций интеграции.
Проверьте повторные действия
Пользователь может повторно нажать отправку или вернуться к незавершённой операции. Согласуйте, какой результат ожидается и как кабинет объясняет состояние запроса. Не рассчитывайте на то, что человек всегда дождётся ответа и выполнит инструкцию без отклонений.
На разрешённых тестовых данных проверьте повторную отправку, обновление страницы и возвращение к записи. Уточните, когда действие создаёт новый объект, а когда относится к прежнему. Если правило ещё не определено, запишите вопрос владельцу процесса вместо выдуманного универсального решения.
Различайте ошибки и пустые состояния
Пустой список, недостаточные права и сбой загрузки имеют разные причины и дальнейшие действия. Проверьте предусмотренное объяснение каждого состояния. Если данных пока нет, человеку может быть доступно создание записи. Если источник недоступен, такое предложение может оказаться неуместным.
Проверьте переход к помощи и сохранение контекста обращения, если это включено в требования. Уточните, какие сведения пользователь передаёт сотруднику и как возвращается к результату. Не указывайте обещанный срок ответа, пока он не подтверждён реальной организацией обслуживания.
Повторите ключевые действия на телефоне
Проверьте согласованные устройства и размеры экрана. Пройдите поиск записи, просмотр длинной карточки, работу с формой и получение файла. Посмотрите, виден ли результат действия без дополнительных догадок и не перекрывает ли элемент управления нужную информацию.
Открытие главного экрана на телефоне не заменяет проверку маршрута. Фиксируйте конкретное устройство, условия и наблюдаемый результат. Если для отдельного формата проверка не проведена, не распространяйте на него успешный результат другого устройства.
Сохраните итоги и открытые вопросы
Для каждого сценария отметьте фактический результат и ограничения. Проблему описывайте через роль, данные, действия и расхождение с ожиданием. Предполагаемую причину отделяйте от подтверждённого наблюдения. Это позволит исполнителю воспроизвести ситуацию и проверить исправление.
После изменения повторите затронутый маршрут и связанные с ним проверки. Решение о запуске принимайте по согласованным критериям и фактическому состоянию проекта. Пройденная приёмка не гарантирует отсутствия любых ошибок, но даёт проверяемое основание для передачи принятой версии и дальнейшего сопровождения.
