Урок 08.01: Основы тестирования ПО

Цель урока

Познакомиться с основами тестирования программного обеспечения: понять, как аналитик участвует в тестировании, изучить уровни и типы тестирования, освоить базовую структуру тест-кейса, научиться отличать Smoke Test, Regression Test и Acceptance Test. Освоить мета-навык: как не попасть в ловушку, когда продукт идеально соответствует ТЗ, но полностью бесполезен для бизнеса. И как провести UAT с «капризным» заказчиком.

Ключевые понятия

Тестирование (Testing) — процесс проверки соответствия ПО требованиям
Верификация (Verification) — «правильно ли мы создали продукт?» (соответствие спецификации)
Валидация (Validation) — «тот ли продукт мы создали?» (соответствие потребностям)
Тест-кейс (Test Case) — описание шагов, ожидаемого результата и предусловий для проверки одной функции
QA (Quality Assurance) — обеспечение качества (процессы, стандарты, метрики)
QC (Quality Control) — контроль качества (тестирование, проверки)
Bug / Defect — несоответствие ПО требованиям или ожиданиям
UAT (User Acceptance Testing) — приёмочное тестирование заказчиком
Verification Trap — ситуация, когда продукт проходит верификацию (всё по ТЗ), но проваливает валидацию (бизнес-ценность нулевая)

1. Почему аналитик должен понимать тестирование?

1.1. Роль аналитика в тестировании

Этап тестирования	Роль аналитика
Планирование тестов	Определяет, что тестировать (на основе требований)
Написание тест-кейсов	Предоставляет сценарии использования (Happy Path, Error Path)
Тестирование требований	Проверяет требования на полноту и однозначность до передачи разработчикам
UAT (User Acceptance Testing)	Собирает обратную связь от заказчика, фиксирует непринятые сценарии
Анализ дефектов	Помогает классифицировать баги (критические, блокирующие, косметические)
Приёмка результата	Проверяет, что реализация соответствует требованиям

1.2. Аналитик vs Тестировщик

Аналитик	Тестировщик
Проверяет требования (до разработки)	Проверяет код (после разработки)
Отвечает на вопрос «ЧТО делать?»	Отвечает на вопрос «РАБОТАЕТ ЛИ?»
Пишет User Stories и сценарии	Пишет тест-кейсы и чек-листы
Участвует в UAT (с заказчиком)	Участвует в системном и интеграционном тестировании
Отвечает за бизнес-ценность	Отвечает за техническое качество
Проверяет валидацию (тот ли продукт?)	Проверяет верификацию (правильно ли сделали?)

2. Уровни тестирования (Test Pyramid)

Пирамида тестирования (Майк Кон, 2009):

          ╱╲
         ╱  ╲          E2E (End-to-End) — медленно, дорого, мало
        ╱    ╲
       ╱──────╲
      ╱        ╲        Integration — средняя скорость
     ╱          ╲
    ╱────────────╲
   ╱              ╲     Unit — быстро, дёшево, много
  ╱────────────────╲

2.1. Unit-тесты (Модульные)

Что тестируют: Отдельные функции, методы, классы. Кто пишет: Разработчики. Аналитик: Не участвует напрямую, но может дать примеры данных и граничные случаи.

Пример: Проверка функции validateEmail(email):

validateEmail("user@example.com") → true
validateEmail("invalid") → false

2.2. Интеграционные тесты

Что тестируют: Взаимодействие между компонентами (API → БД, Сервис A → Сервис B). Кто пишет: Разработчики / QA-автоматизаторы. Аналитик: Участвует в выборе сценариев (какие интеграции критичны, какие данные передавать).

Пример: Проверка, что после POST /api/v1/tasks задача действительно сохранилась в БД.

2.3. Системное тестирование (E2E)

Что тестируют: Полный сценарий пользователя от начала до конца. Кто пишет: QA-инженеры. Аналитик: Предоставляет бизнес-сценарии, проверяет корректность тест-кейсов.

Пример: Регистрация → Создание проекта → Создание задачи → Назначение исполнителя → Смена статуса → Проверка уведомления.

2.4. UAT (User Acceptance Testing)

Что тестируют: Соответствие бизнес-требованиям. Тестирует заказчик. Кто проводит: Заказчик / представитель бизнеса. Аналитик: Организует UAT: готовит сценарии, сопровождает заказчика, фиксирует проблемы.

3. Типы тестирования

3.1. По времени проведения

Тип	Когда	Смысл
Smoke Test	После первой сборки	«Дымовой тест» — проверка, что система запускается и базовые функции работают
Sanity Test	После исправления бага	Проверка, что конкретная функция починилась
Regression Test	После любого изменения	Всё ли остальное работает? (старая функциональность не сломалась)
Retest	После фикса бага	Проверка, что баг действительно исправлен

3.2. По знанию системы

Тип	Смысл	Пример
Black Box	Тестируем без знания внутренней реализации	Проверяем API, UI — только вход/выход
White Box	Тестируем с пониманием кода	Проверяем, что все ветки if-else покрыты
Gray Box	Частичное знание (знаем БД, но не код)	Проверяем API + смотрим записи в БД

3.3. По цели

Тип	Что ищем
Functional Testing	Соответствие функциональным требованиям
Non-Functional Testing	Производительность, безопасность, удобство
Load Testing	Выдерживает ли система N пользователей
Stress Testing	Как ведёт себя при превышении лимитов
Security Testing	Уязвимости, перехват данных, XSS, SQL-инъекции
Usability Testing	Удобно ли пользователю?
Accessibility Testing	Доступно ли людям с ограничениями?

4. Структура тест-кейса

4.1. Стандартные поля

Поле	Описание	Пример
ID	Уникальный идентификатор	TC-001
Title	Название	«Успешная запись к врачу»
Preconditions	Что должно быть выполнено до теста	Пользователь авторизован, выбран врач
Test Data	Данные для теста	Врач: Иванова А.С., слот: 20.06.2026 10:30
Steps	Шаги (нумерованные)	1. Выбрать врача 2. Выбрать слот 3. Подтвердить
Expected Result	Что должно произойти	Система: «Запись подтверждена», статус 201
Actual Result	Что произошло на самом деле	Заполняется после выполнения
Status	Passed / Failed / Blocked
Severity	Критичность (если Failed)	Blocker / Critical / Major / Minor

4.2. Пример тест-кейса

ID: TC-005
Title: Успешное создание задачи с назначением исполнителя
Preconditions:
  - Пользователь авторизован (токен валиден)
  - В системе есть исполнитель с id=5 (Мария)
Test Data:
  title: "Настроить CI/CD"
  description: "Настроить GitHub Actions"
  assignee_id: 5
  project_id: 1
Steps:
  1. Отправить POST /api/v1/tasks с телом запроса (JSON)
  2. Проверить статус-код ответа
  3. Проверить тело ответа
Expected Result:
  - Статус-код: 201 Created
  - В ответе есть id задачи (integer)
  - В ответе есть title = "Настроить CI/CD"
  - assignee.name = "Мария"
  - status = "To Do"
Actual Result:
  [заполняется тестировщиком]
Status: [Passed / Failed]

5. Классификация дефектов (Severity vs Priority)

Severity	Описание	Пример
Blocker	Система не работает, нет workaround	500 ошибка при входе
Critical	Ключевая функция не работает, есть workaround	Кнопка «Сохранить» не нажимается (можно через Ctrl+S)
Major	Функция работает, но с ограничениями	Отчёт выводится, но без подписей колонок
Minor	Косметический дефект	Кнопка съехала на 2px
Trivial	Опечатка, неправильный цвет	«Записьтся» вместо «Записаться»

Priority	Описание
P1 Critical	Исправить немедленно (до следующего билда)
P2 High	Исправить в этом спринте
P3 Medium	Исправить в ближайшие 2 спринта
P4 Low	Исправить, когда будет время

Важное различие: Severity — техническая характеристика (насколько сильно сломано). Priority — бизнес-характеристика (насколько срочно чинить). Тривиальный баг (опечатка в лицензионном соглашении) может иметь Priority P1 (срочно, юристы настаивают), хотя Severity — Trivial. Blocker в неиспользуемой функции может иметь Priority P4.

6. Тестирование требований (Requirements Testing)

Аналитик проверяет требования ДО того, как разработчик начнёт их реализовывать.

6.1. Чек-лист качества требований

Критерий	Вопрос
Полнота	Все ли сценарии описаны? (включая ошибки)
Однозначность	Могут ли два разработчика понять требование по-разному?
Проверяемость	Можно ли написать тест на это требование?
Согласованность	Не противоречит ли другим требованиям?
Необходимость	Действительно ли это нужно заказчику?
Атомарность	Можно ли разбить на меньшие части?

6.2. Техника: «Тест-кейс для требования»

Хорошее требование: «Система должна проверять email на корректность (формат username@domain.tld)».

Тест-кейсы, которые можно написать:

valid@example.com → ✅ принято
invalid → ❌ ошибка
@example.com → ❌ ошибка
user@ → ❌ ошибка
user@.com → ❌ ошибка
user@домен.рф → ✅ принято (поддержка IDN?)

Если на требование можно написать минимум 3 тест-кейса — оно проверяемо. Если 0 — оно абстрактно.

7. Жизненный цикл бага (Bug Lifecycle)

New → Assigned → In Progress → Resolved → Verified → Closed
       │                                          ↑
       └── Rejected (не баг / дубликат) ───────────┘
                     ↑
                Reopened ← Failed Verification

Статус	Что значит
New	Баг заведён
Assigned	Назначен на разработчика
In Progress	Разработчик чинит
Resolved	Разработчик починил, отдал на проверку
Verified	QA проверил, баг исправлен
Closed	Баг закрыт
Reopened	Баг не исправлен или появился снова
Rejected	Не баг / дубликат / «так задумано»

8. Фундаментальный капкан: верификация пройдена, валидация провалена

8.1. История-предостережение

Кейс из реальной практики:

Крупный ритейлер заказал систему управления складом. ТЗ было написано идеально — 450 страниц, 1200 требований. Команда разработки выполнила всё до буквы. Каждый тест-кейс проходил. Систему приняли по чек-листу. Верификация: 100% пройдена.

Через месяц эксплуатации:

Кладовщики возненавидели систему: чтобы принять товар, нужно было нажать 17 кнопок вместо 3 в старой системе.
Система требовала сканировать каждый артикул по одному — нельзя было принять палету целиком.
Интерфейс был спроектирован «как в ТЗ», но никто не спросил кладовщиков, удобно ли им.
Валидация: 0%. Бизнес потерял 2 месяца и $500 000.

Мораль: Система может соответствовать каждому пункту ТЗ (верификация ✅) и при этом быть бесполезной для бизнеса (валидация ❌).

8.2. Анатомия ошибки: почему так происходит

Причина	Что пошло не так	Как предотвратить
ТЗ писалось без пользователей	Требования собирали у начальника склада, а работают кладовщики	Включить в сбор требований всех ролей пользователей
Бизнес-процесс не моделировался	Не учтён сценарий приёма палеты (80% операций)	BPMN-моделирование as-is и to-be
Тесты проверяли только ТЗ	QA проверяли «кнопка есть? есть», а не «удобно ли?»	UAT с реальными пользователями
Acceptance Criteria не включали UX	Требования: «кнопка сохраняет товар» — но не: «количество кликов — не более 3»	NFR на usability

8.3. Как аналитик защищает проект от Verification Trap

Принцип	Действие
User-Centered Requirements	Каждое требование проверять вопросом: «А пользователь это хочет? А почему?»
Acceptance Criteria с UX	Добавлять критерии: «операция выполняется не более чем за N шагов», «пользователь находит функцию за N секунд»
Прототипирование до разработки	Показать figma/прототип пользователям ДО того, как писать код
UAT с реальными сценариями	Не «нажмите кнопку», а «примите палету из 50 артикулов за 5 минут»
Метрики успеха (KPI)	Заранее определить: «система принята, если время приёмки товара не превышает 3 минут на палету»
Пилотное внедрение	Запустить на 1 складе, собрать feedback, доработать — потом на все 50 складов

8.4. Чек-лист: не попали ли мы в Verification Trap?

Вопрос	Если «нет» — красный флаг
Реальные пользователи видели прототип до разработки?	⚠️
Acceptance Criteria включают сценарии с ошибками?	⚠️
Мы знаем, как пользователи работают сейчас (as-is)?	⚠️
KPI успеха определены ДО начала разработки?	⚠️
В команде есть представитель бизнеса (product owner)?	⚠️
UAT-сценарии основаны на реальных бизнес-операциях?	⚠️
Мы проверяем не только «функция есть», но и «функцией удобно пользоваться»?	⚠️

9. UAT с «капризным» заказчиком: пошаговый гайд

9.1. Психология заказчика на UAT

Типичные страхи заказчика:

Страх	Как проявляется	Что на самом деле
«Меня обманули, система не работает»	Требует всё переделать	Не умеет работать с системой
«Я заплатил, а получил не то»	Отвергает любой результат	Не участвовал в создании требований
«Меня не спросили»	Критикует каждую мелочь	Хочет контроля
«Я потеряю лицо перед начальством»	Находит «критические» баги	Ему нужен безопасный способ принять систему

9.2. Подготовка до UAT

Шаг 1. Согласуйте критерии приёмки заранее

Не за день до UAT, а на этапе подписания требований:

❌ Плохо: «Система должна управлять задачами»
✅ Хорошо: «Заказчик принимает систему, если:
   1. Можно создать задачу из веб-интерфейса
   2. Можно назначить исполнителя
   3. Статус задачи меняется через один клик
   4. Уведомления приходят в течение 1 минуты
   5. Не более 3 кликов для любой основной операции»

Шаг 2. Подготовьте UAT-сценарии на языке бизнеса

Не пишите: «Отправить PATCH /tasks/{id}/status с body {"status":"Done"}». Пишите: «Как начальник отдела, я хочу закрыть задачу, которую выполнил мой сотрудник».

Шаблон UAT-сценария:

Сценарий: Приёмка палеты товаров
Роль: Кладовщик
Бизнес-цель: Принять 50 артикулов за 5 минут
Шаги:
  1. Открыть экран «Приёмка»
  2. Выбрать поставку №12345
  3. Отсканировать первый артикул
  4. Ввести количество — 10 штук
  5. Нажать «Подтвердить»
  6. Повторить для всех 50 артикулов
Критерий успеха: Все 50 артикулов приняты.
Время: не более 5 минут.

Шаг 3. Подготовьте окружение и данные

Что сделать	Почему
Создать тестовые данные, максимально похожие на реальные	Заказчик должен узнать свои бизнес-объекты
Проверить, что окружение стабильно (не упадёт во время UAT)	Каждая техническая ошибка подрывает доверие
Подготовить «запасной план» (если упадёт — перезапустить за 5 минут)	Нельзя терять время заказчика
Сделать скриншоты/видео ожидаемого поведения	Если что-то не работает — показать, как ДОЛЖНО быть

9.3. Демо-сессия перед UAT

За 2–3 дня до UAT проведите brief demo для заказчика (30 минут):

Демо-сессия:
  1. «Мы сделали систему, вот как она работает» (15 мин)
  2. «Давайте вместе пройдём один сценарий» (10 мин)
  3. «Вопросы? Записываю» (5 мин)

Цель: Снять первый шок. Заказчик должен увидеть систему ДО того, как начнёт её «принимать». Если он увидит впервые на UAT — эмоции возьмут верх над рациональностью.

9.4. В день UAT: психологический протокол

Правило 1. Не защищайтесь

Заказчик говорит: «Это ужасно, кнопка не того цвета!»

❌ Неправильно: «Цвет согласован в макете на странице 15 спецификации. Вы подписали — значит, всё в порядке». (Это эскалация конфликта.)
✅ Правильно: «Я понял ваше замечание. Давайте запишем. Посмотрим, насколько это критично для работы». (Вы на его стороне.)

Правило 2. Фиксируйте, не обсуждайте

Заказчик нашёл «баг». Ваша задача — записать, а не объяснить.

❌ Неправильно:
Заказчик: «Задача не удаляется!»
Аналитик: «Потому что вы не автор задачи, у вас нет прав. В ТЗ написано...»
→ Заказчик злится, чувствует себя глупым.

✅ Правильно:
Заказчик: «Задача не удаляется!»
Аналитик: «Понял, записал. Давайте перейдём к следующему сценарию, а это разберём после UAT».
→ Конфликт погашен, заказчик чувствует, что его слышат.

Правило 3. Разделите «баги» и «хотелки»

На UAT заказчик может выдавать новые требования как баги. Ваша задача — классифицировать:

Тип замечания	Пример	Что делать
Баг (не работает по ТЗ)	«При нажатии на кнопку — ошибка 500»	Исправить
Несоответствие ТЗ	«Кнопка должна быть синей, а она зелёная»	Исправить (если в ТЗ было)
Новое требование (хотелка)	«А давайте добавим экспорт в Excel!»	Записать в бэклог, не править сейчас
Неудобство (usability)	«Слишком много кликов»	Оценить влияние, возможно, улучшить

Техника: Спросите: «Эта ошибка блокирует вашу работу или просто непривычно?»

Правило 4. Управляйте временем

UAT не может длиться неделю. Установите временные рамки:

10:00–10:30 — Прогон сценария 1 (создание задачи)
10:30–11:00 — Прогон сценария 2 (назначение и смена статуса)
11:00–11:30 — Прогон сценария 3 (уведомления)
11:30–12:00 — Подведение итогов, вопросы

Если заказчик застревает на мелочи — используйте «парковку»:

«Отличное замечание! Давайте запишем его в парковку и вернёмся к основным сценариям, чтобы успеть всё пройти».

Правило 5. Протоколируйте решения

Сразу после UAT отправьте заказчику протокол:

Протокол UAT от 30.05.2026
Присутствовали: Иванов (заказчик), Петров (аналитик)

Пройдено сценариев: 7/8
Не пройден: Сценарий 5 (уведомления в Slack)

Замечания:
  1. Баг: удаление задачи не работает → исправить до 05.06
  2. Хотелка: добавить экспорт в Excel → записано в бэклог
  3. Уточнение: уведомления должны дублироваться в Telegram → встретиться с продактом

Решение: Система принята с условием исправления бага №1 до 05.06.

9.5. Работа с возражениями: скрипты для аналитика

Возражение заказчика	Ответ аналитика
«Всё не так, переделывайте!»	«Давайте конкретно: что именно не работает? Пройдём сценарий вместе»
«В ТЗ было по-другому»	«Покажите, пожалуйста, в ТЗ этот пункт. Если расхождение — исправим. Если нет — запишем как уточнение»
«Мне некогда тестировать»	«Я подготовил сценарии на 2 часа. Давайте пройдём самые важные — creation, assign, notification»
«Вы меня не слышали»	«Я записал все ваши замечания. Давайте подтвердим список и приоритеты»
«Я не подпишу, пока всё не будет идеально»	«Давайте определим критерии "достаточно хорошо". Система никогда не будет идеальной, но мы можем сделать её рабочей сегодня и улучшать итерационно»

9.6. Что делать, если UAT провален

Признаки провала:

Заказчик отказывается работать с системой
Обнаружено более 30% незакрытых критических сценариев
Заказчик требует полной переделки

План действий:

Не паниковать. Провал UAT — не конец света, а сигнал, что требования были неполными.
Провести пост-мортем. Сесть с заказчиком и выяснить: что именно не так? Какие ожидания не оправдались?
Пересмотреть требования. Если заказчик просит новую функциональность — это не баг, а новое требование. Оценить, вписать в roadmap.
Назначить повторный UAT с исправлениями и чёткими критериями.
Привлечь руководство. Если заказчик «ни в какую» — эскалировать. Возможно, нужен разговор на уровне руководителей проектов.

10. Чек-лист: как аналитик готовится к UAT

№	Действие	Когда сделать
1	Подготовить сценарии UAT (на основе Acceptance Criteria)	За 2 недели до UAT
2	Согласовать сценарии с заказчиком	За 1 неделю до UAT
3	Подготовить тестовые данные (реалистичные)	За 3 дня до UAT
4	Проверить, что окружение UAT стабильно	За 1 день до UAT
5	Познакомить заказчика с системой (brief demo)	За 2 дня до UAT
6	Задокументировать ожидаемые результаты по каждому сценарию	За 3 дня до UAT
7	Научить заказчика фиксировать баги (скриншот + шаги)	За 1 день до UAT
8	После UAT — собрать обратную связь, классифицировать	В день UAT
9	Отправить протокол UAT на подпись	На следующий день после UAT
10	Отследить исправление багов до повторного UAT	Ежедневно после UAT

Вопросы для самопроверки

Чем верификация отличается от валидации?
Какие 4 уровня тестирования вы знаете?
Что такое Smoke Test? Когда он выполняется?
Что такое Regression Test? Почему он важен?
Какие поля обязательно должны быть в тест-кейсе?
Чем Severity отличается от Priority?
Как проверить, что требование «проверяемо»?
Что такое Verification Trap? Приведите пример из жизни.
Почему на UAT важно фиксировать замечания, а не обсуждать их?
Как отличить «баг» от «хотелки» заказчика на UAT?
Какие 5 психологических страхов движут «капризным» заказчиком?
Что делать, если UAT провален?

Практическое задание

Задание 1. Напишите тест-кейсы

Для User Story ниже напишите 3 тест-кейса: Happy Path, Error Path, Edge Case.

User Story:

Как пользователь Task Manager, я могу изменить статус задачи на Done, чтобы отметить, что задача выполнена.

Acceptance Criteria:

Пользователь может изменить статус через PATCH /api/v1/tasks/{id}/status
Статус меняется только с «In Progress» на «Done» (другие переходы — ошибка)
Если задача была назначена тестировщику — после Done она переходит в «Testing» (автоматически)
Если исполнитель — автор задачи, статус меняется на «Done»
После изменения статуса система возвращает обновлённую задачу

Формат тест-кейса:

ID, Title, Preconditions, Steps, Expected Result

Задание 2. Классифицируйте баги

Даны 5 багов. Определите Severity (Blocker/Critical/Major/Minor) и Priority (P1–P4):

Баг	Severity	Priority
При нажатии «Сохранить задачу» — 500 ошибка, задача не создаётся
Название задачи отображается шрифтом на 1px меньше, чем в макете
При смене статуса на Done задача не переходит тестировщику, а остаётся у исполнителя
При вводе email без «@» система принимает его как валидный
Кнопка «Удалить задачу» не имеет подтверждения — удаляет сразу без диалога

Задание 3. Проверьте требования на проверяемость

Требование: «Система должна быть быстрой и удобной».

Почему это требование непроверяемо? Перепишите его так, чтобы оно стало проверяемым (укажите метрики).

Задание 4. Verification Trap (анализ кейса)

Кейс: Разработана система управления задачами. Все функциональные требования выполнены. QA подтвердил: все тест-кейсы проходят. Но после запуска пользователи жалуются:

«Я не могу быстро найти свою задачу — нет поиска»
«Чтобы создать задачу, нужно заполнить 10 полей — это долго»
«Я ожидал, что уведомления будут в Telegram, а они по email»
«Невозможно прикрепить файл к задаче»

Вопросы:

Система прошла верификацию? А валидацию? Почему?
Какие из этих жалоб — недостаток требований (не собрали), а какие — недостаток тестирования?
Что нужно было сделать на этапе сбора требований, чтобы избежать этих проблем?

Задание 5. Сценарий UAT

Представьте, что вы — аналитик, завтра UAT с заказчиком Иваном Петровичем. Он известен тем, что:

Придирчив к мелочам
Не любит работать с новыми системами («и старая работала»)
Имеет привычку говорить «всё не так» без конкретики

Напишите план UAT:

Какие сценарии подготовите? (3–4 сценария)
Как построите демо?
Как ответите, если Иван Петрович скажет: «Кнопки не того цвета, всё переделывать»?
Что сделаете, если он откажется подписывать протокол?

Дополнительные материалы

Книга: Роман Савин — «Тестирование Дот Ком» — введение в тестирование на русском
Книга: Святослав Куликов — «Тестирование ПО. Базовый курс»
Книга: Майк Кон — «Scrum: гибкая разработка ПО» — пирамида тестирования
Стандарт: ISTQB — International Software Testing Qualifications Board — глоссарий и основные концепции
Статья: Martin Fowler — «Verification and Validation» — фундаментальное различие
Шпаргалка: «Test Case Template» — шаблон тест-кейса в Excel/Google Sheets
Инструмент: Postman — тестирование API (можно писать тесты на JavaScript)
Инструмент: Jira / Yandex Tracker / YouTrack — трекинг багов