如何證明bug,不是bug/是bug【個人見解】

背景

任何產品在研發階段總有那么一些讓人掉坑的缺陷,然而這些缺陷又是怎么去定義的呢?其實各種書籍和網上都有很好說法和定義,在這里就不再細詳說。寫這文章只是個人對bug理解和看法而已

例:測試web一個頁面時,加載完成的時間達到了5s以上,如果是你在操作,你會怎么去定義這個問題?有以下場景:

1、提出的bug,如何證明它不是bug

測試:這是個bug,頁面加載的時間都有5s以上了,測試了多次都是這樣的,很慢啊

開發:5s的加載時間很正常啊,你可以查查我代碼

需求:5s加載時間至少不會影響使用,客戶沒要求要求頁面響應要多快

項目經理:整體功能為主,這個不響影流程的暫不考慮

領導:能滿足客戶的要求即可

客戶:基本上能達到我們要求的功能和要求

路人甲:不好好測試,浪費時間來研究5s(無語)

路人乙:叫你來測試的,不是叫你來找茬的

路人丙:所有人都沒問題,就你說這個有意義嗎(鄙視的眼神)

……

你所認為的bug,被各種理由無奈的抹殺掉


2、提出的bug,如何證明它是bug

測試:這是個bug,頁面響應和加載時的io過高,經多次測試結果,HTTP 請求的連接、發送請求、等待回應的總時間達5000ms以上了,這樣影響了整體的性能和體驗

開發:有這么高了,我查查代碼

需求:5000ms加載時間太長了,客戶體驗肯定不行

項目經理:那么長的時長,代碼優化一下,控制在200ms~1000ms

領導:用戶體驗很重要,必須把時間縮短下來

客戶:這么長的加載時間,那樣不是很差嗎?我的客戶都不想用了

路人甲:打開頁面要花這么長時間,看來做的不怎么樣

路人乙:這個時間都能測出來,看來是拿著手機在計算時間(這么慢)

路人丙:這是誰開發的(那鄙視的眼神)

……


總結

同樣一個bug,看以什么樣的方式去證明它是什么。提出的問題,不能僅僅是以個人的想法去說服其他人,而是提出有價值且帶專業性的問題,能引起其他人來幫助自己一起去評估這問題,甚至于還幫助去解決問題,這就是共鳴效應。有時候不能以主觀的認知和經驗去判別一件事情的對錯,因為那樣對事件的本身是不公平的。

要善于從不同角度去分析事件的本身的價值和影響程度,是否能真正滿足整體的需求,還有是否是以負責任的態度在做事同樣很重要,對人對事負責任,反過來同樣會回報于己身。

框架理論框架效應,這兩個理論很好的說明了。同樣是指同一件事情,有兩種邏輯思維和意義上相似的說法導致了不同的結果。


End

如果你對測試方面有更好的技術、想法和看法,我們可以一起聊聊。如何改善自己,提升做事效率,個人責任感……


歡迎來撩,但別撩我 ?^ _ ^ ? ? ? --by 王子

最后編輯于
?著作權歸作者所有,轉載或內容合作請聯系作者
平臺聲明:文章內容(如有圖片或視頻亦包括在內)由作者上傳并發布,文章內容僅代表作者本人觀點,簡書系信息發布平臺,僅提供信息存儲服務。

推薦閱讀更多精彩內容