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

23

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

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

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

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

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

Srini
источник

Ответы:

14

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

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

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

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

Томас Оуэнс
источник
2
несколько проблем, с которыми я сталкиваюсь при таком подходе: 1) каждая функция потребует развертывания машины. иногда мы работаем над 5 функциями, иногда только пара. может быть, мы можем настроить Дженкинс, чтобы раскрутить виртуальные машины? что все делают? 2) QA должен знать, какая сборка на какой машине. 3) Мне стало интересно, будет ли его избыточным, так как мы собираемся провести тщательное тестирование в любом случае в ветке релиза.
Срини
4

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

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

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

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

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

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

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

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

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

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

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

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

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

Ewan
источник
-2

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

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

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

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

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