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

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

Подробно:

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

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

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

Короткий ответ: 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/попарное тестирование даёт покрытие пар без комбинаторного взрыва.

Браузер	Доля аудитории	Приоритет
Chrome (Win)	58%	P0
Safari (iOS)	22%	P0
Chrome (Android)	12%	P1
Firefox / Edge	6%	P2
IE / прочие	2%	не тестируем

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

Короткий ответ: SELECT извлекает строки из таблиц. Логический порядок выполнения НЕ совпадает с порядком написания: сначала FROM, затем WHERE, GROUP BY, HAVING, SELECT, DISTINCT, ORDER BY, LIMIT.

Подробно:

Порядок написания (синтаксический):

SELECT   DISTINCT col1, agg(col2)
FROM     t
WHERE    cond
GROUP BY col1
HAVING   agg_cond
ORDER BY col1
LIMIT    10 OFFSET 20;

Логический порядок исполнения:

1. FROM / JOIN      -- какие таблицы, как соединить
2. WHERE            -- фильтр строк ДО группировки
3. GROUP BY         -- группировка
4. HAVING           -- фильтр групп ПОСЛЕ агрегации
5. SELECT           -- вычисление выражений, алиасов
6. DISTINCT         -- удаление дублей
7. ORDER BY         -- сортировка
8. LIMIT / OFFSET   -- срез

⚠️ Ловушка: алиас из SELECT нельзя использовать в WHERE (т.к. WHERE выполняется раньше SELECT), но можно в ORDER BY и часто в GROUP BY (зависит от СУБД). Пример ошибки:

SELECT salary * 12 AS annual FROM emp WHERE annual > 100000; -- ОШИБКА
SELECT salary * 12 AS annual FROM emp ORDER BY annual;        -- ОК