The topic of automation code maintenance came up in a recent partner workshop, and it led me to post on this topic. Software development clearly involves writing code, and collectively we are very adept and proficient at it. As professional developers we also, maybe unconsciously, only write enough code to do the job at hand. I remember many years ago, too many in fact, building UIs in Turbo Pascal by combining ASCII characters into dialog boxes and UI elements in code. Remember Checkboxes like this: [X]?
Would we dream of doing that now? Modern developers use code generation every day, we design dialogs in tools like Visual Studio and the code behind is auto-generated, in turn-relying on UI frameworks to render those elements. Developers are talented enough to build a UI from first principles but we are better tasked building the logic that uses these elements to achieve the business objective, rather than building it from scratch. i.e. just enough code to do the job. Oh yes and what about maintenance? Well, it goes without saying that the more code we hand craft the more we have to maintain, don’t we just adjust the design and rely on the code generator?:
// Auto-generated code – Do not Edit.
My worry with current trends is the exponential growth of test automation code in software development projects, the ratio of Test code to App Code is on the rise and often significantly greater in Agile, TDD and BDD projects. With a “shift left” going on and Test Automation being woven into successful CI, CD and DevOPs it is understandable that this is the case, but are we writing "just enough code" and in the right way?
Sadly, too often test automation is seen as a junior development task, commonly for testers making the technical transition from Capture-Replay techniques and “a bit of VBScripting” to fully fledged OO languages and associated IDEs. I’ve even head cries of “Let’s retrain all of our QA staff to be devs”. While I’m sure a good few will make the grade I am also sure that a good few won’t.
So based on the two assumptions, it leads me to surmise that a good proportion of our collective code output as a software development industry is being hand crafted by inexperienced developers.
And the biggest fear of all? The same level of established rigour isn’t being applied to the development of that code, above all it goes by largely untested. By way of example, I saw the following in a review of a very large automation project before (written in C#), variable names changed to protect the innocent!:
If (output=0) {
report.Pass;
}
Else {
report.Fail
};
Did you spot it? Yes, this will always report a pass, reporting false positives, and was responsible for maybe 700 validations steps in the project. Assurance where it shouldn’t be, potential brand damage and financial risk. All that on the head of untested code written by a junior developer.
So what can we do to improve? One thought might be to ask our more seasoned developers to write our test automation code. Did I just hear a collective groan? Or do we look for efficiencies, tooling, code generation techniques etc. and write “Just Enough Code” to do the task. If we could reduce the amount of hand crafted test automation code down to 10-20% of its current level and auto-generate the rest based on some design tooling, wouldn’t that be worth investigating?
