Category Archives: insight

What drives your learning?

Posted by on December 30, 2011 5 comments

What drives people to take up my offer of free Skype coaching?

Most testers when asked give on of the following reasons:

1) they want to pass an exam
2) They are having difficulty at work and need to get over some particular obstacle
3) They want to test themselves
4) They want a particular question answered
5) They want to know more about a topic
6) They want to learn how to coach other testers
7) They want to become a better tester – topic irrelevant

Many come to coaching with a mixture of frustration in their work or because they feel disillusioned.

It we seems that for many,  testers need drivers and general discontent to push them into learning something more. Few testers come forward wanting to simply learn.

It’s not all that surprising. I myself have just completed a gruelling year of full time work. It’s hard to allow yourself time to reflect and pause when you hop from one crisis to another and when you do, its more likely to be related to the challenges your working on at the time.

But I really admire the the testers that come wanting to learn more. Willing to take a punt at contacting someone they’ve never met and ask them to be coached. I salute you!

What drives these people? Is knowledge some kind of drug to these people? Do they simply want to know more? Do they want to be the best at what they can do?

I think its important to understand this question as people who want to learn for the pure joy of learning have a major advantage over others. They continue to learn and grow despite the daily challenges around them. Its not the challenge or goal that drives them to learn, its the learning that drives them to challenge themselves.

Common external drivers are completing a project, passing an exam, getting a job promotion and getting external approval from others. But what happens when the inevitable happens and the goal is completed or the challenge disappears? What happens to your thirst of learning? Does it die away?

Does that tell you anything?

Removing external oracles (those things you judge yourself by) casts your thirst for knowledge in a very different light, but its not a bad light, its an honest one and it belongs to you.

I believe we have to own our own learning. Drivers to learning can often be short lived. Have a goal to become a test manager, only to discover you’ve plateaued?  I suspect your learning may be driven by goals.

Imagine a world where you can tap into this love of learning as some testers do. Imagine learning for the pure enjoyment of discovering something new. Feel the satisfaction of overcoming a hurdle you have set yourself.

These testers they have taken responsibility for their learning. They see it as a way to develop and grow themselves. Their oracles to learning are inner satisfaction and self respect. They shine with the confidence of owning their own learning.

So do yourself a favour, spend a little time identifying what’s driving your learning and ask yourself “how is that working for me?”

Post Note:

If you want an example of a tester that learns for the love of learning, read Pete Whalen’s post on Rising from the Ashes.

 

 

Speed Kills

Posted by on December 13, 2011 1 comment

Some of my testers have become embedded on a newly formed agile team. Its been a roller coaster ride for sure. Lots of fun, thrills and a few scary points in time where I thought for certain we were not going to make it, or we were heading in the wrong direction.

From a testing perspective, we were quietly confident. Our testing is exploratory by nature, and so it lends itself easily to being flexible and adaptable.

We’re testing before the acceptance criteria are developed by attending the workshop and asking questions about the upcoming feature, learning why its needed and what problem its trying to solve.

And when it comes to testing the feature, we all jump head first  into the deep end, swimming with long powerful strokes through the water of doubt and complexity and only surfacing for air to congratulate and high five each other on another completed testing charter.

Its been a wet wild ride, but not without some uncomfortable moments.

While we’re revelling in the warm waters of upfront information and involvement, we’ve also noticed the cooler waters of reduced timeframes. Shorter iterations has placed a lot of pressure on the testers. There’s a feeling that we’re unable to pause and reflect during our testing, the pressure to be done within the iteration lends to the temptation of minimalist testing.

We had to change something to make sure we were testing well enough.

So, we slowed down.

We made sure we spent time to think critically about our testing, coming up with test ideas, understanding what done meant, and most importantly sharing these ideas with each other (including developers).

Now we test like this:

We still jump into the deep end, splash out, learn some stuff about the product but before we continue with some serious swimming we stop and confer. We reflect on our learning so far, we discuss our ideas and how we know we are done. Only then do we continue with our swimming, our strokes confident and strong.

Its been a revelation for some testers that are new to exploratory testing. They thought the objective was to test as fast as you can without stopping for a breath.

We still have the same time pressure on us, but that stop, that moment of pause and reflection has been sufficient to gain confidence in our approach and confident in delivering the best testing that we can.

 

 

Recession Testing is the new RegressionTesting

Posted by on October 4, 2011 16 comments

Its time to retire the idea of Regression Testing folks. Regression testing, at least the way its being performed today is typically a value free, wasteful exercise and falls into the category of  ”bad testing”.

“Regression testing is any type of software testing that seeks to uncover software errors by partially retesting a modified program.” 

In fairness to Regression Testing. I’m not opposed to the above ideology(except for the partially retesting bit, thats stupid).  I think it has some merit. The concept that modifications in code add risk which testing needs to address is a sound idea and worth taking into account while testing.

But we testers know, that this intent turns out to a different beast.

What gets called ‘Regression testing’ in many companies in my view is not very valuable and has a different intention.  Regression testing ends up a packaged set of tests ( I wince to call them that, as they typically have the same idea repeated over and over) that get repeated at the end of testing to validate that nothing’s broken.

It’s more about maintaing the status quo than any in-depth testing. This to me seems wasteful.

It seems wasteful to me to repeat the same tests giving an illusion of repeatability when in reality we know that each test can never be exactly the same and that getting the same result in a test does not mean for certain that the test has passed.

It seems wasteful to me to exercise a feature using the same testing idea again and again when a different test idea might offer new information about the system

It seems wasteful to me to ask testers to perform tasks that result in the tester disengaging from the activity because its boring.

It seems wasteful to suggest that somehow new features need to be tested differently to older features. Why? Bugs are not ageist.

It seems wasteful to suggest that somehow regression testing demands less cognitive and skeptical thinking.

I think we’re looking at this problem the wrong way. I’d like to suggest a different paradigm.

I’d like to offer up the idea of Recession Testing. Where Regression Testing does its best to test as little as possible, Recession testing insists of focusing on value and removing waste, just like we need to do in a Recession in order to be competitive.

This means, instead of splitting a product into new and existing features, lets test all parts of a product with equal aggression, equal skepticism. When it comes to regression vs new feature bugs, lets make all bugs equal, not some more equal than others!

If we do need to prioritise our work, lets do so on the basis of risk, What are the impact of change on the feature?  What is the importance of the feature being tested?

If you’re going to test a feature, do everyone a favour and test it like you mean it! Don’t give it some half baked, wishy washy run over, to check that its ok and then give the false assumption that you’ve properly tested it. Put the feature through its paces. The feature deserves your respect and  more importantly you deserve to test in a cognitively challenging way.

You know it makes sense!

I wrote this post for Kim, one of my amazing testers who wanted to find out more about regression testing.

I’m sure there are many posts on this topic (if you know of some good ones, do us a favour and add a link in the comments).