Тестовое задание QA: тест-кейсы и баг-репорты

В тестовом задании QA обычно важен путь от требований к наблюдаемому результату. Таблица из множества строк ещё не показывает качество проверки. Нужно объяснить, что именно проверяется, как воспроизвести действие и на каком основании результат считается ошибкой. Соберём небольшой пакет на учебном каталоге.

Для этого урока подготовлена отдельная демонстрация с намеренным дефектом. Она не является рабочей страницей ProfessorWeb. В названии и описании прямо указано её учебное назначение. Не используйте её результаты как сведения о дефектах настоящего сайта или реального работодателя.

Разбираем требования и границы

В каталоге четыре материала: два Frontend, один Backend и один QA. Поиск должен работать по названию, игнорировать регистр и внешние пробелы. Тема и запрос сочетаются одновременно. Пустая выдача получает сообщение; очистка возвращает все материалы и тему «Все».

Проверяем только этот интерфейс и эти данные. Нагрузка, безопасность сервера, авторизация и платёжные маршруты отсутствуют в упражнении. Отметить это полезно: итог «проверил сайт» был бы слишком широким. Реальный результат — проверка определённых требований в определённой версии.

Перед запуском запишите среду: браузер и его версию, устройство или размер окна, адрес страницы и версию упражнения. В подготовленном комплекте версия называется qa-demo-v1. Поле браузера в шаблоне остаётся для вашего фактического значения; не копируйте чужую среду, если проверяли другую.

Выбираем разные классы проверок

Возьмём обычное совпадение, другую форму того же ввода, отсутствие результата, выбор темы, комбинацию фильтров и очистку. Это разные свойства поведения. Набор не доказывает отсутствие всех ошибок, но покрывает главные условия учебного задания.

ID	Действие из исходного состояния	Ожидаемый результат
TC-01	Открыть каталог	Четыре карточки
TC-02	Ввести javascript	Одна карточка JavaScript
TC-03	Ввести JAVASCRIPT	Та же одна карточка
TC-04	Ввести javascript	Та же одна карточка
TC-05	Ввести несуществующийзапрос	Нет карточек, есть сообщение
TC-06	Выбрать Frontend без запроса	Две карточки
TC-07	Ввести javascript, выбрать Backend	Нет карточек, есть сообщение
TC-08	После TC-07 очистить фильтры	Четыре карточки, тема «Все», запрос пуст

Проверки TC-02, TC-03 и TC-04 используют одно название намеренно. Меняется только свойство ввода: регистр или пробелы. Так проще локализовать причину расхождения. Если одновременно менять тему, запрос и данные, интерпретация результата станет труднее.

В комплекте таблица сохранена как CSV. Открыть её можно в редакторе таблиц или обычном текстовом редакторе. Название инструмента не является частью правильности проверки; важнее сохранённые условия и результат.

Оформляем один тест-кейс полностью

Краткая строка TC-03 полезна для общего списка, но для воспроизведения запишем её подробнее. Исходное состояние: версия qa-demo-v1 открыта, поле поиска пусто, выбрана тема «Все», показаны четыре материала. Шаг: ввести JAVASCRIPT в поле «Название материала».

Ожидаемая выдача содержит одну карточку JavaScript: массивы; сообщение об отсутствии результатов скрыто. Основание — требование поиска без учёта регистра. В намеренно неисправной версии фактически появляются ноль карточек и сообщение о пустой выдаче.

Не используйте «проверить поиск» как единственный шаг. Другой участник должен получить то же наблюдение без расшифровки ваших намерений. Также различайте фактический результат и оценку: «ноль карточек» — наблюдение, «не соответствует требованию» — вывод из сопоставления.

Записываем баг-репорт

Для обнаруженного расхождения создадим отдельный документ:

Заголовок: поиск не находит материал при вводе запроса в верхнем регистре.
Версия: учебная демонстрация qa-demo-v1.
Среда: указать фактический браузер и устройство своей проверки.
Предусловия: каталог открыт, все темы выбраны, поиск пуст, видны четыре карточки.
Шаги: ввести JAVASCRIPT в поле «Название материала».
Ожидается: одна карточка JavaScript: массивы, сообщение пустой выдачи скрыто.
Фактически: карточек нет, показано сообщение «Материалы не найдены».
Основание: требование поиска без учёта регистра.
Дополнительное наблюдение: запрос javascript в той же теме находит одну карточку.
Влияние: пользователь может ошибочно решить, что материал отсутствует.
Воспроизводимость: повторяется при указанных условиях в этой версии.

Репорт не должен начинаться с предположения «разработчик забыл lowercase». QA может наблюдать поведение без знания реализации. Если код доступен и вы нашли причину, добавьте её как отдельную техническую заметку с проверкой, сохранив пользовательские шаги.

Серьёзность описывает влияние дефекта, приоритет — очередность исправления с учётом задач команды. В упражнении мы объяснили влияние, но не назначаем универсальный «критический» уровень. Если в настоящем задании требуется классификация, используйте определения принимающей команды и обоснуйте выбор.

Отделяем дефект от вопроса к требованиям

Предположим, после фильтра остаются две карточки, но их порядок не указан. Сам факт, что вам хотелось бы сортировку по алфавиту, не делает текущую выдачу нарушением. Запишите вопрос: «Какой порядок должен использоваться после фильтрации?» При необходимости предложите вариант.

Аналогично отсутствие реальных ссылок на статьи не считается найденной ошибкой этого упражнения: в его границах карточки показывают данные, а переходы не реализуются. Это не означает, что ссылки никогда не нужны каталогу. Значит лишь, что вывод проверки должен опираться на выбранную задачу.

Если проверку не удалось выполнить из-за недоступности страницы, отметьте её как заблокированную или невыполненную, а не как успешную. Если поведение нарушает условие — как непройденную. Эти состояния отражают разные сведения о качестве и требуют разных дальнейших действий.

Проверяем исправление и соседние случаи

В рабочей версии frontend-упражнения запрос приводится к нижнему регистру после удаления пробелов по краям. Повторите TC-03: теперь ожидается одна карточка. Затем проверьте TC-02 и TC-04, чтобы убедиться, что обычный запрос и внешние пробелы продолжают обрабатываться.

После этого пройдите комбинацию с темой и очистку. Само совпадение одного запроса не подтверждает остальные требования. Такой маршрут отличает повторную проверку конкретного исправления от проверки связанного поведения. В подготовке урока расхождение TC-03 воспроизведено в браузере, а рабочая версия проверена отдельно.

При реальном исправлении сначала запишите новую версию, а затем результаты. Иначе через неделю будет трудно понять, в каком состоянии приложения закрыли дефект. Не переписывайте исходный репорт так, будто ошибка никогда не наблюдалась: история помогает восстановить обсуждение.

Подготавливаем итоговый отчёт

Для намеренно неисправной версии наша учебная таблица содержит восемь проверок: семь проходят, TC-03 не проходит. Это характеристика данного набора, а не процент качества приложения. Одна таблица не даёт знаменатель для всех возможных ошибок.

В отчёте назовите проверенный объём, версию, открытый дефект и ограничения. Например: «Проверены текстовый поиск, фильтр темы и очистка на четырёх фиксированных материалах. Найдено расхождение поиска по регистру. Серверные операции, нагрузка и другие браузеры не проверялись». Такая запись помогает команде выбрать дальнейшие действия.

Для собственного портфолио сохраните требования, тест-кейсы, баг-репорт и отчёт рядом. Опишите личный вклад и учебное происхождение приложения. Затем используйте комплект в резюме начинающего QA: он подтверждает конкретную работу, которую можно разобрать на собеседовании.

Скачать таблицу, репорт и обе версии упражнения · Практикум по поиску работы