Интересно, что многие РМы не знакомы с базовыми понятиями управления качеством программного обеспечения, за счет чего возможны ошибки при управлении проектом, расхождение в ожиданиях с подрядчиком или со своей командой, проблемы с финансами (когда в ходе проекта выяснил, что заказал совсем не то) и проч.
Поэтому вот и давайте кратко поговорим о том, в чем же отличие QA, QC и тестирования. Тем, кто работал с более-менее большими и профессиональными командами по обеспечению качества, дальше точно можно не читать.
Итак, наши три уровня работы с качеством программного обеспечения:
- Testing (Тестирование) – самый “нижний”, первый уровень, проверка создаваемого программного продукта на соответствие требованиям к этому продукту. По факту это реактивная работа (выдали – проверил – описал дефекты – исправили), которая может помочь исправить дефекты в уже созданном программном обеспечении, но не более того. Это не значит, что тестирование – это просто (наоборот, профессиональные тестировщики – какие-то сверхлюди, по-моему), но это самая база и минимум, без которого выпускать продукт в принципе нельзя. Основная задача тестирования – выявить и зафиксировать дефекты.
- QC (Quality Control, контроль качества) – второй уровень, включающий в себя тестирование, но не ограничивающийся им. Quality Control обеспечивает не только проверку продукта на соответствие требованиям, но и соответствие заранее согласованному уровню качества продукта и готовность к выпуску продукта в продакшен. Основная задача контроля качества – предоставить объективную картину того, что происходит с качеством продукта на разных этапах разработки.
- QA (Quality Assurance, обеспечение качества) – третий уровень, куда доходят не все, и который включает в себя мероприятия на всех этапах разработки (и, по-хорошему, использования) продукта для обеспечения согласованного уровня качества продукта. Это уже проактивная работа, т.к. основная задача обеспечения качества – это выстроить систему, которая будет превентивно работать на качество продукта, чтобы при тестировании количество дефектов было минимальным. В зависимости от специфики проекта сюда может включаться тестирование документации, ревью кода на соответствие стандартам, внедрение каких-то методик по работе с качеством, коммуникационные активности и проч.
Вообще в PMBOK есть целый раздел про управление качеством, по умолчанию предполагается, что это делает РМ, но на любом более-менее большом проекта выделяется как минимум QC-менеджер (как правило, это тимлид команды тестирования), а в идеале – QA-менеджер, у которого есть понимание, что, зачем и в какие сроки должно быть сделано, и который плотно работает с РМом для обеспечения качества результата проекта.
Картинка в тему:
Как-то так.
Кстати, самая простая проверка, которая поможет сразу понять степень профессионализма подрядчика, которого вы хотите привлечь на проект – это просьба рассказать о том, кто занимается тестированием, какие у этих людей компетенции и проч. Если окажется, что “у нас тестирует аналитик”, “ваш менеджер выполнит тестирование от и до” и прочие варианты без упоминания “у нас есть выделенная группа QA, которая занимается тестированием” – самое время бежать, роняя тапочки. Вообще по тэгу подрядчики в сообществе много историй про качество тестирования, посмотрите.
P.S. Если среди подписчиков сообщества есть специалисты по качеству ПО – буду рада услышать ваше мнение, т.к. пост довольно “по верхам”.
Юлия в чем принципиальная разница между первым и вторым этапом?
2. Говоря тестирование мы имеем в виду тестирование функциональности или в тч прохождения испытаний по б/п разными ролями пользователей?
3. 1 и 2 этап тестирования плавно переходит в ПМИ и это 2 разных процесса?
1. Вроде бы в статье написала про разницу, но попробую еще раз другими словами=))
Тестирование – тупо проверили функционал (может, под разными ролями, может – нет, зависит от продукта) и выдали результат – 10 багов, из них 2 блокирующих. Хорошо это или плохо именно для этого продукта? А кто его знает…
В случае с QC – есть определенный уровень качества, к которому мы стремимся, и показатели становятся качественными. Например, для простого бота 2 минорных ошибки – это много, и выпускать в прод его нельзя, а для огромной ERP отсутствие багов критичного и высокого уровня – уже повод поаплодировать команде и стартовать эксплуатацию. И тут уже можно относительный уровень качества мерять.
2. В данном случае под тестированием я имею ввиду любую проверку, от функционального до нагрузочного тестирования (включая тестирование под разными ролями).
3. Это не этапы тестирования, это уровень зрелости компании в части тестирования. Но обычно наличие ПМИ говорит о том, что компания как минимум на уровне QC (если это, конечно, не для галки для отчетика по ГОСТу сделано). А вообще проверка по ПМИ – это вообще стоящий слегка в сторонке процесс, больше относящийся к политике, чем к реальной проверке качества, к сожалению.
я не специалист по качеству ПО, но, кажется, в пункте третьем случилась опечатка в слове Assurance:
QA (Quality Assirance, обеспечение качества)
Поправила, спасибо=))