Functional Test Plans: The Right Way!, Page 2
Please review a test case template below:
|Test Case #||Required Input||Expected Results||Results||Pass/Fail|
|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.
Test Case 1. Remove [UserName: "A": --> username: "A"] from the LDAP Server.
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.
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.
Page 2 of 2