影響軟件產(chǎn)品質(zhì)量的因素很多，開發(fā)時間、技術(shù)、員工經(jīng)驗、測試方法、工作態(tài)度...還有一樣我覺得是關(guān)鍵但卻很少被人提及，追究原因就是這個因素很難真正的改變，就是開發(fā)者和測試者的關(guān)系，或者說開發(fā)團(tuán)隊和測試團(tuán)隊在一個公司的組織架構(gòu)。我觀察到三種組織模型：

??? 1）不分你我
??? 這在小軟件公司頗為流行（據(jù)統(tǒng)計70%軟件公司都是小公司）。小公司成立初期最重要的是把產(chǎn)品做出來，慢慢的有客戶之后意識質(zhì)量問題日益嚴(yán)重，開始注意開發(fā)后還要好好測試，再之后發(fā)現(xiàn)自己做的自己測的靠不住，讓team其它人測；最后慢慢的張三做的李四測，李四做的張三測......這些小公司的開發(fā)團(tuán)隊簡直就是agile team的典范啊。除了小公司，很多大公司的小產(chǎn)品在剛剛創(chuàng)立階段，也基本沿襲這種開發(fā)/測試組織架構(gòu)。
??? 優(yōu)點：不用多說，小而快，靈活
??? 不足：這種測試停留在“夠用”即可，別奢望追求完美的質(zhì)量。很多時候產(chǎn)品是在后期客戶使用中不斷修修補(bǔ)補(bǔ)完善的

??? 2）你輸我贏
??? 測試和開發(fā)處于不同的部門，或者說二者雖屬于同一產(chǎn)品，但有著不同的goal，而這些goal又是顯然對立的。以之前我工作的通信公司為例：
?? 做不出來開發(fā)的責(zé)任，做出來被后期測試出來的bug太多開發(fā)的責(zé)任；
?? 測不出bug或者測出的bug沒有達(dá)到數(shù)量測試的責(zé)任，客戶上線發(fā)現(xiàn)新bug測試的責(zé)任；
?? 責(zé)任鮮明。記得每次release完后，我都總結(jié)bug數(shù)，然后每個bug單獨做RCA，每個RCA前后耗若干小時；對嚴(yán)重漏到客戶的bug，見到幾次開發(fā)經(jīng)理開發(fā)工程師和測試經(jīng)理測試工程師開會討論到底是誰的責(zé)任。
?? 優(yōu)點:問責(zé)！無論開發(fā)還是測試都有對產(chǎn)品質(zhì)量都有著鮮明的責(zé)任，有壓力自然有動力，潛力在戰(zhàn)斗中才能爆發(fā)，事實證明對產(chǎn)品質(zhì)量控制是顯著的。我知道還有其它通信公司也采用這種方式。
?? 不足:這種過于對立的立場甚至利益點或多或少對teamwork有影響；而軟件開發(fā)過程中的創(chuàng)新往往需要開放、交流、團(tuán)隊的工作氛圍；此外過于強(qiáng)調(diào)一些指標(biāo)比如測試bug數(shù)目，有時候會導(dǎo)致一些無益的內(nèi)耗。

???? 3）你好我好大家都好
???? 開發(fā)和測試有著共同的目標(biāo)，大家朝著共同的目標(biāo)努力著。這種類似又當(dāng)運動員又當(dāng)裁判員的工作模式，表現(xiàn)往往工作氛圍異常好，開發(fā)和測試在和諧愉快的溝通中達(dá)到一個看似“共贏”的結(jié)果，比如產(chǎn)品永遠(yuǎn)是準(zhǔn)時發(fā)布的。
???? 優(yōu)點：共同的目標(biāo)，團(tuán)隊合作，愉快的工作氛圍...這些都是優(yōu)秀公司的基礎(chǔ)；
???? 不足：這種架構(gòu)下，測試工作的成就感以及對測試工作的激情會降低；你會加班3個小時去尋找一個必然存在但3天才能出現(xiàn)的一個bug嗎？除非你挑戰(zhàn)自己，否則難，因為這種成就感這種架構(gòu)下并沒得到認(rèn)可，大家的目標(biāo)是一塊準(zhǔn)時deliver；同樣，在開發(fā)和測試的“較量中”，測試往往也處于相對弱勢，不是人很“弱”，而是你有必要“強(qiáng)”嗎？此外，對產(chǎn)品質(zhì)量問題責(zé)任不清晰，“是你責(zé)任，是我責(zé)任，最后結(jié)果大家都沒責(zé)任”。

???? 很難說哪種組織方式最好，這取決于不同的產(chǎn)品，市場的需求，甚至公司的企業(yè)文化。

轉(zhuǎn)載于:https://blog.51cto.com/binping/336241

總結(jié)

以上是生活随笔為你收集整理的关于软件质量（2）- 开发 vs 测试的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。