最好把這些想法也打消，我會換一種表達方式。他是對的，有時候是能預先定義出好的測試用例，希望測試員無論在什么情況下都這樣做也沒有罪。
我說：“對，有時候，那樣做是最好的。但在我們現在的情況是，我不知道怎么做好。太多不確定的東西了。我么可以寫測試用例，但是它們寫出來是很糟糕的。充分預先定義測試是要在有可測產品或者基于穩定的、定義良好的技術文檔的基礎上，否則，他們就只是敷衍了事而已。我們的挑戰在于一旦我們能很好地創建的時候創建指定的測試�！�
Adam：“那么你怎么控制測試呢？你有測試計劃嗎？”
一個普遍的誤解是只有計劃文檔才能控制過程�，F在是機會介紹我的不同做法的時候了。
我說：“大部分情況下我們使用探索性測試方法，基于風險的測試方法。如果你指的測試計劃是關于測試過程的一系列的想法，那么我們有測試計劃，沒有寫下來但是作為筆記記在我的筆記本上，但是我可以跟你一起分享一下，如果你愿意的話。實際上，我們是通過頻繁的報告測試狀態并基于產品的風險調整測試策略來控制測試的。換句話說，作為我們測試過程的客戶，我希望你能參與到控制我們的測試中來�！�
“探索性測試”和“基于風險”是強調詞，我希望引起他的注意，問我關于怎樣測試的更多問題。但是有點冒險，有可能弄巧成拙。
Adam：“什么是探索性測試方法？”
好，他上鉤了，他可能以為我在唬他。但是至少他注意到了�，F在是我大加分析解釋的時候了。
我說：“就像對產品玩問問題的游戲。我們一輪一輪地測試。我們同時在學習這個產品，設計測試用例，執行測試，報告問題。我們的測試覆蓋隨著我們對產品模型的理解的改進而改進。我們還會用一系列的測試啟發列表。如果你想看的話我可以現在給你看。這是我所知道的測試一個新的、不熟悉的產品的最快的辦法。你想不想讓測試更快一點？讓測試員了解產品是怎樣的，它是怎樣工作的。我們可以為測試員計劃組織一個一小時左右的產品簡報會，然后再有一個小時左右的問答討論。然后我們可以頭腦風暴一下，為我們想出更多的具體的測試策略，怎樣？”
Adam：“那我們什么時候會知道整個測試過程需要多長時間？”
我說：“我們現在就可以坐下來，仔細看看哪些因素影響：風險、各種測試任務、開發任務。也許我們可以找到方法壓縮一下測試過程，但是我們也要想想其它的選擇。是否考慮我們項目最初的愿望？改bug和測試過程是否會拖延……”
這是典型的走廊解釋。它可能發生在項目會議上，而不是走廊，但是原則是一樣的。我們很少有機會解釋我們的工作，所以要準備好一些例子（例如bug2642的悲慘故事）或一些理論知識。
實踐是少不了的，但是也有一些課程可以幫助你加強你的對話技巧。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
