Functional Test Plans: The Right Way!, Page 2

July 31, 2006
By Aleksey Shevchenko

Please review a test case template below:

Test Case #	Required Input	Expected Results
Verify that only valid users can access the system. Verify that valid users cannot access the system without entering a valid password.
1	Navigate to the login screen	Login screen with release number A is loaded.
2	Enter user name "INVALIDUSER", password "INVALIDUSER", and click on login button	Error message: "User name is not found"
3	Enter user name for user [UserName: "A":--> username] and password "test"	Error Message: "Password for user [UserName: "A": --> username] is invalid"
4	Enter user name [UserName: "A": --> username] and password [UserName: "A": --> password]	The main page is loaded with a message: "Welcome [UserName: "A": --> first name] [UserName: "A": --> last name]

As you can see, the Author of the test case does not populate the "Actual Results" and "Pass/Fail" columns. Furthermore, the Author must stay away from providing concrete test data for a test case.

Post-test Setup:The Author must provide instructions on how to clear any data that would prevent this test plan from being executed more than once.

For example:

Test Case 1. Remove [UserName: "A": --> username: "A"] from the LDAP Server.

Test Results: This section is reserved for the information supporting the actual test results. The Tester of the test plan populates this section. It can contain such items as SQL Run Results or screen shots.

Test Plan Execution

When all of the test cases are completed, the Tester can execute the test plan. The Tester must follow the steps of the "Pre-test Setup" of the test plan. After the pre-test setup is complete, the Tester should follow the steps of the "Required Input" section of each test case and record the results in the "Actual Results" section. The Tester should record any supporting information into the "Test Results" section of the document. The Tester should not attempt to compare expected and actual results.

The newly created version of the test plan is saved as a new document that represents one test run of this particular test plan. This allows you to come back to this test plan execution without cluttering the master test plan with test results. It also allows you to come back to the previous executions of this even when the master test plan changes.

Reviewing Test Results

Reviewing the test results should be a collaborative effort between the Business Clients and the Reviewer of the test results. The reviewer is responsible for comparing "actual" and "expected" results and determining whether the test case fails or passes business requirements. The test results are then reviewed by the business clients and resubmitted to the development team for bug fixes as necessary.

Conclusion

Now that you have reviewed the role of the functional test plan, you clearly can see its importance in the context of the application development cycle. Aside from its main goal, which is to test whether an application meets business requirements, it promotes communication between technical and business areas and helps development teams better understand business requirement.

Download Functional Test Plan template here: Functional_Test_Plan.doc (this is a Microsoft Word document).

About the Author

Aleksey Shevchenko has been working with object-oriented languages for over seven years. Aleksey has been implementing Enterprise IT solutions for Wall Street and the manufacturing and publishing industries.