Відстеження проектів тестування за допомогою віртуального порталу статусу: розширення можливостей Rational ClearCase і Web, Різне, Програмування, статті

Зміст



У будь-якому проекті тестування необхідно йти на компроміс між часом на управління тестуванням, тобто часом, витраченим на планування тестів, документування їх результатів і відстеження просування проекту, і часом на безпосереднє тестування програмного продукту. Коли групи тестування знаходяться в географічно віддалених місцях розташування, проблема ускладнюється. Саме з цієї причини моя група технічного забезпечення якості 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), запропонована Джеймсом Бахом в своєму експериментальному методі тестування (www.satisfice.com).


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


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


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


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


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

Рис. 3. Web-сторінка віртуальної електронної дошки


У більш ранню реалізацію документів з технічного забезпечення якості входила інформація про розклад і статус, закодована в рядках з тегом, який при генерації звіту міг розпізнаватися сценарієм Perl. Було прийнято рішення використовувати ту ж стратегію для електронної дошки. У верхній частині кожного контрольного списку був доданий ряд рядків з тегами, що містять інформацію електронної дошки. Рядки, помічені “+ + +” і ключовим словом, можна було не тільки легко витягти і проаналізувати за допомогою сценарію, а й прочитати співробітникам (див. рис. 4).

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


У кожному контрольному списку містяться теги для інформації, показаної на електронній дошці:



На додаток до цих рядках з тегами рівня контрольного списку існує рядок “+ + + 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.


Додаткова інформація



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


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

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

Ваш отзыв

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

*

*