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

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

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

Служба контроля качества должна работать совместно с бизнес-стороной для создания автоматизированных приемочных тестов, которые представляют собой истинную спецификацию и документированные требования к системе. Последовательно, от итерации к итерации, они получают информацию о требованиях со стороны бизнеса и преобразуют их в тесты, которые описывают желаемое поведение системы для разработчиков (см. главу 7, «Приемочное тестирование»). Как правило, бизнес-сторона создает «оптимистичные» тесты, а служба контроля качества – «пессимистичные» тесты с проверкой всевозможных граничных условий, исключений и аномальных случаев.

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