Все были так заняты написанием нового кода и тестированием новых дополнительных функций, что никто не заметил того, что продукт больше не работал. Бета-версия была отложена на несколько недель.
В тот момент я и моя команда поняли всю важность автоматизации тестирования для нашего проекта. Мы начали писать автоматизированные регрессивные тесты для ключевых функций, запускать их каждый день и немедленно устранять серьёзные неполадки.
Чаще всего автоматизацию критикуют из-за времени, необходимого для создания хороших тестовых заданий. Да, тестовые задания требуют материальных и трудовых затрат, но, созданные на совесть, они приносят большие дивиденды. Я рекомендую выделить нескольких специалистов по автоматизации, чьей задачей в цикле разработки будет только написание автоматизированных тестовых заданий.
Время, необходимое для поддержания адекватности тестов будущим выпускам, также является объектом нападок. Особенно это относится к автоматизации тестирования пользовательского интерфейса. Если между выпусками в вашем пользовательском интерфейсе происходят серьёзные изменения, то тестовые сценарии могут не работать и потребовать больших усилий для их совершенствования. По этой причине при автоматическом тестировании следует сосредоточиться на функциях, не относящихся к пользовательскому интерфейсу. Автоматизируйте тестирование ключевых функций, а не деталей пользовательского интерфейса.
Отличная идея — строить продукт, изначально рассчитанный на тестирование. Если вы минимизируете свою зависимость от пользовательского интерфейса и создадите альтернативные способы ввода данных и просмотра выходных данных, то будете защищены от изменений в интерфейсе. Например, рассмотрите возможность использования файлов, записей реестра, параметров командной строки и СОМ-интерфейсов передачи входных данных. Для вывода данных вы можете использовать текстовые файлы, распечатку значений переменных или готовые компоненты, специально предназначенные для этой цели. Я не говорю о том, что пользовательский интерфейс не должен быть протестирован, — просто приоритетным должно быть автоматизированное тестирование ключевых функций продукта. Однако если вы решили автоматизировать тестирование пользовательского интерфейса, начните с «контактного» тестирования. При этом, чтобы проверить функциональность всего интерфейса, вызываются и закрываются все диалоговые окна.
Из собственного опыта
Работая в NuMega над BoundsChecker 5, мы знали, что команда, создающая внутренние компоненты, значительно опережает команду, занятую пользовательским интерфейсом. И мы должны были быть уверены в том, что сможем тестировать продукт, даже если у нас не будет пользовательского интерфейса месяц или больше. Команда, отвечающая за внутренние компоненты, разрабатывала простые драйверы, вызывавшие подсистему с данными, необходимыми для работы. Используя эти драйверы, мы могли тестировать продукт и убедиться, что он твёрд, как скала, задолго до того, как пользовательский интерфейс был готов. Помимо раннего тестирования продукта, эти драйверы предоставляли надёжный и простой способ автоматизированного тестирования подсистем разных выпусков.
Команды, процессы и культура
У вас есть опыт создания качественного ПО? Ваши технологические процессы производительны и эффективны или они обычно занимают кучу времени и ресурсов? Учитывается ли вопрос качества каждым человеком, участвующим в разработке ПО? Как далеко вы готовы пойти, чтобы обеспечить качество? О качестве заботится каждый или есть такие, которые говорят: «это не мой участок»?
Эти вопросы могут определить, насколько группа успешна в разработке качественного ПО. Иногда говорят, что высшее руководство не желает брать на себя обязательства, необходимые для создания качественных продуктов. С другой стороны, они, может быть, и хотят поставлять качественный продукт, но не уверены в том, что у команды есть для этого эффективная система. Они считают, что увеличение количества процессов контроля качества всего лишь приведёт к дополнительным затратам времени и повысит расходы без улучшения продукта. Одной из задач этой книги является определение конкретного набора процессов контроля качества, которые позволят поставлять лучшие продукты в кратчайшие сроки, насколько это возможно. Однажды обзаведясь системой, в которой вы уверены, вы вероятнее всего станете поддерживать и постоянно использовать именно её.
Из собственного опыта
В NuMega менеджер проекта определял качество как главный приоритет для каждого члена команды. Он устанавливал продукт и использовал его почти ежедневно, фиксировал ошибки и обсуждал обнаруженные неполадки со своей командой на совещании, в обеденное время и встреч в коридоре. Это подгоняло всю команду, и каждый её участник включался в работу. Тестированием и оценкой результатов занимались все. Все осознали: ошибки — это зло, и с ними надо бороться. Мы давали всем понять, что до самого конца проекта о качестве будут помнить и не забудут после продажи продукта.
Что, когда и как тестировать
Тестирование эффективно, только если понятно, какую часть продукта, когда и как тестировать. Вроде вопросы простые, но если вы работаете в жёстком графике и с ограниченными людскими ресурсами, то вам нельзя терять время, тестируя объект слишком глубоко или, наоборот, слишком поверхностно. Нужно сосредоточиться на проверке в следующих ключевых областях продукта:
• процедуре установки;
• функциональных возможностях;
• интеграции функций;
• производительности.
Тестирование в этих областях должно происходить постоянно в течение всего цикла разработки. Однако для эффективного выполнения этой процедуры вам нужно знать, когда и как проводить тесты в каждой из этих областей. Короче говоря, для каждого крупного мероприятия в процессе разработки вы должны обладать набором хорошо определённых процессов и процедур, которые будут отлавливать проблемы. Эти процессы и процедуры источают в себя следующие компоненты:
• Входные тесты
Проверяют ПО перед подтверждением внесённых изменений.
• Ежедневные базисные тесты
Выполняются для каждой сборки программы.
• Тесты по завершении функции
Проверяют функцию сразу же после завершения работы над ней.
• Тесты при стабилизации и интеграции
Проверяется интеграция функций через определённые интервалы времени.
• Бета-тестирование и кандидаты на выпуск
Производится внешнее тестирование продукта через определённые интервалы времени.
В оставшейся части этой главы мы поговорим об этих пяти ключевых разновидностях тестирования.
Входное тестирование
Позволяет разработчикам проверить важные функции в локальной сборке перед помещением кода в основную базу. Хорошие тесты должны обладать:
• совместимостью между всеми машинами;
• простотой установки, запуска и выполнения;
• проверять ключевые функции или подсистемы продукта.
Входные тесты представляют наибольшую ценность для случаев, когда вы вносите исправления в критичную или сложную часть системы. Если входной тест выполняется неудачно, вы можете самостоятельно найти и устранить неполадку. Вы не нарушите работу остальных разработчиков, которые могут взять исходные файлы с ошибками, после внесения этих файлов вами в систему. Также входные тесты предотвращают внесение критических ошибок в ежедневную сборку и сбой базисного теста.
Ежедневное базисное тестирование
Ещё один способ реализации стратегии «тестировать как можно раньше», помимо входных тестов, — ежедневные базисные тесты. Так как вы строите продукт каждый день, то и тестировать его нужно ежедневно. Базисные тесты — это основной набор автоматизированных регрессивных тестов, проверяющих, что ключевые функции продукта работают. Они обеспечивают создание работоспособной сборки и гарантию того, что за прошедшие 24 часа не было значительных ухудшений. С добавлением новых ключевых компонентов базисные тесты также следует улучшать и расширять.
Из собственного опыта
Продукт BoundsChecker компании NuMega хорошо известен за свою способность находить утечки памяти в приложениях C/C++. Ежедневные базисные тесты для этой программы включали в себя приложение BugBench, в котором было множество утечек памяти, а также других отвратительных «жучков». Мы использовали эту программу-пример для генерации ошибок, которые BoundsChecker должен был уметь искать. Если BoundsChecker находил не все ошибки в программе-примере, тогда по определению сборка считалась плохой. Нам нравилось получать по утрам «ещё дымящийся отчёт о тесте» с результатами проверки сборки минувшей ночи. Такой процесс позволял нашему проекту почти всегда быть стабильным и работающим, поскольку наши базисные тесты сразу находили критические проблемы.
Заметьте: ежедневные базисные тесты не имели своей целью проверку незначительных функций, таких как проверка работоспособности предварительного просмотра перед печатью, или вызов справочной системы по нажатию клавиши H — все это легко проверить вручную. Мы концентрировались на ключевых функциях проекта.
Как и ежедневная сборка, данные о базисных тестах (предоставляемые в виде отчётов) совместно используются всей командой так, что каждому понятно, есть ли в продукте проблемы или нет. Если да, руководители разработчиков и тестировщиков должны провести расследование, быстро определить причину проблемы и назначить специалиста для её разрешения. Для этого специалиста разрешение данной проблемы должно быть наивысшим приоритетом.
Тестирование реализованной функции
Итак, ваша задача — тестировать каждую функцию, как только работа над ней будет завершена. Для каждой важной функции должны быть назначены разработчик и тестировщик, которые вместе будут отвечать за своевременную и качественную поставку этой функции. Такое назначение будет способствовать совместной работе, обмену информацией и идеями, а успех или неудача разделятся поровну. Для каждой существенной функции должны быть заготовлены автоматические тесты, но вы также должны быть готовы, если понадобится, протестировать их вручную. В вашем плане контроля качества должна быть изложена вся информация так, чтобы было абсолютно понятно, когда и как тестируется каждая функция.
Ключевые функции
Основные усилия команды, отвечающей за контроль качества, направляются на тестирование ключевых функций. Их можно тестировать как автоматически, так и вручную, но это надо делать сразу после того, как разработчик закончил кодирование. Чем раньше начать тестирование фикции, тем быстрее вы объективно оцените продвижение проекта и, если обнаружатся проблемы, начнёте их решать.
Тестировщики почти всегда будут находить проблемы. Для их устранения в графике разработки должно быть отведено некоторое время в период разработки компонента или в ближайшем периоде стабилизации. Я советую выделять немного времени в обоих периодах. Скажем, в пятидневном задании должен быть предусмотрен один день как раз для устранения неполадок, то есть 20% «лишнего времени».
Установка
К сожалению, процедура установки — самая «забытая» часть любого продукта. Люди редко думают о том, что установка — это важнейшая функция программы, и поэтому не уделяют ей должного внимания. Если вы не протестируете процедуру установки, можете пожалеть: этот компонент программы используют все. Единственный способ создать великолепное первое впечатление — это разработать отличную процедуру установки. Иначе пользователь с первых минут будет недоволен вашей программой.
Как и для остальных крупных компонентов, для проверки процедуры установки нужно выделить оперативную команду. То есть задача создания и проверки процедуры установки назначается технологам и тестировщикам. Эта задача должна входить в план проверки качества и выполняться регулярно в течение цикла разработки. Помните, что обычно установка — очень сложная часть программы, она требует безупречной работы на самых разных конфигурациях. И здесь автоматическое тестирование незаменимо.
Вот список основных тестов процедуры установки, которые должны быть выполнены для любого продукта, который вы собираетесь поставить.
• Операционные системы
Проверка на всех операционных системах, поддерживаемых вашей программой.
• Сервисные пакеты
Проверка со всеми сервисными пакетами ОС, поддерживаемых вашей программой.
• «Чистая» установка
Проверка установки продукта на ОС, где не установлены предыдущие версии программы.
• «Грязная» установка
Проверка установки продукта на ОС с установленными предыдущими версиями программы.
• Конфигурации продукта
Проверка поддержки процедурой установки различных конфигураций продукта.
• Функции программы установки
Проверка собственных возможностей процедуры установки (онлайновая регистрация, кнопка «Далее», кнопка «Назад», кнопка «Отмена» и т.д.).
• Тест удаления
Проверка процедуры удаления продукта.
Хотя хорошая процедура установки прежде всего предназначена для пользователей, вы тоже увидите, что она играет важную роль в ускорении работы по контролю качества. Так как команда тестировщиков должна работать с самой последней сборкой программы, у вас постоянно должна быть надёжная процедура установки, которую они будут использовать. Ведь вы не хотите, чтобы команда тратила время на редактирование реестра, копирование файлов, редактирование параметров конфигурации и т.д. Вам нужно направить их усилия на тестирование продукта, а не на ручные процедуры, в которых легко могут появиться ошибки.
Надёжная и простая в использовании процедура установки будет полезна для всех членов команды, а не только для тестировщиков. Каждый сможет установить продукт для своих собственных целей. Техническим писателям потребуется установка для создания описания функций продукта, разработчикам — для отслеживания «жучков», проблем с производительностью и оценки пользовательского интерфейса. Ваша команда должна работать с продуктом, а не бороться с его установкой.
Из собственного опыта
Не забудьте о процедуре удаления! В NuMega команды разработчиков и тестировщиков оценили значимость процедуры удаления. Ведь она позволяет получить чистую систему и не тратить время на ручное удаление записей реестра и файлов из системного каталога.
Тестирование при стабилизации и интеграции
До этого момента в цикле разработки тестирование было направлено на проверку отдельных функций. Но в период стабилизации и интеграции внимание уделяется:
• завершению всех отложенных тестов отдельных функций;
• проверке интеграции функций;
• проверке текущей производительности и нагрузки;
• исправлению всех серьёзных ошибок, изъянов проекта или архитектурных проблем;
• тестированию бета-версий и кандидатов на выпуск.
Завершение каждого из этих этапов очень важно для начала работы над следующей частью проекта. Давайте подробнее рассмотрим каждый из них.
Завершение тестирования отдельных функций
Задача номер один — завершение всех тестов, которые могли быть отложены. Это вполне нормально, когда какой-то оперативной команде для завершения всех тестов требуется больше времени, даже после 4-6 недель упорной работы. Используйте это время для выполнения всех тестов, которые ещё не были выполнены, так вы сможете поддерживать параллельное тестирование до самого конца проекта.
Проверка интеграции
Тестирование интеграции должно быть определено заблаговременно как часть плана тестирования. Лучший способ сделать это — создать набор примеров использования, предпочтительно с точки зрения пользователя, описывающих, как различные функции должны работать вместе. Перед тестированием вы должны быть уверены, что заданные функции находятся в рабочем состоянии и в принципе могут использоваться вместе. Именно сейчас время их совместной проверки, и если они не станут работать, то настанет время исправления ошибок.
Тестирование производительности и нагрузки
Хотя конечный продукт нельзя оценить до тех пор, пока вся система не будет собрана воедино, для оценки прогресса или его отсутствия в цикле разработки могут проводиться наблюдения и предварительные измерения.
Не забудьте создать набор тестов, которые будут служить в качестве эталонных тестов для продукта, и выполнять их регулярно в цикле разработки. Выполняйте стрессовые тесты и оценивайте производительность системы по завершении определённых этапов и в моменты синхронизации и интеграции. Именно для этого разработка разбита на этапы. Выполнение тестов в эти моменты — лучший способ раннего обнаружения ошибок и их исправления до того, как вы продолжите строить ваш продукт на фундаменте, содержащем ошибку.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30
В тот момент я и моя команда поняли всю важность автоматизации тестирования для нашего проекта. Мы начали писать автоматизированные регрессивные тесты для ключевых функций, запускать их каждый день и немедленно устранять серьёзные неполадки.
Чаще всего автоматизацию критикуют из-за времени, необходимого для создания хороших тестовых заданий. Да, тестовые задания требуют материальных и трудовых затрат, но, созданные на совесть, они приносят большие дивиденды. Я рекомендую выделить нескольких специалистов по автоматизации, чьей задачей в цикле разработки будет только написание автоматизированных тестовых заданий.
Время, необходимое для поддержания адекватности тестов будущим выпускам, также является объектом нападок. Особенно это относится к автоматизации тестирования пользовательского интерфейса. Если между выпусками в вашем пользовательском интерфейсе происходят серьёзные изменения, то тестовые сценарии могут не работать и потребовать больших усилий для их совершенствования. По этой причине при автоматическом тестировании следует сосредоточиться на функциях, не относящихся к пользовательскому интерфейсу. Автоматизируйте тестирование ключевых функций, а не деталей пользовательского интерфейса.
Отличная идея — строить продукт, изначально рассчитанный на тестирование. Если вы минимизируете свою зависимость от пользовательского интерфейса и создадите альтернативные способы ввода данных и просмотра выходных данных, то будете защищены от изменений в интерфейсе. Например, рассмотрите возможность использования файлов, записей реестра, параметров командной строки и СОМ-интерфейсов передачи входных данных. Для вывода данных вы можете использовать текстовые файлы, распечатку значений переменных или готовые компоненты, специально предназначенные для этой цели. Я не говорю о том, что пользовательский интерфейс не должен быть протестирован, — просто приоритетным должно быть автоматизированное тестирование ключевых функций продукта. Однако если вы решили автоматизировать тестирование пользовательского интерфейса, начните с «контактного» тестирования. При этом, чтобы проверить функциональность всего интерфейса, вызываются и закрываются все диалоговые окна.
Из собственного опыта
Работая в NuMega над BoundsChecker 5, мы знали, что команда, создающая внутренние компоненты, значительно опережает команду, занятую пользовательским интерфейсом. И мы должны были быть уверены в том, что сможем тестировать продукт, даже если у нас не будет пользовательского интерфейса месяц или больше. Команда, отвечающая за внутренние компоненты, разрабатывала простые драйверы, вызывавшие подсистему с данными, необходимыми для работы. Используя эти драйверы, мы могли тестировать продукт и убедиться, что он твёрд, как скала, задолго до того, как пользовательский интерфейс был готов. Помимо раннего тестирования продукта, эти драйверы предоставляли надёжный и простой способ автоматизированного тестирования подсистем разных выпусков.
Команды, процессы и культура
У вас есть опыт создания качественного ПО? Ваши технологические процессы производительны и эффективны или они обычно занимают кучу времени и ресурсов? Учитывается ли вопрос качества каждым человеком, участвующим в разработке ПО? Как далеко вы готовы пойти, чтобы обеспечить качество? О качестве заботится каждый или есть такие, которые говорят: «это не мой участок»?
Эти вопросы могут определить, насколько группа успешна в разработке качественного ПО. Иногда говорят, что высшее руководство не желает брать на себя обязательства, необходимые для создания качественных продуктов. С другой стороны, они, может быть, и хотят поставлять качественный продукт, но не уверены в том, что у команды есть для этого эффективная система. Они считают, что увеличение количества процессов контроля качества всего лишь приведёт к дополнительным затратам времени и повысит расходы без улучшения продукта. Одной из задач этой книги является определение конкретного набора процессов контроля качества, которые позволят поставлять лучшие продукты в кратчайшие сроки, насколько это возможно. Однажды обзаведясь системой, в которой вы уверены, вы вероятнее всего станете поддерживать и постоянно использовать именно её.
Из собственного опыта
В NuMega менеджер проекта определял качество как главный приоритет для каждого члена команды. Он устанавливал продукт и использовал его почти ежедневно, фиксировал ошибки и обсуждал обнаруженные неполадки со своей командой на совещании, в обеденное время и встреч в коридоре. Это подгоняло всю команду, и каждый её участник включался в работу. Тестированием и оценкой результатов занимались все. Все осознали: ошибки — это зло, и с ними надо бороться. Мы давали всем понять, что до самого конца проекта о качестве будут помнить и не забудут после продажи продукта.
Что, когда и как тестировать
Тестирование эффективно, только если понятно, какую часть продукта, когда и как тестировать. Вроде вопросы простые, но если вы работаете в жёстком графике и с ограниченными людскими ресурсами, то вам нельзя терять время, тестируя объект слишком глубоко или, наоборот, слишком поверхностно. Нужно сосредоточиться на проверке в следующих ключевых областях продукта:
• процедуре установки;
• функциональных возможностях;
• интеграции функций;
• производительности.
Тестирование в этих областях должно происходить постоянно в течение всего цикла разработки. Однако для эффективного выполнения этой процедуры вам нужно знать, когда и как проводить тесты в каждой из этих областей. Короче говоря, для каждого крупного мероприятия в процессе разработки вы должны обладать набором хорошо определённых процессов и процедур, которые будут отлавливать проблемы. Эти процессы и процедуры источают в себя следующие компоненты:
• Входные тесты
Проверяют ПО перед подтверждением внесённых изменений.
• Ежедневные базисные тесты
Выполняются для каждой сборки программы.
• Тесты по завершении функции
Проверяют функцию сразу же после завершения работы над ней.
• Тесты при стабилизации и интеграции
Проверяется интеграция функций через определённые интервалы времени.
• Бета-тестирование и кандидаты на выпуск
Производится внешнее тестирование продукта через определённые интервалы времени.
В оставшейся части этой главы мы поговорим об этих пяти ключевых разновидностях тестирования.
Входное тестирование
Позволяет разработчикам проверить важные функции в локальной сборке перед помещением кода в основную базу. Хорошие тесты должны обладать:
• совместимостью между всеми машинами;
• простотой установки, запуска и выполнения;
• проверять ключевые функции или подсистемы продукта.
Входные тесты представляют наибольшую ценность для случаев, когда вы вносите исправления в критичную или сложную часть системы. Если входной тест выполняется неудачно, вы можете самостоятельно найти и устранить неполадку. Вы не нарушите работу остальных разработчиков, которые могут взять исходные файлы с ошибками, после внесения этих файлов вами в систему. Также входные тесты предотвращают внесение критических ошибок в ежедневную сборку и сбой базисного теста.
Ежедневное базисное тестирование
Ещё один способ реализации стратегии «тестировать как можно раньше», помимо входных тестов, — ежедневные базисные тесты. Так как вы строите продукт каждый день, то и тестировать его нужно ежедневно. Базисные тесты — это основной набор автоматизированных регрессивных тестов, проверяющих, что ключевые функции продукта работают. Они обеспечивают создание работоспособной сборки и гарантию того, что за прошедшие 24 часа не было значительных ухудшений. С добавлением новых ключевых компонентов базисные тесты также следует улучшать и расширять.
Из собственного опыта
Продукт BoundsChecker компании NuMega хорошо известен за свою способность находить утечки памяти в приложениях C/C++. Ежедневные базисные тесты для этой программы включали в себя приложение BugBench, в котором было множество утечек памяти, а также других отвратительных «жучков». Мы использовали эту программу-пример для генерации ошибок, которые BoundsChecker должен был уметь искать. Если BoundsChecker находил не все ошибки в программе-примере, тогда по определению сборка считалась плохой. Нам нравилось получать по утрам «ещё дымящийся отчёт о тесте» с результатами проверки сборки минувшей ночи. Такой процесс позволял нашему проекту почти всегда быть стабильным и работающим, поскольку наши базисные тесты сразу находили критические проблемы.
Заметьте: ежедневные базисные тесты не имели своей целью проверку незначительных функций, таких как проверка работоспособности предварительного просмотра перед печатью, или вызов справочной системы по нажатию клавиши H — все это легко проверить вручную. Мы концентрировались на ключевых функциях проекта.
Как и ежедневная сборка, данные о базисных тестах (предоставляемые в виде отчётов) совместно используются всей командой так, что каждому понятно, есть ли в продукте проблемы или нет. Если да, руководители разработчиков и тестировщиков должны провести расследование, быстро определить причину проблемы и назначить специалиста для её разрешения. Для этого специалиста разрешение данной проблемы должно быть наивысшим приоритетом.
Тестирование реализованной функции
Итак, ваша задача — тестировать каждую функцию, как только работа над ней будет завершена. Для каждой важной функции должны быть назначены разработчик и тестировщик, которые вместе будут отвечать за своевременную и качественную поставку этой функции. Такое назначение будет способствовать совместной работе, обмену информацией и идеями, а успех или неудача разделятся поровну. Для каждой существенной функции должны быть заготовлены автоматические тесты, но вы также должны быть готовы, если понадобится, протестировать их вручную. В вашем плане контроля качества должна быть изложена вся информация так, чтобы было абсолютно понятно, когда и как тестируется каждая функция.
Ключевые функции
Основные усилия команды, отвечающей за контроль качества, направляются на тестирование ключевых функций. Их можно тестировать как автоматически, так и вручную, но это надо делать сразу после того, как разработчик закончил кодирование. Чем раньше начать тестирование фикции, тем быстрее вы объективно оцените продвижение проекта и, если обнаружатся проблемы, начнёте их решать.
Тестировщики почти всегда будут находить проблемы. Для их устранения в графике разработки должно быть отведено некоторое время в период разработки компонента или в ближайшем периоде стабилизации. Я советую выделять немного времени в обоих периодах. Скажем, в пятидневном задании должен быть предусмотрен один день как раз для устранения неполадок, то есть 20% «лишнего времени».
Установка
К сожалению, процедура установки — самая «забытая» часть любого продукта. Люди редко думают о том, что установка — это важнейшая функция программы, и поэтому не уделяют ей должного внимания. Если вы не протестируете процедуру установки, можете пожалеть: этот компонент программы используют все. Единственный способ создать великолепное первое впечатление — это разработать отличную процедуру установки. Иначе пользователь с первых минут будет недоволен вашей программой.
Как и для остальных крупных компонентов, для проверки процедуры установки нужно выделить оперативную команду. То есть задача создания и проверки процедуры установки назначается технологам и тестировщикам. Эта задача должна входить в план проверки качества и выполняться регулярно в течение цикла разработки. Помните, что обычно установка — очень сложная часть программы, она требует безупречной работы на самых разных конфигурациях. И здесь автоматическое тестирование незаменимо.
Вот список основных тестов процедуры установки, которые должны быть выполнены для любого продукта, который вы собираетесь поставить.
• Операционные системы
Проверка на всех операционных системах, поддерживаемых вашей программой.
• Сервисные пакеты
Проверка со всеми сервисными пакетами ОС, поддерживаемых вашей программой.
• «Чистая» установка
Проверка установки продукта на ОС, где не установлены предыдущие версии программы.
• «Грязная» установка
Проверка установки продукта на ОС с установленными предыдущими версиями программы.
• Конфигурации продукта
Проверка поддержки процедурой установки различных конфигураций продукта.
• Функции программы установки
Проверка собственных возможностей процедуры установки (онлайновая регистрация, кнопка «Далее», кнопка «Назад», кнопка «Отмена» и т.д.).
• Тест удаления
Проверка процедуры удаления продукта.
Хотя хорошая процедура установки прежде всего предназначена для пользователей, вы тоже увидите, что она играет важную роль в ускорении работы по контролю качества. Так как команда тестировщиков должна работать с самой последней сборкой программы, у вас постоянно должна быть надёжная процедура установки, которую они будут использовать. Ведь вы не хотите, чтобы команда тратила время на редактирование реестра, копирование файлов, редактирование параметров конфигурации и т.д. Вам нужно направить их усилия на тестирование продукта, а не на ручные процедуры, в которых легко могут появиться ошибки.
Надёжная и простая в использовании процедура установки будет полезна для всех членов команды, а не только для тестировщиков. Каждый сможет установить продукт для своих собственных целей. Техническим писателям потребуется установка для создания описания функций продукта, разработчикам — для отслеживания «жучков», проблем с производительностью и оценки пользовательского интерфейса. Ваша команда должна работать с продуктом, а не бороться с его установкой.
Из собственного опыта
Не забудьте о процедуре удаления! В NuMega команды разработчиков и тестировщиков оценили значимость процедуры удаления. Ведь она позволяет получить чистую систему и не тратить время на ручное удаление записей реестра и файлов из системного каталога.
Тестирование при стабилизации и интеграции
До этого момента в цикле разработки тестирование было направлено на проверку отдельных функций. Но в период стабилизации и интеграции внимание уделяется:
• завершению всех отложенных тестов отдельных функций;
• проверке интеграции функций;
• проверке текущей производительности и нагрузки;
• исправлению всех серьёзных ошибок, изъянов проекта или архитектурных проблем;
• тестированию бета-версий и кандидатов на выпуск.
Завершение каждого из этих этапов очень важно для начала работы над следующей частью проекта. Давайте подробнее рассмотрим каждый из них.
Завершение тестирования отдельных функций
Задача номер один — завершение всех тестов, которые могли быть отложены. Это вполне нормально, когда какой-то оперативной команде для завершения всех тестов требуется больше времени, даже после 4-6 недель упорной работы. Используйте это время для выполнения всех тестов, которые ещё не были выполнены, так вы сможете поддерживать параллельное тестирование до самого конца проекта.
Проверка интеграции
Тестирование интеграции должно быть определено заблаговременно как часть плана тестирования. Лучший способ сделать это — создать набор примеров использования, предпочтительно с точки зрения пользователя, описывающих, как различные функции должны работать вместе. Перед тестированием вы должны быть уверены, что заданные функции находятся в рабочем состоянии и в принципе могут использоваться вместе. Именно сейчас время их совместной проверки, и если они не станут работать, то настанет время исправления ошибок.
Тестирование производительности и нагрузки
Хотя конечный продукт нельзя оценить до тех пор, пока вся система не будет собрана воедино, для оценки прогресса или его отсутствия в цикле разработки могут проводиться наблюдения и предварительные измерения.
Не забудьте создать набор тестов, которые будут служить в качестве эталонных тестов для продукта, и выполнять их регулярно в цикле разработки. Выполняйте стрессовые тесты и оценивайте производительность системы по завершении определённых этапов и в моменты синхронизации и интеграции. Именно для этого разработка разбита на этапы. Выполнение тестов в эти моменты — лучший способ раннего обнаружения ошибок и их исправления до того, как вы продолжите строить ваш продукт на фундаменте, содержащем ошибку.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30