Обеспечение качества - чья это работа?

Для большинства организаций обеспечение качества и тестирование - это одно и то же. Многие из этих организаций ошибочно принимают обеспечение качества за контроль качества. Я буду обсуждать необходимость и того и другого, а также, чем они отличаются. Я расскажу, что значит каждое выражение и как они вписываются в Agile разработку.

Обеспечение качества часто ошибочно принимают за контроль качества. Контроль качества или КК заключается в том, чтобы убедиться, что продукт работает и соответствует требованиям. Обычные усилия по КК могут включать ручное тестирование, тестирование разработки, системное и интеграционное тестирование, автоматизированное, регрессионное и т.д. Этот процесс считается лучшим способом выявления любых проблем в программном обеспечении до выпуска продукта для использования. Распространенное заблуждение состоит в том, что команда КК выявляет любые проблемы, которые могут существовать в продукте. Это не так. Неразумно ожидать, что один человек или команда сможет отловить каждую проблему в тысячах строк кода.

Настоящее обеспечение качества начинается с самого начала проекта, когда задаются важные вопросы: кто, что, когда, где и почему. Эти вопросы закладывают основу процесса обеспечения качества и определяют, какой продукт будет поставляться. Когда эти вопросы задаются и количественно оцениваются, они устанавливают критерии успеха и дают возможность отслеживать и обеспечивать соответствие проекта запросам/целям клиента. Тогда возникает вопрос, кто должен нести ответственность за качество продукта? Ответ прост: За него отвечает вся команда проекта.

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

Менеджеры проектов осуществляют тестирование, задавая такие вопросы, как:

• Есть ли у нас четко обозначенный объем работ?
• Есть ли у нас на проекте нужные игроки?
• Достаточно ли времени, отведенного на проект?
• Нужны ли нам продукт оунеры и спонсоры?

Бизнес-аналитикам следует задавать такие вопросы, как:

• Есть ли у нас требования, охватывающие весь скоуп?
• Все ли требования ясны и поддаются проверке?
• Есть ли какие-то пункты, на которых клиенты настаивают, прежде чем они примут проект?

Руководители разработчиков должны задавать такие вопросы, как:

• Все ли требования ясны и охватывают ли они согласованный объем?
• Достаточно ли у нас деталей, чтобы разработать все необходимое?
• Все ли стандарты разработки определены для проекта?
• Есть ли у нас соответствующие ревью процессы?
• Создана ли надлежащая инфраструктура?

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

Я завершу это одним заявлением: контроль качества - это не гарантия качества, но это ценная часть гарантии качества. Каждый отвечает за качество, и каждый - тестировщик.

Переведено командой QApedia. Еще больше переведенных статей вы найдете на нашем телеграм-канале.