What does browser-driven agile testing look like?
One of the most unique selling points of Functionize is that it is completely browser-driven. This is a first in the industry and it represents a significant innovation. But what exactly does it mean to be browser-driven?
There are various levels of automated testing. These layers are traditionally broken up into three major categories:
These layers are frequently described as having a pyramid "structure" because of the amount of test and code coverage created during the test creation phase.
Anyone familiar with software development will know these terms but as a quick refresher: unit testing refers to code level testing of individual functions, integration testing tests how those units work together when assembled into modules, and functional testing tests the application or website from a user's point of view. Those are the broad definitions.
In addition to these three layers, however, there are other areas of testing that are just as critical but, unfortunately, easily ignored. These include Performance, Load, Security, and API testing. These fit into different layers of the overall testing stack. A revised stack would look something like this:
The first thing you'll notice is that it's no longer a pyramid. What this means is that there is far more happening at the Functional level than is usually taken into account. Even within the category of Functional testing, we have device level testing, which needs to encompass both cross-browser and cross-browser testing. Taken together, this is a massive amount of testing that needs to occur and it's easy to see why so much of it is ignored. So testing complexity is one problem.
The other problem is that, in order to properly test in a full-stack fashion you need to write tests at every layer on the stack. The challenge here is that the deeper you go on the stack, the more code you need to write. This means more engineers or, at a minimum, properly budgeting in development timelines for test creation. Test Driven Development and Behavioral Driven Development paradigms partially solve this problem but I have yet to speak to a development manager who can answer with confidence that they have 100% code coverage everywhere they need it in their unit tests.
There are many reasons for this. Requirements change, patches are needed, applications grow very quickly. Some projects are better than others, for sure. But it's expensive to do right.
So, what if there was a way to allow non-engineering team members to create tests that both covered the major areas needed at the Functional and Integration layers (including Functional, but also Load, Performance, Security, API) and still provided insight and alerting into problems at the Unit Testing layer?
True, it would not solve the problem yet of incomplete code coverage at the Unit layer, but that problem will exist nonetheless. On the flip side, if you were able to achieve the above, you'd have the ability to solve a massive chunk of your testing and quality problems and still gain better insight into problems at the lowest levels of your application.
This is the vision we have for browser-driven testing. It's the next step in enabling companies to become truly agile with far better coverage.
Why does this work? It works with Functionize because of how we built the system from the ground up to support both engineers and non-engineers in a single platform. Everything is managed in the browser.
How is this possible?
It has been tried before but previous attempts failed. Selenium IDE is an open-source project that attempts to make it easy for engineers to write Selenium scripts (Selenium is an open-source tool that allows engineers to automate web browsers for functional testing purposes). The problem is, for engineers, it's faster to just write code. The IDE tools aren't nearly user-friendly enough for non-technical users either.
Other products have tried as well but nothing comes close to the vision of enabling both technical and non-technical users to create and manage full-stack testing directly in the browser. This is what we are building with Functionize.
We have some resources and videos on the site that explain how this work in detail but, briefly, here is what you can do today. First, you install a Firefox plugin. This allows you to record all of your functional tests directly in the browser.
From there, it's simple. Walk through your application in the browser the same way one of your users would. Set up checkpoints along the way. You can do simple condition matching or you can script in JavaScript. Engineers can even create and execute Selenium tests directly in the Functionize environment, using Java.
But that is just the beginning. In addition to the browser's ability to capture complex workflows, user signups, and more, we've also added the ability to set up load, performance, security, and API testing from the same project dashboard. This has never been done before and we can't wait for you to see it.
