Вот смотрите 2 человека с id. А основная масса пилит без id )))))

так как если например кнопка ОК или Cancel (то есть типовая) то лучше класс

Вот смотрите 2 человека с id. А основная масса пилит без id )))))

это не показатель

Кто тут из вк?

Логично же, нельзя привязать почту к андефайнд.

vk.cc/help? )

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

советую ферму для устройств

uber testers проде были.

из пожеланий, устройства не ниже IOS 9 и Android 5, по андроиду, критично чтобы RAM быо не ниже 2гб (можно и меньше но не ниже 1.5)

https://aws.amazon.com/ru/device-farm/

Спасибо огромное!)

пожалуйста ) вот еще обзор https://habrahabr.ru/company/microsoft/blog/333606/

пожалуйста ) вот еще обзор https://habrahabr.ru/company/microsoft/blog/333606/

И, совершенно неожиданно, статья от Майкрософта и разработчика Ксамарина рекомендует ксамариновую ферму.

Кто бы мог подумать. :)

каждый выбирает для себя

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

всем привет) видели новый фейс джиры? как вам?

всем привет) видели новый фейс джиры? как вам?

друг скрин просит

А что там с ней

она поменяяяялась) я щас зашла и обалдела)

всем привет) видели новый фейс джиры? как вам?

ну новый он уже больше месяца(даже наверное больше).. а так ничего, лучше чем был, и меньше глюков стало

Так скрины то будут или где?

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

Внешний вид не очень)

bitbucket напоминает теперь

напоминает tfs

джира кстате за последние 3 месяца поменялась 3 раза )))

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

bitbucket напоминает теперь

или любой другой продукт atlassian ?‍♂️

когда вы проверяете баг чей-то вы проверяете что он воспроизводится на прошлой(версии с багом) сборке, или сразу смотрите что на свежей нет бага?

когда вы проверяете баг чей-то вы проверяете что он воспроизводится на прошлой(версии с багом) сборке, или сразу смотрите что на свежей нет бага?

если все понятно, то сразу на свежей

когда вы проверяете баг чей-то вы проверяете что он воспроизводится на прошлой(версии с багом) сборке, или сразу смотрите что на свежей нет бага?

а зачем проверять на старой сборке?

когда вы проверяете баг чей-то вы проверяете что он воспроизводится на прошлой(версии с багом) сборке, или сразу смотрите что на свежей нет бага?

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

бывает проверяю, точно ли по этим шагам воспроизводится

а зачем проверять на старой сборке?

если на самом деле бага в коде нет, а есть баг в кривых руках админов.

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

или просто "о, новый чужой баг, дай поставлю версию старую, проверю как он вообще, баг ли?"

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

Вавилон какой-то

а нормально описывать баги? а подойти к автору и спросить что имелось в виду? не?

Ну, у нас есть практика во время регрессионных прогонов проверять на предыдущих версиях.

Что бы понимать, привнесенный это баг или нет.

или просто "о, новый чужой баг, дай поставлю версию старую, проверю как он вообще, баг ли?"

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

а нормально описывать баги? а подойти к автору и спросить что имелось в виду? не?

Иногда люди увольняются и спросить не получается

Ну, у нас есть практика во время регрессионных прогонов проверять на предыдущих версиях.

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

а нормально описывать баги? а подойти к автору и спросить что имелось в виду? не?

Это обычно когда чужие баги, или не спросить

Это обычно когда чужие баги, или не спросить

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

Можно) но иногда проще проверить на двух деваисах рядом

И разрабы не всегда доступны

Несколько раз ловили, когда у разраба все отлично(на эмуле), а на девайсе - реопатся

Количество фраз "иногда" в аргументах смущает.

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

Но стоит учитывать эти факторы

Несколько раз ловили, когда у разраба все отлично(на эмуле), а на девайсе - реопатся

какая неожиданность, не так ли? только я не понимаю, как это относится к плохо описанным багам

Это было к

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

какая неожиданность, не так ли? только я не понимаю, как это относится к плохо описанным багам

Да чаще всего это связанно именно с такими ситуациями

Когда баг описан не полностью

Это было к

в этой логической цепочке пропущено звено, где никто не понимает, о чем речь в баге

Разраб не смог у себя воспроизвести и закрыл, ничего не правя, в таком случае он не подскажет.

Это немного другая ситуация

Я о накладке разных факторов, когда и спросить не получается, и надо понять когда появилось. Или с чего вдруг вылезло. Поэтому лезем в прошлые сборки

ERROR: S client not available

Разраб не смог у себя воспроизвести и закрыл, ничего не правя, в таком случае он не подскажет.

но это сколько сэкономленного времени на поиске чужого миража!

Deprecated. The RC interface will be removed in Selenium 3.0. Please migrate to using WebDriver.

А чё тут спорить о том кто пишет юнит тесты? есть скиллы - пишешь юнит тесты, нет скиллов - не пишешь. Чего ждать разрабов, пока они разрадятся? Если у них нет культуры такой, то и не будет тестов

Написал ты юниты, а разрабы их не пользуют - переделали они метод, твои юниты - красные. И кому они теперь нужны ? А может они действительно переделали метод Потому что так надо ? просто "начать писать тесты" - это еще не все. Нужно что бы эти тесты еще и использовались. А это уже Процесс.

А чё тут спорить о том кто пишет юнит тесты? есть скиллы - пишешь юнит тесты, нет скиллов - не пишешь. Чего ждать разрабов, пока они разрадятся? Если у них нет культуры такой, то и не будет тестов

ты вообще то тестировать должен, а не юнит тесты писать

Ну я подразумеваю что тесты юнит уже включены в CI процесс, а покраснел - сборки нет. Разработчик поправит тест

ты вообще то тестировать должен, а не юнит тесты писать

А юнит тесты не тестируют?

это инструмент для разработки в основном

А юнит тесты не тестируют?

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

Я очень многое вынес на юниты, Профит каждый день

тестировщик, который пишет юнит тесты - это как то неправильно, чтоли:D

но в принципе,почему бы и нет?

Помоему это зависит от компании и процессов )

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

другое дело, что может быть речь идет "выносить автотесты на уровень юнит тестов" - это уже другое

Я не вижу чужеродности, потому что это выгода имхо стопроцентная

юнит тесты - часть процесса разработки кода, разве нет?

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

мне кажется это из-за ограниченности мышления каждого конкретного человека-тестировщика

юнит тесты - часть процесса разработки кода, разве нет?

необязательно: хотя нет, нифига не верное утверждение

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

Ну пока e2e человек будет писать сутки один тест, я сделаю сотню тестов и проверок

TDD никто не отменял, можно написать сначала юнит-тесты, потом код, в этом случае тестеровщику у которого есть такой скилл все дороги открыты

точнее не так

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

Господи, опять? :/

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

Господи, опять? :/

Снова)

в интернете кто то не прав

если тестировщик может писать юнит тесты - это хорошо!

Да я не говорю что обязан

Просто если есть возможность - можно делать. имхо я делаю по своей воле ТК увидел какие выгоды это мне приносит