1. The scope of the testing that will be needed can be defined, together with possible sources of test data and an outline of the test cases which will be needed. This will be done at the time at which it is most clear to everyone on the project (both technical and user personnel) exactly what it is that will need to be programmed, and therefore exactly what tests will be required.

2. The strong focus on testing at this stage is almost guaranteed to highlight requirements and difficulties that would otherwise be missed during the requirements definition, and hence would need to be added (at a much greater cost) later.

Right throughout the project development, each phase of the "conventional" project development plan should have an equivalent testing phase as shown in the diagram below.

DEVELOPMENT PHASES
Conventional	Recommended Additional Parallel Phases
Requirements Analysis System design Design walk through Program design Code Code Inspection Unit testing Integration testing System testing Acceptance testing	Test Analysis Test design Test design walk through Unit test design Test creation Test inspection

NOTE: If you automate your tests, you will also need to include "Test the test" activities. This will take you a bit longer initially, but you will benefit every time a bug is fixed or a change is made.

This suggestion may still be considered somewhat radical in some organizations. Cries of "We don't have the budget for that sort of thing" will echo through the corridors. This kind of reaction is usually because the benefits and costs of this approach have not been properly researched and presented. The added cost burden of this approach is usually only a very small percentage of the total project budget, and by performing these tasks at the correct time the chances of bringing the project in on time and within budget are greatly increased. Think it through, prepare your case, and try to convince the rest of the team.

"Wait!", I hear someone cry, "I thought we were going to discuss the real world! I've just been given the task of developing the test plans for a new system, and the first software is due to arrive next month. (/week/tomorrow.... fill in your own times). What do I do?"

If this sounds a bit like your current predicament, read on. All is not lost, it just means you will have to be a bit more innovative, hard working, persistent, hard working, dedicated, hard working.... you get the drift.

So far we have only really considered the "when" of test plan development. In short, "when" should be as early in the project as possible, with the test plan being continually updated as project requirements and schedules change.

Development of a good test plan will require access to two quite different sets of skills. A test environment will need to be set up, and the necessary equipment, access authorities, database space, roll back facilities and other technical issues addressed. This will require sound technical knowledge and a sufficient level of authority to allow the required environment to be established without compromise. You can not test properly if you do not have the right tools and facilities.

The other vital skill set is a detailed knowledge of the functions that the software under test is to perform. How this knowledge is to be provided will depend on the nature of the software concerned. Theoretically, all the information you will need should be included in the requirements specification (if you have one).

If the software is a new development that does not replace any existing automated or manual procedures, then your only source of information will be the specification (or the person or persons who should have written one if a specification does not exist).

If the software will replace existing automated or manual procedures (and let's face it, that's the kind of software that the majority of us will be testing), then as well as the specification you should have access to (maybe you are!) a user who knows intimately the functions that the software must perform.

Where you have access to a specification and user knowledge, use the specification to map out your broad plan, but fill in the fine details by supplementing and checking the specification with current user knowledge. Specifications have a habit of getting out of date, and could easily have been incomplete in the first place.

You may find conflict arises with the development team here. Remember that the specification is their "bible", and they may insist that this is the only source of information to be used in devising functional tests. This will almost certainly be the attitude if the software has been developed externally under contract. However, if there is a current business requirement that can not be met by the software, and there is no acceptable work around, then the software can not be used. Whose fault it is, and who pays for it to be fixed, is a separate argument.

With a little training and experience, users with good functional knowledge and the right attitude can make excellent testers. (See the section on "Attitudes to Testing"). The best testers will come from the more senior user ranks, but make sure they still have an active "hands on" role in the functional area that is to be tested so that you get knowledge of what functions are needed now, as distinct from 6 months or a year ago.

If your test project is of a reasonable size and complexity you will need several testers to get the work done in an acceptable time frame. Your test plan will define how the testing load will be divided, and who will be responsible for each section.

Your test plan will not be a static document (at least it won't if you intend to use it, rather that just provide it as "window dressing"). You will be constantly updating schedules and adding tests as new types of errors surface and requirements change.

Your organization may have a "standard" which must be followed when producing your test plan. If it does, use it. If it is a good standard it will help you to focus on things which you can and need to control and influence. Include anything that will help to define the test objectives, testing environment, methods, schedules and so on. Exclude everything else. Your test plan will be far more useful (and more likely to be used) if you cut out all the superfluous "padding" that is often passed off as documentation in a computer project.

Many books on Information Technology that contain sections on testing will provide checklists of the headings your test plan should contain. Have a look at anything you can get your hands on and select those items which will be relevant to your environment and your project. If you can't find anything better, the following list may help to get you started:

1. Introduction - Summary of the software to be tested, and the testing approach which will be used. Include any useful references to external documents, e.g. requirements specs etc.

2. Scope - Does this test plan cover the entire software suite, or does it test only certain subsystems. List the subsystems included in this plan.

3. Features to be tested - Basically a list of all the features or groups of features you plan to test. This section will serve as a checklist for you when you come to design your actual test cases. This is the high level outline of what you plan to do, so keep coming back to it during test case design to make sure that you haven't overlooked anything.

4. Features not to be tested - Sometimes you will be unable to test parts of the system for some reason, perhaps because your test (hardware) environment does not allow it, or because certain software components are not yet available. If you are in this situation, make sure that you document fully which parts of the system will not be tested and why. Try to identify the associated risks, and make absolutely sure that your project manager is aware of the situation.

5. Environment requirements - What hardware and software do you need, what access requirements, any special system functions (e.g. database roll back capabilities), special tools, documentation etc.

6. Staffing - How many people do you need, what skills must they have, what training do they require, when do you need them, how long do you need them for?

7. Project deliverables - As well as actually doing the testing, you will also be producing various information in the form of test case specifications, test data, test execution logs, test error reports etc. If you are using automated test tools, some of this documentation may be provided by the tool. List the documentation that will result from your testing activities. (As well as helping you to manage the testing process, this documentation will also help to satisfy those who measure your worth by the volume of documentation you produce).

8. Schedule - Divide your planned tests into logical groupings. Work out what must be tested in sequence, and what tests can be run in parallel. Divide the work between your test team members, then build a proposed testing schedule showing key milestones etc. You will often be forced to schedule backwards from some (usually unrealistic) "required by" date. If you can't fit the work into the available time consider running shifts, getting more people on the team etc. (Be careful here, too many can slow you down). Remember that there will be unscheduled delays while errors you have found are fixed by the developers. Make it clear to your management the risks that they may face if you aren't given enough time to do the job properly.

9. Suspension/Resumption Criteria - At some point during the testing you may want to suspend testing for some reason. For example, the software you are being given has so many errors that you cannot complete any test properly, and it is pointless to continue until the development team as been given enough time to sort the problems out. Or you may be on the end of the queue in terms of host response priority, and are wasting inordinate amounts of time waiting for the system to respond. Document in advance (for your own protection) the criteria that you will use to suspend testing, when it can be resumed and what re-work will be necessary when it is started again.

10. Risks and Contingencies - Identify the high risk components of your test plan. (The schedule is almost guaranteed to be one of them). Then specify what will need to be done to get things back on track. Look for any area where your assumptions may be wrong, and try to work out what you would need to do to correct the situation. This is an important aspect to consider because if something does go wrong and you have already planned for it, there is no panic. You can immediately put in place the corrective actions without losing any more time.