制定合理的软件测试流程(2)

其实公司内软件测试一片空白或者测试流程比较完善的公司流程制定和执行相对来说都会比较容易一些，如果是一片空白你可以完全按照自己的想法去建立软件测试流程，剩下的困难只是如何去说服领导和开发配合这个流程。如果软件测试流程已经比较完善，大家对软件测试已经有了一定的支持和理解并且现阶段运行良好，你只需要在一些小节上进行一些修改，如果的确有利于工作会得到大多数人的支持。最难制定的是软件测试刚刚起步有了一些不成型的测试流程，也许不太符合你的想法也许不太适合公司的实际情况但的确在公司运行了一段时间，如果想改变不光要说服测试部门以外的人还要说服测试工作人员，增加了工作的难度，如果公司是这种情况请大家在制定软件测试流程前更要慎重考虑，详细了解公司的情况。

　　制定软件测试流程时可以参照一些比较完善的软件测试流程，但切忌不可照搬这些流程。我们经常会遇到这样的情况，如果在测试工作过程中碰到一些问题有人会说如果在微软或IBM公司是这样处理的，我们也可以这样。但是我们的工作环境和这些公司是不一样的，测试的思想已经深入贯穿到他们开发的每一个步骤中，而我们目前大多数公司的软件开发过程并没有达到这样的程度，我们大多需要解决的是在测试思想还没有贯彻彻底的公司我们怎么处理这个问题。无论是软件测试刚刚起步还是已经有了一定软件测试团队规模有多年软件测试经验的公司，都有一些属于自己公司特定的测试方法和流程，就是完善的软件测试流程也各有各的不同，IBM和微软在测试流程肯定是有所差别的。如果将他们的流程照搬过来，没有给公司同事一个慢慢接受消化的过程，很容易适得其反甚至引起公司同事的抵触情绪。这里并不是说这些测试流程不好，只是这些测试流程也不是一开始就建立起来的，而是通过多年的经验和教训逐步完善一步一步慢慢建立的，并且现在它们仍在进一步完善中。我们不仅要学习这些完善的软件测试流程是什么样的，我们更要学习为什么制定这套软件测试流程。给人金子不如给人点金术，也就是这个道理。那些软件测试流程比较完善的公司走在了我们的前面，我们就要学习他们这一路走来的经验和教训，避免走他们走过的弯路，缩短完善公司流程的时间。

　　制定软件测试流程要明确测试部门的职责。经常会有测试人员抱怨自己在公司里就是一个打杂的，什么工作都要做，其实这就是职责不明确引起的问题，这样会很大程度打击测试人员的工作积极性影响工作情况进而影响大家对软件测试工作的看法。一些如写用户手册、给用户培训等工作在公司里如果没有专门的部门来做，就很容易推给软件测试人员来做，但是都没有明文规定而且在对软件测试人员进行工作考核时又很容易疏忽这些工作，而且这些工作有时候看起来不太起眼，但是需要耗费大量的时间。所以我们要明确制定软件测试部门的职责、软件测试人员担任的工作内容，其他一些工作如果由测试人员来做，就要在制定软件测试计划中明确写出这些工作需要的时间，以防止这些工作占用测试时间，使测试人员陷于被动之中。

　　制定软件测试流程不光要制定软件测试部门内部的工作流程，更要制定与开发部门、需求部门等外部部门的接口工作的流程，一旦项目在进度、功能上有了变化要及时和测试部门沟通，不要让测试部门成为最后一个知情人。

　　另外在具体执行测试流程时要注意执行的效果，将测试工作落实到实处，而不是为了走过场证明测试工作已经达到了某种程度，否则再好再适合的流程也不能起到它的作用。例如大家都一致认为测试应该从需求开始介入，但是从需求开始介入并不是测试人员参与了需求评审会议提出一些问题就达到了目的。而是要求测试人员在开发把产品开发出来前就要了解这个产品都要实现什么功能，虽然不知道开发怎么去实现这些功能，但是要知道实现了哪些功能。因为在产品在开发提交测试之后往往由于产品一些基本功能没有实现，使测试人员很难深入的对产品进行业务流程的测试，所以一些重大的流程问题往往在测试的后期发现，但是这时可能离产品提交用户的时间很近了，开发人员修改这个问题很可能会引发其他的问题增加产品的风险，而且一些开发还会抱怨为什么测试不早发现这些问题，还有可能使公司怀疑测试人员的能力，让测试工作的开展受到一定的阻碍。只有越来越熟悉产品才会发现越来越深入的问题，这是一般的发展规律我们难以改变。但是如果我们前期对产品需要实现的功能有很深的了解，前期就可以提前设计一些业务流程上的问题，一旦产品基本功能可以完成就马上进行业务流程的测试，使这个过程大大缩短。

　　制定合理的软件测试流程是一门很深的学问，它需要制定者有丰富的软件测试理论知识，软件测试执行经验、管理经验以及沟通能力等等多方面的经验能力，还需要许多测试人员经过长时间的实践来验证完善，仅希望此文对大家有所启发。