Project granularity and Taxonomy
A Project in accelQ typically represents one application-under-test, whose test assets are managed in one place. 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 multiple applications belonging to a portfolio, in case testing this portfolio most commonly requires navigating through multiple applications. 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 setup to correspond to a set of Requirements, Sprints or Releases within a given application-under-test. Nor should a Project be setup per User.
Setup Custom Fields to reflect organizational governance
In accelQ, you can setup custom fields for various entities. These custom fields help with test prioritization, governance and process management.
- Allow filtering the Universe based on 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 bulk mode in the Navigator
- Breakdown the test case pass/fail based on Custom Field definition
You can setup 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||Values||Applied to|
|Priority||High / Medium / Low||Scenario and/or Test Case|
|Test Type||Regression / Sanity / Smoke||Test Case|
|Module||Flight / Car / Hotel||Scenario|
|App UI||Legacy / V2||Context|
|Criticality||High / Medium / Low||Action|
Custom field at Scenario level or test case level?
If you recall, a test case in accelQ represents an "instance" of a Scenario which comprises of 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 Scenario level or test case level.
If your test design involves good amount of data driven possibilities with each scenario yielding multiple test cases, it may likely the custom field is more appropriate at 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 Test Case level.
Define appropriate status field values
Status field can be used as a great resource to track progress and readiness of entities. As a Project Administrator, think about your organization's governance and tracking needs and appropriately setup 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 indication. 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):
- Work In Progress
- Under Review
Each Status list option has an attribute which 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 setup the environments based on the specific project need.
Once defined, Application Environments allows 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.