Data Flow Testing

Over the last decade, the extraordinary growth in the World Wide Web has become widespread throughout business and industry. There are a number of companies who have used and are still using web technologies to establish or incorporate their mission-critical applications. As web applications get more and more complex, hence qa testing becomes not only crucial, but also challenging. rnBasically, data flow testing is a white box testing approach. Herein, we test the variable definitions and their use in the program to find out anomalies. Test cases are created based on the data flow within the code and the system. By performing data flow testing, transaction and greater, test coverage can be achieved. Usually, this type of testing is applied on the lowest level. At system and integrated level tests, it also considers the risk analysis which drives the key permutations.rnThe main strategy of data flow testing is based on selecting paths through the program’s control flow in order to explore sequences of events related to the status of data objects. The tester has to cover enough paths to ensure that every data object has been initialized before its use and all defined objects have been used at least once. Data objects containing data values have a distinct life cycle. They are created, used, and then killed.rnThe patterns of data usage are characterized by data-flow anomalies, which may generate some improper or incorrect implementation of the code. These anomalies have been noted to be not only dangerous, but also suspicious, which denotes that slip-ups or miscalculations can happen. There are two techniques that are widely used, in this space: rn1. Static Data Flow Testingrn2. Dynamic Data Flow TestingrnStatic data flow testing is done on source code without really executing it. This approach helps in uncovering bugs like syntax errors. While this is a useful technique, this alone will not suffice. QA Testing for Static data-flow is not appropriate to use as it might collapse in certain scenarios where the state of data variable cannot be determined by examining the code. rnAs web applications get more complex leading to difficult control flows, it may be possible at times that certain paths can never be executed. To make this clearer, let’s take an example of an array, i.e. collection of data elements that share the same name and type. Arrays can be demarcated and demolished as a group, but a few distinctive elements of array are used separately. Static data flow testing cannot ascertain if the define-use-kill guidelines have been charted appropriately unless every single element is taken into account individually.rnThe main goal of dynamic data-flow testing is to expose the possible number of errors while implementing the program code. Test cases are developed to trace every definition to each of its use where every use is traced to each of its definition. There are so many strategies that are engaged for the creation of test cases. rnSome such strategies from qa testing point of view in Data Flow Testing are as outlined below:rnAll Definitions: Every definition of every variable be covered by at least one use of that variable, be that a computational use (C-use) or a predicate use (P-use).rnAll Predicate Uses: In this, test cases are created for providing at least one path of each variable definition to each P-use of variable.rnAll Computational Uses: In this, test cases are created for providing at least one path of each variable definition to each C- use of variable.rnAll P uses Some C uses: In this, test cases are created for every variable; there is a path from every definition to every P-use of that definition. If there is a definition with no p-use following it, then a c-use of the definition will be considered.rnAll C uses Some P uses: In this, test cases for every variable, there is a path from every definition to every C-use of that definition. If there is a definition with no c-use following it, then a p-use of the definition will be considered.rnAll uses: In this strategy, at least one path of every variable from every definition can be reached by that definition to every use.rnAll du paths: A definition-clear path (value is not replaced on path) on the Control Flow Graph starting from a definition to a use of a same variable. Data flow testing strategy is the strongest testing strategy. Every du path from every definition of every variable to every use of that definition is considered here.rnAs mentioned earlier, all data-flow anomalies are not damaging; however, they are suspicious and suggest that an oversight is possible. So we have to emphasize more on these strategies to ensure the quality of the product under test. These strategies always help to identify and modify those anomalies in the early stages of the product life cycle.rnIn conclusion, we can say that the methods discussed for data flow testing can be applied with suitable analysis. Data flow testing can help understand the workings of the code (for both the tester and developer), and positively increase the number of faults that are detected in the system during qa and testing. It means that at least limited data flow testing should be earnestly contemplated during the testing process.