Monitoring jakości systemu w dynamicznie zmieniającym się układzie zależności

29 March, 2017 by Michał Błaszak Continuous delivery
security-camera-1306956-1280x869

Gdy otoczenie biznesowe wymaga od dostawcy oprogramowania działania w coraz krótszych cyklach i połączenia operacyjnego utrzymania systemu z jego ciągłym rozwojem (idea DevOps), kluczowe staje się zminimalizowanie ryzyka związanego z częstą ingerencją w środowisko produkcyjne. Klasyczne podejście do testowania, wypracowane w oparciu o metodyki stosowane w projektach o niskiej dynamice, musi ewoluować do formy monitoringu jakości – stałej kontroli nad stanem systemu, który zmienia się w coraz krótszych interwałach.

Testowanie w procesie ciągłego dostarczania oprogramowania znacząco zyskało na wadze na przestrzeni kilku ostatnich lat. Producenci systemów, w szczególności o globalnym zasięgu, coraz więcej uwagi skupiają na takim podejściu, ponieważ pozwala ono na dostarczenie odbiorcom dodatkowej wartości w bardzo krótkim czasie. Serwisy o ciągłej dostępności dla szerokiego grona użytkowników muszą być stale rozwijane, by móc sprostać rosnącym wymaganiom. Stabilności tych rozwiązań nie da się zatem zbudować poprzez unikanie ich dalszego wzrostu i bez częstego wprowadzania nowych lub ulepszania aktualnych funkcjonalności. Ciągłe testowanie staje się w tych okolicznościach warunkiem koniecznym do wykorzystania potencjału dostarczanego systemu, a pośrednio, zwyżki lub choćby utrzymania pozycji względem konkurencji.

Systemie, nie jesteś sam

Kluczem do sukcesu w podejściu Continuous Delivery jest wprowadzenie, na możliwie szeroką skalę, automatyzacji procesów, które składają się na cykl wytwarzania. W tym, przede wszystkim (choć nie tylko!), procesu ciągłego testowania. Mowa tutaj o testowaniu dostarczanego systemu, ale również jego otoczenia. Ilość zależności aplikacji od siebie nawzajem rośnie w ogromnym tempie. Podejście “system of systems” rozwija się dynamicznie i na ile to możliwe, staramy się maksymalizować benefity wynikające z interakcji wewnątrz ekosystemu aplikacji, które zgodnie z przytoczoną ideą, są większe niż suma wartości jaką zapewniają zaangażowane systemy w odosobnieniu.

Złożone środowisko, w którym funkcjonuje utrzymywana aplikacja, narzuca komunikację (z założenia dwustronną) i wykorzystanie przez nią informacji przetwarzanych przez inne systemy. To powoduje, że poza kontrolą jakości funkcjonalności czy wydajności oprogramowania, musimy również monitorować warstwę komunikacji z elementami otoczenia, od których zależy spełnienie przezeń stawianych mu wymagań biznesowych.

Niedostępność elementów otoczenia w fazie testów

Oprzyjmy się o założenie, że utrzymywany i rozwijany system nie jest zawieszony w pustej przestrzeni, tylko wymaga integracji z aplikacjami, czy bazami danych wokół. W tej sytuacji musimy sprostać wyzwaniu jakie stawia nam ich potencjalna niedostępność, gdy zachodzi potrzeba przeprowadzenia procesu kontrolnego. Wyzwanie to nabiera na sile, gdy weźmiemy pod uwagę jednoczesny nacisk na częstotliwość wykonywania testu oraz rosnącą złożoność rozwiązania i ilość komponentów wchodzących z nim w interakcję.

Powodów negatywnego wyniku testu komunikacji z zewnętrznym elementem może być kilka. Zazwyczaj jest to błąd zewnętrznego systemu lub jego niedostępność z powodu awarii, czy okna serwisowego. Często również mamy do czynienia z ograniczeniem uprawnień. Najciekawszą w kontekście dynamicznego rozwoju i jednocześnie często pomijaną w założeniach kwestią jest jednak brak możliwości wymiany danych z powiązanym systemem, ponieważ nie zdążył on zostać dostosowany do nowych wymagań lub – w skrajnym przypadku – jeszcze nie powstał! Jak zatem zaadresować takie ryzyko?

Zorkiestrowana wirtualizacja serwisów

Kluczem w zautomatyzowanym podejściu do kontroli jakości jest zapewnienie dostępności wszystkich elementów niezbędnych do tego, by wynik testu prezentował stan rzeczywisty poddanego testowi komponentu, celem podjęcia decyzji, czy jest on gotowy na implementację w środowisku produkcyjnym. Celowo wspominam o stanie rzeczywistym, a nie o wymuszonym stanie gotowości, ponieważ potencjalna decyzja o wstrzymaniu zmiany jest absolutnie akceptowalna, gdy w grę wchodzi uszczerbek na wizerunku organizacji wdrażającej modyfikację. Tutaj pojawia się konieczność spojrzenia na zagadnienie z dwóch różnych perspektyw:

  • Przede wszystkim, w oparciu o teorię symulacji, znając założenia techniczne (oby jak najczęściej dokładną specyfikację) warstwy komunikacji, oraz kierując się podejściem, że testujemy tak wcześnie, jak to tylko możliwe, skupiamy się na zwirtualizowaniu serwisów, od których zależy spełnienie przez tworzoną aplikację założeń biznesowych. Możemy wtedy z powodzeniem testować nawet, gdy wymagana wymiana danych z zewnętrznym systemem jest tymczasowo zakłócona z powodów uzasadnionych w kontekście operacyjnym, także tych trywialnych, jak choćby przerwa techniczna, czy chwilowe problemy z połączeniem sieciowym pomiędzy środowiskami.
  • Testować należy też jednak ścieżki naturalne, nie poddane wirtualizacji, aby móc możliwie szybko wychwycić potencjalne zagrożenia wynikające z braku implementacji symulowanego rozwiązania. W skrócie: Wiemy, że system ma dać konkretną odpowiedź. Zatem symulujemy ją, po czym okazuje się, że pomimo pozytywnego wyniku testu, realnie nie nastąpiło wdrożenie symulowanej funkcjonalności na czas, więc udostępnienie doatarczanego kodu produkcyjnie skończy się fiaskiem.

Wniosek jest prosty – wirtualizujmy serwisy, od których zależy spełnienie wymagań biznesowych. Ale jednocześnie kontrolujmy stan implementacji powiązanych komponentów przed wdrożeniem finalnego rozwiązania.

Odwrócenie dwóch piramid

W podejściu DevOps, a w zasadzie DevTestOps – nazwa ta nie bierze się znikąd, bowiem podkreśla nacisk na proces ciągłego testowania jako czynności kluczowej – bardzo ważne jest, by automatyzować tak dużo, jak to możliwe. Na dzień dzisiejszy wiele organizacji, opierając testowanie na złożonych frameworkach i pisaniu pracochłonnych w utrzymaniu skryptów, jest w stanie zapewnić pokrycie na poziomie 20% wszystkich testów. Pozostawiając Państwa na później z myślą o tym, że spory odsetek portfolio przypadków testowych nie daje wymiernej wartości, skupię uwagę na tym, że już niedługo, przy obecnym tempie rozwoju i wzroście częstotliwości cykli wytwarzania, pokrycie automatami na tym poziomie nie tyle utrudni, co uniemożliwi dostatecznie płynną kontrolę jakości, hamując cały proces. Oczywiście nie da się w pełni wyeliminować eksploracyjnych testów manualnych, ale przy wykorzystaniu odpowiednich narzędzi optymalizujących ilość i jakość przypadków testowych oraz automatyzacji bezskryptowej opartej o modele aplikacji musimy być w stanie wynieść automatyzację na poziom powyżej 80% całego zbioru testów. To jednak nie jedyne miejsce, w którym trendy pokazują odwracanie się proporcji. Same automaty, obecnie skupiające się na testowaniu interfejsów użytkownika będą musiały przenieść swój ciężar na kontrolę jakości API. Takie testy można wykonywać dużo szybciej i o wiele wcześniej w cyklu dostawy. Docelowo powinny one stanowić pakiet większościowy portfolio testowego.

Zmiana biegunów i przeniesienie nacisku na dwóch wspomnianych płaszczyznach, w połączeniu z monitorowaniem stanu otoczenia dostarczanego systemu, pozwoli sprostać wymaganiom stawianym nam przez rynek oprogramowania w erze DevTestOps i spojrzeć dalej w przyszłość, bo ta droga zdaje się nie mieć kresu i z pewnością jest jeszcze pełna nieodkrytych możliwości.

 

Leave a Reply

Your email address will not be published. Required fields are marked *

Contact

Drop us a cord completing the form below or at cord@secorda.com. You can also call us +48 570 640 600