軟件測試之敏捷的質量

　　最近一周基本上都是加班到深夜，原因是最近有兩個產品的發布，不湊巧的是這兩個產品的開發是還在試用期的新人，更不湊巧的這兩個產品是原來的產品經理遺留下來的需求。需求本身也存在些許需求描述不清晰的地方。所以加班看來就是在所難免的通往不確定未來的必經之路。

　　加班是苦逼和悲催的，但是莫名其妙的加班尤其是加班后的奇妙莫名就就是不可原諒的，作為沒有理想破滅的PM，我就像那個專治各種牛皮癬的老中醫一樣，在各種不服和糾結后嘗試再一次去尋求解決問題的方法。也許我不能看到曙光，但我一定不能允許自己在黑夜中沉睡。因為我TMD就不相信這個世界上有專治老中醫的牛皮癬。

　　互聯網企業和傳統軟件企業在流程上最大的不同估計就是互聯網為了適應用戶需求而必須做出快速反應。所以互聯網企業的研發流程多是敏捷的。敏捷就目的是適應變更，敏捷的表象是快速發布，但是從來不會有Boss告訴我，敏捷就意味著損失質量。

　　項目管理的三要素是：時間、范圍、成本，從來就沒有把質量放在三要素中，如果有人告訴你項目的三要素包括質量，那就讓他去查查PMbok吧。

　　因為對于項目來說，質量是前提，是很難妥協和變通的。但是顯然、質量即使不和時間成線性上的反比，但肯定是反向相關的。一個女人12個月生出來的孩子不一定會更好，但是5個月就把孩子生出來，大概是好不到哪里去了。

　　然后，無論是PM或者Dev抑或是Qa對線上故障都戰戰兢兢、如履薄冰。原因在于老板只看結果，不看過程。出來問題，老板的板子遲早是會打下來的，誰的屁股都不是金剛不壞屁股。

　　快速發布，如何保證質量?

　　在我看來如下三個關鍵點上的質量保證尤為重要1：PRD的Review; 2：代碼的Review; 3：Testcas的Review。當然這里的Review是指保證質量的方法和手段，而不是大家走馬觀花的看看。并且我也從來不認為其他環節尤其是過程的執行力就不重要，就如同一個男人，如果3分鐘都堅持不了，那還談何技巧呢?

　　在這里，我們先假定質量是指狹義上的軟件質量。

　　1、PRD的質量。所有軟件開發模式都認可這樣兩個原則，a：質量是規劃出來的，而不是測試出來;b：越在項目早期進行質量保證活動，效果會越好，并且成本也會越低?；谶@兩個原則，我們就更加可以相信，PRD文檔的重要性。PRD文檔作為產品的Mother和DNA在一開始就決定了產品未來的摸樣，并且PRD是指導開發進行設計開發以及測試人員進行測試設計的關鍵性文檔甚至是唯一文檔。因為PRD文檔在整個產品開發生命周期中的作用牽一發而動全身。PRD文檔的質量依賴于用戶、需求調研的廣度和深度以及需求分析的經驗和技能這無容置疑。但我們在此顯然并不是為了告訴大家如何做好需求分析。我們只從Review的角度來看看如何在最后環節來保證PRD的不出錯，沒錯Review不能保證我們的產品是一款優秀的產品，但是能夠保證這款產品是一個不容易出錯的產品。PRD的Review需要關鍵人物的參與、尤其是當PRD涉及到多個產品項目或者多個模塊時，因為只有關鍵人物才有對系統整體的把控能力，能夠幫助產品人員預防各種潛在和難以發現的陷阱。這些關鍵人員一般包括：業務的代表、開發的代表、測試的代表、運營的代表，這里的代表不是隨便找個人就代表的，應該是這些team的leader.

　　2、代碼的Review。結對編程和測試驅動是敏捷流程在開發階段保證代碼質量的關鍵方法，然后大部分公司的資源都很難允許這樣做。在所有老板的概念中如果公司不出現爭搶資源以及資源不夠的現象，那個就是應該裁員的時候了。然后開發團隊總會有些新人的進入或者對新的項目不熟悉的團隊成員。在這種情況下，讓經驗豐富的工程師去Review新手代碼或者做交叉代碼Review是一種成本較低但性價比還不錯的選擇。

　　3、Testcase的Review。Testcase最應該被保證的是所有用戶操作而導致程序運行的軌跡和分支需要覆蓋，功能測試是無法覆蓋到代碼分支的，這是因為功能測試和單元測試的測試對方不同，但是功能測試已經要覆蓋到用戶的所有操作，正?；蛘弋惓?，以及這種操作下程序可能的處理結果，從而確認結果是符合預期的。在這里有兩種選擇，PM寫Testcase還是專業的測試工程師，在我的職業生涯中，這兩種情況都有發生，但我個人更傾向于由專業的測試工程師來寫Testcase。的確，PM一定是所有人里面對需求最清楚的人，但PM的思維模式是用戶正向參與產品，也就是說絕大部分的用戶是基于滿足自己需求的方式來使用產品的，PM首先要思考的是如何讓用戶的核心需求最容易和方便的得到滿足或者實現。但軟件的問題中80%的問題卻恰恰發生在犄角旮旯的程序毛刺中，而如何從雞蛋里面挑骨頭卻是測試工程師的思維模式。所以說，PM很難寫出來高質量的Testcase。但是，Testcase Review的關鍵人物一定是PM和Dev。沒有誰比他們更加清楚自己設計和實現的產品了。

　　對于互聯網產品來說，重量級的質量保證流程顯然無法適應快捷的發布需求，所以對軟件中關鍵階段的產出進行質量保證是解決問題的最有效方法。但是我并不敢肯定這種方法的普遍適用性，所以你自己看著辦吧!

原文轉自：http://www.anti-gravitydesign.com