Лемурзильня Тестировщика

1. Расскажите о разнице между verification и validation

A. Verification — соответствует ли продукт спецификации; validation — нужен ли он пользователю B. Это одно и то же C. Verification — это тестирование, validation — отзыв пользователя D. Verification делает разработчик, validation — тестировщик

2. Что вы включите в тест-план в первую очередь?

A. Область тестирования, риски, критерии начала/окончания, ресурсы B. Список всех тест-кейсов продукта C. Имена всех тестировщиков D. Скриншоты приложения

3. Как определить, достаточно ли тестирования? (критерии выхода)

A. Покрытие рисков выполнено, критичные баги закрыты, метрики достигнуты B. Когда закончатся идеи у тестировщика C. Когда менеджер скажет D. Когда пройдены все тест-кейсы без исключения

4. Найден баг в пятницу вечером, релиз в понедельник. Ваши действия?

A. Оценю Severity/Priority, эскалирую с фактами, предложу варианты (фикс, обход, перенос) B. Молча заведу баг и уйду домой C. Напишу в чат «всё пропало» D. Позвоню заказчику напрямую

5. Чем отличается Severity от Priority?

A. Severity — техническая серьёзность, Priority — бизнес-срочность B. Это синонимы C. Severity ставит разработчик, Priority — тестировщик всегда D. Priority всегда выше Severity

6. Что такое тест-дизайн? Назовите 3 техники

A. Проектирование тестов: классы эквивалентности, границы, попарное тестирование B. Рисование макетов интерфейса C. Написание документации D. Выбор среды тестирования

7. SQL: выбрать заказы без предметов (осиротевшие)

A. SELECT o.* FROM orders o LEFT JOIN items i ON i.order_id=o.id WHERE i.id IS NULL B. SELECT * FROM orders WHERE id NOT IN (SELECT id FROM items) C. SELECT * FROM orders INNER JOIN items D. WHERE count(items) = 0 без группировки

8. Какой HTTP-статус ожидать при успешном создании ресурса?

A. 201 Created B. 200 OK C. 204 No Content D. 302 Found

9. DELETE выполнился, но вернул 500. Баг ли это?

A. Да: действие выполнено, но контракт API нарушен — нужен фикс ответа B. Нет: главное, что удаление сработало C. Это всегда проблема сети D. Нужно просто повторить запрос

10. Что напишете в баг-репорте для плавающего дефекта?

A. Условия воспроизведения, закономерность, наблюдения (логи, тайминги), статус «редко» B. «Воспроизводится через раз» и всё C. Ничего, это не баг D. Попрошу разработчика угадать причину

11. Чем исследовательское тестирование отличается от «просто полазить»?

A. Чартеры, заметки, целенаправленное исследование с гипотезами B. Ничем, это то же самое C. Оно выполняется только автоматикой D. Оно дешевле регресса всегда

12. Расскажите о своём самом интересном баге

A. Ситуация → что заметил → как локализовал → как оформил → что улучшилось после B. «Такого не было» C. «Баг был, но его починил разработчик» D. Опишу общие слова без конкретики

13. Ваши действия, если требования противоречивы?

A. Зафиксирую противоречие, уточню у аналитика/PO, отразю решение в кейсах B. Тестирую по своему пониманию молча C. Сразу пишу баг на аналитика D. Жду пока само разрешится

14. Как протестировать форму регистрации за 10 минут?

A. Позитив, поля по классам/границам, дубли email, XSS-базово, API-уровень, UI-валидация B. Зарегистрируюсь один раз — работает C. Прогоню только автотестами D. Составлю 100 тест-кейсов и не успею

15. Что такое mock и когда его применять в автотестах?

A. Заглушка зависимости: изолирует тест от внешнего сервиса, ускоряет и стабилизирует B. Это копия продовой базы C. Инструмент только для нагрузочного тестирования D. Всегда вместо реальных сервисов

16. Как понять, что автотест «хороший»?

A. Стабилен, быстр, независим, понятный селектор, одна проверка на тест B. Он длинный и проверяет всё сразу C. Пишется быстро, даже если падает иногда D. Проходит только на моей машине

17. gRPC vs REST в двух словах — что скажете на интервью?

A. gRPC — бинарный protobuf/HTTP2, контракт-first; REST — текстовый HTTP, ресурсы B. gRPC — это то же REST C. REST всегда быстрее gRPC D. gRPC не использует HTTP

18. Тестируете оплату. Финансовая транзакция задвоилась. Приоритет?

A. Критический: блокирующая зона, эскалация немедленно B. Средний — оплата всё равно прошла C. Низкий — деньги вернутся D. Это не моя зона

19. Какие метрики тестирования вы бы внедрили в команде?

A. Покрытие рисков, время до нахождения бага, доля прод-дефектов, стабильность прогона B. Количество написанных кейсов C. Количество найденных багов у каждого QA D. Время обеда тестировщика

20. Ваша команда не пишет документацию. Как тестировать?

A. Из кода/чатов/экспериментов, фиксирую найденное сам — строю базу знаний B. Откажусь тестировать без ТЗ C. Буду ждать документацию месяц D. Тестирую только то, что задокументировано

21. Что такое CI и зачем он тестировщику?

A. Автоматическая сборка+прогон тестов на каждый коммит — быстрая обратная связь B. Это инструмент только разработчиков C. Замена ручному тестированию D. Сервер для хранения кода

22. Как вы оцениваете трудозатраты на тестирование фичи?

A. Разбиваю на зоны, сравниваю с похожими фичами, закладываю риски и буфер B. Говорю «два дня» без обоснования C. Столько, сколько скажет разработчик D. Никогда не оцениваю

23. Пользователь прислал скриншот «ничего не работает». Ваши первые шаги?

A. Соберу окружение/шаги, воспроизведу, посмотрю логи, локализую уровень B. Перешлю разработчику как есть C. Ответлю «не воспроизводится» D. Скажу пользователю переустановить всё

24. Что такое таблица решений и когда она оправдана?

A. Комбинации условий→действий; оправдана при 3+ бизнес-правилах вместе B. Это расписание дежурств C. Только для БД-тестирования D. Всегда вместо тест-кейсов

25. Как относитесь к «тестировщик должен уть программировать»?

A. Читать код — обязательно, писать — по роли; автотесты на своём уровне B. Тестировщик не нужен, если есть разработчики C. Только ручное тестирование — чистая профессия D. Программирование — требование ко всем одинаково

26. Ваши ожидания от работы в команде как тестировщика?

A. Раннее вовлечение в требования, прозрачность статусов, влияние на качество продукта B. Только чек-листы и закрывание тикетов C. Работа в изоляции от разработчиков D. Минимум коммуникации

27. Почему QA, а не разработка?

A. Осознанный выбор: разрушительное мышление, целостный взгляд на продукт, влияние на качество B. Не взяли в разработку C. В QA проще войти и всё D. Так посоветовали друзья

28. Что будете делать, если все тесты зелёные, а прод лёг?

A. Анализ: что не покрывали тесты, добавлю проверку мониторинга/прод-дым, постмортем B. Скажу «тесты зелёные — не моя вина» C. Выключу тесты, они бесполезны D. Перейду в другую команду

29. Вопрос вам к нам? (что спросите в конце интервью)

A. Про процессы качества, зрелость автоматизации, зону ответственности B. «Сколько платить будут?» — первым делом C. Ничего не спрошу D. «А можно удалённо три дня в неделю?»

Симулятор собеседования