问新的ISO/IEC 29119软件测试标准会与像Scrum这样的敏捷方法一起工作吗？

EN

这一“标准”是在上下文驱动的测试社区的公民直接和反复呼吁停止和停止的情况下制定的。

不管这件事是基于什么，它不会建立在一个真正有代表性的测试者群体之上，也不会建立在合格的社会科学家之间的研究之上。

这是欧洲测试咨询公司将使用的另一种工具，用于蒙蔽客户，推广过时、无知和滥用的测试做法。

我们不需要软件测试的标准。我们需要一群测试人员来研究这一技术并推动它向前发展。请和我一起抵制愚蠢的标准。

为什么只想到敏捷是抱怨这个标准，为什么不上下文驱动的测试学校，为什么不TDD，为什么不脚本测试呢？

我不认为“一刀切”的遵从是不可能的，甚至是一件好事。

原因是每个项目、组织、业务、技术都有不同的标准&测试过程中期望的性质。

尽管如此，也有“标准”在某些行业得到应用的情况，但它们通常是由业务需求驱动的技术标准，而不是流程/活动标准。

我在一家为公共安全收音机(警察、消防安全、电力、军事)生产HW和SW的公司工作，这项技术是一个开放的标准，而标准组织已经规定它应该是一个开放的标准，以鼓励manufactures.Hence之间的互操作性--测试活动的一个重要部分是执行一系列严格控制的测试，通过一套标准documents.However，这是因为所有的制造商都已经得到了标准当局的咨询，并在标准被published.And之前接受了，因为他们认为这是推动他们的业务发展和减少documents.However的一种方式。

然而，似乎这套特殊的测试标准并不能准确地代表广泛的测试专家或来自不同“学校”的测试人员。(从James的评论推断)

我有一个很好的消息给大家-我确实可以访问7月份的2011年草案，我可以安全地说，敏捷测试反映在所有的案例研究(“附件”)在29119-3。具体来说，两个概念上的大型组织：“敏捷公司”和“传统有限公司”之间的对比以及它们的测试方法。下面是一些应该给每个敏捷实践者带来微笑的东西: IEEE标准，它提供了如下示例：

测试报告:新订阅系统( NSS ) Vers。：Sprint 3涵盖:NSS最终冲刺结果，包括以前冲刺的结果，为主要客户交付(供使用)做准备。风险:使用测试团队和客户“清理”的历史实时数据创建模拟数据库，从而避免了实时数据风险。测试结果:客户接受这一发布的产品基于:16个用户故事添加后，最后的状态报告是成功的。一个高风险故事的测试技术实现了100%的语句覆盖率，而其他的72%的语句覆盖率平均达到了72%。团队接受了严重程度3的4个缺陷的积压。展示被客户接受，没有额外的发现。展示演示短跑功能与“现场”数据接口。sprint特性的性能被团队和客户发现是可以接受的。新的和已改变的风险:系统的安全性可能会成为未来Sprint的一个问题，假设后续工作任务是从回顾性的客户备注中收到的:Sprint团队认为可能需要一个新成员，因为没有人知道这个领域的新风险。在下一次sprint中，应该解决转到待办事项中的严重3缺陷，以减少技术债务，修改后的实时数据运行良好，应该得到维护。测试自动化和探索性测试是可行的，但是应该考虑附加的技术，例如安全性和组合测试。

享受吧！