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