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

[@sskorol]

если бы не полезные лекции Александра Баранцева

По всей видимости, речь все же шла об Алексее Баранцеве?

[@Arjah]

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

[@Archie_RU]

Когда на проекте уже проведена предварительная работа, имеется какой-то бэкэнд в виде тест-планов, тест-кейсов, оптимально — автотестов предыдущего этапа АТ.

Точно бэкенд а не бэкграунд, например?

Ну а Krame позволяет эти тесты запускать в разных браузерах

krame?

Спасибо за статью.

[@Arjah]

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

[@igor_suhorukov]

Спасибо за публикацию!

2. Selenium Webdriver
Само решение не слишком элегантно, но об этом написано выше. Если всё же решили идти простым путём, то достаточно поставить:

Тут я с вами не согласен! Весь сценарий может поместиться в одном groovy скрипте(например crawler.groovy), без потребности устанавливать Selenium IDE, webdriver для браузера и т.п. А с Geb фреймворком кода становится гораздо меньше

[@igor_suhorukov]

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

[@Arjah]

Спасибо, Вы написали любопытную статью, можно будет попробовать использовать на одном из проектов.
Но, конкретно здесь указаны не недостатки webdriver'а в целом, как решения (о чём написано в предыдущей главе), а большее удобство использования связки Karma + Protractor для тестирования AngularJS бекэнда.
И опять же в третьих — две главы о выборе и использования инструментария здесь скорее проходят примером решения для конкретного проекта, поскольку само руководство немного о другом. :)

[@igor_suhorukov]

Я понимаю, что ваша публикация скорее о подходе. Но поскольку там мелькают фреймворки и технологии, то не мог удержаться и прокомментировать.

Очень сложно автоматизировать следующие вещи:
Проверка содержимого изображения (есть программы, которые позволяют частично решить эту проблему, но в простом срезе задач такие тесты лучше не автоматизировать, а оставить для ручного тестирования)

Опять же в случае проверки diff изображений из webdriver помогает проект ashot

[@Wolonter]

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

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

Оценка эффективности автоматизации в целом.

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

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

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

[@Arjah]

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

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

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

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

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

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

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

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

[@Snegova]

Инструменты некоторые уже более актуальные есть (не удивительно ?), но информация и ваш опыт все ещё полезны, спасибо, что делитесь ?