How to Become a QA Problem Solver

Sometimes a software tester’s job can be pretty cut and dry. The tester executes a test case, and it fails. A bug report is written and the issue is passed over to the developer. The developer reproduces the bug and fixes it. After fixing the bug, a new build is deployed, and the tester verifies the fix. Pretty simple right? If you are the kind of person who likes to solve problems it actually sounds quite boring. If you are a software tester and you enjoy solving problems, then you are in luck. It rarely happens.

Problem-solving is one of the most important, if not the most important skill a software tester can have. I am going to tell you why software testers must be excellent problem solvers. Then, I’m going to tell you how to do it.

QA finds problems, then developers fix them, right?

Wrong. It’s a common misconception that a tester finds a bug and their responsibility ends there. In some organizations that may be the extent of the expectation for QA. Find the problem, report the quick details and move on. I have worked at organizations where that is the case, but as a tester do you want to contribute more? Would you like to provide an easier fix for the developers and be challenged along the way? Do you want a better understanding of how the developer will fix the bug? If you do, and you pursue that information, you will become a better tester and gain a fuller understanding of the system you are testing.

A “fix” to a bug may require that just one line of code is changed, or even a single character and the developer will likely be the one to make that change. But, any software developer will tell you that the legwork of the fix is identifying where the issue lies. Sometimes, it’s a needle in a haystack and as surprising as it may sound, a tester can do a great deal in finding that needle. Here’s how…

Narrow down the search

Decreasing the breadth of the search is where time can be saved for the entire team. In software, there are often many variables that could be contributing to a bug. Making a bug easier to find is as easy as eliminating as many variables as possible.

What are the variables?

Environment

In most cases there will be a least one environment being used in the development life cycle. For this example, let’s say there are four environments: Development, QA, Staging and Production. All these environments can be used as a means for narrowing down the location of a bug. By identifying the environment or environments where the bug exists, certain variables might be eliminated. For example, if a bug is reproducible in QA, staging and production, we know the bug was not introduced in a recent QA deployment (assuming each environment has its own version of services and/or client). If the bug is reproduced in QA, but not in staging or production, we know it was most likely introduced in a recent build. This narrows the search significantly. Now we can begin the search in the QA environment and look at the most recent changes.

Client or Service Bug?

Another important variable to eliminate is if a bug lies on the client or the services side. Sure, it could be a result of a miscommunication between the two and there is no real side to blame. But, if that is the case and you can figure that out – you have solved the problem. But how do you figure that out?

First, let’s say you identified the issue exists in the QA environment. There was a new client build and multiple services were deployed to the environment. (Lots of variables.) Next, begin narrowing it down by trying the previous client with the new services. If the bug doesn’t appear in the previous client, you may have identified that the issue lies with the new client. That will mean a huge decrease in variables, because we won’t need to consider services as being the issue. Lastly, it could still end up being a services issue, but simply providing the information that it works on the previous client in the same environment could go a long way in identifying the root cause. It narrows down the culprit to changes that services made to the QA environment that would affect this particular feature. We may not have reached the root cause yet, but we have (again) greatly narrowed the scope of the search for it.

Versions

Talk about variables and the conversation will certainly turn to the version being tested, especially if an issue is reproduced by one user, but not another. No matter what type of software is being developed, there are always various versions that must be tested. For example, a website or web app will need numerous browser versions to be tested on each supported browser. A mobile app will be supported on numerous OS versions on each supported mobile platform. If you identify that a bug is reproducible on one version, but not another you may have immediately solved the problem and in essence “fixed” the bug. An example of this could be a bug that occurs on one iOS version might be a result of the client being built on a version of Xcode that deprecated support of that particular feature for older iOS versions. That’s a very specific client example, but every platform has its quirks and issues like this. The same can be done with service versions. If an issue occurs with a particular service, various versions of the service may be tested against other variables such as the client, the OS, and other environments.

More Variables

There are certainly way more variables than those I talk about above. For example, mobile apps need to be tested on a variety of networks, including multiple wifi networks and mobile providers and there are hardware differences such as screen sizes, etc., too. Environment configuration is another variable that could come into play when working to identify a root cause. The number and type of variables depends on the system under test and the extent to which platforms, browsers, hardware and versions of each are supported.

Conclusion

The best QA engineers are problem solvers. All of the above are examples of how a software tester can solve problems without any specific technical expertise. The only knowledge needed in these cases is a simple understanding of the system under test. Finding bugs, reporting bugs and verifying bugs is very challenging but it can also become monotonous after testing the same software for years. Learning to understand a system well enough to streamline the process of actually fixing the bugs adds to the challenge that a tester needs to stay motivated to enjoy their job and expand their skills.

I hope these thoughts and tips inspire you to go beyond the duty of simply reporting a bug and leads you to enjoy the challenge of becoming a QA problem solver.