Вернуться в видеотеку

Собеседование на тестировщика ПО (Junior QA) №12

Публичная симуляция собеседования Junior QA с разбором ответов кандидата. Видео охватывает теорию тестирования и прикладные ситуации, которые могут встретиться на первом интервью.

Источник: cherkasovschool

Открыть на YouTube

Таймлайн

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

Это публичное пробное собеседование на позицию Junior QA: Анастасия, самостоятельно изучающая тестирование и впервые проходящая интервью, отвечает на вопросы, а интервьюер уточняет и корректирует её ответы. Разбираются основы тестирования, классификации и уровни тестов, тест-дизайн, документация и жизненный цикл баг-репорта. Во второй части обсуждают тестирование нативных, веб- и гибридных приложений, HTTP, Waterfall, Agile и Scrum, а в финале дают рекомендации по подготовке к реальному собеседованию.

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

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

  • Формулируя определение тестирования, связывайте фактическое поведение с ожидаемым, а источниками ожиданий называйте требования, документацию, аналоги продукта и здравый смысл.
  • Не представляйте автоматизацию как замену ручному тестированию: регресс можно выполнять обоими способами, UX требует человеческой оценки, а нагрузочные проверки обычно невозможны без автоматизации.
  • Для локализации подготовьте практический список проверок: полнота перевода интерфейса, переключение локали, форматы даты и времени, валюты, единицы измерения и размерные сетки.
  • При дефиците времени сначала проверяют позитивные сценарии из требований; негативные сценарии расширяют осознанно, поскольку их число потенциально неограниченно.
  • Нужно различать smoke-тестирование критичного функционала и регрессионное тестирование ранее работавших частей после изменений.
  • В тестовой документации важны назначение тест-плана, критерии начала и окончания тестирования, а также выбор между кратким чек-листом и подробным тест-кейсом с учётом сроков, сложности и размера команды.
  • Для баг-репорта следует уверенно описывать шаги, ожидаемый и фактический результат, окружение и версии; при споре о баге не закрывать его поспешно, а собрать воспроизводимые данные и проверить статус, требования или дубликат.

Рекомендуем посмотреть