缺陷修改引发问题的思考

 

在2013年5月版需求测试过程当中，我遇到“缺陷修改引发需求变动”和“其余条线的缺陷修改引发另外一条线的出问题”的两种状况，对于这两种状况，处理方法具体以下：

一、缺陷修改引发需求变动

原需求：当天到期或已过时的票，银承自动解付任务流经中心岗后，没有直接提交主机记帐成功，还要手工解付后才提交主机记帐。此作法让操做人员重复工做，效率很差。

后来通过开发人员和业务人员沟通，程序须要修改成：当天到期或已过时的票，银承自动解付任务流经中心岗后，直接提交主机记帐成功。

出现此种状况，开发人员没有提供最新需求说明书，而且没有邮件通知测试人员。

此修改，将会涉及到：需求变动、测试用例修改、工做量增长等状况。

 

咱们测试人员具体处理方法以下：

一、           需求变动：提醒开发人员或需求分析人员须要修改需求说明书。要邮件通知测试人员、业务人员等相关人员，而且提供最新的需求说明书。

二、           测试用例修改：测试人员要根据需求变动内容进行测试用例修改，评估工做量，若是工做量太大，则要上报组长。

三、           工做量评估：若是工做量超过3天以上，那应该上报，要走需求变动审批流程。

 

面对这种状况，我以为测试人员须要多思考多分析，及时上报。

面对这种状况，建议开发人员可以有意识地修改相关需求说明书及通知相关人员。

 

二、其余条线的缺陷修改引发另外一条线的出问题

在5月版需求测试过程当中，遇到一个问题：同城需求的缺陷修改，把银承的挂起任务程序改错了，形成银承自动解付的任务不能挂起。此问题涉及到平台公共部分的程序。

这种状况，开发人员不知道本身改错了。

同城对这个缺陷验证的测试人员也分析不到此问题会影响到其余条线。

 

咱们测试人员的处理方法有以下几种方法：

一、 若是缺陷涉及到平台公共部分的程序，则缺陷验证的测试人员要思考下或是验证缺陷之外涉及的其余条线交易。若是缺陷验证的测试人员对其余条线的交易不熟悉，那能够邮件通知其余条线的组长安排人员验证。

二、 测试人员多学习平台各条线的交易。这样测试人员在测试平台公共部分，就会全方面思考啦。

三、 各条线派出表明人对平台的测试人员作培训。

 

面对这种状况，我以为测试人员须要多思考、多分析、多学习。

面对这种状况，建议开发人员在修改缺陷时多分析缺陷的修改涉及面，特别是平台公共部分程序，若是涉及到多条线的程序修改，那请在缺陷修改说明中描述出来告知测试人员。