QA参与开发人员的集成测试

按照我们公司的原有流程，开发人员在发布给QA测试的版本前需要先进行开发人员的集成测试。一般这个过程QA不参与。而这次，QA也准备参与其中。为什么呢？这次主要基于两个考虑：1.这个版本是新系统的第一个版本。QA对于实现出来的效果并不特别了解或者熟悉。虽然我们也有些原型，但动态的页面流转，包括最终选定的控件的具体操作方式其实都还没有实际接触过。所以QA在正式测试之前参与一下开发人员的集成测试也起到一个热身的效果，为即将到来的正式测试做一个准备。这也是业界广泛采用的能够起到“及早测试”效果的方法之一。2.开发人员尚有一些没有实现的功能需要占用部分的集成测试时间，所以没有充分的时间在执行集成测试的同时修复期间发现的缺陷。有了QA帮助执行测试，开发人员就可以有更多的时间去修复缺陷了。这也是体现敏捷团队不分你我、紧密协作精神的时候啦！

目标

1.     熟悉系统，尤其是UI，以便在正式测试时能够更快进入状态

2.     找出重要的（如block的和major的）缺陷，以便在正式测试之前能够解决这些问题

3.     切实了解哪些功能尚未实现或者部分实现的程度（而不仅仅依赖dev的反馈），以便对后续测试安排作出更准确的调整

方法

           与正式QA测试的目标不同，参与集成测试时，QA的目标是在很短的周期内覆盖足够广的功能点，而对于每个功能点的深度（如，通过数据多样性和操作顺序等发现的较深层次的缺陷）不做强调。

           与正式QA测试相同的是我们也需要报告缺陷并及时验证其是否得到修复。在最后，我们需要得到一个包含两部分的报告：（1）每个模块的未实现的功能列表；（2）每个模块的最大的质量风险或者问题；