我不知何故偶然发现了一些有关新ISO / IEC 29119软件测试标准的参考,该标准目前处于起草阶段(显然)。

我还没有看到这个新标准的细节,但是我希望真正的现代测试标准不应该仅仅承认,它应该包含敏捷开发实践,以便可以在使用诸如Scrum之类的敏捷方法时以符合标准的方式应用。

是否有人“测试”了新标准并将其实际应用于敏捷项目?新的ISO / IEC 29119软件测试标准是否可以与Scrum之类的敏捷方法一起使用?

编辑:虽然James的观点很有趣,但实际上并不能回答问题。我想听听实际使用过它的人的意见。

评论

好问题-草案似乎尚未公开,但是您可以通过发送电子邮件给您的国家标准机构索取一份副本:softwaretestingstandard.org/gettinginvolved.php我很想听听敏捷社区的普遍看法该标准-如果它可以兼容,或使其兼容,或者如果它不兼容-如果它不兼容,那么可以对高级管理层说:“整个社区的共识是该标准与我们选择的开发过程不兼容/不相关。”

我已请求草稿副本以进行审核,并且得知我的请求已转发给负责该标准的委员会。他们无法给出时间表,不幸的是何时能够回复我。但是,此处提供的ppt softwaretestingstandard.org/downloads.php(您必须注册)并没有减轻我对标准的很多担忧。

事情处于草稿状态,不容易获得。测试社区中许多受人尊敬的人都在说这是浪费时间。当您将所有内容加在一起时,我认为找到真正“使用过”然后符合标准的任何人的机会都很低。

@sean_robbins您已经比我走得更远了。我在原始帖子发表时要求提供草稿副本,但尚未得到回复。在ppt上达成协议的前景并不乐观。

#1 楼

这种“标准”是在上下文驱动的测试社区的公民直接和反复请求终止和终止时创建的。

无论这句话说什么或基于什么,它都不会建立在一个真正具有代表性的测试人员社区的基础上,也不会建立在合格的社会科学家的努力基础上的研究。

这是欧洲测试咨询公司将用来使客户和提倡过时,无知和滥用的测试实践。

我们不需要标准的软件测试。我们需要测试者社区,他们需要研究工艺并将其推向前进。请和我一起抵制愚蠢的标准。

评论


同意,只要项目成功,标准不重要

– Aruna
2011年5月22日23:19



我想那是不可以的... :-)

–布鲁斯·麦克劳德(Bruce McLeod)
2011年5月23日4:00



詹姆斯说了什么。毕竟,他是海盗测试员的父亲。啊!

–汉尼拔
2011年5月23日7:39

问题在于ISO / IEC 29119如何与敏捷方法(如Scrum)相关。巴赫先生实际上并没有回答这个问题,所以我很不赞成。

–user246
11年5月23日在20:46

哦,对不起User246。让我直接回答这个问题:不。 ISO / IEC29119与废话有关。这会让您更清楚吗?

–詹姆斯·巴赫(James Bach)
11年7月24日在10:22

#2 楼

为什么只有那时才想到敏捷是对此标准的抱怨,为什么没有上下文驱动的测试学校,为什么没有TDD,为什么没有脚本化测试?

我不认为“全面”合规性是可能的甚至是一件好事。

原因是每个项目,组织,业务,技术都具有与测试工作不同的标准和期望性质。

说过在某些行业中确实有时会使用“标准”,但是它们通常是由业务需求驱动的技术标准,而不是流程/活动标准。

示例-
我工作在一家制造用于公共安全无线电(警察,消防,电力,军事)的硬件和软件的公司中。现在,该技术是一个开放标准,并且标准组织已强制要求该技术应成为一种开放标准,以鼓励彼此之间的互操作性。因此,测试活动的重要部分是执行一堆可以通过一组标准文件进行严格控制的测试。但是之所以这样做,是因为所有制造商均已获得标准机构的咨询,并在标准发布之前就已接受。制造商接受此规范是因为他们将此视为一种方式

然而,似乎这组特定的测试标准似乎并不完全代表广泛的测试专家或来自各种“测试学校”的人员。 (根据詹姆斯·巴赫的评论推断)

#3 楼

对于所有人,我都有个好消息-我确实可以使用2011年7月的草案,可以肯定地说,敏捷测试反映在29119-3中的所有案例研究(“附件”)中。具体来说,这是两个名义上的大型组织之间的对比:“敏捷公司”和“传统有限公司”及其测试方法。这应该使每个敏捷实践者的脸上都露出笑容:具有以下示例的IEEE标准:


测试报告:新订阅系统(NSS)

版本:Sprint 3

封面:

NSS最终的sprint结果,包括以前的sprint结果,为主要客户交付(for使用)。

风险:

通过使用由测试团队和客户“清除”的历史实时数据创建模拟数据库,从而消除了实时数据风险。

测试结果:

客户基于以下条件接受了此版本的产品:
成功完成上一次状态报告后添加了16个用户案例。
面对一项具有高风险案例的测试技术,实现了100%的声明覆盖率,而其他方面则平均达到了72%的声明覆盖率。
团队接受了4个严重性为3的缺陷的积压。 br />展示柜被客户接受,没有添加任何发现。演示演示sprint的功能与“实时”数据连接。
发现sprint功能的性能为团队和客户所接受。

新的和已更改的风险:

假设收到客户的跟进工作任务,则系统的安全性可能成为未来冲刺的问题。

回顾工作中有关未来工作的注意事项:

Sprint小组认为,鉴于可能的新风险,可能需要新成员,因为没有人对此领域有了解。
严重性3待解决的缺陷应在下一个sprint中解决,以减少技术负担
修改后的实时数据运行良好并应予以维护。
测试自动化和探索性测试正在工作,但应该考虑添加技术,例如安全性和组合测试。


享受吧!

评论


Erm-为什么那会带给我微笑?另外,掌握它的秘诀是什么?我从未通过官方渠道收到过对我的请求的任何回复,因此我从未看到过据称可以征求意见稿的信息。

– testerab
2011-09-5 20:46



还有-我的举止在哪里?欢迎来到站点Andy :)

– testerab
2011年9月5日在21:04

欢迎使用SQA!您能否格式化您粘贴的摘录?会更容易阅读

– dzieciou
2012年6月26日13:33

我也有一个副本,在整个标准中都重复了“敏捷”和“上下文”两个词。

–Rsf
2012年8月1日14:09

#4 楼

作为一名前测试人员和现在的质量保证经理,我已经从事了15年以上的测试和管理非常复杂的地质和地球物理解释软件的测试工作。我的测试团队首先是地球科学家,其次是测试人员,因为您必须具有高级学位才能了解软件的功能。我使用RUP在一个团队中工作,并且我们获得了ISO 2000认证。谈论尾巴摇狗。作为团队负责人,在一家生产GeoFrame和现在的Petrel的大型石油服务公司中,我可以说该标准(即ISO2000标准)推动了一切。该组织如此专注并专注于遵守标准,以致于与进行建设性测试相比,花更多的时间在毫无意义的会议上,创建工件并跳过标准所规定的障碍。

现在在其他公司中使用Scrum Agile,测试更加简化和有效。我们正在为敏捷构建测试标准,作为针对用户案例和迭代的完成定义的一部分。我们发现,QA团队迫于无奈地以未完成的工作流测试用例的形式结转了许多技术债务,直到最后一次迭代的所有功能都到位之后,这些工作才能完成。这是Catch-22。在完成所有编码之前,无法完成测试用例;在完成所有测试用例之前,无法关闭所有用户故事。

,我非常费力地不创建测试。将我们穿上直筒夹克或变成摇尾巴的尾巴的标准。

#5 楼

我是软件测试的新手,并希望对此发表自己的看法。

一些开发人员/程序员/商人认为软件测试是一项“低端” IT工作,因为他们“认为每个人都可以做测试!他们认为这是一项“轻而易举”的工作。
当然,我们知道这是错误的。好的质量检查/测试需要大量的高级技能和专业精神。

有了这个ISO标准,我们终于可以向他们(相信每个人都可以进行测试的人)证明,质量检查/测试不是一项低端,毫无头脑的工作。我们有一个标准。我们很专业!(您的老板会把您当成专业人士!)

我只能说我们生活在一个由商人经营的“黑暗”世界中。为了推动质量检查行业前进,“不幸的是”我们需要有一个标准来说服他们。

评论


对此表示反对,因为它无法回答问题。

–user246
2011年5月23日在15:34

我不同意。问题不是要引起商务人士的尊重,而是要找到优秀的技术公司,他们认识到软件是传统商务人士不了解的独特业务。测试社区中最熟练的成员倾向于避开此类标准,而是选择在尊重他们才能的公司工作。这些标准已经存在了一段时间,最好的公司通常会忽略它们。

– Ethel Evans
11年5月23日在16:44

我同意Y先生的意见,我们确实需要某种标准,但是正如@James在下面指出的那样,正在创建的标准是由本身不是测试人员,因此没有资格进行软件测试的人员完成的。标准。所以,我不赞成这个答案,因为它是反动的,而不是客观的答案,而且研究还不够深入

– Tristaan​​Ogre
2011年5月23日在18:40

我实际上对Y先生有些同情,但希望有一天他会意识到他有责任说服他的老板说他是专业人士而不是标准。

–sean_robbins
2011年5月25日20:50

标准!=尊重(在很多情况下甚至可以相反)

– Chuck van der Linden
2011年5月30日,下午1:50