Профессиональные разработчики тестируют свой код. Однако тестирование не сводится к написанию нескольких модульных или приемочных тестов. Написание этих тестов – дело полезное, но отнюдь не достаточное. Любой группе профессиональных разработчиков нужна хорошая стратегия тестирования.
В 1989 году я работал над первой версией Rational Rose. Каждый месяц или около того начальник службы контроля качества объявлял день «охоты за ошибками». Все участники проекта, от программистов до начальников, от секретарей до администраторов баз данных, садились за Rose и пытались вызвать сбой в программе. За разные типы ошибок присуждались призы. Ошибка, приводящая к аварийному завершению приложения, могла быть награждена обедом для двоих. Тот, кто обнаруживал больше всего ошибок, мог выиграть поездку на выходные в Монтеррей.
Контроль качества не должен находить дефекты
Я уже говорил это прежде и скажу снова. Несмотря на то что в вашей компании может существовать отдельная группа контроля качества, занимающаяся тестированием программных продуктов, группа разработки должна стремиться к тому, чтобы контроль качества не выявлял никаких дефектов.
Конечно, вряд ли эта цель будет достигаться постоянно. В конце концов, когда группа умных людей решительно и непреклонно стремится выявить все дефекты и недостатки продукта, она наверняка чего-нибудь найдет. И все же каждый раз, когда служба контроля качества что-нибудь обнаруживает, это должно стать тревожным сигналом для разработчиков. Они должны спросить себя, как это произошло, и принять меры для предотвращения подобных инцидентов в будущем.
Служба контроля качества – часть команды
Из предыдущего раздела может сложиться впечатление, что служба контроля качества и группа разработки противодействуют друг другу, что их отношения имеют антагонистический характер. Этого быть не должно. Служба контроля качества и группа разработки совместно работают для повышения качества системы, а оптимальная роль для специалистов по контролю качества должна заключаться в создании спецификаций и описании характеристик системы.
Создание спецификаций
Служба контроля качества должна работать совместно с бизнес-стороной для создания автоматизированных приемочных тестов, которые представляют собой истинную спецификацию и документированные требования к системе. Последовательно, от итерации к итерации, они получают информацию о требованиях со стороны бизнеса и преобразуют их в тесты, которые описывают желаемое поведение системы для разработчиков (см. главу 7, «Приемочное тестирование»). Как правило, бизнес-сторона создает «оптимистичные» тесты, а служба контроля качества – «пессимистичные» тесты с проверкой всевозможных граничных условий, исключений и аномальных случаев.
Описание характеристик системы
Еще одна роль службы контроля качества – применение дисциплины исследовательского тестирования для описания характеристик истинного поведения работающей системы и передачи информации о нем группе разработки и бизнес-стороне. В этой роли служба контроля качества не занимается интерпретацией требований – она идентифицирует фактическое поведение системы.
Пирамида автоматизации тестирования
Профессиональные разработчики для создания модульных тестов обычно применяют методологию разработки через тестирование (TDD, Test Driven Development). Группы профессиональных разработчиков используют приемочные тесты для составления спецификации своей системы и механизм непрерывной интеграции (см. главу 7, с. 122) для предотвращения регрессии. Однако эти тесты составляют лишь часть картины. Какими бы полезными ни были модульные и приемочные тесты, нам также понадобятся тесты более высокого уровня, которые будут следить за тем, чтобы контроль качества не обнаруживал никаких дефектов. На рис. 8.1 изображена пирамида автоматизации тестирования – графическое представление всевозможных тестов, необходимых при профессиональной организации разработки.
Модульные тесты
У основания пирамиды располагаются модульные тесты. Они пишутся программистами для программистов на языке программирования системы. Целью этих тестов является определение спецификации системы на самом нижнем уровне. Выполнение тестов в контексте непрерывной интеграции помогает проследить за тем, что исходные намерения программистов были успешно реализованы.
Рис. 8.1. Пирамида автоматизации тестирования
Модульные тесты должны обеспечивать покрытие кода, настолько близкое к 100 %, насколько это возможно. В общем случае покрытие должно превышать 90 %, причем оно должно быть реальным – в отличие от фальшивых тестов, которые выполняют код без проверки утверждений относительно его поведения.
Компонентные тесты
В эту категорию входит часть приемочных тестов, упоминавшихся в прошлой главе. Обычно эти тесты пишутся для отдельных компонентов системы. В компонентах системы инкапсулируются бизнес-правила, поэтому тесты компонентов становятся приемочными тестами для бизнес-правил.
Как показано на рис. 8.2, компонентный тест изолирует отдельный компонент системы. Он передает компоненту входные данные, получает от него результаты и проверяет их на соответствие входным данным.
Рис. 8.2. Компонентный приемочный тест
Для изоляции остальных компонентов системы применяются макеты и тест-дублеры.
Компонентные тесты пишутся специалистами по контролю качества и бизнес-стороной при помощи разработчиков. Они формируются в средах компонентного тестирования – таких как FitNesse, JBehave или Cucumber. (Компоненты графического интерфейса тестируются в специализированных средах вроде Selenium или Watir.) Тесты должны быть написаны так, чтобы бизнес-сторона могла читать и интерпретировать их (или даже создавать своими силами).
Компонентные тесты обеспечивают покрытие примерно половины системы. Они в основном ориентированы на «оптимистичные» ситуации и наиболее очевидные граничные условия, исключения и аномальные ситуации. Подавляющее большинство «пессимистичных» ситуаций покрывается модульными тестами, и на уровне компонентных тестов они не имеют смысла.
Интеграционные тесты
Тесты этой категории имеют смысл только в больших системах с множеством компонентов. Как видно из рис. 8.3, эти тесты группируют компоненты и тестируют взаимодействия между ними. Другие компоненты системы, как обычно, изолируются при помощи подходящих макетов и тест-дублеров.
Интеграционные тесты являются «хореографическими»: они не тестируют бизнес-правила, а лишь проверяют, насколько хорошо компоненты группы «танцуют» друг с другом. Они проверяют правильность связывания компонентов и обмена информацией между ними.
Рис. 8.3. Интеграционный тест
Интеграционные тесты обычно пишутся системными архитекторами (или ведущими проектировщиками) системы. Они проверяют основательность архитектурной структуры системы. Именно на этом уровне обычно встречаются тесты производительности и пропускной способности.
Интеграционные тесты обычно пишутся на том же языке и в той же среде, что и компонентные тесты. Они редко выполняются в контексте непрерывной интеграции, потому что обычно занимают слишком много времени. Вместо этого тесты выполняются периодически (еженощно, еженедельно и т. д.) с интервалом, определяемым их авторами.
Системные тесты
Автоматизированные тесты, проверяющие работу всей интегрированной системы. По сути, они представляют собой предельный случай интеграционных тестов. Системные тесты не проверяют бизнес-правила напрямую. Вместо этого они проверяют, что компоненты системы правильно связаны друг с другом, а взаимодействие между ними проходит по исходному плану. Тесты производительности и пропускной способности обычно относятся к этой категории.
Эти тесты пишутся системными архитекторами и ведущими специалистами с технической стороны. Как правило, они пишутся на том же языке и в той же среде, что и интеграционные тесты пользовательского интерфейса. Системные тесты выполняются относительно редко (в зависимости от продолжительности их выполнения), но чем чаще – тем лучше.
Системные тесты покрывают 10 % системы. Это объясняется тем, что они предназначены для проверки правильности не поведения системы, а ее конструкции. Правильность поведения нижележащего кода и компонентов уже была проверена на нижних уровнях пирамиды.
Исследовательские тесты
В этой категории разработчикам приходится поработать за клавиатурой и монитором. Исследовательские тесты не автоматизируются и не оформляются в сценарии. Они предназначены для исследования системы на предмет выявления неожиданного поведения и подтверждения поведения ожидаемого. И для исследования системы в этом направлении необходим человеческий мозг с человеческим же творческим мышлением. Построение письменного плана для тестирования такого рода противоречит его цели.
В некоторых группах имеются специалисты для выполнения этой работы. В других группах попросту объявляется «день охоты за ошибками», когда максимальное количество людей, включая начальников, секретарей, программистов, тестеров и авторов технической документации, «издеваются» над системой в попытках «сломать» ее. Покрытие кода не входит в число целей исследовательского тестирования. Мы вовсе не собираемся проверять все бизнес-правила и все пути выполнения. Целью является проверка нормального поведения системы в условиях использования человеком, а также творческое выявление как можно большего количества «странностей».
Заключение
TDD – мощная методология, а приемочные тесты – ценное средство выражения и проверки соблюдения требований. Но они являются лишь частью общей стратегии тестирования. Для достижения цели «Контроль качества не должен находить дефекты» группа разработки должна работать в тесном взаимодействии со службой контроля качества для создания иерархии модульных, компонентных, интеграционных, системных и исследовательских тестов. Тесты следует выполнять как можно чаще, чтобы обеспечить максимальную обратную связь и гарантировать постоянную «чистоту» системы.