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

 

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

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

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

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

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

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

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

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

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

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

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

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

 

 

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

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

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

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

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

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

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

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

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

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

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

...

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

 

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

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

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

 

 

 

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

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

 

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

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

 

 

 

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

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

 

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

 

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

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

del

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

У Вас 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)

Тот кусочек кода делает не совсем то, что озвучил автор темы.

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

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

Сначала фактический (что же произошло в результате указанных шагов), потом ожидаемый (что должно было быть и почему).

А так? (вариация на тему первого моего варианта)

element.all(by.css(<локатор первой кнопки>))).count().then(function(count) {
   if (count > 0) {

      element(by.css(<локатор>)).click();

   } else element(by.css(<локатор второй кнопки>)).click();

});

Сорри за флуд, просто самой интересно, как же в протракторе решается эта ситуация.