У Вас onclick не на инпуте, а на лейбле.

При этом, сама отметка на радиобаттоне тоже ставится этим же onclick'ом (<label for="ID_DELIVERY_ID_41" onclick="BX('ID_DELIVERY_ID_41').checked=true; submitForm();">).

Попробуйте кликать по '#ID_DELIVERY_ID_41+label' (cssLocator).

Либо по '//*[@id='ID_DELIVERY_ID_41']/../label]' (xpath).

Или '//*[@id='ID_DELIVERY_ID_41']/following-sibling::label]' (xpath)

Я тоже не согласна. Есть вещи, которые ДОЛЖНЫ оставаться неизменными вне зависимости от каких либо не связанных с ними доработок системы, и которые критичны для проверки. 

Например, если система должна принимать решения, в т.ч., к примеру, отказы при определенных условиях - почему же не автоматизировать такие проверки?

Мне кажется автор статьи упёрся в своё собственное понимание того, какой бывает регресс, поэтому не учитывает, что случаи бывают разные.

"Автоматизировать надо те тесты, которые находят ошибки"...

Хм... Т.е. если тест перестал находить ошибки (всё пофиксили ) - он больше не нужен? Или всё же нужен, чтобы убедиться, что ошибки не вернулись? 

А если тест не находит ошибок сейчас, но это функционал, который крайне критичен (его поломка может привести к серьезным финансовым потерям организации) - его не надо автоматизировать, т.к. он "не находит ошибки"? Ждём пока начнёт находить? Так организация уже успеет на этом деньги потерять. Или всё же лучше критичный функционал проверять изначально?

Так статья об автоматизации в целом, а не о том, с чего "начинать".

Ситуации бывают разные, но все меряют по себе.

У нас лишнее => у всех лишнее.

Нам не нужно => никому не нужно.

Слишком однобоко, как мне кажется.

Вообще-то выше был мой пример: система, которая должна при определенных условиях принимать определённые решения.

При этом неверно принятое решение - может привести к серьезным финансовым потерям. 

Проверки не абстрактные, а вполне конкретные, и их не две-три, а достаточно много.

Проверяются регулярно, для бизнеса крайне критичны.

Вы опять пишете про "начало". Нужны ли ручные тесты перед автоматизацией, с чего начинать, что надо делать "сразу" и т.д.

Статья (и я тоже) - об автоматизации в целом. 

Я возразила против тезиса о том, что регрессионный тест вообще не надо автоматизировать. 

Я ничего не писала о том, с чего надо начинать, я не про это вообще пишу.

п.с.: Я работаю в банке и, к сожалению, не могу расписать подробнее, могу лишь сказать, что это весьма далеко от того "списка фич" с пропадающими кейсами, который представили себе Вы. И они не "отсортированы по критичности" - они одинаково критичны, неработоспособность ЛЮБОЙ из этих проверок - блокирующая проблема.

del

 

 

 

Я возразила против тезиса о том, что регрессионный тест вообще не надо автоматизировать. 

тезис о том, что "ручной регрессионный тест не надо автоматизировать" правилен

 

так как автоматизировать надо "тестирование фич", а не "ручные тесты которые тестируют только видимую часть фичи"

 

Я про "ручной регресс" не писала вообще, как и про "ручные тесты которые тестируют только видимую часть фичи".

Видимо, мне так и не понять, где и как Вы в моих словах (и в изначальном тезисе, о котором я писала) увидели то, чего там и близко не было. 

 

 

Я про "ручной регресс" не писала вообще, как и про "ручные тесты которые тестируют только видимую часть фичи".

Видимо, мне так и не понять, где и как Вы в моих словах (и в изначальном тезисе, о котором я писала) увидели то, чего там и близко не было. 

а какой ещё регресс бывает который автоматизируют? бывает только ручной регресс который автоматизируют

 

 

 

Я возразила против тезиса о том, что регрессионный тест вообще не надо автоматизировать. 

вот именно тут вы пишете про ручной регресс

 

И где в этих моих процитированных словах про мифические "ручные тесты которые тестируют только видимую часть фичи"? 

п.с.: те мои тесты, которые я упоминаю, писались "с нуля" на основе документации по соответствующим доработкам + с изучением конкретной реализации вплоть до кода, а не тупо переписывались один в один в автоскрипт из кем-то когда-то написанного "ручного теста". 

driver.switchTo().alert().accept();

Давно не смотрела Selenium IDE, не уверена, можно ли там сейчас как-то завязываться на "текущую дату" и уже от неё плясать.

Это не "поиск необходимого текста", т.к. у этого элемента нет текста. Вы не то гуглите.

У элемента есть атрибут с определенным значением (см. то, что Вам написали выше).

Соответственно и копать Вам надо не в сторону "поиска текста", а в сторону "поиска элемента по значению атрибута".

Как вариант - искать элемент по "#DeparturePath" (т.е. без привязки сразу к атрибуту + у самого элемента есть айдишник свой, его не зачем от вышестоящего как-то искать).

А потом уже следующим шагом получать значение атрибута placeholder и проверять его

Есть вероятность, что скрипт падает на "нет такого окна" до того, как оно успевает возникнуть. 

(new WebDriverWait(browser, <timeOutInSeconds>)).until(ExpectedConditions.alertIsPresent()).accept();

У меня был пример - из моего кода (с небольшими изменениями), а не из "примеров в сети".

Видимо там какое-то специфическое окно. Тогда, наверное, действительно - проще добавить сайт в доверенные.

С другой стороны - может быть у Вас и дальше в софте такие же окна будут? 

Тогда все же придется искать способы с ними работать.

Как вариант - попробовать поставить Каталон (скачать и распаковать, он бесплатен) и автоматизировать в нём эту часть.

Не с целью ВСЁ туда перенести, а просто для того, чтобы подсмотреть, как такие окна находит Каталон (и находит ли).

...

dsound: Could not set cooperative level for window 0000000000000000
dsound: Reason: An invalid parameter was passed to the returning function
audio: Could not init `dsound' audio driver
emulator: WARNING: Requested adb port (5763) is outside the recommended range [5555,5586]. ADB may not function properly for the emulator. See -help-port for details.
...
emulator: WARNING: Not saving state: RAM not mapped as shared
...
$ D:\Android\Sdk/platform-tools/adb.exe kill-server

Я бы копала в эту сторону.

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

Мне кажется, тема канбана не раскрыта вообще.

В чем преимущество Kanban? Команды не ждут конца спринта, а объединяют свои локальные изменения с мастер-веткой по факту окончания реализации задачи, каждый раз проверяя, нет ли конфликтов объединения.

 Суть Канбана (насколько я её понимаю) в WIP и распределении нагрузки, а не в том, как бы про транк договориться.

 

 

Суть Канбана (насколько я её понимаю) в WIP и распределении нагрузки, а не в том, как бы про транк договориться.

вот так и распределяют нагрузку, распределяют слитие в транк, чтобы не в один день 5 веток приходило и головную боль всем доставляло

Я могу ошибаться, но все же это не про очередь слития в транк. 

WIP ограничивают кол-во задач: есть бэклог, на анализе не более X, на разработке не более Y, на тестировании не более Z. 

Это не спасает от ситуаций, когда одновременно Y команд заканчивают свою разработку, а тестирование не может их принять, т.к. у них уже есть Z задач в работе. А исходя из их ситуации - Y не может быть меньше 5, иначе часть их команд будет простаивать.

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

Из-за этого, возникает ощущение, что слово Канбан использовано просто для красоты.

как раз и спасает, так как это не Скрам где спринты заканчиваются в один день, поэтому и команды не одновременно заканчивают разработку

И что же мешает разным независимым командам закончить разработку одновременно без наличия спринтов? 

Без часа Х какие-то из команд резко ускорятся и сделают быстрее? Что мешало им делать быстрее раньше? Не потеряется ли качество?

Без часа Х команды будут тянуть время, чтоб случайно не закончить одновременно? А зачем кому-то может быть нужно дорогостоящее простаивание команды?

Канбан совсем не про то, что Вы пишите.

Кроме того, по их схемкам, регрессионные тесты у них запускаются все же одновременно для всех 5 команд. Просто "сливание" у них теперь не в одной точке, а в нескольких.

Поэтому то, что они сформулировали можно как "мы перешли на Канбан", выглядит гораздо ближе к "мы разнесли по времени спринты скрам-команд". На мой взгляд, это не одно и тоже.

 

Поэтому то, что они сформулировали можно как "мы перешли на Канбан", выглядит гораздо ближе к "мы разнесли по времени спринты скрам-команд". На мой взгляд, это не одно и тоже.

они могли сделать смещение спринтов по командам, а могли перейти на Канбан - они выбрали перейти на Канбан

Выбрали может и Канбан, а сделали, судя по статье - смещение спринтов.

Если там и есть Канбан у них - эта тема в статье не раскрыта.

Здорово, что Вам из этой статьи кристально ясно, что же они сделали. Мне информации в статье не хватило для целостной картины.

Здорово, что Вам из этой статьи кристально ясно, что же они сделали. Мне информации в статье не хватило для целостной картины.

Что-то вроде [data-ident='city'][data-title='Москва'].current

Или: [data-ident='city'][data-title='Москва']>span.tower

(css)

Одновременное использование явных и неявных ожиданий в принципе не рекомендуется.

Одновременное использование явных и неявных ожиданий в принципе не рекомендуется.

наоборот, рекомендуется в случае разных "сложных" элементов, когда элементы кастомные или с фреймворков типа реакта, или когда лэйзи лоадинг применяется

https://www.selenium...er_advanced.jsp

WARNING: Do not mix implicit and explicit waits. Doing so can cause unpredictable wait times. For example setting an implicit wait of 10 seconds and an explicit wait of 15 seconds, could cause a timeout to occur after 20 seconds.