Расширенные техники тестирования. Тестовые сценарии. Позитивные и негативные тесты

1. Лекция 1

РАСШИРЕННЫЕ ТЕХНИКИ ТЕСТИРОВАНИЯ. ТЕСТОВЫЕ СЦЕНАРИИ.
ПОЗИТИВНЫЕ И НЕГАТИВНЫЕ ТЕСТЫ

2. Расширенные техники тестирования: позитивные и негативные сценарии

Расширенные техники позволяют
глубже понять поведение системы
Позитивные сценарии — проверка «как
должно работать»
Негативные сценарии — проверка «как
не должно работать»
Баланс двух подходов обеспечивает
полноту тестирования
Цель лекции: научиться тестировать
системно — выбирать техники, которые
находят неочевидные ошибки.
Проблема: отдельные тесты часто не
покрывают пересечения бизнес-правил
→ критические инциденты
План лекции:
Расширенные техники тестирования: позитивные и негативные
сценарии
Что такое расширенные техники тестирования
Тестовый сценарий и тестовый случай: в чём разница?
Что такое тестовый сценарий?
Структура тестового случая
Позитивные сценарии: что это и зачем нужны
Примеры позитивных сценариев
Негативные сценарии: что это и зачем нужны
Примеры негативных сценариев
Комбинирование позитивных и негативных сценариев
Документирование сценариев и случаев
Инструменты для управления тестами
Приоритеты и классификация тестов
Расширенные техники тест-дизайна
Итоги и рекомендации

3. Что такое расширенные техники тестирования

Расширенные техники тестирования – это набор приёмов, которые помогают:
Находить больше ошибок, чем при обычной проверке
Проверять сложные случаи, которые сложно придумать на ходу
Экономить время и силы тестировщика
Повышать качество продукта

4. Тестовый сценарий и тестовый случай: в чем разница?

Тестовый сценарий — описание общей последовательности действий для
проверки.
Тестовый случай (Test Case) — детализированная инструкция с шагами,
входными данными и ожидаемым результатом.
Сценарий — «что проверяем», случай — «как именно проверяем».

5. Что такое тестовый сценарий?

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

6. Структура тестового случая (test case)

Идентификатор (уникальный номер)
Название теста (чтобы было понятно, что проверяем)
Предусловия (что должно быть готово перед началом проверки)
Шаги (последовательность действий)
Ожидаемый результат (что должно получиться, если всё работает правильно)
Постусловия (что нужно сделать после теста, если это требуется)
Дополнительно: приоритет, версия, автор
Пример простого тест-кейса:
Название: Проверка входа с валидными данными
Шаги: Ввести корректный логин и пароль → нажать на кнопку «Войти»
Ожидаемый результат: Система перенаправляет на главную страницу

7. Позитивные сценарии: что это и зачем нужны

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

8. Примеры позитивных сценариев

Позитивные сценарии — это тесты, проверяющие работу системы при корректных действиях и данных.
Примеры:
Успешная авторизация с корректными данными (логин + пароль).
Оформление заказа с товаром, который есть в наличии, и корректной оплатой.
Отправка формы с правильно заполненными обязательными полями.
Создание нового пользователя с уникальным email и валидными данными.
Загрузка файла допустимого формата и размера.
Поиск существующего товара по ключевому слову.
Просмотр страницы товара без ошибок отображения.
Обновление профиля с корректными данными и успешным сохранением.
Особенности позитивных сценариев:
Проверяют «основной путь» (happy path)
Подтверждают, что ключевые функции работают при правильных условиях
Используются для базовой валидации перед сложными тестами

9. Негативные сценарии: что это и зачем нужны

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

10. Примеры негативных сценариев

Ввод некорректных данных (пустые поля, неверный формат, слишком длинные
значения)
Действия вне логики системы (повторная отправка формы, отмена операции
на середине)
Ограничения и лимиты (превышение допустимого размера файла, частоты
запросов)
Внешние сбои (отключение интернета, отказ стороннего сервиса,
недоступность базы данных)
Попытки обойти правила (SQL-инъекции, XSS, использование устаревших
токенов)

11. Комбинирование позитивных и негативных сценариев

Смешение успешных и ошибочных действий в одном тестовом пути
Проверка системы на устойчивость к нестандартным комбинациям
Оценка поведения интерфейса при частично корректных данных
Имитация реальных условий работы, где ошибки и успехи идут
вперемешку
Важность для выявления "пограничных" и трудноуловимых дефектов

12. Документирование сценариев и случаев

Формат хранения тестовых сценариев (таблицы, тест-менеджментсистемы)
Единообразие структуры описания
Обязательные поля: идентификатор, название, предусловия, шаги,
ожидаемый результат, статус
Версионирование и актуализация документов
Доступность документации для команды

13. Инструменты для управления тестами

Цель: централизация и систематизация тестовой документации
Популярные системы: TestRail, Zephyr, Qase, Xray, PractiTest
Интеграция с баг-трекингом и CI/CD
Возможности: хранение кейсов, запуск тестов, отчётность, аналитика
Критерии выбора инструмента: масштаб команды, интеграции, бюджет

14. Приоритеты и классификация тестов

Приоритеты: определяют, какие сценарии тестировать в первую очередь
Высокий приоритет: критический функционал (авторизация, оплата, оформление заказа)
Средний приоритет: функционал, влияющий на удобство, но не блокирующий работу
Низкий приоритет: косметические изменения, редко используемые функции
Классификация: помогает структурировать тесты
По типу: функциональные, нефункциональные, интеграционные, нагрузочные, UI/UX-тесты
По частоте запуска: регрессионные, smoke, sanity.
По критичности: must-have, should-have, nice-to-have.
Зачем:
Рациональное распределение ресурсов команды
Сокращение времени тестирования без потери качества
Чёткое понимание, что тестировать в первую очередь.

15. Расширенные техники тест-дизайна

Расширенные техники позволяют повысить эффективность тестирования и покрыть больше
возможных сценариев с меньшими затратами.
Основные методы:
Тестирование по таблице принятия решений — проверка работы системы при
комбинации разных условий и действий.
Техника переходов состояний — моделирование поведения системы в зависимости от
её текущего состояния.
Техника "Use Case" — тестирование на основе пользовательских сценариев и целей.
Техника парного тестирования (Pairwise Testing) — минимизация количества тестов при
сохранении высокого покрытия комбинаций.
Техника "Предугадывание ошибки" (Error Guessing) — поиск дефектов на основе опыта
и интуиции тестировщика.
Техника "Exploratory Testing" — исследовательское тестирование без заранее жёстко
прописанных шагов.
Гранчиные значения + Классы эквивалентности — расширенные методы работы с
граничными и эквивалентными значениями.

16. Итоги и рекомендации

Позитивные и негативные сценарии — база надёжного тестирования
Документирование и приоритизация — ключ к эффективности
Освойте расширенные техники тест-дизайна

17. Лекция 2

РАСШИРЕННЫЕ ТЕХНИКИ ТЕСТИРОВАНИЯ. ТЕСТОВЫЕ СЦЕНАРИИ.
ПОЗИТИВНЫЕ И НЕГАТИВНЫЕ ТЕСТЫ

18. Частые ошибки при составлении позитивных и негативных сценариев

Недостаточная детализация шагов — сценарий слишком общий, нет
конкретных действий пользователя
Пропуск граничных условий — не учитываются минимальные и
максимальные значения, крайние варианты поведения системы
Смешивание сценариев — в одном сценарии проверяется сразу несколько
разных функций, что затрудняет анализ результатов
Неявные предположения — тестировщик не фиксирует условия, которые
должны выполняться перед тестом
Отсутствие проверок (expected result) — нет чётких критериев, по которым
определяется успех или провал теста
Слишком сложные сценарии для начала — новички пытаются сразу писать
комбинированные сценарии, вместо простых и понятных
Неверное понимание негативных сценариев — думают, что негативный
сценарий — это "сломать всё", а не корректная проверка на ошибки

19. Граничные значения и классы эквивалентности

Классы эквивалентности: группировка входных данных на
категории, где поведение системы одинаково
Граничные значения: тестирование минимальных, максимальных и
ближайших значений к ним
Применяются для сокращения количества тестов без потери
качества
Особое внимание — пограничным точкам, где чаще всего
встречаются ошибки

20. Переход от требований к сценариям

Анализ требований → определение функций и ограничений
системы
Выделение ключевых бизнес-процессов
Построение пользовательских сценариев (use cases)
Преобразование сценариев в тестовые случаи
Проверка полноты покрытия требований тестами

21. Валидация данных

Что это: проверка правильности, полноты и
соответствия данных заданным требованиям
Цели:
Обеспечить корректность ввода
Предотвратить ошибки при обработке данных
Увеличить устойчивость системы
Что проверять:
Формат данных (email, телефон, дата)
Диапазоны значений (возраст ≥ 18)
Наличие обязательных полей
Уникальность данных
Примеры:
Поле “Email” – содержит символ @
и домен
Поле “Возраст” – целое число от 18
до 99
Пароль – минимум 8 символов,
есть буквы и цифры

22. Минимизация и оптимизация тестов

Избыточное количество тестов = лишние затраты времени и ресурсов
Оптимизация ≠ сокращение качества тестирования
Цели минимизации:
Убрать дубликаты тестов
Упростить избыточные сценарии
Сконцентрироваться на критичных проверках
Методы оптимизации:
Анализ покрытия требований – убрать тесты, которые проверяют одно и то же
Приоритизация – сначала тесты высокого риска
Техники тест-дизайна (классы эквивалентности, граничные значения и др.)
Параметризация тестов – один тест вместо множества похожих
Рефакторинг тест-кейсов – упрощение шагов и объединение проверок

23. Тестовые данные и их подготовка

Качественные тестовые данные должны сочетать в себе следующие
аспекты:
Реалистичность: данные должны отражать реальные условия
Разнообразие: включайте и нормальные, и экстремальные значения
Чистота: исключайте случайные ошибки в подготовке данных
Автоматизация: используйте скрипты или генераторы данных, чтобы
экономить время
Разделение окружений: тестовые данные должны быть изолированы от
“боевых”
Повторяемость: тест должен давать одинаковый результат при
одинаковых входных данных

24. Понятие “тестовые условия” (Test Conditions)

Что это?
Высокоуровневое описание того, что нужно протестировать
Представляет собой аспект функционала или критерий проверки
Примеры:
Поле ввода e-mail должно принимать только корректный формат адреса
Пользователь может успешно авторизоваться с верными данными
При попытке ввести пароль меньше 8 символов выводится ошибка
Зачем нужны:
Служат основой для написания тестовых сценариев
Помогают убедиться, что ни одна важная проверка не забыта
Упрощают коммуникацию с командой — понятны и тестировщику, и аналитику
Отличие от сценария:
Тестовое условие — что проверяем
Тест-сценарий — как и с какими данными проверяем

25. Как понять, что сценариев достаточно

1. Покрытие тестами (Coverage)
Покрытие требований: все требования имеют хотя бы один тест
Покрытие кода: сколько строк или веток программы проверяются тестами.
2. Баланс между полнотой и затратами
100% протестировать невозможно
Выбираем тесты, которые дают наибольшую ценность
3. Признаки достаточного набора тестов
Все ключевые требования проверены
Есть тесты на позитивные и негативные сценарии
Границы и особые условия протестированы
Риски системы учтены
4. “Пирамида тестирования”
Unit-тесты — быстрые и дешёвые
Интеграционные — проверяют взаимодействие частей
UI-тесты — проверяют работу с точки зрения пользователя

26. Почему одни тесты ломаются, а другие живут годами

Причины «ломающихся» тестов:
Жёсткая привязка к интерфейсу (локаторы, тексты кнопок)
Тест зависит от нестабильных данных
Логика теста слишком сложная и хрупкая
Тест проверяет не то, что реально нужно (лишние зависимости)
Причины «долго живущих» тестов:
Проверяют стабильную и важную бизнес-логику
Минимум зависимости от мелочей интерфейса
Чётко отделены тестовые данные от сценария
Лёгкие в поддержке и понятные другим тестировщикам
Главная идея:
Тест «живёт долго», если он написан под устойчивые требования, а не под
«временный» внешний вид.

27. Ошибки новичков при применении техник тест-дизайна

1. Формальное применение
Используют технику “по инструкции”, не думая о сути
Пример: нарисовали таблицу эквивалентных классов, но забыли про реальные пользовательские
данные
2. Перепутанные границы
Ошибки в определении минимального и максимального значения
Часто забывают про «+1» и «-1» к границам
3. Избыточные тесты
Проверяют одно и то же несколько раз, теряя время
Пример: тестируют все 50 значений из диапазона, хотя техника говорит — 2–3 достаточно
4. Пропущенные важные случаи
Фокус на позитивных тестах, забывают о негативных
Не учитывают нестандартные или редкие сценарии
5. Путаница техник
Смешивают несколько техник и не понимают, какая что даёт
Пример: пытаются применить таблицу принятия решений там, где нужна проверка граничных значений
6. Игнорирование реального контекста
Выбирают тесты по технике, но не учитывают бизнес-логику и приоритеты

28. Итог двух лекций: от основ до продвинутых техник тестирования

Мы разобрали:
Роль тестирования в жизненном цикле разработки
Позитивные и негативные сценарии — как и когда их использовать
Техники тест-дизайна: граничные значения, классы эквивалентности, комбинаторика
Как перейти от требований к тестовым сценариям
Методы валидации и проверки данных
Подходы к подготовке тестовых данных
Минимизация и оптимизация тестов без потери качества
Мы научились:
Выделять ключевые проверки, не упуская важные детали
Строить тестовые сценарии, которые легко воспроизвести и проверить
Избегать избыточности и дубликатов
Создавать тестовые данные, которые покрывают все нужные ситуации
Главный вывод:
Хорошее тестирование — это не только поиск ошибок, но и грамотная организация проверок, где каждая
проверка обоснована и даёт ценную информацию о качестве продукта.

29. Спасибо за внимание!