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