Dostarczanie nowego oprogramowania z zachowaniem jego wysokiej jakości wyzwaniem usługodawców

/var/folders/g1/7y68lygx3ng5gnrrkm0dx14m0000gn/T/com.microsoft.Word/WebArchiveCopyPasteTempFiles/iStock-861122930-300x200.jpgTestowanie w procesie ciągłego dostarczania oprogramowania jest obecnie jednym z najczęściej poruszanych tematów w obszarze zapewnienia jakości. Dostawcy systemów i aplikacji coraz częściej decydują się na zastosowanie w procesie produkcji filozofii i narzędzi z obszaru Continuous Delivery / Continuous Integration, by w możliwie krótkim czasie dostarczać nowe wartości biznesowe.

Usługi wykorzystujące oprogramowanie o ciągłej dostępności dla szerokiego grona użytkowników muszą być stale rozwijane, by móc sprostać rosnącym wymaganiom klientów. Rynek wymaga od dostawców oprogramowania działania w coraz krótszych cyklach i połączenia operacyjnego utrzymania systemu z rozbudową jego funkcjonalności, więc dodatkowym ryzykiem do zaadresowania staje się o wiele częstsza niż w klasycznych metodykach wytwarzania oprogramowania ingerencja w środowisko produkcyjne. W takich realiach ciągłe testowanie pośrednio wpływa na utrzymanie pozycji rynkowej, pozwalając na wykorzystanie potencjału biznesowego dostarczanego rozwiązania w dynamicznym i wysoce konkurencyjnym otoczeniu.

Czynnikiem istotnie wpływającym na wykorzystanie potencjału Continuous Delivery jest wprowadzenie, na możliwie szeroką skalę, automatyzacji na wszystkich etapach procesu wytwarzania. Jedną z takich składowych jest zagadnienie ciągłego testowania, które w przedstawionych realiach nie sprowadza się jedynie do sprawdzenia poprawności implementacji (duże pole do automatyzacji testów regresji), wzbogaconej o poszukiwanie błędów (testy eksploracyjne), ale również w zorganizowany sposób umożliwia monitoring otoczenia z którym nasz system wchodzi w interakcję – szczególnie przy wykorzystaniu idei “system of systems”, gdzie dany proces biznesowy realizowany jest z wykorzystaniem większej ilości zależnych od siebie rozwiązań informatycznych.

Coraz rzadziej mamy do czynienia z rozwiązaniami działającymi w odosobnieniu. W takim wypadku należy monitorować złożone środowisko i rozbudowaną warstwę komunikacji testowanej aplikacji z elementami otoczenia, z którymi tworzy ona swoisty ekosystem. Zakładając, że utrzymywany i rozwijany system nie jest zawieszony w pustej przestrzeni, tylko wymaga integracji z innymi aplikacjami, czy zewnętrznymi źródłami danych, musimy sprostać wyzwaniu jakie stawia nam ich potencjalna niedostępność, gdy zachodzi potrzeba wykonania testu. Tutaj z pomocą przychodzi wirtualizacja serwisów, która pozwala na wykonanie testu podczas którego punkty styku są symulowane, w przypadku np.:

  • błędu w wywoływanym systemie
  • niedostępności z powodu awarii
  • ograniczenia uprawnień
  • gdy komponent z którym się komunikujemy jeszcze nie powstał, ale już znamy jego specyfikację.

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ę, tego typu podejście może się okazać nieodzowne, by możliwe było zachowanie ciągłości prowadzonych prac rozwojowych.

Powszechnie wiadomo, że fundamentem podejścia Agile i DevOps jest możliwość szybkiej reakcji na zmiany. Łatwo zaobserwować metamorfozę w sposobach wytwarzania i zarządzania, umożliwiającą dostarczanie innowacyjnego oprogramowania szybciej niż dotąd. Omawiany właśnie proces testowania oprogramowania wydaje się często pomijany, mimo licznych przekształceń w organizacjach. Według różnych badań, 70%-88% firm przyjęło przynajmniej w pewnym stopniu zwinne podejście do wytwarzania oprogramowania, podczas gdy zaledwie 26%-30% z nich zaimplementowało na szeroką skalę automatyzację testów.

W podejściu DevTestOps – używając tej nazwy podkreślam nacisk na proces ciągłego testowania jako czynności kluczowej – kluczowa jest automatyzacja testów zapewniająca możliwie wysokie pokrycie ryzyka biznesowego testowanej aplikacji. Mimo rozwoju technologii i metodyk wspierających taką automatyzację w nurcie testowania opartego o model (ang. Model-Based Testing), wiele organizacji nadal bazuje w tym obszarze na złożonych frameworkach i pisaniu pracochłonnych w utrzymaniu skryptów, nierzadko nie będąc w stanie zapewnić pokrycia testami automatycznymi na poziomie nawet 20-30%. Jeśli dodamy do tego fakt, że spory odsetek portfolio przypadków testowych w organizacjach nie jest zoptymalizowany i nie daje wymiernej wartości, to przy obecnym tempie rozwoju i wzroście częstotliwości i skróceniu długości cykli wytwarzania, pokrycie automatami na tak niskim poziomie uniemożliwi dostatecznie płynną kontrolę jakości, hamując cały proces dostaw wersji oprogramowania. Oczywiście nie da się w pełni wyeliminować testów manualnych – wręcz przeciwnie, testy eksploracyjne powinny być obowiązkowym uzupełnieniem dla innych aktywności QA – ale z wykorzystaniem odpowiednich narzędzi optymalizujących ilość i jakość przypadków testowych oraz przy zastosowaniu automatyzacji bezskryptowej, opartej o modele aplikacji, możemy podnieść poziom pokrycia automatami powyżej 80% całego zbioru testów.

Inną kwestią, jeśli mowa o odwróceniu proporcji jest możliwość zwiększenia nacisku na testy API względem testów interfejsów użytkownika. Takie testy można bowiem wykonywać dużo szybciej i o wiele wcześniej w cyklu wytwórczym. Docelowo powinny one stanowić pakiet większościowy portfolio testowego, a zestaw testów funkcjonalnych UI powinien być regularnie poddawany weryfikacji i optymalizacji pod kątem wartości poszczególnych przypadków testowych, objawiającej się w pokryciu ryzyka biznesowego testowanych funkcjonalności.

Zmiana tych proporcji, zarówno na płaszczyźnie testy manualne / testy automatyczne, jak i testy UI / testy API, będąca efektem zastosowania procesów i narzędzi spójnie adresujących wszystkie aspekty kontroli jakości i wpisujących się w nurt ciągłego dostarczania, pozwoli sprostać wysokim wymaganiom stawianym przez rynek oprogramowania funkcjonujący w duchu DevOps.