測試人員如何做好有效的pdca

入職以來做的測試執行較多（這裡主要是從角色上和項目管理分開，包含測試設計測試分析），現在就談談作為一個測試執行人員對如何做好pdca的看法。

我們的團隊，軟體測試的終極目标是“快速釋出高品質的版本”，那我就從進度和效率方面談談如何做好pdca。

效率：假如你拿到一份任務是滿足smart原則，那麼做好pdca的關鍵就是讓項目經理及時了解你的進度，避免進度方面出現風險。做法：a.每天評估自己的工作進度，并知會項目經理(方式可通過日報或者更新projectserver等) b.當負責的任務進度有風險時要及時提出。必須要保證及時！舉一個例子，假如你拿到一份任務，需要3天完成，1天下來你才完成了5%~10%，進度其實已經有很大的風險了，這時候就要提出來，不能到2天後發現自己才完成40%無非完成任務才提出，這時候就晚了，PM一般允許工作有風險，但是必須讓PM及時的了解風險便于做出相應的對策。

品質：品質和進度其實是相輔相成的，如果一味地趕進度，品質不能保證，後續項目出現返工，項目周期還是會被拉長的。我們負責一個子產品的測試，就要保證品質，但是PM審計和外部PMO審計還是會有問題，為什麼？主要有2方面：a.我們的例行工作沒有做到位 2.我們的風險識别，閉環意識不好。

例行工作：這主要是流程方面的一些工作，如failed案例标注bug id，bug屬性标注正确，bug 回歸通過後要passed相應案例等，這些工作是無需項目經理再去提醒的，我們完全可以自己制定一份例行工作checklist，經常去關注并确認。這裡也有一個技巧，PM和PMO經常做的檢視工作也可以加到我們自己的checklist中，如bug稽核，缺陷預防庫檢視等。

風險識别，閉環：閉環是因為目前發現了問題，是以要針對目前的風險做閉環處理。。舉一個例子，我們發現了一個回歸不充分導緻的bug，原因是bug沒有稽核。那麼我們要分析是否還有其他bug存在此問題，這時候我們可以先自檢下是否存在類似的共性問題 并知會項目經理對bug做2次稽核。我在某個版本發現了測試政策漏測（測試政策是讓開發保證品質）的bug，那這種問題的原因是測試政策問題，那麼要分析是否有其他子產品是否采用類似的測試政策。簡而言之，就是點到面的分析。點到面的分析可以采用如下政策：

分析出問題的點（确認出問題的對象，如某個案例，bug，測試政策，測試方法等）--->确認點的最終原因（如案例沒有做checklist自檢，bug沒有稽核等）--->确認是否是共性問題--->分析other類似對象是否存在此問題--->落實。通過反複的點到面的分析，确認風險最終落地。

上面說的是確定自己發現的問題的最終閉環，但是很可能可能會存在其他自己不能識别的風險，那該如何辦？

我的想法是，我們最終負責的東西需要經過PM和PMO的稽核，那我們可以采用利用他們的經驗幫助我們。如現在PMO用的項目缺陷預防檢視庫，我們可以在確定負責的子產品點到面分析自檢完成後，利用缺陷預防檢視庫 檢視自己的子產品是否存在風險庫的問題。這個也是工作的1個基本的思想，因為PM和PMO是我們負責子產品品質的幹系人，我們負責的東西肯定需要滿足幹系人的标準。

綜合上面分析，做好pdca需要做好基本例行工作，問題的點到面分析，借助幹系人的經驗等。做好pdca既保證了自己負責工作到位，也實作了測試人員的自由（否則項目經理經常會找你，工作會返工的 呵呵）

附錄上我發現的pdca的不好的情況及自己的改進建議。

1.例行工作不到位：産出自己的例行工作checklist

2.工作标準不明确：有時候PM安排一份任務沒有明确标準，有時候會發生PM向你要某份分析文檔你卻沒有。建議PM和項目成員對每一份任務要明确相應的産出标準，尤其是對新員工（剛入職或者剛接觸某個新工作的員工，即便是老員工）。

3.文檔思路不到位：這個其實和第2點一樣，不過這個很常見且很重要（我自己身上也發生過）。其實負責的子產品品質分析一般包含你的測試政策 已測試點 測試結論，pdca無非是確定目前的風險被消除，是以你的資料已經要支援風險消除的結論。分析文檔最好按照測試政策（測試分析），已測試點，點到面分析，測試結論思路來寫。

4.pdca過度：有時候PM可能分析某個問題有點過度，本來可能是個性問題但是分析成了共性問題，其實這往往是問題的根本原因沒有分析到位。這時候如果你想懶一點（不想測試太多内容），就要給出有力的資料支援說明這個隻是個性問題。

5.不能盡早識别風險：這個取決于部分的經驗，但是風險意識必須有。不過可以學習下風險庫，學習下其他項目遇到的問題等