一枚測試人員的苦惱：

    在剛進入新的團隊，我有幸第一次與團隊成員參與了某個系統的測試，但是在產品提測的時候，我作為測試人員感覺有點頭疼不已，因為過程質量不容樂觀，整個過程中major的bug率佔比較高，經常在提測階段出現一輪所有用例沒有測完就直接被Block的情況；其次，不斷的迴歸以及程式碼的變動，讓我們感覺有些力不從心，從時間上來說，哪怕進行了2*12天/人的測試迴歸，直至上線，仍然有很多無法把控的風險因素；

                  圖1：該系統測試報告

  一個契機：

從測試來說，我能看到的是專案已經表現出來的結果，1.專案時間上的延誤 2.過程質量的不容樂觀；

但是縱觀整個整個產品開發過程，產生這些原因的根本可能是因為前期在協作以及方法上沒有達成的一致：

1.  溝通的問題

1） 開站會的時候沒有提出一些風險，站會草草了過，然後等專案提測時候延期提測，每次都不能按時間按要求給出一個較高的提測版本；

2） 等提測的時候，發現有些需求已經變更過，但是並沒有通知到全體參與人員；

3） 多人開發的版本控制教亂，經常出現程式碼回滾合併不一致的問題；

4） 系統版本很多，多個版本開發以及測試人員的協調時間存在問題，曾出現過版本要上線了才發現延後了一個星期；

2.  需求變更頻繁

1）需求把控一直是個比較頭疼的問題，每次等提測的時候仍然有需求插入，沒有進行需求把控；

2）針對變更需求沒有詳細記錄，每次到測試階段測得比較粗糙，到最後發現需求有些坑；

3.  歷史遺留問題

1） 團隊的快速擴大，由單作坊形式變成一個合作模式沒有達成一套自己的管理模式；

2） 之前線上問題較多，每個版本在時間安排上都會被擠掉一些時間去處理線上bug；

3） 針對現有線上系統，團隊整體的質量信心不高；

辣麼多的問題，如果此時能夠從源頭去做一些多多少少的改變，或許對整個專案的質量有一些推進作用，對團隊成員都是有個積極的正面效果。

有些事情需要專案管理去推進，然而當時我們專案組並沒有專案管理；

But，我沒有做過專案管理，又該怎麼推進呢？

此時，我在每次測試報告中，都會提一些想法，然後跟我的leader反饋下處理方式，嗯，那就試試吧！

  一些嘗試：

我所理解的專案管理是需要對專案的成本，時間以及風險的把控，利用敏捷的思維，儘可能早的把問題發現使團隊成員按照預定的時間和軌道到達目的地；

鑑於目前專案中存在的那些問題，我們斷斷續續做了如下的改進：

1.  重新理解站會的側重點以及意義

之前站會存在2個問題：

1） 沒有有效及時的丟擲問題（比如延時提測，或者在開發過程中沒有及時丟擲需要協作的內容）；

2） 時間把控，有些時候會就一個問題在站會上浪費較長時間；

我覺得站會的意義是各自明確對自己計劃的承諾，所以我們進行了一些改變和重申：

1） 明確自己所做任務的時間節點以及風險，有問題及時丟擲；每一天針對前一天的問題先進行回顧檢視前一天問題進度，再開始今天的站會；

2） 有效把控站會時間，明確站會框架，避免時間浪費（昨天做了什麼，今天計劃做什麼，以及時間節點和風險）；

3） 針對需要協調的站會內容，當時沒有用看板，而是用郵件記錄的方式，將時間節點和每日碰到的問題和需要協調的事情記錄；

圖2：站會模式的探索

2.  需求的管理以及線上問題的處理模式探索-- Jira看板的推動

Jira看板主要是為了解決當時的幾個問題：

1） 如何處理線上問題；

2） 針對需求變更，如何能夠進行跟蹤與需求描述；

3） 如何來管理一些零散需求，方便進行放入迭代管理；

4） 如何更有效直觀的檢視專案情況（包括任務，bug，進度等）；

於是組織開了個會，商議嘗試著用jira創立需求池與線上bug的版本，進行跟蹤，這樣可以方便我們對線上問題的統計以及需求的管理，同時也方便進行專案過程質量的統計，當然前提可能需要改變大家以往的工作工具，例如excel等，進行工具的統一：

                       圖3：看板的制定

3.  需求變更流程控制

需求變更控制是需要讓全體成員瞭解在提測過後變更的一些風險，以及我們為啥要控制變更的原因，制定出一些公共策略全員一起討論，達成共識。

1.  首選我們在流程上每次的測試報告都會提出變更的風險，所以在後續的迭代過程中大家針對需求類的問題達到了共識；

2.  其次我們嘗試採用D-box的軟體，需求變更的時候及時的通知；

          圖4：需求類問題的流程推進    

4.  如何推動開發的版本控制

因為人員的不斷擴張，在多人開發專案的過程中經常會出現程式碼回滾上傳的時候一些程式碼遺漏，每次測著測著發現之前的bug又Reopen了，導致測試這邊需要測很多輪，並且無法控制程式碼版本質量；

針對測試過程發現的問題，需要積極的和開發負責人溝通，有效的進行程式碼的管理，形成一致的程式碼管理方式，避免將版本控制的問題出到線上，同時也減輕了測試的迴歸量：

          圖5：制定多人合作的程式碼管理策略探索

5.  覆盤會的框架選擇

我們組內組織過幾次覆盤會，但是有些效果比較好，有些開的效果比較差，總結下來，我覺得覆盤會需要注意以下幾點:

1.  明確開會框架

會前發郵件明確開會內容和開會框架，最常用的框架是每個人能夠用小紙條寫出：

Good，NeedImproved以及Try進行闡述，讓每個人有參與感；

其次在把控主框架的前提下控制開會時間，不要東跑西跑的繞開了主題，影響了大家的時間；

2.  抓住需要Try的重點

每次需要改善的東西很多，但是每次都不能什麼都抓，所以需要主持會議的人根據每個成員所提的幾個Top痛點進行篩選，制定改進措施，達成共識；

最後以郵件發出，定時回顧。

一點點總結：

第一次嘗試一些專案管理的工作，在專案中作為一個雙角色之間的轉換，我深刻的體會到了全域性意識和溝通的重要性；

作為測試人員，需要有全域性意識，能夠憑藉職業嗅覺很快的從專案中發現專案過程的一些問題，並且能夠最終的對釋出版本的質量和存在的風險有著比較清晰的瞭解。

但是如果僅僅以一個測試人員強硬的角色去暴露出產品以及團隊的問題，可能會和開發人員以及產品產生一些衝突，影響團隊的和睦；

專案管理的角色恰好能夠推動測試人員所發現問題的解決，但是在推動過程中需要有較強的溝通和協調能力，這些都是需要鍛鍊的。

過程質量的把控需要方方面面人員的協調與參與，共勉！