Добро пожаловать в тестирование
Эта статья — входная точка для новичков в QA. Дальше — Основы тестирования, маршрут в о разделе. Онбординг в команде — онбординг-пакет.
Кто такой QA
QA (Quality Assurance, обеспечение качества) — специалист, который проверяет, что программа соответствует требованиям и не навредит пользователю, бизнесу и данным.
QA занимается управлением риском:
- что может пойти не так;
- как воспроизвести проблему стабильно;
- как задокументировать дефект так, чтобы разработчик исправил с первого раза;
- как убедиться, что исправление не сломало другое (регресс).
QA ускоряет поставку: дефекты дешевле ловить на dev и stage, чем чинить в production ночными hotfix. Роль — управление риском (что может сломаться, как воспроизвести, как задокументировать, как проверить регресс после фикса).
QA и QC
| Термин | Смысл |
|---|---|
| QC (Quality Control) | Контроль готового продукта — прогон проверок |
| QA (Quality Assurance) | Обеспечение качества процессом — требования, DoD, риски на refinement |
В заголовке должности "QA" часто объединяют ручное тестирование и участие в улучшении процесса.
Роли внутри QA
| Роль | Чем занимается | Типичный стек |
|---|---|---|
| Manual QA | Ручные сценарии, exploratory, UI/UX проверки | Jira, DevTools, Charles |
| Automation QA / SDET | Автотесты API/UI, CI | Python/Java/JS, Selenium, Playwright |
| Performance QA | Нагрузка, стресс | k6, JMeter, Grafana |
| Security QA | Базовые проверки, совместно с AppSec | OWASP ZAP, burp (под руководством) |
Один человек на старте карьеры часто совмещает manual + немного API/SQL. Углубление — по карте раздела.
Подробнее — Основы тестирования, классификация видов.
QA и разработчик
| Разработчик | QA | |
|---|---|---|
| Главный вопрос | Как реализовать требование | Как проверить и опровергнуть ожидания |
| Артефакты | Код, Pull Request | Чек-листы, тест-кейсы, баг-репорты |
| Успех | Фича работает по задумке автора | Дефекты найдены до пользователя |
| Мышление | Синтез решения | Анализ рисков и граничных случаев |
В зрелой команде:
- разработчик пишет unit-тесты и часть integration;
- QA расширяет покрытие: integration, E2E, exploratory, регресс, non-functional (карта уровней);
- оба участвуют в refinement acceptance criteria.
Цель QA — не "поймать" разработчика, а снять риск до релиза. Хороший баг-репорт — подарок, не обвинение.
Карьерный путь в QA
Junior QA (0–1.5 года)
Ожидания:
- ручное тестирование по чек-листам и AC;
- воспроизводимые баг-репорты;
- базовый SQL, HTTP, DevTools;
- участие в регрессе перед релизом.
Рост: техники тест-дизайна, API-тестирование, SQL.
Middle QA (1.5–4 года)
Ожидания:
- самостоятельный test plan на фичу;
- exploratory без детального скрипта;
- автоматизация smoke / regression (частично);
- менторство junior.
Senior QA / SDET
Ожидания:
- стратегия тестирования на релиз или продукт;
- фреймворк автотестов, CI integration;
- оценка рисков на архитектурных review;
- участие в DoD и quality gates.
QA Lead
People management, hiring, процесс, метрики качества, не обязательно hands-off навсегда.
См. подготовка к junior QA, карьера в IT.
Как устроена работа QA в проекте
Типичный поток (Scrum/Kanban команда):
По шагам
- Требования и AC от аналитика — участие QA на refinement.
- Тест-дизайн — кейсы, чек-листы (127, 119).
- Проверка на dev и stage (среды).
- Баг-репорт в Jira/YouTrack.
- Регресс перед релизом — smoke + critical path.
- Участие в release notes — что проверяли (7.25).
Процесс команды — Scrum или Kanban. Вход в проект — онбординг.
Типичный рабочий день QA
Расписание зависит от компании, но каркас дня часто такой:
| Блок времени | Действия |
|---|---|
| Утро | Daily, статус тикетов, уточнение блокеров у dev/аналитика |
| Первая половина | Чтение ТЗ или AC на новые story, обновление чек-листов и кейсов (119, 127) |
| После сборки | Прогон smoke и кейсов на dev/stage, заведение багов |
| После фиксов | Retest по закрытым дефектам, точечный регресс |
| Перед релизом | Smoke + критический путь, черновик отчёта о тестировании |
| Между задачами | Уточнение требований на refinement, пара минут exploratory на рискованную зону |
На старте карьеры много времени уходит на изучение продукта и оформление первых баг-репортов. Без готового ТЗ помогают mind map и вопросы аналитику — сбор требований.
Где QA в sprint
| Событие | Участие QA |
|---|---|
| Refinement | Риски, уточнение AC, testability |
| Planning | Оценка тестовых задач |
| Daily | Статус проверок, блокеры |
| Review | Demo + что ещё проверить |
| Retro | Качество, escaped defects |
Маршрут на первую неделю
| День | Фокус | Действия |
|---|---|---|
| 1 | Доступы, продукт | Онбординг, пройти приложение руками как пользователь |
| 2 | Контекст | Wiki QA, тестовые данные, среды dev/stage |
| 3 | Теория | Основы тестирования — виды, уровни |
| 4 | Документация | Документация тестировщика — шаблон кейса |
| 5 | Практика | Первый баг-репорт (учебный или real minor) |
День 1 подробнее
- Учётка, VPN, трекер, test management (если есть)
- Учётная запись тестового пользователя на stage
- Buddy QA или dev — tour по продукту 60 мин
- Записать 5 вопросов "а что если…" по главному flow
Маршрут на вторую неделю
| День | Фокус | Действия |
|---|---|---|
| 6–7 | Виды тестирования | Классификация — smoke, regression, exploratory |
| 8–9 | Веб или API | Ручное веб-тестирование или API |
| 10 | Тест-дизайн | Техники — equivalence, boundaries |
| 11–12 | Углубление | Чек-лист на story из текущего спринта |
| 13–14 | SQL (желательно) | SQL для тестировщика — SELECT, JOIN |
Дальше — подготовка к junior QA и полный маршрут в о разделе.
Чек-лист конца 2-й недели
- 3+ баг-репорта или 1 качественный + 2 улучшения документации
- 1 чек-лист на фичу (10–20 пунктов)
- Понимаю, куда писать вопросы (канал, buddy)
- DevTools: Network tab, Console — открывал
Навыки с первого дня
Soft skills
- Внимательность и вопрос "а что если…".
- Письмо воспроизводимых шагов — без "не работает".
- Спокойная коммуникация с разработчиком (культура команды).
- Любопытство к домену — банк, e-commerce, логистика.
Hard skills (база)
| Навык | Назначение | Старт |
|---|---|---|
| HTTP | API, статусы, cookies | маршрут веб |
| DevTools | Network, Console, Storage | F12 на любом сайте |
| SQL | Проверка данных в БД | SELECT, WHERE (129) |
| JSON | API bodies | jsonformatter.org |
| Git (read-only) | Какие PR в релизе | clone, log |
| Jira | Баги, статусы | 21 |
SQL для проверки данных — сильное преимущество junior на собеседовании.
Баг-репорт, минимальный шаблон
**Заголовок:** [Модуль] Краткое описание проблемы
**Среда:** stage / prod-like, build 1.2.3
**Браузер:** Chrome 122 / API client
**Шаги:**
1. ...
2. ...
**Ожидание:** ...
**Факт:** ...
**Логи / скрин:** приложить
**Severity:** Blocker / Major / Minor
**Приоритет:** согласовать с lead
Подробнее — документация тестировщика.
QA и автоматизация
Junior не обязан сразу писать Selenium. Но полезно понимать:
| Уровень | Кто | Скорость |
|---|---|---|
| Unit | Dev | Миллисекунды |
| Integration | Dev + QA | Секунды |
| E2E UI | QA automation | Минуты |
| Manual exploratory | QA | Часы, высокая ценность |
Автоматизируют стабильные проверки; exploratory — человек. TDD/BDD — см. связь с Gherkin.
QA и ИИ
Код и тест-кейсы от LLM без review — типичный нейрослоп. QA остаётся обязательным фильтром:
- проверять граничные случаи, которые модель пропустила;
- не доверять "100% coverage" от генератора;
- политика команды — ИИ в процессе.
Типичные ошибки новичка
| Ошибка | Как лучше |
|---|---|
| "Не работает" без шагов | Полный баг-репорт |
| Тест только happy path | Negative, boundaries |
| Боязнь "мешать" dev | Писать в тикет, не в личку с претензией |
| Игнор AC | Тестировать по требованиям, не "как кажется" |
| Только UI, без данных | SQL / API проверка state |
Метрики качества (для понимания)
QA Lead смотрит не "сколько багов нашёл Ivan", а:
| Метрика | Смысл |
|---|---|
| Escaped defects | Баги в prod после релиза |
| Defect leakage | Доля багов, найденных поздно |
| Test coverage (risk-based) | Критичные области покрыты |
| Cycle time bug fix | От report до verified |
Junior достаточно знать: качество баг-репорта и своевременность проверки story важнее количества тикетов.
Портфолио junior QA
Работодателю важнее примеры работы, чем только сертификат. Соберите публичный набор (без NDA-данных):
| Артефакт | Минимум | Где взять |
|---|---|---|
| Чек-лист | 2–3 на разные зоны (логин, форма, каталог) | Любой demo-сайт, лаборатория |
| Тест-кейс | 5–10 с шагами и ожиданием | Учебная story, конвертер файлов |
| Баг-репорт | 2–3 с сильным оформлением | Реальный minor-баг или учебный |
| Автотест (по желанию) | 1 API или UI smoke | Практикум 1011, Playwright |
Оформите README в GitHub: что тестировали, какие техники (127), что нашли. Карьера и собеседования — раздел "Карьера в IT", тестовые задания.
Практика вне работы
- Лаборатория encyclopedia.
- play.spirzen.ru — учебные стенды.
- Pet-проекты: тестировать чужие demo apps, писать чек-листы публично (без NDA данных).
- Open source: воспроизвести issue, дополнить steps.
Онбординг QA в команде
Связка с онбординг-пакетом:
Первый день QA в команде
- Тестовые аккаунты всех ролей (user, admin, …)
- Доступ к stage, test data reset policy
- Где лежат regression checklist и release checklist
Неделя 1
- Pairing с QA lead на regression одной story
- Первый баг в Jira с review от buddy
Месяц 1
- Владение regression области (например, "корзина")
- Участие в release testing
FAQ
Нужно ли QA уметь программировать?
Для manual junior — базовый SQL и HTTP достаточно. Для SDET — да, один язык уверенно.
QA — это девушки?
Стереотип без основания. В профессии люди любого пола; важны навыки.
Manual QA вымирает?
Автоматизация растёт, но exploratory, UX, сложные интеграции и риск-анализ остаются за людьми. Карьера → automation или domain expert.
Как перейти из QA в dev?
Путь распространён: automation → больше кода → internal transfer. Помогает участие в unit-тестах и code review.
С чего начать сегодня вечером?
Прочитать Основы, открыть DevTools на любом сайте, составить 10-пунктовый чек-лист для формы логина.
Куда дальше
| Следующий шаг | Статья |
|---|---|
| Теория | Основы тестирования |
| Виды | Классификация |
| Документы | Документация тестировщика |
| Техники | Тест-дизайн |
| Веб | Ручное веб-тестирование |
| API | API-тестирование |
| SQL | SQL для QA |
| Junior track | Подготовка к junior QA |
| Весь раздел | Тестирование — intro |
Практика — лаборатория, play.spirzen.ru.
Сертификации и обучение (ориентир)
| Направление | Примеры | Когда |
|---|---|---|
| Основы QA | ISTQB Foundation | После 6–12 мес практики |
| Автоматизация | Курсы Playwright/Selenium | Middle track |
| API | Postman learning | Неделя 2–4 |
| SQL | Практика на 129 | Первый месяц |
Сертификат не заменяет практику и портфолио баг-репортов / pet-проектов автотестов.