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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

del

 

 

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

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

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

 

 

 

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

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

 

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

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

 

 

 

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

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

 

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

});

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

Альтернативный вариант:

if (driver.findElements(<локатор первого элемента>).size() > 0) {

     <какие-нибудь ожидания, если нужно>

     driver.findElement(<локатор первого элемента>).click();

} else driver.findElement(<локатор второго элемента>).click();

п.с.: findElements эксепшенов не кидает, если ничего не нашел, просто возвращает пустой List, поэтому try/catch тут не требуется.

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

- Зачем создавать велосипед?

- Если это велосипед, который никому не нужен, почему куча людей продолжают ездить используя машины / мотоциклы /поезда и т.д.?

Кода Ваших страниц тут нет, чтобы сказать, нет ли там возможности не искать по тексту (как + Create New и Next >), но вообще - выглядит гораздо лучше. Фиксированные айдишники - вообще идеальный вариант.

Да, тут похоже, без текста никак. (поиски в стиле button[2] в расчет не беру).

Если есть возможность - можно попросить разработчиков добавить айдишники к элементам, с которыми пользователь может взаимодействовать (поля / кнопки и т.п.).

Не только из-за стабильности (и лаконичности) локаторов, но и в целях удобства дальнейшей автоматизации (если есть id - Вы и не будете тратить время и другие локаторы искать).

Ну, Вы ему писали выше про css - может решил начать с освоения xpath'а.

...

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

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

Два варианта:
1. findElements не падает с эксепшеном, даже если элементы с таким локатором не найдены - просто возвращает пустой список. Соответственно:
ArrayList<WebElement> selectUserOwners = driver.findElements(By.xpath("/html/body/div[6]/div[2]/div/form/div[1]/table/tbody/tr/td[2]/div[2]/div/div[4]/div/div/div[2]/a"));
if (selectUserOwners.size() > 0) selectUserOwners.get(0).click();
 
2. Обернуть оба "элемента" в try { <поиск элемента и клик> } catch (NoSuchElementException e) {}

п.с.: локаторы - адские просто. Максимально нестабильные из всех, которые только могут придти в голову :).

п.п.с: если списки влияют друг на друга (выбираете значение в одном - обновляются значения в другом) - то надо бы добавить ожидания (ExpectedConditions).

 

3) если нет, остается xpath, пишем, опираясь на атрибуты элемента (класс, ссылка... НЕ текст, не title и т.п.)

 

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

Кнопка "Сохранить" может внезапно стать кнопкой "Save", если в Вашем приложении есть возможность смены языков.

При локаторах по тексту - придётся под каждый язык свою версию локатора делать.

При локаторах по айдишникам, к примеру, условная кнопка #saveBtn - таковой и останется вне зависимости от выбранного языка.

 

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

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

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

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

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

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

 

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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