筆者從事軟件行業相關工作將近十年，其中與測試相關時間有7年之久，現淺談軟件項目管理中測試的必要性，供大家參考。
一、測試的必要性
為什么需要測試，那是因為由于分工的精細化，軟件開發必須經歷客戶、需求、設計、開發多個環節。為了保證最終的結果符合要求，上下游是需要確認的。
用戶告訴我們：我需要什么？軟件企業需要在理解正確、表達正確的情況下完成需求規則說明書，把客戶的原始需求轉變為IT需求，表達出能夠提供什么
需求的下一環節是設計，設計主要是要要說清楚：我要讓軟件做什么。需要與前一環節確認理解正確了、設計正確了、表達也正確了
接下來就是實現了，程序告訴計算機怎么做，最終保證能夠運行出結果，而且運行的結果與用戶要求是相符的。
正式因為一個項目參與環境眾多，為了保證客戶需求在傳遞過程中盡可能少的丟失，我們需要反復的校驗、確認，也就產生了測試。
傳統的觀念中把測試定位于從程序員到運行結果這一段，實際上強化每個階段的確認、特別是用戶需求到需求規格的確認，是更能節省時間和成本的方法。
二、測試管理與質量管理之間的關系
首先回顧一下PMI協會關于質量管理的一些觀點：
第一點就是質量管理的最終目標是使客戶滿意，質量管理的定義就是理解、評估、定義和管理客戶需求，以達到客戶期望；能使客戶滿意的標準就是符合要求且易于使用。這是一個從項目角度出發提出的概念，針對產品研發也應該是吻合的。研發出的產品是為了賣給客戶的，不是為了孤芳自賞的，所以研發成果是否滿足客戶要求也是至關重要的。
另外一點就是關于功能性符合度和易用性符合的強調，現在很多企業很容易聚焦于功能而忽視軟件最終是給人使用，是給不同文化層次的客戶使用的，軟件的易用性往往能夠推翻軟件企業為了實現功能所做的一切努力。
舉例來說，有一個項目，需要實現兩種產品單據的傳遞，因為交付工期很短，我們的開發人員加班加點的完成了功能，但是客戶卻拒絕接收。原因在于引入單據之前需要進行兩種產品基礎資料的匹配，開發實現了這個功能，卻忽視了客戶有大概2000條基礎資料需要匹配，沒有提供批量匹配的功能，最終客戶試用中感覺工作量無法接受，拒絕驗收了。前面所有加班所有的努力都白費，原因就是忽略客戶的易用性需求。
可能對于產品研發而言，沒有這么強硬的結果，但是一些功能不好用對客戶滿意度的影響還是相當多的。所以個人認為把產品通過測試的標準定位與符合要求且易于使用是非常恰當的。
第二個觀點是預防勝于檢查，這是很容易明白，但是實際過程中又不大容易做到的。因為客戶的壓力，很多企業的發版是很頻繁的，發版之后是否有人來總結這次版本研發中碰到了什么問題，哪些缺陷影響了發版時間，下次版本中需要一些什么預防措施？如果沒有這樣的一個過程，沒有缺陷的一套分析和預防機制，很多類似的問題會不斷的出現，版本的質量以及補丁的壓力會像滾雪球一樣越滾越大，最終使得整個研發團隊難以負荷。
第三個觀點是關于管理層責任的，提出PDCA循環的戴明就說，85%的質量問題應該由管理層負責，只有15%的責任是團隊負責。很淺顯易懂的一個道理，假設公司老板對你說，這個版本你一定要保證質量，有一個問題都不能放行！你想這個版本質量能差嗎？
換一種場景，你告訴老板有幾個核心問題還沒有解決，沒有達到發版條件，老板卻說，客戶壓力大，你先發出去，后面再出補丁！結果又會如何呢？
老板當然不可能忽視客戶對工期的要求，不惜一切代價的保證質量，但是當成本和質量進行權衡的時候，老板會偏重哪一個，直接影響最終產品的質量；
老板在質量文化減少方面、過程改進方面重視的程度，也將直接影響這個公司所有產品的質量。
這就是管理層的責任！
提出這個觀點的戴明還有一個觀點與PMP相關體系非常符合，即質量并不是由工作人員的能力決定的，而是取決于如何開展工作的程序和制度。之所以要進行項目管理的認證，就是要讓項目管理的整體能力不因為個人能力產生較大起伏，如果都能按照組織確定的流程進行相關活動，最低水平也能被保證。
第四個觀點是持續改進原則，持續地、漸進地改變來改善情況，中國的俗話也說的好：飯要一口一口的吃，別想一口吃成一個胖子。
那測試管理到底與質量管理有什么關系呢？
在量管理活動中，測試是質量控制的重要手段。
三、測試相關原則
上圖中也提到了測試的基本原則，在此做簡單描述，歡迎大家拍磚。
1、盡早測試原則
盡早測試原則與馬丁分析出來的結論有非常大的關系，一個缺陷在需求階段被發現所產生的糾正費用是產品交付后維護階段發生費用的兩百分之一。
有軟件公司也曾經做了簡單測算，1個缺陷留到客戶處被發現，所耗費的成本在50萬左右。
或許引起客戶怨聲載道的嚴重缺陷，在需求環節解決只需要增加一行字的清晰描述，在編碼階段只需要多增加幾行代碼，可是一旦到了客戶哪里，便成了投訴、安撫、補丁、責任追究等一系列的緊急事件。
2、Good-enough原則
Good-enough原則其實是針對測試本環節來說的，也體現了項目管理思想中關于質量和成本直接的關系。如果以精益求精的思想，能夠到底“零缺陷”是最為完美的一種狀態。可是從投入產出的衡量來說，零缺陷是很不劃算的。理想狀態下的測試系統，根據帕累托的二八原則，研發測試應該至少發現80%的bug，而最好只有5%的缺陷是由客戶發現的。之所以要推行good-enough的原則，是因為在項目中時間、成本、質量是永遠不可調和的矛盾，不論是高層還是基層的測試負責人，軟件項目管理人員都需要對自己負責領域進行一定平衡和妥協。
總而言之，做好了測試的管理，對于軟件項目的成本、工期和質量管理都有非常大的好處，但是目前國內的很多軟件企業卻不重視，特別是針對客戶的定制項目，希望未來一段時間能夠得到改觀。