不論測試部門還是兄弟部門，規(guī)模擴展都非常迅速，以前做不同的項目開發(fā)測試人員就這么幾個，現(xiàn)在可不同了，一個項目中，前期與后期的人員都存在變化的可能。
正因為“人”這個重要因素，我們可以看到，項目與項目的過程之間，有著非常大的不可控性。盡管最后有使命感的驅(qū)使完成了項目發(fā)布，但我們的感受與成長卻千差萬別。
無論是業(yè)務(wù)型項目還是改進型項目，測一個項目最大的風(fēng)險可能就是需求的不確定性，當(dāng)然項目的風(fēng)險又豈只這一點，或許我們都經(jīng)歷過這樣的問題：
1.在準(zhǔn)備測試用例編寫時，才分配進入項目
2.介入的項目涉及一個未接觸的業(yè)務(wù)領(lǐng)域
3.項目的需求朝令夕改，跟不上變化
4.需求不了解，測試不深入，不敢承諾質(zhì)量
5.項目測試時間來不及了，把不熟悉業(yè)務(wù)的人調(diào)來測試 等等為此，我們有很多方法，比如管理上保證在項目立項時測試資源到位；需要支持時盡量找相關(guān)業(yè)務(wù)的測試人員；流程上保證需求變更有基線與變更流程控制；保證測試階段的執(zhí)行；等等,方法肯定多于問題的。但同樣的給予，每個項目卻未必有同樣好的效果是為什么呢？因為不夠主動。
那怎么占據(jù)主動呢？有很多時候，我們進入到這樣的境地是不知道自己還有不知道的需求，怎么讓需求自己能夠跳出來找你呢？
1. 集中式掃描需求文檔。
這一條對于不擅長多線程思維的同學(xué)特別有效。這里突出的是“集中式”，找出自己每天記性最強，思維清晰的區(qū)間，把手上的工作排好，專門空出這樣的區(qū)間去閱讀需求類文檔，不要受其他干擾。你會發(fā)現(xiàn)理解需求其實像閱讀一樣富有意境，讓你思緒澎湃，自然而然發(fā)出這樣的問題：這點功能沒有表達清楚是做什么的？這點和那點業(yè)務(wù)有關(guān)系嗎？過了這一環(huán)，需求錯誤，需求描述不清晰，這類型的需求問題能打掃出很多。當(dāng)然，這是體能戰(zhàn)，感冒發(fā)燒稀里糊涂時，此招收效甚微。
2. 珍惜每一次預(yù)審的機會。
特別是評審前的預(yù)審，更為重要。因為技術(shù)型人員多數(shù)都有這樣特點，自尊心特別強，如果在預(yù)審中，能找出問題，并且一對一去和相應(yīng)人員溝通，不光你的問題及時解答，又能幫助其需求得到完善，更是幫助其相關(guān)能力得到提高，這時比較容易與這位同學(xué)建立起親密戰(zhàn)友關(guān)系，相輔相成，交流越多，越能發(fā)散出問題，最能找到像需求的遺漏這樣的大問題。呵呵，這個心理戰(zhàn)使用時，還需要考驗大家的溝通能力與技巧。
3. 親自動手展現(xiàn)項目需求。
這一點必須強調(diào)，哪怕項目需求文檔，設(shè)計文檔，UC文檔已經(jīng)非常精細了，
但還是請你自己，再動手畫一畫系統(tǒng)結(jié)構(gòu)圖，業(yè)務(wù)活動圖，甚至是系統(tǒng)交互圖，因為看的明白和畫的明白，運用的是人腦的不同功能，視覺是理解的來源，動作是理解的表現(xiàn)。在制作的過程中，會要求你的大腦去串連所有需求片段，信息不斷地做著加法，一旦需求有遺漏或是需求理解有錯誤，都會讓你拼不出完整的各式圖表，于是這個項目的各種需求問題不斷的蹦發(fā)出來。當(dāng)拼接的各式圖表成功時，原先雜亂的大腦信息碎片開始迅速做起減法，讓你倍感輕松，快樂無比。無疑，這是實打?qū)嵉募夹g(shù)戰(zhàn)，憑的是經(jīng)驗，拼的是能力。
至此，挖掘需求的實用戰(zhàn)術(shù)簡介完畢。三招而已，三招之后能攻下需求之不確定性嗎？無他，勤練。