Software Test Approaches Test Strategies

To see all articles of ISTQB-ISEB Foundation guide, see here:

Software Testing-ISTQB ISEB Foundation Guide

A test approach is the implementation of a test strategy on a particular project. The test approach defines how testing will be implemented. A test approach can reflect testing for a whole organization, a program of work or an individual project. It can be:

• developed early in the life cycle, which is known as preventative—in this approach the test design process is initiated as early as possible in the life cycle to stop defects being built into the final solution;
• left until just before the start of test execution, which is known as reactive—this is where testing is the last development stage and is not started until after design and coding has been completed (sometimes it is identified as the waterfall approach, i.e. all development stages are sequential, the next not starting until the previous one has nearly finished).

A test approach includes all of the decisions made on how testing should be implemented, based upon the (test) project goals and objectives, as well as the risk assessment. It forms the starting point for test planning, selecting the test design techniques and test types to be employed. It should also define the software and test entry and exit criteria.

There are many approaches or strategies that can be employed. All will depend on the context within which the test team is working, and may consider risks, hazards and safety, available resources and skills, the technology, the nature of the system (e.g. custom built vs COTS), test objectives and regulations, and may include:

• Analytical approaches such as risk-based testing where testing is directed to areas of greatest risk (see later in this section for an overview of risk-based testing)
• Model-based approaches such as stochastic testing using statistical information about failure rates (such as reliability growth models) or usage (such as operational profiles).
• Methodical approaches, such as failure-based (including error guessing and fault attacks), checklist based and quality-characteristic based.
• Standard-compliant approaches, specified by industry-specific standards such as The Railway Signalling standards (which define the levels of testing required) or the MISRA (which defines how to design, build and test reliable software for the motor industry).
• Process-compliant approaches, which adhere to the processes developed for use with the various agile methodologies or traditional waterfall approaches.
• Dynamic and heuristic approaches, such as exploratory testing testing is more reactive to events than pre-planned, and where execution and evaluation are concurrent tasks.
• Consultative approaches, such as those where test coverage is driven primarily by the advice and guidance of technology and/or business domain experts outside or within the test team.
• Regression-averse approaches, such as those that include reuse of existing test material, extensive automation of functional regression tests, and standard test suites.

Different approaches may be combined if required. The decision as to how and why they will be combined will depend on the circumstances prevalent in a project at the time. For example, an organization may as a standard use an agile method, but in a particular situation the structure of the test effort could use a risk-based approach to ensure the testing is correctly focused.

Deciding on which approach to take may be dictated by standards, e.g. those used in the motor industry that are set by MISRA, or at the discretion of those developing the approach or strategy. Where discretion is allowed, the context or scenario needs to be taken into account. Therefore the following factors should be considered when defining the strategy or approach:

• Risk of failure of the project, hazards to the product and risks of product failure to humans, the environment and the company, e.g. the cost of failure would be too high (safety-critical environments).
• Skills and experience of the people in the proposed techniques, tools and methods. There is no point in implementing a sophisticated component-level, technique-driven approach or strategy when the only resources available are business users with no technical grounding.
• The objective of the testing endeavor and the mission of the testing team, e.g. if the objective is to find only the most serious defects.
• Regulatory aspects, such as external and internal regulations for the development process, e.g. The Railway Signalling standards that enforce a given level of test quality.
• The nature of the product and the business, e.g. a different approach is required for testing mobile phone coverage than for testing an online banking operation.

To check your understanding, I would again like to ask you some questions:

Name and explain five approaches to the development of the test approach or test strategy.
Name one of the standards referred to that dictate the test approach.
Can discretion be used when defining a test approach and if so what can influence the decision as to which way to approach testing?

You may follow the complete series of Test Management articles here:

Test Management Risk And Testing
Software Test Organization
Software Test Approaches Test Strategies
Software Test Planning And Estimation
Software Test Progress Monitoring & Control
Software Testing Incident Management
Software Test Configuration Management

To see all articles of ISTQB-ISEB Foundation guide, see here:

Software Testing-ISTQB ISEB Foundation Guide