Собеседование ручного тестировщика | Выпуск №7, менторы Игорь и Даня | QA Studio

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

Менторы QA Studio проводят мок-собеседование с начинающим ручным тестировщиком Владом, который самостоятельно изучал QA и готовится выйти на рынок. Они разбирают основы тестирования, виды проверок, смоук и регресс, тестовую документацию, баг-репорты и техники тест-дизайна. Во второй части кандидат решает практические задачи по API, логам, пагинации, форме подписки, интеграциям, локализации дефектов и кроссбраузерным проблемам, после чего получает положительную обратную связь.

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

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

• Ожидаемый результат теста следует сверять с требованиями, User Story или спецификацией; требования возникают из потребностей заказчика и уточняются через интервью и анализ пользователей и конкурентов.
• Нагрузочное тестирование постепенно повышает нагрузку для определения предела производительности, а стресс-тестирование резко выводит систему за штатные пределы, чтобы найти отказы и узкие места; нагрузку могут измерять в RPS.
• Смоук-набор состоит из критичных быстрых проверок после релиза, а регрессия проверяет, не сломались ли существующие функции после изменений. Состав смоук-набора определяется конкретным проектом и рисками, поэтому, например, восстановление пароля может в него входить.
• В тест-кейсе полезно отделять предусловия, шаги, ожидаемый результат и постусловия. Несколько ожидаемых результатов в одном кейсе уменьшают число кейсов, но делают прогон менее диагностичным: при падении одного результата весь кейс выглядит непройденным.
• При невоспроизводимом дефекте нужно сначала повторить сценарий, сверить требования и окружение: среду, ветку или билд, браузер и ОС; затем использовать DevTools, Postman и логи для локализации.
• Для формы подписки сначала проверяют успешную отправку валидного email, затем невалидные форматы, пустое поле, длину, символы, пробелы, регистры и локали; ответ API и запись данных в базе следует сверять с требованиями.
• Решение о кроссбраузерном тестировании должно опираться на поддерживаемые браузеры и аналитику реального использования, а не только на различия браузерных движков.
• При дефекте только в одном браузере стоит проверить требования и поддержку браузера, повторить проблему после обновления или перезапуска и очистить кэш перед заведением баг-репорта.