Запуск регрессионных тестов + Jira flow + DEV

Теги: #<Tag:0x00007f7383c09ec0> #<Tag:0x00007f7383c09dd0> #<Tag:0x00007f7383c09ce0>

Уважаемые!

А есть тут те, кто работают в кампаниях, где все автоматизированно и QA исключительно только пишут регрессию, а DEV тестирует и релизит новую функциональность сам. Два вопроса:

  1. Есть какой-то способ, как быстро узнать, что фича сделана и она кандидат в регрессию, кроме как мониторить борду разработчиков?
  2. Прогон автоматической регрессии у вас после мерджа в дев или на уровне пулл реквеста QA тоже смотрит код?

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

почему я думаю, что такой подход утопия? потому что нет единого стандарта разработки, к которому бы все по итогу стремились, чтоб по итогу получался конвейер поставки фич на бой, и всё идеально покрывалось автотестами, этим автотестам доверяли, и эти автотесты находили дефекты и так далее и тому подобное

я работал в банке в большой команде разработки ДБО, писал автотесты, которые формально не были регрессией, а покрывали именно сценарии работы пользователей (клиента и банка) в системе; очевидно, что фичи там были и связаны с новыми законодательными нормами, и улучшениями интерфейса, и созданием новых банковских продуктов; и мануальщики не писали сценарии тестирования, а держали в голове чеклист, проходя по которому говорили, можно ли это отдавать всё в релиз
автотесты же молотили параллельно и проверяли “хэппи пас”-сценарии, в чём-то подстраховывая мануальщиков

если смотреть со стороны, то можно сказать, что это проблема отдела тестирования, что не провели работу по выявлению регресса, и так далее; но всё-таки пирамида тестирования права в том, что end-to-end тестов надо стараться делать как можно меньше, в том числе и потому, что поддержка такого тестирования слишком дорога по итогу, а профиты от неё надо еще поискать

На практие был только 1 проект где получилось реализовать нечто подобное

  1. У нас было нечто наподобии компонентного тестирования, то есть каждый контейнер подымался изолированно и против него запускались тесты(то есть мы не зависели от тест энвов)
  2. Это были сервиса и разработка тестов в спринте начиналась одновременно с разработчиками
  3. Так как у нас была микросервисная архитектура, то тесты запускались после каждого коммита для отдельных контейнеров
  4. в каждой команде был автоматизатор который учавствовал во всех скрам митингах и соответственно слышал все апдейты команды и довал соответственные коментарии
2 симпатии