Процессы и инструменты для тестирования больших проектов с несколькими ветками

Question

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

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

Как опытные пользователи, мы смотрим на решение этих проблем с помощью рабочих мест. Это довольно «сырой» инструмент - он более или менее обеспечивает базовую функциональность для этого, но не простой интерфейс, особенно для тестировщиков. Поэтому мне интересно, есть ли более удобные для пользователя методы или совсем другие подходы (хотя я не думаю, что «избегать ветвления» - это практический ответ для нас в этом случае!)

Каковы наилучшие практики для обеспечения эффективного контроля качества в нескольких филиалах? Существуют ли какие-либо хорошие инструменты для автоматизации и поддержки этих проблем?

Answer 1

Иногда тестирование проводится один раз в ветке разработки, а затем после объединения в ветку релиза. Но это выбор процесса, а не требование.

Если вы выпускаете только из "основной ветки", вы можете подумать об изменении процесса QA, чтобы проводить тестирование только после слияния изменений в ветку релиза. И положитесь на разработчика, чтобы проверить их изменения до / после слияния. Это более типично.

С тем, что у вас есть сейчас, звучит так, как будто у вас есть одна ветка на разработчика (только предположение). И вы отправляете ошибки на каждую ветку разработки. Я бы серьезно подумал об изменении этого процесса. Он не подлежит ремонту и будет очень сложным для отслеживания ошибок после слияний.

Как и предполагал TrueWill, настройка непрерывной интеграции была бы хорошей идеей. Дополните это частыми (ежедневными) сборками. Затем попросите QA протестировать сборки.

Answer 2

Если qa находит ошибку в основной ветке, и она исправлена ​​в ветке dev, то:

• позвольте qa проверить, что это исправлено в ветке dev
• позвольте qa комментировать ошибку в основной ветке, но держите ее открытой
• после того, как исправление выпущено в основную ветку, чтобы не проверить его снова в основной ветке
• если исправлено исправление в основной, закрыть ошибку в основной ветке.

Что касается других ситуаций, попробуйте разработать сценарии, подобные этому (здесь у вас есть часть жизненного цикла ошибки). Подготовьте сценарии для того, когда тестировать и что тестировать. Как должна выглядеть связь qa-dev. Запишите все вниз. Это будет ваш тестовый процесс. Сделайте так, чтобы QA следовало ему (и, если нужно, разработчик). Возможно, вы не сразу охватите все ситуации, поэтому со временем улучшите свой процесс.

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

Что касается инструментов, то их может быть немного, но я работал только с HP Quality Center и HP Quick Test Pro. QTP - это программное обеспечение для автоматизации тестирования (запись и воспроизведение, управление данными, создание сценариев - VB). КК является хранилищем для тестов (как ручных, так и автоматических), дефектов, также может содержать требования, результаты тестов. Он может отслеживать охват требований тестами и ссылку тестового дефекта (на самом деле дефект тестового прогона, но вы можете перейти от тестового прогона к тесту).
Кроме того, вы можете определить в нем Циклы и Релизы, например, это может быть Цикл на ветвь и Релиз на выпуск кода (где каждый Релиз связан с данным Циклом, поэтому будет понятно, какой код ветви был выпущен). Или вы можете отобразить это по-другому.
Проблема в том, что программное обеспечение стоит денег. Я имею в виду действительно деньги. Это обязательство.