开发人员如何改善与测试人员的关系？

#1 楼

好又有趣的问题。

以下是使测试人员的工作更轻松的一些方法：


开发人员应该在将产品提供给测试人员之前执行基本测试。
包括来自QA的质量检查项目的开始，而不是产品准备就绪时。
作为团队而不是作为两个不同的部门[Developer＆QA]
作为开发人员，切勿要求QA忽略bug。质量检查人员的工作是验证错误是否已解决。
如果对产品没有清晰的了解，请支持质量检查人员。
努力实现制造固体产品的共同目标。不要以为您是开发人员，而他们却是测试人员。

#2 楼

平等对待它们。

我看到许多开发人员认为它们比公司中的测试人员更好或更出色，并且也采用这种方式。开发人员和测试人员的目标相似：制作高质量的软件。

#3 楼

只需几个简单的操作即可：


在将其标记为“完成”之前，在计算机上运行至少完成一次的代码。与质量检查人员一起按照预期的方式实施功能或错误修复，以帮助在甚至只编写一行代码之前就清除潜在的问题或错误。
鼓励质量检查人员参加Sprint计划/整理，设计和其他相关会议。质量检查通常对整个系统和最终用户有更广泛的了解，这可以在早期计划阶段提供帮助。
不要将质量检查视为“敌人”，而应将其视为防止错误产生费用的安全网。从生产到生产的公司$$$

#4 楼

我已经在这两个职位上工作了一段时间，我的建议是：


（在可能的编码之前）对测试计划进行配对
将质量检查视为保护您的资产以及客户从我们都会犯的错误中
质量保证接近时要保持开放的态度，并避免由于缺乏理解而无法解释问题的（常见）错误
不要以为他们可以通过编码变化很快。例如，不要在2个星期内进行更改，然后假设质量检查会在2小时内通过。
当您将票证交给质量检查人员时，请勿假设票证已基本完成，请向其他人开放代码更改的方式与您进行代码审核的方式相同
考虑组织的工作方式。与开发人员：质量保证人员比率为2：1相比，开发人员：质量保证比率为10：1，这意味着不同的角色。
志愿者可以帮助测试人员解决环境或设置问题，以便他们进行测试。
在执行工程任务时尽可能地将测试人员视为工程师，并尽可能/切实地将技术测试人员（编写测试代码）视为质量工程师。质量检查倾向于对很多人“手动”进行手动测试，并且与入门级/实习/合作社手动测试相关联，因为QE表示技术角色更重要
邀请他们参加有不同意见或该功能位于著名的问题区域中，以获取他们的投入。
鼓励QE测试人员学习更多有关该代码的信息。
公开重视他们的作用，例如“好吧，我认为我做对了，但让我们看看量化宽松首先想到的是什么。”
感谢他们的发现，例如“好吧，我正在研究票务1234，因为幸运的是，质量检查人员发现Firefox中的匿名帖子未更新数据库的问题”，我们都一直试图从这些日志错误中进行跟踪。
质量检查人员及其支持的开发人员。
在团队活动中包括QE，例如：入职，午餐，计划会议，出发午餐，票务梳理，回顾等。
共享一个公共Wiki，记录设置知识
共享用于的工具和技术调试代码
确保其环境与您的环境相同，以便发现的错误不仅是由于环境差异造成的。
使用“三个朋友”方法来帮助将质量检查，产品和开发人员整合进行合作。
对他们可能代表的不同观点持开放态度。好的测试人员会想到许多不同的用户角色，例如快乐，悲伤，生气，健忘，分心的用户。
谦虚并公开感谢测试人员的发现（而不是默默地修复它们）。

有些组织也需要为其开发人员与开发人员之间的关系推广这一功能！

#5 楼

这很简单，但是很有效：

做一个说“谢谢”或“好收获”的开发人员！或每当测试人员发现缺陷时都是肯定的东西。

这是尊重工作关系的日常用语。所有形式上的过程都是好的，但它们来自尊重的基本态度。

#6 楼

要开始，对测试人员的活动和发现的问题持积极态度
将单元+经过开发抽烟的版本提供给质量检查人员
分享发行说明，包括修复，功能和已知错误等信息
提供对系统的技术和后端了解的支持
为分析难以重现的问题提供支持

对测试人员/质量检查人员的工作表示赞赏，并且可以独立工作单位

最后但并非最不重要的一点是，遵循所有最佳实践/质量保证流程，例如共享发行说明，避免频繁的临时构建，进行正确的版本控制，标记错误状态等。

#7 楼

到目前为止，所有答案都很好。

其他一些评论：


请记住，测试人员不在那儿使您的生活痛苦不堪。他们在那里为业务涉众提供有关该软件如何满足其预期用户需求的信息。他们可能会，但是他们宁愿寻找边缘情况，因为您发送给他们的代码在钢螺纹中坚如磐石。
告知您已进行的测试以及您所关注的所有领域。测试人员并不总是了解内部原理，因此他们可能不知道需要对其进行测试。不会因此而生气。他们不是在玩“陷阱”，他们只是想让软件尽可能的好，他们正在努力为您提供帮助（是的，这发生在我身上。您不想成为那个开发人员）。
始终记住，您和测试人员的目标是相同的：生产客户想要使用的优质软件。

我敢肯定，这里至少存在一个问题，它考虑了哪些软件测试人员可以赢得了开发人员的心：我只是还没有发现它。

#8 楼

这里有所有优点，但是我经常会遇到一些QA问题，那就是要记住，尽管我可能对产品相当了解，但我根本不了解代码。被问到代码的哪一部分有问题通常令人沮丧。如果我发现狗拿棍子有问题，我不知道是狗类还是棍类。据我所知，这可能是棍子实现的可获取接口中的问题。 （我可能会对球对象进行一些测试，这些对象也实现了至少可以排除stick类的可获取对象）

另外，当您找到并解决问题时，我将需要知道它是否与狗类，stick类或fetchables接口，以便除了测试bug之外，我还可以进行回归测试以查看该修复程序是否破坏了其他任何东西（遗憾的是，这是我需要不断征求我的开发人员的想法）

#9 楼

尊重质量保证的时间要求

经常，测试时间成为项目缓冲时间。如果候选发布时间晚了一天，您是否更改发布日期还是告诉质量检查人员进行更快的测试或进行更少的测试？拖延。

尽管延迟发布候选者，但如果测试人员快速有效地运行测试，则应给予测试人员认可（例如奖金，晋升等）。 （作为一个旁注，请不要给他们大量的错误报告。）

告诉他们您的单元测试涵盖什么以及如何进行

质量检查人员进行审核您的单元测试并查看了最新的协议，它们可以避免重复工作（除非有明确的决定要仔细检查）。测试人员可以将精力集中在自动化测试不太可能捕获的事物上。开发人员想要使事情正常进行的失败。让他们编写大多数测试用例，并在编写第一行代码之前向开发人员展示它们。 （测试驱动开发，TDD）

我曾经在一个项目中，一个测试人员拒绝该规范为越野车。测试人员是正确的，规范与先前的要求不一致。两者的原因。如果项目是瀑布式的，并且合规性文档很重要，则将质量保证体系作为一个单独的团队，使其团队领导与开发团队的领导处于同一水平。如果项目是敏捷的，而测试的文档不太重要，则将测试人员纳入开发团队。如果使用scrum，请将通过的测试写到done的定义中。直到测试完成，故事还没有结束。

在最极端的情况下，这可能意味着取消测试人员。每个开发人员都要对质量负责。

#10 楼

我阅读了软件测试人员的测试用例，并给了他们反馈。我确保您仅通过阅读代码而知道的每个工作流路径都被覆盖或至少引起了他们的注意。我还使用我自己的功能使它们保持最新，这些功能我可能在会议或UX规范（通常是小型填充程序）中并未真正涵盖。

#11 楼

我个人认为，应该在开发方面和质量检查方面的两个方向上改善这种关系。从我年轻的经验来看，我是团队中唯一的质量检查人员，并且与开发人员的关系很好，我从未与团队中的任何成员经历过戏剧化或任何形式的抱怨。

我认为这是由于我们认为自己是平等的，也是因为开发人员认为我是帮助而不是约束，也不是有人在骚扰他们。

因此，我认为与QA / Dev建立良好关系的几点考虑：


开发人员必须接受QA测试人员在这里提供帮助和它们不是约束，这里可以帮助他们改进代码或对产品的看法
质量保证必须接受开发人员可能会犯错误和创建错误，因此他们必须在开发环境中解释问题。详细而正确的方法。不必对某人生气。如果解决方案有误，则可能是因为场景或预期的行为没有得到详细说明。
此外，质量保证和开发人员必须在同一区域而不是在不同的办公室一起工作，这一点非常重要（在可能的情况下，我个人必须与远程开发人员打交道）。
个人风格：恭喜。这听起来很愚蠢，但是每次我关闭票时，我都会对开发人员表示敬意，因为他做得很好，他们会感谢您，因为您重视他们的工作。小的Good job并不会花费很多，但它可能是有效的。