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