Jak drogi jest Twój bug? – czyli o sztuce przepalania pieniędzy
Czy przeciwdziałanie powstawaniu błędów jest tak samo ważne jak wykrywanie ich podczas testowania, jaki jest finalny koszt błędu? Jak możemy przeciwdziałać powstawaniu błędów już na samym początku, w momencie kiedy dochodzi do tworzenia wymagań i ich analizy.
Często na początku drogi jako tester/QA panuje przeświadczenie, że od pierwszego dnia pracy będę testował i wykrywał błędy, które następnie zgłoszę do programistów.
Przychodzi jednak na myśl pytanie, czy jest to najskuteczniejsza droga do zapewnienia wyższej jakości produktu. Czy QA może angażować się na wcześniejszych etapach prac nad daną funkcjonalnością?
Poniesione koszty
Zacznijmy od tego, że naprawa tego samego błędu może mieć różną cenę. Wszystko zależy, na jakim etapie błąd zostanie wykryty. Głównymi etapami gdzie takie wykrycie błędu może mieć miejsce jest:
- czas przed implementacją
- podczas implementacji
- podczas testów
- na produkcji
W zależności czy będziemy bliżej fazy przed implementacją, czy na produkcji koszt usunięcia tego samego błędu będzie się znacząco różnił.
Błędy znalezione w wymaganiach/dokumentacji – czas przed implementacją ($)
Jak znaleźć błędy przed implementacją? Sposobów jest wiele, najprostszym jest sięgnięcie po dokumenty, które są przygotowane i przeanalizowanie ich. Czasem jeśli tester/QA jest już w projekcie jakiś czas niektóre rzeczy/aspekty, które nie są spójne, z dotychczasową implementacją od razu rzuca się w oczy.
Wtedy potencjalny błąd bądź niespójność możemy naprawić dodatkowymi pytaniami do klienta i uzyskaniem odpowiedzi, że w funkcjonalności X coś nie może zadziałać w dany sposób przykładowo ze względu na istniejącą już logikę bądź będzie to wymagało dużych zmian w innych obszarach aplikacji.
Wyrycie takich aspektów przez napisaniem pierwszej linijki kodu danej implementacji jest najtańszym i najlepszym ze sposobów na wykrycie aspektów, które mogą doprowadzić do powstawania błędów.
Błędy znalezione podczas implementacji/powstałe podczas implementacji ($$)
Jeśli nasze wymagania zaczną być implementowane może się okazać, że:
- programista odkrył niespójne wymagania, które weszły już do implementacji
- na podstawie poprawnych wymagań powstał kod, który zawiera błędy
W przypadku pierwszego puntu jest to nasza strata, ponieważ musimy wracać z wymaganiami do klienta. Trzeba poprawić daną logikę sprawdzić, czy jest spójna z pozostałymi funkcjonalnościami.
Taki scenariusz zawiera jednak dużą wadę. Zabiera czas i możliwe, że zatrzyma też na pewien czas proces implementacji do czasu wyjaśnienia wszystkich nieścisłości.
Drugą możliwością jest fakt, że na podstawie poprawnych wymagań programista stworzy kod, który zawiera błąd. W teorii przed wypuszczeniem takiego przypadku powinny go uchronić:
- testy automatyczne – jednostkowe/integracyjne/e2e
- code review
- statyczna analiza kodu
Niestety nie zawsze takie błędy zostaną wykryte przez te procesy. Wtedy kod zawierający błąd trafi do testów.
Błędy znalezione podczas testów ($$$)
Jest to ostatnia linia obrony przed wypuszczeniem błędnego kodu na produkcję. Testerzy próbują „złamać” aplikację, która powinna przejść testy. Jest to etap gdzie dana implementacja, często może jeszcze wrócić do developerów.
Minusem znalezienia błędów na tym etapie jest zdecydowanie czas. Istnieje możliwość, że podczas wykonywanych testów przez testerów developer zajmuje się już innym ticketem.
Powrót do wytwarzanej już funkcjonalności to zdecydowanie kolejna inwestycja czasowa. Czasem może się okazać, że błędy znalezione na tym etapie będą pokłosiem wymagań zawierających błędy → implementacji na podstawie wymagań z błędami. W taki proces często trzeba będzie jeszcze angażować klienta. Inną możliwością jest błąd stworzony przez programistę.
Kluczowym aspektem podczas testów jest to ile rzeczy uda nam się znaleźć przed wypuszczeniem kodu.
Błędy znalezione na produkcji ($$$$$$)
To najdroższy rodzaj błędów, jaki może się nam przydarzyć. Często zdarza się, że o produkcyjnych błędach dowiemy się dopiero po pewnym czasie od wdrożenia (część błędów nie jest widoczna na pierwszy rzut oka).
Można starać się minimalizować czas ich znalezienia, stosując odpowiednie narzędzia, które powiadomią nas w formie raportu o błędach występujących na produkcji. Koszty usunięcia takich błędów często są bardzo kosztowne.
Naprawianie takich błędów jest często kosztowne dla biznesu, może okazać się, że przyniesie finansowe straty o większych wartościach niż cała inwestycja w zapewnienie jakości w projekcie.
Produkcyjne błędy są też kosztowne dla zespołu developerskiego/QA. Często trzeba zrobić dochodzenie, co tak naprawdę generuje dany błąd, poświęcić czas na napisanie poprawki, a następnie dochodzi do tego jeszcze energia poświęcona we wdrożenie danej poprawki na produkcje.
Finalne koszty błędu
Koszt wykrycia tego samego błędu przed implementacją a na produkcji mogą być diametralnie różne. Ważne więc aby testować nasz projekt już na etapie wymagań/dokumentacji przed implementacją.
Warto też zadać sobie pytanie, czy nasz obecny sposób zapewniania jakości to optymalna droga w aspektach ekonomicznych i procesowych zapewniająca jakość.
Czasami też przyda się chwila refleksji na temat procesu, w którym pracujesz, czy jest on najlepszy, na jaki możemy sobie pozwolić, czy jednak możemy wdrożyć działania, które przybliżą nas do wykrywania błędów bliżej powstawania wymagań/dokumentacji.
