From Classical to Flexible Testing

From Classical Testing to Flexible Testing

From a long time ago Quality Assurance Department were involve in several works: 

• methodology specification, 
• process definition, 
• process implementation, and 
• quality reviews. 

These functions are being enhanced and improved and different teams and responsibilities are being defined.

Testing is a new department in business with a separated responsibilities focus on product verification and validation, integrated in product specifications, product schedule and involve with product goals and success.

This new approximation implies a new paradigm which require new techniques and process focused on succeed.

Differences of a flexible approach. Project Success

In a context where project success is a matter of IT business head, quality is a way to guarantee project success, where all processes are focussed on quality, productivity and excellence. Quality is not an external matter in product generation, but is implicit in all activities and roles.

From this approach, testing could not be a set of process executions oriented to defect detection and request new deliveries, but focus is detect prevention, expecting that with only one delivery software will be accepted and promoted to implementation.

In order to reach this goals, we should:

• Publish our methodology and any automated tool that could simplified verification, in order to allow any developer team auto-evaluated every day and previous any delivery.
• Training service in verification and in any specific consideration that should be know by any part in development and system specification.
• Defect tracking system, in order to communicate development team and testing team.
• Flexibility model: what happens in case of a blocking defect? Should testing ask for a  new delivery? Answer is always yes, but the way we allow this new delivery should be different for certain situations.

Flexibility model

This model allow a conversation between testing office and development office in order to reduce number of deliveries, and makes all one group with one goal: project success.

If we have a delivery in which everything works but there is a dependency no satisfied we can:

• Ask for a new delivery (with all the cost associated with it)
• Allow several correction to each service (for example compilation service), which will be more cheaper and project schedule will be better.

Flexibility model defines for testing office: which services will be flexible, the amount of corrections that will be allowed and the maximum time that testing will wait for them.

With it project quality is not at risk, cost could be reduced and schedule enhanced, but all teams have a must that is project success.