Is there any ‘Shortcut’ for Good Testing? (Here it is how)

In many companies, especially small and medium, where there is a strive to establish any work process, some observe that testers are a little puzzled about how to start, progress, and hurriedly finish their testing job.

The project or test manager always pressurizes the test team to complete the testing as soon as possible. With this pressure, somebody starts with a great methodical way but cannot complete the testing; somebody tries to be fast by short-cutting it, but cannot achieve quality. So, there is a problem in daily practice.

Shortcut Testing But Quality Testing

This article will give you some concrete practical paths to such situations.

Everybody wants a shortcut but wisely says there is no shortcut to do good things.

I do not refute the above but believe there is a ‘shortcut’ to do testing, yet good testing can be done. Here it is how.

Let’s say someone assigns you to test a Web-based application or a website. Since you have cracked the interview of a tester, you have all the theoretical knowledge. Forget those or keep those at the back of your mind for now. Now be ready to enjoy testing.

Do not bother to do too much documentation, just keep your

• Workpad ready
• Be ready to interact with the developers

For Example, now say you are testing a form, where there is a Phone Number field.

Think on this field for 2 minutes and ask these questions to yourself:

• What is the perspective of this field being here?
• Whose phone number is this going to be?
• Who will make calls to this number and why?

The answer to these questions will lead you to prepare test input data.

So, if the answer to the first question is a legal firm is required to have a web presence, then you should understand that, and think for a second, it will reveal that this is perhaps required for making a response to prospective service requests to the legal firm.

If this phone number is a prospective client from the USA, then you should know what the valid phone number types in the USA are. Search on the internet; preferably go to an authentic website, where valid US numbers are examined. Mind that, many developers in Asia still assume the Phone number is a perfect numeric type, which is not.

In the USA, 1-800-OFFICE DEPOT is a valid phone number, and yes, they enter alphabets in the Phone field. So, depending on the target client’s geographic region, prepare all your various input data to test the phone number field.

Just write down the test data on your Workpad.

Now, think from a perspective of the essence of one field concerning another field (s).

While filling out the form, if you select the country field as India, then the Phone field automatically populates with ’91’ – it is a WAH! Thank the developer for this tiny cute usability thought, and you gain by getting a good relationship with the developer.

But mind that, you are a contributor to the quality gate in your organization, so no one gets passed you, not even the CEO, so you have to be a friend in disguise.

Now, from a practical usage point of view, if the Legal firm is aggressive in their business, they must capture an alternate phone number of an inquirer. Ask the project manager (PM) why it is not captured (if it is not). The PM will probably answer; the firm mentioned nothing about it.

You can counter, to be on the safe side. Did we ask the firm? So, gradually, you are not only enjoying testing but also getting involved deeply and perhaps taking the upper hand over other members, so no one can fool you around.

So, by now, what is the scribble there in your notepad? In theoretical terms, everything is needed to prepare your ‘Test Cases’. It hardly makes any sense if you call it a Test Case or anything else, you test it. Discuss the results with the developers, get it fixed, and re-test in the revised version, and you should be done.

In summary, you applied the following shortcuts:

1. No Test Plan document, it is your common sense that worked.
2. No Testing approach document, it is your thought on the perspective that worked.
3. No big Test Case Excel, it is your Workpad that worked.
4. No big test report document, it is your discussion with the developer who worked.

You achieved all these at the cost of your enthusiasm for testing and thinking from the perspective of the software element that you are going to test.

Are you a little more enthusiastic? Then check with the developers how data is stored and how they are retrieving it. Think from the device perspective, if the UI is fine enough, to display the Phone number correctly and soothingly. The zero does not look like ‘O’, the ‘Y’ does not look like ‘V’, the ‘8’ does not look like ‘3’, the ‘g’ is not cut, etc. etc..

That is not the end of it; you will need to apply this thinking process to the whole testing affair.

Now, showcase your theoretical knowledge. Do some testing with some input to check how well are the boundaries protected, the so-called ‘Boundary-Value Testing’. Prepare right-side extreme values by thinking of the highest length of a phone number of all possible types of target region valid phones.

Test the left side extreme, just put the blank or space and see what happens. It should not take a blank or space if it is mandatory. If it is optional, it should allow you to proceed without disturbing.

Now, make some inputs ready for negative testing to check if the developer was a trainee developer (which is a possibility in today’s resource management). Now check whether the developer has forgotten to make the cursor control perfect, which means, if an entry is over in a field, the cursor must automatically go to the next field, the so-called Usability Testing.

Now, last but not least, think from a sniffer’s view that these fields are open, so there are people who want to distort you. They will inject scripts that will either break your software or retrieve useful information from your application.

So, test if it is adequately protected. Put some junk into the field, put commas, inverted commas, single and double, copy and paste some HTML script, put the word ‘NULL’ which is a famous system word to see what happens.

All should come out with invalid entry –this is so-called ‘Security Testing’ even though at the beginner’s level, this shortcut adds value to your testing results.

Conclusion

So, what is needed for quality testing is your highest enthusiasm, deep involvement with software and developers, and deep perspective thinking. Find out the most logical issues in several various twisting cases you can think of and enjoy finding bugs. Do not bother too much with process and documentation before this ‘Shortcut’ Testing, but ‘Quality Testing’.

About the author: This is a guest post by Dipankar Goswami. He is a post-graduate in Mathematics, worked as a Project manager in software development companies, dealing with Testing on his hands, and has led testing teams most practically. This article is a glimpse of his execution from the field.

Let us know your feedback/questions in the comments below.