需求轉化到文檔維護

  進入新單位很快3個月了，熟悉了新的流程後，總結一下需求轉化的感覺：

最早獲得的需求參考有：產品說明書，交互和視覺稿，這個和其餘公司基本一致，差異無非就是文檔格式和語言表達。這個階段咱們要作的是：

  1. 三者對照一塊兒通覽幾遍。個人習慣是打印出來，以便記錄疑問，第二遍看的過程當中試着本身去解答上一遍的疑問

  2. 幾遍均看完後，整理Q&Alist，個人建議是表格形式，列標題包含：序號，模塊名稱，功能點，原文，提問內容/或理解待肯定內容，提問人，提問日期，問題狀態（New，closed，Renew）,答覆內容，答覆人，答覆日期，備註

  3. 主動推動Q&Alist問題的解答和跟進，你能夠求助的人有產品經理，交互設計師，開發項目經理，團隊領導等，切記問題的發出和返回必定要使用郵件，若是是口頭確認要當即郵件記錄準時發送，維護信息和版本內容

  4. 當有問題返回時，肯定理解後，能夠關閉此問題；若是不理解還需澄清，就改成Renew，繼續細化問題，等待回覆。溝通渠道要採用多樣的，不能死等，不然咱們的郵件或問題將石沉大海。

  5. 開始使用導圖工具，一級枝爲模塊名，二級葉爲一級功能點，之後各級需考慮場景或影響因素，不斷細化子葉，其中會讓咱們發現更多問題，繼續整理Q&A

  6. 導圖成型後，可稱爲工做量預估的基礎，測試計劃能夠預估。。通常一個成熟的員工一天能寫50條case，執行40-60條Case，執行量要看case的複雜度，好比這裏不少工做的關鍵路徑是數據的mock，環境的穩定性；計劃要考慮測試策略，好比啓動幾輪，每輪迴歸的比例和環境等

  7. 根據導圖整理成測試分析的功能點表格

  8. 功能點表格可有效的轉化爲測試用例和後期的需求跟蹤矩陣，同時在測分評審時簡單明瞭

  9. 評審會議前，必定將測分文檔準備充分，有疑問或須要明確的內容能夠標黃，會議上一併解決，比較高效。會議記錄要記錄清楚。

  10. 根據測分修改稿進行用例設計

  11. 需求跟蹤矩陣能夠直接使用功能表格，記錄需求從凍結後的一塊兒變化，如新增，修改，日期，影響工做量等

寫的比較糙，更多的感覺慢慢記錄吧，如今天天工做13小時，已經連續2.5個月了，期間休息6天，高強度呀，成長也是很快的，加油！