Obtaining the Flow of Transaction:-  The transaction flows can be mapped into programs such that the flow of transaction will be created easily. The processing of the transactions is done inthe design phase. The overview section in design phase contain the details of the transaction flows. Detailed transaction flows are necessary to design the system's functional test.

 Transaction flows are similar to control flowgraphs  where the act of getting information can be more effective. Therefore, the bugs can be determined. The flow of transaction in design phase is done step by step such that the problems wouldn't arise and a bad design can be avoided.

 Transaction Flow Testing Strategies: Transaction flow is sequence of steps for a system to be tested. The transaction flow begins at the preliminary design and continues as the project progresses. The following testing strategies  has been taken.

1. Inspections: Inspections are the most cost effective quality processes  that  holds for testing. The process  include different phases such as "design phase, coding, testing, desk checking and debugging".

An inspection is a technique to detect errors by reading a group of code. This is often done by the developers or the programmers. A checklist is been compared with the code to  check errors. The duties of the programmer include,failures,

(1) Distributing the requirements, scheduling and inspecting the module.

(ii) Leading the session or module.

 (iii) Detecting the errors.

 (iv) Confirming that errors are corrected.

 Inspection is a methodology that humans can do and the computers can't. some of the example are,

 (1) Checking Syntax Errors: There would not be any syntax errors after inspection if humans do syntax

Checking.

(2) Referencing Program: The language processor cross check the undeclared variables, uninitialized values and be tables that are not been referred in the program. This is a tough job to be done by humans.

(3) Violating Rules: A program have some rules for declaring variables, labels, functions, subroutines and so  on. There may also be some conventions for the usage of memory. Hence, violation of these conventions (rules) is a form of syntax checking. A problem occurs for the language features that support automatic checking.  If the facilities for an automatic checking are not available then the person should check or inspect the code manually. The program is processed by examining  one convention at a time, rather than checking all  conventions simultaneously. It is a faster process to read the program for different conventions at different times.

(4) Comparison of Code: It is a mind-boggling task where the coding sheet is compared character by character to the code on keypunch cards.

(5)  Referencing Code: When a program is directly entered into a PC, the code is been referred or read by a programmer. It is an easier and faster way to check the errors for data structures, control flow and also for processing.

(6) Comparing Flowgraph: The flow graph is created from  the compiled code and compared to the design flowgraph. It's not an automatic task for comparing purpose.

(7)Sensitizing Path Inspection: The inspection should be path sensitizing i.e. the code cannot be forced to check bugs. Once the values of sensitizing paths have been found then necessary checking is done to every line of code involved in the control flow.

2. Reviews: Reviews are used to check the semantics (meaning) of a document. The quality of the documents can be examined and assured by eliminating the defects and mistakes from the documents. These inconsistencies can be found after the completion of document.

       The term review is a process involved with different techniques. It has the following phases in process.

(i)Review Planning: During planning phase, the documents in the software development process are assigned a review technique.

Every individual review has a review leader and a review team of its own. The document is read and checked from different points while planning the review.

(ii)Review Document Information: All necessary information is provided when the review team is formed. The information about the document is shared and reviewed. The reviewed document must be used to he decide if a particular statement is correct or wrong.

(iii)Preparing Review Meeting: The review meeting is  prepared by individual review team members. The inconsistencies and the defects are checked by the reviewers against the documents.

(iv)Objective of Review Meeting: The review meeting is handled bv a review leader. The review leader must ensure that the requirements of all the reviewers has met to find the defects and will be able to express their opinion without any fear.

(v)Taking Different Process: The review manager selects a different technique on the basis of the review results.

(vi)Review Scheduling: If the result of the first review was not acceptable, then another review will be organized by the review manager to correct the defects. Depending upon the review object, reviews can be classified as follows,

        (a) Feasibility Reviews: This review depends upon the logical flow of the document. Here, every unit in the document is feasible to test.

        (b)  Requirements Reviews: This review depends upon the requirements or attributes in the  document. A  system in this reviews can handle the structural limits of a transaction.

3.Walk Throughs: A walk through is an informal review method compared to the other types of reviews. It is a way of finding defects or problems or anomalies in the written documentation In the review meeting, scenarios are walked                   through i.e., the reviewers try to reveal defects and problems by asking questions.Walk through is a technique or a set of procedures to detect errors by reading a group of code. It is often used as part of testing cycle. Walk through has           a team similar to that of a reviewer team and consists of three people.

      (i) The first person plays the role of a secretary to record errors.

      (ii)The second person is similar to that of the a view leader (which handle the team).

      (iii)The third person plays the role of a tester to clear the defects.

During the meeting, the tester comes with a set of inputs to walk through the logic flow of the program. Each test case is individually executed and must be simple because the errors

found in the process of questioning the programmer are more than the errors found by the test cases.

4. Selection of Path for Transaction Flow Testing: The path selection for system testing that is based on transaction flows from the other unit tests that are based on control flowgraphs.  A longest path is taken to find the bugs in the module. The path is reviewed and the bugs are removed from all the

interfaces of the module after reviewing process is completed.

5. Act of Sensitization: The simple paths are easy to sensitize in transaction flows. It is the act of defining transaction. Some paths are difficult to sensitize and therefore these paths result in a bug transaction flows.

6. Measurement: During processing of modules, the information of the path taken for a transaction must be kept Since it plays an important role in the transaction flow testing.

7. Transaction Flow Databases: Every tester or programmer design his own unique database. The test databases in transaction flows are configuration sensitive. Here, every tester needs exclusive usage of system. Therefore, the test databases must be designed using configuration controlled and centrally administered systems.

8. Execution: From starting, the transaction flow testing is committed to test the execution part automatically.