Непрерывная интеграция и контроль качества

Question

В моем проекте мы настраиваем среду непрерывной интеграции и в рамках этого процесса предлагаем одновременное исправление дефектов во время циклов тестирования качества.

Каков обычно практикуемый процесс, когда дело доходит до выпуска этого в среду QA? Являются ли эти исправления немедленно развернутыми в среде QA (после интеграционного тестирования) или они накапливаются до завершения текущего цикла тестирования.

Answer 1

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

CI - это скорее базовый эталон качества кода (например, он строит, проходит тесты на юнит / дым) - не думайте, что QA нужно брать каждую сборку, выходящую из CI.

Answer 2

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

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

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

Answer 3

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

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

Все зависит от политики обеспечения качества компании, некоторые могут или не могут согласиться с моей точкой зрения :)

Answer 4

Насколько я понимаю, вы спрашиваете, какова продолжительность цикла QA в проекте, который имеет цикл непрерывной интеграции?

Мы используем ежедневный цикл QA . Ночная сборка, если она удалась, доступна для тестирования в течение следующего дня.

Answer 5

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

Внутренняя группа обеспечения качества отвечает за проверку работоспособности продукта. Они оценивают базовую проверку работоспособности сборки, выполняя потоки исправности. В случае сбоя любого потока работоспособности или сбоя основного / вновь созданного модуля IQA направляет электронную почту менеджеру по выпуску / менеджеру разработки для разработки новой сборки. Как только потоки исправности пройдены, сборка готова для внешней команды обеспечения качества тестирование.

Сборка планируется ежедневно, о неисправностях сообщают внешние QA. Внутренние QA там для потоков здравомыслия и быстрого общения и обсуждения с dev. Таким образом, весь процесс может быть ускорен, а разрыв QA-Dev уменьшен путем добавления их в команду разработчиков.

Надеюсь, это ответит на ваш вопрос! Ура :)

Answer 6

Зависит от стиля разработки проекта. Предполагая, что вы ловкая команда.

• Существует два уровня тестирования: тестирование во время итерации и конец итерации
• Целью CI является поиск и исправление ошибок во время итерации. Тип тестирования ориентирован на юнит, функционал и реализацию историй
• Ошибки, которые вы найдете в таких гибких командах, должны быть исправлены до выпуска в среду QA
• Среда QA должна использоваться для проведения регрессионного и интеграционного тестирования. Целью такого тестирования должно быть нахождение регрессии и интеграции, а не функциональности функций

Выше приведен общий подход. Конечно, он сильно зависит от характера вашего программного обеспечения и команды

Answer 7

Являются ли эти исправления немедленно развернутыми в среде QA (после интеграционного тестирования) или они накапливаются до завершения текущего цикла тестирования.

Это зависит. Если проблема блокирует и не позволяет тестировщикам запускать больше тестов, чтобы завершить весь план тестирования (т. Е. Выполнить свою работу), то, возможно, может потребоваться немедленное выпуск исправления. Если проблема не является блокирующей, то может быть предпочтительнее поставить исправление в очередь и сделать его доступным в следующем выпуске. Но это требует большой административной работы (регистрация проблемы, аннотирование контрольного примера и т. Д.).

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

Answer 8

Ответ от nitzmahone - отличный совет для балансировки более частых сборок, которые вы получаете от системы CI, с необходимостью контроля качества для известной цели тестирования.

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

• Настройте задание в вашей системе CI, которое запускает запланированное задание (например, ежедневно, в отличие от запуска из-за изменений исходного кода), чтобы выполнить тест производительности в вашей системе и зарегистрировать результаты. Таким образом, вы сможете отслеживать производительность с течением времени и выявлять любые изменения, которые негативно влияют на производительность.
• Попросите ваше задание сборки CI автоматически развернуть вашу систему, если сборка и модульные тесты пройдут успешно, и используйте ИТ-монитор, например Nagios , проверяющий развернутую систему. Это действует как быстрый и грязный системный тест, который часто может находить ошибки, которые не обнаруживаются модульными тестами. Я написал сообщение в блоге , которое может оказаться полезным, если вы заинтересованы в этом типе теста.