呵呵，又当了一回标题党。

　　这里说的逆流而上不是说什么东西在下滑而测试在上升，想说的意思是逆流程而上。

　　不少同行们对于测试还是有很多的疑问，常见的一个就是关于QA（软件测试人员的一种称呼）的value的问题。如果只是在软件开发好了之后去找问题，或者验证，那样value究竟有多大？

　　这是一个很难回答的问题，因为最大的难点在于各个不同组织的状况、需求、认识，还有所处的阶段。

　　这里基于个人的经验和思考说说我自己的一些看法。

　　从我看到的一些资料，最早的软件测试比较类似于debugging，就是程序运行出错之后去调试，很多时候应该是developer自己去做的。然后边调边去验证，某种程度上也不算是现在所谓的测试。

　　后来，测试往前走了，在交付使用之前，在内部先验证是否可以使用。这个时候，整个开发过程已经结束了。测试是针对整个系统的测试。

　　再往前走，就是在整个系统没有完成，而部分功能完成的时候开始测试，这是功能级别的测试，是我们通常所说的功能测试。

　　进一步向前，在一小块代码完成之后就开始测试，就有了单元测试。

　　如果很多时候一开始的设计就是有问题，那也不太可能做出正确的产品，所以就有了设计和SRS（software requirement specification）的测试，这种测试开展的形式是review，就是对于产品spec和design的评审，看是否满足要求，是否合理，是否有可测性等等。

　　结合我们的实践来看，从前面的测试过程走到这一步是有很大的益处，对quality的提高非常有帮助，及早的发现和阻止了很多问题，也帮助大家一起很早的时候就想到很多问题。而且如Weinberg在《完美软件》第16章中所说的，“即使测试人员真的不能在评审过程中找到缺陷（事实并非如此），他们也可以从评审的经历中学到一些东西，评审最大的益处是以下列某种方式提供知识。”。 是的，不仅是测试人员，整个team都从这个review（包括大量的Q&A和讨论）的过程中对产品的认识和理解变得深入，而且使得整个team对于将要实现的产品有了一个很清晰的认识。也正是因为效果如此之明显，这种测试（review）已经变成了不用要求的自觉的process。

　　最近开始去做一个全新的项目，除了很陡的学习曲线可以快速的学习新的东西，也使得对测试有了一些新的看法。其中一点就是再次把测试往前推了。因为是1.0，很多东西都不明确，包括一些需求。在这个时候，我作为QA参与进去，参与到需求的讨论，还有可能的技术方案，有一些自己的意见融入进去。整个产品在大家的这样不断的讨论，prototype的打磨之下开始慢慢成形。我相信对于提高整个产品的quality，包括项目的开展和实施这样的参与也是有帮助的。

　　从这个角度，QA的参与和贡献再次被提前，提前到项目最开始的地方。

　　到这里，QA能够参与和贡献到项目的阶段是整个的流程，而不只是时候的验证。很多的限制其实是我们认为的思维的限制。想起公司的一位老大最近讲到的一个故事，关于浙江和江苏的企业的不同。江苏很多是国企，中央让做什么就去做什么，而浙江很多是民营企业，他们的逻辑是，没有说不可以做这个，那就去做。在工作中的很多时候，特别是对于测试这样一个相对还比较新的领域，我们也要有这样的探索精神。