Ocena testu, który daje niestabilne wyniki

Test typu „flaky” to dwa oszacowania. Nie wiadomo jeszcze, które z nich jest prawidłowe.

W jednym przypadku wystarczyła poprawka w jednym wierszu: założenie dotyczące synchronizacji, zależność od kolejności testów, brakujący elementawait. 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 w pierwszym tygodniu zadanie zajmuje 5, a w trzecim – 13. Rozwiązaniem nie jest podanie dokładniejszej liczby, lecz zmiana sposobu realizacji zadania. Należy wyznaczyć ramy czasowe 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 ta usterka wynika z przyczyny, o której myślę, to oceniam to na 2”.

Inżynier B: „Jeśli działa niestabilnie z powodu, o którym ja myślę, to ocena 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. Nigdy nie pojawia się na komputerze deweloperskim”.

Pytania, które warto zadać przed głosowaniem

• 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 przejazd?
• Kiedy zaczęły występować problemy? Który commit?
• Czy wynik testu jest błędny, czy też wykrywa on 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 kwestią sporu dotyczącą punktów fabularnych, którą można zniwelować poprzez uśrednienie. Jest to nieznana zmienna, którą należy zbadać. Krótki, ograniczony czasowo projekt pilotażowy pozwala ją wyeliminować; głośniejsza kłótnia – nie.

Proszę traktować to jako ramy czasowe, a nie jako rozwiązanie. Pół dnia na zbadanie sprawy, a następnie przygotowanie rzetelnego artykułu na podstawie tego, co Państwo ustalą.

Zobacz szacowanie błędu bez możliwości odtworzenia w przypadku podobnego scenariusza oraz typowe błędy w planowaniu pokerowym 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ę planowania pokerowego, gdy wyniki analizy będą już znane.