Functional Test Plans: The Right Way!

Developer.com content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.

In this article, you will discover the role of the functional test plan in the context of the full development cycle. You will also be presented with a template for a functional test plan document. And finally, and most importantly, you will be presented with arguments supporting the use of the functional test plan as a critical step of the application development life cycle.

Functional Test Plan Definition

First, examine the definition of the functional test plan. As my professional career takes me from organization to organization, I notice that different people define the function test plan in different ways. I will concentrate on the definition that I feel is more appropriate in the context of the testing life cycle of an application.

“The functional test plan measures the quality of the functional components of the system.”

The functional test plan is not testing the underlying implementation of the application components. It is testing the application from the customer’s viewpoint. The functional test is concerned with how the application is meeting business requirements.

Functional Test Plan Audience and Author

When creating a functional test plan, one must realize that it should be geared towards a non-technical audience. Therefore, references to underlying programming languages must not be present in the final document. The Author of the functional test plan must be a person who has in-depth knowledge of the business requirements. It is preferable that application developers do not compose functional test plans. The reason behind such an approach is simple: The developer’s interpretation of the requirements might differ from those of the person who initially created them. The developer will almost subconsciously create test cases that will meet the functional requirements. He or she will be tempted to look for the functionality based on the implementation rather than re-examining the functional specifications.

Timing

It is very important that you begin creating the functional test plans as early as possible. The work on the test plans can start as soon as the functional specification documents are completed. The test cases can reveal flaws in the functional specs. They also can help application designers translate the functional specs into a more accurate application design. A functional test plan is a dynamic document. It must constantly reflect the always-changing business requirements. So, even when the document is completed, it will most likely need to change.

Functional Test Plan Life Cycle

Figure 1

Figure 1 depicts the participants and their interactions with the functional test plan. The Author creates and revises the test plan including test cases, expected results, and pre- and post-test setup. The Tester executes the test plan by performing actions listed in each test case and records actual results into a separate document that is the copy of the function test plan (more on that in the “Test Plan Execution” section) but with the actual results of the test. The Reviewer compares the actual results with the expected results and determines whether the test case passed or failed the functional requirements.

Document Structure

It is a good practice to have separate test plans for each use-case of the application. For example, a login and a policy search use cases should be separated into two documents.

The functional test plan consists of six distinct sections:

1. Update History: This section lists names, dates, and update descriptions to the document. The usual layout of this section looks like this:

Update Date	Update Description	Updated By
07.19.2006	Updated Test Case #7. Added extra step to check for user	Joe Smith

2. Document Purpose: This section contains a list of all functions being tested by this test plan. It is a good idea to attach a use-case diagram that might give a different perspective of the functions being tested.
3. Pre-test Setup: Some test cases might require persistence state to run through the steps. This section should include instructions on how to run scripts to populate the persistent data stores or create the data using another application.

For example, you can provide the following information in this section:

Test Case 1. Create new user profile.

[UserName: "A": --> username:     "A"]
[UserName: "A": --> first name:   "John"]
[UserName: "A": --> last name:    "Smith"]
[UserName: "A": --> access level: "read-only"]
[UserName: "A": --> password:     "profile1"]

As you can see, I provided a pre-test setup for Test Case 1. Note that the [] square brackets denote that this element will be used as a parameter in the test case described in the document.

The information in the square brackets can be interpreted as follows:

[Object Name: "Object Reference Name" -->
   Object Parameter: "Object Parameter Value"]

Object Reference Name represents one of the objects of the application. For example, User Profile or Policy Search Form would constitute an object.

Object Parameter Value represents an element within the object. For example, username is an element of the User Profile object.

When the Author creates a test case, he or she can refer to parameterized values like this:

[UserName: "A": --> username]

4. Test Cases: This section contains a list of test cases where each test case verifies a set of “clear-defined” functions of the use-case. For example,
• Verify that only valid users can access the system.
• Verify that valid users cannot access the system without entering a valid password.

Please review a test case template below:

Test Case #	Required Input	Expected Results	Results	Pass/Fail
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.

5. 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.

6. 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.