Overview of Concepts

Test Modeller supports the concepts of distinct Projects and Versions within Test Modeller workspaces. Test Data Allocation, however, is separate and independent from these Projects. The result is that project teams can use the same Test Data Catalogues and Test Data Allocation pools for different tests, the organization of which is up to the teams themselves.

You may find that many projects are adjacent and share common test data lookups or test in the same test environments, in these cases it makes more sense to share the test data definitions and allocation. Some examples of these are:

1. The HR development team are using automated scripts to test holiday allocation and need to select managers who are not currently on holiday to test the front end system works correctly. They will allocate unique Manager Ids and Employee Ids to each automated test.

Concurrently, the Payroll development team need to test their holiday entitlements detection system to identify if extra holiday has been taken and to be able to manually add holidays to employees. They will create manual tests and need to add holidays to employees.

The Payroll team needs to use the same test criteria as the HR team and will therefore use the same Data Allocation pool so they don’t interfere with the HR automation framework.

1. A migration team is testing the migration process from the existing banking application to a new application. The accounts are split up into different types which require different transformations to ensure they are standardised.

There are over 200 developers and testers working in 20 scrum teams, with each scrum team using a core set of models (lookup new address formats) and individual transforms. Each scrum team has different Test Modeller projects, however there is only one development and testing environment.

Both the manual tests and the automated tests need to use the same allocation pool to ensure teams do not transform the same account using different transforms.