What is QALIPSIS?

The QALIPSIS Graphical User Interface (GUI) allows users, depending on their role, to configure and run load, performance and end-to-end tests with capabilities including, but not limited to:

Using the Command Line Interface (CLI) or the Gradle plugin, you can automatically and repeatedly verify the condition and performance of your system.

With QALIPSIS you are never far from setting up your next load, performance, and end-to-end test campaign.

Start with the creation of a pre-configured project from QALIPSIS bootstrap, then develop code in your IDE.

QALIPSIS provides a Gradle plugin to simplify the configuration, packaging and deployment of your scenarios to your on-premise installation or QALIPSIS Cloud.

You do not need to be a Kotlin expert or a master in the technology that you want to test. QALIPSIS DSL is a meta-language that most users can learn within minutes and it provides the means to execute all of the operations in your scenarios.

Further documentation and examples guide you through more advanced use cases.

Downloading a ready-to-use project for your IDE is easy with QALIPSIS and allows integration with popular DevOps tools to test your software and track the impact of recent changes.

Aggregated assertions allow you to verify the overall results of a scenario. You can define thresholds to make a test succeed or fail and immediately get insights about the performance and consistency of your tested system.

QALIPSIS events and meters provide extended details of load-test operations, providing users with various options for accessing the results. The results visualizations and dashboards, with details of each test-case execution, provide valuable insight for identifying the bottlenecks in your applications and uncovering the components and conditions of failures.

The QALIPSIS Gradle plugin integrates the automated execution of QALIPSIS scenarios with your CI/CD pipelines to validate performance and functionality on a regular and frequent basis. This helps you uncover problems immediately after they are introduced in your system, saving time and money during resolution.

Alternatively, you can use QALIPSIS for constant monitoring. A long-running campaign lets you monitor the availability and responsiveness of your system over a long period of time. The statistics of running campaigns are accessible in real-time, allowing you to observe their evolution and detect issues at their earliest occurrence. Time-to-solution is faster with the ability to analyze problems in real time and conditions.

Combining the double benefits of a lightweight architecture and deployment as a cluster, QALIPSIS makes it possible to simulate the load from thousands to millions of users (e.g. website visitors, connected IoT devices, etc.).

You can execute load, performance and end-to-end test campaigns running several scenarios, and analyze how behaviors of certain personas affect the experience of others.

QALIPSIS not only injects outgoing data into your system to test; it also ingests incoming data sources to compare their values with the ones generated by your tests. You can cross-verify requests and responses with infrastructure metrics, messages, and database records.

QALIPSIS load, performance and end-to-end testing can be performed from any operating system supporting Java with the same impressive results.

QALIPSIS empowers developers to:

QALIPSIS provides IT Operations teams solutions to:

Every web or mobile application involves two execution domains. Server-side execution covers everything your infrastructure controls: API routing, business logic, database queries, message brokering, cache lookups, and inter-service communication. Client-side execution covers everything the end-user’s device handles after it receives a response: on the web, that means HTML parsing, DOM construction, CSS layout, JavaScript compilation and rendering; on mobile, it means native UI rendering, view hierarchy layout, animation frame rates, and on-device business logic.

Protocol-level tools - QALIPSIS, but also JMeter, Gatling, k6, and similar tools - operate in the server-side domain. They issue requests directly over the wire (HTTP, TCP, UDP, MQTT, or messaging protocols) and measure what the infrastructure does: how fast it responds, whether the data is correct, whether the system stays consistent under concurrency. They never instantiate a browser engine or a mobile runtime, so they have no DOM, no JavaScript execution, no native view rendering, and no concept of "the screen is visually complete."

This is a deliberate architectural choice, not a gap. The two domains answer fundamentally different questions. Server-side load testing asks: "Can the infrastructure process 50,000 concurrent workflows without degrading throughput, correctness, or availability?" Client-side performance testing asks: "Once the device receives this response, how quickly does the screen become visually complete and interactive for this user, on this hardware, on this network?" The former is a function of your backend architecture; the latter is a function of front-end asset optimization, JavaScript or native-code complexity, rendering paths, and the end-user’s device capabilities. Conflating them produces misleading results in both directions.

There is also a practical reason: browser engines and mobile emulators serialize work through a single rendering thread, making each virtual user orders of magnitude more expensive to simulate. A typical load-injection node can sustain hundreds of protocol-level virtual users but only a handful of real browser or emulator sessions. Protocol-level operation is what allows QALIPSIS to scale minions from thousands to millions on a modestly sized cluster.

If you need to measure Largest Contentful Paint, Time to Interactive, or layout shift on the web, you need browser-level tools (Lighthouse, Playwright, WebPageTest). If you need to profile mobile rendering performance - frame drops, cold-start time, or memory pressure on-device - you need platform-specific tooling (Android Profiler, Xcode Instruments) or real-device cloud services. These are complementary to QALIPSIS, not competitors.

QALIPSIS integrates with monitoring stacks - it can export events and meters to Elasticsearch, InfluxDB, TimescaleDB, and Graphite - but it is not an APM. It does not instrument your application code, trace internal function calls, or build service dependency maps.

The relationship works in both directions, however. QALIPSIS can also consume data from your observability and monitoring infrastructure during a test. Its plugins include poll and search steps for databases and time-series stores, which means a scenario can ingest infrastructure metrics - CPU utilization, memory pressure, queue depths, error rates - published by your APM or monitoring stack and cross-verify them against the load being injected. For example, you can assert that resource consumption stays within expected bounds at a given concurrency level, or that a spike in database response time correlates with a specific load profile. QALIPSIS produces load-test evidence that your observability tools can correlate with application-level telemetry, and it consumes observability data to enrich its own assertions - but it does not replace the instrumentation itself.

If your goal is to saturate a single URL and measure its raw request-per-second ceiling or p99 latency in isolation, dedicated HTTP micro-benchmarking tools are purpose-built for that: wrk, hey, and vegeta can all hammer one endpoint with minimal setup and overhead. QALIPSIS can do that too, but it is not its primary design intent. QALIPSIS is designed for workflow validation across components: chaining HTTP calls with database assertions, message broker verification, and cross-layer data consistency checks within a single scenario. Its value emerges when the question is not "how fast is this endpoint?" but "does the entire chain - from API request to message broker to database to downstream service - stay correct and responsive under realistic, concurrent load?"

Contract testing verifies that two services agree on the shape and semantics of their interface - request format, response structure, status codes, field names - typically by running lightweight, isolated checks against a mock or recorded contract. Tools like Pact, Spring Cloud Contract, or Specmatic are designed for this: they generate and verify contracts between consumer and provider independently, often as part of a CI pipeline, without deploying the full system.

QALIPSIS operates in a different part of the testing spectrum. It does not generate or verify interface contracts between services. Instead, it deploys load against your actual running infrastructure and validates that the system behaves correctly end-to-end under concurrency: that data flows through the right services, lands correctly in databases and message brokers, and that timing and consistency hold at scale. Contract testing answers "do these two services still agree on the API shape?" - QALIPSIS answers "when 10,000 users exercise the real workflow simultaneously, does the whole system still produce the right outcomes?" The two are complementary: contract testing catches interface drift early and cheaply in the development cycle; QALIPSIS catches the runtime, concurrency, and data-integrity problems that only surface under load on a deployed system.

QALIPSIS generates load to measure performance, correctness, and system behavior under concurrency. It does not probe for security vulnerabilities, test for injection flaws, scan for misconfigurations, or simulate adversarial attack patterns. High request volume is not the same as a security assessment: QALIPSIS sends the requests you define in your scenario; it does not crawl your application looking for exploitable surfaces.

If you need to identify vulnerabilities such as SQL injection, cross-site scripting, broken authentication, or OWASP Top 10 weaknesses, use dedicated security testing tools: OWASP ZAP (open-source, CI/CD-friendly), Burp Suite (the industry standard for manual and automated web application penetration testing), or Nikto (lightweight web server vulnerability scanner). These tools intercept, analyze, and manipulate traffic to discover security flaws - a fundamentally different objective from what QALIPSIS is designed to do.

QALIPSIS produces evidence - metrics, traces, assertion outcomes, and campaign reports - that inform engineering decisions. It reveals where your system degrades, at what concurrency thresholds, and with what data-consistency consequences. Acting on those findings is an engineering responsibility, not a tool capability. QALIPSIS surfaces the problem; your team owns the fix.