Как тестировать больше одной фичи при релизе по фичам?

Question

[Роман Якушев]

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

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

Вопрос - как тестировать одновременно больше одной задачи?
Как работать двум тестировщикам?

Answer 1

[Decadal]

Сделайте ветку dev
пусть облако веток задач будет вокруг дева: каждая ветка тестируется по отдельности, а после тестируется их совместимость между собой (я так понял, это и есть причина, по которой нельзя тестировать ветку без подтягивания изменений из мастера).
После фидбека QA по dev-ветке сливать dev в мастер.
А еще лучше сделать dev->stage->master.
На деве тестить слитые ветки, на stage - целые релизы.

Comments

[Роман Якушев]

но в таком случае теряются же релизы по задачам?
Релизы в таком случае будут проходить реже, и сразу пачкой задач.

[Decadal]

Роман Якушев У вас есть задача одновременного тестирования веток - вам придется их сливать на деве (либо продолжить веселуху с вечным стягиванием основной ветки после каждой новой таски).

А вот из чего составлять релиз - уже другой вопрос. На stage-сервер вы можете заливать именно ту таску, которая была принята QA на деве (в общей корзине со всеми фиксами и тасками, которые туда влили). Потом тестировать stage-сервер конкретно по залитой таске (потому что она сама по себе может работать иначе, чем в окружении других фиксов и тасок, слитых перед этим в дев).
И потом только проводить на мастер.
В итоге всё равно выстроится очередь задач, которые вы проводите на master - ну просто потому что у вас режим "релиз по таске". Как плюс - вы сможете одновременно занять команду QA сразу несколькими тасками, проведёнными на dev. Как минус - станет чуть больше работы, "потестируй там, потом потестируй там", чтобы быть уверенным, что проведённая ветка сохраняет рабочее состояние как вместе с остальными ветками, так и сама по себе.

Альтернативой может стать разворачивание "песочного" сервера для каждого разработчика, который делает таски. Он будет заливать на свой "песок" задачку, звать QA, тот будет проверять конкретно его задачку. Потом он будет просить провести свою задачу на stage-сервер, где будет проверяться работа конкретно его таски со всеми фиксами и тасками, которые на данный момент есть в наличии на stage. После чего - безболезненное слитие stage в мастер.

Answer 2

[Alexej Simakov]

(до этого ее тестировать нельзя)

почему? почему кто-то должен ждать появления в мастер-ветке какой-то другой фичи
если при разработке этой фичи, той другой фичи которую ждут тоже не было. Вы тестируете итерацию разработки.
Представим себе мастер ветка содержит претродактиля, одна ветка разработки делает его фиолетовым, а другая ветка разработки делает ему крылья с перъями. Тестировать цвет и перья можно по отдельности, потому что они разрабатывались по-отдельности. Если вы будете тестировать перья и фиолетовость, вы уже тестируете перья под влиянием цвета, или цвет под влиянием перьев. т.е. делаете частичное интеграционное тестирование. Логично было бы тестировать фичи все таки отдельно, и когда наберется их какое-то количество делать общий интеграционный тест и потом сливать все в мастер-ветку.

Comments

[Роман Якушев]

как сделать общий интеграционный тест? отдельная ветка а ля release/* ?
И как понять что мы тестируем разные вещи? не всегда между задачами ясно видно что их код не пересекается.
Ведь именно это является показателем можно ли тестировать ветки по отдельности, или вы предлагаете тестировать пачками? опять же, тогда теряется релиз проекта по фичам

[Alexej Simakov]

Роман Якушев,

отдельная ветка а ля release/* ?

да, интеграционная ветка.

или вы предлагаете тестировать пачками

нет, каждую фичу отдельно, но сливать не в мастер ветку а в интеграционную ветку, где будет проходить интеграционный тест (прогон сборки, и смоук тест + интеграционные тесты на стыке фичей)
вот тут мне кажется похожий вопрос