Skip to main content

Bug Automation

In many of my clients, more effort is spent on 'test automation' than on other forms of testing or quality assurance. That can be the right choice, for example, I worked on a Data Warehousing project where we needed to write some test automation before we could test the data and its processing.

Many other projects in different technology areas also spend a lot of time on their test automation. To be precise, they spend an increasing amount of time fixing & maintaining old 'tests' and 'frameworks'.

There are great tools around to help us write these automated checks quickly. But as with many software systems: maintenance, in the long term, is where the time and money goes. That is why I'm surprised we don't use short term automation more. We have the skills.

One good example of short term automation is Bug Automation. A simple script / executable that recreates or demonstrates a bug. This isn't a new idea, I've been doing it for years and I know other people have to.

Its common on open source projects to report an issue with example code, to clarify the exact issue you are reporting. Its a quick way to demonstrate the issue.

I'm not referring here to the idea of building a regression test suite from 'tests' (checks) from each bug fix. You can do that if you want, It can be very useful, but you are back to maintenance overhead.

By Bug Automation I'm referring to a disposable script that proves the system is broken. We can falsify the assumption that we have 'working' software. We can't prove the system is bug-free with our automation, but we can show its broken. 

The automation isn't there to indicate when we have fixed the issue - but to highlight that we, as a team, have created one.

In many situations a quick chat, screen-shot or URL is enough to help a developer fix a bug. But not always. For example, A tool like BlueBerry Test Assistant could help demonstrate a bug quicker than I can explain it. But in some contexts the best tool is code.

For example: I discovered a security flaw in an open source Content Management System used by several large media corporations, including my client at the time.  I could have described the issue to people, but that would have been a poor substitute to an actual demonstration.

Its hard to persuade someone that their 'secure' random token generator isn’t random - its easier to show them.  So I wrote some Bug Automation, and sent this along with a summary of the issue. (And together we figured out a more secure solution)

Another simple example: Google has a minor bug whereby if you enter Hebrew or Arabic text (with white-space) the full stop on the 'Press Enter...' message is placed at the wrong end of the sentence.


While the issue isn't hard to describe, or screen grab (see above). Recreating the issue might not be so easy. Therefore we can create some simple Bug Automation, like this.

Other members of your team can run this script and see the issue on their own PC. They don't have figure out how to type Right To Left languages or battle an OS or bug tracking system that doesn’t like you to copy and paste such things. Used purely as a communication aid, It also doesn’t have the maintenance overhead of trying to maintain a 'proof' of a fix long term.

Bug Automation is already a multimillion dollar industry, its called the Zero Day Exploit industry. Unfortunately that automation is often used for nefarious purposes. But as an example of positive deviance, it might be wise to pick-up on the clever things other developers & testers are doing, and use them for ourselves and for good.

Comments

Popular posts from this blog

The gamification of Software Testing

A while back, I sat in on a planning meeting. Many planning meetings slide awkwardly into a sort of ad-hoc technical analysis discussion, and this was no exception. With a little prompting, the team started to draw up what they wanted to build on a whiteboard.

The picture spoke its thousand words, and I could feel that the team now understood what needed to be done. The right questions were being asked, and initial development guesstimates were approaching common sense levels.

The discussion came around to testing, skipping over how they might test the feature, the team focused immediately on how long testing would take.

When probed as to how the testing would be performed? How we might find out what the team did wrong? Confused faces stared back at me. During our ensuing chat, I realised that they had been using BDD scenarios [only] as a metric of what testing needs to be done and when they are ready to ship. (Now I knew why I was hired to help)



There is nothing wrong with checking t…

Manumation, the worst best practice.

There is a pattern I see with many clients, often enough that I sought out a word to describe it: Manumation, A sort of well-meaning automation that usually requires frequent, extensive and expensive intervention to keep it 'working'.

You have probably seen it, the build server that needs a prod and a restart 'when things get a bit busy'. Or a deployment tool that, 'gets confused' and a 'test suite' that just needs another run or three.

The cause can be any number of the usual suspects - a corporate standard tool warped 5 ways to make it fit what your team needs. A one-off script 'that manager' decided was an investment and needed to be re-used... A well-intended attempt to 'automate all the things' that achieved the opposite.

They result in a manually intensive - automated process, where your team is like a character in the movie Metropolis, fighting with levers all day, just to keep the lights on upstairs. Manual-automation, manumatio…

Scatter guns and muskets.

Many, Many years ago I worked at a startup called Lastminute.com (a European online travel company, back when a travel company didn't have to be online). For a while, I worked in what would now be described as a 'DevOps' team. A group of technical people with both programming and operational skills.

I was in a hybrid development/operations role, where I spent my time investigating and remedying production issues using my development, investigative and still nascent testing skills. It was a hectic job working long hours away from home. Finding myself overloaded with work, I quickly learned to be a little ruthless with my time when trying to figure out what was broken and what needed to be fixed.
One skill I picked up, was being able to distinguish whether I was researching a bug or trying to find a new bug. When researching, I would be changing one thing or removing something (etc) and seeing if that made the issue better or worse. When looking for bugs, I'd be casting…