来自于西门子公司的Peter Zimmerer说，在系统中，易测试性必须被明确地设计。测试架构师应该推动易测试性，并和架构师、设计人员和测试人员去共同使用好的设计和工程实践。
在QA&Test 2014大会上，Peter贡献了一个关于针对嵌入式软件系统的易测试性的设计教程。
Peter对易测试性给出的定义是“系统可以被有效及高效测试的程度”。效率与积增的深度和测试的质量有关，在此是指有效地降低成本、工作量和测试时间。易测试性是轻松地确认，即软件可以被高效测试的程度。它在软件的初期开发阶段和维护阶段发挥着作用，易测试性可以被认为是已修改的软件可以被确认的能力。
按照Peter的说法，影响易测试性的主要因素是：
- 控制（不稳定性）：我们能够比较好地控制系统（以孤立的方式），更多、更好的测试可以被执行、自动化和优化。
- 可见性或可观察性：你能够看到什么可以被测试。可以观察到输入、输出、状态、内部构件、错误条件、资源利用率，以及系统在测试时其他方面的影响。
Peter说，易测试性通常是比自动化更为经济的投资。同时，自动化也依赖于易测试性，如果系统设计为可测试的，那么也将会降低自动化测试所需的工作量。
为什么针对易测试性的设计重要呢，你可以如何去说服管理者为此投资呢？它最主要的好处是能够降低成本、工作量和调试、诊断的时间，以及整个软件开发生命周期中的维护成本。Peter引用了Stefan Jungmayr在德国测试社区的调查，这个调查在Testbarkeitsfaktoren und Testaufwand: Auswertung dreier Umfragen中进行了描述说明； testbarkeitsanforderungen an die Software 上其中有一个结论是，易测试性可以节省总体开发中大约10%的预算。
针对易测试性的设计必须由架构师、开发人员和测试人员共同来完成。Peter说，架构师愿意接受易测试性的设计。易测试性是一个设计准则，测试人员必须定义易测试性需求。在敏捷中，易测试性是整个团队的职责，但是，如果有一个专人（比如测试架构师）来推动易测试性会很有好处。
Peter在他的陈述中贡献了一个针对易测试性设计的检查表。这份检查表可以用来讨论团队或项目对易测试性的处理做到了什么程度，能够做什么去改进它：
- 适当的测试架构，好的设计原则
- 通过良定义控制点和可观察点在测试时与系统交互
- 出于测试目的（安装、配置、模拟、恢复）附加的（可脚本化的）接口、端口、钩子、模拟、拦截器
- 编码指南、命名规范
- 内部软件质量（架构、代码）
- 内建自测试、内建测试
- 一致性检验（断言、契约式设计、偏差）
- 日志和跟踪（面向方面的程序设计、计数器、监控器、探查、剖析）
- 诊断和dump 工具，黑盒子（内部状态、资源利用率、运行期的异常现象）
- 测试优先的思维（xTDD）：我可以怎么去测试它呢？
通过应用好的设计实践可以完成针对易测试性的设计。这正是Peter所说的为什么架构师在此扮演着一个非常重要的角色。做好敏捷其实是指做好敏捷工程实践。Peter提到了干净的代码开发人员维基百科，它包括做更好的软件的原则和实践。
针对易测试性的设计策略需要涉及需求、测试和架构。易测试性需要被一致地定义，并由涉及其中的每个人充分地理解它，这些人参与或负责基于风险的测试策略，并保持非功能性需求的稳定性。易测试性指南可以在设计中用来规定易测试性和内嵌的易测试性。里程碑和质量门需要有易测试性的标准，不管是从事静态测试还是动态测试都必须要研究和探索易测试性。
“忽视易测试性意味着增加技术债”，Peter以这句话作为了他的教程的结论。