Manual Testing

БЛОК 4. Тест-дизайн техники — 11. Основы тест-дизайна

📚 25 вопросовПройти тест →
Лекция

БЛОК 4. Тест-дизайн техники — 11. Основы тест-дизайна

Manual Testing

БЛОК 4. Тест-дизайн техники — 11. Основы тест-дизайна

🧭 Введение: зачем QA нужен тест-дизайн

Когда junior QA начинает работу, чаще всего он проверяет фичу «как чувствует»: нажал кнопку, прошёл по форме, посмотрел пару ошибок. Такой подход иногда ловит баги, но не даёт стабильного качества.
Тест-дизайн нужен, чтобы проверки были не случайными, а системными и повторяемыми. Это способ превратить «интуитивное тестирование» в понятный план с осознанным покрытием рисков.
💡 Совет:
Если не можете объяснить, почему проверяете именно эти сценарии, значит тест-дизайн ещё не собран.
✅ Вывод:
Тест-дизайн — это фундамент, на котором строятся сценарии, тест-кейсы и релизные решения.

⚠️ Проблема -> решение

Проблема начинающего QA: много проверок, но покрытие непонятно. Команда не видит, что уже проверено, а что пропущено. В итоге дефекты всплывают поздно, а время тратится хаотично.
Решение — использовать базовый каркас тест-дизайна:
  • понять объект проверки;
  • выделить риски и ограничения;
  • выбрать техники;
  • зафиксировать покрытие и expected result.
🟢 Если совсем просто:
Тест-дизайн отвечает на вопрос: «что и почему мы проверяем».
🎯 Как понять, что этап прошёл успешно:
По фиче есть структурированный набор проверок, который можно защитить на ревью и выполнить повторно.

🛠️ Чем помогает и как работает

Тест-дизайн помогает QA и команде говорить на одном языке: что критично, что в приоритете, где риски релиза. Он уменьшает пропуски и делает тестирование предсказуемым.
Как это работает:
  • Шаг 1: анализируем требования и контекст фичи.
  • Шаг 2: определяем типы рисков (бизнес, данные, интеграции, UX).
  • Шаг 3: выбираем подходящие техники тест-дизайна.
  • Шаг 4: строим набор сценариев и тестовых данных.
  • Шаг 5: фиксируем expected result и приоритеты.
  • Шаг 6: выполняем, обновляем покрытие и корректируем набор после дефектов.
✅ Вывод:
Тест-дизайн соединяет требования, риски и практическое выполнение в единую систему.

📚 Ключевые термины (простыми словами)

  • Test Design (тест-дизайн) — процесс проектирования проверок до их выполнения.
  • Test Scenario (тестовый сценарий) — проверяемый поток поведения на высоком уровне.
  • Test Case (тест-кейс) — детальная проверка с шагами, данными и expected result.
  • Coverage (покрытие) — насколько полно проверки закрывают требования и риски.
  • Risk (риск) — вероятность и влияние дефекта на продукт.
  • Test Data (тестовые данные) — подготовленные значения для проверки.
  • Expected Result (ожидаемый результат) — чёткое описание правильного итога.
  • Prioritization (приоритизация) — порядок выполнения проверок по риску и ценности.

1. Что такое тест-дизайн на практике

Тест-дизайн — это не отдельный документ «для галочки», а рабочий процесс мышления QA перед execution. Хороший тест-дизайн сразу отвечает, какие проверки обязательны, какие дополняющие, какие можно отложить.
🟢 Если совсем просто:
Тест-дизайн — это план проверки с логикой, а не случайный список действий.
🎯 Как понять, что этап прошёл успешно:
Вы можете объяснить, откуда взялась каждая проверка: из требования, риска или инцидента.
Назначение:
Сделать тестирование управляемым, воспроизводимым и прозрачным для команды.
Простыми словами:
QA заранее проектирует карту проверок, а не «пробует наугад».
Для новичка:
Если перед тестированием у вас есть структура «что проверяю и почему», вы уже делаете тест-дизайн.
Аналогия:
Как план строительства: сначала проект, потом стройка. Без проекта результат случайный.
Пример:
Фича: РегистрацияТест-дизайн:- Happy path- Negative по валидации- Boundary по длине пароля- Edge: double submit, timeout API
🔎 Как это происходит на практике:
  • QA получает задачу и AC.
  • Делает первичный черновик покрытия.
  • Сверяет его с рисками и обратной связью команды.
Характеристики:
  • ✅ Осознанное покрытие вместо хаоса.
  • ✅ Повторяемость проверок.
  • ✅ Прозрачность для ревью и релиза.
Когда использовать:
Всегда, даже для небольших задач.
✅ Вывод:
Тест-дизайн — это обязательный этап зрелой QA-работы, а не опциональный бонус.

1.1 Тест-дизайн vs тест-документация

Эта путаница очень частая у junior QA: «если я написал тест-кейс, значит тест-дизайн сделан». На практике это разные вещи, хотя они тесно связаны.
🟢 Если совсем просто:
Тест-дизайн — это мышление и проектирование покрытия, документация — это способ зафиксировать результат.
🎯 Как понять, что этап прошёл успешно:
Сначала у вас есть логика покрытия (почему и что проверяем), и только потом она аккуратно оформлена в сценарии/кейсы/чек-листы.
Разделение:
  • Тест-дизайн — как думаем, выбираем техники, строим покрытие и приоритеты.
  • Тест-документация — как фиксируем результат дизайна: сценарии, тест-кейсы, чек-листы.
✅ Вывод:
Написанный тест-кейс без проектирования покрытия не гарантирует качественный тест-дизайн.

2. Откуда берётся хороший тест-дизайн

Сильный набор проверок не рождается «из головы». Он собирается из источников, которые дают контекст и реальные риски.
🟢 Если совсем просто:
Нет источников -> нет качественного тест-дизайна.
🎯 Как понять, что этап прошёл успешно:
Каждая ключевая проверка связана с конкретным источником.
Назначение:
Построить покрытие на фактах, а не на догадках.
Простыми словами:
Сначала собираем информацию, потом проектируем проверки.
Для новичка:
Если не читали AC и не посмотрели прошлые дефекты, вы проектируете вслепую.
Пример:
Источники:1) Требования и acceptance criteria2) Бизнес-риски3) Архитектура и интеграции4) История дефектов/инцидентов5) Ограничения релиза (время, окружение)
🔎 Как это происходит на практике:
  • QA на grooming фиксирует неясности.
  • На основе ответов обновляет карту проверок.
  • Перед execution сверяет покрытие с релизными рисками.
Характеристики:
  • ✅ Меньше «внезапных» пробелов.
  • ✅ Легче объяснить приоритеты.
  • ✅ Лучше качество коммуникации в команде.
Когда использовать:
На старте каждой задачи и перед релизом.
✅ Вывод:
Качество тест-дизайна напрямую зависит от качества входной информации.

3. Базовый каркас покрытия для junior QA

Чтобы не теряться, удобно использовать фиксированный каркас. Он подходит почти для любой продуктовой фичи и помогает быстро оценить полноту покрытия.
🟢 Если совсем просто:
Один каркас = меньше пропусков и меньше хаоса.
🎯 Как понять, что этап прошёл успешно:
В наборе есть все ключевые категории проверок.
Назначение:
Системно собрать минимально достаточный набор сценариев.
Простыми словами:
Это чек-лист, который не даёт забыть важные типы проверок.
Для новичка:
Если сомневаетесь, с чего начать, идите по этому каркасу сверху вниз.
Пример каркаса:
1) Happy path2) Negative scenarios3) Boundary values4) Edge cases5) Роли и доступы (если есть)6) Интеграционные риски
🔎 Как это происходит на практике:
  • QA заполняет каркас для новой фичи.
  • Помечает критичные пункты.
  • Уточняет у команды спорные места до execution.
Характеристики:
  • ✅ Быстрый старт даже для сложных фич.
  • ✅ Хорошая база для тест-кейсов.
  • ✅ Удобно использовать на ревью.
Когда использовать:
Для любой новой задачи и для регресса после изменений.
✅ Вывод:
Каркас покрытия — лучший инструмент junior QA для стабильного качества.

3.1 Глубина тест-дизайна: разная для разных задач

Ещё одна важная практика: тест-дизайн не всегда должен быть «большим и формальным». Глубина зависит от критичности задачи, рисков и цены ошибки.
🟢 Если совсем просто:
Чем выше риск задачи, тем глубже нужен тест-дизайн.
🎯 Как понять, что этап прошёл успешно:
Вы выбрали достаточную глубину дизайна для задачи, не создавая лишнего формализма.
Практическое правило:
  • Маленькая задача: краткое сценарное покрытие.
  • Средняя задача: сценарии + тестовые данные + приоритет.
  • Критичная задача: полный набор техник + явная матрица рисков.
✅ Вывод:
Хороший QA подбирает глубину тест-дизайна под контекст задачи, а не копирует один шаблон на всё.

4. Как выбирать технику под задачу

Тест-дизайн — это не одна техника, а комбинация. Важно понимать, когда какая техника приносит максимальную пользу.
🟢 Если совсем просто:
Разные риски требуют разных инструментов.
🎯 Как понять, что этап прошёл успешно:
Вы можете объяснить, почему в задаче использованы именно эти техники.
Назначение:
Сделать проверки точными и экономными по времени.
Простыми словами:
Не каждая техника нужна всегда; выбираем по типу проблемы.
Для новичка:
Берите 2–3 базовые техники под задачу, а не все сразу.
Пример:
Если есть диапазоны и лимиты -> Boundary ValueЕсли есть множество вариантов ввода -> Equivalence PartitioningЕсли есть много бизнес-правил -> Decision TableЕсли поведение зависит от статуса -> State Transition
🔎 Как это происходит на практике:
  • QA смотрит на требования.
  • Выбирает техники под тип риска.
  • Фиксирует технику рядом со сценарием.
Характеристики:
  • ✅ Экономит время на лишних проверках.
  • ✅ Увеличивает точность покрытия.
  • ✅ Облегчает ревью тест-дизайна.
Когда использовать:
На этапе проектирования проверок перед execution.
✅ Вывод:
Выбор техники по задаче — ключевой навык перехода от junior к strong junior.

5. Пошаговый алгоритм тест-дизайна (готовый шаблон)

Ниже простой алгоритм, который можно применять сразу в ежедневной работе.
🟢 Если совсем просто:
Требования -> риски -> техники -> сценарии -> данные -> приоритет.
🎯 Как понять, что этап прошёл успешно:
По задаче собран исполнимый и объяснимый набор проверок.
Алгоритм:
  1. Прочитать AC и выписать ограничения.
  2. Определить ключевые пользовательские потоки.
  3. Отметить риски (данные, бизнес, интеграции).
  4. Выбрать техники под каждый риск.
  5. Сформировать сценарии и test data.
  6. Зафиксировать expected result.
  7. Проставить priority и подготовить run order.
✅ Вывод:
Этот шаблон помогает junior QA работать системно даже в новых для себя доменах.

📊 Сравнение: ad-hoc проверки vs тест-дизайн

ПодходКак работаетРиск
Ad-hoc (хаотично)Проверяем «что вспомнили»Высокий риск пропусков
Тест-дизайн (системно)Проверяем по структуре и рискамКонтролируемый риск

✅ Must-Know для junior QA

  • Тест-дизайн начинается до execution.
  • Без expected result проверка неполная.
  • Покрытие должно быть связано с AC и рисками.
  • Один и тот же сценарий можно усилить разными техниками.
  • Приоритет проверок должен быть risk-based.
  • История инцидентов — важный источник новых проверок.
  • Хороший тест-дизайн уменьшает споры на triage и релизе.

❌ Частые мифы

❌ Миф:
Тест-дизайн нужен только на больших проектах. ✅ Как правильно:
Он нужен в любой задаче, просто глубина может быть разной. 📎 Почему это важно:
Даже маленькие фичи ломаются из-за пропущенных рисков.
❌ Миф:
Достаточно написать много тест-кейсов. ✅ Как правильно:
Важно не количество, а обоснованное покрытие. 📎 Почему это важно:
Много слабых кейсов не заменяют структурный дизайн.
❌ Миф:
Тест-дизайн — это теория, не нужная в ежедневной работе. ✅ Как правильно:
Это практический инструмент планирования проверок и приоритизации. 📎 Почему это важно:
Без него тестирование становится случайным и дорогим.
❌ Миф:
Junior не должен думать о рисках. ✅ Как правильно:
Оценка рисков — базовый навык QA любого уровня. 📎 Почему это важно:
Именно риски определяют, что проверять в первую очередь.

❓ Часто спрашивают на собеседованиях

❓ Вопрос:
Что такое тест-дизайн? ✅ Ответ:
Это процесс проектирования проверок на основе требований, рисков и техник тестирования до выполнения тестов.
❓ Вопрос:
Чем тест-дизайн отличается от написания тест-кейсов? ✅ Ответ:
Тест-дизайн определяет что и почему проверять, а тест-кейсы фиксируют как именно это выполнять пошагово.
❓ Вопрос:
С чего начать тест-дизайн в новой задаче? ✅ Ответ:
С анализа AC, выделения рисков и построения базового каркаса покрытия: happy, negative, boundary, edge.
❓ Вопрос:
Как понять, что покрытие достаточное? ✅ Ответ:
Когда закрыты критичные потоки и риски, у сценариев есть expected result и явная связь с требованиями.
❓ Вопрос:
Почему приоритизация важна в тест-дизайне? ✅ Ответ:
Потому что время ограничено, и сначала нужно проверять то, что сильнее всего влияет на релизный риск.

🚫 Типичные ошибки

Ошибка 1: Начинать тестирование без проектирования

❌ Неправильно:
Сразу идти в execution без карты покрытия.
✅ Правильно:
Сначала собрать базовый тест-дизайн и приоритеты.
Почему:
Иначе проверки хаотичны и дают ложное ощущение полноты.

Ошибка 2: Проверки без связи с требованиями

❌ Неправильно:
Писать сценарии, которые нельзя связать с AC или рисками.
✅ Правильно:
Для каждой ключевой проверки фиксировать источник.
Почему:
Это упрощает ревью и релизное обоснование.

Ошибка 3: Нет expected result

❌ Неправильно:
Формулировки «проверить форму» без критериев успеха.
✅ Правильно:
Всегда прописывать ожидаемый результат.
Почему:
Без этого pass/fail становится субъективным.

Ошибка 4: Нет risk-based приоритизации

❌ Неправильно:
Выполнять тесты в произвольном порядке.
✅ Правильно:
Сначала закрывать critical/high риски.
Почему:
Так снижается шанс пропустить блокирующий дефект до релиза.

🧩 Best Practices

  • Делайте короткий тест-дизайн-черновик до написания тест-кейсов.
  • Используйте стандартный каркас покрытия для каждой фичи.
  • Для каждой проверки фиксируйте expected result.
  • Указывайте источник сценария: AC, риск, инцидент.
  • Применяйте 2–3 техники осознанно, а не «все сразу».
  • Обновляйте тест-дизайн после изменений требований и прод-багов.

🏁 Заключение

Основы тест-дизайна — это ключевой навык, который делает QA полезным для команды уже на junior-уровне.
Он помогает проверять не «много», а «правильно» и с прицелом на риск.
Если вы научитесь стабильно проектировать проверки до execution, ваши результаты станут предсказуемыми, а ценность для команды — заметно выше.
🎯

Проверьте знания

Закрепите материал — пройдите тест по теме «БЛОК 4. Тест-дизайн техники — 11. Основы тест-дизайна»

Пройти тест →