測試文檔是測試人員在測試過程中輸出的測試工作產品，類似於軟件工作產品，是形式化測試過程的重要組成部分。IEEE 829是軟件測試行業內最有名的文檔標準，它提供了一種很好的測試文檔描述，同時描述了測試文檔之間以及與測試過程之間的關係。
行業內不少公司在使用IEEE 829測試文檔標準，或者以IEEE 829爲基礎開發自己公司的文檔模板，但是實際的結果並不樂觀，主要表現在：
1) 成本較高：測試人員需要花費大量的時間投入到測試文檔的編寫，按照模板填充類似格式的案頭工作；
2) 效果較差：按照測試文檔模板編寫出的並不是特別有價值的大量原始材料，甚至由於時間的限制，測試文檔幾乎在測試過程中沒有什麼人看；
3) 文檔維護成本高：特別是在測試文檔的輸入軟件工作產品變更的時候，不僅要修改捆綁到軟件變更部分，而且還要搜索必須修改的其他有關聯的內容。
因此，純粹照搬使用IEEE 829測試文檔模板，或者公司內部開發的文檔模板並不是提供測試文檔的初衷。爲了提高測試文檔模板的效率和有效性，測試人員需要考慮測試文檔需要解決什麼問題，它的主要目的是什麼。假如希望編寫出好的測試文檔，需要有測試文檔模板的支持，而更重要的是測試人員需要了解模板沒部分的含義，爲什麼需要有這部分，什麼時候可以刪除這部分內容，即測試人員必須能夠根據公司特徵和項目特點合理裁剪測試文檔模板。
決定什麼內容包含到測試文檔中，什麼內容不包含，應該以項目需求爲基礎。爲了更好的確定測試文檔模板的深度與廣度，即合理裁剪測試文檔模板，測試人員至少需要考慮下面的這些因素：
1) 測試目標
測試人員測試該產品或者系統的目標是什麼。假如測試文檔不能支持這個目標，或者無助於達到這個目標，那麼這樣的測試文檔（與所創建的所有其他軟件工作產品一樣）價值就會降低很多。
2) 測試文檔是產品還是工具
假如測試文檔是軟件系統或者產品的一部分，那麼這些文檔是需要發佈給客戶使用的，這時候測試文檔就需要按照客戶的要求遵循某種表尊。而假如測試文檔只是內部使用的工具，那麼就不必太完整、太整齊，能夠在最低限度上有助於達到目標即可。
3) 軟件設計變更是否頻繁
如果軟件設計變更很頻繁，則不要將許多細節寫入測試文檔中，因爲這些細節很快就會過時。這種情況下，不要編寫大量的測試文檔，它們被修改或者放棄的速度太快，不值得在測試文檔上投入太多。
4) 採用的測試方法
假如目前採用的軟件開發模型是V模型之類的線性模型，那麼採用的測試方法通常是依賴於預先定義的測試，這時候需要詳細的測試用例的操作和維護文檔。假如採用的是探索性測試，則更需要策略方面的文檔，例如：關於某個測試領域的想法，但不是具體的測試用例。
5) 測試文檔給誰看
假如測試文檔是主要給新的測試人員或者沒有經驗的測試人員看，那麼需要足夠詳細使得他們能夠正常開展工作。
測試人員在裁剪測試文檔的時候，上面的這些問題可以幫助測試人員思考，寫出他們所需要的東西，以及內容的詳細程度，以達到測試文檔的目標。