Как скоординировать тест между несколькими командами схватки

Question

Я участвую в новом проекте, который использует схватку и масштабируется от одной команды схватки до четырех и, вероятно, будет расти дальше. Это новая технология, поэтому архитектура все еще развивается, поэтому куски должны быть протестированы в системе в целом. Используя аналогию с машиной, у нас есть команды для шасси, тормозов, двигателя и рулевого управления. Любая данная история имеет фокус (например, ускорение ускорения) и назначается одной команде (например, движку). Определение сделанного обычно определяет критерии по этой части в этой схватке. Однако некоторые испытания еще нужно сделать с помощью «системы» (например, водить автомобиль вокруг дорожки), чтобы изменения не нарушали другие части системы. Например, двигатель может быть тяжелее, что влияет на торможение или рулевое управление.

Here указывает, что отдельная тестовая группа НЕ является ответом. Он перечисляет «отдельную тестовую команду» сначала в своих «пяти главных проблемах при масштабировании схватки». Таким образом, тестирование системы должно выполняться с помощью структуры схватки.

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

Как система оценивает масштаб как проект, растет до нескольких команд схватки?

Answer 1

В гибкой разработке избегать зависимостей, таких как чума.

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

Если команда не значение производства, что делает сделано mean? Как вы определяете приоритеты, когда вам нужны команды для синхронизации, чтобы получить автомобиль?

Сравните, как работает Facebook (например, и, насколько я знаю):

• Одна команда делает чат
• Одна команда делает фотоальбомов
• Один ТЕМ делает график
• ЕСС ...

Они все Deploy - т.е. непосредственно генерировать значение - и полностью независимы в их тестировании.

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

Answer 2

Я считаю, что проблема заключается в том, что ваш DOD не включает в себя тест интеграции.

Если вы продляете DOD до этого этапа, все 4 команды будут интегрировать результаты, полученные на раннем этапе - во время спринта - на этап интеграции и получить оттуда результаты. Очень важно сделать это в начале спринта, потому что в противном случае ошибки с этого этапа будут опоздать для фиксации в одном и том же спринте. Однако исправление ошибок в спринте, где они определены, должно быть. Багги код не СОВЕРШЕН.

Расширение DOD на другой этап также является лучшей практикой для команд, которые регулярно выполняют DOD.

BTW: Расширение DOD, конечно, повлияет на вашу скорость в начале. Это нормально, потому что вы сделаете больше, чтобы выполнить DOD.