Top 5 Software Testing Traps and How to Overcome Them

If you are a software tester and have been in this field for a while then you might have run into situations (let me call them software testing traps and hurdles) that limit your efficiency and effectiveness as a tester. It could be a common problem like lack of enough time and/or resources to finish testing or could be because you are surrounded by coworkers and colleagues who don’t realize the importance of your work. But if you’re like me who cannot work on projects and with people unless you have got credibility, respect and their confidence in the work you do, then you must be aware of these pitfalls, mistakes, traps and hurdles that any tester can face in their life.

I started writing this blog when I began my software testing career (exactly 9 years from today) and I don’t know about you but I have run into plenty such software testing traps while working on various testing projects at various stages of my career. And every time I ran into them, it gave me a chance to look for magic spells, ways, methods, techniques, tricks, tips and anything and everything that could help me come out of such situations. And today’s article is a compilation of some of those top 5 traps that I’ve ever run into in my software testing career and some of the ways that helped me overcome them, in my context. The following case points and suggested solutions can help you overcome many common real-life software testing problems.

#1 Running Out of Testing Ideas?

This is by far the most common problem that a tester can run into while on a project. How many times have you been in a situation where you didn’t know what else to test and how? I call this phenomenon as “tester’s block syndrome” [a condition, associated with testing as a profession, in which a tester may lose the ability to find new bugs and defects in the software that (s)he is testing]. If you’re curious, which you should be (if you are or aim to become a good tester), then you can read more about it in the article titled The Se7en Deadly Sins in “Software Testing” that I wrote a while back.

How to overcome this trap?

Pair Testing:

You can use Pair testing to your advantage to generate test ideas that seem to have dried up when you try alone. Pair testing is nothing but a testing technique where two testers work in pair to test the software under test.

BCA (Brute Cause Analysis):

Testers can employ this unique brainstrom technique when one tester thinks about a bug and the other tester thinks of all possible functions and areas where this bug can manifest.

Think ‘Out of the Box’:

Instead of thinking about the feature/function/application in front of you, rather try thinking in opposite directions. Take a step back and reassess the situation. Have you been trying to run functionality test when you ran out of ideas? How about performance, load and stress tests? How about tests involving data, structures, platforms, browsers, devices, operations?

[wpcd_coupon id=4046]

#2 Missing the Testing Goal?

How many times were you in a team meeting where your manager or someone from the dev. team was talking about this cool new/enhanced feature that needs testing and everybody else in the meeting room appeared to be ‘getting it’ whereas it was only you who had no idea what it was? When in such situation, nodding your head as if you are able to understand everything may seem like the natural (easy) path but trust me; it is not the best path to go unless you want to end up in trouble later in the test planning and execution phase of this feature!

How to overcome this trap?

Ask Relevant Questions:

The importance of good questioning skills can not be stressed enough if you plan to be an excellent tester. And this very skill can come to your rescue when you are trapped in a situation like the above. It’s okay to admit you don’t understand something and then get it clarified than to not admit and be ignorant for rest of your life.

Brainstorm:

Okay, so you have asked tons of relevant questions about the upcoming feature/application/product that needs testing and have taken notes. Now what? Now is the time to pull your testing team and brainstorm ideas to find all sorts of possible test ideas, strategies, plans etc for this test project by gathering a list of ideas that come spontaneously by the teammates.

Read between the lines:

More often than not, when starting working on a new product or technology or even a tool you can find some level of available documentation on the same to help you get started. But a word of advice — take everything that you read there with a pinch of salt. I’m not saying not to read them at all. But when you do, be careful about all those things that might not have been put down in words but are implied. Sometimes, proactively being able to find and underhand these implied messages in the project documents can help you in a big way to understand the testing goal.

#3 Suffering from In-attentional Blindness?

How many times have you missed a very obvious bug or a defect or an error that was right there on the screen, staring right back you and yet you missed it because you were busy ticking off the other test items from the testing checklist or executing the test case document? Situations like these can be very embarrassing not only because you missed something that is so basic and so obvious but also because it happened when you were actually busy religiously following the test cases to find things just like these!

How to overcome this trap?

Stop blindly following the Test Case and Test Matrix:

Before starting to use a test case for your testing always ask yourself the following questions and then adjust your test cases to fill any missing links.

– “Why is this test case important?” — “What are the things that are covered by this test case? What are not?” — “What portion of the product functionality does this test case cover?” — “Can this test case be tested in any other methods or ways? If yes, how?”

Change the Focal Length of Your Testing Approach:

When following the test cases and test matrix to test something, keep and open eye for anything else that might be going on during test execution. Explore other related areas even though they are not mentioned in your test case/matrix. A control object that flickers a little when you save your inputs in another section of the form, a ding sound coming from the speaker when certain button is clicked, a slight change in the color of a Submit button when you click inside another test area — all of these subtle looking actions may be an indication of an approaching catastrophic system failure.

#4 Not Sure if ‘It’ is Really Working… or Not?

How many times have you come across issues that you didn’t report as errors and bugs because you were not sure if it was really a bug or something that you did wrongly and later those same issues were found and picked up by a coworker or your manager or, god forbid, your clients or the customers?

How to overcome this trap?

Trust Your Tester’s Instinct:

IF your instinct is telling you that something is fishy and what you’re observing and experiencing could very well be a bug, then follow your instinct and report it to the devs. After all, what could be the worst case scenario? The devs might come back and say it is something that you did wrong (misconfiguration of certain settings, misunderstanding of the actual feature etc) and not a bug. It is still much more better than ignoring it thinking it might not be a bug and later your manager or customer finding it.

Start with a fresh set of eyes:

Fresh eyes find bugs, and if you are still unsure then take a short break and retest and confirm that what you’re seeing is really not a bug.

Have it tested by a fellow tester:

Pick one of your fellow testers and ask them to go through the same test scenario and see what they come up with.

#5 What to Test and What can be Skipped… Safely?

How many times have you been in a situation when you felt overwhelmed by the number of possibilities and choices to approach testing? With the complexity of software and technology becoming more complex day by day, often the number of things that a tester needs to consider while testing can be overwhelming. And with the project deadline approaching fast it can be very challenging to decide what to test, where to begin, how to begin and what can be skipped.

How to overcome this trap?

Gather Intelligence Data:

First of all, look at the existing bugs in your bug tracker tool and make a note of critical bugs. Talk to developers and ask them to think of top 10 most critical things in the product that affects majority of end-user functions and make a list of them too. Go though the review docs, user manuals, implementor’s guide and basically anything that can give you an idea of things that are going to be most important for your customers and end users.

DIQ approach (Dive In/Quit):

Now that you have the list of all these important things that need testing, let me introduce to you the magical DIQ approach (Dive In/Quit). In this testing approach, pick any of these most critical test items and just dive in and test. While testing, if it appears too hard for you then quit and take another item, dive in and test until you have exhausted all your test ideas on it. Repeat! So basically you take an item > dive in > quit when you can’t test it any further > repeat it with another item > come back to initial item when you have finished all other test items.

#And finally… Learn to Accept FAILURE, once in a while!

Due to the intrinsic nature of complexity of modern day software and communications systems, software testing is turning more complicated. As a result, more efficient and effective testing heuristics, techniques and methodologies needs to emerge. If you are not evolving fast enough as a tester then the chance of failure is exponentially high and you should be prepared to face failure once in a while. After all, we are testers; not magicians! But as long as you are learning from your past mistakes, upgrading your testing skills and updating your testing heuristics to accommodate those mistakes so they never happen again, I think you should be fine.

About the Author:

Debasis Pradhan has over a decade worth of exclusive experience in the field of Software Quality Assurance, Software Development and Testing. He writes here to share some of his interesting experiences with fellow testers.

Source: Software Testing Tricks