Что хотят услышать интервьюеры:

Это признак нестабильности теста или самого продукта, то есть flaky behavior. Обычно такая ситуация говорит не о “случайной” ошибке, а о зависимости от времени, окружения, данных или порядка выполнения. Важно уметь отличать дефект продукта от проблемы теста и быстро локализовать источник нестабильности.

Определение:

Если тест иногда проходит, а иногда падает без изменения кода и условий запуска, его называют нестабильным, или flaky. Причина может быть в самом тесте, в асинхронности, в зависимостях от внешних сервисов, в некорректной подготовке данных или в гонках за ресурсы. Для QA это сигнал, что результат теста нельзя считать надежным до выяснения причины.

Пример использования:

Например, UI-тест иногда не находит кнопку “Сохранить”, хотя на экране она есть. При повторном запуске тест проходит, потому что страница еще не успела полностью загрузиться или анимация перекрыла элемент.

def test_save_button_visible(driver):
    driver.get("https://example.com/profile")
    button = driver.find_element("css selector", "#save")
    assert button.is_displayed()

Если перед проверкой не дождаться полной загрузки страницы или видимости элемента, тест может падать только иногда.

Пояснение кода:

Код показывает типичную проблему нестабильного UI-теста: поиск элемента выполняется сразу после перехода на страницу. Если интерфейс загружается асинхронно, элемент может еще не быть доступен в момент проверки. Тогда при одном запуске тест пройдет, а при другом — упадет из-за разницы во времени загрузки.

Разбор по шагам:

Открывается страница профиля.
Сразу выполняется поиск кнопки по селектору.
Если DOM еще не готов или элемент не отображен, проверка падает.
При более быстром окружении тест может пройти, поэтому поведение выглядит “случайным”.

Ключевые моменты:

Нестабильный тест чаще всего указывает на проблему в тесте, а не на “магическую случайность”.
Частые причины: ожидания по времени вместо явных ожиданий, асинхронность, зависимость от внешних сервисов, общие тестовые данные, гонки.
Повторный успешный запуск не доказывает, что тест корректен.
Нужно воспроизводить проблему, изолировать окружение и смотреть логи, тайминги, данные и порядок выполнения.
Хорошая практика — заменить фиксированные sleep на явные ожидания и сделать тесты независимыми друг от друга.

Как интерпретировать ситуацию, когда тесты проходят успешно только иногда, а иногда — проваливаются?