Uwaga klienci korporacyjni, to inspiracja szczególnie do was. Częstym problemem w dużych wdrożeniach narzędzi BPM są testy regresyjne i ich złożoność, koszty oraz czas. W aplikacjach serwerowych automatyzacja testów jest standardową praktyką w wytwarzaniu oprogramowania od długiego czasu. Nie jest to jednak praktyka rozpowszechniona na tyle, by także małe wdrożenia czerpały z tego korzyści, a już na pewno nie w testowaniu rzeczy trudno testowalnych. Z tego właśnie powodu wyłuskać możemy tutaj problem z testowaniem i dokumentowaniem procesów biznesowych. Dlaczego testowanie procesów zajmuje dużo czasu? Procesy zawierające dużą liczbę atrybutów na formularzu wraz z walidacją i ogromną listą kroków wymagają parunastu minut by choć raz przejść jeden przypadek testowy.
Przypadków testowych jest zazwyczaj conajmniej kilka, głównie rozdzielone per formularz by łatwo można było je przyswoić. Gdy stworzymy listę scenariuszy testowych zobaczymy, że przypadków jest n, więc wystarczy przejść cały proces n razy aby go wytestować.
Jeśli skomplikowanych kroków mamy K, akcji do wykonania razem ze ścieżkami (złożoność decyzji biznesowych) D, a przejście pojedynczego przypadku testowego zajmuje nam T, to czas wymagany do przetestowania pojedynczego wdrożenia wynosi KDT minut. Dla przykładu - średni proces z 5 skomplikowanymi krokami:
K=5
D=10
T=5 minut
Czas testów = 5 * 10 * 5 = 250 minut = 4 godziny 10 minut
Średnia stawka testera to powiedzmy 10 000 PLN brutto.
Przy 10 przejściach testów regresji w miesiącu daje nam to 2 500 minut = 42 godziny = 2 500 PLN
Jedno wdrożenie - 4/5 testów regresji * 3 wdrożenia w miesiącu = 15 * 2 500 PLN = 37 500 PLN
Jak widać z powyższych obliczeń taki tester nie ma szans prowadzić nawet 3 wdrożeń w miesiącu, może prowadzić maksymalnie jedno wdrożenie. Oczywiście praca powtarzalna to jeden z głównych czynników wypalenia zawodowego, dlatego najlepiej wykorzystywać zasoby ludzkie w sposów efektywny i zgodny z ich naturą. Tester manualny może nie nauczy się testów automatycznych, ale co jeżeli przypadki testowe mógłby generować sam biznes, a testy utrzymywać np. jeden developer. Naturalnie jeden developer mógłby obsługiwać wiele projektów naraz, choć należy pamiętać także, że wprowadzone zmiany są stałe tj. jedna zmiana będzie testować jeden przypadek biznesowy do końca życia projektu, albo do momentu złamania jej założeń czy też jej zmiany wynikającej z samego biznesu.
// TODO: przykładowa lista scenariuszy testowych
Testowanie BDD (Cucumber/Gherkin) w połączeniu z testami End To End wykorzystującymi przeglądarke i realne scenariusze użytkowników. Oczywiście zwrot z inwestycji testów BDD E2E byłby jeszcze większy, gdyby się okazało, że organizacja chce przetestować działanie nowego procesu biznesowego pod obciążeniem, a np. korzysta z eksperymentalnych czy niepotierdzonych jeszcze rynkowo metod.
Język Gherkin polega na opisywaniu scenariuszy użytkownika za pomocą składni Given, When, Then np.
Scenario: Umowa czeka do podpisu 7 dni. Czas na podpis nie może przekroczyć 10 dni, ponieważ inaczej przychodzi kontrola
Given: Umowa jest gotowa do podpisu przez Jan Kowalski
When: Od dnia gotowości do podpisu minęło 7 dni
Then: Wysłano powiadomienie do menadżera Staszek IksińskiW ten sposób można opisywać dowolne zachowania w procesie.
Testy UI wykonywane w przeglądarce mogą mieć dokładnie taką samą formę jak przedstawione powyżej Given, When, Then np.
Scenario: Pełne przejście procesu klienta
Given: Rejestracja nowego klienta
When: Wpisano imię Tomasz
When: Wpisano nazwisko Dłuski
When: Wpisano NIP 123
Then: Wyskakuje błąd walidacji NIP
When: Wpisano NIP <poprawny>
When: Kliknięto ścieżkę przejścia "Rejestracja"
Then: Wykonała się akcja SDK "Pobierz dane z GUS"
Then: Element przeszedł do nowego kroku "Klient Aktywny"
Then: Element posiada atrybut Adres ul. Jana Heweliusza 810/11Bardzo łatwo można przetestować takie rzeczy jak:
- Wysyłka maila
- Przydzielenie zadania do konkretnej osoby
- Przejście do kroku
- Wykonanie dowolnej akcji np. SDK w systemie WEBCON
- Zaktualizowanie atrybutu
- Walidacja formularza
- Wykonanie SQLa
Bardzo ciekawym projektem byłoby wdrożenie podobnego systemu do testów regresji. W razie zainteresowania proszę o kontakt pod publicznym adresem z profilu https://github.com/Toumash