Подготовка к собеседованию — QA-инженер (ручное тестирование)

Короткий ответ: Полноценный тест-кейс с предусловиями, шагами и ожидаемым результатом нужен там, где важна воспроизводимость и трассируемость: аудит, комплаенс, сложные многошаговые флоу. Лёгкий чек-лист достаточен для регрессии по стабильным фичам и exploratory-сессий, где важнее скорость.

Подробно:

1. Тест-кейс — формальный документ, любой может повторить шаг в шаг; дорого писать и поддерживать.
2. Чек-лист — список того, что проверить, без детальных шагов; быстро составить, гибко использовать.
3. Критерий выбора — цена поддержки против требований к строгости и аудируемости.

⚠️ Частая ошибка: тянуть тяжёлые формальные тест-кейсы туда, где хватает списка проверок, и утонуть в поддержке документации вместо реального тестирования. Интервьюер хочет услышать обоснование выбора при нехватке времени.

Короткий ответ: New → Assigned → In Progress → Fixed → Retest → Closed. Это основной поток, но у него есть важные ветвления: Reopened (баг вернулся после фикса), Rejected (не баг), Duplicate (уже заведён), Deferred (отложен). Ключ в ответе — назвать не только линию, но и ветки, и кто выполняет каждый переход.

Подробно:

1. New — тестировщик завёл баг.
2. Assigned → In Progress — лид назначил разработчика, тот взял в работу.
3. Fixed — разработчик починил и передал на проверку.
4. Retest → Closed — тестировщик перепроверил на новом билде и закрыл.
5. Ветки — Reopened (тестировщик), Rejected/Duplicate (разработчик или лид), Deferred (PM отложил на потом).

 New ──► Assigned ──► In Progress ──► Fixed ──► Retest ──► Closed
 (QA)     (лид)         (dev)         (dev)     (QA)       (QA)
           │                                      │ не прошёл
           ▼                                      ▼
 Rejected / Duplicate (dev, лид)           Reopened ──► снова в работу
 Deferred (PM отложил)

⚠️ Частая ошибка: назвать только прямую линию New→Closed и забыть про ветки Reopened/Rejected/Duplicate/Deferred — именно они показывают, что вы работали с реальным трекером.

Короткий ответ: Клиент (браузер, мобильное приложение) отправляет запрос, сервер обрабатывает его и возвращает ответ — модель request/response поверх HTTP. Полагаться на клиентскую валидацию нельзя, потому что клиент полностью под контролем пользователя: форму можно обойти через curl, Postman или DevTools и отправить на сервер любые данные. Поэтому сервер обязан валидировать сам, а QA проверяет оба слоя независимо.

Подробно:

1. Клиент — рисует UI, делает первичную валидацию для удобства (быстрый фидбек, без лишнего трафика), хранит токен.
2. Сервер — источник правды: проверяет права, валидирует тело, пишет в БД. Это единственный слой, которому можно доверять.
3. Что делает QA — не только кликает по UI, но и бьёт прямо в API в обход клиента: отправляет пустые/невалидные поля, чужой id, инъекции — и смотрит, что сервер их отбил (400/403), а не сохранил.

  КЛИЕНТ                         СЕРВЕР
 ┌────────┐   request  (HTTP)  ┌─────────┐
 │  UI    │ ─────────────────► │  API    │
 │ ✔ UX-  │                    │ ✔ обяза-│
 │ валид. │ ◄───────────────── │ тельная │──► БД
 └────────┘   response         │ валид.  │
     ▲  можно обойти:          └─────────┘
     └── curl / Postman / DevTools

⚠️ Частая ошибка: считать, что раз кнопка «Отправить» блокируется на форме, невалидные данные до сервера не дойдут. UI обходится за секунду — надёжная система проверяет всё на сервере.

Короткий ответ: Кроссбраузерное тестирование — проверка, что приложение одинаково работает в разных браузерах, версиях и ОС. Матрицу строят не «все браузеры», а от аналитики трафика аудитории и риска: полный перебор браузер × ОС × разрешение нереален, поэтому его сокращают приоритизацией и pairwise-подходом.

Подробно:

1. Отталкиваться от данных — аналитика (GA и т.п.) показывает реальные доли браузеров/ОС/устройств у вашей аудитории.
2. Приоритет по покрытию и риску — сначала комбинации, покрывающие большинство пользователей и критичные потоки (оплата, регистрация).
3. Сокращать перебор — pairwise/попарное тестирование даёт покрытие пар без комбинаторного взрыва.

⚠️ Частая ошибка: не суметь обосновать выбор матрицы («проверил, где было под рукой»). Интервьюер ждёт логику «данные аудитории + риск + pairwise», а не список любимых браузеров.

Короткий ответ: За 2 взвешивания. Делю не пополам, а на группы 3-3-2, потому что весы дают три исхода (левая тяжелее / правая тяжелее / равно), а значит на каждом шаге отсеиваю сразу треть.

Подробно:

1. Первое взвешивание — 3 против 3, две монеты откладываю.
   • Если чаша перевесила — фальшивка среди 3 на поднявшейся (лёгкой) стороне.
   • Если равно — фальшивка среди 2 отложенных.
2. Второе взвешивание — из подозрительной группы кладу по 1 монете на чаши.
   • Из тройки: 1 против 1; поднялась — она фальшивая, равно — это третья, отложенная.
   • Из двойки: 1 против 1; лёгкая и есть фальшивка.
3. Почему не 3 — весы троичны: за k взвешиваний различаешь до 3^k вариантов. 3² = 9 ≥ 8, поэтому двух хватает; деление пополам (двоичное) недоиспользует исход «равно».

         8 монет
     [3] vs [3]   +2 в стороне
      /    |    \
 перевес  равно  перевес
   3        2        3
 [1]vs[1] [1]vs[1] [1]vs[1]
  → 2 взвешивания

⚠️ Частая ошибка: ответить «3», деля пополам (4-4-2-2-...). Это игнорирует, что весы дают ТРИ исхода, а не два — и теряет одно взвешивание.