好吧，如果我们的产品连这些不言自明的要求也考虑到了，那么是不是会被认为质量很好呢?不一定。
　　Quality scope#3：设计符合用户的需求
　　在scope#1中，我们提到好的质量的起码的条件是实现了宣称的功能。那么引伸出另一个问题是，设计本身是合理的吗?
　　如果我们把developer定位成实现所需要的功能的人，把QA定位成验证这些功能是否正确实现了的人，那么这一部门的质量我们没有办法覆盖到。因为如果是这样的定位，大家不会去想，这样做合理吗?是用户想要的吗?做出来用户会喜欢吗?反正我们只要按着spec做出来好了。
　　这样的例子其实也有很多，比如
　　1.by design，我们只支持IE浏览器。但是我们发现很多用户都在使用Firefox和Chrome。
　　2.我们的邮件历史查找只支持按收件人，现实中有很多用户也需要按发件人来查找
　　3.如果用户重装系统的话，需要把曾经在老系统上配置的policy一条条重新配置，包括white list和black list。
　　4.如果中途网络断掉了，用户前面输进去的东西下次联网后要重新输入。
　　类似的例子我们还可以举出很多。这些问题有什么共同点呢，那是用户会抱怨我们的系统质量不够好，会给售后服务部门提一个case过来，提出他们的合理(从他们的角度确实是)要求。
　　如果我们的软件测试只停留在验证功能的角度，这些问题都不是问题，因为直接被我们排除在工作范围以外。但是终这些问题都会被用户遇到，而且形成一种印象，那是我们的产品质量不够好，特别是当竞争对手能够做到的时候。这会形成一个gap，我们内部测试的时候觉得质量很好很稳定，但是用户还是不满意。
　　要解决这样的问题，可能有两个方面的要求
　　1.测试人员(其实也包括开发人员)应该更多的从用户的角度来考虑问题。也是常说的customer insight，从这个角度我们不是完全被动的按着spec走，而是可以challenge它，为什么做成这样，至少要知道为什么。
　　2.测试人员要往开发流程的更前面走，而不只是等到产品做出来了之后去装起来验证。那样太晚了，而且修改的成本比早期要高很多。测试人员一开始应该参与到产品的设计中，并且从用户的角度给出自己的意见。当然，这一部分也依赖于domain knowledge和个人的经验。
　　以上两个方面，对测试人员来讲，是挑战，因为要求更高了，也是机会，因为工作更有value了。
　　到目前为止，看起来我们的质量范围已经比较完整了?not yet。
　　Quality scope#4：处理异常情况的能力
　　说到这个问题，还是举个例子吧。很多人可能对nokia手机的抗摔能力印象深刻，自己遇到的或者听朋友说的。常见的情节是这样的，一不小心从桌子上，或者从楼梯上把手机摔了下来，然后盖子摔开了，甚至电池也掉出来了，这时候心里拔凉的，但是抱着侥幸心理把它们重新装到一起，按下开机键，everything is OK，然后很happy。这种故事的后续是很多人因此第二次，第三次称为诺记的用户。因为觉得他们的手机质量很好。
　　这个故事有趣的地方在于说明书上从来不会写我们的手机从楼梯上摔下来不会有问题，厂家估计一般也不敢写。从楼梯上把手机摔下来是一个异常的情况，也不是产品针对的场景，严格来说摔了之后坏了也属正常。但是反过来，如果这种异常的情况下，都没有问题，会让人觉得质量很好。所以是一个质量加分的地方，也是branding build up的地方。比如你可以(以前?)不小心把水倒在Thinkpad的键盘上，也可以踢到macbook的电源线。
　　从软件的角度，异常的情况也有很多，比如
　　1.突然停电
　　2.硬件故障
　　3.操作系统故障
　　4.网络连接意外中断
　　5.系统资源(内存，硬盘，网络端口等)耗尽
　　6.用户的误操作
　　通常情况下，这些情况都不会发生，但是还是会发生(墨菲法则)的。如果只是一个PC上播放MP3的软件，遇到上面的情况出问题了，甚至不能恢复需要重装，也许还是可以接受的，毕竟不是很重要的任务，而且也不常发生。但是如果是很重要的软件系统，而且有着重要的数据，不能恢复问题大了。
　　对于这一部分，我们都应该考虑到，不管是开发还是测试。在测试的过程中，我们也要尽量的去验证。