Тест-кейс (Test Case) — это фундамент работы любого тестировщика. Он является и инструкцией по проверке того или иного модуля или поведения, и документом, который помогает команде понять, работает продукт так, как задумано, или нет.
В этой статье разберем анатомию идеального тест-кейса, типичные ошибки новичков и преимущества хранения кейсов в TMS.

Что такое тест-кейс и зачем он нужен?

Тест-кейс — это описанная последовательность действий, условий и ожидаемых результатов, необходимая для проверки конкретной функции или элемента продукта.

Если говорить проще: это сценарий.

• Сценарий: Пользователь вводит верный логин и пароль -> Нажимает "Войти".
• Ожидаемый результат: Пользователь попадает в личный кабинет.

Зачем это описывать? Чтобы любой член команды (а не только вы) мог проверить функционал одинаково, не упустив важные детали.

Структура идеального тест-кейса

Хороший тест-кейс должен отвечать на вопросы: Что проверяем? Как проверяем? Что должны получить?

Основные атрибуты, которые должны быть в любом кейсе:

1. Заголовок.

Он должен быть кратким, но емким, и в то же время уникальным. Также типичной ошибкой при заполнении заголовка являются "мусорные" слова, такие как "проверка" или "тест". Тест-кейс по определению является проверкой, и потому нет необходимости дополнительно акцентировать на этом внимание.
Плохо: Проверка авторизации.
Хорошо: Успешная авторизация пользователя с валидными данными.

2. Предварительные условия.

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

Например, если мы будем проверять сценарий входа зарегистрированного пользователя, правильно будет указать в предусловиях: "Пользователь зарегистрирован, открыта страница входа."

3. Шаги

Пошаговая инструкция к действиям, которые должен предпринять тестировщик для проверки модуля или сценария. Шаги пишутся безлично: "кликнуть", "ввести" и т.д. Шаги должны описывать только актуальные в контексте определённого тест-кейса действия. Например, если мы проверяем функционал авторизации, нет необходимости описывать в рамках этого тест-кейса действия, требуемые для проверки дизайна окна авторизации. Таковые лучше вынести в отдельный тест-кейс, ориентированный именно на проверку дизайна - так мы соблюдём принцип атомарности тест-кейсов.

4. Ожидаемый результат

Самый важный пункт. Именно по нему мы определяем, пройден тест или нет.
Как правило, ожидаемые результаты описываются в отношении каждого выполненного шага. Ожидаемые результаты должны содержать достаточную информацию, чтобы мы могли судить о соответствии или несоответствии поведения системы относительно заданного.

Пример: Производится редирект в Личный кабинет. В правом верхнем углу отображается аватарка пользователя.

5. Постусловия

Необязательный, но полезный пункт. Что нужно сделать, чтобы вернуть систему в исходное состояние?
Пример: Удалить созданного пользователя из БД.

6. Тэги.

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

Топ-5 правил написания тест-кейсов

Чтобы ваши кейсы не вызывали боли у коллег, следуйте этим принципам:

• Атомарность. Один тест-кейс проверяет одну конкретную вещь. Не пытайтесь проверить и логин, и смену пароля, и покупку товара в одном кейсе. Разделяйте бизнес-логику и дизайн на отдельные кейсы.
• Независимость. Тест-кейс не должен зависеть от предыдущего. Вы должны иметь возможность запустить их в любом порядке.
• Ясность. Избегайте слов "корректно", "правильно" и т.д., так как они не дают понимания того, как именно должно выглядеть и работать ПО. Вместо этого давайте детализированные описания поведения и того, что должен увидеть пользователь: "Поле подсвечивается красным", "Произошёл переход на такую-то страницу".
• Отсутствие избыточности. Не описывайте очевидные вещи (например, "запустить приложение").
• Актуальность. Если в тестируемое ПО внесли изменения, тест-кейс нужно обновить. Устаревший тест-кейс хуже, чем его отсутствие.

Где хранить тест-кейсы: Excel vs TMS.

Многие начинают вести тестовую документацию в Excel или Google Таблицах. Это бесплатно и привычно. Но как только количество кейсов переваливает за несколько десятков, начинаются проблемы:

1. Сложно искать нужные проверки;
2. Нет истории изменений, а значит, невозможно сказать наверняка, кто и когда сломал тест;
3. Неудобно собирать прогоны и отчеты.

Профессиональные команды используют TMS (Test Management Systems).

Как это реализовано в DoQA.

Мы в DoQA создавали систему, чтобы избавить тестировщиков от рутины. Вот чем это удобнее Excel:

• Древовидная структура: Вы раскладываете кейсы по папкам (модулям), как файлы на компьютере.
• Shared Steps (Общие шаги): Вы один раз описываете шаг "Авторизация" и вставляете его во все 50 тест-кейсов. Если логика авторизации изменится, вы поправите её в одном месте, а не в 50.
• Версионность: Вы всегда видите, как выглядел тест-кейс месяц назад.
• Гибкие Тэги помогают мгновенно сформировать тест-план из тех кейсов, которые затрагивают тестируемую в данный момент функциональность.
• Импорт из Excel: Если вы уже ведете базу в таблицах, переезд в DoQA займет пару минут — система сама распознает колонки.
• AI генерация кейсов: Мы специально обучили ИИ всем правилам написания кейсов, чтобы ускорить работу тестировщиков.
• Дашборды с отчётами: работа тестировщиков в наглядном виде представлена в метриках, автоматически собираемых DoQA.

Готовы навести порядок в документации?
Попробуйте DoQA — российскую TMS, созданную тестировщиками для тестировщиков. У нас есть бесплатный тариф для небольших команд.
Попробовать бесплатно