Testowanie przepływów

Lista kontrolna z polami tak i nie — testowanie przepływów

Przepływ uruchomiony bez sprawdzenia działa na danych produkcyjnych od pierwszej sekundy. Skutki bywają nieodwracalne.

Środowisko testowe

Kopie systemów albo konta próbne. Bez tego każde sprawdzenie zapisuje coś w danych rzeczywistych. Przy programach instalowanych lokalnie zwykle da się zrobić kopię bazy i pracować na niej. Przy usługach zewnętrznych bywa konto próbne, a gdy go nie ma — trzeba wydzielić zakres, w którym pomyłka nie zaszkodzi: osobny magazyn, osobna kategoria, kontrahent testowy.

Dane do prób

Nie wymyślone, tylko skopiowane z produkcji. Zestaw powinien zawierać rekord typowy i kilka nietypowych, bo to te drugie ujawniają błędy. Postać danych opisuje tekst o przekazywaniu danych między krokami.

Przypadki brzegowe

  • pola puste i wartości nietypowe,
  • znaki specjalne i polskie litery,
  • rekord już istniejący,
  • system docelowy niedostępny,
  • zdarzenie powtórzone.

Do tego przypadek najczęściej pomijany: brak uprawnień. Konto techniczne działające przy budowie bywa inne niż to, na którym przepływ pracuje później.

Każdy przypadek trzeba przejść osobno i zapisać wynik. Sprawdzenie, którego nikt nie odnotował, przy następnej zmianie zostanie zrobione od nowa albo pominięte — w obu razach czas idzie na marne.

Tryb bez zapisu

Przepływ wykonujący wszystko poza ostatnim krokiem. Pozwala sprawdzić dane wyjściowe bez skutków. To najtańszy sposób na wyłapanie błędów w mapowaniu pól, bo widać dokładnie, co trafiłoby do systemu docelowego i w jakiej postaci.

Uruchomienie ograniczone

Na jednym kliencie, jednej kategorii albo jednym dniu. Rozszerzanie po potwierdzeniu poprawności. Zakres warto wyznaczyć warunkiem w samym przepływie, a nie umową z zespołem, że „na razie nie wprowadzamy innych”. Warunek działa zawsze, ustalenie ustne — nie.

Obserwacja po uruchomieniu

Przegląd każdego wykonania przez pierwsze dni. Później wystarczają powiadomienia o błędach. Sprawdza się nie tylko to, czy przepływ zakończył się powodzeniem, ale też czy wynik w systemie docelowym jest taki, jakiego oczekiwano — powodzenie techniczne i poprawność merytoryczna to dwie różne rzeczy. Stały sposób obserwacji opisuje tekst o monitorowaniu działania przepływów.

Sprawdzenie po zmianie

Każda poprawka wymaga powtórzenia prób. Zmiana w jednym kroku psuje inny częściej, niż się wydaje, zwłaszcza gdy kroki korzystają ze wspólnych danych. Pomaga spisana lista przypadków do przejścia — krótka, ale zawsze ta sama. Bezpieczne wprowadzanie zmian opisuje tekst o wersjonowaniu i zmianach.

Czego próby nie wykryją

Zachowania przy pełnym obciążeniu i sytuacji, które pojawiają się rzadko: zamknięcia miesiąca, sezonu, awarii po stronie dostawcy. Dlatego etap ograniczonego uruchomienia jest potrzebny nawet po dobrze przeprowadzonych próbach.

Nie wykryją też błędów w samym założeniu. Przepływ może działać bez zarzutu i robić coś, czego proces nie potrzebuje. To wychodzi dopiero wtedy, gdy wynik zobaczy osoba, która wykonuje tę pracę na co dzień — dlatego warto ją zaprosić do sprawdzenia, zanim przepływ obejmie całość danych.

Zobacz też

Zadzwoń22 378 48 59