As anyone pursuing a position in QA knows, a level of technical skill must be achieved if you want to have a successful career - but that’s not the whole story.
As proficient as a tester might be, other non-technical skills need to be mastered too. It is these aspects of the QA position that I will talk about here. Not just anyone can thrive as a QA engineer, a range of important non-technical attributes are needed too.
“Repetition is the mother of learning, the father of action, which makes it the architect of accomplishment.” – Zig Ziglar
Repetition is a key aspect of testing. Each time a new build is created, a QA engineer must execute a sanity test to verify the build under examination is ready for more detailed testing. Then, another set of tests that will have been performed many times must be executed to locate any regressions (new bugs that were working in the previous build.) All of these tests require repetition which can be tedious at times. Unfortunately, this is par for the course. Just about any job in software is going to require the same tasks to be repeated over and over. But there are several ways to change things up to help avoid the same person repeating the same tasks.
For example, if you have a QA team comprised of several members, the sections of a QA sanity checklist may be rotated so each member performs a different part of the checklist with each build. There are also ways an individual tester can break the monotony. These include varying the search terms, executing tests in a different order or switching back and forth between tasks to break up the day. Another suggestion is to switch up the hardware or OS version that is under test as there are usually a set of supported devices, browsers or OS versions that must be tested. These are just some ways a tester can get creative to keep the mind fresh while testing. No matter how you slice it, being okay and even enjoying repetition is a key aspect of quality assurance.
“The two hardest tests on the spiritual road are the patience to wait for the right moment and the courage not to be disappointed with what we encounter.” – Paulo Coelho
Here is a common scenario: You reported a bug a couple months ago, and it was fixed in the next build. In the subsequent build, the bug returned. You re-opened it and it was fixed again. The cycle repeats itself a month later and then again in the next build. It happens. Code gets reverted inadvertently, or not checked in. It’s never a good thing when this happens because it causes unnecessary work for multiple people. Do what you can to alleviate the situation when it does happen, but don’t lose your cool. Yes, it’s frustrating, but you can be sure the developer that has fixed the bug every time is just as frustrated, if not more so.
There will be times when your patience is tested by developers, by the process, by the product owners and so on. You might have reported bugs that you strongly believed were high priority and should be fixed as soon as possible. In the interest of getting a product to market, sometimes these bugs are pushed to the backlog to be fixed another day because they are deemed lower priority than other features or bugs. When this happens, you probably state your case as best you can, identify the use case and make your opinion known. But after that, you wait. The bug may not be prioritized the way you would like, but you have done all you can and so you move on. This bug might make it into production where it is then realized that you were right and it should have been fixed! Or, maybe you were wrong – and it was really an edge case that users will rarely see. These are just a couple of examples where a high level of patience will be required so being able to calmly handle these unavoidable times of frustration is a skill worth mastering.
Trial and Error
One of the things I love most about testing is the challenge of recreating an issue that has so far been difficult to reproduce. While this can be frustrating, it is also highly satisfying when you eventually locate the problem. You see a bug, then document the steps to reproduce it, try to reproduce it yourself and it doesn’t happen. You try again, it still doesn’t happen. At this point you might wonder if you were imagining it but of course you weren’t, so it’s time to investigate possible reasons for the inconsistent behavior. Perhaps you try multiple OS versions or different browsers, if it is happening on only a certain version? Maybe there was an outage with a service, so you check the service status. What about the load balancer? Is it only happening when hitting a particular service.
After some time in QA, you learn possible causes for inconsistent behavior. Sometimes, the bug just occurs with a certain search term or only when following a very specific set of steps. The thing is, you’ve identified a bug, but it most likely won’t be fixed until you’ve done the detective work to figure out how to reproduce it. At times, this can be extremely frustrating, but the key is to think of it as a challenge and enjoy the process. Solving these cases turns a button pusher into a bonafide valuable team member.
A Beginner’s Mind
A new feature. A new workflow. It’s not new to you because you’ve tested it a hundred times. When the new feature hits production, it’s brand new to the end-user. Every time an adjustment is made to a workflow or a new screen is added, you need to look at it as though for the first time. You know where to click because you’ve done it a hundred times but will the end-user know? A successful QA engineer will think like a beginner every day.
A QA engineer is learning constantly so having a beginner’s mind can be a great help. You’ve become an expert on an application or project and then the company switches you to another project. It feels like switching careers in a way. You worked your way up to being the top dog on a team and now you are a complete novice on a different team. This is a good thing. You might struggle for a while, but you will continue to grow. You were comfortable, but now you are not. Consider it an opportunity to move onward and upward.
The last point I want to make about a beginner’s mind deals with tools. Tools are constantly changing and, chances are if you change jobs, you will need to learn how to use tools that are very different from those you are used to. My advice is, don’t wait until you’ve switched jobs. If there are tools you know are becoming popular within the industry, start learning about them on your free time. When it is time to switch jobs, your interviewer will be impressed with the knowledge you gained of your own volition.
Technical aptitude is no doubt an important aspect of software testing – you won’t be able to land your first job without it, much less progress in your career. But, the ability to pursue excellence of character is just as important and it may actually take you further in your career than the technical skills that are usually given priority.