Подготовка к собеседованию — Автоматизатор тестирования (AQA)

Короткий ответ: Полноценный тест-кейс с предусловиями, шагами и ожидаемым результатом нужен там, где важна воспроизводимость и трассируемость: аудит, комплаенс, сложные многошаговые флоу. Лёгкий чек-лист достаточен для регрессии по стабильным фичам и 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», а не список любимых браузеров.

Короткий ответ: Selenium поддерживает восемь стратегий: id, name, className, tagName, linkText, partialLinkText, cssSelector и xpath. CSS быстрее и читаемее, но XPath умеет то, чего CSS не может: подниматься вверх и назад по DOM (ancestor, parent, preceding-sibling) и искать элемент по тексту. В этом вся асимметрия.

Подробно:

1. CSS-селектор — стандарт по умолчанию: короткий синтаксис, работает быстрее (браузер оптимизирует CSS-движок), покрывает 90% случаев.
2. XPath навигация вверх — только XPath дойдёт от найденного элемента к родителю/предку: //span[text()='Итого']/ancestor::tr.
3. XPath по тексту — //button[text()='Оплатить'] или contains(text(),'...'); в CSS поиска по текстовому содержимому нет вообще.

⚠️ Частая ошибка: не знать асимметрию и отвечать «XPath мощнее». Мощнее только в навигации вверх и по тексту — во всём остальном по умолчанию берут CSS.