The process of determining Test Scenarios for an application requires considerable analysis of the application to ensure that no particular functionality of the application remains untested. However, a much complex aspect that has to be analysed during designing of Test Cases is analysis of Functional Flow in an application.
This is important since a certain functionality of an application may be expected to behave differently under different Functional Flows. For example, a “Login” webpage in a website may prompt for a username and password when the user is not logged into the system, but it may not display the same when the user is already logged into the system.
From the testing perspective, it is important that the Test Case covers testing of login webpage for both the aspects – when user is not logged into the system and when the user is already logged into the system.
Generally, for common scenarios such as the one explained above, it may be easy to identify different possible conditions for a certain functionality, but with no formal technique, it is often very risky to design Test Cases in this manner.
For example, “Registration” functionality commonly has some unique field (such as username) and thus, may often require a Test Case to test if two distinct registrations do not accept exactly same values, or perhaps a “Update User Information” functionality should not allow one to change to username to same as that entered by some other user during “Registration”.
This demonstrates how simple and common functionalities also require in-depth analysis to ensure that Test Cases flows cover all the possible conditions. Moreover, Test Case coverage becomes much more complex yet important when the application and its functionalities are novel and complex.
Functional Flow Matrix is a simple yet effective document that can be used to analyse and take into consideration, different possible functional flows in an application while designing Test Cases. It is based on the concept of dependencies between different functionalities.
A functionality X is said to be dependent on functionality Y if occurrence of Y affects the behaviour of X.
For example, the functionality of “Reservation Cancellation” is dependent on functionality of “Ticket Reservation” in a Ticket Reservation System since a reservation cannot be cancelled unless it is reserved earlier.
So, “Reservation Cancellation” functionality would behave differently for the cases when reservation is already done and reservation is not performed. As a result, the test case flow for this functionality would require testing it without reservation being done earlier and also with a valid reservation performed earlier.
Such obvious dependency scenarios may often be easy to identify when we perform such dependency analysis between the functionalities subconsciously but, with Functional Flow Matrix, a thorough analysis of such dependencies between different functionalities enables higher confidence in quality of coverage of Test Scenarios.
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