Время — деньги. Создание команды разработчиков программного обеспечения

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

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

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

Из собственного опыта

Работая в NuMega над BoundsChecker 5, мы знали, что команда, создающая внутренние компоненты, значительно опережает команду, занятую пользовательским интерфейсом. И мы должны были быть уверены в том, что сможем тестировать продукт, даже если у нас не будет пользовательского интерфейса месяц или больше. Команда, отвечающая за внутренние компоненты, разрабатывала простые драйверы, вызывавшие подсистему с данными, необходимыми для работы. Используя эти драйверы, мы могли тестировать продукт и убедиться, что он твёрд, как скала, задолго до того, как пользовательский интерфейс был готов. Помимо раннего тестирования продукта, эти драйверы предоставляли надёжный и простой способ автоматизированного тестирования подсистем разных выпусков.

Команды, процессы и культура

У вас есть опыт создания качественного ПО? Ваши технологические процессы производительны и эффективны или они обычно занимают кучу времени и ресурсов? Учитывается ли вопрос качества каждым человеком, участвующим в разработке ПО? Как далеко вы готовы пойти, чтобы обеспечить качество? О качестве заботится каждый или есть такие, которые говорят: «это не мой участок»?

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

Из собственного опыта