Best Practice - Workspace Organisation

As your teams work together in Test Modeller, it’s helpful to organize your models in ways that enable the most collaboration and visibility. Below are some best practices we’ve defined:

When to Use Projects and Workspaces

Projects

Projects are the highest level of organization inside a Workspace. Projects contain folders to organize models and their test assets. Within the projects, releases can be used to associate models with specific project iterations. At the project level, you can grant access to specific user groups and move folders between different projects. This level is most useful when you want users to be able to view the same information and collaborate together.

Most Test Modeller users will assign one project to either one application, one area of a larger application, or the type of application (Web, Mobile, API). For example, if we consider a holiday booking company, they might split the projects up in the following way:

• Hotel Booking Web Application
• Hotel Bookings Mobile Application
• Flight Bookings Web Application
• Flight Bookings Mobile Application
• Bookings API

Then, if the Hotel Bookings Web Application is very big and worked on by multiple teams, it may make sense to break it down further into the components of the application.

Workspaces

Workspaces are isolated instances of Test Modeller that create a work area for your organization. They are a level of organization above projects, and do not share information with other workspaces.

It’s important to note that models and their generated assets cannot be shared between workspaces. Organizing on the project level is the most common practice, unless you want true isolation. This can be useful when you have teams working separately with no shared information between them.

Creating User Groups

Defining User Groups is a way of creating teams inside of Test Modeller. Inside of a User Group you can add members, who will have the same level of access. You can define user access per Project and specify what kind of access they should have, such as Admin, Editor, or Read only. This is a quick way to give teams access to specific projects and their releases.

Keeping Folders Organized

By default, projects will contain 3 folders: Components, Data Sheets, and Scenarios. You can structure your folders in any way, but we provide this example as a way to organize your projects.

• Components: This folder would contain models, their associated automation functions and page collections. These models are components of a larger end to end system.
• Data Sheets: This folder is used for storing test data assets, such as excels and CSVs.
• Scenarios: This folder would contain models of end to end flows, built by subflows. These subflows utilize models contains inside of Components. 

Alternative approaches commonly used include:

• Grouping folders by area of application.
• Having two folders, one with automation assets and one with models.

We recommend keeping your automation assets grouped together with their associated models for easy referencing. For example, inside of the folder below, we have the model and a folder containing the module functions and page collection for the application it is using.