Проводите ли код-ревью друг другу
Что проверяют
Относитесь ли вы к коду автотестов как к обычному коду и участвуете ли в просмотре изменений разработчиков. По ответу видно, есть ли в команде инженерная культура или тесты живут отдельной свалкой.
Как отвечать
Разделите два направления.
Просмотр тестового кода. Что смотрите: нет ли ожидания фиксированной длительностью вместо ожидания условия, устойчивы ли локаторы, вынесены ли шаги в общий слой, независим ли тест от порядка запуска и от данных соседнего теста, убирает ли он за собой созданное, есть ли осмысленные проверки с понятным сообщением о падении, безопасен ли запуск в несколько потоков, не лежат ли учётные данные в репозитории.
Просмотр кода разработчиков глазами тестировщика. Вопросы другие: как эту правку проверить, появились ли устойчивые признаки для поиска элементов, хватит ли логов и метрик, чтобы разобрать инцидент, что происходит при ошибке внешнего вызова, какие граничные значения обработаны. Такой просмотр экономит время позже, когда воспроизводить дефект уже поздно.
Добавьте про нестабильные тесты: падение разбирается, а не заглушается перезапуском.
Где спотыкаются
Смотрят тест по признаку зелёный или красный. Тест без единой проверки, тест, который перехватывает исключение и молча идёт дальше, проверка вида «страница открылась» проходят такой просмотр и дают ложное чувство покрытия.
Пропускают копирование. Сценарий множится с одной изменённой константой, и через полгода правка одного поля требует руками пройти два десятка файлов. На просмотре это видно сразу, потом уже никогда.
Пишут в чужом запросе только одобрение или, наоборот, лезут в реализацию. Ценность тестировщика в других вопросах: тестируемость, наблюдаемость, поведение при ошибке. Спор о названии приватного метода её не заменяет.