t.me/atinfo_chat Telegram группа по автоматизации тестирования

Какие главные проблемы работы/интеграции автоматизации с test management системами?!

management
poll
testcasemanagement
integration
tools
Теги: #<Tag:0x00007fb2f746e018> #<Tag:0x00007fb2f746de60> #<Tag:0x00007fb2f746dc80> #<Tag:0x00007fb2f746dac8> #<Tag:0x00007fb2f746d8c0>

(Mykhailo Poliarush) #1

Мне очень интересно узнать ваши :open_book: истории, :speaking_head: мнения, :pushpin: боль использования тест менеджмент систем вместе с автоматизацией. На какие грабли наступали? Что так и не получилось прикрутить? И что у вас до сих пор работает на костылях?

Тест менеджмент системы сейчас очень большие и громоздкие и я замечаю что именно из-за сложности систем многие до сих пор используют confluence, excel, spreadsheets, и другие простые инструменты для управления тестами.

А, вы довольны вашей тест менеджмент системой в общем?

  • Да
  • Нет
  • Не знаю, напишу в комментарии

0 участников

Кстати какую тест менеджмент систему вы используете и как интегрируете с тулами автоматизации?

image


(Vladislav Abramov) #3

отправляем в тестрейл результаты по api, ищем сьют, в нем тест кейс, если нет - создаем, потом открытый ран по этому сьюту, и в него отправляем результат кейса
ссылку на тестрейл кладем в секцию environment отчета allure, неделя времени на изучение с нуля, все работает


(Mykhailo Poliarush) #4

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


(Vladislav Abramov) #5

главная проблема - переименовавшийся тест-кейс, остальное легко решается.

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

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


(Maxim Andryushchenkov) #6

Тоже тестрейл. В нем заведены сьюты, в них кейсы с номерами. Данные кейсы легко интегрируются в код, у меня за это отвечает плагин pytest-testrail. Он умеет навесить декоратор с номером как на весь тест, так и на кейс в параметризации. Да, это работает, но есть два НО:

  1. Это никому не нужно. Я понимаю и без этой интеграции что упало и где смотреть (репорт, логи), а ручным тестировщикам туда лезть и времени особо нет, тем более когда автоматизатор рядом. Скажете нужна история багов, ранов, покрытие и тд? Никому не нужно это, прошла итерация и у всех как память стерли. Еще ни разу со времен реализации я не открыл ни один ран и не стал смотреть по нему “где упало”.
  2. Может я особо и не разобрался, но как указать тестрейлу что кейс был скипнут? Пример - вы собираете тесты в PyTest по маркерам и у вас сначала происходит селекция кейсов и только потом они скипаются. Так вот в тестрейл они приходят просто без прогресса и отражаются в процентах криво. Пришлось написать свой селектор, который просто не собирает кейсы если они явно указаны.

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


(Sergei) #7

бешено плюсую


(Евгений Бухгаммер) #8

Сейчас результаты автотестов — это логи в Teamcity и saucelabs. Так как я как инженер автоматизации ближе к разработке, чем к отделу QA, я работаю вне релиза в данный момент (у состоянии догнать регрессию). Для менеджера Куа такая интеграция помогает при составлении прогонов в Testrail увидеть какие из тестов были пройдены автоматизацией. Espresso / xcuitest используют простой http client api testrail , то есть никаких общих решений я не нашёл и набросал сам создание прогона из имеющегося тест плана и простановку статусов по шагам в тесте и общего статуса в тесте с аттачем ошибки в случае падения .

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


(Vladislav Abramov) #9

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

делается это всё для того, чтобы бизнес и руководители разработки видели, когда и что тестировалось в одном месте. 2 рана - регрессионный ручной и автоматизированный

так как у нас “эджайл”, в котором задачи в релиз пихаются в последний день, нужно понимать, когда последний раз проходили автотесты + что именно и КОГДА трогалось руками. коммиты в 7 вечера пятницы, когда релиз в 09:00 субботы - норма


(Maxim Andryushchenkov) #10

Мне кажется этим грешат все команды у кого нет жесткого код фриза) “Ой там чуть совсем, правок не много”… И покатили реп бека перед выходными. И по моим наблюдениям, проблемы, вызванные вот такими пятнично-вечерними пушами невозможно усмотреть ни одной трекинговой системой. Хотя, это скорее от лида зависит)


(Tatyana Durova) #11

А кто-нибудь работал с PTC?


(Георгий Рыбаков) #12

Вы за 4 дня спросили дважды, и ценой невероятных мучений мне все-таки удалось догнать, что вероятно, подразумевается IBM Rational Team Concert. Такого опыта не было.

По теме: сколько не видел, не читал - TMS изначально не очень расположены к интеграции с автоматизацией (изначально делались для другого). И везде - велосипеды и костыли. Знаю, что в Яндексе озадачивались отцы Allure этой проблемой, и запилили годную штуку - Allure Server (на митапчике в mail.ru Артем Ерошенко рассказывал).
В вакансиях от СпортМастерЛаб проскакивало, что они используют. Интересно было бы услышать мнение тех кто уже покрутил эту штуку. Есть такие?)


(Vladislav Abramov) #13

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


(Александр Толстопятов) #14

Мы отказались от использования Allure Server. Почему? Потому что мы просили их предоставить нам демку, потом наш CTO просил их предоставить нам демку и… ничего. Абсолютно несерьезное отношение


(Георгий Рыбаков) #15

Действительно, странно.
И в целом, ситуация странная с этим Allure Server. Показывают только по конфам с середины 2019 года, примерно. А никакого официального ресурса по нему до сих пор нет.


(Vladislav Abramov) #16

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

я думаю, если к ним с кошельком идти, то сразу все ускорится


(Александр Толстопятов) #17

Так я же не зря написал про то, что им писал наш СТО. Это же не Вася из города N, а серьезный дядя с серьезными намерениями. Они могли бы попросить подождать в очереди или что-то вроде, но вместо этого была абсолютная тишина


(Tatyana Durova) #18

мы используем https://en.wikipedia.org/wiki/PTC_Integrity


(Michael Kotov) #19

Во время сборки джарки парсим все @Test аннотации, и засылаем результаты по API в Testrail (имя метода и description). Во время прогона тестов создается ран, и результаты так же постятся через API.