測試不是對抗而是一劑預防針 - 我們一起學項目管理 （三十七）

對於一個軟體的開發團隊而言，測試雖然並不直接參与開發，但是確實對於軟體質量是一道保障。唯有他們可以站在終端用戶的角度對於系統進行測試。摒棄主管因素的影響，客觀的尋找bug，捍衛軟體質量。

經常會聽到測試和開發在某些團隊里吵的不可開交。大有水火不容的趨勢。

測試覺得開發不好好寫功能，在沒有完全驗證自己代碼功能的情況下就交給自己進行測試，完全是不負責任的做法。

開發覺得測試老是注重一些細節，對於主要功能視而不見。純粹是小題大做。

遇到項目交付來不及了，還看著測試慢條斯理的測試，開發覺得要抓狂。

開發和測試對於同一個功能的理解不一樣，於是，雙方圍繞著這是不是一個bug據理力爭。

以上場景在一個項目團隊應該並不少見。首先對於開發和測試相互有敵意，這是不可取的。無論是開發，還是測試，都是自己的職責所在。開發使用軟體編碼實現客戶要求的功能。測試運用自己的能力幫助驗證功能的準確性。從某種角度來講，雙方都是為團隊為項目出力。出發點一致。

所以基於以上情況，項目經理需要在項目團隊中制定一系列的規則，以幫助大家從規則上，或者說從工作範圍上明確各方職責。以下是我的一些看法，作為一個拋磚引玉，大家看了可以留言做補充：

一、明確各個階段的准入准出條件。

通俗的講，什麼樣的情況下，開發可以交付測試，即結束開發階段轉向測試階段？滿足什麼樣的條件可以結束測試，部署交付？這些條件需要在項目一開始就制定下來。並且告訴團隊中的每一個人。

比如：在測試用例中選出一部分基礎功能，作為smoke test的用例。只要這些用例跑通過了，項目即由開發階段轉向了測試階段。

這樣做可以解決開發隨意改完代碼交給測試人員測試，而自己卻不驗證功能準確與否，從而浪費整個團隊時間的問題。

二、在Kick off會議的時候，明確測試Leader的權利，即在當前屬於測試環節的前提下，test leader有權一票拒絕交付。

可能在這裡有人會覺得這樣的權利過大，拒絕交付造成的損失擔得起嗎？

那麼我們不妨設想一下，這樣的情況：當前在測試階段，明天要交付了，但是測試leader的反饋是目前系統還存在足以使得系統癱瘓的bug沒有修正。如果在這個時候強行交付，可能一時上客戶驗證不出來，但是到了真正上線之後，再爆發出系統癱瘓這種問題，客戶的經濟損失就大了。如果牽涉到支付等功能，情況會更嚴重。

所以如果在這個時候，測試leader提出明天不能交付，就需要注意和衡量了，他所說的理由是否合理。如果當初已經制定，測試階段的准出門檻是嚴重的問題完全修復。那麼在這個時候，項目經理理應支持測試leader將項目交付延期。

提這一點的是為了解決有些項目到最後實在趕的急了，一邊開發還在修bug，一邊已經要發布的情況。即項目質量未達到發布要求的強行發布的情況。一旦此類情況產生，感覺測試與整組人為敵。這是不可取的。也是需要避免的。

三、項目進行過程中保持團隊相關人員的信息透明。確保開發人員和測試人員對於需求的更改和理解是一致的。

我們在項目進行到測試階段之後，經常會碰到測試報了一個bug，開發據理力爭說這不是個bug的情況。於是兩撥人圍繞這不是一個bug爭論了半天，如果此時項目經理不介入，或者BA不介入，爭論會無休無止的進行下去。

為什麼會這樣？因為兩組人理解需求不一致！

這就要求BA在需求講解的時候，做到開發和測試都到場，讓他們理解的一致。在做設計的時候，能夠核實功能。在評審測試用例的時候，能夠找出異議，在項目初期就解決此類分歧。

當然這類問題不能100%杜絕，但是至少降到最低，那麼在正式測試的時候，偶爾發生一兩次，BA再做一個澄清，也不會對於項目有太大影響。

綜上所述，項目經理在這個時候需要做一個協調人員，不是說站在那一邊，找隊站，而是通過一些列的規則和溝通，將兩隊人員擰在一起，達到高質量的按時完成項目的目的。這更多的是考驗的項目經理的情商。