Category Archives: startups

Bizcamp Talk

I gave a talk at Bizcamp this year on how to get the most out of your software testing.

This was an interesting challenge as the I wasn’t speaking to software testers but developers. How could I help developers and small companies test better?

I decided to go down the path of identifying typical traps that testers and developers fall into, e.g testing to little, or testing too much and how to try and get your testing just right.

I used the analogy of Goldilocks to get my point across.

I got lots of questions which was very gratifying.

Walking the walk, but can you talk the talk?

In my experience, selling testing is a lot harder than testing. Despite being Irish, “the gift of the gab”  eludes me, often leaving me tongue tied and twisted when selling my wares.

Its one of the reasons I have got myself a business mentor.  His main focus has been for me to understand my ‘product’ and my customers.  He’s arguing at the moment, that the word ‘testing’ is not sufficient to draw in my customer base. The reason being, is my customers work in a different paradigm and use different language and so fully fail to comprehend the benefits that testing can provide.

We know as testers that testing can have massive benefits right across the company, and that the information and insight (thanks Joe) we provide is useful beyond the IT development lifecyle.  For example, we know that marketing can benefit from data resulting from performance testing, that legal teams can benefit from any compliance testing we perform.

There is a bit of a trend recently to describe our work in clear terms such as testing and bugs. Where before we perhaps worked in QA, we our now testers. We have ceased to use language such as gatekeepers and milestones. But I wonder in using such limiting language such as testing and bugs does it make it harder to sell testing to these stakeholders? I certaintly struggle in finding ways to bridge the language gap between testing and my customers.

Words such as Quality and Assurance have in a way become tainted and I try to avoid such terminology, but really where does this leave me?  I know for effective communication with my customers (who exist outside the IT world), I need to use their language and describe testing in their terms.

I will give you an example.

I attended a BizSpark networking event recently where a number of Venture Capitalists were present. One concept I’ve been toying with is to provide independent technical reviews on software products for investors and the like.  I know, it sounds a lot like testing, but if I used the word test  and bugs, VC’s eyes glaze over.

So I speak to them using words such as due diligence, audits and risk management.

Does this mean I’m not testing anymore?  Am I now selling insurance as opposed to  testing? Personally, I don’t see it that way, to me the core is all about testing. It’s just that the context has changed, and so the language has.

Perhaps I’m over complicating things here. I’m unsure.  I know that placing testing in their context it makes it easier for them to buy into. Is that so wrong?

I’d really like to hear people’s thoughts on this, it’s a topic that fascinates.

Changing the Goal Posts

I got a chance to watch some Gaelic Football recently as my two sons have started playing hurling and gaelic football.  Hurling is a fairly ferocious sport where everyone goes for the ball with hands and sticks. Gaelic Football gives the appearance of being a far kinder sport. However, the Australian version (aka Aussie Rules), is a much more physical and aggressive game.  One thing that differs between the Irish and the Australian version is the goal posts. In Aussie rules points are scored when you kick through one of four poles, Gaelic, you kick into or over a pole. Little differences but really important to know and get right.

hurling

Adam Goucher had a nice post this week on communication and letting your team know where the goalposts are. Well I have had a similar goalpost problem. Except in mine, the goalposts changed. How I scored the goal had changed, and no-one had told me.

I have a very nice client (he’s a client, so he has to be nice, well in this case he actually is very nice) but new to the software development, and a grappling with some of the basics do’s and don’t to mostly people in IT take for granted.  It’s the basic advice they require most. Like, letting people know when things change, so I can relate to Adams comments.

I spent a good amount of time before the project, understanding who the stakeholders were, and the mission of the testing effort. I explained to them the many different types of testing I could perform, such as Usability, Performance, functionality, Installation and Configuration. It was decided to narrow the scope to robustness, it was a prototype after and all and as long as the screens did not crash, that would be satisfactory.

The day before delivery to their customer, there was a review. The stakeholders were dismayed at the state of the screens and the way the functionality worked. But I spluttered, “you told me you didn’t want Usability Testing”  What a frustrating experience. They had changed the goalposts!

The experience left me angry and frustrated. I had approached the whole exercise well. I had involved the stakeholders, I had worked out their mission. Why did the customer have to go and change their minds?

I suddenly felt empathy developers whose requirements continuously change.

It then struck me that in a way I was the problem. I was being too inflexible and rigid in expecting an inexperienced customer not to change their minds.

I’ve resolved to be far more open in my approach to what’s required (for this project). As long as the customer understands the financial implications of such decisions who am I to argue?

After all is not the customer always right?