Przycisk Wstecz i utrata danych tworzą problem wtedy, gdy klient oczekuje powrotu do zadania, a musi odtworzyć całą wcześniejszą pracę. Po karcie produktu mogą zniknąć filtry i miejsce na liście, po drugim kroku formularza wpisane informacje. Zacznij od określenia oczekiwanego stanu i przejścia drogi w obu kierunkach. To konkretna kontrola nawigacji na stronie, a nie ogólne założenie, że przeglądarka zawsze zachowa wszystko, co było widoczne wcześniej.
Zapisz drogę prowadzącą do utraty stanu
Droga do sprawdzenia powinna zawierać ekran początkowy, wykonane zmiany, przejście i sposób powrotu. Przykład: klient wpisuje frazę, wybiera kategorię, przechodzi na drugą stronę wyników, otwiera produkt i wybiera Wstecz w przeglądarce. Zapisz każdy stan osobno, ponieważ powrót frazy nie oznacza jeszcze zachowania kategorii albo pozycji, a ponowny odczyt listy może dodatkowo zmienić kolejność produktów, jeśli oferta została zaktualizowana podczas oglądania szczegółów. Bez takiego rozpisania zespół może odtworzyć krótszy przebieg, w którym problem nie występuje, i błędnie uznać zgłoszenie za niewiarygodne.
W drugim przykładzie klient wypełnia pierwszy krok formularza, przechodzi dalej i wraca do poprawienia wcześniejszej odpowiedzi. Ustal, czy użył przycisku przeglądarki, odsyłacza w aplikacji czy własnej kontroli „Poprzedni krok”. Te działania mogą wykonywać różną nawigację i wymagają osobnej próby. W formularzu kontaktowym oraz procesie wieloetapowym nie oceniaj utraty danych wyłącznie na podstawie jednego wybranego sposobu powrotu.
Ustal oczekiwania dla powrotu, odświeżenia i zamknięcia
Oczekiwany stan ustal z właścicielem procesu oraz osobą korzystającą z zadania. Przy powrocie ze szczegółów do listy istotne mogą być fraza, filtry, numer strony i pozycja przewinięcia. Przy formularzu potrzebne są odpowiedzi oraz poprawny etap bez ponownego wysłania zadania. Tabela pokazuje różne działania, których nie należy uznawać za równoważne tylko dlatego, że kończą się widokiem tej samej strony.
Przesuń tabelę w bok, aby zobaczyć wszystkie kolumny.
| Działanie | Co sprawdzić | Nie zakładaj automatycznie |
|---|---|---|
| Wstecz ze szczegółów do listy | Fraza, filtry, strona i pozycja | Że lista zawsze wróci w dawnym stanie |
| Odświeżenie listy | Stan po nowym załadowaniu | Że działa jak Wstecz |
| Zamknięcie i ponowne otwarcie karty | Dostępny zapis zadania | Że pamięć strony oznacza trwały zapis |
| Powrót z drugiego kroku formularza | Wartości oraz prawidłowy etap | Że ekran kroku potwierdza zapis zgłoszenia |
Zamknięcie karty i odświeżenie mogą uruchamiać inną drogę niż Wstecz, dlatego nie obiecuj jednakowego zachowania bez weryfikacji. Gdy proces wymaga trwałego szkicu, musi istnieć odpowiedni zapis aplikacji; samo zachowanie widoku w pamięci przeglądarki nie jest dowodem takiej funkcji. Opisz granicę w komunikacji z klientem, jeżeli produkt nie przechowuje rozpoczętej pracy. Nie nazywaj chwilowo odtworzonego ekranu zapisanym zgłoszeniem lub zamówieniem bez sprawdzenia faktycznego stanu operacji.
Zrób kontrolowaną próbę z danymi przykładowymi
Kontrolowana próba powinna korzystać z bezpiecznych, rozpoznawalnych wartości, aby łatwo stwierdzić, co wróciło. W liście wybierz dwie różne cechy produktu i pozycję znajdującą się poza pierwszym ekranem. W formularzu użyj syntetycznej odpowiedzi, która różni się od wartości domyślnej, bez wysyłania prawdziwych danych klienta. Zapisz oczekiwany oraz uzyskany stan po każdym sposobie powrotu, zamiast ograniczać ocenę do stwierdzenia „ekran wygląda podobnie”.
Powtórz drogę w obsługiwanych warunkach istotnych dla produktu, na przykład na telefonie i komputerze, a nie we wszystkich możliwych kombinacjach. Sprawdź także dojście klawiaturą: po powrocie użytkownik powinien móc kontynuować zadanie bez szukania zagubionej pozycji. Zanotuj, czy fokus trafia do sensownego miejsca i czy nie znika pod stałym elementem. Test manualny uzupełnia obserwacje, których nie da się wiarygodnie potwierdzić samym przebiegiem kursora na nagraniu.
Sprawdź więcej niż widoczny adres strony
Ten sam adres nie dowodzi, że wrócił ten sam stan zadania. Filtr może być przechowywany w adresie, stan formularza w pamięci aplikacji, a pozycja listy zależeć od odtworzenia elementów strony. Zapisz, które z tych informacji rzeczywiście zostają przywrócone, bez zakładania jednego mechanizmu dla całego ekranu. Błąd może dotyczyć wyłącznie jednego składnika, więc ogólne żądanie „zapisuj wszystko” utrudnia przygotowanie ograniczonej, konkretnej poprawki.
Pamięć bfcache pomaga wyjaśnić, dlaczego czasem strona wraca z wcześniejszym stanem, lecz nie jest kontraktem trwałości zadania. Jeżeli wynik raz działa, a raz nie, porównaj kontrolowane warunki i poproś właściciela strony o sprawdzenie przywracania stanu. Nie zalecaj wyłączania zabezpieczeń lub zmiany ustawień przeglądarki jako domyślnej drogi użytkownika. Naprawa powinna odpowiadać wymaganiom produktu, a nie polegać na przypadkowym uzyskaniu korzystnego zachowania pamięci podczas jednej próby.
MDN opisuje pamięć bfcache jako możliwość zachowania stanu strony przy nawigacji wstecz i dalej, odrębną od pamięci HTTP. Nie jest to gwarancja trwałego zapisu danych biznesowych ani identycznego powrotu w każdej sytuacji.
Obejrzyj dalszą drogę po ponownym początku
W dostępnych nagraniach szukaj zachowania po powrocie, a nie jedynie samego wybrania Wstecz. Klient może ponownie wpisywać frazę, przewijać długą listę albo opuszczać proces, ale nie każde z tych działań oznacza ten sam problem. Porównaj widoczny stan z kontrolowanym testem i zaznacz, które elementy musiały zostać odtworzone. Nie przypisuj klientowi frustracji wyłącznie dlatego, że wrócił na poprzedni ekran i wykonał dodatkowe działania.
Stosuj zasady analizy nagrań sesji, uwzględniając pokrycie rejestracji oraz maskowanie pól. W analityce Meetlead nagranie może pomóc znaleźć moment ponownego początku, ale nie odtworzy automatycznie utraconego szkicu ani nie naprawi historii aplikacji. Jeśli wartości są niewidoczne, potwierdź utratę w kontrolowanej próbie. Raportuj obserwowaną sekwencję zamiast dopisywać treść, którą użytkownik rzekomo wpisał wcześniej do zamaskowanego pola.
Przygotuj poprawkę dla jednego składnika stanu
Poprawkę opisz przez oczekiwany efekt po konkretnej drodze. Przykład: „Po powrocie ze szczegółów do listy zachowaj kategorię i numer strony; klient powinien widzieć produkt, który właśnie oglądał”. Dla formularza ustal z właścicielem funkcji przechowywanie szkicu i sposób powrotu do edycji zgodny z wymaganiami danych. Nie rozszerzaj zadania automatycznie na zachowanie całej sesji między urządzeniami, jeśli zgłoszenie dotyczy jednego powrotu w jednej karcie.
Przy kontroli po zmianie sprawdź tę samą drogę oraz poprawność nieoczekiwanego wejścia, na przykład bez istniejącego szkicu. Zwróć uwagę, czy przywrócona pozycja nie jest zasłonięta; temat przyklejonych elementów zasłaniających przyciski pomaga opisać taką kolizję. Ustal również, jak aplikacja reaguje, gdy dawny produkt lub termin już nie istnieje. Zachowany stan nie powinien obiecywać aktualności obiektu, który zmienił się podczas przerwy w zadaniu.
Pytania o Wstecz i stan zadania
Czy przeglądarka zawsze zachowuje wpisane dane? Nie należy przyjmować takiej gwarancji. Zachowanie zależy od nawigacji, implementacji aplikacji i warunków przeglądarki.
Sprawdź wymagany przebieg, a trwały szkic potwierdź jako osobną funkcję zapisu. Powrót widoku nie jest dowodem, że rozpoczęta operacja została przyjęta przez system.
Czy trzeba zachować każdy szczegół listy? Wybierz te informacje, które pozwalają kontynuować rzeczywiste zadanie. Dla porównania produktów ważne mogą być filtry, strona oraz pozycja; inne drobne elementy nie zawsze są potrzebne.
Ustal oczekiwania przed poprawką i sprawdź je po zmianie. Nie wprowadzaj szerokiego mechanizmu zapisywania wszystkich danych bez konkretnej potrzeby.
