«Флакі-тест» часто означає просто «ми не міряли»Був у нас UI-тест, який падав приблизно раз на десять прогонів. Класика жанру: таймаут 120 секунд, браузер не дочекався переходу, стектрейс на пів екрана. Найочевидніше рішення напрошується саме — підняти поріг до 180 і жити далі.Замість цього ми додали один рядок логування: скільки мілісекунд насправді тривало очікування. Не «впав / не впав», а конкретне число.А потім витягли з архівів Jenkins звіти за 8 прогонів. Виявилося, що в JUnit XML лежить <system-out> — увесь stdout тесту. Тобто вся історія вимірювань уже була, просто ніхто в неї не дивився. Скрипт на сотню рядків дав 396 замірів.І ніякої випадковості там не виявилось.Тест проганяє один і той самий сценарій шість разів поспіль — для шести різних довідників. Медіани:довідник 1 3,4 сдовідник 2 52,4 с ←довідник 3 3,2 сдовідник 4 2,4 сдовідник 5 38,6 с ←довідник 6 5,4 сДві позиції з шести повільні. І у всіх восьми прогонах це ті самі дві. Жодного винятку. Це не флакі — це детермінована поведінка бекенду, яка іноді просто не вкладається в поріг.Три висновки, які я забрав собі.Таймаут — це бінарна відповідь на неперервне питання. Він каже «встиг / не встиг» і викидає найцінніше: на скільки саме не встиг. Логуйте тривалість поруч із кожним очікуванням — особливо коли воно успішне.Підняти поріг — це не виправити, а перестати бачити. 180 секунд зробили б білд зеленим. А користувач у проді все одно сидів би хвилину перед незмінним екраном без індикатора прогресу. Тест не помилявся. Він показував правду, яку незручно було читати.Дані вже є, просто в незручному місці. Якщо ваш пайплайн архівує build/test-results/**, у вас уже лежить готовий датасет по кожному прогону. З нього будується розподіл — замість суперечок на відчуттях.Наступного разу, перш ніж написати в тікеті «flaky, перезапустив — пройшло», спробуйте поставити питання інакше: а скільки саме секунд?@AllAboutQA