测试管理中走流程是否就一定好?

rbzzp

在我们工作中,可能因为种种原因,没有做到,从一立项就开始介入项目,参与需求调研、参与需求评审、写测试计划、写用例，然后到执行测试。
我做了几个新项目，虽末参与需求调研，但还好有需求文档，看着需求和项目计划，或常与项目组成员沟通写了测试计划和用例，但在测试时，却发现不是那样实用，用了部分用例进行测试，后来就没用了，只是手工测试，参照着需求，再做一些边界等什么的测试。
希望和大家共同讨论怎么做测试，怎么管理测试会好一些？虽然我们总是在说写用例的种种好处，但当需求变更频繁，或需求写的不够详细完整，是否能写出优秀的用例来？是否有更好的方式解决现在测试状况呢？

[ 本帖最后由 rbzzp 于 2007-8-2 15:24 编辑 ]

xiongxing

不一定吧，最好看情况而定．

velata

需求变更控制好难哦
我们有规范
但到最后都做不到
可以说完全没有控制

archonwang

y严格遵循需求变更委员会关于需求变更控制的建议，这样的话至少不会出现测试与现时需求脱节的情况，所不同的是，需要注意如何合理安排变更的周期，这点是很重要。

rbzzp

楼上说的有道理.
我一直在想能否找到一种更好的方式,解决目前测试状况.需求常变更,测试的系统种类较多,有项目,有产品,有产品定制.需求并不能很好的指导测试,只是体现了事件流程.

ycxlove11

楼上说的好详细啊，鄙人小说2句：调研比起不调研肯定是有优势的，写的用例一定会详细很多。再者没有一个完全正确的套路可以走，测试的过程我想应该是灵活多变的。

archonwang

首先，在项目立项时，必须建立一个职责明确的组织架构体系
再，建立对应阶段的流程，必须不断完善他们
三，建立变更管理控制委员会
四，优秀的用例并不是来自详细的设计，而是能否发现更多更严重的错误


我的建议是：

一，项目管理层建立变更控制委员会，处理变更事宜，确立发布标准和版本更新制度。以减少和控制频繁变更对测试的影响；

二，关于测试案例，需要在需求确定的时候进行范围的圈定，根据这个范围的圈定内容细化到各个具体的案例。测试案例无效一般都是由于修订不及时造成的！没有按照测试案例进行测试是不正确，它完全否定了你前面的关于测试案例的工作；修改不及时更是一大原罪，它造成了测试案例无效的直接元凶。

三，需要强调的说，所谓文档，只是一个过时的标准，需要不断根据变化进行更新升级。所以，测试计划和测试案例的变更修改是很正常的事，没什么事情是一劳永逸的。需要在流程中改变这种一劳永逸的心态。如果你可以做到计划每天更新，测试案例的每阶段更新，基本上算是做到位了。必须养成习惯，心里要有这种观念！

四，强化执行的跟踪，加强检查。对于测试组的组长，team leader，需要明确真正的执行工作只占你的少部分工作，更应该把精力放在计划资源合理安排，改善流程，增强沟通、加强培训等非技术层面。