The two main categories of test types are Functional and Performance:

• Functional tests are used to check that the application works as it should.
• Performance tests are used to check that the application can withstand load and demand.

To make sure you create a comprehensive set of tests, first see Test Plan.

For details about creating tests, see Create tests.

For details about the test types ALM provides and supports, see Test types.

ALM provides a container for your tests, called a Test Set. ALM provides test set types for each type of automated test: Functional test sets and Performance test sets.

You can group your tests into test sets in different ways. You can group them in terms of features and aspects in the application. Alternatively, you can create groups of tests that check positive flow, and create groups of tests that check negative flow.

For details, see Create test sets.

ALM provides a way to bundle several test sets together, regardless of their type, to create a Build Verification Suite. The build verification suite is used to check the overall status of your build. A build verification suite may contain both Functional test sets and a single Performance test set.

You can create multiple build verification suites to check the application at varying levels of comprehensiveness. One large build verification suite can be created and scheduled to run every night, and another build verification suite containing only the core test sets can be created and scheduled to run every hour, or manually every time a build is produced.

For details, see Build Verification Suites.

ALM provides a way to define a set of environment parameters that you can bundle with your build configuration suites and test sets, called an AUT Environment Configuration.

Instead of defining and running several different tests that use the same logic but need different environment parameters, you can simply bundle a set of environment parameters into an AUT environment configuration. When you run your build verification configuration suites or functional test sets, you can provide your AUT environment configuration, and ALM uses those parameters to run your tests.

If your application environment is dynamic and changing, you may want to use ALM Desktop Client and Lab Management to link your AUT environment configurations to CDA. Linking the environment parameters in your AUT environment configuration to CDA allows you to dynamically provision and deploy your application environment using a private or public cloud.

For details about CDA servers, see Create and configure CDA servers.

For task information about managing CDA servers in Lab Management, see Create and configure CDA servers.

For details about linking AUT environment configurations and parameters to CDA in ALM, see Lab Resources.

ALM allows you to schedule deployment and testing of your application for the future using Timeslots. ALM ensures that the testing resources required for your timeslot are reserved ahead of time.

Instead of having to manually run a set of tests after producing a build, ALM allows you to automatically allocate resources and initiate provisioning, deployment, and testing of an application in an environment. You can use timeslots to reserve resources for a build verification suite or a test set run, and if you integrate CDA into your build verification suites, you can even arrange for scheduled dynamic provisioning and deployment.

There are a few ways to schedule a run. The simplest is to schedule a test and allocate resources in advance by creating a timeslot in the Testing > Timeslots module. Alternatively, if the testing resources are available, you can arrange for a run to be executed immediately.

For details about timeslot reservation, see Reserve timeslots for running tests.

For details about executing tests and test sets, see Run tests automatically.

For details about executing build verification suites, see Build Verification Suites.