接着上篇《敏捷测试四象限之一二》，这里主要讲下剩下的三四象限。
这篇就没有上篇那些吐槽生活中的小例子了。
在四象限图的右边部分，区别于“支持团队”，主要目的是来“评价产品”。
所谓评价产品，就是以用户体验的角度去测试系统 —— 在测试中尽量重现最终用户的实际体验，或者如beta测试，直接邀请终端用户参与测试。
第三象限，“面向业务”、“评价产品”的测试
面向业务的测试实例帮助团队设计期望的产品，但可能业务某些测试实例本身是错误的 —— 业务专家可能遗漏了某些功能；或者是因为该功能不是他们的实际领域、并没有正确的了解这个功能；团队误解了某些实例；开发编写的代码可以通过之前一二象限的测试，但并没有产生客户想要的东西，等等。
这就是使用第三象限测试的地方。
第三象限中测试的主体，是手动完成。
当然，如果没有将象限一和象限二中的测试实现自动化，那么测试人员根本没有时间进行第三象限的测试。
而对于第三象限的测试，实现自动化是很困难的，因为这类测试依赖于人们的智力、经验和直觉。
比如，探索性测试，就是敏捷测试中，对于用户故事测试和自动化回归测试集的重要补充。
使用探索性测试时，首先，测试人员对现存系统有整体了解，然后，不按照原有的验收测试项剧本，将“测试设计”、“测试执行”和“学习”同时进行。最终能设计新的测试，并能引出不少对新特性的想法，而这些新特性往往会演变成新的故事。
可用性测试。注意这里是Usability，不是availability。后端开发人员估计第一反应是后者。
这里的第三象限的可用性测试，是指对于用户来说的可用性，包括 —— 是否易于学习、记忆、操作，是否提升用户效率等等。
UAT、alpha、beta 测试，都算是用户验收测试，基于系统的全量评测，发现并反馈问题，修复或者获取新的用户故事想法来以此改进。
由于本人作为一个开发人员，参与的不多，就不仔细描述了。
第四象限，跨功能性需求测试
第四象限的目的是评价产品的跨功能性需求，比如性能、安全、可靠性、可扩展性等等。
这是一个敏捷开发比较容易忽视的测试维度。
为什么会忽视呢？
其中一部分原因是 —— 敏捷流程中一个很重要的步骤是，让业务（PO）编写用户故事并对其优先级排序。一般非技术的业务团队成员通常会“假定”开发人员会考虑性能、安全等因素，但开发们只是专注于客户给出的优先级高的功能。
而有时候跨功能需求可能比实际的功能更重要。比如，如果一个在线商城的响应时间是一分钟，那么客户将不会等待欣赏它的任何功能。
因此，应该在开发周期的每一步都要考虑评价产品的面向技术的测试，而不是留到最后。不然，可能会太迟而不能修正这些问题。在很多情况下，这些测试甚至应该在功能测试之前进行，比如性能指标的不同，会驱动出不同的技术解决方案。
跨功能性需求，最好准备一个核对的表单，让团队对其有所了解，同时也能让 PO 给出每项的重要级别。开发团队有义务解释清楚不重视这些跨功能需求所导致的后果，PO 应该仔细思考所有这些重要质量因素并进行权衡，必要时候，在涉及的功能、用户故事上对其进行特别强调。
最后，具体第四象限的执行，团队可能需要借助固定专家的帮助，比如DBA、安全小组等，同时也会使用一些开源或者需购买的工具来完成。
最后
终于将敏捷测试四个象限写完了。
至于作为一个开发人员，为啥会跑去写一篇测试的博文、还跑去把《敏捷软件测试》这本书翻了一遍。
其中最主要的一个原因是，想要让开发人员充分了解“质量”的重要性，专注于质量。
而“质量”，对于开发团队来说，是用来获取客户信任的一个重要政治资本。
另外，敏捷测试每个象限其实承担了保持“技术债”在一个可管理的水品的角色。
