да я уже вижу - "зачем если уже есть" "в чем отличие от существующего" - в этом и весь наш менталитет - не поддержать а обосрать

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

да я уже вижу - "зачем если уже есть" "в чем отличие от существующего" - в этом и весь наш менталитет - не поддержать а обосрать

Надеюсь ты не серьёзно. Пользоваться то всёравно будут те, у кого есть ценность в этом конкретном решении. Вот и интересно сразу узнать про плюсоминусы.

да я уже вижу - "зачем если уже есть" "в чем отличие от существующего" - в этом и весь наш менталитет - не поддержать а обосрать

Никто не обсирает

Но это логичные вопросы

В бете будет следующий функционал: управление кейсами и группами кейсов, составление тест планов, визард для ручного прогона тестов

Дальше в роадмэпе: майлстоуны, тестовая документация, API, интеграция с внешними системами (JIRA/Trello/Gihub/Slack...)

да я уже вижу - "зачем если уже есть" "в чем отличие от существующего" - в этом и весь наш менталитет - не поддержать а обосрать

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

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

нет не вижу

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

нет не вижу

соболезную

да что ж такое...

https://qase.io

По скринам выглядит очень красиво. Напихайте туда всяких апишечек.

Спасибо! API будет обязательно

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

Не уверен, поэтому и пришёл сюда :)

За фидбэком

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

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

Плюс вы хотите каким-то образом (судя, опять же, по скриншоту) мерить время выполнения сценария, хотелось бы узнать как.

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

Интересно, спасибо! Измерять пока что простым методом "в лоб": в визарде открыли кейс", записали время. Закрыли кейс (зафейлили, пропустили или апрувнули). Посчитали разницу.

Интересно, спасибо! Измерять пока что простым методом "в лоб": в визарде открыли кейс", записали время. Закрыли кейс (зафейлили, пропустили или апрувнули). Посчитали разницу.

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

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

Для пропущенных (skipped) кейсов время не учитывается

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

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

Пока что да

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

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

Спасибо за фидбэк. Попробую подумать, как можно решить эту проблему.

прошел по ссылке

запросил бету

ничего не получил

опечален

Инвайты начну рассылать немного позже

f

а

жду)

спасибо)

Ещё не весь функционал готов :)

Ну ждем ждем, интересно как это все будет работать)

спасибо :)

вопрос по функционалу сайта

кнопка home будет куда-то в процессе выводить в другое место?

просто ссылка на главную)

их две

Есть тут люди использующие telerik testing framework? Который бесплатный, без студии.

Коллеги, добрый день. На очередном этапе борьбы с автоматизацией мобильного приложения с appium+pytest столкнулся с собственным желанием вырвать захордкоженный ай-ди телефона и заодно сделать паралельные тесты в случае, когда подключённых девайсов больше одного. (xdist прикручен) Моё решение выглядит как баш скрипт, который а) собирает айдишники из adb в массив. б) стартит аппиум сервер(а) и сохраняет порты. в) всё это запихивает в вызов параметры при вызове pytest. Внимание, вопрос. Насколько такая конструкция дикая? и нет ли другого решения по элегантнее? Или смириться со всем этим, накатить 2-3 конфигурационных файла в проекте и уже их обрабатывать в коде фикстур для тестов?

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

или я не так понял ?

Коллеги, добрый день. На очередном этапе борьбы с автоматизацией мобильного приложения с appium+pytest столкнулся с собственным желанием вырвать захордкоженный ай-ди телефона и заодно сделать паралельные тесты в случае, когда подключённых девайсов больше одного. (xdist прикручен) Моё решение выглядит как баш скрипт, который а) собирает айдишники из adb в массив. б) стартит аппиум сервер(а) и сохраняет порты. в) всё это запихивает в вызов параметры при вызове pytest. Внимание, вопрос. Насколько такая конструкция дикая? и нет ли другого решения по элегантнее? Или смириться со всем этим, накатить 2-3 конфигурационных файла в проекте и уже их обрабатывать в коде фикстур для тестов?

Адище.

Столкнулся с такой же задачей

Вынес в настрйоки CI. Почему "За" такой подход: 1) Легко править 2) Любой это может сделать 3) Оперативно можно поменять

В Вашем подходе вижу дикий ад,если придется передать проект другому тестировщику

Уж лучше вынести в conftest нужные capabilites и запускать с нужным параметром

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

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

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

Оно же опенсорсное.

Скачали, развернули и впуть.

gradle spoon

такая команда

и все бегает на всех подключенных девайсах

но у меня был только андроид

В Вашем подходе вижу дикий ад,если придется передать проект другому тестировщику

Ну дикий ад то будет, если он захочет это читать. Так то в моем воображение это один раз сделать и забыть.

Ну дикий ад то будет, если он захочет это читать. Так то в моем воображение это один раз сделать и забыть.

А если понадобится еще устройства прикрутить?

Уж лучше вынести в conftest нужные capabilites и запускать с нужным параметром

Вот наверное да, второй вариант именно забить и не выдрючиваться.

Вот наверное да, второй вариант именно забить и не выдрючиваться.

у тебя только андроид?

А если понадобится еще устройства прикрутить?

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

А если понадобится еще устройства прикрутить?

А в конфиги как раз ручками каждый раз крутить.

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

Kiss не для нас?)

Kiss не для нас?)

Ну вот, например посмотрю...

у тебя только андроид?

Пока да.

если у тебя только андроид то юзай плагин https://github.com/stanfy/spoon-gradle-plugin можно ручками вбивать какие девайсы юзать, а какие нет, а можно просто gradle spoon и он на всем что есть запустит тесты

spoon { devices = ['333236E9AE5800EC'] skipDevices = ['serial-you-want-to-skip'] }

достаточно понятно помойму

Скачали, развернули и впуть.

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

А, во.

А в конфиги как раз ручками каждый раз крутить.

Конфиг так часто меняется?

Сразу бы сказали, что я не то смотрю. :-)

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

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

Ну градл я не прикручивал..

но он есть в проекте ?

но он есть в проекте ?

Неть

Но вариант, конечно. Возможно в следующий раз сделаю.

Конфиг так часто меняется?

Вооот. Ладно, просто тогда с конфиг файлами попробую. А там в фикстурах уже значения ловить, да?

Вооот. Ладно, просто тогда с конфиг файлами попробую. А там в фикстурах уже значения ловить, да?

Я бы в фикстуры вынес то, что может меняться: uuid

Я бы в фикстуры вынес то, что может меняться: uuid

Погоди, тут поподробнее, пожалуйста. Как это сделать с xdist корректно?

У меня фикстура это старт драйвера с капами и убйство драйвера.

Дальше через фром импорт эта фикстура рядом с тестом и передается в тест.

С ссылкой для драйвера.

Так, надо вспомнить пайтон и пайтест)

У меня фикстура это старт драйвера с капами и убйство драйвера.

Так почему не вынести получение UUID в фикстуру?

Ааа. Это да.

С параметра входного на вход, ога.

Надо попробовать.