С английским все норм)

нет она в 2017 вышла

А я и думаю, почему я про нее раньше не слышал?))

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

об этом устройстве> Настройки доверия сертификатов > Поставить галочку сертификату

Версия ос то хоть какая?

9

Скажите, плз, может ли где-то в тестировании пригодиться ipad mini 1024x768?

Ага, книжки можно читать

9

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

Всем привет! Хочу предложитть подработку. Есть сайт для видео-конференц связи. Платформа для проведения вебинаров. Собственно его и нужно автоматизировать. Используем Selenium + Java + Selenide. Автотесты только начали внедрять. Архитектуру примерную сделали. Описаны страницы регистрации и входа в платформу. Остальное с нуля надо описывать.

для этого есть другая группа @qa_jobs

оу

Спасибо

Но там, как я понял на полную занятость

Укажите частичную занятость и остальное по правилам заполнения. Не вижу проблемы

Ок. Всем спасибо. Сорян, за вброс :)

@RichardGears тут похоже тоже надо вжухнуть

ВЖУХ!

Спасибо. А на русский язык ее ещё никто не перевёл?

Она прямо на столько шикарна? В амазоне один отзыв на две звезды из серии "автор водолей"

Спасибо

Всем привет! Поделитесь опытом, кто из участников чата практиковал парное тестирование? Какие плюсы и минусы вы выявили в процессе? Получили ли профит от данного метода? Если да, то какой? И какие ожидания от данного подхода у вас были изначально? Сам пробовал подобное решение в паре с разработчиками во второй итерации тестирования, чтобы сразу большинство своих сценариев рассказать разработчику, услышать его мнение, узнать технические особенности реализации при отступлении от первоначальной постановки (если они были). Потому что был пул задач, тестирование которых было размазано на три итерации, что является непозволительной роскошью. Было бы интересно послушать про ваш опыт, и возможно, позаимствовать что-то в свою практику.

Всем привет! Поделитесь опытом, кто из участников чата практиковал парное тестирование? Какие плюсы и минусы вы выявили в процессе? Получили ли профит от данного метода? Если да, то какой? И какие ожидания от данного подхода у вас были изначально? Сам пробовал подобное решение в паре с разработчиками во второй итерации тестирования, чтобы сразу большинство своих сценариев рассказать разработчику, услышать его мнение, узнать технические особенности реализации при отступлении от первоначальной постановки (если они были). Потому что был пул задач, тестирование которых было размазано на три итерации, что является непозволительной роскошью. Было бы интересно послушать про ваш опыт, и возможно, позаимствовать что-то в свою практику.

У нас был вечер до несдвигаемого релиза и мы выкручивались как могли. Помогло.

У нас был вечер до несдвигаемого релиза и мы выкручивались как могли. Помогло.

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

А никто и не смеялся. Ты спросил использовали ли и какие были профиты. я ответил.

А никто и не смеялся. Ты спросил использовали ли и какие были профиты. я ответил.

А с кем в паре? С другими тестировщиками, разработчиками? Да и ты сказал о причине, вероятно, а не о результате и преимуществах данного (были ли они?) подхода. Хочется узнать, стоит ли практиковать данный метод тестирования? Возможно, что вывод посредственный, но напрашивается следующий: парное тестирование даёт профит перед жестким дедлайном, когда вокруг огонь и пламень.

Не вижу сценариев, в котором парное тестирование дает профит для результата и скорости тестирования. Для шаринга знаний - возможно.

В остальном случае проще, имхо, параллелить процессы.

А с кем в паре? С другими тестировщиками, разработчиками? Да и ты сказал о причине, вероятно, а не о результате и преимуществах данного (были ли они?) подхода. Хочется узнать, стоит ли практиковать данный метод тестирования? Возможно, что вывод посредственный, но напрашивается следующий: парное тестирование даёт профит перед жестким дедлайном, когда вокруг огонь и пламень.

С разработчиком. Нас тогда тое было. Три тестера и три разраба сели по парам. СЭкономили уйму времени. Но там уже разработка была завешена. С точки зрения бизнеса это не самый оправданный метод. Соответственно, на входе были условия: полное отсутствие документации, отсутствие времени на тестирование и длинная ночь.

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

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

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

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

Даже в случае форс мажоров не очень понимаю, как это должно помочь.

Ну, если ты уже ввиду изложенного не понимаешь, то забей - это не твоё.

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

Вполне резонный довод, кстати. Осталось только жир, всмысле сарказм, с монитора стереть. :)

Ну, если ты уже ввиду изложенного не понимаешь, то забей - это не твоё.

Ну, я правда не понимаю, чем тестирование парами в описанной тобой ситуации эффективнее, чем параллельное тестирование силами разработчика и тестировщика по отдельности. Поделись мудростью.

Вполне резонный довод, кстати. Осталось только жир, всмысле сарказм, с монитора стереть. :)

хорошая метрика оценки работы программиста - количество завершенных фичей по DoD. Её часто путают с % времени в течении которого программист программировал.

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

Вру конечно, кто ж ему разрешит меньше программировать.

Нет времени думать, кодируй довай!

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

Это, кстати, не значит, что не стоит привлекать совсем. Это значит только, что это действительно дороже.

Это верно, если активность А является боттленком системы.

И неверно, если не является

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

Это верно, если активность А является боттленком системы.

Независимо от боттлнека, у каждой активности есть условная рыночная стоимость, за которую можно взять человека, способного это делать. От наличия боттлнека условный cost не меняется, меняется только value от его устранения. В тот момент когда value переваливает за cost - будь ты хоть HIPPO -> время тестировать. До тех пор, пока не переваливает -> это действительно не твоя работа и лучше заниматься тем, в чем у тебя эксклюзивная экспертиза.

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

Аналогом на производящем предприятии была бы идея например, загружать на 100% самый дорогостоящий станок в цепочке ("ну мы же столько денег за него выложили"), вместо того, который регулируют пропускную способность всей системы

Аналогом на производящем предприятии была бы идея например, загружать на 100% самый дорогостоящий станок в цепочке ("ну мы же столько денег за него выложили"), вместо того, который регулируют пропускную способность всей системы

И в приведенной тобой аналогии cost не меняется ни у первого, ни у второго. Меняется только value, т.е. итоговая эффективность будет больше, если повысить пропускную способность системы.

Как это противоречит тому, что я сказал?

И в приведенной тобой аналогии cost не меняется ни у первого, ни у второго. Меняется только value, т.е. итоговая эффективность будет больше, если повысить пропускную способность системы.

А как меняется cost от того что программист не программирует?

А как меняется cost от того что программист не программирует?

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

> Таким образом, что в момент, когда человек с зарплатой программиста тестирует, он выполняет более дешевую, в рамках рынка, функцию, за кост более дорогой. О_о. Бессмысленная фраза. Более дешовую функцию за более дорогой кост?! Это из какого курса экономики, я его пропустил.

Кост у процесса разработки каждый месяц примерно постоянный - сумма всех зарплат, плюс расходы на аренду, маркетинг и железо.

Это из курса экономики, где ты платишь 200++к разработчику, а потом сажаешь его гнать руками регрессию, которую может делать жуниор тестировщик за 40.

Примерно где-то из той реальности.

Ну мы разные курсы проходили, в моём курсе, если 5 программистов стоят 200к каждый, а один тестировщик 50к, то в месяц на всех уходит 1.050.000 вне зависимости от того, что они делают.

А если я найму еще одного тестировщика за 50к, чтобы тот программист свои драгоценный Ци не тратил, то расходы неожиданно станут 1.100.000, то есть вовсе не уменьшатся

И получают они 200к и 50к соответственно, тоже независимо от того, что они делают, да? :)

ну у нас да, люди получают обговоренную зарплату независимо от того, что они делают

ERROR: S client not available

кек.

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

это какая страна? кошмар какой-то))

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

Но кажется с третьего раза тоже не получится донести это предельно простую мысль.

большинство моих знакомых получают на счёт 1-2 раза в месяц, не за экспертизу или что они что-то могут, а за то, что они заключили договор найма с такими условиями :)

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

просто мысль слишком простая и неправильная

поуправлял бы заводиками, понял бы наверное)

Настолько неправильная, что вместо каких-то аргументов ты свалился в пустую софистику про трудовые договоры, ага. :)

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

Настолько неправильная, что вместо каких-то аргументов ты свалился в пустую софистику про трудовые договоры, ага. :)

Ты не смог прочитать и осилить аргументы

Ты не смог прочитать и осилить аргументы

Ага, зато ты смог, как я вижу. :) Даже до "сперва добейся" аргументов дошло.

Это не про добейся, это про то, что ты не знаком с простой теорией производства.

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

Без набросов, даааа)))

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

При чём тут цена часа рабочего времени? Это снова к вопросу о понимании процесса (не технологического) производства.

Цена станков - разная

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

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

Совершенно непричем.

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

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

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

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

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

И если бы ты читал, что тебе пишут, а не размазывал по чатику аргументы про то, что неплохо бы кому-то кроме тебя поруководить заводами, ты бы увидел, что я черным по белому написал: Для получения максимальной прибыли в short time перспективе может быть более выгодно использовать более дорогие ресурсы для выполнения более дешевых активностей. В долгосрочной перспективе выгоднее снимать боттлнек по минимальной стоимости, т.е. в нашем случае - привлекать к тестированию тех, кто стоит дешевле.

Разработчики на одном месте работы больше уделяют времени на описание того, что сделали в тикете, с описанием и советами по узким местам. Они не должны это делать потому что дорогие? Смотрите -ка, облегчают работу тестированию