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