項目實戰：敏捷測試特性文檔交付難/拖延沒空寫，如何解決？

背景介紹

產品文檔作為產品交付的配套，承擔著產品交付后的部署、開通應用操作指導的作用。

編寫的文檔質量好壞，直接影響產品交付開通應用的整體用戶體驗、產品口碑。

結合當前項目的研發過程中，對文檔交付的質量、交付的時效性以及交付流程實踐進行一下分享探討。

按照整個產品研發過程中涉及到交付文檔類別、交付階段、文檔作用以及交付周期大致劃分如下：

由于當前工作涉及內容主要在敏捷測試階段，針對敏捷測試階段涉及的特性指導書類文檔交付過程實踐進行分享探討。

問題分析

對于敏捷測試特性文檔交付，從一開始被文檔交付的困擾，到改進實踐并形成一定的固化流程，跌跌撞撞中一路調整走上了正軌，實踐過程分別從組織、流程兩個方面來完善調整。

特性文檔交付痛點：

文檔交付難/拖延

沒空寫：特性的交付都有明確的迭代周期，按照項目敏捷交付的流程，特性所配套的文檔是特性交付中的一部分，是特性完成交付中檢查標準中的一項，特性會按交付周期來完成，但受迭代交付壓力，隨之一起交付的特性文檔永遠是優先級最低的任務，沒空寫。

沒人寫：對于文檔，也沒人愿意寫，認為只要編好代碼，做好測試就行；對于交付給用戶指導特性開通的文檔，工程師站在實現的角度來編寫，工程師思維和用戶使用的貼合度不高，用戶文檔也不會寫。

特性文檔質量不佳

看不懂：編寫的特性文檔大多是拷貝的特性方案中的內容，系統具體的內部實現，對于使用用戶對系統沒有深入的知識背景，看此類拷貝方案內容的文檔，就不知所云。

有錯誤：特性文檔編寫優先級低，沒人寫、沒人控，導致文檔錯誤，質量不佳。

無價值：對于用戶來說，文檔無法指導用戶對特性的開通使用；沒有價值。

文檔交付拖延、質量不佳，直接導致了產品在外場上線后，無法指導實際的開通應用，需要后方研發工程師人力支持，耗時耗力，用戶對產品體驗下降。

存在、發現了問題是變革的動力，于是項目通過一定的管理手段、技術手段在特性文檔交付上做了優化改進，在敏捷測試交付過程中完善特性文檔的交付。

實踐過程

組織上

為保障文檔交付的時效性和質量，項目的各組織：

多崗位協同編寫

全程進度控制

隨迭代同步交付

在時效性方面：需求階段識別>特性開發階段編寫。由對應測試專家進行編寫計劃的跟蹤，并且特性文檔交付加入驗收高壓線，隨特性一起交付，在驗收時未完成交付，則特性提交不通過。

在質量方面：由熟悉特性應用市場的SE、特性實現的SE、特性測試的QA共同編寫完成。由驗收專家TS進行文檔審核，由系統測試TE進行文檔測試驗證。通過相關人員協同組織來保障文檔質量。

流程上

特性文檔的交付嵌入到研發流程中：

在需求分析階段識別是否編寫，提前識別為下一流程環節中預留編寫時間；

在特性開發階段進行編寫、評審、跟蹤，在開發過程環節中控制編寫質量；

在系統測試階段驗證發布，通過最后的系統測試來為文檔交付質量再次守護。

各階段流程中對應的要求、相關輸出、以及參與人員如下：從整個流程上來控制特性指導文檔的輸出質量、輸出時效。

實踐總結

為解決特導文檔交付的時效性、保證文檔內容質量，項目做到了以下幾個方面。

協同交付

組織上創建團隊協作氛圍，市場規劃、特性開發、特性驗收、系統測試共同合作，互幫互助，讓輸出的文檔從工程師思維向用戶思維轉變，交付高質量文檔。

流程保證

特性開通指導文檔嵌入研發流程，提前識別、預留編寫時間、跟蹤編寫計劃、納入驗收DOD通過流程來保證文檔提交的時效性。

需求階段識別，特性階段編寫、評審、修訂，驗收階段審核，系統測試階段測試驗證，研發各流程環節共同協作保障文檔交付。

最后：在我的V ：atstudy-js，可以免費領取一份10G軟件測試工程師面試寶典文檔資料。以及相對應的視頻學習教程免費分享！其中包括了有基礎知識、Linux必備、Shell、互聯網程序原理、Mysql數據庫、抓包工具專題、接口測試工具、測試進階-Python編程、Web自動化測試、APP自動化測試、接口自動化測試、測試高級持續集成、測試架構開發測試框架、性能測試、安全測試等。