作为QA工程师要避免的7个坏习惯
目录
Bad Habit #1: Testing Things You Don’t Understand(坏习惯＃1：测试你不理解的事情)
Bad Habit #2: Testing Only What the Story Tells You to Test(坏习惯＃2：仅测试story告诉您测试的内容)
Bad Habit #3: Assuming That Odd Behavior Is Correct Behavior(坏习惯＃3：假设奇怪的行为是正常的)
Bad Habit #4: Chasing Things Down the Rabbit Hole(坏习惯＃4：钻牛角尖)
Bad Habit #5: Automating Tests for the Sake of Doing Automation(坏习惯#5为了自动化而自动化)
Bad Habit #6: Creating Complicated and Flaky Tests(坏习惯＃6：创建复杂和不稳定测试)
Bad Habit #7: Accepting a Poor User Experience(坏习惯＃7：接受糟糕的用户体验)
Remember Why You Are Testing(记住你为什么要测试)
翻译正文
Most people would agree that software quality is important. We have seen the results of buggy software in all kinds of situations: from Mars probes malfunctioning and chemotherapy machines administering lethal doses of radiation, to telecommunications systems experiencing a cascade failure. It would seem logical to assume that software testers would be much-valued members of a development team. Yet sadly, that is not always the case.
大多数人都同意软件质量很重要。 我们已经在各种情况下看到了存在缺陷的软件的下场：从火星探测器故障和化学机器管理致命剂量的辐射，到经历级联故障的电信系统。 认为软件测试人员是开发团队中非常有价值的成员，这似乎是合乎逻辑的。 然而遗憾的是，情况并非总是如此。
Some software developers, product owners, and managers assume that quality assurance (QA) engineers are people who wanted to be developers and lacked the necessary skill or grit to succeed. Unfortunately, there are a few testers who fit this description, but most testers are people who genuinely care about the quality of the product they are testing.
一些软件开发人员，产品人员和管理人员认为，质量保证（QA）工程师是想成为开发人员，并缺乏必要技能或勇气而没有成功的人。 不幸的是，有一些测试人员符合这种描述，但大多数测试人员都是真正关心他们正在测试的产品质量的人。
Why then have testers gotten such a bad reputation? Usually, it’s because of bad habits they have developed over the course of their careers.
那么为什么测试人员会得到如此糟糕的声誉呢？ 通常，这是因为他们在职业生涯中养成了不良习惯。
This article will outline seven habits that QA engineers should actively avoid and the good habits to replace them with, in order to ensure that QA engineers are doing high-quality work and earning the respect of their peers.
本文将概述QA工程师应该积极避免的七种习惯以及代替它们的良好习惯，以确保QA工程师能够从事高质量的工作并赢得同伴的尊重。
Bad Habit #1: Testing Things You Don’t Understand(坏习惯＃1：测试你不理解的事情)
We’ve all been there: There’s some obscure story on the JIRA board that involves some legacy back-end code, and no one is entirely sure what the code does or how to change it. The developer tasked with the story has done enough research to fix the code but hasn’t put any detail in the story about how it works or what change has been made. The developer says to you, “Just run this request on this server, and if you get this response, then it’s fixed.”
我们一直都在那里：JIRA板上有一些模糊的story，它涉及一些遗留的后端代码，没有人完全确定代码的作用或如何改变它。 负责这个故事的开发人员已经做了足够的研究来修复代码，但没有在story中详细说明它是如何工作的或者做了哪些改变。 开发人员对你说，“只需在这台服务器上运行此请求，如果你得到这个响应，那么它就是固定的。”
Here’s the problem with this scenario: How do you know the developer is right? If the issue is not fixed, and there is a failure in production, your manager will come back to you with questions. Do you really want to have your only response be “The Dev told me to do this, and it worked, so I moved the story to Done”?
以下是此方案的问题：您如何知道开发人员是对的？ 如果问题没有解决，并且在生产环境失败，您的经理会带着问题您来找你。 你真的想让你唯一的反应是“开发者告诉我这样做，而且它确认工作了，所以我把story推到了完成”？
The Good Habit: Ask questions. Ask your developer to explain to you how the feature works and what changes were made to it.
好习惯：提出问题。 请您的开发人员向您解释该功能的工作原理以及对该功能所做的更改。
Keep on asking clarifying questions until you really understand what is happening. In doing this, you may bring up points the developer hadn’t thought of, sending them back to improve their work.
继续问清楚问题，直到你真正理解发生了什么。 在这样做的过程中，您可能会提出开发人员没有想过的要点，然后将他们回去改进他们的工作。
Software developers are continuously learning, and you should be as well. Listen to podcasts and read blog posts to keep up with the latest technology trends and testing strategies.
软件开发人员不断学习，你应该也一样。 收听播客并阅读博客文章，以了解最新的技术趋势和测试策略。
Bad Habit #2: Testing Only What the Story Tells You to Test(坏习惯＃2：仅测试story告诉您测试的内容)
Our development stories often contain acceptance criteria (AC), which outline exactly how the new feature or fix should behave. These are often written by the product owner, and sometimes by the developer. The AC are helpful and are certainly better than having no AC at all, but they often contain only “Happy Path” scenarios.
我们的开发story通常包含验收标准（AC），其中概述了新功能或修复应该如何表现。 这些通常由产品人员编写，有时由开发人员编写。 AC很有帮助，肯定比没有AC好，但它们通常只包含“Happy Path”场景。
Even when the developer writes the AC, they may not include test scenarios where bugs could be hiding, not because they are trying to be duplicitous, but because the scenarios might not have occurred to them. Testers will often assume that the developer knows best and will test only the AC. This means that there may be critical areas that are left untested and bugs left undetected.
即使开发人员编写AC，他们也可能不会包含可能隐藏缺陷的测试场景，不是因为他们想保持双重性，而是因为他们可能没有想到这些场景。 测试人员通常会认为开发人员最了解并且只会测试AC。 这意味着可能存在未经测试，且未检测到缺陷的关键区域。
The Good Habit: Think outside the box. One of our skills as QA engineers is being able to think about what might go wrong; we need to use this skill with every story we test.
好习惯：跳出框框思考。 我们作为QA工程师的一项技能是能够思考可能什么地方会出现问题; 我们需要在测试的每个story中使用此技能。
Before you sign off on the AC, ask yourself, “Can I think of anything else to test here? Is there anything I’ve missed?” This will often help you find bugs in areas that no one else thought of.
在你在AC上签字之前，问问自己，“我能想到其他任何东西要在这里测试吗？ 有什么我没有想到的吗？“这通常可以帮助你找到其他人没有想过的地方的缺陷。
Bad Habit #3: Assuming That Odd Behavior Is Correct Behavior(坏习惯＃3：假设奇怪的行为是正常的)
Often, when we are testing a new feature, we run across behavior that doesn’t make sense. Perhaps it’s an odd page refresh or a navigation to a place we weren’t expecting. Or perhaps a button appears where we weren’t expecting one.
通常，当我们测试新功能时，我们会遇到没有意义的行为。 可能这是一个奇怪的页面刷新或导航到我们不期望的地方。 或者在一个地方出现我们没想到的按钮。
It’s easy when we are testing on a deadline to focus so much on the AC of the story that odd behavior gets pushed to the back of our mind. We might tell ourselves, “I’ll ask the Dev about that when this story is done,” (and then we forget), or we say, “Well, I’m sure she knows what she’s doing; it’s probably supposed to do that.”
当我们在截止日期内进行测试时，很容易将注意力集中在story的AC上，以致于奇怪的行为被我们忘在了脑后。 我们可能会告诉自己，“当这个story完成时，我会问Dev，”（然后我们忘了），或者我们说，“好吧，我确定她知道她在做什么; 它可能应该就是这样做。“
The Good Habit: Listen to your instincts. If the behavior is odd, there’s a very high probability that end users are going to find it odd as well; they may even find it so frustrating that they stop using the application.
好习惯：遵从你的直觉。 如果行为是奇怪的，那么最终用户很可能也会觉得行为奇怪; 他们甚至可能会觉得很沮丧，以至于停止使用该应用程序。
We need to remember that our end users are our customers. We are the last line of defense in making sure that they have a good experience with our application. If your instinct is telling you that something isn’t quite right, document your testing and speak up about what you are seeing.
我们需要记住，我们的最终用户是我们的客户。 我们是确保用户对我们的应用程序有良好体验的最后一道防线。 如果你的直觉告诉你某些事情不太正确，请记录你的测试并大声说出你所看到的。
Bad Habit #4: Chasing Things Down the Rabbit Hole(坏习惯＃4：钻牛角尖)
This is the opposite of Bad Habit #3; sometimes QA engineers are so focused on finding every single thing wrong with an application, no matter how tiny, that they wind up in “analysis paralysis” and bring their team’s progress to a halt.
这与坏习惯＃3相反; 有时QA工程师如此专注于发现应用程序的每一个小的缺陷，无论多么微小，以至于他们最终都会陷入“分析瘫痪”并使他们团队的进展陷入停顿。
I remember asking a fellow QA engineer what her favorite bug was that she had found in the course of her career. She excitedly told me about a bug that involved clicking a button several times, navigating forward and backward through a pair of pages, and then scrolling quickly, all in one specific browser.
我记得问过一位QA工程师，她在职业生涯中她发现的最喜欢的缺陷是什么。 她兴奋地告诉我一个缺陷，包括多次点击一个按钮，在2个页面中向前和向后导航，然后在一个特定的浏览器中快速滚动。
While I’m sure this bug was fun to chase down, it involved behaviors that a user would never, ever do, and the bug itself wasn’t particularly harmful. I wondered how many other real issues she could have found while she was trying to reproduce this one obscure issue.
虽然我确信追踪这个bug很有意思，但它涉及用户永远不会做的行为，并且bug本身并不是特别有害。 我想知道在她试图重现这个模糊不清的问题时，她可以找到多少其他真正的问题。
The Good Habit: Focus on real-world use cases. Always remember that our focus should be on making sure that our software works well for our users and that our software is well-protected from malicious users. We are not merely finding bugs for the joy of the hunt.
好习惯：关注现实世界的用例。 永远记住，我们的重点应该是确保我们的软件能够很好地为我们的用户服务，并确保我们的软件免受恶意用户的侵害。 我们不仅仅是为了狩猎的快乐来找缺陷的。
If you find yourself going down the rabbit hole, ask yourself if your time could be better spent testing more realistic use cases.
如果你发现自己钻了牛角尖，问问自己，是否可以更好地花时间测试更实际的用例上。
Bad Habit #5: Automating Tests for the Sake of Doing Automation(坏习惯#5为了自动化而自动化)
QA engineers who have learned how to write automation discover that automating things is fun. There is a certain rush that comes with solving a technical challenge and watching your test run automatically.
已经学习了如何实现自动化的QA工程师，发现自动化很有趣。这样会伴有一定的冲动来解决技术挑战，并看你的测试自动运行。
But automation is not always the answer. When we have a new feature to test, it’s important to take time and get to know the feature as an end user would by actually using the feature. When we jump into automation before we’ve done this, we can wind up automating tests that don’t exercise the feature well.
但是，自动化不总是最合适的答案。当你有一个新功能要测试时，花时间去了解最终用户如何使用这个功能是很重要的。在此之前进入自动化阶段，自动化测试并不能很好地测试该功能。
We can also miss key features. For example, if we had a new search feature that searches by a date range, an automation engineer might spend all their time figuring out how to pick dates using Selenium test software and never notice that it was possible to enter in a start date that was after the end date.
我们也可能忽略关键功能。比如，如果我们有一个通过日期范围搜索的新功能，自动化工程师可能花费很多实际来弄清楚，如何使用selenium测试软件来选择日期，而不会注意到可能输入的开始日期会晚于结束日期。
The Good Habit: Take the time to do manual, exploratory testing to get to know a feature. Ask questions about how the feature will be used. Think about what your end users will do. Find as many bugs as you can. Then, start to think about how you should automate it.
好习惯：花时间去做手动测试，探索性测试以了解功能。 询问有关该功能会如何使用的问题。 想想你的最终用户会做什么。 找到尽可能多的缺陷。 然后，开始考虑如何自动化它。
Bad Habit #6: Creating Complicated and Flaky Tests(坏习惯＃6：创建复杂和不稳定测试)
When I first learned how to automate user interface (UI) tests with Selenium, I automated them like they were manual tests. My tests had lots of steps and implicit waits. The more steps a test has, the more likely it is that some test step will fail, causing the entire test to fail. Implicit waits are unreliable because waiting for a set number of seconds does not guarantee that the element will become present and clickable in that time.
当我第一次学习如何使用selenium来实现UI自动化时，我像手工测试一样来实现自动化。我的测试有很多步骤和隐含的等待。一个测试存在的步骤越多，其中的某些步骤失败的可能性越大，这带来了整个测试的失败。隐含的等待之所以不可靠，是因为等待设定的秒数并不能保证元素在那段时间内会出现并可点击。
Consequently, my tests were extremely flaky.
因此，我的测试非常不稳定。
Every morning when I arrived at work, I checked to see which tests had failed and reran all of the failures. Then I would tinker with the tests that had failed a second time to see if I could get them to work correctly. This was a tremendous waste of my time.
每天早上我一开始工作，我都会检查哪些测试失败并重新考虑所有失败。 然后我会修补第二次失败的测试，看看我是否能让他们正常工作。 这极其浪费我的时间。
The Good Habit: Remember that the point of automation is to make your work easier, freeing you up to do more exploratory testing.
好习惯：请记住，自动化的目的是让您的工作更轻松，让您能自由地进行更多的探索性测试。
Automated tests should be simple, with each test checking only one thing. Take a look at your UI tests and see if they could be automated with API tests instead. Application programming interface (API) tests are faster and more reliable than UI tests because they don’t rely on responses from the browser. When a UI test is needed, be sure to use explicit waits rather than implicit waits to reduce flakiness.
自动化测试应该很简单，每次测试只检查一件事。 看一下您的UI测试，看看它们是否可以通过API测试自动化来代替。 应用程序编程接口（API）测试比UI测试更快，更可靠，因为它们不依赖于浏览器的响应。 当需要进行UI测试时，请务必使用显式等待而不是隐式等待来减少测试的不稳定性。
Bad Habit #7: Accepting a Poor User Experience(坏习惯＃7：接受糟糕的用户体验)
Sometimes, when we are working on a deadline and have many stories to test, we look only at the functionality of a feature. If the feature works and has no bugs, we call it done and move on.
有时，当我们在截止日期前工作并有许多story要测试时，我们只关注功能特性。 如果该功能工作并且没有缺陷，我们将其称为完成并继续下一个。
But it’s important to remember the end users. If a user doesn’t understand what to do on the page or finds that they have to click several times in order to get something done, they will be frustrated and won’t want to use the product.
但记住最终用户非常重要。 如果用户不理解页面上的操作或发现他们必须多次点击才能完成某些操作，他们将感到挫败并且不想使用该产品。
I saw an example of this recently when I was asked to fill out a survey. The questions I was asked required long answers, but the survey fields were so small that I could only see one line at a time, making it difficult to type and proofread my entry. I’m sure that the QA engineers that tested the product verified that the field could be typed in and that the entry was saved, but they didn’t consider how difficult it would be to use.
最近，当我被要求填写调查时，我遇到了一个问题。 我被问到的问题需要很长的答案，但是调查字段非常小，以至于我一次只能看到一行，这使我很难输入和校对我的条目。 我确信测试该产品的QA工程师确认可以输入该字段并保存该条目，但他们没有考虑使用它的难度。
The Good Habit: Always think of your end users when testing your application. Find out from your product owner what the expected workflows are and run through those workflows. Ask yourself what you would think of the product’s behavior if you were the end user rather than the tester. If the behavior would frustrate you, advocate for a change in the behavior.
好习惯：在测试应用程序时始终考虑最终用户。 向您的产品用户了解预期的工作流程是什么，并贯穿这些工作流程。 如果您是最终用户而不是测试人员，请问自己对产品交互的看法。 如果这种行为会让你感到沮丧，那就提倡在行为中做出改变吧。
Remember Why You Are Testing(记住你为什么要测试)
In our daily work as testers, it’s easy to get distracted by deadlines and technical challenges. We are great at focusing on the minutiae of software, which is why we are good at finding bugs. But we must never lose sight of why our company exists: to create software that people will use.
在我们作为测试人员的日常工作中，很容易因截止日期和技术挑战而分心。 我们非常注重软件的细节，这就是我们善于发现缺陷的原因。 但我们绝不能忽视我们公司存在的原因：创建人们将使用的软件。
The end result of all of our tasks must be the assurance that a user will be able to use our product intuitively, safely, and easily. When we consistently focus on the quality of the products our team is delivering, we earn the reputation of being effective QA engineers as well as the respect and trust of our developers, product owners, and leaders.
我们所有任务的最终结果必须是确保用户能够直观，安全，轻松地使用我们的产品。 当我们始终关注我们团队所提供产品的质量时，我们赢得了高效QA工程师的声誉以及我们的开发人员，产品人员和领导者的尊重和信任。
ABOUT THE AUTHOR
Kristin Jackvony discovered her passion for software testing after working as a music educator for nearly two decades. She has been a QA engineer, manager, and lead for the last eight years and is currently working as a QA Lead at Paylocity. She writes a weekly blog called Think Like a Tester, which helps software testers focus on the fundamentals of testing.
Kristin Jackvony在担任音乐教育者近二十年后，发现了自己对软件测试的热情。 过去八年来，她一直担任质量保证工程师，经理和负责人，目前在Paylocity担任质量保证负责人。 她每周写一篇名为Think Like a Tester的博客，它可以帮助软件测试人员专注于测试的基础知识。