Путь тестировщика: от User Story до Test Case

Представьте, что вы строите дом. Можно начать сразу класть кирпичи, но велик шанс, что стены выйдут кривыми, а крыша рухнет. Сначала нужен архитектурный план, дизайн-проект и смета. В мире разработки программного обеспечения роль такого «плана» играет набор техник и артефактов, которые помогают разработчикам и тестировщикам создать качественный продукт. 

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

1. С чего все начинается: User Story (пользовательская история)

Прежде чем писать код или искать баги, нужно понять:  а что именно нужно пользователю? Для этого существует User Story.

User Story (пользовательская история) — это описание требования к системе, написанное простым языком   с точки зрения конечного пользователя. Ее главная цель — донести ценность функции для клиента, а не перечислять технические детали.  User Story отвечает на вопрос: «Зачем» и «Для кого» мы делаем функцию. 

Пример User Story: «Как покупатель, я хочу фильтровать товары по цене, чтобы быстро находить то, что могу себе позволить.»

User Story можно проверить по критериям INVEST:

• I (Independent — Независимая): не зависит от других историй.

• N (Negotiable — Обсуждаемая): команда может обсуждать детали.

• V (Valuable — Ценная): приносит реальную пользу бизнесу или пользователю.

• E (Estimable — Оцениваемая): понятно, сколько времени займет реализация.

• S (Small — Маленькая): умещается в один цикл разработки (спринт).

• T (Testable — Тестируемая): Есть четкий критерий проверки успеха.

2. Детализируем поведение: Use Case (сценарий использования)

Use Case (сценарий использования) — это техника описания взаимодействия   между пользователем (актором) и системой для достижения конкретной цели. Он отвечает на вопрос «Что» произойдет.

В IT Use Case часто изображают в виде диаграммы (прямоугольник — система, человечки — акторы,   овалы — сами сценарии) и подробного текстового описания с шагами. Это отличная база для написания тестов, так как каждый шаг — это потенциальная проверка.

Представьте, что вы в ресторане.

User Story — это «хочу поесть».

Use Case — это конкретный сценарий: «Сделать заказ»

• Актор: клиент

• Триггер (активатор): клиент проголодался.

• Предусловие: клиент сидит за столом, у него есть меню.

• Успешный сценарий:

• клиент выбирает блюдо по меню

• официант (API) принимает заказ

• повар готовит блюдо

• официант приносит заказ

3. Что именно проверять: чек-лист

Теперь у нас есть требования. Начинающий тестировщик может растеряться: за что хвататься? Чтобы ничего не забыть, составляют чек-лист.

Чек-лист — это просто список проверок. Он отвечает на вопрос «Что нужно проверить», но не говорит «Как». Это быстрый, наглядный и удобный инструмент.

Преимущества: скорость, гибкость, наглядность прогресса.

Недостатки: разные тестировщики могут понимать один пункт по-разному (например, «проверить сортировку» — по возрастанию, по убыванию или по цене?).

Пример чек-листа для авторизации:

• Ввод валидного логина и пароля

• Ввод невалидного пароля

• Ввод пустого логина

• Восстановление пароля по ссылке

• Автозаполнение полей браузером

Совет: чек-листы идеальны на ранних этапах, когда продукт быстро меняется, или для проверки GUI/верстки.

Источник

4. Точная инструкция: тест-кейс

Когда система сложная, а проверки требуют точности (например, финансовая отчетность), на помощь приходит тест-кейс.

Тест-кейс — это уже полноценная инструкция для тестировщика, содержащая:

• Уникальный номер и заголовок

• Предусловия: что должно быть сделано до начала (например, «пользователь авторизован»)

• Шаги: пошаговое описание действий (например, 1. Открыть страницу «Корзина»  2. Нажать кнопку «Оформить»)

• Ожидаемый результат: что мы должны увидеть после каждого шага (например, «Открылась форма оплаты»)

• Окружение: браузер, ОС, версия приложения

• Статус: Passed (успешно), Failed (провал), Blocked (заблокировано)

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

• Позитивный: проверяет корректную работу на правильных данных (ввели пароль верно —    вошли в систему)

• Негативный: проверяет обработку ошибок (ввели неправильный пароль — получили предупреждение)

• Деструктивный: проверяет прочность системы (ввели 1000 символов в поле для имени —    система не упала).

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

Источник

5. Борьба со сложной логикой: таблица решений

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

Смысл прост:

• Слева сверху пишем Условия (например, Посещаемость ≥ 75%», «Средний балл ≥ 4.0»)

• Слева снизу пишем Действия (результат, например, «Допущен ли к экзамену?»)

• Справа создаем колонки — Правила (комбинации условий)

Это графическое представление алгоритма, где фигуры имеют значение:

• Овал: начало или конец процесса

• Прямоугольник: действие или операция

• Ромб: решение (вопрос, от которого идут стрелки «Да» / «Нет»)

• Параллелограмм: ввод или вывод данных

• Линии и стрелки: последовательность шагов

Блок-схемы незаменимы для:

• Документирования сложного бизнес-процесса

• Объяснения логики принятия решений (mock-схема «дерево решений»)

• Проектирования рабочего процесса (диаграмма «плавательных дорожек», показывающая, кто за что отвечает)

Например, блок-схема авторизации будет выглядеть так: (овал «Начало») → (действие «Ввести пароль») →   (ромб «Пароль верен?») → (если да: действие «Вход в систему») → (овал «Конец»).

Источник  

Заключение: собираем пазл

Теперь вы видите полную картину создания качественного ПО:

• User Story определяет ценность для пользователя.

• Use Case описывает поведение и взаимодействие.

• Чек-лист дает быстрый список направлений для проверки.

• Тест-кейс — точную инструкцию для тестировщика.

• Таблица решений помогает справиться со сложной логикой.

• CRUD — это кирпичики, из которых строится любое приложение.

• Блок-схема визуализирует всё вышеперечисленное.

Поздравляем, вы сделали первый шаг  на пути в тестирование! Дальше — больше практики :)