Ответ
Процесс написания тест-кейса:
- Анализ требований (Requirements Analysis): Четкое понимание спецификаций (user stories, техническое задание, дизайн-макеты).
- Определение тестового покрытия (Test Coverage): Какие аспекты функционала нужно проверить (позитивные, негативные, boundary-значения, usability, безопасность).
- Создание структуры: Чёткие, атомарные шаги с ожидаемыми результатами.
- Рецензирование (Review): Проверка кейсов разработчиком, аналитиком или другим тестировщиком.
Ключевые принципы хорошего тест-кейса:
- Однозначность (Unambiguous): Шаги не должны допускать различного толкования.
- Воспроизводимость (Repeatable): Кейс должен давать одинаковый результат при каждом выполнении.
- Независимость (Independent): По возможности, кейс не должен зависеть от результатов других кейсов.
- Проверяемость (Testable): Ожидаемый результат должен быть объективно проверяемым.
Пример структурированного тест-кейса:
**ID:** TC_AUTH_001
**Заголовок:** Успешная авторизация с валидными email и паролем.
**Приоритет:** High
**Предусловия:** Пользователь зарегистрирован в системе (email: user@test.com, password: Qwerty123!).
**Шги:**
1. Открыть страницу авторизации (/login).
2. В поле "Email" ввести "user@test.com".
3. В поле "Password" ввести "Qwerty123!".
4. Нажать кнопку "Sign In".
**Ожидаемый результат:**
* Происходит редирект на главную страницу (/dashboard).
* В заголовке страницы отображается приветствие: "Welcome, user@test.com".
* В HTTP-ответе устанавливается cookie сессии.
**Постусловия:** Выполнить логаут.Дополнительно: Для нового функционала также стоит создать тест-кейсы на проверку интеграции со смежными модулями и откат изменений (rollback).
Ответ 18+ 🔞
А, ну это ж классика, блядь! Сидишь такой, втыкаешь в требования, а там — хуй пойми что написано. "Пользователь должен иметь возможность взаимодействовать с интерфейсом". Да я и сам, сука, имею возможность, вопрос — какую, блядь, конкретно? Ну ладно, поехали разбирать этот цирк с конями под названием "написание тест-кейса".
Первым делом — анализ требований. Это когда ты берёшь эти user stories, ТЗ или дизайн-макеты и пытаешься понять, что же, блядь, от тебя хотят. Чувствуешь подозрение, ёпта, что половину функционала додумали уже в процессе, а вторая половина описана так, что хоть святых выноси. Но надо вникнуть, иначе потом охуеешь, когда окажется, что кнопка "сохранить" на самом деле отправляет всё в никуда.
Дальше — определение тестового покрытия. Вот тут включается мозг, если он, конечно, не набекрень. Надо прикинуть, что проверять-то будем. Не только что всё работает, когда ты всё делаешь правильно — это для лохов. Надо, чтобы и когда пользователь, этот, ебушки-воробушки, начнёт вводить в поле пароля "SELECT * FROM users", у него всё аккуратно так, с улыбочкой, сломалось в нужном месте, а не отдало базу данных хакерам. Проверяем позитивные сценарии, негативные, граничные значения (boundary values), юзабилити (удобно ли, блядь, тыкать в эту кнопку с телефона) и, конечно, безопасность — чтоб не было дырок, куда можно просунуть свой кривой хуй с винтом.
Потом создаёшь структуру. Это святое. Шаги должны быть атомарными, как инструкция для робота-дауна. "1. Открыть глаза. 2. Найти браузер. 3. Кликнуть левой кнопкой мыши по иконке". И ожидаемый результат — чёткий, как удар топором. Не "всё должно работать", а "появляется надпись 'Успешно', зелёная, курсивом, размером 14px".
И ни в коем случае не забываем про рецензирование. Отдаёшь свои шедевры коллеге, а он такой: "А тут, сука, в шаге 3 ты написал 'ввести логин', а какой логин, блядь? Логин от чего? От почты? От бабушкиного сундука?" И ты понимаешь — да, мудак, надо было точнее. Вот для этого и нужен review, чтобы не выглядеть идиотом потом.
Ключевые принципы, блядь, хорошего кейса:
- Однозначность. Читает тестировщик из соседнего отдела — и у него в голове должна сложиться та же картина, что и у тебя. Никаких "как бы" и "типа того".
- Воспроизводимость. Запустил кейс сегодня, завтра, через неделю — результат один и тот же, пиздец. Если нет — это не тест-кейс, а гадание на кофейной гуще.
- Независимость. Идеально, когда кейс — это замкнутая вселенная. Запустил, проверил, почистил за собой. Не надо чтобы для проверки входа в аккаунт сначала требовалось выиграть в покер с самим чёртом.
- Проверяемость. Ожидаемый результат должен быть таким, чтобы его можно было ткнуть пальцем и сказать: "Да, вот оно, блядь, зелёное и на месте". Не "чувство удовлетворения у пользователя", а "отображается pop-up с текстом 'OK'".
Вот, смотри, как это выглядит вживую, на примере:
**ID:** TC_AUTH_001
**Заголовок:** Успешная авторизация с валидными email и паролем.
**Приоритет:** High (Потому что без этого нихуя дальше не сделать, всё на этом держится).
**Предусловия:** Пользователь зарегистрирован в системе (email: user@test.com, password: Qwerty123!). То есть, его уже, грубо говоря, занесли в базу.
**Шаги:**
1. Открыть страницу авторизации (/login). Не главную, не блог, а именно /login, ядрёна вошь!
2. В поле "Email" ввести "user@test.com".
3. В поле "Password" ввести "Qwerty123!".
4. Нажать кнопку "Sign In". Левой кнопкой мыши, Карл!
**Ожидаемый результат:**
* Тебя перекидывает на главную страницу (/dashboard). Редирект, блядь, должен быть!
* В заголовке страницы светится приветствие: "Welcome, user@test.com". Дословно, сука!
* В HTTP-ответе должна проставиться cookie сессии. Это уже для тех, кто в теме, но проверить надо.
**Постусловия:** Выполнить логаут. Чтобы не засирать сессию для следующих тестов, чистота — залог здоровья.И да, чувак, дополнительный лайфхак: когда делаешь кейсы на новую фичу, не забудь про интеграцию. Эта ваша новомодная кнопка не должна, блядь, сломать весь старый функционал рядом. И продумай, как это всё откатывать, если пойдёт по пизде. Мало ли что. Всё, теперь ты гуру.