Rudolf de Schipper在項目管理、咨詢、QA及軟件開發(fā)上有豐富的經(jīng)驗。他有管理大型跨國項目的經(jīng)驗，喜歡團隊合作。Rudolf 很擅長分析，對公共部門、金融、電子商務領域很感興趣。他曾在國際型設計和開發(fā)中使用過面對對象的技術。除了IT相關項目的管理方面，他的興趣還覆蓋程序管理、質量管理、業(yè)務咨詢以及架構和開發(fā)。堅持跟進技術工作，Rudolf 曾與StratEx團隊合作開發(fā)過StratEx應用程序（www.stratexapp.com），其架構以及所用到的代碼生成工具。在此過程中，他學會并體驗了許多嚴峻的軟件設計和開發(fā)相關的困難，包括測試的挑戰(zhàn)。
　　在StratEx中，除了開發(fā)StratEx應用程序，明顯我們還很重視質量和測試應用程序。畢竟我們一心要為用戶提供高質量。StratEx使用代碼生成的概念來縮短開發(fā)周期，能夠快速實現(xiàn)新特性和功能。同時還提供一個好看統(tǒng)一的用戶界面，因為我們一直保持代碼生成的簡單性。所以創(chuàng)建一個看起來與眾不同的（生成的）屏幕并不容易。代碼生成概念給了我們可靠的代碼，也減少了測試時間。不過，除了有效地編碼外，我們還想找到有效測試的方法。（至少從我們的角度看）顯著的解決方案是自動化和生成我們的測試。但這聽起來簡單，實際上卻并非如此。我們要花不少時間思考佳測試策略該是什么樣的以及該如何實現(xiàn)它（使用測試自動化）。首先我們解決用戶UI測試，使用Selenium。我們手動記錄一些測試場景并將它們包含到我們的持續(xù)集成建立流程中去（關于這點我后面會講到）。它幫助部署經(jīng)過煙霧測試的構建，但是當我們對屏幕做出改變時，它完全起不到幫助。這是我們一直以來在做的事，因為有了我們的生成代碼，它變得很簡單，我們需要為用戶提供這種靈活性！當然，這一點上我們決不妥協(xié)，甚至不能確保我們的代碼被自動測試。是的，你沒看錯——我們是敢于部署沒有完全經(jīng)過端到端測試的代碼！我們更愿意經(jīng)常且快速地部署，盡管要冒著可能有用戶會找到bug的風險。

　　我們對此仍不滿意，因此我們堅持尋找更好的解決方案。接下來要進行長期的調查活動，以便能夠：找到更好的（更快的）測試，生成測試，改進我們手寫代碼的方法，閱讀大量關于測試的書籍文章。即使到了現(xiàn)在，該調查還沒結束，我們仍未能成功（完全）生成我們的測試。然而這些日子部署一個新構建前我們一直在運行自動化測試。同時，我們很樂意分享我們遇到的一些關于各種測試/開發(fā)方法的發(fā)現(xiàn)。
　　TDD(測試驅動設計/開發(fā))
　　TDD方法的基本前提是：你的開發(fā)基本是由若干（單元）測試驅動的。你第一次編寫測試，然后運行它們。很明顯，測試失敗了，那你下一步要編寫代碼使測試通過。依我們之見，TDD及其對單元測試的重點關注是：一個被高估的概念。這很容易理解，因此很快吸引了熱情的追隨者。其方法的重大差距也是代碼。且這代碼必須得寫，得維護，它還會含有bug。所以如果我們的整個項目中開發(fā)員花x%的時間寫新的（測試）代碼而不重視寫產品代碼，那我們必須問問其中的意義何在了。在我們看來，你們只是在制造更多行的代碼及更多的bug。