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 mające na celu ustalenie, jak duże jest dane zadanie, a nie dopiero po jego zakończeniu, sprawia, że w tym przypadku w pierwszym tygodniu zadanie zajmuje 5, a w trzecim – 13. Rozwiązaniem nie jest dokładniejsza liczba, lecz inny sposób organizacji pracy. Należy wyznaczyć ramy czasowe dla analizy, a dopiero po ustaleniu zakresu zadania 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 ocena to 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 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 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 test sprawdzający 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 odkryją.

Zobacz: „Szacowanie błędu, którego nie da się odtworzyć” w odniesieniu do tego samego przypadku 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 wraz z objaśnieniami lub rozpocznij bezpłatną sesję planowania pokerowego, gdy wyniki analizy będą już znane.