A Testing Process

Testing Process Example

Following the set of articles relate to Testing and TMMI implementation, today I will write about an example testing process

Testing process is the set of activities that control and support the testing model, allowing to organize all roles, entries, outputs and techniques that support the process.

The testing process is the global process that any delivery will follow in the testing factory. It is resume in the following draw:

Main roles that are identified:

• Project Manager: person with the responsibility to deal the project, between other functions this person will indicate the acceptable risk tolerance, services to include in testing, level of acceptance, quality rules to apply, schedule and costs.
• Testing Team: technical team that will handle all test cases, define the test scope (in accordance with the project manager), report defects (block defects and normal defects) and generate the testing reports.
• Testing Manager: collaborates on test plan definition, in accordance to testing team and project management. Governs of testing process, testing techniques, testing reports templates and content, capacity management, availability management...
• Development Team: group of people that are building the delivery (software and/or documentation). They have to update configuration management system with the alpha/beta version and support for Blocking defects

What Blocking and Normal defects are?

• Defect is any deviation between what is expected or is documented and what is delivered
• Blocking Defect is a defect that blocks the testing services execution, and need to be solved as soon as possible in order to continue with testing activities. A response time need to be accorded in order to allow this flexible model.
• Normal Defect are all other defects, that should be fixed in next releases and they are reporting in the moment that they are detected. 

Activities description:

• 1.- Request: project manager ask to testing team or provider to test a delivery, giving the necessary input, as for example: delivery scope, delivery dates or detected risks. 
• 2.- Delivery study: testing team will study the request with the context information about this project (i.e. previous deliveries, previous testing reports, testing plan...)
• 4.- Testing Plan: with the summary made from testing team, testing management will analyse the request and formalize a proposal of services, acceptance level, quality evidences, risk mitigation... and planning the testing services and budgeting this delivery. 
• 5.- Approve: the project manager have to validate testing plan scope, budget and schedule, in accordance to their liabilities.
• 6.- Waiting for Delivery: once the test plan is accepted, the development team will announce when the delivery is ready for test. In parallel the testing team and the testing management will be working to ensure platform availability, test cases design and update and all the previous tasks that could be performed without the delivery performed.
• 7.- Testing Execution: execution of all testing services included in the scope of this delivery. In the case that the testing process is blocked due to a defect (i.e. needed libraries are not available to build, build process fails for any reason, installation process fails) a blocking defect will be register to stablish a collaboration canal between testing team and development team. 
• 8.- Block Defect Resolution: development team has to solve this kind of defects as soon as possible. New instructions, new updates in configuration management system could be done.
• 9.- Report Generation: once services are finished a report will be generated to summarized and give recommendation to the project manager or/and to the development team.
• 10.- Revision: Test Management audit and review test execution to ensure the alignment to quality policy.
• 11.- Report Submission: reports are distribute to stakeholder for their evaluation in order to decide what to do with the delivery (ask for a new delivery, accept the delivery or accept and promote to production the delivery)
• 12.- Invoicing: testing manager will invoice all finished testing deliveries at the end of marked invoicing period.

It is just an abstract, to complete the process new activities, inputs and outputs should be included, but I think it is a good starting point.

The relation between this testing process and the tmmi processes area could be summarized in this matrix (with many considerations - it is just a initial approximation):

Testing Services, overview

Testing Services

I would like to resume and describe a set of basic IT testing services that should be offered to any customer. In the context of TMMI implementation, there are several process area that focus their goal (specific goals and specific practices) on defining a testing policy and increase testing capabilities.

In this context, a testing service catalogue, should be the base for any testing organization.

The main TMMI processes area that should be involved on this are:

• Test Policy and Strategy
• Test Design and Execution
• Test Organization
• Non-functional Testing

The list is not exhaustive, but from my point of view, it is a good starting point.

Early Testing: a set of services focus on software engineering process that aims on early defect detection. Early Testing has it basics on increasing system quality by early defect detecting on the application lifecycle, decreasing defect impact and defect correction. As early a defect is detected as cheaper is the solution. A quality assurance plan starts in the begging of project lifecycle and it is applied all along the project life.

Early Testing services mission is to assurance that the technical and functional documentation is complete and according to end user requirements. A basic catalogue set of services should be:

• Requirement Testing: related to testing requirement specification, aims on reviewing requirements, that should comply:
• Concision: simple redaction, clear and understandable for all stakeholders
• Completeness: requirements are written with enough information to be defined
• Consistency: there are not contradictions between different requirements
• Concreteness: requirements are not ambiguous, have only one interpretation
• Verifiable: it could be check its fulfilment in the final product
• Analysis Testing: activities applied to analysis phase aimed on reviewing how analysis techniques have been applied and to verify the traceability between requirements and analysis specification.
• Design Testing: activities applied to design phase aimed on reviewing how design techniques have been applied and to verify the traceability between requirements, analysis and design specifications.

Software Testing: services useful to apply to a software delivery. Software delivery testing is organized in a wide set of testing services which are focussed on project risk management (this will be expose on other blog entry). The workflow of services could be like this one:

• Build and Static Code Review: source code verification, in order to measure code rules fulfilment and code quality. Build process ensure that the organization is able to build the application from the source code delivered by the development team. This ensures independence from the development supplier and business continuity.
• Setup Testing: is possible to deploy the application with the documentation and sources that have been delivered?
• Functional Testing: focused on system functional behaviour, according to the test plan and the requirement specification.
• Usability Testing: test system usability, ease of use, consistent behaviour... if the organization has a usability rules, they should be reviewed.
• Accessibility Testing: if there is any accessibility requirements this service will review its fulfilment
• Regression Testing: functional testing of previous functionality, that should be kept invariant. Usually regression testing is based on automed programs aimed to decrease testing cost.
• Performance Testing: stress, capability and continuous load test in order to predict system behaviour on real conditions
• Security Testing: test of security vulnerabilities of system implementation (see owasp recomendations)

Testing and Development: sustainable economic model

Test processes increase total cost of projects

This sentence could be the started point for a long discussion about truth and false that have to be analysed in detail.

• Development teams should test every version, if we have a independent testing team for version verification, then we have increased total cost.

This affirmation is true and there is no much to add, the key concept that we have to realise is that this cost should be budgeted from the early beginning and also it should be in our project plan. Another point is that testing cost should be something less than 15% of development cost.

•  Where is the advantage of testing? Do they improve software? Which is ROI of every euro spent in testing?

There are specific economic models to show the value of testing, and how 1 Euro spent on testing will save several in maintenance, operation, codification... it depends on when you invest on testing, as early you start as much money you will save

• As there is a testing team, developers are lazy testing their own work
• ... 

The main goal in the last months in my job has been to define a sustainable economic model  that allow business to have the benefits of testing with a predictable cost.

The model is sustainable with the following concepts:

• For every software version we will know development cost and testing cost.
• For every delivery of the same version we will have two metrics, derived from testing:
• Number of corrections until the software has been deployed in test environment.
• % of requirements passed as ok after testing is finished
• Two indicators and two slas are associated to these metrics:
• Number of corrections have to be less than X (for example three)
• Fulfillment of requirements have to be greater than Y (for example 75%)

With this, it is possible starting a new version and the development team will estimated the cost (ie 100.000,00 €) and the testing team also (15% - 15.000,00 €). Then, when the first delivery arrives:

• If both indicator are better than expected by the sla --> total version cost will be 115.000,00 € and the first version is a good candidate to be  promoted in a production environment (it will depend, but could be)
• If any indicator is worse than expected --> a new release will be delivered, test cost will increase, but development team will be penalized --> (100.000,00 - 10.000) [Developement] + (15.000,00 + 5.000,00) [Testing] = 110.000 €

With this model, as many release are needed less development cost  and more testing cost, the total cost should be constant for final business.

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.

Continual Improvent Process

The continual improvement process is almost the most important concept that every methodology must define, and that should be always implement in any organization.

If we take a look at most significant methodologies, we can see this process area definition:

• ITIIL V3
• CMMI - Dev - 1.3
• TMMI

Continual Improvement Processes aimed to be used not in an initial application of any of these methodologies, but in a later step, and this causes several miss-performance situations in organizations:

• Organizations that are making an effort in methodology improvement don't have a continuous improvement process included on their process map.
• After implementation of the methodology in the organization there are no metrics to determine if performance is increasing or not.
• Basic diagnostic is not determine: is the methodology in my organization being used?

To avoid those situations any implementation of any methodology must define a set of processes, with almost the following matters:

• A set of processes not in paper, but with a computer based solution that support then.
• A set of basic metrics that measure how are  being used processes.
• A set of performance indicators to determine if throughput is increasing or not.
• A set of reports that inform the methodology leader how everything is going on.
• the organization must know how to inform or propose improvement  to methodology.