如果是在專門的測試專案裡工作,多半會學到一些測試方法與規範。這裡先保留不提工作上的測試相關工作。先來談平常生活中所遇到的問題。
試想,如果說你上週買了一台冷氣,用了不到一週,今天他突然不會運轉了,於是你撥電話給該公司客服,你會怎麼陳述問題?
「我的冷氣不會動了!」
是這樣的嗎?
其實有這樣客服與顧客之間的對話實際發生過:
「我的電視不能看了,我上週才剛買的!」顧客反應這麼說著
『昨天還能看嗎?』客服問道
「昨天還能看,今天就突然不能看了」
『可以說明一下是怎樣不能看嗎?』
「就我拿遙控器對著電視按電源鍵,但電視就沒反應啊!」
『可以確認一下遙控器是不是還有電嗎?或是你換一組新的電池看看,按遙控器時看上面的發送燈號有沒有亮。』
「我試過了,換新電池後,按遙控器時確認發送燈有亮,但電視就是沒反應!」
『不知道遙控器會不會摔壞了,這樣好了,你走到電視前,從電視的面板上按電源鍵看看!』
「等我一下喔....還是沒反應耶!」
『嗯....可以麻煩你看一下電視的插座有插上嗎?』
「我看看喔....啊沒有插上....」
類似這樣的交談流程會分常冗長,有些公司就會開始利用一些方法教導顧客先做基本的障礙排除,然後在顧客找客服支援前,會再適度的教導顧客要準備哪些資料,例如在產品說明書上就印好一個空白表單,讓顧客準備好問題的背景資訊,以便跟客服接洽時可以較有條理的反應問題。
以上面的例子,在說明書上的基本障礙排除就會先列上諸多檢查項目,諸如檢查電源插座、遙控器、電池等等。針對問題的描述則會請顧客描述故障的種類與細節,例如是開啟電源畫面完全是黑的,還是呈現雪花狀畫面。如果是呈現雪花狀畫面,是不是每個頻道都是如此,有無事先詢問有線電視業者訊號是否正常等等。
在開放的論壇上,也時常有網友詢問問題,類似那種「我的車子突然發不動了」、「我玩遊戲時感覺很卡」、「我的手機執行xx程式就會當掉」等等,千百種的問題,但很常見沒頭沒尾就冒出來一個問題,即使其他網友要協助也完全找不到下手處。
回過頭來看測試領域,通常在規範撰寫軟體錯誤報告時,會要求類似如下的資訊
作業系統版本與語言:
安裝的軟體清單與版本:
問題的重製步驟:
1.
2.
3.
產生的錯誤結果描述:
預期的正確結果描述:
其他附註:
但這是錯誤報告,如果現在是要與其他人溝通一個問題呢?其實我覺得原則是一樣的,當要反應一個問題,事先先要做背景的描述,然後針對問題儘可能的加以剖析,清楚的描述所發現的問題現象,以及敘述預期的正常結果。
好比說如果我想要對台北市政府反應交通問題,那麼也許我可以這麼說:
基隆路與忠孝東路交叉口,在路口西東南側,也就是沿基隆路往北然後右轉東向的忠孝東路這個方向,在上午九點半至十點之間,通常因為已過交通尖峰期,交通警察多半已在九點半之前便已撤離。因此這段時間便開始有很多計程車司機開始違規在路口紅線上,以及公車停靠區域,違規排班,導致公車進站、出站困難,進而造成交通堵塞。建議交警能夠加強此區段的違規取締,以改善交通紊亂狀況。
背景資訊是路段地點,重製步驟是地點加上時間,發現的問題是違規排班,預期的正常結果是加強取締並使交通紊亂獲得改善。
我發現有時有些人在溝通一個問題時,問題被轉了很多手,然後已我旁觀者來看我覺得問題已經失焦了,大概因為在轉手時,收到問題的人往往只花很短的時間看「重點」,然後又轉給下一個人,經常只附帶「客戶反應這個問題,麻煩你看一下」這類的訊息,這時這個信件本身已經很冗長了,如果加上處理人員沒有認真追蹤問題,或是反應問題時沒有提供足夠資訊,往往處理問題的人因為無法重製問題而草率結案。但問題並沒有解決,於是問題又再度透過層層關卡反應,到了最後處理的人員,這時可能已經過了一個月,他大概只有些許的印象,覺得這麼問題又來了,上次不是試過沒問題嗎,然後簡單試一下發現還是不能重製問題,又打了回票。
這樣的溝通就會顯得相當的浪費時間。我通常會建議當發現問題逐漸失焦時,最好是把問題的前因後果等細節重新描述一次,不花多少時間,卻可能讓問題可以快速回到焦點上並在短時間內獲得解決。
一個重點是,通常問題在被轉送時,訊息會逐步被短縮,所以有必要的話,最好每遇上一個新的處理人員,就跟他再描述一次問題。
0 Comments:
張貼留言