QA, QC и Testing – в чем разница?

Интересно, что многие РМы не знакомы с базовыми понятиями управления качеством программного обеспечения, за счет чего возможны ошибки при управлении проектом, расхождение в ожиданиях с подрядчиком или со своей командой, проблемы с финансами (когда в ходе проекта выяснил, что заказал совсем не то) и проч.

Поэтому вот и давайте кратко поговорим о том, в чем же отличие QA, QC и тестирования. Тем, кто работал с более-менее большими и профессиональными командами по обеспечению качества, дальше точно можно не читать.

Итак, наши три уровня работы с качеством программного обеспечения:

1. Testing (Тестирование) – самый “нижний”, первый уровень, проверка создаваемого программного продукта на соответствие требованиям к этому продукту. По факту это реактивная работа (выдали – проверил – описал дефекты – исправили), которая может помочь исправить дефекты в уже созданном программном обеспечении, но не более того. Это не значит, что тестирование – это просто (наоборот, профессиональные тестировщики – какие-то сверхлюди, по-моему), но это самая база и минимум, без которого выпускать продукт в принципе нельзя. Основная задача тестирования – выявить и зафиксировать дефекты.
2. QC (Quality Control, контроль качества) – второй уровень, включающий в себя тестирование, но не ограничивающийся им. Quality Control обеспечивает не только проверку продукта на соответствие требованиям, но и соответствие заранее согласованному уровню качества продукта и готовность к выпуску продукта в продакшен. Основная задача контроля качества – предоставить объективную картину того, что происходит с качеством продукта на разных этапах разработки.
3. QA (Quality Assurance, обеспечение качества) – третий уровень, куда доходят не все,  и который включает в себя мероприятия на всех этапах разработки (и, по-хорошему, использования) продукта для обеспечения согласованного уровня качества продукта. Это уже проактивная работа, т.к. основная задача  обеспечения качества – это выстроить систему, которая будет превентивно работать на качество продукта, чтобы при тестировании количество дефектов было минимальным. В зависимости от специфики проекта сюда может включаться тестирование документации, ревью кода на соответствие стандартам, внедрение каких-то методик по работе с качеством, коммуникационные активности и проч.

Вообще в PMBOK есть целый раздел про управление качеством, по умолчанию предполагается, что это делает РМ, но на любом более-менее большом проекта выделяется как минимум QC-менеджер (как правило, это тимлид команды тестирования), а в идеале –  QA-менеджер, у которого есть понимание, что, зачем и в какие сроки должно быть сделано, и который плотно работает с РМом для обеспечения качества результата проекта.

Картинка в тему:

Как-то так.

Кстати, самая простая проверка, которая поможет сразу понять степень профессионализма подрядчика, которого вы хотите привлечь на проект – это просьба рассказать о том, кто занимается тестированием, какие у этих людей компетенции и проч. Если окажется, что “у нас тестирует аналитик”, “ваш менеджер выполнит тестирование от и до” и прочие варианты без упоминания “у нас есть выделенная группа QA, которая занимается тестированием” – самое время бежать, роняя тапочки. Вообще по тэгу подрядчики в сообществе много историй про качество тестирования, посмотрите.

P.S. Если среди подписчиков сообщества есть специалисты по качеству ПО – буду рада услышать ваше мнение, т.к. пост довольно “по верхам”.