Jak przetestować nowe transakcje terminala na produkcji: osobna rola testowa i skrypty z trybem próbnym

Testowanie nowych transakcji terminala na produkcji ma w opisywanym wdrożeniu jedną cechę widoczną od razu: nie ma osobnej bazy. Konsultant sprawdza nową transakcję w tej samej bazie, w której pracują magazynierzy, więc musi rozdzielić to, co widać na terminalu, od danych, na których testuje. Zmiany formularzy i menu wydruku wprowadzały skrypty. Dane testowe zakładały również skrypty. Skrypty mają kontrolę bazy i transakcję, a część z nich także tryb próbny i samoweryfikację.

Strona opisuje organizację takiego testu, a nie jego wyniki. Przeniesienie nowych transakcji na kafle magazynierów przewidziano dopiero po akceptacji i podajemy je wyłącznie jako plan, bez daty i bez opisu efektów.

Ogólny przebieg projektu opisuje strona o wdrożeniu systemu WMS, a osobne środowisko demonstracyjne strona o demo systemu WMS. Tutaj chodzi o inny przypadek: test w bazie produkcyjnej, który prowadzi osobna rola z własnymi kaflami. Dane testowe są oddzielone od produkcyjnych.

Test składa się z sześciu kroków, a każdy ma własne narzędzie

Tabela zestawia sześć kroków w kolejności, w jakiej opisuje je dokumentacja wdrożenia. Trzecia kolumna podaje, co dany krok sprawdza albo przed czym chroni. Część tych ustaleń pochodzi z dokumentacji, a nie z pomiarów na terminalu, i tak je oznaczamy w dalszych sekcjach.

Pętla na schemacie jest prosta. Odmowa akceptacji wraca do skryptu w trybie próbnym, a dopiero akceptacja otwiera dolny pas z przeniesieniem na kafle magazynierów.

Osobna rola testowa dostaje własne kafle z opisem TEST

W opisywanym wdrożeniu każda nowa transakcja terminala ma w rejestrze transakcji własny wpis. Wpis ma osobny kod i identyfikator, a jego opis zawiera dopisek „TEST”. Wpisy transakcji, których używają magazynierzy, pozostają bez zmian.

Wpisy testowe wskazują pliki testowe terminala. Dla istniejących transakcji obok dotychczasowego pliku leży plik testowy z przyrostkiem w nazwie. Trzy transakcje są nowe i dotychczasowego pliku nie mają.

Według dokumentacji wdrożeniowej transakcje testowe przypisano do osobnej roli terminala, czyli roli testowej. Rola ogranicza widoczność kafli w menu i nie jest zabezpieczeniem technicznym. To ustalenie z dokumentacji, a nie z pomiaru na terminalu. Ogólny podział uprawnień wyjaśnia strona o rolach i użytkownikach w systemie WMS, a samą aplikację terminala opisuje strona o aplikacji magazynowej na Androidzie.

Znacznik wersji w adresie pliku decyduje, który plik pobierze terminal

Adres pliku transakcji niesie znacznik wersji. Platforma traktuje go na dwa sposoby, opisane w liście poniżej.

• Znacznik ze znakiem „@” na początku: platforma zamienia go na parametr wersji w adresie pliku.
• Brak znacznika: platforma dokleja do adresu numer wersji aplikacji.

Znaczniki transakcji testowych mają postać daty, z dwucyfrowym numerem kolejnym przy kolejnych podmianach pliku. Przykład (fikcyjny): plik testowej transakcji podmieniono tego samego dnia po raz drugi. Znacznik dostaje wtedy numer kolejny, a adres pliku różni się od adresu po pierwszej podmianie.

Zmiana znacznika sprawia, że przeglądarka terminala pobiera nowy plik. Znacznik dotyczy więc pliku transakcji. Konfiguracji zapisanej w bazie dotyczy inna czynność: po jej zmianie wykonuje się reset pamięci podręcznej aplikacji, a użytkownik terminala loguje się ponownie (według dokumentacji skryptów wdrożeniowych). To dwie osobne czynności, które wykonuje się obok siebie: pierwsza przy podmianie pliku, druga po zmianie konfiguracji.

Kontrahent testowy i dane testowe da się odróżnić od produkcyjnych i wycofać miękko

Testy wykonywano na kontrahencie testowym i z loginem testowym. Palety, dokumenty, zlecenia i partie testowe mają w numerze wyróżniający przedrostek, więc dokumenty testowe łatwo odróżnić od produkcyjnych.

Stan i dokumenty testowe zakładają skrypty, a nie ręczny wpis w programie. Zakres danych testowych jest więc zapisany w skrypcie, a nie w pamięci osoby, która je wpisywała.

Dane testowe wycofuje się miękko. Skrypt wycofujący ustawia znacznik usunięcia na stanie testowym, a ten sam znacznik dostają dokumenty i zlecenia testowe. Po wycofaniu skrypt liczy, czy nie zostały aktywne wiersze testowe. Kopie testowe formularzy usunięto osobnym skryptem po kontroli liczb wierszy.

Odróżnienie danych testowych od produkcyjnych jest warunkiem bezpiecznego sprzątania. W opisywanym wdrożeniu służą do tego kontrahent testowy i przedrostek w numerach, a o sposób takiego rozróżnienia pytamy w drugim pytaniu do analizy.

Skrypt wdrożeniowy ma nagłówek i najpierw sprawdza, na jakiej jest bazie

Każdy skrypt wdrożeniowy ma nagłówek z siedmioma polami. W polu statusu zapisuje się, gdzie skrypt wykonano. Dopisuje się tam też termin i wynik wykonania.

Skrypt zaczyna od kontroli nazwy bazy. Przy innej bazie przerywa pracę: zgłasza błąd i wyłącza wykonywanie dalszych instrukcji, a na końcu przywraca normalny tryb. Skrypt zmieniający dane lub formularze wykonuje zmiany w jednej transakcji, a błąd w trakcie cofa całość.

Skrypt zmieniający formularz ma jeszcze dwa zabezpieczenia. Gdy punkt zaczepienia w treści zapytania formularza nie występuje dokładnie raz, kończy się błędem i niczego nie zapisuje. Jest też idempotentny: kolumny dopisuje tylko wtedy, gdy ich brakuje.

Samoweryfikację ma część skryptów, nie wszystkie, i opisujemy tu tylko te, które ją mają. Samoweryfikacja skryptu zmiany formularzy wypisuje do przeglądu cztery kontrole, opisane w liście poniżej. Same kontrole po zapisie niczego nie przerywają.

• Zapytania formularzy: opisują się bez błędu.
• Nowe pola: są w wyniku zapytania.
• Definicje kolumn: nie ma zdublowanych.
• Rewizje zmian: tabele objęte rejestrem rewizji są aktywne.

Tryb próbny wykonuje zmiany i cofa je, a sprzątanie po teście liczy wiersze

W skryptach, które go mają, tryb próbny to przełącznik na początku skryptu. Zero oznacza wykonanie zmian i kontroli, a potem cofnięcie transakcji, jeden oznacza zapis. Taki skrypt jest domyślnie w trybie próbnym i wypisuje kontrole przed cofnięciem. Tryb próbny z wycofaniem dla zapytań zapisanych w bazie opisuje osobny artykuł o zmianie zapytań zapisanych w bazie z trybem próbnym.

W trybie próbnym skrypt wykonuje zmiany i kontrole, a potem cofa całą transakcję.

Pierwsze uruchomienie niczego więc nie zapisuje, a wdrażający dostaje wynik kontroli do przeglądu, zanim przestawi przełącznik na jeden. Makieta poniżej pokazuje przykładowy wynik takiego przebiegu: dwie siatki z liczbami i przykładowy komunikat o wycofaniu. Liczby i komunikat na makiecie są wymyślone i nie pochodzą z żadnej bazy.

Tryb próbny stosowano też przy sprzątaniu. Kopie testowe formularzy kartotek usunięto osobnym skryptem w trybie próbnym. Skrypt porównuje liczbę usuniętych wierszy z oczekiwaną i przy niezgodności przerywa oraz cofa zmiany.

Definicje pól przeniesiono z kopii testowych do formularzy docelowych (według dokumentacji), a formularze docelowe mają dodatkowo podpowiedzi przy polach. Test ręczny na terminalu obejmował przebieg od początku do zatwierdzenia dokumentu na danych testowych, także według dokumentacji.

Przeniesienie na kafle magazynierów jest planem po akceptacji

Przeniesienie nowych transakcji na kafle magazynierów przewidziano po akceptacji. Według planu wdrożenia obejmie ono cztery czynności: podmianę pliku w istniejących transakcjach, nowe kafle dla nowych transakcji, podbicie znacznika wersji i reset pamięci podręcznej.

Do czasu akceptacji ten etap pozostaje planem. Nie podajemy daty przeniesienia ani tego, czy magazynierzy pracują już na nowych transakcjach, bo opis wdrożenia tego nie rozstrzyga. Kto akceptuje test i w jakiej formie, to osobne pytanie projektowe, do którego wracamy w pytaniach do analizy.

Przykład jednego testu od zarejestrowania transakcji do akceptacji

Przykład (dane wymyślone). Konsultant dostaje od operatora gotową nową transakcję terminala. Rejestruje ją jako osobną transakcję z opisem „TEST: Nowa transakcja (przykład)” i dodaje jej kafel w roli testowej. Po rejestracji transakcji i kafla resetuje pamięć podręczną, a według dokumentacji rola magazynierów nowego kafla nie widzi.

Skryptem zakłada stan testowy dla Klienta Testowego: palety i dokumenty z przedrostkiem „TEST-” w numerze. Skrypt najpierw uruchamia w trybie próbnym, żeby zobaczyć kontrole i cofnięcie. Gdy wynik się zgadza, przestawia przełącznik na jeden i zapisuje.

Po zapisie loguje się ponownie na terminalu i prowadzi przebieg na dokumencie wydania ze zlecenia dla Klienta Testowego. Typy dokumentów, o których mowa, zestawia strona o dokumentach magazynowych. Po akceptacji dane testowe wycofuje się znacznikiem usunięcia, a przeniesienie na kafle magazynierów planuje osobnym skryptem.

Pytania do zadania na etapie analizy

Poniższe pytania nie są faktami o kliencie. To lista rzeczy, które zadajemy w analizie przedwdrożeniowej, zanim ktoś zacznie testować nowe transakcje w bazie, w której pracują magazynierzy. Cztery pytania stoją w liście poniżej.

• Rola testowa: czy w bazie, w której pracują magazynierzy, istnieje rola lub grupa kont, której kafle są niewidoczne dla pozostałych, i kto zarządza jej menu?
• Dane testowe: po czym odróżnicie dane testowe i kontrahenta testowego od produkcyjnych, żeby sprzątanie po teście nie dotknęło prawdziwych danych?
• Akceptacja: kto i w jakiej formie akceptuje test przed przeniesieniem nowej transakcji na kafle magazynierów?
• Skrypty zmian: czy wasze skrypty mają kontrolę nazwy bazy oraz tryb próbny z samoweryfikacją?

Odpowiedzi decydują o tym, czy opisany układ da się odtworzyć u was i ile przygotowania wymaga, zanim powstanie pierwsza transakcja testowa.

Czego ten opis nie rozstrzyga

Test w tej samej bazie wymaga osobnej roli, osobnych kafli, danych testowych i skryptów z kontrolami. Opis pokazuje, co oddzielono. Zmiany formularzy i menu wydruku wprowadzały skrypty, a dane testowe zakładały również skrypty.

Rola ogranicza widoczność kafli w menu i nie jest zabezpieczeniem technicznym. Według dokumentacji wdrożeniowej transakcje testowe przypisano do osobnej roli, i na tym ustalenie się kończy.

Nie opisujemy skali testów ani wyników akceptacji. Ogólniejszy opis testowania systemu zawiera strona o testowaniu systemu w programie magazynowym.