We’ve all been there, starting our software testing career as a junior software engineer. I will start this article by quoting “If you don’t make mistakes, you’re not working on hard enough problems. And that’s a big mistake.” – F.wikzek. Throughout the years, I learned that in most cases, mistakes actually can lead to useful discoveries, same as the story I have here to share with you.
A couple of weeks ago I had to automate a new test case. As usual in test automation, I first checked to see if we already had keywords to drive some of the actions needed in the test. One keyword was just written by a junior software engineer, which I was curious of its function and which parameters were expected. As soon as I saw it, my hair stood up on my head! It was a perfect example of how NOT to write a keyword! The same code repeated over and over, no documentation nor a description of the parameters (some of which were not even being used). It always waited a fixed amount of time for some event, so on a fast machine it would waste a lot of time, but on a slow one it would crash with a timeout. What do you do in such cases? In Germany, you cannot just fire somebody, and I am no fan of
violence, but I admit that my first reaction was not that peaceful.
I have been working on Test Automation Patterns for several years at this point. These are patterns that occur when doing system test automation (they are not prescriptive as for instance unit-test patterns or the usual development design patterns). Together with Dorothy Graham, we have developed a Test Automation Patterns Wiki, the issues they solve and even a diagnostic feature that makes it easy to pinpoint the issue(s) that are currently ailing a test automation project.
I’ve decided to use that keyword as a tutorial material. It illustrated better than anything I could ever have imagined the issue BRITTLE SCRIPTS and what happens when you don’t use the following patterns:
DESIGN FOR REUSE
DOCUMENT THE TESTWARE
GOOD PROGRAMMING PRACTICES
MAINTAINABLE TESTWARE
VARIABLE DELAYS
Junior was my first test object, we started with DESIGN FOR REUSE, I immediately asked him:
“Is it a bad idea to repeat the same code over and over again?” It needed some nudging (“You are not “lazy” enough”). Sooner than later, the lamp turned on:
-“ If something changes there, then I have much more to update…”.
“Yes! And what can you do about it?” I prodded, adding “Look up the pattern!” That helped and junior was able to tell me that the solution was to build a new keyword to be called every time needed! Actually, I had already explained that in training, but apparently theory doesn’t always stick!
In conclusion, junior actually managed to deliver a great example to use in tutorials, that, beyond any doubt, is more descriptive and useful than a sole theory. This junior software engineer taught me that simply telling someone about a good design idea doesn’t always translate into them doing it correctly. Lesson learned: this case and many other require clear instructions and demonstrations, which the Wiki can greatly assist in.