Testowanie aplikacji do zamawiania usług hotelowych w pokojach: scenariusze chroniące przychody

1. Zdefiniuj zasady biznesowe, zanim ktokolwiek zacznie korzystać z internetu

Zanim ktokolwiek uruchomi aplikację stagingową, ustal zasady, których produkt nie może łamać. Zdecyduj, co się stanie, gdy kuchnia zostanie zamknięta, gdy produkt się wyprzeda, gdy pokój będzie poza godzinami dostawy oraz kiedy hotel akceptuje opłatę za pokój, płatność kartą lub obie te opcje. Jeśli te zasady będą niejasne, wyniki testu również będą niejasne.

• Zespół powinien być w stanie z wyprzedzeniem odpowiedzieć na proste pytania, na przykład czy późne zamówienie jest blokowane, czy opłatę za pokój można łączyć z płatnością kartą oraz czy zamknięte menu znika, czy pozostaje widoczne z ostrzeżeniem.

Jeśli aplikacja narzuca regułę, której personel hotelu nie stosuje, goście są blokowani bez powodu. Jeśli zignoruje regułę, od której hotel się uzależnia, konsekwencje ponoszą kuchnia i recepcja. Celem jest nie tylko poprawność kodu, ale także spójność z rzeczywistym funkcjonowaniem obiektu.

2. Przygotuj realistyczne środowiska i dane testowe

Dane testowe są równie ważne, jak sama aplikacja. Użyj środowiska testowego, które jak najwierniej odzwierciedla konfigurację na żywo, z podłączonym punktem sprzedaży (POS), wyświetlaczem kuchennym lub drukarką, środowiskiem płatności i menu z realistycznymi stanami pozycji.

• Otwarte pozycje menu, zamknięte pozycje menu i pozycje wyprzedane.
• Wymagane modyfikatory, opcjonalne modyfikatory i zagnieżdżone modyfikatory.
• Różne podatki, opłaty za usługi, zniżki i przypadki zwrotów.
• Pokoje w różnych strefach czasowych, jeśli grupa obiektów działa w różnych regionach.
• Wolna sieć, niestabilna sieć i profile testowe offline.

Jeśli hotel korzysta z łańcucha systemów obsługujących przepływ zamówień, przetestuj aplikację w oparciu o ten sam stos operacyjny, z którego korzystają kuchnia i recepcja. Aby uzyskać szerszy obraz testów, to właśnie tutaj prawdziwi goście, prawdziwe warunki staje się właściwym punktem odniesienia.

Przebieg przejściowy powinien pozwolić zespołowi odtworzyć pełną ścieżkę od przeglądania menu do potwierdzenia zamówienia z tymi samymi regułami danych, które będą obowiązywać po uruchomieniu. Jeśli model podatkowy, stan menu lub zachowanie integracji różnią się od środowiska produkcyjnego, test może nadal zakończyć się powodzeniem, mimo że właściwość jest narażona na możliwe do uniknięcia awarie.

3. Przetestuj granice dostępności w świecie rzeczywistym

Dostępność to coś więcej niż tylko flaga „otwarte” lub „zamknięte”. Dobra aplikacja do zamawiania usług pokojowych w hotelu musi uwzględniać godziny zamknięcia, wyprzedane produkty, przesunięcie terminu, strefy czasowe, nieaktualne koszyki i zmiany stanu magazynowego podczas realizacji transakcji.

• Godziny zamknięcia – sprawdź, czy zamówienie złożone przed upływem terminu zostanie przyjęte, a zamówienie złożone po terminie zostanie zablokowane lub przekierowane zgodnie z polityką hotelu.
• Produkty wyprzedane – gość nie powinien mieć możliwości zamówienia produktu, który kuchnia oznaczyła jako niedostępny.
• Zmiana dnia – jeśli menu zmieni się o północy lub o godzinie granicznej w danym lokalu, aplikacja powinna płynnie zmienić menu, nie mieszając go z menu z wczorajszego dnia.
• Strefy czasowe – aplikacja powinna korzystać z czasu operacyjnego hotelu, a nie zegara urządzenia, zwłaszcza w przypadku gości podróżujących w różnych regionach.
• Nieaktualne koszyki – jeśli gość pozostawi koszyk otwarty zbyt długo, aplikacja powinna ponownie sprawdzić dostępność przed ostatecznym wysłaniem.
• Zmiany stanu magazynowego podczas realizacji zamówienia – jeśli produkt zostanie wyprzedany w trakcie płacenia przez klienta, aplikacja powinna wyświetlić jasny komunikat i zaproponować rozwiązanie, a nie po cichu zaakceptować nieudane zamówienie.

Właściwy wynik jest prosty: aplikacja albo poprawnie realizuje zamówienie, albo zatrzymuje gościa z jasnego powodu. Nigdy nie powinna sugerować, że danie jest dostępne, gdy kuchnia nie może go podać. Brak tego potwierdzenia oznacza, że hotel ponosi koszty w postaci zmarnowanego czasu w kuchni, skarg gości i zgłoszeń do pomocy technicznej, przez co aplikacja od pierwszego dnia wydaje się zawodna.

4. Testowanie cen modyfikatorów od początku do końca

Ceny modyfikatorów to miejsce, gdzie drobne błędy mogą okazać się kosztowne. Zamówienie na obsługę pokoju może zawierać wymagane i opcjonalne modyfikatory, wiele ilości, zagnieżdżone opcje, podatki, opłaty za obsługę, rabaty i zwroty. Wszystkie te elementy powinny być zgodne z systemem POS.

• Wymagane modyfikatory – jeśli burger wymaga wyboru dodatku lub napój wymaga wyboru rozmiaru, aplikacja nie może pozwolić gościowi kontynuować bez dokonania wyboru.
• Opcjonalne modyfikatory – dodatki powinny wiązać się z dodatkowymi kosztami tylko po ich wybraniu, a gość powinien natychmiast zobaczyć zmianę ceny.
• Zagnieżdżone modyfikatory – jeśli danie ma możliwość wyboru bazy, a następnie drugiej warstwy dodatków, ostateczna kwota powinna być obliczona poprawnie na każdym poziomie.
• Ilość – dwa zamówienia tego samego produktu z różnymi modyfikatorami muszą pozostać oddzielne, a ich cena musi być prawidłowa.
• Podatki i opłaty za obsługę – ostateczna kwota powinna być zgodna z zasadami rozliczeń obowiązującymi w hotelu, a nie tylko całkowitą kwotą za menu.
• Rabaty i promocje powinny być naliczane w przewidywalnej kolejności, a gość powinien widzieć rzeczywistą cenę końcową przed wysłaniem zamówienia.
• Zwroty pieniędzy – jeśli przedmiot zostanie zabrany lub zwrócony, transakcja powinna zakończyć się pomyślnie, bez narażania gościa na nadmierne obciążenie kosztami.
• Niezgodność POS – kwota wysłana do POS musi być zgodna z kwotą pokazaną gościowi, do najmniejszej jednostki walutowej dozwolonej w danym obiekcie.

Test cenowy będzie przydatny tylko wtedy, gdy suma widoczna dla gościa, kwota w punkcie sprzedaży i dane finansowe będą się zgadzać. Jeśli jeden z nich się różni, problem nie jest natury kosmetycznej. Ma on wpływ na marżę, pewność rozliczeń i ilość pracy, jaką dział finansowy lub recepcja muszą wykonać po wykonaniu usługi.

5. Przetestuj duplikaty kranów i idempotencję

Goście ponownie stukną, jeśli ekran będzie wydawał się powolny. To normalne. Aplikacja musi sobie z tym poradzić w bezpieczny sposób. Przetestuj przy powolnym połączeniu sieciowym, opóźnionych odpowiedziach serwera, ponawianiu prób i wielokrotnych stuknięciach w kasie.

• Wolna sieć – jeśli odpowiedź trwa dłużej niż oczekiwano, aplikacja powinna wyświetlić postęp i wyłączyć opcję wysyłania lub ustawić bezpieczne ponawianie próby.
• Kliknij dwukrotnie przycisk „Wyślij” – powinno zostać utworzone tylko jedno zamówienie i autoryzowana powinna zostać tylko jedna opłata.
• Ponów próbę po przekroczeniu limitu czasu – ponowienie próby nie powinno powodować utworzenia drugiego zamówienia, jeśli pierwsze już dotarło do serwera.
• Widoczna informacja zwrotna od użytkownika – gość musi widzieć, że zamówienie jest przetwarzane, złożone lub nie powiodło się, aby nie klikał bezmyślnie.

System musi być idempotentny. Jedna akcja gościa powinna generować jeden wynik biznesowy, a nie dwa. W przypadku kontroli związanych z obsługą urządzeń mobilnych i uwierzytelnianiem warto zapoznać się z szerszymi wytycznymi w OWASP MASTG, zwłaszcza jeśli aplikacja przechowuje dane sesji lub tokeny płatnicze. Bez tej warstwy ochrony duplikowanie opłat za pokoje, duplikowanie paragonów kuchennych i zwrotów kosztów jest znacznie bardziej prawdopodobne.

6. Przetestuj tryb offline i tryb przerywany

Hotele nie zawsze mają idealne Wi-Fi. Aplikacja powinna działać uczciwie, gdy połączenie zostanie zerwane lub stanie się niestabilne.

• Przeglądaj pamięć podręczną – jeśli aplikacja wyświetla dane menu z pamięci podręcznej, gość powinien być świadomy ich aktualności.
• Trwałość koszyka – wybrane elementy nie powinny znikać, gdy połączenie zostanie zerwane.
• Kolejka do przesłania lub jawna blokada – zdecyduj, czy zamówienia offline mają być kolejkowane do późniejszego przesłania, czy blokowane, podając jasne wyjaśnienie. Oba podejścia są dobre, jeśli są przemyślane i widoczne.
• Ponowne połączenie w celu uzgodnienia – po przywróceniu połączenia aplikacja powinna ponownie sprawdzić dostępność, cenę i czas przed przesłaniem czegokolwiek do kuchni.
• Nieaktualne ceny i dostępność – dane przechowywane w pamięci podręcznej nigdy nie mogą stanowić cichej obietnicy, której hotel nie może spełnić.
• Brak utraty zamówienia – jeśli zamówienia nie da się zapisać, gość musi o tym natychmiast wiedzieć.

Najlepszym rozwiązaniem nie zawsze jest złożenie zamówienia offline. Czasami bezpieczniejszym rozwiązaniem jest zablokowanie zamówienia i wyjaśnienie przyczyny. Ważne jest, aby gość otrzymywał jasny status na każdym etapie i aby żadne zamówienie nie zniknęło bez wyjaśnienia. Zignorowanie tego aspektu może prowadzić do utraty zamówień, wielokrotnych telefonów do recepcji i frustracji w momencie, gdy obsługa pokoju powinna być łatwa.

7. Symuluj szczytowe obciążenie przed hotelem

Szczyty śniadaniowe i obiadowe to okres, w którym wiele aplikacji dla gości zawodzi. Aplikacja do zamawiania usług room service w hotelu musi radzić sobie z nagłymi wzrostami ruchu w sieci, aktualizacjami koszyka i składaniem zamówień, a jednocześnie musi być zależna od systemu POS, wyświetlacza w kuchni, bramki płatniczej i usług powiadomień.

Zaprojektuj test obciążenia w oparciu o model częstotliwości przybycia, aby odzwierciedlał on rzeczywistą liczbę przybywających gości, a nie tylko ustaloną liczbę użytkowników. Wykonawca stałej szybkości przybycia k6 jest przydatnym punktem odniesienia przy planowaniu tego typu scenariuszy.

• Przetestuj przy śniadaniowym i obiadowym wzroście krwawienia oraz przy mniejszym krwawieniu późnym wieczorem.
• Łącz przeglądanie, dodawanie do koszyka, realizację transakcji, sprawdzanie statusu zamówienia i wywoływanie płatności w jednym przebiegu.
• Należy uwzględnić zależności POS, KDS i płatności, aby test odzwierciedlał cały łańcuch, a nie tylko ekran aplikacji.
• Ustaw progi dla rzeczy, które są ważne dla hotelu, takie jak powodzenie złożenia zamówienia, czas reakcji, wskaźnik nieudanych płatności i zaległości w kolejce.
• Podczas pracy śledź dane z pulpitów obserwacyjnych, aby zespół mógł zobaczyć, gdzie zaczyna się spowolnienie.
• Zaplanuj łagodne przejście na tryb przeglądania tylko do odczytu lub wyświetl wyraźny komunikat “usługa zajęta”, zamiast poważnej awarii.

Celem nie jest sprawienie, by aplikacja wyglądała na szybką w wersji demonstracyjnej. Chodzi o udowodnienie, że system może przyjmować zamówienia do ustalonego progu, a następnie w kontrolowany sposób obniżać wydajność, zamiast się załamywać. Jeśli testy obciążeniowe zostaną pominięte lub potraktowane jako ostatnie pole wyboru, hotel odkryje limit w okresach największego ruchu na posiłki, kiedy straty przychodów i powolne trasy są najbardziej dotkliwe.

8. Ustal priorytety ważności i zwartą bramkę wydania

Nie każdy problem jest taki sam. Użyj prostego modelu ważności, aby liderzy mogli szybko podjąć decyzję o podjęciu lub zaniechaniu działania.

• P0 – blokuje przychody, bezpieczeństwo, płatności lub integralność zamówienia. Brak zwolnienia.
• P1 – przerywa standardową ścieżkę gościa lub powoduje błędy w cenach lub dostępności. Wydanie tylko z zatwierdzonym obejściem i wskazanym właścicielem.
• P2 – ograniczony wpływ, rzadki scenariusz lub problem niekrytyczny w przepływie pracy. Zaplanuj szybką interwencję.
• P3 – problem kosmetyczny lub poprawka o niskim ryzyku. Śledź zaległości.

W takim przypadku bramka zwalniająca powinna być krótka.

• Wszystkie kwestie P0 zostały zamknięte.
• Brak otwartych spraw P1 w zakresie składania zamówień, ustalania cen, płatności lub przekazywania kuchni.
• Dostępność, ceny, scenariusze podwójnego poboru prądu, pracy w trybie offline i obciążenia szczytowego przetestowano w uzgodnionym środowisku.
• Potwierdzono potwierdzenie POS, KDS i uzgodnienia płatności.
• Podano nazwisko właściciela wsparcia w dniu premiery.

Decyzja o zwolnieniu powinna opierać się na dowodach, a nie na optymizmie. Jeśli bramka jest zbyt luźna, ryzyko przenosi się na gościa i zespół hotelu. Jeśli bramka jest jasna i krótka, liderzy mogą działać z przekonaniem.