## Каким должен стать такой тестировщик

Это не “кликер”, а **системный QA-исследователь**. Его задача:

* проверять **бизнес-логику и сквозные пользовательские сценарии**;
* быстро находить **нерабочие сценарии**;
* фиксировать **полный контекст дефекта**;
* понимать, где проблема: на фронте, в API, в бизнес-правилах, в бэкенде, в интеграции, в БД;
* уметь передать коллегам **воспроизводимую картину**, а не “у меня что-то не работает”.

Ему не обязательно сразу делать глубокую root-cause диагностику уровня senior backend engineer. Но он обязан уметь **сузить область проблемы** и собрать доказательства.

---

# 1. Главная модель мышления: как смотреть на систему

Новичку надо начать не с инструментов, а с мышления.

Любую систему он должен видеть как цепочку:

**Пользовательский интерфейс → клиентская логика → API → бизнес-логика сервиса → БД / внешние интеграции → обратный ответ → отображение на фронте**

Когда сценарий ломается, нужно задавать себе одни и те же вопросы:

1. **Что хотел сделать пользователь?**
2. **Что ожидалось по бизнес-правилам?**
3. **Что реально увидели на фронте?**
4. **Какой запрос ушел?**
5. **Что вернул API?**
6. **Что произошло на бэкенде?**
7. **Что сохранилось или не сохранилось в БД?**
8. **Это дефект логики, отображения, данных, интеграции или окружения?**

Это и есть базовая “операционная система” мышления хорошего QA.

---

# 2. Что должен уметь начинающий QA по итогам обучения

Через несколько месяцев обучения у него должна появиться такая способность:

Он открывает задачу вроде “заказ не оформляется при оплате бонусами” и может сам пройти путь:

* воспроизвести сценарий;
* описать шаги;
* зафиксировать, какие поля вводились;
* открыть DevTools / proxy / Postman и снять запросы;
* увидеть payload и response;
* понять, на каком шаге логика пошла не так;
* проверить логи/состояние бэкенда;
* сделать SQL-проверку в БД;
* написать баг-репорт с артефактами;
* передать коллегам понятный пакет: **видео + HAR/скрины + API + SQL-снимок состояния + вывод**.

Это очень ценная роль. На ней быстро растут в middle/senior.

---

# 3. Путь обучения по этапам

## Этап 1. Основа QA и мышление по сценариям

Сначала нужно освоить базу.

### Что изучить

* что такое тестирование и зачем оно нужно;
* виды тестирования: функциональное, интеграционное, smoke, regression, exploratory, UAT;
* что такое тест-кейс, чек-лист, баг-репорт;
* жизненный цикл дефекта;
* приоритет и серьезность;
* позитивные и негативные сценарии;
* техники тест-дизайна:

  * классы эквивалентности;
  * граничные значения;
  * таблицы решений;
  * переходы состояний;
  * pairwise;
  * причинно-следственные связи.

### Что важно именно для этого профиля

Нужно учиться мыслить не экраном, а **бизнес-сценарием**.

Не “кнопка серая”, а:

* пользователь создает заявку;
* заявка проходит валидацию;
* создается запись;
* уходит событие в сервис X;
* статус должен стать `Approved`;
* на фронте должен появиться номер заявки.

### Практика

Пусть берет любой простой сервис: интернет-магазин, CRM, трекер задач, форму регистрации.

И для каждого сценария делает разбор:

* цель сценария;
* предусловия;
* шаги;
* ожидаемый результат;
* точки контроля на каждом слое.

Например, для “создания заказа” точки контроля такие:

* UI: форма доступна, валидация работает;
* API: POST `/orders` отправился;
* backend: заказ создан;
* DB: запись появилась;
* интеграция: событие ушло;
* UI: пользователь видит номер заказа.

---

## Этап 2. Понимание веба и клиент-серверного взаимодействия

Без этого новичок не сможет быть сильным системным QA.

### Что изучить

* как работает браузер;
* HTTP/HTTPS;
* методы: GET, POST, PUT, PATCH, DELETE;
* headers, cookies, local storage, session storage;
* auth: session, token, JWT, refresh token;
* статус-коды HTTP;
* JSON;
* CORS;
* кэширование;
* idempotency;
* синхронные и асинхронные запросы;
* polling, websockets, events.

### Практика

В браузерных DevTools научиться:

* смотреть вкладку Network;
* фильтровать XHR/fetch;
* смотреть request payload;
* смотреть response;
* проверять headers;
* искать correlation/request ID;
* смотреть console errors;
* проверять DOM и состояние UI.

### Что должен уметь после этапа

Он должен открыть страницу, выполнить действие и ответить:

* какой запрос отправился;
* с какими параметрами;
* что вернул сервер;
* почему на фронте пользователь увидел именно это.

---

## Этап 3. Бизнес-логика и системное мышление

Это ключевой этап.

Новичку надо научиться читать систему как набор правил.

### Что изучить

* как читать требования: BRD, PRD, user story, acceptance criteria;
* как извлекать бизнес-правила;
* что такое workflow и state machine;
* жизненный цикл сущности:

  * заказ,
  * заявка,
  * пользователь,
  * платеж,
  * документ,
  * тикет;
* обязательные и необязательные поля;
* зависимости между ролями, статусами, фичами, лимитами;
* правила переходов состояний.

### Как учиться

Для каждой сущности нужно рисовать руками простую схему:

**Сущность → статусы → переходы → триггеры → ограничения**

Например:

**Заявка**

* Draft
* Submitted
* Under Review
* Approved
* Rejected
* Cancelled

И тестировщик должен знать:

* из Draft можно в Submitted;
* из Approved нельзя редактировать;
* при Rejected должен быть комментарий;
* при Submitted уходит уведомление;
* при Approved создается запись в другом модуле.

### Практика

Берется 1 сущность и разбирается так:

* поля;
* обязательность;
* источники данных;
* кто меняет;
* когда меняется статус;
* какие последствия.

Тогда дефекты начинают находиться намного глубже и точнее.

---

## Этап 4. API-тестирование как обязательный навык

Если человек должен собирать полную картину, без API он будет слабым.

### Что изучить

* REST API;
* endpoint, method, path params, query params, body;
* auth в API;
* коды ответов;
* стандартные ошибки;
* контракт API;
* schema;
* idempotency;
* пагинация, сортировка, фильтрация;
* versioning.

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

* Postman или Insomnia;
* Swagger / OpenAPI;
* curl;
* при возможности — Bruno или Hoppscotch.

### Что должен уметь

* отправить запрос вручную;
* повторить запрос из браузера;
* проверить тело ответа;
* сравнить ожидание с фактом;
* понять, это ошибка UI или бэка;
* собрать коллекцию запросов для регресса;
* сохранить примеры успешных и неуспешных ответов.

### Практика

Для каждого сценария делать API-карту:

* какой endpoint вызывается;
* какой payload уходит;
* какой response ожидается;
* какие поля критичны;
* какие ошибки возможны.

Например:

* создание клиента;
* получение клиента;
* обновление статуса;
* отправка в обработку.

Это резко повышает качество тестирования.

---

## Этап 5. SQL и понимание данных

Если QA должен фиксировать, “что в БД”, SQL обязателен.

### Что изучить

* таблицы;
* primary key / foreign key;
* индексы;
* связи one-to-one / one-to-many / many-to-many;
* audit-поля: created_at, updated_at, created_by, status;
* soft delete;
* транзакции;
* eventual consistency как идея.

### SQL минимум

* `SELECT`
* `WHERE`
* `JOIN`
* `ORDER BY`
* `GROUP BY`
* `COUNT`
* `IN`
* `LIKE`
* `LIMIT`
* подзапросы
* базовое понимание `INSERT/UPDATE` без практики на проде

### Что должен уметь QA

* найти запись по id, email, номеру заказа, external id;
* проверить, создалась ли сущность;
* проверить статус;
* проверить связанные записи;
* сравнить payload и то, что реально сохранилось;
* убедиться, что данные не задублировались;
* фиксировать SQL-результат в баге.

### Очень важный навык

Не просто “в БД есть запись”, а:

* **какая именно запись**;
* **какие поля важны**;
* **что не совпадает с ожиданием**;
* **на каком шаге произошло расхождение**.

---

## Этап 6. Логи, бэкенд-состояние, трассировка

Новичку не обязательно уметь дебажить сервис как разработчик, но он должен понимать признаки проблемы.

### Что изучить

* что такое application logs;
* уровни логов: info, warn, error;
* correlation ID / request ID / trace ID;
* как строится путь запроса через сервисы;
* типовые ошибки:

  * validation error,
  * null/reference error,
  * timeout,
  * 401/403,
  * 404,
  * conflict,
  * deadlock,
  * duplicate key,
  * external dependency failure.

### Что должен уметь QA

* найти по времени и request ID нужный запрос;
* сопоставить UI-действие с логами;
* выделить ключевую ошибку;
* понимать, это функциональная ошибка или инфраструктурная;
* фиксировать выдержку из логов в понятном виде.

### Что важно

Не надо сразу учить человека “читать все логи”.
Надо учить его отвечать на три вопроса:

* был ли запрос обработан;
* завершился ли он успехом;
* где виден сбой.

---

## Этап 7. Инструменты наблюдения и диагностики

Это рабочий набор QA для полной картины.

### Минимальный обязательный стек

* **Browser DevTools**
* **Postman / Insomnia**
* **SQL-клиент**: DBeaver, DataGrip
* **Система логов**: Kibana, Grafana Loki, ELK, CloudWatch, Splunk
* **Таск-трекер**: Jira / Linear / YouTrack
* **Документация**: Confluence / Notion
* **Скриншоты / запись экрана**
* **Прокси-инструмент**:

  * Charles,
  * Fiddler,
  * mitmproxy
    если нужно перехватывать и воспроизводить трафик

### Дополнительно полезно

* Kafka UI / RabbitMQ UI — если есть очереди;
* Swagger / Redoc;
* Grafana/Prometheus — базово;
* feature flag UI;
* admin-панель продукта;
* test data generators;
* mock-сервисы.

---

# 4. Как именно собирать “полную картину” при дефекте

Вот рабочий шаблон мышления, которому надо учить новичка.

## Шаг 1. Зафиксировать сценарий

Нужно записать:

* кто пользователь;
* в какой роли;
* на каком окружении;
* какие предусловия;
* что именно делал;
* какие данные вводил.

## Шаг 2. Зафиксировать фронт

* скрин или видео;
* текущий экран;
* состояние формы;
* текст ошибки;
* не тот статус;
* отсутствие ожидаемого результата;
* консольные ошибки, если есть.

## Шаг 3. Зафиксировать API

* какой запрос ушел;
* URL;
* method;
* headers при необходимости;
* request body;
* response status;
* response body;
* время запроса;
* request ID / trace ID.

## Шаг 4. Зафиксировать бэкенд

* был ли вызов обработан;
* была ли ошибка в логах;
* ключевое сообщение;
* стек/код ошибки, если доступен;
* какие сервисы участвовали.

## Шаг 5. Зафиксировать БД

* создалась ли запись;
* какой у нее статус;
* какие поля имеют неожиданные значения;
* есть ли частично созданные данные;
* есть ли дубли / сироты / несогласованность.

## Шаг 6. Сформулировать вывод

Например:

* фронт отправил корректный payload, backend вернул `200`, но запись в БД не создана;
* UI показывает успех, хотя API вернул ошибку;
* API вернул `400` из-за бизнес-валидации, но сообщение пользователю некорректно;
* данные записались частично: родительская сущность есть, дочерняя отсутствует.

Вот это и есть “полная картина”.

---

# 5. Как писать сильный баг-репорт для такого типа QA

Хороший баг-репорт для системного QA должен содержать не только “шаги/факт/ожидание”.

Нужен такой формат:

## Структура

**Заголовок**
Кратко и по сути:
`Не создается заказ при оплате бонусами, UI показывает бесконечный лоадер`

**Окружение**

* env
* build/version
* браузер/устройство
* роль пользователя

**Предусловия**

* пользователь авторизован
* на счету 500 бонусов
* корзина содержит 1 товар

**Шаги**

1. Открыть корзину
2. Выбрать оплату бонусами
3. Нажать “Оформить заказ”

**Фактический результат**

* UI зависает на лоадере
* заказ не отображается в списке

**Ожидаемый результат**

* заказ создается
* пользователь видит номер заказа и статус

**Артефакты**

* видео / скрин
* HAR / скрин запроса
* request payload
* response body
* request ID
* выдержка из логов
* SQL-снимок

**Техническое наблюдение**

* POST `/api/orders/create` вернул `200`
* в response отсутствует `orderId`
* в таблице `orders` запись не создана
* в логах сервиса `OrderService` ошибка mapping/conversion

**Предварительный вывод**

* вероятная проблема в backend-логике после успешной валидации запроса;
* UI некорректно обрабатывает пустой успешный ответ.

Такой баг любят разработчики, аналитики и руководители.

---

# 6. Чему учить по фронту, бэку и БД без перегруза

Начинающего не надо сразу делать “мини-архитектором”. Но нужно дать ему **достаточную глубину**.

## По фронту

Нужно понимать:

* из чего состоит страница;
* как происходит валидация;
* что отображается из API;
* что такое loading / error / empty state;
* что такое feature flag;
* что часть проблем — это не “не работает”, а “неверно отображается состояние”.

## По бэкенду

Нужно понимать:

* сервис принимает запрос;
* валидирует;
* выполняет бизнес-правила;
* обращается в БД/другие сервисы;
* возвращает ответ;
* пишет логи;
* иногда работает асинхронно.

## По БД

Нужно понимать:

* данные — это источник истины не всегда, но часто;
* UI может показать успех раньше, чем данные реально обработаны;
* асинхронность может ломать ожидания;
* часть проблем — это не ошибка запроса, а ошибка сохранения или последующей обработки.

---

# 7. Как построить обучение по месяцам

## Первый месяц

Фокус: база QA и веб.

Что делать:

* тест-кейсы, чек-листы, баг-репорты;
* HTTP, JSON, DevTools;
* основы требований и бизнес-правил;
* ручное тестирование простых сценариев.

Практика:

* ежедневно 1–2 сценария с полным описанием;
* каждый дефект оформлять с шагами и скринами;
* разбирать UI + Network.

## Второй месяц

Фокус: API и сценарное тестирование.

Что делать:

* Postman/Swagger;
* негативные сценарии;
* бизнес-валидации;
* трассировка запроса от UI до API.

Практика:

* повторять запросы вручную;
* собирать коллекции запросов;
* сравнивать UI и API-поведение;
* делать mini root-cause notes.

## Третий месяц

Фокус: SQL и данные.

Что делать:

* SELECT/JOIN/WHERE;
* чтение схемы;
* проверка записей;
* сопоставление payload → DB.

Практика:

* после каждого сценария проверять БД;
* писать простые запросы на проверку состояния;
* искать несогласованность данных.

## Четвертый месяц

Фокус: полная картина и системность.

Что делать:

* логи;
* correlation ID;
* сквозные сценарии;
* интеграции;
* асинхронные процессы;
* очереди/события базово.

Практика:

* оформлять баги со всеми слоями;
* делать разбор “где именно ломается”;
* строить схемы workflow.

## Пятый-шестой месяц

Фокус: уверенная рабочая самостоятельность.

Что делать:

* exploratory testing;
* рисковые зоны;
* regression impact;
* тестовые данные;
* работа с неочевидными бизнес-правилами;
* улучшение качества документации.

Практика:

* брать крупный бизнес-процесс целиком;
* декомпозировать на подсценарии;
* составлять карту проверок;
* собирать полноценный incident package.

---

# 8. Какие реальные задания давать новичку

Очень важно учить не теорией, а заданиями.

## Задание 1

Проверить регистрацию пользователя.

Нужно сдать:

* чек-лист;
* список позитивных/негативных сценариев;
* 3 оформленных бага;
* 1 API-разбор;
* 1 SQL-проверку по созданному пользователю.

## Задание 2

Проверить изменение статуса сущности.

Нужно сдать:

* карту статусов;
* допустимые/недопустимые переходы;
* запросы API;
* данные в БД до и после;
* отчет по одному дефекту с полной картиной.

## Задание 3

Проверить сквозной сценарий “создание → согласование → завершение”.

Нужно сдать:

* workflow-схему;
* тестовые данные;
* трассировку по шагам;
* логический анализ, где могут ломаться правила;
* баг-репорт по найденному сбою.

## Задание 4

Разобрать инцидент.

Дается готовый баг, и новичок должен ответить:

* что произошло;
* где симптомы;
* где подтверждение;
* каких данных не хватает;
* что передать разработчику.

---

# 9. Как учить современным IDE с ИИ

Это важно, но с правильной ролью: **ИИ — не замена мышления, а ускоритель**.

## Какие IDE и инструменты полезны

* VS Code
* JetBrains IDE / DataGrip
* Cursor / Windsurf / Copilot-подобные инструменты
* встроенные AI assistant в IDE
* AI для SQL, regex, документации, генерации тестов

## Для чего их использовать QA

### Хорошие кейсы

* быстро объяснить незнакомый JSON;
* сгенерировать черновик чек-листа;
* составить негативные сценарии;
* помочь написать SQL-запрос;
* расшифровать stack trace;
* объяснить код endpoint’а;
* помочь построить state diagram;
* преобразовать сырые заметки в баг-репорт;
* сравнить два payload;
* подсветить пробелы в покрытии.

### Чего нельзя делать бездумно

* слепо верить AI-анализу;
* отправлять чувствительные прод-данные в внешние модели без политики безопасности;
* копировать придуманные SQL/API-ответы;
* использовать AI вместо понимания бизнес-логики.

## Как учить правильно

Нужно дать новичку правило:

**Сначала сам формулируешь гипотезу, потом просишь ИИ помочь ее проверить или оформить.**

Например:

* не “разберись, что сломалось”;
* а “вот запрос, вот ответ, вот данные в БД — помоги выделить несоответствия и сформулировать баг”.

## Очень полезные AI-задачи для QA

* “Преобразуй эти acceptance criteria в таблицу тестовых сценариев”
* “Составь список негативных кейсов для поля”
* “Сравни expected/actual и выдели расхождения”
* “Помоги написать SQL для проверки статуса сущности”
* “Объясни этот код обработчика простыми словами”
* “Сделай шаблон расследования дефекта по слоям UI/API/Backend/DB”

---

# 10. Минимальный стек знаний по технике

Вот что реально нужно знать новичку, если цель — стать сильным системным QA.

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

* QA basics
* test design
* bug reporting
* HTTP/JSON
* browser DevTools
* API testing
* SQL
* reading logs
* Jira/Confluence
* базовое понимание auth
* workflow/state transitions
* тестовые данные
* скриншоты/видео/артефакты

## Очень желательно

* Git на базовом уровне
* Linux basics
* Docker basics
* message queues basics
* microservices basics
* CI/CD basics
* contract testing idea
* observability basics

## Плюс к росту

* автотесты API/UI на базовом уровне;
* чтение кода;
* Python/JavaScript basics;
* регулярные выражения;
* data analysis mindset.

---

# 11. Как понять, что человек растет правильно

Хороший прогресс у новичка выглядит так:

Сначала он говорит:

> “Не работает кнопка”

Потом:

> “После нажатия на кнопку уходит POST-запрос, сервер возвращает 400”

Потом:

> “Сценарий ломается на бизнес-валидации: фронт отправляет пустой `customerType`, backend ожидает обязательное значение, UI не отображает текст ошибки”

А потом:

> “Проблема воспроизводится только для роли Broker и только при переходе из Draft в Submitted. Запрос корректен частично, но флаг `requiresApproval` не пересчитывается после изменения суммы. В БД сохраняется старое значение, из-за этого workflow идет по неверной ветке.”

Вот это и есть рост в системного QA.

---

# 12. Самый важный навык: делать не просто проверки, а расследование

Нужно научить человека работать по шаблону расследования.

## Шаблон расследования дефекта

**Контекст**

* кто, где, при каких условиях

**Сценарий**

* что делали пошагово

**Ожидание**

* что должно было произойти по логике

**Факт**

* что произошло реально

**UI**

* что увидел пользователь

**API**

* какие запросы и ответы были

**Backend**

* что видно по логам/сервисам

**DB**

* что сохранилось / не сохранилось

**Гипотеза**

* на каком слое проблема вероятнее всего

**Артефакты**

* скрин, видео, payload, response, request ID, SQL

Если новичок научится всегда так мыслить, он станет очень полезным QA.

---

# 13. Что я бы рекомендовал как учебный план в одном абзаце

Сначала дать базу QA и тест-дизайна, затем HTTP/веб и DevTools, потом API-тестирование и чтение контрактов, затем SQL и проверку состояния данных, после этого логи, трассировку и понимание архитектуры, и уже на этой основе тренировать сквозное тестирование бизнес-воркфлоу с обязательной фиксацией полной картины по слоям UI → API → backend → DB. Параллельно учить пользоваться IDE с ИИ как помощником для анализа payload, SQL, требований, логов и кода, но не как заменой собственному пониманию системы.

---

# 14. Практический итог: каким должен быть его рабочий стандарт

Каждый найденный дефект он должен уметь сопровождать таким пакетом:

* краткое описание сценария;
* шаги;
* ожидаемый и фактический результат;
* скрин/видео;
* request/response;
* request ID;
* состояние записи в БД;
* краткая выписка из логов;
* гипотеза о слое проблемы;
* всё это в одном понятном баге.
