苦逼的測試工程師面對坑爹的需求文檔

　　剛開始做測試的時候，認為作為測試依據的需求文檔或功能說明書應該是條理清晰，一目了然的?？墒呛髞聿虐l現：

　　經過兩周苦逼的研究需求文檔的過程，我總結了一下兩個原因：

　　(1)由于測試人員對于業務的不理解，面對一個陌生的業務領域，生僻的各類名詞術語，不知所云?？墒俏覀?a href='http://www.kjueaiud.com/ceshi/ceshijishu/rjcsgcsrm/' target='_blank'>測試人員從何處來理解業務呢?除了公共的業務知識可以從網絡上獲取外，最重要的系統專業相關的業務知識，我們只能從文檔中獲取，或者從開發人員或需求人員或有經驗的測試人員那里獲取。

　　可是在很多公司的測試人員流動性很大，常常面對這樣的狀況：因為是維護項目或者新增特性，那么開發或需求人員不可能再從頭至尾給你系統詳細的講解業務需求。而熟悉需求業務的測試人員可能已經離職，又沒有較好的文檔，那么就沒有良好的獲取業務知識的途徑了。

　　(2)需求文檔或功能說明書思路不清晰，信息不全，前后矛盾。造成這種現象的主要原因是寫文檔的開發人員或需求人員的水平問題。很不幸，我們現實中常常需要面對這樣的文檔。那么有人就要說了，干嘛不直接問寫文檔的人或者讓他重新寫呢?假設我們可以實現這樣的要求，那么你想這樣思路不清晰的需求或開發人員能給你講清楚嗎?即使讓他重寫，你保證就能理解嗎?

　　那么就好像玩推理游戲，反復的研究文檔，找關鍵字，加以各種猜測、推理。然后整理出自己認為的流程和規則，逐條與需求或開發來確認。

　　當然問題是要解決的，現狀是需要改善的。第一個問題可以通過本維護項目測試經驗的積累來解決，同時積累良好的文檔來方便后來者。第二個問題卻比較難解決了，這樣的測試外包項目，我們站在比較被動一方，不好對客戶有太多的要求，只有祈禱能潛移默化的影響他們了，哪天他們看我們的問題列表看煩了，突然覺悟能寫出更清晰的文檔來給我們。

原文轉自：http://www.kjueaiud.com