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 third installment we consider how you get people to act based on the information you write in your test plan.

~~//~~

 

How do I get people to act?

All too often a test plan will be written and then forgotten about. Without action, however, you’ll never achieve the goals you set out to accomplish.

In order to get going you need to tell people what action they need to be taking. And you can’t do that unless you proactively circulate the information in the test plan.

Approaches for improving the distribution of the information in the test plan include:

#7 Identify responsibilities

In each area of the test plan, list the people who will find that section most relevant. When you identify the sections that are most pertinent for specific team members, then they only need to read that particular section. This will save your team time and frustration (because they won’t be forced to read information that doesn’t apply to them). For example, the test task section may only be applicable to the test analysts and testers.

#8 Hold regular update meetings

When you have completed the test plan draft, or when you make significant updates to the test plan, hold review meetings to go over the updated information. With the amount of information people are expected to absorb these days it’s not unusual for a 30-page document to go unread by most people.

Holding update meetings means that your team is forced to take some time out to process the information you’re trying to get across.

#9 Refer to the test plan regularly

When in project meetings, team meetings, or casual conversations make sure you regularly talk about the test plan and what will need to happen to get it done. This helps increase the visibility of the plan and emphasizes the importance of the information it contains.

#10 Increase the visibility on your intranet

Get a link to your test plan placed prominently on the project web page and ensure that each time the test plan is updated that the link gets highlighted again. Increasing the visibility of the test plan so that people have easy access to it is essential. Don’t just leave it in an anonymous directory on a server somewhere and expect people to find it.

#11 Translate the plan into a To-Do list

Turn all the possible pieces of information in the test plan into a To-Do list that you can reference on a regular basis. Assigning completion dates and owners to each action helps ensure that each task is assigned to a single person with the aim of completing the action by a certain date.

For example, you might have identified a certain risk area within the application. What you should do is assign a tester to review that risk on a monthly basis with the appropriate developer. This is something that would go on your To-Do list.

Review and update your To-Do list on a regular basis.

#12 Consider outside help

Use an application like QaTraq to organize all of your information in one place, and to help keep your test plan in front of your team on a daily basis. QaTraq can help you and your team:

• Improve the quality of your product releases. Because you can report on and track your testing against the test plan, your products will be of higher quality. This means you’ll improve the reputation of your company and increase your product credibility.
• Reduce support cost. When you can identify quality issues earlier in the development process, you don’t have to spend as much time mired down fixing problems that customers report.
• Reduce the time to market. With QaTraq, it’s easier to prioritize the testing so you don’t waste time testing the functions that really won’t make a difference.
• Easily pull together information to support the release decision. We can provide you with reports to identify the quality of your product and the coverage of the testing.
• Quickly see who is responsible for testing what, and see the progress they are making. With QaTraq you can clearly assign work to testers and track their progress, which saves you time and frustration.

 

~~//~~

 

Conclusion

Writing a test plan isn’t always easy. Many people struggle with the process. You might have started one in the past, only to stop because no one was reading it, let alone using it to guide their day to day testing efforts.

If it’s not done right then yes, a test plan can be a huge waste of time. But, it doesn’t have to be. If you can put the right information in the test plan, get the information from the right sources, and inspire people to act then a test plan can be well worth the time you put into its creation.

Finally, don’t forget that the test plan should be a living document. Update it on a regular basis, and keep your team in the loop every time there is a significant change. Don’t expect everyone to just read the test plan when you email them a copy; talk to your team about the changes, keep the test plan accessible and follow up with them to make sure they’re staying up to date.

What to do next

Traq Software have developed QaTraq Professional to help test teams take control of their testing, to help you keep your test plan in front of your team and to get your test team following your test plan. QaTraq Professional is one of the leading test planning tools available today, providing the foundation that teams need to create and track test cases, test plans and test results.

To sign up for a free 30 day hosted trial account for QaTraq Professional just click the link below, sign up and we’ll send you your account details in an email. This 30 day free trial gives you immediate access to one of the leading test plan management applications.

http://install.traqhost.com/hostedtrial.php

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.