Noob_test/QA.md

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

Это не “кликер”, а системный 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;
• состояние записи в БД;
• краткая выписка из логов;
• гипотеза о слое проблемы;
• всё это в одном понятном баге.