Senior QA Manual — Вопросы на собеседовании QA Manual

Вы приходите в команду, где процесса тестирования нет вообще. Что делаете в первый месяц?

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

Как обосновать штат QA руководителю, который видит в тестировании только затраты?

Перестать спорить о покрытии и начать показывать, что прорвалось. Считайте дефекты, найденные после релиза, во что они обошлись во времени поддержки, хотфиксах и ушедших клиентах, и сравнивайте со стоимостью поймать их раньше. Выигрывает не аргумент «нам нужно больше тестировщиков», а «вот во что нам обошёлся прошлый квартал и вот сколько стоит это предотвратить».

Что заставит вас возражать против автоматизации теста?

Когда фича ещё меняется — вы будете чинить тест чаще, чем он вас защитит. Когда проверка дёшева для человека и дорога для машины: визуальные оценки, юзабилити. Когда тест нестабилен по своей природе — тайминги, внешние сервисы, реальные платежи, — потому что красная сборка, которой не верят, хуже её отсутствия. Автоматизация окупается на стабильных, повторяющихся и ценных путях, а не на всём подряд.

Критичный баг доехал до продакшена. Как проводите разбор?

Безобвинительно и про механизм, а не про человека. Восстановить таймлайн, отделить триггер от причины, по которой он прошёл, и спросить, почему его пропустил каждый слой — требования, ревью, тесты, окружение. На выходе небольшое число изменений с владельцами, а не решение «быть внимательнее». Если баг того же класса прорвался дважды, дефект в процессе, а не в тестировщике.

Как выбрать, какие метрики качества показывать, и какие из них врут?

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

Продукт хочет вырезать QA из спринта, чтобы успеть к дате. Что отвечаете?

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