Вернуться в каталог собеседований

76 QA Interviews Stream. 04.01.2023 at 20:00 GMT(UTC) +3

Длинный стрим с тремя тренировочными QA-собеседованиями и подробными разборами ответов по теории и практическим ситуациям. В финале ведущий анонсирует изменения в программе своего курса и критерии отбора учащихся для рекомендаций.

Вадим Ксендзов
  • Опубликовано на YouTube:
  • Просмотры на YouTube: 6,1 тыс.
  • Лайки на YouTube: 229
Открыть на YouTube

Таймлайн

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

Это запись 76-го открытого стрима с тренировочными QA-собеседованиями: ведущий опрашивает Светлану, Павла и Максима, уточняет их ответы и разбирает типичные ошибки. Обсуждаются основы тестирования, API и Postman, клиент-серверная архитектура, тест-дизайн, баг-репорты, жизненный цикл дефекта, авторизация, базы данных, кроссбраузерность и мобильное тестирование. Ведущий также рассказывает о своём курсе и заявленном плане рекомендовать наиболее подготовленных учащихся HR-специалистам; это не подтверждение трудоустройства участников эфира.

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

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

  • Для ответов на интервью полезно чётко разделять проверку требований без запуска продукта и проверку готового продукта; ведущий объясняет это через верификацию и валидацию на примере производства сумок.
  • Регрессию нельзя сводить только к изменённому участку: при нехватке времени сначала проверяют критичные пользовательские и денежные сценарии, затем затронутые модули по release notes и информации от разработчиков.
  • По позиции ведущего, Postman в резюме стоит подкреплять умением писать автопроверки на JavaScript; для старта достаточно функций, переменных, типов данных, условий и циклов, а не глубокого изучения языка.
  • При диагностике ошибки регистрации или отправки формы нужно последовательно проверить отображение на клиенте, payload запроса, ответ API и фактическое сохранение данных в базе; одного HTTP 200 недостаточно.
  • В задачах «как протестировать элемент» сначала нужно собрать требования: обязательность, допустимые значения, состояние по умолчанию, локальность или глобальность изменения и ожидаемый обмен с сервером. Полезно фиксировать их в чек-листе до составления тестов.
  • Для bug report нужны конкретные заголовок и модуль, предусловия, шаги, ожидаемый и фактический результаты, окружение и воспроизводимое вложение; расплывчатые формулировки осложняют исправление.

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