Does your test automation framework suffer from holes so big that it will become unmaintainable in no time? Are you noticing small issues like variables spelled incorrectly and class names that are starting to creep into your automation codebase?
Your automation framework may be heading for demolition unless you address the small issues before they become huge issues. An exaggeration, you ask? After all, how could a little thing like spelling issues snowball into larger issues that can eventual kill your automation efforts?
Don’t allow broken automation testing windows
The broken window concept is actually a theory discovered by James Q. Wilson and George L. Kelling. The theory, in a nutshell, is that there is a linkage between disorder and crime. This can manifest itself, for instance, in a broken window in an abandoned city building. If left unrepaired, it’s likely that all the other windows will be broken as well. The reason for this is that people generally take cues from their surroundings and change their behavior based on what they see.
If a building has a broken window it is often a signal that no one cares. When this occurs, vandals figure they may as well break more windows. This theory can be applied to other things such as litter, theft and — you guessed it– automation code.
Test Code windows
Think of your framework as a building housing many code windows. Don’t leave code “broken windows” un-repaired. Fix each one as soon as you find it. I have personally seen automation framework deteriorate pretty quickly once little code cracks start appearing. This is especially true if you have a fair amount of contractors working on your project. Contractors take their cues from the test engineers that actually work for the company.
Trust me — if the engineers are willing to let small things slide, the contractors will pick up on that, and before long their code will begin to exhibit similarly poor practices. It almost reminds me of a shark feeding frenzy; when a weakness in a code is sensed, they start swarming and piling bad code on top of bad code.
Don’t let all your hard automation work go to waste and end up in a development dumpster. Crack down now!
Test Code reviews are a MUST
A good way to stay on top of things is to treat your automation code just like any other development asset. It should be treated exactly like you treat your production code. Require that any automation code that gets promoted to your production testing environment receives a code review. Without a code review, it cannot be promoted.
Be sure that you enter bugs for things as small as spelling errors, or even incorrect formatting that doesn’t follow your standards. My thinking is that if you can’t trust people to do the right thing with the small stuff, how can you trust them to do the right thing with more difficult automation code?
Your code reviews should train your engineers to learn that you expect quality automation, and that anything less will not be accepted. By adopting this approach you can prevent the dreaded code automation “broken window syndrome” from occurring, and ensure that your automation efforts are successful.