Фреймворк работает в однопоточном или многопоточном режиме?

Что проверяют

Знаете ли вы, как устроен запуск в вашем проекте, и понимаете ли, что требуется от тестов для параллели. Вопрос почти всегда ведёт к следующему: почему ваш набор нельзя просто взять и распараллелить.

Как отвечать

Сначала конкретно про свой инструмент, а не про абстрактные режимы:

• pytest сам по себе последовательный, параллель даёт плагин pytest-xdist с ключом -n, который раскидывает тесты по процессам;
• JUnit 5 умеет параллель, но её включают настройками в junit-platform.properties и аннотацией @Execution;
• в TestNG параллель задаётся в XML-сьюте: по методам, классам или тестам, там же число потоков;
• в Go пакеты тестируются параллельно по умолчанию, а внутри пакета нужен t.Parallel().

Дальше главное: упирается всё не во фреймворк, а в тесты и стенд. Нужны независимые данные (свой пользователь на тест, а не общий), отсутствие общего изменяемого состояния, свой экземпляр драйвера на поток, запас по ёмкости окружения.

Честно назовите цену: прогон становится короче, но отладка сложнее, логи перемешиваются, и артефакты приходится жёстко привязывать к конкретному тесту.

Где спотыкаются

Повторяют, что параллель в JUnit включается аннотацией @Threads. Такой аннотации там нет, она из библиотеки бенчмарков JMH, а параллельный запуск в JUnit 5 настраивается свойствами платформы.

Обещают параллельный прогон и рассыпаются на общих данных: одна учётная запись на всех, общая тестовая сущность, драйвер в статическом поле. Тесты начинают падать случайным образом, и команда возвращается к последовательному запуску.

Отвечают общими словами про плюсы и минусы, не зная настроек своего проекта. Уточняющий вопрос простой: сколько потоков стоит сейчас и где это прописано. Без ответа видно, что запуском занимался кто-то другой.