База для QA
К списку уроков
Блок 1 · Введение в IT и разработку ПО

Урок 1. Зачем нужен тестировщик, если есть разработчик?

Как устроена разработка ПО

Темы урока

Роль QA, виды IT-компаний (продуктовые/аутсорс/аутстафф/стартапы), команда разработки (PM/BA/Dev/QA/DevOps/Designer), взаимодействие ролей, дорожная карта марафона

Видео урока

Пройти тест по уроку

Конспект урока

Главное за урок

Тестировщик нужен, потому что разработчик не может объективно проверить свой код. Автор знает, как «должно работать», и подсознательно обходит проблемные места. QA смотрит на продукт глазами пользователя и системно проверяет то, что разработчик мог упустить.

Цена бага растёт от этапа к этапу. Дефект, найденный на ревью требований, исправляется за минуты. Тот же дефект в продакшне обходится бизнесу в 10–100 раз дороже: поддержка, откаты, репутация, недополученная выручка.

QA — это не «нажать кнопку», а система обеспечения качества. Тестировщик подключается с момента анализа требований и работает до релиза — помогая строить продукт без багов с самого начала, а не вылавливать их в конце.

Виды IT-компаний

Тип Что важно знать QA
Продуктовая Свой собственный продукт, глубокое погружение, долгий горизонт работы.
Аутсорс Твоя компания делает проекты для внешних клиентов. Широкий опыт, частая смена стека.
Аутстафф Ты как сотрудник «арендуешься» к клиенту и сидишь у него в команде.
Стартап Процессов почти нет — строишь сам. Scope широкий: от API до мобильного приложения.

Главное различие, которое путают новички:

  • Аутсорс = моя компания делает проект для клиента.
  • Аутстафф = я как QA сижу в команде клиента, формально оставаясь сотрудником своей компании.

Команда разработки: кто за что отвечает

  • PM (Product Manager) — определяет, что мы строим и в каком порядке. Принимает решения о приоритетах, сроках и компромиссах между качеством, объёмом и сроками.
  • BA (Business Analyst) — переводит размытые хотелки бизнеса в конкретные требования, user stories и критерии приёмки.
  • Designer (UX/UI) — проектирует, как продукт выглядит и как с ним взаимодействует пользователь.
  • Dev (Разработчик) — реализует фичи в коде.
  • QA (Тестировщик) — проверяет, что фичи работают так, как задумано, и защищает пользователя от багов.
  • DevOps — отвечает за инфраструктуру, окружения, CI/CD и автоматизацию релизов.

QA — единственный в команде, кто систематически проходит весь пользовательский путь целиком. PM знает бизнес, Dev знает свою фичу, и только QA видит продукт «как пользователь».

Как QA взаимодействует с каждой ролью

  • С BA — уточняет требования, задаёт вопросы «что если…», находит пробелы в спецификации до начала разработки.
  • С Dev — заводит баг-репорты, обсуждает воспроизведение, согласует Definition of Done.
  • С PM — приоритизирует баги по severity/priority, оценивает риски релиза, даёт сигнал о готовности к выпуску.
  • С DevOps — договаривается об окружениях для тестирования, тестовых данных и доступах к логам.
  • С Designer — сверяет реализацию с макетами, ищет расхождения по UX.

Shift Left: QA подключается с самого начала

Принцип Shift Left = «сдвинуть тестирование влево по таймлайну», то есть вовлекать QA как можно раньше:

  1. На этапе требований — искать противоречия и пробелы.
  2. На этапе дизайна — оценивать тестируемость решений.
  3. На этапе разработки — писать кейсы параллельно с кодом.
  4. На этапе ревью — проверять фичу до того, как её увидит пользователь.

Правило: чем раньше найден дефект, тем дешевле его исправить.

Типичный день QA в Scrum-команде

  • Утро: дейли — кратко рассказываешь, что протестировано, что заблокировано, какие риски.
  • День: берёшь задачи в тестирование, пишешь баг-репорты, общаешься с разработчиками, уточняешь требования у BA/PM.
  • Конец дня: обновляешь статус задач, оцениваешь готовность фич к завтрашнему демо или релизу.

Почему QA — отличная точка входа в IT

  • Не нужны алгоритмы и сложная математика как у разработчика.
  • Нужны: внимательность, аналитическое мышление, умение задавать правильные вопросы.
  • Порог входа ниже, чем у Dev, а потолок роста — такой же высокий.

Карьерный путь: Junior QA → Middle QA → Senior QA → QA Lead.
Альтернативы: автоматизация (AQA / SDET), управление (QA Manager), переход в продукт (PM).

Дорожная карта марафона

  • Блоки 1–2 — IT, команды, клиент-серверная архитектура, HTTP, API.
  • Блоки 3–4 — теория тестирования, тест-дизайн, баг-репорты, чек-листы, тест-кейсы, тест-планы.
  • Блок 5 — инструменты: DevTools, Postman, Charles Proxy, TMS и баг-трекеры.
  • Блок 6 — базы данных и SQL.
  • Блоки 7–8 — soft skills, резюме, стратегия поиска работы, собеседование.

К финалу марафона у тебя будет: резюме, портфолио из домашних работ, опыт с инструментами и готовность к интервью на Junior QA.

Ключевые тезисы для теста

  • Разработчик не может объективно тестировать свой код — он автор и подсознательно обходит проблемные места.
  • Цена бага в продакшне в 10–100 раз выше, чем на ранних этапах разработки.
  • В команде минимум 6 ключевых ролей: PM, BA, Designer, Dev, QA, DevOps.
  • BA пишет требования, Dev — код, QA проверяет продукт целиком, DevOps готовит инфраструктуру.
  • Аутсорс = делаем проект для клиента, аутстафф = QA сидит в команде клиента.
  • Shift Left = QA подключается с этапа требований, а не после разработки.
  • QA — самый низкий порог входа в IT без опыта в коде.

Полезные ссылки