Cnews - 20 червень 2014 року - Олена Ермохіна, Віталій Шульга, EPAM
Інформаційні системи в сучасній компанії сьогодні перетворюються в оркестр. Кожна програма - це окремий інструмент, який може грати як соло (вирішувати певне завдання), так і в складі камерного ансамблю (разом з іншими системами підтримувати наскрізні бізнес-процеси). Різні партії - то виконувані паралельно, то зі зрушенням на кілька тактів - нагадують синхронний і асинхронний режим роботи всього комплексу систем. Для вдалого виступу кожен елемент оркестру повинен грати зовсім, при цьому утворюючи єдине гармонійне звучання з іншими інструментами. Точно також: для успішної роботи інформаційних систем необхідно протестувати як кожен окремий компонент рішень, так і їх роботу разом. На допомогу диригенту-тестувальників приходять засоби автоматизації, використання яких здатне надати свіже звучання навіть класичним мелодіям.
Прискорення темпу: коли автоматизація необхідна
Accelerando, stringendo, stretto - темп і характер сучасного бізнесу з кожним днем змінюються так швидко, що за ними не наздогнати без використання інформаційних технологій. Випуск раз на рік нових версій систем, з якими працюють кінцеві клієнти, вже не годиться для бізнесу. Новий функціонал повинен з'являтися постійно, наприклад, щомісяця. При цьому від його якості залежить дуже багато: на думку аналітиків Forrester, саме ПО стало ключовою точкою взаємодії між клієнтом і компанією, перетворюється в бренд і її «обличчя». Гнучкі методології розробки і практики CI / CD дозволяють випускати новий продукт в ще більш короткі терміни. Наприклад, Facebook пропонує поновлення щотижня. В Amazon пішли ще далі і зробили електронний магазин - свій «продукт» - повністю динамічним: нова версія виходить кожні 11 секунд.
Почастішання релізів і, як наслідок, зменшення тривалості фази тестування спричиняють зміни в розрахунку повернення інвестицій в автоматизацію. При випуску нового релізу 1 раз в 6 місяців вкладатися в автоматизацію неефективно. Так, для кожного оновлення виконується 1 цикл регресії. У типовому випадку автоматизація тестування на рівні користувача інтерфейсу займає в 10 разів більше часу, ніж ручне виконання тих же тестів. Оскільки тести будуть виконуватися 2 рази на рік, нам знадобиться 5 років тільки на те, щоб окупити витрати на автоматизацію тестування. Але за цей час наш продукт зміниться кардинально, що призведе до величезних витрат на підтримку тестів в актуальному стані.
У випадку з 10-12 релізами в рік ми, навпаки, не можемо собі дозволити не інвестувати в автоматизацію і витрачати місяці на регресійне тестування. Автоматизація стає швидкоокупними (потрібен приблизно 1 рік) і життєво необхідною. В результаті вона поступово починає використовуватися на все більшій кількості проектів.
В самі додатки стрімко проникають нові технології. Mobile, Cloud, Big Data, Social, розподілена і модульна архітектура - технології, які швидко набирають популярність і окремо або в комплексі знаходять своє відображення в сучасних рішеннях. Ускладнення програмних продуктів і перехід до модульної і розподіленої архітектурі дозволяють організувати тестування кожного модуля окремо. Такий підхід дає можливість виявляти дефекти раніше і виправляти їх швидше. Можливість перенести тестування на рівень окремих компонентів призводить до зростання кількості Автотест і самого проекту автоматизації.
Покриття додатки тестами, до і після впровадження тестування на рівні модулів.
Перехід від централізованих додатків до модульних і децентралізованим впливає на тестові сценарії. Великі end-to-end сценарії важко піддаються автоматизації, а якщо і піддаються - є нестабільними. У таких випадках вигідно змістити фокус автоматизації на покриття атомарних бізнес-функцій, ніж повного шляху користувача. Через зменшення кількості дій в тест-сценарії час його виконання зменшується. Нарешті, в цьому випадку ідентифікувати помилки і потім усунути їх стає простіше. Тим самим ефект від застосування засобів автоматизації зростає.
Мотиви розробки для кращого звучання
Новим трендом в автоматизації тестування стає запозичення тестувальниками «кращих мелодій» - практик та інструментів - з арсеналу розробників. Якщо в музиці подібне вважали б плагіатом і піддали б остракізму, то в сфері ІТ цей підхід навіть вітається. Відзначимо, що застосування при реалізації проектів джазових імпровізацій - гнучких методологій розробки (Agile) -менять схему взаємодії між розробниками і тестувальниками. Якщо раніше розробка і тестування існували окремо, то тепер це єдина, тісно взаємодіє команда.
Сучасний проект автоматизації містить десятки і сотні тисяч рядків коду і має багаторівневу модульну архітектуру. Підтримувані такого проекту життєво необхідна. Забезпечити її можна за допомогою таких практик розробників, як:
- застосування об'єктно-орієнтованої архітектури проекту (відсутня необхідність використовувати функції для повторюваного коду, функції вже «вмонтовані» в об'єкти »), можливість використовувати стандартні інструменти для збірки і налагодження та підключати додаткові бібліотеки і фреймворки, які входять в використовуваний мову програмування (Java, C # , Python і ін.).
- використання системи контролю версій, коли проект автоматизації зберігається в одному репозиторії з основним продуктом. При цьому якщо раніше в якості інструменту для управління версіями використовувався централізований SVN, то зараз акцент все більше зміщується в бік децентралізованої і розподіленої системи Git.
- застосування патернів проектування розробки і створення нових патернів, наприклад, Page Object патерн в інструменті Selenium Web Driver
- часті перегляд і інспекції коду, застосування coding guidelines.
Одночасно з практиками, фахівці з автоматизації тестування починають використовувати і інструменти розробників. Раніше достатньо було побіжного погляду на монітор співробітника, щоб зрозуміти, хто він-Автоматор-тестувальник або розробник. Зараз розібратися в цьому стало проблематичніше. Тестировщики все частіше відмовляються від звичних продуктів QTP, TestComplete, Silk Test на користь широко поширених, потужних і знайомих кожному розробнику середовищ, як Eclipse або Visual Studio. При автоматизації тестування веб-додатків популярністю користується стек технологій - Java + Selenium + JUnit. Для розширення можливостей проектування, оптимізації роботи з базами даних і веб-сервісами часто застосовуються бібліотеки Spring і Hibernate, які перестали бути виключною прерогативою розробників. Тим самим використання і в розробці, і в тестуванні однакових технологій, мов, інструментів збірки і формування звітів дозволяє прибрати межу між двома процесами і забезпечити їх безшовну інтеграцію.
Нові інструменти для виконання
Свіжі ноти в класичну мелодію автоматизації тестування додає розвиток програмного забезпечення, яке йде в геометричній прогресії. За пару років технологія може народитися, розвинутися і завоювати ринок, як це було у випадку, наприклад, з браузером Google Chrome або операційною системою Android. Як тільки з'являється нова технологія, виникають і інструменти для її тестування, в тому числі нові засоби автоматизації.
Багато інструменти автоматизації, які ми зараз знаємо як вільне програмне забезпечення, починали своє життя в інноваційних компаніях, які використовували ці продукти для тестування власних рішень. Так, Selenium Core був придуманий в Thought Works, a WebDriver - в Google. Рішення поділитися власним продуктом з спільнотою і відкрити його код має ряд переваг. По-перше, це представляє компанію у вигідному світла як інноватора і мецената. По-друге, дозволяє використовувати ресурси світового ІТ-спільноти для виправлення помилок і розробки нового функціоналу.
В результаті бурхливий розвиток інструментів з відкритим вихідним кодом і децентралізованих систем контролю версій відкриває можливості для появи відгалужень від продуктів автоматизації та їх доповнення іншим функціоналом. У поєднанні з безкоштовним хостингом на таких платформах, як github, bitbucket, sourceforge, це призвело до виникнення безлічі невеликих «обгорток» і плагінів для популярних інструментів розробки і автоматизації (наприклад, проект Selenium має більше 300 відгалужень). Можливість публікувати готові рішення і розширення для засобів автоматизації породжує велику кількість готових до роботи фреймворків. Частина таких відгалужень надалі переростає в самостійні продукти і обганяє за популярністю своїх «батьків». Найбільш характерні приклади для автоматизації веб-додатків - Thucydides від Wakaleo Consulting (інтеграція приймальних тестів і звітності з WebDriver) і HtmlElements від Яндекса (розширення паттерна Page Object в WebDriver).
Одним із трендів останнього часу стає той факт, що все частіше маленькі ссавці - рішення з відкритим вихідним кодом - виграють в еволюційної боротьбі у великих динозаврів - комерційних інструментів, навіть незважаючи на те, що відкрите ПЗ, наприклад, висуває більш високі вимоги до технічного рівню фахівців. Як правило, основний фактор успіху вільних ІТ-рішень - це концентрація на вужчих завданнях і здатність їх швидко вирішити з найкращим результатом.
Такий природний відбір особливо добре помітний серед інструментів автоматизації мобільного тестування. Якщо може бути застосовано до тестування веб-додатків визнаним лідером є Selenium WebDriver, то в мобільній сфері явного переможця поки немає. Найбільш явним претендентом на лідерство з середини 2013 року можна назвати рішення Appium. На його користь говорять фактори схожості з лідером близькою сфери Selenium і можливості використання в якості інструменту для тестування і нативних, і гібридних, і веб-додатків, а також крос-платформенность і стабільність роботи інструменту. Але чи може в найближчі півроку відбутися зміна лідера автоматизації мобільного тестування? Цілком: ринок гранично динамічний.
Нарешті, не можна не згадати про ще одну обставину. Зараз бізнес-фахівці починають приймати всі більшу участь в процесі розробки і тестування ПО, оскільки при високій частоті релізів необхідно не менше часто визначати набір змін, який буде реалізований в новій версії продукту. Тісна взаємодія бізнесу і розробників промислового ПО призвело до виникнення нової методології розробки та тестування програмного забезпечення - Behavior-driven development. Вона передбачає, що бізнес-фахівці надають вимоги до ІТ-рішення в спеціальному форматі Gherkin language, який однаково добре читається як людиною, так і фреймворком. В результаті для створення нового автотеста немає необхідності вносити зміни в код - достатньо лише передати фреймворку нову специфікацію в форматі Gherkin. При застосуванні цієї методології нові Автотест створюються бізнес-аналітиками, що дозволяє знизити ризик втрати інформації при комунікаціях між замовником і виконавцем і мінімізувати витрати на розробку і тестування.
практичне виконання
Тенденції, про які ми говорили вище, добре ілюструються прикладом з практичного досвіду одного з замовників EPAM Systems - системи замовлення подорожей через Інтернет. Це рішення розробляється десятками команд по всьому світу. Його простий протягом декількох годин означає для власників бізнесу втрати мільйонів доларів втраченого прибутку. Нові версії системи виходять щомісяця.
Важливою частиною поставки кожного оновленого компонента рішення є автоматизовані тести. При автоматизації використовуються ті ж технології, що і при розробці системи - Java, Spring, Hibernate, JUnit, що полегшує процес. Випробування проводяться на декількох рівнях (юніт-, компонентні і end-to-end тести), причому всі вони автоматизовані. Збірка і тестування нової версії проводиться в автоматичному режимі по коммітов (запис змін в репозиторій) в систему версионного контролю. Для керуванням інтеграцією використовується система Jenkins.
В цілому процес тестування виглядає наступним чином:
- Відбувається Комміт змін в систему контролю версій
- Проводиться статичний аналіз і інспекція коду Автотест
- Сервер безперервної інтеграції виділяє машину для тестів і готує оточення
- При необхідності створюються заглушки нижчестоящих і вищих рівнів, щоб ізолювати тестований компонент від інших модулів
- Запускається група Автотест. Запуск можна зробити як ізольованим (з заглушками інших компонентів), так і серед реальних модулів. Виконання Автотест йде паралельно в кілька потоків.
- У разі успішного виконання тестів компонент переходить на сервер тестування інтеграції, де виконуються регресивні тести, end-to-end сценарії і негативні ручні тести.
- При успішній інтеграції компонентів випускається нова версія продукту.
Тестування збірки займає не більше години, завдяки чому в день в середньому виходить близько 4-х збірок.
цикл тестування
Мелодія автоматизації тестування активно набирає силу і збагачується все новими мотивами. Ускладнення програмних продуктів і перехід до модульної і розподіленої архітектурі дозволяють організувати тестування кожного модуля системи або рішення окремо, що дає можливість скоротити терміни проведення тестування. Застосовувані розробниками інструменти і практики все більше «перетікають» в сферу тестування, що допомагає фахівцям з обох сторін працювати в єдиній команді і підвищує ефективність як тестування, так і розробки. Поява нових технологій породжує нові інструменти автоматизації, найяскравіший приклад - Appium зі сфери автоматизації тестування мобільних додатків. Комерційні продукти автоматизації все більше поступаються місцем під сонцем вільного ПЗ. У виграші від цього залишаються компанії-замовники: оркестр їх інформаційних систем в результаті звучить злагоджено і гармонійно.
оригінал публікації
Але чи може в найближчі півроку відбутися зміна лідера автоматизації мобільного тестування?