如何發揮需求評審的價值，測試同學應該怎麽做？
- 2020-12-04 10:00:00
- IDO老徐 原創
- 13407
需求评审没做好，可能会导致，整个研发过程节奏拖拉、提测质量烂、上线质量烂、项目延期 等综合症 ；
需求评审，是一个项目启动的源头；一般会有哪些人参与呢 ？
产品、研发、测试，以及项目Leader ，甚至是业务方（当然，业务方这块，可以不用一起参与；可产品经理，单独找业务方评审；拆分成两个会议）；
高效的需求评审会议，至少得「产品、研发、测试」参与，且控制1小时左右，全程大家有问题及时提問 ；
一场只有产品经理在那讲，其他同学拿着电脑各忙各的「需求评审会」没有价值、没有开的必要 ；
對于软件测试工程师，老徐的建议：要么不参加，要参加，就要提出问题（比如，需求合理性、逻辑闭环、边界的考虑 等 ）；
观点如上，如下是一个案例 ；
這是一個，來自星球，某測試工程師的提問；問題不錯，很多團隊的通病，IDO老徐 ，統一解答下。
問：“ 如何让需求评审真正发挥作用？ 我們現在有個需求評審會議通知人員到場，然後産品經理blabla講了一番系統的基本需求比如要做注冊、增加、刪除等之類的。 开发、测试、前端由于对系统无任何背景信息和了解，听听就过了，到真的做的时候发现很多逻辑点不清楚 ”
如下是老徐的解答：
關于如何發揮需求評審的價值，這問題很好。很多公司，評審開始可能很好，慢慢的，可能就會變成形式；爲了評審而評審，或者應付流程。
那么如何发挥需求评审的价值呢 ？
IDO老徐，給幾個建議，可參考 ：
就是所謂的，會議「前、中、後」
1、評審前，産品經理，提前把需求文檔、原型等，發給相關人。讓與會人員提前了解下，否則會議就是悶逼狀態。變成産品經理一個人在那自嗨，其他人完全不知道是什麽。
2、與會人員，提前看文檔。標記有疑問的地方，在會上重點討論，交流。
3、産品經理，控制會議節奏，把控討論主脈絡。
4、評審結束後，把會議上大家的疑問點，補充後，發一個新版本出來，大家提前了解，並安排下一次的需求澄清會議（也可由測試主導）。
5、需求存档，确保最新，团队成员同步（建议放在wiki ）。
其他相關文章：
測試用例評審，他們是這樣做的
放养式的测试團隊管理 。
無需求文檔，保障測試質量的可行性做法
关于测试用例的所有问题 。
《簡曆前中後、面試前中後、Offer前中後》有套路(完整腦圖)
最後，
老规矩，强烈建议所有「爱学习、乐分享、喜热闹、需见证」的同学，一起自学、成长 。
每天，老徐都在星球交流；你遇到的99%的問題都討論過、解答過 ；有啥疑問的，「21天打卡」星球，365 * 24 随时向老徐提問 。
IDO老徐
全网同名，个人IP公衆號
日更10年，每天 1 分钟、解决 1 个问题
職場、副業、輕創業、寫作、個人IP
公衆號、視頻號、小红书、知乎
長按/掃碼，關注IDO老徐
關注回複 401 送你「十年原創资料包」
| 聯系人： | IDO老徐 |
|---|---|
| Email： | 957863300@qq.com |
| QQ： | 957863300 |
| 微信： | 957863300 |
| 微博： | isTester |
| 網址： | idoxu.com |
| 地址： | 中国 · 广东 · 深圳 |
來源備注：老徐博客