🧪 Test design: превратить что тестировать в конкретные проверки

Если test analysis отвечает на вопрос
что тестировать?, то test design отвечает на другой, не менее важный
как именно это тестировать?

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

🔖 Что происходит в test design.
test conditions разворачиваются в: test cases, наборы тест-кейсов, другую тестовую документацию.
определяется и приоритизируется,
какие кейсы нужны в первую очередь,
подбираются или создаются test data.
проектируется тестовое окружение
(настройки, инфраструктура, инструменты).

фиксируется двусторонняя traceability
между test basis, test conditions, test cases, test procedures.

Проще: test analysis говорит о чём мы думаем, test design как именно мы будем это проверять.


❔ Интересный момент, который подчёркивает ISTQB дефекты часто обнаруживаются и на этапе test design.

Когда тестировщик начинает выбирать конкретные значения,
уточнять границы и условия,
всплывают вещи, которые не были заметны на высоком уровне.

Например:есть условие проверить граничные значения, но нигде не указано максимальное допустимое значение.

Это дефект test basis, и очень удачно, если он найден до выполнения тестов, а не в продакшене.

📌 Чем глубже детализация,
тем выше шанс заметить пробелы в требованиях и логике.

Какие именно задачи test design будут выполняться, зависит от проекта, продукта, рисков, уровня тестирования, ограничений по времени и ресурсам.

Как и весь тест-процесс,
test design адаптируется под контекст,
а не существует в универсальной форме.

📘 Основа: Foundations of Software Testing, ISTQB, 4th Edition
✍️ Пересказ и комментарии