前几天会上，有人提出在开发完成前，QA这边没时间提供用例，这可能会是一个风险。另一个人站出来说，开发完成的时间不应该受QA提供用例时间的制约。

在我看来，这两者并不冲突，开发人员基于自己的理解做实现，当然不会收到QA提供用例的影响。这里边其实有个核心问题，为什么QA要在开发完成之前提供用例？

从业务QA的角度来考虑，说白了就要保证提测质量。再往上走一层，其实是要提前暴露质量风险，识别风险也是QA的日常工作之一。

为什么QA要在开发完成之前提供用例？

1. 产品、开发、测试三方，需要一个机会再去对齐需求内容、确定最终期望，避免gap。

也许你会说，那就再开会对齐，如果再开会对齐，是以什么为基准？这里有3种可能性：
（1）修订后的需求文档
（2）开发的设计文档
（3）QA的测试用例

一个最基本的理论，问题越早发现，成本越小。

对于消除需求理解的gap，有些公司尝试做需求反串讲，也就是说PM做完需求评审之后，由非PM（QA、RD）基于对需求的理解做需求串讲，三方参与，就反串讲发现的gap做及时补充与修正。

反串讲，可以在开发/设计之前暴露需求问题，成本最小。它也有劣势，即RD和QA都未开始做设计，细节问题暴露不足，在做设计时，再遇到问题，还是要进行讨论和修正。所以在设计后，再进行一轮评审势在必行。

若以开发的设计文档作为基准去评审，在评审过程中，很容易陷入技术的漩涡，越走越深，以技术的设计的角度去解释需求，会使需求不聚焦，不利于需求的梳理和理解。

热知识： QA用例来源于两方=》一个将产品需求拆解，一个是根据开发的设计。

从这三者来看，需求文档更偏向于用户角度，开发设计文档更偏向于技术角度，只有QA的用例，介于两者之间，可以从用户角度出发覆盖技术变更，也可以从设计角度反推用户的行为。所以，以QA用例为基准的对齐会比直接对齐需求文档或者技术文档更加全面，更好着手。

用例评审给了第三方一个机会去说明自己对需求和技术的理解，这个环节PM、RD、QA都要参加，三方可共同探讨就需求、技术而产生的gap，有利于三方统一对齐，从而减少各方的理解差异。

此时你会说，QA用例评审时，可能开发已经开始了，如果需求有问题，那么成本会更高。是的，没错，如果可以，反串讲之后，再做用例评审固然好，一切都不是一成不变的，一定要不断的迭代。

2. 开发需要在测试开始前保证基本流程走通

开发往往更关注单元测试，但产品是一个整体，从入口到出口，最基本的流程是否能走通？交付给QA之后是否会block？

这里需要讨论：QA如何做质量保障？开发在质量保障中需要做些什么？

从比较狭隘的观点出发，QA就是测试，根据产品需求和开发文档，产出测试用例，提测之后执行测试，测试用例全部通过后，上线，再做线上测试。

大多数时候，QA确实在做这些事。但是QA能做的和要做的不仅如此。

QA要从全流程，每个环节去发现质量风险，提出质量风险，进而推动各环节人员、流程、测试方法等做改进，最终确保项目保质保量的交付以及产品整体的可靠。觉醒的前辈们也提出了测试左移与测试右移。这些high level的观点，需要不断的输出，才能对QA形成有益的循环，希望你的leader们可以经常输出 What is QA doing? Why we do that? 我相信你的日子会更加好过。

从全流程角度保证质量，要比单纯的把质量风险集中在测试周期内更加可靠、高效。调动全员参与质量保证也是QA人员工作的一部分，使每个人都能对质量负责。

所以开发该不该在开发周期内，保证主流程走通？
当然了！首先，他分散了风险。其次，单元测试、开发做简单的集成测试也是质量保证的一个环节。再者，做产品需求，开发需要对产品有一个整体的概念，执行一些P0级别的case，有益于理解产品需求。

但我相信，就算再花言巧语，其他人也不会全部认可。

这时候有些RD会说，没有时间！那么QA在确定排期时，需要提出增加这部分自测的时间。如果大家都挤不出时间，那显而易见，这次交付的质量风险会比较高，QA需要提前周知到质量风险。

还有人说，我们又不是QA，不是专业的测试，执行case干嘛？测试是你们的事情。看到了么，普及质量保障意识是多么重要的一件事，但我真的无法保证用什么方法论或者说什么话做什么事，可以轻而易举的使对方认同你，对于不同的人，我们要做不同的事，用不同的方法，想扭转一个人的观点很难。有些人的观点里，开发就是要做开发，最多做个单元测试。但是QA可以从很多角度去影响他们，比如新人培训时，增设质量保障相关课程，在开发一入职就培养质量思维；比如了解开发leader们的想法，看看他们对此的态度，再决定下一步你该做什么；比如定期向外界输出 What are we doing? How can we test best?；比如了解别人的困难，适时提供帮助，不要让人以为你总是找麻烦的那个；比如找一些容易的切入点，以点带面，让大家看到全员质量保障的优势；比如做一些数据统计，以实际数据支持理论开展；比如硬性的定一些规则，必须执行，等等等等，做你能想到的任何事。

还有一部分开发质量意识极棒，做为QA你可能又感到压力，如果每个开发都具有非常好的质量意识，代码质量极高，QA又能够多做哪些事呢？说到这，我们又聊到了职业自信，哈哈，QA大概是最不自信的那一类人，有两种说法，角度不同，其实是一个意思，我们比开发更懂产品、比产品更懂开发；我们没有开发技术好，也没有产品的产品思维那么敏锐。一种是积极向，一种是消极向。讲真，我一直是消极向。但是不可避免的，我们要在职业发展中找到自己的优势所在，比如在同工种中，你的优势是什么？比如在不同工种间你的优势是什么？以后单开一个小作文，聊一聊职业优势吧。

假如质量引导做的不好，并且流程还没建立起来，如果有人challenge说，我们不要做冒烟测试，不要执行用例，希望大家不要生气，也不要撕x，强势的推广只存在于开发领导们的大力支持下，有时候我们需要一些纵容，并记录这个过程中的艰辛，最后形成总结报告，提交给项目经理或开发经理，通过真实的数据共同探讨下一步我们如何优化流程。一次两次，不断的总结，不断地探讨，坚定不移我们的决心，相信最终会影响到其他人。万事开头难，做QA更难。

还有一个点需要讨论：什么时间提供测试用例最好？

在我看来，一定是详细的需求评审结束，开发的技术评审结束，QA就可以开始着手设计测试用例，完成之后立即做用例评审。
其实大部分互联网公司也都是这么做的，还有些公司技术设计评审做的不够好，这点也许会需要一些时间去沟通。
为什么说这个时间最好呢？这个时间相当于开发才刚刚着手开始，改动成本相对不高，在用例评审时发现的问题，比如需求不合理，需求遗漏，设计不合理等都可以迅速的改正。越到项目的后期，修复的成本越高。

题外话

做了很久测试之后，发现很多时候，观点的对齐花费的时间、精力要比执行起来难得多，当大家各执一词，你如何说服对方？对方有很多，比如你的其他QA同事，与你合作的RD、PM，你思维内觉得一定要这样做的事，并非所有人都会同意，在推广一个流程或者工具之前，你准备好会遇到的各种难题了么？有获取到老大们的支持么？是否有提前调研到QA和RD同事的接受度？

讲一个在某公司（大厂）的真实故事，longlongago，some QA定了一个rule，冒烟用例不超过3条，后面我们有机会一起讨论一下，那些年你遇到过的奇葩规则以及如何去打破这些规则。

测试发展至今，大家都在谈自动化，每个QA似乎都要写的一手好代码，RD也不再向早前几年，觉得QA只会点点点。业务QA的日子越来越好过了。测试工具开发也逐渐向成熟的方向发展。当前有些公司将测试工具开发与业务QA彻底分开，业务QA不再需要承担工具开发的任务，只需要专注于业务测试，深入业务，挖掘业务的质量风险，从全流程做质量保障。需要工具给工具开发提需求，工具开发做纯开发任务以及给业务QA提供技术支持，做提效工具，以及从技术角度做质量监控与风险暴露。下一回，想和大家谈一谈职业发展。

虽然遗留了许多工具建设的坑，但我想认清前面的路更重要，认识自己，找准自己的路。

欢迎留言～