Installation Documentation

Explore the installation processes for Test Modeller, Test Data Automation and VIP:

Test Modeller Installation

Test Data Automation Installation

Installation Overview

Test Modeller is a browser based application that can be installed on premise or accessed through the cloud. Test Data Automation is powered through our VIP Virtual Integration Processor, which is utilized alongside Test Modeller. Please review the required machines and installation details below.

Public Cloud Installation

Test Modeller can be accessed through the cloud in an environment that has internet access with no firewalls. Users can create Workspaces, which are private and isolated instances of Test Modeller. All assets that are created are stored inside the workspace, and can only be accessed by its users.

If Test Data Automation is required, a Windows machine will need to be provisioned. Please refer to the system and software requirements here. A Curiosity representative will schedule a call to walkthrough the installation.

Private Cloud (On-Premise) Installation

If you would like Test Modeller to be installed behind firewalls in a private cloud or on-premise, a Linux machine will be required. The Linux machine will host Docker with the Test Modeller Databases, API, and Web front end images. Please refer to the system and software requirements here.

An on premise installation of Test Data Automation requires a Windows machine on which the VIP Server is installed. Please refer to the system and software requirements here.

A Curiosity representative will schedule a call to walkthrough the installation. If you would like to discuss advanced configuration options, please refer to our documentation and speak with your representative.

The Curiosity Platform

The Curiosity platform consists of the following components:

• Test Modeller Engine – is accessed via our common Web UI
• Test Data Automation Engine – can be accessed via the common Web UI but also has it’s own thick client
• Our Job Server which manages job execution for both engines and allows them to work together for certain capabilities

Test Modeller Engine - A set of pre-configured containers

The Test Modeller Engine has multiple components. Some are proprietary and others are third party products which have configured to work with the engine. 

They all run on Linux. Regardless of the specific mode of deployment (docker compose, Kubernetes, Open Shift), they are delivered in a single packaged release, based on specific versions of each component. 

Every container and service plays an indispensable role in the successful deployment of the Curiosity platform. Let's delve into the functionalities of each component and their contribution to the solution.

• Web UI - This acts as a hosting space for the front-end application, facilitating web access for users.
• Meta API - This API is integral in managing the tracking and access to all metadata and traceability links.
• Graph API - Serving as the backbone API, it manages authentication, security, and the modeller engine.
• TDM API - Specialized for handling all TDM operations.
• Job Engine - It's utilized for executing long-duration operations in the job engine.
• NGINX - This reverse proxy enables the client to connect to all the container services.
• Kafka - This acts as a communication layer between services, and it also handles the creation and status monitoring of executed jobs.
• Postgres - It functions as the data repository for everything within the Curiosity portal.
• Neo4J - This is used for storing graph data pertinent to traceability.

Test Data Automation Engine and Job Server

The Test Data Automation Engine is a single component. Processes can be edited and run directly via the engine’s thick client. More commonly, they are published to the Common Web UI and run via the Job Server.

Architecture Overview

The below diagram illustrates the architecture of the Curiosity platform - Test Modeller and Test Data Automation.

Curiosity provides a fully integrated solution composed of proprietary and third party components

All components are delivered with the exact version and configuration. If needed, we can supply information on running the third party components as separate instances.

The below docker container dependency map illustrates the many dependencies between the docker containers that make up the installation.