目录
Know What You Are Being Tested On 知道你在测试什么
Test Your Own Stuff First 首先测试你自己的东西
Avoid The Bug/Fix Cycle 避免缺陷/修复周期
What About That One Asshat?那个蠢货怎么办？
翻译内容
It’s a bit humorous and somewhat unexpected, but for many software developers, one of the most difficult parts of their jobs is dealing with QA, quality assurance… yes, those dreaded… testers.
这有点幽默，有些出乎意料，但对于许多软件开发人员来说，他们工作中最困难的部分之一是和QA人员打交道，质量保证......是的，那些可怕的......测试人员。
In a previous chapter, we talked about testing and laid out the basics of what it is and how it’s done.
在前一章中，我们讨论了测试并列出了它的基础知识以及它是如何完成的。
But just because you understand testing doesn’t mean you understand testers.
但仅仅因为您了解测试并不意味着您了解测试人员。
So, that is what this short chapter is about.
所以，这就是这个简短的章节要谈论的。
It’s about you, as a developer and how you can deal with testers and QA in general.
这是关于你，作为开发人员以及如何与测试人员和QA打交道。
QA Is Not The Enemy(QA不是敌人)
It’s important to start out this chapter by letting you in on a little secret… QA is not the enemy.
通过让你了解一个小秘密来开始这一章很重要...... QA不是敌人。
I know it may seem that way. 我知道可能就是这样。
I know things are set up that way. 我知道事情就是这样的。
I mean, here you are making stuff, building features, kicking ass, getting shit done, and there is QA over there picking their noses, making sneering comments, reading the latest post on sticky minds, and—oh yeah—breaking your code.
我的意思是，在这里你正在制作东西，建立功能，踢屁股，搞屁股，并且有QA在那里挑三拣四，发表嘲笑的评论，阅读最新的关于思想的帖子，以及 - 哦，是的 - 破坏你的代码。
But, are they really breaking your code?
但是，他们真的破坏了你的代码吗？
Is it really QA’s fault that the code you wrote has bugs in it and they are trying to find those bugs?
您编写的代码中存在缺陷并且他们正在尝试查找这些缺陷，这真的是QA的错吗？
It’s not. 不是
It’s your fault, or it’s no one’s fault, if you like to be one of those “let’s not blame anyone” type of people. (But it is really your fault.)
这是你的错，或者没有人的错，如果你想成为那些“不要责怪任何人”的人之一。 （但这确实是你的错。）
Anyway, the point is you are actually on the same team.
无论如何，重点是你们实际上是在同一个团队。
You actually have the same end goal: to produce high quality working software.
你们实际上有相同的最终目标：生产高质量的工作软件。
Yes, it can seem at times that you are enemies, because it seems that your goals conflict.
是的，有时你们似乎是敌人，因为你们的目标似乎有冲突。
And I’m not going to say that there aren’t testers who aren’t hell bent on breaking your code and making sure it doesn’t ship.
而且我不是说，没有这样的测试人员，他们不会因为破坏你的代码并确保它没有出发而屈服。
There are plenty of QA people who forget that the goal is to actually create working software, not to prevent any software from ever being released. We’ll get to them a little later.
有很多QA人忘记了工作目标是创建工作软件，而不是阻止任何软件发布。 我们稍后会谈到他们。
But, in general, you have to recognize that it is not you versus them.
但是，一般来说，你必须认识到，你不能与他们形成对立状态。
Because if you start that battle and you make it you versus them, you are going to have a really difficult time trying to do your job.
因为如果你开始那场战斗，并且你与他们形成对立状态，那么你将很难开展自己的工作。
Whatever notions you have of QA being the enemy, get rid of them now.
对于QA是敌人，无论你有什么样的概念，现在就摆脱它们。
It’s not going to help you, it’s only going to hurt you in your software development career.
它不会帮助你，它只会在你的软件开发生涯中伤害你。
Oh, and I’m talking from personal experience on this one.
哦，我正在谈论个人经历。
Trust me, I’ve had many epic battles with testers over the years.
相信我，多年来我与测试人员进行过多次史诗般的战斗。
I’ve even being accused of throwing a chair—utter nonsense.
我甚至被指控扔了一把椅子 - 完全是胡说八道。
Know What You Are Being Tested On 知道你在测试什么
Here is where most QA/developer conflicts start(这是大多数QA /开发人员冲突开始的地方):
“Hey, what the heck, this isn’t a bug.” “嘿，这到底是什么，这不是一个bug。”
“Yes it is, your code doesn’t sort non-alpha characters correctly.” “是的，你的代码没有正确排序非字母字符。”
“It’s not supposed to. That’s not a valid test. The feature works.” “这不应该。 那不是一个有效的测试。 该功能有效。“
“Well, it should. It’s a bug.” “好吧，它应该。 这是一个缺陷。“
“No, it’s not a bug. I’m going to throw this f—- chair at you mother f—-!” “不，这不是一个缺陷。 我要把这个f--椅子扔给你妈妈f--！“
What we have here is a failure to communicate. 我们在这里的是沟通失败。
No, really. That’s all it is. 不完全是。 这就是全部。
Problems like this one can be resolved extremely easily, simply by talking to QA before you write any code and agreeing, together, on what is going to be tested.
像这样的问题可以非常容易地解决，只需在编写任何代码之前与QA交谈并一致同意将要测试的内容。
In that situation, a five-minute conversation could have prevented a perfectly good chair from being destroyed.
在那种情况下，五分钟的谈话可能会阻止一把完美的椅子被摧毁。
If I—ahem, I mean the software developer involved in this “incident”—had talked with this ass—I mean tester—ahead of time, and simply discussed what was going to be tested, then this software developer would know that they should make their code handle sorting non-alpha characters.
如果I-ahem，我的意思是涉及这个“事件”的软件开发人员提前 - 与这个屁股谈话 - 我的意思是测试人员 - 并且只是简单讨论将要测试的内容，然后这个软件开发人员会知道他们应该 让他们的代码处理排序非alpha字符。
Or they could have disputed it before writing the code, before any ego was invested, and the conversation could have been much more civil.
或者他们可能在编写代码之前就已经提出异议，在任何自我投入之前，谈话可能更加和谐。
You wouldn’t take a test in school without knowing what you are going to be tested on first, right?
你不会在不知道你将要考什么的情况下在学校参加考试，对吗？
I mean, I don’t think very many lawyers walk into the bar exam without knowing exactly what is going to be on the test.
我的意思是，我不认为很多律师在不知道考试的具体内容的情况下会参加律师考试。
It’s not like they sit down to take the exam and say, “I have no idea what is going to be on this test, but let’s just hope it’s what I studied.”
这并不像他们坐下来参加考试并说：“我不知道这次考试什么，但我们只是希望会考我已经学习的东西。”
So, don’t write code that is going to be tested without knowing in which way and on what it is going to be tested. Duh.
因此，不要在不知道以何种方式以及将要测试的内容的情况下编写将要被测试的代码。
Test Your Own Stuff First 首先测试你自己的东西
I briefly covered this in the other chapter on testing, but I’m going to mention this again since it’s so important.
我在关于测试的另一章中简要介绍了这一点，但我会再次提到这一点，因为它非常重要。
Test your own stuff first. 首先测试你自己的东西(引申：开发人员自测)
QA is not a babysitter who tests your code for you so that you don’t have to. QA不是为您测试代码的保姆，因此您不必自己测试。
QA is a last defense before your code goes out and wreaks havoc on your customers.
QA是您的代码发布，对您的客户造成严重破坏之前的最后一道防线。
Don’t expect testers to find your bugs, expect them to validate that your code works.
不要指望测试人员找到您的缺陷，期望他们验证您的代码是否有效。
In fact, good testers often call what they do verification, not testing.
事实上，优秀的测试人员经常称他们进行验证，而不是测试。
(Oh, don’t get me started on this. I went to a QA conference one time and I was lectured for hours on the difference between verification and manual testing.)
（哦，不要让我谈论这个。我去过QA会议一次，我在验证和手动测试之间的差异上讲了几个小时。）
Anyway, it’s your responsibility to test your code before you hand it over to QA.
无论如何，在将代码移交给QA之前，您有责任对其进行测试。
When I say this, some software developers get annoyed and ask me, “What is a tester’s job if I have to test my own code anyway? What good are they?”
当我这样说时，一些软件开发人员生气地问我：“如果我必须测试自己的代码，那么测试人员的工作是什么？ 他们有什么用？“
It’s a fair question, and in some organizations testers exist solely to manually run tests, but in general, a tester’s main value is coming up with what should be tested and thinking about all the ways things could break or use cases which haven’t been thought of.
这是一个公平的问题，在一些组织中，测试人员只存在于手动运行测试中，但总的来说，测试人员的主要价值在于提出应该测试什么以及考虑所有可能产生破坏的所有事情，或尚未想到的使用场景。
Think of it this way. 这样想吧。
Anyone can come up with the basic scenarios of how an obvious feature should work.
任何人都可以想出一个明显功能应该如何工作的基本场景。
You should be testing all of those basic, obvious scenarios before you hand your code over to QA.
在将代码交给QA之前，您应该测试所有这些基本的，明显的场景。
But a good tester might try running some of the not-so-obvious scenarios and corner cases which you might not have thought of.
但是一个好的测试人员可能会尝试运行一些你可能没想过的，不那么明显的场景和角落案例。
(Of course, I still recommend that you run even those tests if you’ve talked to QA before you actually write your code and decided on what should be tested.)
（当然，如果您在实际编写代码之前已经与QA交谈并决定应该测试什么，我仍然建议您运行甚至那些测试。）
The point is that the basic use cases, and anything you know is going to be tested, should work.
关键是基本用例和你知道的任何将要测试的东西都应该正常工作。
测试人员永远不应该浪费时间在代码中找您可以很容易发现的缺陷。
Which brings us to the next point. 这将我们带到下一点。
Avoid The Bug/Fix Cycle 避免缺陷/修复周期
The big reason for working with QA in this way has less to do with whose job something is and more to do with increasing the overall efficiency of the team.
以这种方式与QA合作的重要原因与谁的工作关系不大，而与提高团队的整体效率有关。
As much as possible, we want to avoid the cycle of finding bugs, fixing bugs, verifying the bugs are fixed.
尽可能地，我们希望避免发现缺陷，修复缺陷，验证缺陷的循环。
It takes a large amount of time and resources for a bug report to get filed, get assigned to a developer, be reproduced, fixed, sent back to QA, verified to be fixed, and then logged as fixed.
缺陷报告需要花费大量时间和资源才能归档，分配给开发人员，被重现，修复，发回QA，验证，然后记录为已修复。
We want to avoid going through all that time and overhead as much as possible.
我们希望尽可能避免经历所有时间和开销。
That is one of them main reasons you should test your own stuff.
这是你应该测试自己的东西的主要原因之一。
If you find the bug before you even send the code to QA to be tested, you cut most of the steps out of that loop.
如果您在将代码发送到要测试的QA之前发现了该缺陷，则可以从该循环中删除大部分步骤。
But… there is another way to shorten this loop.
但是......还有另一种缩短这种循环的方法。
Try to work directly with QA to fix any bugs as they find them rather than them filing a bug report and going through that whole formal process.
尝试直接和QA合作，来修复他们找到的任何缺陷，不是他们提交缺陷报告并完成整个正式流程。
One simple way to do this is ask the tester who is going to test your code to come over to your desk, run through a few scenarios, and look at what you built before you even check it in.
一种简单的方法是让要测试你代码的测试人员来到您的桌面，运行几个场景，并在检查之前查看您构建的内容。
You could also put the code on a development server or give them some other way to access it.
您还可以将代码放在开发服务器上，或者让他们以其他方式访问它。
Or, if it has already reached QA officially, you can go over to their desk and watch them executing some of the tests. or ask them to let you know if they find anything, so you can figure out if you can do a quick fix for it instead of filing a bug.
或者，如果它已经正式到了QA那里，你可以去他们的办公桌看他们执行一些测试。 或者让他们告诉你他们是否发现任何东西，这样你就可以弄清楚你是否可以快速修复它，而不是归档一个缺陷。
Sometimes, an official bug report needs to be logged, and then it makes sense to track the bugs, prioritize them, and go through that whole process.
有时，需要记录正式的缺陷报告，然后跟踪缺陷，确定优先级并完成整个过程是有意义的。
But, in general, if you can avoid that bug/fix cycle as much as possible, you are going to save the development project quite a bit of time.
但是，一般情况下，如果您可以尽可能地避免缺陷/修复周期，应该尽可能避免，这样您将节省开发项目相当多的时间。
Help With Automation 帮助实现自动化
Most testers are not software developers.
大多数测试人员不是软件开发人员。
Even the ones who know how to write some code probably aren’t as good at writing code and architecting a system as you are.
即使那些知道如何编写代码的人，也可能不像你那样擅长编写代码和构建系统。
Yet, many software development organizations want to have their testers automate their testing efforts.
然而，许多软件开发组织希望让测试人员自动完成测试工作。
As a software developer, this can be extremely frustrating when you get bug reports on your code that you know works, but some automated test failed because it wasn’t properly written or designed.
作为一名软件开发人员，当您获得有关您知道有效的代码的缺陷报告时，这可能会非常令人沮丧，但是一些自动化测试因为没有正确编写或设计而失败。
You should step in before this happens and help with creating automated tests, and especially with creating a test automation framework.
您应该在此之前介入，并帮助创建自动化测试，尤其是创建测试自动化框架。
This is one area where you can be a huge benefit to QA. It is a great opportunity to bring the testers and developers closer, which can greatly reduce conflict and the me versus them attitude.
这是一个你可以为QA带来巨大好处的地方。 这是一个让测试人员和开发人员更加接近的绝佳机会，这可以大大减少冲突和我与他们对立的态度。
What About That One Asshat?那个蠢货怎么办？
Ok, so you are trying to get along with QA.
好的，所以你试图与QA相处。
You are testing your own stuff first, you are making sure you know what is going to be tested before you even write your code, you even took the entire QA team out to lunch to show them how you aren’t such a bad guy.
你首先测试你自己的东西，你甚至在编写代码之前确定要测试什么，你甚至带着整个QA团队去吃午餐，向他们展示你不是一个坏人。
But there’s this one QA dude—this asshat—who just seems to be gunning for you.
但是有一个QA老兄 - 这个蠢货 - 他们似乎正在与你而战。
No matter what you do or how friendly you are, he just seems to be hell bent on proving that your code sucks, derailing the project, and finding as many bugs as possible, whether they are relevant or not.
无论你做什么或者你有多友好，他似乎都在努力证明你的代码糟透了，使项目脱轨，并找到尽可能多的缺陷，无论它们是否相关。
What do you do? 你该怎么办
Warning: what I am about to say is not politically correct and it’s going to piss some people off, but it’s the truth.
警告：我要说的不是完全正确的，而且会让一些人感到沮丧，但这是事实。
Look, here’s the deal. 看，这是交易。
Let’s be honest. 说实话。
Sometimes—not all the time—people who are in QA feel inferior to developers.
有时 - 并非所有时间 - QA中的人员都不如开发人员。
In the back of their head, they feel like they just couldn’t hack it as a developer, and they settled for a job as a tester.
在他们的意识中，他们觉得他们不能像开发人员那样破解它，他们选择了作为测试人员的工作。
Now, don’t get me wrong, this doesn’t describe every person in QA, but it does describe some people in QA and, most likely, that asshat you are struggling with.
现在，不要误解我的意思，这并没有指QA中的每个人，但它确实描述了QA中的一些人，而且很可能是你正在努力解决的问题。
One way of dealing with this feeling of inadequacy is to try and bring down other people, especially developers who you are envious of, in order to make yourself feel smarter and better.
处理这种不足感的一种方法是尝试打倒其他人，特别是你羡慕的开发者，以使自己感觉更聪明，感觉更好。
I’ve seen this pattern enough times to know that it is fairly common.
我已经足够多次看到这种例子，知道它很常见。
And, in my experience, I’ve found that one of the best ways to deal with this kind of problem is to swallow a little of your pride and frustration and acknowledge the intelligence of your colleague.
而且，根据我的经验，我发现处理这类问题的最佳方法之一就是吞下一点你的骄傲和沮丧，并承认你同事的智慧。
It’s not easy to compliment someone who is purposely dishing out abuse at you, but it is the higher road.
恭维那些故意向你施虐的人并不容易，但这是更高明的方法。
I’ve found that in many cases, this person is just looking for some validation and acknowledgement, and once you give it to them, they are like a puppy following you around and wagging their tail.
我发现在很多情况下，这样的人只是在寻找一些验证和确认，一旦你给他们赞美/恭维，他们就像一只小狗跟着你，摇着尾巴。
A little genuine and sincere praise can go a very long way—remember that.
一点真诚和由衷的赞美可以发挥很长的作用 - 记住这一点。
And if your efforts still fail, at least you’ll know you’ve done what you can.
如果你的努力仍然失败，至少你会知道你已经做到了。
关于作者
John Sonmez is the founder of Simple Programmer and a life coach for software developers. He is the best selling author of the book "Soft Skills: The Software Developer's Life Manual."
John Sonmez是Simple Programmer的创始人，也是软件开发人员的生活教练。 他是“软技能：软件开发人员生活手册”一书的畅销书作者。
原链接
https://simpleprogrammer.com/software-developers-qa-testers/