不知道你们的团队中是否存在这种文化：开发人员不愿进行测试，认为测试与他们无关。最近，就有人在Reddit上提出了这样的一个问题。问题描述如下：
我们公司有一个奇怪的文化，开发人员尽可能快地工作，但不进行任何测试。最终的结果是，开发人员在Sprint的最后一刻还在添加新的故事和修复bug。当然，Sprint结束时会有一些需要测试的内容，但这些内容经常会被推迟到待办事项列表中，因为其他事情被优先考虑了。
另一个问题是开发人员会在Sprint之外做一些事情，我称之为隐藏工作。
我们为每个Sprint团队都配备了专门的质量保证人员，所以开发人员的态度是，测试并不是他们的工作。
我从未在这样一个地方工作过，他们对测试任务抱着与我无关的态度。我们如何才能改变这种心态呢？
针对这一问题，我们一起看下大家是如何回复的（注：以下回复按照点赞数从高到低展示）：
nagemot的回复
这并不奇怪。组织需要考虑如何为发布功能设定团队目标。当每个人都有类似的目标时，每个人都会对完成工作感兴趣。只有当每个人都承担某种形式的责任时，整个团队的质量观才能得以坚持。
kaito1000的回复
开发人员不应该在系统测试中测试自己的内容以关闭测试任务，而应该在开发阶段测试这些内容，以确保它们处于可用状态，以供QA测试。我还发现奇怪的是，开发人员会自行引入他们的故事，难道你们就没有在Sprint阶段会议上讨论哪些故事会被带进来，并在Sprint阶段结束时追溯这些问题吗？
notsofaroff的回复
我们就是这样的，有些时候我都快疯了。开发人员几乎要花费整个Sprint阶段来完成一个故事。然后，我花了 5 分钟就发现了一个 bug。
我就是不明白，什么有人能够将有问题的东西推给 PR。检查自己写的代码是否能正常运行，难道不是最基本的要求吗？我试图帮助他们……提供postman 集合、专门用于开发环境测试的 Jenkins流水线……他们就是不使用。我是一个SDET，负责大约 8 名开发人员，但我只信任2 名开发人员。
抱歉，这变成了一场咆哮。但是，是的，这不仅仅是你一个人会遇到的问题。
Roshi_IsHere的回复
在一个任务没有经过测试之前，不应该将其从任务板上移开。如果发生了这种情况，应该在回顾会议或一对一会议中提出。在Sprint结束时将任务移到测试阶段并不是什么大问题，只需在下一个Sprint里进行测试即可，但在测试任务完成之前不应该被关闭。如果你需要帮助进行测试或自动化，但又跟不上进度，请确保编写代码的开发人员不应该测试他们自己的代码。
GrandHot4386的回复
在讨论解决方案时，我们向开发人员提供单元测试的思路。当代码移交给 QA 时，开发人员必须演示一条成功Case和一条失败Case。如果存在很多问题，则代码会留在开发人员那里。这样可以防止开发人员草率行事。我们有一种文化，鼓励他们如果事情还没有准备好，可以多花一天时间，而不是按时交付带有大量错误的产品。
此外，如果代码在第一天就有重大缺陷，QA 可以拒绝测试。
Achillor22的回复
你不需要这样做。这不是你的工作，这是他们经理的职责。与他们讨论下这件事，因为这需要一个重大的组织变革。但听起来，你们的问题不仅仅是开发人员不写测试这么简单。
但同样，在我工作过的大多数地方，开发人员都不会编写自动化测试，也确实不会进行大量的开发测试。他们只是把测试工作扔给了 QA。
AMonkeyAndALavaLam的回复
我不太相信任何开发人员的测试。他们向我们的QA团队发布的任何东西都要经过测试，就好像之前没有人碰过一样。
Radiant_Addendum7862的回复
有几种方法，有好有坏。这取决于我的心情：
- 收集一份bug列表，保存起来，在Sprint的最后一天转交给开发团队。
- 与你的 PO/经理和团队商定一个测试开发截止日期。如果故事在Sprint截止日期前 x 天还没有完成，就不能再进行测试。
- 不断向管理层强调工作量太大。如果你需要加班，确保你有一些自由时间来补偿。还要强调需要额外人力或推动测试自动化（虽然工作量也更大）。
- 如果在prod中出现 bug，要善加利用。强调问题所在，并强调在有限的时间内你无法深入测试，因此才会在 prod 上出现 bug。
- 倡导单元测试。
ResolveResident118的回复
只是停止测试一切。
如果开发人员不做的测试都由你来承担，那么当他们不做任何测试时，你也不要感到惊讶。
另一个好的方法是优先完成工作。任务在看板上越靠右，完成它的优先级就越高。这意味着一旦团队成员完成了他们的任务，如果有一个处于”准备测试”状态的任务，他们就不能再接手新的工作。
Rectal_Scattergun的回复
总的来说，如果他们完成了太多工作而让你陷入困境，这听起来像是在Sprint开始时的指向和计划方面存在问题。
他们不应该在计划之外处理任务，这需要在回顾会议中进行讨论，与 Scrum Master、你的直接主管以及他们的主管一起解决这个问题。如果有必要，他们需要停止这种做法。这会破坏工作流程和使用到的一些指标。任何任务都不应该被放回到那么靠后的待办列表中。处于测试阶段的任务应该待在那里，直到完成或代码被回退。
当他们这样做时，他们会回退他们的代码吗？你是否将未经测试的代码发送到生产环境中，如果是，那就太荒谬了。
开发人员只负责本地测试任务和单元测试，一旦合并，他们就不应该进行系统集成测试（SIT）或端到端测试（E2E），因为他们不具备考虑所有情况的思维过程和经验。
就像我们不编写代码一样……当然我们可以尝试，但我们可能做的不会很好。
dragodracini的回复
以下是一个有着10年经验的质量保证主管（我）的一些想法。
首先：公平地说，开发人员的工作并不包括除单元测试和预质量保证测试之外的测试。这就是他们的测试责任范围。质量保证团队必须对这些变更进行验证和回归测试。开发人员有责任确保质量保证团队拿到的是有效的代码。
质量保证人员设定了他们可以在发布前完成工作量的规则。我的规则基本上是：如果距离发布时间不到24小时，则有被取消发布的风险。有时，48小时也可能由于反复修改而受到影响。但如果质量保证人员能够自信地完成任务，那就可以发布。
重要的是要将团队视为一个整体。每个人都对质量负有责任。研究如何建立一个质量文化。产品团队通过建立强有力的验收标准、需求、文档来提高质量。工程师们按照规范构建代码，然后质量保证人员确认需求已经得到满足，并且变更在实施中正常运行。大家齐心协力。
你可能需要申请一名额外的质量保证团队成员来处理“溢出的”任务。
团队是否期望你测试所有“额外”的任务？还是积压的工作越来越多？如果是积压，那就让它增长吧。让工程师们知道，积压的工作需要以某种方式进行处理，因此可能需要根据优先级从Sprint中放弃掉一些任务。此外，随着代码变得陈旧，出现问题的可能性越来越大，这意味着它们需要重构，这意味着工程师们需要重新学习他们编写的代码，并找到新的应用方式。我认为这是“墨菲定律”的一部分。
Vegeton的回复
在过去的一家公司里，人们认为开发人员会一直进行测试，直到他们不再这样做，这导致了长时间的构建失败，随后引入了强制性测试。
QA 已经拥有我们自己的构建验证测试 (BVT)，用于批准在全公司范围内推出的构建。他们还为开发人员创建了一个“迷你 BVT”，这是由生产部门和主管部门规定的在提交任何更改之前必须进行的测试。本质上，这是每个开发人员在提交更改之前必须运行的少数测试用例，这些用例可能需要 5-10 分钟的时间来运行，确保核心功能和整体的稳定性。
总结一下—开发人员破坏构建的时间太长，QA 向生产部门提出了这个问题，生产部门批准了 QA 创建的一组强制性测试，生产部门强制要求开发人员进行这些测试。
除此之外，开发人员要么喜欢测试并将其视为工作的一部分，要么认为测试完全是 QA 的工作，这确实是一个难题。根据我的经验，进行测试的开发人员会推出更干净的产品进行测试，从长远来看，这比不进行测试的开发人员更有帮助，因为不进行测试会导致构建更混乱或构建长时间损坏/无法修复（我曾经参与过一个项目，该项目的构建基本上损坏了近两个月）。
stepkar的回复
我曾在一家初创公司工作过，那里的开发人员也是这样工作的。 “我们太忙了”、“但这是你的工作”、“我不会写 bug”等等。
最后，我统计了由于开发人员没有进行基本的冒烟测试，或在前端测试他们的特定代码更改，而浪费了多少时间。真的是很多时间。有数据来支持你的观察确实有所帮助。这样更难被忽视。
Ikeeki的回复
使用持续集成/持续交付（CI/CD），要求进行单元测试，并建立良好的测试文化。
CoughRock的回复
这更像是一个项目管理（PM）的问题，他们没有将修复bug优先于新功能开发。
Strong_Lecture1439的回复
你为什么要让开发人员做测试呢？
看完以上网友的评论， 你是怎么看待这个问题的呢？欢迎留言分享。
