Хранение ошибок. Дефектоскопия
Известно, что отловить и исправить ошибку в программном коде очень сложно. Обычно все самые неприятные ошибки обнаруживаются на этапе коммерческой эксплуатации продукта со всеми вытекающими отсюда последствиями. Компания Rational предлагает достаточно большой круг программных и методологических решений, направленных на уменьшение числа ошибок в текстах программ.
По RUP процесс тестирования и документирования найденных ошибок должен начинаться вместе с этапом разработки. Чем позже начинается тестирование, тем ниже качество конечного продукта, тем больше времени тратится командой на постоянные доводки продукта в режиме "пожарной команды".
Для тестирования по RUP можно пользоваться следующими инструментами:
– для контроля над ошибками доступа к памяти;
– для профилирования производительности и оптимизации кода;
– для получения области охвата (сколько процентов кода протестировано);
– для функционального и нагрузочного тестирования;
– как средство планирования и осуществления тестирования (совместно с Robot). Позволяет не только проводить планирование тестов, но и осуществлять распределенные комбинированные тесты на разных платформах.
Описывать данные инструменты мы здесь не будем. По ссылкам вы сможете прочитать специальные статьи по каждому из них.
Давайте рассмотрим, как Rational предполагает осуществлять документирование ошибок, но сначала еще раз разберемся с терминологией и направленностью инструментов тестирования. Первые три продукта в списке - это продукты необходимые разработчикам во время написания и отладки кода. Четвертый и пятый - для тестировщиков, которым видеть код не всегда нужно, им важно проверить функциональность системы в целом, не вдаваясь в тонкости кодирования. Заметим, что это не всегда так, потому что на этапе определения требований к проекту может быть записано, что тестировщик должен оценивать строгость кода, проверяя его на наличие специальных инструкций или на соответствие определенным стандартам на разработку.
Менеджерам проектов и руководителям отделов абсолютно необходим контроль (мониторинг) состояния текущего проекта, наличия в нем ошибок, также необходим механизм поручения исправления ошибок с последующим контролем вплоть до выхода новой версии продукта или передачи исправленной версии клиенту.
А весь контроль необходимо осуществлять в реальном масштабе времени. Здесь и придет на помощь ClearQuest.
Наличие одного CQ недостаточно, поскольку для полноценной работы необходимо взаимодействовать с репозиторием, с определенной версией схемы и физической базой данных. Не вдаваясь в детали того, как это делается (читайте следующий выпуск статьи) отметим, что для целей создания единого репозитория и инициализации схем и баз данных используется утилита Rational Administrator.
Все базы и схемы настраиваются единожды для каждого проекта, представляя собой репозиторий хранения групп пользователей, баз требований RequisitePro, баз изменений ClearQuest и тестовых данных. При создании базы следует выбрать ее тип и схему. Схема нужна для того, чтобы определить, по каким правилам и с какими продуктами будет работать база ClearQuest. В идеальном случае можно воспользоваться схемой ENTERPRISE для получения базы, способной работать с любой программой из комплекта поставки Rational Suite Enterprise (более подробно о схемах читайте в первой части данной статьи, а также в следующей статье). В нашем случае для тестового примера была выбрана схема Test, а в качестве СУБД - MS Access (так как создание файлов mdb не требует установки самого продукта).
За время существования ошибки она проходит несколько стадий, от "начальной" (представленной), до "закрытой", когда дефект исправлен. Ценность ClearQuest состоит в том, что он имеет ряд предустановленных состояний ошибок (дефектов), а также предоставляет возможность компании вносить любое число возможных состояний и именовать их в соответствии со сложившимся корпоративным стандартом (смотрите описание CQ Designer).
Рассмотрим основные этапы нахождения и прохождения ошибки через проект:
1. Начальный (представлено). Вводится человеком, который обнаружил ошибку. Здесь следует отметить, что ошибку может представить любой участник проекта. Это может быть служба технической поддержки, которая принимает нарекания по телефону, и должна как-то документировать свою деятельность.
При помощи специальных механизмов, встроенных в CQ, представить ошибку может и сам заказчик (например, через Web-доступ). Еще, как вариант, можно встроить в конечный программный продукт "обратную связь" через электронную почту, когда найденный дефект в работе автоматически (по согласованию с пользователем) отправляется на сервер дефектов, где входит в состав базы дефектов.
2. Назначено. По RUP предполагается наличие роли, действием которой, является просмотр и назначение представленных дефектов на конкретного исполнителя. Обычно это руководитель группы разработчиков или тестировщиков.
3. Открыто. Данный статус начинается с момента реализации (редактирования) исполнителем ошибки. При этом, если говорить о связи CQ с ClearCase, можно отметить, что в базе CQ будет отражено имя файла (или файлов), номер версии и имя разработчика, который начал исправление дефекта. Это очень интересный момент, так как работа над одной ошибкой часто приводит к изменению в нескольких файлах исходного текста;
4. Реализовано.Выход от разработчика. Данное состояние ошибка получает тогда, когда разработчик закончил ее исправление. Ее можно считать сигналом для тестировщиков.
5. Протестировано.Это состояние свидетельствует о том, что версия протестирована. При совместной работе CQ и CC каждую версию сопровождает атрибут, на основании которого строится следующий релиз (продвигается базовая линия). Для того чтобы получить релиз, тестировщик помечает исправленную версию (ставит атрибут "tested"). Интегратор, просматривая атрибуты, делает новый релиз на основе проставленной метки.
6. Закрыто. Финальный этап. Отмечается после отправки версии клиенту.
Существует два способа документирования дефектов - ручной ввод (выполняется непосредственно из среды ClearQuest) и автоматический (CQ вызывается автоматически из средств тестирования Rational). Это значит, что если продукт выпущен в коммерческую эксплуатацию, а сама компания создала службу технической поддержки, то все ошибки, связанные с работой программы, может документировать служба техподдержки, а менеджер проекта может назначать конкретные лица на исправление тех или иных ошибок.
Как видите, способов взаимодействия очень много, и как любой сложный инструмент, CQ требует в первую очередь решения организационно-методических проблем, то есть в компании должны определиться участники команды, и соответствующие им роли: один исправляет, другой вносит, третий контролирует. Без организационных решений будет сложно настроить подобную систему с четко выверенной структурой.
Здесь отображено главное окно CQ, поделенное на три части: дерево запросов (отображает список проектных запросов), список дефектов (для текущего запроса) и состояние
Рисунок 1 показывает фрагмент окна с запущенным CQ.
В данном окне через интерфейс мы можем построить новый запрос на изменение, новую гистограмму о состоянии проекта (число ошибок) и новый отчет.
Единица представления информации в CQ - это дефект (defect). Все участники проекта изъясняются только на языке дефектов. Сам по себе дефект связан с определенной ошибкой в программной системе, либо может описать более глубокую особенность системы. С дефектами можно связать следующие атрибуты (смотрите рисунки 2 и 3):
ID. Идентификационный код дефекта. Назначается автоматически;
State. Текущий статус дефекта (закрыт, в работе, назначен.... и т.д.);
Headline. Комментарий к дефекту. В зависимости от используемых средств тестирования заполняется автоматически или вручную;
RA. Ассоциация с проектом (репозиторием);
Priority. Приоритет дефекта. Заполняется вручную менеджером проекта;
Severity. Строгость, критичность дефекта. На данном этапе можно, например, определить дефект как нестрогий и исправить в последнюю очередь, либо в последующей версии продукта;
Owner. Владелец дефекта. Здесь следует отметить такую особенность: CQ имеет два контрольных поля - Submitter и Owner. Причем первое поле содержит имя пользователя, под которым была активизирована ошибка, а под вторым заводится владелец ошибки – тот, кому нужно исправить. В идеальном случае имена пользователей могут совпадать, то есть когда разработчик сам исправляет свои же ошибки).
Поле владельца может изменять любой участник проекта без ограничений;
Keyword. Набор ключевых слов для дефекта. В качестве ключевых слов часто выносят ассоциации с номерами ошибок, выданными компилятором;
Symptoms. Признак воздействия дефекта (Cosmetic Flaw, Data Corruption, Data Loss, Slow Performance... и так далее). В поле заносится ассоциация с результатом воздействия дефекта на приложение или систему. Список симптомов являет собой часть корпоративного стандарта на тестирование и разрабатывается на этапе определения требований;
Description. Описание проблемы. Если поле Headline необходимо заполнять строго в соответствии с корпоративным стандартом во избежание двусмысленности, то поле описания насыщается произвольным образом. При совместной работе со средствами тестирования и это поле может быть заполнено автоматически;
Resolution. Заключение о разрешении проблемы (fixed/nofixed). Выставляется при завершении работы над дефектом (или при смене статуса);
Attachment.Сюда можно присоединить любой документ (например, код программы или документ);
History. История документирования изменений дефекта (см. рис 2). Генерируется автоматически, показывая список участников проекта, редактировавших данный дефект;
Рис. 2. Отображает историю изменений данного дефекта. Как видно из рисунка, в истории хранятся не только дата и время редактирования, но и тип
TestData. (рис. 3) Определенный набор сопроводительных артефактов (логи, билды...). Поля заполняются при автоматизированном тестировании Robot’ом и TestManager’ом;
Демонстрация ассоциации со скриптами и средой средств автоматизированного тестирования
Environment. Среда сопровождения. Здесь можно определить тип операционной системы, тип процессора, где был найден дефект. Заполняется вручную;
Requirements. Здесь можно задать связку дефекта с требованием из RequisitePro. Данная связь необходима для документирования сложных ошибок, таких как, противоречие начальным требованиям. Например, разработчик реализовал компонент "кнопка" круглой, а в требованиях на интерфейс указано, что она прямоугольная.
Такое противоречие должно быть документировано;
ClearCase. Это поле появляется при правильно настроенной интеграции с данным инструментом. Показывает список версий файлов, которые были редактированы (получены/изменены) в результате исправления данного дефекта;
Над имеющимися дефектами можно произвести четыре действия (actions): modify, reopen, duplicate и delete.
По своей природе CQ является прослойкой между средствами тестирования, участником проекта и физической базой данных (в нашем случае Access). Любые изменения, внесенные в CQ, мгновенно сохраняются в физической базе. Это дополнительный "плюс", так как если руководителю проекта не хватит изобразительных возможностей по отчетности, то всегда можно обратиться напрямую к базе, сформировав SQL-запрос. Рисунки 4 и 5 показывают сформированные таблицы в Access.
Список таблиц созданной базы в Access
Если посмотреть на CQ в разрезе обоснованности его применения в командной разработке, то получится, что продукт представляет собой достаточно интересный и полезный инструмент для четкого отслеживания происходящего в проекте.
Для лучшей управляемости проекта необходимо административным образом распределить роли участников проекта. Действительно, ClearQuest позволит закрыть собой многие "проектные дыры" только в том случае, когда в компании строго определены роли участников, когда каждый из них отвечает за свой сегмент проводимых работ. Необходимо это сделать в силу многих причин, но одна, пожалуй, самая важная - это гибкая подстройка инструмента под конкретные цели конкретной организации вообще, и под конкретный проект в частности. Соответственно, подобная гибкость требует четкой иерархической структуры команды и определенных правил, во избежание ненужных действий.
Для CQ необходимо решить, кто из участников проекта имеет право на поручение (перепоручение) исправления дефектов (например, менеджер проекта или начальник отдела тестирования), поскольку если все будут иметь право на внесение изменений, то контроль за дефектами будет очень усложнен и запутан.
Информацию о проблеме распределения ролей и взгляд Rational на эту проблему можно узнать из статьи документации (в начале статьи описан типичный сценарий внесений дефекта с распределением ролей).
Фрагмент таблицы "Defect" со списком дефектов из рис. 1
