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