研發流程職責要求
- 2021 年 10 月 28 日
- 筆記
產品
產品內部需要先進行需求評審，確定需求後，才能跟技術進行需求宣講；
需求宣講前，至少提前1天把需要宣講的需求發出來，通知測試和開發宣講時間和地點；
需求宣講後，測試和開發有疑問，產品需進行Q&A，維護到對應需求文檔上，並及時更新需求；
需求宣講完成，原則上不允許進行需求變動；如果進行需求變動，需要在協作平台提需求變更，開發和測試重新評估時間；
產品新增/變更需求，需要進行三方周知，不能只單方通知到測試或單方只通知開發；
產品規劃需求前，涉及多方業務時，需要跟多方業務部門溝通清楚，避免出現上線後臨時又要優化需求的現象；
開發
開發在需求宣講後，需要理解並拆分需求，及時跟產品溝通並督促 產品更新需求；
開發前期需求需要完全了解，非自己開發部分也需要大概了解；
開發完成後需要重新核對一遍需求，有些需求變更才不會漏掉；
開發需要測試部署時，要提供完整的部署信息（包括：環境、服務、分支）和部署說明（本次部署的目的）；
開發在設計評審階段，可以讓測試一起參加了解；
開發不允許私自修改或優化代碼但沒有告知測試，很容易導致測試漏測；
開發bug原則上需要日清，緊急和嚴重問題非特殊情況必須日清；
開發提測前，需要將全流程都跑通（執行冒煙測試用例）才能提交測試，不能只是每個開發模塊開發完成，獨自模塊自測完成後就算提測；
涉及到迭代開發的所有人員都需要清楚每個迭代的節點時間（提測時間、預生產時間、上線時間）；
開發身上的bug，如果需要流轉到其他開發，需要備註下一個開發需要幫忙做的事情，然後私下再通知對應開發幫忙排查問題；
開發解決bug後，需要備註出現問題的原因和影響範圍，方便測試回歸驗證；
開發提測，需要有提測說明和影響範圍說明（開發全功能提測後，發現有不影響主流程的問題，正在修復，也可以寫到提測說明中）；
開發不能私下接需求，產品新增或修改需求，需要測試也評估後才能決定是否新增/修改；
開發提測後，可以多對自己的代碼和本次迭代流程進行測試，在測試發現問題前先消滅掉（建議）；
最好是能前緊後松，不要所有東西都堆積到後面來處理，導致後面發佈風險；
開發過程中碰到有2個小時內自己都解決不了的問題，要向上尋求幫助，不要耗上一天或者半天的時間；
群里或者私聊的時候，有看到消息開始處理了要通知一聲讓對方了解情況，所有消息都最好能稍微回復/反饋；
測試提測問題單，如有描述多個問題場景，要所有場景都處理才算修復，修改好的問題自己要先核對正確了再提測，不要反覆浪費時間；
上預生產，上生產，負責人要提前做好腳本和配置的工作，同時要核對下預生產和生產是否跟測試環境有差別，提前規避因為此類問題導致上預生產/生產的時候才發現問題，耗費時間；
問題修復及時更新狀態給測試，所有問題到測試手中都必須是已解決的，同時要區分延期，不處理，已處理。已處理代表是有修改內容，不處理和延期必須要跟測試和產品溝通確定ok才能改成這類狀態，非缺陷的請備註好原因通知測試重新驗證；
多版本同時在測試環境的時候，要注意不要版本之間混雜在一起；
多個需求在同個版本上線，各負責人合併代碼，上線等各個節點需要互相通知，保證最後合併後的分支包含各部分內容，同時同一個版本打tag前最好使用相同分支號，這樣打包部署才不會混亂；
開發提交上線單子（線上變更）標題規範：標題：【上線任務】系統+版本+上線內容+上線時間
如：【上線任務】財務中台-結算中心V1.6.1 大興機場資金結算 上線 2019-11-01 22:30
測試
需求分析
.拆分需求，需要確認的問題，整理成文檔發給產品確認，並督促產品維護Q&A到對應需求文檔上，及時更新需求文檔；
測試用例編寫
.編寫測試用例時，要100%覆蓋到產品需求，覆蓋完整後再補充場景、邊界、異常等測試用例；
.編寫測試用例，標註測試用例級別，1級用例為開發提測前必須自測通過的主流程case，提測後測試以此進行冒煙測試；
.測試用例編寫完成後，至少要在測試用例評審的前1天把發出用例發到群里@開發負責人、測試負責人、對應開發和對應產品，通知大家用例評審的時間和地點；
.需求宣講完成後，所有的需求變動和新增，都需要開發和測試一起評估，同意變更後，需讓產品補充需求文檔和提需求變更單子，不接受口頭需求變更，不接受單方面需求變更
測試前
.提測前1天跟開發確認提測情況，確保提測日期當天可以順利提測；
.提測後優先進行冒煙測試，冒煙測試結果發群里@開發負責人、測試負責人、對應開發和對應產品（PMO）；
.冒煙測試不通過，不算提測；冒煙測試通過，提測成功，測試進入測試階段；
.冒煙測試模板規範：
冒煙測試模板
【系統+版本號】
【冒煙測試結果】冒煙通過/冒煙不通過
冒煙項1：冒煙結果（通過/不通過）
冒煙項2：冒煙結果（通過/不通過）
冒煙項3：冒煙結果（通過/不通過）
……
艾特開發、測試、產品負責人
（冒煙測試不通過的，需要寫明不通過的原因/存在的bug）
測試中
.測試中，遇到阻塞問題，及時群里@對應開發和開發負責人，督促問題及時解決，不要私聊；
.測試中發現開發私自修改代碼沒有同步測試，群里周知，督促開發規範性；
.開發解決bug，要求開發需要備註修復原因和影響範圍，方便測試驗證回歸；
.開發需要把bug解決後測試才能驗證關閉，測試不能自己修改bug狀態進行關閉操作；
.測試中提的bug，原則上需要日清，緊急和嚴重問題非特殊情況必須要求開發日清，測試及時驗證開發日清的bug
.測試環境測試完成，計划上預生產，提前在群里@開發和開發負責人，安排準備上預生產的腳本和配置，不要私聊；
.預生產流程走通後@產品同步驗收；
.預生產測試完成前，提前群里@開發和開發負責人打tag；
.tag驗證沒問題，上線當天群里@開發、開發負責人和產品 ，上線通知；
.及時更新協作平台上測試任務狀態；
.多項目或多人配合時，環境部署（開始部署和部署完成）需要再群里通知；
.遇到任何不清楚，不明確，有疑問的都需要在群里跟產品/開發確認，涉及修改需求時督促產品更新需求；
.測試中發現的問題，都要提交協作平台記錄，不能只是口頭傳達；
.測試不能100%確定要延期的問題都需要跟產品確認，原則上需要延期的問題都要跟產品溝通；
測試完成
.上線完成，@產品已經上線完成；
.jira上線單子，上線完成後，需要@2個群組（@tech_pm和@tech_leader），備註測試情況，並把jira單子指派給對應開發；
.協作平台上線單子，上線完成後，備註測試情況，關閉上線任務；
線上操作
.上線後，本次上線的內容能驗證的都需要驗證，不能驗證的群里通知產品，產品第二天需要配合業務部門進行相應功能驗證；
上線後第二天跟蹤
.上線後，第二需要關注並響應群里的消息和問題；
.上線較晚，第二天在家支持，也需要關注並響應群里的消息和問題；
