ACTE

Our products allow teams to build Automated Continuous Testing Environments (ACTE). ACTEs are environments that perform comprehensive regression testing and automatically generate "QA certifications" as part of a continuous integration process. In enterprise environments ACTEs typically can decrease the time it takes to attain QA certifications from weeks or months to minutes. Automated Continuous Testing Environments also eliminate the lion-share of the QA costs, increase overall quality and facilitate a more predictable process.

Building Automated Continuous Testing Environments can be a time-consuming and difficult effort though, especially for systems that leverage multitier architectures. Testing may further be complicated if different tiers are owned by other groups inside or outside the enterprise. Different tiers often evolve at a different pace and it becomes essential to isolate the system under test from changes that occur elsewhere.

Our products greatly simplify the construction of effective Automated Continuous Testing Environments. They provide "Test Fixtures" for liberating the system under test from its dependencies. Our products replace the client with our Test Runner scripts. Back-ends are replaced with the Server Simulator. Isolating the system under test in this manner creates the type of stability required for implementing an effective Automated Continuous Testing Environment. The resulting environment is self-contained. No outside support is necessary to create an ACTE and keep it running.

ACTEs also enable teams to make stress testing part of continuous integrations. Adding stress testing to the continuous integration process means that potential performance problems can be detected and addressed early in the process.

Server Simulator

The server simulator substitutes for a back-end server during development and testing of a system. (The simulator may also be very beneficial during training or demonstration sessions, because it eliminates the need for the "real" back-end system to be available.) The simulator is able to mimic the behavior of the "real" servers with the help of a pattern matching algorithm. This algorithm selects a response by comparing the request to a set of cached requests and responses.

Beyond this core functionality, the simulator supports many other noteworthy features:

• Universal Matching: The simulator supports all technologies popular today, including XML-based formats such as SOAP as well as more proprietary XML-based formats. JSON is another noteworthy format that is fully supported by the simulator. Last but not least the simulator also handles legacy technologies such as EDI.

• Fast Matching: The simulator uses a highly-optimized matching algorithm that is guided by a heuristic and can match hundreds of thousands of documents effectively, regardless of their size. Beyond being able to match requests, the algorithm is also able to index response document, which are typically much larger.

  This fast machine approach allows the simulator to run on inexpensive hardware, perform exhaustive consistency checks & and accounting while still outperforming mainframes and the other powerful machines that may have to be used for the "real" server.

• "Forgiving" Matching: Requests often contain time-stamps or unique ids, which complicate the matching. The matching mechanism used by the simulator can be configured to be "forgiving". This way the administrator of the simulator may specify which parts of document to ignore when trying to find a match.

• Recording Data: The simulator can act as a proxy for the server and build its cache by recording requests & responses. Data collected this way can then be replayed directly or it be edited to simulate conditions that may be hard to record, such as "system unavailable" responses.

• Manufacturing Data: There are many reasons why test data may be difficult to report. One example are back-ends still under development. Another example may be back-ends that may impair progress because of a bug. In some organizations it may be more cost-effective to manufacture most of the test-data instead of having to acquire them from another team. There may also be limitations the backend system has that prevent it from generating certain test worthy conditions. For all these situations the simulator has a convenient way to manufacture test data. Test data can be edited &, copied, or created from scratch.

• Simulate Errors: Comprehensive tests of error conditions is exceedingly difficult in many environments. It can be close to impossible to capture certain conditions that trigger valid but error response. It is typically also impossible for automated test to shut down a back-end system for testing system-down conditions.

  When using the simulator all of these problems can be overcome easily. The simulator makes it simple to test any kind of error condition.

• Verify Cache: One of the dangers of the isolation provided when using a simulator is that changes & incompatibilities introduced to the back-end systems may not be caught. Our server simulator avoids this pitfall by being able to run in proxy mode and verifying that the cached responses match the ones returned by the actual server. If inconsistencies are found during this process the simulator can create appropriate warning & error messages.

• Matching Sequences of Interactions: Beyond basic matching of requests and responses, the simulator can also match complete call-sequences. This means that a request can return different responses depending on what requests have been processed by the simulator previously. Matching sequences of interaction means that the simulator support tests for functionality that modifies values in a database, such as a funds-transfer in a financial service application.

  Funds-transfers usually imply that before and after the transfer a balance is displayed to the user. The balance is typically returned for a request that is identical before and after the transfer, but the response to this request has to differ in both cases.

  Unlike with tests that utilize "real" backend systems the simulator can isolate individual user while running tests. This means if two people use the same test data at the same time the simulator can ensure that the execution of one test does not influence the results of another test.

• Simulate Latencies: The simulator can support stress testing environments by eliminating the need to stress the downstream system. The simulator allows testers and developers to configure latencies, emulating the time it normally takes for the backend system to return a response.

• Web-2.0 Administration UI: The simulator comes complete with convenient Web 2.0-based UI that makes administering the system easy.

• Extensible: The simulator is built using the OSGi framework and can easily be extended using Java, JavaScript, as well as many other popular scripting languages.

For more information or a quote, please contact sales@jolira.com.

Test Runner

The test runner is a product that allows QA professionals as well as developers to quickly create test-scripts many types of applications. The components allow users of the test runner to emulate user-interactions with browsers as well as interactions with remote server using formats such as SOAP, JSON, or EDI.

The test-runner comes with an plug-in for the Firefox browser that automatically creates script by recording interactions with web-applications.

Scripts written using the test-runner product can be exercised as part of regression testing as well as as part of stress-tests. Using the same scripts for stress-testing and for regression testing ensures that applications are also behaving appropriately when under load.

For more information or a quote, please contact sales@jolira.com.