Передовий досвід управління тестуванням на базі IBM Rational ClearQuest, IBM Rational ClearCase і IBM Rational Requisite Pro, Комерція, Різне, статті

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


Що таке управління тестуванням?


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



Більш масштабне тестування може використовувати доморощені програмні рішення, зазвичай побудовані на основі електронних таблиць або баз даних, або комерційні програми, такі як IBM Rational ClearQuest Test Manager або Mercury TestDirector.


Загальна мета управління тестуванням повинна дозволяти групам розробників планувати, розробляти, виконувати і оцінювати всю діяльність з тестування в загальному процесі розробки програмного забезпечення. Сюди відносяться заходи по координації всіх дій, залучених в процес тестування, відстеження залежностей та взаємовідносин між тестовими активами (test assets) і, найважливіше, визначення, вимір і відстеження показників якості.


Аспекти управління тестуванням

Управління тестуванням може бути розбите на різні фази: організація, планування, авторинг, виконання та складання звітності. Нижче ці фази розглядаються більш детально.


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



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


Авторінг тестування являє собою процес визначення конкретних кроків, необхідних для завершення даного тесту. Цей процес вирішує питання, як щось буде тестуватися. Саме тут якісь абстрактні тестові приклади розвиваються в більш докладні кроки тестування, які, в свою чергу, стануть тестовими сценаріями (test scripts) (або ручними, або автоматизованими).


Виконання тестування тягне за собою запуск тестів шляхом об’єднання послідовностей тестових сценаріїв в набір тестів. Це продовження відповіді на питання, як тестувати (більш конкретно, як провести тестування).


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


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


Найтиповіші генеруються при тестуванні дані, які часто служать джерелом для показників якості, – це дефекти. Дефекти не є статичними, а змінюються в часі. Крім того, деякі дефекти часто пов’язані один з одним. Ефективне відстеження дефектів має вирішальне значення як для груп тестування, так і для груп розробників.


Інші фактори в управлінні тестуванням


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


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


Пов’язані дисципліни розробки програмного забезпечення


Хоча всі дисципліни в розробці програмного забезпечення мають відношення до дисципліни тестування, деякі з них особливо важливі для тестування:



Управління вимогами – Це попередник великого обсягу робіт з тестування, що забезпечує значну кількість мотивацій для тестування і вимог для перевірки. Процес управління конкретними вимогами до проекту може мати вирішальний вплив на процес управління тестуванням. Однією з аналогій цього взаємозв’язку може бути естафета, де перший бігун представляє управління вимогами, а наступний бігун, який отримує естафетну паличку, представляє управління тестуванням. IBM ® Rational ® RequisitePro ® є інструментальним засобом для пошуку, документування, організації та відстеження вимог.


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


Управління конфігураціями важливо для управління тестуванням через стеження за тим, які складання в який час необхідно тестувати. Управління конфігураціями контролює складання, а також середовища, відслідковують системою управління тестами для виконання тестування. IBM ® Rational ® ClearCase ® є провідним інструментальним засобом управління конфігураціями. Додаткова інформація наведена на сторінці продукту IBM ® developerWorks ® Clearcase.


Проблема управління тестуванням

Одним із способів підвести підсумок виконання завдань управління тестуванням є відповідь на наступні питання:



Хоча це може виглядати досить зрозумілим на високому рівні, існує багато перешкод, які часто виникають в типовому процесі розробки програмного забезпечення. Ці проблеми описуються нижче.


Недостатньо часу для тестування


За винятком деяких спеціалізованих або дуже відповідальних додатків, дуже мало програмних проектів мають достатню кількість часу в життєвому циклі розробки, для того щоб досягти високого рівня якості. Дуже часто майже неминучі затримки в програмному проекті переносяться на і так короткий “цикл тестування”. Навіть найкращі проекти, дуже ймовірно, мають жорсткі тимчасові обмеження на виконання тестування. Результатами цієї перешкоди для управління тестуванням є постійно мінливі пріоритети і перемикання завдань, а також зменшений обсяг даних для результатів тестування і показників якості.


Недостатньо ресурсів для тестування


Крім нестачі часу дуже часто складно одержати потрібні ресурси, доступні для виконання необхідних робіт з тестування. Ресурси можуть спільно використовуватися іншими задачами або іншими проектами. У той час як апаратні ресурси для тестування можуть додати затримки і труднощі, проблему нестачі людських ресурсів може бути навіть ще важче вирішити. Результати цієї перешкоди для управління тестуванням приблизно такі ж, як і для тимчасових обмежень.


Група тестування не завжди розташована в одному місці


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


Труднощі з вимогами


Хоча існує багато стратегій тестування, перевірка коректності вимог зазвичай має головний, найвищий пріоритет при тестуванні, яке має бути завершено. Це вимагає наявності повних, недвозначних і придатних для тестування вимог. Управління не цілком точними вимогами може привести до більш серйозних проблем при виконанні тестування. Використання такого інструментального засобу як RequisitePro може значно поліпшити управління вимогами, а також сприяє розробці хороших вимог.


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


Збереження синхронізації з процесом розробки


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


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


Складання звітів з коректною інформацією


Робота з тестування корисна лише тоді, коли можна висловити стан тестування і деякі показники якості проекту. Генерування звітів є досить простою процедурою, але уявити коректну інформацію (в потрібний час і всім зацікавленим особам) може бути складніше, ніж здається, з кількох причин:



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


Що таке показники якості?


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


Рекомендації з управління тестуванням

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


Починайте роботу з управління тестуванням якомога раніше


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


Тестуйте в ітеративному режимі


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


Повторне використання тестових артефактів


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


Використовуйте тестування, засноване на вимогах


Тестування може бути розділене на два загальних підходи:



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


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


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


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


Використовуйте ресурси віддаленого тестування


Для пом’якшення впливу нестачі ресурсів або просто для максимізації використання персоналу ви повинні скористатися будь-якими ресурсами, які є у вашому розпорядженні, незалежно від їх місця розташування. В даний час ресурси можуть бути розподілені географічно (часто з різних континентах). Це вимагає ретельного й ефективного координування для отримання максимальної віддачі від віддалено розташованих тестувальників та інших людей, залучених в управління тестуванням. Тут можуть існувати значні технічні труднощі, а тому необхідні відповідні інструментальні засоби. Можливості управління тестуванням в ClearQuest з MultiSite є засобом, що спрощує координування при географічно розподіленому тестуванні.


Потрібно використовувати Web-клієнт або автоматично реплицируемой дані? Це два доступних рішення, які роблять можливим спільну роботу віддалених виконавців. Перше є легким і щодо простим, але існує потенційне обмеження – час реакції мережі, особливо при доступі до різних куточках земної кулі. Для віддаленого доступу обмеженого числа користувачів або для обмеженої функціональності це хороше рішення. Однак для ситуацій з великою кількістю людей, що знаходяться в різних місцях і формують загальну віртуальну групу тестувальників, вам знадобиться мати копії даних на локальних серверах для максимізації швидкості роботи. Це також означає, що вам знадобиться простий і цілісний спосіб автоматичної синхронізації даних у всіх розташування. Ось тут можна використовувати ClearQuest MultiSite для управління тестуванням.


Визначення та виконання гнучкого процесу тестування


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


Визначення процесу з потоками робіт для управління членами групи не дає так вже й багато переваг, якщо не можна змусити будь-яким чином йому слідувати. Наскільки жорстко це робити, залежить від організації і проекту. Програмні проекти в багатьох організаціях в даний час повинні підкорятися різним положенням, наприклад, SOX і HIPPA. Деякі вимагають контрольованості змін, ведення історії проекту та інші жорсткі перевірки відповідності, такі як електронні підписи (e-signatures). Незалежно від того, вимагає управління тестуванням вашого проекту строгого проходження процесу, або використовує більш безсистемний підхід, вам потрібен механізм для визначення і здійснення чого-небудь. Одним з таких інструментів управління тестуванням, що забезпечує всі ці можливості, є ClearQuest.


Координація та інтеграція з іншими етапами розробки


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


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


Стан обміну інформацією


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


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


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


Фокусуйтеся на показниках і результатах


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


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


Автоматизуйте для економії часу


Управління тестуванням – це великий процес, а його численні завдання можуть бути дуже трудомісткими. Щоб заощадити час можна застосувати інструментальні засоби для автоматизації, або, по крайней мірою, часткової автоматизації багатьох завдань. Хоча прості інструментальні засоби, такі як текстові редактори й електронні таблиці, забезпечують хорошу гнучкість, спеціалізовані засоби автоматизації тестування більше призначені для цього і забезпечують відмінні можливості заощадити час. До завдань, які значно виграють при їх автоматизації, відносяться:



Спеціалізовані інструментальні засоби та автоматизація потрібних завдань в управлінні тестуванням значно підвищить його цінність і вигоди.


Резюме

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


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


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

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


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

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

Ваш отзыв

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

*

*