Size: a a a

2018 November 21

AG

Anton Golov in QA Сибирь
Олег Неумывакин
@coolco 1) используем Git, даже для ручных кейсов,
2) testlink / testrail / testpalm не используем специально, так как они подрывают эффективность, они сделаны для менеджеров, не для эффективных команд
3) максимальная интеграция с тестируемым продуктом, в случае git'a эта интеграция близка к максимальной. Асинхронные Executor и Reporter
4) Ничего не заставляет, но в других командах может быть принято использовать существующее решение, которое было внедрено ранее, и теперь уже дорого перейти на другое, своеобразный effort lock/vendor lock.
А можно уточнить в чем подрывают эффективность?
источник

AG

Anton Golov in QA Сибирь
я работал с несколькими системами из списка, довольно хорошо все.
источник

СМ

Све Михайлова in QA Сибирь
Anton Golov
А можно уточнить в чем подрывают эффективность?
с собственной практики - можно так настроить пайплайн,что не пройдя тестирование ТОЧНО задача не попадёт ** (например, на прод/предпрод). в случае с ТМС всегда есть шанс,что пройдёт (в багтрекере всегда можно под шумок закрыть задачу или вывести втихоря мимо тестирования)
источник

AG

Anton Golov in QA Сибирь
ээээ а гитом то что меает так сделать??
ливнуть  на прод сразу??!!!
источник

СМ

Све Михайлова in QA Сибирь
настройка пайплайнов (+пермиссии). // в случае с Gitlab например.
источник

AG

Anton Golov in QA Сибирь
еще раз ответе на вопрос где здесь влияние TMS - ситемы которая занимается учетом и прогнозированием работ. И частично обеспечивает пайплайн.
что значит под шумок закрыть задачу, она автоматом уедет в релизную ветку?
ну тут вообще связи с библиотекой кейсов прямой нет.
как тогда в вашем случае определяется что задача протестирована??
источник

СМ

Све Михайлова in QA Сибирь
" TMS - ситемы которая занимается учетом и прогнозированием работ. " ?? Что?
источник

СМ

Све Михайлова in QA Сибирь
это хранение информации и запуск ранов по плану + отчёты
источник

AG

Anton Golov in QA Сибирь
посмотрите тест рейл.
унего отличный модуль который делает прогнозы по времени работ и тд. Его только надо статистикой накормить.
хранение и прочее понятно основной функционал я его дадже не рассматрвиаю его все умеют.
источник

AG

Anton Golov in QA Сибирь
и такие ситемы они всегда енмного сбоку.
источник

СМ

Све Михайлова in QA Сибирь
да работала я со всеми этими системами... 8+ лет. тут надо перестроить мировоззрение и не использовать лишние времяпоглотители там, где есть возможность.
источник

AG

Anton Golov in QA Сибирь
эффективность в чем измеряется?
источник

AG

Anton Golov in QA Сибирь
это отношение чего к чему?
источник

AG

Anton Golov in QA Сибирь
я ответа так и не получил, и подозреваю что его нет
источник

СМ

Све Михайлова in QA Сибирь
Anton Golov
эффективность в чем измеряется?
time/increment
источник

A

Aleksandr in QA Сибирь
Здравствуйте, я сделал опрос в гугл форме, чтобы не разводить флуд в чате. https://goo.gl/forms/PszK8a3IXOAYbeVS2 Спасибо за участие!)
источник

A

Aleksander in QA Сибирь
@oneumyvakin git для ручных кейсов? А где храните тест резалты?
источник

ОН

Олег Неумывакин in QA Сибирь
@alfemy в моей голове этот вопрос звучит так: "Как избавиться от ручной работы?" и "Как сделать ручную работу ненужной?"
источник

S

Sergei in QA Сибирь
В teamcity тоже можно настроить зависимости т хранения запусков всех тестов, соответственно есть и история для статистики и регрессий. Графики можно смотреть. Видны билды для которых гонялась тесты. Тмс разве что для регистрации ручных прогонов.. зачем ещё?
источник

ОН

Олег Неумывакин in QA Сибирь
Све Михайлова
@oneumyvakin а как вы ПО/аналитиков перенесли в GIT? или это чисто дев проект?
@stelmashenkosvan
"ПО" - это product owner?  Наш PO написал первую версию продукта, у него нет проблем с git'ом. Но точно ли PO нужен TMS?
"Аналитики" какие именно? Знаю три определения аналитиков:
- которые анализируют данные - им не нужен TMS
- которые PM'ы - они могут накидывать кейсы, но им не нужен TMS.
- которые "тест-аналитики" - они уже пишут код.
источник