问答 问题已解决

caolanmiao · 发布于 2017年11月02日 · 最后由 nie.qingyang 回复于 2017年11月06日 · 878 次阅读

问题已解决

共收到 31 条回复
2e1373

为什么不一起开?要分开?

11901
2e1373newbe 回复

因为之前测试有活,就开发和产品先开了

12112

测试参与需求评审可以更早的理解需求,然后开发在开发功能的时候测试人员就可以着手去设计测试策略和用例了

5847

要么一起开,要么先比开发早一步开,测试在评审更大的作用是完善需求

11901
12112CwXwWw 回复

可是什么样的需求是看文档看不明白的呢?有必要牺牲测试的干活时间吗

11901
5847h470789634 回复

新需求的完善是要靠测试来完成?这点我真是不太理解呀

7642

这种 还是要一起开才行

11901
7642lxs1314520 回复

我甚至觉得测试没有参与的必要

6853

让开发自测最好

110

最好的方式:

step1:产品+开发+测试一起搞下需求宣讲。
step2:开发拉测试,产品过系分(如何实现需求的设计文档)
step3:测试拉开发,产品过测分(如何测试)

167d23

为了更好的验证开发确实按照产品的文档或者陈述去实现需求。
首先,信息的传递容易失真,早期测试介入,容易把控需求的完成度;
其次,开发的惰性,你不早点介入跟踪开发的进度,很大可能会遇到开发偷工减料、微变更需求、为了方便提交不可测试代码的情况,这时候带来的工作成本更高;
然后,测试左移,这个概念是鹅厂某分享主题,从需求层面发现bug或者不合理性,减少不必要的返工,也是提升效率的切入点;
最后,个人拙见,多了解点产品特征也没啥不好的,反正我每次参加这种会提出一堆问题,觉得自己这个测试的存在感很强,工作认同度也好多啦

16280

测试有事,那是你们自己的责任,不赖流程

16120

个人拙见~
1.需求评审会议应该是产品,开发,测试一起参与的,这样有利于测试清晰整个产品的架构和逻辑,以及可以评估下风险,对自己设计和编写用例有很大的帮助。
2.如果情况是测试有事没参与需求评审会议,那会后只需要给确定下来的需求文档到测试即可,并不需要再跟产品开多一次会,纯属浪费时间。测试对需求文档有疑问的地方,可以先记录下来,再找个时间跟产品确认即可。
3.我觉得你公司在需求评审会议时有要求测试参与,这点可以看得出公司对测试有一定的看重,而这个会议的质量得自己去把握,有的人喜欢别人直接告诉他怎么做,他就怎么做;有的人喜欢参与别人的讨论中,一起开启头脑风暴。至于利弊,我想你心里也应该有个数吧~
4.我从你的文字中看出了你的急躁,也看出了你似乎很忙碌?或许可以说是一种效率不高的表现?如果我说错那我道歉哈~其实你大可不必这么忿愤,每件事都有它的意义,耐心一点也许你会发现其中的好处,如果一点好处都没有,那就当做是放松自己咯~
希望对你有些帮助~

9631

个人认为:测试肯定是需要参与需求评审的,只看文档 能了解所有的需求吗?
能了解到需求的细节吗? 测试参与需求评审,可在评审过程中更加深入的了解需求,对需求提出一些建议或者意见
按照LZ的思维,那产品为什么要和开发评审呢?看文档不就可以?
最后个人认为。。。评审会议还是一起开比较好。。。

445

问题来了,为啥不是测试,产品,开发一起开需求评审。

关于是不是鸡肋,我个人认为非常有必要。 首先测试,开发,产品在需求评审会上,每个角色都会根据自己角色出发去考虑需求是否合理,站的角度不同, 再来测试其实往往是最熟悉产品功能的人,往往可以发现需求很多问题,最后磨刀不误砍柴工,越早发现问题,fix的成本越低。

13165

开发要做的是怎么实现需求,对业务的理解能力不如测试。测试参加需求评审可以提供更好的建议,也可以发现需求期隐藏的BUG。
但是听你的说法,你们更像是产品在给讲需求,而不是做需求评审。

12369

题主的想法好奇怪啊。别的人都是抱怨测试不被重视,需求或者变更总是最后一个才知道。导致有漏测或者临时的加班

你怎么是调过来的?觉得产品找你对需求反而是负担。。

当然,如果是资源很少,不想用开会这么重的方式,可以跟产品提意见,在工位简单过一下也是可以的。不至于这么吐槽吧。

测试什么会都不参与,只看文档测试,就不怕背锅吗

11901
caolanmiao · #18 · 2017年11月03日 作者
12369jacksonchina 回复

不是抱怨啦,只是我觉得当测试的话语权不足的时候,这样的方式是不是值得探讨,还有如果一定要让测试来背锅的话,其实跟测试有没有参与评审会是木有关系的~

E5e79f

目前我们也是这样的模式:
1、产品和开发过需求的会议,是让开发评估需求的可行性,其中还包括实体和数据流转的细节。
2、可行性会议通过后,产品需要按会议结果修改然后发布需求。
3、在需求发布出来后,测试需要看需求&理解需求。这时候分为2种情况:
a、需求文档足够详细,测试可以直接按现有需求文档写用例;
b、需求文档存在细节的疏漏,测试需要汇总然后发布给产品/开会讨论,让产品完善需求。
产品修改的需求都需要邮件通知给开发。
c、需求存在设计疏漏(毕竟测试是最了解现有系统的人),这个时候产品、开发、测试都需要开会讨论了。
在会上定下来最新的需求。

56d552

测试需求也是测试工作的一部分吧?
“测试只负责保证是否按需求实现”——你这个观点就是个伪命题,一个系统工程,怎么可能简简单单的就是分工?把需求疑问点消灭的初始阶段,这是需要整个软件工程参与者都参与的事情。

12369
11901caolanmiao 回复

正因为测试话语权不足,才需要多多参与。不参与,别人怎么知道你测试厉害呢?

你能在开发产品测试一起的会议中,查漏补缺,力排众议,久而久之,你就是事实上的业务专家。

如果什么都不想参与,只想干好自己的活,何来话语权的提升。非职权的影响力就是要依靠这种

团队的日常交流共同的场合,一步一步建立的。另外,我表达的意思是多沟通,是可以减少背锅的哈。不是

说你参与了会议就不用背锅了

56d552
11901caolanmiao 回复

约莫你是没学过软件工程,你觉得需求谁都看得明白,是压根儿不知道大家思想上和理解上有多大差异

5837

适应公司的文化就好,有些流程并不通用,毕竟是打工的只能提提意见,别太纠结。

16280
5837taflo 回复

你这个观点比楼主的还要让人觉得无厘头,消极到家了

5837
16280fudax 回复

并没有消极啊~~只是让人看开点,这种流程的东西不用太纠结,有时间多看看技术类的东西。

970147

正常且灵活的流程,是产品+开发+测试一起需求评审。

11901
caolanmiao · #27 · 2017年11月03日 作者
6853codeskyblue 回复

哈哈哈,这个说法可以的!

12759

难道不是一起开需求评审么?

1706

@taflo 如果你以后职位能有上升的话,回头看估计你自己都会鄙视你现在说的话~
测试如果都这个心态的话,地位低真心怨不了别人。
目前团队里测试就是需求评审不提意见,一头包。

5837
1706yangchengtest 回复

话不要说这么满。仔细想想谁是最应该也最有时间去调研需求?评审提意见有时间有精力当然要搞,但评审完就一定没问题?然后就有评审规则,标准等等出来。还是那句话有时间有精力当然要搞。
最后说一句在一个公司地位高低和你在什么团队是什么职位“没有关系”,就看你为其他同事们(包括老板)能提供和提供多少服务而决定的。

Ebe164
16120Ningxw 回复

讲得很中肯

11901 caolanmiao 关闭了讨论 11月07日 15:57
需要 登录 后方可回复, 如果你还没有账号请点击这里 注册