Добро пожаловать в тестирование
Эта статья — входная точка для новичков в QA. Дальше — Основы тестирования, маршрут в о разделе. Онбординг в команде — онбординг-пакет.
Кто такой QA
QA (Quality Assurance, обеспечение качества) — специалист, который проверяет, что программа соответствует требованиям и не навредит пользователю, бизнесу и данным.
QA занимается управлением риском:
- что может пойти не так;
- как воспроизвести проблему стабильно;
- как задокументировать дефект так, чтобы разработчик исправил с первого раза;
- как убедиться, что исправление не сломало другое (регресс).
Это не "кликать всё подряд" и не "мешать релизу ради формальности". Хороший QA ускоряет поставку: дефекты дешевле ловить на dev и stage, чем в production с angry users и ночными hotfix.
QA и QC — в чём разница
| Термин | Фокус |
|---|---|
| QC (Quality Control) | Контроль: проверка готового продукта |
| QA (Quality Assurance) | Обеспечение: процесс, чтобы качество было встроено |
На практике в IT заголовок "QA" часто включает и ручное тестирование, и участие в улучшении процесса (DoD, риски на refinement).
Роли внутри 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 в 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 важнее количества тикетов.
Практика вне работы
- Лаборатория encyclopedia.
- play.spirzen.ru — учебные стенды.
- Pet-проекты: тестировать чужие demo apps, писать чек-листы публично (без NDA данных).
- Open source: воспроизвести issue, дополнить steps.
Онбординг QA в команде
Связка с онбординг-пакетом:
День 1 (QA-specific)
- Тестовые аккаунты всех ролей (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-проектов автотестов.