In many companies, especially small and medium, where there is a strive to establish any work process, it has been observed that testers are a little puzzled about how to start, progress and finish their testing job in a hurried manner.
The project or test manager always pressurize the test team to complete 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.
This article will give you some concrete path to such situations in a practical way.
Shortcut Testing But Quality Testing
Everybody wants a shortcut but wisely says there is no shortcut to do good things.
Whereas I do not refute the above but believe there is ‘shortcut’ to do testing and yet good testing can be done. Here it is how.
Let say, you are assigned to test a Web-based application or a website. Since you have cracked the interview of a tester, you have all theoretical knowledge. Forget those or keep those at the back of your mind for the time being. Now be ready to enjoy testing.
Do not bother to do too many 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 required to have their 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 exampled. Mind that, many developers of Asia still assumes 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, in short, depending on the target client’s geographic region, you should cater to prepare all your various input data to test the phone number field.
Just write down the test data in your Workpad.
Now, think from a perspective of the essence of one field with respect to another field (s).
While filling the form, if you have selected the country field as India, then if the Phone field is automatically populated with ‘91’ then 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 did not mention anything 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 needed to prepare your ‘Test Cases’. It hardly makes any sense if you call it Test Case or anything else, you go and test it. Discuss the results with the developers, get it fixed, re-test in the revised version, and you should be done.
In summary, you applied the following shortcuts:
- No Test Plan document, it is your common sense, which worked.
- No Testing approach document, it is your thought on the perspective which worked.
- No big Test Case excel, it is your Workpad which worked
- No big test report document, it is your discussion with the developer which worked
And you achieved all these at the cost of your enthusiasm in testing and thinking from the perspective of the software element which 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, bring your theoretical knowledge to the forefront. 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 on 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 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 definitely 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 the least, you have to think from a sniffer’s view, these fields are open, so there are people who want to distort you, they will inject scripts which will either break your software or will 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’ that is a famous system word see what happens. All should come out with invalid entry –this is so-called ‘Security Testing’ even though at 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 developer, and deep perspective thinking. Find out the most logical issues in a number of 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 own hand, and has lead testing teams in a most practical way. This article is a glimpse of his execution from the field.
Let us know your feedback/questions in the comments below.
good example. is this exploratory testing or part of it or similar to it?
Great post !!!!
I can’t agree with this. It’s a short-term fix and will come back to haunt you. How do you make the test case(s) re-usable? How do you version control test cases/test plans so you can run only the correct test cases for different releases of the app? This “back-of-a-napkin” approach is what got us all into trouble in the first place, causing us to over-compensate with crazy amounts of process and documentation (that no one ever read). We need to find a balance between agility and sustainable collective knowledge; this is not it.
@sially,
I am not sure what testing it is this is my practical experience, I will rather coin it as ‘perspective testing’ but it is similar to exploratory testing, which have worked well for clients.
Clients hardly bothers what test cases you ran, what planning you made, how many documents you prepared but they start using the software with their knowledge of the domain, and gets satisfied if no major bugs found. This approach I have seen have reduced bugs in the end.
@latha,
Thank you, hope you enjoyed reading it!!!
@Laurence,
I get your point, this is hard to agree, but if you can reduce bugs in a software in whatever way you can, your clients/ users, becomes happy. Also please note that I am talking about small and medium companies, where process establishment is a struggle.
This approach I am sure if taken in its right spirit, will reduce bugs. Clients hardly bother about what test cases you ran or re-ran, they will use their test cases, their domain knowledge, their utility cases. They will shout if they find bugs, and then PMs, TMs, will have massive meetings with teams and search for Test documents, who did what mistake, all kinds of finger pointing etc.
And ofcourse your test cases are there in your workpad. So, you can always re-use them. The approach applies to all versions. The main point is, with time constraint, quality of testing cannot be compromised, but documentation can be compromised and even process can be compromised. As long as you tend to produce zero bugs, it will not haunt you. Purpose is to show a short-cut to achieve that for not-so-organized companies through a perspective testing approach without much documentation.
This is a great post for testers and especially for freshers.
This surely is initial exploratory.l do this often. But when I don’t document it I loose it . Particularly in regression testing a good scenario that caught an ugly bug cannot be checked again because I forgot the exact details of my brilliant idea of a testcase.
Yes we need a balance between a quickfix and a lenghty documented process.while quick shortcuts is good for sanity and some and cloud testing, regular cycles requires discipline:)
in realtime, do we want to write seperate test case for different types of testing like for functonal testing we write functional test case or for system testing we write system test case like wise….and also tell me what type of testing we need to do in eCommerce website. and how we work on quality center tool for test case prepration ,execution and making report.
Yes it is right. We can use error guessing technique here as per out experience and exploratory testing also. And discussion with developer is also the great thing to give us the hint.
@Radha,
Thanks for your comment. I agree that the balance too much of documentation and quick fix is required.
But, the workpad, where you have your test cases/scenario is very important, is really an official document, your ideas must be there first. Wherever else you document is of no gain to client or to you or to testing quality.
Discipline is fine, but not at the cost of Quality Testing. Many companies run after discipline but do not run after nurturing the testers to innovate stunning test cases/scenarios. And whenever you have thought of a good test case idea, it only requires a workpad, but if you are asked to make an excel, you are bored, your idea is gone! Your enthusiasm is lost!!! I tried to highlight these in the article.
@Jayasri,
Thanks for your comment.
I wanted to mention, I tried the most practical approach to testing, so do not want to categorize this into any traditional format, but want to stress on two things
a) Perspective thinking behind a software element.
b) Enthusiasm in testing and finding defects getting them resolved.
i agree with this
Because its the short term testing when u are giving a Demo of ur vanilla release in emergency. this is the some basic of testing. after that u can start ur full testing senario.
great post…minute basic facts explained so nicely…
I agree with this .
This is very helping while you working as a freelancer and want to achieve yr deadline in very short period.
Very nicely explained.