Testowanie w oparciu o proces biznesowy – czy to jest proste?

Wprowadzenie do problemu

Testowanie w oparciu o proces biznesowy to podejście w testowaniu, w którym przypadki testowe projektowane są w oparciu o opis i/lub wiedzę o procesie biznesowym [3]. W praktyce często spotykamy się z taką sytuacją, że testy oprogramowania poprowadzone w czasie stabilizacji aplikacji nie do końca odzwierciedlają zastosowanie aplikacji w rzeczywistości. Wbrew pozorom nie jest to problem, który łatwo da się rozwiązać. Jedna z podstawowych zasad ISTQB mówi, że testowanie jest zależne od kontekstu - mamy tutaj na myśli kontekst użycia aplikacji. W przypadku, gdy oprogramowanie jest w miarę proste i dotyczy czynności, które występują w życiu codziennym, ryzyko przetestowania ”niebiznesowo” jest dość małe np. sklep internetowy. Jeżeli aplikacja jest dedykowana wysoko wyspecjalizowanej gałęzi przemysłu lub nauki, to oprogramowanie może być narażone na niepoprawne przetestowanie biznesowe jeśli nie zostaną zapewnione odpowiednie działania, które wyeliminują takie zagrożenie.

Punkt widzenia testera oprogramowania

Tester oprogramowania na ogół jest skupiony na testowaniu konkretnego wymagania, które jest do niego przypisane, a co za tym idzie:

• identyfikacji warunków testowych,
• tworzeniu przypadków testowych dla zidentyfikowanych warunków testowych,
• wykonaniu napisanych przez siebie lub przez kogoś testów w celu weryfikacji wymagań funkcjonalnych.

Doświadczony tester z pewnością napisze testy nie tylko potwierdzające poprawność implementacji wymagań funkcjonalnych, ale również znajdzie miejsca, które wymagają wprowadzenia dodatkowej walidacji. Doświadczony tester ponadto:

• może zadać pytania, których nie zadał nikt wcześniej lub zadać pytania, na które nie ma odpowiedzi w wymaganiach i wymagają dodatkowych ustaleń,
• dobierze strategię oraz dane testowe, dobrze pasujące do zidentyfikowanych warunków testowych,
• dzięki wykorzystaniu swojego doświadczenia znajdzie miejsca, w których na ogół pojawiają się błędy.

Wyżej opisane punkty są jak najbardziej pożądane podczas planowania testów czy już samego testowania. Cechą wspólna, która łączy wyżej opisane warunki jest to, że patrzymy na aplikację punktowo. Nie jest to podejście niepożądane, a zwłaszcza w przypadku, gdy tester pracuje w projekcie zaledwie od kilku dni. Wówczas w ten sposób można uczyć się systemu, a później próbować łączyć ścieżki. Jak się okazuje, jest to jedna z dobrych praktyk poznawania systemu. Jednak może wystąpić taka sytuacja, że punktowe testowanie oparte tylko na wiedzy testerskiej to za mało, ponieważ na produkcji i/lub podczas testów akceptacyjnych u klienta wystąpią problemy, które są blokerami z biznesowego punktu widzenia.

Testowany program może być na tyle wymagający, że bez podjęcia odpowiednich działań (nawet bardzo doświadczony) tester będzie narażony na to, że biznesowe testy nie zostaną wykonane w całości. Gdy np. mamy do czynienia z oprogramowaniem do diagnozy raka, to nie ma możliwości poprawnego przetestowania takiego oprogramowania bez znajomości pojęć oraz parametrów stosowanych przez lekarzy. Kierownik testów lub kierownik projektu wiedząc, że testowanie wymaga wiedzy biznesowej, może podjąć pewne kroki, które pozwolą złagodzić ryzyko testowania niebiznesowego albo całkowicie je wyeliminują. Takimi środkami zapobiegawczymi mogą być poniższe rozwiązania.

1. Zatrudnienie albo przydzielenie do projektu takiego testera, który posiada wiedzę biznesową. W praktyce ma miejsce taka sytuacja, że zatrudnia się osoby znające branżę. Jednak takie postępowanie również nie jest często spotykane, ponieważ nie łatwo zatrudnić testera mającego wiedzę specjalistyczną z przemysłu.
2. Efektywne wdrożenie osoby testującej, zakończone np. krótkim sprawdzeniem stanu wiedzy, zanim ta osoba zacznie testować na poważnie. Testerzy często są rzucani na głęboką wodę w przypadku zmiany pracy lub zmiany projektu. Zespół jest często zapracowany, nie ma za wiele czasu dla testera, a w takim przypadku tester będzie potrzebował czasu, aby zrozumieć biznesowe znaczenie aplikacji.
3. Wprowadzenie cyklicznych szkoleń prowadzonych przez osobę, która dobrze zna testowany produkt od strony biznesowej. Okazuje się, że takie szkolenia są prowadzone przez firmy coraz częściej, co jest bardzo dobrym rozwiązaniem, jeśli chodzi o zawód i rozwój testera w Polsce.
4. Zorganizowanie lub gromadzenie materiałów mających wartość biznesową. Wymagania funkcjonalne z pewnością są pomocne w wielu sytuacjach, natomiast nie zawsze są pisane dobrze pod względem biznesowym. Można również wprowadzić zasadę, że funkcjonalność nie będzie realizowana jeśli w jej treści nie pojawi się biznesowe uzasadnienie nowej funkcjonalności - to bardzo pomaga, zwłaszcza w przypadku pojawienia się nowych osób w projekcie.
5. Zorganizowanie warsztatów wspólnie z klientem, prowadzonych przez potencjalnych użytkowników oprogramowania.
6. Podjęcie wszelkich starań, aby środowisko testowe w firmie było jak najbardziej zbliżone do tego, które ma klient. Stosowanie zbyt dużej ilości mocków, zaślepek nie odzwierciedla rzeczywistości i nie pozwoli na testowanie zgodne z danymi rzeczywistymi.
7. W przypadku aplikacji, która używa bazy danych możemy napisać zapytania w SQL, które zrobią nam odpowiednie statystyki. Dzięki nim zdobędziemy pewną wiedzę na temat najczęściej używanych danych. Istnieją również odpowiednie eksperckie systemy informatyczne, które na podstawie pewnych zadanych kryteriów potrafią wyznaczyć zależności między danymi, pozornie niezwiązanymi ze sobą. Nie jest to powszechna metoda wśród testerów. Takie systemy mogą jednak również dostarczyć wiedzę biznesową lub pomóc ustalić pewne reguły zachowania.
8. Zrozumienie biznesowe testowanej aplikacji powinno być również realizowane przez samego testera. Sytuacja, w której testerowi nie zależy na zdobyciu wiedzy biznesowej wpływa negatywnie na oprogramowanie. Testowanie odbywa się zależnie od kontekstu, wobec tego osoba niechętna to nauki lub analizy biznesowej nie powinna testować. Stosowanie wymówek typu: "ja nie jestem osobą biznesową", "niech biznesowe testy zrobi sobie klient, itd." nie przystoi komuś, kto uważa się za doświadczonego testera. W dzisiejszych czasach wszyscy mamy dostęp do Internetu, a co za tym idzie dostęp do różnych portali, na których można pozyskać pewną wiedzę, np. prawo bankowe, leasing, administracja. Taka wiedza jest dość ogólna. Nie opisze wszystkiego, co dotyczy konkretnego klienta, ale z pewnością sporo może pomóc. Również przegląd statystyk np. w przypadku pożyczek czy kredytów może podpowiedzieć, jakie dane wejściowe zastosować w celu zaprojektowania testów. Tester może także zadbać o to, aby warunki oczekiwane w przypadkach testowych były sprawdzane przez osoby znające biznes. Z kolei kierownik testów może wprowadzić takie wymaganie, żeby warunki końcowe w przypadku testowym potrafiły odpowiedzieć na pytanie, jaka wartość biznesowa została osiągnięta po wykonaniu testu.

Spośród wyżej wymienionych rozwiązań nie należy stosować wszystkich naraz. Niektóre z nich jednak mogą okazać się bardzo pożądane i mogą poprawić jakość testowania.

Ciekawą strategią z punktu widzenia testowania w oparciu o proces biznesowy jest testowanie oparte na funkcji, które „wymaga zrozumienia, że nie wszystkie funkcje są równe i nie każda funkcja jest kluczowa dla działania biznesu. Funkcje można dzielić w zależności od krytyczności, obszaru czy wyróżniać funkcje pożądane i niepożądane” [2]. Strategia ta może okazać się niezbyt łatwa, wymaga od testera własnego zaangażowania oraz większego wysiłku, ale z pewnością ma swoje dobre zastosowanie w praktyce. Szczegóły tej strategii są opisane w pozycjach [1,2]

Podsumowanie

Celem napisania niniejszego artykułu było zwrócenie uwagi na problemy, które mogą pojawić się podczas testowania - ryzyko przetestowania niezgodnie z procesem biznesowym. Autor biorąc pod uwagę literaturę oraz własne doświadczenie pragnie podać kilka wskazówek (nie są to wszystkie możliwe wskazówki), które mogą usprawnić testowanie w oparciu o proces biznesowy. Artykuł nie jest adresowany tylko do testerów, lecz także do osób odpowiedzialnych za jakość produkowanego oprogramowania np. do kierownika testów czy kierownika projektu. Zwłaszcza te osoby powinny mieć wypracowane strategie eliminowania ryzyka biznesowo niepoprawnych testów.

Autor: Marek Żukowicz

Literatura