中興通訊測試專案實踐:敏捷測試特性文件的交付過程實踐探討

博為峰網校發表於2022-09-16

背景介紹

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

編寫的文件質量好壞,直接影響產品交付開通應用的整體使用者體驗、產品口碑。

結合當前專案的研發過程中,對文件交付的質量、交付的時效性以及交付流程實踐進行一下分享探討。 加我VX:atstudy-js 回覆“測試”,進入 自動化測試學習交流群~~

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

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

問題分析

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

特性文件交付痛點:

文件交付難/拖延

沒空寫:特性的交付都有明確的迭代週期,按照專案敏捷交付的流程,特性所配套的文件是特交付中的一部分,是特性完成交付中檢查標準中的一項,特性會按交付週期來完成,但受迭代交付壓力,隨之一起交付的特性文件永遠是優先順序最低的任務,沒空寫。

沒人寫:對於文件,也沒人願意寫,認為只要編好程式碼,做好測試就行;對於交付給使用者指導特性開通的文件,工程師站在實現的角度來編寫,工程師思維和使用者使用的貼合度不高,使用者文件也不會寫。

特性文件質量不佳

看不懂:編寫的特性文件大多是複製的特性方案中的內容,系統具體的內部實現,對於使用使用者對系統沒有深入的知識背景,看此類複製方案內容的文件,就不知所云。

有錯誤:特性文件編寫優先順序低,沒人寫、沒人控,導致文件錯誤,質量不佳。

無價值:對於使用者來說,文件無法指導使用者對特性的開通使用;沒有價值。

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

存在、發現了問題是變革的動力,於是專案透過一定的管理手段、 手段在特性文件交付上做了最佳化改進,在敏捷測試交付過程中完善特性文件的交付。

實踐過程

組織上

為保障文件交付的時效性和質量,專案的各組織:

多崗位協同編寫

全程進度控制

隨迭代同步交付

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

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

流程上

特性文件的交付嵌入到研發流程中:

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

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

在系統測試階段驗證釋出,透過最後的系統測試來為文件交付質量再次守護。

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

實踐總結

為解決特導文件交付的時效性、保證文件內容質量,專案做到了以下幾個方面。

協同交付

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

流程保證

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

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

最後:

可以到我的個人V:atstudy-js,可以免費領取一份10G軟體測試工程師面試寶典文件資料。以及相對應的影片學習教程免費分享!其中包括了有基礎知識、Linux必備、Mysql資料庫、抓包工具、介面測試工具、測試進階-Python程式設計、Web自動化測試、APP自動化測試、介面自動化測試、測試高階持續整合、測試架構開發測試框架、效能測試等。

這些測試資料,對於做【軟體測試】的朋友來說應該是最全面最完整的備戰倉庫,這個倉庫也陪伴我走過了最艱難的路程,希望也能幫助到你!

來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/31407649/viewspace-2915035/,如需轉載,請註明出處,否則將追究法律責任。

相關文章