через browser.driver.wait(visibilityOf)

С промисами как-то не так работает слип

странно, протрактор же сам резолвит, где надо

Там ситуация из серии loadButton.click() а потом expect(element.all(by.xpath('path')).count()).shouldBeMore(0)

и даже если засунуть browser.sleep() между ними, слип срабатывает, но раньше клика. чертовы промисы :)

И это логично, потому что слип запускается сразу после создания промиса, а не после его получения.

Вы же понимаете, как работает асинхронность? :)

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

В селениум тестах надо ждать). Плюшки от промисов вообще никаких.

и даже если засунуть browser.sleep() между ними, слип срабатывает, но раньше клика. чертовы промисы :)

https://stackoverflow.com/questions/38171249/how-to-wait-in-protractor-till-the-element-is-enabled

Примеры: var elm = element(by.id('paynow-info-btn')); var EC = protractor.ExpectedConditions; browser.wait(EC.elementToBeClickable(elm), 5000); elm.click();

Остальное - смотреть доку к протрактору

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

Там есть встроенные вейтеры

Коллеги, добрый день. Был тут недавно на собеседовании, где задали интересный вопрос. Во что должен и не должен вмешиваться тестировщик в жц ПО? Что думаете?

тестировщик - ни во что

Понятно, что тестирование и анализ требований. А ещё какие мысли?

должен или не должен?

должен или не должен?

Во что должен а во что не должен

тестировщик только тестировать, а если QA то он должен во всех этапах ЖЦ участвовать

тестировщик только тестировать, а если QA то он должен во всех этапах ЖЦ участвовать

this

На этапе разработке разве стоит вмешиваться?

конечно

Если QA, то и до этапа разработки нужно, на стадии формирования требований

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

Ну если мы под разработкой понимаем непосредственно пиление

На этапе разработке разве стоит вмешиваться?

разработчик не знает нужной бизнес-логики - обращается к QA . Не понимает как работает тот или иной функционал - обращается к QA. И т.д.

разработчик не знает нужной бизнес-логики - обращается к QA . Не понимает как работает тот или иной функционал - обращается к QA. И т.д.

Есть аналитики для этого

Есть аналитики для этого

у вас есть, ок

+1

КуА в разработке про другое

разработчик не знает нужной бизнес-логики - обращается к QA . Не понимает как работает тот или иной функционал - обращается к QA. И т.д.

У вас не было нормальных разработчиков, видимо.

и у нас есть аналитики, но куа может знать больше об особенностях реализации и взаимодействия

у вас есть, ок

Если нет аналитиков, то ПМ. QA не должен объяснять разрабу, какой должна быть фича.

Если разраб не знает как писать юниттесты - странный разраб

Да, если разработчик не знает предметку - ну это такое.

У вас не было нормальных разработчиков, видимо.

забавно, окей. Спасибо за мнение

Если разраб не знает как писать юниттесты - странный разраб

Он может и знает. Он не хочет это дело делать. И может писать хреновые юниттесты

который как бы есть, а баги пропускают

На мой взгляд, QA это весь отдел. Все обеспечивают качество. А тестировщик скорее QC, что есть часть QA

Это сейчас к чему?

На мой взгляд, QA это весь отдел. Все обеспечивают качество. А тестировщик скорее QC, что есть часть QA

Тестировщик - это тестировщик.

забавно, окей. Спасибо за мнение

Бизнес-логика формируется не только основываясь на требованиях, но и согласуясь с разработчиками, выясняя техническую специфику реализации задачи., возможные отсупления от первичной реализации. Все это проговаривается заказчикам на планировании и согласуется. А там, - сюрприз - участвуют разработчики.

Это не всегда

Бизнес-логика формируется не только основываясь на требованиях, но и согласуясь с разработчиками, выясняя техническую специфику реализации задачи., возможные отсупления от первичной реализации. Все это проговаривается заказчикам на планировании и согласуется. А там, - сюрприз - участвуют разработчики.

Т.е. вы изначально предполагаете что разработчики обязанны знать пользовательский функционал вдоль и поперёк и на этапе разработки не прибегают к помощи QA ?

Есть много команд где с бизнесом общаются аналитики

Всем привет, есть у кого пример pytest + selenium + POM ? Скиньте пожалуйста

Есть много команд где с бизнесом общаются аналитики

и есть много команд где аналитиков нет

Т.е. вы изначально предполагаете что разработчики обязанны знать пользовательский функционал вдоль и поперёк и на этапе разработки не прибегают к помощи QA ?

Есть мнение в миру, что хороший разраб не нуждается в аналитике и тестерах

и есть много команд где аналитиков нет

есть много бед на этом свете, но лучше бы все-таки разрабам быть в курсе проекта

и есть много команд где аналитиков нет

Согласен, поэтому и не пишу в ультимативной форме

Есть мнение в миру, что хороший разраб не нуждается в аналитике и тестерах

да нафига ему вообще кто-то? сиди и пиши код, действительно

наверное на начальном этапе и обращаются к QA, но так-то можно и код посмотреть и разобраться

Т.е. вы изначально предполагаете что разработчики обязанны знать пользовательский функционал вдоль и поперёк и на этапе разработки не прибегают к помощи QA ?

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

да нафига ему вообще кто-то? сиди и пиши код, действительно

Ну ерничать не надо

Ну ерничать не надо

А мне почему-то кажется, что это не шутка даже была.

наверное на начальном этапе и обращаются к QA, но так-то можно и код посмотреть и разобраться

Или спросить у своего лида

А мне почему-то кажется, что это не шутка даже была.

Всм?

Всм?

"Программист - пишет код, тестировщик - тестирует" и тд.

ERROR: S client not available

Т.е. вы изначально предполагаете что разработчики обязанны знать пользовательский функционал вдоль и поперёк и на этапе разработки не прибегают к помощи QA ?

Ок, у вас нет аналитиков, разработчики отвлекают QA от их работы уточнениями "Как то, что я пилю, должно работать?". Для вас это нормальная ситуация?

Чем в это время ПМ занимается?

"Программист - пишет код, тестировщик - тестирует" и тд.

Солнце светит. Как это относится к теме?

Ок, у вас нет аналитиков, разработчики отвлекают QA от их работы уточнениями "Как то, что я пилю, должно работать?". Для вас это нормальная ситуация?

Это в исходных требованиях до момента оценки задачи должно быть всё описано же, не?

Ок, у вас нет аналитиков, разработчики отвлекают QA от их работы уточнениями "Как то, что я пилю, должно работать?". Для вас это нормальная ситуация?

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

Чем в это время ПМ занимается?

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

Это в исходных требованиях до момента оценки задачи должно быть всё описано же, не?

Вот я к этому и веду. На личном примере: я в момент формирования требований пишу к ним замечания и указываю на узкие места, далее уже проверяю реализацию в соответствии с требованиями.

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

Т.е. если не учтен какой-то нюанс, то решение у вас принимает QA?

Ок, у вас нет аналитиков, разработчики отвлекают QA от их работы уточнениями "Как то, что я пилю, должно работать?". Для вас это нормальная ситуация?

Да, нормальная.

Т.е. если не учтен какой-то нюанс, то решение у вас принимает QA?

в каких-то моментах - конечно

если нужен продакт - зовём и резво принимаем с аргументами совместное решение

в каких-то моментах - конечно

А у QA есть прямой контакт с заказчиком? Я просто не совсем понимаю, исходя из чего QA может принимать решения по конкретной реализации

если нужен продакт - зовём и резво принимаем с аргументами совместное решение

Это у вас разрабы просто покладистые

Это у вас разрабы просто покладистые

Почему вы таки так решили?

А у QA есть прямой контакт с заказчиком? Я просто не совсем понимаю, исходя из чего QA может принимать решения по конкретной реализации

Жизненный опыт и здравый смысл )

Жизненный опыт и здравый смысл )

А ещё экспертиза, знание продукта, понимание бизнес-целей по фичам, етк-етк-етк. :)

А у QA есть прямой контакт с заказчиком? Я просто не совсем понимаю, исходя из чего QA может принимать решения по конкретной реализации

в продуктовой компании заказчики могут быть - бизнес юниты, которые хотелки формируют продакту. Тот вещает в джиру, стендапах и т.д.. Если QA достаточно знает продукт и понимает тонкости его бизнес-логики - может принимать решения.

Жизненный опыт и здравый смысл )

А потом "Но мы же хотели совсем иначе, кто так решил?"

Почему вы таки так решили?

Это была гипербола. Конечно вариантов процессов, когда решение принимает qa можно быть больше

А потом "Но мы же хотели совсем иначе, кто так решил?"

И что?

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

И что?

Мой бэкграунд говорит о том, что QA дает аргументированную оценку, но конечное решение принимает product owner. Которому может быть и немного по боку на озвученные риски, т.к. у него в голове больше информации про текущую бизнес-ситуацию

Мой бэкграунд говорит о том, что QA дает аргументированную оценку, но конечное решение принимает product owner. Которому может быть и немного по боку на озвученные риски, т.к. у него в голове больше информации про текущую бизнес-ситуацию

Мой бэкграунд говорит, что команды бывают разные. Я работал в команде, где кроме разработчиков и QA вообще никого не было - ни менеджеров, ни аналитиков. Решения принимались самостоятельно, командой.

вот мы сейчас скатываемся к ответу 42, на тему "всё разное, продукты, компании, команды"

Ну ваще, крутые!

Найс, расходимся :)

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

Если у вас разработчики или куа существуют в информационном вакууме, без понимания бизнес-целей фичи, ожиданий заказчика и прочего - очевидно, их решения могут быть неправильными. Только проблема в данном случае не в том, что кто-то этим холопам доверил что-то решать, а в том, что у людей которые делают продукт - дефицит информации.