分散式團隊中溝通引發的問題, 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 下如可組織和管控測試等，