我的经理想要在质量检查环境中进行回归测试-如何与之进行沟通？ [关闭]

#1 楼

我认为这不是一个好主意，因为在完成集成和完整性测试之后再进行系统测试，然后再执行回归测试。不行，这不一定是一个坏主意。 />
不要仅仅根据测试的顺序将其视为一个坏主意。

按定义：回归测试是一种软件测试，它可以验证先前开发和测试的软件在更改或与其他软件接口后仍然可以正确运行。

回归测试通过增加您对软件质量的信心来提供业务价值，这是值得做的。

请考虑以下情形：


在进行集成测试之前，开发人员修复了损坏的功能，并希望确保该功能能够按预期运行，并且新功能不会对其他功能造成负面影响；回归测试是您的答案。

#2 楼

我的建议：

不要通过电子邮件传达您的异议

安排时间与您的经理见面并与他们进行交谈。

电子邮件不能很好地用于这种交流，因为不清楚所有重要的“基调”是什么，并且一次也只能单向通，对于困难的对话来说效果不佳。

经理还可能期望对话主要是关于学习他/她做出给定决策的原因和理由，而不是决策本身是否正确。毕竟，您应该期望经理会使用他们的智慧和经验来指导您。如果讨论和您的问题以及您带给对话的任何其他信息显示出错误的决定，则可以在讨论过程中一起发现该错误。

#3 楼

张瑜说得很好。
我只想加两分钱来弥补它的另一个方面。
即使我们认为经理的建议是错误的。在做出反应之前，最好花一些时间考虑一下建议，并提出遵循说明的所有优点和缺点。除此之外，我们还应该与朋友和同事讨论我们的想法，以得到他们对指导的看法（您可以通过在此论坛上进行讨论正确完成）。富有成果的话，那么我们需要谨慎对待选择回应经理（或成为任何人）的措辞。
最后，我们需要确保每个人都有动力。如果我们的回复使某人士气低落，那不好，因为经理也可能会犯一个错误。与经理进行一对一（面对面）讨论。通常，我会开始以某种方式分享我对建议的想法，就像我想获得更多有关该建议的信息。
在这种情况下，如何始终获得积极的结果？开始这样的对话，不要像讨论一个非常大的问题那样开始。只是开始就好像这是您要讨论的另一件事。在这样的对话中，我总是有积极的结果。我指的是积极的结果，有时我的经理会阐明我所缺少的方面，有时我会谈到他所错过的某些方面。因此，我要么说服了他，要么说服了。
这样的对话怎么会朝错误的方向发展？
根据我过去10到12年的经验，如果我们的目的是了解另一个人的观点或分享我们的观点，我认为这些问题更容易解决。当对话围绕“谁错了？”而展开时，这种问题就变得很糟糕。然后开始自我问题，等等。

#4 楼

通过概述您可以预见的是否按照经理的建议进行测试的特定问题，您听起来会很专业。我可以想象几个这样的问题：


回归测试需要执行大量的工作，而在完全集成之前运行它们会浪费这种工作。完整的软件并在“进行中”版本上运行会触发过多的误报

您还没有任何回归测试，现在设计这些测试将使团队脱离工作任务您认为应该优先考虑


还有其他一些我无法想象的原因，但是这些可能仍然是有效的。如果您认为它们足够严重，请不要犹豫，将其传达给您的经理。如果您唯一的反对意见是此类测试是“非正统的”，或者不应将它们称为“回归测试”，那么我相信您应该重新考虑自己的立场。

#5 楼

正如我直接说的，拒绝在质量检查环境中进行回归不是一个好主意。您应该问他/她这样的问题：


为什么他要您专门在QA环境中进行回归？
他对回归测试的实际含义是什么？
客户或最终用户是否发现了错误？

这些问题的答案将帮助您阅读经理的思想，并基于此可以进行有益的讨论，并指出要点，不建议这样做质量检查环境的回归。

除了争论，您还可以提供一些证据，证明在质量保证环境中执行回归套件不值得。

#6 楼

随着产品的成熟，回归测试套件将花费越来越多的时间来运行，但很少会报告失败，因此将其从正常开发周期中转移到自动化集成测试中非常有意义。 />测试自动化的责任在于测试团队，因此在开发人员确认错误已消失之后，应将回归测试移交给他们。

运行没有意义。一个长达数小时的测试套件，可验证所有长时间关闭的错误在每次提交之前均已消失。相反，足够运行与在提交之前已修改的功能部件组关联的测试，并在一夜之间运行所有其他测试。与每年在每次提交上花费的额外时间相比，每年一次的夜间构建一次或两次捕获回归（这意味着开发人员应在前一个构建基础上进行第二天的工作）造成的额外工作量微不足道。