Hello again. I’ve been unusually busy these past few months plus I’ve been waiting for inspiration to strike and boy oh boy it certainly did.

It won’t be the first time you’ll have read something about this but I wanted to share my take on it for you – intrigued? Read on.

So. Testing eh? We love it. I know fellow testers love it. We understand it. We continue to learn about it. We strive to improve our approaches. We read books. We attend seminars and conferences and such like. We want to make the world a better place.

These days, and this is a fairly broad interpretation and heavily context dependent, a concrete set of requirements, a clearly defined set of acceptance criteria, and a wholly unambiguous, complete understanding of exactly what to expect as far as behaviour is concerned (that’s software behaviour) is something only dreams are made of.

While this maybe true and even if it isn’t testers should never ever be afraid of asking questions. Thinking back to my days as a trainee, it was always drummed into us that ‘testers never assume’. This is not an excuse to flick your common-sense switch off however.

With the Agile manifesto ringing loudly in everybody’s ears nowadays, individuals and interactions are the order of the day. Talk to people. Talk to yourself (don’t go mad though). Get up from that coffee cup strewn desk of yours and wander over to speak to a fellow colleague. Ask that question. Collaborate. Those that will remember Bob Hoskins will recall his BT advert catchphrase “It’s good to talk.”

I like talking. I was always told off at school for talking too much in fact. I soon learned I needed to concentrate whilst working so I left my talking for later. As a tester (fast forwarding many years forward) I still need to concentrate when working on something. As much as I’d love to talk about last nights “I’m a Celebrity Get Me Out Of Here” I have a job to do and invariably a deadline to hit.

However, like we were saying earlier testers need to ask those questions. Sending an e-mail can sometimes be necessary but when the person you need to ask is sat in front of you (or next to you, or behind you) go and build those relationships and speak to them. Testing is a service after all. You’d be demonstrating to colleagues how passionate you feel about the work you do. Though I have to say not every team member understands Testing. I guess I don’t know everything about Business Analysis, Development, Product Management, etc though when somebody from a different discipline asks me a question I respectively and politely try to provide an answer. I want to help. We’re all trying to deliver aren’t we? Since I understand that they are a professional at what they do. The same as I am a professional at what I do. There’s a mutual respect (or should be). Moreover it’s just nice to be nice – isn’t it?

Unfortunately not everybody in a team will be willing to just be nice (maybe they’re having a bad day) or appreciate the fact that your question is in relation to the work that you are doing (since they are probably oblivious to why it’s relevant or just fail to show any willingness to want to understand why you are asking the question) and may decide to just give you the bum’s rush and send you on your way with a flea in your ear.

Bum’s rush? Flea in your ear? To give you the brush off. To not be helpful or understanding. To do or say anything to get rid of you. This flies in the face of team working. Not only will this serve to make you think twice about approaching them in the future, it is sowing the seeds for a total communication breakdown and lack of team spirit.

A classic example for you. You’re in the middle of test execution. Maybe days, weeks, down the line. Then all of a sudden you notice something different. You haven’t seen this behaviour before. Why is this happening? There could be a host of reasons. So like any good Vulcan, you apply logic. Maybe something has changed within the code base? Let’s face it how often have you had to deal with ‘changes’ you were not made aware of in the middle of your testing owing to non-existent release notes. So who should you ask? Maybe the Lead Developer but they’re not around. You see the Project Manager sat in front of you. So you wander over and ask in person. Sounds like a sensible course of action.

What if the PM immediately replies with “It’s not a defect!” in a less than friendly tone? Yet you never said it was. Since at this point in time you’re trying to establish expected behaviour and determine whether or not a change had been implemented in a recent build or not. “Why?” “What difference does it make?” the PM may ask. Failing to understand the testing implications of a potential code change that we were not made aware of. You wander back to your desk bemused.

The example above could have been so different had the PM handled it differently. The response could have been “Oh that’s odd I wasn’t aware of any changes for this. I’ll check for you.” In turn you would have thanked them for their help and continued with your investigation into other possible causes.

Testers need a thick-skin. A level of resilience. It can be so frustrating.

So yes, absolutely, speak to people. Ask those questions. Just be mindful of the fact that not everybody understands or wants to understand why you are asking.

I’ll leave you with something else we learned at school…play nicely.

 

 

 

 

 

 

 

 

Advertisements

One thought on “Curiosity Killed the Tester

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s