正文
于是我们又回到了软件测试的本质，"测"与"试"。
所谓"测"就是检测软件系统是否按照用户显性需求的运转，比如功能；"试"可以理解为试错，尝试。比如找到系统最大负载点，系统对错误输入，异常环境是否可以适应，一旦程序发生错误多久可以修复。我们也可以把"测"理解为证"真"，"试"理解为证"伪"。
下面我们来讨论在一个Sprint中如何运用软件测试的本质"测"与"试"来进行测试工作。
我们假设一个Sprint为1个月，即22个工作日，我们把这22个工作日分成前、中、后三部分。前（第1个工作日到第7个工作日），中（第7个工作日到第14个工作日），后（第15个工作日到第22个工作日）。
在Sprint前期测试人员的主要工作为书写这个Sprint 新功能的测试用例
，这些测试用例可以是自动化，也可以是手工的，并且在这些测试用例中，以证"真"的"测"的方法为主，证"伪"的"试"的方法为辅。我把这种测试方法叫做纸上谈兵式测试，在这里测试用例没有具体的格式，目的只要可以给相应的开发人员看懂就行，关键需要关注的是对新特性的覆盖度。从第二个工作日开始，在每日站会后，测试人员把他们前一天写的测试用例交给相应的开发人员，与他们进行一对一的评审，由于测试用例是每日提交的，所以评审的时间不会很长。一旦通过评审后，这个测试用例就交给开发人员了。开发人员在开发期间需要100%达到这些测试用例所希望的结果，并且根据开发人员的自身需求，在适当的时候执行测试用例。
在Sprint中期，测试人员主要工作专向基于经验的探索式测试和非功能性测试
，在这个阶段，主要运用证"伪"的试的方法。而开发人员的主要责任在重新运行一遍交给自己的测试用例，以及对缺陷的修改。
在Sprint后期，开发人员协助测试人员一起完成回归测试，
开发人员按照以前的测试用例执行测试，测试人员仍旧以探索式方式来测试，以保证整个Sprint结束是一个高质量可交付的产品。一旦发现缺陷，开发人员优先回去修改缺陷。
