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

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

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

Источник: cherkasovschool

Открыть на YouTube

Таймлайн

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

Публичное тренировочное собеседование Николая Черкасова с Алёной, начинающей QA-инженеркой с опытом учебного и веб-тестирования. Они разбирают базовую теорию тестирования, требования, виды и уровни тестирования, smoke/sanity/regression, тест-дизайн, документацию и жизненный цикл баг-репортов. В конце интервьюер даёт Алёне рекомендации: закрепить краткие определения, различать цели и классификации тестирования, а также изучить особенности web, native и hybrid-приложений и Kanban.

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

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

  • Подготовьте короткое определение тестирования как проверки соответствия ожидаемого и фактического поведения программы на выбранном наборе тестов.
  • Для вопроса об отсутствии требований назовите источники: заказчик или менеджер, похожие сервисы, общепринятые ожидания от продукта; на примере интернет-магазина — корзина и оплата.
  • Чётко разделяйте smoke, sanity и regression: smoke быстро подтверждает пригодность сборки к тестированию, sanity углублённо проверяет новую или выбранную функциональность, regression проверяет старую функциональность после изменений.
  • В негативных сценариях ожидаемый результат — корректная реакция системы, например сообщение об ошибке при делении на ноль; число возможных негативных сценариев бесконечно, поэтому проверяют наиболее вероятные и важные.
  • Используйте классы эквивалентности, чтобы выбирать по одному или нескольким представителям группы одинаково обрабатываемых входных данных, и анализ границ: min−1, min, max, max+1.
  • Различайте тест-план, чек-лист и тест-кейс: в тест-плане важны критерии начала и окончания, окружение и объём работ; чек-лист — краткий перечень проверок, тест-кейс содержит шаги и ожидаемый результат.
  • В баг-репорте нужны понятное название, окружение, предусловия, шаги, ожидаемый и фактический результаты, вложения при необходимости; при споре о воспроизведении сначала сверяют условия и версию сборки, а дубликат сопоставляют с исходной задачей.

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