Основные принципы

Основные принципы

Начнём с принципов работы системы контроля качества. Лейтмотив — обеспечение качества непосредственно в процессе разработки. Продукту нельзя придать качество позже без значительных затрат денег, сил и времени. Создание качественного продукта основывается на четырёх простых принципах:

• тестирование продукта осуществляется параллельно с процессом его разработки;

• качество продукта улучшается регулярно при завершении каждого планового этапа разработки;

• тестирование необходимо максимально автоматизировать;

• качество является частью культуры и технологии.

Параллельное тестирование

В среде с ограниченным временем поиск и устранение проблем в кратчайшие сроки с момента их появления — условие необходимое. Раньше узнаешь о проблеме — раньше решишь. Ваша задача — тестировать функции программы сразу после их окончательного создания. Это и называется параллельным тестированием. Чтобы его правильно осуществлять, вы должны иметь средства автоматизированного тестирования или ресурсы для проведения ручных тестов, доступные в момент реализации новых функций. Если реализация функции запланирована на конец пятой недели, то команда испытателей должна быть готова протестировать её на шестой. Это правило следует применять ко всем основным функциям. Хотя автоматизированное тестирование предпочтительнее, к запланированному моменту должны быть готовы и ресурсы для ручного проведения этой операции.

Ниже представлен идеальный график параллельного тестирования набора функций программы (табл. 6-1). Заметьте, что разработка и тестирование идут максимально плотно друг за другом. Реализация функции завершается в конце недели, команда испытателей готова приступить к тестированию в начале следующей. Хотя разработчики ответственны и за создание кода, и за его базовое тестирование, команда тестировщиков в заданный период проверяет функцию по максимуму. Так как разработчики и тестировщики должны работать над функцией вместе, их называют «оперативной командой».

Табл. 6-1. График работы оперативной команды над функциями А, В и С.

Разработчики и тестировщики несут обоюдную ответственность за своевременное обеспечение качества. В такой системе реализация функции не завершается написанием кода. Функция считается законченной, если она проверена тестировщиками и соответствует заданным критериям. Разработчики и тестировщики должны осознавать, что для завершения работы над функцией они должны работать вместе. У каждой группы свои задачи (написание кода, тестирование, автоматизация и т.п.), но чтобы сделать всю работу, они должны действовать сообща. Нельзя переходить к следующей функции, если текущий набор функций не проработан окончательно и не стабилизирован.

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

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

Стабилизация и интеграция

Через каждые 4-6 недель команда должна отводить 1-2 недели (в зависимости от сложности проекта) на тестирование, стабилизацию и интеграцию функций, завершённых к данному моменту. Такие периоды стабилизации и интеграции идут на пользу команде, функциональности и качеству. Вы можете завершить незаконченное тестирование, начать интегральную проверку функциональности и определить проблемы, которые следует решить, прежде чем продолжить работу над проектом. Не обращайте особого внимания на мелкие неисправности и детали. Просто перед началом очередной стадии убедитесь, что структурно и функционально проект находится в хорошем состоянии. В течение этого периода все члены команды должны направлять свои усилия только на стабилизацию и интеграцию. Не работайте над новыми функциями, кодом или чем-то ещё до тех пор, пока вы не будете уверены в стабильности того, что уже построено.

Периоды стабилизации и интеграции также позволяют сопоставить фактическое продвижение проекта с запланированным. Если проект хорошо спланирован, вы будете точно знать, на какой неделе какая функция будет завершена. Укладываетесь ли вы в график? Можно ли использовать определённые функции в намеченный срок? Эта информация необходима для того, чтобы не дать проекту выйти из колеи. Повторю, что о календарном планировании подробно говорится в главе 11, а сейчас просто запомните, что вам нужно заранее определить периоды, во время которых вся команда, работающая над проектом, будет концентрироваться на стабилизации и интеграции программы.

Автоматизация

Максимально возможная автоматизация процесса тестирования — ключ к параллельному тестированию (и раннему обнаружению ошибок). Автоматизация предоставит вам следующие преимущества:

• Сокращение внутреннего цикла тестирования

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

• Сокращение потребностей в персонале

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

• Проверка изменений, внесённых в последний момент

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

• Обеспечение полноты тестирования для новых выпусков

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

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

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

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

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

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

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

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

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

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

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

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

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

В NuMega менеджер проекта определял качество как главный приоритет для каждого члена команды. Он устанавливал продукт и использовал его почти ежедневно, фиксировал ошибки и обсуждал обнаруженные неполадки со своей командой на совещании, в обеденное время и встреч в коридоре. Это подгоняло всю команду, и каждый её участник включался в работу. Тестированием и оценкой результатов занимались все. Все осознали: ошибки — это зло, и с ними надо бороться. Мы давали всем понять, что до самого конца проекта о качестве будут помнить и не забудут после продажи продукта.