從微軟的轉型看軟件測試的發展 (2)

 

在實際工作中，大部分公司使用敏捷開發（agile development）, 軟件項目的構建被切分成多個子項目，各個子項目的成果都可以測試，
且可以集成和統一運行。它是一種以人為核心，人們可以先做想要做的的模塊，可以修改流程，可以變更和修改當前的功能； 同時又是一種迭代，循序漸進的開發方法。即使有多年的敏捷開發應用經驗的團隊，測試都是一種挑戰，人們很容易的說，
我們自始至終都做測試， 但是很難把它做好。有時測試影響了這個項目的時間進度，質量得不到保證。

經常聽到團隊的人說：“為了實現新的功能， 代碼到最後一刻才做好，怎麽能完成測試呢？”

“我們試圖用自動測試代碼來完成驗收這個新的編譯，可是十有八九要失敗，因為程序代碼改變了，而自動測試沒有及時更新那些調用。”

“我想許多缺陷沒有發現， 因為我們重點測試已有的功能，新的功能，對軟件係統沒有仔細的測試。”

現在人們普遍認為，測試人員測試，程序員寫編碼，把二者分開是很重要的。獨立的測試隊伍才能保證軟件的質量。現在我們來分析一下為什麽程序員不能測試。

也許你會說，”當然， 程序員可以測試”, 但是， “他們不會找出他們自己的編碼錯誤，也許他們可以測試其他人的代碼，
但不是他們自己的。”

但是，同時作為程序員和測試員， 時間不夠是比上述問題更重要的問題，至少我個人認為是這樣。當我的時間不夠時， 我匆匆忙忙完成任務，因此就容易忘記或漏掉去測試一些功能。後來，
當缺陷從最終用戶哪裏反饋來了， 這個缺陷就發生在我忽略的那一部分，或者我忘記的那部分。測試其他人的編碼不能發現由於時間的壓力，忽略的那些功能而導致的缺陷。