Tag Archives: automated tests

Agile, BDD/ATDD, Software Development, Software Testing

Putting Cucumber where it’s not supposed to go will hurt!

Leave a comment

Today, I came across this post by Ryan Bigg where he talks of the pains he’s experienced with Cucumber.

Fortunately for Ryan, the outcome was a positive one, he ended up finding what appears to be a nice looking API for automating test-execution.

The experience he had with Cucumber, however, is a common one. Often teams start using Cucumber in an effort to reduce the need for programming skills when writing automated tests.

This isn’t the problem that Cucumber and other BDD tools are trying to solve and this is why so many teams who misuse it in this way experience difficulty and frustration.

BDD tools like Cucumber are designed to help teams and their customers arrive at a shared understanding of the problem they wish to solve (in terms of the user’s goals and tasks). It’s not really intended to describe the solution (i.e. step-by-step interactions with the GUI).

If your Cucumber scenarios have words such as “click” or “type” or mention field names and the like, it’s probable that you’re either:
a) Using Cucumber to automate test-execution (not what it was intended for) or
b) Trying to do BDD but writing the scenarios at too low a level of detail.

If you’re doing the latter (b)… then you may find the post I wrote over the weekend useful.

If what you’re doing is (a) then the post I wrote over the weekend might help you go down a path where automating your tests will make the transition to BDD that much easier.

If you really, really only want to automate test-execution then you might find that you’re putting Cucumber where it’s not supposed to go… and just so you know – that’s probably going to hurt 🙂

Agile, Software Testing

Boredom: a Testing Smell?

Leave a comment

This first appeared on my old blog in June 2005.

Somebody I know who was doing some (unscripted) testing spoke of being bored the other day… I have always found boredom to be a sign that something is wrong.

I believe, as has been said by Kaner et al, that testing is a brain-engaged activity. If that is the case, why would I ever be bored?

Borrowing the Smell metaphor… I would say that boredom is a Bad Testing Smell. If it isn’t a bad smell, it is a whiff of an underlying bad-smell for sure.

If on the rare occasion I find that I am bored, I’d ask myself:

  1. Am I testing this area more than I need to? (if so, why?)
  2. Am I losing concentration because my brain is tired? Do I need a break?
  3. Is what I am doing so repetitive that perhaps it should be automated?
  4. Is there a better way of testing this feature?

If I answer “yes” to any of these, I know that perhaps I need to do something differently. Whether that is feasible in a given context, might be a different story.

Update 9th July 2010: This applies to scripted testing as much as it does to exploratory testing. Generally, I’ve found that boredom during scripted testing is because we’re asking a human to do something we should be asking a computer to do… The main barrier to this, in my experience, is that it is harder to write the automated tests than to write manual scripted tests… so, I look for ways to make automated tests as easy to write as manual scripted ones. Usually, I can achieve this with a little effort and have found it makes a huge difference.