13.5.2 纯软件测试方法在Sprint中的运用
下面来讨论在一个Sprint中如何运用软件测试的本质“测”与“试”来进行测试工作。假设一个Sprint为1个月，即22个工作日，把这22个工作日分成前、中、后三部分。前（第1个工作日到第7个工作日），中（第7个工作日到第14个工作日），后（第15个工作日到第22个工作日）。
在Sprint前期测试人员的主要工作为书写这个Sprint 新功能的测试用例，这些测试用例可以是自动化，也可以是手工的，并且在这些测试用例中，以证“真”的“测”的方法为主，证“伪”的“试”的方法为辅。在这里测试用例没有具体的格式，目的只要可以给相应的开发人员看懂就行，关键需要关注的是对新特性的覆盖度。从第二个工作日开始，在每日站会后，测试人员把他们前一天写的测试用例交给相应的开发人员，与他们进行一对一的评审，由于测试用例是每日提交的，所以评审的时间不会很长。一旦通过评审后，这个测试用例就交给开发人员了。开发人员在开发期间需要100%达到这些测试用例所希望的结果，并且根据开发人员的自身需求，在适当的时候执行测试用例。
在Sprint中期，测试人员主要工作专向基于经验的探索式测试和非功能性测试，在这个阶段，主要运用证“伪”的试的方法。而开发人员的主要责任在重新运行一遍交给自己的测试用例，以及对缺陷的修改。
在Sprint后期，开发人员协助测试人员一起完成回归测试，开发人员按照以前的测试用例执行测试，测试人员仍旧以探索式方式来测试，以保证整个Sprint结束是一个高质量可交付的产品。一旦发现缺陷，开发人员优先回去修改缺陷。
13.5.3 纯软件测试方法与软件质量的关系
谈起软件质量，肯定就会想到ISO 225000标准（参见第一篇第1.1.9节），软件质量可以分为功能性、可靠性、易用性、效率、信息安全、相容性、维护性与可移植性八个方面。
功能测试是指测试软件所具有的功能，软件的功能一般都会通过《需求规格说明书》或《用户故事》来说明，所以功能测试主要是验证软件是否满足用户提及的功能需求，属于验证，证“真”，所以功能测试为“测”的范畴。
可靠性测试主要试验软件在错误情况下的应变能力，比如断网，断电后的恢复能力，对非法输入的处理能力等。所以可靠性测试属于证“伪”，所以为“试”的范畴。
易用性测试主要检查软件是否好用，易用，易用性一般没有真正的需求，而且某些易用性与人的性格有关。但易用性测试主要检查软件是否存在大多数用户不容易使用的部分，比如重要功能需要点击三次鼠标才可以方现。所以易用性测试为“试”的范畴。
效率即为性能，在有些需求中有相应的性能需求，比如在大多数并发条件下，首页必须在二秒内显示完毕，二，三级页面在五秒内显示完毕，叶子页面在七秒内显示完毕，这种性能测试为“测”的范畴。而大部分测试需要找到最大负载点，最大数据饱合量，最大吞吐量，对于这样的性能测试则为“试”的范畴。
信息安全测试可以属于“测”的范畴，也可以属于“试”的范畴。对于安全测试，需要检验系统是否安全或者系统是否存在安全漏洞。前者属于“测”，后者属于“试”。
是否具有相容性，比如Web程序对浏览器的兼容性测试，需要去尝试才能得到答案，所以相容性测试为“试”的范畴。
软件是否具有可维护性测试，也需要去尝试，比如需要把原来系统上增加新的功能，就要去尝试是否可以升级？同样可测试性也需要通过尝试的行动来确定是否具备。所以可维护性测试也为“试”的范畴。
同样，可移植性测试与可维护性测试相同，比如需要把原来系统数据库平台从My SQL移植到Oracle，仍旧需要去尝试。所以可移植性测试还是“试”的范畴。
综上所述，功能性测试，部分性能测试与部分安全性测试属于“测”的范畴。稳定性测试、部分性能测试、部分安全性测试、易用性测试、相容性测试、可移植性测试与可维护性测试属于“试”的范畴。但是某些时候“测”与“试”也不是完全绝对的，上面介绍的只是在一般情况下。比如系统必须支持火狐浏览器下运行，可说：“我们验证一下系统是否可否支持火狐浏览器。”而在大多数情况下是不可确定的，所以只能说：“我们尝试一下系统可否可以支持火狐浏览器。”
顾翔凡言：
不是好的工作会给你带来好的心情，而是好的心情会给你带来好的工作。
