Великая путаница
В индустрии ПО термины «QA», «QC» и «тестирование» используются взаимозаменяемо настолько часто, что большинство людей перестали замечать разницу. В вакансиях пишут «QA Engineer», имея в виду «тестировщик». Отделы называются «QA», хотя занимаются только «QC». А «тестирование» используется как обобщающий термин для всего, что связано с качеством.
Эта путаница имеет значение. Понимание этих трёх концепций как отдельных, но взаимосвязанных дисциплин меняет то, как вы думаете о качестве — и в конечном счёте, как вы создаёте лучшее ПО.
Quality Assurance (QA): процесс
QA ориентировано на процессы. Оно фокусируется на предотвращении дефектов путём улучшения процессов, используемых при создании ПО. QA не проверяет продукт напрямую — оно проверяет и улучшает процессы, которые производят продукт.
Думайте о QA как об инспекторе фабрики, который не проверяет отдельные изделия, сходящие с конвейера, а аудитирует сам конвейер. Откалиброваны ли станки? Обучены ли работники? Поставляют ли материалы надёжные поставщики? Если процесс правильный — продукты будут правильными.
Активности QA
- Определение стандартов разработки и руководств по кодированию
- Установление процессов ревью (code review, ревью дизайна)
- Внедрение CI/CD-пайплайнов
- Создание и поддержка стратегий тестирования
- Проведение аудитов процессов
- Обучение членов команды лучшим практикам
- Выбор и внедрение инструментов
- Определение метрик и KPI качества
- Установление рабочих процессов управления дефектами
- Проведение анализа корневых причин для предотвращения рецидивов
QA проактивно
Фундаментальная характеристика QA — оно проактивно. Действует до того, как дефекты будут созданы. Когда QA вводит правило «все запросы к БД должны использовать параметризованные выражения», это предотвращает написание SQL-инъекций.
Quality Control (QC): продукт
QC ориентировано на продукт. Оно фокусируется на выявлении дефектов в реальном продукте. QC проверяет поставляемый результат — код, приложение, систему — чтобы определить, соответствует ли он стандартам качества.
Думайте о QC как об инспекторе в конце конвейера, который проверяет каждое изделие на дефекты. Он осматривает готовую продукцию, сравнивает со стандартами качества и отмечает всё, что не проходит проверку.
Активности QC
- Тестирование (все виды: функциональное, нагрузочное, security и т.д.)
- Инспекции и walkthroughs кода
- Ревью документации на точность
- Валидация сборок и развёртываний
- Мониторинг продакшена на предмет дефектов
- Проверка соответствия стандартам
- Ревью результатов тестирования и метрик
QC реактивно
Фундаментальная характеристика QC — оно реактивно. Действует после того, как продукт (или его часть) создан. QC находит уже существующие дефекты, а не предотвращает их внесение.
Тестирование: активность
Тестирование — это активность в рамках QC. Это процесс выполнения ПО для нахождения дефектов путём сравнения фактического поведения с ожидаемым. Тестирование — наиболее видимая и практическая часть экосистемы качества.
Активности тестирования
- Написание и выполнение тест-кейсов
- Исследовательское тестирование
- Регрессионное тестирование
- Нагрузочное тестирование
- Тестирование безопасности
- Юзабилити-тестирование
- Создание баг-репортов
Тестирование — подмножество QC
Каждая активность тестирования — это активность QC, но не каждая активность QC — тестирование. Walkthrough кода — это QC (проверка продукта), но не тестирование (ПО не выполняется). Ревью документации — это QC, но не тестирование.
Как они связаны
Связь иерархическая, но циклическая:
- QA определяет процессы и стандарты
- QC оценивает продукт по этим стандартам
- Тестирование — наиболее распространённая техника QC
- Результаты тестирования и QC возвращаются в QA для улучшения процессов
Комплексное сравнение
| Аспект | Quality Assurance | Quality Control | Тестирование |
|---|---|---|---|
| Фокус | Процесс | Продукт | Выполнение |
| Характер | Превентивный | Детективный | Детективный |
| Масштаб | Вся организация | Конкретные поставки | Конкретное ПО |
| Время | До и во время разработки | Во время и после разработки | Во время и после сборки |
| Цель | Предотвратить дефекты | Найти дефекты | Найти дефекты через выполнение |
| Подход | Проактивный | Реактивный | Реактивный |
| Ответственность | Все (под руководством QA) | Команда QA/QC | Тестировщики |
| Пример | «Все PR требуют 2 ревьюеров» | Инспекция кода находит баг | Выполнение теста находит баг |
| Результат | Стандарты, процессы, руководства | Отчёты о дефектах, метрики | Результаты тестов, баг-репорты |
Один день в каждой роли
День в QA
Мария — QA Manager. Сегодня она:
- Анализирует показатель утечки дефектов за прошлый квартал и определяет, что 60% багов в продакшене связаны с интеграцией API
- Предлагает новый процесс: все изменения API должны включать контрактные тесты перед мёржем
- Обновляет документ стратегии тестирования, добавляя контрактное тестирование API
- Проводит ретроспективу по последнему инциденту в продакшене для выявления процессных пробелов
- Обучает младших инженеров новому подходу к контрактному тестированию
Мария сегодня ничего не тестировала. Она улучшила процессы, которые предотвратят будущие дефекты.
День в QC
Дмитрий — аналитик QC. Сегодня он:
- Ревьюит код новой платёжной функции, проверяя на соответствие стандартам
- Инспектирует документацию API, чтобы убедиться, что она соответствует реальной реализации
- Валидирует, что артефакты сборки правильно подписаны и версионированы
- Ревьюит отчёт о покрытии тестами для выявления недотестированных областей
- Проводит security-ревью потока аутентификации
Дмитрий проверил несколько продуктов и артефактов, но не выполнял ни одного теста.
День в тестировании
Наталья — Test Engineer. Сегодня она:
- Выполняет 15 регрессионных тест-кейсов для потока оформления заказа
- Проводит исследовательское тестирование новой функции поиска
- Пишет три новых тест-кейса для потока сброса пароля
- Запускает автоматизированный набор API-тестов и расследует два провала
- Создаёт баг-репорты на найденные дефекты
Наталья весь день выполняла ПО и сравнивала фактическое поведение с ожидаемым. Это тестирование.
В реальных организациях
На практике, особенно в небольших компаниях, границы существенно размываются:
Маленькие стартапы (5-20 человек): Один человек часто выполняет все три роли. Определяет процессы тестирования (QA), ревьюит pull request-ы (QC), пишет и выполняет тесты (тестирование). Его должность обычно «QA Engineer».
Средние компании (50-200 человек): QA-команда занимается QC и тестированием. QA Manager или Lead отвечает за QA на уровне процессов. Разработчики участвуют в QA через code review и unit-тестирование.
Крупные корпорации (500+ человек): Выделенные QA-отделы определяют стандарты на уровне организации. Команды QC аудитируют проекты. Команды тестирования выполняют тесты. Специалисты по улучшению процессов фокусируются исключительно на методологии QA.
Упражнение: классифицируйте активности
Классифицируйте каждую активность как QA, QC или тестирование:
- Запуск нагрузочного теста с 10,000 виртуальных пользователей
- Введение правила, что все коммиты должны пройти линтинг перед мёржем
- Ревью документа требований на предмет двусмысленностей
- Выполнение тест-кейса, проверяющего цвет кнопки логина
- Установление процесса триажа багов с определениями серьёзности
- Инспекция развёрнутого билда для проверки правильного номера версии
- Настройка CI-пайплайна, запускающего unit-тесты на каждый коммит
- Проведение исследовательского тестирования новой мобильной функции
- Определение Definition of Done для user stories
- Ручное сравнение ответа API со спецификацией Swagger
Подсказка
Спросите себя: это улучшает процесс (QA)? Проверяет артефакт продукта (QC)? Или выполняет ПО для поиска дефектов (тестирование)?Решение
- Тестирование — Выполнение ПО под нагрузкой для нахождения дефектов производительности
- QA — Установление процессного правила для предотвращения дефектов
- QC — Проверка артефакта продукта (документа требований) на предмет дефектов
- Тестирование — Выполнение ПО и сравнение фактического поведения с ожидаемым
- QA — Определение процесса управления дефектами
- QC — Инспекция артефакта продукта (развёрнутого билда) без выполнения тестов
- QA — Настройка инфраструктуры, обеспечивающей автоматический запуск процессов качества
- Тестирование — Выполнение ПО для обнаружения дефектов через исследование
- QA — Определение процессного стандарта, направляющего качество разработки
- QC — Ревью артефакта продукта (ответа API) по спецификации, хотя может считаться тестированием, если API был активно вызван
Профессиональные советы
Совет 1: Ваша должность может звучать как «QA», но ваша работа может быть «тестированием». Это нормально. В большинстве организаций «QA Engineer» означает человека, который тестирует ПО. Но понимание полного спектра QA-QC-тестирование помогает расти за пределы выполнения тестов к улучшению процессов и стратегическому лидерству в качестве.
Совет 2: Инвестируйте в QA, чтобы снизить нагрузку на QC. Каждый час, потраченный на QA (предотвращение дефектов), экономит несколько часов QC и тестирования (поиск и исправление дефектов). Если ваша команда постоянно находит одну и ту же категорию багов — прекратите тестировать усерднее и начните улучшать процесс, который допускает эти баги.
Совет 3: Тестирование необходимо, но недостаточно. Нельзя «втестировать» качество в продукт. Если процесс разработки сломан, никакое количество тестирования не произведёт качественный продукт. Именно для этого существует QA — чтобы устранять корневую причину, а не только симптомы.
Ключевые выводы
- QA ориентировано на процессы и превентивно — улучшает то, как создаётся ПО
- QC ориентировано на продукт и детективно — оценивает то, что было создано
- Тестирование — активность на основе выполнения в рамках QC — запускает ПО для нахождения дефектов
- Тестирование — подмножество QC, которое работает под зонтиком QA
- На практике один человек часто выполняет все три роли, особенно в небольших командах
- Понимание этих различий помогает расти от исполнителя тестов к лидеру качества