1、這個bug我這邊重現(xiàn)不了
解決辦法
Bug應(yīng)該簡明扼要,重點突出。如果描述存在歧義,一定要總結(jié)并盡快改進。有時會遇到概率性的bug,要告訴開發(fā)概率是多少,盡可能多的提供重現(xiàn)的條件。
在復(fù)現(xiàn)問題時,希望能大致判斷幾個問題點,然后和測試人員溝通下,需要如何捕獲信息,捕獲那類信息?是不是提供debug版本進行復(fù)現(xiàn),或者根據(jù)預(yù)判的點增加打印信息版本進行復(fù)現(xiàn)?
2、這個不是代碼問題,需求這么定義的
解決辦法
需求也是人定的,如果覺得有異議,可以找需求人員詢問清楚,為什么這樣定義,把自己的想法告訴他們,看他們怎么決定。如果被需求說服了當然是較好的,如果自己還是不同意需求的看法,需求又不同意我的提議,那只能聽他的,畢竟權(quán)力在他那里。但是我們可以保留交流的記錄,證明曾經(jīng)在這里發(fā)生過歧義。
3、這塊是別人負責的,我負責的部分沒有問題
解決辦法
如果bug是由開發(fā)的項目經(jīng)理來分發(fā)到程序員,那就是項目經(jīng)理來面對這樣的問題,而不是測試。當然,項目經(jīng)理當然有項目經(jīng)理的處理辦法。可是,測試遇到這樣的問題怎么辦呢,把負責相關(guān)內(nèi)容的開發(fā)都邀請到一個討論組里,讓他們自己討論,這樣更清楚,不必在測試這里中轉(zhuǎn)。如果他們都覺得代碼沒問題,而我也有強有力的截圖和真相,那就只有上交給上級領(lǐng)導(dǎo),讓他們來決定怎么解決。
4、有問題嗎?(也就是開發(fā)不認為這是個問題)
解決辦法
測試人員一定比開發(fā)要敏感,對bug的容忍度也要低一些。特別是一些不符合用戶習(xí)慣的bug,開發(fā)總覺得無大礙。比如,一個列表默認的寬度太小了,導(dǎo)致初次打開,有一些內(nèi)容被隱藏在后面,但是這個寬度可以手動調(diào)節(jié)。開發(fā)覺得問題很小,不影響功能,而且也有解決辦法,所以不認為是bug。這個時候,就要發(fā)揮測試的本事了,嘴甜一點,說說好話,態(tài)度柔和一些。因為既然是小問題,解決起來一定不難,耐心地催開發(fā)的改過來就好。催一次不行催兩次,記住態(tài)度一定要好。
5、用戶不會像你這樣操作的!
解決辦法
用戶怎么操作,誰都預(yù)料不到。我們不可能覆蓋所有可能性,但是大多數(shù)用戶會出現(xiàn)的操作,我們當然要測試。慢慢地把開發(fā)從代碼的世界里帶出來,帶到用戶的世界里,讓他換個角度思考問題,畢竟軟件開發(fā)不是為了實現(xiàn)功能,是要滿足用戶需求的。如果最后還是沒能說服他,第一向上級反映,第二做好溝通的記錄,將來備份在測試報告里。
推薦閱讀:
本文內(nèi)容不用于商業(yè)目的,如涉及知識產(chǎn)權(quán)問題,請權(quán)利人聯(lián)系SPASVO小編(021-60725088-8054),我們將立即處理,馬上刪除。