今天，世界庆祝着测试者的一天。 在这种情况下，我们决定帮助您从不同的角度看待这些专家的工作，以便合作将为所有参与者带来最大的利益和最小的压力。
图片来源： David Goehring CC BY
1.“再次仔细检查，绝对没有错误”
让我们从根本问题开始。 Ars Technica论坛有一个古老的话题 ，一个开发人员在其中谈论对“学究”测试人员的深恶痛绝。 他非常恼火，一些测试专家花了数小时来寻找最微小的错误。 最令人不快的是，他们仍然找到了它们。
可能出问题的地方 ：并非每个人都愿意承认自己的错误。 有人唱了一首关于“不是错误，而是功能”的老歌，试图证明一切都是预期的。 其他人则坚持要求仔细检查代码，并确保没有错误。 测试人员只是试图做好自己的工作，而不是出于感激之情，而是将他送去重新检查。
怎么做 ：很简单：如果测试人员发现您的代码中存在缺陷，并且您知道他是对的，那么最好承认这一事实。 你们两个都有一个相同的目标-发布经过调试且可以正常工作的产品。 幽默有助于对这个问题的理解。 这是一篇文章 ，其中测试人员将试图保护其代码的开发人员的陈述汇总在一起。 我们建议您仔细阅读它们，并从测试人员的角度想象这些“经典”短语的发音。
2.“发布前一周。 希望您在接下来的两天没有计划其他事情。”
有时，代码会在发布前几天提交给测试人员。 然后，他们必须匆忙工作。 一些质量检查专家认为 ，同事只是低估了他们的工作。 据称，他们认为查找错误既容易又快速，因此他们在最后一刻推迟了调试。
可能出了什么问题 ：在紧急情况下，测试人员不仅会感到烦恼，而且会失去警惕。 缺乏时间是测试人员跳过错误的主要原因之一 。
如何成为 ：有几种开发模型。 从质量检查的角度来看，主要有两种方法：级联和敏捷。 在第一种情况下，测试人员分阶段接收代码片段。 在第二种情况下，他们在编写代码的同时对其进行测试。
敏捷有助于使质量保证专业人员尽早参与该项目。 因此，您不必“在发布前一个小时”进行测试。 另外，这种方法不允许查找错误，而是防止错误的发生。 如果您的测试人员抱怨持续的时间压力和错误遗漏，请查看此方法。
照片： Tim Regan CC BY
3.“我迅速调整了代码。 看，请。”
假设您的团队使用级联模型，并且知道如何正确规划开发阶段。 测试人员可以获取代码，并且似乎有足够的时间进行调试。 但是开发人员有一个习惯，就是在此阶段尽力而为。 他们会收到详细的错误报告，对其进行肤浅的阅读，迅速消除明显的错误，并将代码发送到下一个测试周期。
可能出问题的地方 ：问题在于，表面更改后的代码通常会返回甚至更多的错误。 测试人员花了一些时间准备一份详细的报告，并对此做出了回应。 他不得不多次这样做，只是因为开发人员不想将时间花在“小错误”上。
怎么做 ：显然，不要着急。 但这还不够。 您需要弄清楚为什么您没有对报告给予应有的关注。 如果这是平庸的懒惰，则只有您可以自助。 还有其他原因。 例如，您认为质量检查工程师向您泛滥了一些无关紧要的错误报告。 然后，您需要在领导层上澄清这个问题-测试人员应该“分散细节”的注意力。 答案很可能是肯定的。 一些产品经理甚至要求开发人员在代码中专门添加一些小错误，以便测试人员始终处于警惕状态。 重要的是，采用这种方法并适当注意处理错误报告。
4.“看来我已经解决了这个错误。 但是我不记得确切了”
有时，表面的方法是一个系统性的问题。 在某些团队中，错误报告会浪费时间和空间。 没有人对报告做出适当的回应，没有标记问题是否已解决或仍然处于困境。
可能会出问题的地方 ：开发人员修复了某种错误，对代码进行了“较小的”更改，忘记了通知测试人员，然后将代码发送到了发行版。 结果，该问题在为时已晚时弹出。 测试人员通常是“极端”人员。
怎么做 ：混乱的问题需要系统地解决。 混乱会损害发展，因此您必须完全重组团队中的沟通流程。 在这里值得使用在开发人员和质量检查工程师之间建立通信的基本技巧：确定术语；确定术语。 明确提出要求； 介绍各种错误的优先级层次结构。 对于与错误的混淆，有一些很好的实用技巧：a）让错误报告所有内容； b）那么优先考虑它们是很重要的； c）任何封闭的错误都意味着将编写功能测试； d）状态“已解决”不是由开发人员分配的，而是由测试人员分配的。 这种方法可确保问题得到真正解决。
照片： Tim Regan CC BY
5.“我为什么要测试这个？ 我不是测试员！”
在某些团队中，调试责任完全由测试人员承担。 开发人员不必花时间在最明显的单元测试上。 他们确信这不是他们的工作。 总的来说，尽管对此问题存在不同的观点（可以在此处找到社区的观点）。
可能出问题的地方 ：在这种情况下，测试人员必须连续处理所有缺点-即使存在最原始和最愚蠢的错误。 当然，这很烦人。
怎么做 ：许多开发人员在将独立测试发送到QA部门之前，都喜欢进行独立测试。 这不仅有助于减轻测试人员的负担，而且还有助于从批评家和用户的角度学习如何看待产品。 相信这对专业人员有用，并且对最终结果具有最佳效果。 对于那些不想麻烦检查的人，有自动工具。 他们帮助发现最明显的错误。 无论如何，即使团队中有质量检查工程师，将开发人员和质量检查严格分开也不是最好的方法。
6.“伊戈尔，今天您与奥列格一起工作。 你会喜欢的
产品经理不仅限于层叠方法和敏捷方法。 他们中有些人喜欢尝试。 例如，安排配对编程和测试会话。
可能出了什么问题 ：这是捕获错误的有效方法，但也有缺点-人们可能对创新并不热心。 习惯于独自在另一层楼和设备上工作的QA专家可能会感到不舒服，离开熟悉的环境。 此外，他可能不会对搭档的经验和知识tri之以鼻。 结果，产品经理没有进行有效的测试，而是得到了两名不满意的员工。
怎么做 ：主要建议是不要割断肩膀。 敏捷和DevOps的实践似乎很有吸引力，但是如果没有适当的准备，它们将无法工作。
7.“我会带您的设备进行测试，您介意吗？”
开发人员有时间开始调试，他要求测试人员“从字面上看20分钟”购买一个测试设备，然后将其放置很长时间。
可能出了什么问题 ：大多数情况下，开发人员根本不会将设备放回原处，如果确实如此，则设备会完全放电。 考虑到测试人员可以在此设备上执行并行任务，所以这很烦人。
怎么做 ： 给自己起提醒作用，贴上贴纸，做任何事情，但是请按时将测试人员的东西归还他们。
照片： Dave Allen CC BY
以及对开发人员和产品经理的主要建议，这些建议与以前的建议一样：尊重他人的工作和时间，并尽可能使自己代替测试人员。 毕竟，即使不是他，整个世界也会知道您的错误。