QA, QC и тестирование: в чём разница

Три термина, которые в вакансиях свалены в кучу, а на собеседовании их просят разложить по полочкам — и по ответу сразу видно уровень кандидата.

QA (Quality Assurance, обеспечение качества) — работа с процессом, чтобы дефекты не возникали. QC (Quality Control, контроль качества) — работа с продуктом, чтобы дефекты находились до пользователя. Тестирование — конкретная деятельность внутри QC: спланировать, выполнить проверки, сравнить с ожидаемым, доложить.

Забудьте на минуту про IT. Представьте пекарню.

QA — это рецептура, обучение пекарей, поверенные весы, регламент «тесто расстаивается 40 минут», журнал температуры печи, правило «муку с открытой пачкой не используем». Всё это делается ДО того, как появится первый батон, и работает на то, чтобы брак вообще не случился.
QC — это приёмка: батоны, вышедшие из печи, взвесили, разрезали контрольный, посмотрели на мякиш, отбраковали подгоревшие. Продукт уже существует, мы его проверяем.
Тестирование — это само действие: взять батон, разрезать, посмотреть, записать «мякиш плотный, не пропёкся». Одна из процедур внутри QC.

Иерархия получается вложенная: тестирование ⊂ контроль качества ⊂ обеспечение качества. Отсюда и главная фраза, которую от вас ждут: «всё тестирование — это QC, но не всякий QC — тестирование; и весь QC — часть QA, но QA этим не исчерпывается».

Таблица, которую стоит запомнить

Критерий	QA — обеспечение качества	QC — контроль качества	Тестирование
Цель	Предотвратить появление дефектов	Обнаружить дефекты в готовом продукте	Получить информацию о конкретной сборке
Объект	Процесс: как мы работаем	Продукт: что мы сделали	Конкретная функция, сборка, сценарий
Когда	Постоянно, ещё до первой строки кода	После того, как что-то создано	Внутри цикла проверки продукта
Вопрос	«Почему у нас вообще появляются такие баги?»	«Есть ли баги в этой сборке?»	«Что произойдёт, если ввести отрицательное число?»
Кто делает	Вся команда: тимлид, аналитик, разработчик, тестировщик	Чаще тестировщики, но также ревьюеры и аналитики	Тестировщик, автотесты, иногда разработчик
Примеры активностей	Definition of Done, ревью требований, код-ревью, статический анализ в CI, ретроспективы, шаблоны багрепортов, обучение	Тестирование, инспекции кода, приёмка релиза, аудит данных	Написание тест-кейсов, дымовое и регрессионное тестирование, исследовательская сессия
Метафора	Рецепт и санитарные нормы кухни	Отбраковка готовых батонов	Разрезать батон и посмотреть на мякиш

Два родственных термина: верификация и валидация

Их спрашивают следом, потому что это второй уровень той же путаницы.

Верификация (verification) — «правильно ли мы делаем продукт?» Соответствует ли то, что получилось, спецификации, макетам, стандартам. Проверяем продукт против документа.
Валидация (validation) — «тот ли продукт мы делаем?» Решает ли он реальную задачу пользователя. Проверяем продукт против потребности.

Живой пример. В требованиях написано: «после оплаты показать экран с номером заказа». Разработчик сделал ровно это, тестировщик сверил с макетом — верификация пройдена, всё по спеке. А пользователи в отзывах пишут: «оплатил и не понял, придёт ли чек, куда звонить». Валидация провалена: продукт формально правильный, а задачу человека не закрывает. Классика: «сделали точно по ТЗ, получилось не то».

Хороший тестировщик умеет и то и другое: спорить с реализацией по букве требования и спорить с самим требованием по смыслу.

QA-петля: как один баг меняет процесс

Разница между «тестировщиком» и «инженером по качеству» видна не в объёме кликов, а в том, что человек делает после того, как дефект найден. Смотрите на цикл.

1. QC нашёл: при регистрации можно ввести email вида "a@@b" — принимается.
2. Чиним конкретный баг → это ещё не QA, это просто ремонт.
3. Спрашиваем «почему он появился?» → в требованиях нет ни слова про формат email.
4. Смотрим шире: а в прошлом спринте была та же история с телефоном и с ИНН.
5. Причина процесса: в шаблоне постановки нет раздела «валидация полей».
6. QA-мера (меняем ПРОЦЕСС, а не продукт):
     - в шаблон user story добавлен обязательный блок «правила валидации»;
     - в Definition of Ready: задача не берётся в спринт без этого блока;
     - в CI добавлен линтер, который валит сборку без валидации на форме;
     - в чек-лист код-ревью: «проверены ли негативные значения полей».
7. Результат: класс дефектов «нет валидации» больше не рождается.

Пункты 1–2 — контроль качества. Пункты 3–7 — обеспечение качества. Именно за пункты 3–7 платят senior-у, и именно их не умеет делать джун, который «просто прогоняет тест-кейсы».

Стоимость качества: почему бизнесу это вообще выгодно

В управлении качеством расходы принято делить на четыре корзины. Полезная модель, чтобы аргументировать своё существование перед менеджером.

Категория	Что это	Примеры	Относится к
Предупреждение	Тратим, чтобы дефект не появился	Ревью требований, обучение, статический анализ, шаблоны, автотесты в CI	QA
Оценка	Тратим, чтобы узнать, есть ли дефекты	Тестирование, инспекции, приёмка, тестовые стенды	QC
Внутренние потери	Дефект нашли до пользователя	Переделка, повторный регресс, сдвиг релиза	Последствия
Внешние потери	Дефект нашёл пользователь	Хотфиксы, поддержка, компенсации, отток, штрафы, репутация	Последствия

Смысл вложений в первые две корзины ровно один: они на порядок дешевле последней. Когда менеджер спрашивает «зачем нам ещё один тестировщик», отвечают не «чтобы искать баги», а «чтобы перенести расходы из графы внешних потерь в графу предупреждения».

Почему путаница мешает на собеседовании

Вопрос «в чём разница между QA, QC и тестированием» — дежурный. Он проверяет не память, а ширину мышления: понимаете ли вы, что качество делается не только кликами.

Ответ на 2 балла из 10:
  «Ну, QA — это когда мы обеспечиваем качество, а тестирование — когда мы тестируем.
   По сути это одно и то же, у нас в компании так и называли — QA.»

Ответ, после которого зовут на второй этап:
  «Тестирование — это действие: прогнать проверки и получить факты о сборке.
   QC — шире: любая проверка уже созданного продукта, включая инспекции и приёмку.
   QA — это работа с процессом, чтобы дефекты не появлялись:
   ревью требований, Definition of Done, статанализ в CI, ретро.
   Тестирование входит в QC, QC входит в QA.
   На прошлом проекте я не только заводил баги про валидацию,
   но и добавил блок «правила валидации» в шаблон постановки —
   этот класс багов почти исчез. Вот это была QA-часть моей работы.»

Второй ответ работает потому, что в нём есть определение, иерархия и личный пример влияния на процесс.

Отдельно про реальность рынка, чтобы вас не смущал разрыв. На большинстве вакансий в СНГ слова «QA-инженер», «тестировщик» и «QA» используются как синонимы: ищут человека, который будет тестировать. Это нормально и это не повод считать, что различия — выдумка методологов. Просто держите в голове: должность может называться QA, а работа при этом на 90% состоять из QC. Разница в терминах — ваш инструмент, чтобы честно видеть, где вы сейчас, и куда расти: от «мне принесли сборку, я нашёл 12 багов» к «я поменял процесс так, что эти 12 багов не родились».

Как это работает

На живом проекте три уровня переплетены и выглядят так:

Аналитик пишет историю по шаблону, где обязательны критерии приёмки — это QA.
Тестировщик читает историю до начала разработки и находит противоречие: «а если купон и скидка одновременно?» — формально это тоже QC (проверяется артефакт «требование»), и одновременно самая дешёвая находка в спринте.
Разработчик пишет юнит-тесты, CI не пускает ветку с падающим статанализом — это QA-барьер, встроенный в инструменты.
Тестировщик прогоняет дымовые и регрессионные проверки на сборке — это QC, и внутри него собственно тестирование.
На ретроспективе команда видит, что треть багов — про мобильную вёрстку, и вводит правило «каждая задача проверяется на телефоне до передачи в тест» — снова QA.

Заметьте: границу «QA или QC» проводит не должность человека, а объект воздействия. Меняем продукт — контроль. Меняем то, как рождается продукт, — обеспечение.

Частые ошибки

Ставить знак равенства между QA и тестированием. На собеседовании это мгновенно опускает вас в грейде: спрашивающий понимает, что человек видит только кончик процесса.
Считать, что за качество отвечает «отдел QA». Отдельный отдел контроля качества, отгороженный от разработки, — верный способ получить культуру «перебросим через забор, они найдут». Качество делает вся команда; тестировщик — тот, кто добывает про него правду.
Останавливаться на «баг заведён». Заводить один и тот же класс дефектов каждый спринт и не спрашивать «почему он появляется?» — это работа руками там, где нужна голова.
Путать верификацию с валидацией. «Сделано по ТЗ» не означает «нужно пользователю». Тестировщик, который никогда не оспаривает требование, полезен вполовину.
Прикрываться терминами вместо дела. Обратная крайность: человек красиво рассуждает про QA-процессы, но не может внятно проверить форму оплаты. Иерархия терминов — надстройка над ремеслом, а не замена ему.

Итоги

Тестирование — действие; QC — проверка готового продукта; QA — работа с процессом, чтобы дефекты не рождались. Вложенность: тестирование ⊂ QC ⊂ QA.
Верификация — «делаем ли правильно» (продукт против документа), валидация — «то ли делаем» (продукт против потребности).
Признак зрелого специалиста — после найденного дефекта спросить «почему он появился?» и изменить процесс, а не только продукт.
Экономический аргумент профессии: вложения в предупреждение и оценку на порядок дешевле внешних потерь.
На рынке названия должностей размыты — держите различие в голове как карту роста, а не как повод спорить с рекрутером.