Test plan is one of the key component of the verification plan. It’s not a document that is created and thrown in some corner.  Test plan is a live map that guides verification to reach destination of meeting verification goals to achieve sign off.

What is test plan?

Test plan is an executable document listing various scenarios to prove the DUT will function as per the requirement specification and will not have any unintended side effects.

It’s achieved by listing of the complete set of scenario to be exercised. As the name says it’s a plan. It serves as a guide for the execution of the verification process.

What are some of prerequisites to be met before writing test plan?

Verification strategy, approach of verification in this case we are considering constrained random verification, clarity on directed vs. constrained random approach and broad functional division of the functionality.

Read more about prerequisites in test plan writing prerequisites.

How to write test plan ?

Test plan is about translating requirement specification in into verifiable description.

A verifiable description is rewriting or inferring the requirements from verification point of view aligned to verification strategy without any change to primary intent of specification.

This translation is done centered around the design, which is synthesizable transformation of the same requirement specifications.

This translation involves specifying various stimulus and checks required to confirm functionality. The entire functional specification is broken down into various areas and each area will have specific approach best suited to attack it from verification perspective.

Read more about the 8 steps or 8 dimensions to be considered to enumerate all the scenarios in test plan writing process.

Who should write the test plan?

First thing that comes into mind is, DUT designer should write the test plan himself. He knows the requirements specification and design.

Isn’t he best suited to do it?

No. It’s not recommended. Designer must review the test plan but it’s not advisable for designer of the DUT to write the test plan as well.

Writing test plan involves inferring and transforming requirement specification for the purpose of verification. This process of translation has possibility of misinterpretations. So when the designer does the interpretation for verification as well same assumptions as design can creep into the verification as well.

That’s why both the design team and verification team doing it independently is important. This guards against same misinterpretation affecting both design and verification.

What should be referred for writing the test plan?

Verification requirements are made up two sets of specifications:

1. Requirement specifications for design either in the form of standard specification or proprietary specifications used for the design
2. RTL design(DUT) micro-architecture specifications

The first one allows focusing verification from black box verification perspective. Test cases targeted for black box approach are applicable for all the DUTs implemented for this requirement specification. This is implementation independent.

Second one allows focusing on the white box verification. This will focus on the verification scenarios arising due to specific implementation. For example some internal FIFO full or underflow conditions, internal arbiter exercise conditions, verifying the entire register structure and its individual register properties etc.

Only way to ensure the completeness of test plan is manual reviews. To ease the manuals reviews it’s very important to reference it to specification and features.

Why test plan writer needs to know about verification strategy?

When the test plan is written without understanding the verification strategy, it will take one more layer of transforming the test plan to adapt it to verification strategy later. Every transformation is potential risk of missing something during the process of transformation and introducing the holes.

For example when the verification strategy for a set of features is coverage driven constrained random the details of the default randomization, global checks common to all tests, functional coverage of randomized parameters can be abstracted out of the test plan. Test plan can focus on the constrained random scenarios to be created.

It may be possible verification strategy is distribute the overall verification requirements into multiple testbenches. In such cases, it’s important to identify which tests should be executed in which testbench.

The clear idea about the verification strategy helps write a test plan that is aligned for execution to help achieve the desired results.

Verification strategy has to be defined before jumping into writing the test plan. Test plan is a plan to execute the verification strategy.

Who are stakeholders of a test plan?

Verification team owns test plan. Architecture and design teams contribute.

Test plan is typically written by the verification lead. If the bandwidth availability is a concern, verification lead should create the outline and senior verification engineers can complete it. Test plan is one of the key deliverables for verification activity signoff.

Although test plan is owned by the verification team contribution from the architecture and design team are vital for its success. Architects, design leads and design engineers should review test plan.

Verification engineers will use the test plan for writing the tests and update the test execution status back to the test plan.

Verification manager would use the test plan as reference for tracking the execution of the verification activity. The metrics such as total tests, total tests written, total failing tests, total passing tests, tests per owner, break up tests by different priority is all extracted from the test plan.

How test plan should be organized?

Test plan should be organized to cater to needs of creation, review, execution and tracking verification to closure.

To know how to achieve it read more about test plan organization.