More and more often I see outsourcing contracts that requests 10-15 test phases. It looks like someone has simply thrown the book at it, and not considered if it is an infrastructure project, a software development project or COTS implementation or – what on earth, they actually want to learn from the testing.
These are the phases of a recent project:
- Environment Acceptance testing
- Hardware and integration testing
- Component testing
- Component- integration testing
- Installation test
- System testing
- Functional testing
- Regression testing
- Security testing
- Performance testing
- Operational acceptance testing
- Service Level testing
It’s a challenge in the vendor reply. The vendor will want to reply to all test phases in order to be compliant with the tender, and not loose points. There is no room for elaboration or discussion if you want in on the bid process.
Quite often the requester comes back and say “we didn’t want all those weird testing things, we just want something that works for us”. But when the contract is signed and the work set in motion the project team have challenge to make the testing practical within the framework of the contract. This goes from both sides. Many good hours can be wasted with unwinding cumbersome contractual terms.
What I usually do in such a situation is to bundle the contract’s testing scope into fewer activities, and setup a mapping so that everything is covered. That is if the client allows me to make the activities practical and context-driven. If not – my hands are tied, and we deliver according to spec – even if the chapters of the test plans are set in stone.
Let’s work towards better deals for testing activities. If you are looking to prepare a BID include a test manager – and have a discussion of the value-add and learning of testing up front. There is no one book of how to do testing. Instead spend the time and money figuring out your context. Figure out what phases are on the client side, and what is on the vendor side. Have a test management consultant on retainer for before and after the bid process. Do something to discuss your test strategy and put the guidelines in the contracts, so that the vendors can propose a solution.
Don’t request everything and the kitchen sink too

[…] https://jlottosen.wordpress.com/2017/08/23/andthekitchensinktoo/ […]
LikeLike
[…] https://jlottosen.wordpress.com/2017/08/23/andthekitchensinktoo/ […]
LikeLike
[…] … following the ISTQB cook book […]
LikeLike
[…] testing professionals we can help the business both not to request the kitchen sink, while also test all the things (that matter). As with all other testing – even the dreaded […]
LikeLike
[…] – and in what contexts they apply best. We should obviously not do everything and the kitchen sink in every single testing project in the world. The value of any practice depends on its context […]
LikeLike
[…] When you become the pointy cog in the wheel (or bottleneck in a lean vocabulary) you get all the bumps and heat. I can see how the test plan templates have evolved over the years. Written in project blood as check lists usually are. but now they are being used against the testers and test managers. We have simply been painted into a corner and have asked for everything and the kitchen sink. […]
LikeLike
[…] delivery teams. In the recording you can hear me talk about how Timing is Everything for working on bids and tenders. And contemplating the lessons from social enterprise networks – where 77% use it to find […]
LikeLike
[…] More and more often I see outsourcing contracts that requests 10-15 test phases. It looks like someone has simply thrown the book at it, and not considered if it is an infrastructure project, a software development project or COTS implementation or – what on earth, they actually want to learn from the testing. […]
LikeLike