Добрый день! Почему вам не подошел подход когда при получении новой версии микросервиса собирается docker-compose/minikube с 10 сервисами на изолированной машине, запускаются тесты, потом машина убирается и потом при получении очередной версии опять собирается оркестрация? В этом случае у вас будет прямой доступ к сервисам, очередям, базам данным и можно любые данные инжектить, можно эмулировать любые запросы пользователей. Зачем было изобретать синтетику?
Не думали оставить только 1 или 2 e2e сценария, а все остальное покрытие перевести в компонентные тесты (1 тест затрагивает только 1 микросервис)?
«Для целей E2E развернуто два k8s-кластера с микросервисами, которые участвуют в БП, покрываемых тестами» , как вариант, можно разворачивать 1 микросервис с минимальными зависимостями и запускать компонентные только после изменений в микросервиса (нового релиза). В итоге можно параллельно изолированно тестировать разные микросервисы и тесты будут запускаться не по расписанию, а только после изменений
Добрый день, спасибо за интересную статью. К сожалению в бесплатной версии разрешено использовать максимум 20 таблиц. Вы случайно, не знаете ориентировочную стоимость платной подписки?
Добрый вечер, спасибо за статью. Тоже часто приходилось работать с Maven Reactor и большим кол-вом JUnit тестов. Но у меня не возникало проблем с распараллеливанием. Вы не могли бы объяснить проблему с параллельными запусками подробнее? Я использовал подход, что для каждого модуля отдельная job в Team City/Circle CI/GitLab и мы для модуля задаем количество потоков в Custom Strategy в JUnit 5 https://junit.org/junit5/docs/snapshot/user-guide/#writing-tests-parallel-execution-config
То есть вопрос в том, зачем запускать сборки по большому количеству модулей в одной Team City job? Одна команда автоматизаторов переиспользует тесты от нескольких других команд?
На мой взгляд, зря потраченное время на разработку велосипеда. Согласен с предыдущим комментарием, что запускать тесты вручную не нужно. Можно запускать тесты после деплоя изменений на стенд или, например, по расписанию полный регрессионный набор. Если у вас есть зависимости от тестовых данных и 11 продуктов, то добавьте эти зависимости в pipeline и сэкономите кучу времени избавившись от ручных запусков. В рамках исключения, всегда можно просто зайти в мобильную версию CI/CD и запустить job.
Насчет нотификаций в корпоративный чат - это уже давно реализовано в CI/CD системах и не нужно пилить велосипеды. Например, в Circle CI делается одной строчкой orbs: ms-teams-notifier: oktapodia/ms-teams-notifier@1.0.0 Уверен, что Jenkins тоже есть плагины.
Тестирование — бонус, улучшающий систему, а не критическая необходимость.
С помощью тестирования проверяется, что продукт реализован как задумано и это критично. Например, разработана система денежных переводов и в ней должна быть фича, что уведомления о транзакциях приходят на почту, и если, например, криво настроена CRM, то без тестирования никто даже не узнает, что фича не работает.
Где человеку, разрабатывающему на Java и Selenium, можно посмотреть пример настройки CI для PlayWright на TeamCity или Jenkins?
В документации PLayWright нашел только GitHub Actions.
Можешь скинуть альтернативную ссылку чтобы посмотреть видео?
«третьим заблуждениями я подсмотрел на конференции TestBash в Мюнхене (для просмотра доклада нужно зарегистрироваться на сайте ministryoftestingorg.com, но там есть бесплатный пакет).»
Спасибо за статью. По вашему мнению есть какая-то золотая середина между временем, который team lead занимается менеджментом, коммуникациями и собственно разработкой кода? ~60 % разработки? Ведь очевидно, что не практикующий team lead быстро вылетит из тренда и ни сможет никого коачить.
Привет. Спасибо за статью.
1. В Allure 2 нет вкладки perfomance. Вы что-то самостоятельно кастомизировали? Можете поделиться кастомизацией Allure?
2.
Eще у них есть решение для браузера, а так как у нас большая часть функционала находится именно там, то в браузере он тоже что-то делает и дает какие-то метрики.
Я правильно понимаю это что-то типа плагина, который настраивается на агенте с которого происходит запуск? Вы его настраивали? Какие метрики можно получить кроме скорости загрузки страниц?
Привет. Ты сам задаешь реализации для Gherkin шагов — их можно модифицировать как угодно. Начиная с 3 версии cucumber поддерживаются пост-действия и можно не только делать приведение к начальному состоянию в предыстории, но и после выполнения сценариев.
Никакой проблемы реализовать подобный сценарий нет:
Дано незарегистрированный пользователь
Создается 1 бронирование в системе:
Когда пользователь заходит на сайт
И делает бронирование
Немного не понял, с одной стороны вы пишете про сокращение time-to-market, а с другой стороны делаете акцент на разработку автотестирования верстки с целью поиска мелких ui-ошибок:
—————————-
Тестирование — отдельная история. Мы создали тесты, анализирующие скриншоты компонентов и сигнализирующие об изменениях: неверном расположении или цвете кнопки, некорректной работе выпадающих списков и других мелких UI-ошибках.
—————————
Мне всегда казалось, что тесты на верстку самые хрупкие, долгие, сложноподдерживаемые, а баги найденные с помощью этих автотестов низкоприоритетные — ведь по сути ничего страшного если кнопка вместо красного цвета стала розовой...
———————
Клиенты не успевают заметить, что что-то пошло не так, — мы уже исправляем это.
———————
Я не очень понимаю почему настолько плохо знать сколько получают другие? Я провожу много собеседований и знаю рынок. Знаю, что большинстве случаев новому человеку предложат больше, чем текущему сотруднику, который проработал в компании больше 3 лет. Эти знания, например, никак на мою производительность не влияют.
Спасибо за ссылку, я пока только ваш colibri-ui фреймворк для мобильных приложений смотрел.
Можешь подробно рассказать как у вас построен процесс доработки фреймворка автоматизации (как я понял — это решение для многих проектов) в разрезе scrum? Например, одной команде нужны какие-то кастомные методы для их приложения, они отправляют pull-request в общий репозиторий, то другие squads тоже принимают участие в review? Или, например, если нужно сделать рефакторинг структуры фреймворка, то как распределяется эта задача между squads?
Также у вас автоматизаторы в squad атомарны или всё-таки есть плотное взаимодействие с автоматизаторами из других squads?
Не думали сделать squad только из автоматизаторов (команду автоматизации), которые бы приходили в конкретный проект что-то делали бы и уходили?
Привет. Можешь рассказать про роль специалистов по автоматизированному в Scrum? У вас бывают ситуации, что несколько SQUAD используют одно решение для автотестов или каждый раз кастомное?
Добрый день! Почему вам не подошел подход когда при получении новой версии микросервиса собирается docker-compose/minikube с 10 сервисами на изолированной машине, запускаются тесты, потом машина убирается и потом при получении очередной версии опять собирается оркестрация? В этом случае у вас будет прямой доступ к сервисам, очередям, базам данным и можно любые данные инжектить, можно эмулировать любые запросы пользователей. Зачем было изобретать синтетику?
Добрый день! Спасибо за статью!
Не думали оставить только 1 или 2 e2e сценария, а все остальное покрытие перевести в компонентные тесты (1 тест затрагивает только 1 микросервис)?
«Для целей E2E развернуто два k8s-кластера с микросервисами, которые участвуют в БП, покрываемых тестами» , как вариант, можно разворачивать 1 микросервис с минимальными зависимостями и запускать компонентные только после изменений в микросервиса (нового релиза). В итоге можно параллельно изолированно тестировать разные микросервисы и тесты будут запускаться не по расписанию, а только после изменений
Добрый день, спасибо за интересную статью.
К сожалению в бесплатной версии разрешено использовать максимум 20 таблиц. Вы случайно, не знаете ориентировочную стоимость платной подписки?
Добрый вечер, спасибо за статью. Тоже часто приходилось работать с Maven Reactor и большим кол-вом JUnit тестов. Но у меня не возникало проблем с распараллеливанием. Вы не могли бы объяснить проблему с параллельными запусками подробнее? Я использовал подход, что для каждого модуля отдельная job в Team City/Circle CI/GitLab и мы для модуля задаем количество потоков в Custom Strategy в JUnit 5 https://junit.org/junit5/docs/snapshot/user-guide/#writing-tests-parallel-execution-config
То есть вопрос в том, зачем запускать сборки по большому количеству модулей в одной Team City job? Одна команда автоматизаторов переиспользует тесты от нескольких других команд?
На мой взгляд, зря потраченное время на разработку велосипеда.
Согласен с предыдущим комментарием, что запускать тесты вручную не нужно. Можно запускать тесты после деплоя изменений на стенд или, например, по расписанию полный регрессионный набор. Если у вас есть зависимости от тестовых данных и 11 продуктов, то добавьте эти зависимости в pipeline и сэкономите кучу времени избавившись от ручных запусков.
В рамках исключения, всегда можно просто зайти в мобильную версию CI/CD и запустить job.
Насчет нотификаций в корпоративный чат - это уже давно реализовано в CI/CD системах и не нужно пилить велосипеды. Например, в Circle CI делается одной строчкой
orbs:
ms-teams-notifier: oktapodia/ms-teams-notifier@1.0.0
Уверен, что Jenkins тоже есть плагины.
Не согласен вот с этим пунктом
Тестирование — бонус, улучшающий систему, а не критическая необходимость.С помощью тестирования проверяется, что продукт реализован как задумано и это критично. Например, разработана система денежных переводов и в ней должна быть фича, что уведомления о транзакциях приходят на почту, и если, например, криво настроена CRM, то без тестирования никто даже не узнает, что фича не работает.
В документации PLayWright нашел только GitHub Actions.
Можешь скинуть альтернативную ссылку чтобы посмотреть видео?
«третьим заблуждениями я подсмотрел на конференции TestBash в Мюнхене (для просмотра доклада нужно зарегистрироваться на сайте ministryoftestingorg.com, но там есть бесплатный пакет).»
www.ministryoftesting.com/dojo/lessons/qualitative-risk-based-test-reporting-nancy-kelln — похоже теперь только для pro member и платно.
1. В Allure 2 нет вкладки perfomance. Вы что-то самостоятельно кастомизировали? Можете поделиться кастомизацией Allure?
2.
Я правильно понимаю это что-то типа плагина, который настраивается на агенте с которого происходит запуск? Вы его настраивали? Какие метрики можно получить кроме скорости загрузки страниц?
Никакой проблемы реализовать подобный сценарий нет:
Дано незарегистрированный пользователь
Создается 1 бронирование в системе:
Когда пользователь заходит на сайт
И делает бронирование
Не понял в чем проблема с Gherkin.
Немного не понял, с одной стороны вы пишете про сокращение time-to-market, а с другой стороны делаете акцент на разработку автотестирования верстки с целью поиска мелких ui-ошибок:
—————————-
Тестирование — отдельная история. Мы создали тесты, анализирующие скриншоты компонентов и сигнализирующие об изменениях: неверном расположении или цвете кнопки, некорректной работе выпадающих списков и других мелких UI-ошибках.
—————————
Мне всегда казалось, что тесты на верстку самые хрупкие, долгие, сложноподдерживаемые, а баги найденные с помощью этих автотестов низкоприоритетные — ведь по сути ничего страшного если кнопка вместо красного цвета стала розовой...
———————
Клиенты не успевают заметить, что что-то пошло не так, — мы уже исправляем это.
———————
Вы ui-тесты прогоняете на production?
Можешь подробно рассказать как у вас построен процесс доработки фреймворка автоматизации (как я понял — это решение для многих проектов) в разрезе scrum? Например, одной команде нужны какие-то кастомные методы для их приложения, они отправляют pull-request в общий репозиторий, то другие squads тоже принимают участие в review? Или, например, если нужно сделать рефакторинг структуры фреймворка, то как распределяется эта задача между squads?
Также у вас автоматизаторы в squad атомарны или всё-таки есть плотное взаимодействие с автоматизаторами из других squads?
Не думали сделать squad только из автоматизаторов (команду автоматизации), которые бы приходили в конкретный проект что-то делали бы и уходили?