tcf{tc}

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 em>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:

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]

• Verify that only valid users can access the system.
• Verify that valid users cannot access the system without entering a valid password.