🧠 Что такое тест-дизайн (по-человечески)

Тест-дизайн — это этап, на котором мы решаем:

• что именно будем проверять;
• какими тестами это проверим;
• какими данными будем пользоваться.

То есть тест-дизайн — это мостик между ТЗ и реальными тест-кейсами.

💡 Без тест-дизайна тестировщик просто «тыкает куда попало».
💡 С тест-дизайном — работает по понятной системе и ловит больше багов меньшим количеством тестов.

🎯 Цели тест-дизайна

Зачем вообще всё это нужно:

• 🐛 Находить самые серьёзные ошибки — особенно там, где система ломается по-настоящему.
• ✂️ Уменьшить количество тест-кейсов — не проверять 1000 вариантов, если достаточно 10 умных.
• ⏱️ Сократить время на тестирование — тестов меньше, а пользы больше.

🧩 Этапы тест-дизайна

Очень упрощённо:

1. Анализ материалов
   Читаем:
• требования,
• спецификации,
• макеты,
• схемы,
• иногда даже код.
  Задача — понять: что должен делать продукт.
2. (Иногда) спецификация тест-дизайна
   Это документ, где мы фиксируем:
• подход к тестированию,
• какие техники используем,
• что считаем приоритетом.
  Это не обязательно, но полезно для командной работы.
3. Проектирование тест-кейсов
   Используем техники тест-дизайна и превращаем их:
• в конкретные сценарии,
• в набор тестовых данных.

🧰 Какие бывают техники тест-дизайна?

Техники — это инструменты, которые помогают:

• определить, какие данные взять;
• какие случаи обязательно проверить;
• как сократить количество тестов, не потеряв качество.

Их делят на три большие группы:

1. 🎱 Техники чёрного ящика
   Смотрим только на поведение системы:
   «что на вход — что на выход».
   Код нас не волнует.
2. ⚙️ Техники белого ящика
   Смотрим во внутренности:
   «как устроен код, какие ветки, циклы».
   Обычно это зона разработчиков / автотестов на уровне кода.
3. 🧪 Техники, основанные на опыте
   Используем:
• собственный опыт,
• знание типичных багов,
• историю проекта.
  Сюда относятся, например, прогнозирование ошибок.

В этой карточке мы фокусируемся на чёрном ящике, потому что это база для ручного тестировщика.

1️⃣ Эквивалентное разбиение (эквивалентные классы) ⚖️

🧩 Суть техники

Эквивалентное разбиение — это когда мы делим все возможные входные значения на группы (классы), внутри которых значения «ведут себя одинаково» для системы.

👉 Идея:
Если одно значение из класса ведёт себя правильно/неправильно — то остальные в этом классе, скорее всего, так же.

Поэтому нет смысла тестировать каждое число, каждую строку — достаточно выбрать по одному представителю из каждого класса.

💻 Как применять технику эквивалентных классов?

Общий алгоритм:

1. Определить входные данные / параметры, которые хотим тестировать.
   Например: возраст, сумма, дата, тип документа.
2. Для каждого параметра:
• выделить допустимые (валидные) классы;
• выделить недопустимые (невалидные) классы.
3. Из каждого класса взять по 1–2 представителя и сделать на их основе тесты.

📌 Пример (простой)

Поле «Возраст»:
Допустим ввод: от 18 до 60 включительно.

Мы можем выделить классы:

• ❌ Класс 1: возраст < 18 (например, 10, 17)
• ✅ Класс 2: 18–60 (например, 20, 35, 60)
• ❌ Класс 3: возраст > 60 (например, 61, 99)

Для тестов мы не берём все числа, а выбираем по одному представителю:

• Тест 1: возраст = 17 (недопустимый, слишком маленький)
• Тест 2: возраст = 30 (допустимый)
• Тест 3: возраст = 65 (недопустимый, слишком большой)

🧠 Рекомендации по выделению классов

1. Если входное условие — диапазон
   Например: от 1 до 10
   ➜ 1 допустимый класс: 1–10
   ➜ 2 недопустимых: <1 и >10
2. Если входное условие — набор значений
   Например: статус ∈ {«новый», «в работе», «закрыт»}
   ➜ по 1 допустимому классу на каждое значение
   ➜ 1 общий недопустимый класс — всё остальное.
3. Если условие — «должно быть так-то»
   Например: поле обязательно для заполнения
   ➜ 1 допустимый класс (поле заполнено корректно)
   ➜ 1 недопустимый (пустое/некорректное значение).

✅ В чём польза эквивалентных классов для тестировщика?

• Ты не перебираешь все возможные значения, а проверяешь только «представителей» классов.
• Покрываешь все важные случаи, не утопая в бесконечных вариациях.
• Экономишь время и выглядишь на собесе как человек, который умеет думать системно, а не просто «тыкать поля».

2️⃣ Анализ граничных значений (Boundary Values) 📏

🧩 Суть техники

Граница — это место, где система переходит:

• от «разрешено» к «запрещено»,
• от одной скидки к другой,
• от «стаж работы слишком маленький» к «достаточный».

Техника граничных значений говорит:

Больше всего багов — на границе.
Поэтому проверяй не только внутри диапазона, но и рядом с границами.

Обычно проверяют:

• значение чуть меньше границы,
• саму границу,
• значение чуть больше границы.

🔢 Что такое «ШАГ» и зачем он нужен?

Прежде чем применять технику, нужно понять:
👉 ШАГ — это минимальная разница между двумя соседними значениями.

Например:

• Если суммы в корзине идут по целым рублям → шаг = 1 рубль.
• Если цены могут быть с копейками → шаг = 0.01.

🍏 Пример с корзиной и скидками

Условие:

• До 100 рублей — 0% скидки
• От 100 рублей и выше — 5% скидки

🇷🇺 Российский интернет-магазин

Цены только в рублях, без копеек → шаг = 1 рубль.

Граница — 100 рублей. Значит тестируем:

• 99 — ещё нет скидки
• 100 — уже должна быть 5%
• 101 — всё ещё 5%

🇧🇾 Белорусский интернет-магазин

Цены в рублях и копейках → шаг = 0.01.

Проверяем:

• 99.99 — 0%
• 100.00 — 5%
• 100.01 — 5%

👉 На собеседовании обязательно проговаривай шаг:

«Если шаг = 1 рубль, проверю 99, 100 и 101.
Если есть копейки, проверю 99.99, 100.00 и 100.01».

🧠 О чём гласит техника граничных значений?

Коротко:

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

3️⃣ Попарное тестирование (Pairwise) 🤝

🧩 Что это вообще такое?

Попарное тестирование — это техника, которая помогает проверить все пары параметров, но не перебирать все комбинации целиком.

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

👉 Попарное тестирование говорит:

«Большинство багов проявляются при взаимодействии двух параметров.
Поэтому протестируем все пары комбинаций, а не полный перебор».

🧯 Когда применять попарное тестирование?

Используем, когда:

• Есть несколько параметров с несколькими вариантами (цвет, размер, тип товара, страна, способ доставки).
• Полный перебор комбинаций даёт десятки/сотни сценариев.
• Нужно:
• сократить количество тестов,
• но всё равно покрыть большинство важных комбинаций.

Типичные случаи:

• формы с множеством выпадающих списков;
• фильтры (каталог товаров);
• настройки, где пользователь может задавать разные комбинации параметров.

✅ В чём польза для тестировщика?

• 📉 Меньше тест-кейсов, чем при полном переборе.
• 📈 Больше покрытия, чем если «тыкать наугад».
• 💰 Экономия времени и ресурсов.
• 🔍 Часто позволяет найти баги, которые не видно одиночными проверками.

⚠️ Недостатки

• Не покрывает все сложные комбинации (например, когда баг возникает при одновременном сочетании 3+ параметров).
• Нужно грамотно выбрать параметры и их значения, иначе можно упустить важные случаи.

🛠 Инструмент для попарного тестирования

Есть удобный онлайн-сервис:
👉 https://pairwise.teremokgames.com

Что можно сделать:

1. Вбить:
• параметры,
• варианты значений.
2. Нажать «сгенерировать».
3. Получить короткий список сценариев, которые покрывают все пары параметров.

Ты можешь:

• сделать тестовый пример,
• сохранить набор сценариев,
• приложить файл или скриншот в свою карточку по учебному проекту.

4️⃣ Таблица переходов / схема состояний 🔄

🧩 Что такое схема переходов и состояний?

Любой объект в системе может:

• находиться в разных состояниях,
• переходить из одного состояния в другое по событию.

Схема переходов и состояний — это модель, которая показывает:

• какие состояния бывают,
• какие события к каким переходам приводят,
• какие переходы запрещены.

📌 Пример: документ в системе

Состояния:

1. «Не создан»
2. «В разработке»
3. «Утверждён»
4. «Устаревший»

Переходы:

• «Создать» → из «Не создан» в «В разработке»
• «Утвердить» → из «В разработке» в «Утверждён»
• «Аннулировать» → из «Утверждён» в «Устаревший»

Техника «таблица переходов» позволяет:

• явно описать эти состояния и переходы,
• проверить, что невозможные переходы не происходят (например, сразу из «Не создан» в «Утверждён»).

5️⃣ Таблица принятия решений 🧾

🧩 Суть техники

Иногда система принимает решение на основе нескольких условий.
Например:

• пользователь зашёл?
• он админ?
• подписка активна?
• баланс > 0?

Таблица принятия решений помогает:

• выписать все важные условия,
• указать возможные комбинации «да/нет»,
• прописать, какое действие выполняется в каждой комбинации.

Это очень удобно, когда логика сложная и много веток.

6️⃣ Прогнозирование ошибок (Error Guessing) 🧙‍♀️

🧩 Что это такое?

Это техника, основанная на опыте тестировщика.

Тестировщик задаёт себе вопросы:

• «Где тут разработчик мог накосячить?»
• «В этом месте обычно забывают проверять пустые значения?»
• «В прошлых проектах в этих сценариях часто вылезали баги».

Он вспоминает:

• прошлые баги,
• типичные ошибки,
• особенности этой системы.

И специально делает тесты именно под эти предполагаемые слабые места.

7️⃣ Причинно-следственный анализ (Cause–Effect) 🧬

🧩 Суть техники

Мы рассматриваем систему как набор:

• причин (conditions) — условия / входные данные,
• следствий (effects) — результаты / реакции системы.

Задача:

Найти связь:
«какие комбинации причин приводят к каким следствиям».

Например:

• Причина: логин и пароль введены правильно
  ➜ Следствие: пользователь авторизован
• Причина: пароль неправильный
  ➜ Следствие: ошибка авторизации

Техника помогает:

• системно перебрать комбинации условий;
• понять, где не хватает проверки;
• увидеть, что некоторые комбинации не обработаны вообще.

8️⃣ Исследовательское тестирование 🕵️‍♀️

🧩 Что это такое?

Исследовательское тестирование — это когда ты:

• не следуешь заранее написанным тест-кейсам,
• а сам изучаешь систему «живьём»,
• строишь гипотезы,
• сразу же проверяешь их.

Это смесь:

• любопытства,
• опыта,
• логики.

Обычно:

• используют, когда документа мало,
• или продукт сильно меняется,
• или нужно быстро «прощупать» новую фичу.

Но даже в исследовательском тестировании техники тест-дизайна всё равно в голове: ты всё равно мысленно используешь эквивалентные классы, границы, сценарии, переключаешь состояния и пр.

9️⃣ Небольшой конспект техник (как шпаргалка) 📚

• ⚖️ Эквивалентное разбиение
  Делим входные данные на классы (валидные / невалидные) и берём по одному представителю из каждого.
• 📏 Граничные значения
  Проверяем значения на границах диапазона и рядом с ними.
  Перед применением — обязательно определяем ШАГ.
• 🌐 Доменный анализ
  Разделение диапазона значений на поддиапазоны (домены) и выбор 1–2 значений из каждого для тестирования.
• 🧙 Прогнозирование ошибок
  Используем опыт и знание типичных багов, чтобы специально искать слабые места.
• 🧬 Причина / следствие
  Вводим условия → смотрим результаты → проверяем связи между ними.
• 🎭 Use Case тестирование
  Проверяем реальные пользовательские сценарии (истории, как пользователи взаимодействуют с системой).
• 🧨 Исчерпывающее тестирование
  Проверка всех комбинаций. В теории красиво, на практике почти нереально.
• 🤝 Попарное тестирование (Pairwise)
  Строим тесты так, чтобы все пары параметров встретились хотя бы раз.
  Сильно сокращает количество тестов.
• 🔄 Состояния и переходы
  Моделируем, в каких состояниях может быть объект и как он переходит из одного в другое.
• 🧾 Таблица принятия решений
  Упорядочиваем сложную бизнес-логику с несколькими условиями и результатами в виде таблицы.

🧷 Главное, что должен вынести новичок

1. Тест-дизайн — это не «страшная теория», а способ думать о тестах умно.
2. Техники помогают:
• уменьшать количество тестов,
• повышать качество проверок,
• находить серьёзные баги быстрее.
3. На собеседовании важно:
• уметь объяснить эквивалентные классы,
• граничные значения (обязательно упомянуть шаг),
• попарное тестирование,
• таблицу состояний / переходов.

дополнительная информация тут:

https://youtu.be/7a7vGZqwtCA?si=4T6kTpEieVlMjiOB

полезная шпаргалка с примерами:

https://habr.com/ru/articles/740026/