A Testers Bag of Tricks

We all go to work every day carrying a bag under our arm. The bag has everything we could possibly need for every possible scenario we may encounter for our working day as a tester. Each time we encounter a problem we dive arm deep into the bag and pull out the solution to the problem. Right................? No? Just me then?

If someone really has got a bag with a solution to every problem in (and I'm not talking about a big bottle of Vodka) I'd love to hear from you.

Now for the rest of us who don't have that we will just have to make do with what we have in our heads. What am I waffling on about?

Well I guess I am trying to attach some realism to the daily life of testers. I am asking testers to be ambitious but flexible. To strive for better but solve the problem in front of them.

I regularly read articles or listen to webcasts explaining how the latest new concept or tool in testing will revolutionise the way we test software. How we can automate every behaviour or every regression test? I have lost count of the times I am told that regression testing or GUI automation are prehistoric methods of testing and how anyone still engaging in such activities should catch up with modern software development techniques.

Back in my university days I read a book (yes it was a long time ago but I can just about remember):

Software Testing In The Real World: Improving The Process

-Edward Kit

I'm not suggesting you buy and read this book. It was written in 1995 and much of the content was based on available tools and development technologies of the time. It is quite frankly out of date. What does stick in my mind however is the general concept and ideals behind the decision making suggested by Ed. Some of this I understand much better today than I did when I read it, which is really no surprise as I was probably reading it after 4 or 5 pints in the union bar. The pragmatism of making decisions based on the way things are rather than how we would like them to be is likely to yield more success than trying to perfect everything first.

Testers are working in all manner of teams and situations, from Greenfield to brownfield, from VB to Node.JS, from Web solutions to Excel Macros, from small local agile teams to large corporate test teams located across the world........ you get the point. So why then are people surprised when they attempt to implement something that has worked elsewhere without understanding why it has worked elsewhere?

Testers have a wide variety tools and options available to solve different problems, and believe me they will have a wide variety of problems depending on the situation.

I should add at this stage that when I talk about tools, I don't mean specifically 'testing tools'. I am generalising about everything that a tester may have access to and can be used to make a difference. These include processes, training, actual tools, testing techniques, other resources.

What testers can do and should do is to really understand the situation they are in, fully understand what tools and options are available to them (look hard and do some serious research) and then look at what they can change or improve that will make a difference.........NOT what someone else in a completely different situation has changed to make a difference.

Probably the worst thing a tester can do is to accept everything and not try to adapt and change. If you lose the ability to question things then are you losing the thing that makes you a good tester? Strive to become more efficient and to find better ways to improve software quality but do so in a way that works best in your situation!

I'm not sure the level of humour in this post is nearly enough however in keeping with my previous posts please find the token random image: