QA测试员如何参与需求定义流程

日期: 2015-05-20 作者:Robin F. Goldsmith翻译:蒋红冰 来源:TechTarget中国 英文

QA测试人员应该如何参与到需求定义流程中?

在需求定义流程中,审查是更适合质量保证(QA)测试人员的角色,而不是定义;但QA测试人员需要学习如何高效执行审查。对于QA测试人员来主产,在于需求定义审查中成功获得支持关键在于,找到对于其它参与人员重要的问题,这就意味着找出需求内容相关的问题,避免投入过多的精力在形式和可测试性上。在我的书中,或相关的讨论坛中,我描述了许多方法来识别需求问题——包括清晰度和可测试性——以及如何使用强大的方法来检测出错误和疏忽的内容。

有些组织让业务分析师负责定义需求和开发测试,从而证明需求已经达到要求。这类双重角色常常会因为测试方法和知识的不足,而导致测试被忽略掉。另外,分析师的测试不可能显示他们需求问题。这类弱点也还会更严重,当开发人员是定义需求和测试的人时。

因此,让具备独立技能的测试人员定义和执行需求测试是有道理的。

让他们,与资深的分析师一同参与到需求发现行动中,如面试的利益相关者,这又是另外一回事了。

如果QA测试在需求和设计流程中参与的早的话,测试人员可以准备更多的测试,且当代码到来时,准备好开始执行他们。早期的参与者帮助确保需求是可测试的,并帮助QA测试人员更好地理解测试什么,然后编写更好的测试。

我已经警告过,仅仅取得接近需求的权利往往会事与愿违。更常见的是,QA测试人员在第一次尝试中并没有准备好做出高效地贡献。其它人也发现他们并有什么帮助,更糟的甚至他们有点碍事,然后把他们排除在需求审查之外。此外,这种不好的经验阻断了第二次返回的机会。主要原因是我称之为的“可测试性陷阱”;具有讽刺性的是,它是来自于QA测试权威的口中,他们说需求的主要问题是缺乏可测试性,进而在很大程度上是由于缺乏清晰度。

这样,当他们参与到需求审查流程时,QA测试人员更倾向于停留在引用他们认为所缺乏的可测试性的需求,然后期望分析师们重写它们,使之更加可测试性。分析师鲜少有时间,也很少有兴趣重做他们的工作;而其它审查者常常认为这类对可测试性的抱怨是无关紧要的。它们也被忽略了,这些参与者不仅没有增加价值,还干扰了有用的评论。

我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。

我原创,你原创,我们的内容世界才会更加精彩!

【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】

微信公众号

TechTarget微信公众号二维码

TechTarget

官方微博

TechTarget中国官方微博二维码

TechTarget中国

翻译

蒋红冰
蒋红冰

TechTarget云计算主编,主要负责云计算和虚拟化网站的内容建设。长期专注于IT前沿技术,对云计算、虚拟化、人工智能、区块链等技术都有了解;对行业趋势、市场动态有一定的洞察。

相关推荐