Po co tyle testów? Czyli rzecz o testowaniu oprogramowania

Czym jest testowanie oprogramowania

Muszę przyznać, że na początku, szukając tytułu dla artykułu, do głowy przychodziły mi mało cenzuralne zwroty. Głównie dlatego, że temat ograniczenia ilości testów wywołuje wiele negatywnych emocji. Po analizie różnych komentarzy na branżowych stronach dochodzę do wniosku, że dzieje się tak z wielu powodów. Zacznę od tego, czym jest testowanie oprogramowania, w tym celu odwołajmy się do definicji ISTQB:

„Proces składający się ze wszystkich czynności cyklu życia, zarówno statycznych, jak i dynamicznych, skoncentrowany na planowaniu, przygotowaniu i ewaluacji oprogramowania oraz powiązanych produktów w celu określenia, czy spełniają one wyspecyfikowane wymagania, na wykazaniu, że są one dopasowane do swoich celów oraz na wykrywaniu usterek.”

Proces ten sam w sobie wskazuje, że naturalną formą rozwoju testów w danym projekcie jest zwiększanie liczby przypadków testowych, a także innych aktywności, które są wykonywane wokół testów.

Testy – liczą się liczby?

Zacznę od liczb. Pracując już ładnych kilka lat w projektach zagranicznych, gdzie samych programistów testów jest 15 (nie mówiąc o całej armii testerów manualnych, programistów itd.), zauważyłem jedną tendencję: liczą się liczby.

Nie jakość wykonywanych testów, ale liczby. Test manager staje się kimś, kto „broni” testów przed osobami zarządzającymi. Management najczęściej zwraca uwagę głównie na koszty, prezentując podejście znane jako: „A po co nam testy, przecież programiści powinni pisać kod bez błędów”.

Takie sytuacje wciąż się zdarzają i nie jest to tylko opowieść pochodząca z odmętów Internetu. To podejście, z którym spotykałem się wielokrotnie przez 10 lat wykonywania testów. Podejście, które… w ogóle mnie nie dziwi – i mówię to bez sarkazmu. Kim jest dziś test manager? To osoba, która ma jakąś wiedzę techniczną, jednak większość swoich umiejętności skupia zupełnie gdzie indziej. Podam przykład, którego doświadczył pewnie niejeden z nas. Klasyczny konflikt interesów studenta i wykładowcy. Student rozkłada swoje siły i czas pomiędzy różne przedmioty, tak by skutecznie osiągnąć swój cel (dostanie się na kolejny rok). Dla wykładowcy z kolei to jego przedmiot jest najważniejszy (wiem, co mówię – byłem po obu stronach).

Manager zarządza projektami tak, jak student zarządza sesją, więc testy są tylko jednym z wielu elementów, i to nisko w hierarchii, bo najważniejsze jest dostarczenie produktu. Aby udowodnić sens wynajmowania określonej liczby testerów, test manager musi pokazać project managerowi dane: ilość przypadków testowych, ilość pokrycia przez automatyzacje, a także ilość znajdowanych błędów, czas zaoszczędzony poprzez automatyzację, ryzyka, potencjalne koszty błędów itp.

Po co nam automatyzacja testów?

Dziś automatyzacja testów stanowi ważne uzupełnienie testów manualnych. Testy automatyczne pozwalają zastąpić dużą ilość testów manualnych i odciążyć testerów oprogramowania oraz zaoszczędzić czas. W przypadku testów automatycznych z perspektywy test managera często najważniejsze jest, ile pokrywają testów manualnych, a szczególnie – ile godzin pracy testerów manualnych zastępują testy automatyczne. Wszystko wydaje się w porządku. Ilość przypadków testowych rośnie, automatyzacja się rozrasta. Przypadki testowe to jakieś 4-5 tys., a automatyzacja pokrywa 1600. Kolejne osoby dołączają do projektu. Statystyki się zgadzają, management jest wniebowzięty.

Utrzymanie testów

I w tym momencie pojawia się nowy problem – utrzymanie rosnącej liczby testów. Presja czasu i narastające skomplikowanie projektu powodują, że z dnia na dzień wszyscy mają coraz więcej zajęć. Release z jednodniowych zamieniają się w tygodniowe testy i pojawia się konieczność sprawdzania, czemu testy automatyczne nie działają. Przy poprawianiu ich okazuje się, że są nieaktualne, a manualny przypadek testowy nieaktualny od 3 miesięcy. Test przechodził, a nagle pada. Nikt nie wie, jak dana funkcja powinna działać, bo zadań w Jirze są tysiące, a samo szukanie odpowiedzi trwa 2 dni. Oczywiście można by się zgłosić do osoby posiadającej wiedzę, ale jej już dawno nie ma w organizacji (w projektach IT rotacja pracowników to chleb powszedni).

Wina testerów i narzędzi?

W takiej sytuacji można pomyśleć, że to wina nieodpowiednich narzędzi, testerów, którzy źle wykonują swoją pracę, a także test managerów. W jakimś stopniu na pewno, jednak przede wszystkim to kwestia skali. 

Są dwie rzeczy, które nie mają ograniczeń ze względu na zasoby. Zakładanie wiecznego wzrostu gospodarki, jak i przyrostu liczby testów. Zarówno managerowie, test managerowie, jak i sami testerzy czy testerzy automatyzujący mają ambicję wykonywania jak największej liczby testów, co jest całkowicie naturalne. Niestety, ogranicza ich rzeczywistość. W pewnym momencie wykonywania testów liczba istniejących już przypadków testowych powoduje dość znaczące problemy.

Testy po prostu trzeba utrzymywać. Pokrycie przez testy automatyczne manualnych przypadków testowych w teorii ma zdejmować z barków testerów manualnych konieczność opieki nad daną częścią. Jednak ten cel nie zostaje osiągnięty, jeżeli przypadki manualne nie są stale aktualizowane względem nowych funkcjonalności, a wraz z nimi testy automatyczne.

Testy fałszywie pozytywne

Jaka może być skala problemu? To jest bardzo niebezpieczne pytanie. Łatwo wykazać przypadki testowe, które przestają działać. Takie testy po prostu „padają”, a weryfikuje się je, przechodząc manualnie, więc podczas ich wykonywania można je poprawić. W wypadku testów automatycznych również pokazują negatywny wynik, więc też pojawia się podobna ścieżka, choć trochę dłuższa. Niestety, widziałem bardzo dużo projektów, które na tym poprzestawały. Jest jednak dużo bardziej szkodliwe zjawisko. A co, jeżeli test przechodzi i jest nieaktualny? Liczba testów fałszywie pozytywnych w projekcie nastawionym na ilość testów, a nie na ich jakość, jest czymś, czym zwyczajnie nie sposób zarządzić.

Testy oprogramowania – ilość czy jakość?

Kolejną konsekwencją jest spadająca jakość testów, zarówno kodu, jak i samych przypadków testowych. Widać to bardzo dobrze na przestrzeni czasu, w jakim dane przypadki są pisane. Pierwsze przypadki testowe są szczegółowe, zawierają wszystko, co potrzeba. Kolejne są już tylko zgrubnymi opisami tworzonymi na szybko, a ich aktualizacja to problem. W kodzie pojawia się coraz większy bałagan, a code review testów zamienia się w pobieżne spojrzenie na kod. Testerzy nie mają czasu i wszystko zamienia się w równię pochyłą, gdyż im więcej testów, tym więcej problemów, a management oczekuje stałego przyrostu przypadków testowych.

Oczywiście wszyscy są tego świadomi i próbuje się rozwiązywać ten problem na wiele sposobów. Czy każdy jest jednak skuteczny?

Za dużo testów – możliwe rozwiązania

Błędna ucieczka w BDD

Aby rozwiązać problem, wykorzystuje się czasem Behaviour-Driven Development. O ile wydaje się to jednym z ciekawszych kierunków, w wielu projektach przynosi skutek wręcz odwrotny. BDD mówię „tak”, jeśli wdraża się to rozwiązanie dla wszystkich. „Nie” – jeżeli tylko dla testerów automatyzujących. W wielu projektach widziałem podejście polegające na tym, że testerzy manualni piszą scenariusze metodą klasyczną, a automatyzujący w BDD. Strata czasu na kolejną warstwę abstrakcji jest kroplą przelewającą czarę goryczy. W BDD często test managerowie upatrują innego ratunku. Otóż zdaje się, że jeżeli zautomatyzowaliśmy dużą część kodu i mamy grupę stepów, które już działają, to może automatyzować każdy, natomiast tak naprawdę stepy stają się nowym pseudojęzykiem, który staje się niepotrzebny, jeśli mamy dobrze napisany kod.

Przeczytaj także: Organizacja data driven – strategia dla firm przyszłości

Aby rozwiązać problem skali, przyjmuje się do pracy kolejnych testerów – często o bardzo małej wiedzy i doświadczeniu, gdyż kryterium jest cena. Managerowie łudzą się, że dzięki wykorzystaniu BDD można rozwijać automaty tylko poprzez ponowne używanie gotowych kroków napisanych w języku naturalnym. Często w kopiowaniu kodu osoby takie mogą sobie bardzo dobrze poradzić, jednak nie każdy ma talent i predyspozycje do nauki automatyzacji w ten sposób. Według mnie jest to błędne założenie. Stwierdzam wręcz, że jeżeli tester, patrząc na nazwę testów i wykorzystywane metody napisane w Selenium, nie potrafi zrozumieć, co robi dany test, to nie ma on szans na rozwój. Takie rozwiązanie powoduje, że do projektu dołącza osoba, którą trzeba się opiekować, spędzać z nią czas – a warunki projektu nie stwarzają jej możliwości rozwoju.

Można do projektu dołączyć doświadczonych testerów, którzy mają usprawnić kod automatyzacji lub wesprzeć zespół w testach manualnych. Jest to rozwiązanie istotne, ale nadal nie rozwiązuje problemu ciągłego przyrostu testów, które też będzie trzeba usprawniać.

Odpowiedzialność za testy

Rozwiązanie, któremu jestem przychylny, a które coraz rzadziej można zaobserwować, to zwiększenie udziału części „test managerskiej”. Osoba, której rola dość często ogranicza się do obrony testów przed managementem i walki o kolejne zasoby, musi wrócić do korzeni. Niestety, takie elementy jak tworzenie strategii testów, planowanie i koordynacja testów oraz raportowanie ich wyników stają się reliktem. Nie chodzi o to, żeby w projekcie był to jeden jedyny człowiek, który myśli o wszystkim. Odpowiedzialnym test managerem powinien być każdy związany z testami. Aby jednak takie podejście miało szanse powodzenia, trzeba przyjąć początkowe założenie: „Nie, nie chodzi o ilość testów, ale o ich jakość i odpowiednie zarządzanie”.

Dla wielu osób ograniczanie testów będzie herezją, bo wydaje się, że cały świat mówi: „Więcej testów!”. Jednak nie, nie o to chodzi. Chodzi raczej o to, aby lepiej planować wykonywane prace, a także, aby tester oprogramowania brał odpowiedzialność za plan testów. Ja jako osoba testująca dany obszar wiem, które testy są istotne i co przyniesie wartość klientowi. Biorę odpowiedzialność za to, jakie wykonuję przypadki testowe, jak również za to, co automatyzuję. Pewne obszary testów na danym etapie projektu mogą być nieistotne. Sensowne wydaje się włożenie wysiłku nie tylko w wykonywanie testów, ale przeanalizowanie zasadności.

Przykładowo, automatyzowanie każdej ścieżki w wielu wypadkach nie ma sensu. Wiele ścieżek pokrywa podobne obszary, nie ma potrzeby wykonywać odrębnych przypadków. Wróćmy do podstaw metod i technik testów, które najczęściej tak naprawdę nie odpowiadają nam na pytanie „Jak najlepiej przetestować”, ale „Jak wykonać testy skutecznie, najmniejszym nakładem pracy, przyjmując ryzyko wynikające z tej metody”. Nie wymagajmy jednak od test managera, by powiedział nam, co mamy zrobić. To testerzy powinni dostarczać informację test managerowi, ile i jakie testy w danym czasie wykonują w tym określonym releasie. Test manager nie pracuje z daną funkcjonalnością i nie ma tej wiedzy.

Bardzo przydatna może się okazać analiza wpływu – obszary, które są już bardzo dobrze przetestowane, a także stabilne, często nie potrzebują ponownych testów. Określić można to na podstawie analizy wpływu. Jako testerzy musicie wykonywać ją przy każdym nowym Sprincie. Taka analiza powinna odpowiadać na pytania:

• jak nowe funkcje wpłyną na stare,
• czy potrzebujemy aktualizacji testów,
• jakie testy, w jakich obszarach należy wykonać, aby mieć pewność, że wszystko działa poprawnie,
• które testy automatyczne w tym pomogą, które testy należy zautomatyzować, które przygotować w postaci manualnych skryptów, a które wykonać eksploracyjne, tylko pozostawiając dowód w postaci checklist.

Przeczytaj także: Testerze, eksploruj

Zarządzanie ryzykiem

Przy wprowadzaniu nowego podejścia pojawi się na pewno strach w postaci obawy przed „efektem motyla”, związanym z regresją, jednak tester powinien myśleć o testowaniu jak o zarządzaniu ryzykiem, gdyż testy tym właśnie są. Obszary większego ryzyka oczywiście muszą być objęte odpowiednimi zestawami testów, a pole do działań mamy w obszarze mniejszego ryzyka. Nie bójmy się mniej testować, stawiając na lepszą jakość wykonanych testów, a także ich stabilność. Błędy zawsze będą się pojawiać, pytanie brzmi: jak bardzo istotne i szkodliwe jest skupianie się na wszystkich obszarach w takim samym zakresie.

Podsumowanie

Dziś każdy tester powinien być po części test managerem. Każdy powinien brać odpowiedzialność za decyzje, a także zarządzanie swoimi siłami w danym projekcie. Zatem kim w czasach Agile powinien być test manager? Osobą agregującą informacje, przedstawiającą wyniki managementowi, a także wspierającą testerów w podejmowaniu decyzji o braniu na siebie odpowiedzialności. Test manager musi też umieć wytłumaczyć zarządowi, że jeżeli posiadamy 1600 skryptów testów automatycznych, z czego 600 jest bezwartościowych, to nie jest to podstawa do dokładania kolejnych 600. A raczej zwolnienia tempa, poprawienia jakości i zastanowienia się, jakie testy są dla nas zasadne. Podsumowując, zarówno test manager, jak i tester nie mogą się obawiać zadać pytania: „Po co nam tyle testów?”.

Przeczytaj także: Quality Assurance – zapewnij jakość w projektach IT