原文來自51testing，原文地址位於：http://www.51testing.com/html/24/n-812424.html
前兩天，Cory Foy在tweeter上發佈一條消息“有一個QA部門，標誌着你們開發部門的無能，討論。”
我是這麼想的：我是一名測試人員，現在該是我們增長技能的時候了。不論開發人員的組織結構如何，該是測試人員走出QA部門的時候了。
2008年秋，我在AYE會議現場，輔助Fiona Charles和Jerry Weinberg主持一個session”測試的謊言“。Jerry坐在會議室前排，當人們不停的進入會場就座時，我聽見Jerry在和幾個人討論問題。他問：” 你們是質量保證部門的？“ 回答是是的。”那麼，你們有權修改被測試的源代碼嗎？” ”這絕對不行。“ ”這很有趣。那麼你如何來保證質量呢？“
真是個好問題，它讓我立即想起十多年前的一次對話。1996 年 秋，Cem Kaner在Quarterdeck做了一個黑盒軟件測試的講座。那時我還是一名開發經理，但是QA（也就是測試）的頭邀請我參加這次講座。作爲課程的一 部分，Cem引導我們討論”測試團隊是否真的應該被叫做質量保證？“ 他的立場是，每個人– 開發人員或測試人員 — 當然能夠確保他自己工作的質量，但是測試人員，不能確保別人工作的質量，也不應該試圖去確保別人工作的質量。Cem說，企業中質量保證這個職責（role）應該歸於管理者和CEO（企業中主要的質量官），因爲是他們–而不是測試人員–有權利做關於質量的決策。多年來，Cem持續的構築這個思想，在他的膠片中和提交給The Ongoing Revolution in Software Testing的論文中表達這個觀點，這個觀點蓋過了他所有其他的工作。測 試人員的職責不是質量保證，我們沒有權利控制項目計劃、預算、開發人力、產品範圍、開發模型、客戶關係等等。但是當我們盡最大努力做我們的工作的時候，我 們會提供很有價值的、實時的有關產品和項目真實狀態的信息。我們不對質量負責，我們幫助那些對質量負責的人、提供質量相關的信息、以影響他們的決策。”質 量輔助，這就是測試做的事情。“
最近，在接受Roy Osherove的一次採訪中，James Bach也明確表達，測試人員不是質量的看門人。測試人員並不比其他任何角色有更多的責任對質量負責；開發團隊中每個人都有對質量負責的責任。 當James在蘋果公司第一次當測試經理時，質量把門人這樣的想法讓他充滿活力。”但是後來我認識到這個想法對其他的角色是莫大的侮辱，因爲這樣的說法傳 遞給其他人的信息就是‘你們這些傢伙並不真的關心質量，是吧？你們不像我這樣的關心質量。我是測試人員，因此我才更關心質量。’ 開發人員除了創造質量，他們還使質量真實的存在。沒有開發人員，什麼都不存在；你擁有的質量是0。所以，說‘測試人員是質量的把門人’，是對開發人員的侮 辱，當你想用這樣的說法侮辱開發人員的時候，開發人員就不願意和你一起工作。“
上週，我去參加Orlando舉行的StarEast測試會議。經常有測試人員和測試經理來請求我的幫助。他們希望我給出建議：測試人員如何才能使開發人員採納那些‘最佳實踐’？測試人員如何去影響一個產品經理去做更好的工作？測試人員如何使得開發人員按照某種過程模型開發產品？在一個議題中，測試人員哀嘆來自業務人員的需求的質量（再重複解釋一下這個普遍的用詞，當測試人員說需求的時候，實際指的是需求文檔）。其中有個人響應這個問題說，等他回去的時候，將讓測試人員承擔起需求撰寫的工作。
在答覆上述尋求建議的問題上，迄今爲止我能給出的最有用的解答是：這些都不是有技能的測試人員應該做的事。
測試人員不是項目的大腦。這就是說，測試人員不能控制項目。我們的角色是提供ESP–不是指”超感官的洞察“，而是指”額外的敏瑞的洞察“。對開發人員和管理者而言，測試人員是項目額外的眼睛、耳朵、手指、鼻子、味蕾。我們是他們器官的延伸。如果我們竭盡所能，我們可能像極度敏感和超精校準的儀器-顯微鏡、望遠鏡、超靈敏麥克風，遊標卡尺，質譜儀，嗅彈探測器。（測試人員像儀器的想法是Cem Kaner啓發了我。）測試人員幫助開發人員和管理者們聽到和看到那些在有限的時間內、由於他們得用自己的思維方式去工作，而不大可能意識到的東西。
聽好：如果你真的想提升代碼質量，並且認爲你可以做到，那去做一名開發人員。我就這麼做過。我能保證如果你真的這麼做了，很快就會發現成爲一名真正的優秀的開發人員是一件多麼具有挑戰和震撼人心的工作–因爲就像所有的工具一樣，計算機可以迅速和有力地延伸你的無能，就如它可以擴展你 的能力一樣。如果你想管理一個項目，就去當項目管理者。我也這麼做過，還做得不錯。但當你試過後，你很快將發現質量就是對某個或某些人的價值，並且這些人 很在乎這些價值。而你自己定義的質量標準遠不如那些真正使用產品併爲此買單的人所定義的質量標準。成爲項目管理者，你幾乎馬上就會意識到是否發佈一個產 品，確實會受到技術問題的多少的影響，但最終它是一個商業的決定，需要平衡產品的價值以及缺陷–即對產品價值的削弱–和不發佈產品而帶來的成本。
在上述任何一種情況下，如果一個沒有做過開發或者版本管理的人來向我發牢騷，說我不尊重質量，這並沒有什麼幫助；如果他還試圖指導我如何做好我的工作，而他卻從來沒有做過這項工作，那就更糟糕了。無論我是開發人員還是項目經理，我希望從測試人員那裏得到的是信息。作 爲開發人員，我希望瞭解測試人員在我寫的代碼裏發現了什麼問題，他們是怎麼發現的，產品可能無法正常工作的情形，以及任何我需要的有助於找到和修復這個問 題的步驟和線索。作爲項目經理，我希望瞭解測試人員都獲取了哪些關於產品的信息，他們在獲取這些信息時是如何配置、操作、觀察和評估的。我想知道我們的產品是如何與以往一直工作的方式所不同的。我想了解內部的不一致。我想了解我們的產品與市場上同類產品對比有哪些不同；怎麼更好了，或者怎麼更差了。我想知道我們的產品因何堆放在那裏，面臨索賠。
那麼：你想影響質量、影響團隊。想知道如何正向地影響開發人員？
■ 就像James在訪談中建議的那樣，告訴開發人員，你的主要目標是幫助他們看起來更好–然後開始相信這個說法。你的工作不是要羞辱、指責、作惡別人。我甚至認爲我們不應該拿別人開玩笑，因爲這一點也不好笑。
■ 你經常是壞消息的承載者。認識到這一點，帶有同情心和謙卑地發佈這些消息。
■ 你也可能犯錯，對於你所下結論要三思。
■ 聚焦於探索、發現、調查、學習產品，而不是聚焦於證實那些我們本已經知道的東西。
■ 對你所瞭解的產品做報告：說明該產品的價值以及對這些價值產生的威脅。
■ 試圖從你所能想到的各個層面上全方位理解產品是如何工作的。欣賞產品的複雜，當你有這樣輕率的想法，比如修復一個問題是如此的簡單、或者試圖發現代碼中的所有缺陷，這時你該停下來反思。
■ 對開發人員所做的工作表示真摯的興趣，如果適合你的話你也可以學習編碼。至少了解一些代碼是如何工作的以及代碼是做什麼的。
■ 永遠不要告訴開發人員他們應該如何做好他們的工作。如果你真的認爲這是你應該做的，試着問問這個現實的問題：如果他們也同樣的對你（告訴你應該如何做好測試），你是什麼感覺？
想知道如何影響管理者嗎？
■ 提供給他們需要的信息，以便做出更明智的決定。
■ 始終保持清醒，管理者們做的是商業的決定，不僅僅是技術的決定。
■ 知道產品不一定非要切合你的質量標準。
■ 讓你高興不是開發經理的工作，也不是任何其他人的工作。幫助你工作更高效，可能是他們工作的一部分。你要讓他們瞭解如何做到這一點。
尤其要注意的是：
■ 使測試變緩慢的問題是可怕而重要的，因爲它們使得缺陷可以隱藏得更久更深。所以在報告中不僅要描述產品的缺陷，還要描述阻礙測試的問題。
■ 如果你想提供些信息用於改進開發的過程，那麼報告一下你的測試時間是如何分配的。
■ 注意到，通常都是這樣，爲什麼測試需要這麼長時間呢—你只花了極少的時間用於實際測試產品，而花了大量的時間用在缺陷調查和報告、測試準備、會議、文案、和其他爲了獲得更高測試覆蓋率而進行的中斷事務上。
■ 專注於測試報告的準確性（5%或10%）而不是精確性上。因爲軟件開發中的大部分問題都可以基於這些一手的度量數據而發現和解決，無需那些基於反正是無效的模型而進行的六十進制分析的數據。
■ 向管理者展示你所發現的大部分問題都不是簡簡單單地通過重複執行用例就可以發現的，而是通過測試用例所沒有覆蓋到的步驟和觀察發現的–也就是說，是通過你對產品進行的一次次睿智的調查而發現的。
■ 幫助開發人員和管理者之類的人認識到，測試自動化，遠遠不只是編個程序讓機器自動去代你敲鍵盤。
■ 讓每個人瞭解自動化對某些種類的測試是有益的，但同時也極大地限制了測試的其他方面。
■ 幫助人們認識到測試和檢查的區別，認清二者各自的價值，認識到優秀的檢查需要具備大量的測試技能。
■ 用你的實際工作去證明測試是對產品的一次技巧性探索，讓管理者認識到恰恰是這點使得你發現了很多缺陷。
■ 幫助團隊認識到軟件開發並不是一個線性的過程，而是一個有機的過程。
■ 幫助管理者和程序員逐漸認清，通常所說的”測試階段“實際上應該叫做”缺陷修復階段“。
■ 當被要求籤署產品時，禮貌地提供你的測試報告，把簽署的權利留給那些意見真正起作用的人：產品負責人。
想贏得你所在團隊的尊重？
■ 爲項目提供測試服務，而不是成爲一個障礙。你是信息的提供者，而不是過程的強加者。
■ 停止去嘗試那種”質量是測試人員的“，”測試人員對質量負責“的思想。並默認項目中的其他人至少是和你一樣關心質量。
■ 認識到你的角色是挑剔的思考，幫助開人員和管理者不被錯誤的假想所欺騙–這首先要起於你自己不被錯誤的理念所欺騙。
■ 讓你的技能、團隊和戰術儘量多樣化。就像Karl Weick所說：”如果你想理解一個複雜的事務，你首先得讓自己變得複雜起來。“
■ 如James Bach所說，去發明適合你的測試。不要滿足於其他人所說的（包括我說的），基於你的知識、經驗和技能去實地考證。經常在你所處的圈子裏看看別人都是怎麼測試的。
■ 如果你發現有什麼東西可以幫助你提升你的知識或感官，有助於提升你的測試能力，就去學習它。
■ 學習測試技能，尤其是挑剔地思考的技能，同時也包括系統思維，科學思維，社會生活的信息，人機交互，數據表示，編程，數學，測量… …
■ 實踐你需要的和讀過的技能。通過參加週末測試活動提升你的技能。
■ 找一個當地的導師幫助你。如果你找不到，可以到互聯網上找。請求幫助！
■ 不要屈服於外界壓力而成爲別人交易中的商品。參加認證意味着你花了錢卻成爲和其他成千上萬人無異的人。要有你自己的標誌。
■ 要知道，過程模型只是模型和過程模型–特別是那些涉及人類活動如軟件開發的過程–很多真正的實際項目中發生的細節並未包含其中。
■ 聚焦於提升你的個人技能和思維，這樣你就可以適應任何過程模型。
■ 分享你自己的軟件測試中的經驗教訓和完美軟件以及與有關測試的幻想。
最後，如果你是一名測試人員，遠離質量保證部門。成爲你能成爲的最好的測試人員：一個熟練的調查者，而不是一個程序員或者項目經理的崇拜者（作者注：和Michael交流後，最後一句表達的是，”。。。成爲一名熟練的 調查者，而不是缺乏技能或相應權力的情況下卻想成爲一個程序員或者項目經理。”）。