转载：测试人员参与评审的目的不只是为了学习

测试人员尽早参与项目，是软件测试中的一个基本原则。但是，在测试实践中，测试人员的尽早参与常常是为了学习，例如：理解了测试对象之后进行测试用例的设计，而将尽早发现其中的问题和缺陷的目的放在了较低的优先级。这实际上很大程度上违背了评审的初衷。

　　下面通过笔者实际经历的一个案例，阐述这样的一个观点：测试人员参与评审，其最主要的目的是尽早发现其中的问题和缺陷；当然学习也是一个目的，但是学习的目的是为了更好的理解和设计测试用例，而设计的测试用例，其主要的目的是更加有效的发现测试对象中的缺陷，以提高产品质量。而在测试执行过程中发现和修复缺陷的效率会比评审低的多，而成本将高的多，该方面的信息，可以参考博客中的另一篇文章“用数据说话：评审如何降低成本、提升质量和帮助过程改进”。

　　案例中功能的简单描述：登陆某个系统，例如：某个网站，首先需要创建不同权限的用户。不同权限的用户，其对系统操作的内容是不一样的。本案例中，用户的权限UAP（User Access Privileges）分别定义为CONF、PROV、ADMIN、DEBUG和READ五种类型。

　　针对用户权限UAP的选择，系统的需求是这样描述的：创建的用户UID（User Identifier），可以为它们分配不同权限的UAP。但是，每个用户的权限UAP都至少包括READ权限，即每个用户都需要有READ权限。图1是用户权限UAP进行选择和删除的简单示意图。

图1 用户的UAP选择示意图

　　在开发人员实现该功能的过程中，包括图1的界面设计上，尽管测试人员都参与了评审，但是测试人员由于时间、资源和理念方面的原因，仅仅只是定位在功能的学习和理解上面。等开发人员将功能提交给测试人员之后，测试人员在测试过程中发现了下面的几个缺陷：

　　● 默认得UAP权限READ可以被删除，即在图1中，右边方框内的Read-only（READ）可以被移除；

　　● 假如在修改用户的属性时候，再选择一次Read-only（READ），那么修改之后的用户权限中会出现两个Read-only（READ）的条目，如图2上半部分所示；

　　● 假如在修改用户属性的时候，只选择了除Read-only（READ）之外的其他权限UAP，那么修改之后的用户权限没有了Read-only（READ），如图2所示的下半部分；

图2 用户的UAP缺陷示意图

根据系统需求中的描述，每个用户的权限都至少包括Read-only（READ），因此，上面的3个问题都应该确认为缺陷，测试人员分别都提交了缺陷报告。

　　在项目结束之后的总结会议上面，笔者就针对该功能的实现和GUI提出了自己的想法：假如在开发人员具体实现阶段，测试人员将评审的目的更多的放在发现缺陷上面，开发人员尽早修复其中的问题，那么该功能的实现可以更加简单高效，而测试人员后期的工作量也可以大大降低。笔者的建议包括：

　　● 根据需求的描述，Read-only（READ）应该作为每个用户UID必须具备的权限，因此将Read-only（READ）作为每个用户的默认值，不允许进行增加、修改和删除等动作；

　　● 根据上面的建议，在该功能的图形化，如图1所示中，将Read-only（READ）选项移除，因为改选项已经通过内部代码实现了，不需要操作人员进行选择。

　　假如测试人员在评审过程中发现了上述的问题，并根据上面的建议开发人员进行了修复，那么，在软件实现过程中，可以获得下面几个好处：

　　● Read-only（READ）作为每个用户的默认值，不允许增加、修改和删除，那么，在图1的示意图中直接删除Read-only（READ）选项，可以简化示意图；

　　● 按照上面的思路，代码中就可以省略针对Read-only（READ）异常处理，例如：在修改的时候，不需要判断用户是否重复选择了Read-only（READ）选项，或者没有选择Read-only（READ），直接可以节约开发人员的代码异常处理的工作量；

　　● 而对于测试人员，由于前期参与评审工作，发现了其中的一些缺陷，提高了代码的质量，可以减少后续的测试工作量；

　　假如测试人员、系统人员和开发人员在实现该功能之前，认真仔细的评审了具体的实现，那么，我相信上面碰到的问题就可以避免在系统测试过程中才被发现。另外，系统人员、开发人员和测试人员在针对该功能的评审过程中，除了可以避免将这些问题和缺陷引入到工作产品中之外；还可以帮助大家对功能的实现和期望结果有了更好的认识，并更加容易达成一致。这是不是可以更好的实现在整个团队内部的知识共享呢？