912 lines
34 KiB
Markdown
912 lines
34 KiB
Markdown
## Каким должен стать такой тестировщик
|
||
|
||
Это не “кликер”, а **системный 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;
|
||
* состояние записи в БД;
|
||
* краткая выписка из логов;
|
||
* гипотеза о слое проблемы;
|
||
* всё это в одном понятном баге.
|