Jack Wilber, 作家/記者
2005 年 3 月 01 日
本訪談分兩部分，業界分析師就關於電子商務趨勢是如何影響測試團體這個問題交換了意見。這些專家來自廣泛的開發團隊--項目經理、分析師、測試人員--可能沒有人會比測試人員更加感受到當前這種趨勢帶來的衝擊了吧。測試人員的任務就是使用非常有限的資源、面對馬上就要結束的項目期限，確保複雜應用程序的質量。
簡介
本訪談分兩部分，業界分析師就關於電子商務趨勢是如何影響測試團體這個問題交換了意見。這些專家來自廣泛的開發團隊--項目經理、分析師、測試人員--可能沒有人會比測試人員更加感受到當前這種趨勢帶來的衝擊了吧。測試人員的任務就是使用非常有限的資源、面對馬上就要結束的項目期限，確保複雜應用程序的質量。
作者記錄了三名受人尊敬的測試專家和分析師的看法與觀點：Theresa Lanowitz，Gartner公司的研究執行官；Hung Nguven，LogiGear公司的董事長和CEO；以及Sam Guckenheimer，IBM的自動化軟件質量高級技術執行官。在訪談的第一部分中，他們交流了測試人員所面對的挑戰，以及迎接挑戰所需要的技術、技能和策略。第二部分集中了討論有關架構變更是如何影響測試和自動化測試工具的問題。
技能
讓我們先從討論技能開始吧。在過去的兩三年中，分佈式應用程序的爆炸式發展是如何影響測試人員所需的有效的技能和領域知識的呢？
Hung Nguyen，LogiGear：我認爲這種發展帶來的影響是巨大的。在過去，在測試環境中要進行的所有事情都是非常獨立的。您拿到了一套交付的產品，開始運行安裝程序，然後進行測試。但是，當使用更加分佈式的，或者電子商務的模型時，測試人員就要面對兩個主要的問題了。第一個問題，在技術方面，所有的事情都發生了變化。由於您的系統可能使用分佈於各個地方的組件，一些是您的團隊開發的，一些是第三方組件，所以您無法控制您的環境。這樣，僅僅是瞭解環境並且弄清如何進行有效地測試就是一個很大的技術挑戰。
第二個問題，在業務方面，規則也有所改變。過去，用戶購買軟件包，安裝後就可以使用。現在您的用戶可能購買軟件包，或者他們可能僅僅使用您的電子商務基礎設施進行業務交易。所以，在業務的基礎上，測試人員還需要進行學習纔能有效地工作。例如，考慮性能方面，這只是測試的一個角度。在新環境中，測試人員需要了解非功能性的問題，例如，什麼是性能？我如何才能得出"合理的"響應時間，並且對其進行測試呢？這些都是他們在功能方面不總是能夠看到的。另一個要考慮的方面就是進行安全的測試。測試人員需要詢問，我如何才能知道我的用戶是否受保護或者業務是否受保護呢？這些正是測試的灰色區域，因爲幾乎沒有幾個測試人員知道如何有效地進行這種測試。
我們已經開始意識到要使測試有效地進行，您需要具備技術技能。因爲該領域還不是那麼的成熟，我們的測試團隊中還有不懂技術的人員。目前，在業務邏輯和用戶級，這是無可厚誹的。但是您也需要彌補技術方面的缺陷。直到所有人都瞭解到我們需要技能熟練的人員進行工作時，我還認爲測試人員，會非常不幸地，一直處於發展不充分的狀態，並且平均起來掙得較少。在理想情況下，技能熟練的測試人員與開發人員所瞭解的技術知識應該差不多，因此理應拿到同等的報酬，或者與他們的能力相匹配--而且管理層應該瞭解這個道理。如果工資結構有所改變，爲將更多的天才人員轉變爲混和工程師添加了預算的話，那麼更多的開發人員就會有興趣成爲一名測試工程師。
Theresa Lanowitz, Gartner：即使我們已經看到了分佈式應用程序的爆炸式發展，我們還沒有看到技能方面的爆炸性發展，對於開發人員或者測試工程師來說都是如此。使用許多分佈式應用程序的話，應用程序就是業務。突然間，企業的應用程序都是面向客戶的，在傳統企業中的IT組織現在都負責創建創造利潤的產品，而不只是應用程序。
但是技能並沒有什麼發展；實際上，我認爲它們還有所減退，因爲越來越多的企業都匆匆忙忙地創建這些面向客戶、利潤驅動的產品，他們無法找到技術足夠熟練的人員，所以他們常常僱傭那些沒什麼經驗的人員。回到1999年和2000年，我們看到了許多這樣知名的網站以失敗告終。在大概相同的時候，您聽到過許多有關測試工具的大肆宣傳，說它們是如何地易於使用，您不必瞭解技術就可以使用它們。但是我認爲這樣傳達了錯誤的信息；您確實需要具有技術技能以完成我們所希望的對應用程序的測試。
而且，分佈式應用程序只會變得越來越複雜。從發展的角度看，您可以知道使用大型機應用程序的用戶是誰，您也可以瞭解使用了什麼樣的架構。然後出現了客戶端-服務器應用程序，後來又進入了Internet世界，而現在有了無線的應用程序。爲了從測試的角度處理這種新出現的複雜情況，您就需要使用熟練的質量工程師--就是那些既瞭解過程又明白質量工程內容的人。
公司都瞭解這個情況，但是幾乎沒有哪家公司願意這麼做。通過調查，我們知道讓職工具有堅實的技術技能是企業最關心的問題。不過，他們最不可能做的一件事就是花錢進行培訓。所以，這是一個一直存在的問題。
另一個問題就是測試常常是開發組織需要削減預算時首先要考慮的事情，測試人員也可能被認爲是入門級的角色，或者將測試看作是您在成爲一名開發人員之前，首先要接受的崗位。正如Hung指出的那樣，測試人員確實沒有被給予與專業人員同等的關注和應有的尊敬。所以，組織常常重複地出現相同的問題，因爲他們還做得不夠，核心測試人員還不具備原理性的知識。
Sam Guckenheimer, IBM Rational：所以，我們正在討論的就是，以前人們認爲不需要具備關於正在進行測試的軟件的深入技術知識，也可以進行測試，但是當面對分佈式應用程序時--尤其是在Web上的應用程序--這個假設就站不住腳了。
Hung的一本有關測試基於Web應用程序的書極好地解釋了這一觀點。測試人員需要知道技術是如何影響他們所發現的錯誤和風險的種類的。他們需要理解技術問題--例如部署拓撲--就像理解他們進行測試的技術所內在的錯誤種類一樣。甚至要了解一些細節，例如在應用服務器上bean管理和容器管理持久性之間的差異--所有這些問題都對會影響到您將要發現的錯誤的種類。現在的測試人員需要了解技術以及相關領域，同時也要掌握通用的測試技巧。
例如，假設您在瀏覽器中看到一條錯誤信息"404-Page not found"。這種錯誤可能是由於一個損壞的鏈接引起的，或者也可能是由於某些服務不存在。一名優秀的測試人員不僅僅應該對不存在的服務產生疑問，而且也應該能夠肯定他的這種懷疑--例如，通過查看其他與該服務有關的頁面來判斷。這是分離判斷錯誤的關鍵技術。
另一項技能最近也受到了廣泛的關注，也就是測試人員是否具備一名優秀探索者的能力。從歷史角度來看，測試所要進行的許多內容都已經被高度腳本化，並且進行了周密的計劃，但是，實際上，優秀的測試人員應該是優秀的探索者。他們可以發現可能作爲提示的東西，而且知道如何在此基礎上進一步探索。這些提示可能非常簡單，例如某個頁面的加載時間驚人地漫長。一名優秀的測試人員會懷疑，這意味着什麼呢？而且知道接下去應該採取什麼策略。James Bach 編寫了一些有關探索性測試的最佳資料，而且對該主題也進行了深入的運用。我認爲這當然是一種關鍵的技能，也是測試團隊需要具備的技能。
壓力
多年來，組織不斷地努力"更快地、更好地、更節省地"開發軟件，測試人員的存在只是保證要實現"更好地"這個方面。現在，測試人員是不是要承受更大的壓力解決"更快地"和"更節省地"這兩方面問題呢？
Theresa Lanowitz：我們真正在談論的其實是使用了多年的選擇三角形：預算、日程還是質量。您的問題認爲測試人員的存在就是爲了保證"更好地"這個方面；但是他們確實能夠做到嗎？請考慮一下，測試工程師已經被強迫賦予了一種角色。在傳統的瀑布式開發中，測試僅僅在應用程序將要付諸使用之前的一個很短的時間段內纔開始進行。測試工程師實際上從沒有在開發過程中使用過用例或者測試用例。而且如果開發期間的日程安排有所順延，那麼測試工程師就遭殃了。我認爲測試人員並不總是能夠保證"更好"。
如果要保證"更好"，測試人員實際上就需要成爲客戶的代言人。而且我不認爲他們會受到尊重，擁有足夠的時間，使用優秀的工具，或者甚至沒有正確的文化背景來支持。組織總是更加關心更快與更節省，而不是更好，而且常常只有發生了災難性的或者接近災難性的事件，纔會使大部分人意識到他們的開發能力並不是像假設的那樣優秀。在過去幾年中，我們經歷過所有那些高知名度的運行中斷和網站故障，我們一次又一次地感受到歷史在重演。
在預算內準時地創建高質量的應用程序，這需要那些非常嚴謹的組織才行--在管理和過程兩方面都很嚴謹。但是這種文化氛圍還沒有在業界中流行起來。
這種文化需要什麼樣的基石呢？熟練的職業人員；可以文檔化並且重複的過程和過程；強大的工具和服務。人們常常認爲工具將會是萬能的，但是事實並非如此。如果您的目的是要較快地發佈，那麼您可能就要犧牲質量，而且可能會超過預算。這就是在.com蓬勃發展時我們所看到的。但是真實的情況是比較悲觀的，您即無法真正地加快面世時間，而且由於超時，新項目開發的費用也會失去控制，超過維護費用，而且使您無法準時將正確的產品推向市場。
Hung Nguyen：我認爲，這個問題可以追溯到缺乏對於測試團隊的預算。管理層常常想要創建質量更好的產品--我沒有遇到過意見相左的人--那麼這就需要更好的過程、使用更先進的開發方法學和更好的測試策略。但是，如果您看一看大部分的業務預算，就會發現沒有爲測試留出餘地；這都歸咎於研發或者開發。所以，在組織中沒有爲測試留下一席之地，也沒有業務策略和管理級的預算，但是測試人員仍然承擔全部的責任，要確保系統運行正常。
另一個問題就是，幾乎不存在什麼可靠的度量方法來表示以前您已經作了多少工作，所以也就無法追溯判定您是工作得更好了還是更差了。如果您的產品中出現一個巨大的故障，那麼千夫所指的是哪裏呢？首先就是測試，但是最後所有人都會收到責備，沒有人可以爲單獨一件事情負責。我認爲這是從管理層角度出發所面臨的最大問題。如果您想要"更好"，那麼您必須提升測試和質量工程的可見度，而且您可以通過提高預算來完成，這是很有效的。應該讓測試人員與開發人員合作來弄清如何完成工作。測試預算可以是開發預算的百分之幾，或者優選方案，應該爲業務預算的百分之幾，實際的數值還在爭論中，但是肯定是要制定計劃的。我們將資金分配於市場、銷售和研發，那麼爲什麼沒有測試的份呢？
"更節省地"開發也並不是件容易的事。工具和過程當然可以有所幫助。培訓，尤其是如何有效地使用工具，也會有所幫助。實際上，這又回到了我們剛纔討論過的技能問題上來。尋找優秀的測試培訓是個問題；嚴肅的、基於技能的軟件測試課程數量是有限的。我絞盡腦汁只想到目前在美國惟一一個開設良好培訓的例子，是由Florida技術學院提供的，Cam Kaner和James Whittaker進行講授。California大學在Berkeley 與Santa Cruz Extension、LogiGear 與 SQE所進行的課程也是提供有用軟件測試課程有限的幾個的例子。除了這些，我認爲也存在巨大的技能鴻溝，在大學級別上，增加更多的教育課程會是一個好辦法。例如Rational的公司一直都在開發支持新技術的工具，但是測試人員需要在更廣闊的環境中對其進行了解。工具只是解決問題的方法。要想有效地使用它們，我需要知道我已經出現了問題，這個問題是如何定義的，而且存在很多的方法來解決它。這纔是我所談論的教育的類型。
Sam Guckenheimer：實現更快與更節省的關鍵是在開發週期內使用迭代的開發過程使測試不斷向前，這樣，在發現缺陷時，纔可能更節省地、更輕鬆地修復。不過，我不認爲測試人員已經進行了良好的培訓能夠使用迭代的過程進行工作。項目經理也可能沒有進行良好的培訓以考慮測試的角色；那就是爲什麼我們向Rational Unified Process和Rational大學培訓中加入大量內容並且還要持續進行擴展以展示測試人員是如何進行迭代工作的原因。
但是，即使您並沒有進行迭代式開發--如果您在使用瀑布方法--也適用相同的概念：爲了節省時間和金錢，首先要把測試作爲基礎。在早期迭代中，您首先想要檢驗技術條件並且在簡單的測試中進行功能級的測試，然後逐漸上升到複雜場景和配置測試，在稍後的版本中又進行多變量的混和測試。理想情況下，您會不斷積累自動化測試方法，但同時您也需要不斷地進行優化。例如，對於接口的自動化測試是絕對關鍵的，而且應該在任何時候不斷地進行。但是在用戶的場景中，可能會在可用性、測試反饋或者設計變更方面有所變化，您也需要肯定、清楚地瞭解您測試的內容是什麼，以及當應用程序在測試發生變化的狀態下您如何進行優化測試。
非常重要的一點就是要了解不同級別測試的強大威力，而不認爲測試只是在已完成的系統GUI上進行操作。作爲測試人員，我們需要仔細地理解單元測試和交互測試，什麼樣的測試種類纔算恰當以及在哪裏進行測試。
過程變更
讓我們來更多地討論一下過程吧。在測試人員與擴展開發團隊的其餘人員協同工作時會出現什麼樣的變更阻止前進的步伐呢？敏捷的開發過程提倡進行測試爲先的設計和單元測試。測試團隊現在是否在更深入地進行代碼級和模型驅動的測試呢？
Sam Guckenheimer：我們來一次回答這些問題，首先從測試人員與擴展開發團隊協同工作開始吧。我堅信測試人員必須與開發人員緊密合作；他們應該一起工作，同時進行迭代過程。我認爲市場中大概有一半的公司正在以這種方式進行工作。另一半則認爲測試人員應該比較獨立，他們中的大部分將測試外包。從我的觀點來看，您這樣做就丟掉了測試的一半好處。您僱傭人員來發現錯誤，但是您並沒用創建出以不斷的和探索性的學習爲基礎的過程。如果您的測試人員與開發人員工作聯繫比較緊密的話，那麼在過程中都會有所收穫，而且也都會爲創建出更好的產品而貢獻力量。如果您將測試放手交給外包測試人員或者項目之外的測試團隊的話，他們能夠發現一些機械的錯誤同時進行報告，但是真正以迭代的方式發展產品或過程的能力卻會受到限制。
下面就是有關"敏捷開發過程"問題的部分。發展式開發的概念是極限編程（XP）的基礎，極限編程已經發展成爲一種敏捷的活動。在敏捷開發中進行測試還沒有被明確地定義，對於它應該包括的內容有許多觀點。我傾向於使用Brian Marick 與Bret Pettichord所使用的定義，基於6個原則--實際上他們稱其爲口號--都是從實踐得出的。一個原則就是您應該以實現技術說明書的方式開發測試；本質上，測試就是面向設計說明書的。因此，Rational Unified Process所稱的用例實現都是通過測試完成的。您在軟件創建的同時進行探索性測試，您要不斷進行迭代和優化，主要關注於爲可測試性而設計。我認爲，這些都是偉大的實踐，而且許多測試人員已經開始注意到它們了。
測試人員已經在源代碼級就更深入地進行測試了嗎？這裏，這個命名會有點讓人犯暈。在一個組織中被稱爲測試人員的人可能在另一個組織中被稱爲開發員，反之亦然。在大多數組織中，測試人員並不是直接從源代碼階段就開始進行測試，除非他們與開發人員配對工作。我認爲這樣是恰當的，因爲開發人員應該爲源代碼的質量負責。很久以來我們就已經知道測試源代碼的最佳人選就是編寫源代碼的人，而且Rational也提供了強大的工具支持開發人員進行測試活動。
模型驅動的測試也會帶來另一個問題。模型提供了一種偉大的方法，進行文檔化系統、可視化系統行爲並且在團隊中以一種易於理解的、減少複雜度的方式溝通共享的工作。使用模型進行測試的好處正在成指數地增加，而且呈現出一種奇妙的趨勢。模型驅動的測試包括很多的內容。一個就是可以專門爲測試而開發模型，與源代碼開發分離開來，這可以作爲一種創建大量測試的方法。（Microsoft 的Harry Robinson在他維護的網站中體現了這重意思：www.model-based-testing.org）。
從另一方面來講，Rational 的觀點就是，模型驅動的測試意味着模型描述了測試狀態下的軟件--其結構和行爲。相同的模型可以捕獲對所要進行測試的內容的定義，也可以捕獲測試的結果。我們正在努力爲模型驅動測試的發展做着貢獻。例如，Rational Test RealTime以UML順序圖的形式表示了測試狀態下軟件的行爲。我們的模型驅動開發的概念與在OMG工作組進行的用於UML測試簡檔的工作相一致。如果UML測試簡檔被OMG所採用，我預言我們會看到使用模型進行結果可視化和定義測試的急速發展。
我們還沒有討論測試人員與分析師協同工作的方式問題。在這兩個角色之間一直都存在一種關係，即使在最明顯的"瀑布"過程中（比如IEEE 829），人們也可以瞭解測試需求。建模不斷地發展爲分析和開發的實踐，這將分析師和開發人員緊密地聯繫在一起，因爲它將幫助開發人員使用級別不斷增加的技術條件將需求轉換爲設計。另一方面，它也會允許他們以不斷增加的抽象度將設計可視化。起初，測試人員並沒有被考慮進該循環中，但是仍然享受到了這些益處。確實，當他們意識到模型不僅僅會描述構思，而且也會捕獲實際系統行爲時，他們就體會到了其中的妙處。人們頻繁地剋扣模型中的用例實現方式，但是如果團隊能夠將應用於結構上的相同類型的反覆工程應用到行爲上去的話，這種情況即將改變。那也就是我們正在前進的方向。如果您使用了Rational Test RealTime，那麼您就會發現，在序列圖中的值正是您通過捕獲系統行爲而得到的。
Theresa Lanowitz：過程，包括早期測試的方法，對於任何取得成功的組織來說都是很關鍵的，但是許多人並沒有意識到這一點。兩三年前，Gartner 聽到許多的組織說："我們開發這套應用程序就是爲了[適合您最需要的垂直行業]，而且我們想將其轉變爲商業產品。我們的計劃就是把它賣到行業中的其他公司去，並且使我們脫離母組織。"但是，當我們探討了作爲一家商業軟件公司所需要的條件時，他們就會退縮。我們沒有看到任何成功脫離的案例。但是，實際上，企業確實需要能夠並且也願意表現得像商業軟件公司那樣。他們需要了解創建週期、需求和日程；他們需要能夠與工程組進行溝通的產品經理等等。目前，我們還沒有看到企業組織全部都採取了這種更加結構化的行爲。
要實現這種改變，就需要建立起支持它的文化。資深人員常常告訴我，管理層並不想要過程，因爲那樣會佔用太多的時間。要建立一個優秀的過程，您必須理解它應該包括什麼內容，並且在整個過程採用的最初階段保持對其的管理，貫徹完整的原則。您也必須記住，最終目標是爲了準時並且在預算內發佈高質量的人們所公認可以作爲產品的應用程序。除非組織中從上到下每個人都重視產品質量，否則組織就會以一種混亂或者無法發揮作用的模式運行。
應該牢記編寫代碼實際上僅僅是任何項目開發中的一小部分內容，這一點是很重要的。識別正確的架構，開展恰當的過程，確保您遵守企業已經建立的標準--這些都是很關鍵的事。
對於進行源代碼級的測試，開發人員現在正在編寫更多的單元測試，這是值得肯定的。一些確實不錯的工具已經在市場上出現，這些工具都可以幫助開發人員創建單元測試。不過，我仍然認爲，隨着時間的過去，測試人員需要變得更加地懂得技術，而且組織需要進行更大的投資培訓測試人員，使其跟上技術的發展。那麼，隨着測試人員技能的不斷成熟，組織就會更加公平地對待和尊敬測試部門。測試人員肯定也會更多地參與進代碼級的測試中。
對於模型驅動的測試，UML爲此做了很大努力。如果您編寫了測試用例，那麼您就已經編寫出測試用例了。如果您能夠將一個優秀與穩定的過程完全集成入您的軟件開發生命週期中，那麼這就是一件很值得肯定的事。
Hung Nguyen：當然，測試人員與開發團隊的其餘人員的融合程度隨公司的不同變化幅度很大。一家公司可能使用並不是很懂技術的測試工程師，但是他們應用了很棒的過程，完全能夠使測試、開發與業務團隊協同工作一起探討需求和特性，並且全部將其文檔化。但是，在整個行業的範圍內，這種情況肯定會發生改變，測試人員會更早地參與過程，並且與業務分析師和開發團隊進行更多的合作。
讓開發團隊在源代碼級考慮其代碼的可測試性並且考慮進行單元測試是很好的。但是如果您看看要進行測試的階段--需求級、源代碼級、接口級、組件級以及集成測試所在的系統級--測試人員在源代碼級、接口級和組件級的表現都不夠理想。在接口（API）級，合作進行得還不錯，但是在源代碼級，就仍然是開發人員的事情了；測試人員還需知道如何才能在那個環境中發揮作用。
例如，Rational Purify屬於一種開發人員經常使用的動態工具，這是很好的。但是，要想進行更廣泛的測試，您就需要執行更多的代碼，而開發人員沒有時間這樣做。所以，一種明智的辦法就是將開發團隊與過程相集成，並且也讓測試人員在測試過程中使用Rational Purify。同樣地，讓開發人員先進行一遍單元測試，然後再讓測試人員進行一遍測試，這樣做也是可以的。雖然可能由於缺少對測試過程的學習，我們仍然將代碼級的測試看作主要是開發人員的活動，但是我們確實需要填平開發人員與測試人員之間的溝壑。但是測試人員僅僅需要運行測試，記錄所有的錯誤，然後把結果發送給開發人員；他們甚至不需要解釋這些結果所包含的意義。
我認爲模型驅動的測試在測試設計和分析方面扮演了很重要的角色。例如，Rational Quality Architect能夠創建基於模型和依賴性的測試。如果您發現了錯誤，您實際上就可以使用模型來縮短推算出故障的路徑。所以，模型驅動的測試就是進行測試設計和生成的關鍵因素，也可以作爲自動化故障分析與精確定位問題的知識基礎。
故障的代價
人們常常討論把過程作爲一種減少軟件故障的方式。很多著述也記錄了與面向公衆的電子商務站點有關的故障的代價在不斷地增加。業務的變更很大程度上影響了測試實踐嗎？
Theresa Lanowitz：絕對如此。當使用電子商務時，故障並不僅僅意味着人們將不能使用該軟件；這還是有關公衆形象的問題。因爲使用這些應用軟件的人都沒有技術基礎，也因爲軟件的應用範圍正在逐漸增大，所以軟件必須是能夠防止錯誤操作的。您的用戶並不具備豐富的經驗，所以您僅僅有一次機會。如果他們想要使用什麼--例如Web服務--而它根本就無法執行或者工作，那麼他們就不會繼續進行，只會轉向其他的站點。這就直接說明了需要將產品（例如Web服務）的質量提高這一問題。
Sam Guckenheimer：我認爲故障代價的增加已經使管理層更加意識到測試和質量的重要性。幸運的是，我們已經超越了這個階段，也即一些以前的網站忽略了質量，而完全關注速度問題。因爲我們經歷了那麼多高知名度網站的故障，所以管理層變得越來越精明，越來越仔細。
Hung Nguyen：我不認爲故障帶來的高代價確實是一個新問題；我們以前就已經面對過這個問題了。它確實會影響測試人員；它給我們施加了壓力，使我們更有效地發現錯誤。但是這個問題與質量保證過程更加緊密相關。我們該如何實施更好利用人員和技術的質量過程呢？我們該如何使QA與開發團隊協同工作以開發更好的實踐呢？在電子商務故障的環境下，我們現在進行測試的方式與曾經進行測試的方式有所不同了。我們不會停止工作，知道產品已發佈；我們持續地進行着測試。這也是爲什麼一個新的監理市場已經興起的原因，我們正在使用機制來提醒我們注意故障。
目前，公衆也受到了更好的教育。他們明白如果他們付了錢，那麼您就必須提供優秀的產品。他們可以進行選擇；行業內的競爭如此的激烈，如果您無法提供優秀的、高質量的產品，那麼他們就會離你而去。
這些故障也造成了一個非常積極的結果，管理層已經開始從金錢的角度看待質量問題了。他們正在告誡他們的開發組織："我並不關心你稱它是高質量或者低質量的產品。如果它讓我的站點關閉兩分鐘，那就會花費我一百萬美元，我不想這類事情發生。所以，你回去應該弄清如何才能不讓這類事情發生。"而且管理層也知道如果他們給測試小組提供相當的預算，那麼測試小組就應該負起責任。當您制定年預算時，會想要把測試置於列表的頂部，因爲這是獲取高質量軟件的主要途徑。最終，那將賦予測試人員權力、責任和義務。
您可以參閱本文在 developerWorks 全球站點上的原文： 閱讀英文原文
