W tym poście opiszę, po co są testy, czym są środowiska testowe, w jakim celu się je stosuje i jaką wartość wnoszą do rozwoju oprogramowania. To ważne zagadnienie, które zajawkowo poruszam we wpisie drugim mojej serii o tym, dlaczego Scrum Master musi być techniczny.
Testy, na co to komu?
Każdy z nas miał okazję korzystać z jakiegoś oprogramowania: apki na telefonie, stronki internetowej, programu na kompie. Ile razy mieliście okazję z czegoś korzystać i okazało się, że coś nie działa jak powinno? Niesmak pozostał, no nie?
Przypomina mi się pewna anegdotka, kiedy pewnego pięknego dnia otrzymałam powiadomienie mailowe od firmy kurierskiej, że mogę przełożyć datę dostawy, jeśli wyznaczona data mi nie pasuje. Wystarczy ściągnąć apkę na telefon, zakładasz konto, zmieniasz datę i gotowe. Jako że coś mi wypadło w ten dzień, kiedy miał być kurier z moją wyczekiwaną paczką, to nie ukrywam — skusiłam się na takie nowoczesne podejście proponowane przez firmę kurierską. Pomyślałam: O! W końcu jakaś "nowoczesna" firma wychodząca naprzeciw potrzebom swoich klientów. Super!
Wzięłam się do roboty i pobrałam apkę, przeszłam proces rejestracji i na ostatnim kroku... oniemiałam. Pojawił się komunikat informujący mnie, że aby zweryfikować prawdziwość moich danych, prześlą mi kod aktywacyjny pocztą. I nie, nie chodziło o pocztę mailową, tylko taką tradycyjną. Zagotowało się we mnie i pierwszy raz w życiu napisałam recenzję aplikacji w Google Play. Nadmienię, że po tej historii nie korzystam z usług tego przewoźnika.
Spróbujesz zgadnąć, o jaką firmę chodzi? Czy to był bug (to zapożyczenie z angielskiego tłumaczymy jako "błąd", powszechnie używamy tego zwrotu w IT)? Nie. Tak po prostu zaprojektowano ten proces rejestracji. Przecież mogli weryfikację przeprowadzić przy użyciu adresu mailowego czy numeru telefonu, które w trakcie rejestracji trzeba było podać tak czy siak. Testerzy na pewno sprawdzili, że działa według przyjętych kryteriów akceptacyjnych i w ten oto sposób aplikacja trafiła na produkcję, do klientów. Pewnie teraz się zastanawiasz, po co opowiedziałam Ci tę historię. Otóż:
Z moich dobrych doświadczeń ze współpracy z testerami oprogramowania, wiem, że wróciliby do właściciela biznesowego tej aplikacji, że wdrażany proces rejestracji odbiega od ogólnie przyjętych standardów. W dobie dzisiejszej cyfryzacji, każda firma chce uniknąć czarnego PR-u lub utraty klientów na rzecz konkurencji.
Na etapie testów z użytkownikami na pewno wróciłaby informacja zwrotna, że funkcjonalność budzi duże niezadowolenie z jej działania. Ba, jestem skłonna zaryzykować stwierdzenie, że spadłby poziom konwersji. Konwersji dla rejestracji, czyli tego ilu użytkowników zarejestrowanych potem aktywnie korzystało z tej aplikacji. A to przekłada się na wyniki finansowe. Rozwój i utrzymanie aplikacji to jednak spory koszt ;).
Zatem podsumowując, mój przydługi wywód, testy służą do:
wyłapywania błędów (potocznie zwanych bugami) w tworzonym oprogramowaniu, czyli sytuacji, w których coś nie działa tak jak powinno (może to dotyczyć tej testowanej funkcjonalności bądź innych części systemu),
zbierania informacji zwrotnej,
weryfikacji doświadczeń użytkownika, czyli jak użytkownik ocenia dany proces i jaki to będzie on miał efekt na korzystanie z danej funkcjonalności,
weryfikacji, czy parametry aplikacji pozostają bez zmian lub, czy zmiany są akceptowalne (np. czy ładowanie strony nie zwolniło poza przyjęte normy).
Środowiska testowe
Aby aplikacja trafiła na środowisko produkcyjne, czyli do regularnego korzystania przez użytkowników, musi ona przejść przez szereg innych środowisk. Każda firma ma swoje realia, technologie, wymogi, więc liczbę środowisk dostosowuje pod siebie.
Najczęściej spotykany jest zbiór 3 środowisk, aczkolwiek zdarza się ich nawet 5 czy 6.
Te są najpopularniejsze:
Środowisko deweloperskie
Często, kiedy opowiadam, czym jest środowisko deweloperskie, to śmieję się, że to tutaj dzieje się magia ;). Właśnie na tym środowisku programiści tworzą nowe funkcjonalności. To oznacza, że aplikacja ma te same funkcjonalności, co produkcja + nowe, które jeszcze nie są dostępne dla użytkowników. Najczęściej nie ma podpiętej bazy danych. Tutaj pisane są testy jednostkowe (w innym wpisie opiszę rodzaje testów).
Środowisko testowe
Kiedy zespół jest gotów, to przenosi zbudowane zmiany na kolejne środowisko dedykowane do testów. Tutaj najczęściej testerzy, a czasem i biznes, weryfikują poprawność nowych wymagań i zgłaszają błędy do poprawki. Na tym środowisku jest podłączona testowa baza danych. Dane czasem są kopią z produkcji, czasem sztucznie wytworzonymi rekordami na potrzeby testów. Pisane są też różne testy np. integracyjne czy kontraktowe. Często aplikacje na środowisku testowym stoją na słabszej infrastrukturze. Po pierwsze nie ma tam takiego ruchu, po drugie koszt pozostanie zawsze kosztem, a infrastruktura jest zazwyczaj droga.
Środowisko produkcyjne
W zależności od przyjętego sposobu pracy i technologii do tego przystosowanej, w pewnym momencie zapada decyzja o wdrożeniu zmian na produkcję. Następuje wtedy release na produkcję. Ze względu na specyfikę tego środowiska i jego wagę, tutaj odpala się najwięcej testów: wydajnościowych, integracyjnych, funkcjonalnych e2e (end-to-end).
To, co tygryski lubią najbardziej, czyli testy na prodzie
Zawsze teza pozostaje tezą, do czasu jej weryfikacji. Budowane oprogramowanie jest tylko założeniem, które zweryfikują użytkownicy. Jednakże ich cierpliwość robi się coraz krótsza, jeśli chodzi o błędy czy wtopy.
20 lat temu 2 minuty ładowania strony internetowej było akceptowalne. A dziś? Czy będziesz czekać 2 minuty, by kupić swoje nowe słuchawki? Nie. Jeśli regularnie korzystasz z apki fitnessowej, by odbyć swój regularny trening i nagle nie możesz przejść do kolejnego poziomu swojego wyzwania. Czy będziesz sprawdzać codziennie, czy już możesz? Też zaryzykuję i powiem: Nie. To miałam na myśli, pisząc o cierpliwości użytkowników. Kto na tym skorzysta? Konkurencja. Natura nie lubi pustki, a inteligentne algorytmy i wszechobecność reklam zapewni, że sfrustrowany użytkownik chętnie poeksploruje rynek ;) i zobaczy, co inni mają do zaoferowania.