Спор о качестве

На прошедшей конференции eTalksQA 2010 завязалась дискуссия c Константином Быченковым, какова же роль QA (quality assurance) команды в разработке программного обеспечения. Константин высказал точку зрения, что задачи команды QA заключаются в непосредственной проверке соответствия программного продукта специфицированным и документированным требованиям, иными словами, в различных видах тестирования системы как «черного» или «серого ящика». По мнению Константина, это и является задачей-максимум QA команды: профессионализм и квалификация QA специалиста сводятся именно к эффективному проектированию тестов на основании спецификации требований и затем как можно более оптимальном выполнении тестового набора.

Я отчасти согласен с таким подходом, так как узкие рамки и формализация любого вида деятельности – суть база для её оптимизации и роста квалификации соответствующего специалиста. Также подобная точка зрения на 100% процентов соответствует пониманию качества, как мере соответствия продукта предъявляемым требованиям.

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

Вторым условием является соответствие архитектуры программной системы требованиям, бизнес целям, ее тестируемость и однозначная оптимальная реализуемость – то есть качество архитектуры. Как же гарантировать качество программной архитектуры и чьей задачей это является?

Несомненно, обеспечение упомянутых условий можно считать естественным результатом «встраивания качества» в более ранние стадии процесса разработки: анализа и систематизации требований, архитектурирования, непосредственно кодирования. То есть качество требований и архитектуры может и должно быть следствием правильно построенного процесса, квалификации аналитиков и архитекторов. Но требуется ли при таком подходе проверка соответствия процессу, и требуется ли контроль качества спецификации требований и программной архитектуры? Должен ли и может ли быть этот контроль формальным?

Должна ли участвовать команда QA/QC в процедурах контроля этих артефактов? – это вопрос спорный? Но может ли участвовать команда QA/QC в этих процессах, и будет ли такое участие эффективным – с моей точки зрения, да, особенно в небольших проектах.
Квалифицированные участники команды QA могут в результате анализа спецификации требований и архитектуры, как и другие участники команды, на основе собственного опыта в тестировании других продуктов могут помочь

  • идентифицировать технологические риски проекта;
  • указать на неоднозначность тех или иных требований;
  • указать на возможные проблемы интеграции или производительности предлагаемой архитектуры;
  • указать на недостатки предлагаемой системы по сравнению с конкурирующими аналогами и др.

Какова цена этой информации, если она получена на ранних этапах работы над проектом? Насколько дешевле будет внести исправления на этапе анализа требований или архитектурирования, чем если та же информация от тех же участников команды QA поступит на этапе тестирования пусть даже промежуточной версии программного продукта? Кто бы из менеджеров хотел иметь возможность управлять ожиданиями заказчика с самого начала проекта с учетом этой информации?

В небольших проектах, для которых характерны недостаточно формальная спецификация требований и лишь высокоуровневая архитектура, экспертное мнение каждого из участников команды высказанное на ранних этапах является критическим слагаемым успеха проекта и разрабатываемого продукта. Не менее критическим является «инициативный подход» к проекту и продукту всех участников команды на всех этапах. Тестирование в таких проектах не может сводиться к проверке командой QA соответствия продукта документированной спецификации, но должно включать критический анализ соответствия проекта и продукта бизнес-целям, способности продукта удовлетворять потребности пользователя, возможных рисков. Для небольших проектов, именно в силу их размера, подобный подход становится возможен! Более того, по моему мнению, именно совокупность ранней вовлеченности всех участников проекта и неформального отношения всех участников являются залогом качества разрабатываемого продукта.

Tags: