А зачем обновлять то, что и так отлично работает?

На 10.9 уже нет актуальных версий браузеров, на 10.10 только хром

Не имея целью разжечь. Чем руководствуются пользователи macOS на данный момент уже не поддерживаемых активно версий (10.10 и т.п.), когда отказываются от обновлений операционки? Если здесь такие присутствуют

у коллеги древний air с 4 гигами памяти, он его вообще не обновляет. отказался от новой прошки с 8 гигами. говорит, что на его машине лучше нужный ему для разработки софт работает. его личное имхо.

Добрый вечер! Подскажите, где размещать вакансию? Прям тут можно, есть правила?)

В описании группы ссылки

В описании группы ссылки

Спасибо огромное) почему-то пропустила.

Не имея целью разжечь. Чем руководствуются пользователи macOS на данный момент уже не поддерживаемых активно версий (10.10 и т.п.), когда отказываются от обновлений операционки? Если здесь такие присутствуют

Потому что можно нарваться на панику ядра/неработающее приложение (ide), глюкнувшую версию языка и прочие прелести. У меня коллеги напарывались так, потом обновлялись только после отзывов

@pipirupipipipipipirupi rupi

Не имея целью разжечь. Чем руководствуются пользователи macOS на данный момент уже не поддерживаемых активно версий (10.10 и т.п.), когда отказываются от обновлений операционки? Если здесь такие присутствуют

У кого-то старые компы, которые не могут обновиться, У кого-то старые компы, которые они не хотят обновлять из-за смены GUI (лампово там например) или нежеланием тсолкнуться с проблемами несовместимости(небходимости донастройки) софта

Не имея целью разжечь. Чем руководствуются пользователи macOS на данный момент уже не поддерживаемых активно версий (10.10 и т.п.), когда отказываются от обновлений операционки? Если здесь такие присутствуют

Отвечу за "не пользователя macOS": начиная с win 2000 - не ставлю себе новую операционку раньше, чем на неё выйдет 4-й сервиспак. А так как работаю тестером (и хорошо знаком с сырыми и "свежими" продуктами) - не особо стремлюсь к новому. Багов и на работе хватает. И знаете - этот мой принцип уберег меня уже от огромного количества "разочарований" :)

т.е. ты win 7 и далее не будешь никогда использовать?

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

т.е. ты win 7 и далее не будешь никогда использовать?

:) Свои правила устанавливаю только я сам, и только для себя :) Поэтому на Win 7 я сейчас и сижу. Дальше - пока не стремлюсь :)

:) Свои правила устанавливаю только я сам, и только для себя :) Поэтому на Win 7 я сейчас и сижу. Дальше - пока не стремлюсь :)

но у win 7 же sp3 это финальный был? Как ты на ней сидишь?

Как-то вы рано остановились в развитии.

Как-то вы рано остановились в развитии.

Ну если смена используемой ОС - это "развитие", то да! Я "остановился в развитии" :)

но у win 7 же sp3 это финальный был? Как ты на ней сидишь?

вот на ней и сижу :) К счастью - win8 успешно пропустил! :) Да и с win 10 - тоже торопиться не собираюсь :)

вот на ней и сижу :) К счастью - win8 успешно пропустил! :) Да и с win 10 - тоже торопиться не собираюсь :)

"не ставлю себе новую операционку раньше, чем на неё выйдет 4-й сервиспак."© На win 7 нет sp4. Почему вы на ней?

Идите во флуд.

Идите во флуд.

Приношу извинения. Флуд с моей стороны завершен.

всем привет! пишу автотесты на джаве, использую фреймворк cucumber, для отчетности используем allure. появилась задача в отчетах скипать упавшие тесты, на которые уже заведены баги в джире, и привязывать ссылку на багтрекер. может кто подсказать с какой стороны подступиться? на уровне огурца я возможности менять статусы тестов не нашел. для отчета в аллюр используется cucumber-jvm-adapter, в котором есть AllureReporter, который если я правильно понял подключается как плагин для maven-surefire-plugin, была идея пересобрать по своему этот адаптер с нужной логикой, и как-то подсунуть в surefire.

всем привет! пишу автотесты на джаве, использую фреймворк cucumber, для отчетности используем allure. появилась задача в отчетах скипать упавшие тесты, на которые уже заведены баги в джире, и привязывать ссылку на багтрекер. может кто подсказать с какой стороны подступиться? на уровне огурца я возможности менять статусы тестов не нашел. для отчета в аллюр используется cucumber-jvm-adapter, в котором есть AllureReporter, который если я правильно понял подключается как плагин для maven-surefire-plugin, была идея пересобрать по своему этот адаптер с нужной логикой, и как-то подсунуть в surefire.

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

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

спасибо =)

может и не автозаведение :)

может и не автозаведение :)

ну из той же серии

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

на своем опыте для этого придется несколько перепилить хммм все)

ну автозаведение пока еще только в планах, но полагаю можно будет логику в том же адаптере реализовать

Осталось только ответить на вопрос "Зачем?", но это совсем другая история.

Даёшь автофикс бага!

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

Идеальный вариант это разбить тесты на степы. Почему я заговорил об автозаведении, потому что это та же самая задача по сути. То есть в случае падения запоминаем степ, запоминаем ошибку, генерируем некоторую структуру из этих данных. Затем начинаем искать в жире эту структуру, если не находим, то считаем что бага нет и заводим новый, в котором сразу описываем все шаги автотеста, а в специальную "неизменяемую" секцию записываем нашу структуру с упавшим степом и ошибкой )можно трейс, часть трейса, сам эксепшн). Далее если тест упадет еще раз в том же месте, то он уже найдет такой трейс в подобной секции и уже не будет заводить новый

Идеальный вариант это разбить тесты на степы. Почему я заговорил об автозаведении, потому что это та же самая задача по сути. То есть в случае падения запоминаем степ, запоминаем ошибку, генерируем некоторую структуру из этих данных. Затем начинаем искать в жире эту структуру, если не находим, то считаем что бага нет и заводим новый, в котором сразу описываем все шаги автотеста, а в специальную "неизменяемую" секцию записываем нашу структуру с упавшим степом и ошибкой )можно трейс, часть трейса, сам эксепшн). Далее если тест упадет еще раз в том же месте, то он уже найдет такой трейс в подобной секции и уже не будет заводить новый

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

Даёшь автофикс бага!

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

Осталось только ответить на вопрос "Зачем?", но это совсем другая история.

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

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

Анализировать все баги, это конечно мощно)

И опять же вы проставите как skipped и прогон у вас будет зеленый?

имхо это плохая практика

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

Нет, я не спрашивал "зачем линковать падения к багам", я, скорее, спрашивал на кой хрен городить отдельный велосипед, который тоже надо поддерживать и багфиксить, ради экономии на спичках. Но, вопрос, конечно, был риторический. Я и так знаю зачем.

Нет, я не спрашивал "зачем линковать падения к багам", я, скорее, спрашивал на кой хрен городить отдельный велосипед, который тоже надо поддерживать и багфиксить, ради экономии на спичках. Но, вопрос, конечно, был риторический. Я и так знаю зачем.

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

И опять же вы проставите как skipped и прогон у вас будет зеленый?

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

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

Есть SPA приложение, отдельно папка с проектом для фронта, отдельно папка с солюшеном для бекенда. Бекенд на .NET. Нужно добавить тесты ui на c#, как правильно это сделать? Добавлять Class library проект с существующему солюшену или делать отдельный солюшн под тесты?

потом тесты нужно будет на тимсити гонять

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

Это репортпортал умеет насколько я знаю.

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

Как запустить один и тот же тест в нескольких браузерах одновременно??Хотела попробовать использовать Parametrized .class,но у меня получается только с цифрами.Может как то с помощью xml??Если можно поделитесь пожалуйста примерчиком,ссылкой на него

Как запустить один и тот же тест в нескольких браузерах одновременно??Хотела попробовать использовать Parametrized .class,но у меня получается только с цифрами.Может как то с помощью xml??Если можно поделитесь пожалуйста примерчиком,ссылкой на него

https://learn.techbeacon.com/units/how-use-testng-parallel-test-execution это фреймворк который поможет запустить тесты параллельно https://habr.com/post/327184/ это замена привычному серваку на селениуме, используя докер. http://testng.org/doc/maven.html это зависимости для сборщика, если юзаете джаву. https://maven.apache.org/surefire/maven-surefire-plugin/examples/testng.html это зависимость для запуска сюитов формате xml. Это все поможет запустить кучу браузеров в параллельном режиме, удачи

Копайте инфу, дружище

Как запустить один и тот же тест в нескольких браузерах одновременно??Хотела попробовать использовать Parametrized .class,но у меня получается только с цифрами.Может как то с помощью xml??Если можно поделитесь пожалуйста примерчиком,ссылкой на него

Могу пример xml файла написать, если это все юзаетете

Привет, кто сталкивался с мануал тестированием веб приложений на ios, Chrome и Safari часто работают по разному? Просто по сути, там же один движок, эпл запрещает что-то ещё использовать емнип

В mobile web зачастую можно обойтись mobile режимом в хроме

Привет, кто сталкивался с мануал тестированием веб приложений на ios, Chrome и Safari часто работают по разному? Просто по сути, там же один движок, эпл запрещает что-то ещё использовать емнип

Иногда верстка ломается, но ничего критичного не было

В mobile web зачастую можно обойтись mobile режимом в хроме

ээх, было бы всё так просто

Привет, кто сталкивался с мануал тестированием веб приложений на ios, Chrome и Safari часто работают по разному? Просто по сути, там же один движок, эпл запрещает что-то ещё использовать емнип

я чуть, там какая-то специфика реализаций, гонять придётся и там и там, в чём вопрос то?

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

И не очень понятно, много ли багов в таком случае будет пропущено

А по юзерам статка есть?

как-то тестировал на iOS как раз и в Safari, и в Chrome баги идентичны были. сходу даже не припомню, кажется был один баг за 8 месяцев только в Chrome, да и тот был также и в macOS.