Project Setup and Custom Fields

Project granularity and Taxonomy

A Project in ACCELQ typically represents one application-under-test, whose test assets are managed in one place. The most obvious mapping is that an ACCELQ Project corresponds to one software application that you are testing.

In some cases, an ACCELQ Project may also include test assets from multiple applications belonging to a portfolio, in case these applications are tested as an end-to-end unit. If a user story for the portfolio cuts across multiple applications and thus involves testing these applications as a unit, you may design this suite of applications in one ACCELQ Project.

Project in ACCELQ should not be set up to correspond to a set of Requirements, Sprints, or Releases within a given application-under-test. Nor should a Project be set up per User.

Setup Custom Fields to reflect organizational governance

In ACCELQ, you can set up custom fields for various entities. These custom fields help with test prioritization, governance, and process management.

• Allow filtering of the Universe based on a combination of Custom Fields
• Setup Dynamic Test Suite based on matching Scenario filters with Custom Fields
• Setup Test Case filters when executing test suites
• General filter/update cycle on entities in the bulk mode in the Navigator
• Breakdown the test case pass/fail based on Custom Field definition

You can set up different types of custom fields and assign these fields to one or more entities (Test Suite, Scenario, Test Case, Context, Action, and Data Type).

Here are some examples:

Custom field at Scenario level or test case level?

If you recall, a test case in ACCELQ represents an "instance" of a Scenario that comprises a set of data values to drive the workflow designed in the Scenario. When you are designing custom fields, a question may arise if the field is applicable at the Scenario level or test case level.

If your test design involves a good amount of data-driven possibilities with each scenario yielding multiple test cases, it may be likely the custom field is more appropriate at the test case level.

For example, consider the following custom field:

     Test Type: Regression / Sanity / Smoke.

You may use this custom field to define a suite for Sanity testing. If your filtering granularity should be at the level of a test case, then apply this custom field at the Test Case level.

Define appropriate status field values

The status field can be used as a great resource to track the progress and readiness of entities. As a Project Administrator, think about your organization's governance and tracking needs and appropriately set up these status values. Make sure the team consistently tracks the status up to date for all entities.

Order the status list options in a logical sequence of progress indications. Specifically, the first Status list option is used by default, for all the newly created entities. For example, consider the list below (in that order):

1. New
2. Work In Progress
3. Under Review
4. Completed

Each Status list option has an attribute that indicates if an entity in that particular status can be considered ready for test execution. This readiness indicator attribute is used as one of the parameters when calculating the Test Suite readiness. Following a consistent approach here will provide great guidance on your Sprint or Release progress.

In the above list, if you believe only "Completed" entities can be considered as "Ready", indicate appropriately.

Make use of Application Environments

ACCELQ supports the concept of Application Environments to mirror multiple deployment environments you may have in your product development process. As you promote the build between different environments, this feature allows you to seamlessly execute the same scripts without intervention.

Defining the list of Application Environments is the first step in this process. A Project Admin can review and set up the environments based on the specific project need.

Once defined, Application Environments allow you to abstract the data differences between different environments such as Prod, Test, and Dev. Test execution in ACCELQ should be completely hands-free without requiring any environment-specific updates when you run the tests. You can also conditionalize action logic based on the environment name.

Here is an end-to-end article on working with App Environments