Guidelines for writing software test plan

Aruna — Sun, 31 Oct 2010 03:24:40 +0000

The test plan defines the scope, approach, resources and schedule of the intended testing activities. It identifies the features to be tested, the testing tasks and who will do the tasks.

The three main elements of a test plan are:

Test Coverage: The test coverage measures the proportion of the program exercised by the test suite. It is usually expressed in percentage. It helps in finding areas that are not exercised by the test suite. Having complete test coverage ensures 100% test effectiveness and that the test suite reveals all the defects
Test Methodology: The approach, techniques and tools to be used for testing
Test Responsibilities: Includes the features/functions to be tested and the criteria for success/failure for the tests

The Test Plan contains the following:

The Project Overview
Objective and scope of testing
The test methodology
Resources and responsibilities
The testing efforts and schedule
Entry and exit criteria for testing
The features to be and not to be tested
Success/failure criteria
Test environment
Risk factors and contingency plan
References to the supporting documents which includes FSD, SRS, TDD and the like.

The scheduling of the testing tasks and milestones is done considering the below factors:

Complexity of the feature
Competency of the resource
Stability of the requirements

Each of these factors could be rated as high, medium or low.

For large projects, there will be a single test strategy document. There will be many test plans that draws its content from the test strategy. The Test Strategy is a high level document that defines the testing approach to achieve the testing objectives. It is prepared by the project manager and it will not be updated often. The test plan is derived from Software Requirements Specification, Technical Design Document, and Functional Specification Document. It includes test strategy/test approach as well. It is prepared by the test lead. The test plan needs to be updated often to reflect any deviation from the original plan.

Credit: Jurvetson (flickr)

If a feature is not to be tested the test plan should state why it is not. For ex: It could be: a low risk feature, tested and found to be stable in the past, not pushed in the current release.

There are several inherent software risk factors in a project like complexity or newness. A well rounded test plan notes all the risks and tasks interdependencies in the test plan and communicates to the stakeholders regarding those dependencies and risks. Dependencies could be like cross-functional impact of a new feature, delay in getting stable builds, late change in original requirements, late delivery of fix and resource availability.

Once the test plan is documented it requires review and approval by the test manager /release management team in order to move the next phase of testing.

Project Estimation

Aruna — Sun, 15 Nov 2009 11:12:36 +0000

Running an organization without access to relevant and pertinent performance metrics is like driving a car without any instrument. The more inspiring the final goal and challenging the deadline, the more key stakeholders are tempted to compromise on best principles of planning, management and control. Yet, it is critical to measure project performance for cost and schedule objectives, process improvement activities for business maturity objectives and system performance and desired outcome measures for our Return on Investment (ROI) objectives.

Credit: Flickr – Umer Ahmed Khan

Hard indicators are facts that can be measured directly, whereas soft indicators are less tangible conditions that must be measured indirectly. The time it takes to execute a task or how much it costs are typical hard indicators. Quality, expressed as customer satisfaction of needs, is one example of typical soft indicator. Hard indicators are by far more widely used; soft indicators are seen by many as being so inaccurate that they are rarely useful. As Deming (1986) stated, the most important numbers are often unknown. Management by numbers is one of the deadly diseases that have ruined many enterprises. Planning for the unknown or the importance of a detailed upfront scoping process is one of the major critical success factors for a project.

The success of any software project largely depends on effective estimation of project effort, time, and cost. Estimation helps in setting realistic targets for completing a project. The most important estimation that is required to be fairly accurate is that of effort and schedule. This enables you to obtain a reasonable idea of the project cost. If the team starts fully aware of the likely reasons schedules fall apart and takes some actions to minimize those risks, the schedule can become a more useful and accurate tool in the DEV process.

Schedules are a kind of prediction. Good schedules come only from a team that relentlessly pursues and achieves good judgment. There is no magic formula or science for creating perfect schedules. Schedules don’t have to be perfect. Schedules need to be good enough for the team to believe in, provide a basis for tracking and making adjustments, and have a probability of success that satisfies the client, the business or the overall project sponsor. Good work estimates have a high probability of being accurate.

Good estimates come from good designs

Good engineering estimates are possible only if you have two things: good information and good engineers. If the spec are crap, and a programmer is asked to conjure up a number based on an incomprehensible whiteboard scribbling, everyone should know exactly what they are getting – a fuzzy scribble of an estimate.

There are known techniques for making better estimates. The most well-known technique is PERT, which tries to minimize risks by averaging out high, medium and low estimates. This is good for two reasons. First, it forces everyone to realize estimates are predictions, and that there is a range of possible outcomes. Second, it gives project management a chance to throttle how aggressive or conservative the schedules are.

Technology and Leadership» Schedule

Guidelines for writing software test plan

Project Estimation

Good estimates come from good designs