软件测试员应该怎么做才能变得对开发团队更有价值和更有帮助？

#1 楼

从这个角度考虑测试人员的角色对您来说非常令人钦佩。

严峻的事实：


当他们的代码中发现错误时，没有人高兴。想象自己是一名开发人员，您已经完成编码，已经完成单元测试，并且在签入代码时感觉很好。当有人在代码发布前不久出现并告诉您您的工作还不够好时，您会有什么感觉。
开发人员采取防御措施是常见的反应；防御心态有两个表现形式：1，不是虫子； 2，测试员本可以早点告诉我的。

测试人员如何处理这种情况？

您提到在代码发布和/或代码冻结之前不久发现了错误，因此您的开发变得非常关注。


这是不可避免的；您无法完全控制发现错误的时间。在冻结代码或将其标记为可以发布之前，请教您吗？在冻结代码或将代码标记为可以发布之前，应咨询测试人员。如果未咨询您，则应提出更改建议。是的，在某些文化或某些公司中，无法更改它。 （您的发布管理可能没有很好的组织，但是没有进一步的细节，这只是我的推测。）

您提到您的开发团队并不欣赏您在测试时的效率发现了相同错误的新症状。


可能是其他错误，也可能是部分已修复的同一错误。如果这是一个新错误，那么找到它就是您的功劳，您做到了。如果像开发人员所声称的那样，只部分被发现并因此被部分修复的同一bug，并不表示您做得还不错。请记住，不可能发现所有错误。每个人都想念的东西。解决方案是改善与开发人员的沟通方式。
指出他们的代码中存在错误的一种有效方法是将这个坏消息夹在两个好消息中。例如，发现错误时；立即与您的开发人员联系，并开始谈话，说：我喜欢您的代码，它的工作精美。当您的开发人员不处于防御模式时，请找出错误；然后称赞一下，结束这次谈话。随着时间的推移，开发人员不会将您视为他们的致命敌人，而是一个帮助者。

我想澄清一个问题：



当我写详细的缺陷描述或错误报告时，我团队的开发经理感到很满意....，您直接将错误报告发送给谁？拥有这段代码的开发人员还是您的经理？我见过一些经理，他们在质量保证和开发之间造成不必要的延迟和误解。理想情况下，应该将错误报告直接发送给其开发人员，当然，在某些公司中，经理们希望首先阅读它们，以便他们可以进行优先级排序等。

#2 楼

为了使测试人员变得更有价值，并且对开发团队有所帮助...
专注于在开发过程中尽早帮助开发人员
专注于在过程中尽早增加价值。在代码编写之前和编写过程中，而不是在测试/登台环境中部署代码之后，应集中精力与开发人员合作。这将有助于您将角色从批评家转变为助手。
实现这一转变的实用方法：

参加冲刺计划会议并在会议中就质量问题提供意见目标受众使用的各种浏览器和移动设备，以便QE或开发人员可以根据需要使用它们。寻找拥有票证的开发人员，并要求与他们配对。
请确保您拥有管理支持，以便在开发人员早期与开发人员合作。通常，这意味着您要向开发总监报告，并得到开发总监的支持，而不仅仅是首席程序员，架构师或编程团队的负责人。 >请在正式代码Pull Request发布之前，而不是在发布之后提供意见。
继续发展您的实践技术技能。如果您具备以下能力，将会得到开发人员的更多尊重：

搜索和解析服务器日志
执行SQL查询
浏览并理解源代码/>
继续在编程原理中发展技术知识
质量工程原理
用户体验，可用性和可访问性
设计原理



我是一名前开发人员，以上内容反映了我的经验。
一旦我终于完成了代码，就会听到质量检查的声音，这很烦人。让他们通过测试计划，或当场推出移动设备或IE浏览器以检查仍在进行中的开发是有帮助的，受到我的欢迎。

#3 楼

所以，首先，我认为您遇到管理问题。在某种程度上，这听起来像是一种“我们反对他们”的哲学，其中测试被视为发布的障碍，而不是开发过程的组成部分。以我的经验，一个好的开发人员完全意识到他们是人，会犯错误。他们知道测试是为了保护最终用户，开发人员和测试人员对整体工作同样重要。需要考虑的问题包括组织中的测试人员是否有晋升的途径？还是将测试视为开发的一种方式？如果没有一种方法可以使测试人员成为高级测试人员，并且对开发过程的影响力不如首席开发人员，那么这可能就是一个问题。如果开发人员在报告缺陷时变得防御起来，那就是一个问题。如果没有管理层的帮助，这不一定可以解决。例如，如果评估开发人员的代码中发现了多少缺陷，那么这就是解决有争议关系的秘诀。

第二，由于您是黑盒测试员，有机会比任何开发人员都更好地了解整个系统。一般来说，开发人员对自己的专业知识非常了解，但是他们不了解自己的技术如何与其他所有事物或周围的基础架构一起工作。建筑师通常也是如此。您有机会成为这方面的专家，并且是最终用户的真正拥护者。

第三，就像开发人员并不完美一样，测试人员也不是完美的。这就是为什么您不应该仅测试代码的原因。您的工作以及其他所有人的工作都应该改善流程，以使缺陷很少出现在代码中，而更有可能在发现缺陷时发现。有时，这意味着编写代码以便于测试。瀑布式与敏捷式之间的关系是无关紧要的。重要的是您寻找可以改进流程的位置，并且可以尽早发现缺陷。以您的错误重新发现为例，为什么开发人员没有在您第一次报告该错误之后就拥有可检测到该错误的单元测试用例？或者，如果您发现了更大问题的征兆，他们为什么不意识到问题大于实际问题呢？您不是唯一负责软件质量的人。

最后，找到并报告错误（即使是在周期的后期）比找不到错误要好得多。您是否愿意在现场找到它？请注意，这并不意味着有时（通常）不建议将错误修复到下一个版本，而是应该在了解了缺陷的影响以及被击中的可能性之后才做出决定。如果它是一个严重的错误，那么您应该弄清楚为什么以前找不到它。是因为还有许多其他错误阻碍了查找此错误？引入该错误是为了解决另一个问题吗？也许让更多的人进行测试会更早地发现错误。

#4 楼

从开发人员的角度来看，

我是一名自由开发人员，因此我使用许多不同的质量检查设置。从一个人测试所有内容到完整的团队检查其他人的工作。我通常是唯一的开发人员，或者是处于“管理”类型的职位（Dev经理，Lead Dev等）。我只提到那一点，因为知道我在“岛的哪一边”很重要。

首先，最重要的质量检查起着至关重要的作用。我可以编写出色的代码。但是我只能编写代码以了解我要解决的问题。如果质量检查只做其他事情，然后提供不同的心态，则它们的价值已经是天文数字。



了解您不是要释放的障碍，而是沿着道路前进的一步。我已经看到很多次质量检查“人员”被权力淹没，并由于错误或问题“阻止”发布，这已经太多次了。有时会发生这种情况，但更多的时候不是关于确定问题然后阻止发布。特别是在发行周期短的情况下，列出“已知问题”通常会好于没有新功能。

请记住，您是支持角色。毫无疑问，该程序对您有好处，但是您在那里可以帮助该程序变得更好。很多时候，质量检查人员会感觉到自己是王国钥匙的保管人。质量检查人员觉得如果发现更多问题，他们的工作就会做得更好。这导致他们开始发现各种废话。我收到了一些错误报告，说“地址导入”不起作用，因为用户无法上传JPG。我还看到质量检查人员为每一个逗号丢失的文本提交了一个小小的错误。

学习使用问题跟踪程序希望与您一起工作的开发团队正在使用某种问题跟踪系统。我经常看到质量检查人员没有搜索系统并多次列出同一问题，或者将问题放在明显错误的位置（例如，桌面应用类别中的网站问题）。正确使用问题跟踪器会很有帮助。

及早报告问题让我们举一个假的例子。星期一和星期二我编写新代码，星期三和星期四专门进行清理和维护。星期五开始生产。不要等到星期四晚上将600个问题转入问题跟踪器（甚至1个），为时已晚。相反，当我周一编写代码时，您应该对其进行测试。您星期四的任务应该（在完美的世界中）“是固定的”。如果您确实在星期四发现问题，则当然需要提出这些问题，但是目标是要解决问题而不是发现新问题。

报告问题时要冗长，据我所知，没有开发人员会因为拥有太多信息而生气。告诉我们问题，到达那里的工作，版本，分支，错误消息，屏幕快照，堆栈跟踪（如果有）以及预期的输出。至少您应该能够说：“当我执行X时，Y应该发生，而Z发生。”我看到质量检查人员多次“不起作用”或“我遇到错误”。但这还不足以让我做任何事情。错误应该在那里。因此，这是一个好错误还是一个坏错误。

知道程序和路径很多时候，QA People会提交一个“ bug”，因为在发布的整个过程中，只要更改了功能，功能就会更改。例如，如果我们说我们要限制上传2兆。然后，质量检查人员需要知道这一更改，并且在5 Meg文件上传失败并出现适当的错误时，不要提交错误。您还需要注意次要更改。在“支持国际电话号码”的新功能之后，我将看到大量报告，例如“电话号码导致验证错误”。尝试了解对应用程序所做更改的原因和结果。

在适当的时间询问问题。您可以做的最糟糕的事情之一就是走向开发人员，然后“应该这样做吗？”。您可以做的最好的事情之一就是发送电子邮件或进行聊天，询问完全相同的问题。

支持您的开发团队很多时候，质量保证人员说的话使他们成为开发人员的敌人。他们并不是真的要这么做，但是他们都是一样的。 “我正在等待开发人员解决地址上传问题。”那很糟。 “我们仍在通过地址上传解决问题。”那很好。只要您说出使问题成为“开发人员的过错”的东西，就会自然而然地证明事实并非如此。相反，如果您采取团队合作的方式，那么开发人员就不会“必须”“将您扔到公车上”来清除他们的名字。这是一个出路的问题。也许地址问题是您尝试上传XLS而不是CSV。最好获得一张标有“不支持XLS格式，请尝试导入CSV”的票证，然后让电子邮件链回复“质量检查未正确测试该功能。该功能是CSV导入，他们正在使用XLS。这些不是同一回事。“

将自己视为大团队的一部分很多时候，质量检查人员倾向于将自己视为裁判。没有。如果说dev是进攻线，那么QA是防守线，他们有不同的目标，但是SAME的所有部分都更大。

#5 楼

觉得您在测试过程中为时已晚。专注于防止缺陷和与编码并行进行测试。

我喜欢测试宣言的说法：太宽泛，无法在此处回答。

更新：

瀑布还是不瀑布，您仍然可以应用大多数想法。让我们预防错误。您可以问他们如何解决此问题，而不是与开发人员打乒乓球？更好的测试不是问题，因为它们可能会因更改而破坏其他功能。意味着您将继续回来，这就是问题所在，您不断在他们创建的代码中发现问题。


我坚信，成为一名优秀的软件开发人员的一部分是成为一名优秀的测试人员。

-John Sonmez


开发人员制造缺陷而不是测试人员。我认为您应该教会开发人员成为更好的测试人员，以便您可以专注于全局而不是细节。

#6 楼

从帮助您在发现和报告错误时与顽固/脾气暴躁的开发人员打交道的角度来看，到目前为止，大多数答案似乎都在解决此问题。许多人（正确！）指出，质量保证/测试人员所做的工作对于项目的成功至关重要，即使您在发布周期的后期发现问题，您也不应该为提出问题感到难过。 br />
从开发人员的角度来看，我还要补充几点。我已经与许多测试人员一起工作，并且我无法强调多少开发人员对提交良好缺陷报告的测试人员表示赞赏。对我而言，可以做出良好缺陷报告的事情有：


重现问题的分步指南
显示缺陷行为的屏幕截图，尤其是对于Web应用程序
预期的行为
实际行为
您用来产生不良行为的任何特定数据
您正在使用的软件/浏览器/版本的版本

与其他所有人一样，开发人员最终希望他们所构建的产品很棒且很棒，尽管发现错误后它肯定会影响自我，但是报告错误显然对每个人都有利。话虽这么说，但是如果提交的缺陷报告没有足够的数据来重现该问题，那么它会给涉及的每个人带来大量的额外工作。测试人员在我的代码中发现错误，但是当这些测试人员使我尽可能轻松地解决问题时，一切都会很快得到原谅。

#7 楼

除了其他答案外，

测试工程师必须保持坚强的个性，以便在任何时候都可以引入新的错误，因为开发人员和测试人员都知道，开发或测试无法做到这一点。宣布完成显然！就像没有开发人员立即编写完美的工作代码一样，没有测试人员可以保证早日捕获所有错误。

在生产之前找到它确实是一个很大的安慰！即使它可能未固定在当前版本中，但现在已成为所有人的已知问题。因此，在最坏的情况下，如果实际用户报告了此问题，则软件团队可以尽快解决此问题或将其声明为“已知”，而不必惊慌！

总是有改善产品质量的空间。如果测试人员坚持自己的观点和观点，那么开发人员或管理人员都无法将他/她这种情况视为未受到赞赏！我们必须通过我们的个性来赚钱！

但是，再次可能的事实是，为了满足严格的期限管理，必须推迟将此错误在下一版本中修复。这个时间测试仪必须足够大。因为抱怨事实并不总是恰当的。对于开发人员和测试人员而言，了解情况并进行相应调整对于构建/维护更好的软件都具有很高的素质！