Ile zaoszczędzisz, jeśli Twój Software House wprowadzi testy już na wczesnym etapie software developmentu?

Wydawać by się mogło, że testuje się rzeczy gotowe. Bo jak przetestować coś, co nie jest ukończone? Albo jeszcze lepiej – jest dopiero w fazie zbierania specyfikacji! Okazuje się jednak, że odpowiednie umiejscowienie testów w procesie software developmentu realnie wpływa na ostateczną cenę i harmonogram projektu. Dlatego jeżeli uważasz, że im później testerzy zaczną swoją pracę, tym więcej zaoszczędzisz (w końcu przepracują mniej godzin, prawda?), to jest to dobry moment, żeby zmienić swoje zdanie o 180 stopni.

Krok w prawo czy w lewo?

W zamierzchłych czasach software developmentu (czyli kilka lat temu), świadomość w zakresie testowania oprogramowania była zdecydowanie niższa niż obecnie. Za normę uważało się przesuwanie testów w prawo (shift right) w cyklu życia oprogramowania, a więc na późne fazy projektowe. Zespół definiował wymagania i zaczynał pracę nad kodem, a kontrola jakości następowała dopiero po wytworzeniu jakieś większej części aplikacji. Niestety generowało to sporo problemów.

Poślizgnięcie we wcześniejszych fazach projektu potrafiło boleśnie odbić się na jego późniejszych etapach. Czasem developerzy musieli przepisywać całe funkcjonalności, a to negatywnie wpływało na budżet i harmonogram projektu. Nie mówiąc już o obniżeniu nastrojów w zespole i potencjalnych napięciach na linii developer-tester.

Source: https://www.reddit.com/r/ProgrammerHumor/comments/tcomip/at_the_end_of_the_day

Dzisiaj mamy świadomość, że tester nie jest zwykłym “klikaczem”, którego należy zaangażować dopiero w końcówkę projektu, żeby przeklikał gotową aplikację. Jego rolą jest zapewnienie jakości na każdym etapie wytwarzania oprogramowania, a więc im szybciej dołączymy go do zespołu, tym lepsze osiągniemy efekty. Tym samym pojawiło się nowe podejście: przesuwanie testowania w lewo (shift left), czyli na wczesne etapu cyklu życia oprogramowania. I nie chodzi tu wyłącznie o testy, a właśnie o jak najszybsze zaangażowanie w projekt samego testera.

Jak umiejscowienie testów w procesie wytwarzania oprogramowania wpływa na cały projekt IT?

Stare podejście — przesunięcie testowania w prawo:

• Tester: zadowolony, bo znajduje błędy
• Developer: płacze, bo naprawa będzie kosztować go wiele pracy
• Project Manager: zły, bo musi poinformować klienta
• Klient: wkurzony, bo projekt ma opóźnienia

Nowe podejście — przesunięcie testowania w lewo:

• Tester: zadowolony, bo znajduje błędy
• Developer: zadowolony, bo ma szanse od razu je naprawić
• Project Manager: zadowolony, bo powie klientowi, że wszystko idzie zgodnie z harmonogramem
• Klient: zadowolony, bo projekt nie ma opóźnień

Wczesne testowanie. Dlaczego warto?

Uruchamianie testów w późnych fazach software developmentu nieodzownie wiąże się podwyższonych ryzykiem wystąpienia problemów projektowych i produktowych.

Przyjrzyjmy się zagrożeniom:

• Niewielkie zaangażowanie testerów w projekt, a co za tym idzie, słabsza kontrola jakości budowanego oprogramowania;
• Wszelkie defekty (zarówno od strony wymagań, jak i kodu) znajdywane są późno. Zazwyczaj już po wdrożeniu;
• Czasu na naprawę znalezionych bugów jest mało. Prace przesuwane są na późniejsze wersje, a to obniża jakość oprogramowania i zmusza do zaciągania długu technicznego;
• Naprawa błędów staje się trudniejsza, bardziej czasochłonna i droższa.

Za to przesunięcie testów w lewo umożliwia testerowi zadbanie o zapewnienie wysokiej jakości tworzonego rozwiązania. Oczywiście na jednego testera nie spada cała odpowiedzialność za projekt, ale jest on ważnym wsparciem dla zespołu. My, pracując w SCRUM, znajdujemy przestrzeń dla testerów już w momencie tworzenia Backlogu i przez wszystkie następne etapy cyklu życia oprogramowania:

• Tworzenie Backlogu (testy historyjek, testy makiet, testy specyfikacji, testy dokumentacji, DOR – PASS);
• Planowanie (planowanie podzadań, wycena, wspólne wykrywanie zagrożeń, wskazywanie wąskich gardeł, nadawanie priorytetów);
• Development (przygotowywanie scenariuszy i kampanii testowych, sygnalizowanie problemów);
• Testy (egzekucja testów, identyfikacja scenariuszy do testów dymnych i automatyzacji, dbałość o jakoś budowanej aplikacji, wykrywanie i eliminacja testów, DOD – PASS);
• Wdrożenie (wsparcie testów klienta, kontrola stabilizacji systemu, kontrola funkcjonalności i ich działania w zgodzie z wymaganiami oraz specyfikacją).

Co daje takie podejście?

• Tworzymy całościową strategię testowania dla wszystkich obszarów kontroli jakości;
• Wykrywanie nieścisłości już na etapie Backlogu przyśpiesza realizację całego projektu;
• Tester wspiera zespół na etapie planowania, co pozwala skuteczniej wykrywać potencjalne zagrożenia i wąskie gardła projektu;
• Wprowadzamy do projektów testowanie statyczne, które wpiera weryfikację wymagań oraz pozwala wyszukać defekty przed kompilacją kodu;
• Ostateczny koszt znajdywania i naprawy błędów jest niższy.

Wczesne testowanie kluczem do sukcesu

Można się więc zastanowić: dlaczego tester nie jest obowiązkowym członkiem każdego zespołu developerskiego i z automatu nie bierze udziału w projekcie już od samego jego startu? Wynika to po pierwsze z braku świadomości, a po drugie z pozornie wyższych kosztów. Wydawać by się mogło, że włącznie testera do projektu dopiero pod sam koniec będzie najzwyczajniej w świecie tańsze. Jednak nic bardziej mylnego!

Na początek przykład z zewnętrznego źródła. Już w 2002 roku NIST opublikował badanie, w którym prześledzono koszt naprawy błędów w różnych fazach projektu IT (realizowanego w tradycyjnej metodyce Waterfall). Jak widać, naprawa błędu wykrytego dopiero na produkcji wychodziła 30 razy drożej niż w sytuacji, kiedy błąd znaleziony został podczas fazy planowania i analizy wymagań.

Source: https://dzone.com/articles/quality-is-the-answer  

Skąd taka różnica w kosztach? Tak jak wspominaliśmy, im później znaleziony błąd, tym więcej pracy przy jego naprawie (tym samym godzin pracy developerów). Uwzględnione zostały także koszty opóźnień projektu i łatania długu technicznego.

Pokusiliśmy się również o własny przykład. Dane zostały zebrane z naszych projektów, zakończonych już kilka lat temu. Projekty realizowane były w metodykach zwinnych, ale nasza świadomość odnośnie testowania była na pewno niższa niż w obecnej chwili.

Jak widać, wyniki są bardzo zbliżone do powyżej wspomnianych badań. Doszliśmy do tożsamych wniosków — nawet niewielka liczba błędów wykryta na produkcji powoduje duży wzrost kosztów. Mimo tego, że większość błędów wykryliśmy we wczesnych etapach developmentu, to te kilka przeoczeń mocno uderzyło w końcowy budżet. Koszty naprawy wynosiły prawie 5 razy więcej niż naprawa błędów we wczesnych etapach.

Testować czy nie testować?

Mamy nadzieję, że te konkretne liczby przemawiają do wyobraźni i udowadniają, że testy warto prowadzić praktycznie od samego początku cyklu życia oprogramowania. Tester powinien być częścią projektu już na etapie specyfikacji i ściśle współpracować z analitykiem czy architektem. Doświadczony tester już w momencie czytania specyfikacji i weryfikacji spójności wymagań będzie w stanie wychwycić pierwsze nieprawidłowości.

Czy zawsze da się znaleźć i naprawić wszystkie błędy, tak żeby żaden nie trafił na produkcję? Nigdy nie ma na to 100% gwarancji. Jednak stale rozwijamy się w tym kierunku, żeby minimalizować ryzyka projektowe i w jak najbardziej wydajny oraz bezpieczny sposób podchodzić do procesu wytwarzania oprogramowania.