Как строился процесс работы с системной аналитикой
Что проверяют
Умеет ли тестировщик работать с требованиями до того, как появился код, и понимает ли, откуда эти требования вообще берутся. По ответу видно, встроен ли QA в поток разработки или получает готовую задачу и молча проверяет её руками.
Как отвечать
Описывать реальную цепочку на своём проекте, а не абстрактную схему: откуда приходит потребность (продукт, поддержка, метрики), кто превращает её в спецификацию, где подключается QA, чем этап заканчивается.
Ключевая мысль ответа: тестирование требований дешевле тестирования кода. QA приходит на груминг и ревью спецификации и задаёт вопросы до разработки:
- что происходит на границах: пустое значение, максимум, ноль, отрицательное число, дубликат;
- какие сценарии ошибок описаны: таймаут внешнего сервиса, недоступная база, повторная отправка формы;
- что с правами: какая роль видит, какая меняет;
- есть ли нефункциональные требования: время ответа, объём данных, совместимость;
- нет ли противоречий с уже работающим поведением.
Артефакты, которые полезно назвать: user story с критериями приёмки (часто в формате Given/When/Then), контракт API в OpenAPI, диаграмма последовательности для интеграций, схема состояний сущности. Тест-кейсы пишутся прямо из них, а не выдумываются из головы.
Инструменты: Jira и Confluence для требований, Swagger UI и Postman для проверки контракта, Miro для схем на груминге, Allure TestOps или Zephyr для трассируемости. Важна не марка инструмента, а связность: по требованию видно покрытие тестами, по дефекту видно нарушенное требование.
Сильный финал ответа: конкретный случай. Неоднозначная формулировка в спецификации, вопрос на ревью, правка до разработки, отсутствие бага в проде. Это убедительнее перечисления методологий.
Где спотыкаются
Рассказывают про Agile и Waterfall вообще, вместо процесса своей команды. Второй провал: сводят роль QA к схеме «получил задачу, проверил», не упоминая ни ревью требований, ни критерии приёмки.