Был ли опыт мануального тестирования

Что проверяют

Есть ли у вас реальная практика ручного тестирования и умеете ли вы им управлять: проектировать проверки, а не просто кликать. После ответа «да» почти всегда просят рассказать про самый интересный найденный баг и спрашивают, как вы понимаете, что протестировали достаточно.

Как отвечать

Отвечайте на своём опыте, чужой шаблон тут не поможет. Каркас:

• продукт и контекст: веб, мобильное приложение или API, размер команды, как часто выходили релизы;
• виды тестирования: смоук после сборки, регресс перед релизом, проверка новых фич, исследовательское тестирование;
• тест-дизайн: классы эквивалентности, граничные значения, таблицы решений, переходы состояний, попарное тестирование. Назовите, что применяли и на какой задаче;
• артефакты: чек-листы или тест-кейсы в TestRail, Qase, Allure TestOps, баг-репорты в Jira или YouTrack;
• инструменты: DevTools браузера, Charles или Proxyman для трафика, Postman для API, adb logcat и консоль Xcode для мобильных логов, SQL для проверки данных;
• цифры: сколько кейсов в регрессе, сколько он длился, сколько багов в среднем находили за спринт. Только ваши реальные значения.

Один конкретный пример сильнее перечня: какой баг, как нашли, как описали шаги воспроизведения, чем закончилось.

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

Где спотыкаются

Описывают опыт как «проходил по тест-кейсам». Без техник тест-дизайна и примеров это звучит как опыт исполнителя, а не инженера.

Берут готовый STAR-шаблон с круглыми цифрами вроде «нашёл 15 критических багов». На первом уточнении, что именно было критичным, история рассыпается.

Противопоставляют ручное тестирование автоматизации и оправдываются, что «пока не автоматизировали». Ручная проверка остаётся основой профессии, и подавать её стоит уверенно.