На подготовке к собеседованию тестировщика соединяйте теорию с проверяемым действием: какое условие вы проверяете, какие данные используете и как отличаете правильный результат от ошибки. Список из десятков терминов мало помогает, если непонятно, что делать с конкретной формой или API.
В подборке Mentoring.digital есть короткие ответы и три учебных кейса. Это придуманные условия для тренировки, а не вопросы конкретного работодателя и не обнаруженные дефекты реального сервиса. Состав интервью зависит от вакансии: здесь основной акцент на ручном тестировании и базовой проверке API.
Теория тестирования: ответы, которые нужно уметь применить
Чем тестирование отличается от обеспечения качества?
Тестирование помогает оценивать продукт и выявлять дефекты. Обеспечение качества также связано с процессами, которые помогают предупреждать проблемы. Например, проверка расчёта скидки относится к тестированию, а договорённость о проверяемых критериях требований помогает сделать качество частью процесса разработки.
Что можно проверить без запуска программы?
Требования, макеты и код можно анализировать статически. Например, заметить, что спецификация одновременно разрешает и запрещает отмену заявки после подтверждения. Запуск программы нужен для динамической проверки её поведения.
Чем отличаются повторная проверка исправления и регрессия?
Первая отвечает на вопрос, устранён ли исходный дефект. Регрессионная проверка ищет нежелательные последствия изменения. После исправления скидки проверьте сам ошибочный сценарий, затем связанные расчёты, отмену и другие правила, которых могло коснуться изменение.
Что важнее: severity или priority?
Это разные характеристики. Severity описывает влияние дефекта, priority задаёт очерёдность исправления. Оценка требует контекста: какой пользовательский сценарий нарушен, сколько людей затронуто и есть ли обходной путь. Не назначайте приоритет только по эмоциональному впечатлению от ошибки.
Чем тест-кейс отличается от чек-листа?
Тест-кейс подробно задаёт условия, действия и ожидаемый результат. Чек-лист оставляет больше решения исполнителю. Для передачи новичку сложного расчёта полезнее детальный сценарий; для знакомой команде повторяющейся проверки может хватить короткого перечня. Важно, чтобы люди одинаково понимали, что считается успешной проверкой.
Кейс 1. Поле возраста и граничные значения
Условие. Учебная форма принимает только целые значения от 18 до 65 включительно. Пустое поле запрещено. При неверном значении форма показывает сообщение и не создаёт заявку. Эти правила заданы для упражнения; на рабочем проекте их сначала нужно получить из требований.
| Проверка | Данные | Ожидаемый результат |
|---|---|---|
| Ниже диапазона | 17 | Отказ, заявка не создана |
| Нижняя граница и сосед | 18, 19 | Возраст принят |
| Верхняя граница и сосед | 64, 65 | Возраст принят |
| Выше диапазона | 66 | Отказ |
| Отсутствующее значение | Пустая строка | Сообщение об обязательном поле |
| Нецелое или текст | 18.5, abc | Отказ по формату |
Не ограничивайтесь красной рамкой в интерфейсе. Проверьте, что неверная заявка действительно не появилась, а исправленное значение позволяет продолжить. Если форма отправляет запрос на сервер, проверка только в браузере не подтверждает серверную валидацию. Сам запрос проверяют в разрешённом тестовом окружении.
Отдельно уточните пробелы, ведущие нули и знак плюса: это не универсально допустимые или недопустимые значения. Если требования молчат, зафиксируйте вопрос вместо выдуманного ожидаемого результата.
Кейс 2. Как оформить баг-репорт на скидку
Условие. В учебном магазине промокод FIRST разрешён только для первого завершённого заказа. Представим, что тестовый пользователь с завершённым заказом применяет его повторно и получает скидку. Это условный дефект, на котором можно потренировать описание.
- Заголовок: FIRST уменьшает сумму нового заказа у пользователя с завершённым заказом.
- Предусловия: тестовая учётная запись, один завершённый заказ, действующий промокод FIRST. Отдельно укажите, учитываются ли отменённые заказы.
- Шаги: войти под этой записью, добавить доступный товар, открыть оформление, применить FIRST.
- Ожидается: промокод отклонён, сумма не уменьшена, причина понятна пользователю.
- Фактически в условии: промокод принят, сумма уменьшена.
- Что приложить при реальной проверке: версию сборки, тестовое окружение, идентификаторы обезличенных заказов, ответ API и снимок результата без секретов.
Хороший отчёт позволяет повторить проблему. Фраза «скидки не работают» не объясняет ни входные данные, ни нарушение. После исправления нужны проверки первого заказа, повторного заказа и согласованных правил для отмены. Одно успешное применение промокода не закрывает все варианты.
Кейс 3. Проверка API создания бронирования
Учебный контракт. Авторизованный пользователь отправляет запрос создания брони комнаты. При свободном интервале API возвращает 201, идентификатор брони и согласованные даты. Занятый интервал отклоняется с 409. Конкретные поля и эти коды ошибок являются условиями упражнения, а не обязательным поведением любого API.
- Отправьте корректный запрос. Сверьте статус, схему тела, владельца, комнату и интервал. Затем прочитайте созданную бронь: ответ на создание и сохранённое состояние должны согласовываться.
- Проверьте отсутствующие поля, конец раньше начала и занятый интервал. Убедитесь, что отклонённая операция не создала запись.
- Проверьте доступ без авторизации и доступ другого пользователя к чужой записи по правилам продукта. Успешная собственная бронь ещё не подтверждает правильность разграничения прав.
- Уточните контракт повторного запроса. POST сам по себе не гарантирует защиту от повторного создания. Если предусмотрен ключ идемпотентности, проверьте повтор с тем же ключом и ситуацию, когда тело изменилось.
Не делайте вывод «API работает» только по зелёному статусу ответа. Проверяйте данные и последствия операции. Для отрицательного сценария важен и отказ, и отсутствие нежелательного изменения состояния.
Что отвечать на вопросы о покрытии и автоматизации
«Мы проверили всё» требует уточнения: все требования, классы входов, переходы состояний или строки кода? Назовите конкретную область покрытия и то, что осталось вне неё. Количество тест-кейсов само по себе не говорит, насколько проверен риск.
«Что автоматизировать первым?» Начните с устойчивого, важного и повторяющегося сценария с однозначным результатом. Оцените стоимость подготовки данных и поддержки. Если требования меняются каждый день, автоматизация большого интерфейсного сценария может потребовать много переделок. Ручное исследование и автотесты решают связанные, но разные задачи.
На курсах QA с наставником можно согласовать практику тест-дизайна, API и подготовки к интервью. Для предметной обратной связи принесите одну задачу, свой набор проверок и объяснение приоритетов.
Самопроверка перед собеседованием
Возьмите незнакомую форму и за несколько минут запишите требования, позитивные и негативные сценарии, границы и вопросы к постановке. Затем оформите один баг-репорт на учебном примере. Если можете объяснить, какую ошибку обнаруживает каждая проверка, подготовка уже выходит за рамки заучивания.
Разбор с ментором по тестированию полезно строить вокруг ваших решений: какие условия пропущены, где ожидаемый результат не определён, какие проверки дублируют друг друга. Не приписывайте себе коммерческий опыт на основе учебного упражнения: лучше честно показать ход мысли и то, что вы проверили самостоятельно.
