测试用例评审、技术方案评审、UI评审,考验的是发现问题的能力

文摘   2024-05-28 11:11   广东  

产品经理评审完需求后,测试要开始写测试用例;研发要开始评估需求出技术方案,不用出技术方案的需求直接就开始开发了;UI也要开始出图了。

先说一下我对测试用例的价值理解
1、测试用例需要覆盖所有场景,确保测试没有遗漏,会决定功能的质量。这点是最难的,毕竟测试不是产品经理,对需求和用户的理解没有那么深,这点是会考验测试人员的经验和产品熟悉度的。
2、测试用例很细,会细到文案匹配、UI匹配、行间距文字空格、表单元素的限制长度符号等,能避免出现很多基础问题。
3、测试用例可以作为研发的检查项,有的测试用例描述的点或者场景,研发自己可能没想到。正常研发开发完成后,要用测试用例走一次自测,这样可以减少研发的Bug率。
测试用例评审
测试用例评审由测试主讲,需项目经理、产品经理、对应开发人员参加。
目的很简单,就是一起评审测试用例是否会有遗漏,写的用例是否有问题。
测试用例的评审是枯燥的,很多时候用例评审效率其实都不高,主要是因为产品经理和技术其实都不认真不投入,好像和自己关系不大一样,测试用例评审更多的是走走过场。
系统上线后,如果有Bug,一般主要责任都会在测试身上,要么就是测试用例覆盖不够,要么就是没认真测试。
技术方案评审
一般什么需求要技术方案评审呢。
比如第三方登录,研发至少需要把时序图画出来,要把每一段链路画清楚,然后如讨论合理性和最优性。
还有比如技术选型、性能方案、系统对接、系统架构设计等,基本上涉及到纯技术的沟通讨论。
技术方案评审一般是技术内部的沟通会,产品经理正常都不用参加技术方案的评审讨论,但是其实我建议产品经理参加,这是学习技术、理解研发思考逻辑、需求实现逻辑的最好方式。
技术上的东西不用完全懂,知道大致作用和实现逻辑就好,能提升产品经理和研发的沟通效率,这也能提升产品人在研发心中的威望,如果你懂点技术,知道实现大致逻辑,研发也不敢随便忽悠你,更不敢轻易说没法实现了,回头你给个解决思路分分钟打研发脸。
UI评审
一般公司都没有UX(用户体验设计),都是产品经理直接画完原型和交互设计,专门招个人来做UX成本太高,通常只有大公司或者互联网企业才有这个岗位。
UI设计师根据原型设计出UI图后也需要进行评审,如果公司有UX那么要等UX设计好交互并评审完才会给到UI出图。
UI设计师画完图后,要先给设计部内部确定没问题,然后给到产品经理进行确定,产品经理确定后然后再开UI评审会给研发测试讲一次UI。
大部分人都无法挑出UI的问题,因为专业性也很强,设计师画完后给到你来看,很多时候感觉不好但是又说不上来,给不了太多建议,但是优秀的产品经理可以,在视觉这块产品经理也必须要有一定审美能力和提问题的能力。
如何提高自己对UI图的审美能力?
1、产品经理要多看看竞品的页面设计。
2、多在网上(ZCOOL站酷、花瓣、vcg视觉中国、Pexels、Pinterest、Dribbble)找找其他UI图多看看,只有看多了,审美能力才会提升上来
3、多注意一下优秀的人是如何评判UI好坏的,这里还是有一点技巧在里面的。
产品经理是对需求、用户、情境最熟悉的人,在测试用例评审、技术方案评审、UI评审中,最考验产品经理的是发现问题的能力。
要发现什么问题呢?
1、测试用例有哪个环节、哪个细节点没有考虑到,需要你找出来,确保需求的测试能够全面覆盖。
2、技术方案评审产品经理好像是一个旁观者,但其实也是重要的主力之一,要站在用户的角度、产品的角度、情境的角度去提出技术实现的问题,去发现技术方案在某些场景的不足或未来的扩展性问题。
3、UI设计师做好的UI,至少要经过产品经理的把关后才能给到开发实现,改改改改再改改,完全靠设计师是不行的,还得靠产品经理去磨一磨,磨的越细最后出来的价值肯定越大。

------ END ------

推荐阅读
产品经理需求评审会的本质,为什么需求评审对产品经理是一个挑战?
产品经理成长体系 I阶段
产品经理方法论 62讲
产品经理思维框架24讲
关注公众号
在公众号主页发消息:1
加好友,备注加群,进微信交流群,一起分享和成长!
发消息:3、4、5
免费下载PPT原型+Axure元件库》
免费下载整套产品文档》(竞品分析、产品规划...)
免费下载《产品经理成长计划表》源文件

    产品经理方法论
    让每个PM的学习和成长之路都是最高效的。
     最新文章