三年前給B公司測試團隊轉型的建議

Time：2015年6月7日(星期天) 中午12:05

背景：B公司有20-30研發人員，測試團隊新成立幾人。

問題：

一、在最後交付中APP產品質量一直上不去，使用問題居多；

二、研發過程當中開發並不參與測試相關工做，也不知道應該怎麼保證質量；

三、須要組建專業測試團隊對產品質量負責。

溝通分析點：

一、流程當然重要，但不是最關鍵的東西，它能幫助你固化環節，但不能幫助你把事情作得更快、更好，關鍵仍是團隊；

如今加再好的流程，也不能幫助解決問題，團隊的基礎、積累、沉澱決定了走多遠；

若是非要有個流程，現階段比較合適嘗試《全程軟件測試實踐》http://www.infoq.com/cn/articles…

二、目前團隊最缺的並非測試人員，是團隊（研發、產品等）重視質量的程度；

有沒有人重視，有沒有深度用戶，有沒有人和產品的生存聯繫在一塊兒，這些都是要思考的問題

三、開發進度夠不夠快，開發質量夠不夠好，會不會步子太大容易扯蛋；

技術債務永遠都存在，只是可以還清、不能還清的問題了

改進策略建議以下

一、找bug獎勵制度

全員參與找bug，包括研發、測試、產品、市場人員，動員一切可用的力量，及早攔截問題到用戶手上；本身的狗糧本身吃，找到的bug制定評分機制，給予獎勵。

二、前端框架的易用性（例如Android），將下降開發、維護成本，更加快速響應問題修復

可靠性和用戶體驗，永遠要找一個平衡點，可靠性都不能保證，最後再美觀都是扯談的事實，

長遠來講，要考慮前端界面開發的高效，積累一批人才，最終仍是要人來完成。

三、從產品設計、需求階段開始介入測試要點分析

什麼意思呢？簡單來講，產品設計了一個原型圖，全部元素都在上面了，功能性的也肯定了，

這個時候就能夠根據原型圖進行要點測試了，根本不用去運行任何app，固然前提是要有對業務吃透的人員來分析，

具體方法能夠參考《敏捷腦圖用例實踐之路》：http://www.infoq.com/cn/articles…

團隊可以作到根據原型圖就寫出核心測試要點了，其餘查漏補缺就是開發過程去完成了。

四、持續集成+代碼分析

jenkins+sonar，用來支持Android、java後端平臺的持續構建，代碼分析，行程平常研發過程當中質量閉環活動：發現問題-->解決問題-->繼續運行代碼分析。

五、分析每一個版本的bug緣由

爲何？bug都是血的教訓，頗有價值的，舉個例子：

首先分析問題所在，其次分析引起這個問題的框架、控件，最後分析：自身團隊的技術緣由，仍是官方的框架問題

不斷積累缺陷庫經驗，能夠從中指導團隊成員改進，我猜不少作Android的對控件特性都不熟悉，只是懂得用，可是不太懂怎麼用的更加好，若是是這種狀況，他可以完成業務，

可是不能保證業務流程的可靠性、穩定性，因此仍是團隊有沒有一個主心骨，可以從中總結出問題去改進；

六、團隊不須要專職測試人員，前提是什麼？

團隊成員全體測試，全部人多業務、設計都很是熟悉，全部業務、設計通過你們的評審，都認同，而且可以指出關鍵點（也就是測試須要留意的點），

並且還有一套有效的機制來驗證這些點的問題，這樣子的團隊才能夠徹底脫離專職的測試人員，作到人人蔘與，外界宣傳的Google測測試研發比例是1:10，其實中間作了不少事情，你們都不懂，只是去看表面，Google的測試更加細分，以下圖所示有三種角色；

另外經過測試成熟度來區分團隊，因此不要盲目去追風，國內的團隊還更不達不到這個水平。

最後一點：又要研發進度，又要測試質量，還得確保用戶買單，能怎樣？

增強團隊兼備開發、測試技能，從中提拔有能力者去突破而且帶領團隊開拓新天地，另外培養熟練業務人員把關，列舉關鍵業務點測試，積累相關缺陷經驗庫指導避免重犯問題，而如今最重要是把團隊成熟度提高，打好基礎，把質量債務最致命地方先還上。

用一張圖來表達目前比較好的成熟團隊合做方式，僅僅是作好開發階段，都很棒了。

這裏並無提到自動化，當時測試團隊起步的基礎都沒有，談何自動化容易呢

（微信公衆號：樂少的黑板報）