+二次開發(fā)業(yè)務(wù)+外包開發(fā)業(yè)務(wù)
3. 日后所有的開發(fā)內(nèi)容(技術(shù)平臺補丁、標準產(chǎn)品補丁、外包開發(fā)團隊的功能內(nèi)容)必須以標準補丁的形式更新測試環(huán)境，進行測試。不允許在測試服務(wù)器上進行手工操作，包括腳本的執(zhí)行。
4. 原則上每日更新補丁測試，開發(fā)人員對于bug的修改每日構(gòu)建，第二天更新補丁進行測試。如有緊急需求，張小靜可以增加補丁更新的頻度，但不允許替換jar的形式更新。
5. 測試環(huán)境保持唯一性和準確性，所有的內(nèi)容都以補丁形式進行驗證
6. 每條項目任務(wù)的通過以項目管理工具中項目任務(wù)通過為標準，項目進度以及項目質(zhì)量全部以項目管理工具數(shù)據(jù)為準。在開發(fā)機上測試結(jié)果不能作為任務(wù)通過標準。
質(zhì)量保障缺陷處理機制：
1. 測試中發(fā)現(xiàn)的所有問題都必須以bug的形式在項目管理工具中更新，無論是環(huán)境問題、標準產(chǎn)品問題、技術(shù)平臺問題、二次開發(fā)內(nèi)容還是外包開發(fā)內(nèi)容
2. 所有的任務(wù)和缺陷修復(fù)開發(fā)人員必須做好單元測試，單元測試必須執(zhí)行測試用例的1級用例或執(zhí)行30%的核心用例，減少中斷等影響測試開展的重大錯誤。測試人員保障業(yè)務(wù)流程的有效測試。
3. 項目問題分析和處理機制：首先標準產(chǎn)品研發(fā)人員進行分析，標準產(chǎn)品確認無誤后，二次開發(fā)人員對二次開發(fā)內(nèi)容進行分析，確認無誤后外包團隊開展問題分析，只至分析出問題的所屬團隊，由對應(yīng)團隊成員第一時間處理。
4. 幾種BUG處理機制
1) 除重復(fù)bug外，其余bug一律不允許打回
2) 測試人員提交bug給開發(fā)人員A，如該bug不屬于開發(fā)人員A處理，不得打回，應(yīng)將bug轉(zhuǎn)交給對應(yīng)的開發(fā)人員，如不清楚該bug對應(yīng)的開發(fā)人員，將bug轉(zhuǎn)發(fā)給項目經(jīng)理，由項目經(jīng)理轉(zhuǎn)交給對應(yīng)的開發(fā)處理人。
3) 測試人員提交bug給外包團隊開發(fā)人員A，開發(fā)人員A發(fā)現(xiàn)該bug屬于技術(shù)平臺或標準產(chǎn)品或二次開發(fā)影響導致，不得將bug打回，將bug轉(zhuǎn)發(fā)給項目經(jīng)理，由項目經(jīng)理協(xié)調(diào)相關(guān)人員進行修改，待bug處理解決以后，標記已改提交給測試人員驗證
4) 測試人員提交bug給開發(fā)人員，開發(fā)人員發(fā)現(xiàn)該bug屬于測試環(huán)境問題，不得將bug打回，而是需要分析測試環(huán)境為什么會存在問題，并告知環(huán)境解決的方法，如果有問題，可以申請相關(guān)人員協(xié)助，如果無法發(fā)現(xiàn)問題，將bug提交給項目經(jīng)理，由協(xié)調(diào)資源處理，待問題解決，將bug標記已改提交測試驗證
5) 對于技術(shù)上存在難度或認為bug無需處理，可將bug標記暫不處理，且必須注明暫不處理的原因，并提交項目經(jīng)理。由項目經(jīng)理和我共同決策該bug是否可以不處理。原則上只有人機交互和產(chǎn)品建議可以不處理，其他bug不允許不處理。
6) 開發(fā)人員和測試人員遇到爭議問題要進行充分溝通，保證對于產(chǎn)品缺陷的一致性，提升bug修改的效率和質(zhì)量
7) 所有的bug逐條關(guān)聯(lián)項目任務(wù)，直接反應(yīng)項目任務(wù)的開發(fā)質(zhì)量
8) 對于bug，開發(fā)和測試人員必須及時處理，原則上提交的bug開發(fā)必須在3天內(nèi)處理完畢，重大中斷、數(shù)據(jù)等缺陷必須在1天內(nèi)處理完畢，測試人員必須在2天內(nèi)保證bug的驗證通過。
進度和質(zhì)量的衡量標準
1. 項目任務(wù)的完成進度以項目管理工具數(shù)據(jù)作為唯一標準，以項目任務(wù)的通過率作為項目任務(wù)進度數(shù)據(jù)
2. 功能質(zhì)量以項目管理工具完成情況為依據(jù)。測試通過的任務(wù)視為有質(zhì)量保證的任務(wù)，測試未通過的項目任務(wù)一律認為存在質(zhì)量問題，不納入進度數(shù)據(jù)。