mabl today added a load testing capability to its portfolio of application testing tools that it makes available via a software-as-a-service (SaaS) platform.
That capability promises to make it simpler to streamline testing within a DevOps workflow by making available load testing tools that measure application peformance alongside existing mabl tools accessible via a test automation platform.
Dan Belcher, mabl CEO, said the goal is to make it simpler for developers to run functional and non-functional tests as early as possible within the software development life cycle.
It’s not clear how much responsibility for testing is shifting left toward developers, but as it becomes simpler to run these tests it is more likely they will be run, noted Belcher. One of the core issues that plagues application development today is the inadequate level of testing. That issue is largely because it takes too much time to create and run relevant tests, he added.
mabl streamlines that process using a test automation platform based on a low-code tool that makes it simpler to create and manage the testing process. Those tests can be configured to run independently or be integrated with a DevOps pipeline, noted Belcher.
Shifting testing further left toward developers doesn’t eliminate the need for a dedicated team of testers, but it should reduce the number of routine errors being made. That reduction should free those development teams to focus more of their time and effort on more complex quality assurance (QA) issues, said Belcher.
Of course, more testing processes will become automated as artificial intelligence (AI) continues to evolve, so most organizations will soon find themselves revamping those processes. In theory, SaaS platforms that aggregate testing data should be in a better position to apply AI models to testing. That’s critical because the pace at which even more complex applications are being built and deployed shows no sign of slowing down.
In the meantime, DevOps teams should assume they will soon be held more accountable for security issues that arise after an application is deployed. It may be a while, but the number of legislative initiatives focused specifically on application security has increased; it’s only a matter of time before laws that hold organizations liable for security are going to be passed. At the same time, the level of tolerance application software consumers have for issues that arise because some trivial mistake led to, for example, a SQL injection attack, is dropping. The expectation is that application testing is soon going to be a lot more thorough than it has historically been.
The issue, of course, is that too many development teams tend to view security requirements as obstacles to be overcome rather than as intrinsic elements of the QA process that is supposed to ensure expectations are consistently met and exceeded.
At this juncture it’s clear that application testing is going to improve. The only thing left to determine now is how much friction will be experienced on the way to achieving that goal.