上次周铁人博士的 SpecDD 演讲归来以后，一直很忙，所以也就没时间写第二篇归后感，今天正好有点时间，就顺便来简单说一下，我也是是初学者，所以讲的不好，大家也多谅解。
SpecDD在Scrum的基础上，把需求与测试这部分进一步的升华了，我准备接下来把需求与测试的升华来给大家介绍一下，今天的话，就开始从测试的升华上来介绍。
下图是一张 SpecDD的基本结构图，
从图上我们可以清楚地看到，测试是贯穿于SpecDD整个过程的，从需求到开发到大规模测试，无一不显现着测试的影子。
不过虽然测试贯穿整个过程，但是其实是不同类别的测试，比如需求阶段的叫做“设计测试“，开发阶段的“验证测试”，而产品进入大规模测试阶段叫做“Full Cycle Testing”，而我今天想讲的 Floater QA，即使是属于开发阶段的测试，下面来主要介绍一下：
从英文上分析 Floater QA的意思大约是流浪的QA，引申开来大致就是这个QA不会去固定做一个工作，而是会参与很多地方的测试，哪里有需要就会去哪里。（以下简称FQA）
那这个FQA有哪些地方需要去参与呢？
- 参与测试用例的编写
-
参与功能最初的验证性测试，修改测试用例，并且给出改善建议
-
与开发人员与项目经理紧密合作解决所有阻碍下一步测试的问题
为什么需要有FQA这么一种QA的设置呢？
因为在实际的软件开发过程中，我们可能会经常遇到一种情况，一个功能或者一个产品给QA去测试的时候，由于开发不可能把所有地方都测试过，所以一旦发现严重的问题，这些问题会阻碍QA去进一步的测试，但是开发不一定每次都是能第一时间去修复它，那也就使得对于这个功能的测试会因此暂停。如果这种问题不断累积的话，我们会发现一个更加严重的问题：开发很忙，因为有很多功能需要去做；而QA需要测试的功能也很多，但是却发现很多没法测试下去。
所以引入FQA这么一类人，他们跟开发与项目经理合作最紧密：
1.当功能还在开发的时候，先去写测试用例
2.当功能开始有Build可以测试的时候，FQA首先去介入测试，他的测试其实是为后面的正规测试做准备，所以要确保该功能基本功能能够工作正常，符合设计文档，发现了问题，需要直接面对面与开发沟通，快速修复，如果这个最初的测试无法通过FQA的测试，那意味着这个功能的开发部分工作还没有结束，无法让正式的QA团队去进行测试。（平常情况下，开发人员为了改进度，可能草草跑了一下功能就说做好了，导致以后发现很多问题，进而影响其他功能，影响整个进度，而FQA的出现，能让这种情况较少出现）
3.FQA测试完成后，开发人员可以正式把这个功能打到“待测试的状态”，让正轨的测试人员在各种的环境下进行更加细致的测试和性能测试。
4.FQA测试的同时需要根据需要更新测试用例，让之后的正规QA测试可以做些参考。
所以，用一句话形容FQA的作用就是：帮助开发人员去高质量完成开发工作，帮助测试人员去顺利进行测试工作，帮助产品的开发能够在可控的范围下进行。