Save £12 Million every year > Save £3 Million every quarter   
The Big Agile Toolkit: no Dogma, no Bias, no Accreditation, no Exams & no Fees   
 Testing responsibilities  Testing responsibilities   Types of testing   Types of testing

Lifecycle   »   Agile Testing   »   Testing Approach

The goal of any solution is to meet its objectives in a business environment and to operate in a technical environment with as few errors as possible. Testing validates this and uncovers the errors as soon as possible. Broadly, testing falls into two main categories: functional testing and non-functional testing. Functional testing is validating the solution in a business environment while non-functional testing validates the solution in a technical environment.

The important message we seek to get across in the Toolkit is that testing has not gone away even though the responsibility for deliverable quality of the emerging solution is passed to the business team. A business team will have business skills and these will almost invariably be deficient in technical assessment and evaluation techniques. The testing manager, testers and wider testing team have long been the domain for the provision of this very important and professional service.

Importantly though, what the project will decide is what level and what type of testing will be applied to the project. The project team management will make this decision though as a combined collaborating shared business and technical project.

They will decide what level of testing is important because the project will know what degrees of quality are mandatory and what can be accommodated. They will decide what type of testing is important because the project, using the Toolkit, adopts a risk based approach to testing. The project will not do this to limit testing or add risk to the outcomes. The project does it to focus project spend on evaluating the areas of the development which represent the highest exposure to risk.

Very importantly, this will be a project call and a project decision. Business ecosystems and specifically mapped project solutions are too many and various to provide a one stop answer to all possible permutations. This was another failing of traditional methods. By making the recommendation that this test or that test was important, industry standard or so called common sense, it made demands on all projects to ensure this extra effort and expense was incurred with often marginal added value in the product. The odd low risk failure is not the end of the world. Failures happen regardless even when the most intense testing is applied.

So the project will open up the debate about the projects testing strategy. It decides it and documents it in the Testing Strategy document. Simply opening up the debate with testing leaders and business leaders launches the idea of a new ethos to do testing differently and to achieve the most appropriate quality for project products and solution. A fit for purpose outcome is always the primary objective and signed up to within Engagement Commitment.


 Testing responsibilities     Testing responsibilities   Types of testing    Types of testing

Glossary:     a  »   b  »   c  »   d  »   e  »   f  »   g  »   h  »   i  »   j  »   k  »   l  »   m  »   n  »   o  »   p  »   q  »   r  »   s  »   t  »   u  »   v  »   w  »   x  »   y  »   z

#personas  »   #artefacts  »   #archetypes  »   #patterns  »   #change  »   #personas  »   #increasingoutput  »   #reducingvariation  »   #improveefficiency  »   #abstraction  »   #predictionandcontrol  »   #management  »   #organisations  »   #socialnetworktheory  »   #failfast  »   #quality  »   #waste  »   #complexity  »   #learning  »   #adapt  »   #inspect  »   #improvement  »   #models  »   #complexadaptivesystems  »   #informationflow  »   #sytemsthinking  »   #butterflyeffect  »   #unpredictability  »   #chaos  »   #emergence  »   #emergentbehaviour  »   #distributedcontrol  »   #continuousimprovement  »   #complexityscience  »   #gametheory  »  
 Agile In 6 Steps    |    Projectivity    |    Instant Agile    |    Risks    |    Auditing Agile Projects 
Big Agile Toolkit Book (Amazon Japan)   |   Big Agile Toolkit Book (Barnes and Noble)
Buy the Big Agile Toolkit Book   |   Buy the Big Agile Toolkit Kindle eBook
Testing Approach


The Big Agile Toolkit

 SPADE: Successful Pragmatic Agile Delivery Everytime™ 
Topic: 326  Page: 278/444  Progress: 62.6%
 About    |    Author 
Follow @BigAgileToolkit

This content can be copied to third parties for personal use if you acknowledge the source of the material with website URL ( and Twitter hashtag (#BigAgileToolkit).
In all other cases, no part of bigagiletoolkit or associated text or website may be copied reproduced or redistributed in any form or by any means without prior permission in writing from the author.
Agile Project Governance for Cost Conscious Companies™

All rights reserved.