Wytwarzanie oprogramowania to zwykle długi, czasochłonny, skomplikowany proces. Aby przebiegał on poprawnie i dało się nim efektywnie zarządzać – proces developmentu dzielony jest na różne etapy, fazy. Każda faza charakteryzuje się swoimi unikalnymi czynnościami i aktywnościami. Dokładnie na tej samej zasadzie przeprowadza się proces testowy. Krótko mówiąc – w każdej fazie wytwarzania oprogramowania powinny pojawić się odpowiednie czynności testowe.

Testy możemy podzielić na następujące 4 podstawowe poziomy:

• Testy modułowe (jednostkowe)
• Testy integracyjne (wewnętrzne, zewnętrzne)
• Testy systemowe
• Testy akceptacyjne

Przedstawię teraz dokładniej wszystkie wyżej wyszczególnione poziomy testów, gdyż ich poprawne rozumienie jest kluczem do późniejszego właściwego ich doboru i wykonywania. Koniecznie musimy posiadać wiedzę o tym kiedy, w jakim czasie wykonywać testy z konkretnego poziomu.

Poniższa grafika prezentująca „Piramidę Testów”, obrazuje w przybliżeniu: jaka proporcja w ilość testów powinna być zachowana na poszczególnych etapach testowania.

Testy modułowe ( jednostkowe)

Testy modułowe wykonujemy na etapie wytwarzania oprogramowania ( równocześnie z pracami developerskimi ). Zwykle testy te wykonują sami programiści, którzy rozwijają aplikację. Robią to w swoim kodzie w środowisku developerskim – testy te można rozumieć jako „pierwszy front” weryfikacji jakości oprogramowania. Testy jednostkowe w swojej koncepcji skupiają się na weryfikacji małych, wyizolowanych konstrukcji programistycznych, np. fragmentów kodu takich jak pojedyncze funkcje, metody. Mają one za zadanie sprawdzić czy dany fragment kodu realizuje dokładnie zakładaną czynność, logikę. Np. jeśli programista napisał funkcję, która przelicza kwotę woluty Euro na PLN, to test powinien zweryfikować czy na pewno funkcja poprawnie realizuje przeliczenie Euro na PLN. Konkretniej ujmując – taki test będzie polegał na wprowadzeniu wartości wejściowej (kwota Euro) i weryfikacji wartości wyjściowe (kwota PLN). Bardzo ważną cechą testów modułowych jest to, że testowane konstrukcje programistyczne, fragmenty kodu – powinny działać w odizolowaniu od innych funkcjonalności, czyli mówiąc prościej, powinny być niezależne od innych wytworzonych funkcjonalności. Napisałem wcześniej, że testy jednostkowe zwykle wykonuje programista, jednak nic nie stoi na przeszkodzie, żeby wykonywał je, lub pomagał w ich wykonaniu tester oprogramowania, a właściwie tester automatyzujący. Jednak, aby to robić trzeba posiadać sporą wiedzę programistyczną, gdyż oczywiście takie testy wykonuje się bezpośrednio na kodzie w środowisku developerskim.

Dlaczego testów jednostkowych powinno wykonywać się tak dużo (spójrz piramida testów) ?

Mówiąc nieco z przymrużeniem oka „jeśli nie wiadomo o co chodzi to chodzi o pieniądze”. Testy te jak już sobie powiedzieliśmy, wykonuje się we wczesnej fazie – wytwarzania oprogramowania, więc znalezione tutaj błędy są tanie w naprawie, a ich poprawka zwykle wykonywana jest „od ręki”, co szybko i bezpośrednio przekłada się na poprawkę jakości oprogramowania. Obsługa tych błędów jest nieformalna – błędy nie są nigdzie formalnie zapisywane, zgłaszane – są od razu poprawiane przez programistę. Należy pamiętać, że jakość oprogramowania podnosi się wraz z naprawą błędów, a nie z ich wykryciem! Ważne do zapamiętania jest to, że im mniej błędów zostanie przeniesionych z etapu developmentu do etapu testów formalnych, tym szybciej aplikacja zostanie przekazana do klienta, a sama jakość oprogramowania będzie wyższa.

Testy integracyjne

Testy integracyjne to krótko mówiąc, weryfikacja integracji, współdziałania gotowych jednostek kodu, modułów, czy nawet całych systemów i usług. Zakończenie fazy testów integracyjnych powinno pozwolić przejść do fazy testów systemowych, czyli powinno pozwolić traktować wszystkie moduły jako cały, funkcjonalny system, który jest zdolny do poprawnego realizowania konkretnych procesów biznesowych. Tylko przekonanie o spójności systemu daje nam „zielone światło” do testów End-T0_End, czyli do testów konkretnych biznesowych procesów w oparciu o cały system. Aby efektywnie wykonywać testy integracyjne, musimy mieć pewność, że dane moduły ( które ze sobą powinny korelować, współpracować) – działają prawidłowo oddzielne – czyli przeszły pozytywnie testy jednostkowe. Dopiero wtedy możliwe jest poprawne testowanie integracji, czyli współpracy dwóch czy większej liczby modułów. Zadaniem testera oprogramowania na poziomie testów integracyjnych, jest również budowanie w zespole świadomości, że każdy nawet niewielki błąd, czy niefortunna zmiana w kodzie w jednym z modułów, może mieć bardzo duże negatywne skutki w innym miejscu aplikacji, gdyż system softwarowy to „system naczyń połączonych” (zestaw modułów, które wzajemnie ze sobą korelują).

Testy integracyjne powinny dać odpowiedzi na następujące pytania:

• Czy współpraca miedzy modułami (częściami oprogramowania) jest poprawna? Właściwą współpracę miedzy-modułową mogą zakłócić zarówno problemy techniczne (np. niedostępność pewnych kanałów komunikacyjnych) jak i problemy logiczne/biznesowe
• Jak zachowają się inne moduły w przypadku awarii jednego z nich?
• Czy integracja poszczególnych modułów spełnia, wykonuje poprawnie zakładany proces biznesowy? Tutaj mogą ujawnić się problemy w logice (np. wszelkiego rodzaju braki, luki, oraz specyficzne biznesowe sytuacje, które nie zostały uwzględnione na etapie planowania i wytwarzania oprogramowania)

Testy integracyjnie w prostej linii możemy podzielić na:

• Testy integracyjne wewnętrzne
• Testy integracyjne zewnątrzne

Testy integracyjne wewnętrzne dotyczą tylko systemu, który rozwijamy i tutaj testujemy wszelkie integracje między tworzonymi modułami.
Testy integracyjne zewnętrzne to testy, które dotyczą integracji z innymi systemami (niekoniecznie naszymi) oraz z zewnętrznymi usługami, które istnieją na rynku. Oba typy integracji są bardzo ważne, dlatego proces testów integracyjnych powinien być przeprowadzony kompleksowo i z dbałością o szczegóły.

Testy systemowe

Testy systemowe to testy, których zadaniem jest weryfikacja aplikacji jako całości (produktu) lub jej samodzielnego fragmentu, realizującego jakiś większy zakres projektu. Powyższe zdanie jest bardzo ważne, gdyż przekonałem się, że panuje mylne spojrzenie, że testy systemowe, to tylko testy systemu jako gotowego produktu końcowego. Bardzo ważną rzeczą na etapie testów systemowych , jest to, aby testy przeprowadzać na środowisku testowym, które jest w jak największym stopniu zbliżone do środowiska produkcyjnego, na którym docelowo aplikacja będzie funkcjonować. Dlaczego to jest takie ważne?? Otóż, tylko na takim środowisku możemy zmniejszyć ryzyko niewykrycia błędów, które mogą zostać przeoczone z powodu różnic w specyfice i konfiguracji obu środowisk. Testy systemowe powinny skupiać w sobie zarówno testy funkcjonalne jak i niefunkcjonalne, gdyż jednym z głównych zadań tych testów jest ocena całościowa, generalne sytemu, bądź jego fragmentu. Na tym etapie testów, możemy wykryć potrzebę zastosowania różnych zaślepek, mocków, stymulatorów, które pozwolą nam zasymulować integrację z innymi systemami czy usługami zewnętrznymi.

Aby solidnie wykonać test systemowe powinniśmy przeprowadzić następujące typy testów:

• test funkcjonalne
• testy niefunkcjonalne (wydajnościowe)
• testy regresji
• testy konfiguracji
• testy bezpieczeństwa

Testy akceptacyjne

Testy akceptacyjne to testy wykonywane przez klienta, które mają dać mu informację potrzebną do podjęcia świadomej decyzji o odbiorze bądź odrzuceniu produktu. Zwykle tego typu testy klient realizuje u siebie, przy wykorzystaniu swoich zasobów ludzkich w postaci testerów, potencjalnych użytkowników systemu, lub z przy współpracy z niezależnym zespołem testerskim. Testy akceptacyjne weryfikują system pod kątem zgodności z założeniami i wymaganiami, które zostały postawione przed fazą developmentu. Na tym etapie sprawdza się również wszelkie zgodności z zapisami w umowach oraz z obowiązującymi przepisami prawa. Testy akceptacyjne powinny przejść i zweryfikować wszystkie kryteria zakończenia testów, które powinny zostać spisane w planie testów. Faza testów akceptacyjnych zakończona sukcesem jest podstawą do formalnego rozliczenia kontraktu.

Autor: Tomasz Stelmach