Każdy z nas jest tylko człowiekiem i popełnia błędy. Niektóre z nich są trywialne, ale zdarzają się też takie, które powodują ogromne straty, bądź są wręcz niebezpieczne dla życia i zdrowia.

26 kwietnia 1994 roku samolot chińskich linii lotniczych rozbił się z powodu błędu w oprogramowaniu. W wyniku tego zdarzenia zginęły 264 osoby, a 7 zostało ciężko rannych.

Powyższy przykład – podręcznikowy już w zasadzie – pokazuje, że błędy w oprogramowaniu mogą nieść za sobą poważne skutki. Niestety w historii było wiele podobnych przypadków. Można było ich uniknąć, gdyby danego oprogramowania nie dopuszczono do użytku. Ewidentnie zawiodły tu testy. Na pytanie CZY testy jakiegokolwiek systemu są potrzebne, odpowiedź zawsze jest taka sama: – Yes! Yes! Yes! – cytując klasyka. 

Nie wszystkie błędy prowadzą do skrajnych skutków. Na przykład defekty w aplikacji dla dzieci mogą jedynie utrudnić korzystanie z niej, obniżyć satysfakcję użytkownika… i rodzica. Tylko skąd wziąć wiedzę, że dane oprogramowanie nie zawiera w sobie uchybień, które prowadzą do groźnych sytuacji czy kosztownych awarii? Odpowiedź brzmi: zaplanować testy!

Ale moim celem nie jest w tej chwili omawianie teorii związanej z tematem testów oprogramowania. Teoria testów to temat na serię artykułów i to bardzo obszernych. Wolałabym skupić się na uzmysłowieniu obu stronom takiej kooperacji, jak istotny jest to element każdego wdrożenia IT. Zastanówmy się zatem co złego/dobrego wydarzy się dla Twojego biznesu, jeżeli nie poświęcisz/poświęcisz zasobów/zasoby na testy wdrażanego oprogramowania. Stworzę przykładowe case study.

Rodzajów testów oprogramowania jest naprawdę wiele. Każdy z nich ma własny cel i zastosowanie. Łączy je jedno – zamiar znalezienia BŁĘDU. Tester chroni klienta przed otrzymaniem oprogramowania, które może działać niepoprawnie i spowodować straty w wizerunku klienta bądź materialne. Można również powiedzieć, że testowanie to proces walidacji i weryfikacji tego, czy program, aplikacja lub produkt:
• spełnia wymagania biznesowe i techniczne zgodne z zamierzeniem projektu,
• działa zgodnie z zamierzeniem,
• może zostać uruchomiony przy zachowaniu niezmienionej charakterystyki.

Firma zajmuje się w internecie sprzedażą mebli. Target to klienci biznesowi, czyli model B2B2C. Na prośbę działu sprzedaży firma postanowiła przejść z klasycznych metod pracy z arkuszem kalkulacyjnym, żółtych karteczek oraz malowania po kalendarzu ściennym na własny, dedykowany system CRM z platformą sprzedaży e-commerce.

 Software house zrobił dwudniowe warsztaty, na podstawie których zebrał od firmy założenia, jakie funkcjonalności muszą zostać zakodowane. Powstała dokumentacja funkcjonalna: długa, opisująca procesy biznesowe, sposób ich rozwiązania w systemie, przypadki użycia. Komu? Pytam: niby komu chciałoby się to dokładnie czytać? Szef sprzedaży ma już wystarczająco dużo obowiązków i tonie pod żółtymi karteczkami, a teoretycznie to on wskazał potrzebę powstania tego systemu – jest jakby Product Ownerem, powinien zaakceptować dokumentację, zanim przejdzie do fazy produkcji.

I tu pojawia się pierwsza ważna kwestia: KTO ma testować – czyli zasoby po stronie klienta (zlecającego) oraz software house’u. Wielu klientów postrzega to w ten sposób: „Ale dlaczego ja mam poświęcać zasoby po swojej stronie? Przecież płacę wam za dostarczenie działającego oprogramowania, które wyniesie moją firmę w nowe przestworza biznesu?!”. No właśnie – płacisz, więc powinieneś być pewny, za co płacisz. Pilnuj swojego budżetu! 

Wskaż po swojej stronie osobę odpowiedzialną za wdrażane oprogramowania (Product Owner). Taki pracownik powinien znać procesy w firmie i cel budowanego systemu. To on zaakceptuje dokumentację i będzie odbierał kolejne elementy systemu. To on będzie na początku i na końcu łańcucha dostarczenia oprogramowania. To właśnie będzie zasób odpowiedzialny za testy klienckie (funkcjonalne).

Jeśli wszystkie informacje o budowanym systemie będą w głowie jednej osoby, to pojawia się DUŻE RYZYKO, że utracisz tę wiedzę w organizacji. Jeśli są możliwości finansowe, to warto przydzielić do tego zadania zespół.  
 
Software house po swojej stronie również wystawi taką osobę. Zazwyczaj jest to Project Manager/Analityk, który poszczególne funkcjonalności przekaże do realizacji deweloperom. Dodatkowo w projekcie pojawi się osoba na stanowisku Tester, której zadaniem będzie weryfikacja, czy wyprodukowana przez programistę funkcjonalność jest zgodna z oczekiwaniami klienta, nadaje się do publikacji i przekazania klientowi do weryfikacji.

Przedstawiam w tej historii wciąż przykład testów ręcznych, funkcjonalnych, wymagających udziału „czynnika białkowego”, czyli ludzkiego i weryfikujących biznesowy aspekt wdrożenia. Dlatego teraz trochę o tym JAK testować.

Bardzo ważną częścią każdego projektu systemu są testy automatyczne. W skrócie: kod sam sprawdza, czy zachował się w oczekiwany sposób. Niestety stworzenie tego typu testów jest bardzo czasochłonne, co równa się ze zwiększeniem ceny za system prawie dwukrotnie, dlatego często software house’y nie proponują testów automatycznych klientom w obawie o odrzucenie oferty. Przykładowo: takie testy sprawdzą, czy do danego handlowca zostały przypisane wszystkie sprzedaże i wynik jego prowizji wyliczył się prawidłowo. To pozwala w dużym stopniu na mniejsze zaangażowanie po stronie zasobów ludzkich.

Obecnie wielu programistów już nawet nie chce brać udziału w projektach, w których nie ma testów automatycznych, a software house nie weźmie pod opiekę systemu po innej firmie programistycznej bez testów automatycznych. Pozornie taka oszczędność na projekcie skutkuje brakiem możliwości przejścia klienta z systemem do innej firmy.

Ciekawą alternatywą, z jaką na co dzień pracujemy w PDAIT Solutions, są user case i scenariusze testowe, które wytwarzamy wraz z zaangażowanym klientem podczas warsztatów analitycznych. Tworzymy wówczas mapę myśli w postaci diagramu wszystkich procesów biznesowych, jakie mają odbyć się w systemie, z punktu widzenia pracy różnych typów użytkowników programu.

Takie podejście nie tylko pozwala na dokładne zebranie założeń do projektu, ale też wskazuje na każdą końcówkę procesu, dzięki czemu można zastosować tańsze testy automatyczne, tzw. końcówki API. Dodatkowo ułatwia pracę ze zmianą w trakcie projektu i jasno wskazuje, czy dana funkcjonalność miała znaleźć się w systemie, czy jest to CR.

Testy „końcówek API” polegają na sprawdzeniu, jak interface komunikujący, podprogramy, odpowie na zadany test. Na przykładzie wygląda to tak:


Test wykazał błąd – faktura nie została wystawiona lub została wystawiona z błędem danych. Automat wskazał na informację, że jest problem z wygenerowaniem dokumentu, ale odpowiedzialność za weryfikację źródła tego błędu jest po stronie zasobu ludzkiego. Może to być tabela z produktami, klientami, wartością FV itd. To już musi zweryfikować tester – ręcznie i analitycznie.

Teraz już wiemy, dlaczego firmie IT zależy i wymaga, by klienci brali udział w testach i dlaczego na testy warto zaplanować większy budżet i więcej czasu. 

Z uśmiechem na ustach wspominam teraz czasy, a było to 10 lat temu, kiedy w firmie, dla której pracowałam, na testy oraz dokumentację systemu wdrażanego pół roku, planowano dwa tygodnie. Teraz sama podejmuję decyzje i wiem, że dobre testy funkcjonalne zajmują czasem więcej niż samo zaprogramowanie danej funkcjonalności.