我說:“我不知道怎樣精確地預測計劃。工作可能很快也可能很慢,要看情況。在Alaska項目,bug2642,記得嗎?它耗費了我們2周的時間把它找出來并重現。結果是與某個著名的防病毒工具有關系。你也很高興能在發布之前把它fix掉,但是我們不能預先知道這樣的事情!
Adam:“我也知道很難評估,但是能否壓縮一下工作,在5周內搞定呢?”
我不明白為什么Adam專注在這個時間范圍。他好像沒有聽我說。如果我回答并解析這個問題,他可能會生氣。走廊解釋的秘訣在于知道什么時候“說教”什么時候“閉嘴”。在現在這種情況下,應該傾聽。
我說:“我知道進度對你來說很重要。但是5周的重要性是什么?”
Adam:“是這樣的,在我們早期計劃的時候,幾個高級經理把時間搞混了。我們都認為發布時間是6月30號,結果是收入時間,發布時間要至少提前3周,以便及時發貨!
我說:“如果產品到那個時間就是還沒準備好怎么辦?”
Adam:“必須要!
我說:“如果不是呢?”
我的問題的目的是把情況說清楚,以便我們能把現實和愿望分開看待。然后我可以向他說明不是只有一個選擇,而是有很多選擇。
Adam:“副總不會喜歡這樣的!
我說:“可能是。但是作為一名測試員,我的工作是提供信息以幫助組織做出更好的決定。我在這里看到多個選擇。最后副總可能會愿意推遲產品發布而不愿意看到一個很糟糕的產品;蛘咚麜M覀儼岩恍┕δ芴匦匀サ!
Adam:“為什么我們不能修改一下策略,獲得我們想要的效果?你自己也說了測試可能不需要8周。我想整個過程能更緊湊點!
現在他看起來接受了不止一個選擇的觀點,他在建議他的選擇,F在他不得不考慮影響決定的因素,這是我想他需要明白的關于測試的東西。
我說:“好吧,我們來看看,首先,我希望你明白測試計劃不是僅僅取決于我,當我們的質量要求很高時,我們需要做更多仔細的測試。如果開發遞交的產品是很不穩定的,我們的某些測試可能會阻塞。如果開發遞交的產品很難讓我們理解和診斷,很難控制,那么測試進度會很緩慢。如果我們找到的bug很多是難以捉摸的、間歇出現的,那么我們的測試和報告會需要更多的時間。如果產品的變更控制沒有管理好的話,我們可能需要做廣泛的測試。如果程序員花很長的時間去修改bug,他們可能不能按時提交測試,不管還遺留多少測試需要進行。你知道我的意思嗎, Adam?如果你想調整計劃,我們就要看是什么影響計劃的!
Adam:“我知道你的意思。那么我可以幫什么忙呢?如果我讓程序員幫你測試怎樣?我們幫你執行部分測試用例怎樣?”
我說:“我們沒有定義測試用例!
Adam:“真的?但是如果你預先組織好測試用例不是更好嗎?這樣不是更快嗎?”
好了,現在我要對付一個不了解測試的人了,我想說:你的需求規格說明書一團糟,但是你期望我們寫出高質量的測試用例文檔?你饒了我吧!
文章來源于領測軟件測試網 http://www.kjueaiud.com/