Автоматизация тестирования

В CI UI-тест падает только при параллельном запуске: какое свойство тестовой архитектуры следует проверить первым?

Команда хочет проверять интеграцию с нестабильным внешним сервисом, не делая результат CI зависимым от его доступности. Какой механизм автоматизации применить?

В CI настроены повторы упавших тестов. Определите главный риск такой настройки для достоверности результата.

ci:
  run: test-suite
  retry_failed_tests: 3
  merge_allowed_if: passed_on_last_attempt

После добавления большого числа end-to-end-тестов CI стал медленным, хотя покрытие выросло. Какое архитектурное решение восстановит быструю обратную связь?

Представьте, что поставщик API и потребитель развиваются независимо: как контрактные тесты предотвращают несовместимое изменение интерфейса до интеграционного запуска?

На странице кнопка становится доступной после асинхронного запроса, поэтому тест иногда не успевает нажать её. Какой механизм ожидания следует применить вместо фиксированной задержки?

import time

def test_submit(page):
    page.open('/checkout')
    time.sleep(5)
    page.click('#submit')
    assert page.text('#status') == 'accepted'

В автотесте проверяется истечение срока, но результат зависит от реального времени. Какой архитектурный механизм сделает такую проверку детерминированной?

В CI нужен быстрый набор тестов на каждый коммит и полный набор по расписанию. Как организовать такой отбор без дублирования тестов?

Команда замечает, что тесты зависят от данных, оставшихся после предыдущего запуска. Какой принцип организации тестовых данных устранит эту зависимость?

Из-за изменения локатора десятки UI-тестов требуют правки, хотя пользовательские сценарии не изменились. Какой архитектурный механизм должен локализовать такие изменения?

Ситуация: тесты проходят на ноутбуках, но нестабильно в CI из-за различий окружения. Какой механизм сделает окружение запуска воспроизводимым?

Тест в CI завершился ошибкой, но по статусу сборки причину определить нельзя. Как организовать воспроизводимую диагностику сбоя?

Как мутационное тестирование выявляет слабые утверждения в тестовом наборе?

Сервис возвращает ошибку, но автотест зависит от точного текста сообщения. Каким способом сделать проверку устойчивой к изменению формулировки?

В тестах изменение обязательных полей заказа требует правок в десятках сценариев. Какой паттерн локализует подготовку тестовых объектов?

Как организовать генерацию случайных тестовых данных, чтобы найденный сбой можно было воспроизвести?

Для одного бизнес-правила доступны UI- и сервисный автотесты: какой уровень следует сделать основным?

В наборе автотестов один сценарий должен выполняться с разными ролями пользователя. Что следует изменить в архитектуре, чтобы добавление роли не порождало копию сценария?

В ревью автотестов обнаружено, что все зависимости сервиса заменены имитациями, а тесты проверяют только вызовы этих имитаций. Какой архитектурный риск создаёт такой подход?

На интерфейсе нужно автоматически обнаруживать незаметные визуальные смещения после изменений. Какой подход следует применить?