The first step in testing an application always involves understanding the application requirements and its functionality. This typically involves identification of the major Test Scenarios in the application. For example, Login, Registration, Ticket Reservation, Ticket Cancellation, Ticket Status, etc may be common scenarios of a Reservation System. Hereby, one has to ensure that none of the functionality should be missed during identification of scenarios.
It is worth noting however, that identification of scenarios is different from determining different flows that each of these scenarios would cover. For example, a scenario such as “Cancel Reservation” may typically be identified, but one still needs to determine what flows this scenario may cover – this scenario may have a flow where we try to cancel a reservation that does not exist or try to cancel a reservation performed by some other user, etc.
Identification of Unit Tasks:
Once the major scenarios to be tested are identified, one is required to magnify into each of the scenarios to determine exact way in which the scenario are to be tested. The first step to perform this magnification is the process of determining unit tasks.
A unit task is a set of one or more user-actions that will always involve a single flow of action within that unit task.
Some of the example unit tasks for a reservation system could be as follows:
Inputting a user-name and password and pressing Login button
Inputting a set of user details and pressing Submit button for registration
Entering user information to reserve a ticket
Searching for a reservation status by inputting Reservation ID
Inputting a Reservation ID and cancelling the reservation.
For the first example in the above list, application may behave differently for entering valid/ invalid login information thus, exhibiting different flows. Here, one flow would be a user entering valid login details and thus allowed to login and another flow would be him entering invalid login details and thus notified with appropriate error message. But, the process of user entering username and password and then pressing login button would always remain same – thus considered to be having a single flow in it-self. So, we can consider this set of user actions as a unit task.
Similarly, suppose certain registration functionality is divided into two screens, where the first screen asks for username, password, address and has a checkbox for “I possess a mobile phone”. Now, only when this checkbox is checked, a second screen prompting for mobile information is displayed, other wise the user is registered straightaway. Here, we cannot term entire registration as a single unit task.
It can be clearly seen that complete registration has two flows – one where user may opt for mobile information and other when he doesn’t. So, we would have two unit tasks here – one for the first screen and other for the second one.
However, it is very important to note that a unit-task cannot be mapped to a single user-screen/ web-page. Many complex applications may have multiple flows within a single screen. On the other hand, many times a set of screens/ web-pages may be part of a single flow only, thus forming a single unit tasks only.
The process of identifying unit task is the first step in creating functional flow document so it is very important to ensure that this identification is done in a correct manner to ensure correctness of subsequent tasks.
The key to determine correctness of unit tasks is to ensure that no branching of functional flows exists within a unit task itself. If a unit task may contain a branching of flow within itself, such a branching may be missed during formation of functional flow matrix, thus leading to incorrect and incomplete analysis.
RELATED POST
WHITE BOX TESTING
WHITE BOX TESTING PART TWO
WHITE BOX TESTING PART THREE
WHITE BOX BASIC PATH TESTING
BLACK BOX TESTING PART ONE
BLACK BOX TESTING PART TWO
AUTOMATION IN TESTING
AUTOMATED TESTING TOOLS
AUTOMATED TESTING ANALYSIS
AUTOMATION BEST PRACTICES
AUTOMATED TESTING PROCESS
CHECK POINTS IN AUTOMATED TESTING
SILK TEST
SILK TEST INTRODUCTION
FEATURES OF SILK TEST
FEATURES OF SILK TEST PART TWO
LIMITATIONS
TEST PLAN FOR SILK TEST
INSTALLATION TIPS FOR SILK TEST
TEST CASES IN SILK TEST
No comments:
Post a Comment