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