14 Testy i opis procedury

Efekty uczenia się: U2, U6, U7, K3 · Treści programowe: 10, 11 · Czas: Nauka 35 min, Wyzwanie 55 min

14.1 Nauka

Po co testować model

Model, który wdraża się do silnika, nie musi działać tak, jak zakłada procedura. Warunek na bramce może mieć odwrotny znak. Reguła w tabeli decyzyjnej może nigdy nie zadziałać, bo poprzednia przechwytuje wszystkie przypadki. Formularz może nie zapisywać pola, od którego zależy decyzja. Takie błędy wychodzą dopiero wtedy, gdy przez proces przejdą sprawy o różnych danych.

Testowanie procesu wykonywalnego to celowe przeprowadzenie przez silnik takich spraw, które razem odwiedzą każdą ścieżkę modelu. Wynik każdej sprawy porównujesz z tym, czego oczekujesz na podstawie opisu procesu.

Przypadki testowe

Przypadek testowy (test case) to opis jednej sprawy: z jakimi danymi ją uruchamiasz, jakie decyzje podejmujesz w zadaniach i jakiego wyniku się spodziewasz. Zestaw przypadków powinien pokryć:

  1. każde zakończenie procesu: co najmniej jedna sprawa na każde zdarzenie końcowe;
  2. każde wyjście z każdej bramki: także gałąź domyślną;
  3. każdą regułę tabeli decyzyjnej: co najmniej jedna sprawa, w której ta reguła wygrywa;
  4. wartości graniczne: dokładnie na progu reguły (np. cena 150 zł przy regule <= 150) i tuż obok niego;
  5. zdarzenia graniczne: sprawa, w której termin mija albo przychodzi wiadomość przerywająca.

Przypadki zapisujesz w tabeli. Oto zestaw dla procesu „Propozycja zakupu książki” z rozdziału 12:

Nr Dane startowe Decyzje w zadaniach Oczekiwana ścieżka Oczekiwany wynik Sprawdza
T1 drukowana, 89,90 zł zamówienie: Dostawca A DMN → bez akceptacji → koszt → zamówienie „Książka zamówiona”, koszt = 102,4 reguła 2, gałąź domyślna
T2 drukowana, 150 zł zamówienie: Dostawca A jak T1 „Książka zamówiona” wartość graniczna reguły 2
T3 drukowana, 150,01 zł kierownik: zgoda DMN → akceptacja → zgoda → zamówienie „Książka zamówiona” reguła 3, gałąź „tak”
T4 e-book, 40 zł kierownik: odmowa DMN → akceptacja → odmowa „Propozycja odrzucona” reguła 1, gałąź „nie”
T5 e-book, 40 zł brak decyzji przez 7 dni DMN → akceptacja → zegar „Propozycja wygasła” zdarzenie graniczne

Przypadek T5 wymaga czekania 7 dni. Do testu tymczasowo skróć termin w kopii modelu do PT2M (dwie minuty) i wdróż ją pod inną nazwą procesu. Po teście wróć do właściwej wartości. Tak samo postępuje się w instytucjach: terminy testuje się na skróconej kopii, a nie przez czekanie.

Wykonanie testu i zapis wyniku

Każdy przypadek przeprowadzasz w Tasklist, a wynik sprawdzasz w Operate. W Operate widać ścieżkę instancji na diagramie i wartości zmiennych. Wynik testu zapisujesz w dwóch kolumnach dopisanych do tabeli: wynik rzeczywisty i ocena (zgodny / niezgodny). Przy niezgodności opisujesz przyczynę i poprawkę.

Dobrym nawykiem jest też liczenie pokrycia, np. „5 przypadków odwiedziło 12 z 12 elementów modelu i 3 z 3 reguł tabeli”. Jeśli jakiś element nie został odwiedzony przez żaden test, albo brakuje przypadku, albo element jest zbędny. Właśnie tak test prowadzi do oceny kompletności modelu.

Spójność i kompletność procesu

Testy sprawdzają, czy model działa. Ocena spójności i kompletności sprawdza, czy model odpowiada potrzebom informacyjnym organizacji. Pomocne są pytania oparte na kryteriach jakości informacji:

Kryterium Pytanie do modelu
kompletność czy decyzje mają wszystkie potrzebne dane? czy formularz pyta o wszystko, czego używa tabela decyzyjna?
aktualność czy dane są aktualne w chwili decyzji? czy proces nie czeka tak długo, że decyzja opiera się na nieaktualnych informacjach?
poprawność kto sprawdza wprowadzone dane? czy jest punkt kontrolny przed decyzją?
spójność czy te same dane nie są wprowadzane dwa razy w różnych miejscach? czy nazwy zmiennych są jednolite?
dostępność czy osoby wykonujące kolejne kroki widzą dane, których potrzebują?
poufność czy formularze nie pokazują danych osobom, które ich nie potrzebują?

Zmiany w otoczeniu instytucji

Procesy żyją w zmieniającym się otoczeniu. Zmieniają się przepisy, systemy, budżety, oczekiwania użytkowników i sama kultura informacyjna organizacji. Dobry model pozwala przewidzieć, co trzeba będzie zmienić, zanim zmiana nastąpi. W analizie zmian zadajesz dwa pytania: co może się zmienić? i gdzie w modelu ta zmiana wyląduje?

Zmiana Przykład Gdzie w modelu Skala zmiany
reguła nowy próg ceny wymagający akceptacji tabela decyzyjna mała: nowa wersja tabeli, proces bez zmian
termin regulamin skraca czas na decyzję do 5 dni zdarzenie czasowe mała: nowa wersja procesu
rola likwidacja stanowiska kierownika oddziału linie, przypisania zadań, formularze średnia
system biblioteka wdraża nowy system zamówień zadania usługowe, dane duża: nowe połączenia, zmiana kroków
przepisy nowe wymogi ochrony danych formularze, kontrola dostępu, nowe kroki kontrolne średnia lub duża
zachowania użytkowników czytelnicy proponują głównie e-booki rozkład spraw na ścieżkach, obciążenie ról analiza: model bez zmian, inna organizacja pracy

Zwróć uwagę na pierwszy wiersz. Oddzielenie reguł (DMN) od przebiegu (BPMN) ma praktyczną wartość: zmiana regulaminu, która dotyczy tylko reguł, nie wymaga przebudowy procesu. W wielu instytucjach tabelę decyzyjną może wtedy aktualizować właściciel procesu, bez udziału informatyków.

Opis procedury

Model nie zastępuje opisu procedury. Diagram pokazuje przebieg, ale nie mówi, jaki jest cel procedury, na jakiej podstawie działa i kto za nią odpowiada. Pisemny opis procedury jest też formą udokumentowanej informacji, której wymaga ISO 9001 (spotkanie 2). Typowa struktura:

  1. Cel: po co istnieje procedura i jaki wynik dostarcza.
  2. Zakres: których spraw dotyczy, a których nie.
  3. Podstawa: regulamin, zarządzenie, przepisy.
  4. Definicje i skróty.
  5. Odpowiedzialności: role i ich zadania, z rozdziałem obowiązków. Pomocna jest tabela rola × krok, w której zaznaczasz, kto wykonuje, kto zatwierdza, kogo się informuje.
  6. Przebieg: krok po kroku, z odwołaniem do numerów kroków na diagramie.
  7. Reguły decyzyjne: tabela DMN w wersji czytelnej dla człowieka.
  8. Terminy i wyjątki: co się dzieje, gdy termin minie albo krok się nie uda.
  9. Dokumenty i rejestry: jakie zapisy powstają i gdzie są przechowywane.
  10. Mierniki: jak sprawdzisz, że procedura działa (np. czas od propozycji do zamówienia, odsetek propozycji wygasłych).
  11. Załączniki: diagram BPMN, tabela decyzyjna, wzory formularzy.

Opis procedury piszesz dla pracownika instytucji, a nie dla informatyka. Nie używaj w nim nazw zmiennych i wyrażeń FEEL. Pisz „jeśli cena przekracza 150 zł”, a nie cena > 150.

14.2 Wyzwanie

Polecenie: przetestuj swój proces wykonywalny, przeanalizuj wpływ zmian w otoczeniu i napisz pierwszą wersję opisu procedury.

Dane wejściowe: Twój folder projekt/ ze spotkania 13 i działający Camunda 8 Run.

Kroki:

  1. Ułóż zestaw przypadków testowych według pięciu zasad z części Nauka (projekt/testy.md). Policz pokrycie elementów modelu i reguł tabeli.
  2. Przeprowadź wszystkie przypadki w Tasklist i sprawdź w Operate. Termin przetestuj na kopii modelu ze skróconym czasem.
  3. Popraw znalezione błędy (sam albo z agentem) i powtórz testy, które wcześniej nie przeszły.
  4. Dopisz do projekt/testy.md tabelę trzech zmian w otoczeniu Twojej instytucji: zmiana, gdzie w modelu, skala.
  5. Zacznij projekt/procedura.md według struktury z części Nauka. Na zajęciach napisz punkty 1–6.

Rezultat: projekt/testy.md z wynikami wszystkich przypadków, poprawiony model i pierwsza wersja projekt/procedura.md.

Praca: indywidualnie; testy możesz wykonać w parze, wymieniając się rolami (jedna osoba uruchamia sprawy, druga obserwuje Operate i zapisuje wyniki).

Czas: 55 minut. Opis procedury dokończ przed spotkaniem 15.

Na co zwrócić uwagę

  • Oczekiwany wynik zapisz przed uruchomieniem sprawy. Wynik dopisany po fakcie zawsze „się zgadza”.
  • Jeśli test wymaga poprawki modelu, wdrożysz nową wersję procesu. Stare instancje zostaną na starej wersji. W Operate sprawdzaj numer wersji przy instancji.
  • Opis procedury ma sens także bez silnika. Wyobraź sobie, że czyta go nowy pracownik w pierwszym tygodniu pracy.

14.3 Pytania sprawdzające

  1. Jakie pięć rodzajów sytuacji powinien pokryć zestaw przypadków testowych? Dlaczego warto testować wartości graniczne?
  2. Jak przetestować zdarzenie graniczne z terminem 14 dni bez czekania 14 dni?
  3. Dlaczego zmiana progu w regulaminie nie wymaga przebudowy procesu, jeśli reguła jest w tabeli DMN?
  4. Wymień pięć kryteriów jakości informacji i do każdego sformułuj jedno pytanie do modelu.
  5. Czym opis procedury różni się od diagramu? Których informacji nie da się odczytać z diagramu?