Thanks to Jani Haapala, DevOps Architect at Gofore, for providing us with this blog post.
William Gibson famously said, “the future is already here – it’s just not evenly distributed”. In software development, we constantly talk about future trends and future methods that are coming one day, but so often fail to see that in most cases, the future is already here – but maybe not yet in your context.
The problem with QA and testing is that it always seems to play catchup with these trends and methods. QA is mostly reacting and adapting to challenges that the future is bringing to us, rather than proactively creating or defining them.
So, if there’s already a recognized need, how come we’re not answering it? In my opinion, it’s because, in some cases, those of us in QA are still living in the past.
Living in the past
Some of us are still living in the past – although we might not realize it. In these situations, I see that QA as a function fails to provide the value that it should. I have found out that there are two major contexts where QA is still living in the past:
QA is a step: in many cases companies have adopted agile, and are driving fast toward DevOps. Some companies are already doing DevOps in some form. But QA still seems to be mostly a manual step on these fast phased cycles. Developers are having CI/CD pipelines; build and unit testing is happening automatically but when it comes to functional testing, end to end testing, and system testing, it often tends to be something that “needs to be asked from QA people”. This separates QA to its own manual silo, and creates unnecessary handovers. Instead of this, QA people should drive toward automated testing that is fully integrated to the CI/CD pipelines that development is using. Test automation is not a tool that testers use; it’s an automatically triggered set of tests by commit of code.
QA is about running tests: QA is often still fixated on ‘creating tests’ and ‘running tests’, and it seems that the only function of QA is to be the executor of tests. This leads to a situation – with test automation in particular – where there’s thousands of test cases that might pass and might not, or nobody cares. Tests are becoming mere ‘experiments’ that fade over time. So, QA and testing should be all about bringing valuable feedback to people that need it. They should focus on thinking about the most valuable thing that we can get from the system, and how to present that to those who need it. And remember, most valuable things change, and so does the importance of any given tests.
The future that we live today
So, what are the latest trends that QA should take note of sooner rather than later? What’s already on our doorstep, and needs immediate attention? Let’s hop on the train early, figure out what kind of feedback is needed, and learn how to provide that. Some of the future scenarios that we are already living include:
The ‘XaaS’ movement: in the past there was a huge ‘XaaS’ moment – ‘Something as a Service’ shaped our daily lives. Rather than creating everything themselves, development teams started to consume services. Cloud services, version controlling services, deployment services, and so on. After that, we found out that these services and platforms could be controlled programmatically. So, the new ‘XaC’ boom started. ‘XaC’ means ‘Something as Code’, and that means that everything is done by creating a code file for it. Examples of these are Infrastructure as Code, Configuration as Code, Storage as Code, and Detection as Code. For this modern need, QA also needs the ability to test, verify, and provide feedback on how these code files are working
QaSec ownership: if QA is considered to be a silo, then I have a story about InfoSec! InfoSec is often an even more separate action than QA. InfoSec is mostly done completely separately, and if InfoSec tries to suggest something, it’s only considered if it doesn’t affect the daily work, or make it more complicated. In the future, InfoSec should follow in the footsteps of QA – and be part of QA. Having QA and Sec combined to one QaSec needs to have real impact to development. Too often agile managers are cut down so much that nobody is in charge of overall quality or security. That’s why QaSec needs to be owned and recognized as one of the key stakeholders of development.
New architectures: The world is truly evolving. People who were running systems of physical machines or virtual machines are now running the same services on clouds in the form of service meshes and microservice architectures; or even without any maintained resources on just lambda functions. QA needs to be very aware of both today and the future architectures to be able to give proper feedback on these. QA can’t also test those if they are stuck on ‘just using’ something that was set up for them; they need to be actively involved in creating and improving these to define safe production environments, and get production-like environments for their needs.
Get ahead of the future
So, if we want to be proactive instead of reactive towards new trends and ensure our validity, what could we do? I don’t want to start doing too much guesswork here, but some future “safe bets” that will eventually take over the world are:
New methods: new methods are coming, and those methods need the capability to adopt. QA might be done on different stages or in different contexts. For example, one of the promising ‘new’ methods is Google’s Site Reliability Engineering (SRE): that’s Google’s take on DevOps, and focusing on reliability. SRE is an extremely useful practice when companies are having more large scale software production. There’s likely more than one, and they can grow rapidly in popularity.
RPA: Robotic Process Automation is something that we already see companies experimenting with. This enables companies to automatically connect legacy systems together to form long, fully automated business processes. RPA used to be available only from vendor companies with a high price tag, but more and more RPA is now done with pure open-source software. In many cases, QA can repurpose their test automation knowledge and tooling to start implanting RPA solutions also.
Artificial Intelligence: If RPA is the first step into full process automation, AI is mostly the target. Even though AI sounds both cool and scary, the reality is that we are far away from general AI that works just like a human. In QA’s scope the near future is very interesting when it comes to testing early AI applications, or using AI as part of the testing. People’s first reactions is to point out that AI can’t do the same things as humans, or make decisions – but that’s not the point (at least right now). The point is to help people make the right decisions with a faster lead time.
Get into the high performers group
If you recognize yourself embracing the future, please, be loud about it! Keep presenting at conferences, and spread the word on how to get ahead of the game, and help your fellow QA people join the high performers group. But if you see yourself in the past or present group, please start taking advantage of all of this, and begin the journey to elevate yourself to the high performers group. It just takes a willingness to learn, and some time, to get you started on your journey.
Jani Haapala, DevOps Architect at Gofore
Jani works as a DevOps architect at Gofore. He is passionate about measurement, feedback, and continuous automated quality feedback loops. Jani’s journey started from manual testing and has evolved to full-scale software development automation. Jani thinks that automation can help everybody and increase value in anything.