Essential Software Testing Tools Blog

Over a period of three weeks we are looking at creating software test plans that actually make a difference, in an easy step-by-step formula. We are covering the three main areas you need to consider as part of software test planning, as well as 12 checklist points that should be addressed in every software test plan. In this second installment we consider where you will find the right information for your software test plan.

~~//~~

 

Where do I find the information I need for the test plan?

#4 From other teams involved in the project

A significant amount of information for the test plan will not come from the test team itself. For example, to identify the areas required for testing you’ll be dependent on the application designers and architects. To help detail risks for the test project, you’ll need to work with the developers and start a discussion about the areas of the application that are likely to prove more difficult to code.

You will only start to build up an accurate picture within the test plan when you have collated important information from the project managers, application architects, application designers, developers, and customers. For example the project manager should be able to provide key milestone dates and help you define the deliverables. The business analyst will be able define the features to tested based on the requirements document he or she produces.

#5 Past evidence from previous projects

When it comes to completing the schedule and staffing sections of the test plan you can find a wealth of information from previous projects.

For example, where you have reusable regression test scripts from previous projects you should be able to accurately assess the amount of time it took to run these regression tests. Then, you can feed this information right into the test plan schedule.

Where you have had project review meetings from previous projects you should be able to take the “areas where we could have done better” and identify them early in your new projects.

Learning from past mistakes is essential to any improvement process, so feeding the lessons learnt from previous projects directly into the test plan at the start of a new project can prevent you from repeating those mistakes.

#6 Sometimes the information you need just isn’t available yet

Yes, it’s frustrating, but it’s going to happen. There are going to be times when the information you need for the test plan just won’t be available when you need it.

For example, at the beginning of a project, before the development team has even started coding, they’re probably not going to be able to tell you what sort of build schedule they expect to be working towards.

The trick here is to be clear about what you don’t know. Call this out plainly. Explain who is responsible for providing this information, and when it is they expect to be able to provide it. Don’t forget to follow up on a regular basis to see if the information is available. Typical information that is not available at the beginning of the test project includes; the build schedule, a complete list of features to be tested, feature delivery dates and full/complete requirements specification.

 

In the next post we will look at getting people to act on the information and instructions contained in your software test plan.

Over a period of three weeks we are going to look at creating software test plans that actually make a difference, in an easy, step-by-step formula. We’ll cover the three main areas you need to consider as part of software test planning, as well as 12 checklist points that should be addressed in every software test plan.

1. What information should be included in the software test plan
2. Where to find the right information for your software test plan
3. How to get people to act based on your software test plan

~~//~~

 

What information should I include in the test plan?

#1 Identify a clear goal

The main point of writing a test plan is so you and your team can achieve a specific goal (or goals). The aim is to clearly convey the information necessary to get all of your team pulling in the same direction to achieve that goal quickly and efficiently. If you can’t identify your goals clearly, or if you aren’t clear on your goals in the first place, then you shouldn’t waste your time writing a test plan yet. Once you have defined your goals, then state them clearly at the start of the test plan.

#2 Follow the IEEE Test Plan recommendations

The IEEE 829 Standard is a standard that defines a set of Software Test Documentation. The IEEE 829 standard aims to describe a set of basic software test documents that can be used to communicate a test approach. Within that standard is a template that provides a suggested list of items your test plan should include. You will find many useful articles on the Internet that cover the details of an IEEE 829 test plan, but two of the most useful are:

 

1) http://en.wikipedia.org/wiki/IEEE_829

2) http://online.gerrardconsulting.com/iseb/otherdocs/ieee829mtp.pdf

 

In short, the items that should be covered in an IEEE 829 compliant test plan are as follows:

1. TEST PLAN IDENTIFIER
This is some type of unique, company-generated number that will identify your test plan, its level, and the level of software that it is related to.

2. REFERENCES
List all documents that support your test plan. Documents that can be referenced include: the Project Plan, Requirements Specifications, High Level Design Document, etc.

3. INTRODUCTION
State the purpose of the plan, and possibly identify the level of the plan (master etc.).

4. TEST ITEMS (FUNCTIONS)
These are the things you intend to test within the scope of your test plan.

5. SOFTWARE RISK ISSUES
Identify what software is to be tested and what critical areas might present some inherent software risks. An example would be the complexity of a particular module.

6. FEATURES TO BE TESTED
This is a listing of what is to be tested from the USERS point of view.

7. FEATURES NOT TO BE TESTED
This is a listing of what is NOT to be tested from both the Users viewpoint and a configuration management/version control view.

8. APPROACH (STRATEGY)
This is your overall test strategy for the test plan, and should detail the rules and processes that will be followed (e.g. What metrics will be collected?).

9. ITEM PASS/FAIL CRITERIA
What are the completion criteria for this plan? This could be based on the test cases completed, the coverage provided and/or the level of defects identified.

10. SUSPENSION CRITERIA AND RESUMPTION REQUIREMENTS
It should be clearly stated that, in certain scenarios, testing will be suspended. You must identify what criteria must be met for the testing to resume.

11. TEST DELIVERABLES
What is to be delivered as part of this plan? This includes the test plan document, test cases, test design specifications, etc.

12. TEST TASKS
This section may contain descriptions of those test tasks that need to be completed by internal and external groups.

13. ENVIRONMENTAL NEEDS
Are there any special requirements for this test plan, such as special hardware or static generators?

14. STAFFING AND TRAINING NEEDS
How much time is required to complete the test effort, and what kind of training on the application/system is required?

15. RESPONSIBILITIES
Who is in responsible for completing each section of this test project?

16. SCHEDULE
This will include a detailed list of resources and the effort required. You can also link this information to realistic and validated estimates to complete the project.

17. PLANNING RISKS AND CONTINGENCIES
What are the overall risks to the project? Keep an emphasis on the testing process here.

18. APPROVALS
Who can, and will, approve the process as complete and allow the project to proceed to the next level?

19. GLOSSARY
The Glossary is used to define terms and acronyms used in the document, and testing in general, to eliminate confusion and promote consistent communications.

#3 What a test plan is not

A significant number of people in software development, product development, and the testing arena itself seem to think that a test plan is a collection of tests or test cases.

So, let’s start by stating categorically that a test plan is NOT a collection of tests.

Typically, a test plan is a document used to describe the course of action to help achieve a testing objective. A test plan is definitely NOT just a list of test cases. This confusion is one reason why the IEEE defined the IEEE 829 standard.

In the next post we will look at where we need to find the right information for your software test plans.