价值驱动下的敏捷测试也应该保持测试的严谨性

在敏捷项目中，我们经常听到 “价值” 这个词，我们围绕“价值”制定原则，围绕价值进行开发和测试。在敏捷测试中就有一条非常重要的原则“使业务价值最优化”。然而在这种业务价值驱动的测试中，我们往往把非核心业务价值等同于“不重要”，从而丧失了测试本身应该具有的严谨性。 最近在产品环境下出现的一些问题，让我深深体会到了这一点。

最近在产品环境能中遇到这样两个问题：

1 客户内部管理员网站出现了性能问题，在数据库数据量不大的情况下出现了需要几分钟才能加载页面的情况。

2 用户订阅的某些字段无法退定

其实这两个问题我们在平时测试的过程中都碰到过，对于第一个问题，因为是内部管理员网站，不是最终用户网站，所以我们认为稍微差一点的性能是可以接受的，我们可以把精力放在更有价值的地方。于是在没有调查导致性能问题的根本原因的情况下，把这个问题直接忽略了。 这次因为加载太慢，导致客户管理员网站无法使用，才开始调查原因，悲催的是，我们发现访问返回时间居然随着记录量几何倍数增长！一个明显而又严重的错误。对于第二个问题，我还清晰的记得，当我们在本地环境上遇到这个问题的时候，大家理所当然的认为是测试数据出现了问题，这种数据在真实环境下不会被写进数据库，修这样一个问题是做没有价值的工作。
然而，当在产品环境下出现这个问题的时候，我们发现用户的一个小小的非正规操作，就产生了这样的数据，而我们的程序无法涵盖这样的逻辑。 哎，真想找个地缝钻了。

在产品环境下出现问题，像我们这样的交付项目，无疑会影响客户对我们的信赖。然而看着这些问题，各个都似曾相识，而却没有在合适的时候把他们给找出来并且修好！现在反思一下，是什么原因导致了这重情况，我发现我错误的把非核心业务价值等同于了“不重要”，而且我发现项目组中有很多人都犯了和我同样的错误。这对于测试来说是一个非常危险的信号。

其实现在想想，敏捷测试中价值核心是一个很好的原则，而对于一个defect或者是潜在的defect，我们首先应该考虑的是它的严重性和它对系统所造成的影响。而要定义它的严重性和其影响，我们首先需要做的是找到导致错误的根本原因。一个defect在找到根本原因之前，我们不应该对它做任何定义，这就是测试的严谨性。无论是否在敏捷项目，这种测试的严谨性，我们应该始终都要保持。