Exhaustive Testing

Exhaustive Testing as the name suggests ‘Performed comprehensively and completely’ and remember that 100 % Testing is not possible, you may have a greater confidence on your application but 100 % Tested Application can only be found in Pluto; just take it for the understanding don’t get into it.

Let’s come to the actual point. Assume you are testing an application that has a Textbox (accepts min 1 and max of 26 chars length) that accepts characters from a-z, if the user is a novice tester then it will first enters a, b … z individually then will group them as aa, ab, … az, then will increase the order and combinations and then finally come up at the point where he has to enter all characters as abcde…z in that Textbox. This kind of testing is exhaustive testing which is extremely undesirable.

The solution for the Exhaustive testing appears to be resolved by boundary values as follows:

If I am going to test that Textbox in my application I will create following test cases to get the same degree confidence that required by Exhaustive Testing.

1. Enter nothing (leave the textbox blank) application remains intact error/warning is displayed depending on requirement.
2. Enter a or any other SINGLE character only
3. Enter ab or any other TWO character only
4. Enter abc..y or any combination of 25 characters only
5. Enter abc…z or any combination of 26 characters only
6. Enter abc…za or any combination of 27 characters only, error/warning is displayed depending on requirement.

I anticipate, the idea is a bit clear about Exhaustive Testing by considering above two examples and it is very obvious which way is more effective and efficient.

Let’s look at the scientific part of the Exhaustive Testing. You know that English alphabets composed of 26 letters and the Textbox above is also a maximum of 26 length, therefore there are “6.1561195802071573107966742884002 e+36” that many combination that you have to test for that single Textbox which is impossible. If you are thinking to automate this textbox then you are fooling yourself, the amount of logic required to test this textbox will also be cumbersome. Once you try to find the solution for this then you will say test case 1 to test case 6 is the better solution.

What is Test Scenario?

Test Scenario

Test Scenarios, as it little obvious with its phrase. Scenario is something which is meaningful. Let’s take an example of routine life – as in submitting a utility bill in queuing in front of the local bank or via your cell phones. Doing that scenario you have to meet some conditions (i.e. by date available for the bill) and some valid documents (utility bill). Available Date and Utility bill itself meaningless in someway until it is submitted/cleared. Therefore, all the steps you will take to submit your utility bill will become a SCENARIO. Thinking all these steps in computer software context is a Test Scenario if an automated systems is put into place in the bank and you are testing the utility bill scenario in that software application.

Technically, test scenario is group of test cases to achieve/complete desired goal (objective) with the software application.

Let’s take the other example step-wise.

How do you check your emails? Checking emails is Test Scenario… How?

1. Launch browser or tab
2. Enter mail.google.com
3. Provide user-id password
4. Press Login

Step 1 to 4 as a whole represent a Test Scenario, if you successfully managed to see your emails the Test Scenario is passed otherwise it will be considered as failed

Formally, “steps required to complete a meaningful activity is a test scenario”

In the above example steps 1 to 4 are individual test cases in order to test individual steps.

Test Scenarios are the cornerstone of Scenario Based testing.