程序猿告訴你，沒問題不用測，信了你就輸了（首發公衆號：子安之路）

用例千萬條，質量第一條。 

流程不規範，親人淚兩行！

 

昨天襯衫哥接到新的上線需求提交到測試，功能很簡單。

程序猿童鞋告訴我，不用測了，沒問題的。

這個時候，剛工做不久的測試童鞋可能本着相信同事，抹不開情面，選擇不測或者少測，直接發給運維童鞋準備部署上線了。

若是是這樣的話，測試童鞋準備被上課了：上線後有問題，都是測試的鍋了。

測試第一準則就是：不要相信任何人說的話。眼見爲實，任何事情都須要驗證過，以可交付的文檔，原型等文字內容爲準。爲何？

由於要隨時防止背鍋啊。

上線前，項目經理催你進，產品經理催你，運維催你，銷售也催你。

上線後，出問題了，他們第一反應就是，測試怎麼沒測出來？

所謂，催進度他們來，背鍋測試去。

這個時候，須要須要把以前評審過的測試用例甩出來，漏了你們都有責任，有鍋你們一塊兒扛。

與產品的聊天記錄，郵件把需求不清晰，上線前還在變動需求的鍋甩回產品。

測試計劃要把各類風險多描述清楚，特別是測試時間被壓縮會致使漏測的風險標註出來。爲何？由於項目開發進度歷來都是不夠的，測試時間歷來都是被壓縮的。

沒錯，這就是it行業裏的潛規則之一。

不要信什麼敏捷開發，背靠背開發，都是爲了減小程序猿們的文字工做。之前的開發模式，特別是須要CMMI3以上的，開發過程當中各類文檔，寫的項目成員是欲仙欲死。

因此如今流行敏捷開發，開發文檔少，程序猿童鞋舉雙手同意。但這種開發模式對團隊人員的技術能力以及溝通能力都有比較高的要求的。

國內敏捷開發就是產品經理一通抄，一天搞定一個原型，大概過下主流程沒問題就開幹。

遇到原型不清楚的就靠程序猿童鞋問，或者本身拍腦殼本身發揮。

發揮出一個版本，客戶不滿意，接着第二，第三個版本搞起來。

這樣趕項目，程序猿童鞋天然是各類偷懶，能省則省。

測試測出來就改，沒測出來等上線發現bug，測試背鍋。

測試上線報告這個時候，須要把項目的bug狀況介紹下，只說測試用例覆蓋的已經完成，發現的bug已經修復，而後把是否能上線權限給產品或者項目經理，同時沒bug這種事情絕對不能說滿，凡事留一線。