Hi all - I'm on the lookout for some quality guest posts to put up here at testertroubles.

If you got something original (and interesting) to say about agile testing, tips to help fellow testers or just want to get something off your chest. Why not contact me at testertroubles@hotmail.co.uk.

I'll credit all posts with a link by to your own blog which will help with SEO link backs.

Read the full post

From my previous posts, you might think I'm anti in favour of automating tests. This couldn't be further away from the truth. In fact, providing it's well thought out, easy to maintain and gives you value for money, you'd be hard pressed to find a bigger automation fan than me.

However, I do have a problem when automation is mentioned, and everyone starts to get starry eyed thinking all their software problems are over. The reality is, it's not!

Ok - now my mini rant is off my chest,

here's my guide to making automation a success.

Read the full post

So we all know how to plan, define and execute tests, but what about ad hoc testing? Can it be as good? Is it effective?

As a tester in my previous life, I've found the answer to this is no. You might disagree with this statement but I've always found that you end up getting side tracked and going round in circles. You might think that ad hoc testing is part and parcel of testing agile, but think again.

Ok, let me back track slightly and tell you how to be as effective as possible when ad hoc testing to the point where it's not ad hoc.

Read the full post

Sometimes analysing what needs to be tested can be overwhelming, but I don't see this as such a big deal. I always start with what I see as the 3 key test building blocks Add, Edit & Delete and then expand and build on them. Too often I've seen some really complex test matrix created only for the most obvious tests to be overlooked.

By following the Add, Edit & Delete principle, you cover many bases such as data loss when saving and usability.

Once you've got these basics covered, then you think about other tests to widen the coverage such as: validation (positives & negatives) and boundaries. See my checklists for other tests.

Read the full post

So you know you want to introduce automation into your regression suite, but not sure where to start? You could go down the traditional route and automate each module. But what if the software's an existing product and there's hundreds of modules already in place?.

It would take an awful long time (and cost) before you've caught up with the code. Mention this to stakeholders/managers and you could be derailed before you've even started.

I've recently heard of an alternative approach that sounds quite interesting and it wouldn't take too much effort to get automation up and running.

Read the full post

I've often wondered if there's such a thing as an 'Agile Tester' or am I just a Tester who happens to work in an Agile Development environment. Having read countless blogs and based on my own experiences, I've come to the conclusion that the 'Agile Tester' really does exist. Let me explain...

The Agile Tester
As a Tester, you guide the development team in a way that ensures each user story/feature of the product behaves as intended and without bugs.

Read the full post