Где команда QA должна провести тестирование в модели ветвления Gitflow

Мы большая команда (10-12 разработчиков и 4 человека), работающие над несколькими проектами с одним и тем же git-репозиторием. Это бэкэнд-сервис на основе весенней загрузки. Мы ищем хорошую стратегию git для ветвления и развертывания. у нас также есть команда qa, которая гарантирует, что наши функции работают должным образом (в определенной степени без ошибок).

Прочитав несколько статей, я почувствовал, что модель Gitflow будет хорошо работать для нас. Здесь возникает мой вопрос.

Где наша команда QA должна проверить наши возможности?

1. если они будут тестировать в ветви функций, где они будут поднимать ошибки, и разработчик исправит это, и как только он пройдет тест QA, мы объединяемся для разработки. и QA снова проведет тестирование на интеграцию в развивающейся отрасли.
2. Должны ли мы объединить все функции (после модульных тестов и базового тестирования от разработчика), чтобы разработать ветку и дать оттуда тест qa. все исправления и тесты будут происходить и в разработке.

Мне любопытно услышать, какой подход хорошо сработал для других.

QA, вероятно, должен тестировать дважды.

Первое тестирование должно проводиться вокруг конкретных изменений и проводиться в ветви функций. Это позволяет тестировать QA вокруг конкретных изменений и видеть, что конкретное изменение завершено, как указано, и ведет себя как ожидалось. Это также дает им предварительный просмотр для второго раунда тестирования, что на самом деле имеет значение для QA.

Исходя из моего опыта работы в различных регулируемых средах, второе тестирование необходимо выполнить для тега в ветви разработки, соответствующей релизу, или ветви релиза, или, возможно, главной ветви. Перед выпуском QA должен тестировать полный и полный код, который будет развернут перед его развертыванием, и вы должны быть в состоянии утверждать, что все, что было протестировано QA, в точности совпадает с тем, что развертывается в рабочей среде. Я предпочел бы, чтобы после замораживания кода к ветке релиза был применен тег, и QA проверит это. Изменения вносятся в ветку разработки, проверяются на месте, а затем снова тестируются в новом теге в ветке релиза. Эти теги в ветке релиза будут соответствовать кандидатам на релиз.

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

Отличный вопрос Я не думаю, что есть «официальный» правильный ответ на это. Это зависит от того, как быстро вы можете проверить.

Существенная проблема заключается в том, что каждое слияние, компиляция или даже развертывание потенциально может создавать ошибку. Чем дальше «цепочка», которую вы тестируете, тем быстрее вы узнаете об ошибках, но и тем больше раз вам придется проходить повторное тестирование.

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

Но очевидно, что уже немного поздно, чтобы впервые проверить код!

Если вы тестируете ветку релиза в qa env, тогда вы можете рискнуть и сократить живое тестирование только до дымовых тестов. и применить исправления ошибок к ветке релиза. Но вы не можете оценить, завершена ли функция, прежде чем создавать релиз

Если вы тестируете разработку, вы получаете мини-ветки с исправлениями ошибок. Функции все еще объединяются до их оценки, плюс функции для следующего выпуска могут столкнуться с тестированием текущего выпуска.

Если вы тестируете ветки Feature, вам нужен миллион сред и вы должны согласовать порядок слияний и тестовых подписей. плюс много повторного тестирования.

Из моего опыта я бы порекомендовал:

быстрый тест функциональной ветви на машине разработчика. Просто убедитесь, что его функции завершены, и тестировщики / разработчики согласны с тем, что означают требования.

Ежедневное тестирование / автоматизированное тестирование на ветке разработчика, развернутой на серверах qa. Позволяет протестировать все функции вместе и сказать, когда вы будете готовы к выпуску.

Если все функции включены, но тестирование еще не завершено. например, спринт завершен. создайте ветку релиза и разверните ее во второй среде. Это позволяет продолжить исправление ошибок / тестирование в выпуске 1 одновременно с функциями для выпуска 2.

(преданные Scrum скажут, что вы должны вносить только исправления ошибок в спринт 2, но давайте будем практичны)

Дымовые тесты на живом зеленом / синем развертывании перед переключением. Это очень важно, так как вы обнаружите ошибки конфигурации / среды, которые никто не ищет во время разработки.

Я согласен с Томасом Оуэнсом. Вы, вероятно, должны тестировать дважды. Один раз в ветке функций до ее слияния и один раз в основной ветке перед выпуском.

На самом деле, мне очень нравится этот рабочий процесс, поэтому я создал инструмент Topico , который автоматически создает и запускает одноразовые версии вашего приложения для каждого запроса на выборку, каждый со своим уникальным URL-адресом для тестирования. Это позволяет вашей команде QA тестировать ветви функций изолированно, без необходимости создания какой-либо динамической среды тестирования, установленной на их собственной машине.

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

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