Pull to refresh

Comments 10

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

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

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

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

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

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

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

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

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

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

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

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


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


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

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


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

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


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

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


Вам большое спасибо за комментарий, как появится время — раскрою вопрос с выбором цели автоматизации подробнее.
Only those users with full accounts are able to leave comments. Log in, please.