## Каким должен стать такой тестировщик Это не “кликер”, а **системный 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;изучил * понять, на каком шаге логика пошла не так;изучил * проверить логи/состояние бэкенда;не изучил ( могу проверить только по 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. Зафиксировать бэкенд частично изучил только через response * был ли вызов обработан; * была ли ошибка в логах; * ключевое сообщение; * стек/код ошибки, если доступен; * какие сервисы участвовали. ## Шаг 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. Минимальный стек знаний по технике изучил кроеме sql Вот что реально нужно знать новичку, если цель — стать сильным системным 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; * состояние записи в БД; * краткая выписка из логов; * гипотеза о слое проблемы; * всё это в одном понятном баге.