The Perils of Test Automation – From the Tantalising First Date to Old Age
“Your eyes meet, you’re transfixed, your heart flutters. It’s incredible, they’re attractive, you get on like a house on fire, the conversation is riveting, and you share so much in common. In what feels like the blink of an eye and you’re settled into one another’s quirks and you feel like you’ve met the one. You’re ready to take the next step, moving in together, the joint bank account, the shared commitment and tackling the future together. Then life moves on, it has presented its challenges and its joys… the middle-age spread is starting to show, things have changed, is it time for a mid life crisis or stay the course. You nod off on the couch with your favourite angling weekly and wake up old and grey and wonder where it all went right and where it all went wrong and wish you could start off on a different foot but incredibly thankful for what you have achieved in life. I hope to take you through a side by side analogy of a test automation journey through Test Automation likened to that of our journey through life, I hope you enjoy!
The Tantalising First Date
Over the past 15 years of the testing industry test automation has trailed a blaze from the early adopters straight into the hearts, minds and onto the critical path of delivering QA into agile projects. Speaking personally this appreciation of value-add in the wider software development community certainly simplifies the justification around automation adoption however many of the same challenges remain.
The early stages of automation are an incredibly exciting time, business/technical stakeholders have high expectations of what automation may offer. As a QAer your mindset rapidly shifts to appropriate tooling selection, up-skilling as needed as rapidly as possible, proof of concept of both the automation tool to achieve the desired results & the compatibility between your selected tool and the application under test, building an early test automation framework… these challenges whilst trying to maintain appropriate expectations with stakeholders. If expectations are too low investment may not be worthwhile in comparison with competing projects in the organisation, if expectations are too high then automation may under-deliver which certainly will not help career progression.
In this early stage the primary objective, of automation, is to achieve that quick return on investment – understanding the early engagement may bear fruit, you’ve had a wonderful first date and you’re already thinking about the second and third! Granted, you’re wearing your best outfit, the lights are low, the music, the atmosphere…. we’re off to a promising start!
Let’s Take the Next Step
First impressions around automation have been cemented and feel like a distant memory, time & resource is allocated and protected and automation needs to deliver at appropriate stages in the project… be it sprint by sprint, drop by drop, phase by phase or on a project basis.
Just like you’re more comfortable with your partner and they’ve become part of your life, the usage of the automation is starting to become more ingrained in the organisation and use is more widespread. In the same way you’ve seen an apartment that would suit your needs perfectly but you’ve never lived with anyone before; the automation framework and scripts have gained a critical mass and inclusion into a continuous integration tool is a bridge to be or just crossed. You’re opening your first joint account and pooling your income and paying shared expenses, it’s us against the world! Continuous Integration is becoming ingrained in the organisational psyche and the investigation & maintenance costs are starting to be spread within the organisation as more users are active customers of the automation suites.
The Middle-Age Spread
The business value that our automation framework offers is undeniable, risks are more quantified, regression issues are caught early and highlighted. However, the bad habits are starting to manifest…. not tidying up after yourself, test automation failing periodically and not due to software change, dirty laundry not quite finding its way to the laundry basket, automation scripts that are proving difficult to investigate/debug, the beautifully turned out attire from the first date isn’t quite there as often as it used to, automated scripts that aren’t failing when they should… who tests the test, you’re shared interests are dwindling, what standards were used when writing the tests?, the bad habits are taking more of my attention then the positives.
You’re arriving at a crossroads! you’re coming to the realisation that some your decisions early in your relationship with automation were good but could have been better. Could you have had better coding standards around your test scripts? there is a greater likelihood that you’ll be looking at the test automation scripts more often than your application under tests code. Did you write your automation framework cognisant to minimising debug time in the event of test failure or are you getting the word “Error”, infuriated you feel like it should say “Error – good luck debugging! 🙂 ” ? Were they sufficiently commented to allow re-factor/rework when the application under test changes, which is inevitable.
You’ve also embarked on the automation road with a specific toolset, in hindsight how has that panned out? is that product still actively being supported? Is there a newer/better tool that would meet your needs? Do you need to forge ahead or migrate to a new/better tool? What do you do with your existing test suites? Migrate to a new tool or try and maintain two tool sets? Has the application under test augmented to support technologies/platforms that your automation tool does not? All the time your automation suites are growing, increasing, becoming more complex?, being written to different standards by a combination of newer and older resources.
So you’ve successfully navigated the middle-age spread and forged ahead down the automation path. Often the appreciation of the savings that automation brings are now taken for granted. The challenges have further morphed. There are more automation suites than we have time/machines to run in a single run. The upkeep of the automation is starting to hurt when you can least afford it. Failure investigation & triage isn’t as rapid as is needed.
Automation has been a great friend and covered more ground in testing than any manual testing effort could cover ever but you’re now facing difficult decisions in grappling with the maintenance of automation. Automated tests are failing for various reasons (a) the application under test has changed necessitating script update/retirement/replacement (b) intermittent failures from misbehaving test script/environmental issue/intermittent application under test failure (c) poorly written non deterministic test scripts that have been written and grown over time to varying standards. At this point in automation the application under test is often a mature product with growth and investment slowing from an organisation perspective with resource commitment remaining steady/declining. Even with a relatively low percentage of failure the sheer volume of automated suites combined with the growing numbers lead to difficult decisions.
The Test Automation Journey
Automation is an incredibly valuable asset and is key in ensuring the quality of today’s projects. The Test automation journey explored here is like every relationship; you have to bear in mind how long the relationship may last. An appreciation of automation lifecycle and the challenges that are around the corner can help ensure the problems of tomorrow are a lot easier to deal with and less significant. Buy the lovely surprise gift today certainly may help the secure the permission slip for the weekend away with your friends! Wishing you the very best in your journey through automation.