缺乏文檔應該怎麼樣進行測試？

擷取正確的資訊對於很多公司來說都是挑戰，而且即使你獲得了所需要的文檔，但是缺乏你真正需要的資訊。我曾經看到過大量的不同品質程度的文檔（從優秀的到停用），但是我喜歡項目在兩個不同的階段有兩種不同的方式組合。

一開始，項目使用XP的方式開展，系統從零開始構建，而我作為測試人員就整天與開發人員和項目主管呆在一起。在那段時間，我學到了關於系統的所有東西，包括內部的細節，即使沒有什麼文檔。

在軟體提交給客戶後，項目組到了第二階段，我們從XP轉移到更傳統的方式，開發人員和BA（業務分析員）寫一些粗略的說明書。在初始版本構建完成後，我獲得了發布的記錄，裡面記錄了由BA和開發人員寫的背景資訊。

雖然我在後期階段才介入，但是接下來的階段都只有很少的特性被加入，所以我仍然能夠很好地工作，因為閱讀這些發布記錄就已經足以讓我瞭解清楚擴充了什麼東西，我應該尋找哪些方面的bug。

在另外一個項目，我是個開發人員，我們只有少得可憐的文檔，但是我們會邀請目標使用者每隔六周過來用一整周的時間測試我們的系統。在那段時間裡，我們每天都修正bug並且討論哪些功能特性需要在下個迭代周期加入。那個產品的品質出奇的好，而在那個時候RUP和XP對於我們來說還是個未知的名詞。

在另外一個項目，我一開始就得到很糟糕的文檔，還有停用發布記錄。開發人員工作在另外一個國家。BA和項目主管忙著在全世界推銷正在開發的軟體，測試人員則努力嘗試弄清楚系統要做什麼。

功能測試在幾個分開的郵件中有解釋，但是有時候內容是互相矛盾的。

在這種沒有文檔或文檔很糟糕的情況下，我通常傾向於請開發人員示範功能特性，而不會強迫他們去寫只會包含部分需求資訊的糟糕的文檔。

這些項目經驗告訴我，與其過分關注需求文檔，倒不如讓項目組的所有成員都緊密地工作在一起，確保你得到成為所測試系統的領域軟體測試專家需要的資訊。我也同意這種方法可能在航空領域和醫學行業不那麼容易生效。