За 17 лет в QA я не раз сталкивался с тем, что на курсах, тренингах дают десяток техник тест-дизайна. Всё красиво: классификация, схемы, примеры.
А потом ты приходишь на проект — и релизы каждую неделю, десятки тикетов, ручная регрессия, звонки, встречи… И времени на всё это просто нет.
📌 Что чаще всего работает на практике:
- Эквивалентное разбиение + граничные значения — основа, которая помогает быстро.
- Попарное тестирование — удобно, если нужно сократить число кейсов.
- Тестирование переходов состояний — полезная техника, хороша для анализа требований в том числе, особенно когда система ведёт себя по-разному в зависимости от текущего состояния. (банкоматы, логин-сессии, почтовики, редакторы, интернет-магазины и т.д.).
- Предугадывание ошибок — навык, который с опытом становится почти автоматическим.
Белый ящик? На практике встречал пожалуй 1 qa на 30 кто реально бы смотрел pull request-ы, разбирался в них и находил баги, в основном матерые автотестеры, пишущие на тех же языках, что и разрабы.
Главное — понимать, зачем ты применяешь ту или иную технику и как она помогает в твоей работе.
Тест-дизайн — это не про количество техник. Это про осознанный выбор того, что даст результат.
Мои уроки по техникам:
📊Классы эквивалентности и граничные значения
🔄Диаграммы состояний и переходов
А вот здесь можно качнуть самую крутую книжку по тест-дизайну A Practitioner’s Guide to Software Test Design by Lee Copeland на русском и английском
А вы что реально используете на проектах?
Какие техники помогают, а какие лежат в теории и не применяются?