Ocena testu, który daje niestabilne wyniki
Jak oszacować test niestabilny: dlaczego potrzebne są dwa oszacowania, a nie jedno, oraz dlaczego wyznaczenie ram czasowych jest lepszym rozwiązaniem niż spieranie się o punkty, gdy odpowiedź zależy od tego, co się odkryje.
Test typu „flaky” to dwa oszacowania. Nie wiadomo jeszcze, które z nich jest prawidłowe.
awaitW jednym przypadku wystarczyła poprawka w jednym wierszu: założenie dotyczące synchronizacji, zależność od kolejności testów, brakujący element. W drugim przypadku test przypadkowo wykrył sytuację wyścigu w kodzie produkcyjnym, której rozwikłanie zajęło trzy dni. Gdy karty rozkładają się w przedziale od 2 do 13, zespół nie spiera się co do wielkości — spiera się co do tego, jakiego rodzaju jest to błąd, co stanowi rzeczywistą niewiadomą.
Szacowanie wielkości zadania przed rozpoczęciem prac, a nie po ich zakończeniu, sprawia, że w tym przypadku projekt osiąga poziom 5 w pierwszym tygodniu i 13 w trzecim. Rozwiązaniem nie jest podanie dokładniejszej liczby, lecz zmiana sposobu realizacji zadania. Należy wyznaczyć ramy czasowe dla analizy, a dopiero po ustaleniu zakresu prac oszacować rzeczywisty nakład pracy.
O czym się mówi w tym pomieszczeniu
Inżynier A: „Jeśli to działa niestabilnie z powodu, o którym myślę, to oceniam to na 2”.
Inżynier B: „Jeśli działa niestabilnie z powodu, o którym ja myślę, to jest to 13.”
Wstęp: „Czy ktoś faktycznie uruchomił to lokalnie z ustalonym wartością początkową?”
Pytanie dotyczące kontroli jakości: „Błąd występuje wyłącznie w środowisku CI. Na komputerze programisty nigdy się nie pojawia.”
Pytania, które warto zadać przed oddaniem głosu
- Czy problem ten występuje lokalnie, czy tylko w środowisku CI?
- Jak często dochodzi do awarii — 1 na 50, 1 na 5, co drugi uruchomienie?
- Kiedy zaczęły występować problemy? Który commit?
- Czy wynik testu jest błędny, czy też wykrywa coś rzeczywistego?
- Czy ktoś w międzyczasie wyłącza tę funkcję i jakie są tego konsekwencje?
Różnica między inżynierem A a inżynierem B nie jest sporem dotyczącym punktów fabularnych, który można zniwelować poprzez uśrednienie — jest to nieznana kwestia, którą należy zbadać. Krótki, ograniczony czasowo projekt typu „spike” pozwala ją wyeliminować; głośniejsza kłótnia — nie.
Proszę wyznaczyć konkretny przedział czasowy, a nie konkretne zadanie. Pół dnia na zbadanie sprawy, a następnie przygotowanie pełnego artykułu na podstawie tego, co uda się ustalić.
Zobacz szacowanie błędu bez możliwości odtworzenia w przypadku podobnej sytuacji oraz typowe błędy związane z metodą Planning Poker dotyczące szacowania błędów z dokładnością na poziomie funkcji. Zapoznaj się z innymi przykładami szacowania lub rozpocznij bezpłatną sesję Planning Poker, gdy ustalenia z analizy będą już znane.