Tablice decyzyjne tworzone są w celu pokrycia testami wszystkich możliwych stanów aplikacji. Zazwyczaj tworzone są, by zobrazować testy fragmentu aplikacji.
Wyobraź sobie, że masz do przetestowania formularz zapisu na newsletter. Niech będzie to najprostszy z możliwych takich formularzy zawierający pole e-mail oraz formatkę do zaznaczenia zgody na przetwarzanie danych.
Co byś sprawdził? Jakie testy przychodzą Ci do głowy?
Zgaduję, że może zacząłbyś od kliknięcia zapisz bez wpisywania niczego? Potem może wpisałbyś byle co i kliknął zapisz? Następnie wpisałbyś poprawny adres i nie zaznaczył formatki? I wreszcie podałbyś prawidłowy adres i zaznaczył zgodę na przetwarzanie danych. Kolejność nie ma znaczenia.
Czy wszystko pokryłeś testami?
I tak i nie. Tak, ponieważ z logicznego punktu widzenia, jeśli po kliknięciu zapisz, gdy e-mail jest pusty i formatka nie zaznaczona, dostałeś komunikat o braku wymaganej zgody oraz adresu e-mail, to prawdopodobnie dla przypadku brak e-maila i zaznaczona formatka dostaniesz ten komunikat. Jednak wymieniając przypadki „z głowy” nie wziąłeś tego pod uwagę. A może i innych?
Po co testerowi tablice decyzyjne?
Tablice decyzyjne służą nam do tego, by rozpisać sobie to, jak aplikacja ma się zachowywać w różnych warunkach. Prawidłowo rozpisane uwzględniają wszystkie stany aplikacji również i takie, do których z logicznego punktu widzenia nigdy nie dojdzie w aplikacji.
Zaczynamy od definicji, czyli czym są tablice decyzyjne
Tablice decyzyjne należą do czarnoskrzynkowych metod testów. Odwołując się do definicji, którą znaleźć możesz na stronie SJSI, czytamy następującą regułkę.
Tablica decyzyjna – tablica pokazująca kombinację wejść i/lub czynników (przyczyn) z odpowiadającymi im wyjściami i akcjami (skutkami), pomocna w projektowaniu przypadków testowych.
Przykład – Tworzenie tablicy decyzyjnej formularza zapisu na newsletter
Weźmy na początek taką właśnie najprostszą tablicę. Mam formularz zapisu na newsletter znajdujący się na tej stronie.
W nim pole tekstowe oraz checkbox. Wypełnienie obu pól jest wymagane przy zapisie na newsletter.
W celu niekomplikowania zadania przyjmijmy, że przetestować chcemy tylko wymagalność pól.
Pierwsza kolumna tablicy decyzyjnej służy rozpisaniu warunków, które testujemy. Każdy warunek to nowy wiersz tabeli decyzyjnej. Dobrze jest je rozpisać tak, by odpowiedź na nie była tak/nie.
Kolejne kolumny to stany, jakie może przy danych warunkach przyjąć aplikacja. Ich ilość zależy od ilości warunków.
Każdy warunek wpisywany jest w kolejnym wierszu tabeli.
W ostatnim wierszu tabeli wpisujemy spodziewany wynik.
Oto jak wyglądałaby tablica decyzyjna dla wspomnianego powyżej formularza zapisu na newsletter.
Mamy zatem cztery przypadki do przetestowania dla przykładu testu wymagalności pól formularza zapisu na newsletter.
Scenariusz pozytywny dotyczy sytuacji, kiedy podano e-mail i wyrażono zgodę.
Trzy przypadki testowe dotyczą scenariusza negatywnego, czyli sytuacji, w jakich po kliknięciu „zapisz” mamy otrzymać komunikat o błędzie.
Gdyby to rozpisać mielibyśmy do wykonania następujące testy:
- System zapisuje na newsletter po podaniu adresu e-mail i zaznaczeniu checkboxa.
- System wyświetla błąd, gdy użytkownik nie podał adresu e-mail oraz nie zaznaczył formatki.
- System wyświetla błąd, gdy użytkownik podał adres e-mail oraz nie zaznaczył formatki.
- System wyświetla błąd, gdy użytkownik nie podał adresu e-mail oraz zaznaczył zgodę na przetwarzanie danych.
Czy zatem tablice decyzyjne używa się tylko podczas testów wymagalności pól?
Nie, ale takie tablice są najłatwiejsze do wytłumaczenia.
Prosta tablica decyzyjna weryfikująca tylko wypełnienie danych wymaganych formularza zawsze będzie obrazować przypadki, z których wszystkie są możliwe do wystąpienia w systemie. Pomimo tego nie zdarzyło mi się testować wymagalności pól formularza na zasadzie kolejnego sprawdzania każdego pola. Działo się tak z prostej przyczyny, nikt nigdy nie dał mi czasu na to bym to robiła. Testy wymagalności pól (o ile wymagalność nie zależała od wartości w innym polu) testowałam zwykle poprzez kliknięcie zapisu bez podania danych w formularzu. I to wystarczało.
Ilość możliwych stanów aplikacji w przypadku tablic decyzyjnych jest równa 2^n (dwa do potęgi n)
Liczba przypadków dla tablic decyzyjnych równa jest 2 ^ n (gdzie n to liczba danych wejściowych).
Jak więc łatwo policzyć liczba ta rośnie bardzo szybko wraz ze wzrostem liczby danych wejściowych.
I tak w powyższym przykładzie były 2 dane wejściowe, liczba możliwych przypadków = 2 ^ 2 = 4.
Dla przykładu z zapisem na newsletter można dodać podczas realnych testów jeszcze jeden warunek:
Czy e-mail poprawny?
Wówczas mamy 3 dane wejściowe, zatem liczba przypadków = 2^3 = 8.
Czyli otrzymujemy osiem przypadków testowych.
Wśród nich od razu możemy wykluczyć z testów dwa, których test nie ma sensu (szare tło kolumn). Te przypadki nie są możliwe w systemie, ponieważ nie jest możliwe niepodanie e-maila, który jest zarazem poprawny.
Jeśli wrócić do początkowo rozpisanych „z głowy” przypadków testowych, to zauważysz, że pominęliśmy testy dla podanego niepoprawnego adresu e-mail i zaznaczonej formatki. Pytanie, jak bardzo ten test jest konieczny, jeśli sprawdziłeś „Może wpisać byle co i kliknąć zapisz?” pozostawiam tobie.
Przykład – tablica decyzyjna kalkulatora pożyczki
Tablica decyzyjna dotyczy testu systemu dla różnych danych. I tak to od nas zależy co testujemy, jakie warunki i co za tym idzie, jak ją stworzymy. Przykładowo możemy mieć do testów kalkulator pożyczkowego. Przyjmijmy, że ma on dwa pola: wiek i zarobki.
Wiemy, że aby dostać pożyczkę trzeba mieć >18 lat i zarobki > 2000.
Krok po kroku tworzenie tablicy decyzyjnej (na przykładzie powyższego kalkulatora).
- Zapisz warunki i wynik testów, które chcesz przetestować, tak by móc na nie odpowiedzieć prawda/fałsz (True/False).
Czy wiek > 18?
Czy zarobki > 2000?
2. Policz ilość przypadków testowych (2 ^ liczba_warunków).
2 ^ 2 = 4
3. Stwórz tabelę. Przyjmij, że liczba_kolumn = wynik z punktu 2 + 1, liczba_wierszy = liczba_warunków + 1.
4. W pierwszej kolumnie wpisz w kolejnych wierszach warunki, w ostatnim wierszu wpisz spodziewany wynik.
5. Wypełnij tabelę tak, by kombinacja wyników nie powtórzyła się w żadnej kolumnie.
Dobrym sposobem jest trzymanie się zasady:
Pierwszy wiersz wypełniam kolejno YNYN.
Drugi wiersz wypełniam trzymając się wzorca YYNNYYNN.
Trzeci YYYYNNNNYYYYNNNN.
Czwarty YYYYYYYYNNNNNNNN.
Jak widać, zasada jest taka, że liczba tych samych liter sąsiadujących ze sobą jest dwa razy większa niż w wierszu poprzedzającym.
6. Mając rozpisane warunki, uzupełnij wynik na podstawie dokumentacji aplikacji.
7. Wyeliminuj stany, które są niepotrzebne do testów.
Przykładowe zadania z ISTQB dotyczące tablic decyzyjnych
Poniżej znajdziesz dwa zadania dotyczące tablic decyzyjnych, które umieszczone są w przykładowych testach do certyfikatu ISTQB FL.
Wygląda na to, że w tabelce w powyższym zadaniu jest błąd. W kolumnie T4 po spełnieniu wszystkich warunków powinno nastąpić przyznanie bonusu.
Mamy więc sytuację, w której pracownicy dostają premię, jeśli pracują przez dłużej niż rok, zgodzili się na cel i osiągnęli go (np. sprzedaż 50 aut).
Gdyby tę sytuację rozpisać w tabeli decyzyjnej to otrzymalibyśmy taką tabelkę.
Teraz wykluczmy sytuacje niemożliwe w realnym życiu.
Wychodzi na to, że odpadają nam dwa warunki, które dotyczą sytuacji, gdy pracownik osiągnął cel, ale nie wyraził na niego zgody.
Teraz popatrzmy na odpowiedzi do zadania.
a) dotyczy jednego z niemożliwych scenariuszy
b) zawiera błąd – premia jest przyznawana pracownikowi, który nie spełnił na nią warunków
c) ta odpowiedź dotyczy drugiego wykluczonego z tablicy scenariusza
d) Ta odpowiedź jest prawidłowa, dotyczy sytuacji, gdy pracownik nie przepracował roku, wyraził zgodę i nie osiągnął jeszcze wyznaczonego celu.
Bardzo podobne wytłumaczenie tego zadania znajdziesz w pliku z odpowiedziami do testu, który również można pobrać.
Zadanie z zestawu B
Testowany jest system pobierania opłat za przekroczenie dozwolonej prędkości. Mierzone są prędkość pojazdu oraz to czy doszło do wykroczenia w pobliżu szkoły. Wynikiem zajścia warunków może być mandat lub więzienie.
Mamy więc dwa warunki, czyli kompletna tablica decyzyjna będzie miała cztery stany (przypadki).
Pierwszy i czwarty stan są uwzględnione w tablicy decyzyjnej.
Celem zadania jest podanie, które przypadki z drugiej tabelki powinny zostać przetestowane w celu pokrycia testami całej tablicy decyzyjnej.
Szukamy zatem kolumn, dla których
1. Prędkość poniżej 50 w pobliżu szkoły.
2. Prędkość powyżej 50 i nie jest to strefa szkoły.
Są to kolumny DT2 i DT4, czyli powinniśmy zaznaczyć odpowiedź C.
Podsumowanie
Pytania dotyczące tablic decyzyjnych pojawiają się często w części praktycznej, na rozmowach rekrutacyjnych na stanowisko testera oprogramowania.
Jeśli wierzyć statystykom, to na egzaminie ISTQB FL na 40 pytań testowych, jedno dotyczy tablic decyzyjnych. Obliczenia dokonałam poprzez przejrzenie przykładowych pytań do egzaminu ISTQB FL, które możesz znaleźć na stronie istqb.org. Certyfikat ISTQB FL jest chyba najbardziej znanym i najczęściej zdawanym wśród testerów. Często jest również wymagany lub też mile widziany przez firmy rekrutujące.
Problem z tablicami decyzyjnymi dotyczy tego, że ilość przypadków testowych rośnie lawinowo przy dużej ilości danych wejściowych. Dlatego nie spotkałam się jeszcze nigdy z ręcznym testowaniem wszystkich możliwych kombinacji danych bez eliminacji niektórych przypadków. Najczęściej tablica napisana na kartce służyła mi tylko do tego, by pomóc sobie podczas testów. Zwykle wówczas dotyczyła wybranych pól aplikacji, a nie całych formularzy.
Miałam natomiast do czynienia z sytuacją współpracy testera z programistą w celu pokrycia testami automatycznymi aplikacji. Dane do testów pobierane były z tablicy.
Super pomocny artykuł, dziękuję
Cieszę się, że Ci się przydał 🙂
Chodzi o pierwsze zadanie z „Przykładowe zadania z ISTQB dotyczące tablic decyzyjnych”. Dlaczego uznano 2 scenariusze jako niemożliwe? Czyż nie jest możliwy scenariusz w realnym życiu że bez względu na długość pracy i bez zgody na cel pracownik osiągnął cel? Przecież mógł mimo tego sprzedać 50 aut lub więcej.
Zapomniałem o jeszcze o jednym. W tabeli w tym zadaniu (treść pytania po angielsku) jest błąd (T4)? Przecież zostały spełnione wszystkie warunki a premia niby nie została przyznana. Następnie autorka w swojej tabeli ujmuje ten sam przypadek – po spełnieniu wszystkich warunków pracownik dostaje jednak premie.
Ta treść w języku angielskim jest obrazkiem z oryginalnego próbnego testu. Wygląda na to, że jest w nim błąd. Natomiast tabelkę poniżej rozpisywałam sama i biorąc pod uwagę warunki początkowe, zaznaczyłam, że pracownik dostaje bonus, gdy spełnia wszystkie kryteria. Dziękuję za tą uwagę, umieszczam pod obrazkiem informację, że jest w tabelce błąd.
Oczywiście, że jest możliwe, że pracownik sprzeda w pierwszym roku więcej niż 50 aut. Nie zmienia to jednak faktu, że w specyfikacji jest informacja iż bonus może dostać ktoś kto przepracował rok, zgodził się na mierzenie celu a także sprzedał wystarczającą ilość aut czy towaru. Jeśli firma określa takie warunki, nam pozostaje je sprawdzić.