Мне очень интересно узнать ваши истории, мнения, боль использования тест менеджмент систем вместе с автоматизацией. На какие грабли наступали? Что так и не получилось прикрутить? И что у вас до сих пор работает на костылях?
Тест менеджмент системы сейчас очень большие и громоздкие и я замечаю что именно из-за сложности систем многие до сих пор используют confluence, excel, spreadsheets, и другие простые инструменты для управления тестами.
А, вы довольны вашей тест менеджмент системой в общем?
Да
Нет
Не знаю, напишу в комментарии
0участников
Кстати какую тест менеджмент систему вы используете и как интегрируете с тулами автоматизации?
отправляем в тестрейл результаты по api, ищем сьют, в нем тест кейс, если нет - создаем, потом открытый ран по этому сьюту, и в него отправляем результат кейса
ссылку на тестрейл кладем в секцию environment отчета allure, неделя времени на изучение с нуля, все работает
А что вы делаете когда, приложение поменялось, логика тестов изменились, автоматические тесты падают из-за изменений? Все ручками проходите и анализируете изменения?
главная проблема - переименовавшийся тест-кейс, остальное легко решается.
если приложение поменялось, то мы на ненужный тест вешаем признак @disable, и в тестрейле у него автоматически проставляется такой же статус, ручками можно все такие удалить
при изменении логики тестов шаги в тестрейл новые не отправляем, тут косяк, можно накрутить проверку равны ли шаги в тесткейсе тестрейла текущим, и если что обновлять
Тоже тестрейл. В нем заведены сьюты, в них кейсы с номерами. Данные кейсы легко интегрируются в код, у меня за это отвечает плагин pytest-testrail. Он умеет навесить декоратор с номером как на весь тест, так и на кейс в параметризации. Да, это работает, но есть два НО:
Это никому не нужно. Я понимаю и без этой интеграции что упало и где смотреть (репорт, логи), а ручным тестировщикам туда лезть и времени особо нет, тем более когда автоматизатор рядом. Скажете нужна история багов, ранов, покрытие и тд? Никому не нужно это, прошла итерация и у всех как память стерли. Еще ни разу со времен реализации я не открыл ни один ран и не стал смотреть по нему “где упало”.
Может я особо и не разобрался, но как указать тестрейлу что кейс был скипнут? Пример - вы собираете тесты в PyTest по маркерам и у вас сначала происходит селекция кейсов и только потом они скипаются. Так вот в тестрейл они приходят просто без прогресса и отражаются в процентах криво. Пришлось написать свой селектор, который просто не собирает кейсы если они явно указаны.
Вообще это не моя инициатива, но, что сказали, то и сделал. Скорее всего, проект автоматизации не должен иметь таких интеграций. Ведь есть нормальные логи и репорт. Не устраивает из коробки - возьми Allure.
Сейчас результаты автотестов — это логи в Teamcity и saucelabs. Так как я как инженер автоматизации ближе к разработке, чем к отделу QA, я работаю вне релиза в данный момент (у состоянии догнать регрессию). Для менеджера Куа такая интеграция помогает при составлении прогонов в Testrail увидеть какие из тестов были пройдены автоматизацией. Espresso / xcuitest используют простой http client api testrail , то есть никаких общих решений я не нашёл и набросал сам создание прогона из имеющегося тест плана и простановку статусов по шагам в тесте и общего статуса в тесте с аттачем ошибки в случае падения .
Лично я думаю что это ни разу не обязательная интеграция, но она может быть полезна, если команды автоматизации не являются частью релиз цикла, а решение о протестированности и общий статус наглядно хочется видеть в тест менеджмент системе.
мы каждый тест, который подходит по критериям отбора, пытаемся запустить
если у него есть тег disable, то мы не включаем браузер, а сразу вываливаемся с ошибкой, что тест не реализован, перекрашиваем его в аллюре и отправляем в тест-рейл, проставляя тестрейловский статус какой-то там
делается это всё для того, чтобы бизнес и руководители разработки видели, когда и что тестировалось в одном месте. 2 рана - регрессионный ручной и автоматизированный
так как у нас “эджайл”, в котором задачи в релиз пихаются в последний день, нужно понимать, когда последний раз проходили автотесты + что именно и КОГДА трогалось руками. коммиты в 7 вечера пятницы, когда релиз в 09:00 субботы - норма
Мне кажется этим грешат все команды у кого нет жесткого код фриза) “Ой там чуть совсем, правок не много”… И покатили реп бека перед выходными. И по моим наблюдениям, проблемы, вызванные вот такими пятнично-вечерними пушами невозможно усмотреть ни одной трекинговой системой. Хотя, это скорее от лида зависит)
Вы за 4 дня спросили дважды, и ценой невероятных мучений мне все-таки удалось догнать, что вероятно, подразумевается IBM Rational Team Concert. Такого опыта не было.
По теме: сколько не видел, не читал - TMS изначально не очень расположены к интеграции с автоматизацией (изначально делались для другого). И везде - велосипеды и костыли. Знаю, что в Яндексе озадачивались отцы Allure этой проблемой, и запилили годную штуку - Allure Server (на митапчике в mail.ru Артем Ерошенко рассказывал).
В вакансиях от СпортМастерЛаб проскакивало, что они используют. Интересно было бы услышать мнение тех кто уже покрутил эту штуку. Есть такие?)
на гейзенбаге Артём говорил, что можно им написать, и есть возможность потрогать аллюр сервер бесплатно. наверняка если команда маленькая и что-то делаете в опенсорс, то дадут без проблем.
Мы отказались от использования Allure Server. Почему? Потому что мы просили их предоставить нам демку, потом наш CTO просил их предоставить нам демку и… ничего. Абсолютно несерьезное отношение
Действительно, странно.
И в целом, ситуация странная с этим Allure Server. Показывают только по конфам с середины 2019 года, примерно. А никакого официального ресурса по нему до сих пор нет.
гейзенбаг был в ноябре вроде, там Артём как раз сказал, что запросов была куча, и они не смогли в них разобраться. кто-то успел получить, кто-то не успел
я думаю, если к ним с кошельком идти, то сразу все ускорится
Так я же не зря написал про то, что им писал наш СТО. Это же не Вася из города N, а серьезный дядя с серьезными намерениями. Они могли бы попросить подождать в очереди или что-то вроде, но вместо этого была абсолютная тишина
Во время сборки джарки парсим все @Test аннотации, и засылаем результаты по API в Testrail (имя метода и description). Во время прогона тестов создается ран, и результаты так же постятся через API.
testomat.io управление авто тестами
истории, 
мнения, 
боль использования тест менеджмент систем вместе с автоматизацией. На какие грабли наступали? Что так и не получилось прикрутить? И что у вас до сих пор работает на костылях?