讓bug扼殺在搖籃裡

1.qa全方位參與整個

軟體開發過程，例如當ba和開發人員kick off乙個卡的時候，qa參與討論，提出一些需要程式設計師自測時候可能會忘記

測試的點，此外，qa往往對業務更熟悉，可以提供建議給程式設計師，那些業務細節不能夠忽視，以防止這些地方出現

bug。

2.當開發人員做完卡時候，需要把卡sign off給qa，在這個過程中，會在開發本地環境演示，期間如果出現缺陷，開發人員會重新把卡放到in dev列進行修復。直到開發人員本地環境都沒有問題後，qa才開始正式測試。

3.把 jmeter的

效能測試指令碼加入到ci中，每次提交**會跑一遍效能測試指令碼，確保每次新**的提交，不會破壞產品關鍵流程的效能。

4.建議團隊使用**缺陷掃瞄工具，避免一些通用的bug的出現。

5.建議團隊的把

單元測試覆蓋率提高到一定程度，例如80%，可以減少新的功能**對原有功能的破壞。

6.建議團隊根據實際情況去使用bdd的方式（cucumber）去寫

自動化測試用例，可以讓專案的pm，ba，dev，qa等人對業務有一致的理解，減少由於業務理解不止出現的bug。

7.多寫一些測試blog發布在公司內網發布，幫助開發人員了解哪些地方容易出現bug。

8.我如果碰到了一些比較有趣或者通用的bug，會在團隊的每天早上站會，或者下午code review時候，跟大家分享，這樣大家都會知道這種型別的bug。

9.有些開發認為開發出的介面和設計稿有一定偏差問題不大，但是我建議介面盡量按照設計稿做，因為幾個畫素的偏差，乙個按鈕位置的不同，一塊區域透明度不夠等，都會造成整體美感的下降。經過和團隊合作一段時間後，大家實現的介面和設計稿更加貼近或者完全一致。

10.建議開發把重要的，或者一些特殊的實現思路，以及一些需要別人知道的細節，

記錄在jira的卡中。因為敏捷團隊中，文件比較少，而jira卡中記錄了這些資訊後，將來任何人拿到這個卡，都能很快了解上下文和這個卡有無特殊實現等。我自己做測試時候，如果碰到一些比較有趣的卡，也會記錄下測試思路和測試資料。

11.建議開發和qa結對測試，傳遞測試的方法和思路。因為在探索性測試過程中，使用結對測試的方法，可以比較有效的傳遞知識。

12.有些開發缺少橫向對比同類產品的意識，因此開發出來的功能會不易使用。建議每個人都應該關心和對比同類產品的優缺點，這樣才能讓自己做出的功能模組來更有競爭力，更好使用。

13.當qa測試的非常仔細的時候，開發自測的仔細程度也會相應提高很多。例如，剛進入團隊時候，有些開發自測時都很少考慮多

瀏覽器相容性測試，於是瀏覽器上經常會出現bug。我告訴大家，我每次測試都會在所有需要測試的瀏覽器上進行測試，而且每次出現bug後，我都會把卡挪回開發重新處理。因此在和團隊一起

工作一段時間後，大家在不同瀏覽器上自測的力度就越來越大了。