學習過測試理論的同學肯定都知道，測試人員參與專案的第一步，大部分都是需求評審，但是不少測試同學反饋，自己很少參與需求評審，需求會議也很少喊測試人員參與。

我覺得這一方面可能是流程上各角色配合的問題，另一方面可能是因為測試在評審過程中沒有體現出參與的價值。

針對第一個可能，需要測試主動找產品溝通，一方面表達希望參與需求評審的意願，另一方面也要求他們在需求評審時喊上測試。

針對第二個可能，就需要測試人員從自身上做改進了，為什麼這麼說呢？我曾經參加過幾次需求評審會議，就發現產品在那講需求，開發偶爾會提一些技術實現上的細節問題，測試就只是在那聽了，會議結束後，回去該幹嘛幹嘛，既然我們測試參與需求評審時不能產生什麼價值，那產品怎麼能在評審的時候想起來喊我們呢？

終於到了今天我們要說的主題了，作為測試，參與需求評審時我們可以貢獻什麼價值？下面我說下我的觀點。

1.需求評審的作用

回答上面的問題前，我們先看看需求評審到底是幹嘛的？先不管書上怎麼說，從我的經驗看，需求評審就兩個作用：

1.同步產品對於需求的詳細設計
2.收集大家對於需求的各種反饋

對於需求設計，肯定是產品發起並負責的了，那麼作為測試人員參與需求評審，著重點就在於第二點，關於需求的反饋上面了。

2.需求評審的形式

最開始我提到有同學說沒有參與過需求評審，有部分是面試的同學說的，但是詳細問過之後，才知道他說的是形式的問題。

比如他理解的需求評審就是大家一起弄個會議室，產品講需求，開發和測試懟產品這樣的，而實際情況是，產品把需求往群裡一扔，大家就七嘴八舌的討論開了，又或者產品直接跑過來，在開發和測試的工位上當面溝通一下就算完事了，恩，我說這也算需求評審呀，形式不重要，重要的是做這事的目的和效果。

3.測試是否需要參與需求評審

廢話，必須十分完全有必要呀，僅僅從同步需求設計的角度看，當面的同步一下需求，肯定比文字上的傳達效果要好的多了，而最重要的其實還是測試在需求評審中提出的反饋，才是最寶貴的，所以下面我就主要說說測試對於需求反饋的價值主要都體現在哪些方面。

4.需求評審之需求合理性

需求合理性，這是開發和測試慫產品最多的地方之一。

彈這麼大個框，太打攪使用者了吧？我建議縮小二分之一。
解除安裝個軟體，還要確認這麼多次，使用者該煩了吧？我建議點選解除安裝按鈕就完事。
首頁內容已經很多了，再加一個會有效果麼？是不是再精簡點內容比較好？我建議一屏不超過 5 條內容。
這操作流程有點反人類呀，互動咋設計的呀？我建議主要操作一步即達，次要的三步以內完成。

恩，雖然最後拍板可能還是產品是說了算，但是作為種子使用者，該提意見還是要提的，特別是有些地方其實產品也沒有定論，這時候的意見非常有可能會被採納，如果建議被採納的次數多了，自己的建議就會更受大家重視，那麼話語權也就會相應的有提升了。

然而，很多人其實是不會反駁需求合理性的，大不了就內心裡吐吐槽「這麼腦殘的設計，虧的能想出來」，也許這是和公司環境有關係，但是如果自己真的有什麼好的建議，還是建議找機會提出來，畢竟咱們是測試嘛，使用者體驗的質量也是質量範疇內的事噢。

5.需求評審之需求全面性

前面說的需求合理性，需要我們站在使用者的角度去考慮問題，不是所有人都能做到，這也情有可原，但是需求全面性這個確實是需求評審中必須要考慮的問題啦，這個不僅僅針對產品設計，也包括開發實現邏輯。

如果使用者登入超時了，產品怎麼展現？
如果使用者輸入了非規定範圍內的資料，邏輯上是否做了異常處理，怎麼告知使用者？
如果使用者長時間不關機，邏輯上是否有問題，如何處理？
如果多使用者同時登入，會出現啥問題？
如果系統休眠後恢復，產品如何處理？

針對這部分內容，大多是對於使用場景的覆蓋，很多產品考慮需求時，只覆蓋了常規使用者的主要操作分支，而異常情況考慮的比較少，對於測試來說，異常場景的考慮正是我們的長處，所以在需求評審階段儘可能多的和產品確認各種異常場景的處理，可以極大的避免在測試過程中出現問題後被返工的情況。

好了，羅羅嗦嗦說了這麼多，希望對大家有幫助，有任何有疑問的地方，歡迎留言溝通。

本文原創釋出於公眾號「sylan215」，十年測試老兵的原創乾貨，關注我，漲姿勢！