Подготовка к собеседованию: ручное тестирование

Ландшафт собеседований по ручному тестированию #

Собеседования по ручному тестированию обычно комбинируют три элемента: концептуальные вопросы по теории тестирования, практические упражнения где вы тестируете что-то на месте, и поведенческие вопросы о вашем опыте. Этот урок покрывает первые два — поведенческие вопросы рассматриваются в Уроке 12.7.

Цель — не заучить ответы. Интервьюеры оценивают процесс мышления, а не способность пересказывать определения. Лучшие кандидаты думают вслух, задают уточняющие вопросы и структурируют ответы логически.

Топ-20 вопросов собеседования #

Категория 1: Основы #

В1: В чём разница между QA, QC и Testing?

• QA (Quality Assurance): Ориентирован на процессы. Фокус на предотвращении дефектов. Проактивный подход.
• QC (Quality Control): Ориентирован на продукт. Фокус на выявлении дефектов. Реактивный подход.
• Testing: Подмножество QC. Непосредственное выполнение тестов для нахождения дефектов.

В2: Объясните STLC (Software Testing Life Cycle).

Пройдите по шести фазам: Анализ требований, Планирование тестирования, Разработка тест-кейсов, Настройка окружения, Выполнение тестов, Закрытие тестирования.

В3: В чём разница между верификацией и валидацией?

• Верификация: Мы правильно строим продукт? (Соответствует спецификациям)
• Валидация: Мы строим правильный продукт? (Удовлетворяет потребности пользователей)

В4: В чём разница между severity и priority?

• Severity: Техническое влияние дефекта на систему
• Priority: Бизнес-срочность исправления дефекта

Ключевой момент: они могут различаться. Опечатка в имени CEO на главной — низкая severity, но высокий priority. Краш в admin-панели, используемой раз в год — высокая severity, но низкий priority.

В5: Назовите семь принципов тестирования (ISTQB).

Перечислите все семь и будьте готовы привести пример для каждого. Чаще всего спрашивают о Парадоксе пестицида и Кластеризации дефектов.

Категория 2: Дизайн тестов #

В6: Что такое анализ граничных значений?

Тестирование на границах допустимых диапазонов. Для поля возраста 18-65: тестируем 17, 18, 19, 64, 65, 66. Дефекты кластеризуются на границах из-за неправильных операторов сравнения.

В7: Что такое эквивалентное разбиение?

Разделение входных данных на группы, где все значения в группе ведут себя одинаково. Для возраста (18-65): невалидный низкий (<18), валидный (18-65), невалидный высокий (>65).

В8: Как бы вы тестировали страницу логина?

Структурируйте ответ по категориям:

• Функциональные: Валидный логин, невалидный пароль, пустые поля, SQL-инъекция
• UI/UX: Лейблы, сообщения об ошибках, порядок табуляции, маскирование пароля
• Безопасность: Защита от брутфорса, управление сессиями, HTTPS
• Производительность: Время отклика под нагрузкой
• Доступность: Совместимость со скринридерами, навигация с клавиатуры
• Кросс-браузерность: Chrome, Firefox, Safari, Edge

В9: Что такое регрессионное тестирование?

Тестирование неизменённых функций для подтверждения, что новые изменения их не сломали. Выполняется после каждого изменения кода или исправления бага.

В10: Что такое исследовательское тестирование?

Одновременное проектирование и выполнение тестов без предопределённых скриптов. Тестировщик использует знание домена и интуицию для исследования приложения.

Категория 3: Процессы и документация #

В11: Как написать хороший баг-репорт?

Обязательные элементы: заголовок, шаги воспроизведения, ожидаемый vs фактический результат, окружение, severity/priority, вложения.

В12: Тест-план vs тест-стратегия?

• Тест-стратегия: Высокоуровневый, организационный, редко меняется
• Тест-план: Специфичный для проекта, детальный, меняется от релиза к релизу

В13: Как решить, что тестировать первым при ограниченном времени?

Risk-based testing: приоритизация по бизнес-влиянию и вероятности сбоя.

Категория 4: Реальные сценарии #

В14: Нашли критический баг за 1 час до релиза. Что делаете?

Немедленно уведомить тимлида/PM, задокументировать баг, оценить влияние, предложить варианты (отложить релиз, выпустить с известной проблемой, hotfix).

В15: Разработчик говорит, что не может воспроизвести ваш баг. Как реагируете?

Не защищаться. Предложить воспроизвести вместе, поделиться деталями окружения, предоставить видеозапись.

Упражнения на тестирование в реальном времени #

Упражнение «Протестируй этот объект» #

Интервьюеры часто просят протестировать бытовые объекты: ручку, лифт, банкомат, торговый автомат.

Фреймворк для ответа:

1. Уточнить: Кто пользуется, основное назначение, ограничения?
2. Категоризировать: Организовать тесты по типам (функциональные, юзабилити, безопасность, производительность, граничные случаи)
3. Приоритизировать: Начать с самых критичных тестов
4. Думать вслух: Делиться рассуждениями по ходу

Пример: «Протестируй лифт»

Функциональные: Каждая кнопка этажа, кнопки открытия/закрытия, кнопка экстренной связи Безопасность: Превышение веса, датчик двери, отключение электричества Юзабилити: Доступность для инвалидных колясок, шрифт Брайля, аудио-объявления Производительность: Время ожидания между этажами, скорость дверей

Упражнение: Практика mock-интервью #

Практикуйтесь с таймером (2 минуты на ответ):

1. У вас есть flow оформления заказа в e-commerce. Опишите подход к тестированию.
2. CEO спрашивает: «Продукт готов к релизу?» Как ответите?
3. Протестируйте поиск на e-commerce сайте. Составьте 15 тест-кейсов за 5 минут.

Красные флаги, которых стоит избегать #

Флаг 1: Думать только о функциональном тестировании. Всегда упоминайте нефункциональные аспекты.

Флаг 2: Никогда не задавать уточняющих вопросов. Прыгать к тест-кейсам без понимания контекста — признак слабого аналитического мышления.

Флаг 3: Негатив в адрес разработчиков. Фразы вроде «разработчики всегда пишут багованный код» сигнализируют о плохих навыках командной работы.

Флаг 4: Утверждение, что можно протестировать всё. Покажите, что понимаете приоритизацию и risk-based testing.

Ключевые выводы #

• Структурируйте ответы логически: определение, пример, применение в реальной жизни
• Всегда задавайте уточняющие вопросы перед тестированием чего-либо
• Организуйте тест-кейсы по категориям: функциональные, безопасность, производительность, юзабилити, граничные случаи
• Думайте вслух — интервьюеры оценивают процесс, а не только ответы
• Готовьте конкретные примеры из опыта
• Честность о пробелах в знаниях в сочетании с подходом к решению проблемы создаёт доверие