![\"\"](\"https:\/\/simpleprogrammer.com\/wp-content\/uploads\/2018\/08\/bad-habits-square-300x300.png\")
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.<\/p>\n
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.<\/p>\n
Why then have testers gotten such a bad reputation? Usually, it\u2019s because of bad habits they have developed over the course of their careers.<\/p>\n
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.<\/p>\n
We\u2019ve all been there: There\u2019s 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\u2019t put any detail in the story about how it works or what change has been made. The developer says to you, \u201cJust run this request on this server, and if you get this response, then it\u2019s fixed.\u201d<\/p>\n
Here\u2019s 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 \u201cThe Dev told me to do this, and it worked, so I moved the story to Done\u201d?<\/p>\n
The Good Habit: <\/strong>Ask questions. Ask your developer to explain to you how the feature works and what changes were made to it.<\/p>\n Keep on asking clarifying questions until you really understand what is happening. In doing this, you may bring up points the developer hadn\u2019t thought of, sending them back to improve their work.<\/p>\n Software developers are continuously learning<\/a>, and you should be as well. Listen to podcasts<\/a> and read blog posts<\/a> to keep up with \u00a0the latest technology trends and testing strategies.<\/p>\n 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 \u201cHappy Path\u201d scenarios.<\/p>\n 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.<\/p>\n The Good Habit:<\/strong> Think outside the box.<\/a> 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.<\/p>\n Before you sign off on the AC, ask yourself, \u201cCan I think of anything else to test here? Is there anything I\u2019ve missed?\u201d This will often help you find bugs in areas that no one else thought of.<\/p>\n It\u2019s 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, \u201cI\u2019ll ask the Dev about that when this story is done,\u201d (and then we forget), or we say, \u201cWell, I\u2019m sure she knows what she\u2019s doing; it\u2019s probably supposed to do that.\u201d<\/p>\n The Good Habit:<\/strong> Listen to your instincts. If the behavior is odd, there\u2019s 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.<\/p>\n 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\u2019t quite right, document your testing and speak up about what you are seeing.<\/p>\n 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 \u201canalysis paralysis\u201d and bring their team\u2019s progress to a halt.<\/p>\n 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.<\/p>\n While I\u2019m sure this bug was fun to chase down, it involved behaviors that a user would never, ever do, and the bug itself wasn\u2019t particularly harmful. I wondered how many other real issues she could have found while she was trying to reproduce this one obscure issue.<\/p>\n The Good Habit:<\/strong> 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.<\/p>\n If you find yourself going down the rabbit hole, ask yourself if your time could be better spent testing more realistic use cases.<\/p>\n 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.<\/p>\n But automation is not always the answer. When we have a new feature to test, it\u2019s 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\u2019ve done this, we can wind up automating tests that don\u2019t exercise the feature well.<\/p>\n 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.<\/p>\n The Good Habit:<\/strong> 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<\/a>.<\/p>\n 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.<\/p>\n Consequently, my tests were extremely flaky.<\/p>\n 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.<\/p>\nBad Habit #2: Testing Only What the Story Tells You to Test<\/h2>\n
Bad Habit #3: Assuming That Odd Behavior Is Correct Behavior<\/h2>\n
![\"\"](\"https:\/\/simpleprogrammer.com\/wp-content\/uploads\/2018\/08\/odd-habits-300x300.png\")
Often, when we are testing a new feature, we run across behavior that doesn\u2019t make sense. Perhaps it\u2019s an odd page refresh or a navigation to a place we weren\u2019t expecting. Or perhaps a button appears where we weren\u2019t expecting one.<\/p>\nBad Habit #4: Chasing Things Down the Rabbit Hole<\/h2>\n
Bad Habit #5: Automating Tests for the Sake of Doing Automation<\/h2>\n
Bad Habit #6: Creating Complicated and Flaky Tests<\/h2>\n
![\"\"](\"https:\/\/simpleprogrammer.com\/wp-content\/uploads\/2018\/08\/user-300x300.png\")
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.<\/p>\n