产品与测试

    产品，顾名思义，就是负责写需求文档，画模型图的人，平日里就周转于客户与本部的研发组之间，其实特别繁忙

    测试，如名字一样，平日里测试开发写出来的代码，将其实现的效果与产品提供的需求文档进行对比。而大部分公司在技术总

监或者老板的影响中，将其独立出来变成了质量部门。这种模式在不同的公司都有不同形势的体现，包括现在发展起来的大型公

司尤为突出。

    两者要说共同点，大部分的共同点就是研究需求。从客户到产品，到开发，再次到测试，中间会涉及到2次交流的过程。彼此

之间通过文档或者一些形象的图标进行交流，有工作经验的产品，一般都能做出很美的文档和模型图，但是这种模式却有很大的

缺陷。从客户到产品，从产品到测试或者开发，这中间就有了2次的信息沟通，就这个信息交流的过程就会导致你想要的并不是

客户想要的，从而造成产品质量的下降。那么什么才是正确的研发流程，这个是应该考虑的，不过现在大部分公司照搬的就是这

种模式。产品失败之后，产品部回复一般都是开发不按照需求文档来写。

    经过一两次的教训，很多公司有意识地会在研发流程中再次引入产品测试的流程。比如开发完了之后，第一波先让产品测试，

测试完了之后再让测试来测试。其实这种研发模式还是错误的，毕竟测试会按照边界值或者等价类划分的角度来测试，测试出来

发现，原先的设计是有极大的漏洞的，由此可能会引发需求修改。这种现象，在研发组内部的显现也是极为突出的。

    那么正规的流程是什么呢。还是应该是这样的 客户-需求-开发-测试-产品同学测试。 按照这样的流程来走。宁可多招收一些

产品经理，至少要有一个人能从头到尾跟踪项目，这样，产品部的也能对做出来的东西做到心中有数。也避免了测试遗漏导致线

上出现低级错误的情况，可谓是一举两得。那么测试平日里也可以串行 做产品做得事情，比如写需求文档，写用户手册，等等。

但是还是那句话，至少有一个人能完全从头跟踪到位，做到对整个项目的需求修改以及前因后果能有完整的了解。

    楼主现在所在的公司，测试已经和产品完全融合，这种模式确实是可以带个整个项目组很大的正能量。多半时候，能够做到相

互体谅，一个和谐的工作环境能最大的 发挥一个团队的凝聚力，爆发力。测试不再是背锅侠，开发也不再是背锅侠，因为开发是

给产品擦屁股，测试给开发擦屁股，而测试后面应该是需要有产品来擦屁股的，这样形成一个闭环，俗话说，人无完人，金无赤

足，我们要的不是特别牛逼的个人，而是特别牛逼的团队，这就是一个团队。