Подготовка к собеседованию — Автоматизатор тестирования (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», а не список любимых браузеров.

Короткий ответ: Изменяемый объект можно менять на месте (list, dict, set), неизменяемый — нельзя (int, str, tuple). Перепривязка переменной и изменение объекта — разные действия.

items = [1, 2]
alias = items
items.append(3)
assert alias is items and alias == [1, 2, 3]

text = "hello"
original = text
text += " world"
assert original == "hello"  # исходная строка не изменилась

Подробно:

• id() идентифицирует объект и постоянен в течение его жизни. То, что это адрес памяти, — деталь реализации CPython.
• В кортеже нельзя заменить элементы, но вложенный список может изменяться. Неизменяемость не означает автоматически глубокую неизменяемость или потокобезопасность.
• Ключ словаря и элемент множества должны быть хешируемыми: хеш остаётся стабильным, а равные объекты имеют равные хеши. Кортеж со списком нехешируем. Изменяемый экземпляр пользовательского класса может хешироваться по идентичности: хешируемость не синоним неизменяемости.
• Функция получает ссылки на объекты. Мутация аргумента может быть видна вызывающему коду; перепривязка локального параметра не перепривязывает переменную снаружи.

Источники: Хешируемость Python, идентичность объектов.