A whole new world…
(a new fantastic point of view)
Sorry, Aladdin, for borrowing your theme song. I do want to share about this world I am dreaming of – all the new horizons to pursue, but not from a magic carpet.
I dream of a world…where test automation can be used at its maximum potential – to be as helpful as it can for our daily lives. And before moving any further – yes, test automation is more than my job – is my passion.
Now… as I was saying. Despite our best efforts, test automation is still not where it should be. It is not fulfilling its purpose.
What is that? What is the very goal of (using) test automation?
Well, I’m glad you’ve asked.
In our day to day (software) world, we work with systems. A system is by design developed to be reliable, stable – but also easy to use and to be updated. To grow and to be, as much as possible, automated. And for its maintenance and testing – well, it needs the support of test automation engineers.
In this fast-fashion, fast-food world, delivering software products has to be … well, fast. Super-fast. And the new products – new. And awesome.
This is why is we tend to focus on getting each application developed and out the door faster and faster. But in doing so, at some point, we have to give up something. You have to cut down from somewhere. That “somewhere” is, more often than not, the testing process. You may call it “minimal attention”. A “let’s wrap it up and go” approach. The fact is that we are not focusing on the very steps that are supposed to make our apps testable and reliable to automate. When it should be quite the opposite.
Why would we focus first (or at least, more) on the testing process?
Having a reliable and high coverage test automation suite brings certain undeniable benefits.
Application maintenance becomes easier and more efficient – less effort in test execution and result analysis, not to mention the fact that any defects generated by code changes can be traced within minutes. There is a higher level of trust in the application, due to the performance improvements – with little to no degradation – and the increased stability.
There is actually a methodology called `test driven development` – which, like the name says, views testing as an extremely important phase in system development, and one that needs to be considered first. This sounds good – in theory. In practice – I have yet to discover a company that is actually implementing it. It would have to have a different mindset than the norm, for sure.
I can almost hear your comments – about how this approach seems too revolutionary, too much or simply unrealistic for your company. The good news is that there are smaller steps you and I can take in the right direction – starting from where we currently are. There is always something to be done.
For example, we can improve our application development flow – regarding the way we implement simulators for 3rd party software and then add the security measures preventing automation on higher environments.
More precisely, the idea is to integrate them earlier – because at the moment, the specs for 3rd parties are not available at the early stages of the development or they are not useful enough. And there are, of course, many cases when the 3rd parties don’t allow automation. And even if they would allow for some levels of automation, the development team has no control over the 3rd party software implementation.
Currently, even if the software applications –or, more general, the software systems – are available for the general user, they have a lot of security measures in place as to discourage automation. From things like captcha to timers that block the request if it is the same or too similar to the previous one to simply closing the session after a specific time and so on.
The issue is that we tend to be overachievers and we sometimes implement these measures before we need to, or we rarely consider allowing a way to replace these measures on certain lower systems, with very limited access.
This is pretty much the way we are doing things now – and we think it works. But we rarely count the price the development and testing teams are paying, in terms of effort and nerves. And let me tell you, it’s high enough. And there is enough blaming and firefighting between them and the clients – and plenty of frustration to go around.
We are focused on delivering as much as possible, as fast as possible – so much that the quality tends to be the last thing on our minds. Until we discover issues in our systems – then it’s the only thing we can focus on. And so we fix them and go back to our “quick and dirty” deliver style.
And sure, this vicious cycle is being discussed in most team/client meetings. We say we need to keep “quality first”. But at the moment, it’s more or less a catch phrase than actual mindset. What we hear is “do more, do faster” and “go big or go home”. If only there could be another way…It takes some brave, crazy people to change the system. But it can be done. One code line at a time.
