Year End Offer: Save 30% + Teams Save Up to an Extra 25%!

EuroSTAR Conference

Europe's Largest Quality Engineering Conference

Quality Assurance

Choosing the best Test Automation Tool for your QA Team

by

Thanks to Leapwork for providing us with this blog post.

In this short article we’re going to cover how QA teams can set themselves up for success with test automation and test management that fosters collaboration.

But first, what causes these issues within QA, and how does test automation come into the picture?

Test automation has typically been a very siloed operation. The solutions that we’ve been relying on until now are typically code-based.

And here-in lies the problems with code-based solutions:

  1. They are adopted by a small group of people. People who normally have a developer-type profile. This makes automated testing unusable to those who need it – product owners, test managers, ITOps, and business analysts. Collaboration is hindered.
  2. Developers (as we know too well) are expensive to hire and difficult to find. We need developers to spend their time where they create the most value for the business – developing features, and fixing issues that arise during testing.
  3. The maintenance it takes to keep these automated tests running is immense. Take Selenium as an example which requires more time to maintain than is spent testing. This simply isn’t scalable. And it creates another collaboration blocker.
  4. It can take anywhere between 6-12 months to learn a code-based tool. If there is only one person (we’ve discovered that this is quite often the case) building and maintaining these tests, what happens if they’re on holiday? Or sick? Or quit? If a test breaks, there’s no one to catch regressions or run tests. No one to quickly pick up the build and maintenance of said tests. You can’t meet your deadlines. And the business can’t push out releases or customizations quickly. Progress is put on pause.

What can you do to avoid these bottlenecks?

For starters, test automation doesn’t have to be code-based. In fact, test automation shouldn’t require a tester to code at all.

Testing isn’t a domain that’s specific to developers. It’s a task that’s carried out by an entire profile of people. By that logic, test automation should also be accessible to the people who are testing – business users and analysts (aka. User acceptance testers), test managers, and product owners.

And lastly, test automation shouldn’t require more maintenance than the time you spend testing.

A visual automation framework can help you overcome these challenges.

What exactly is a visual automation framework?

Well, instead of using code to describe test cases or processes, tests are built in a way that people find easy to understand – as simple as cobbling lego blocks together. 

In the image below, you can see an example of what a visual automation framework looks like. A series of blocks that enable any tester to build automation in minutes, and an entire team can learn, build and maintain in a month.

Leapwork automation framework process

Seeing this picture for the first time, it probably won’t capture your imagination right away. But this approach to automation means that you can close the skills gap between developers and testers. You’re enabling anyone with the tester profile to build and collaborate on/with(?) automation.

And, you can keep maintenance to a minimum. You don’t need to comb through lines and lines of code to ensure that a test is functional.

The outcome? Your life becomes a whole lot easier. New features, customizations and products are released much faster.

As a result, there is more room for collaboration between developers and testers during the development lifecycle for the work that you find valuable. And for the work that brings value to the organization.

If you want to learn more about why visual automation frameworks are key for collaboration, and how they can foster a future of faster releases, visit our solutions page on test automation.

Author

Anna Thorsen Automation Expert

Anna Thorsen, Automation Expert at Leapwork

Anna Thorsen is an automation expert and writer and covers a range of topics on test automation. These topics range from tackling technical debt, getting the best return on investment from test automation, and assessing your testing maturity so you can build an efficient QA function.

 Leapwork is an EXPO Gold partner at EuroSTAR 2023, join us in Antwerp

The future is here – is QA ready for it?

by

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.

Author

Jani Haapala, DevOps Architect at Gofore

 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.