测试人员应该批准发布，还是只报告测试？

20

将签名授权给测试人员是否有意义？应该有一个测试团队

只需测试功能，问题等，并仅在通过/失败的基础上进行报告，然后由其他人根据这些结果采取行动，或者
是否有权根据这些结果自行阻止发布？

换句话说，应该要求测试人员实际批准发布吗？与我一起工作的测试团队认为他们确实这样做了，因为“测试范围蠕变”，我们对此有疑问-拒绝批准发行版有时是基于有问题的发行版未明确解决的问题。

testing release-management process

— 欧内斯特·弗里德曼·希尔
source

2

请改写您的问题，以免它不是民意调查。您要解决的问题是什么？

— M. Dudley

5

“应该”很大程度上取决于公司的组织结构。如果根据生产中发现的错误来衡量它们，那么能够保留错误的发布是必不可少的工具。

很好的一点，@MichaelT。在我的组织中，测试是角色而不是职位描述，而评估则是临时性的，而根本不是定量的。成功的部署会带来正面的评价，但是生产中的错误将不是特定的负面影响，对团队中的其他任何人来说都不是。

— 欧内斯特·弗里德曼·希尔

5

如果您遇到问题，即测试人员基于计划中未解决的问题而拒绝批准发布，那么您将遇到沟通问题（他们不知道计划中未解决的问题）或人员问题（他们正在使自己变得重要；是否是重要的）？发布是最终的商业决定）。

— Jan Hudec

27

我在质量检查人员那里工作过的大多数地方的确有某种签核步骤，但是对于发布是否继续没有最终的决定权。他们的签字表明他们已经完成了发布计划所预期的测试，而不是发布是完美无缺的。

最终，质量保证！=业务和业务需要确定他们是否可以在当前状态下部署代码，还是收益大于弊端或其他原因。这通常是由客户或利益相关者在部署之前立即完成的，通常称为“用户接受”。

如果您的质量检查人员也是您的用户接受组，则有可能他们确实有权将发布候选者定义为不可接受，但是如果您遇到的问题超出了错误修正/迭代/冲刺/更改的范围要求/无论您花多少时间，项目经理或业务干系人都需要来耶稣与质量保证团队会面。

报告先前存在的缺陷或新要求的意外结果是可以的，但是如果超出范围且没有灾难性的影响，通常将其标记为阻塞性问题是不可接受的。它会将积压的订单留给产品所有者，以使其像其他所有事情一样确定优先级。

— 法案
source

谁决定您是否邀请客户对内部版本1234进行验收测试，或者该测试不足以进行验收测试？

— Bart van Ingen Schenau

3

@BartvanIngenSchenau：产品负责人/项目经理必须对这些有最后决定。因为即使需要，即使是验收测试也经常会膨胀（即使我们无法让Y一起使用，您现在是否仍要使用功能X，还是要再等2个月才能修复它？）和产品所有者正在协商。

— Jan Hudec

除了Jan所说的以外，在许多方法中，这里都会有时间表或节奏。有些人将在最初的烟雾测试中幸存下来的每个候选人都部署到UAT，一些人将所有检查到的内容自动部署到候选分支中，有些则将所有检查到主要位置中。理想情况下，您一直在以某种方式向利益相关者展示进度，因此最后应该不会有太大的惊喜。在某些情况下，您最终向利益相关者展示了质量检查人员一直在拖延您什么事情，他们只是说“谁在乎”而已。

— 比尔

在具有连续部署的现代SaaS中，代码（服务）部署周期可以与功能（业务）发布周期分开。可以使用功能标志或切换功能来实现此功能发布周期，例如从alpha（内部）到beta（启用）到一般可用性。这是一种涉及更正式的业务签署的方法，而与特定代码或服务的可部署性无关，而与之无关。相反，将功能发布与服务部署联系在一起，将耦合和风险引入流程中，而使用功能标志技术可以避免这种情况。

— 威尔

@我不会不同意，但是如果那些隐藏功能被隐藏得足够使初始部署中的beta团队以及最终我使用该方法的用户无法注意到，则仍然有人会做出判断，或多或少是相同的，但活动部件上带有不同的标签，风险有所变化。我更喜欢您所描述的情况，但是QA团队发现已有的东西或产品经理决定继续进行与我所经历的其他事情一样，在此模型中同样重要。

— 比尔

6

有人需要那种权威。无论是测试人员，测试人员团队，测试人员团队的负责人还是开发组织的负责人，都无关紧要。或更准确地说，这取决于组织。

最终，发布软件的选择是业务功能。企业必须决定质量是否合适。可以说，质量保证总监应该做出该决定，或者将该决定提供给适当的业务部门。这一切都取决于公司的规模，质量的相对重要性等。

综上所述，用于做出决定的信息始于测试人员。无论他们是否有权停止发布，当他们认为自己认为应该导致发布延迟的内容时，他们都应该有责任通知决策者。

— 布莱恩·奥克利（Bryan Oakley）
source

6

授予测试人员发布许可权（即否决权）与将开发权授予开发人员一样有意义：根本没有。

测试人员和开发人员主要是技术人员，因此他们可能主要根据技术来做出决定。但是，发布时需要权衡的问题既涉及技术方面也涉及业务方面。显然，如果您交付的产品存在漏洞，客户将不会满意，但是如果您继续推迟发布，则客户也会同样不满意，因为产品上仍然存在未解决的问题。

有人需要在优质产品和遵守客户承诺的时间表之间找到适当的平衡。要做到这一点，你应该不参与该项目在纯粹的技术角色，而是像项目经理或产品拥有者，并从测试人员和开发人员把你输入更多的业务/管理的导向作用。

— 巴特·范·恩根·舍瑙
source

1

我之所以投反对票，是因为我从根本上不同意您所做的几点和假设。我不同意质量检查人员无权否决发布，因为许多质量检查人员小组也以用户接受角色工作。此外，我不同意测试人员是技术人员的假设。并非总是如此，并非每个发布软件的团队都能负担得起完整的质量检查团队，因此，该角色可能落在业务分析人员身上，而这些人员可能根本不是技术人员。

— maple_shaft

1

除了maple_shaft的观点外，我经常看到最后一个求助对象是客户角色的所有人，除非发现了可怕的问题。最终它们是可交付的，并且假设您向他们提供了准确的信息，则他们最有可能对风险有正确的观点。

— Bill

5

“发布”或“不发布”的决定是在业务决策的最后一天，在此需要进行严格的风险/回报分析。

任何组织要求测试团队承担此责任，或者测试团队同意此责任，这都是疯狂的。

测试团队的作用是提供对软件质量，软件准备发布以及确定为发布或不发布业务决策的输入的任何风险的分析。

正如其他人指出的那样，某人（我相信是个人）确实需要做出“释放”或“不释放”决定的权限。同一个人可以在特定条件下委托该决定（即没有P1或P2错误）

— 约旦
source

3

我曾遇到过这样的情况，即测试人员过度接触并发明了更具创造性的方法来破坏系统，而当评估风险时，这种系统在生产中几乎不可能发生。

我理解并赞扬测试团队不希望发布不完善的版本，但确实需要强大的产品所有权来定义什么是“可接受的风险”。

以我的经验，测试团队应获得否决软件发布权的否决权，但产品拥有者应否决该否决权，但必须与首席测试人员讨论后才可否决。

软件将永远不会是完美的，如果您正遭受测试蠕变的困扰，那么您将永远不会发布任何东西，直到出现重大生产问题（无法正确测试）并赶出市场。

— 麦可
source

1

那是一个真正的问题，但是我不确定这是否一定是OP的问题。我的解释是，测试人员以某种方式正在解释最初未定义的新要求。

— maple_shaft

2

我在测试团队中的经验使我陷入了另一方面。对我来说，质量检查人员不应期望能够阻止部署而不会向团队其他成员提出要求，也不会期望所有者取代团队。

— Bill

1

没错-我可能还不够明确，测试人员提出缺陷时也会发生相同的问题，而我引用“引人入胜的故事”，引出相同的问题-从未发布过。

— 迈克尔

就我而言，更多是@maple_shaft的解释；在报告无法处理明显不受支持的情况时报告失败，而不是在寻找破解软件的方法时表现出vious回。

— 欧内斯特·弗里德曼·希尔

1

@ ErnestFriedman-Hill听起来您正在描述负面需求，而这些正是您的功能需求文档所缺少的。否定要求是关于系统将不执行的操作的明确声明，可以像常规要求一样接受。如果声明了这些，则它们针对否定要求的测试用例将无效。

— maple_shaft