Redakcja testerzy.pl
Niska efektywność transformacji DevOps rzadko jest uwarunkowana brakami w zapleczu narzędziowym. Główną przyczyną pozostaje powierzchowność wdrożenia, polegająca na wymianie technologii i redefinicji procesów przy jednoczesnym zachowaniu dotychczasowych nawyków wykonawczych. Optymalizacja operacyjna w duchu DevOps wymaga restrukturyzacji pięciu płaszczyzn określonych akronimem CALMS:
- kultury współpracy (ang. culture),
- automatyzacji procesów (automation),
- szczupłości procesu (lean),
- pomiarów (measurement),
- dzielenia się wiedzą (sharing).
Geneza CALMS
Model CALMS, wprowadzony szerzej w książce The DevOps Handbook, jest ramami koncepcyjnymi wskazującymi zmiany organizacyjne niezbędne do skutecznego wdrożenia DevOps. Skupiają się one przede wszystkim na kulturze pracy i ludzkich nawykach, zamiast koncentrować się na kwestiach czysto sprzętowych. Znajomość modelu pozwala precyzyjnie określić i uargumentować zadania zespołu do spraw zapewnienia jakości na wczesnych etapach projektu, zamiast ograniczać jego rolę do końcowej weryfikacji przedwdrożeniowej.
Istnieją też warianty tego skrótu. Przykładem jest wersja CALMR, obecna w metodyce SAFe, która rozszerza ten podział o czynnik odtwarzania środowiska po błędzie (ang. recovery).
Autorzy sylabusa ISTQB® CT-QDO wskazują CALMS jako jedną z podstaw wiedzy oczekiwanej od testera. Poniższe informacje pokazują, jaki wkład wnosi zespół QA w każdy z tych pięciu wymiarów.
Kultura współpracy (Culture)
Sylabus definiuje ten model jako ewolucję Agile, dającą zespołom autonomię w realizacji celów przy jednoczesnym eliminowaniu barier komunikacyjnych z innymi pionami.
W tym modelu odpowiedzialność za jakość rozkłada się równomiernie na wszystkich członków zespołu, eliminując w ten sposób sytuację, w której testowanie jest procesem zewnętrznym. Wymusza to zmianę roli testera, który angażuje się w proces jeszcze przed powstaniem kodu, poprzez uczestnictwo w przeglądach, weryfikacje wymagań pod kątem testowalności oraz identyfikację ryzyka. Takie działanie zastępuje tradycyjną, końcową bramkę kontrolną podejściem prewencyjnym, ukierunkowanym na zapobieganie defektom.
Automatyzacja procesów (Automation)
Ten obszar skupia się na automatyzacji procesów budowania, wdrażania, konfiguracji infrastruktury, analizy statycznej kodu oraz testów dynamicznych. Zgodnie z sylabusem nadrzędną zasadą jest traktowanie tych elementów jako kodu (everything as code). Przeniesienie tych operacji do potoku CI/CD pozwala na ciągłe dostarczanie małych pakietów zmian i skraca pętlę sprzężenia zwrotnego przy zachowaniu wymaganej jakości.
Dla testera oznacza to natychmiastowy dostęp do wyników weryfikacji po każdej modyfikacji kodu, co zapobiega kumulacji defektów i obniża koszty ich naprawy. Trzeba jednak zaznaczyć, że automatyzacja nie eliminuje testów manualnych. Badanie użyteczności, testy eksploracyjne czy analiza kontekstowa zachowania systemu wciąż wymagają interwencji testera.
Szczupłość procesu (Lean)
Założeniem jest tu upraszczanie cyklu wytwórczego i usuwanie kroków bezproduktywnych. Wymóg ciągłego doskonalenia procesów dotyczy w tym samym stopniu działań z zakresu zapewnienia jakości. Dla zespołu testerskiego wiąże się to z koniecznością skonstruowania procesu w taki sposób, aby nie stanowił on blokady dla potoku wdrożeniowego. Trwające wiele godzin testy regresyjne, wykonywane przy każdej próbie wydania, bezpośrednio generują przestoje. Aby temu zapobiec, stosuje się mechanizmy takie jak kategoryzacja testów na warstwy, wykonywanie współbieżne, zawężanie zakresu testów do obszarów dotkniętych zmianą czy wcześniejsze uruchamianie konkretnych sprawdzeń. Rolą zespołu zapewnienia jakości jest zabezpieczenie stabilności systemu bez jednoczesnego opóźniania wydań.
Pomiar (Measurement)
Pomiary umożliwiają zbieranie faktów o zachowaniu aplikacji w produkcji oraz o sprawności całego procesu deweloperskiego. Podstawą tego podejścia są mierzalne i dające możliwość działania wskaźniki efektywności oraz jakości, które służą do ciągłego doskonalenia procedur.
W dziedzinie zapewnienia jakości przekłada się to na eliminację domysłów na rzecz argumentacji popartej danymi. Intuicyjne założenie, że dany komponent zawiera więcej defektów, zastępowane jest przez statystykę ich gęstości i trendy czasowe, a wrażenie długiej egzekucji testów – przez precyzyjne logowanie czasu działania CI/CD. Autorzy sylabusa rozbudowują ten aspekt w sekcji poświęconej wskaźnikom DORA, służącym do ewaluacji tempa dostarczania zmian i niezawodności systemów.
Dzielenie się wiedzą (Sharing)
Ostatni wymiar dotyczy budowania kultury otwartej dyskusji o problemach i sukcesach projektowych oraz systematycznego wdrażania dobrych praktyk. Proces ten wspiera ciągłe podnoszenie kwalifikacji i optymalizację działań całego zespołu.
W tym schemacie pracownicy odpowiedzialni za zapewnienie jakości realizują funkcję podwójną – odbiorcy oraz twórcy zasobów informacyjnych. Krytycznym wkładem ze strony testera jest feedback z automatycznych procesów walidacji, precyzujący poziom testowalności architektury i poprawności biznesowej kodu. Metryki z wykonania skryptów, rejestry incydentów o wysokiej powtarzalności oraz analizy technicznych blokad wdrożeniowych stanowią bezpośredni wkład w standaryzację pracy zespołu. Pozycja działu QA ewoluuje z pasywnego konsumenta specyfikacji do aktywnego dostawcy danych technicznych.
Podsumowanie
Poszczególne elementy ramy CALMS traktować trzeba nie jako niezależne procedury, ale jako komplementarny model zapewnienia jakości w całym procesie deweloperskim. Ich prawidłowe wdrożenie pozwala na przyspieszenie wydań oprogramowania i redukcję błędów produkcyjnych. Zmiana kulturowa włącza pracowników odpowiedzialnych za jakość w bezpośrednie struktury zespołu, automatyzacja znacznie przyspiesza feedback, eliminacja marnotrawstwa zapobiega blokowaniu potoku wdrożeniowego przez testy, metryki zastępują intuicję faktami, a współdzielenie informacji przekształca pojedyncze wnioski we wspólne zasoby techniczne.
