Роберт Мартин - Идеальный программист. Как стать профессионалом разработки ПО

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

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

В 1989 году я работал над первой версией Rational Rose. Каждый месяц или около того начальник службы контроля качества объявлял день «охоты за ошибками». Все участники проекта, от программистов до начальников, от секретарей до администраторов баз данных, садились за Rose и пытались вызвать сбой в программе. За разные типы ошибок присуждались призы. Ошибка, приводящая к аварийному завершению приложения, могла быть награждена обедом для двоих. Тот, кто обнаруживал больше всего ошибок, мог выиграть поездку на выходные в Монтеррей.

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

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

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

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

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

Профессиональные разработчики для создания модульных тестов обычно применяют методологию разработки через тестирование (TDD, Test Driven Development). Группы профессиональных разработчиков используют приемочные тесты для составления спецификации своей системы и механизм непрерывной интеграции (см. главу 7, с. 122) для предотвращения регрессии. Однако эти тесты составляют лишь часть картины. Какими бы полезными ни были модульные и приемочные тесты, нам также понадобятся тесты более высокого уровня, которые будут следить за тем, чтобы контроль качества не обнаруживал никаких дефектов. На рис. 8.1 изображена пирамида автоматизации тестирования [39]– графическое представление всевозможных тестов, необходимых при профессиональной организации разработки.