Управление проектами.РУ

Управление проектами.РУ
Сообщество тех, кто умеет или хочет научиться
хорошо управлять проектами
19 апреля 2019 Записки на салфетках
4

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

Юлия Бажанова
Редактор проекта, РМР, ICP-PPM

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

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

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

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

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

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

Как-то так.

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

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

комментарии

Добавить комментарий

Такой e-mail уже зарегистрирован. Воспользуйтесь формой входа или введите другой.

Вы ввели некорректные логин или пароль

Sorry that something went wrong, repeat again!

4комментария

сначала новые
по рейтингу сначала новые по хронологии
1

Юлия в чем принципиальная разница между первым и вторым этапом?
2. Говоря тестирование мы имеем в виду тестирование функциональности или в тч прохождения испытаний по б/п разными ролями пользователей?
3. 1 и 2 этап тестирования плавно переходит в ПМИ и это 2 разных процесса?

Автор2
Юлия Бажанова

1. Вроде бы в статье написала про разницу, но попробую еще раз другими словами=))
Тестирование – тупо проверили функционал (может, под разными ролями, может – нет, зависит от продукта) и выдали результат – 10 багов, из них 2 блокирующих. Хорошо это или плохо именно для этого продукта? А кто его знает…
В случае с QC – есть определенный уровень качества, к которому мы стремимся, и показатели становятся качественными. Например, для простого бота 2 минорных ошибки – это много, и выпускать в прод его нельзя, а для огромной ERP отсутствие багов критичного и высокого уровня – уже повод поаплодировать команде и стартовать эксплуатацию. И тут уже можно относительный уровень качества мерять.
2. В данном случае под тестированием я имею ввиду любую проверку, от функционального до нагрузочного тестирования (включая тестирование под разными ролями).
3. Это не этапы тестирования, это уровень зрелости компании в части тестирования. Но обычно наличие ПМИ говорит о том, что компания как минимум на уровне QC (если это, конечно, не для галки для отчетика по ГОСТу сделано). А вообще проверка по ПМИ – это вообще стоящий слегка в сторонке процесс, больше относящийся к политике, чем к реальной проверке качества, к сожалению.

3

я не специалист по качеству ПО, но, кажется, в пункте третьем случилась опечатка в слове Assurance:
QA (Quality Assirance, обеспечение качества)

Автор4
Юлия Бажанова

Поправила, спасибо=))

Сообщить об опечатке

Текст, который будет отправлен нашим редакторам: