Are you Serious?

Are you serious?

Seriously, how serious are you about testing? Lets presume you study the craft of testing. Does that make you a serious tester?

If you answer yes to this question, congratulations. You are on your way to becoming a serious tester. Now ask yourself this question:

“Do you take yourself seriously?”

If you want to be taken seriously about testing, you need to take yourself seriously. Note the difference here. Taking yourself seriously is much larger than being a serious tester.

Taking yourself seriously means you avoid behaviour and thinking such as:

“I will put myself down in front of others to make them feel better about themselves”
“I resort to behaving childishly when placed in pressure situations”
“I hand over power in order to avoid conflict”
“I feel like a fake even though my actions demonstrate otherwise”

I know this, because its only recently I realised that I haven’t been taking myself so seriously.

When you stop speaking to yourself in such a way and start taking yourself seriously, a wonderful thing happens. You start to believe in yourself. In fact, you have to. You owe it to yourself to do so.

I’ve discovered a new strength in this self belief. It means I have courage and strength to stand up for what I want. In doing so, I give myself the respect and honour for all the hard work I have put in.

So, let me ask the question again: Do you take yourself seriously?

Expression epitomised in Rage comics following a David Silverman interview of Fox News by Bill O’Reilly 

are_we_there_yet_cover

Are we there yet?

Ever been in a long car journey packed with young kids? I remember these eight hour drives with six kids crammed into a car driving to our holiday destination. My younger brother in particular was annoying, constantly asking questions and irritating his sisters. By far the most irritating question (especially to our parents) was: Are we there yet? This line of questioning would normally begin half an hour into the journey, and would be constantly repeated throughout the journey.

This potent cocktail of repetitive questioning usually resulted in one of my parents  (usually my Dad) exploding in frustration, yelling at us all to be quiet. This was typically followed by a threat of being dumped on the side of the road. (He actually carried out on his threat once, dumping my brother, who unfazed promptly hid in some nearby field, resulting in the whole car load having to search for him.)

But it was a fair question from us kids. We had no real sense of time or distance to help gauge how far we had come and had to go. We also were totally bored with no iPods or stuff to entertain us. Singing (very Von Trapp like) took us only so far. Counting number plates helped a little. And remember, we were going on holidays, the mere thought conjured up more excitement than our poor little bodies could hold. The journey was always going to be arduous when faced with a destination the held so much promise.

As a parent myself, I have a little more sympathy for my parents. Of course, we have the luxury of allowing our kids to be immersed in some tacky iPod game, distracting them to the point they forget they are going on holidays. But I get it. I get that its really hard to explain to someone with little understanding of distance or time, how long something is going to take.

When testers ask me how we know when we are done in Exploratory Testing, I am faced with a similar challenge. How do I help a tester understand when they are done? Pointing them to the excellent list of Stopping Heuristics on Michael Bolton’s blog helps but how do you apply them? Some of them are easier than others. For example, with the “Time’s up!” heuristic, its pretty simple to apply. But take something like the Flatline Heuristic. The Flatline heuristic tells us to stop when “No matter what we do, we’re getting the same result.” But as Michael points out, there are hidden risks to this. For example, it may be that there is no new information, but it also may mean we are insufficiently explored the application in depth.

In this situation, how do we know what to do?

Like many things in testing, there is no clear cut answer to this. A considered answer requires an understanding of what’s happening around testing, and the implications of the decision being made. Hence the inclusion of the word heuristic.

I’ve found a conversation with stakeholders around stopping heuristics *before* testing starts a useful exercise. Knowing that you have a time limit on your testing goes a long way to preventing tester angst about when to stop. Include in that conversation a discussion on what ‘done’ means including into that the impossibility of complete testing. Stakeholder who get that bugs may be missed can influence which stopping heuristics you use.

Like kids in the back seat, as we test we need to repeatedly ask ourselves the question “are we done yet?”.  It may be useful to use our emotions to trigger this question. For example, if I’m bored, does that mean I’m done – or does it mean I need to change something in my testing? If I’m anxious does that mean I’m about to hit some constraint in the form of time? If I’m angry, does that mean my information is being ignored and maybe I need to address that instead of raising a tsunami of bugs. If I’m confused, does that mean I need to explore more?  Emotions like these can be useful indicators of when to ask if your done. Again Michael Bolton has done lots of work in this area.

I’ve also found  that in times of deep uncertainty its always a good idea to draw on the “phone a friend” card and ask someone more experienced than you for their opinion. There’s no shame in this, these are tough questions to answer. An outsider may have insight or additional knowledge that you’ve overlooked.

Building relationships and credibility with those around will also go a long way to helping you in situations when that significant bug is missed. And as in most of testing, articulating your process and your decision making helps to demonstrate diligence and considered testing.

Question with sprinkle of humility on the side

Michael Bolton tweeted yesterday:

Why do testers insist on trying to be influential? I suspect part of the reason is that part of a tester’s job is to recognise problems. Too often , testers see that the *real* problem is not the software itself, but the process behind the software and go into bug prevention mode. That sort of change requires influence.

Often though, we simply don’t have the authority or the influence to do make change. We may moan and tear our hair out in frustration, but at the end of the day, without the mandate to make change and the influence to implement it, there’s little we can do to change an organisations culture or process.

Trying do do so regardless, can lead to a sense of helplessness and even slowly, over time, a sense of powerlessness. I suspect most of us at one time or another have felt like this. It’s not a great position to be in.

I know I’ve been there. I tried to change the culture of a company (company no less!) that had some  negative ideas about testing and teamwork in general. (I’m talking about this at Eurostar this year). As a consultant, I probably should have known better, but I argued (to myself) that the culture was affecting the tester’s ability to perform their job. It needed to change!

We  testers are gifted with keen observation skills and the nature of our role sometimes means we get to see and recognise problems that perhaps others don’t. But lets not get away with ourselves. Without a mandate for change, we become close to the schoolyard tale tattler, dobbing in on everyone and despised by all (including often the teacher). I failed to recognise that I hadn’t the authority or the influence to make these sorts of changes. I fell into a classic consultants trap. I really should have known better.

It’s not that we *should* or *should not* ignore these problems. Often these challenges are too complex to be solved with simple answers and probably need to be dealt with on a case by case basis. But I think adopting the tone of helper (or servant) goes a long way to contributing to an answer. In some cases a question sprinkled with a little humility can be more helpful than smothering the problem with large doses of  tester sauce.

I hope I’ll remember that next time!

independently Minded