Rudolf de Schipper在项目管理、咨询、QA及软件开发上有丰富的经验。他有管理大型跨国项目的经验，喜欢团队合作。Rudolf 很擅长分析，对公共部门、金融、电子商务领域很感兴趣。他曾在国际型设计和开发中使用过面对对象的技术。除了IT相关项目的管理方面，他的兴趣还覆盖程序管理、质量管理、业务咨询以及架构和开发。坚持跟进技术工作，Rudolf 曾与StratEx团队合作开发过StratEx应用程序（www.stratexapp.com），其架构以及所用到的代码生成工具。在此过程中，他学会并体验了许多严峻的软件设计和开发相关的困难，包括测试的挑战。
　　在StratEx中，除了开发StratEx应用程序，明显我们还很重视质量和测试应用程序。毕竟我们一心要为用户提供高质量。StratEx使用代码生成的概念来缩短开发周期，能够快速实现新特性和功能。同时还提供一个好看统一的用户界面，因为我们一直保持代码生成的简单性。所以创建一个看起来与众不同的（生成的）屏幕并不容易。代码生成概念给了我们可靠的代码，也减少了测试时间。不过，除了有效地编码外，我们还想找到有效测试的方法。（至少从我们的角度看）显著的解决方案是自动化和生成我们的测试。但这听起来简单，实际上却并非如此。我们要花不少时间思考佳测试策略该是什么样的以及该如何实现它（使用测试自动化）。首先我们解决用户UI测试，使用Selenium。我们手动记录一些测试场景并将它们包含到我们的持续集成建立流程中去（关于这点我后面会讲到）。它帮助部署经过烟雾测试的构建，但是当我们对屏幕做出改变时，它完全起不到帮助。这是我们一直以来在做的事，因为有了我们的生成代码，它变得很简单，我们需要为用户提供这种灵活性！当然，这一点上我们决不妥协，甚至不能确保我们的代码被自动测试。是的，你没看错——我们是敢于部署没有完全经过端到端测试的代码！我们更愿意经常且快速地部署，尽管要冒着可能有用户会找到bug的风险。

　　我们对此仍不满意，因此我们坚持寻找更好的解决方案。接下来要进行长期的调查活动，以便能够：找到更好的（更快的）测试，生成测试，改进我们手写代码的方法，阅读大量关于测试的书籍文章。即使到了现在，该调查还没结束，我们仍未能成功（完全）生成我们的测试。然而这些日子部署一个新构建前我们一直在运行自动化测试。同时，我们很乐意分享我们遇到的一些关于各种测试/开发方法的发现。
　　TDD(测试驱动设计/开发)
　　TDD方法的基本前提是：你的开发基本是由若干（单元）测试驱动的。你第一次编写测试，然后运行它们。很明显，测试失败了，那你下一步要编写代码使测试通过。依我们之见，TDD及其对单元测试的重点关注是：一个被高估的概念。这很容易理解，因此很快吸引了热情的追随者。其方法的重大差距也是代码。且这代码必须得写，得维护，它还会含有bug。所以如果我们的整个项目中开发员花x%的时间写新的（测试）代码而不重视写产品代码，那我们必须问问其中的意义何在了。在我们看来，你们只是在制造更多行的代码及更多的bug。