我们也有类似的问题，有时 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 是非常困难的。当然技术上的问题不光数据库一个，但个人感受技术上的问题都是有办法解决的，更大的问题还是在人的观念上。

不知道你们的每次 build 要多久，如果让 QA 单独测 PR（rebase PR on develop），通了直接 merge，那就可以一定程度上避免一个 bug 耽误所有人的事。缺点就是我前面说的，有些功能不是完全独立的，后 merge 的测了没问题，但前面的可能需要重新测一遍。

【 在 xunery (寻) 的大作中提到: 】
: 是，bug不可避免，只要是人去做，就有出错的可能。
: 其实，我主要想把严重的bug在编译完成之后，打包之前能筛选出来。以前碰到过什么情况，就是一个人引入一个fatal bug，导致QA拿到新的包不可用，不光影响QA的工作，别人修改的代码也无法验证。
: 这时候如果有自动化测试环节，可能影响就会降低很多。长期来看，对整个团队的效率都有提高。
: ...................
--
FROM 203.211.111.*