Управління тестуванням, розробкою та конфігурацією на основі Rational Change Request Management, Різне, Програмування, статті

Зміст



Введення


Ідея написати цю статтю в стилі “Follow Me” прийшла в голову після листів, що прийшли на мою адресу після публікації двох статей про технології Rational Software (Засоби тестування додатків для розробників. Інструменти від компанії Rational Software) і ClearCase – Система конфігураційного і версійність контролю. Сенс листів зводився до того, що побудувати за технологіями Rational Software базу з тестування і конфігурації можливо, тільки от зв’язати все це воєдино непросто, і вже тим більше не можна на основі описаних продуктів говорити про яку б то не було керованості з точки зору керівництва компанії. Звичайно ж, докір вірний, але технології Rational Software хороші тим, що будь-який їхній сегмент можна розглядати як окремо, так і як частина великої мозаїки. Склавши таку мозаїку, ви отримаєте повністю кероване виробництво, на вході якого можна подати ідею, а на виході отримати сучасний програмний продукт. Сам процес розробки при цьому буде схожий на виробничий конвеєр, де все тече, працює і підкоряється строго встановленими правилами, де кожен учасник проекту знає, що йому робити, і завдання від учасника до учасника передаються не на словах, а за допомогою спеціальних засобів; відповідно, при такій передачі повинна створюватися певна база даних, в якій і буде зберігатися історія проектів, – такий собі репозиторій проекту. Всі вищеописані проблеми може вирішити Rational Unified Process(RUP) – інтерактивна енциклопедія з побудови якісного процесу випуску програмного забезпечення.


Розгляд RUP ми почали зі коштів тестування для розробників, а продовжили конфігураційним управлінням. Сьогодні ми коротко розглянемо програмний продукт, який зможе зв’язати в єдиний ланцюжок розробників, фахівців з тестування та їх керівників. Ім’я даного продукту – Rational ClearQuest.


Що дадуть проекту CRM і ClearQuest?


Як відомо, знання – сила. А на сьогодні нам відомо, що чим більше проект, тим менш він керований. Як бачите, залежність тут обернено пропорційна. Погодьтеся, що співробітник, тестує продукт, повинен мати інструмент, який дозволить описати будь-яку знайдену в продукті помилку, розробник повинен, використовуючи відомості, отримані від групи тестування, виправити модуль, де знайдена помилка, а керівник, в свою чергу, повинен знати, по-перше, хто і чим у даний момент зайнятий, а по-друге, яка кількість помилок і якого роду супроводжують ту чи іншу версію проекту.


Проблема до болю знайома, і кожна компанія вирішує її по-своєму, винаходячи часом те, що вже є і працює … Давайте подивимося, що пропонує Rational.


ClearQuest – Це засіб управління запитами на зміну (Change Request Management – CRM), Спеціально розроблене з урахуванням динамічної і складної структури процесу розробки ПЗ. ClearQuest призначений для відстеження та управління будь-яким типом дій, що призводить до змін протягом всього життєвого циклу продукту, допомагаючи тим самим створювати якісне ПЗ більш передбачуваним чином.


ClearQuest являє собою багатомодульним додаток, який власними коштами створює базу даних проекту і заносить в неї всі зміни. Він підтримує СУБД провідних виробників, зокрема Oracle, Microsoft і Sybase.


Сенс роботи продукту простий і прозаїчний. Основна інформаційна одиниця – дефект – це знайдена помилка в продукті або опис якоїсь його особливості. Дефект заноситься в систему користувачем, який виявив його. У кожного дефекту є певний набір станів, по яких керівництво може як відстежити історію проекту, так і оцінити поточний стан справ.


Станів у дефектів всього п’ять. “Подано” (Submitted) – опис дефекту щойно внесено; “Призначено” (Assigned) – опис передано певного співробітника. Початок роботи над запитом переводить його в “Відкрите” стан (Open), і вся команда може бачити, що хтось обробляє запит. Нарешті, коли запит перевірений і закритий, він проходить відповідно стадії “Перевірка” (Verify) і “Закрито” (Resolved).


Стани здатні вказати лише на статус того чи іншого дефекту, а ось прискіпливо описати його допоможуть лише спеціалізовані поля. Будь дефект містить певну кількість описових полів, причому якщо використовувати ClearQuest спільно із засобами тестування, то при виявленні помилки дані продукти самі заповнюють всі необхідні поля. Щоб ви не порахували автозаповнення недоліком системи, скажу, що поряд з автозаповненням в ClearQuest передбачено і ручне внесення опису дефектів в систему, при якому вся відповідальність за подану інформацію лежить на операторі.


Отже, дефект отримує ідентифікаційний номер і набір описових даних. Ось короткий список того, що можна передати в якості опису до дефекту.


State – поточний статус дефекту (закритий, відкритий, в роботі …).


ID – ідентифікаційний код дефекту. Впливати на це значення користувач не може, оскільки система присвоює номер автоматично.


Headline – коментар до дефекту. У разі ручного введення дається користувачем самостійно. При автоматичної інтеграції заповнюється автоматично програмою, що виявила дефект.


RA – асоціація з проектом (репозитарієм). Необхідна для асоціації дефекту з вимогою до системи.


Priority – пріоритет виправлення дефекту. Цей параметр можна змінювати по ходу проекту.


Severity – критичність дефекту. Тобто на першому етапі дефект можна визначити як некритичний і виправити в останню чергу або в подальшій версії. Цей параметр також можна змінювати по ходу проекту.


Owner – власник дефекту. Тут слід відзначити таку особливість: ClearQuest має два контрольні поля – Submitter і Owner. Причому перше поле містить ім’я користувача, який активізував помилку, а друге – ім’я користувача, який повинен цю помилку виправити.


Keyword – набір ключових слів для даного дефекту. Спеціальний механізм, що дозволяє конкретної компанії вводити в ужиток свій набір помилок і приводити їх у стан асоціативного зв’язку з помилкою в ClearQuest.


Symptoms – ознака дефекту (Cosmetic Flaw, Data Corruption, Data Loss, Slow Performance … і т.д.). Заздалегідь визначені типи.


Description – опис проблеми, коментар.


Resolution – спосіб розв’язання проблеми (fixed / nofixed).


Attachment – сюди можна приєднати будь-який документ (скажімо, код програми).


History – історія внесення змін до дефекті.


TestData – певний набір супровідних документів. Заповнюється або вручну, або автоматично засобами тестування.


Environment – середа супроводу. Тут можна визначити тип операційної системи, тип процесора, при яких проявляється дефект.


Requirements – тут можна задати зв’язок дефекту з вимогою з RequisitePro.


ClearCase – Зв’язок дефекту з конкретною версією файлу. Даний модуль з’являється тільки при правильному налаштуванні ClearQuest і ClearCase (Див. нижче).


На рис. 1 показано діалогове вікно, що виникає при введенні або зміні дефекту. Як бачите, вікно включає велику кількість закладок, переважна більшість яких вже описано вище.


Рис. 1. Внесення нового дефекту

Отже, подивимося, що дасть ClearQuest кожному учаснику проекту:



Починаємо працювати з ClearQuest


Тут ми опишемо механізм, за допомогою якого можна “змусити” працювати ClearQuest. Природно, що докладний опис виходить за рамки цієї статті, але спробуємо зробити це коротко. Отже, найбільш простий спосіб підготувати проектну основу і сконфігурувати її – використовувати Rational Administartor, що дозволяє за допомогою декількох кроків майстра повністю підготувати проект. Тут воєдино зв’язуються метадані для тестування, а також вимоги до системи, за якими потім тестувальники створять низькорівневий план тестування, згенерують скрипт тестування, базу ClearQuest і приєднають модель з Rational Rose.


На етапі створення бази необхідно вказати тип формату бази даних і місце розташування генерується файлу (для прикладів я використовував MS Access), А також тип схеми, за якою вона буде будуватися. Число доступних схем – приблизно 7-8, але може змінюватись разом з новими версіями продукту. З основних схем хочеться відзначити Enterprise і DefectTracing . Перша передбачає набір правил, за якими схема буде працювати з усіма продуктами, так чи інакше описаними в RUP. Друга призначена тільки для використання можливостей документування дефектів. Ми вибираємо схему Enterprise, задаємо логічне ім’я бази. На останньому кроці створюємо користувачів та групи, а також описуємо права доступу.


Тепер необхідно запустити ClearQuest і провести ще ряд дій, створити запит Query (правила створення запитів однакові для всіх баз даних, і тут ми їх не розглядаємо) і нарешті, спробувати зареєструвати дефект.


Ми виконали тільки основні кроки з отримання бази даних. Але їх досить, щоб створити працюючий CRM.


ClearQuest та засоби тестування


Як говорилося в одній з моїх попередніх статей (Засоби тестування додатків для розробників. Інструменти від компанії Rational Software), Rational має два типи засобів тестування: для розробників і тестувальників. Хоча залежність тут не жорстка, та й ролі учасників конкретного проекту можуть варіюватися.


З усіма засобами ClearQuest починає працювати, як тільки створена база даних. Відмінності від продукту до продукту полягають тільки в способі заповнення полів. ClearQuest викликається автоматично, при натисканні правої клавіші на описі тієї чи іншої помилки.


Тут хочеться звернути вашу увагу ось на що: ClearQuest не може сам в автоматичному режимі занести всі помилки, виявлені засобами тестування, – цим має займатися людина. Іншими словами, розробник може вносити, а може і не вносити опис дефекту. Звичайно передбачається, що розробник повинен тільки виправляти помилки і неточності, на які йому вказують тестувальники. Природно, з цим можна посперечатися, але продукт дозволить застосувати будь-який підхід. За вами – вибір, відповідний традиціям, що склалися у вашій компанії.


Як вже говорилося вище, засоби тестування самі здатні заповнити супровідні поля. Якщо такий засіб, як Rational Purify, Здатне дати лише заголовок помилки, то Rational Robot може вже заповнювати поля згідно з тим, який скрипт в якій версії знайшов ту чи іншу помилку. Тестувальник для отримання повної картини тестування залишиться тільки задокументувати тип процесора, тип системи і описати, з якими з сторонніх програмних засобів, проводилося спільне тестування. Само собою зрозуміло, що всі проблеми зі зберігання таких даних візьме на себе ClearQuest.


Побудувати ж графік по помилках або зробити вибірку за певними операційним системам здатний будь-який, хто хоч раз працював з базами даних.


Отже, тестувальники отримують інструмент архівації відомостей про всі дефекти, здатний провести аналіз інформації по заданим критеріям.


ClearCase і ClearQuest


Даний набір продуктів дозволяє розробникам не просто виправляти певні версії файлів, виводячи їх для цього в стан Check-out, а й асоціювати те чи інше виправлення у відповідності з тими дефектами, які описані в системі. Уявний сам по собі простим, даний механізм допоможе витягти з проекту всю інформацію по помилках і змінам, що призвело до їх виправлення або до породження нових. Всю інформацію можна отримати подібно підняття виноградної грона за верхівку, розглядаючи її з різних боків!


Тут ховається перший підводний камінь – Rational пропонує для вирішення проблем з “change set” дві методики: UCM (Unified Code Management) і ClearCase Base. Про достоїнства кожної з них ми поговоримо в одній з наступних статей, а зараз зупинимося тільки ось на чому: UCM пропонує універсальний підхід і містить в собі правила швидкої побудови проектів встановленого зразка. UCM вже визначив всі ролі і дії, а також здійснив інтеграцію ClеarCase з ClearQuest. UCM – Це спроба Rational здійснити уніфікований підхід до тестування. Але в гонитві за універсальністю UCM втратив ряд важливих рис, головна з яких – гнучка настройка під конкретний процес. Тим Проте, UCM розвивається, поліпшується, але для великих компаній зі складною інфраструктурою поки не зовсім придатний. Тому ми розглянемо варіант інтеграції ClearCase Base з уже сконфігурованої базою в ClearQuest.


Спочатку проведемо інтеграцію, а потім поговоримо про концепцію.


“Впровадження” продуктів один в одного – процес двосторонній. Спочатку ClearCase налаштовується за допомогою модуля ClearCase ClearQuest Integration. У вікні необхідно вказати, з яким VOB буде проведена інтеграція, і які операції будуть потрапляти в базу. Наприклад, можна зробити так, що в базу будуть потрапляти тільки дії check-out, пов’язані з гілкою DEBUG, і так далі (рис. 2).


Рис. 2. Діалог інтеграції ClearCase. Зліва – список VOB, а в центрі – типи запитів. Тут можна відзначити, що інтеграція з боку ClearCase проходить на рівні інсталяції в VOB тригерів, що викликають ClearQuest

Тобто тут ми налаштовуємо реакцію ClearCase на ту чи іншу подію. Відповідним чином для кожної події буде викликатися список дефектів з ClearQuest, з якими потрібно проводити асоціацію.


Але цього налаштування мало. Тепер схему ClearQuest необхідно “навчити розуміти” події ClearCase. Робиться це в такий спосіб:



  1. Запускається ClearQuest Designer.
  2. Завантажується схема, за якою була згенерована база даних.
  3. Через меню Package підключається інтеграція з ClearCase.
  4. Схема зберігається.
  5. Робиться оновлення бази.

Тепер, як тільки користувач дасть команду CheckOUT, ClearCase не тільки попросить прокоментувати дії, а й запропонує вказати асоціацію з певним дефектом в базі ClearQuest. Значить, можна дізнатися, які версії в ClearCase були породжені тієї чи іншої помилкою.


Асоціативні зв’язки можуть бути двох типів:



  1. Один файл, кілька проасоціювали дефектів.
  2. Кілька дефектів на основі одного файлу.

Діалогове вікно, що містить асоціації, відображує на рис. 3.


Рис. 3. Дане вікно викликається кожного разу при виникненні зазначеного в СС події. Тут користувач асоціює породження нової версії з існуючим дефектом, або створює новий

Отже, ми отримуємо наступний алгоритм розробки програмного забезпечення:


1. Розробник створює працюючий код.
2. Тестувальник (або розробник) виявляє помилку:



a. заносить опис помилки (defect) в базу даних;


b. вносить тип помилки і її критичність;


c. призначає відповідального.


3. Розробник виправляє помилку:



a. відшукує в базі модуль і дефект;


b. виводить відповідний файл в стан CheckOut і асоціює його з одним або декількома дефектами;


c. виправляє помилку і позначає її як виправлену (fixed).


4. Керівник проекту отримує повну статистику про наявність помилок в проекті, ступеня їх локалізації та критичності.


Висновок


Отже, при створенні великих проектів мати в своєму розпорядженні тільки інструменти тестування і конфігураційного управління в нинішніх умовах розробки програмного забезпечення вже недостатньо. Необхідно використовувати не тільки індивідуальні засоби розробки, а й засоби і технології колективної роботи.


Контролювати проект і об’єднувати між собою тестувальників та розробників допоможе саме Rational ClearQuest.


Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*