Советы и рекомендации по развёртыванию процесса автоматизация тестирования с нуля

Исправил :) Спасибо за пометку.

Спасибо за пометки, вы совершенно правы:
1. Бэкграунд
2. Karma

Для получения webdriver в билде поможет плагин driver-binary-downloader-maven-plugin

Вы, наверное, шутите? Автоматика — как средство многократного и быстрого тестирования нужна именно там, где все меняется. Чтоб проверить не сломали ли чего изменения. То, что не будет меняться — можно проверить и вручную. Изредка.

Отличный комментарий, спасибо. Здесь как раз совершенно наглядна разница двух основных подходов к выбору области автоматизации (когда писал статью — обдумывал, стоит ли это расписывать, видимо стоило).
По сути очень многое в выборе подхода зависит от ресурсов, имеющихся у команды и сложности самого проекта.
Для проектов, где я развёртывал автоматизацию наиболее слабым местом была именно регрессия, даже тестирование в дельта-окрестности отдельных задач нового релиза требовало большого времени на разные варианты проверки (в основном — тесты с высокой вариативностью входных данных), и ресурсы тестировщиков тратились именно на эти сложные проверки. Закрытие их авто-тестами практически закрыло проблему регрессии.
Здесь важно отметить, что мало изменяемый код не означает — мало используемый. Понятно, что автоматизировать стоит в первую очередь критические точки проекта.
В то же время, совершенно разумный подход — при отсутствии проблем в мало изменяемых областях и при наличии ресурсов — автоматизировать часто изменяемый код — с, как вы верно отметили, целью проверки его на валидность после внесённых изменений. Подход можно рекомендовать компаниям, где автотестирование профессионально отлажено (либо есть профессиональный специалист), и изменение повалившихся тестов при изменении функционала не занимает долгого времени и сил.
У начинающих специалистов, для которых, в основном статья и написана, подобный подход может отнимать слишком много времени (впрочем, всё, естественно, зависит от человека).

И опять на те же грабли, оцениваем автоматизированное тестирование по отношению ручному. Да еще и эффективность в отрыве от результативности. Это разные виды тестирования с разными тактическими целями и задачами. Автоматизация — во многом — скорость и воспроизводимость.

В статье указано, что эта оценка — примерная и её стоит использовать в том случае, когда данные о результативности автоматизации по данному модулю либо малы, либо отсутствуют, по сути — когда это будет предварительная оценка автоматизации на основании приблизительных данных из других модулей и/или ручного тестирования на проекте. На основании вашего вопроса чуть подробнее раскрыл описанное в статье.
Эта оценка нужна скорее для того, чтобы начинающий специалист мог понять и обосновать руководству, нужна ли вообще автоматизация на проекте, или ну её, руками справимся быстрее.

Функциона́л — это отображение, заданное на произвольном множестве.
Не следует путать с функциональностью — совокупностью возможных вариантов использования или возможных действий выполняемых неким объектом (программой).

Функционал в контексте функциональности — часто используемый жаргонизм и элемент сленга.
Впрочем, с учётом того, что это режет глаза — почистил текст.

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

Вам большое спасибо за комментарий, как появится время — раскрою вопрос с выбором цели автоматизации подробнее.