Този сайт използва бисквитки (cookies). Ако желаете можете да научите повече тук. Разбрах

Новини ИТ мениджмънт
бр. 3, 2018

Agile и DevOps водят със себе си автоматизираното тестване

от , 27 март 2018 0 613 прочитания,

IDG, САЩ

Промените при плащанията създават много възможности за банките. За да се възползват от тях, те трябва да гарантират, че проектите за трансформирането на системите им са приложени правилно и сигурно. Всеки аспект от внедряването на технологиите – включително процесът на тестване – трябва да бъде пригоден към дигиталната ера.

Agile и DevOps водят със себе си автоматизираното тестване


Ръчните тестове са източник на разходи и риск
Според световния доклад по качеството (World Quality Report) на Capgemini за 2017 основните пет фактора, които допринасят за увеличаването на бюджетите за тестове са: по-голям брой разработки (52%); преминаване към Agile и DevOps подходи, които водят до повтаряне на тестовете (41%); повече предизвикателства, свързани с тестовата среда (36%); компаниите изискват по-високо качество на ИТ (33%); откриване на повече дефекти, което налага провеждането на по-дълги тестови цикли (31%).
Предстоят да бъдат направени още проверки, но както докладът на Capgemini показва, нивото на автоматизацията е под 30%, което означава, че твърде много дейности се извършват ръчно. Така се пропиляват много часове, тъй като служителите трябва да чакат за получаване достъп до устройствата или схемите, за да приключат работата си. Същевременно загубите се увеличават и заради допълнителното време, необходимо за рестартиране на хардуерната и софтуерната среда. Автоматизацията може да намали тези загуби и да позволи на множество екипи да извършват тестове паралелно.
Като цяло подходите при ръчната работа са остарели и не се вписват в процеса на дигитализацията. По-важното обаче е, че ако банките не предприемат промени, те рискуват да изостанат от своите нови конкуренти и да не успеят да отговорят на нуждите на все по-претенциозните потребители.
Освен това ръчните процеси са трудни за скалиране, тъй като при разрешаването на какъвто и да било проблем винаги има усложняване, неефективност и по-високи разходи за мениджмънт.
Не на последно място, банките не могат да подобрят новите техники за проверка, използвайки ръчния подход. Исторически тестовете почти винаги са били необходими при приключването на един проект. Лидерите очакват от своите екипи да им гарантират успех и да ги уверят, че новата технология работи и е готова да се прилага. По-модерните подходи поставят фокуса си не само върху това, че софтуерът работи, но и върху изпитването на самата система, за да идентифицират и елиминират нейните слаби места. В една автоматизирана среда това по-лесно се случва, тъй като тя осигурява много повече възможности. Тестовете са последователни, могат да бъдат провеждани бързо и по няколко пъти с много по-малки разходи, а резултатите не трябва да бъдат интерпретирани от служителите.
С други думи, автоматизираните тестове са значително по-ефективни от ръчните такива. Това означава, че чрез тях фирмите ще могат не само да получат повече от своите ИТ инвестиции, но и ще извършват самите тестове по един по-безопасен начин. Ако финансовите институции не извършват тестовете по адекватен начин, се увеличава рискът за това на пазара да бъде пуснато неработещо решение за плащания. Вследствие на това нараства опасността от накърняване на репутацията на организацията, а проблемът може бързо да се разрасне чрез социалните медии.

Предизвикателствата: наследени и сложни системи
Платежният отрасъл се трансформира, увеличавайки сигурността, скоростта и ефективността на транзакциите. Без съмнение обаче тези промени ще отнемат време. Преминаването от наследените системи към новите технологии е едно значително предизвикателство, което често води до забавяне при спазване на сроковете.
Развиващите се стандарти, собствените интерфейси и формати, криптографията, еволюцията на новите съобщения и тоукъни, както и зачестилите случаи на измами добавят нови слоеве на сложност, които трябва да бъдат управлявани и контролирани.
Като цяло платежните системи се развиха и сега в тях се наблюдават повече взаимозависимости. Те трябва да бъдат тествани в различни комбинации, а всеки компонент трябва да остане устойчив в случай на неизправност.
С други думи, заради съществуването на тези взаимозависимости вече не е достатъчно да се тестват елементите на платежните процеси индивидуално и по групи. Цикълът за плащания инкорпорира всички аспекти от платежния процес – от инициирането до съгласието, а тестовите среди трябва да имат капацитета и способностите да извършват тестовете сякаш са в реалния свят.
Това на свой ред показва и необходимост да не се изостава от изискванията на регулациите. Постоянният цикъл на задължителни промени, наложени от нормативните актове, се очаква да продължи да бъде ключова характеристика на индустрията за финансови услуги и в бъдеще. От гледна точка на тестването това създава потребност от лесно достъпен начин за записване какви промени са били направени, за да се отговори на регулаторните изисквания, и защо.
За да бъдат спазвани законите обаче, трябва да могат да се провеждат регресивни тестове. Дори малки промени в платежните системи мога да създадат проблеми. Същевременно организациите често предполагат, че няма да се стигне до трудности и затова само на думи отделят средства за проверки. Банките трябва да имат набор от регресивни елементи, които да пускат срещу системата всеки път, когато бъдат направени промени.
Очаква се платежните системи да увеличат сложността си заради Втората директива за платежните услуги. Финансовите институции ще разкрият множество отворени API, за да позволят на другите играчи да интегрират своите услуги. Първата стъпка е при разплащанията, но през следващите няколко години това трябва да обхване и други допълнителни банкови услуги.
След като отворените API бъдат включени, използването на други методи за интеграция може би ще намалее, но едва ли това ще се случи веднага. Отворените API представляват важна възможност за банките да предложат нови услуги, нови екосистеми и нови бизнес модели, увеличавайки още повече сложността на платежните системи. Те също така ще засилят нуждата да се заменят ръчните подходи, с автоматизирани техники за тестване.

Agile и DevOps водят със себе си автоматизираното тестване

Гъвкавият подход: нож с две остриета
Голямата скорост, с която се променя процесът на плащанията, води до прилагането на Agile и DevOps методологии. Изследване, публикувано в началото на 2017 от Vanson Bourne, установява, че компаниите за финансови услуги приемат DevOps подходи по-бързо и с по-голяма решимост спрямо фирмите в другите индустрии. Според проучването 45% от организациите за финансови услуги вече са приели подобен подход, а при останалите индустрии, сред които са търговията на дребно, медиите и софтуерният сектор, едва 32%.
Същевременно докладът от 2017 State of Testing – най-голямото изследване относно извършването на проверки, с повече от 1600 участници от над 60 държави – разкрива, че все повече се приема гъвкавият подход. Почти 87% от запитаните са отговорили, че работят с Agile методологии (82% през миналата година). Анкетата показва още, че приемането на DevOps е ясна тенденция, потвърдена от 26% от участниците тази година (спрямо 23% през миналата година и едва 14% през 2015).
Изследването посочва, че броят на служителите, работещи с традиционния (Waterfall) подход, е намалял от 39% на 37% (а преди две години е бил 42%). Това е доказателство, че традиционните модели за разработване, на които изчислителната индустрия разчиташе от края на 70-те години, се променят. Този старомоден линеен подход към управлението на проекти осигурява здрава рамка, в която всеки елемент зависи от завършването на предходния. Въпреки изместването на фокуса от Waterfall подхода и макар че не е подходящ при по-чести промени на софтуера, той продължава да се прилага.
Новите начини на работа – Agile, DevOps и постоянното развитие – са свързани с увеличаващите се изчислителни мощности и по-големите изисквания към отделите по разработване. При тях се намаляват циклите за разработване, което води до по-бързо създаване на софтуерните елементи. Това значително увеличава възможностите за пускане и обновяване на кода, както и налага нуждата от нов начин за тестване. Проверката се превръща в ключова част от целия процес, а не е само допълнителна стъпка или просто механизъм за тестване дали отделни части на кода работят.
С други думи, имайки предвид ориентирането към Agile и DevOps, въпросът не е дали да се премине към автоматично тестване, а кога ще се случи това. Фирмите няма да могат да останат в крак с тенденциите, ако не въведат автоматизирани процеси.

Автоматизацията намалява риска
При съставянето на стратегиите за тестовете важно място трябва да заеме принципът за опростяването на процесите. В противен случай има опасност тестовите среди да станат по-сложни от платежните. В този контекст виртуализацията е важна, тъй като позволява създаването на консистентност, стандартизирана среда, намалени ресурсни ограничения и позволява консолидация на уменията – а всичко това води до по-голяма ефективност.
Изграждането на множество виртуални образи на една система дава възможност всички нива на проверка да протичат паралелно. Всеки инженер или група от инженери имат достъп до своя собствена виртуална система, без да се засягат тестовете на другите. Виртуализацията осигурява симулация на реалния свят, без невъзможно високите цени за работа с множество огледални образи.
Стратегията трябва да очертае процесите, които да бъдат автоматизирани, как това ще бъде направено, как тестовите активи ще бъдат поддържани и какви са очакваните разходи и ползи. Автоматизацията не заменя необходимостта от добро планиране или писане на тестови сценарии. Това, което обаче тя прави, е да предлага възможността за повторно използване на тестовите активи и улеснява миграцията от наследените платформи към тези от следващо поколение.
Основно изискване е да се преосмисли начинът, по който се управляват съществуващите тестови активи, включително симулаторите и данните. Умен подход е да се създаде тестови хъб, който да замени различните набори от компоненти, работещи поотделно.

КОМЕНТАРИ ОТ  

Полезни страници
    За нас | Аудитория | Реклама | Контакти | Общи условия | Декларация за поверителност | Политика за бисквитки |
    Действителни собственици на настоящото издание са Иво Георгиев Прокопиев и Теодор Иванов Захов