It has been over two decades since those clever people sat down in a resort in Utah and penned the agile manifesto. A key tenant of that manifesto was that testing should not occur after the build phase but simultaneously. Since then, a host of methodologies have followed from the CI/CD to TestOps. While much testing and QA has occurred earlier, it has mostly been restricted to unit testing, integration testing, and the early creation and adoption of a test framework. Functional regression testing of new features has not been, by their very nature, possible to execute simultaneously with the build phase.  

However, functional regression testing in the same sprint as the build stage is possible, though it has proven to be elusive and problematic. Test automation has offered glimmers of hope in this area. But in-sprint testing, for the most part, remains an aspiration rather than a reality. But as was with many decade-long-held aspirations, from time to time, someone fills the unforgiving four minutes and goes the extra mile. Simultaneous build and test phases and in-sprint test phases are now a reality. Bold claim; read on to either ridicule or see that reality. 

In-sprint test automation

If you want in-sprint test automation for new features, you need one thing: speed. Well, speed and collaboration, so two things. In fact, speed, collaboration, and scale, but mostly speed: speed of authoring and speed of execution. Now, the advent of testing in parallel on the cloud means speed of execution has been a reality for some time, but speed of authoring still remains problematic. With in-sprint test automation, we get to validate the quality of the software and give Development the fast feedback required to remain agile and deliver faster. But what kind of velocity in test authoring is needed to give you your classic 80/20 split and guarantee in-sprint testing? We need the speed of manual testing with the scalability of test automation. One way of attempting this has been to use recorder-based automation. The problem is (and we know because we tried ourselves 😉) that recorders are great until they are not.  And guess what, you don’t find out they are not until after you have executed/run the test. A classic, real-world example would be: tester sits down to author the test, hits the run or execute button and, oh, something went wrong, either immediately or in the very next release. Time to reauthor, re-execute, cross your fingers anddd, well you get the idea. It’s author, execute, re-author, execute, eat, sleep, repeat, and we’ve not yet found an actual bug. Recorders are just an audit trail until you finally get them to work.

Virtuoso’s Live Authoring turns this audit trail on its head and validates that your test will work instantly. To avoid ridicule and prove this pudding, we are going to eat up an example. If we take a look at the below animation, you see how each step is written in Natural Language and validated simultaneously. As you write each step, it is then executed so that you know your test works. It’s not after the fact. It’s in the moment. It’s live. Now for the clever bit: Virtuoso launches a headless browser and the tester instructs bots to perform, execute, and validate each step as it happens. Our users have seen a 98.35 x increase in authoring speed and achieved in-sprint testing from sprint one.

Now, how about interacting with the UI with your mouse. Yep, another screenshot to show how it works. The useability of recorder technology but with none of the pitfalls. By the way, the screenshot shows Virtuoso interacting with an iFrame; you can’t tell, you’ll have to take my word for it, because it just works. In-sprint testing is no longer aspirational, it is a reality. But can we take this further? 

Build tests from requirements and wireframes 

Getting a testing framework and acceptance criteria is one way to shift your testing left. And if you can author with never-before-seen speed, you can get your build and test phases in the same sprint. But what if you were able to do more earlier? Instead of twiddling your thumbs at the start of the sprint waiting to author the hell out of tests at the end, you could build test structures and fully executable tests from requirements and wireframes? Well, guess what? You can. Let’s say your requirements are written in Gherkin Syntax: simply drag and drop them into Virtuoso and have a test structure automatically generated for you. You can then add meat to the bones at breakneck speed with live authoring.

We can take this even further. As Virtuoso uses Natural Language Programming, you can author fully executable tests from wireframes. If you look at the below example, we have wireframes created in Figma, which we use to create our tests. These are then executed on the app once it is developed. Of course, we do not live in a perfect world. Requirements and wireframes change. But when combined with Live Authoring, you can perform any tinkering needed at lightning speed and further guarantee quality in-sprint. Plus, everyone is thinking more about build and test from designs (which in turn will come from requirements and needs), so you’re baking in a culture of valid build and test.

Meaningful, functional, and end-to-end testing can now happen simultaneously with every stage of the Software Development Lifecycle. Whether it is creating test structures or tests at the planning stage or guaranteeing in-sprint regression testing, we are in a position to grasp the future of agile development now.

Looking for more examples of Live Authoring? Check out this on-demand Webinar showcasing the capability!