Когда перестанете плакать и хамить, можете описать свое видение обзора инструментов более аргументированно? А не на уровне ученика 8 класса...

Баги также конструктивно описываете?

спасибо за коммент,

Но конфигурить Jenkins через веб интерфейс в 2018 году — дурной тон.

это тема для отдельной статьи. Описывать здесь Pipline — только растягивать статью и путать новичка, ИМХО.

Selenide — обёртка на любителя

 — на вкус и цвет все фломастеры разные, но ИМХО Selenide экономит намного больше времени чем будет затрачено на добавление ожиданий к элементам где это необходимо через: "$("someElement").waitUntil(Condition, timeout);"

видео капчурить и браузеры в докере умеет и стандартный образ от github.com/...​eleniumHQ/docker-selenium .

на момент выбора docker реализации, selenoid показался более стабильным в плане управления сессиями, скорее всего что-то уже изменилось у docker-selenium

Странно, не сталкивались с этой проблемой ни у меня ни на других машинах на которых запускали. Но спасибо, надо будет посмотреть на досуге, мб найду причину.

Расположение выбрано в соответсвии с рекомендациями из оф, документации maven.apache.org/pom.html#Reporting, формирование отчета относится к стадии Site соответсвенно и зависимости подтягиваем в эту секцию.

Что значит не подтягивает? по mvn clean test site что происходит? дайте текст ошибки. Если используете тестовый проект который прикреплен к статье, обратите внимание что необходимо заменить URI в классе «MyDriverManager» на актуальный.

Спасибо,а что именно вызывает сомнения?

Сколько людей столько и мнений, пару комментами выше коллега писал, что API тесты просто, основы JS + Postman. Вам сложно) Как по мне. так все сложно, если качественно, а не вжух-вжух и в продакшен =)

Наследовать и создавать с 0 это 2 совсем разные ситуации. Наследство, понятно что проще переписать в 99% случаев.

А секрет легкого сопровождения банален и прост. Чём меньше тестов , тем проще поддержка. Не стоит плодить телегу из UI тестов. Разумный баланс интеграционных и UI поможет, но это тема совсем другой статьи. Да и сломано в этом вечном холиваре 100500 копий.

Обычно проще выбросить и заново написать

С таким подходом сопровождаемых тестов никогда и не будет. Какой смысл переписывать тесты если не было изменения бизнес логики. Если была, то тут очевидно проще переписать, т.к. тест банально перестал быть актуален. А вот минорные изменения, например изменения в верстке, вносятся легко и непринужденно...

Почему все пытаются выбирать что-то одно? Тесты API — это тесты API, тесты UI это тесты UI и у каждого вида тестов свое место и степень покрытия. Не стоит пытаться покрыть одним типом теста все и вся... UI и API тесты прекрасно сосуществуют и дополняют друг друга, но не стоит забывать что API тестов должно быть больше. Если крыть все UI тестами то боль и разочарование обеспечены

в большинстве случаев это сигнал о том. что у вас проблемы в первую очередь в тестах

Не нужно писать «как сложилось» и без рефакторинга. Необходимо раз, но по-человечески и довести тесты до стабильного выполнения для исключения случайных сбоев которые не считая сбоев по связи в 99% случаев имеют четкую причину которую возможно найти. Перестать городить велосипеды, а использовать зарекомендовавшие себя инструменты. Также не стоит крыть тестами все и вся, а только устоявшийся на данный момент функционал. И про боль поддержки тестов можно будет забыть. А умеючи. можно и лом согнуть....

ускорить процесс тестирования без потери качества,

Возможно важны быстрые релизы? Возможно дать быстрый фитбек девам о внесении изменений?

спасибо что перефразировали =)

Если все настолько противоположно у Вас, поделитесь — всем будет интересно. Для нас важно ускорение процесса тестирования без потери качества, а с его повышением. Уменьшение времени на прогоны регрессионных тестов позволяет использовать его более рационально.

«Статья будет полезна не только менеджерам, отвечающим за процессы разработки и тестирования, но и рядовым тестировщикам. Ведь нет такого тестировщика, который не хочет стать автоматизатором.» — часть вступления.

Статья — обзор инструментов и места автотестов в процессе разработки, Бывалые автоматизаторы давно прошли этот путь.

memesmix.net/media/created/igzbmy.jpg

Истинно так =) на эту темы огромное кол-во статей и докладов. Пирамиду автотестов никто не отменял