Redakcja testerzy.pl
Szybki kontekst na sam początek. James Bach stoi za metodyką Rapid Software Testing i szkołą context-driven. To szkoła, która dość krytycznie podchodzi do formalnych podejść do testowania, stosów dokumentacji czy sylabusów certyfikacyjnych. Nie zmienia to jednak faktu, że wnioski autora o języku rozmów w projektach są celne dla każdej osoby, niezależnie od tego czy bliżej jej do ISTQB®, RST czy do opierania się na praktyce.
Bach wychodzi z założenia, że rozmowy o testowaniu są trudne, bo sama praca ma nietypowy charakter. Z jednej strony generuje ona nowe zadania – każdy znaleziony defekt trzeba przecież naprawić, a nowe ryzyko zbadać. Z drugiej, testowania tak naprawdę nie da się ukończyć, chociaż w którymś momencie trzeba je po prostu skończyć. I to właśnie z tego napięcia biorą się nieporozumienia, które autor ułożył w sześć konkretnych punktów.
Błąd 1
Liczba przypadków testowych nie jest żadnym wskaźnikiem
Pierwszy błąd dotyczy skupiania się na liczbie przypadków testowych, a nie na tym, co naprawdę testujemy. Bach porównuje to do pracy programistów – nikt przecież nie ocenia dewelopera po liczbie plików czy wciśniętych klawiszy, bo to nijak nie świadczy o jakości. Sytuacja z przypadkami testowymi wygląda identycznie, tylko rzadziej to zauważamy. W końcu tę samą aktywność można zamknąć w jednym przypadku testowym albo rozbić na sto tysięcy przypadków – kwestia napisania prostego skryptu.
Zamiast pytać „ile”, Bach proponuje pytanie o to, co te testy tak naprawdę pokrywają, jakie defekty są w stanie wykryć i jakie ryzyka za nimi stoją. Mało kto zadaje te pytania, bo odpowiedź na nie wymaga więcej wysiłku. Same liczby są łatwiejsze do przedstawienia w raporcie i pozwalają pokazać postęp bez wchodzenia w szczegóły. Sęk w tym, że raport oparty na liczbie przypadków, bez pokazania zmapowanych ryzyk, daje tylko złudzenie, że panujemy nad sytuacją.
Błąd 2
Test jest działaniem, a nie rzeczą
Drugi błąd zahacza co prawda o teorię, ale dotyka samej praktyki. Bach przypomina, że test jest procesem, czymś, co się dzieje. Dokumentacja, dane czy skrypty są ważne, ale nie wyczerpują tematu. Jeśli sprowadzimy test do obiektu („mamy testy”, „przekazujemy testy”), zapominamy o uwadze, intencji i umiejętnościach człowieka. Dwóch testerów nie zrobi tego samego testu dokładnie tak samo. To tak jak w sporcie – dwóch zawodników nigdy nie powtórzy akcji w 100% identycznie.
W naszych realiach ten problem widać chociażby w ogłoszeniach o pracę czy przy wycenach projektów, gdzie przejęcie testów po poprzednim zespole traktuje się jak zwykłe przekazanie repozytorium. Repozytorium to po prostu kod, ale całej wiedzy o produkcie i intencji, które stały za tymi testami, nie da się przekazać w samych plikach.
Błąd 3
Problem z wyjaśnieniem strategii testowej
Trzeci punkt dotyczy braku pomysłu na strategię testową i jej ewolucję. U Bacha strategia to konkretny zestaw zasad kierujących wyborem testów. Daje odpowiedź na to, dlaczego wykonujemy akurat te testy, z czego rezygnujemy i jak zareagujemy, gdy trzeba będzie przetestować coś szybciej albo dokładniej. Taka świadomość odróżnia profesjonalne podejście od działania na oślep, opartego wyłącznie na intuicji i przyzwyczajeniach.
Błąd 4
Narzędzia nie testują; testują ludzie, którym narzędzia pomagają
Czwarty błąd to chyba najbardziej znany motyw u Bacha, rozwijany przez lata z Michaelem Boltonem wokół podziału na testowanie (ang. testing) i sprawdzanie (ang. checking). Gdyby o programowaniu rozmawiać tak jak o testowaniu, deweloperzy twierdziliby, że kod napisał kompilator, a oni tylko wciskali przyciski. Narzędzie potrafi jedynie wykonać skrypt i porównać dwa rezultaty. Bach nazywa to sprawdzaniem faktów, nie testowaniem. Testowanie to cała otoczka stworzona przez człowieka: od pomysłu na test, przez analizę wyników i utrzymanie skryptów, aż po wybór tego, co naprawdę opłaca się sprawdzić.
Ten punkt zestarzał się chyba najciekawiej. Wystarczy podmienić automatyzację na dzisiejsze AI i całe wywodu pasują bez zmieniania ani jednego słowa. Dyskusja o tym, czy modele językowe zastąpią testerów, dobrze odtwarza spór o automatyzację sprzed dekady. Znowu przypisujemy narzędziu pełne wykonanie pracy, zamiast traktować je jako wsparcie dla człowieka, który bierze za tę pracę odpowiedzialność. Różnica jest taka, że dzisiejsze narzędzia są bardziej elastyczne i potrafią świetnie udawać własny osąd, przez co jeszcze łatwiej pomylić jedno z drugim.
Błąd 5
Nie istnieje tylko jeden wymiar pokrycia testami
Błąd numer pięć to sprowadzanie pokrycia testowego do jednego wymiaru. Bach podaje prosty przykład: kiedy testujesz stronę z wynikami wyszukiwania, sprawdzasz zarazem funkcjonalność (typ wyszukiwania), jak i dane (zbiór, na którym operujesz). Jeśli zmienisz zapytanie, pokrywasz nową funkcję; jeśli zmienisz dane – pokrywasz nowy obszar danych. A defekty lubią chować się właśnie na styku jednego i drugiego. Pokrycie kodu, do którego tak często się odwołujemy, pokazuje zaledwie ułamek całości.
Osoby znające sylabusy certyfikacyjne doskonale kojarzą ten temat, bo rozróżnienie kryteriów pokrycia to absolutna podstawa teorii. Problem pojawia się w codziennym raportowaniu. Z wielu wymiarów w praktyce zostaje zwykle jeden szybki procent w dashboardzie, bo po prostu łatwo wrzucić go na wykres.
Błąd 6
Traktowanie testowania jako statycznego zadania
Ostatni punkt zbiera to wszystko w całość, opisując testowanie to proces poznawczy. Jeśli ktoś testuje i nie uczy się przy tym niczego nowego o produkcie, to zdaniem Bacha po prostu nie testuje. Nauka ma to do siebie, że nie da się zaplanować każdego kolejnego odkrycia. Dlatego sensowne testowanie polega na ciągłym badaniu i projektowaniu eksperymentów, z częstym zbaczaniem ze sztywno wytyczonych ścieżek. Procedury i automatyzacja są tu przydatne, ale tylko jako narzędzia reagowania na to, co akurat odkrywamy. Żaden odpowiedzialny tester nie pracuje według prostego schematu: „zaprojektuj przypadki, a potem je po kolei wykonuj”.
W komentarzach pod artykułem Erik J zaproponował zresztą siódmy punkt, który Bach przyjął z dużym uznaniem: błędem jest traktowanie wiedzy o systemie tak, jakby mogła być absolutna. Zgodnie z filozofią Poppera, cała nasza wiedza jest omylna. Nie chodzi więc o to, by dowiedzieć się absolutnie wszystkiego, tylko o to, by odpowiednio zarządzić ryzykiem i niepewnością w dostępnym czasie.
Co zrobić z przemyśleniami Bacha po latach
Nie trzeba się zgadzać ze wszystkim, co pisze Bach. Dyskusja o tym, czy zwrot „automated testing” ma sens, toczy się od dawna i trudno odmówić racji tym, którzy wolą zachować pragmatyzm – skoro wszyscy w branży rozumieją ten skrót myślowy, walka o czystość języka mija się z celem. Wartość tego zestawienia leży jednak gdzie indziej. Jest to zbiór pytań, które warto zadać zespołowi podczas spotkania:
- co dokładnie sprawdzamy?
- przed czym te testy nas chronią?
- co nowego wiemy dzisiaj o systemie?
Kiedy zespół potrafi na nie odpowiedzieć, liczba przypadków testowych w raporcie w niczym nie przeszkadza. Kiedy odpowiedzi brakuje – sam wskaźnik niczego nie naprawi, a jedynie odwlecze w czasie twarde zderzenie z rzeczywistością.
