About Unicorns and Rhinos

Agile testing days are over. I have not been there, but from Twitter it seems they happened in a different land – the Unicorn Land. Must be great there, all those helpful experts and friendly people, a lot of fantastic user names with certain message…: @FriendlyTester, @the_qa_guy, @badtesting, Testknight, …. Then I look out of the window. Grey. No colorful unicorns. Grey day to day fighting with my test job…

So what is so special about the Unicorn Land testing? Quite some time ago I read the article of  Sigurdur Birgisson, where he writes about “Agile Testing – Unicorn perspective” compared to the real world, where the unicorns are grey and are called rhinos… While his point is about not falling into the ditch after great discussions and not getting out of it in order to DO something, I guess I would need a solid bridge to get across the ditch: my Rhinos live in a completely different land.

My Real Testing Land

In my testing land, the world looks a bit different:

• Not about agile mindset – but about getting the requirements tested
• Not much about exploring – but about checking
• Not much about experts with fancy names – but formal hierarchies
• Not much about testing knowledge – but about… well here it gets special:

In my work context rather often, I end up in the situation where I have a majority of business people in my team with little or no testing skills. But they have great other skills: they do know what is important. They do have a very genuine interest in that the result of the work is usable in day to day work. So you might have guessed it: I often work in V-model like projects usually in late test stages.

But I can imagine, that you Unicorns have met those grey brothers and sisters before: your company has asked for a final test by the business department, your application interfaces with a backend system, where no agile teams are working yet… So you know the question: how can I (claimed to have some agile mindset) support the success of my test outside Unicorn Land?.

How to Color A Rhino

From my experience, to work with such a team you need to extremely carefully check what is the purpose of the test phase and then “sell” it to the testers. Can you have some trust, that someone else covered the basics before (maybe the Unicorn guys, or maybe it is a COTS product (custom off the shelf) and we really only need to test very specific things? Is it more of a “learning” and not testing? Is it a test of data “delivered” via some interface? This has to result in some visionary statement. In my current project I could call it “The product would work fine, if we did not configure too much” – i.e. the focus is on testing the configurations of a COTS product…  in such projects I experienced several ways to “agilization”:

Work on par: Your test strategy needs to build trust for the business people into the test object and you –  they need to believe that the test scope is sufficient. So ask the team what they think is really important. Learn to understand their reasoning and then extend it with own ideas and methods, and cast it into some strategy. Try to carefully extend that by pointing out what you think is also dangerous. But don’t use technical terms. In my example of the COTS product, one would assume the product is tested a few thousand times before, so only test the extensions. Testing experience is: you also have to show that the extensions work together with the product and did not destroy the unchanged part of the product. Experience is, business people do have a strong interest into this.

Help them find the right tools: this sometimes is shocking for the testing community and for myself – but the most preferred test management tool in business units very often is Excel! But maybe you can convince them to have an easier life with other tools…  which then helps you in test reporting…

Add on skills: do pair testing with them in the beginning and get them on the hunt. Not only the happy path is important – and they do know that from their real life. So ask them for their worst nightmare and then see if you together can follow that test.

Try to get the checking work into some machines! Making the testing stuff way more fun for the rhinos…. More challenging, more diverse, …

Explore carefully: why carefully you might ask. This is very often because at this stage of the project, change requests are NOT welcome. So you first need to create a space in which change is accepted, otherwise frustration is large.  And then use the space to explore. What happens: next time they want to be involved earlier! YippiYee

Work with project management to point out early involvement is great! And  get the team to ask their bosses!

Is this already agile? No. But there are some of the characteristics in there looking at what Sigurdur mentioned.

So, do you now have a flock of unicorns? No, but maybe some funny looking rhinos… and a good chance to combine fun and power to succeed.