QA Инженер

Парсите JSON JSON Formatter (плагин для браузера), jq в консоли

---

6. Главные ошибки новичков

· Смотрят только UI и пишут баг «не работает», а нужно показать конкретный ответ API или запрос.
· Бухтят в БД без транзакции (загрязняют данные, мешают другим тестам).
· Не берут логи в момент воспроизведения (а через час они уже перезаписаны).
· Путают 400 (ошибка клиента) и 500 (ошибка сервера) — разные команды на починку.

Это золотой стандарт QA выше среднего. Когда вы перестаёте верить UI и лезете «под капот» — вы становитесь настоящим инженером. UI может врать, а логи, БД и API показывают правду.

Давайте разберём каждый слой детально.

---

1. Анализ API (Backend без интерфейса)

Что проверяете:

· Статус-коды (200 OK, 400 Bad Request, 500 Internal Error, 401 Unauthorized).
· Тело ответа (JSON/XML) — структура, типы данных, значения.
· Заголовки (Content-Type, Authorization, CORS).
· Время ответа (если > 2 сек — уже повод задуматься).

Главные инструменты:

· Postman / Insomnia — ручные запросы + коллекции автотестов.
· cURL — для быстрых проверок из консоли.
· Swagger / OpenAPI — документация, по которой вы сверяетесь.
· Charles / Fiddler — перехват трафика между фронтом и бэком (видите, что реально уходит).

Ваши действия:

1. Открываете DevTools (F12) → вкладка Network.
2. Смотрите запрос: какие параметры ушли? (Тело, заголовки, куки).
3. Смотрите ответ: соответствует ли ТЗ? (Ключ user_id вернулся?).
4. Шлёте тот же запрос напрямую в Postman — отдельно от UI, чтобы понять: баг во фронте или в бэке.

---

2. Анализ БД (База данных)

Что проверяете:

· Корректность сохранения данных после действия пользователя.
· Целостность связей (внешние ключи, каскадное удаление).
· Типы данных (не записалось ли "123" как строка в числовое поле).
· Триггеры и хранимые процедуры (логика на стороне БД).

Инструменты:

· SQL-клиенты: DBeaver, DataGrip, pgAdmin (PostgreSQL), MySQL Workbench.
· Базовые запросы: SELECT, INSERT, UPDATE, DELETE, JOIN, WHERE.

Пример на практике:

· Вы создали заказ в UI → идёте в БД:
```sql
SELECT * FROM orders WHERE user_id = 123 ORDER BY created_at DESC LIMIT 1;
```
· Проверяете: total_price совпадает с суммой товаров? status = 'NEW'? Поле created_at заполнилось?

Продвинутый уровень:

· Знаете схему БД наизусть для своего продукта.
· Можете написать запрос с несколькими JOIN, чтобы проверить сложную логику.
· Умеете читать EXPLAIN (план выполнения запроса) — если запрос тормозит.

---

3. Анализ логов (Logs)

Что это: текстовые файлы (или вывод в консоль/Kibana), куда приложение пишет все события: ошибки, предупреждения, информационные сообщения, стектрейсы.

Что ищете:

· ERROR / FATAL — явные падения.
· WARN — потенциальные проблемы (например, таймаут или повторная попытка).
· Стек вызовов (Stack Trace) — чтобы показать разработчику точное место в коде.
· Логи на уровне DEBUG — включаете, чтобы увидеть входные параметры и промежуточные вычисления.

Инструменты:

· Вручную: терминал (tail -f logs/app.log), файлы на сервере.
· Визуализация: Kibana / Grafana (централизованный сбор, поиск по времени).
· Консоль браузера (F12 → Console) — логи фронтенда.

Как читать стектрейс:

```
java.lang.NullPointerException at com.payment.PaymentService.process(PaymentService.java:42)
```

— значит, ошибка на 42-й строке в классе PaymentService. Эту информацию вы копируете в баг-репорт.

Главное правило:

· Логируйте время инцидента (чтобы найти его в общем потоке).
· Запрашивайте уровень логирования — по умолчанию часто стоит INFO, а для отладки включайте DEBUG.

---

4. Как это работает в связке (реальный сценарий)

Ситуация: Пользователь оплачивает заказ, но получает ошибку «Недостаточно средств» (хотя деньги есть).

Ваш путь как QA:

1. API: Шлёте запрос на оплату через Postman → получаете 500 Internal Error.
2. БД: Проверяете баланс пользователя (SQL) — видите, что сумма корректна.
3. Логи: Идёте в Kibana, фильтруете по времени, находите стектрейс:
SQLException: Connection timed out — проблема с сетью до БД.
4. Вывод: Баг не в логике, а в инфраструктуре. Создаёте баг-репорт, прикрепляя стектрейс и ответ API, но назначаете не разработчику, а DevOps.

---

5. Инструменты-шпаргалки

Что делаете Инструменты
Смотрите трафик DevTools (Network), Charles, Fiddler
Шлёте API-запросы Postman, Insomnia, cURL
Проверяете БД DBeaver, DataGrip, pgAdmin, MySQL Workbench
Ищете ошибки в логах Kibana, Grafana, grep, tail -f

· Пишут заголовок «Не работает» — бесполезно для поиска.
· Не обновляют статус после проверки фикса (забивают).

---

8. Шпаргалка-памятка

Запомните аббревиатуру STAR для бага:

· S — Steps (шаги)
· T — Test data (данные)
· A — Actual (что было)
· R — Result expected (что должно быть)

Баг-трекер — это не просто «тулза для записи косяков», а центр управления качеством. Через него коммуницируют все: менеджер ставит приоритеты, разработчик видит, что чинить, а QA отслеживает историю продукта.

Вот полный разбор для QA:

---

1. Популярные системы (ваш выбор)

· Jira — стандарт индустрии (гибкая, кастомизируемая, интеграции с Confluence, TestRail, Git).
· YouTrack — легковесный, удобный для агile-команд, от JetBrains.
· Redmine — бесплатный, но устаревший интерфейс.
· Trello / Asana — для маленьких команд (вместо досок).
· Bugzilla / Mantis — классические, бесплатные, но редко сейчас.

---

2. Структура идеального баг-репорта (ваш шаблон)

Каждый баг должен отвечать на 5W + H:

· Заголовок — суть одной фразой (макс. 50 символов).
Пример: «Кнопка "Оплатить" неактивна при выборе карты Mastercard»
· Важность (Priority / Severity):
· Severity (технический урон):
Blocker (краш), Critical (потеря данных), Major (не работает основная фича), Minor (опечатка), Trivial (не влияет).
· Priority (бизнес-важность):
Highest, High, Medium, Low — ставит менеджер или лид.
Важно: «Blocker» в тесте может стать «Low» для бизнеса (например, баг в неиспользуемой фиче).
· Шаги воспроизведения (Steps to Reproduce) — пошагово и номерами (1, 2, 3).
Плохо: «Зайдите и нажмите там...»
Хорошо: «1. Открыть страницу /login. 2. Ввести логин 'test'. 3. Нажать Enter».
· Фактический результат (Actual) — что произошло.
· Ожидаемый результат (Expected) — что должно быть по ТЗ.
· Окружение (Environment) — ОС, браузер, версия приложения, девайс, разрешение экрана.
· Вложения — скриншоты, видео (желательно с подсветкой проблемы), логи, HAR-файлы, дампы БД.
· Дополнительно (опционально):
· Связанные задачи (Links) — дубли, эпики.
· Тест-данные — логин/пароль для воспроизведения.

---

3. Жизненный цикл бага (статусы)

Стандартный поток (в Jira это может называться иначе):

1. New / Open — вы создали.
2. Triaged — менеджер или лид подтвердил, что это действительно баг (отсеивает «не баг» / «работает как задумано»).
3. In Progress — разработчик начал чинить.
4. Fixed / Resolved — код изменён, деплой на тестовый стенд.
5. In Retest — QA проверяет на том же окружении.
6. Verified / Closed — баг исправлен, закрываем.
7. Reopened — если не починили или воспроизвелось на проде.
8. Duplicate — такой уже есть (вы ищете дубли по поиску до создания!).
9. Won’t Fix / Cannot Reproduce — закрыт без правки (по решению команды).

---

4. Ваши действия в трекере (кроме создания)

· Триаж багов — участие в ежедневных/еженедельных встречах, где команда обсуждает: «Сколько багов? Какие самые критичные? Кто чинит?».
· Обновление статусов — если баг воспроизводится на новой версии, напишите об этом в комментарии.
· Проверка дублей — перед созданием обязательно поищите по ключевым словам.
· Переоткрытие — если фикс не полный, аргументируйте в комментарии (скриншот, лог).
· Приоритезация — помогаете менеджеру оценить, что блокирует релиз, а что потерпит.

---

5. Золотые правила общения (софт-скиллы)

· Не пишите «сломалось» — пишите что, где, при каких условиях.
· Не ставьте статус «Blocker» без веской причины (если только не креш и потеря данных).
· Будьте дипломатичны — баг — это не «ты плохой программист», а «мы упустили этот сценарий».
· Никогда не пишите в баг-репорте эмоции — только факты и логи.
· Если не можете воспроизвести у себя — попросите разработчика показать его окружение (версия БД, конфиги).

---

6. Продвинутый уровень (для Middle+)

· Интеграция с автотестами — настраиваете автозаливку багов при падении ночных прогонов (через Jira API).
· Дашборды — строите графики: количество багов по дням, среднее время жизни (MTTR), наиболее «багованные» модули.
· Root Cause Analysis — ищете системные проблемы (например, «80% багов из-за того, что нет документации по API»).

---

7. Главные ошибки новичков

· Создают дубли (не поискали перед созданием).
· Забывают указать окружение (бесполезный репорт).

Автоматизация тестирования — это не «замена ручек роботами», а инвестиция в скорость и повторяемость. Рука проверит 10 сценариев за час, а авто — 1000 за 5 минут, но только если они стабильны и не меняются каждый день.

Вот полный разбор для QA:

---

1. Что именно автоматизируем (пирамида)

· Модульные тесты (Unit) — пишут разработчики (JUnit, PyTest). Проверяют функции изолированно. Самый дешёвый и быстрый слой.
· API-тесты — ваш главный фокус (Postman/Newman, REST Assured, SoapUI). Проверяют логику без UI. Стабильны и быстры.
· UI-тесты — через браузер (Selenium, Playwright, Cypress). Самые дорогие и хрупкие (из-за изменения селекторов). Должны быть только на критический путь.

---

2. Типичный стек (чем пишут)

· Языки: Python (Pytest), Java (TestNG/JUnit), JavaScript/TypeScript (Jest, Mocha).
· Фреймворки: Selenium WebDriver, Playwright, Cypress, Appium (мобилки).
· API: REST Assured (Java), Requests (Python), Postman + Newman.
· Отчёты: Allure, ExtentReports.
· CI/CD: Jenkins, GitLab CI, GitHub Actions (запуск автотестов после каждого коммита).

---

3. Из чего состоит хороший автотест (структура)

По паттерну AAA (Arrange-Act-Assert):

· Arrange — подготовка: создать юзера, заполнить БД тестовыми данными.
· Act — действие: отправить запрос / кликнуть кнопку.
· Assert — проверка: статус 200, в БД появилась запись, элемент виден.

Обязательно:

· @BeforeEach / setup — очистка состояния перед каждым тестом (чтобы тесты не влияли друг на друга).
· Уникальные тестовые данные (рандомизация), чтобы не было конфликтов.

---

4. Когда запускаем (стратегия)

· Smoke-авто — на каждый PR (быстро, 5–10 мин) — упало → не сливаем в мастер.
· Регрессия — ночью или перед релизом (тысячи тестов, 1–2 часа).
· По расписанию — например, каждое утро на свежее окружение.

---

5. Главные сложности (с чем боретесь)

· Flaky-тесты — сегодня зелёный, завтра красный без изменений кода (киллер доверия). Причины: тайминги, асинхронность, состояние БД.
· Поддержка — меняется селектор → чините 50 тестов. Решение: Page Object Model (выносите локаторы в отдельные классы/файлы).
· Тестовые данные — если БД общая, тесты мешают друг другу. Решение: Docker-контейнеры с чистой БД на каждый прогон.
· Окружение — тесты падают из-за того, что сервер не поднялся, а не из-за бага.

---

6. Page Object Model (ваша архитектура)

Главный паттерн в UI-авто:

· Page — класс с локаторами и методами (LoginPage.inputLogin()).
· Test — только вызовы методов и ассерты (без findElement в тестах!).

Пример (Python + Selenium):

```python
class LoginPage:
def login(self, user, pwd):
self.enter_login(user)
self.enter_pwd(pwd)
self.click_submit()

def test_login_ok():
main_page = LoginPage(driver).login("valid", "valid")
assert main_page.get_username() == "John"
```

---

7. Когда НЕ надо автоматизировать

· Фича меняется каждую неделю (переписывать дороже).
· Нужно проверить UI-визуал (шрифты, отступы) — это делают глазами.
· Разовый тест (например, миграция данных).
· Авто тест дольше писать, чем проверять руками 1 раз.

---

8. Градация навыков в авто

· Junior AQA — пишет тесты по готовому фреймворку, правит локаторы.
· Middle — настраивает фреймворк с нуля, пишет хелперы, интегрирует с CI.
· Senior — строит тестовую инфраструктуру (Docker + виртуализация), внедряет BDD (Cucumber), учит команду.

---

9. Главная метрика

Не % покрытия кода, а время выполнения регрессии (было 2 дня ручками → стало 20 минут авто).

Ручное тестирование (Manual Testing) — это не «нажимать на кнопки наугад», а осознанная исследовательская деятельность. Автоматизация проверяет то, что вы уже знаете, а руками вы находите неизвестное.

Вот полная картина:

---

1. Виды ручного тестирования (по целям)

· Функциональное — работает ли так, как написано в ТЗ? (клик → результат).
· Регрессионное — не сломали ли старые фичи новым кодом? (выборочная проверка ядра).
· Смоук (Smoke) — «дымит ли» билд? (критический путь за 10–15 минут, чтобы дать зелёный свет команде).
· Санитарное (Sanity) — узкая проверка конкретной фиксации бага.
· Исследовательское (Exploratory) — без чек-листа, вы изучаете продукт как хакер, ища неочевидные баги (обязательно с записью шагов!).
· Приёмочное (UAT) — от имени заказчика: всё ли готово к релизу?

---

2. Чем вы реально пользуетесь (артефакты)

· Тест-кейсы — пошаговые инструкции (TestRail/Excel): предусловие, шаги, ожидаемый результат.
· Чек-листы — список «что проверить» без детальных шагов (быстрее, но требует опыта).
· Тест-раны (Test Runs) — прогон на конкретной версии/окружении.
· Баг-репорты — ваша главная ценность: заголовок, шаги воспроизведения, фактический vs ожидаемый результат, логи, скриншоты/видео.

---

3. Что проверяете помимо «кликнул-открылось»

· UI — соответствует ли макету (пиксель-хантинг), адаптивность.
· API — что сервер возвращает (Postman/Swagger) и как приложение это обрабатывает.
· БД — корректно ли сохранились данные (SQL-запросы).
· Логи — нет ли красных ошибок (Kibana/консоль браузера).
· Конфиги — не слетели ли настройки при деплое.
· Сеть — поведение при потере связи, перезапуске сервера.

---

4. Техники выполнения (ваши суперсилы)

· Тестирование на счастливый и несчастливый пути (Happy/Negative Path) — сначала «как надо», затем «как не надо» (пустое поле, спецсимволы, превышение лимитов).
· Тестирование вслепую (Gorilla Testing) — многократный прогон одного модуля в поисках ресурсных багов (утечка памяти).
· Монки-тестинг — хаотичные клики без сценария (иногда находит краши, но редко).
· Сессионное тестирование — ставите таймер (напр. 45 мин) и фокусируетесь на одной зоне риска.

---

5. Типичные ошибки начинающих

· Сразу лезут в фичу, не прочитав ТЗ.
· Перепроверяют одно и то же 5 раз вместо того, чтобы покрыть новое.
· Стесняются спросить у разработчика, «как это должно работать».
· Пропускают окружение (тест на Проде отличается от Теста).
· Не чистят кэш/куки между тестами — получают ложные баги.

---

6. Когда руками — это круто, а авто — нет

· UX/юзабилити — сложно автоматизировать «удобно/неудобно».
· Визуальная вёрстка — авто не заметит сдвиг на 2px.
· Новые фичи — пока нет стабильного UI под автотесты.
· Кратковременные проекты — писать авто дороже, чем накликать за час.

---

7. Ваш главный девиз (запомните)

«Ручка — это не про тупое выполнение, а про интеллектуальный отбор самых опасных мест и исследование зон неопределённости»

Тест-дизайн — это не «придумывание рандомных тестов», а научный подход к выбору минимального количества тестов, которые найдут максимум багов. Это математика и логика, а не творчество.

Вот полная картина для QA:

---

1. Зачем это нужно?
— Невозможно проверить все значения (например, поле «возраст» от 0 до 150 — это 151 вариант, а если 3 поля — уже миллионы).
— Тест-дизайн сокращает количество тестов в 10–100 раз, сохраняя покрытие критичных сценариев.

---

2. Базовые техники (обязательный минимум)

Классы эквивалентности (Equivalence Partitioning)
— Делим входные данные на группы (классы), где поведение системы одинаково.
— Пример: поле «возраст» (0–120). Классы:

· Валидный: 1–120 (берём 1 тест, например 30).
· Невалидные: отрицательные (‑5), 0, >120 (150), буквы («abc»).
— Итог: 4 теста вместо 121.

Анализ граничных значений (Boundary Value Analysis)
— Баги чаще всего живут на границах (ошибка <= вместо <).
— Пример: возраст 1–120. Границы:

· Минус‑1, 0, 1, 2 (внутренняя граница), 119, 120, 121, 122.
— Важно: проверяем как саму границу, так и соседние значения.

Попарное тестирование (Pairwise Testing)
— Когда много комбинаций параметров (например, Браузер + ОС + Разрешение).
— Основано на теории: большинство багов вызваны взаимодействием всего двух параметров.
— Пример: 3 браузера × 2 ОС × 3 разрешения = 18 комбинаций. Pairwise сжимает до 6–8 тестов, сохраняя все пары значений.

Таблицы принятия решений (Decision Tables)
— Для проверки бизнес-логики с несколькими условиями (например, расчёт скидки).
— Рисуете таблицу: все комбинации «Если А=Да, Б=Нет → Результат X».
— Помогает найти пропущенные правила в требованиях.

Тестирование состояний и переходов (State-Transition)
— Для систем с разными статусами (заказ: Новый → В работе → Доставлен → Отменён).
— Проверяете все разрешённые и запрещённые переходы (нельзя из «Доставлен» вернуть в «Новый»).

---

3. Продвинутые техники (для Middle+)

· Use Case Testing — сценарии от начала до конца по реальным действиям пользователя.
· Error Guessing — «чуйка» баг-хантера (места, где чаще всего ошибаются: кэш, таймауты, кодировки).
· Domain Analysis — комбинация EP + BVA для сложных зависимостей.

---

4. Как это выглядит на практике

1. Вы получаете задачу (например, «фильтр товаров по цене»).
2. Применяете техники → получаете компактный чек-лист:
· Цена от 0 до 1 000 000 (границы: 0, 1, 999999, 1000000, 1000001).
· Пустое поле, отрицательная, дробная, буквы.
· Комбинации: цена + бренд + скидка (Pairwise).
3. Отдаёте чек-лист разработчику до начала кодинга — он сразу видит, о чём не подумал.

---

5. Главные ошибки новичков

· Тестировать «средние» значения (30 лет) — багов там почти нет.
· Проверять все комбинации вручную — выгорание гарантировано.
· Прыгать в тесты без техник — пропускаете критические границы.

---

6. Бонус: память-шпаргалка
Запомните аббревиатуру BECPT:

· Boundary (границы)
· Equivalence (классы)
· Combinations (Pairwise)
· Path (состояния)
· Table (Decision Tables)

Анализ требований (Requirements Analysis) — это фундамент QA. Если требования плохие, то даже идеальный код не спасёт: вы проверите «не то» и «не так».

Вот как это выглядит в работе QA-инженера по шагам:

1. Роли и артефакты
Вы работаете с:
— Бизнес-требованиями (что хотим получить).
— Функциональными требованиями (как система должна работать).
— Макетами/дизайном (как это выглядит).
— User Stories и Acceptance Criteria (критерии готовности).

2. Что именно анализируем?
QA смотрит на текст как «адвокат дьявола»:
— Полнота — описаны ли все сценарии? (Что при пустом поле? Что при обрыве сети?)
— Однозначность — нет ли двойных трактовок («быстрый ответ» — это 1 сек или 3 сек?).
— Непротиворечивость — не пересекаются ли требования с другими модулями?
— Тестируемость — можно ли это объективно проверить? (Если написано «красивый интерфейс» — это не тестируемо. Если «кнопка #FF0000» — тестируемо).
— Реалистичность — выполнимо ли это в текущих сроках и стеке?

3. Основные инструменты (техники)
— Mind Maps — рисуете связи, чтобы не упустить побочные эффекты.
— Разбор пограничных случаев (Edge Cases): например, ввод 9999 символов, нулевая сумма, дата 29 февраля.
— Применение техник эквивалентности: деление диапазонов на классы (валидные/невалидные) ещё до старта разработки.
— Составление вопросников: по шаблону “Что если…” (What-If Analysis).

4. Практические действия
На практике вы:
— Участвуете в Refinement / Grooming (обсуждение задач до спринта).
— Пишете уточняющие комментарии прямо в задаче (Jira/Confluence).
— Создаёте декомпозицию: разбиваете одну большую фичу на десятки проверяемых пунктов.
— Формируете тестовые оракулы: определяете, где брать эталонный результат (БД, калькулятор, старый сервис).

5. Главная «суперсила» QA здесь
— Сдвиг влево (Shift Left) — найти ошибку на этапе «бумажки» стоит в 100 раз дешевле, чем на проде.
— Вы страхуете разработчика: если он пишет код по плохому ТЗ, он переделает его 3 раза. Вы экономите время всей команды.

Типичные ошибки джуниора:
— Сразу открыть приложение и начать кликать (исследовательское — это позже).
— Игнорировать нефункциональные требования (производительность, безопасность, юзабилити).

Ваш главный вопрос на встречах:

«А что именно должно произойти, если…?» — и фиксировать ответ прямо в задаче.

ТЕОРИЯ

Инженер по обеспечению качества (QA) — это «адвокат пользователя», который проверяет, что продукт работает корректно, безопасно и удобно. Он не просто «находит баги», а предотвращает дефекты на всех этапах разработки.

Ключевые области (чем занимается):

· Анализ требований — поиск противоречий еще до написания кода.
· Тест-дизайн — придумывание сценариев (позитивных, негативных, граничных).
· Ручное тестирование (функциональное, регрессионное, исследовательское).
· Автоматизация (если это AQA) — написание кода на Python/Java/JS для автотестов.
· Работа с баг-трекерами (Jira, YouTrack) и документацией (TestRail, Allure).
· Анализ логов, БД, API (Postman, Swagger, SQL) для поиска корня проблемы.

Главные скиллы (хард):

· Понимание клиент-серверной архитектуры.
· Знание техник тест-дизайна (эквивалентность, граничные значения, попарное тестирование).
· Основы SQL, HTTP, JSON/XML, Git.
· Для автоматизации — Pytest/JUnit, Selenium/REST Assured, CI/CD (Jenkins/GitLab).

Мягкие навыки (софт):

· Критическое мышление и внимание к деталям.
· Умение четко описывать шаги воспроизведения (чтобы разработчик понял с первого раза).
· Коммуникация и дипломатичность (баги — это информация, а не претензия).
· Проактивность (предложить улучшение процесса, а не просто выполнить чек-лист).

Уровни грейдов (для резюме):

· Junior — выполняет готовые тест-кейсы, учится.
· Middle — проектирует стратегию тестирования, приоритезирует, пишет автотесты.
· Senior — улучшает процессы, внедряет инструменты, менторит, отвечает за качество на уровне команды.
· Lead — строит QA-культуру в компании.

Главная метрика успеха:
Не количество найденных багов, а количество багов, не попавших в прод.