標籤：

經驗談：文檔測試策略與流程

03-17

導言

收到一位TW新人的問題：該如何去制訂適用的文檔測試策略，這方面，有什麼標準嗎？

好問題！文檔測試是保證文檔正確性與完整性（Easy to Use）的關鍵一環。對於文檔測試的標準，我沒注意到業內出過相關國際國內標準。不過，我很樂意根據以往的工作經驗，總結一下我對文檔評審與測試方法與策略的心得。

主要環節與參與人

對於操作類手冊，評審通常分兩塊：

  • 外部評審：由測試工程師（有時會是開發工程師）與產品經理對文檔進行評審
  • 組內內審：組內同事互審（含Editorial Review)

有條件的還可以請SME對文檔進行綜合評測。比如在穆迪時，穆迪產品管理department有一個由資深銀行從業人員組成的SME組。他們會從用戶的角度對文檔進行評審，為操作手冊提供不少實用的案例，加深用戶對產品應用場景的理解。這些案例的加入，大大提高了文檔的可讀性與專業性。

評審要點

  1. 操作步驟是否正確無誤；對於在線幫助，測試鏈接是否有效；
  2. 功能有無遺漏；
  3. 對概念性問題的闡述與理解是否正確；
  4. 概念闡述是否正確反映產品設計意圖；
  5. 表達是否通順正確；
  6. 文檔組織結構是否合理;
  7. 文法是否遵循公司寫作規範；
  8. 從近「小白」的角度，考查易懂性、邏輯合理性、文字簡潔清晰性

角色側重點

  • 產品經理：2、3、4、5、6
  • 測試人員：1、2、3、5、6
  • 內審：5、6、7、8

Tip: 對於評審意見的採納，TW必須要有自己的堅持。比如，在寫作時，TW會把一個feature（功能）包裝成一個與用戶日常操作Task, 但測試的評審出發點是：功能；有時不能領會TW的苦心。這時，TW要與測試進行溝通，據理力爭，正確的立場就必須堅持。

文檔評審流程

我的經驗：Waterfall與Agile流程下評審流程有所不同。

對於操作手冊，（此處放流程圖為佳）Agile開發模式下：

  1. 一個iteration結束(也即下一個iteration開始），開始該iteration文檔開發；
  2. 當下一個iteration結束時，完成上一個iteration內容開發。將文檔發給QA(測試）與給產品經理(PM)測試評審。然後，TW根據意見修訂文檔。如此往複至所有iteration結束。
  3. 文檔整體定稿，發給QA與PM全文複審。之後，TW根據複審意見修訂文檔。
  4. 定稿後，內審開始，發editor與內部peer reviewer審稿。同時，發SME審閱。

Waterfall流程下，通常集成測試結束後，開始操作文檔的外部評審。

推薦閱讀：

TAG:文檔 | 測試 |