背景
任何產品在研發階段總有那么一些讓人掉坑的缺陷,然而這些缺陷又是怎么去定義的呢?其實各種書籍和網上都有很好說法和定義,在這里就不再細詳說。寫這文章只是個人對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 王子