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

Короткий ответ: adb управляет Android-устройством или эмулятором: установка сборки, сброс данных, deep links, скриншоты и logcat — системный лог, который фильтруют по процессу приложения. xcrun simctl делает то же для iOS-симулятора (macOS с Xcode): установка, запуск, openurl, симулированный push, скриншот и log stream. В баг-репорт идёт лог вокруг момента сбоя, а не весь поток за час.

Подробно:

1. Чистый старт — pm clear сбрасывает данные приложения, logcat -c очищает буфер перед воспроизведением.
2. Лог только приложения — фильтр --pid по процессу; краши Android лежат в буфере crash, для ANR и системных проблем есть adb bugreport (zip-архив).
3. Сценарии — deep link через am start -a VIEW -d, гибель процесса в фоне через am kill, разрешения через install -g или pm grant.
4. iOS — simctl push проверяет обработку push без APNs, simctl privacy выдаёт и сбрасывает разрешения; логи и отчёты о крашах реального iPhone берут в Xcode (Devices and Simulators) или в Console.app.

# Android: устройство или эмулятор
adb devices                                  # подключено?
adb install -r -g app-debug.apk              # переустановить, выдать права
adb shell pm clear com.example.shop          # сбросить данные
adb logcat -c                                # очистить лог перед шагами
adb logcat --pid=$(adb shell pidof -s com.example.shop) > app.log
adb logcat -b crash -d                       # стеки последних крашей
adb shell am start -a android.intent.action.VIEW -d "shop://orders/42"
adb exec-out screencap -p > screen.png

# iOS Simulator (macOS + Xcode)
xcrun simctl install booted Shop.app
xcrun simctl launch booted com.example.shop
xcrun simctl openurl booted "shop://orders/42"
xcrun simctl push booted com.example.shop push.json
xcrun simctl io booted screenshot screen.png
xcrun simctl spawn booted log stream --predicate 'process == "Shop"'

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

Короткий ответ: Примитив хранит само значение, а переменная ссылочного типа хранит ссылку на объект. Локальные переменные лежат в стеке потока, объекты в куче. Аргументы в Java всегда передаются по значению: для объекта копируется ссылка, а не сам объект.

Подробно:

1. Примитивы — byte, short, int, long, float, double, char, boolean. Не бывают null, == сравнивает значения.
2. Ссылочные типы — классы, интерфейсы, массивы. Переменная может быть null, == сравнивает ссылки.
3. Где лежат — зависит от места объявления: локальный int находится в кадре стека, поле int внутри объекта в куче. JIT может убрать аллокацию объекта, но поведение программы от этого не меняется.
4. Передача в метод — метод получает копию. Через копию ссылки можно изменить общий объект: хелпер с users.add(...) меняет тестовые данные и у вызывающего теста. А вот перенаправить его переменную на другой объект нельзя.

static void change(int count, List<String> users) {
    count++;                     // копия числа
    users.add("bob");            // копия ссылки, объект тот же
    users = new ArrayList<>();   // меняется только локальная копия
}

int count = 1;
List<String> users = new ArrayList<>(List.of("ann"));
change(count, users);
System.out.println(count);       // 1
System.out.println(users);       // [ann, bob]

⚠️ Частая ошибка: говорить, что объекты передаются по ссылке. Тогда users = new ArrayList<>() заменил бы список и у вызывающего кода, а этого не происходит.