Maintenance

Blogging is something that I do sporadically – there are people who seem to have an awful lot of time during the working day to post updates, but I am too busy to do that, and in the evenings I want to unwind and let my brain relax a bit. I find that during the weekend where I am winding down a little is when some of my better ideas pop into my mind.

Like this morning. I went out into the garden to put the Guinea Pig into the outdoor run, where I noticed just how quickly the grass had grown since it was cut only 8 days ago. Looking around, things are growing at a fast pace – shrubs, grass, weeds and the vegetables in the greenhouse. In fact the grass verges were a metre high before the council cut them last week!

I sat with a cup of tea and started thinking about the maintenance jobs I need to do later on today – onions and lettuces to plant out, weeds to pull, some shrubs to trim a little. You may wonder where I am going with this, and what it could possibly have to do with testing, but here’s the thing – it’s all about maintenance. Oddly as I was thinking about gardening, the idea for this blog came to me.

As testers, we need to perform maintenance around our testing artifacts in the same way that gardeners need to do in their gardens.

We have many test artifacts – in my organisation there are testing notes for each application, so that if a tester is new to that team, they will have reference notes about the application, what it does, where environments are, the test data needed, where the automation pack is etc, and of course we will have our test automation suites as well.

Having this information to hand is a good thing – but only if it is maintained and kept up to date. Applications are ever changing and we should ensure that we perform maintenance as part of our core testing approach, rather than leaving it.

The grass outside our houses and on the green up the road was left to grow to a metre tall, and as a consequence children couldn’t kick footballs around until it was cut by the council. It is the same with testing – things become unusable. If we do not maintain our automated tests, they either do not run at all, or a number of them fail, giving a false indication to the development team as to the state of the build. It then become necessary to waste time investigating why some failed, and determining if they are genuine failures or not. And if links are not updated, or test data suites are ignored, they become useless and the time originally invested becomes worthless.

Planning to include maintenance as part of our testing day jobs is a must – but it is a challenge. We haven’t got there yet with all teams, due to pressures for delivery, so this is something that I also need to work on with my team. It isn’t easy, as we have to persuade others that the time spent doing the maintenance is valuable and gives us some pay-back.

I’d be interested in hearing from anyone who has managed to pull this off, as I would be willing to bet it may only be a reality for a minority of testers.

My first challenge today is getting the garden in order – who knows, I might have some more bright ideas whilst pulling out some weeds later (it is very therapeutic!!).

Advertisements

One thought on “Maintenance

  1. Nice article Steve. I have shared this with my QA team too. There is a misconceived idea that regression tests are written once, forever. I think your article busts that idea. I like the way it is written and curious to know anyone who pulled it out with all concerning parties. – Please share your findings, Steve.

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s