Most good testing service providers see the advantages of Testing as a Service (TaaS) for both their clients and themselves. However, client concerns about the risks of transition can be a roadblock. To see how goats can help to remove that roadblock, read on ….
“Crossing the River” to TaaS
I first heard “crossing the river” from a sales guy. He explained that his sales technique was to show the client that they were currently on one side of the river, that his product was the other (more attractive) riverbank, and his job was to show them how to cross the river.
The Client’s Riverbank
Introducing a client to TaaS usually starts with a discussion about the pains of the way they currently engage external test resources – which, for most of them, is team augmentation (“body-shopping”). Sometimes they are surprised to hear us, a supplier, admit that body-shopping is a win-lose relationship where the supplier is the winner, because body-shopping usually means certain profit with little effort and no real responsibility – and the client is the loser. By the end of the discussion they are usually nodding their heads in agreement about the pains of body-shopping: the time and effort needed to find and select external resources; the struggles with performance and knowledge not matching claims made in a CV or an interview; high turnover and having to go through the process again and again.
Where the Grass is Greener
Then we explain how TaaS can create a win-win relationship. We describe the principles and the specifics of our delivery models. We show them how the burden of responsibility is transferred to the supplier and how the client can take advantage of the supplier’s expertise to boost the quality of their overall test process.
Where’s the Bridge?
By now the client usually agrees that the other riverbank looks greener and pleasanter. When they start to think about crossing the river, however, they imagine that it will have strong currents, be filled with crocodiles and have no bridge; at this stage, panic can set in.
Sometimes the first reaction is “TaaS is not for us, we’re moving to Agile”. This reaction may be a legacy of TaaS being offered by major vendors as a ‘test factory’ service, where the software and its specification are sent out for testing and a test report comes back. This is a centralized testing service. In Agile testing is devolved to the Scrum teams and centralized testing may look largely incompatible. However, TaaS is highly compatible with Agile.
The foundation of TaaS is definition of services that meet client needs and provide value. Services can be defined that support and extend Agile’s devolved testing. Using services some functional or non-functional testing can be “outsourced” from Scrum teams, and some test support activities can be provided. These can free up the scrum teams from repetitive tasks or help them with activities that require specialist skills. This allows the Scrum team to focus on their core responsibilities and be fully involved in Agile’s key rituals. When Agile is scaled up then TaaS can reduce costs significantly through economies of scale.
Whatever the SDLC TaaS can look scary to those with no previous experience with it. For services to work well, the expectation of their outcomes must be clear from the start. Clear means quantifiable, and that means metrics, but many potential clients will not be mature enough to define what they want in measurable terms. TaaS also requires good governance and many clients will not, initially, know what this should look like.
The Three Billy Goats Gruff
All change carries risk. As testers we know that it’s critical to mitigate risk – it’s the core of what we do. Risk is also partly why many people resist change. “Better the devil you know”, as the English say. If the transition to TaaS is to make it across the river, it has to be carefully managed.
There’s a Norwegian nursery rhyme called ‘The Three Billy Goats Gruff’. The goats were brothers: one was small, one was medium-sized and one was large. They wanted to cross the river to eat the lush grass on the other side, but the only way was a bridge guarded by a hungry troll (who, by the way, was on a body-shop contract). How did the goats get across? They sent the small one over first. When the troll tried to stop him, saying that he would “gobble him up”, the little goat said “Don’t eat me, I’m too small, wait for the next goat because he’s bigger”. And so the troll let the smallest goat across.
Starting with something small is just one risk management approach we recommend. Other good transition approaches are start with the familiar and start with the unpopular. Let’s take regression testing as an example. For most testing teams this is usually both familiar and unpopular. If you have a well-maintained regression pack that has been run several times then you already know:
- how many tests it has,
- what data are required,
- how long it takes to prepare and run the tests,
- what knowledge is needed to run them,
- how many errors you typically find during execution,
- how many regression bugs typically escape to production.
So, you have a set of metrics that can define your initial expectations about service performance and let you monitor the outcome. You can try out both TaaS and your chosen provider in a relatively low-risk way, and make yourself popular with your testers who are freed of this monotonous job. You can expect to get added flexibility and cost savings from the supplier. When you are happy, you can send a medium-sized goat across.
In the nursery rhyme, the medium-sized goat played the same trick on the body-shopped troll that the smallest one did. The biggest goat, last across the bridge, killed the troll. We believe that, once a client starts with TaaS, they’ll soon wonder why they stuck for so long with that troll.
Phil Royston – CEO, Tesena
Having wandered reluctantly into IT about 30 years ago, my first contact with formal testing came unexpectedly in 2002 when I was told that I would be the Test Manager on the project I was working on. Maybe it was fate, but it seems I found my true calling. Or maybe my fate was to become the guy they called when there was a “problem in testing”. Whilst fire-fighting on troubled projects I began to tire and wonder if there wasn’t a better way. So five years ago I co-founded a testing start-up in Prague with a mission to change the testing world by making it work better.
Find out more about Tesena on www.tesena.com