Topic: Viable Automated Testing Methodologies!!!!!

Message

   Now that we’ve eliminated Record/Playback as a reasonable long-term automated testing strategy, let’s discuss some methodologies that I (as well as others) have found to be effective for automating functional or system testing for most business applications

The "Functional Decomposition" Method

The main concept behind the "Functional Decomposition" script development methodology is to reduce all test cases to their most fundamental tasks, and write User-Defined Functions, Business Function Scripts, and "Sub-routine" or "Utility" Scripts which perform these tasks independently of one another. In general, these fundamental areas include:

   1. Navigation (e.g. "Access Payment Screen from Main Menu")
   2. Specific (Business) Function (e.g. "Post a Payment")
   3. Data Verification (e.g. "Verify Payment Updates Current Balance")
   4. Return Navigation (e.g. "Return to Main Menu")

In order to accomplish this, it is necessary to separate Data from Function. This allows an automated test script to be written for a Business Function, using data-files to provide the both the input and the expected-results verification. A hierarchical architecture is employed, using a structured or modular design.

The highest level is the Driver script, which is the engine of the test. The Driver Script contains a series of calls to one or more "Test Case" scripts. The "Test Case" scripts contain the test case logic, calling the Business Function scripts necessary to perform the application testing. Utility scripts and functions are called as needed by Drivers, Main, and Business Function scripts.

    * Driver Scripts:

      Perform initialization (if required), then call the Test Case Scripts in the desired order.

    * Test Case Scripts:

      Perform the application test case logic using Business Function Scripts

    * Business Function Scripts:

      Perform specific Business Functions within the application;

    * Subroutine Scripts:

      Perform application specific tasks required by two or more Business scripts;

    * User-Defined Functions:

      General, Application-Specific, and Screen-Access Functions;

      Note that Functions can be called from any of the above script types.

Example:

The following steps could constitute a "Post a Payment" Test Case:

   1. Access Payment Screen from Main Menu
   2. Post a Payment
   3. Verify Payment Updates Current Balance
   4. Return to Main Menu
   5. Access Account Summary Screen from Main Menu
   6. Verify Account Summary Updates
   7. Access Transaction History Screen from Account Summary
   8. Verify Transaction History Updates
   9. Return to Main Menu

A "Business Function" script and a "Subroutine" script could be written as follows:

Payment:

    * Start at Main Menu
    * Invoke a "Screen Navigation Function" to access the Payment Screen
    * Read a data file containing specific data to enter for this test, and input the data
    * Press the button or function-key required to Post the payment
    * Read a data file containing specific expected results data
    * Compare this data to the data which is currently displayed (actual results)
    * Write any discrepancies to an Error Report
    * Press button or key required to return to Main Menu or, if required, invoke a "Screen Navigation Function" to do this.

Ver-Acct (Verify Account Summary & Transaction History):

    * Start at Main Menu
    * Invoke a "Screen Navigation Function" to access the Account Summary
    * Read a data file containing specific expected results data
    * Compare this data to the data which is currently displayed (actual results)
    * Write any discrepancies to an Error Report
    * Press button or key required to access Transaction History
    * Read a data file containing specific expected results data
    * Compare this data to the data which is currently displayed (actual results)
    * Write any discrepancies to an Error Report
    * Press button or key to return to Main Menu or, invoke a "Screen Navigation Function"

The "Business Function" and "Subroutine" scripts invoke "User Defined Functions" to perform navigation. The "Test Case" script would call these two scripts, and the Driver Script would call this "Test Case" script some number of times required to perform all the required Test Cases of this kind. In each case, the only thing that changes are the data contained in the files that are read and processed by the "Business Function" and "Subroutine" scripts.

Using this method, if we needed to process 50 different kinds of payments in order to verify all of the possible conditions, then we would need only 4 scripts which are re-usable for all 50 cases:

   1. The "Driver" script
   2. The "Test Case" (Post a Payment & Verify Results) script
   3. The "Payment" Business Function script
   4. The "Verify Account Summary & Transaction History" Subroutine script

If we were using Record/Playback, we would now have 50 scripts, each containing hard-coded data, that would have to be maintained.

This method, however, requires only that we add the data-files required for each test, and these can easily be updated/maintained using Notepad or some such text-editor. Note that updating these files does not require any knowledge of the automated tool, scripting, programming, etc. meaning that the non-technical testers can perform this function, while one "technical" tester can create and maintain the automated scripts.

It should be noticed that the "Subroutine" script, which verifies the Account Summary and Transaction History, can also be used by other test cases and business functions (which is why it is classified as a "Subroutine" script rather than a "Business Function" script) – Payment reversals, for example. This means that if we also need to perform 50 "payment reversals", we only need to develop three additional scripts.

   1. The "Driver" script
   2. The "Test Case" (Reverse a Payment & Verify Results) script
   3. The "Payment Reversal" Business Function script

Since we already had the original 4 scripts, we can quickly clone these three new scripts from the originals (which takes hardly any time at all). We can use the "Subroutine" script as-is without any modifications at all.

If different accounts need to be used, then all we have to do is update the Data-Files, and not the actual scripts.  It ought to be obvious that this is a much more cost-effective method than the Record/Playback method.

Advantages:

   1. Utilizing a modular design, and using files or records to both input and verify data, reduces redundancy and duplication of effort in creating automated test scripts.
   2. Scripts may be developed while application development is still in progress. If functionality changes, only the specific "Business Function" script needs to be updated.
   3. Since scripts are written to perform and test individual Business Functions, they can easily be combined in a "higher level" test script in order to accommodate complex test scenarios.
   4. Data input/output and expected results is stored as easily maintainable text records. The user’s expected results are used for verification, which is a requirement for System Testing.
   5. Functions return "TRUE" or "FALSE" values to the calling script, rather than aborting, allowing for more effective error handling, and increasing the robustness of the test scripts. This, along with a well-designed "recovery" routine, enables "unattended" execution of test scripts.

Disadvantages:

   1. Requires proficiency in the Scripting language used by the tool (technical personnel);
   2. Multiple data-files are required for each Test Case. There may be any number of data-inputs and verifications required, depending on how many different screens are accessed. This usually requires data-files to be kept in separate directories by Test Case.
   3. Tester must not only maintain the Detail Test Plan with specific data, but must also re-enter this data in the various required data-files.
   4. If a simple "text editor" such as Notepad is used to create and maintain the data-files, careful attention must be paid to the format required by the scripts/functions that process the files, or script-processing errors will occur due to data-file format and/or content being incorrect.

Author	Message
tanushree Senior Member Joined: 04Apr2007 Online Status: Offline Posts: 2160	Topic: Viable Automated Testing Methodologies!!!!! Posted: 01Oct2007 at 12:05am
	Now that we’ve eliminated Record/Playback as a reasonable long-term automated testing strategy, let’s discuss some methodologies that I (as well as others) have found to be effective for automating functional or system testing for most business applications The "Functional Decomposition" Method The main concept behind the "Functional Decomposition" script development methodology is to reduce all test cases to their most fundamental tasks, and write User-Defined Functions, Business Function Scripts, and "Sub-routine" or "Utility" Scripts which perform these tasks independently of one another. In general, these fundamental areas include: 1. Navigation (e.g. "Access Payment Screen from Main Menu") 2. Specific (Business) Function (e.g. "Post a Payment") 3. Data Verification (e.g. "Verify Payment Updates Current Balance") 4. Return Navigation (e.g. "Return to Main Menu") In order to accomplish this, it is necessary to separate Data from Function. This allows an automated test script to be written for a Business Function, using data-files to provide the both the input and the expected-results verification. A hierarchical architecture is employed, using a structured or modular design. The highest level is the Driver script, which is the engine of the test. The Driver Script contains a series of calls to one or more "Test Case" scripts. The "Test Case" scripts contain the test case logic, calling the Business Function scripts necessary to perform the application testing. Utility scripts and functions are called as needed by Drivers, Main, and Business Function scripts. * Driver Scripts: Perform initialization (if required), then call the Test Case Scripts in the desired order. * Test Case Scripts: Perform the application test case logic using Business Function Scripts * Business Function Scripts: Perform specific Business Functions within the application; * Subroutine Scripts: Perform application specific tasks required by two or more Business scripts; * User-Defined Functions: General, Application-Specific, and Screen-Access Functions; Note that Functions can be called from any of the above script types. Example: The following steps could constitute a "Post a Payment" Test Case: 1. Access Payment Screen from Main Menu 2. Post a Payment 3. Verify Payment Updates Current Balance 4. Return to Main Menu 5. Access Account Summary Screen from Main Menu 6. Verify Account Summary Updates 7. Access Transaction History Screen from Account Summary 8. Verify Transaction History Updates 9. Return to Main Menu A "Business Function" script and a "Subroutine" script could be written as follows: Payment: * Start at Main Menu * Invoke a "Screen Navigation Function" to access the Payment Screen * Read a data file containing specific data to enter for this test, and input the data * Press the button or function-key required to Post the payment * Read a data file containing specific expected results data * Compare this data to the data which is currently displayed (actual results) * Write any discrepancies to an Error Report * Press button or key required to return to Main Menu or, if required, invoke a "Screen Navigation Function" to do this. Ver-Acct (Verify Account Summary & Transaction History): * Start at Main Menu * Invoke a "Screen Navigation Function" to access the Account Summary * Read a data file containing specific expected results data * Compare this data to the data which is currently displayed (actual results) * Write any discrepancies to an Error Report * Press button or key required to access Transaction History * Read a data file containing specific expected results data * Compare this data to the data which is currently displayed (actual results) * Write any discrepancies to an Error Report * Press button or key to return to Main Menu or, invoke a "Screen Navigation Function" The "Business Function" and "Subroutine" scripts invoke "User Defined Functions" to perform navigation. The "Test Case" script would call these two scripts, and the Driver Script would call this "Test Case" script some number of times required to perform all the required Test Cases of this kind. In each case, the only thing that changes are the data contained in the files that are read and processed by the "Business Function" and "Subroutine" scripts. Using this method, if we needed to process 50 different kinds of payments in order to verify all of the possible conditions, then we would need only 4 scripts which are re-usable for all 50 cases: 1. The "Driver" script 2. The "Test Case" (Post a Payment & Verify Results) script 3. The "Payment" Business Function script 4. The "Verify Account Summary & Transaction History" Subroutine script If we were using Record/Playback, we would now have 50 scripts, each containing hard-coded data, that would have to be maintained. This method, however, requires only that we add the data-files required for each test, and these can easily be updated/maintained using Notepad or some such text-editor. Note that updating these files does not require any knowledge of the automated tool, scripting, programming, etc. meaning that the non-technical testers can perform this function, while one "technical" tester can create and maintain the automated scripts. It should be noticed that the "Subroutine" script, which verifies the Account Summary and Transaction History, can also be used by other test cases and business functions (which is why it is classified as a "Subroutine" script rather than a "Business Function" script) – Payment reversals, for example. This means that if we also need to perform 50 "payment reversals", we only need to develop three additional scripts. 1. The "Driver" script 2. The "Test Case" (Reverse a Payment & Verify Results) script 3. The "Payment Reversal" Business Function script Since we already had the original 4 scripts, we can quickly clone these three new scripts from the originals (which takes hardly any time at all). We can use the "Subroutine" script as-is without any modifications at all. If different accounts need to be used, then all we have to do is update the Data-Files, and not the actual scripts. It ought to be obvious that this is a much more cost-effective method than the Record/Playback method. Advantages: 1. Utilizing a modular design, and using files or records to both input and verify data, reduces redundancy and duplication of effort in creating automated test scripts. 2. Scripts may be developed while application development is still in progress. If functionality changes, only the specific "Business Function" script needs to be updated. 3. Since scripts are written to perform and test individual Business Functions, they can easily be combined in a "higher level" test script in order to accommodate complex test scenarios. 4. Data input/output and expected results is stored as easily maintainable text records. The user’s expected results are used for verification, which is a requirement for System Testing. 5. Functions return "TRUE" or "FALSE" values to the calling script, rather than aborting, allowing for more effective error handling, and increasing the robustness of the test scripts. This, along with a well-designed "recovery" routine, enables "unattended" execution of test scripts. Disadvantages: 1. Requires proficiency in the Scripting language used by the tool (technical personnel); 2. Multiple data-files are required for each Test Case. There may be any number of data-inputs and verifications required, depending on how many different screens are accessed. This usually requires data-files to be kept in separate directories by Test Case. 3. Tester must not only maintain the Detail Test Plan with specific data, but must also re-enter this data in the various required data-files. 4. If a simple "text editor" such as Notepad is used to create and maintain the data-files, careful attention must be paid to the format required by the scripts/functions that process the files, or script-processing errors will occur due to data-file format and/or content being incorrect. Post Resume: Click here to Upload your Resume & Apply for Jobs

	IP Logged


One Stop Testing Forum : Types Of Software Testing @ OneStopTesting : Automated Testing @ OneStopTesting