Category Archives: BlogRoll - Page 2

Walking the walk, but can you talk the talk?

Posted by on March 9, 2010 9 comments

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.

Waxing and Waning during Exploratory Testing

Posted by on February 23, 2010 5 comments

I had this great plan for today where I would observe how I work throughout a day of exploratory testing.  Unfortunately, the software is not quite ready for testing, so my plan has been slightly scuppered. Still I suppose this situation is often typical of any testing  scenario, so I will still include it into my final analysis.

The idea behind this ‘observation’ is I want to have an understanding of how my enthusiasm, concentration change throughout a day of testing.

The reason I want to do this is because I’ve notice that often at the end of testing I tend to be less enthusiastic than say at the start.  That’s understandable and probably most testers have noticed this wane themselves, especially if the testing goes on for a long time.

I attribute many reasons to this, for example, sometimes I leave the boring and tedious tests to the end, or perhaps I feel the majority of ‘interesting’ bugs appear to have been found. It might even be that once the excitement of testing something new has left, I’m left with my own discipline and sheer determination to get through the rest of testing.

So, I thought it might be interesting to track my enthusiasm and concentration in exploratory testing. I get to chose what I test and when, so perhaps with me in control of my testing destiny it would be interesting to see how my enthusiasm wanes and waxes. By observing how it changes, I might be able to put into affect some different techniques to use the peak  points of enthusiasm and concentration for testing the software and perhaps the times when I’m er a bit less enthusiastic to do documentation etc.

The idea is that by observing my testing flow I can plan better how to use my day.

I wonder if this is something that all testers would find helpful?  I imagine that most testers would differ in their daily ebb and flow. If you observed your concentration levels what would you see?

I will keep you posted on how this little exercise goes.

Testing my backbone

Posted by on February 16, 2010 14 comments

I’m a nice person. Well, I like to think I’m a nice person anyhow, and some people tell me that’s true too. Especially my kids, they tell me I’m the best Mum in the world. Aw shucks!

But sometimes, being nice creates problems because I want people to be nice back to me too.

This can be a real problem in software testing when faced with an aggressive and rude developer with little respect for your work.

The consequence of being ‘nice’ is that I’m as helpful and co-operative as possible with developers. Generally testers like me raise great bug reports and are very attentive if the developer requires further information.

On the down side, at some point in your working life, you are going to face an aggressive and unpleasant developer and to do your job, you are going to have to stand your ground.

And then its time for wimpy tester to find her voice and become  assertive tester.

So I’ve had to come up with some techniques to turn my wimpy ‘nice’  persona into an assertive positive voice.

For all you wimpy and not so wimpy testers out there, here they are:

1)  Rule Number 1. It’s all about the software, its not about you. Focus on your goal and don’t be distracted by outrageous and manipulative statements. Sometimes I imagine the developer yelling and screaming at the software not me.

2) Rule Number 2: Stick to the facts, and backup statements with evidence or in Cem Kaner’s language, find a credible source.

3) Rule Number 3: Don’t be bullied by an aggressive developer, raise your risks and speak your mind.

4) Rule Number 4: Keep a pleasant an even tone in all your discussions. Emotion is not required here.

5)Rule Number 5:  Focus on the commonalities. You both want the software to be delivered successfully. Work as a team even if it doesn’t feel like a team.

Remember the goal is not to get the developer to like you, its to get good software delivered. At the end of the day, you are responsible for raising bug reports and identifying risks. If some developer is determined to be aggressive, that’s their call, but if you stand your ground at least then you can complete your work with a clear conscience.