Podczas wieloletniej pracy jako programista miałem do czynienia z projektami o różnym stopniu skomplikowania. Jednak za każdym razem testy były kluczowe podczas potwierdzenia, że nasze rozwiązanie działa zgodnie z oczekiwaniami naszymi, a najlepiej także klienta. Nieważne czy pierwotne założenia zostały spełnione czy wymagania uległy zmianie w trakcie implementacji, testy zawsze potwierdzały zgodność implementacji z założeniami dotyczącymi projektu.
W momencie, którym testy nie zostały prawidłowo przeprowadzone przed wdrożeniem, wówczas:
- Niemożliwe jest potwierdzenie spełnienia wszystkich wymogów poprzez dostarczone rozwiązanie.
- Niemożliwe jest potwierdzenie prawidłowego działania dostarczonego rozwiązania.
Oba punkty brzmią podobnie i prowadzą do takiego samego wniosku.
Dostarczone rozwiązanie nie działa prawidłowo.
Skutkiem tego jest błąd, który wcześniej lub później zostanie dostrzeżony i zgłoszony. W świecie Servicenow taki błąd jest często traktowany jako incydent, a nie zawsze takim jest.
Według ITIL – incydent to nieplanowana przerwa w świadczeniu usługi lub obniżenie jej jakości.
Tylko czy w takiej sytuacji mamy do czynienia z incydentem, a może bardziej defektem (ang. Defect) lub ulepszeniem (ang. Enhancement). Spojrzenia na to są różne, ale przyczyna jednakowa – brak całościowych testów. A tych mamy naprawdę sporo.
Testy funkcjonalne
Testy funkcjonalne służą sprawdzeniu, czy oprogramowanie zachowuje się zgodnie z oczekiwaniami i spełnia wymagania funkcjonalne.
Test jednostkowy
Opis: Koncentruje się na testowaniu poszczególnych komponentów lub modułów oprogramowania w izolacji.
Przykład: Programista testuje funkcję obliczającą całkowitą cenę artykułów w koszyku, aby upewnić się, że zwraca ona poprawną wartość.
Najpopularniejszy rodzaj testu, który powinien być wykonany przez programistę w celu weryfikacji, że jego rozwiązanie działa, zanim zostanie przekazane do dalszego testowania.
Test integracyjny
Opis: Testowanie interakcji między różnymi modułami lub komponentami oprogramowania w celu zapewnienia ich poprawnego działania.
Przykład: Tester weryfikuje, czy bramka płatności bezproblemowo integruje się z systemem zarządzania zamówieniami w sklepie internetowym.
Taki test w środowisku Servicenow często sprowadza się do weryfikowania konfiguracji testowanych modułów i komponentów, a ostatecznie ręcznego przeprowadzenia całego procesu. W wybranych sytuacjach możliwe jest zastosowanie testów automatycznych (ang. Automated Test Framework).
Test dymowy
Opis: Wstępny test sprawdzający, czy podstawowe funkcjonalności oprogramowania działają zgodnie z oczekiwaniami.
Przykład: Po wdrożeniu nowej wersji aplikacji mobilnej testerzy sprawdzają, czy aplikacja uruchamia się, pojawia się ekran logowania i użytkownicy mogą się zalogować.
W praktyce taki test sprowadza się do najprostszego określenia: „Działa lub nie działa.”. Wszystko poza może i powinno być potwierdzone testami innych rodzajów.
Test regresyjny
Opis: Upewnia się, że nowe zmiany w kodzie nie wpłyną negatywnie na istniejącą funkcjonalność oprogramowania.
Przykład: Po dodaniu nowej funkcji do witryny e-commerce testerzy weryfikują, czy proces realizacji zamówienia, który wcześniej działał, nadal działa poprawnie.
W mojej ocenie taki test regresyjny jest swoistym testem integracyjnym, ponieważ nowe rozwiązanie musi działać z istniejącym systemem, a dodatkowo nie powodować nowych błędów. Najprościej opisać to jako kolejna opcja do wyboru. W przypadku braku nowej opcjonalnej wartości system działa jak dotychczas, a nowa wartość zmienia działanie procesu lub komponentu.
Test akceptacji użytkownika (UAT)
Opis: Weryfikacja, czy oprogramowanie spełnia wymagania biznesowe i jest gotowe do wdrożenia, zazwyczaj przeprowadzana przez użytkowników końcowych lub klientów.
Przykład: Klient testuje nowy system płacowy, aby upewnić się, że oblicza on wynagrodzenia i generuje raporty zgodnie z oczekiwaniami przed zatwierdzeniem jego wydania.
W świecie Servicenow taki test najczęściej jest wykonywany ręcznie przed wdrożeniem zmiany na środowisko produkcyjne. Sprawdza się do potwierdzenia, że pierwotne lub aktualne wymagania zostały spełnione poprzez przygotowanie rozwiązanie. Poza zewnętrznymi systemami do śledzenia postępów wdrożeniowych kilku z moich klientów używało modułu Test Management 2.0 dostępnego w Servicenow.
Test weryfikacyjny użytkownika końcowego
Opis: Potwierdza, że oprogramowanie działa zgodnie z przeznaczeniem w rzeczywistym środowisku, w którym będzie używane.
Przykład: Grupa pracowników korzysta z nowego systemu zarządzania zapasami w swoich codziennych działaniach, aby upewnić się, że spełnia on ich potrzeby.
W zasadzie jest to ostatni krok w potwierdzeniu, że cały proces zmiany zakończył się sukcesem. Kluczem do zrozumienia istoty tego testu jest miejsce jego przeprowadzenia, czyli środowisko produkcyjne. Mimo tego, że wdrażamy coś już zostało wcześniej przetestowane, to niekoniecznie samo przeniesienie tego między środowiskami musi być udane. Właśnie to ma potwierdzić ten test.
Test niefunkcjonalne
Testy niefunkcjonalne koncentrują się na ocenie wydajności, bezpieczeństwa, użyteczności i innych atrybutów jakościowych oprogramowania.
Test obciążenia/wydajności
Opis: Ocena działania oprogramowania w warunkach oczekiwanego i szczytowego obciążenia.
Przykład: Zespół testuje platformę streamingową wideo, symulując jednoczesne oglądanie filmów przez tysiące użytkowników, aby upewnić się, że nie ulegnie awarii.
Servicenow jako platforma działająca w modelu SaaS jest przygotowana na wzmożony ruch i wzrost obciążenia naszej instancji. Mimo wielu rozwiązań po stronie dostawcy widziałem kilku klientów, którzy dotarli do różnych granic technologii. W celu sprawdzenia czy nasze rozwiązanie w skrajnych sytuacjach nie położy środowiska (mało prawdopodobne, ale możliwe) są testy wydajnościowe dostępne od wersji Washington DC.
Test bezpieczeństwa/penetracyjny
Opis: Identyfikacja luk w zabezpieczeniach oprogramowania w celu zapewnienia jego bezpieczeństwa przed potencjalnymi atakami.
Przykład: Zespół ds. bezpieczeństwa symuluje cyberatak na aplikację bankową, aby sprawdzić, czy w jej systemie logowania nie ma słabych punktów.
To nie są typowe testy jakie wykonują programiści i konsultanci, a raczej dedykowany zespół bezpieczeństwa. W przypadku architektów Servicenow istotne jest śledzenie najlepszych praktyk i regularne sprawdzanie kondycji instancji (Instance Scan). Dodatkowo Servicenow Security Center jest miejscem, gdzie znajdziemy różne metryki bezpieczeństwa i konkretne zalecenia odnośnie zgłoszonych luk i aktualizacji bezpieczeństwa.
Test użyteczności
Opis: Ocena łatwości i intuicyjności obsługi oprogramowania przez użytkowników.
Przykład: Testerzy obserwują użytkowników poruszających się po nowej stronie rezerwacji podróży, aby zidentyfikować obszary, w których napotykają trudności lub są zdezorientowani.
Często pomijane i niedoceniane w świecie Servicenow. Wiele elementów, szczególnie gotowych komponentów wykorzystywanych przy tworzeniu rozwiązania ma z góry zdefiniowane działanie, które w najlepszym przypadku może być częściowo modyfikowane. Zdarza się wymagania biznesowe nie idą w parze z wytycznymi UI oraz UX dla aplikacji internetowych, a są tylko cyfrowym odwzorowaniem znanego już procesu fizycznego. Najbardziej widoczne było to to w zbyt skomplikowanych pozycjach katalogowych, raportach i formularzach rekordów, a obecnie także interfejsie tworzonym przy użyciu UI Buildera.
Podsumowanie
Testy są elementem często niedocenianym i pomijanym, szczególnie przez początkujących programistów i konsultantów. Dla własnego bezpieczeństwa, a tym bardziej dla podnoszenia poziomu naszego profesjonalizmu powinniśmy przetestować wszystkie scenariusze przewidziane w wymaganiach klienta.
W momencie, kiedy te nie zostały określone to naszym obowiązkiem jest wskazać je zleceniodawcy i potwierdzenie działania rozwiązania w warunkach brzegowych. W ten sposób pokażemy nasze zaangażowanie w wykonywanych zadaniach i w dłuższej perspektywie przyśpieszymy prawidłowe wdrożenie rozwiązania.
Dużo lepiej świadczy o Tobie, kiedy klient dowie się o czymś czego nie przewidział na etapie projektowania niż w trakcie testowania. Zdecydowanie nieprofesjonalnie wygląda scenariusz kiedy wszystko z wielką pompą trafia na środowisko produkcyjne, a potem okazuje się, że nie działa tak jak oczekiwano. Zwykle wtedy brak winnych.