Time：2015年6月7日(星期天) 中午12:05
背景：B公司有20-30研發人員，測試團隊新成立幾人。
問題：
1、在最後交付中APP產品質量一直上不去，使用問題居多；
2、研發過程中開發並不參與測試相關工作，也不知道應該怎麼保證質量；
3、需要組建專業測試團隊對產品質量負責。
溝通分析點：
1、流程固然重要，但不是最關鍵的東西，它能幫助你固化環節，但不能幫助你把事情做得更快、更好，關鍵還是團隊；
現在加再好的流程，也不能幫助解決問題，團隊的基礎、積累、沉澱決定了走多遠；
如果非要有個流程，現階段比較合適嘗試《全程軟體測試實踐》http://www.infoq.com/cn/articles…
2、目前團隊最缺的並不是測試人員，是團隊（研發、產品等）重視質量的程度；
有沒有人重視，有沒有深度使用者，有沒有人和產品的生存聯絡在一起，這些都是要思考的問題
3、開發進度夠不夠快，開發質量夠不夠好，會不會步子太大容易扯蛋；
技術債務永遠都存在，只是能夠還清、不能還清的問題了
改進策略建議如下
1、找bug獎勵制度
全員參與找bug，包括研發、測試、產品、市場人員，動員一切可用的力量，及早攔截問題到使用者手上；自己的狗糧自己吃，找到的bug制定評分機制，給予獎勵。
2、前端框架的易用性（例如Android），將降低開發、維護成本，更加快速響應問題修復
可靠性和使用者體驗，永遠要找一個平衡點，可靠性都不能保證，最後再美觀都是扯談的事實，
長遠來說，要考慮前端介面開發的高效，積累一批人才，最終還是要人來完成。
3、從產品設計、需求階段開始介入測試要點分析
什麼意思呢？簡單來說，產品設計了一個原型圖，所有元素都在上面了，功能性的也確定了，
這個時候就可以根據原型圖進行要點測試了，根本不用去執行任何app，當然前提是要有對業務吃透的人員來分析，
具體方法可以參考《敏捷腦圖用例實踐之路》：http://www.infoq.com/cn/articles…
團隊能夠做到根據原型圖就寫出核心測試要點了，其他查漏補缺就是開發過程去完成了。
4、持續整合+程式碼分析
jenkins+sonar，用來支援Android、java後端平臺的持續構建，程式碼分析，行程日常研發過程中質量閉環活動：發現問題-->解決問題-->繼續執行程式碼分析。
5、分析每個版本的bug原因
為什麼？bug都是血的教訓，很有價值的，舉個例子：
首先分析問題所在，其次分析引發這個問題的框架、控制元件，最後分析：自身團隊的技術原因，還是官方的框架問題
不斷積累缺陷庫經驗，可以從中指導團隊成員改進，我猜很多做Android的對控制元件特性都不熟悉，只是懂得用，但是不太懂怎麼用的更加好，如果是這種情況，他能夠完成業務，
但是不能保證業務流程的可靠性、穩定性，所以還是團隊有沒有一個主心骨，能夠從中總結出問題去改進；
6、團隊不需要專職測試人員，前提是什麼？
團隊成員全體測試，所有人多業務、設計都非常熟悉，所有業務、設計經過大家的評審，都認同，並且能夠指出關鍵點（也就是測試需要留意的點），
而且還有一套有效的機制來驗證這些點的問題，這樣子的團隊才可以完全脫離專職的測試人員，做到人人蔘與，外界宣傳的Google測測試研發比例是1:10，其實中間做了很多事情，大家都不懂，只是去看表面，Google的測試更加細分，如下圖所示有三種角色；
另外通過測試成熟度來區分團隊，所以不要盲目去追風，國內的團隊還更不達不到這個水平。
最後一點：又要研發進度，又要測試質量，還得確保使用者買單，能怎樣？
加強團隊兼備開發、測試技能，從中提拔有能力者去突破並且帶領團隊開拓新天地，另外培養熟練業務人員把關，列舉關鍵業務點測試，積累相關缺陷經驗庫指導避免重犯問題，而現在最重要是把團隊成熟度提升，打好基礎，把質量債務最致命地方先還上。
用一張圖來表達目前比較好的成熟團隊合作方式，僅僅是做好開發階段，都很棒了。
這裡並沒有提到自動化，當時測試團隊起步的基礎都沒有，談何自動化容易呢
（微信公眾號：樂少的黑板報）