Тест-кейсы: как и зачем писать📝



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



Виды тест-кейсов:




Позитивные (положительные). Проверяют, что система правильно реагирует на корректные данные

Пример: пользователь существует в системе и он может пройти авторизацию



Негативные (отрицательные). Показывают, что система умеет работать с некорректными данными

Пример: пользователь при регистрации ввёл простой пароль 12345, а кнопка “Установить пароль” активной не стала, т.к ждёт более сложный



🚫 Деструктивные. Служат для проверки прочности системы

Пример: метод для получения заказов пользователя нельзя выполнить без авторизации





Особенности:

💩Идеально подходят для описания сложных проверок в системе и регрессионного тестирования

💩Помогают автоматизировать ручные проверки, если тестирование занимает много времени

💩Используются для проверки системы не тестировщиками, для онбординга новых людей на проект

💩Помогают определить необходимое время на тестирование

💩Избыточны для небольших задач

💩Требуют много времени на написание и актуализацию

💩Может возникнуть "Эффект пестицида" — когда из-за постоянного повторения одинаковых шагов не получается найти ошибки





Содержание тест-кейса



💫Уникальный номер. Позволит ссылаться на тесты по номеру

💫Заголовок. Отражает цель - что именно нужно проверить

💫Предусловия. Что нужно сделать перед началом тест-кейса

💫Постусловия (редко). Что нужно сделать после проведения проверки. Например, удалить изменения из базы данных

💫Шаги. Что нужно сделать для проверки

💩Не описывать шаги слишком подробно. Например, следует писать «Введите email» вместо «Введите email, нажимая клавиши на клавиатуре».

💩Шаги должны быть конкретными. Написать: “Нажмите на иконку пользователя → Личный кабинет” вместо “Зайдите в личный кабинет”

💩Скриншоты можно использовать только как дополнение к текстовому описанию

💫Ожидаемый результат. Что должно получиться после или во время прохождения шагов

💫Статус. Passed/Failed, то есть Успех/Провал или другой. Отмечается при прохождении кейса тестировщиком





Use Case 🆚 Test Case



🔹 Use Case — детальное описание того, как пользователь взаимодействует с системой, включая различные сценарии, условия и результаты. Используют для описания функциональных требований к системе



🔸 Test Case — детальное описание того, как должно проходить тестирование конкретной функции в системе. Основываются на юскейсах и используются для проверки соответствия реализации требованиям.





👨‍💻 Аналитик и тест-кейсы

На старте проекта кейсы может написать и согласовать аналитик - именно он лучше всех знает требования к системе. Это упростит сдачу проекта в будущем

Аналитик подсвечивает тестировщику какую часть функционала нужно оформить в виде кейсов для регрессионного тестирования - что было самым важным в релизе

Ревью тест-кейсов — аналитик проверяет, что тестировщик правильно понял задачу и ожидаемый результат соответствует требованиям





Инструменты ведения для тест-кейсов:

Zephyr for Jira

TestRail

Qase

Test IT





⭐️ Подборка материалов доступна в базе знаний по системному анализу



#тестирование