отчётности, как лучше её выстроить по автоматизированным тестам? Кто-то связал с testrai API, но никто туда не заходит кроме QA. кто-то делает с отправкой в телеграмм канал.
В общем: что внедрить в компании посоветуете?
Пока просто настроил триггер на свою почту, если ран failed и генериться артифакт в pipeline с html отчетом, но без рассылки.
Я бы начал с выяснения того, кому эта информация нужна. Если она нужна только вам, то уже всё готово, как я понимаю. Если она нужна кому-то ещё, то таких людей нужно найти и выяснить наиболее предпочитаемые каналы оповещения. Делать оповещения по 4-5 каналам, которые никто не будет читать - затея не самая лучшая. И да, нужно понимать что именно в вашей компании является наиболее распространённым каналом связи. Например, у нас большая часть людей работает с MS Teams и потому мы настраивали оповещения именно в каналы Teams.
Тимлид должен знать, что dev сломали, потому что все всё бросают и чинят (ну если по уму)
Нет лида - сам себе лид.
Лид разрабов имеется в виду
У нас только выстраиваются QA стандарты, так что мне задавать правильный тон/практики. Остальным не до этого. У нас также, Teams. И как у Вас там отчётность сделана? У нас если падает билд- приходит сообщение на спец devOps канал. Но не ясно что упало- пока не залезешь
Понял - хорошая идея, только тут такого нет. У нас есть куча проектов и в каждом 2-3 разраба (без Лида). Есть программер-менеджер, но он не знает кухню каждого проекта
Вот именно так и сделано. Не стоит в канал пихать stack trace с которым всё упало. Это лишь средство оповещения. Те, кому это всё нужно, пойдут в Jenkins или другие ресурсы, откроют логи и будут копаться. В общих оповещениях это никому и никогда не нужно.
Могу лишь дополнительно посоветовать делать отдельный канал на отдельный проект. Иначе получится месиво из отчётов.
У вас именно отчеты по тестам или по результату пайплайн рана? Да, интересная идея для обсуждения с командой. Есть канал под проект!
Если нет никаких требований и ожиданий, то зачем вам вообще делать отчётность?
Есть разные ситуации. Единого подхода нет. Всё же нужно бороться за информативность, а не за единообразие в данном контексте. 1) Где тестов мало и они очень длительные (сутки или недели прогона), то вырисовывается таблица с состоянием каждого теста. 2) Если тестов много (от 30 и более), то в результате мы получаем состояние всего сьюта тестов. А отдельные тесты выводятся таблицей только если они упали. Т.е. в ситуации когда всё хорошо я вижу "Такой то сьют Passed". В ситуации, когда что-то упало "Такой-то сьют Fail и дальше тесты, которые завалились". 3) В других местах из-за необходимости проведения автотестов на разных ОС выводится таблица: OS | Test Suite | Suite State
есть мнение, что если отчетность никому не нужна, то она в любой форме будет всё еще никому не нужна
Если нет никаких ожиданий,то кому вообще нужна эта отчётность? (Вопрос риторический, если что)
Это кастомные решения отчётности таким оформление или готовые библиотеки?
Всё кастомное. Там 50 строк кода.))
кто чинить будет - тому пусть и падает. Нет лида - всем разрабам на проекте, пусть сами разбираются. В идеале всем авторам коммитов с последнего удачного теста, конечно
По сути им это не так нужно-ибо они видят в Jenkins (blueOcean), что билд упал и могут посмотреть какой стейдж. Там главное сделать, чтобы по моим логам было ясно, что конкретно упало и как дебажить (если это их ошибка).
это тебе только разрабы ответят. Задача - минимум - оповестить, что тесты зафэйлились. А так можешь на выбор: запихать их мэйлы в рассылку и спросить "так пойдет?". Это вызовет их на разговор, получишь задачку на улучшение артефактов к событию фэйла и выполнишь ее
Отлично, спасибо за идею
если отчетность никто не требует, то светить ею на публику никакого смысла нет. Лучше сделать это внутренним артефактом, который можно использовать как инструмент демонстрации продуктивной работы куа. И строить их инфраструктуру и наполнение исходя из этого факта. Надежда же на то, что "я соберу мегауберотчет и все поймут, как это классно делать куа" - обречена на провал.
Обсуждают сегодня