Сначала плохо было облачному, потом было плохо локальному.
У меня нет понимания почему идея этого выкладывания вообще кажется кому-то хорошей идеей. Возьмите Репорт Портал, выкладывайте туда (так сделали после того как Тестрейлу стало очень плохо).

Вот как , спасибо .
У нас вот прикручен алюр для отчетов. Но от нас хотят кажется , чтобы ещё и в общем регрессе (для мануальщиков) были хорошо расписанные автотесты и можно было видеть что закрывается ручными тестировщиками а что автотестами. Чтобы все кейсы в одном общем месте были . Я так кажется понимаю

У нас было поле AutomationID (не помню кастомное ли).
По идее "закрывание" можно обеспечивать без "выкладывания".

Когда начинался разговор по "общие места" и "общие подходы", я ехидно спрашивал как живёт компания без общего подхода к сидению на офисных креслах.

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

СТРАШНАЯ ПРАВДА состоит в том что даже если что-то куда-то аплоадится, это совершенно не означает что эта транзакция отмечает качественный сценарий, а не Ктулху знает что попало.
Потому что ни тестрейл ни другие системы тест-менеджмента не проверяют сценарии автоматизации, и даже БДД их не проверяет.

Отметить что-то как автоматизированное — такая же человеческая работа как проверить что сценарий автоматизации соответствует сценарию в тест-менеджмент системе.

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

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

Ещё лучше, повесить x-ray на джиру

Привет, у нас сейчас куртится наверное вот этот:
https://www.gurock.com/testrail/pricing/server
И тестировщики и менеджмент пока довольны, но опять таки у нас принципиально не жмотятся на лицензии и у каждого тестировщика/менеджера есть своя, в какую сумму это влетает компании,  я даже представить боюсь(
По поводу того что тупит и лагает, этого не замечено.
Сейчас у нас порядка 10к тестов, из них заавтомачено порядка 5к. Это те которые гоняются от 1-го до 20 раз в день. Общее число прогнанных тестов - около 1.8 миллиона. Опять таки ничего не тупит. Не знаю есть ли взаимосвязь, у нас не висят тысячи открытых тестранов. Мы их закрываем, и тестраны и майлстоуны.
Что прикольно у тестрейла есть апиха, для автотестов удобно. Что плохо - она как бы это помягче скзать - не айс. Клиента на java когда мы начинали не было, был “неофициальный”, но уже тогда устаревший, пришлось его ручками “подхачивать”. Люди которые писали на python - использовали официальный клиент и вроде у них все ок.
Т.к. клиент для интеграции с тестрейлом на java’е пришлось практически буквально писать самим, мы заморочились и прикрутили фичу “держать тесткейс в коде”. Тким образом в тестрейле всегда актуальные автокейсы.
Поддержка кастомных полей в тестрейле - офигенная штука. Нам очень понравилось. Апи для работы с ней, конечно то еще гауно, но это та фигня которая прибивается гвоздями один раз, а потом туда никто не лезет.
Скажем так, пока из всех систем тестменеджмента, с которыми мне довелось работать рейл мне нравится больше всего.

Немного от сердца отлегло)
Но апиха и правда не айс

Тестрейл это очень неудобная ерунда

Даже лагцчий hp alm лучше

Не надо упоминать это всуе..

Отличный инструмент в плане юзабилити и фич.

Сверху еще воркфлоу скриптов накатить и вообще конфетка

+++

Если бы он умел жить не только в IE, был бы просто иделаным

Если он только в IE работает это не то чтобы недостаток

Это просто делает невозможным его использование

Я, дорогие товарищи, профита этих интеграций не понимаю.
Может объяснит кто?
С тестрейлом работал, по-моему он куда поудобнее динозавра HP ALM, бывшего QC.
Но всё же.

Главная задача автопроверок -- определить что где-то есть проблема когда она там есть.
100500 зелёных квадратиков "тест прошёл" -- они, по-моему, ни о чём.
Либо проблемы найдены, либо они не найдены. Некоторые вообще считают что падающих даже временно проверок быть не должно, только "всё проходящее"/"всё зелёное".

Идентифицировать в коде что он автоматизирует?
ID-строка и/или URL сценария в комменте.

Идентифицировать в тесткейзе что он автоматизирован?
Поле, родное или кастомное, ИД-строка, как в комменте автоматизации.

Что-то упало? Отдельный отчёт по упавшим.
Что-то отключено? Отдельный документ, файл в репозитории с проверками, или отчёт по отключенным, это ж можно и через аннотации находить.
Тенденции? Если проверки нет в упавших и отключенных, значит она проходила. Посмотреть разок отчёт сколько passed.
И/или логи.

Покрытие? Есть цифра автопроверок, есть цифра тесткейзов, можно считать по разбиениям (папкам, классам)?

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

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