Radek Smilgin
Próba uszeregowania metod kontroli i zapewnienia jakości, w zależności od złożoności i krytyczności produktów, jest wyzwaniem karkołomnym, ale nie niemożliwym do osiągnięcia. Jednym z głównych założeń musi być to, że metody nigdy nie występują samodzielnie. Często stosujemy wiele z nich, ale nacisk kładziemy na jedną, tę dominującą. Musimy również pamiętać, że działania związane z jakością są domeną wielu czynności w procesie wytwarzania. Są one zarówno w zakresie działań inżynierów jakości, analityków biznesowych, właścicieli produktów, jak i są częścią działań wytwórczych prowadzonych przez programistów. Każda z nich może być wspierana przez testerów oprogramowania, gdzie sami testerzy mają również swoje, specyficzne techniki i narzędzia.
Pierwszym krokiem jest zdefiniowanie wymiarów w jakich będziemy oceniali metody.
Może dziwić, że testowanie manualne i automatyczne GUI znajduje się tak nisko w strukturze metod. Ręczne sprawdzenie polegać będzie na uruchamianiu predefiniowanych przypadków testowych i odbywać się będzie w znanych ograniczeniach jak nieskończoność testowania oraz omylność działań wykonywanych przez testerów. Takie podejście może być więc stosowane skutecznie tylko w produktach prostych i mało krytycznych. Dodatkowo obie metody (manualna i automatyczna) często wiążą się z późnym zaangażowaniem gdy dostępne są już interfejsy końcowego użytkownika.
Automatyzacja GUI będzie niewiele skuteczniejsza od testów manualnych i pozwoli nam zweryfikować bardziej złożone produkty, jednak jej stosowanie w produktach krytycznych będzie malało wraz ze wzrostem ich krytyczności.
Kropkę w przestrzeni grafiki trzeba potraktować jako punkt graniczny, najbardziej wysunięty względem osi krytyczności i złożoności. Oczywiście metody te pokrywają wszystkie mniej złożone i mniej krytyczne produkty.
Produkty dużo bardziej złożone, ale mniej krytyczne, lepiej będzie kontrolować przy pomocy monitoringu. Wyróżnimy tu dwie metody - ręczną, gdzie decyzję o wycofaniu produktu z środowiska (roll back) podejmie człowiek oraz automatyczną, gdzie to algorytm zdefiniuje, że musimy przywrócić poprzednią wersję.
Choć sam jestem zwolennikiem testowania eksploracyjnego i widzę jego przewagę nad formalnym testowaniem, to jednak ciągle będzie to metoda trudna w systemach bardzo złożonych. Pozostaje ona najskuteczniejszą, pojedynczą metodą w obszarze jaki pokrywa, a obszar ten to jakieś 80% tworzonego oprogramowania.
Pod hasłem „CI / CD” kryje się dużo więcej, niż tylko continuous integration, delivery i deployment. Pamiętajmy, że na metodę tę może składać się wiele działań jak analiza statyczna, testy jednostkowe, API i GUI. Wiele zależy od tego, jak została w projekcie wdrożona. W próbie wartościowania metod traktuje ją więc, jako najlepsze rozwiązanie dla produktów średnio skomplikowanych i średnio krytycznych oraz podstawową metodę w ramach DevOps.
Testy A/B wydzielam z monitoringu traktując je jako metodę wymagającą, oprócz monitorowania metryk produkcyjnych, również profesjonalnej oceny ryzyka, zanim zdecydujemy się wystawić daną wersję użytkownikowi końcowemu.
W zestawieniu nie mogło zabraknąć analizy statycznej i dynamicznej. W produktach krytycznych i bardzo prostych będą one kluczowe. Pozwalają one nie tylko zadbać o wysokiej jakości kod źródłowy, ale również wspierać kontrolę poziomu niezawodności oprogramowania. 
Wyżej ulokują się testy akceptacyjne, które dla mnie będą nie tyle „przeklikaniem” się przez produkt, przez końcowego użytkownika, ale w dużo większym stopniu świadomą decyzją podjętą przez właściciela produktu o gotowości wdrożenia produktu na środowisko produkcyjne. Decyzja musi bazować na rozległej analizie wyników z wielu wspomnianych tu metod.
Przeglądy nigdy nie będą najważniejszą metodą kontroli jakości, ale są krytyczne dla jej zapewnienia. Ciężko, z jednej strony traktować ją jako dominującą, ale z drugiej ciężko byłoby ją pominąć w zestawieniu. Przeglądy będą miały niezaprzeczalną wartość dla produktów krytycznych (jak i mniej krytycznych) oraz dla średnio złożonych.
Test kodu i interfejsu (jak i TDD) traktuję jako najskuteczniejsze w kontroli i zapewnieniu jakości. Tu szczególnie widać, że te metody nie mogą być traktowane jako w pełni „samodzielne” i tak jak wszystkie pozostałe muszą być uzupełnione przez inne metody operujące już na zintegrowanym systemie. Choć zapewne metod można wyróżnić więcej to wydaje się, że najważniejsze zostały już pokazane. Brakuje nam jedynie metod, które mogłyby weryfikować produkty najbardziej krytyczne i najbardziej złożone. Ponieważ na dziś jeszcze takiej metody nie ma, to wiemy że firmy starają się unikać tworzenia systemów bardzo skomplikowanych i mogących jednocześnie zagrozić życiu użytkowników. Gdybyśmy jednak spróbowali spojrzeć w przyszłość i określić co mogłoby być taką metodą to...
Jeśli zgodzimy się (w pewnym stopniu ogólności) co do poprawności powyższego zestawienia, to możemy je traktować jako wyznaczenie kierunku do wzmacniania pozycji już wdrożonych metod, ale również szukania nowych pomysłów do jeszcze lepszej kontroli i zapewnienia jakości.
Zestawienie metod powstało na potrzeby prezentacji „Co jest ważne” przygotowane na meetup ŁuczniczQA (marzec 2020).
