Jak się okazuje, nie zawsze kierowanie się „złotymi zasadami” testowania daje pożądane efekty. Lekceważenie tych reguł również może być fatalne w skutkach, czego dowodzą przykłady znanych firm i instytucji. Jedno jest pewne – błędy oprogramowania wiele kosztują. Na szczęście są sposoby, aby te straty zminimalizować.

Wyobraź sobie, że w wyniku błędu systemu opieki medycznej przestają być aktualizowane historie chorób pacjentów, na podstawie których lekarze wystawiają recepty. Medycy przepisują zatem leki nieadekwatne do zgłaszanych schorzeń, co dla niektórych osób może oznaczać zagrożenie zdrowia, a nawet życia. To nie jest scenariusz filmu science-fiction. Taka sytuacja miała miejsce w 2018 roku w drugiej co do wielkości europejskiej gospodarce. Powód? Bug w systemie dostarczanym dla publicznej opieki zdrowotnej w Wielkiej Brytanii (NHS). Nieprawidłowe recepty otrzymało wtedy ponad 10 tys. osób. Na szczęście nie wiązało się to dla nich z poważnymi konsekwencjami zdrowotnymi. Straty, jakie pociągają za sobą  takie błędy trudno oszacować, bo poza czysto biznesowymi kosztami ich naprawy, konsekwencje reputacyjne mogą być jeszcze bardziej dotkliwe (szczególnie dla firm spoza sektora publicznego). Tylko w Stanach Zjednoczonych straty wywołane wprowadzeniem na rynek słabej jakości oprogramowania w 2018 roku szacowano na 2,8 bln USD

Skutki błędów testerskich

Wagi generowanych w procesie wytwarzania oprogramowania błędów nie lekceważą też specjaliści z branży. W badaniu przeprowadzonym w 2019 roku przez Micro Focus w Stanach Zjednoczonych oceniali oni, jak trzy obszary działania oprogramowania wytwarzanego w metodologii Agile/DevOps: funkcjonalny, wydajnościowy i bezpieczeństwa wpływają na poszczególne obszary działalności firmy. Uznano, że błędy na wszystkich trzech płaszczyznach najbardziej uderzają w dochód firmy, reputację marki oraz wywołują konsekwencje prawne.

Remedium na tę sytuację ma być prężnie rozwijający się rynek testów automatycznych, który – co może zaskakiwać – jest jednocześnie wskazywany jako obszar, który jest dla firm ogromnym wyzwaniem, na co wskazuje najnowszy  „World Quality Report 2019-2020”:

Wśród najczęściej wskazywanych przyczyn znalazły się:

  1. Brak odpowiedniego środowiska testowego i danych.
  2. Nieumiejętność w stosowaniu automatyzacji testów na odpowiednim poziomie.
  3. Trudność w identyfikacji obszarów, na których powinny skupić się testy.

Co znamienne, testowanie zostało wskazane jako największe wyzwanie w zakresie działań podjętych w celu zapobiegania występowaniu defektów w oprogramowaniu:

Dlaczego testowanie jest postrzegane jako tak trudne zadanie? Może to wynikać albo z braku wiedzy, albo nieumiejętności jej zastosowania. Jednym z rozwiązań może być audyt aktualnie podejmowanych w firmie działań, do którego może ci posłużyć poniższa lista: 

Złe strategie testowania, czyli co może generować niepotrzebne koszty

Niedopracowane scenariusze testowe.

Scenariusze testowe powinny powstać w wyniku konsultacji zespołu testerskiego, który tworzy je na podstawie zebranych wcześniej wymagań biznesowych. Już na tym wcześniejszym etapie, czyli rozmów z product ownerami, project managerami i deweloperami, powinna zostać stworzona dokładna dokumentacja produktu. To między innymi ona staje się bazą do stworzenia dokładnych scenariuszy działania (dużą rolę odgrywają też bowiem umiejętności i doświadczenie samych testerów). Solidny plan, wdrażany od początku pracy nad wytwarzaniem oprogramowania zgodnie z ideą shift-left testing, czyli rozpoczęcia testów na najwcześniejszym etapie działań deweloperskich, paradoksalnie ułatwia elastyczne dostosowanie się do zmian charakterystycznych dla podejścia Agile. Testerom łatwiej jest modyfikować już ustalony plan niż działać w chaosie, pogłębianym przez każdy kolejny sprint. Potwierdza to przykład małego software house’u, opisanego w pracy naukowej „’Dobre’ powody organizacyjne dla ‘złego’ testowania: etnograficzne studium testowania w małym software housie” autorstwa D. Martina, J. Rooksby’ego, M. Rouncefielda, I. Sommerville’a. Firma z Wielkiej Brytanii na potrzeby badania została nazwana W1REsys. Wytwarza ona środowiska deweloperskie, które umożliwiają klientom pisanie aplikacji mobilnych. W1REsys zatrudnia siedem osób, w tym czterech programistów. Z powodu braku dedykowanego zespołu testerskiego, wymagania dla nowych produktów lub funkcjonalności powstają albo na bazie zgłaszanego przez klientów zapotrzebowania, albo pomysłów na elementy, które mogą być atrakcyjne dla potencjalnych nowych klientów. Wspomniane pomysły dostarczają przedstawiciele marketingu i sprzedaży, a naukowcy przeprowadzający badanie w firmie stwierdzili, że testowanie opiera się tutaj raczej na propozycjach co należy testować, niż jak to zrobić. Tworzone w W1REsys testy automatyczne nie są zatem częścią ustrukturowanego planu, przez co pozwalają na rozwój jedynie wybranych funkcjonalności. Pomysły na ich udoskonalanie powstają też w trakcie pracy deweloperów, są wynikiem dyskusji na temat obecnego działania systemu. Takie podejście rodzi ryzyko wystąpienia poważnych błędów na produkcji i – jak przyznają autorzy badania – takowe występują, jednak są utrzymywane na akceptowalnym dla firmy poziomie.

Zwiększ swoją efektywność z BugBug

2. Brak dopasowania procesu testowania do sposobu funkcjonowania organizacji.

Przykład firmy W1REsys pokazuje, jak istotne jest dostosowanie zasad efektywnego testowania do możliwości konkretnej organizacji. W większych firmach, które zajmują się prowadzeniem złożonych projektów, postępowanie zgodnie z regułami sztuki jest gwarantem sukcesu. W mniejszych, zmagających się często z brakami kadrowymi, należy dostosować te reguły do realnych możliwości zatrudnionych pracowników. W przeciwnym wypadku będą oni pracować pod ogromną presją czasu i frustracji, że nie udaje się zrealizować wszystkich nałożonych na nich celów. Jak wynika z badania Micro Focus z 2019 roku, najbardziej kosztowne są błędy wykrywane na ostatnim etapie wytwarzania oprogramowania – na produkcji. Takie wyniki uzyskano badając zarówno projekty zarządzane w mniej popularnej już dziś metodyce Waterfall, jak i cieszącej się ogromnym zainteresowaniem metodyce Agile:

 

Według Erica Elliota, który o błędach produkcyjnych napisał cały artykuł dla serwisu Medium.com, koszt naprawy błędu na produkcji może być 100x wyższy od kosztu jego naprawy na etapie projektowania i 15x wyższy od kosztu naprawy na poziomie wdrożenia.

Mniejsze firmy, które nie mogą sobie pozwolić na realizację rozbudowanych scenariuszy testowych, powinny postawić na takie ułożenie zadań, aby były one wykonywane w kolejności od tych najbardziej do najmniej istotnych dla projektu. Wspomniany software house W1REsys z badania zrealizowanego w Wielkiej Brytanii za cel postawił sobie testowanie najczęściej używanych przez klientów funkcjonalności, dzięki czemu udaje jej się odpowiednio zarządzać defektami, które są wykrywane na produkcji. To dobry przykład traktowania testowania nie jako sposobu na doskonałe przetestowanie całości kodu, które w wielu przypadkach jest po prostu niemożliwe, lecz jako sposobu na zarządzanie ryzykiem, które można mitygować dzięki nadaniu odpowiednich priorytetów poszczególnym zadaniom testowym.

  • Ignorowanie znaczenia testów szybkości działania i wydajności aplikacji mobilnych.

Skupienie się na testach funkcjonalności (działa/nie działa) sprawia, że niektóre zespoły lekceważą znaczenie testów szybkości i wydajności. O tym, jak duże mogą być koszty takiej postawy, informuje badanie Dimensional Research z 2015 roku. Użytkownicy aplikacji mobilnych byli w nim pytani m.in. o opinię dotyczącą czasu reakcji. Jak widać na poniższym wykresie, ich oczekiwania są bardzo wysokie – optymalny czas odpowiedzi to według nich 2 sekundy:

80 procent badanych przyznało, że w przypadku problemów z działaniem aplikacji dają jej maksymalnie trzy szanse, a później porzucają na rzecz konkurencyjnych rozwiązań. Co ciekawe, przy wyborze aplikacji obiecywane przez producenta funkcjonalności są stawiane na równi z opiniami na temat jej działania, zamieszczanymi przez innych użytkowników:

Source: Dimensional Research

O tym, jak pozytywne konsekwencje biznesowe przynosi przebudowa aplikacji na szybszą i bardziej responsywną przekonał się w 2017 roku Pinterest, który po jej wdrożeniu odnotował zarówno większy przychód, jak i ruch:

Source: Medium.com

4. Rezygnacja z Test Driven Development.

To podejście, które zakłada stworzenie  testów automatycznych jeszcze przed przystąpieniem do pisania właściwego kodu. Testy na starcie oczywiście nie przechodzą by z biegiem czasu i pisania kolejnych linii kodu dojść do etapu, gdzie wszystkie kończą się pozytywnie. Dzięki temu zwiększa się ilość „bezawaryjnego” kodu; można też dokładnie przemyśleć i zaplanować sposób działania całej aplikacji. Cytowany już wcześniej Eric Elliot na dowód efektywności tej metody, która odstrasza wielu zarządzających kadrą IT ze względu na większe koszty, jakie w przypadku jej realizacji należy ponieść we wstępnej fazie projektu, przytacza następujące obliczenia:

 

Source: Medium.com

W przytoczonym przez Elliota fikcyjnym przykładzie development bez wykorzystania TDD miał kosztować 1000 godzin bez uwzględniania kosztów utrzymania systemu. Dzięki TDD zaoszczędzono 623 godzin, co oznacza miesiąc pracy dla czteroosobowego zespołu.

5. Niedocenianie lub przecenianie testów automatycznych.

Sukces każdego zespołu testerskiego opiera się zarówno na wykwalifikowanych pracownikach, jak i odpowiednio dobranych narzędziach. Testy automatyczne znacznie przyspieszają i ułatwiają pracę, dzięki czemu uwalniają zasoby testerów, którzy mogą skupić się na przeprowadzaniu testów eksploracyjnych lub analizie produktu pod kątem stawianych mu wymagań oraz doświadczenia użytkownika. Zespoły, które z nieufnością podchodzą do narzędzi do automatyzacji lub zawiodły się na programach starszej generacji, mogą preferować testy manualne. Skutkuje to często przeciążeniem pracowników, którzy dodatkowo jeszcze frustrują się koniecznością wykonywania powtarzalnych, nużących zadań. Z drugiej strony testy automatyczne nie są w stanie zastąpić pracownika, który na podstawie wytycznych biznesowych może stworzyć odpowiednie scenariusze testowe lub nawet uzupełnić je o propozycje nowych, ciekawych funkcjonalności. Optymalna strategia testowania pomaga w taki sposób zaprojektować działania testerów, aby mogli oni w pełni korzystać z możliwości, jakie dają narzędzia do testów automatycznych, przy jednoczesnym wykorzystaniu kompetencji poszczególnych pracowników np. w zakresie przeprowadzania manualnych testów eksploracyjnych.

 

Oszczędź do 70% czasu pracy testerów oprogramowania

Niezawodne, kompleksowe oprogramowanie, które usprawnia pracę testerów i programistów.

Zamów newsletter