Testy automatyczne — dlaczego oszczędzą 30% budżetu

Testy automatyczne to pozycja, którą przy cięciu budżetu skreśla się jako pierwszą — bo nie widać ich w interfejsie i nie da się ich pokazać zarządowi. Rachunek wygląda jednak inaczej niż intuicja: koszt naprawy błędu rośnie kilkudziesięciokrotnie w zależności od momentu, w którym zostanie wykryty. Testy są sposobem, żeby wykrywać go możliwie wcześnie.

Autor: zespół Convert Studio — software house z Kielc i Krakowa, projektujemy aplikacje webowe, sklepy i wdrożenia AI dla firm.

Skąd bierze się oszczędność

Koszt naprawy błędu zależy przede wszystkim od tego, kiedy zostanie znaleziony. Błąd wykryty przez test uruchamiany automatycznie kosztuje kilkanaście minut — programista ma jeszcze w głowie kontekst zmiany. Ten sam błąd zgłoszony przez klienta po trzech miesiącach wymaga odtworzenia sytuacji, przejrzenia historii zmian, poprawki, testów i wdrożenia poza planem.

Ostatni wiersz jest najkosztowniejszy i najczęściej pomijany w kalkulacjach. Błąd w wyliczaniu rabatu, który działał niepoprawnie przez kwartał, oznacza nie tylko poprawkę w kodzie, ale i konieczność ustalenia, które dokumenty wymagają korekty.

Rodzaje testów i ich opłacalność

Proporcje mają znaczenie ekonomiczne. Testy interfejsu są najbardziej przekonujące — odtwarzają dokładnie to, co robi użytkownik — ale też najdroższe w utrzymaniu i najbardziej podatne na fałszywe alarmy przy drobnych zmianach wyglądu. Zestaw oparty głównie na nich staje się po roku obciążeniem, które zespół zaczyna ignorować.

Najlepszy stosunek korzyści do kosztu dają testy jednostkowe reguł biznesowych: wyliczania cen, rabatów, podatku, terminów i limitów. To właśnie tam błędy są najbardziej kosztowne, a testy najtańsze w napisaniu i najstabilniejsze w czasie.

Co warto pokryć testami w typowej aplikacji

• Wyliczanie cen, rabatów i podatku — najczęstsze źródło kosztownych błędów.
• Proces składania zamówienia od koszyka po potwierdzenie płatności.
• Logowanie i uprawnienia — w tym scenariusz próby dostępu do cudzych danych.
• Integracje — zachowanie przy braku odpowiedzi systemu zewnętrznego i przy odpowiedzi błędnej.
• Powiadomienia zwrotne od operatora płatności, łącznie z odebraniem tego samego powiadomienia dwukrotnie.
• Reguły dostępności w systemach rezerwacyjnych.
• Import i eksport danych — w tym pliki niepoprawne i niepełne.
• Migracje struktury bazy uruchamiane na kopii danych zbliżonej do produkcyjnej.

Uruchamianie testów — bez tego nie ma korzyści

Testy, które trzeba uruchomić ręcznie, przestają być uruchamiane po kilku tygodniach. Warunkiem opłacalności jest automatyczne wykonanie przy każdej zmianie w repozytorium i zablokowanie wdrożenia, gdy któryś scenariusz zakończy się niepowodzeniem.

• Uruchomienie przy każdej zmianie, z wynikiem widocznym w narzędziu do przeglądu kodu.
• Blokada wdrożenia przy niepowodzeniu — bez możliwości pominięcia „na tę jedną zmianę".
• Czas wykonania poniżej dziesięciu minut dla zestawu podstawowego; dłuższe scenariusze uruchamiane nocą.
• Natychmiastowa reakcja na test niestabilny — scenariusz, który raz przechodzi, a raz nie, podważa zaufanie do całego zestawu.
• Dane testowe generowane automatycznie, nigdy kopiowane z produkcji.

Zapisy w umowie z wykonawcą

Jeżeli zależy Ci na testach, muszą być elementem zakresu, a nie deklaracją. Bez zapisu w umowie zostaną pominięte jako pierwsze przy presji terminu — i będzie to decyzja racjonalna z punktu widzenia wykonawcy.

• Lista procesów objętych testami, uzgodniona na etapie analizy.
• Automatyczne uruchamianie testów przy każdej zmianie jako część środowiska wdrożeniowego.
• Przekazanie testów wraz z kodem — są częścią przedmiotu odbioru.
• Wymóg dopisania testu do każdej naprawy błędu zgłoszonego w okresie gwarancji.
• Dokumentacja uruchomienia zestawu przez inny zespół.

Ostatni punkt bywa niedoceniany, a jest kluczowy przy zmianie wykonawcy. Zestaw testów, którego nowy zespół nie potrafi uruchomić, nie ma żadnej wartości.

Kiedy testy się nie opłacają

Uczciwe podejście wymaga wskazania sytuacji, w których nakład nie zwraca się w rozsądnym czasie.

• Wersja pilotażowa budowana po to, żeby sprawdzić hipotezę i prawdopodobnie zostać przebudowana.
• Narzędzie o krótkim czasie życia — kampania, konkurs, jednorazowe wydarzenie.
• Warstwa czysto prezentacyjna bez logiki biznesowej.
• Projekt bez planów rozwoju, oddany i niezmieniany.

Nawet w tych przypadkach warto jednak pokryć testami obsługę płatności, jeśli występuje. Błąd w rozliczeniu kosztuje tyle samo niezależnie od tego, jak krótko aplikacja miała żyć.

Testy w projekcie przejmowanym po innym wykonawcy

Sytuacja spotykana najczęściej: system działa, dokumentacji nie ma, autorzy są nieosiągalni, a każda zmiana rodzi obawę, że coś przestanie działać w miejscu, o którym nikt nie pamięta. Pisanie testów od zera dla całej aplikacji jest wtedy nierealne kosztowo, ale istnieje podejście pośrednie.

Polega ono na obejmowaniu testami wyłącznie tych fragmentów, które są dotykane. Zamiast planować pokrycie całości, zespół przyjmuje zasadę: każda zmiana w istniejącym kodzie wymaga wcześniejszego napisania testu opisującego jego obecne zachowanie.

• Test przed zmianą — opisuje, jak kod działa dzisiaj, zanim zaczniesz go modyfikować.
• Test przy każdej naprawie błędu — odtwarza sytuację, w której błąd występował.
• Pokrycie procesów krytycznych w pierwszej kolejności, niezależnie od planu zmian.
• Scenariusze końcowe dla dwóch, trzech najważniejszych ścieżek użytkownika.
• Brak celu procentowego — pokrycie rośnie samo, w miejscach, które faktycznie się zmieniają.

Dlaczego to działa lepiej niż plan całościowy

Kod, który nie jest zmieniany od dwóch lat i działa poprawnie, nie potrzebuje testów — nie ma skąd wziąć się w nim regresja. Testy są potrzebne tam, gdzie coś się zmienia, a to zwykle niewielka część systemu.

Takie podejście ma też zaletę organizacyjną: nie wymaga osobnego budżetu ani zgody na projekt, którego efektu nie widać w interfejsie. Koszt rozkłada się na bieżące zadania, a po kilku miesiącach najczęściej zmieniane fragmenty systemu są objęte testami. To zwykle dokładnie te fragmenty, w których wcześniej powstawało najwięcej błędów.

Podsumowanie

Testy automatyczne to nie kwestia dojrzałości technicznej zespołu, lecz rachunku ekonomicznego. Podnoszą koszt wytworzenia o kilkanaście do trzydziestu procent i obniżają koszt utrzymania o połowę, przy czym efekt jest tym większy, im dłużej system żyje i im częściej się zmienia.

Praktyczne podejście polega na pokryciu procesów, których awaria kosztuje pieniądze, oparciu zestawu na testach jednostkowych reguł biznesowych i uruchamianiu wszystkiego automatycznie przy każdej zmianie. Zestaw obejmujący dziesięć krytycznych scenariuszy i faktycznie uruchamiany jest wart więcej niż setka testów, których nikt nie sprawdza.