Тестировщик не стоит в конце конвейера и не «принимает работу». Он участвует в разработке с первого дня. На собеседовании это проверяют вопросами про модели разработки, Scrum и про то, как выглядит твой день.
Модели разработки
- Водопад: требования, дизайн, код, тестирование, внедрение строго по очереди. Тестирование в конце, дефекты требований находят слишком поздно.
- V-модель: каждому этапу разработки соответствует свой уровень тестирования. Бизнес-требования ↔ приёмочное, системные требования ↔ системное, архитектура ↔ интеграционное, дизайн модулей ↔ модульное. Тесты проектируют рано, по документу своего этапа.
- Итеративные и гибкие: продукт растёт короткими циклами, после каждого есть работающий инкремент. Scrum и Kanban самые распространённые.
Scrum за минуту
Три ответственности: Product Owner (ценность и бэклог), Scrum Master (процесс), Developers (все, кто делает инкремент). Отдельной роли тестировщика в Scrum Guide нет: тестировщик входит в Developers, а качество общая ответственность.
События: планирование спринта, ежедневный Scrum (дейли, 15 минут), обзор спринта (показываем результат заинтересованным лицам), ретроспектива (улучшаем процесс). Груминг (уточнение бэклога) не отдельное событие, но на практике он есть почти везде, и тестировщику там самое место.
Definition of Ready: когда задачу можно брать (понятные критерии приёмки, макеты, оценка). Это популярная практика, в Scrum Guide её нет. Definition of Done: когда задача готова (код на ревью, тесты пройдены, нет критичных дефектов).
Жизненный цикл тестирования (STLC)
- Анализ требований: читаем задачу, макеты, задаём вопросы.
- Планирование: объём, подходы, ресурсы, сроки, риски.
- Проектирование тестов: чек-листы, тест-кейсы, тестовые данные.
- Подготовка окружения: стенд, доступы, данные.
- Выполнение: прогон, баг-репорты, ретест.
- Завершение: отчёт, выводы, что улучшить.
В Scrum этот цикл крутится внутри каждого спринта, иногда внутри каждой задачи.
Критерии входа и выхода
- Критерии входа: когда начинаем тестирование. Сборка на стенде, smoke пройден, требования согласованы.
- Критерии выхода: когда заканчиваем. Запланированные тесты выполнены, открытых блокирующих и критичных дефектов нет, остаточные риски приняты владельцем продукта.
- Критерии приостановки: когда тестировать бессмысленно. Например, блокер в авторизации.
Отработанные часы и число найденных багов не критерии: они ничего не говорят о качестве.
Shift-left и shift-right
Shift-left значит переносить проверки раньше: ревью требований, встреча «три амигос» (аналитик, разработчик, тестировщик обсуждают задачу и примеры до кода), модульные тесты, автотесты в CI.
Shift-right значит проверять и наблюдать после выкатки: мониторинг, алерты, фича-флаги, канареечные релизы, A/B-тесты. Это не замена тестированию до релиза, а дополнение, особенно когда выкатки идут много раз в день.
Тестируемые требования
Требование «каталог должен работать быстро» нельзя проверить: каждый поймёт по-своему. Тестируемое требование однозначно и измеримо: «страница каталога загружается не дольше 2 секунд при 100 одновременных пользователях на 4G». Найти и переформулировать такие места на этапе требований одна из самых ценных вещей, которые делает тестировщик.
Частые ошибки
- Ждать сборку, вместо того чтобы читать требования и готовить тесты заранее.
- Тестировать все задачи в последний день спринта. Проверяй по мере готовности.
- Называть тестировщика отдельной ролью Scrum.
- Путать обзор спринта (про продукт, с заказчиками) и ретроспективу (про процесс, внутри команды).
Что спросят на собесе
- Какие модели разработки знаешь, чем V-модель отличается от водопада?
- Как работает тестировщик в Scrum-команде на протяжении спринта?
- Что такое DoD и критерии приёмки?
- Когда заканчивать тестирование?
- Что делать, если задачи копятся в колонке «Тестирование»?