Для запуска автоматических тестов часто ставится задача – создание изолированного окружения под различные платформы, но организовать такие окружения для тестирования — далеко не самая простая задача. Хотим еще иметь систему мониторинга и управления автотестами и тестовым кодом, анализировать стабильность тестов и качество проверяемого ПО – задача становится еще сложнее.

Каких бы размеров не были ваши кубирнейтесы, в которых вы поднимаете докер контейнеры для прогона селениуем тестов, сколько бы сотен тестов не запускали в минуту – не стоит забывать об одной неприятной особенности селениум тестов – хрупкости. Сейчас существует огромное количество способов борьбы с флаки тестами, начиная от использования фреймворков, с помощью которых можно писать стабильные тесты, заканчивая инструментами, позволяющими “на лету” в ходе теста изменять элементы, давая тесту пройти.

Бывает, что после простого изменения, неожиданно проваливаются 50+ испытаний. Нестабильные тесты, которые зависят от специфики GUI и приводят в результате к ошибке NoSuchElementException – это основная проблема при тестировании с помощью Selenium. Повторная проверка проекта с открытым кодом представляет собой простое и элегантное решение.

За последние десятилетия AI проникает в самые обычные вещи. Телефон распознаёт лица и выполняет голосовые команды. Автомобиль может самостоятельно двигаться в потоке или припарковаться. Гражданская авиация не представляется без систем, принимающих критические решения, исключая человеческий фактор.