軟件測試人員與開發人員的戰斗:我不是一個人在戰斗

　　作為一個軟件測試老兵，經常聽到有測試新人抱怨，需要和開發人員進行激烈的討論，感覺像打仗一樣。其實，測試人員和開發人員的戰斗不僅僅在小公司有，在大型軟件公司也是比比皆是。這種戰斗不僅僅發生在開發周期的初期，也發生在開發過程中，甚至在產品發布后，很多產品質量問題的追責也會引入新的戰斗。

　　作為一個老測試工程師，也聊聊開發人員和測試人員的戰斗，談談自己的心得吧。

　　先說說戰斗的種類。

　　1)缺陷(Bug)屬性之戰

　　對于一個缺陷，開發人員和測試人員有不同意見，例如，開發人員說是“建議”，測試人員說“代碼缺陷”;開發人員說是優先級3的，測試人員說是優先級1的;開發人員說不能重現問題，測試人員說曾經出現，必須調查。

　　2)產品指標目標之戰

　　對于一個產品達到什么要的指標，也是測試人員和開發人員討論的熱點。例如，測試人員說性能必須到達200毫秒，但是開發人員常反駁說500毫秒是合理的目標。雖然，在需求說明書中，產品經理規定了產品大的指標，但是一些執行的細節目標卻沒有仔細規定，這往往是開發人員和測試人員的戰場。

　　3)質量任務之戰

　　質量保證的任務有很多種，包括寫單元測試，收集試驗數據，搭建環境，功能測試，安全檢查等等…. 那么這些任務究竟是如何安排的，是測試人員做還是開發人員做，不同公司有不同的文化，有不同的開發測試人員比例，導致其分工也不一樣。有時，開發和測試對于一些任務的責任人也有著不同看法，這也往往會成為戰斗焦點。

　　4)代碼質量之戰

　　代碼的質量的好壞，是否可接受也是在代碼審查時經常討論的，比如一些異常的處理，是否合理，覆蓋面是否全面。

　　測試人員的戰略和戰術

　　很多測試人員在這些戰斗中不容掌握主動，以下就是一個老兵的一些經驗，希望能夠幫助測試人員在戰斗中更好的贏得主動，為高質量軟件產品贏得勝利?？偟膩碚f，對于測試人員說，是保護用戶的體驗，因此有機會得到更多人的支持，換句話說，測試人員”不是一個人在戰斗“。另外，”多算勝，少算不勝“，討論前盡量多準備準備。

　　1)多引用用戶體驗，多引用競爭對手的數據作為論據

　　在討論中，列舉的論證時，如果測試人員的論據是以“我認為…..”，這種論據通常是不是很令他人信服的，因為開發人員也可以說”我認為…不是這樣的..'’。因此，在討論中，應該多引入用戶體驗的數據作為支持論據。另外，可以多多列舉競爭對手的數據，也是很有說服力的。

　　舉例來說，一個用戶登錄界面，產品需要3秒鐘登陸了，測試人員認為很慢，開發人員認為可以接受。那么，測試人員可以指出，在這種設計下，用戶體驗很差的，用戶需要更好的性能，同時可以列舉一些競爭對手的登錄時間作為參考。少說”我認為…..”，多說用戶體驗差的具體數據。

　　2)爭取項目經理或則產品經理的支持

　　產品經理通常也是產品質量的堅決擁護者，因此產品經理通常都站在測試人員一邊。如果在用戶體驗上，開發與測試人員的觀點僵持不下的話，可以考慮將產品經理引入討論，通常產品經理會支持更好的用戶體驗，而站在測試人員的一邊。獲取產品經理的支持，注意引入的次數與頻率，如果引入過于頻繁，有時容易導致開發人員的不滿。

　　3)存同求異

　　對于一些非關鍵的爭論點，例如，一些與產品質量沒有本質影響的決定，測試人員可以與開發人員保持不同的觀點。對于這些不同觀點，不會影響項目的進展和產品的質量。

　　4)速戰速決

　　孫子言”兵貴速，不貴久“。測試人員的工作通常繁重，如果花大量時間和開發人員爭斗，往往得不償失的。其實大部分討論，在前5分鐘，雙方都已清楚的表達了觀點，列舉了大部分的論據，因此5分鐘后的大部分討論，都是這些觀點和論據的反復陳述，通常無法通過論據本身說服別人。因此，我提倡對于單個問題的討論，不應該超過5分鐘，測試人員應該控制節奏，5分鐘內結束討論。如果5分鐘內仍然沒有結論，測試人員可以主動結束這次討論：對于原則性的問題，考慮另外收集更多的論據(數據)，獲得更多人的支持，另找時間再和開發人員繼續討論;對于可以權衡的問題，可以考慮相互讓步，已得到雙贏;對于一些小問題，可以考慮抓大放小。

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