TRANSKRYPCJA

 

Dzień dobry Państwu, wita Państwa Piotr Furtak, trener Altkom Akademii. W naszym dzisiejszym spotkaniu chciałbym przedstawić Państwu jedną z popularniejszych technik projektowania testów – technikę przejść między stanami.

 

Jest to technika czarnoskrzynkowa, bardzo często opisywana w literaturze tematu, obecna w programie kursów propedeutycznych opisujących podstawy testowania oprogramowania, obecna również na egzaminach na certyfikaty testerskie. Popularność tej techniki wynika głównie z tego, że dostarczana przez nią konwencja graficzna jest na tyle zrozumiała, na tyle jasna i intuicyjna, że może być przydatna nawet wśród członków projektu, którzy nie mają podstaw teoretycznych, matematycznych; generalnie widać po prostu na rysunku co się ma wydarzyć w przyszłym systemie.

 

Daje to możliwość szybkiego wyjaśnienia przyszłego procesu, ewentualnie dyskusji nad niejasnościami, które mogłyby na takim rysunku wystąpić. Podstawy tej techniki są bardzo mocne – jest ona związana mocno z teorią grafów i wielu autorów w toku ostatnich dekad opisywało w jaki sposób można obliczać złożoność przyszłego systemu, w jaki sposób można projektować przejścia, które w takim systemie by następowały.

 

Mamy tutaj wymienione nazwiska dwóch podstawowych, aczkolwiek jest tutaj wiele prac innych naukowców, chociażby bardzo popularne jest pokrycie czoła. Zarysowywany system bywa nazywany maszyną stanów bądź automatem skończonym; skończoność, która się w tej nazwie pojawia wynika z tego, że zbiór stanów, które możemy przedstawić musi być właśnie skończony, nie zakłada się tam rozwoju, tak samo zbiór przejść, które można wykonać między tymi stanami. Metoda ta okazała się na tyle przydatna, a forma graficzna na tyle pomagająca w zrozumieniu projektu, że grafy tego typu zostały zaimplementowane do języka modelowania, do UML-a.

 

Chciałbym zwrócić uwagę na coś co jest bardzo typowe dla pracy testerów, mianowicie poczucie najczęściej pewnego chaosu – w momencie kiedy dostajemy jakąś dokumentację wymagań, ona często jest spisana w postaci zdań w języku naturalnym. Bardzo różne konwencje panują w różnych firmach, ale również po prostu wśród różnych twórców przyszłych systemów i bardzo często po przejrzeniu iluś tam dokumentów testerzy, którzy wiedzą, że za moment będą musieli przystąpić do projektowania testów, wymyślania w jaki sposób ten przyszły system sprawdzić, a ewentualnie jak ocenić jego stopień złożenia, jak ocenić to, czy został w ogóle dobrze zaprojektowany, często brakuje właśnie jednoznaczności w tych opisach.

 

I tutaj ta technika zdecydowanie może nam pomóc, z racji tego, że wymaga ona od nas przedstawienia przyszłego systemu w formie graficznej, w formie, która jest jednoznaczna – a jednoznaczność to jest coś czego chyba najbardziej tester potrzebuje w momencie kiedy pracuje w projekcie.

 

Wyobraźmy sobie jakieś proste, wyimaginowane urządzenie, które będzie przedstawiało nam różne stany – niech będzie to jakiś prosty dyktafon cyfrowy, rozrysowany tutaj, jak widzicie, w postaci takiego mocka, mamy tutaj obrazek, który ideowo nam przedstawia jakieś urządzenie. Z lewej strony widzimy jakiś włącznik, można to urządzenie sobie uruchomić, no i widzimy tutaj przyciski.

 

Część z tych przycisków jest oznaczona graficznie w taki sposób, że odwołuje się to do naszych popularnych intuicji,  tak, że większość osób tutaj rozpoznaje zielone przyciski jako przycisk play, widzimy przycisk, który najprawdopodobniej będzie powodował zapauzowanie jakiegoś procesu, widzimy też na czerwonym przycisku symbol oznaczający nagrywanie, stop też, kwadracikiem przedstawiony, wydaje się być dosyć oczywisty.

 

Ale widzimy też, że pewne rzeczy prawdopodobnie będą do osiągnięcia w tym budowanym urządzeniu na skutek wyborów, które się będą pojawiały, opcji, które będą nam przedstawione, zapewne na interfejsie graficznym; ponieważ widzimy strzałkę w górę, strzałkę w dół, to są abstrakcyjne symbole, które mogą przyjmować różne znaczenia, w zależności od tego co faktycznie tam będziemy w danym momencie na ekranie mieli.

 

Ten stan, w którym właśnie będziemy dostawali informacje co można zrobić dalej poprzez wykonanie jakiejś akcji, jak sama nazwa wskazuje, będzie właśnie tutaj odpowiadał stanom naszej przyszłej maszyny stanów. Wyobraźmy sobie, że włączamy nasze urządzenie, wita nas ono ekranem powitalnym, jest tutaj wyraźnie napisany tekst „Witaj!”, nie jest jednoznacznie na tym obrazku powiedziane co się będzie działo dalej, nie widzę tutaj na tym ekraniku żadnego prompta, żadnego ponaglenia aby coś zrobić.

 

Być może po kilku sekundach po prostu moje urządzenie przejdzie do jakiegoś innego stanu. Na tym etapie, jeżeli moja dokumentacja wyglądałaby wyłącznie tak jak teraz, nie wiedziałbym tego jeszcze. Załóżmy, że następny stan, który tutaj zaprojektowano dla nas, wygląda w ten sposób. Widzimy tutaj, że już jest jakiś numer projektu, czyli prawdopodobnie będzie to pierwszy projekt 001. Widzimy ponaglenie – jest tutaj informacja, że należałoby wcisnąć przycisk nagrywania, no tutaj akurat REC od Record, ale widzimy też, że jest jakaś opcja inna, jedna ze strzałek tutaj pokazanych, jedna ze strzałek, ta mierząca w dół, miałaby nas skierować w kierunku jakiegoś menu.

 

A zatem już na tym etapie widzimy, że z tego stanu można wyjść na więcej niż jeden sposób; czyli mogę wcisnąć nagrywanie, prawdopodobnie wtedy proces nagrywania się rozpocznie, ale mógłbym też pójść do jakiegoś właśnie menu. A zatem gdybyśmy sobie teraz próbowali rozrysować strzałkami co można z tego stanu osiągnąć, tu mielibyśmy w naszym procesie jakieś rozwidlenie. Także można sobie to w tym momencie już zarysować w wyobraźni.

 

Załóżmy, że wciśniemy jednak nagrywanie. Wciskamy nagrywanie, widzę, że stan się zmienił, system informuje mnie, że nagrywa jakiś materiał dźwiękowy, tutaj ideowo jest przedstawiony licznik czasu, tak, że ten czas będzie nam tutaj prawdopodobnie przyrastał sekundowo. Natomiast gdy tak krytycznym okiem spojrzymy na ten interfejs graficzny, to widzimy, że bardzo niewiele informacji on nam w tym momencie tak naprawdę podaje.

 

Nagrywanie przebiega, natomiast nie wiem co by się stało gdybym nagle wpadł na pomysł wciśnięcia strzałki w górę, nie wiem co by się stało gdyby było w dół; prawdopodobnie mogę to zatrzymać. Z doświadczenia wiem, ze jak wciskamy stop w takich sytuacjach, to proces się przerywa, tak, także tutaj można domniemywać, że ten przycisk jest wystarczająco znaczący. No ale nie wiem, czy można zapauzować proces nagrywania, czy jest on zarezerwowany wyłącznie, ten przycisk pauza, do odtwarzania nagranego materiału – trudno powiedzieć tak naprawdę, tutaj już tester może sobie postawić wiele różnych teorii.

 

No i kolejne jest to miejsce, w którym bardzo chcielibyśmy mieć to ujednoznacznione, żeby był jakiś rysunek, który nas poinformuje co ja z tego stanu faktycznie mogę zrobić; także po raz kolejny widzimy, że sam obrazek nie wystarcza, że aż prosi się żeby rozrysować co tutaj się może wydarzyć albo to opisać. Możemy na próbę wcisnąć sobie pauzę. Wciskamy pauzę, widzimy, że,o, dobra, ok, rzeczywiście można zapauzować proces nagrywania.

 

Jeżeli można zapauzować to prawdopodobnie można również, od tego momentu, który tutaj jest zaznaczony, 1:17, można zapewne ponowić to nagrywanie, ale, znowu, tutaj projektant nie zostawia informacji jednoznacznej, nie wiem czy w tym momencie powinienem wcisnąć jeszcze raz pauzę, nie wiem, czy wciśnięcie przycisku nagrywania wyjdzie ze stanu pauzy; no, oczywiście testerzy by tutaj natychmiast pokombinowali ze wszystkim.

 

A co się stanie, jeżeli wcisnę play? A co się stanie, jeżeli wcisnę na przykład dwa przyciski naraz? Także tutaj pytań od razu pojawia się bardzo dużo. No, w każdym razie, znowu, ta forma przedstawienia przyszłego systemu i interfejsu graficznego jest bardzo, jak się okazuje, ułomna. Możliwości jest dużo.

 

Załóżmy, że akurat w tym systemie on jest czysto hipotetyczny, tak że można sobie dowolne historyjki przy nim wymyślić. Załóżmy, że wciskamy pauzę żeby wrócić do procesu nagrywania no i rzeczywiście, nagranie idzie sobie dalej, rozpoczyna się tam od momentu, w którym pauza nastąpiła, przebiega, przebiega sobie, no właśnie, z jakąś długością, tak, dużo wskazuje na to, że jeżeli wcisnę stop, to w sposób bardziej jednoznaczny zakończę ten proces nagrywania więc pewnie zaraz to sobie przetestujemy, natomiast też można by się zastanowić, czy to jest jedyna forma zakończenia tego procesu, który właśnie tutaj mamy zobrazowany.

 

Możemy sobie wyobrazić, że jest to jakiś rejestrator cyfrowy więc prawdopodobnie ma jakiś nośnik dźwięku, jakąś kartę SD na przykład, na której kolejne sektory pamięci są zajmowane. Prawdopodobnie jest jakaś ustalona pojemność tego nośnika więc zapewne w którymś momencie ten system, nie wiem, być może by nas zaczął ostrzegać, że zostało już tylko 5 minut albo po prostu by się zawiesił, scrushował, cokolwiek. Także to byłby pewnie jeden tam z testów, które byśmy sobie wymyślili, no ale na tym etapie dobrze byłoby mieć jednoznacznie powiedziane co się ma stać kiedy wciskam przyciski.

 

Załóżmy, że wciskamy stop akurat tutaj. Wcisnęliśmy stop, o, i widzimy, że możemy sobie uwiecznić ten zapisany materiał. Dostajemy pytanie, czy mamy zapisać, zasave’ować nagrany materiał, widzimy jego długość, 3:46. No i teraz na interfejsie jest jednoznaczna wskazówka, że jeżeli wcisnę strzałkę w dół, to nastąpi zapisanie. Nie ma informacji natomiast co by się stało gdybyśmy wcisnęli pozostałe przyciski i tutaj już też właśnie testerski umysł prawdopodobnie by wyobraził sobie te przyciski albo nawet ich tam kombinacje jako różne strzałki wiodące do znaku zapytania co tu się może stać jeżeli ja się zacznę bawić resztą interfejsu.

 

Tutaj oczywiście mamy zarysowane proste urządzenie, jakiś prosty projekt, a zatem nie ma zbyt wielu opcji, natomiast liczba kombinacji, tam momentami się zarysowywało, że potrafi być dosyć duża. No więc, jak wspomniałem na samym początku, testerzy bardzo lubią uściślenia, lubią mieć jednoznacznie powiedziane, jak system ma się zachowywać.

 

Tutaj w kilku momentach naprawdę można było postawić dużo pytań. No, to są sprawy, które należałoby wyjaśnić, tak, że same te rysunki nie wystarczają. Należałoby ustalić albo w tekście gdzieś towarzyszącym tym grafikom albo najlepiej właśnie w postaci rozrysowania jakiegoś diagramu jak faktycznie ten system się może zachowywać, jakie są opcje, które przyciski kiedy są aktywne, kiedy natomiast powinny pozostać zdeaktywowane.

 

W momencie kiedy byśmy tutaj siedzieli razem nad rysunkiem z takim projektem, programista mógłby zadać cenne pytanie, on mógłby chcieć już na tym etapie sobie wymyślać jakie zmienne obsługiwałyby konkretne fragmenty tej logiki; na pewno powstałoby tutaj wiele pytań, które można byłoby właśnie stawiać – czy mogę na przykład odpauzować wciskając pauzę, czy mogę odpauzować wciskając przyciskiem rec? I tak dalej, i tym podobne.

 

Natomiast te wszystkie pytania najsensowniej można byłoby zadawać, najwięcej przyniosłyby pożytku i najszybciej by dyskusja przebiegała, gdyby były właśnie nad jakimś rysunkiem przedstawiającym te wszystkie stany w jednym miejscu – i temu właśnie będzie służyła taka notacja.

 

Zobaczmy sobie teraz jak można byłoby hipotetycznie ten systemik, który jest wbudowany w to urządzenie, przedstawić, te stany, które się w nim tutaj pojawiają. Widzimy tutaj strukturę taką, niepełną mapę przejść między stanami, no ale widzimy, że rzeczywiście ponazywane są te momenty z działania naszego urządzenia w postaci bloczków obłych – no i tutaj odwzorowane faktycznie chociażby jest to, że na etapie kiedy wyświetlał nam się ten pierwszy projekt z gotowością do nagrywania można było rzeczywiście przejść do menu, widzimy tutaj długą strzałkę, łuk, który idzie dołem, do tego menu nam sięga.

 

Nie mamy przy tych strzałkach jeszcze napisane jakie to przyciski. Tutaj na tym etapie chociażby można by było z takiej ilustracji skorzystać i ponanosić właśnie na nią dodatkowe informacje, które dostarczałyby właśnie wiedzy na temat tego, który przycisk jaki proces wywołuje, dodatkowo można byłoby też opisać co się dzieje w czasie zachodzenia tego procesu w systemie; tak, że jest to to szablon, na którym można byłoby się oprzeć żeby jak najbardziej zabudować dla wszystkich tutaj biorących udział w tym projekcie właśnie sytuacje.

 

Można by też właśnie stawiać pytania na przykład; jednoznacznie chcielibyśmy się dowiedzieć, dobrze, a czy nagrywanie, jeżeli już faktycznie zostało zatrzymane, czy na przykład można je ponowić? Bo czemu nie, w końcu jest to coś co może przyjść do głowy i teraz czy ono ponawiałoby się od momentu, kiedy zostało zatrzymane, a może byłoby tutaj nagrywane od początku, tak, żeby wykorzystać po prostu tę samą nazwę pliku?

 

Tak, że tych opcji jest całkiem dużo, ale znacznie wygodniej jest rozmawiać właśnie patrząc na rysunek i tu właśnie przy tej strzałce można byłoby nanieść adnotację, jakiś dymek, z pytaniem, które by się pojawiło podczas jakiegoś spotkania projektowego. Inna sprawa co na przykład z zatrzymaniem nagrywania; tam praktycznie można było wyłącznie przejść z tego co było widać na obrazkach do zapisania projektu.

 

A może ktoś by sobie życzył żeby móc przeskoczyć do menu, żeby podejrzeć nazwy wcześniej zapisanych projektów? Też pytanie, które oczywiście mogłoby się spotkać z odpowiedzią negatywną, ale można byłoby je zadać w sposób jednoznaczny, zilustrować to właśnie taką strzałką, która teraz się pojawiła.

 

Może zupełnie jakaś inna możliwość? Widzimy, że od ekranu powitalnego do nowego projektu przechodziliśmy, tam w zasadzie wszystko wskazywało na to, że po prostu następował ten kolejny stan, a może ktoś by wolał żeby istniała taka opcja żeby po ekranie powitalnym natychmiast pojawiało się menu zamiast jakiegoś nowego projektu. To by się bardzo fajnie nadawało na funkcję w ogóle, że można byłoby przełączać sobie rejestrator w taki sposób żeby wybrać albo taki stan startowy albo inny, także tutaj takie pytanie by powstało, moglibyśmy zaproponować, zasugerować istnienie takiej strzałki.

 

To wszystko, co teraz opowiadam, ma na celu w gruncie rzeczy podsumowanie spraw, które są według mnie oczywiste i pewnie każdy dobrze wie, że najlepiej sobie właśnie rozrysować w jakimś stabilnym układzie to co się może wydarzyć w naszym systemie, natomiast mając już zarysowany taki właśnie kawałeczek mapy, przejść między stanami, spójrzmy jak wygląda cały ten koncept od strony teoretycznej.

 

Technika przejść między stanami jest jednym ze sposobów modelowania systemów, czyli przedstawiania sobie systemów w taki sposób, aby było to przedstawienie jednoznaczne, ograniczone wyłącznie do tych aspektów, które nas faktycznie interesują i poddane takim rygorom żeby notatki te, mapy, za każdym razem można było rozumieć w ten sam sposób i żeby można było jasno wskazać na przykład co jest w takiej notatce błędne.

 

Maszyna stanowa będzie składała się z niewielkiej liczby możliwych, graficznych elementów; mamy tutaj je wypisane. Stan, Przejście, Zdarzenie, Działanie, zwane też Akcją, opcjonalnie można też zapisać Warunek, który towarzyszyłby Zdarzeniu. Nazewnictwo, które obowiązuje, czasami nieco się różni; różnie w różnych książkach tłumaczone są na przykład Działania, dlatego tutaj właśnie mamy Akcję w nawiasie, ale w większości przypadków różnice nie są duże.

 

Pierwsza sprawa, podstawowa, to Stan. Stan jest obrazowany prostokątem, czasami kółeczkiem, w zależności od tego jaką konwencję się przyjmuje. Konwencje niebawem pokażę. Stan musi być jakoś nazwany, musi być unikalny jeżeli chodzi o swój numer, o swój symbol, który będzie go tutaj nam identyfikował. Jak widzicie, tutaj, no, mamy definicję, która stara się być możliwie jak najbliższa prawdy w każdej możliwej sytuacji, dlatego jest ona bardzo ogólna, ale mówiąc prosto, Stan opisuje jakąś sytuację, która zachodzi w naszym systemie, jest sytuacją powtarzalną, w momencie kiedy ten Stan obserwujemy, nie zmienia się ta sytuacja, tak, że musi być on stabilny, niezmienny w czasie.

 

Zmienność, czyli właśnie jakieś zmiany, które będą zachodziły w naszym systemie, czy to sprowokowane przez nas, czy będące skutkiem jakiegoś działania, będą odwzorowywane już za pomocą strzałek, opisu działań. A zatem Stan musi być możliwie stabilny. Natomiast zmiany będą właśnie ilustrowane przejściami.

 

No i teraz przejście to najczęściej po prostu strzałka; strzałka, która w jedną stronę tylko się zwraca, tak, czyli wiedzie nas od stanu wyjściowego do stanu wejściowego. Jest to wynik jakiegoś Zdarzenia. Zdarzenie zaraz zostanie opisane. Ważną sprawą jest to, że strzałki te mają groty skierowane zawsze w jednym kierunku.  Zdarzenie – Zdarzenie opisujemy już przy strzałce.

 

Zdarzenie, event, wejście, bodziec – z takimi pojęciami się można spotkać kiedy się właśnie rozbiera ten temat od strony teoretycznej. Ważne jest to, że Zdarzenie zawsze przychodzi z zewnątrz systemu – czyli nie jest to coś, co się w systemie wzbudza samo, musi być jakaś siła wyższa.

 

Tutaj w naszym przypadku, przy naszym przykładzie, to po prostu była intencja człowieka, który wciskał przyciski. Zatem Zdarzenie będzie prowokowało Przejście, będzie doprowadzało do tego Przejścia. Samo Zdarzenie jest chwilą, jest chwilowe, nie jest jakimś procesem długo zachodzącym, musi być jak najkrótsze tak aby można było właśnie stworzyć sobie taki zestaw, zbiór zdarzeń, które akceptujemy, które są rozpoznawalne i więcej się nimi nie zajmować tak naprawdę, one są tylko bodźcami dla naszego systemu.

 

Natomiast pod kreską, która jest tutaj zarysowana pod słowem „Zdarzenie”  widzimy Działanie i Działanie może już trwać nieco dłużej, Działanie będzie nam opisywało co się w tym naszym systemie wyzwoliło, co zostało puszczone w ruch, co się wydarza podczas tego momentu kiedy przechodzimy ze stanu pierwszego do drugiego. Tutaj można byłoby na przykład dać adnotację z informacją ile to trwa.

 

Jak Państwo widzą, opcjonalnie można jeszcze dopisać w takim schemacie warunki. Warunek byłby technologiczną formą opisu, wskazywałby na to co faktycznie w tym systemie się wydarza od strony technicznej, czyli tutaj na przykład mielibyśmy informacje o tym jaka metoda została wyzwolona, jaka zmienna przyjmuje jaką wartość.

 

Najczęściej tutaj będzie ten taki fragmencik dla developera, ale również dla testera, który by mógł od tej strony przetestować przyszłą aplikację. Notacja, którą tutaj widzimy jest możliwie najbardziej intuicyjna i najprostsza jaką tylko można było zastosować, jednakowoż, ze względu na to, że w wielu różnych momentach różne osoby rozwijały tę koncepcję tej techniki, wyodrębniły się różne konwencje graficzne, na szczęście bardzo podobne do siebie. Trzy najpopularniejsze teraz przedstawię.

 

Mamy tutaj tradycyjną notację, analizę strukturalną i notację zgodną z UML-em, ale wszystkie te trzy obrazki wskazują dokładnie to samo. Jak widzimy, za każdym razem mamy komplet niezbędnych informacji dotyczących, z którymi stanami mamy do czynienia, jak wiodą strzałki i za każdym razem opisane właśnie jest Zdarzenie, Działanie, ewentualnie można do Zdarzeń dokładać jeszcze warunki, tak, że tutaj różnic żadnych nie ma.

 

Skoro już opisaliśmy sobie ogólnie jak wyglądają takie grafy, przejdźmy do założeń teoretycznych, które stoją na straży tego żeby to modelowanie za każdym razem działało tak samo. Warunki teoretyczne – w danej chwili maszyna stanów może być tylko w jednym stanie. Jest to warunek istotny bo ze względu na jego spełnianie, maszyny stanowe nie mogą obsłużyć żadnych procesów współbieżnych – czyli ten proces, który będziemy właśnie tutaj ilustrowali poprzez przechodzenie strzałkami od stanu do stanu zachodzi dokładnie tylko w tym miejscu, tak, że nie wydarzają się tutaj żadne rzeczy jednocześnie.

 

Jeżeli chcemy jakąś współbieżność oddać, to należałoby użyć już tutaj innych modeli. Jest to spore ograniczenie, niewątpliwie, natomiast siła tej techniki polega na jednoznaczności, którą właśnie można oddać poprzez takie pojedyncze procesy. Drugie przejście następuje ze stanu bieżącego do stanu wynikowego, no to po prostu informuje nas o tym, że strzałki są jednozwrotne tutaj, następnie stan końcowy jest tym, w którym maszyna przestaje przyjmować Zdarzenia.

 

Stan końcowy wypada graficznie jakoś zaznaczyć, w jakiś sposób szczególny, tutaj jest podwójna ramka. Nie w każdym natomiast schemacie, którego się używa przy projektowaniu i nad którym się dyskutuje, nie każdy będzie stan końcowy posiadał; w gruncie rzeczy często się można spotkać z takimi gdzie są jakieś pętle, tak, że można potraktować go jako coś opcjonalnego tutaj. Niejednokrotnie jest tak, że w maszynach skończonych wraca się do punktu wyjścia, tak, że jeśli rzeczywiście taki stan końcowy jest, no to jest to moment w którym maszyna przechodzi do jakiegoś tam stanu stand by, już nie przyjmuje więcej impulsów poza ponowieniem uruchomienia.

 

Każda niepowtarzalna para wejście – wyjście obecna w maszynie ma niepowtarzalny ciąg wejść poprzednich. Jest to bardzo teoretyczny warunek, potrzebny do tego żeby nie dochodziło do żadnych przeskoków ponad stanami, tak, że zachowuje to nam spójność tego grafu. Poniekąd wynika również z tego warunku to, że wszystkie stany są równoprawne, tak, że ogólnie na poziomie matematycznym rzeczywiście ten warunek okazuje się być ważny.

 

Następnie maszyna zaczyna działanie w stanie początkowym, no, od czegoś się musi faktycznie ten proces zacząć. Zazwyczaj stan początkowy jest wskazywany poprzez strzałkę, która dochodzi do tego stanu, natomiast nie wychodzi znikąd, tak, że można w ten sposób symbolicznie oddać rozpoczęcie pracy tego systemu. Następnie maszyna czeka na zdarzenie przez czas nieokreślony; chociażby dzięki temu warunkowi, jeśli jest jakiś stan końcowy, to jest tylko jeden, natomiast jeżeli nie jesteśmy w stanie końcowym, to maszyna po prostu będzie czekać i w tym momencie wszystkie stany poza stanem końcowym są równoprawne.

 

Jeśli zdarzenie nie jest akceptowane w stanie bieżącym, jest pomijane. Ten warunek informuje nas po prostu o tym, że nie będą nas interesowały Zdarzenia, które w danym momencie nie są przewidziane, tak. Tu oczywiście testerzy mogliby kombinować; mogliby różne Zdarzenia dodatkowe próbować wywoływać żeby zobaczyć, czy przewidział modelujący różne chociażby kombinacje jednoczesnych zdarzeń, ale generalnie na poziomie teoretycznym właśnie nasz model nie powinien akceptować warunków, które nie zostały przewidziane.

 

Następne dwa warunki stoją na straży powtarzalności działania naszego modelu; wszystkie stany są równoprawne, dają możliwość przechodzenia pomiędzy sobą. Natomiast warunek trzeci jest nieco innej natury; on mówi nam o granicach naszego modelu, czyli o tym, że nie będziemy próbowali opisywać Zdarzeń, które przychodzą spoza tego systemu, czyli to nas nie interesuje, tak jak na przykład intencja, która może być po stronie operatora tego systemu, nie jest tutaj opisana, my opisujemy wyłącznie to co ten system może zrobić w odpowiedzi na te intencje, czyli po prostu same warunki są tutaj opisane możliwie krótko.

 

Następny warunek mówi, że Zdarzenia rozpoznawane są pojedynczo; w każdej chwili następuje tylko jedno przejście. To jest bardzo pokrewne do warunku mówiącego, że tylko jeden stan w danym momencie może być aktywny. Czyli tutaj po raz kolejny brak współbieżności w takiej maszynie stanowej jest podkreślany. Następnie nie rozpoznaje się innych zdarzeń niż zdefiniowane przez model; bardzo podobne do jednego z wcześniejszych warunków, jeszcze raz jest tutaj jasno powiedziane, że tylko to, co zostało przewidziane może działać.

 

Stan bieżący może ulec zmianie tylko przez zdefiniowane przejście, odpowiednio tutaj właśnie też musimy mieć opisane wszystkie strzałki. Skończoność tego naszego właśnie systemu, skończoność tej maszyny jest w tym miejscu dodatkowo jeszcze zabezpieczona. Ostatnie dwa warunki natomiast informują nas o tym, że ten model nie może sam siebie rozbudowywać – czyli nie dochodzą nam żadne nowe stany i nie ubywa żadnych stanów. Musi być stały, ta maszyna musi być stała, musi mieć dokładnie opisaną liczbę stanów, jak i przejść.

 

Jest to też dosyć istotna sprawa jeżeli się projektuje właśnie za pomocą takiej notacji ponieważ po prostu wszystkie możliwe stany musimy od razu przewidzieć. Nie zakładamy tego, że coś w tej maszynie będzie doprowadzało do konstruowania kolejnych wierzchołków grafu, tak, że tutaj mamy do czynienia z tradycyjną logiką, tradycyjnie zamodelowanym systemem, który sam siebie nie będzie rozbudowywał w żaden sposób.

 

Warunki teoretyczne, które zostały tutaj przedstawione skutkują różnego rodzaju konsekwencjami. W oparciu o nie można wyznaczyć pewne struktury, które są niedopuszczalne w takim zarysowaniu przejść między stanami. Dzięki temu można sobie stworzyć listę podstawowych błędów, które mogłyby się pojawić w projekcie, które są częstsze od innych – i takie trzy podstawowe, najczęściej wspominane, tutaj przedstawię.

 

Jest to stan martwy, martwa pętla oraz tak zwany stan „magiczny”. Zacznijmy od stanu martwego; jeżeli do jakiegoś stanu wszystkie strzałki wchodzą, wszystkie przejścia wiodą w jego kierunku, a jednocześnie nie jest to stan końcowy, to jest to stan, którego nie powinno tutaj być, stan, z którego nie można po prostu wyjść.

 

Jeżeli coś takiego byśmy zauważyli, jeżeli dołączony do istniejącej dokumentacji wymagań, czy elementów projektu stan w ten sposób by wypadł w naszym grafie, tak by trzeba było go przedstawić, to od razu można oponować tutaj bo wskazuje na to, że coś jest nie tak z tym naszym modelowaniem. Podobną sytuacją będzie martwa pętla, z tym, że tutaj nie mamy do czynienia z pojedynczym stanem, a grupą stanów, które tworzą sektor tego naszego grafu przejść między stanami, z którego to sektora nie można wyjść no i podobnie to wygląda tutaj.

 

Nie można osiągnąć stanu końcowego, nie można opuścić tego kawałka logiki biznesowej, a zatem jest to też coś co można by wskazać jako błędny kawałek tego grafu. Dosyć często na zadaniach egzaminacyjnych przy certyfikacjach testerskich kiedy przychodzi do odpytywania właśnie z tego rejonu, z tej techniki testowej, wskazanie na pętlę martwą, czy stan martwy, może być elementem pytania egzaminacyjnego.

 

Ostatnia konstrukcja, która jest niedopuszczalna w prawidłowym modelu, to stan magiczny. Tu dla odmiany mamy stan, z którego mamy tylko wyjścia, ale nie ma dla niego wejścia. I tutaj też chyba dosyć logiczne jest to, że nie można czegoś takiego tutaj umieścić bo nie ma jak do takiego stanu żadnym przypadkiem testowym, czy sekwencją decyzji, dojść.

 

Tak, że jest to stan, który, jeżeli rzeczywiście pojawia się w trakcie budowania, zarysowania konceptu przyszłego systemu, to może wskazywać na to, że trzeba po prostu jakiś proces oddać osobną mapą – ponieważ, jeżeli nie jest to stan startowy, no to w tym momencie, no musi być możliwość jakoś jednak dojścia do niego, tak, że jest również wskazywany jako coś co przeczy warunkom teoretycznym, które były zarysowane wcześniej.

 

Technika ta jest często wspominana w szkoleniach dla testerów, w kursach propedeutycznych informujących właśnie o tym jak prawidłowo projektować testy, również w certyfikacjach testerskich, takich jak ISTQB. Podstawowe zalety, które się wskazuje przy okazji tej techniki to przede wszystkim ujednolicona notacja, usprawnienie procesu przeglądu wymagań.

 

Jeżeli wymagania mamy zapisane w języku naturalnym i zaczniemy sobie je wspólnie z twórcami projektu systemu przedstawiać w takiej właśnie graficznej formie, łatwiej można nawiązać komunikację, łatwiej można wyłapać rejony, które nie są dobrze opisane, które w jakiś sposób mogą być właśnie błędne. W języku naturalnym natomiast czasami nie widać tego w sposób jednoznaczny, nie widać tego tak wyraziście.

 

Jeżeli chodzi o proces projektowania testów, no to tutaj po prostu przechodzenie pomiędzy tymi stanami, czyli sekwencja odwiedzanych stanów zazwyczaj oznacza tyle, co przypadek testowy. Tych przypadków testowych możemy zaprojektować tutaj jakąś liczbę; jak wiadomo, testerzy zawsze stają w obliczu bardzo dużej wielości możliwości przejścia przez system.

 

W momencie kiedy to zamodelowanie mamy schludnie przeprowadzone właśnie za pomocą takiego grafu, można wyliczyć ile tych podróży powinno minimalnie być żeby jednak przetestować jak najwięcej się da – tak, że jest to istotny fundament dla szacowania pracochłonności testów, możemy sobie ustalić własnie jakie ścieżki, jak długie powinniśmy przyjąć, jakimi schematami będziemy odwiedzali poszczególne stany, aby zoptymalizować po prostu zestaw naszych przypadków testowych, tak, że chociażby układ wielu różnych pętli, które kończyłyby się w punkcie wyjścia i dawały możliwość rozpoczęcia przypadku testowego zaraz po zakończeniu poprzedniego, mogłyby być właśnie projektowane w oparciu o taki graf przejść między stanami.

 

Przydatność tej techniki jest o tyle duża, że jest ona wspomniana praktycznie w każdej książce testerskiej, a dodatkowo jeszcze jest opisana w standardzie zbierającym techniki testerskie, czyli BS 7925. Możemy w drugiej części tego standardu znaleźć informacje na temat tej techniki w podanych tutaj przeze mnie rozdziałach. To tyle na dzisiaj, w tym spotkaniu opisałem początkowo jak ta technika wygląda, jakie są jej podstawowe założenia teoretyczne, natomiast zastosowania, sposoby liczenia, już w następnym spotkaniu. Bardzo dziękuję Państwu za uwagę, mówił Piotr Furtak, trener Altkom Akademii.