Tag Archives: Agile

Speed Kills

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.

 

 

Is automation the new documentation?

Have automation tools become the new templates in software testing? The cornerstone on which all our testing hangs on? Its starting to look that way.

Think about it.

The traditional method of testing was to use a software testing process identifiable by test templates. These templates were (and in many cases still are) the focal point of all testing.

Then some new thinkers introduced concepts such as Exploratory Testing and Context-Driven Testing, placing the tester central to the testing exercise. It rocked the testing world.

Then along came agile with its focus on automation. This has lead to a heavy emphasis on automation instead of  the individual behind the tool.

Traditionally the majority of time in testing was spent writing heavy onerous documents, instead now, we are writing automated test scripts. What has gone wrong?

I was suprised at the emphasis on tools in agile testing talk I went to, as I am suprised at the interest in automation tools by all testers.

My feelings about automation are best described by this post by Kevin Pang where he writes:

The difference between a good developer and a bad developer isn’t whether they use duct tape, it’s how well they can recognize whether a situation calls for it.

There is a similar problem in automation testing.  Automation in itself is not a good or bad thing, its knowing when to use it. That’s whats been overlooked in this whole agile testing excitement.

The skills required to be a good tester are being overlooked in favour of good automation skills.  Instead of “are you a good tester”, you are being asked “what automation tools you know”.

I can understand why, its easier to quantify automation tool experience than quantifying what makes a good tester.

We need take more care about what we discuss in Agile testing. The emphasis on what tools is  too heavy and a rebalance is overdue.

More emphasis needs to be put on how a testers creates a strategy for automation, not just the type of tool they use.

It’s time to reset the balance and put the tester centric to the testing effort.

The Irish post – QTT now published

An Irish Post

An Irish Post

Some people asked me to let them know when my first post on QTT is up.

Well its up now. You can find the post here

Quick Testing Tip  By Anne-Marie Charrett

I hope you enjoy it.

Anne-Marie

http://www.quicktestingtips.com/tips/