Доброе утро, возможно кто-то сможет помочь, генерируется пустой allure репорт при связке (junit +maven + allure). Создала отдельную тему с полным описанием и pom.xml файлом http://automated-testing.info/t/generiruetsya-pustoj-allure-report-appium-junit-allure/19067 Заранее спасибо)

Бедный форум , сколько там уже таких же тем. Вы пользовались поиском по форуму, прежде чем создать этот топик?

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

Доброе утро, возможно кто-то сможет помочь, генерируется пустой allure репорт при связке (junit +maven + allure). Создала отдельную тему с полным описанием и pom.xml файлом http://automated-testing.info/t/generiruetsya-pustoj-allure-report-appium-junit-allure/19067 Заранее спасибо)

предположу, что при запуске allure serve нужно передать в него аргументом дирректорию, где находятся xml файлы с тестами но это так теория

В противном случае помощь вам будет выглядеть так: - это пробовали ? - (вы делаете свою работу, пропадаете, идёт время ) ...да, пробовал - а это? - (пауза) ...да - а это?

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

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

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

А зачем это делать через Pika, если у реббита есть свой CLI который умеет делать листинги очереди и вот это всё?

http://www.rabbitmq.com/management-cli.html

в скрипте в рамках теста проверяем что итем не умер в соответсвии в выставленым в конфиге таймаутом

необходим к сожалению данный шаг, в UI посмотреть нет возможности, вернее есть но смотреть каждыцй раз в рамках теста...

http://www.rabbitmq.com/management-cli.html

сорян я походу не внимательно прочитал, тоесть можно проще прослушать очередь к примеру из терминала\cmd через тотже парамико(речь идет об удаленной машине) правильно я понял?

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

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

спс я познакомлюсь поподробнее с доком

спс я познакомлюсь поподробнее с доком

у кролика неплохое HTTP API есть, если оно видно вам снаружи

у кролика неплохое HTTP API есть, если оно видно вам снаружи

да откртыо, сейчас взгляну.

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

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

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

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

{'error': 'Unauthorized', 'reason': '"Unauthorized"\n'}

HttpBasicAuthenticator

HttpBasicAuthenticator

спасибо

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

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

Сразу вбрасывай, без прелюдий.

Мне бы в личку поприставать. Там есть нюанс

И тут я вспомнил анекдот про Чапаева

Глаголь)

Забанют

А что, он страшней, чем про Кейнса, Ленина и кого-то там третьего?

Этот смешной анекдот гуглится по словам "анекдот про ньюанс"

Я его тоже каждый раз вспоминаю, как слышу слово "нюанс")

Идите во флудилке его спросите.

Привет всем, А может кто-то поделиться опытом планирования QA активностей в scrum, как это происходит? В частности не можем решить проблему: в начале спринта задач для QA еще нет, а в самом конце ~летят пачками. Хотели вводить код фриз за пару дней до окончания , но вопрос что после код фриза будут делать девелоперы ?

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

А в конце спринта? Если программистов не остановить то они до последнего дня будут фичи делать и мы не успеваем завалидировать

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

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

А в конце спринта? Если программистов не остановить то они до последнего дня будут фичи делать и мы не успеваем завалидировать

Эмм, а откуда они возьмут их на реализацию?

С беклога

А то, что состав спринта утвержден?

Привет всем, А может кто-то поделиться опытом планирования QA активностей в scrum, как это происходит? В частности не можем решить проблему: в начале спринта задач для QA еще нет, а в самом конце ~летят пачками. Хотели вводить код фриз за пару дней до окончания , но вопрос что после код фриза будут делать девелоперы ?

Будут фиксить баги из этого релиза/кодить на следующий релиз

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

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

Тех долг попробую пропихнуть)

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

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

Ребят, аннотация @Description для чего? объясните пожалуйста

То есть бранчевание - частая практика в скрам командах? Менеджмент говорит так нельзя , внутри спринта должны фичи делать

У нас кстати начали еще подкидывать легкие задачки, если разрабам совсем заняться нечем, условно 4 разраба, 2 из них забрали последние задачи из бэклога спринта, остальным двоим делать нечего и им скидывают из бэклога продукта какие-то мелкие доработки

То есть бранчевание - частая практика в скрам командах? Менеджмент говорит так нельзя , внутри спринта должны фичи делать

Ну все таки если что-то помогает процессу, можно рассмотреть вариативность. Но да, если принципиально нет то есть техлолг

У нас кстати начали еще подкидывать легкие задачки, если разрабам совсем заняться нечем, условно 4 разраба, 2 из них забрали последние задачи из бэклога спринта, остальным двоим делать нечего и им скидывают из бэклога продукта какие-то мелкие доработки

Вот мы так тоже хотели. Делать на след спринт

У нас в принципе оунер лояльный, мол ну не упели дотестить, давайте на след. спринт возьмем и вот уже тестировщики не простаивают в начале недели :D

Ну это пока разработка идет. А так кроме как в 2 ветках работать - хз

Наш нет) он еще может подойти в тихаря и уговаривать не тестить бэк тк на фронте "это вроде проверяли" ?

Ну мы в процессе становления процесса , ищем варианты, пока получается два: бранчи и тех долг

У нас была еще валидация девелоперами, отменили)

ERROR: S client not available

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

Времени много отберет)

У кого?

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

Так это же отлично!

А чем это поможет?

Отказываться легче?

А чем это поможет?

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

И да, накат идёт только когда все ок

Поняла )

Сокращает время обратной связи. Типа чувак пофиксил, а через полчаса ему уже фидбэк по его фиксу

Я верно понимаю, что каждая доработка на отдельном тестовом стенде?

У нас довольно быстрый фитбек тоже) что не мешает фейлить спринты

Каждый pr от каждого кодера после код ревью сливается в основную ветку и собирается билд

Т.е в день может по 10 билдов собираться. В каждом 1 тикет зарезолвлен

Хм, у нас так же тогда, да

Просто я сначала подумал иначе, у нас было примерно так. Есть 2 дев стенда, одну доработку заливают на дев1, другую на дев2, и типа каждая тестируется отдельно. Офк у нас случилась фигня т.к. 2 функциональных и 0 интеграционных.

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

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

Ну т.е скрам - это про небольшие команды, когда кодят и тестят непрерывно. А схема «они кодят весь спринт, а у нас времени протестить нет» - это не скрам :)

То есть бранчевание - частая практика в скрам командах? Менеджмент говорит так нельзя , внутри спринта должны фичи делать

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

Времени много отберет)

если у вас веб продукт - вы можете придти к тому, чтобы фронтенд и бекенд задачи релизить пофично - (если это не таски какой-то конкретной юзерстори, которые требуют связности). Зачем пользователям например ждать фичи 2 недели, когда она может выйти и радовать всех уже сегодня? Пофичный релиз не требует полной регрессии, если ты оцениваешь масштаб переделок (тут помогает белый ящик и общая оценка рисков + комментарии от разработчиков насчет фронта работ + смоук тесты и регрессия на автотестах).

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

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

есть нетленка, наберите в Youtube *уяк *уяк и в продакшн - там все четко и по делу

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

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

если у вас веб продукт - вы можете придти к тому, чтобы фронтенд и бекенд задачи релизить пофично - (если это не таски какой-то конкретной юзерстори, которые требуют связности). Зачем пользователям например ждать фичи 2 недели, когда она может выйти и радовать всех уже сегодня? Пофичный релиз не требует полной регрессии, если ты оцениваешь масштаб переделок (тут помогает белый ящик и общая оценка рисков + комментарии от разработчиков насчет фронта работ + смоук тесты и регрессия на автотестах).

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

Было интересно как же делают скрам не наркоманы