Отслеживание проектов тестирования с помощью виртуального портала статуса: расширение возможностей Rational ClearCase и Web

Сьюзен Маквей, инженер по качеству ПО Rational Software, IBM Software Group

Оглавление

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

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

Давайте начнем с краткого описания проекта и группы. Rational PurifyPlus for UNIX поддерживается группой разработчиков программного обеспечения и смежной группой инженеров по качеству ПО. Первоначально обе группы находились в Кьюпертино, Калифорния, однако в последние годы в группу был включен ряд других разработчиков и испытателей в городе Бангалор, Индия. Хотя некоторые проекты тестирования проводятся в одном из офисов, сотрудники этих офисов совместно решают многие задачи.

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

После экспериментов с различными уровнями формальности в документах на протяжении нескольких итераций была создана система контрольных списков для технического обеспечения качества. Контрольный список - это документ, в котором содержится как план тестирования, так и протокол испытаний одной сферы продукта, как правило, новой функциональной возможности, поддержки нового компилятора или версии операционной системы или проекта проверки версии. Хотя согласно промышленным стандартам для отчетов о тестировании и планов тестирования должны создаваться отдельные документы, мы считаем, что эти документы целесообразно объединить для простого просмотра в web-браузере. В контрольном списке для технического обеспечения качества содержится описание тестируемой функциональной возможности, инструкций по настройке среды тестирования и список задач тестирования. В каждой задаче имеется краткое описание и место для записи о выполнении теста. Контрольный список также содержит примечания тестировщиков и указатели на отчеты о проблеме в базе данных отслеживания ошибок (см. рис. 1).

Рис. 1. Контрольный список для технического обеспечения качества по проекту Rational PurifyPlus для UNIX

Испытатели хранят подробные примечания в своих рабочих портативных компьютерах, однако с помощью контрольного списка можно получить более широкое представление. Для повторяющихся задач, таких, как проверка сборки ПО, тестирование новой версии программы установки или тестирование Rational Purify с новым компилятором, существует шаблон контрольного списка, который можно легко обработать и изменить для каждой итерации. При тестировании новых функциональных возможностей продукта функциональная спецификация и дизайн рассматриваются в рамках более строгого и традиционного процесса, вырабатывается план тестирования, который перед началом тестирования проверяется. Как правило, в каждой версии Rational PurifyPlus содержится приблизительно 25 - 35 контрольных списков, из которых больше половины являются реализациями стандартных шаблонов контрольных списков. Контрольные списки можно также создать для проектов тестирования инфраструктуры. В итоговом контрольном списке для каждой версии содержатся все прочие контрольные списки и ссылки на каждый из них (см. рис. 2).

Рис. 2. Итоговый контрольный список для версии продукта

Контрольные списки хранятся в Rational ClearCase как файлы html. Файлы могут быть отредактированы в Netscape Composer или текстовом редакторе, например, в vi или emacs, однако для просмотра файлов редактор должен вызываться из окна оболочки в виде ClearCase. Чтобы сохранялась только одна копия протокола, документы тестирования объединяются непосредственно в главное ответвление ClearCase и в отличие от исходного текста продукта не развертываются на версионные ответвления. Вместо этого контрольные списки для каждой версии находятся в отдельных подкаталогах.

Для просмотра контрольных списков из web-браузера была создана ссылка с web-сайта ведомственного интранета на итоговый контрольный список для каждой версии. И, как отмечалось, ссылки из итогового списка вели к каждой функциональной возможности или каждому контрольному списку версии. Несмотря на то, что контрольные списки используются в основном инженерами, имеющими доступ к файлам в Rational ClearCase, другим пользователям также необходимо просматривать контрольные списки со своего персонального компьютера, подключенного к интранету. Поскольку этим пользователям необходимо только просмотреть эту информацию, а не редактировать ее, копия контрольных списков экспортируется на диск, который совместно используется в системах PC и UNIX. Экспортированные файлы обновляются с помощью сценария Perl путем запуска представления и копирования файлов из базы версий объектов (VOB). Для запуска экспорта используется сценарий cron или триггер, позволяющий выполнить сценарий экспорта при каждом объединении контрольного списка из чьего-либо персонального ответвления к главному ответвлению. Гипертекстовые ссылки в контрольных списках относятся к текущему каталогу и не включают полный путь, поэтому они работают как в базе VOB, так и в экспортированной копии.

Информационная доска для технического обеспечения качества

Для получения полного представления о тестировании и статусе продукта используется модифицированная форма системы информационных досок (whiteboard), предложенная Джеймсом Бахом в своем экспериментальном методе тестирования (http://www.satisfice.com).

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

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

Как и многие вещи в мире разработки программного обеспечения, эта система работала довольно хорошо, пока не изменились условия. Когда к нашей группе присоединилась группа разработчиков в Бангалоре, мы столкнулись с двумя проблемами: обеим группам было необходимо одновременно использовать те же файлы контрольного списка, и инженеры в Бангалоре не имели возможности пользоваться нашей информационной доской в Калифорнии. Решение совместного использования файлов было очевидным: группа продуктов уже использовала приложение Rational ClearCase MultiSite для совместного использования исходного текста в этих двух местоположениях, поэтому было принято решение совместно использовать документы тестирования также с помощью этого приложения.

Онлайн-портал статуса тестирования

Физической информационной доской можно было пользоваться только в одном местоположении, поэтому ее было необходимо заменить web-страницей интранета, которую могли просматривать обе группы. В строках информационной доски содержалось резюме контрольных списков, поэтому было принято решение сгенерировать web-страницу виртуальной электронной доски на основе файлов контрольного списка, хранящихся в Rational ClearCase. Мы могли не только просматривать и редактировать электронную доску в файлах ClearCase в обеих группах, но и расширить ее содержание информацией о завершении задачи, на постоянное обновление которой на физической доске потребуется слишком много времени (см. рис. 3).

Рис. 3. Web-страница виртуальной электронной доски

В более раннюю реализацию документов по техническому обеспечению качества входила информация о расписании и статусе, закодированная в строках с тегом, который при генерации отчета мог распознаваться сценарием Perl. Было принято решение использовать ту же стратегию для электронной доски. В верхней части каждого контрольного списка был добавлен ряд строк с тегами, содержащих информацию электронной доски. Строки, помеченные "+++" и ключевым словом, можно было не только легко извлечь и проанализировать с помощью сценария, но и прочитать сотрудникам (см. рис. 4).

Рис. 4. Контрольный список со строками, помеченными для простого извлечения

В каждом контрольном списке содержатся теги для информации, показанной на электронной доске:

  • Название или краткое описание контрольного списка (+++Description).
  • Текущий уровень усилий, прилагаемых к проведению тестов для этого контрольного списка, или статус SHIP ("Готово к поставке"), если выполнение контрольного списка завершено (+++Effort: HIGH, LOW, WAITING, START, SHIP).
  • Объем тестового покрытия, завершенный на данный момент для этой функциональной возможности и выражаемый числом от 0 до 3, и целевое число, которое группа ожидает достичь (+++Coverage).
  • Оценка качества тестируемой функциональной возможности или версии с помощью тех же символов, которые использовались на первоначальной информационной доске. Нейтральное черное лицо было заменено на желтое для большей понятности, а пустой серый круг - на "N/A" ("Недоступно") для функциональных возможностей, качество которых еще не оценено (+++Assessment: RED, NEUTRAL, GREEN, N/A).
  • Одна или несколько строк комментария, добавляемых членами группы. Они выводятся в столбце "Comments" ("Комментарии") и обычно содержат такую информацию, как "Дальнейшее тестирование невозможно до устранения ошибки 12345" или "Ожидание установки нового компилятора". (+++Comment)

В дополнение к этим строкам с тегами уровня контрольного списка существует строка "+++ Status" (статус), связанная с каждой задачей тестирования в контрольном списке с опциями Выполнено, Не выполнено, Приостановлено, Ожидание или Удалено. Если в плане тестирования имеется группа связанных задач, например, проведение теста с различными компиляторами, в отдельной строке статуса выводится статус всей этой группы задач. На электронной доске можно просмотреть число завершенных задач и общее число запланированных задач. Это число завершенных задач отличается от вышеупомянутого числа завершенных тестов: вышеупомянутое число - это показатель завершения плана, тогда как число завершенных задач - это показатель тестового покрытия для продукта. Для достаточно понятного постепенного внесения изменений целевой уровень покрытия продукта может быть низким, поскольку предполагается проводить только простой регрессионный тест; однако все еще ожидается, что покрытие плана тестирования достигнет 100% перед утверждением продукта к выпуску.

На главной web-странице версии приводятся описание продукта и его изменения по сравнению с предыдущей версией, а также контрольные списки тестирования. На ней также содержатся строки с тегами, помеченные как "+++Header:" (заголовок), которые выводятся в верхней части виртуальной электронной доски. Они используются для идентификации версии и просмотра информации о расписании и статусе.

Сценарий Perl, разработанный моим коллегой Томом Арнольдом, считывает все контрольные списки для версии, анализирует строки с тегами и генерирует web-страницу электронной доски, а также страницу индексов со ссылками на все электронные доски, активные на данный момент. Если работа ведется одновременно над несколькими версиями продукта, могут быть активны несколько электронных досок (см. рис. 5).

Рис. 5. Страница индексов со ссылками на несколько электронных досок

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

Проблемы и возможности

Наша первоначальная система работала хорошо, но в каждую новую версию мы вносили небольшие изменения для оптимизации работы системы. Одной из таких оптимизаций было добавление нескольких оценок качества (значков лиц). Иногда в течение бета-итерации проекта качество определенной функциональной возможности оценивалось как достаточно хорошее для первой бета-версии (зеленое лицо), но она все еще нуждалась в доработке перед выпуском окончательной версии (красное лицо). Электронная доска переполнялась комментариями, поясняющими, к какой итерации относится данная оценка. С целью упрощения была внедрена возможность присваивать каждой итерации свою оценку качества. Вместо одной строки оценки качества "+++Assessment" в контрольном списке могут содержаться строки "+++Beta1_Quality" (качество первой бета-версии), "+++Beta2_Quality" (качество второй бета-версии), "+++Final_Quality" (качество окончательной версии) и т. д. Кроме того, к итоговому контрольному списку был добавлен новый тег "+++Show_Quality" (показать качество), поэтому теги для предыдущих итераций можно было удалить с электронной доски.

Если файл редактировался обеими группами разработчиков между двумя обновлениями, Rational ClearCase позволяет выполнить автоматическое слияние, пока разработчики в обеих группах не редактировали те же строки файла. В первой версии контрольных списков вместо файла .html использовался текстовый файл, и в файле имелись таблицы, в которых в одном столбце содержались тесты для Solaris, а в другом столбце - тесты для HPUX. Поскольку операционные системы Solaris и HPUX тестировались различными группами, обе группы получали обновления той же строки файла, т. е. эти обновления невозможно было объединить автоматически. Разделив задачи, выполняемые группами в Кьюпертино и Бангалора, на различные строки или абзацы в документе, проблем со слиянием удалось избежать, и процесс обновления выполнялся автоматически.

Расширение этого было проблемой планирования ежедневного слияния. Калифорния и Индия находятся почти в противоположных часовых поясах, поэтому в любое время дня или ночи невозможно обеспечить, что кто-нибудь в одной из групп не обновит контрольный список. В любом случае какой-нибудь сотрудник одной из групп редактирует файл, когда поступает обновление из другой группы. Чтобы избежать связанных с этим проблем, мы в конечном счете начали делить контрольные списки тестирования функциональной возможности между географическими местоположениями; вместо одного контрольного списка для нового компилятора gcc были созданы две копии: одна для операционной системы Solaris (Кьюпертино), другая для операционной системы HPUX (Бангалор).

Также была добавлена возможность скрыть информацию, ставшую со временем бесполезной. Для каждого прототипа или бета-версии существуют один или два контрольных списка, поэтому через некоторое время электронная доска переполняется, и информацию для протестированных функциональных возможностей уже не требуется просматривать. Чтобы скрыть устаревшие контрольные списки на электронной доске, в них вставлялся тег "+++Closed" (Закрыто); если членам группы необходимо просмотреть закрытый контрольный список, для этого можно использовать ссылку на него из итогового контрольного списка.

Заключительной оптимизацией виртуальной электронной доски по отношению к физической было включение web-ссылок. Щелкнув кнопкой мыши на любой информации на электронной доске, пользователи могли просмотреть ее определение. Щелкнув кнопкой мыши на названии функциональной возможности, пользователь может перейти к ее контрольному списку. Щелкнув на завершении плана тестирования, можно просмотреть список задач (отдельные строки "статуса" в контрольном списке), который указывает, выполнены ли эти задачи.

Какая информационная доска лучше: виртуальная или физическая?

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

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

Поэтому в заключение я хочу сделать следующее предложение: независимо от формы ваших планов тестирования, контрольных списков или других отчетов о статусе, я рекомендую хранить исходные данные в файлах Rational ClearCase и генерировать виртуальную электронную доску с информацией о статусе проекта. Вы будете просто удивлены тем, сколько времени освободится для тестирования продуктов. Просто посмотрите на рис. 6!

Рис. 6. Виртуальная электронная доска с информацией о статусе проекта позволяет освободить драгоценное время для тестирования

Примечания

1 Решение Rational PurifyPlus for Unix включает возможности продуктов Rational Purify, Rational Quantify и Rational PureCoverage.

Дополнительная информация


Страница сайта http://test.interface.ru
Оригинал находится по адресу http://test.interface.ru/home.asp?artId=1154