Testowanie w (Biz)DevOps

Bogdan Bereza
Bogdan Bereza

Spis treści

Motto

W kilku rozmowach pojawiła się opinia, że BizDevOps i zakładane przez tę koncepcję przejście na mikro-usługi pozwala zrezygnować z testowania regresyjnego.

BizDevOps, DevOps, mikro-usługi

Kilka dni temu w pewnej grupie na fejsbuku, zajmującej się tematyką fotografii gastronomicznej, padło pytanie: „czy używacie do zdjęć potraw obiektywów makro?”. W odpowiedzi ktoś napisał, że tak, nawet z 300-milimetrową ogniskową… i zaczął się musical nieporozumień (1). Tak samo jest z pytaniem, czy BizDevOps pozwala zrezygnować z testowania regresyjnego.

Testowanie regresyjne oznacza, że po zmianie w oprogramowaniu (2) testuje się nie tylko samą zmianę, ale rozmaite inne obszary, na które podejrzewamy, że ta zmiana mogła wpłynąć. Takie podejrzenie – obawa wynika z jednego albo dwóch powodów:

A. Architektury oprogramowania takiej, że zmiana kawałka programu może spowodować nieoczekiwane skutki w działaniu innego kawałka,

B. … albo struktury wymagań takiej, gdzie wymagania są ze sobą powiązane.

Przykładem sytuacji „A” jest mój hydrofor, mający około 40 lat. Jeśli strzeli mi korek na tej fazie, do której podłączony jest hydrofor, po naprawieniu awarii prądu schodzę jeszcze do piwnicy i sprawdzam, czy hydrofor ruszył (jeśli nie, to mu pomagam), bo – z powodu zanieczyszczonych styków – czasem tego nie robi. Tak więc generalnie oprogramowanie o poplątanej, bałaganiarskiej architekturze, albo po prostu takie, gdzie architektury nie znamy i obawiamy się, że jest kiepska – takie oprogramowanie rodzi potrzebę szerszego zakresu testów regresji.

W tym sensie architektura oprogramowania typu SOA (3) rzeczywiście pozwala na zmniejszenie zakresu testów regresji – ale nie na rezygnację z nich!

Przykładem sytuacji „B” jest nasza kuchnia, w której zwykle ja panuję niepodzielnie, ale od czasu do czasu – na przykład teraz, przed Wielkanocą – władzę na krótko przejmuje Żona, biorąc się za tworzenie zaawansowanych wypieków. Wówczas moje ustawienie naczyń i sprzętu jest niedogodne, więc Żona je modyfikuje, a te zmiany są dla mnie z kolei niedogodne, kiedy życie wraca do post-świątecznej normy. Rozwiązaniem takiej struktury interesariuszy i ich sprzecznych potrzeb byłyby oczywiście dwie osobne kuchnie, co pozwoliłoby nam na kuchenny DevOps… albo musimy się dwa-trzy razy do roku męczyć z przestawianiem i zaakceptować, że DevOps (ani BizDevOps) nie mamy.

Odpowiedź 1: architektura SOA zmniejsza zalecany zakres testów regresji

Architektura SOA, jak każda architektura stosująca hermetyzację (ang. encapsulation), ma zapewniać brak wpływu wewnętrznej implementacji funkcji – metody – serwisu na działanie tego serwisu. Czyli, przetestowawszy odpowiednio zmodyfikowany mikro-serwis, nie ma już potrzeby wykonywania testów regresji wszystkich możliwych jego zastosowań.

Czy wobec tego zmiana w systemie, którego funkcjonalność realizowana jest przez mikro-serwisy, też nie wymaga testów regresji? To zależy już od jego struktury, na ile są w niej zaszyte różne zależności.

Trzeba też pamiętać, że o ile architektura SOA może faktycznie zmniejszyć potrzebny zakres testów funkcjonalnych, o tyle wpływa wręcz przeciwnie na wymogi regresji testów niefunkcjonalnych, związanych z przeniesieniem złożoności z poziomu usług na poziom ich relacji, opóźnień sieciowych itd.

Odpowiedź 2: BizDevOps nie zmniejsza potrzeby testów regresji związanej z zależnościami wymagań

Aby pokazać, co przez to rozumiem, opowiem na przykładzie, zamiast silić się na opis ogólny – pełniejszy, ale trudniejszy do zrozumienia.

Często – zgodnie z praktyką – pokazuje się powiązanie modeli wymagań i architektury na przykładzie BPMN i SOA. Popatrzmy na dwa prościutkie procesy biznesowe, opisane w BPMN:



Powyżej diagram, pokazujący proces składania i realizacji zamówienia. Zapewne, właściwe będzie stworzenie jednej usługi (mikro-usługi) dla każdego z zadań na diagramie (4).

Drugi diagram - poniżej - pokazuje proces wzięcia udziału w zajęciach z tańca i rytmiki.



Okazuje się, że oba procesy mają taką samą strukturę, oraz że – co istotniejsze – w obu znajdują się zadania o tej samej nazwie: „Papierologia” oraz „Fakturowanie”. Po bliższej analizie okazuje się, że „Papierologia” jest tylko taką samą nazwą dla dwóch różnych czynności, ale „Fakturowanie” w jednym i drugim procesie, to identyczne zadanie.

Zdrowy rozsądek i zasady modelowania BPMN jednakowo wskazują, że zalecane jest w tej sytuacji usunięcie zdublowania definicji „Fakturowania” i zastąpienia jej jedną, w formie tak zwanej „czynności wywoływanej” (ang. call activity):



W ten sposób, czynność zdefiniowana tylko w jednym miejscu na diagramach BPMN, może być umieszczana w diagramach wielu procesów. Oczywiście, oznacza to także, że taka czynność jest wręcz wzorcową usługą (lub mikro-usługą), wywoływaną przez wiele różnych aplikacji.

Potem czas mija, diagramy BPMN pokrywają się (wirtualnym) kurzem, realia biznesowe ulegają zmianie i nowe przepisy wymagają, żeby faktury za lekcje tańca zawierały jakieś specjalne dane, zbędne do faktur za zwykłe produkty. Jeśli proces zarządzania zmianami nie uwzględnia wszechstronnej analizy modeli procesu biznesowego (ja wiem, Wy zawsze to robicie, prawda?), to zmiana serwisu „fakturowanie” dla procesu lekcji tańca spowoduje klasyczną i zupełnie nieprzewidzianą awarię procesu sprzedaży produktów. Obszerne testy regresji są jedynym sposobem, aby tego uniknąć, czy dokładniej, aby to wykryć przed wdrożeniem.

Czyli odpowiedź na pytanie „czy BizDevOps ogranicza potrzebę testów regresji” brzmi: to zależy od tego, czy uprawiany jest porządnie, czyli z modelowaniem i analizą wymagań oraz procesów, z solidnym projektowaniem architektury etc. Jeśli nie jest, to ani trochę tej potrzeby nie zmniejsza, gdyż obszerne testy regresji są zawsze i wszędzie, tak samo w BizDevOps, jak i w metodach tradycyjno-sekwencyjnych, kosztownym lekarstwem na skutki bałaganu i niechlujstwa. Dodam – lekarstwem do leczenia objawowego (5), a nie leczenia choroby.

A teraz – do rzeczy

Skoro już uporałem się z tematem testów regresji w BizDevOps, w istocie rzeczy drugorzędnym, ale jak wynika z motta – dlaczegoś popularnym, popatrzymy na inne aspekty BizDevOps, mające wpływ na praktyki testowania.

DevOps wymaga ciągłego wdrożenia (ang. continuous deployment), ono – ciągłej integracji (ang. continuous integration), a ta – ciągłego testowania.

Jeśli uda się ograniczyć zakres i pracochłonność testów regresji, osiągnięcie CI będzie nieco łatwiejsze, ale nadal trudne.

„Biz” przed „DevOps” oznacza dwa dodatkowe wymagania:

A. Nowe potrzeby biznesowe muszą być szybko i w sposób ciągły analizowane, walidowane i weryfikowane pod względem spójności z pozostałymi wymaganiami biznesowymi. To wymóg kluczowy, ale ponieważ formalnie „testowanie wymagań” nie jest zaliczane do testowania (6), nie będę o nim tutaj pisał.

B. Nowe potrzeby biznesowe trzeba szybko i w sposób ciągły przekładać na ich testy, które…

C. … które z kolei trzeba sprawnie automatyzować i wykonywać, zarówno dla potrzeb testów nowej funkcjonalności, jak i dla – mimo wszystko niezbędnych – testów regresji.

Nie ma cudów – osiągnięcie „B” oraz „C” jest niełatwe! I jest warunkiem koniecznym, ale niewystarczającym (niezbędne jest także „A”!), dla skutecznej realizacji BizDevOps.

Szczęśliwie, do realizacji wymogu „B” jest gotowa metodyka, język i narzędzie. Zanim powszechnie zrealizowane zostaną wizjonerskie projekty „od wymagań do kodu w mgnieniu oka” (7), wsparte automatycznym generowaniem testów z modeli (8), możemy posługiwać się prostszymi sposobami: BDD - specyfikacja na przykładach – Gherkin (9).

Jak dostatecznie szybko tworzyć testy automatyczne?

Powyżej wspomniałem o dwóch sposobach: z użyciem języka „Gherkin” oraz przy pomocy tajemniczo brzmiącego „automatycznego generowania testów z modeli” (10). Poza tym, są jeszcze dwa sposoby:

A. Nagrywanie, przy pomocy specjalnych narzędzi, testów wykonywane ręcznie, tak że po jednorazowym, ręcznym wykonaniu otrzymuje się skrypt, gotowy do wielokrotnego, automatycznego wykonania tych samych testów (11). Ten sposób, spektakularny na pierwszy rzut oka, ma szereg ograniczeń, które nie pozwalają na jego zastosowanie w BizDevOps (ani w DevOps, ani w ogóle w ciągłej integracji i testowaniu).

B. Pisanie programów testowych ręcznie, co znów oczywiście jest zbyt powolne, o ile nie…

… o ile nie wesprzemy tego podejścia formułą tak zwanego „testowania przy pomocy słów-kluczy” (12), którego odmianą jest właśnie BDD/Gherkin.

Coś jeszcze? Tal, gdyby udało się mieć narzędzie na tyle inteligentne, żeby umiało połączyć kilka technik automatycznego tworzenia skryptów testów:

A. Z modeli, wprost do kodu skryptu testowego;

B. Nagrywania, jak w metodzie „zarejestruj – odtwórz”

C. Z kodu źródłowego (jak narzędzia do generowania testów jednostkowych, np. „Cantata”)

D. Z interfejsu

E. Z modeli rozkładu prawdopodobieństwa.

Takim narzędziem jest między innymi Tricentis Tosca (13). Sporo wiadomości na jego temat można znaleźć na stronie http://secorda.com/pl/#page-top.

Podsumowanie - czy warto pisać podręcznik „Testowanie w BizDevOps”?

To pytanie analogiczne do tego, jakie od ponad 10 lat zadawane jest wobec testowania w agile. Niektórzy robią z testowania w projektach realizowanych metodami agile niemal nową specjalność, wymagającą osobnych (kosztownych!) szkoleń i tajemnej wiedzy, a inni twierdzą, że uprawianie testowania w różnych modelach projektowych – w tym w agile – nie jest w żaden sposób wyjątkowe (14). Dyskusja czasem staje się gorąca (15).

Testowanie w BizDevOps, czy szerzej – zapewnienie jakości w BizDevOps – też nie jest jakąś radykalnie odmienną dyscypliną. Natomiast prawdą jest, że dla skutecznej i udanej realizacji metod BizDevOps-owych, niezbędne jest spełnienie kilku reguł, odnoszących się do inżynierii wymagań, projektowania architektury oprogramowania oraz testowania. Bez nich, BizDevOps będzie tylko modną nazwą. Te reguły to:
  • Poprawne i elastyczne modelowanie wymagań
  • Szybki, skuteczny proces analizy wpływu zmian
  • Łączenie testów z wymaganiami
  • Ciągłe testowanie:
    • Szybkie – najlepiej automatyczne – tworzenie testów z wymagań
    • Szybkie – najlepiej automatyczne – tworzenie programów testowych i automatyzacja wykonywania testów.


Rola organizacji testowej w transformacji BizDevOps

Przejście od metod tradycyjnych, a nawet agile’owych, do DevOps i BizDevOps, jest niełatwe. Miałem okazję pomagać kilku organizacjom przezwyciężać te trudności.

Nie wystarczy zmienić organizację, zastępując tradycyjne struktury organizacyjne i projektowe samowystarczalnymi, samoorganizującymi się zespołami, mającymi upoważnienie do samodzielnej realizacji zmian, potrzebnych w podlegającym im procesie, usłudze czy produkcie. Oprócz tego, niezbędne jest stworzenie takiej architektury systemu i takiego sposobu modelowania wymagań, które to umożliwią.

W okresie przejściowym, kiedy próby realizacji BizDevOps prowadzi się na wielkim, monolitycznym systemie z mnóstwem skomplikowanych, zaszytych zależności, a biznes dopiero uczy się, jak rozwikłać i rozpleść swoje procesy na osobne ścieżki, niezbędna jest pomoc kogoś, kto zna wszystkie zależności, techniczne i biznesowe, kto rozumie i „ogarnia” całość. Często taką rolę w dotychczasowej organizacji pełnił dział testów właśnie, i naiwne próby jego przedwczesnego rozparcelowania pod hasłem „w DevOps osobny dział testów nie jest potrzebny”, to poważny błąd.

Powodzenia! Bogdan Bereza

bogdan.bereza@victo.eu

___________________________________________________________

1. Obiektyw „makro” to taki, który umożliwia powstanie na zdjęciu obrazu większego, niż widziany z bliska gołym okiem, czyli jakby „lupo-obiektyw”, natomiast obiektyw długoogniskowy (teleobiektyw) służy do przybliżania na zdjęciu obiektów odległych, czego raczej nie stosuje się w gastro-fotografii. Niezależnie od tych kwestii technicznych, których nie wyczerpałem, pytanie tak naprawdę dotyczyło nie rodzaju obiektywu, a sensu robienia zdjęć fragmentów potraw w powiększeniu. Czyli nieporozumienie piętrowe.

2. Czyli po naprawieniu błędu albo dodaniu nowej funkcji, albo przeniesieniu na inną platformę, albo zmianie implementacji.

3. SOA (service-oriented architecture) czy mikro-SOA, nie ma znaczenia. Mikro-serwisy, to po prostu małe serwisy, więc różnica jest tylko skali.

4. To skądinąd ważna i interesująca tematyka, jaki zakres serwisu jest właściwy, jaki jest zbyt obszerny, a jaki za wąski w sensie biznesowym („nano-serwis”), ale jest spoza obszaru testowania.

5. Medycyna paliatywna (łac. pallium – płaszcz) – dział medycyny, a także specjalność lekarska, która obejmuje leczenie i opiekę nad nieuleczalnie chorymi, którzy znajdują się w okresie terminalnym śmiertelnej choroby. Celem działań medycyny paliatywnej nie jest zatrzymanie procesu chorobowego oraz jego wyleczenie, ale poprawienie jakości życia osób w tej fazie choroby.

6. http://blogomocja.blogspot.com/2015/01/gimbaza-testerow.html

7. http://requirements.org.pl/re-challenge/2015-prezentacje/redseeds.pdf

8. http://requirements.org.pl/seminaria2017/modelarskie.html

9. http://wymagamy.blogspot.com/2017/04/specyfikacja-na-przykadach-bdd-gherkin.html

10. Np. http://www.all4tec.net/Matelo/model-based-testing.html

11. Zwane „capture – replay”, albo „capture – playback”, albo “zarejestruj – odtwórz”

12. https://en.wikipedia.org/wiki/Keyword-driven_testing

13. https://www.tricentis.com/software-testing-tools/

14. http://www.computerworld.pl/news/Blad-Arystotelesa-w-IT,394951.html

15. http://blogomocja.blogspot.com/2014/05/modne-bzdury-kontratakuja.html