分佈式團隊中溝通引起的問題, itest 解決之道

導讀：

從問題場景和 itest 優雅解決辦法及示例2部分來闡述

1.問題場景:

研發團隊是分散在幾地的分佈式團隊，常常會因溝通引來一些問題。以下三圖是開發以爲測試進度太慢，一番對話以後， 接下來他們的對話截屏：

 

 

 

   問題的本質其實是溝通的問題，多問幾句也能夠解決，可是經常是一人測試多個項目，開發也是一人蔘加多個項目，只要當前不閒着，加上又是分佈式團隊，可能有些須要溝通的事情，就先推後，不到最後要處理了纔來溝通，在itest 開源測試管理中，從機制上根本避免了這個問題。

2.itest 優雅解決辦法及示例:

      關於BUG指派不清的問題，ITEST 有兩個保障，一：能夠在測試流程中，由測試負責人（測試leader 之爲的的測試人員）設置BUG分配人，提交的BUG先到分配人那裏（分配人一般是某個項目的開發負責人），再由分配人（分配人能夠設置多個）來分配到具體開人員；二：可對測試需求模塊，設置開發人員，當提交的BUG時，指定了該模塊，就自動設置修改人爲以前設置的開發人員，若是是大團隊項目，可能一個模塊就量個子系統，還能夠對測試需求模塊設置分配人。

     ITEST中有上述兩個保障後，測試執行人員，根本不須要關心，這BUG提給誰，只負責執行就行。

 

  以下圖所示：

  設置測試流程並附流程設置說明：

 

  流程說明：

 

1 * 提交問題：必選流程，人員主要爲測試人員，不是提交問題這流程節點上的人員也可填報BUG，只是不能確認BUG是否己修復。

2測試互驗:可選流程，當測試人員和開發人員不在同一地點辦公時，或想測試把關新手提交的BUG時，開啓該流程，由資深測試人員來作測試互驗，既能夠指導新人編寫高質量的BUG，也能夠在開發人員在處理BUG前，測試人員內部先檢查新提交的BUG，省去了可能的因BUG描述理解差別上，或是BUG可復現上帶來的和研發人員的溝通成本。

3分析問題:可選流程，分析BUG產生的緣由，估算修復BUG須要的時間及期限，通常爲研發經理，系統分析師來作分析工做。

4分配問題:可選流程，單元測試時，或團隊規模比較小且測試人清晰的知道開發人員所負責的模塊時，能夠不啓用該流程，測試人員提交的BUG，直接分配給開發人員。通常分配人應該爲研發經理，研發組長等，能夠有多個分配人。

5 * 修改問題:必選流程，顧名思義是修復BUG的環節，設置的人員是研發人員。

6開發互檢:顧名思義是開發人員修改完BUG後，他們間的交叉檢查。設置的人員是研發人員。

7 * 分歧仲裁：必選流程,當測試人員和研發人員對某個BUG的達不成共識時，或研發人員要求BUG延期修改，或不計劃修復某個BUG時，由仲裁員來裁決。通常仲裁員爲研發經理，或產品經理。

8 項目關注: 可選流程，設置項目關注人員，這些人員，在項目中不作具體的工做，設置爲關注人後，這些人員能夠在「切換測試項目中」 切換到所關注的項目

 

 

測試需求項（測試需求模塊）人員分配：

 

 

itest 是一款: 匯聚10年沉澱，由對軟件測試有情懷，熱衷於開源，又熱心傳播分享的一羣測試人共同打造，最懂測試人的開源測試管理新秀。

。也可在線體驗，也有一鍵安裝包，  https://itest.work/rsf/site/itest/product/index.html

後續咱們會陸續，把ITEST下面幾個方面分享出來，歡迎拍磚：流程驅動測試，度量體現測試人價值，測試負責人每日覆盤，敏捷測試，迭代測試，devops 下如可組織和管控測試等，