QA Craft for Jira – Getting started

QA Craft is a JIRA plugin, allowing:

• Efficient management of QA process in the organization.
• Real-time reporting of progress and test results, reported errors, and coverage of requirements with tests.
• Collecting test metrics necessary to support the entire IT application testing process.
• Creating test repositories using the built-in wizard or by importing from external sources (Testlink, Excel).
• Cloning of parts or entire repositories between JIRA projects.

QA Craft is dedicated for:

• Project Managers – online reporting of test progress by area, coverage of test requirements and reported errors.
• Test Coordinators – Progress reporting, assigning tasks to testers, bugs management.
• Test Analysts –  identifying and defining tests.
• Testers – executing tests, reporting bugs.
• Developers – resolving reported bugs.

Key terms

Task structure

Task structure in QA Craft plugin.

All types of issues can be connected with each other in any direction.
Test Case can be connected with a requirement (Story), although it’s not mandatory. Requirement <—> Test Case relation one-to-many type (one requirement can be connected with multiple test cases). Reverse relation (one issue connected with many requirements) is allowed, however, it has a negative impact on reports presented in Test Suites (statistics show more requirements than they really are).
Design and implementation steps:

• Draft – Status of the newly created Test Case. The test Case is in the design phase and it shouldn’t be forwarded for implementation. The transition to the next status marks the end of the design phase.
• Ready – Test Case is ready for implementation.
• In Progress – Case in progress. The transition to this status occurs automatically after performing one of the steps defined in the test case.
• Done – completion of the Test Case. The result of the end of the case is determined by the “Test Case Resolution” field, which shows the status of the finished test.

Workflow

Test case execution status

Test Case Resolution statuses:

• Failed – finished with failed result
• CNT (could not test) – not possible to perform
• Passed – made correctly with expected result
• Skipped – intentionally skipped
• Blocked – blocked, e.g. errors blocking its implementation

QA Craft Licence management

To enter the license management tab, click the gear and then click Manage Apps



At the bottom of the newly opened page, find and click QA Craft config

Then select the QA Craft License subtab



This tab contains information on the status, type, number of max users, date of creation, license expiration date and Maintenance expiration date.

To enter or change the license key click Change key button

A text window will appear in the newly opened tab in which you must enter and confirm the license key.

After clicking Save button, the license details will be updated.

Tests design

How to create a Test Plan

The Test Plan can be created from the JIRA main screen.
1) Create new task (Create button)

On the JIRA toolbar, click the “Create” button. The result of the action should be the “Create Issue” window.
2) “Create Issue” window

In the “Create Issue” window, select:
Project – The name of the project in which you are going to create a task.
Issue Type – Select the type of created task (Optional: Test Plan, Test Suite, Test Case, Bug and Requirements (Story). In this case, Test Plan was selected).
After completing the data, click “Create”. As a result of this action, a new “Test Plan” task will be created.
A window with a link to the newly created Test Plan appears in the upper right corner of the opened page.

How to create a Test Suite

Test Suite can be created from an existing Test Plan.
1) “Test Suite” creation button

To create “Test Suite” from the previously created “Test Plan”, click “Create Test Suite”. The result will be an open “Create Issue” window.
2) “Create Issue” window

In the “Create Issue” window, please complete the following mandatory details:
Summary – The name of the newly created “Test Suite”.
After filling in the data, click “Create”. As a result of this action, a new “Test Suite” task is created. A window with a link to the newly created Test Suite appears in the upper right corner of the opened page.
We can repeat the above steps until we have added all Test Suites.
The Test Suite can also be created by clicking on the ‘Create’ button and specifying ‘Summary’ and Issue Type ‘Test Suite’. The Test Suite created in this way will not be connected to any of the structures.

How to create a Test Case

New Test Case can be created from an existing Test Suite.
1) Creating a new Test Case

To create “Test Case” from the previously created “Test Suite”, click “Create Test Case”. The result will be an open “Create Issue” window.

“Create issue” window

In the “Create Issue” window, please complete the following mandatory details:
Summary – The name of the newly created “Test Case”.
Test Case Type – Automation or manual. If set to “none”, a new “Test Case” in default will be manual.
After filling in the data, click “Create”. As a result of this action, a new “Test Case” task is created. A window with a link to the newly created Test Case appears in the upper right corner of the opened page.
We can repeat the above steps until we have added all Test Cases.

The Test Case can also be created by clicking on the ‘Create’ button and specifying ‘Summary’ and Issue Type ‘Test Case’. The Test Case created in this way will not be connected to any of the structures.

 

Creating a steps list in Test Case

To add steps in the test case, use the “Edit steps” button in the “Steps” section. The result of the action is editing the steps.
Editing steps in Test Case:
Enter the first step data:
Action – Detailed actions to be performed
Input – Input data – for example: login, password etc..
Expected result – Result of performed actions.
Status – Not used during test design.
Comment – Field for any comment if needed.
After entering the data, the following actions are available before saving:
Change the order of steps. Move the current step one position up. The button does not work when used in the first step.
Change the order of steps. Move the current step one position down. The button does not work when used in the last step.
„- Remove selected row” – Delete current step
„+ Add new step” – Adding the next step (under the current one)
“Cancel changes” – Close without saving
Actions available regardless of saved steps:
“Compact view” – Collapsed view of the Test Case steps
“Extended view ” – Extended view of the Test Case steps

After adding steps, save them using the “Save steps” button..

Import steps from a .csv file

In the Steps tab, click Import button.

Choose a file with steps.

The structure of the steps should appear in the table..
An example of the structure of steps imported from the file in the figure below:

From the Steps tab it’s also possible to export steps by using the Export button.

Automation tests

Create a new Test Case and set the Automation parameter in Test Case Type.
If the Test Case is in manual mode, change it by editing the Test Case Type and set it to Automation.

To add a file to execute, select the Selected file field.

Select the test in the feature file by clicking the None field. A new window should open with the option with contained feature files.



After clicking the selected feature file, its contents will be shown.

After clicking the Select button, the changes are automatically saved in the “Automation Tests Steps” section and a message about the correct saving of the automatic test appears..

Coverage of requirements with tests

From Test Plan level
The set of requirements for implemented tests can be prepared in several ways. If we have already defined our requirements before the test design stage, it is most convenient to add them from the Test Plan level. The tree view is able to show any requirement from all projects in JIRA. Requirements are grouped by Epic. Without an Epic → Story relation, they are presented as requirements not attached to any Epic. A defined set of requirements can be modified at any time by adding new or removing unnecessary requirements.

From the requirement level
If we have defined requirements and assigned them to testers for testing, the most appropriate way will be to create test cases directly from the requirement. Staying at the requirements level, create as many cases as needed to cover them with tests.When creating a test case, we decide where a specific test structure should be added (by providing existing issues such as “Test Plan” and “Test Suite”, or adding to an existing structure. Method often used in sprints. For each requirement in the sprint we create the appropriate number of test cases, connected to one common “Test Suite” in order to report tests for the whole sprint.

From the Test Case level
If we have both pre-defined requirements and test cases, we can connect them with each other at any time.

Structure navigation & Tree view

Test Cases and Test Suites have a navigation panel (QA Craft navigation), enabling quick transition to the parent issue – Test Suite to Test Plan, Test Case to Test

Attaching issues to the structure

In the Test Plan, the navigation panel indicates the project belongs to.

The tables in the “General Metrics” and “Bugs Metrics” tabs also perform the function of navigation.
Structure navigation panel at the Test Suite level..
After clicking the link next to the Test Plan, we will be transferred to the Test Plan, which is above the given Test Suite.

Button that leads to higher being. In this case to the Test Plan – at the Test Suite level.

Structure navigation panel at the Test Case level.
After clicking on the link next to the Test Plan or Test Suite, we will be transferred to the Test Plan/Test Suite, which is above the given Test Case.

Button that leads to higher being. In this case to the Test Suite – at the Test Case level.

The button that leads to the connected requirement is in the “Details” tab under “Step progress” – at the Test Case level.

Link to the reported Bug – at the Test Case level..

Link to Test Plan, Test Suite or Test Case – at Bug level in QA Craft navigator

Link to the Test Case – at Bug level

Tree View

A feature that allows you to view all Test Plans, Test Suites and Test Cases in the form of a tree, clone and copy Test Suites and Test Cases from one structure to another.
Tree cloning works the same as cloning the structure described above. You can clone selected parts to another QA Craft project.
Clicking the “Tree View” button in any Issue, redirects to the connected Issue in the tree structure.

Clicking the right mouse button into Tree view area will open a window with the listed options:

1. Open in a new tab
2. Move – Move Issue to another structure
3. Copy –  Copy Issue to another structure
4. Paste – Paste Issue into another structure
5. Clone -Clone the entire structure (described in Cloning structure)
6.  Delete – Delete Issue and its associations

Attaching issues to the structure

Use the Attach to Structure function. Click ‘More’ button, than ‘Attach to Structure’, and in the window that appears, enter ‘Issue Key’ or the name (Summary) of the issue. A list of issues will appear to which we can attach our Issue.
After selecting issue, click ‘Add’. The connection is created.
Connections are made from bottom to top of the structure, i.e. from the lowest being to the highest, e.g. Bug can be connected with Test Case. Test Case can be connected with Test Suite. Test Suite can be connected with Test Plan.

The screen shows the location of the “Attach to Structure” button, that allows the attachment of an issue to the structure.
A pop-up is presented below, where we give the name of the task to which the selected issue will be attached.

After successfully connecting the Bug to the Test Case, a link appears on the Test Case level that directs directly to the Bug.

Detaching issues from the structure

Detach from Structure is used to disconnect a given issue from the structure. Disconnection is done by clicking the “More” button, then “Detach from Structure” and in the window that appears choose “Issue Key” from which we want to disconnect our Issue. Click “Disconnect” – The connection will be deleted. Disconnections are made from the bottom up the structure, i.e. from the lowest being to the highest, e.g. Bug can be disconnected from the Test Case. Test Case can be disconnected from Test Suite. The Test Suite can be disconnected from the Test Plan.

The screen shows the location of the “Disconnect from structure” button, which is used to disconnect the issue from the structure.

Bug can be connected with more Test Cases. Choose the Test Case that you want to detach from the bug and click “Disconnect”.

Tests implementation

Implementation of Test Cases

Change the status of test case steps

The test case steps list has an interactive “Status” field. After placing the mouse pointer on it, the list of allowable statuses is expanded, which is presented in the table above.
Select the status of the Test Case steps

After selecting the status, it is assigned to the selected step.
Test Case status selection
You can set the statuses of all steps in a simpler way, the following buttons are available:

• “Reset steps” – which resets all steps to “None” status.
• “All Passed” – changes the status of all steps to “Passed”
• “All Failed” – changes the status of all steps to “Failed.

Test Case automatically changes to “In Progress” status after changing one or more of the steps..

Status selection for automation test
It is executed by the script and closes by sending a request or we can close it manually as in position 4
Closing the Test Case
After completing all possible steps, close the Test Case by clicking the “Done” button.

4.  Adding the result in Test Result and status in Test Case Resolution for the entire test case before its closing.
After clicking “Done” a window appears in which we can enter Test Result and select Test Resolution. In the example below, Test Result = Done and Test Case Resolution = Passed.

After accepting the entered data and thus closing the test case, on the Test Case main page, we see that the “Status” field gains the value “Done” and the “Test Case Resolution” field the result of the case.

How to report a bug

Bug can be reported from the JIRA toolbar through the “Create” button, and from the Test Case level using the “Create Bug” button.
Reporting a bug from the JIRA toolbar – Use the “Create” button

On the JIRA toolbar, click “Create” button. The result of this action is the “Create Issue” window.
Reporting a Bug from the Test Case level


To create a new “Bug” connected with “Test Case”, click “Create Bug” button from the “Test Case” level. The result is an open “Create Issue” window.
“Create Issue” window

In the “Create Issue” window, select:
Project – The name of the project in which we create the issue
Issue Type – Selectable: Test Plan, Test Suite, Test Case, Bug and Requirements. In our case – Bug
After filling in the data, click “Create”. A new Bug is created.
A link to the newly created bug will appear in the upper right corner
The bug created in this way is not connected to any entity from the structure.
You can disable the “Create Bug” button in the configuration file.
After creating a Bug, it’s necessary to connect it to the Test Case.

Aggregation functions in the Metrics table

General Metrics table in the Test Plan

The following aggregation functions were used to present the Metrics table:
issue in linkedTestCaseWithTestSuite()
Returns a list of test cases connected with a “Test Suite” task

Syntax:
issue in linkedTestCaseWithTestSuite(issuekey)
where “issuekey” is the “Test Suite” task key
Examples of use:

1. issue in linkedTestCaseWithTestSuite(QACRAFT – 1111) and “Test Case Resolution”= PassedFunction returns Test Cases connected to the indicated Test Suite with the Passed status. Where QACRAFT – 1111 is a valid ‘Test Suite’ issue key
2. issue in linkedTestCaseWithTestSuite(QACRAFT – 1111) and “Test Case Resolution”= FailedFunction returns Test Cases connected to the indicated Test Suite with the Failed status. Where QACRAFT – 1111 is a valid ‘Test Suite’ issue key
3. issue in linkedTestCaseWithTestSuite(QACRAFT – 1111) and “Test Case Resolution”= Blocked Function returns Test Cases connected to the indicated Test Suite with Blocked status. Where QACRAFT – 1111 is a valid ‘Test Suite’ task key
4. issue in linkedTestCaseWithTestSuite(QACRAFT – 1111) and “Test Case Resolution”= SkippedFunction returns Test Cases connected to the indicated Test Suite with the status Skipped. Where QACRAFT – 1111 is a valid ‘Test Suite’ task key
5. issue in linkedTestCaseWithTestSuite(QACRAFT – 1111) and “Test Case Resolution” is Empty Function returns Test Cases connected to the indicated Test Suite, where the status is not filled with any value. Where QACRAFT – 1111 is a valid ‘Test Suite’ task key
6. issue in linkedTestCaseWithTestSuite(QACRAFT – 1111) Function returns Test Case connected to the indicated Test Suite, where QACRAFT – 1111 is a valid ‘Test Suite’ task key

issue in linkedTestCasesWithTestPlan()
Returns a list of Test Cases connected with a “Test Plan” task
Syntax:
issue in linkedTestCasesWithTestPlan(issuekey)
where “issuekey” is the key of the “Test Plan” type task
Examples of use:

1. issue in linkedTestCasesWithTestPlan(QACRAFT – 2222) and “Test Case Resolution”= Passed Function returns Test Cases connected to the indicated Test Plan with the Passed status. Where QACRAFT – 2222 is a valid ‘Test Plan’ task key
2. issue in linkedTestCasesWithTestPlan(QACRAFT – 2222) and “Test Case Resolution”= Failed Function returns Test Cases connected to the indicated Test Plan with the Failed status. Where QACRAFT – 2222 is a valid ‘Test Plan’ task key
3. issue in linkedTestCasesWithTestPlan(QACRAFT – 2222) and “Test Case Resolution”= Blocked Function returns Test Cases connected to the indicated Test Plan with the Failed status. Where QACRAFT – 2222 is a valid ‘Test Plan’ task key
4. issue in linkedTestCasesWithTestPlan(QACRAFT – 2222) and “Test Case Resolution”= Skipped Function returns Test Cases connected to the indicated Test Plan with the Skipped status. Where QACRAFT – 2222 is a valid ‘Test Plan’ task key
5. issue in linkedTestCasesWithTestPlan(QACRAFT – 2222) and “Test Case Resolution” is Empty Function returns Test Cases connected to the indicated Test Suite, where the status is not filled with any value. Where QACRAFT – 2222 is a valid ‘Test Plan’ task key
6. issue in linkedTestCasesWithTestPlan(QACRAFT – 2222)Function returns Test Case connected to the indicated Test Suite, where QACRAFT – 2222 is a valid ‘Test Suite’ task key

issue in linkedBugsWithTestSuite()
Returns a list of bugs connected with a “Test Suite” task 
Syntax:
issue in linkedBugsWithTestSuite(issuekey)
where “issuekey” is the “Test Suite” task key
Examples of use:

1. issue in linkedBugsWithTestSuite(issuekey) and status not in (Closed, Done) Function returns Bugs connected to Test Suite with status other than Closed or Done. Where QACRAFT – 3333 is a valid ‘Test Suite’ task key
2. issue in linkedBugsWithTestSuite(QACRAFT – 3333)Function returns Bugs connected to Test Suite. Where QACRAFT – 3333 is a valid ‘Test Suite’ task key

issue in linkedBugsWithTestPlan()
Returns a list of Bugs connected with a “Test Plan” task

Syntax:
issue in linkedBugsWithTestPlan(issuekey)
where “issuekey” is the key of the “Test Plan” type task

Examples of use:

1. issue in linkedBugsWithTestPlan(QACRAFT – 3333) and status != DoneFunction returns Bugs connected ta Test Plan with a status other than Done. Where QACRAFT – 3333 is a valid ‘Test Plan’ task key
2. issue in linkedBugsWithTestPlan(QACRAFT – 3333)Function returns Bugs connected to a Test Plan. Where QACRAFT – 3333 is a valid ‘Test Plan’ task key

Running automation tests from the Test Plan level

Each Test Plan has a “QA Craft Test Runs” section with 3 tabs::

1. “Test Run”
2. “Test Run Templates”
3. “Test Automation Parameters”

The “Test Run” tab has a “Create Run” button for creating new objects that control the execution of selected Test Cases. After pressing it, you can configure the launch of a new test execution and the window of selection of Test Cases will appear:

In the “Summary” field there is an option (optional) to add any label describing the new “Run”. The “Linked Issue” field is used to select the object (optional) to which the “Test Result” object should be connected after testing.
The “Test Run Status” field is used to select the type of action to accompany the creation of a new run:

We can choose to create a “Test Run” object without running any tests or to run them immediately. In addition, if necessary, we have the option of setting the test launch date:

The “Select test run template” field allows the user to select previously defined and saved “Test Run” settings. Select the test cases to be performed from the list.
The “Test Run” tab presents the status of individual launches selected to perform test cases. It presents the dates of creation and launch of “Test run” and its current status.

Three buttons related to operations on the test run:

Details will display detailed information about the selected “Test Run”.

There is information about implementation of selected test cases and a link to files with logs and other data.

“Edit” button allows you to edit the selected “Test Run”:

The selected view allows editing parameters in the same way as in the case of “Create Run”.

“Abort” button will abort the test.
The “Test Run Templates” tab contains the “Create Run Template” button for creating predefined settings for the new “Test Run Templates”:

After clicking the “Create Run Template” button, the following view will appear:

The option to select the label in the “Summary” field and select the status, i.e. whether the “Template” should be visible in the settings when creating a new “Test Run”. Below you can choose specific test cases to perform.
The “Test Run Templates” tab also presents a list of all “Templates” created so far:

Each of them has 2 buttons: “Details” and “Edit”.
“Details” shows the configuration of the given “Template”:


“Edit” allows to change the “Template” settings:

While editing, it is possible to add the Issue Key of the object with which it is to be connected (Linked issue field) and to add the test start time.
 Test Automation Parameters” tab :

It is used to set the “Endpoint” for the request to run tests on the test environment. In the “Test Trigger Endpiont” field, we can enter any address on which the pre-configured test environment is listening. The “Submit” button saves the current configuration.

Tests monitoring

Test Plan

Test Plan is an issue that groups statistics of subordinate Test Suite connected to it.
The Test Plan has a “QA Craft Reports” section with 4 tabs:

1. General Metrics
2. Test Case Metrics
3. Bug Metrics
4. Test Coverage Metrics

General Metrics tab
Test Plan and overall metrics subsection


Test Plan and overall metrics tab contains informations about requirements, Test Case and bugs connected to the Test Suite. In addition, the TS status is automatically calculated according to the following algorithm:

• If 100% of Test Cases has Passed status – Test Suite status = passed.
• If Test Cases have passed or failed status – no matter what proportions – TC status = failed.
• If Test Cases have passed or blocked status – no matter what proportions – TC status = blocked.
• If Test Cases have passed, failed or blocked status – no matter what proportions – TC status = blocked.
• Skipped status does not affect the calculated TS status

The “Test Plan and overall metrics” tab presents the metrics of all tests in a given “Test Plan”

• TS – Test Suite ID connected with the current Test Plan.
• TS Name – the name of the specific test suite,
• TS Priority – Test Suite priority
• TC Progress – progress of closed Test Cases in a given Test Plan
• TC Passed – number of test cases carried out with a passed result,
• TC Failed – number of test cases carried out with a failed result,
• TC Blocked – number of test cases blocked (e.g. due to errors blocking the execution of tests),
• TC Skipped – number of test cases not performed intentionally,
• TC None – number of not performed Test Cases,
• TC Total – total number of Test Cases,
• Total Open Bugs – The number of unresolved bugs reported as part of a specific Test Suite present two values. The upper one (without brackets) presents a unique number of bugs in relation to Test Cases. The lower value (in brackets) presents the number of bugs related to Test Cases including repetitions.
• Total Bugs – The Total number of bugs reported as part of a specific Test Suite are represented by two values. The upper one (without brackets) presents a unique number of bugs in relation to Test Cases. The lower value (in brackets) presents the number of bugs related to Test Cases including repetitions.
• Total Req – total number of requirements in Test Suite.

After clicking a given number, e.g. in the “Total Bugs” column, we go to the reported bugs, as shown in the next screen.

Filtering in the Test Plan
It is possible to filter the Test Suite in the table “General Metrics tab” in the “Test Plan and overall metrics” subsection by selecting the checkbox next to the specified Test Suite.
After selecting at least one checkbox, a green icon appears at the height of the bookmarks bar, which indicates that the selected Test Suite has been remembered.

In the Test Case Metrics tab and after enabling the previously selected filtering (click on the filter icon), we will see all Test Cases closed in the selected Test Suite.
After deselecting the filter icon (it gets grayed out), we will see all Test Cases closed within the entire Test Plan.
Test Case Metrics tab
Test Plan (Test Case Metrics) – Contains the history of all closed Test Cases with statuses included in the Test Plan
The Test Case Metrics contains 4 subsections:

1. Test Case execution – gruped by day (idle days excluded) – table showing all closed Test Cases in a given Test Plan for a given day
2. Test Case history – Contains the history of all closed Test Cases with statuses included in the Test Plan grouped by the number of iterations
3. Test Case execution – grouped by day charts – chart showing all closed Test Cases in a given Test Plan day by day – line graph and bars
4. Test Case statistic charts – contains 2 pie charts:
   1. All Test Cases included in the Test Plan according to Status workflow
   2. All Test Cases with Done status

Test Case execution – grouped by day subsection

Nagłówki w tabeli w podsekcji Test Case execution – grouped by day (idle days execluded) :

• Date – Date of testing
• Total TC – the number of all Test Case done
• Passed – the number of tests that have passed successfully
• Failed – the number of tests that have passed negatively
• Blocked – the number of blocked tests
• Skipped – the number of skipped tests

Test Case History subsection



Headers in the Test Case History table:

• Execution Date – date of last execution
• Test Case – Jira key  
• Summary  – Test Case name
• Iteration – Number of test performances
• Version –  Software version
• Environment – Test environment
• Status – Test Case closing status
• Requirement – Connected with a given Test Case with Jira key

The previous iterations of the Test Case are presented in gray.
Buttons in subsection:
“Show current iterations” – collapsing Test Case iterations to the current iterations. After collapsing, the “Show all iteration” button appears
“Show all iterations” – developing all Test Case iterations
“Group by Test Case” – test case grouping according to the Test Case Key
“Reset filtering and sorting” – reset filtering and sorting to default settings
Test Case execution – grouped by day charts  subsection
The line and bar chart shows the execution of all Test Cases for 1 day for 30 days closed with the specified status


Test Case statistic charts subsection

Test Case Status pie chart contains all open (Draft, Ready, In Progress) and closed (Done)
Test Case Resolution pie chart contains all closed Test Cases with a specific status
Bugs Metrics tab
Test Plan (Bugs Metrics) – Contains reported bugs for all Test Cases included in the Test Plan.
Bugs Metrics contains 5 subsections:

1. All Bugs grid
2. Bugs History grid
3. Bugs created and resolved chart
4. Bugs created and resolved cumulative chart
5. Bugs statistic charts – contains two pie charts:
   1. All Bugs included in the Test Case by bug status
   2. All closed with a specific status

All Bugs grid subsection


The table presents all bugs reported during tests divided into priorities and statuses.
Subsection Buttons:
“Open bugs” – Shows all open bugs
“Closed bugs” – Shows all closed bugs
„Show summaries” – Shows whole bugs names (Summary).
„Hide summaries”- Shows Issue Key only
Bugs History grid subsection
Test Plan (Bugs History grid) – Contains a report of the history of reported bugs with different statuses.

Table Bugs History grid – Contains the history of all Bugs contained in a given Test Plan connected with Test Cases

• Creation date – Bug creation date
• Bug – Jira key
• Summary – Bug name
• Priority – Bug priority
• Status – Status of a specific Bug
• Resolution – Bug resolution status
• Resolution Date – Bug resolution date

Bugs create and resolved chart subsection
The chart shows all Bugs opened and removed within 30 days

Bugs created and resolved cumulative chart subsection
The chart shows summary of Bugs opened and removed over 30 days


Bugs statistic charts tab

Bugs Status pie chart contains all open (Open, In Progress,  QA) and closed (Done)
Bugs Priority pie chart contains all closed Bugs with the specified priority
Test Coverage Metrics tab
Test coverage grid subsection
Test Plan (Test Coverage grid) Contains all requirements connected to Test Case requirements in a given Test Plan

Test Coverage headings:

• REQ ID – Issue Key Requiments(Story),
• Summary – Requiments(Story) name,
• Status – Requiments(Story) current status,
• TC Progress – Progress of closed Test Cases in a given Requiments (Story),
• Total – Number of Test Cases connected to a given requirement,
• TC Passed – Number of Test Cases with a passed status,
• TC Failed – Number of Test Cases with a failed status,
• TC Blocked – Number of Test Cases with a blocked status,
• TC Skipped – number of skipped Test Cases,
• TC None – Number of not performed test cases.

In the table above, Requirements in red do not have a Test Case connected, but have been assigned to a given Test Plan and are visible on the QA Craft tree.

Test Suite

The Test Suite may (but does not have to) have “over itself” in the Test Plan structure.
The Test Suite presents reports/statistics on the structure of Test Cases, requirements and bugs connected with them.
QA Craft Reports contains 4 tabs:

• General Metrics
• Test Case Metrics
• Bug Metrics
• Test Coverage Metrics

General Metrics
Test Suite content and overall metrics subsection
The issue includes detailed reports on the implementation of the connected Test

Cases and the status of the requirements connected to the Test Case.
Table includes:

• TC – Test Case Key
• Summary – Test Case name
• Priority – Test Case priority
• Status – Test Case status
• Steps Progress – Test Cases steps progress
• Resolution – Result of the test
• Iteration – Number of tests performed
• Assignee – Person assigned to perform the test
• REQ_ID – Requiments(Story) attached to Test Case as its key
• Total Bugs –  All Bugs in a given Test Case
• Open Bugs – All open Bugs in a given Test Case
• Soft v. – Software version
• Env – Environment

Test Case Metrics tab
Contains the entire history of changes made in Test Cases and the history of performed tests..
Test Case execution – grouped by day subsection

Tabs in the Test Case execution – grouped by day (idle days execluded) subsection:

• Date – Date of testing
• Total TC – Number of all done Test Cases
• Passed – Number of Test Cases with a passed status
• Failed – Number of Test Cases with a failed status
• Blocked – Number of blocked Test Cases
• Skipped – Number of skipped Test Cases

Test Case history subsection

Headers in the Test Case History subsection

• Execution Date – date of last execution
• Test Case – Jira key
• Summary  – Test Case name
• Iteration – Number of test performances
• Version –  Software version
• Environment – Test environment
• Status – Test Case closing status
• Requirements – Requirement connected with a given Test Case with its issue key and summary

Test Case execution subsection – grouped by day charts
The line and bar graph shows the execution of all Test Cases with the specified status within 30 days

Test Case charts subsection

Test Case Status pie chart contains all open (Draft, Ready, In Progress) and closed (Done) Test Cases
Test Case Resolution pie chart contains all closed Test Cases
Bugs Metrics tab
All bugs grid subsection

Contains information about individual bugs reported during the project.
„Show summaries” – Shows whole Bugs names
„Hide summaries”- Shows Issue Key only

Bugs history grid subsection

Tabela Bugs History grid  – Contains the history of all Bugs contained in a given Test Suite related to Test Cases:

• Creation date – Bug creation date
• Bug – Jira key
• Summary – Bug name
• Priority – Bug priority
• Status – Bug status
• Resolution – Bug resolution status
• Resoluton Date – Bug resolution date

Bugs created and resolved chart
Chart shows all Bugs opened and removed within 30 days

Bugs created and resolved cumulative chart
Graph shows summary of opened and removed Bugs within 30 days

Bugs static charts


Bug status pie chart contains all opened (Open, In Progress, QA) and closed (Done)
Bug Priority pie chart contains all closed Bugs with a specific priority
Test Coverage tab
Contains information about how test cases are covered by tests how many tests are still to be done.

Import & Clonning

Structures import (TestLink, Excel)

QA Craft allows you to import structures from TestLink and Excel.
To import a structure from ‘TestLink, enter the project into which you want to import the structure. A list with options for importing structures from ‘TestLink’ and ‘Excel’ will appear. Choose ‘Import TestLink → QACraft’. After choosing the type of import we are transferred to the page where we choose the file to be imported. After selecting the file, the system loads the ‘Test Suites’ and ‘Test Cases’. The user can mark in the checkboxes what part of the structure he wants to import. In the ‘Type name of Test Report’ window, enter the name (Summary) of the Test Plan to which the structure will be imported. After selecting the Test Suites and Test Cases, just click ‘Import’. The system will start importing selected parts or the whole structure into the Test Plan. After importing, user will be transferred to the highest entity or Test Plan, in which he can see in the ‘Metrics’ table whether all Test Suites and Test Cases have been imported.

Import selected part of the structure (Test Suite)
Imported structure from TestLink

Clear view of test statuses
Further tasks can be planned based on the structure

Import selected Issues from Excel

To import a structure from ‘Excel’, enter the project into which the structure is to be imported. Then click ‘Add-ons’, after which a list with options for importing structures from ‘TestLink’ or ‘Excel’ will be expanded.. Choose ‘Import Excel → QACraft’. After choosing the import type, a page appears where we select the file to be imported. After selecting the file, the system loads the Test Suites and Test Cases. The user can mark which part of the structure he wants to import. The selected structure will be imported into the Test Plan, which will have the name (Summary) the same as the name of the imported file.. After marking the selected Test Suites and Test Cases, click ‘Save’. The system will start importing selected parts or the whole structure into the Test Plan. After importing, the user will be able to go to the imported structure.  The user will be transferred to the highest entity – Test Plan, in which he can see in the ‘Metrics’ table whether all Test Suites and Test Cases have been imported correctly.

For large data structures, if the import operation does not complete within one minute, a message appears saying that the import operation is in progress (NOTE: depending on the configuration of JIRA, the message window may close automatically after a few seconds). A link will appear in the corner (shown in the image below), after which you will be redirected to the Test Plan of the imported structure. The further import of structure elements takes place in the background, invisible to the user. In extreme cases (several thousand test cases), the import operation may take about an hour.

Structures cloning

Structures cloning is available in the QA Craft tool. Click the More button and select Clone Structure. The function is available from the Test Plan and Test Suite levels. Test Plan cloning includes all connected Test Suites and Test Cases. However, from the TS level, all connected TCs. Cloned structures do not have any connected requirements (even if they were attached in the cloned Issue), test iterations and the status of individual Test Cases and steps are zeroed.
After clicking on Clone Structure, select the project in which the cloned structure should appear.

Cloning the entire structure

After selecting the link, a screen appears with the option to select Issue to clone. After selecting one Test Case, the Test Suite is automatically selected – it is not possible to clone a child Issue without a parent.

Screen for selecting items to clone.

Partial cloning of structures

In case you need to clone only part of the repository from the structure, the situation looks the same as in the case of the whole structure cloning described above. Click ‘Clone structure’ and select the part of the repository we need to clone.