“Continuous Load Testing” involves exposing performance-related risks early and continuously so that rapid software releases don’t compromise the end user experience. Tricentis accelerates the path to Continuous Load Testing with Tricentis Flood. Flood’s breakthrough technology frees load testing from resource-intensive performance labs and “shifts it left” with a simplified and highly-scalable approach. It’s load testing reinvented for today’s lean, fast-paced delivery pipelines.
Whether your team is already using open source load test tools or you have Tricentis Tosca test cases—which will power load testing as well as functional testing— it’s easy to make Continuous Load Testing part of your quality process.
About Tricentis Flood Load Testing
Tricentis Flood is the industry’s most flexible and scalable on-demand load testing solution. We help DevOps teams test how their applications scale with massive load generated from around the world. Scale out your Flood load tests for maximum concurrency and throughput at any given time. We’ll take care of the infrastructure and provide aggregated, real-time reporting. Our distributed grid infrastructure was built with a “shared nothing” architecture that lets us scale horizontally beyond the capabilities of any other load testing service on the market today.
- Massively scale your existing JMeter or Gatling scripts to test specific components with extreme concurrency
- Rapidly create and scale realistic browser-level tests with Flood Element or scriptless Tricentis Tosca tests
- Reuse your existing Tricentis Tosca and/or Selenium functional tests for load testing
Continuous Load Testing
with Tricentis Tosca
Tricentis Tosca + Tricentis Flood integration allows teams to perform load testing with Tricentis Tosca’s scriptless functional test cases (including tests for SAP Fiori). This enables teams to:
- Start load testing with any Tricentis Tosca cross-browser test case
- Create smoke tests on the fly with the Tricentis Tosca recorder
- Integrate load testing into CI for immediate feedback
- Identify performance problems early—when they’re easiest to fix
Why Continuous Load Testing?
Agile delivery cycles rely on continuous quality, including user experience and performance testing across dynamic release cycles (and we are also seeing increased use of open source). Organizations are re-architecting the quality process for accelerated delivery…As part of that process, I am seeing adoption of lightweight, continuous load testing emerging across development teams, from early-stage startups to large enterprises.
Melinda Ballou, IDC
Times have changed. Old performance testing approaches are too late, too heavy, and too slow for today’s lean, fast-paced delivery pipelines, Yet, releasing updates without insight into their performance impact is incredibly dangerous in today’s world—with competitors just a click away.
Sandeep Johri, CEO Tricentis
Driven by mobile, the internet of things, and the need for speed, dev teams want to use their functional test cases not only for user acceptance testing (UAT) and automated regression testing, but also for testing load performance — and they want do more of it. Performance testing is shifting left, meaning that teams test load performance early and locally so they can fix their designs sooner rather than later.
Diego lo Guidice, Forrester Research *
Load Testing…Simplified for DevOps
- Why load testing is becoming critical for all testers
- How the new “browser-level user” (BLU) approach makes load testing feasible for everyone
- How BLU compares to protocol-level approaches (JMeter, Gatling) and when to use each
Case Study: LaneOne Concert Experiences
LaneOne’s CTO shares how they:
- Successfully load tested at both the protocol level and browser level
- Iteratively assessed and optimized their system’s performance characteristics until their goals were met
- Could rest assured that their brand-new application would meet high consumer and partner expectations