最近有些懈怠，虽然一直还在读书，但是貌似已经几周没有写读书笔记了。
今天读到《Scrum精髓》的后记，副标题是：“接收测试”引发的思维转变。译者徐毅详细讲解了对AT这个词在翻译时的斟酌和谨慎，感叹其对细节的认真态度，同时觉得对最近手头正在做的工作有些启发和借鉴意义，因此花点时间记录下。
传统的UAT概念关注重点在于该解决方案能够解决用户的问题，而非系统本身有无故障、是否满足需求文档中的要求。
敏捷的AT和传统的UAT确实不一样。在敏捷开发中，如果说存在着一个完美的情况，那就是开发团队经过一个短迭代的开发之后，可以拿出一个可交付或潜在可发布的产品增量，也就意味着团队需要完成可交付或潜在可发布标准中的所有测试，代码级别的测试就是单元测试，而更高级别的各种测试则统一用AT。
顺应敏捷开发的特点，一切都从一个简约明确的需求出发，那么团队采取的方式就是在计划时明确定义需求的边界和验证的标准。如果需求是实现一个新特性，那么测试就大多是功能性的测试；如果需求是要改进系统的响应速度，那么测试主要就是性能测试；如果需求是增加对某款新型浏览器的支持，那么测试很可能就涵盖功能测试和兼容性测试等类型。然而，不管是哪种类型的测试，都是用来判断某个具体需求或故事是否已经完成的标准并称为AT。以此方式，也可以简化团队在计划时的工作，团队只需要问“这个特性要做到什么样子才算完成呢？”至于这些要求如何细化为具体的AT，则交由团队来完成。
其实真正能够做到研发团队叫出来就是一个可交付或潜在可发布的东西，往往还需要交给某个专门做更高级别或更接近尾声的测试的部门，例如系统测试、性能测试、全联网测试等。这也意味着在研发团队完成开发和测试之后，还有一些其他类型或阶段的测试工作需要继续，半成品的系统还没有达到可以交付的水平，当然也远没有到可以执行UAT的状态或时间点。
书最后的词汇表里把AC和AT中的Acceptance都翻译成了接收，而不是验收，这个和之前的习惯叫法有了一些区别。
总结下，感觉是这样：接收测试强调的是满足产品负责人对具体需求的要求，强调满足具体需求或故事的接收标准；而验收更多是从用户的角度来说的，要求的标准更完整和全面，是面向整个系统的。很多时候，尤其是针对离岸开发的情况，产品负责人并不是最终用户。AT和UAT之间的部分，是Craig Larman定义的Undone的内容。在每个迭代完成后形成的潜在可交付增量，这个“潜在”是不是表示并不能真正交付，并且遵循敏捷的原则，这是可以接受的？
最近在修订研发项目的绩效要求文档，对于每个关键里程碑的交付物需要达成的标准，要求比较理想，是希望把性能测试、安全性测试都做完，形成一个真正达到商用标准的交付版本；不过受限于实际的人力、机器等资源情况，这个可能是无法做到的。对于这件事情就有个纠结，两个方向到底哪个是对的：一是设定一个高要求和目标，不问是否能做到，而是问要怎样才能做到；二是脚踏实地，结合资源的现状做到最佳情况。
用精益和敏捷的思想来考虑这个问题，延迟决策是正确的，如果还没有真正的客户需要这个版本，那就不需要每个里程碑的时候都做这种需要消耗大量资源和人力的测试，这些成本不需要过早支付；但是也有可能发现有重大性能问题时需要优化，对系统会产生非常大的颠覆性影响，这时反而需要支付的成本更多。另外从持续改善、不断挑战现状的角度来说，发现存在这种隐患的情况，就应该要努力去改进它。
纠结中，感觉这个事情应该没有唯一正确答案，不同环境不同客户不同时期最适合的方案会有不同。不过目前阶段，个人还是倾向于严守质量标准，及早做完整的性能测试和安全性测试，避免风险。
