I love that quote from Ricky Gervais. It typically resides in a corner of my monitor, where it reminds me that no matter how much organizational or grammatical debt I’ve accumulated, it’s never too late to get to work on what matters most to me.

As I saw at the recent STARWEST 2015 testing conference, what’s important to many today is achieving some level of “continuous” in their software development life cycle.

“Continuous” has become the golden benchmark for so much of software: integration, testing, delivery, deployment—with Continuous Quality and speed being the ultimate goals for startups to enterprises and everyone in between.

(Related: Testing needs to catch up to agile and DevOps)

These aren’t new goals, either. But as more companies step up at these conferences to share their story of, “How we reached Continuous ______,” your leadership is going to expect greatness from you and your team(s) as well. Especially if it’s your competitors on stage getting the applause.

At STARWEST, Continuous Testing was the week’s leading topic by a mile. Speakers shared “keys,” “good habits” and “strategies” for Continuous Testing; I counted nine different sessions that described a path to Continuous Testing just in the title alone.

As someone who has attended this show multiple years in a row, I found this not repetitive or lacking in variety, but promising for the future of software and the testers who help build it. In years past, the overarching theme would often be debates around manual vs. automated testing, or how testers can prove their value to an organization that fails to respect quality as much as speed. But as software failures and their economic impact continue to dominate headlines, I’m not sure Continuous Quality has ever been more sought after.

Manual and test automation camps have a huge opportunity to delight leadership and customers alike by embracing Continuous Testing, and not at the cost of speed.

Adam Auerbach, technology director at Capital One, led a fantastic session, titled “Putting Quality First through Continuous Testing.” While Capital One’s dev/test processes, culture, shared dedication and accountability for quality code were clearly beyond impressive to the entire room, it was his confession that struck me the most: “We’re still trying to get to Continuous Delivery. We’re not there yet. And you may not get there, but get close.”

With all of the test automation, short feedback loops and skilled dev/test teams in place, the state of Continuous Delivery is still a work in progress at Capital One—but they’re a lot closer than many out there.

Auerbach also shared some wisdom from DevOps guru Jez Humble, who had recently visited the dev/test teams at Capital One. We often assign value to all sorts of tools, practices, methodologies, collaboration, etc., but as Humble pointed out to Capital One, “What has value is code that’s in production, and it works.”

While software that can be released to production at any time is still a goal for most (has not yet happened), people like Auerbach are on the right path to making it a reality.

I was also pleased to see many of the week’s sessions dedicated to helping testers see the need for looking at testing in a new light, and to start looking for solutions to the problems that make Continuous Testing, Quality or Delivery seem like a pipe dream at best.

Parasoft chief strategy officer Wayne Ariola told the crowd at his session on Continuous Testing that “We have to stop asking ‘Are we done testing?’ and move to a more quality-focused ‘Does the release candidate have an acceptable level of risk?’ ” This isn’t semantics. “Are we done testing?” is no longer sufficient when the news of a software failure or security breach skyrockets just as quickly as subsequent stock prices, and as satisfied—or paying—customers plummet.

It may be easier to answer “yes” to “Are we done testing?” but it hardly confirms that your code is at a low enough level of risk to be released. You may simply be “done” testing because you ran all the tests you could in the limited time you were given.

Software testers, teachers and longtime STAR conference presenters James Bach and Michael Bolton offered a glimpse into one area that continues to plague not just testers, but entire organizations that are struggling to improve software quality.

Their session, “The Secret Lives of Testers: Where Your Time Really Goes,” showed that due to wait times on IT around environment or platform provisioning—along with the time required to find, report, duplicate and finally eliminate a bug—there’s nothing even remotely continual about testing or quality for many organizations. These quality roadblocks have to be brought to the attention of those who have the power (or sometimes the budget) to get rid of them. Rather than pointing the blame solely on developers or IT ops, Bach put the onus on testers themselves, saying, “Part of being a tester is becoming more aware of the things that are constraining your choices.”

What makes Continuous Testing possible, so that Continuous Quality, Performance and Delivery can follow? We hear all the time that everyone should be focused on increasing business value and helping customers succeed, but if testers can’t test due to the unavailability of time or resources, you can claim to be focused on quality all you want: It’s not coming.

So what’s the solution? Judging by the number of sessions at STARWEST and conferences later this year, many of those currently promoting Continuous Testing used service virtualization to get there.

Capital One and Alaska Airlines each shared their stories of how service virtualization has allowed their testers to not just test earlier and more often; their tests have become more robust as they’re now able to test against events and systems that testers struggle to get access to. Service virtualization and the automation of any manual, error-prone and time-consuming tasks that delay the delivery of working code to production become more of a must-have with each enterprise that adopts them.

The pre-production virtualization of services, events and environments is making what was once hard to come by now available instantly on-demand, and securely sharable on a global scale.

I was surprised by how many STARWEST attendees admitted to being pretty unfamiliar with service virtualization, and I run into people all the time who are still constrained by the bottlenecks caused by shared lab hardware. But like the Ricky Gervais quote at the start of this article says, don’t worry about how late to the game you may be. Start improving. Now.