Zbuduj przepływ pracy automatyzacji wsparcia dla Androida, który odtwarza problemy z aplikacjami, przechwytuje zrzuty ekranu i dzienniki oraz przekazuje przydatne dowody kontroli jakości lub programistom. LaiCai Screen Mirroring.
Automatyzacja wsparcia powinna zachować historię klienta.
Przydatne zgłoszenie do pomocy technicznej zawiera historię: czego próbował klient, czego się spodziewał, co zamiast tego się pojawiło oraz jaki stan urządzenia lub aplikacji mógł mieć wpływ na wynik. Automatyzacja obsługi Androida powinna zachować tę historię, a nie ograniczać ją do sekwencji kliknięć. Celem jest spójne odtworzenie zatwierdzonej ścieżki i pozostawienie dowodu, który będzie mógł sprawdzić inny zespół.
LaiCai Screen Mirroring wykorzystuje LaiCai Flow jako widoczną warstwę przepływu pracy. Członek zespołu wsparcia może przeglądać węzły, oglądać ekran Androida, robić zrzuty ekranu, prowadzić dzienniki czasu wykonywania i zatrzymywać się, gdy zaobserwowany stan nie jest już zgodny z biletem. Dzięki temu narzędzie do automatyzacji AI w systemie Android jest przydatne do gromadzenia dowodów, a nie do ukrywania decyzji dotyczących obsługi klienta w czarnej skrzynce.
Zawsze należy obejrzeć pierwsze uruchomienie. Problemy z urządzeniami mobilnymi często zależą od monitu o pozwolenie, klawiatury, powiadomienia, animacji ładowania, stanu konta lub ekranu, o których nie wspomniano w zgłoszeniu. Oglądanie lustrzanego ekranu systemu Android podczas odczytywania dziennika przepływu pomaga operatorowi oddzielić rzeczywiste objawy produktu od nieprawidłowych założeń początkowych. Gdy obserwowana ścieżka będzie stabilna i bezpieczna, można powtórzyć tę samą listę kontrolną, nie tracąc punktów dowodowych, które sprawiły, że pierwszy przebieg był zrozumiały.
Zmień zgłoszenie pomocy technicznej w listę kontrolną ograniczonej reprodukcji
Przepisz zgłoszenie jako ograniczoną listę kontrolną przed zbudowaniem przepływu. Podaj ekran startowy, wersję aplikacji, typ konta, stan sieci, ustawienia regionalne, dokładne kroki, oczekiwany wynik, zaobserwowany wynik oraz moment, w którym przepływ pracy musi się zatrzymać. Żądanie typu „strona kasy jest uszkodzona” jest zbyt niejasne; „Otwórz kompilację testową, użyj zatwierdzonego konta testowego, dodaj przykładowy produkt, przechwyć ekran płatności i zatrzymaj się przed przesłaniem” jest wykonalne.
Utrzymuj krótki pierwszy przepływ. Odtwórz tylko najmniejszą ścieżkę, która może potwierdzić lub odrzucić raport. Nie dodawaj ponownych prób, niepowiązanych porządków, zmian konta, wiadomości wychodzących, zakupów ani destrukcyjnych działań. Wąska lista kontrolna jest łatwiejsza do porównania na różnych urządzeniach i bezpieczniejsza w obsłudze dla personelu pomocy technicznej.
Zarejestruj środowisko przed odtworzeniem problemu
Zarejestruj środowisko przed pierwszą czynnością. Przydatne pola obejmują wersję Androida, model urządzenia lub profil emulatora, rozmiar ekranu, wersję aplikacji, ustawienia regionalne, stan uprawnień, typ połączenia oraz to, czy problem występuje w środowisku testowym, czy produkcyjnym. Nie zgaduj nazw pakietów ani szczegółów urządzenia; odczytaj je z kontekstu autoryzowanego urządzenia, jeśli są dostępne.
Dowody środowiskowe zapobiegają fałszywym przekazaniom. Błędu, który pojawia się tylko w jednej wersji Androida, języku, stanie konta czy wolnej sieci, nie należy określać jako uniwersalnego. Dodaj początkowy zrzut ekranu i krótki identyfikator, aby późniejsze zrzuty ekranu i dzienniki mogły być powiązane z tą samą próbą odtworzenia.
Przechwytuj zrzuty ekranu i dzienniki w punktach decyzyjnych
Przechwytuj dowody w punktach decyzyjnych, a nie po każdej bezsensownej akcji. Do zalet zalicza się stan początkowy, ekran bezpośrednio przed zgłoszoną awarią, nieoczekiwany ekran, baner błędu, brakujący element sterujący i stan końcowego zatrzymania. Nazwij zrzuty ekranu, aby inżynier ds. kontroli jakości mógł zrozumieć zamówienie bez otwierania każdego pliku.
Dzienniki powinny wyjaśniać, który krok został wykonany, jaki warunek został sprawdzony, jaki wynik wybrano i dlaczego przepływ został zatrzymany. Unikaj logowania haseł, tokenów, prywatnych wiadomości, szczegółów płatności lub niepotrzebnych identyfikatorów klientów. Zrzut ekranu plus czytelny powód zatrzymania jest zwykle bardziej przydatny niż setki zdarzeń niskiego poziomu bez kontekstu.
Używaj widocznych warunków zamiast klikania na ślepo
Automatyzacja obsługi powinna obserwować, zanim zacznie działać. Używaj struktury interfejsu użytkownika, jeśli istnieją stabilne selektory, OCR, gdy wymagany tekst jest widoczny, ale nie jest odsłonięty, i dopasowywania obrazów tylko wtedy, gdy odpowiedni jest zweryfikowany zasób wizualny. Węzły obserwacyjne powinny zwracać dowody; oddzielny węzeł akcji może zostać dotknięty dopiero wtedy, gdy wynik spełni warunek przepływu pracy.
Jeśli brakuje oczekiwanego stanu, przechwyć dowody i zatrzymaj się. Nie klikaj na ślepo zapamiętanych współrzędnych ani nie obniżaj każdego progu zaufania. Wyraźne oczekiwania są łatwiejsze do przejrzenia niż ukryte pauzy, a wyraźna awaria jest bardziej użyteczna niż przepływ kontynuowany do niewłaściwego ekranu.
Chroń dane klientów na każdym etapie przepływu pracy
Dowody pomocy technicznej mogą zawierać poufne informacje. Jeśli to możliwe, korzystaj z zatwierdzonych kont testowych. Przed udostępnieniem zrzutu ekranu sprawdź nazwiska, adresy e-mail, numery telefonów, numery zamówień, powiadomienia, treść czatu, lokalizację, dane dotyczące płatności i aplikacje działające w tle. Przytnij lub zredaguj informacje, których kontrola jakości nie potrzebuje.
Zdefiniuj zasady przechowywania i dostępu do zrzutów ekranu i dzienników. Nie wklejaj dowodów klientów do publicznych zgłoszeń ani do szerokich pokojów rozmów. Jeśli do autoryzowanego dochodzenia potrzebne są prawdziwe dane klienta, zminimalizuj je, zapisz, dlaczego są potrzebne i postępuj zgodnie z polityką prywatności i usuwania danych organizacji. Automatyzacja poprawia powtarzalność; nie daje pozwolenia na gromadzenie większej ilości danych.
Przekaż dowody kontroli jakości i programistom w przydatnym formacie
Mocne przekazanie zawiera oryginalne podsumowanie zgłoszenia, warunki wstępne reprodukcji, środowisko urządzenia i aplikacji, dokładną wersję przepływu lub listy kontrolnej, kolejność zrzutów ekranu, odpowiednie fragmenty dziennika, oczekiwany a rzeczywisty wynik, częstotliwość odtwarzania i przyczynę zatrzymania. Uwzględnij to, co nie zostało przetestowane, aby kontrola jakości nie pomyliła wąskiej kontroli z szerokim zakresem.
Skorzystaj z przewodnika LaiCai Flow, aby zachować czytelność poszczególnych etapów wykresu, przewodnika dotyczącego tworzenia kopii lustrzanych ekranu Androida, aby oglądać ten sam ekran, z którego korzysta Flow, oraz przebiegu procedury zdalnego rozwiązywania problemów z Androidem w celu wspólnego przekazywania praktyk. Inżynier odbierający powinien być w stanie ponownie uruchomić ścieżkę lub zrozumieć, dlaczego nie można jej jeszcze uruchomić ponownie.
Uchwyt nie może uczciwie odtworzyć wyników
„Nie można odtworzyć” to wynik, a nie dowód, że klient się myli. Porównaj środowisko, ustawienia regionalne, uprawnienia, stan konta, sieć, flagi funkcji, kompilację aplikacji i czas. Uruchom tylko uzgodnione odmiany, zapisz dowody dla każdej z nich i dokładnie oznacz wynik: odtworzony, nieodtworzony w testowanych warunkach, przerywany, zablokowany z powodu brakujących informacji lub zatrzymany ze względu na prywatność lub bezpieczeństwo.
W przypadku braku informacji poproś o najmniejszy dodatkowy dowód, który może zmienić następny test. Domyślnie nie żądaj nagrań pełnoekranowych, pełnych dzienników ani dostępu do konta. Ustrukturyzowany przepływ wsparcia pomaga zespołowi odróżnić defekt aplikacji od niedopasowania środowiska, niekompletnych kroków, czasu lub stanu wymagającego oprzyrządowania inżynierskiego.
Praktyczna lista kontrolna dla zespołów wsparcia
Przed uruchomieniem potwierdź autoryzację, stan uruchomienia, kompilację aplikacji, konto testowe, kontekst urządzenia, sieć, ustawienia regionalne, punkty dowodowe, limity prywatności i granicę zatrzymania. Podczas biegu obserwuj ekran, stosuj wyraźne oczekiwania i warunki oraz zapisuj tylko dowody potrzebne do biletu. Po uruchomieniu przejrzyj zrzuty ekranu i dzienniki przed ich udostępnieniem.
Przejrzyj pakiet dowodów tak, jakbyś był inżynierem odbierającym. Czy potrafisz rozpoznać, który zrzut ekranu należy do którego kroku? Czy dziennik pokazuje warunek, który się nie powiódł? Czy oczekiwane i rzeczywiste wyniki podano oddzielnie? Czy dane prywatne są usuwane? Czy pakiet identyfikuje testowane środowisko i wersję Flow? Jeśli nie można odpowiedzieć na te pytania, ponowne uruchomienie automatyzacji może spowodować jedynie utworzenie bardziej niejednoznacznych plików. Krótki, uporządkowany pakiet dowodów jest cenniejszy niż duże archiwum bez narracji reprodukcyjnej.
Praktycznym rezultatem jest lepsza rozmowa pomiędzy wsparciem, kontrolą jakości i rozwojem. Wsparcie zapewnia powtarzalną historię klienta, kontrola jakości otrzymuje porównywalne dowody, a programiści otrzymują krótszą ścieżkę z widocznym stanem. Automatyzacja obsługi Androida działa najlepiej, gdy ułatwia weryfikację niepewności i dowodów, a nie wtedy, gdy próbuje zastąpić ludzki osąd.