赞！
我之前参加过的项目有这种情况，这都是大型项目了。
严重影响QA的主要有两种情况，一种是break build，另一种是build不能用。
Joel on software提到微软30年前遇到break build一般是让肇事者午饭时间看着rebuild。
但我们有个项目build一次10个小时，没法搞。
如果按瀑布开发管理方式，我们之前是在qa和build之间插automation qa，保证基础功能可用
如果是按agile管理，按feature划分小scrum团队，每个scrum团队有自己的branch。有的qa在主branch上工作，有的qa在各个feature之间流动工作
这是我们遇到的情况和处理方式

【 在 eGust 的大作中提到: 】
: 我们也有类似的问题，有时 QA 环境更新收到大量 PR。在测试 A 功能时，由于功能 B 出了问题，导致 QA 无法进行测试。而 QA 又无法判断是谁导致的，于是就随机 bounce 某一个 ticket。然后开发这边就得花时间 debug，找到出错的代码，再告诉 QA 这个问题是由另外一个 jira 导致的，你 bounce 错了。如果有 work around 的话我可能也会讲一下，不然可能不光我一个人的没法继续测。有时候实在太严重，只好 ssh 过去直接修了，不然按照我们的流程，可能半天时间 QA 都干不了活儿了。一来二去，浪费至少两个人的时间。
: 这方面我们感觉很大程度上是 branching model 导致的，因为 QA 用的 branch 包含所有人的代码。而 QA 只是随机的拿一个 jira，并不知道有哪些变动，更不具备可以判断问题出在哪里的能力。出了问题，自然也做了一定的研究，看看别人的经验。不过这方面我并没有非常成熟的想法，主要也是很多相关 model 的介绍中都并没有提到 QA 的角色。
: 比如 git flow，并没有明确说 QA 应该测试哪个 branch。如果测 develop branch，那就跟我们的现状没有差别，完全解决不了问题。测 feature branches 的话，首先就是可能某些 features 单独测没问题，但是它们又并非完全独立的，merge 到 develop 后可能会产生新的问题。其次，某些 feature 本身的工作量也很大，需要几个人协作完成，并且也无法避免产生依赖关系。最后需要给 QA 能够主动切换 branch 的能力，但我们最大的问题是数据库，想要 rollback 是非常困难的。当然技术上的问题不光数据库一个，但个人感受技术上的问题都是有办法解决的，更大的问题还是在人的观念上。
: ...................
--
FROM 123.116.198.*