文 / 初夏
今天首次参与了用例评审会议，和印象中的有那么点差别。
会议前准备：
1、将用例内容分享给评审会议参加人员；（用例库）
2、将需要商议的用例整理成表格提前发至会议参加人员；（包括用例编号，标题，需商议内容）
3、按优先级分类看下case内容（由于其中一部分是自己写的，比较熟悉）；
4、备好纸和笔，随时记录一些需要纠正完善的地方
PS：会议前还在想如何将效率比较高，按照优先级分类，讲功能点？还是按照他们之前的规则，一条条过？
会议中：
1、主讲人为模块owner，参与者为开发、产品、测试；
2、首先，抛出需商议问题（之前整理的），并一一确认；
3、其次，看迁移过来的参考用例，确定本版本产品的数据标准；
4、然后，看场景功能点是否需要补充（该场景也是迁移过来，产品实现也如此，并未大的改动）
5、最后，看客户端的功能点哪些需要更新或者删除（该客户端整合两个版本的特色，有改动）
PS：全程我的发言不过3句话
会议后：
1、模块owner整理出需要更新的部分（当然，我在会议中也记录下来）
2、根据会议记录，更新用例
感受：
1、参与感不强（可能因为产品的特殊性，所以用例的很大部分与之前版本相似，所以基本主要探讨修改的部分，主要是开发、产品和owner的交流）；
2、修改部分的细节未探讨，没有文档参考（写用例时给了一份PRD参考，会议上说一些场景做修改，并未阐述修改细节）；
3、会后的总结（owner对用例还未足够熟悉，因此评审总结不是很全面）；
想法：
1、提高参与感，根据产品的特色，有重点的参与进入评审会议，对于某些问题提出作为产品的真正测试者的想法；
2、提高积极性，写完用例时，主动询问产品/开发有无修改点，如有，提供修改点的文档，或者具体的交互细节，节省会议上对于修改点的探讨；
3、会后总结，对于case的熟悉程度应属编写人员最了解，因此向owner请缨，主动写评审报告，写清需修改、删除、添加的用例，并对一些注意点作说明，完善用例的覆盖面。
网友评论