Borland SilkTest для підтримки створення програмного забезпечення за методикою Agile, Різне, Програмування, статті

Все більше і більше компаній переходять на гнучкі (Agile) методи розробки програмного забезпечення (ПО). Але методологія Agile приносить із собою новий ряд складнощів. Серед них автоматизація функціонального тестування: в співтоваристві Agile думки про корисність автоматизованого тестування розходяться. Однак реальність така, що групи розробників ПО повинні управляти якістю, якщо вони повинні уникати операційних ризиків. Організації заохочуються у впровадженні процесів Agile, які підходять для їх унікальних вимог. Ніщо, що відноситься до Agile, не є визначеним або обов’язковим. Тому немає нічого дивного, що організації знаходять проблематичним впровадження методології Agile в якості надійного бізнес-процесу. Використання процесу створення ПЗ на базі методології Agile – це ще одна змінна, яка ускладнює рішення, які вони повинні приймати.

Автоматизація та створення ПО за методологією Agile

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


Незалежно від того, чи розглядає ваш колектив розробників перехід на Agile, знаходиться в процесі переходу або вже працює по цій методології, важливо продумати, як технологія може підтримувати цей новий спосіб роботи – особливо в області тестування. Згідно з дослідженням компанії Forrester, “в гнучких (agile) процесах є місце для покращення – наприклад, за допомогою поліпшення підтримки методології Agile з боку основних інструментів для автоматизації тестів, управління тестами та управління вимогами “. Forrester зауважує, що в процесах Agile тестування є безперервним і обов’язковим, оскільки можливості не вважаються “готовими” до тих пір, поки не пройдуть всі пов’язані з ними контрольні приклади. Більше того: “Через регресійної навантаження тестування має бути максимально автоматизованим (І обгрунтованим) “. Організації, які впроваджують Agile, стикаються з наступними проблемами.



Роль автоматизованого тестування у розробці за методологією Agile


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


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



Необхідність швидкості: прискорення процесу створення коду та тестування за допомогою швидких і автоматизованих сценаріїв тестування


Автоматизація дозволяє фахівцям з тестування створювати прості сценарії для багаторазового використання. Ці сценарії можна розгортати для економії часу і поліпшення уніфікації тестування для подібних побажань користувачів (User Stories), балів Story Points чи вимог щодо одного чи кількох проектах. Ці сценарії, розроблені на базі User Story для поліпшення функціональних можливостей, можна швидко і багаторазово запускати, що забезпечує розробку на основі тестів (Test Driven Development). Такий підхід значно знижує робоче навантаження на фахівців з тестування і виключає необхідність “марафонів” з тестування, що проводяться пізніми ночами і у вихідні і здатних вимотати групу.



Необхідність повторюваності: виконання тих же тестів і сценаріїв тестування з правильними критеріями придатності


Регресійне тестування вимагає, щоб: 1) ви виконували ті ж тести кожен раз при тестуванні певної частини коду, 2) щоб сценарій тесту складався щодо критеріїв прийнятності для кожного відповідного функціонального вимоги User Story. При кожній зміні коду (або його розширення для включення нової можливості) потрібно перезапускати всі функціональні тести для всіх вимог користувачів аж до останньої зміни. Це потрібно, щоб гарантувати відсутність ненавмисних наслідків для інших функцій. (При розробці за методологією Agile регресійне тестування повинне звичайно виконуватися в кінці кожної ітерації. В деяких випадках це означає щоденне виконання.)


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


Приклад Borland: використання автоматизованого тестування для підтримки створення ПЗ за методологією Agile


У компанії Borland є свій власний досвід корпоративного переходу на Agile. Ми спостерігали важливу роль, яку автоматизоване тестування і централізоване управління тестами можуть грати в забезпеченні успішного переходу. Ми почали свій перехід на підхід Agile в 2006 році. У нас було 350 інженерів, які працювали над широким спектром проектів з розробки ПО в 13 різних офісах по всьому світу.


У переході на Agile ми слідували ітераційний підходу, здійснюючи перехід в одному певному географічному регіоні, а не у всіх відразу. Приблизно більше 60% груп розробників в Borland тепер використовують методики Agile. Всі ці методики підтримуються продуктами Borland ALM, і їх переваги величезні. Проте ми визнаємо спостереження, зроблене компанією Forrester: перехід на Agile може бути для організацій важким через зміни, які потрібно зробити в наступних областях:



За даними Forrester, більшість організацій не готові включити в свої процеси безперервне і итеративное тестування, необхідне для підтримки розробки за методологією Agile. Більш того, в дослідженнях Forrester наголошується, що “в корпоративному контексті зазвичай потрібно робити деякі винятки для тестування з особливо великими вимогами до ресурсів, наприклад, для тестування продуктивності, безпеки, зручності використання, прийнятності для користувачів і приймальне тестування “.3 [GG3]


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



Відправна точка


Як приклад: в нашому офісі розробки в Лінці, Австрія, було три групи розробників, які використовували традиційний “Водоспадний” (waterfall) підхід для розробки рішень для тестування Borland SilkTest . Після деякого аналізу ми вирішили, що в рамках нашого переходу на Agile для кількох груп найважливішим компонентом буде автоматизація інструментальних засобів.


Очевидно, перехід був заснований не тільки на просте можливості використання інструментів – як і для багатьох інших груп, перший крок полягав у визначенні нових ролей, наприклад власника продукту (Product Owner, PO). Основна відповідальність PO полягає в сприянні обміну даними між учасниками процесу з боку бізнесу і технічними фахівцями і в подальшої передачі їх вимог до ПЗ і змін в групи розробки та забезпечення якості. Це підтримувалося за допомогою щоденних нарад (stand-up) з використанням відповідних коштів. Такий підхід забезпечував обмін інформацією та спільну роботу для ВСІХ учасників групи, незалежно від їх реального розташування.


Група в Лінці перейшла на чотиритижневі ітерації. Це дозволило групам розробників зосередитися на менших одиницях роботи – крок вперед до Agile. Група підтримувала User Stories в Borland CaliberRM і оцінювала їх придатність для тестування за допомогою засобів забезпечення якості. User Stories були прив’язані до Borland SilkCentral Test Manager. Це дозволяло групам забезпечення якості розробляти контрольні приклади та пов’язані з ними сценарії автоматизованого функціонального тестування в Borland SilkTest. Результатом став покращений процес спільної роботи, який забезпечив створення високоякісних тестованих вимог (виражених як User Stories). Тепер розробники і фахівці з тестування отримали чіткі вимоги та могли запровадити тестування на більш ранніх стадіях процесу розробки. Це дало їм можливість ефективно забезпечувати розробку на базі тестів і підтримувати відстеження зв’язків між User Stories, кодом, тестами і результатами.


Інтеграція груп тестування для створення повноцінних колективів по розробці ПО


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



Для підтримання стандартів якості та допомоги групам у забезпеченні адекватності тестування ми створили ще одну роль під назвою “наставник по забезпеченню якості” (“QA coach”) – єдиний ресурс, який надає досвід в галузі забезпечення якості для всіх трьох груп. Під керівництвом наставника щодо забезпечення якості (і за допомогою SCTM для організації і планування сценаріїв, а також за допомогою StarTeam для їх зберігання і контролю їх версій) люди змогли виконувати свої ролі більш ефективно, спільно використовуючи і багато разів застосовуючи сценарії Borland SilkTest у всіх групах.


Вибір правильних засобів для автоматизації тестів


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


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


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


На противагу цьому, завдяки своєму безпосередньому досвіду переходу на Agile ми гарантуємо, що продукти Borland Silk можуть допомогти впровадити і поліпшити процес створення ПЗ на базі Agile. Одночасно забезпечується якість, скорочуються ризики і знижуються витрати. Засоби тестування Borland використовуються в тисячах організацій по всьому світу. Ці кошти можуть підтримувати будь-який процес розробки – Agile або традиційний. Їх можна налаштувати на підтримку бажаних процесів будь-якої групи розробників. Ці кошти також дозволяють колективам впроваджувати автоматизоване тестування – швидке, відтворюване і точне. А оскільки вони є частиною інтегрованого пакета засобів для відкритого управління життєвим циклом додатків (Application Lifecycle Management, ALM), який підтримує тестування на базі вимог та управління якістю в життєвому циклі, групи розробників не працюють в ізоляції. У кожного в організації є інформація про процес створення ПЗ на базі методик Agile, і кожен може відповідним чином брати участь в цьому процесі.


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


SilkTest допомагає цим проектним групам двома дуже подібними шляхами. По-перше, можливість в SilkTest прямого виклику бібліотек DLL всередині сценарію, минаючи користувальницький інтерфейс. Це дозволяє групам закріплювати точки автоматизації в більш конкретних областях застосування. Другий спосіб – через середу SilkTest Silk4J, за допомогою якої зусилля по автоматизації можуть також прив’язуватися до низькорівневих Java-частинам архітектури.


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



Borland SilkTest для створення тестів


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


Borland SilkCentral Test Manager для управління і синхронізації тестів


Borland SilkCentral Test Manager – це потужний засіб для управління тестуванням ПЗ. Воно створено за принципом “все включено” і вбудовує якість і ефективність у процес тестування. Borland SilkCentral Test Manager інтегрується з іншими інструментами і технологіями Borland, а також з інструментами сторонніх виробників для управління життєвим циклом додатків. Ця інтеграція гарантує, що тестування ПО стає керованим процесом, який поширюється на весь життєвий цикл розробки ПО і допомагає забезпечити відповідність пріоритетів бізнесу та розробки.


SilkCentral Test Manager також спрощує верифікаційні тести зборок, що важливо для підтримки розробки за методологією Agile. Кожна група потребує гарантії, що новий код, який вони створюють кожен день, не викличе несподіваних проблем в інших частинах програми. Ці тести, як правило, можна виконати за 2:00 для кожної збірки і для різних конфігурацій, що дозволяє скрам-групі створювати робоче ПО в кінці кожного дня.


Java в якості мови сценаріїв (Java as a Scripting Language)


Borland продовжує розробляти інноваційні підходи до підтримки методології Agile. Наприклад, в якості мови сценаріїв для SilkTest * доданий мову Java (функція Java as a Scripting Language). Така можливість дозволяє розробникам і фахівцям з тестування створювати сценарії для SilkTest на звичному мовою розробки – Java. Це забезпечується через модуль Eclipse, який дозволяє генерувати сценарії і працювати на тому ж мовою, яка використовується для самої розробки. Сценарії створюються і запускаються за допомогою функції Open Agent в SilkTest.


SilkTest і FitNesse


FitNesse надає середовище з відкритим вихідним кодом, яка дозволяє фахівцям з тестування визначати тести на бізнес-рівні (в таблиці), де дії пов’язані з очікуваними результатами. Потім FitNesse ставить вибрані дії та результати у відповідність автоматизованим завданням в SilkTest. Завдяки можливості використання мови Java в якості мови сценаріїв ми створюємо бібліотеки, які посилаються на об’єкти і функціональність, з урахуванням параметрів, визначених у тесті. Аналогічно ми розробляємо процедури верифікації, як і спільно використовувані класи, які також можна використовувати. Більш того, за допомогою Open Agent ми можемо викликати ці сценарії через функції виклику зовнішніх коштів з FitNesse. Що це дає нам в кінцевому підсумку? Можливість для користувачів, які не є технічними фахівцями, розробляти сценарії тестування в веб-браузері або вікі-середовищі (FitNesse). Потім ця середу буде використовувати SilkTest без будь-якої додаткової роботи по створенню сценаріїв для тестового управління додатком і його перевірки. Результати збираються з файлів. RES, створені в SilkTest, і вставляються в браузер FitNesse. * Підтримка та розробка продукту Borland Silk 4Test буде продовжена.

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


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

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

Ваш отзыв

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

*

*