本文章轉(zhuǎn)載于搜狗測試
需求變更處理遇到的坑
需求變更是項目迭代中常見的環(huán)節(jié)交洗，從項目的角度考慮送粱，有些需變會對項目帶來很大的收益栓袖。小編所在的項目中，也會遇到需求變更的情況亏吝，結(jié)合之前的經(jīng)驗岭埠，小編整理了如下需變處理不到位而遇到的坑，請大家繞坑而行蔚鸥。
問題一：二輪測試中惜论，小A負責的模塊需求變更，需變發(fā)出后止喷，未經(jīng)三方確認評估馆类。小A介入測試時，發(fā)現(xiàn)改動范圍較大弹谁，之前測試的功能需要重新回歸乾巧，對于二輪階段來說句喜，項目迭代速度及質(zhì)量均存在風險。問題三方確認后沟于，發(fā)現(xiàn)此需求變更的優(yōu)先級不高咳胃，鑒于后期版本迭代的控制，代碼進行了回滾社裆。
總結(jié)：對于需求變更拙绊，需三方確認溝通向图，對于需變的合理性泳秀、需變效果要求、需變帶來的代碼改動成本榄攀、測試回歸成本等均需進行評估確認嗜傅，結(jié)合三方的意見，最終決定是否進行需求變更檩赢。
問題二：小A在主線版本測試過程中吕嘀，負責某個模塊的需變，需求變更經(jīng)過了三方統(tǒng)一的評估且達成一致贞瞒，因優(yōu)先級不高偶房，未能及時的更新至排期，導致需變的任務遺漏军浆。
總結(jié)：需變往往是模塊功能的優(yōu)化補充棕洋，測試人員在高優(yōu)先級忙于其他任務的測試，很容易將需求變更的任務遺漏乒融。需求變更確認后掰盘，需及時的更新至排期中，避免遺漏赞季。
問題三：二輪測試中愧捕，小A負責某個模塊的需變，因需變業(yè)務邏輯相對簡單申钩，小A直接進行的測試次绘，而未進行用例設(shè)計的編寫和評審，導致場景考慮不全而出現(xiàn)線上Bug撒遣。
總結(jié)：遇到需求變更后邮偎，尤其是二輪期間，測試人員經(jīng)常會遺漏用例設(shè)計及評審環(huán)節(jié)愉舔，導致未嚴格按照測試流程執(zhí)行钢猛，對于版本的質(zhì)量存在風險。所以轩缤，針對需求變更命迈，不論測試在什么階段贩绕，均需要嚴格按照流程規(guī)范執(zhí)行。
需求變更的規(guī)范模板
針對如上遇到的坑壶愤，小編為大家提供了如下需求變更的模板淑倾，產(chǎn)品/開發(fā)在需求變更時，可參考如下模板發(fā)送郵件征椒，減少溝通的成本及潛在的質(zhì)量風險娇哆。
需求變增
項目版本Android_V5.7.0版本
功能名稱推送通知
變更類型□新增??■變更???□內(nèi)部改進????□產(chǎn)品缺陷????□其他
需求優(yōu)先級□高（基本的）■中（條件的）□低（可選的）
效果要求□強（完美實現(xiàn)）??■中（實現(xiàn)即可）??□弱（可容忍缺陷）
變更內(nèi)容xxxxx
變更原因xxxxx
連帶影響模塊通知
變更風險xxxxx
產(chǎn)品文檔（說明：可為相應的SVN鏈接或郵件附件）
提出日期4/10/2017
Deadline4/21/2017
變更審批人項目經(jīng)理、產(chǎn)品負責人
變更執(zhí)行人產(chǎn)品勃救、開發(fā)碍讨、測試
是否需要重新測試是/否
申請人員xxx
需求變更的處理流程
需求變更在流程上，需三方確認蒙秒，三方達成一致后勃黍，測試人員對于需求變更的處理需嚴格按照測試流程規(guī)范走，避免質(zhì)量上的風險晕讲。具體流程規(guī)范可參考如下：
需求變更的總結(jié)思考
需求變更是不可避免且有意義的覆获，但是針對頻繁的需求變更，會增加開發(fā)瓢省、測試的成本弄息，測試人員持續(xù)的總結(jié)思考，做到提前的預知和規(guī)避勤婚。
1.針對需求變更摹量，需要評估需求變更的合理性，并總結(jié)是否提前可預知蛔六。最好能夠把需求變更的時間提前至需求討論會階段荆永，避免對項目后期造成的壓力。
2.針對已發(fā)生的需求變更国章，需要記錄具钥，上線后與產(chǎn)品一起分析總結(jié)，持續(xù)優(yōu)化可提前預知的需求變更液兽。
