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

а зачем кружка без чая?

вообще конечно чай без кружки крайне сомнителен

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

??

Чот ржу)

чай еще разный бывает - заваренный или нет

В смысле "важнее"?

что не понятно в этом слове?)

мало ли какой продукт они делают

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

это конечно такой себе пример, но пример

а вообще важно всё, тут надо смотреть статистику людей кто софт вашей компании юзает на мобилках и на каких

если еще не релизнулись, то просто статистику))

дельное дело говоришь

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

В любом случае, при любом примере важно учитывать оба параметра. Хоть они связаны между собой, но это всё равно 2 разных параметра.

Нельзя ставить приоритеты и смотреть только на один из них.

нельзя ставить где? на бумаге? на практике даже на один из этих параметров часто кладут)

не то что оба

То же самое, что посчитать производительность устройства, основываясь только на "камне", и не учитывать оперативку и ОС.

нельзя ставить где? на бумаге? на практике даже на один из этих параметров часто кладут)

А это уже "Допустимые упущения"=))

кто идет?

https://elegion.timepad.ru/event/573432/

На заметку=)

ЗНИ - запрос На Изменение ПМИ - Программа и Методика Испытаний

Кто как проверяет наличие элемента на странице (selenium webdriver)? Например, после проведения платежа убедиться, что на странице отобразились нужные результаты. Я делаю через исключение NoSuchElementException (проверяю, например, что на странице присутствует текст Платеж проведен успешно)

Смотря из чего состоит страница после успешной\неуспешной оплаты.

не очень понятен вопрос. у элемента есть свойство isDisplayed, но оно упадет, если элемента не будет, так что надо оборачивать, да.

при желании можно wait.until(ExpectedConditions.elementToBeClickable(

не очень понятен вопрос. у элемента есть свойство isDisplayed, но оно упадет, если элемента не будет, так что надо оборачивать, да.

Так а разве смысл не в том чтобы он падал ?

Когда его нет

Через assert это же никак не проверишь?

Так а разве смысл не в том чтобы он падал ?

В идеале не падать, а вернуть false

Что такое падать ?

вернуть Exception

Он жк всегдв тау делает ?

Да, поэтому приходится оборачивать в try-catch

ну либо обрабатывать выше падение метода

Есть вариант проверять количество элементов на странице, типа если элементов 0, то ассерт не проходит. Такой вариант приемлемый?

тоже приемлемый, кстати. Лучше тем, что не надо ловить Exception

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

кто-нить из тестировщиков в ПМы переходил? стоит ли оно того?) или куда расти лучше?

Это довольно распространенный путь "развития", хотя развитием это сложно назвать.

Стоит или нет - зависит от того, что хотите получить в итоге.

Не могу подтвердить это статистикой, но по ощущениям у нас вертикальный рост гораздо выгодней горизонтального

Отсюда вывод, что путь QA -> PM -> CIO самый выгодный

но вообще холиварная тема

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

А с чего вы взяли, что QA -> PM это вертикальный рост, вообще?

Большинство ПМов получают меньше денег, чем разработчики, которыми они руководят, например.

Большинство ПМов получают меньше денег, чем разработчики, которыми они руководят, например.

А гемора больше

Йеп.

Меньше чем разрабы но больше чем тестировщики

Меньше чем разрабы но больше чем тестировщики

Зависит от тестировщиков.

Зависит от тестировщиков.

Именно

Зависит от тестировщиков.

Зависит от разработчиков. И зависит от ПМов

я сам из Киева и что бы тестировщик ( пофиг автоматизатор или не) получал больше 2.5к это фантастика

И много таких проектов, где тестеры получают больше девелоперов?

Ну, окей. По моей скудной выборке - вакансию QA на 170net в Питере найти проще, чем вакансию PM.

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

Скиллов и решаемых задач, простите.

Более выгодным, в плане бабла, выглядит позиция PM\PO, но тут надо понимать, что помимо менеджмента на тебя ложится ещё и всё продуктовое направление, маркетинг и прочий буллшит. И за +15% к зарплате ты получаешь троекратное увеличение зоны ответственности и объемов задач.

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

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

Будь ты хоть самым элитным тестером, дева ты не переплюнешь по зп

Но как ни крути, зарплатный потолок у QA ниже)

получается нужно в бизнес идти)

получается нужно в бизнес идти)

Да.

открывать уже свою аутсорс компанию)

Тестер никогда не переплюнет хозяина пяти шаурмичных по доходу.

Но как ни крути, зарплатный потолок у QA ниже)

Чем у project manager? Нет. Зарплатный потолок у QA выше. Причем значительно.

вы меня опять в депрессию вогнали

Вертикальный рост это QA -> Team Lead -> Head of QA -> CIO

Чем у project manager? Нет. Зарплатный потолок у QA выше. Причем значительно.

Пм может получать 4к а тестер нет

Пм может получать 4к а тестер нет

тестер нет, а QA Engineer может

Вертикальный рост это QA -> Team Lead -> Head of QA -> CIO

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

QA -> PM это горизонтальный рост, потому что с точки зрения иерархии на одном уровне

вы меня опять в депрессию вогнали

Жизнь - боль

https://jobs.dou.ua/salaries/

Ну, на украине весь мир не заканчивается, так-то.

это не зависит от страны

А где иная динамика в статистике?

это реальный опрос проводится

когда вы доберётесь до потолка (3-4k$), что будете делать?)

когда вы доберётесь до потолка (3-4k$), что будете делать?)

ну, многим этого достаточно

когда вы доберётесь до потолка (3-4k$), что будете делать?)

Это у кого такой потолок то?

Ребят, вы бы шли в вакансии и аналитику с этим, а?

Через assert это же никак не проверишь?

проверить

проверить

Подробности в студию

Ребят, вы бы шли в вакансии и аналитику с этим, а?

Направления профессионального развития разве не сюда? Да и чат с вакансиями, кмк, узковат для обсуждения рынка труда.

Подробности в студию

написать метод который возвращет true/false в зависимости от того отображается ли элемент для этого использовать метод webelement'a is_displayed оборачивать его в try /catch в catch ловить NoSuchElementException или вообще любой WebDriverException и возвращать в этом случае false иначе true ну и соотвественно делать в итоге assert element.is_displayed()

Направления профессионального развития разве не сюда? Да и чат с вакансиями, кмк, узковат для обсуждения рынка труда.

Не сюда - это обсуждение зарплат. И если чат про аналитику рынка труда узковат, то в проф чате этому точно не место.

кто-нить из тестировщиков в ПМы переходил? стоит ли оно того?) или куда расти лучше?

Чтобы дров не наломать при переходе из QA в PM, надо подумать не только о ЗП. Надо разобраться, что у вас в компании входит в обязанности PM-а. Что из этого ты умеешь делать, что нет. Есть ли у кого более опытного поучиться. Какое взаимодействие с заказчиками (если это аутсорс), есть ли уже опыт общения с ними. Ну и нужно готовиться прокачивать свои коммуникационные скилы, технические уйдут на второй план. Готовься к тому, что начнешь бояться находить баги =)

Не сюда - это обсуждение зарплат. И если чат про аналитику рынка труда узковат, то в проф чате этому точно не место.

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

Не сюда - это обсуждение зарплат. И если чат про аналитику рынка труда узковат, то в проф чате этому точно не место.

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

написать метод который возвращет true/false в зависимости от того отображается ли элемент для этого использовать метод webelement'a is_displayed оборачивать его в try /catch в catch ловить NoSuchElementException или вообще любой WebDriverException и возвращать в этом случае false иначе true ну и соотвественно делать в итоге assert element.is_displayed()

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