Efektywny, wg słownika języka polskiego PWN to: dający dobre wyniki, wydajny. W których aspektach związanych z testowaniem można rozpatrywać zwiększenie efektywności? I czy więcej znaczy lepiej?
Zacznijmy od ludzi. Efektywny tester to taki, który rzetelnie wykona miarodajne testy, na czas zakomunikuje o problemach, dostarczy wyczerpujących danych w zgłoszeniach, właściwie ustali priorytety, będzie potrafił zdobyć informacje i nimi zarządzić. Kiedy staje się ekspertem w obszarze, którego dotyczy testowany zakres – dostarczy też pomysłów na możliwe warianty przypadków, a dodatkowo poradzi sobie w sytuacji zdobycia informacji co do tego jak powinien zachować się system. Uproszczeniem będzie jednak założenie, że tylko ludzie w testach są gwarancją odpowiednio wysokiej jakości i kompleksowości ich wykonania. Podczas planowania typów i poziomów testów, które będą odpowiedzią na charakter zmian oraz zgłoszone wymagania – dopasowujemy pozostałe, niezbędne zasoby: dane testowe (dzięki którym otrzymamy wynik dla reprezentatywnego zakresu przypadków, a także w razie potrzeby informację o aspektach wydajnościowych rozwiązania), środowiska testowe (odzwierciedlające konfigurację produkcyjną, bądź umożliwiające wykonanie kolejno zaplanowanych poziomów) i dopiero taki zestaw zapewni nam odpowiednio kompleksową informację zwrotną.
Zgodnie z jednym z artefaktów testowania – nie da się przetestować wszystkiego. Planowanie testów albo dodawanie zadań w sprincie jest więc serią decyzji do podjęcia: co, w jaki sposób, w jakiej kolejności oraz konfiguracji powinno zostać sprawdzone, aby otrzymać możliwie najlepszy wynik. Niejednokrotnie zaczynamy od eksperymentowania i działania wg najlepszej posiadanej w danym momencie wiedzy.
W ramach rozważań warto przyjrzeć się efektywności testowania na osi czasu.
Na etapie testów jednostkowych ważny będzie taki dobór przypadków, który można będzie wykonywać wielokrotnie, a więc krótkich i różnorodnych. Przemyślane podejście do testów jednostkowych będzie więc dobrą bazą do efektywności kolejnych poziomów. Będzie też przyczynkiem do tworzonych na potrzeby regresji skryptów automatycznych, które będą bardziej trwałe, ale też tańsze w utrzymaniu. Dodatkowo w zwiększeniu ich efektywności pomóc może właściwy dobór narzędzi, np. JUnit ma problem ze zrównolegleniem testów, wtedy lepiej wybrać TestNG. Przemyślany sposób implementacji rozwiązania, zwłaszcza tam gdzie działamy w złożonej, wielowarstwowej architekturze, może stanowić bazę efektywnych testów jednostkowych, która będzie tworzona z myślą o przyszłych testach regresji. Jeśli rozwiązania są tak projektowane i realizowane, skorzysta na tym efektywność ich testowania. Słowem: im mniej zawiłości kodu tym bardziej przejrzyste i w efekcie łatwiejsze w utrzymaniu skrypty i scenariusze testowe.
W ramach testów systemowych, które uznamy za efektywne powinien dać się wykonać taki zakres, który będzie np. odpowiedzią na mogące się zmaterializować ryzyko dotyczące nowej architektury rozwiązania. Powinniśmy zebrać możliwe słabe punkty, które na tym etapie da się wywnioskować: z dokumentacji, doświadczenia oraz dotychczasowej implementacji. Np. wydajność poszczególnych operacji/czynności, ewentualne opóźnienia w wykonywanych akcjach po którejkolwiek z zaangażowanych komponentów. Warto, a nawet trzeba taki przegląd zakresu testów zrobić w powiązaniu ze zgłoszonymi wymaganiami oraz przypadkami użycia, gdyż na tym etapie najpóźniej powinny zostać wyjawione wszelkie braki albo nieporozumienia w wykonanej implementacji. Niewystarczająca będzie tu opinia ekspertów poszczególnych obszarów biznesowych, spójrzmy szerzej, cenna będzie opinia architekta i administratora rozwiązania. Być może z korzyścią dla przyszłej efektywności działań okażą się też wykonane na tym etapie przeglądy wytworzonych funkcjonalności. Chętnie zobaczą je interesariusze i na tym etapie, zgłaszając uwagi, podniosą ‘jakość’ rozwiązania. Dobrze rozumieją ten aspekt metodyki zwinne, gdzie Właściciel Produktu daje natychmiastową odpowiedź na temat poprawności i wartości wytworzonego elementu albo ‘dającej się zwalidować’ jego części. W taki sposób wykonane testy systemowe będą dobrym wstępem do kolejnego poziomu.
Efektywne testy akceptacyjne (User Acceptance Tests) to etap, który następuje wtedy, kiedy sformułowane wcześniej krytyczne ryzyka testowe mają dużo mniejszą szansę się zmaterializować: borykaliśmy się z nimi wcześniej i ten etap zainteresowane strony skłonne są uznać za zamknięty i wyjaśniony. Mam na myśli m.in. sytuacje, kiedy trzeba zdecydować się na kompromisy, bo nie wszystko udało się wykonać w 100%. Pole do dyskusji już było i umowy, ew. plany awaryjne są ustalone i mają szansę na realizację. W efekcie na tym etapie testów koncentrujemy się tylko na potwierdzeniu wystarczająco dobrej jakości bezspornego zakresu.
Jeśli natomiast mówimy o efektywności w odniesieniu do automatyzacji to skłonna jestem przyjąć założenie, że ma to miejsce wtedy, kiedy przy doborze scenariuszy testowych do automatyzacji kierujemy się przede wszystkim możliwie największym prawdopodobieństwem wykrycia błędów. Ten atrybut będzie miał większe znaczenie niż pozostałe: łatwości zmian (ang. evolvable), przykładności (ang. exemplary), czy ekonomiczności (ang. economic).
Zwiększamy efektywność jeśli w całym projekcie dostrzegamy powtarzające się sygnały z testów, które spowalniają czynności albo generują nadmierne obciążenie pracą. Mogą one dotyczyć stricte samej organizacji prac. Przykład: w jednej z firm był taki okres, kiedy odebrano koordynatorom testów uprawnienia do importu scenariuszy testowych do narzędzia, zgłoszenia stały w kolejce i realizowały je dwie osoby.
Podejście do testowania i w ogóle wytwarzania oprogramowania ewoluuje w kierunku zwinności (‘bycia’ Agile). Trend ten owocuje m.in. pojawianiem się na rynku narzędzi, które oprócz funkcjonalności klasycznego zarządzania testami oferują już znacznie więcej. Zawierają bowiem funkcje mogące zastąpić albo znacznie usprawnić dotychczasowe klasyczne planowanie i projektowanie testów, np. pisanie scenariuszy tylko pod jeden typ lub poziom testów albo obsługę zmieniających się parametrów. Przykładowo narzędzie Tosca Tricentis oferuje moduły, na których programiści zaprojektują testy jednostkowe, integracja z Jenkins umożliwi kontrolowanie wydawanych wersji, a kiedy z aplikacji skorzystają analitycy – uda się połączyć zestawy testów z wymaganiami. Możliwe będzie też nagranie sekwencji kroków przy pomocy wbudowanych narzędzi rejestrujących, a następnie odtwarzanie ich niczym testy automatyczne. Jeśli dodamy do tego opcję nagrania kroków procesu biznesowego, to narzędzie-kombo będzie wspierało modną ostatnio robotyzację procesów biznesowych (RPA – Robotic Process Automation). I wszystko w jednym narzędziu. Jest to przykład wsparcia narzędziowego podążającego za trendami, ale tylko właściwe dopasowanie do sytuacji i systemów, które mamy – pracę usprawni i narzędzie będzie rzeczywiście wykorzystywane.
Efektywność w testach ‘by lean’ – to identyfikowanie, ale przede wszystkim wcielanie w życie zmian do elementów, które oddalały nas od osiągnięcia celów testowania albo nie spełniały kryteriów Definition of Done. Wtedy przy kolejnej iteracji albo sprincie będziemy potrafili: robić lepsze oszacowania, bardziej optymalnie przydzielać prace, może zmieniać priorytety, poprawiać komunikację albo wnioskować o dodatkowe testy dymne na krytyczne elementy środowiska testowego. W metodykach zwinnych będziemy to nazywać działaniem w imię największej możliwej wartości dla biznesu.
Gdy naszą aktywność opatrzymy miernikiem stopnia osiągnięcia celu to rzeczywista poprawa wyrażona w liczbach będzie zachętą do bardziej regularnych przeglądów rzeczywiście osiąganej efektywności. Wtedy przekaz z anglosaskiego przysłowia: ” Work smarter not harder” – w testach także znajdzie zastosowanie.