Tester lateralny, czyli przyszłość QA

Zagadka taka, jak powyżej, nazywana jest niekiedy lateralną, ponieważ jej rozwiązanie wymaga spojrzenia na problem w sposób niestandardowy, wymagający zerwania ze stereotypowym podejściem, które towarzyszy nam na co dzień. Zaskakującego rozwiązania pozornie niemożliwej sytuacji dokonuje już bohater opowiadania Edgara Poe, pt. “Zabójstwo przy Rue Morgue”, które, napisane niemal dwieście lat temu, uważane jest za pierwowzór powieści kryminalnych. Mimo to samo pojęcie myślenia lateralnego (ang. lateral thinking), pozwalającego na szukanie nowych, alternatywnych metod, zaproponował Edward de Bono dopiero w roku 1967. Podejście to zakłada analizę skupioną na szczegółach, ale z celowym pominięciem standardów i nieistniejących reguł, za którymi intuicyjnie podążamy. De Bono proponuje różnorodne techniki generowania idei (np. na bazie powiązania ich z losowo wybranych rzeczownikiem ze słownika) czy spojrzenie na sytuację z różnych perspektyw (np. technika tzw. “kapeluszy myślowych” - ang. Six Thinking Hats).

Co ważne dla nas, jako inżynierów jakości, myślenie lateralne, niestandardowe, jest kluczowe nie tylko w rozwiazywaniu szarad, ale też efektywnym testowaniu eksploracyjnym. Większość standardowych scenariuszy działania aplikacji jest zwykle sprawdzona jeszcze przez samego programistę zanim kod zostanie przekazany do testów. Ponadto, wraz z intensywnym rozwojem systemów opartych na sztucznej inteligencji (m.in. działających na bazie GPT-3), możemy już wkrótce spodziewać się oprogramowania testującego kod w oparciu o wymagania spisane w formie dokumentów tekstowych (nb. oznacza to, że specjalista od automatyzacji to też gatunek zagrożony). Ponadto systemy oparte o sztuczne sieci neuronowe nauczą się standardowych technik testowania i najpopularniejszych, klasycznych błędów. Będą działać niezwykle efektywnie, ale, z drugiej strony, w sposób szablonowy i schematyczny. Jeśli i my będziemy pracować podobnie, staniemy się szybko mało konkurencyjni, a nasz etat zastąpi licencja na oprogramowanie. Czekają nas zmiany. Skrypty manualne czy klasyczne czarnoskrzynkowe techniki projektowania testów (np. analiza wartości brzegowych, tablice decyzyjne) niedługo będę w pełni zautomatyzowane i równie powszechne jak dziś narzędzia do statycznej analizy kodu.

Manualny tester przyszłości (i to nie tak odleglej) będzie więc musiał wykazać się cechami, których nie zastąpimy łatwo oprogramowaniem. Odtwarzanie powszechnie stosowanych heurystyk albo metodyczne przeglądanie scenariuszy z dokumentacji przejmie AI. Tester-człowiek będzie osobą kreatywną, budującą swoje własne heurystyki, patrzącą na analizowaną aplikację w sposób niestandardowy, właśnie lateralny. W ten sposób znajdzie błędy i ryzyka, których działający stereotypowo automat nie wychwyci. Musi także dostrzegać aplikację w szerszym kontekście, rozumieć nie tylko działanie jej samej, ale też widzieć aspekty biznesowe i zależności w całym ekosystemie (wewnętrznym i zewnętrznym).

Tylko jak działać niestandardowo? Skąd czerpać inspirację? Myślę, że warto zacząć od rzeczy, które dobrze znamy i poszukać głębiej pewnych nieoczywistych zależności i wymiarów nienazwanych wprost. Weźmy na przykład klasyczną technikę klas równoważności znaną wszystkim dobrze z podstawowego sylabusa ISTQB®. Streszczając: technika sugeruje pogrupowanie danych wejściowych na takie, dla których testowana aplikacja zachowuje się w różny sposób. Klasyczny przykład: aplikacja przyjmuje wartości całkowite wieku użytkownika z przedziału [0, 130]. Gdy podamy wartość do 64, program zwraca tekst “do roboty!”, a od 65 - “miłej emerytury!”. Technika klas równoważności wskazuje więc, że mamy do czynienia z dwiema klasami poprawnymi i dwiema niepoprawnymi (mniej niż 0 i powyżej 130). Zwykle tutaj nasza przygoda się kończy. Warto jednak przyjrzeć się matematycznej definicji klasy równoważności: jest to zbiór elementów, między którymi zachodzi relacja równoważności R spełniająca 3 warunki:

• zwrotność: aRa (czyli obiekt jest w relacji R sam z sobą),
• symetryczność: jeśli aRb, to bRa,
• przechodniość: jeśli aRb i bRc, to aRc.

Oczywiście relacja równości = jaką znamy jest relacją równoważności. Relacja mod5 oznaczająca tę samą resztę z dzielenia liczby przez 5 - także. Ale warto spojrzeć szerzej, niestandardowo. Wówczas zauważymy, że zgodnie z powyższą definicją relacja równoważności nie musi dotyczyć liczb (mimo, że jest to najbardziej oczywisty i najłatwiejszy przykład). Co za tym idzie same klasy równoważności nie muszą więc być zbiorami liczb, a na przykład:

• zbiorami trójkątów podobnych (relacja: “bycie figurą podobną do”),
• zbiorami prostych do siebie równoległych (relacja: równoległość),
• zbiorami aut w tym samym kolorze (relacja: “mieć ten sam kolor co”),
• zbiorami produktów spożywczych tego samego typu (relacja: “bycie w tej samej kategorii produktów”).

Jako testerzy powinniśmy zatem patrzeć na klasy równoważności dużo szerzej niż wymagają tego przykładowe testy egzaminacyjne ISTQB®. Idąc analogicznym rozumowaniem szybko bowiem znajdziemy ciekawe podziały, z których warto czerpać dane testowe (np. po jednym ze zbioru):

• zbiory podobnych użytkowników (UX),
• zbiory identycznych praw dostępu (wariant testów bezpieczeństwa),
• zbiory podobnych klas szybkości łącza/sieci (testy wydajności),
• zbiory tych samym/zbliżonych urządzeń, systemów operacyjnych, przeglądarek internetowych (testy przenoszalności)
• zbiory produktów o tej samej formie dostawy (testy funkcjonalności sklepu internetowego) 
• …

Powyższy przykład pokazuje, jak dzięki nieszablonowemu, lateralnemu podejściu można ze standardowej, wręcz nurzącej, koncepcji klas równoważności przejść do tworzenia własnych heurystyk nie odbiegających jakością od tych proponowanych w nowoczesnych metodach testowania eksploracyjnego jak np. Rapid Software Testing (M. Bolton). Zmiana pespektywy i poszerzenia spojrzenia są kluczem do przyszłości testowania manualnego.

A jak to możliwe, że dwaj synowie nie są bliźniakami? Otóż mają jeszcze siostrę i są tak naprawdę trojaczkami!