App project settings
To access App project settings, go to ⚙️ Settings on AgileTest Sidebar → Settings → Project Settings.
Only Jira admins and Project admins can manage Agile Test project configuration
1. Test Strategies
On the first page, you can find settings for 3 Test strategies, they are:
Script Test: a checklist where you can write your own checklist or an outline and run tests and link defects on the fly.
Exploratory Test: constituted by Test Sessions on which you could run a timer and conduct exploratory or ad-hoc tests with a single click. After finishing, you can save elapsed time, and create and link the defects directly to your Test Session.
Classic Test (Traditional Test Management): includes Test, Test Plan, and Test Execution. This type of strategy allows you to conduct your test in traditional manner by managing these test items in order, Test Plan → Test Execution → Test.
Users can enable or disable these strategies by switching the Active toggles on the top right hand of each board.
2. Issue Type Mapping
The settings section allows users to map available issue types to their respective Agile Test items.
To learn more about creating new issue types, please refer to this document from Jira
As you may know by now, we have 5 item types in Agile Test, Test script, Test session, Test case, Test plan, and Test execution.
After you alter the mapping, the change will be reflected immediately in through out Agile Test.
3. Requirement & Defect
The final section is the Requirements & Defects. This is where users can map available issue types to Agile Test items.
A. Requirements & Defects
It is recommended to categorize Task, Story, or similar issue types under the Requirement group, and Bug under the Defect group. However, if you wish to modify this, simply drag any available issue types from the left column onto the desired groups.
Changing issue type mapping after a period of using the app could cause data lost. We recommend that you should finalize this configuration on the first access to the app in the new project. To learn more about this, please refer to this document Initiate your project with Agile Test.
B. Link settings
Right below issue type mapping, you could find the configuration for links of Requirement - Test case and Test case - Defect. In Agile Test, we provide 2 new link types, Agile Test link type and Agile Test Defect link type
AgileTest link type: this is the link type between Requirement and Test Case.
Requirement Issue Link Type
You may see additional link types in the dropdown list, representing the available link types in your instance. If you need to use a different link type, feel free to change it. Otherwise, it’s recommended to keep the default value, “AgileTest”.
Requirement Issue Link Type Direction
Inward option - is tested by
On Requirement, it is read/understood as “Requirement is tested by Test case”.
On Test Case, it is read as “Test case tests Requirement”.
Outward option - tests
It is read/understood backward. This is only recommended when you want to customize your link, otherwise, you should select the Inward option as the default setting.
Agile Test Defect link type
Link type between Test case and Defect. By default, it is set to AgileTest Defect.
Defect Issue Link Type Direction
Inward option
On Defect, it is read/understood as “Defect is caused by Test Case”.
On Test Case, it is read as “Test Case causes Defect.
Outward option
It is read/understood backward. This is only recommended when you want to customize your link, otherwise, you should select the Inward option as the default setting.
Defect Link Strategy
There are 3 options for you to select.
Link Defects with Test → During testing, any Defects created will be linked to Test case tickets.
Link Defects with Test Execution → During testing, any Defects created will be linked to Test execution tickets.
Link Defects with Covered Issues → During testing, any Defects created will be linked to Requirement tickets.
By default, it is set to Link Defects with Test Execution.
4. Automated Test configuration
A. Trigger configuration
Bitbucket
Firstly, click New Bitbucket Configuration button to reveal the configuration dialog.
User is required to fill in details as follows.
Please refer to this document to learn more about Bitbucket parameters - Run a pipeline with parameters.
Trigger Name: New trigger name.
Workspace: Your Bitbucket workspace.
Repository Slug: aka repo-slug, you can find it in your repository url
https://bitbucket.org/ <workspace-id>/<repo-slug>Body Data: we support Bitbucket parameters.
Example:
{
"target": {
"commit": {
"type": "commit",
"hash": "32fe523af85fe828ab97c70eb816ae1c9956d7b4"
},
"ref_type": "branch",
"type": "pipeline_ref_target",
"ref_name": "nunit"
}
}Repository Access Token: the access token of the current repository. To get one, please refer to this document from Jira Create a Repository Access Token.
Additional Parameters: additionally, we support extra params.
These fields are required only when a user creates a Test Execution without linking a Milestone, Test Plan, Test Environment, Revision, or Fix Version.
If the user has already provided these details, Agile Test will take them into account during the triggering process. The following cases may occur:
Field values already linked to the triggering Test Execution ticket: These values will be ignored.
Field values different from those linked to the triggering Test Execution ticket: The new values will be appended.
GitHub
Firstly, click New GitHub Configuration button to reveal the configuration dialog.
User is required to fill in details as follows:
Please refer to this document from GitHub for more details → Create a workflow dispatch event.
Trigger Name: New trigger name.
GitHub Owner: A string of your GitHub account name.
Repository Name: A string of the current repository.
Branch Name: A string of the branch on which we are going to trigger the workflow.
Inputs: This field allows users to add custom variables to send along with the triggering request. In most cases, it won't be necessary. However, in certain situations, it can be useful for integrating with additional setups in your GitHub workflow.
Access Token: A string of your Personal Access Token. To get one please refer to this document from GitHub Managing your personal Access Tokens.
Additional Parameters: additionally, we support extra params → Please go to Additional params.
GitLab
Firstly, click New Gitlab Configuration button to reveal the configuration dialog.
User is required to fill in details as follows:
Please refer to this document from GitLab for more details Trigger a pipeline with a token.
Trigger Name: New trigger name.
GitLab Project ID: A string of your GitLab project id. To get project id from GitLab main page go to Projects → Open your project → Copy project ID.
Branch Name: A string of the branch on which you want to trigger build.
Variables: This field allows user to add any custom variables to send along with triggering request. In most cases, you would not need it. However, in some special cases, it may provide a way to collaborate with further setups in your GitLab pipeline.
Pipeline Trigger Token: A string of your Pipeline trigger token. To create one please refer to this document from GitLab Create a trigger Token.
Additional Parameters: additionally, we support extra params → Please go to Additional params.
Jenkins
In Agile Test, we support 2 types of Jenkins jobs: Pipeline and MultiBranch.
Trigger Name: New trigger name.
Jenkins Username: A string of your Jenkins username.
Remote Jenkins URL: The URL to your Jenkins server, where you will run builds, e.g.
http://jenkins_url.Job Name: A string of the job which we are going to trigger.
Branch Name (only available for MultiBranch setting): Name of the branch on which we are going to trigger the pipeline.
Parameters: This field allows you to add custom variables when triggering a request. It's generally not required, but in some special cases, it can be useful for additional setups in your Jenkins jobs.
API Token: A string of your Jenkins API token.
To create a new API Token in your Jenkins instance, please follow these steps.
Log in to Jenkins.
Click your name (upper-right corner).
Click Configure (left-side menu).
Click Add API Token.
Additional Parameters: additionally, we support extra params → Please go to Additional params.
B. Execute build remotely
This step applies to any CI/CD configuration. Once the trigger setup is complete, open a Test Execution ticket.
On the right panel of the issue screen, under the Agile Test section, you will see the trigger you just created. Simply click Run to start your pipeline.
If everything is working correctly, clicking the Refresh button will display a confirmation message indicating that the pipeline has been triggered successfully.
Should you need any assistance or further AgileTest inquiries, contact here!