在Agile Practitioners 2016大会上，Huib Schoots谈了可测试性。他指出，低可测试性（任何导致软件难以测试的东西）会导致团队效率低下，并探讨了如何提高可测试性。
　　Schoots谈了软件开发中未知的未知问题。我们无法掌握开发一款产品需要提前完成的一切工作，因此，我们必须确保在软件开发过程中构建洞察力。我们必须知道如何应对复杂性和不确定性。“控制与命令”式的瀑布方法会成为构建洞察力的障碍。
　　敏捷测试是在敏捷环境中测试。测试不会因为我们采用敏捷而改变，变的是环境。敏捷测试有一些不同，它使用迭代方法，准备提前期变短，测试执行和报告生成变快，而变化非常常见。此外还有角色的变化，Schoots提到，使用敏捷时，测试经理更多的是一名教练，只做较少的测试。
　　Schoots表示，快速测试是一种测试理念和综合技能。快速测试可以减少文档，将更多的精力集中在如何测试上。快速测试是一种通用的测试方法，不仅适合敏捷，也适合任何的项目或产品。
　　测试是指人们在不确定的情况下通力合作。我们不可能什么都知道，而事情总是在变化。
　　Schoots表示，测试的目的是了解产品的状态以及任何威胁产品价值的因素，以便客户可以做出明智的决策。测试人员能够看到事情的真相，并照亮前进之路。他们会把真相告诉团队和项目经理。
　　检查（与测试相对）是指操作一款产品检查具体的输出。按照Schoots的说法，所有的检查都应该尽可能地自动化。检查非常繁琐，自动化可以提高可测试性。
　　Schoots提到了James Bach对可测试性的定义：
　　产品实际的可测试性是指在特定的环境中，产品被特定的测试人员及测试过程测试的难易程度。
　　按照Schoots的说法，我们需要可测试性，因为它可以简化测试，提升测试速度，降低测试成本及减少不可再现的Bug。
　　Schoots讲了一个故事，是关于一家他工作过的银行。他们不能使用生产环境的代码进行测试。因此，他们必须创建文本文件来测试钱在“测试银行”之间的转移。Schoots目睹了测试人员如何手动修改一个用于测试的大文本文件。由于这耗费了太多时间，所以他们决定构建一个工具用于这种修改。经过扩展之后，该工具能够做使用生产环境代码作为输入创建测试文件所需要的所有修改。借助这款工具，测试人员每天节省了大约三个小时，因此，这款工具提升了可测试性。
　　认知可测试性是指我们知道的东西同我们需要知道的东西之间的差距。认知测试需要具备产品质量的先验知识。据Schoots介绍，测试等待的时间越长，差距越大。一个例子是，了解什么功能已经在单元测试中进行了测试，如果有了这样的知识，那么不需要在系统测试中再次对它进行测试。
　　James Bach认为，测试人员必须要求可测试性。Schoots对此并不完全赞同，他的观点是，测试人员应该要求更高的可测试性，因为那是一种团队职责，整个团队都会从高可测试性中受益。
　　Schoots表示，高可测试性使测试更快、更简单，同时成本更低，每个人都可以从中受益。他建议将可测试性作为冲刺计划的一个主题，团队应该进行可测试性回顾，找出提高可测试性的方法。