Testy niefunkcjonalne – co warto o nich wiedzieć?

Testy funkcjonalne

Testy funkcjonalne skupiają się na najbardziej podstawowych wymaganiach – czy funkcjonalności działają zgodnie z założeniami. Zespół projektowy dostaje gotowe wymagania, a klient czy pracodawca mniej lub bardziej dokładnie wie, co chce otrzymać. Podczas pracy wymagania te mogą ulegać zmianom – niemniej ciągle mamy je przed oczami i wiemy, do czego dążymy. Tester, programista, analityk biznesowy czy nawet użytkownik końcowy jest w stanie przetestować aplikację względem wymagań funkcjonalnych i zazwyczaj nie ma tutaj potrzeby zdobywania skomplikowanej wiedzy teoretycznej o tym, jak testować. Aplikację należy „przeklikać”, sprawdzając, czy spełnia swoje zadanie zgodnie z wymaganiami biznesowymi.

Przeczytaj także: Quality Assurance

Testy niefunkcjonalne

Testy niefunkcjonalne określane są też jako testy jakościowe – tutaj sprawa jest bardziej skomplikowana niż w przypadku testów funkcjonalnych. Najczęściej zakres, jaki sprawdzają, definiowany jest krótkim zdaniem: „jak działa system”. Zacznijmy od podziału na podstawie sylabusa ISTQB – Analityk Testów. Testy niefunkcjonalne mogą sprawdzać:

• użyteczność (usability)
• bezpieczeństwo (security)
• niezawodność (reliability)
• wydajność (performance)
• utrzymywalność (maintainability)
• przenaszalność (portability)
• kompatybilność (compatibility)

Testy niefunkcjonalne a rzeczywistość

Na testowanie niefunkcjonalne decydują się tylko te firmy, które są świadome tej problematyki oraz zagrożeń wynikających z nieprzeprowadzania testów. Nie wszystko jednak uda się przewidzieć czy znaleźć i od czasu do czasu mogą przekonać się o tym także giganci, tacy jak np. LinkedIn, z którego wyciekły i zostały wystawione na sprzedaż dane 700 milionów użytkowników (93% kont). Problemów nie uniknął też Facebook (oraz aplikacje z jego grupy, takie jak WhatsApp, Messenger, Instagram), który w październiku 2021 odnotował największą w historii awarię i był niedostępny przez niemal 6 godzin. Ta awaria wygenerowała straty rzędu ok. 6 mld dolarów!

Interesujący jest zwłaszcza przypadek projektów publicznych – choć wydaje się, że obwarowane są one szeregiem wymogów prawnych, znacznie trudniejszych do zrealizowania, to mimo wszystko są one częstym obiektem niepowodzeń, takich jak:

• luki bezpieczeństwa – jak luka w systemie e-Toll, która umożliwiała pobieranie danych użytkowników
• problemy wydajnościowe – jak np. te, z którymi borykały się rządowe serwery
• nieprzydatność dla użytkowników – niska intuicyjność systemu utrudniająca działanie aplikacji do poboru opłat na autostradach była powodem krytyki ze strony wielu kierowców

Dlaczego więc testy niefunkcjonalne nie są przeprowadzane? W niewielkich (np. do 10 osób) i krótkoterminowych projektach, nawet jeśli świadomość testów niefunkcjonalnych jest duża, to często są pomijane z dość oczywistych względów – koszty.

Typy testów niefunkcjonalnych

Testy wydajności

Wśród testów niefunkcjonalnych wymienionych wcześniej, są 2 typy testów, których świadomość mocno rośnie i warto się nimi zainteresować. Pierwszym, z niższym poziomem wejścia, są testy wydajności. Tematyka wydaje się dość skomplikowana, jednak po poznaniu kilku narzędzi (np. JMeter, Gatling) okazuje się, że stosunkowo szybko można zacząć przeprowadzać podstawowe testy wydajności, które pozwolą wyłapać poważne problemy w aplikacji.

Wydzielić można następujące typy testów wydajności:

• obciążeniowe – testowanie działania systemu w zależności od różnych poziomów obciążeń, mieszczących się w zakładanym zakresie,
• przeciążeniowe – testowanie wydajności poza maksymalnym oczekiwanym obciążeniem lub przy dostępności zasobów niższej niż minimalne wymagania,
• skalowalność – testowanie zdolności systemu do zwiększania lub zmniejszania wykorzystywanych zasobów w zależności od obciążenia,
• skokowe – testowanie zdolności systemu do przetworzenia skokowego przyrostu obciążenia, a następnie powrotu do typowego obciążenia,
• wytrzymałościowe – testowanie stabilności systemu pod zadanym obciążeniem w czasie, jaki jest adekwatny i proporcjonalny do realiów produkcyjnych,
• współbieżności – testowanie sytuacji, w której ta sama akcja jest wykonywana jednocześnie,
• przepustowości – określanie maksymalnego obciążenia, jakie jest w stanie obsłużyć system przy jednoczesnym spełnieniu wymagań wydajnościowych.

Wymagania dla testów wydajnościowych:

Przy tworzeniu nowych aplikacji trudno jest podać dokładne wymagania dla testów wydajnościowych. Opierają się one zwykle na określeniu profili produkcyjnych lub na podstawie przewidywań bądź doświadczeń z podobnymi, działającymi już aplikacjami. Łatwiej jest zdefiniować wymagania przy wdrażaniu nowszej wersji oprogramowania, ponieważ można się tutaj odnieść do danych produkcyjnych, jak np. liczba zapytań na sekundę, przepustowość łącza, moc obliczeniowa. Jednym z zagrożeń przy wykonywaniu testów wydajności jest ich nieumiejętne przeprowadzanie (np. przez osoby niemające doświadczenia), które może prowadzić nawet do braku analizy kluczowych elementów systemu czy do mylnej interpretacji wyników. Kolejnym dużym ryzykiem jest przeprowadzanie testów na środowiskach testowych, które zazwyczaj nie są tożsame ze środowiskami produkcyjnymi ze względu na konfigurację, ilość danych oraz moc.

Testy bezpieczeństwa

Drugim, znacznie szerszym, jeśli nie przeogromnym działem, jest bezpieczeństwo. Testy bezpieczeństwa sprawdzają, czy system wystarczająco dobrze chroni dane oraz funkcjonalności przed atakiem osób trzecich. Ich waga rośnie coraz bardziej – kto z nas nie słyszał o różnych włamaniach, wyciekach, oszustwach czy kradzieżach spowodowanych niewystarczającymi zabezpieczeniami bądź niską świadomością użytkowników? Trudno jest jednak znaleźć testera, który na co dzień zajmuje się testami funkcjonalnymi, a oprócz tego może od czasu do czasu przeprowadzić testy bezpieczeństwa. Dlatego najczęściej (jeśli w ogóle) po stworzeniu systemu (lub jego części) audyty bezpieczeństwa zleca się zewnętrznym firmom. Temat jest bardzo rozległy, a naukę warto zacząć od poznania OWASP Top 10 – to dokument zawierający 10 najczęstszych zagrożeń bezpieczeństwa.

Wybrane typy testów bezpieczeństwa:

• skanowanie podatności – wykonywane przy użyciu narzędzi, które skanując program, szukają znanych podatności w jego komponentach,
• skanowanie bezpieczeństwa – skupia się na bezpieczeństwie konfiguracji aplikacji, sieci oraz innych systemów,
• testy penetracyjne – proces symulujący rzeczywisty atak,
• audyt bezpieczeństwa – szeroko zakrojony, ustrukturyzowany proces inspekcji aplikacji zgodny ze zdefiniowanymi standardami,
• ocena ryzyka – analiza i zidentyfikowanie największych zagrożeń bezpieczeństwa
• ocena stanu zabezpieczeń – połączenie skanowania bezpieczeństwa, testów penetracyjnych oraz oceny ryzyka w celu określenia poziomu bieżących zabezpieczeń oraz ich efektywności.

Testy użyteczności

Te testy sprawdzają, czy użytkownik może łatwo nauczyć się korzystać z aplikacji i czy jego doświadczenia będą pozytywne. W grę wchodzą tutaj także takie aspekty jak estetyka, intuicyjność, a także możliwość korzystania z aplikacji przez osoby niepełnosprawne. Warto mieć to z tyłu głowy i skupiać się na tych kwestiach od samego początku projektu, szczególnie w projektach zwinnych, gdzie mamy stały kontakt z klientem i realną możliwość wpływu na zmianę tworzonych funkcjonalności. Bezkrytyczne dodawanie funkcjonalności zgodnie z wymaganiami klienta (który nie zawsze jest osobą techniczną) nie jest najlepszym podejściem. Przeprowadzenie testów użyteczności dopiero po ukończeniu aplikacji może skutkować znaczącym wzrostem kosztów projektu, spowodowanym dodatkowymi pracami.

Przeczytaj artykuł: Dostępność cyfrowa strony – jak o nią zadbać?

Testy niezawodności

Testowanie niezawodności sprowadza się do weryfikacji, czy system jest w stanie działać poprawnie przez określony czas w określonych warunkach. Trudno jest jednak symulować warunki produkcyjne na środowiskach testowych przez wystarczająco długi czas, dlatego między innymi testy takie mogą odbywać się częściowo na serwerach produkcyjnych. Przykładem testowania niezawodności jest umieszczenie nowej wersji aplikacji na jednym (mniej wykorzystywanym) z wielu serwerów oraz pozostawienie poprzedniej wersji na pozostałych. Po założonym okresie monitorowania aplikacji nowa wersja zostaje wgrana na pozostałe serwery. Podejściu takiemu musi towarzyszyć odpowiednia konfiguracja, aby w przypadku wystąpienia problemów z nową wersją na pojedynczej maszynie ruch został automatycznie przekierowany na pozostałe.

Charakterystyki niezawodności to:

• dojrzałość – poziom spełnienia wymagań dotyczących niezawodności,
• osiągalność – czas, po jakim system jest dostępny,
• tolerowanie usterek – zdolność systemu do kontynuowania działania podczas wystąpienia awarii,
• odtwarzalność – zdolność do odzyskania danych po awarii, mierzona w czasie oraz ilości utraconych danych.

Testy utrzymywalności

Testowanie utrzymywalności pozwala przeanalizować stopień skomplikowania utrzymania systemu w przyszłości. Są raczej rzadko przeprowadzane, mimo tego, że utrzymanie programu będzie (w założeniu) trwało dłużej niż jego tworzenie. Ważną rolę odgrywa tutaj „profilaktyka” już od początku trwania projektu – systematyczne przeprowadzanie code review oraz prowadzenie dokumentacji. Jest bardzo prawdopodobne, że system w przyszłości będzie utrzymywany bądź rozwijany przez inne osoby niż te, które go tworzyły. Z tego powodu przejrzystość kodu i dokumentacji odgrywa tutaj kluczową rolę.

Głównymi celami testów utrzymywalności są:

• minimalizacja kosztów utrzymania aplikacji,
• minimalizacja przestojów w działaniu aplikacji, potrzebnych do jej utrzymania.

Testy przenaszalności

Testowanie przenaszalności pozwala określić poziom skomplikowania wiążący się z przenoszeniem komponentu oprogramowania lub aplikacji z jednego środowiska na drugie. W tym przypadku również rzadko spotyka się wydzielenie ich z procesu testowego i skupienie się tylko na takich rodzajach testów. Testom przenaszalności w naturalny sposób sprzyjają zwinne frameworki projektowe, takie jak Scrum. W iteracyjnym podejściu do tworzenia oprogramowania przenaszalność jest testowana przy okazji częstych wydań kolejnych wersji (przenoszenie aplikacji ze środowiska developerskiego / testowego na produkcyjne), nawet co 2 tygodnie. Inne sytuacje, w których warto wykonać testy przenaszalności to np. przejście z przeglądarki Internet Explorer na Chrome, z jednej wersji bazy danych na inną lub rozszerzenie możliwości instalacji programu na kolejne wersje systemów Windows czy Mac. Miarą przenośności może być nakład pracy wymagany do przeniesienia komponentu oprogramowania z jednego środowiska do innego. Charakterystyki przenaszalności to:

• instalowalność – możliwość zainstalowania programu w nowym systemie,
• zdolność adaptacyjna – możliwość zainstalowania aplikacji na wszystkich docelowych systemach,
• zastępowalność – możliwość zastąpienia istniejącego modułu oprogramowania.

Testy kompatybilności

Testy kompatybilności weryfikują możliwość współistnienia różnych programów na tym samym środowisku, a także możliwość działania programu w zależności od różnych parametrów. Bardzo popularny jest test kompatybilności, który ma na celu sprawdzenie działania aplikacji w różnych przeglądarkach, takich jak Chrome, Firefox, Internet Explorer, Safari czy Opera. Innym przypadkiem są testy aplikacji mobilnych na wielu różnych urządzeniach. Podejście takie pozwala zidentyfikować problemy, z którymi mogą spotkać się klienci, używając niestandardowych systemów operacyjnych bądź przeglądarek.

Kompatybilność można testować ze względu na:

• sprzęt
• system operacyjny
• oprogramowanie
• sieć
• przeglądarkę
• urządzenie mobilne
• wersję oprogramowania

Podsumowanie

Testy funkcjonalne są bardzo ważne i w zdecydowanej większości projektów nikt nie kwestionuje ich istotności. Bieżące testowanie manualne oraz rozwijanie i utrzymywanie regresji praktycznie wyczerpuje temat. Musimy jednak być świadomi, jak ważne jest również testowanie niefunkcjonalne i jakie ryzyko wiąże się z pomijaniem tego typu testów. Często już na etapie planowania testów brakuje dokładnej analizy, jakie testy niefunkcjonalne powinny być przeprowadzone, co sprawia, że tylko pośrednio część błędów zostaje znaleziona. Zagrożenia są duże: nieodpowiadająca strona sklepu w Black Friday, wyciek poufnych danych klientów, zablokowanie strony dla okupu, nieintuicyjność aplikacji czy brzydki design zniechęcający użytkowników do korzystania, niedziałające płatności po wgraniu nowej wersji… Wszystko to może okazać się znacznie bardziej kosztowne niż inwestycja w systematyczne przeprowadzanie testów niefunkcjonalnych.