Equivalence partitioning & Boundary value analysis
Practically, due to time and budget considerations, it is not possible to perform exhausting testing for each set of test data, especially when there is a large pool test cases. We need an easy way or special techniques that can select test cases intelligent from the pool of test-case, such that all test scenarios are covered.
For that, we use two techniques - Equivalence Partitioning & Boundary Value Analysis testing techniques.
Equivalence Partitioning – It is a black box technique (code is not visible to tester) which can be applied to all levels of testing like unit, integration, system etc. In this technique, you divide set of test condition into partition that can be considered the same. To get a better idea let see an example.
Let's consider the behavior of tickets in the Flight reservation application, while booking a new flight.
Ticket values 1 to 10 are considered valid & ticket is booked. While value 11 to 99 are considered invalid for reservation and error message will appear, "Only ten tickets may be ordered at one time".
Here is the test condition
Any Number greater than 10 entered in the reservation column (let say 11) is considered invalid.
Any Number less than 1 that is 0 or below, then it is considered invalid.
Numbers 1 to 10 are considered valid
Any 3 Digit Number say -100 is invalid.
We cannot test all the possible values because if done, number of test cases will be more than 100.To address this problem, we use equivalence partitioning hypothesis where we divide the possible values of tickets into groups or sets as shown below where the system behavior can be considered the same.
The divided sets are called Equivalence Partitions or Equivalence Classes. Then we pick only one value from each partition for testing. The hypothesis behind this technique is that if one condition/value in a partition passes all others will also pass. Likewise, if one condition in a partition fails, all other conditions in that partition will fail.
Boundary Value Analysis- in Boundary Value Analysis, you test boundaries between equivalence partitions
In our earlier example instead of checking, one value for each partition you will check the values at the partitions like 0, 1, 10, 11 and so on. As you may observe, you test values at both valid and invalid boundaries. Boundary Value Analysis is also called range checking.
Equivalence partitioning and boundary value analysis are closely related and can be used together at all levels of testing.
What is Decision Table Testing?
Decision Table Testing is a good way to deal with a combination of inputs, which produce different results. It helps reduce test effort in verifying each and every combinations of test data, at the same time ensuring complete coverage
Example: To understand the importance of Decision Table Making we will see an example, let's consider the behavior of Flight Button for different combinations of Fly From & Fly To.
Rule 1:When destination for both Fly From & Fly To are not set the Flight Icon is disabled. In the decision table, we register values False for Fly From & Fly To and the outcome would be False, which is Flights Button will be disabled. Likewise, you can decide different outcome for different situation.
Rule 2: When Fly From destination is set but Fly to is not set, Flight button is disabled. Correspondingly, you register True for Fly from destination in the decision table, and the rest of the entries are false.
Rule 3: When Fly from destination is not set but Fly to destination is set, Flight button is disabled and you make entries in the decision table.
Rule 4: only when Fly to and Fly from destinations are set, Flights button is enabled and you make the corresponding entry in the decision table.
If you observe the outcomes for Rule 1, 2 & 3 it remains the same. So you can select any one of them and rule 4 for your testing.
The significance of this technique becomes immediately clear as the number of inputs increases. Number of possible Combinations is given by 2 ^ n , where n is the number of Inputs. For n = 10, which is very common in the web based testing, having big input forms, the number of combinations will be 1024. Obviously, you cannot test all but you will choose a rich sub-set of the possible combinations using decision based testing technique
What is State Transition Testing?
This tutorial explains the State Transition Testing Technique which is helpful where you need to test different system transitions.
For example, we have a flight reservation login screen, consider you have to enter correct agent name and password in the login screen to access the flight reservation application at first attempt. It gave you the access to the application with correct password and login name, but what if you entered the wrong password. How system decides how many login attempts should be allowed to users for the login screen with the wrong password before it finally closes the application. For our flight reservation application, we allowed 3 attempt, and if users enter the wrong password at 4th attempt, the system close the application automatically. So, testing for scenario 1 with the correct password and the 4th scenario with an incorrect password is compulsory, for that we use state transition testing.
You can use State Table to determine invalid system transitions. In a state Table, all the valid states are listed on the left side of the table, and the events that cause them on the top. Each cell represents the state system will move to when the corresponding event occurs.
For example, while in S1 state you enter a correct password you are taken to state S6 (Access Granted). Suppose if you have entered the wrong password at first attempt you will be taken to state S3 or 2nd Try. Likewise, you can determine all other states. Two invalid states are highlighted using this method which basically means, what happens when you are already logged into the application and you open another instance of flight reservation and enter valid or invalid passwords for the same agent.
What is Use Case Testing?
A use case is a description of a particular use of the system by an actor or user. It is used widely in developing tests at system or acceptance level.
The Use-Case Testing Technique helps identifying test cases that cover the entire system, on a transaction by transaction basis from the start to finish.
In a use-case, an actor is represented by "A" and system by "S". First we list the Main Success Scenario.
· Consider the first step of an end to end scenario for a login functionality for our Flight Reservation application where the Actor enters Agent Name and password to login into the Flight Reservation application.
· In the next step, the system will validate the password
· Next, if the password is correct, the access will be granted
· There can be an extension of this use case. In case password is not valid system will display a message and ask for re-try four times
· Or if Password, not valid four times system will close the application
Here we will test the success scenario and one case of each extension.
What is Static Testing? What is a review ?
Static techniques are testing techniques in which the code is not run. Its counter-part is Dynamic Testing which checks an application when code is run.
Code review , inspections ,walkthroughs , technical review are some static testing methods.
A review is the most important testing technique.
This tutorial describes how reviews carried out with help of a case study.
· In the Follow -up phase , the moderator will circulate the reworked document all
review participants and ensure that all changes have been included satisfactorily.
review participants and ensure that all changes have been included satisfactorily.
· This was a generic review.
· Note that, there are three types of reviews
· Walk Through , which is led by Author
· Technical Review , which is led by a trained moderator with No management
participation
participation
· Inspection ,which is led by trained moderator and use entry and exit criteria
· All these 3 types follow the same review process and follow the same stages as
discussed earlier.
discussed earlier.
No comments:
Post a Comment