是誰的責(zé)任的問題我就不回答了

就算全世界的軟件研發(fā)理論都認(rèn)為測試不能發(fā)現(xiàn)100％的bug,且整個研發(fā)團(tuán)隊需要對bug負(fù)責(zé)

然并卵

最終命中的炮灰大部分時候仍然是測試人員

我來說說怎么辦

測試人員需要怎么有理有據(jù)地保護(hù)自己

首先

事前諸葛亮要當(dāng)

你需要充分了解每次發(fā)布的重點(diǎn)設(shè)計的變更

制定有效的測試計劃

設(shè)計有效的測試用例

與相關(guān)人員review并改進(jìn)

要隨時掌握研發(fā)進(jìn)度

對任何可能影響到測試的變動要非常敏感

并及時做出反應(yīng)

或者修改測試計劃測試用例或者匯報測試風(fēng)險

你甚至要了解程序員的編碼習(xí)慣

知道哪個程序員代碼質(zhì)量可靠哪個是bug大王

對bug大王要掌握他們常犯的代碼錯誤

其次

事后諸葛亮的事必須要做而且要做好

而且非常非常非常非常重要

沒有這一步

你就沒有日后發(fā)言的主動權(quán)

你的測試效率也不會太高

你負(fù)責(zé)的產(chǎn)品的質(zhì)量也不可控

第一條

每個post-relesebug都應(yīng)該做以下分析

－bug的產(chǎn)生階段：需求期？設(shè)計期？代碼期？等等

－bug的產(chǎn)生原因：需求不清楚？設(shè)計錯誤？代碼失誤？測試環(huán)境局限或數(shù)據(jù)不足？培訓(xùn)不到位相關(guān)人員沒理解功能？等等

－為什么沒有在測試階段發(fā)現(xiàn)：測試用例設(shè)計失誤？研發(fā)流程不完善？測試資源不足？測試時間太緊張？測試人員失誤？等等

－以后項目中避免同類bug的方案

第二條

針對整個項目測試做以下分析

－測試coverage分析

－產(chǎn)品bug分布：哪個功能bug成堆，哪個模塊總有最嚴(yán)重bug，哪類功能升級或bug修復(fù)會引發(fā)大規(guī)模bug爆發(fā)，等等

－測試用例效率分析：平均一個測試用例發(fā)現(xiàn)多少bug，針對不同模塊哪類測試用例最有效，等等

－測試效率分析：測試的每個階段消耗資源情況

－研發(fā)流程回顧：整個研發(fā)流程中，哪部分好，哪部分需要改進(jìn)，如何改進(jìn)

－同類項目對比：與同類其他項目比，本次測試在上述方面好在哪兒差在哪兒原因為何如何改進(jìn)

如果你把這些都做了

用數(shù)據(jù)說話

用事實(shí)說話

你就掌握了更多的主動權(quán)

比如你提到的測試只有1－2天

一個月測了幾個版本

我理解你是在抱怨工作量太大測不過來

但如果我是你老板

感情上我可以理解

但理智上我肯定不接受這樣的抱怨

建議你換一種說法：

老板

按以往同類項目經(jīng)驗

這個測試需要3天能夠達(dá)到比較理想的測試結(jié)果

原因是啥啥啥

如果只有2天

我將運(yùn)用啥啥啥測試方案

重點(diǎn)測試啥啥功能啥啥模塊

保證本次發(fā)布的要點(diǎn)被測到

我將不能覆蓋啥啥啥測試啥啥啥功能啥啥啥模塊

因此可能的質(zhì)量風(fēng)險是啥啥啥請問您有什么建議？

很顯然

上述那些啥啥啥

需要你有強(qiáng)有力的數(shù)據(jù)支撐

如果你能說出這些內(nèi)容

并能應(yīng)對你的老板針對你說的這些內(nèi)容可能提出的問題

說明你對測試工作很了解

對被測產(chǎn)品很了解

那么你的測試計劃應(yīng)該是周密的

產(chǎn)品的質(zhì)量是可預(yù)測并可控的

風(fēng)險和意外的幾率是低的

就算最終真的出現(xiàn)質(zhì)量問題

應(yīng)該也不會是大問題

加上事后諸葛亮的處理

這些問題再次發(fā)生的幾率也會非常非常低

如果你沒有這些數(shù)據(jù)說不出這些話

說明你還沒有成為一名合格的測試人員

請聯(lián)系網(wǎng)站客服，了解詳細(xì)的優(yōu)惠課程信息~

優(yōu)質(zhì)、權(quán)威、便捷、省心