Какие техники тестирования применить для проверки приложения
Что проверяют
Умеете ли вы строить стратегию, а не перечислять всё подряд. Хороший кандидат начинает с вопросов о приложении и рисках. Следом обычно просят расставить приоритеты, если на проверку есть два дня.
Как отвечать
Начните с уточнений: веб или мобильное, домен, есть ли требования, что считается критичным, какие сроки. От ответов зависит набор.
Дальше выстройте каркас по рискам:
- дымовое тестирование: сборка запускается, основные сценарии проходят, иначе глубже идти нет смысла;
- функциональное с тест-дизайном: классы эквивалентности и границы для полей, таблица решений для бизнес-правил, переходы состояний для статусов заказа или заявки;
- API: запросы через Postman или код, коды ответов, валидация, авторизация, контракт между фронтендом и бэкендом;
- интеграции: платёжный шлюз, почта, сторонние сервисы, поведение при их недоступности и таймаутах;
- нефункциональное: нагрузка через JMeter или k6, базовые проверки безопасности по OWASP Top 10 (инъекции, доступ к чужим данным), совместимость браузеров и устройств, доступность;
- мобильная специфика: прерывания звонком, потеря сети, фоновый режим, разрешения, разные версии ОС;
- регрессия: стабильные критичные сценарии уходят в автотесты, чтобы не проверять их руками к каждому релизу.
Закончите приоритетами: что проверите в первую очередь (оплата, регистрация, данные пользователя) и по какому признаку остановитесь, например все критичные сценарии пройдены и нет открытых блокеров.
Где спотыкаются
Сразу начинают перечислять виды тестирования, не задав ни одного вопроса. Для банковского приложения и лендинга ответ разный, и интервьюер ждёт, что вы это покажете.
Называют A/B-тестирование техникой QA. Это продуктовый эксперимент, который измеряет поведение пользователей, а не поиск дефектов.
Не говорят о приоритетах и времени. Список из десяти видов без порядка звучит как пересказ учебника, а не как план работы.