90 QA Interviews Stream [Armenia -Yerevan]. 21.05.2023 at 10:00 GMT(UTC) +4

Коротко о видео

Это публичный стрим с учебным QA-собеседованием: ведущий по очереди задаёт добровольцу вопросы о тестировании отказов и восстановления, диагностике веб-проблем и HTTP. Разбираются сценарии отсутствующего события регистрации, ошибок 405 и 500, тайм-аутов, баннерной рекламы и способы их проверки через DevTools, throttling и Charles Proxy. Во второй половине обсуждаются решения о релизе при баге, CI/CD, Git, подготовка тестовых данных, тестирование рисков и локализации, hotfix и приоритизация способов оплаты.

Затронутые темы

Что взять на заметку

• Для проверки восстановления нужно искусственно вызвать падение или перезапуск приложения и проверить сохранность пользовательских данных, сессии и штатную работу после запуска; обновление приложения — отдельный близкий сценарий.
• Если после нажатия кнопки регистрации нет серверного события, диагностировать стоит цепочку от DevTools Network и статуса запроса до payload, консоли браузера, момента логирования и загрузки JavaScript-ресурсов; среди гипотез — недоступность CDN в конкретной стране.
• Ведущий уточняет, что HTTP 405 возникает, когда endpoint не поддерживает использованный HTTP-метод, например запрос PUT отправлен в endpoint, принимающий только POST; это не просто «заблокированный» метод.
• Отсутствие интернета и долгий ответ сервера — разные ситуации: первую можно проверить отключением сети, а долгий запрос — throttling; ответ 500 и обработку пользовательской страницы ошибки можно эмулировать через Charles Proxy, breakpoints или подмену ответа.
• При проблеме с рекламным баннером нужно отдельно проверить получение баннера, его формат и отображение на фронтенде, а также соответствие событий списания показов реально отображённым баннерам; в приведённом опыте два запроса списывали оплату за два баннера при показе одного.
• Решение о выпуске релиза с багом зависит от серьёзности дефекта и того, блокирует ли он критический smoke flow; решение обсуждается с менеджером и разработчиками, а после hotfix нужны ретест исправленного места, проверка соседних функций и как минимум smoke-тест.
• Если необходимо проверить все 20 способов оплаты, их нельзя исключить тест-дизайном, но порядок разумно определить по статистике использования, выручке и важности локалей; тестовые данные для нагрузки можно генерировать циклом с рандомизацией непосредственно в БД или программным скриптом.