Problemy testowania (?)

Data: 2014-07-03
Autor: Sebastian Konkol
Problemy testowania (?)

Niniejszy wpis to opowieść z cyklu: „Wszyscy wiedzą, jak powinno być, a jednak robią inaczej”. Przez ostatnich kilka lat uczestniczyłem w projektach informatycznych o dużym znaczeniu dla firm finansujących te projekty. Oglądałem wdrożenia systemów sprzedażowych, bilingowych, obsługi klienta, platform usługowych, systemów transakcyjnych. Skoro system informatyczny, to trzeba testować, prawda?

Prawda. Nikt nie zaprzecza i wszyscy testują. We wszystkich projektach, w jakich uczestniczyłem w ostatnich latach, powtarzał się jednak ten sam schemat, a raczej jeden z dwóch – albo testy się wydłużały, albo zakres wdrożenia był radykalnie „fazowany”. Nie jest to kwestia pecha projektów, bo koledzy od innych projektów z branży „zeznają analogicznie”. We wszystkich przypadkach testowanie było (a) na końcu procesu rozwoju oprogramowania oraz (b) utożsamiane z weryfikacją jakości systemu.

Od długiego – jak na standardy IT – czasu, bo już ponad dekadę, znane są zarówno optymalne podejście do tworzenia systemów informatycznych, jak i testowania ich. TDD (Test-driven Development), chyba najlepiej znana praktyka w tej sferze, zakłada, że myślenie w kategoriach testowania należy zacząć na samym początku, a najlepiej najpierw tworzyć testy przed samym oprogramowaniem. Truizmy o wykładniczo rosnącym koszcie usunięcia błędu w następujących po sobie fazach realizacji systemu są znane wszystkim, a jednak testowanie „na poważnie” traktowane jest dopiero na końcu. W efekcie trwa dłużej i kosztuje więcej. Zawsze…

Ale to zaledwie wierzchołek góry lodowej jakości oprogramowania. Nie chodzi tu nawet o teoretyzowanie, czy wiedzę uniwersytecką, ale o zdrowy rozsądek. Nie jestem ekspertem od testów, więc skupię się na innych elementach dbałości o jakość oprogramowania.

Spostrzeżenie pierwsze, czyli pułapka unifikacji. Projekty informatyczne różnią się charakterem – zakresem, zasięgiem, oczekiwaniami wobec dostarczanych systemów. Mimo takiego zróżnicowania, weryfikacja jakości systemu w praktyce podlega tym samym regułom. Sposób ich testowania nie wykracza poza generyczne podejście. W moim odczuciu, chwila refleksji na temat dobrania zakresu, metod czy podejścia do weryfikacji jakości systemu – w odniesieniu do charakteru projektu – znacząco pomogłaby projektom IT, a kilka z nich mogłaby uratować. Być może brak takiej refleksji to jeszcze inna odsłona wtórnego analfabetyzmu informatyki stosowanej, ale skłaniam się tu raczej ku wygodnictwu.

Spostrzeżenie drugie, czyli zatestować się na śmierć. W niemal każdym projekcie, w którym testy prowadzone są jako ostatnia faza rozwoju systemu, pod koniec testowania przychodzi taki czas, kiedy większość została już przetestowana, ale ciągle pojawiają się błędy i nikt nie ma odwago zdecydować, co z tym zrobić. Z tygodnia na tydzień okazuje się, że jeszcze nie jest wystarczająco dobrze, ale nikt nie potrafi powiedzieć, ile to jeszcze może potrwać. W związku z napiętymi harmonogramami nikt także nie ma odwagi powiedzieć, że należy zastanowić się nad „planem B”. Żaden system nie będzie bezbłędny – nigdy. Warto poświęcić chwilę na zrozumienie konsekwencji, jakie miałoby zdrożenie systemu takim, jakim jest i ustalić, jak sobie z nimi radzić, zamiast ciągle odsuwać termin zakończenia testów o krótki okres, w którym „nie zdążymy wdrożyć planu B”.

Spostrzeżenie trzecie, czyli wiara w procenty. Najczęstszą miarą postępu w osiąganiu oczekiwanej jakości systemu jest liczba przypadków testowych, które „przechodzą poprawnie”. Wydaje się to być rozsądne, ale pod jednym warunkiem – stabilności warunków pomiaru. W wielu przypadkach jednak, w konsekwencji pojawiających się błędów w systemie lub odkrywanych niespójnościach w przypadkach testowych, sumaryczna liczba tych przypadków zmienia się. Często jest tak, że rozbudowa listy przypadków dotyczy małego fragmentu systemu, w którym wykryto błędy, przez co jedna wartość procentowa wyliczona dziś staje się nieporównywalna z tą samą wartością wyliczoną dla stanu tydzień temu. W ten sposób traci się stabilność pomiaru, a więc zdolność do wnioskowania na podstawie tej miary. W konsekwencji, znacznemu osłabieniu podlega zdolność zarządzania tą fazą realizacji systemu informatycznego.

Spostrzeżenie czwarte, czyli testy dopiero na produkcji. Praktyka pokazuje, że dość częstym przypadkiem jest brak możliwości odtworzenia w warunkach symulowanych środowiska działania systemu – brak możliwości zbudowania pełnego środowiska testowego. Czasami powodem bywa brak możliwości zarezerwowania odpowiednich składowych środowiska w ustalonym przez harmonogram projektu horyzoncie czasu. Często powodem są ograniczenia ekonomiczne, bo takie środowisko byłoby zbyt kosztowne. Co wtedy? Robimy, co możemy na testowym, a następnie wdrażamy produkcyjnie i patrzymy, czy się nie wywróci. Często się wywraca…

Spostrzeżenie piąte, czyli po wdrożeniu jest już dobrze. Niby pozostaje ono w sprzeczności z poprzednim z poprzednim, ale jednak nie jest. Powszechnie stosowana praktyka weryfikacji jakości systemów kończy się na testach przed wdrożeniem lub krótkoterminowej obserwacji zaraz po wdrożeniu. Wszak, skoro przeszły testy, to system działa dobrze. Przez pewien czas, prawdopodobnie, działa poprawnie, ale złożoność współczesnych środowisk informatycznych w połączeniu z intensywnością zmian do nich wprowadzanych sprawiają, że nawet mała zmiana w odległej części środowiska może wpłynąć na warunki działania właśnie wdrożonego systemu. Swoisty efekt binarnego motyla. Nie ma co liczyć na to, że przewidziane zostały wszystkie możliwe interakcje i zrozumiane ich konsekwencje. Sugeruję prowadzenie ciągłych, ściśle zautomatyzowanych obserwacji sposobu działania systemu na środowisku produkcyjnym. Niektórzy nazywają to testami aktywnymi.

Spostrzeżenie szóste, czyli konfiguracji nie trzeba testować. Z niezrozumiałych dla mnie powodów w mentalności użytkowników systemów informatycznych istnieje ścisła granica między konfiguracją a tworzeniem oprogramowania. Konsekwencją jest skupienie się na weryfikacji poprawności tworzonego oprogramowania z częstym pomijaniem weryfikacji wpływu zmian konfiguracyjnych na dany system. Współczesne systemy IT mają taką mnogość konfiguracji, a niektóre „opcje konfiguracyjne” mają taką moc, że mogą zmienić diametralnie charakter systemu. Zmiany w części z nich mogą wpływać nie lokalnie na jedną funkcję systemu, ale globalnie – na funkcjonalność, bezpieczeństwo, wydajność itd. Nie każda zmiana konfiguracyjna może być przeprowadzona bez weryfikacji jej wpływu.

Takich spostrzeżeń, mniej lub bardziej doniosłych, pojawia się sporo przy okazji każdego z projektów – o rzekomo powszechnie stosowanej automatyzacji testów, o kontraktach i ich zapisach wypaczających cele weryfikacji jakości systemu, o testerach i ich pryncypialnym podejściu do zagadnień jakości, o rozgrywaniu sił pomiędzy stronami uwikłanymi w projekt IT bazując na braku transparentności testów itd. Nie o to chodzi jednak, aby je tu skatalogować i wyśmiać. Chodzi raczej o to, jak zmienić podejście do weryfikacji jakości systemów, aby było ono adekwatne do uwarunkowań współczesnych projektów informatycznych. Mam dwie propozycje. Pierwsza, z procesem wytwórczym systemów IT w tle, dotyczy sposobu traktowania testów. Testy nie są czymś oddzielnym realizowanym na końcu, ale są działalnością nierozłącznie związaną z cyklem życia systemów na każdy z jego etapów (koncepcja, programowanie, integracja, wdrożenie, użytkowanie, wyłączenie), a właściwsze – w mojej ocenie – postrzeganie jest takie, że sam rozwój systemów jest elementem osadzonym wewnątrz weryfikacji jakości i powinien być jemu podporządkowanym. Druga, na tle architektury systemów, dotyczy funkcjonalności systemów. W bardzo mały odsetek systemów jest dzisiaj wbudowana zdolność do ograniczenia zasięgu wpływu zmiany realizowanej w systemie. Powinny one być bowiem budowane według wzorca sandbox i umożliwiać ograniczone w zasięgu eksperymentowanie. Takie eksperymentalne funkcje systemów mogłyby być udostępniane wyłącznie dla określone grupy użytkowników FUT (Friendly-user Tests), a rozszerzenie dostępności funkcji powinno opierać się na działaniach konfiguracyjnych, nie zmianach w oprogramowaniu.

Czy skorzystacie z tych wskazówek, czy nie, odradzam „ślepe” opieranie się na metodach zapewnienia jakości, gdyż są one uśrednione lub zagregowane i nigdy nie przystają w pełni do konkretnego projektu IT. Silnie doradzam oparcie się na myśleniu i świadomym doborze metod weryfikacji jakości oraz zasięgu i siły ich stosowania.

Pozostaw komentarz