The Test and Development phases of the software development life cycle process are seen as key indicators to the success and efficiency of a product being available to the general public on time. Here's a usage scenario of how Go2Group synapseRT can add value to your workflow.
This document applies to version 5.x.
Grab the PDF Here (5MB)
Go2Group synapseRT for JIRA 5 Usage Guide
Go2Group synapseRT plugin allows you to operate JIRA Projects by requirement based testing methodology. The operation schematic is shown below.
Release Versions are defined for Jira Project and include Requirement sets. Requirement realization is tested by Test Cases, assigned to one or several Requirements of one or several Releases. Bugs that appeared in testing are used in Defect Tracking process.
SynapseRT plugin provides automatical creation of synapseRT Test Project. This Project has Releases, Requirements, Test Cases, Bugs, Workflows already created. This manual is description of Requirement Based Testing Scenario with usage of synapseRT tools.
Requirement Based Testing Scenario
Release Version operation.
Open Jira Administration page and follow the Projects link.
Open the Test Project.
You will see the Project page. Follow the More link in Versions section to open the Versions page.
On the page you can manage the Release Versions of current Project.
1. Add new Version with some Release Date.
2. Manage existing Versions using menu. You can delete, archive or release Version.
Additionally you can edit Version fields just by clicking on the corresponded field.
Release screen is presented below. Uresolved issues can be moved to the next Release.
So, the next guide step is Requirement review.
Release Version is characterized by their Requirements.
Please note - The Requirement issue type is a custom issue type, created during the installation process. Since synapseRT v2.3 all Jira issue types can be Requirements or bugs. See details in Configuration manual.
If you have huge amount of requirements and want to organize them into tree view synapseRT gives you this possibility. When you create or edit a requirement you can set a parent requirement for the issue or select None at the parent requirement field.
You can navigate through the tree by pressing - sign to collapse branch and + sign to expand. When you are ready with your selection you can save the issue.
You will see a link to parent requirement at your issue in Issue Links section and information about parent requirement for your child requirement. When you change the parent requirement link will be updated automatically.
Please note - The Parent Link is a custom link, created during the installation process.
On the parent requirement page you can see a list of child issues which are accessible through the links
It means that you will have a set of root requirements with child requirements that are organized into a tree and can be used in Requirement field for Test Cases and Bugs.
Requirement Creation Practice
In order to practice we will create our own Requirement issue in synapseRT Test Project, assign it to some Versions, Parent Requirement and add Estimate time.
Open the Create Issue menu and choose synapseRT Requirement as the issue type.
On the issue creation page specify Requirement Fix Versions, Original Estimate time and Parent Requirement as shown below.
On the created Requirement page you will see all parameters specified.
Please note - The Time Tracking estimates will update as work is performed (Work Log created) and logged against this requirement.
With Go2Group synapseRT it is possible split requirement into a set of sub-requirements. This sub-requirements can be linked with Test Cases and Bugs as separate issues, but they would be grouped into one Requirement with JIRA Sub-Tasks mechanism.
To create Sub-requirement for a requirement select Create Sub-Task item from More Actions popup menu as shown below
Select SubRequirement sub-task issue type from a list.
Please note - The SubRequirement issue type is a custom sub-task issue type, created during the installation process.
Select the Releases and Estimated time as it was done for Requirement and click Create button. On the previously created Requirement page now you can see new SubRequirement in Sub-Tasks section.
Test Cases are used for Requirements testing, so one or more Requirements can be assigned to one Test Case. SynapseRT provides the set of useful Test Case custom fields: assigned Requirements (from Requirement tree described above), Test Suite and Test Case State.
Please note - The Test Case issue type is a custom issue type, created during the installation process.
Test Cases tree
From Go2Group synapseRT v3.1 Test Cases are tree based in the same way as the Requirements. So when you create or edit a test case you can set a parent test case for the issue or select Root tree level at the parent test case field.
To navigate through the tree use "-" sign to collapse branch and "+" sign to expand. When you are ready with your selection you can save the issue.
Created issue will have the link to Parent Test Case in the Issue Links section. This section also includes the links to the child Test Cases of the issue.
Subtest issue type is additional feature provided by synapseRT. It belongs to Sub-Tasks issue types. If it is enabled on synapseRT Dashboard configuration page then when you assign a Test Case to a Test Plan, synapseRT creates Subtest for the Test Case and assign the Subtest in place of the Test Case. See more in Test Plans section .
You can see the nested tree of requirements that assigned to an issue (Test Case, Bug) at the requirement panel. If requirement was not selected for Test Case or Bug then Requirement tab will not be displayed.
Test Suites Management
It can be very useful to organize Test Cases in Test Suites for different Project, Project Categories or globally for Jira. Go2Group synapseRT for JIRA 5 includes Test Suite management functionality to better group individual test cases. Test suites will be displayed within JIRA issue windows, similar to the Test Case scenario described above. From synapseRT v2.3 Test Cases can have multiple Test Suites assigned.
You can find the Test Suites management Guide in the corresponding section of Installation Guide .
It is possible to link a Test Case to the Test Suites during creation Test Case as it is described in the Test Case Creation Practice section. On the Test Case creation page find Test Suite list. Use [Ctrl] + Left Mouse Click to select several Test Suites in the list.
Test Suite Dashboard mode
To review the linked Test Cases open synapseRT Test Case Planning dashboard.
Set Order option to Test Suite (1). After page reloading you will see several columns with Test Cases. These Test Cases are all linked to Test Suites. The Test Cases linked to several Test Suites are in Undefined column (2). The Test Cases linked to one Test Suite are in corresponded columns (3). You can dynamically change Test Suite for a Test Case using drag and drop functionality.
Test Suite Project tab.
To browse Test Suites which relate to a Jira Project, you can open the Test Suite tab of the Project, see image below.
If you want more Test Cases information on the page, you can enable this feature on synapseRT Configuration page as it is described in the Installation Guide. The tab view with information on Test Case Assignee, Reporter and Fix Versions presented below.
Some Actions are available for the Test Suites in Project Jira Container. These Actions include Edit, Delete, Update operations.
- Edit Action allows to rename Test Suite.
- Delete Action allows to delete Test Suite.
- Update Action allows to update Test Cases in the Test Suite. You can change Test Case States and Statuses according to the Active Test Case Workflow.
Choose new Test Cases State, Status and press Update button.
On reloaded page you will see a Progress bar. To refresh progress just reload the page.
When Update operation is complete you will see all Test Cases in the Test Suite have new Test Case States and Statuses.
Test Case State and Test Case Results
To run the test scenarios and track the test results synapseRT contains Test Case State and Test Case Results custom fields.
Test Case State can be set to one of the following states:
If you run the test you may update Test Case State field with information about that test run (i.e. test was failed). Also you can put additional information on run in Test Case Results field.
When you save the Test Case you will see that your Test Case State was changed and information on the run was saved to Test Case Result.
Information to Test Case Result will be added, not replaced by new values
On the requirements panel you can see that all requirements connected to the test case were marked red. It means that these requirements are connected to failed Test Cases.
If you follow to the requirement view and look at Test Case Coverage you will see a list of Test Cases colored according to their Test Case State
Color Scheme for Test Case States
Test Case State
This color scheme is availible at Tracebility dashboard too.
There is another option to automate Test Case State change. You can link Test Case State change to real transition in your workflow. During installation process workflow postfunction and custom screen were created. See the corresponding section of Installation Guide for instructions.
Test Case State can be applied to the set of user-choosable requirements and test plans
Test Case State can be applied to the requirements and test plans which were defined for a test case by user. User can choose needed issues from issues assigned to a test case.
Create three requirements and three test plans as shown below. Link each issue with precreated Test Case.
Open the Test Case page.
1. Choose the Requirement tab on created Test Case page in Activity section.
2. You will see that assigned requirements have blue color. It means that the requirements are connected to In Progress Test Case.
3. Open the Test Plans tab. It also contains blue-coloured issues.
Click Edit button.
You will see links to expand the lists of connected requirements and test plans in the Test Case State custom field.
Please note - synapseRT Dashboard configuration page provides an option to make the Test Plans list always expanded
In the Test Case State select list choose failed. In Requirements list choose first connected requirement.
Open linked Test Plans list and select first connected one from the list.
Update issue by pressing the Update button.
Set Passed and Can't Test Test Case States in the same way for others two requirements and two test plans.
Now you will see that Requirements in Requirement tab have different colors and the Test Case issues has different colors in connected Test Plans. The colors correspond to Test Case States defined for the Requirements and Test Plans. It means that our Test Case Failed in first Requirement, Passed in second one and Can't Test in third Requirement.
Test Case Creation Practice
With Go2Group synapseRT, creating a Test Case directly from a related Requirement is easy. Simply click on the More Actions link found in Issue Operations section within the requirement and select Create Test Case item from popup menu, as shown below.
Specify Fix Versions, Original Estimate time, assigned Requirements, Test Suite and Test Case State custom fields for the Test Case.
Please note - Since the Test Case was created within a specific Requirement, the corresponding Requirement and Fix Versions are already selected.
After clicking the Create button, the Test Case is created. While familiar to a normal JIRA issue, we can now see the test case coverage beginning to take shape, including:
1. Fix Versions for this issue.
2. The Requirement summary within the JIRA issue
3. Assigned Test Suites information.
4. Parent Test Case link and summary.
5. Test Case State field and change history.
6. Test Case Results field.
7. The Requirement tab, providing additional Requirement details, including a link to the actual Requirement
8. Time tracking Estimate.
From synapseRT v3.1 Test Plan feature is available. SynapseRT Test Plan is the issue type that provides test process with user selected Test Cases. It allows to assign Test Cases to Test Plans, every of which represents test process, so Test Plan should be started when testing starts. After test process is completed Test Plan should be closed. Test Case parameters will be stored in Test Plan for test process that have been running, so you can review every test process even when it's Test Cases has been changed in other tests. These parameters are Summary, Version, Component, Status, Test Case State, Test Case Results, Requirements and Bugs and they form Test Case Snapshot for a test process.
Step-by-step guide for Test Plan management is below.
1. Create your first Test Plan as usual issue. Specify summary and assigned Test Cases at least. These Test Cases will be covered by Test Plan during test process. Press Create button.
2. On the Test Plan page open the Test Plan tab. This tab contains assigned Test Cases. You can find current Test Case parameters here. Start Test Plan.
3. We see started Test Plan. It means that we started our testing and Test Cases can be changed during this test process.
Then we should change a Test Case just like it happen in real test process, close our Test Plan (end test process) and see how Test Plan stores Test Case parameters.
4. We will fail our SYNAPSETEST-14 ("Validate field names") Test Case like it changed in the testing. Now it has new Test Case State, Test Case Results and Status.
Please note - You can see information on all Test Plans for a Test Case in the Test Plan tab as shown on image below
5. So when Test Case is changed in our "test process" then we should look at them in the Test Plan. In Progress Test Plan displays the current state of Test Cases.
Now we will Close Test Plan as our test process is complete.
Please note - Test Plan State has been automatically set to Failed since it is the "worst" Test Case State of assigned Test Cases.
6. Then all Test Case Snapshots are saved in the Test Plan. To see what it means let's change one of our Test Cases. We will Restart SYNAPSETEST-14.
7. Open the Test Plans tab of the Test Case. This tab contains information about all current and past Test Plans and corresponding Test Case Snapshots for this Test Case as you can see below. In this example, SYNAPSETEST-14 has different current Status, Test Case State and Test Case Results custom fields than it's Test Case Snapshot in the Test Plan.
Please note - Test Case Snapshot is the set of the Test Case parameters at the moment of Test Plan closing.
8. Open Test Plan. You will see that Test Plan contains only saved information about Test Case parameters. These parameters are saved in the Test Case Snapshot by Test Plan at the end of test process when Test Plan was closed.
Please note: if you upgrade synapseRT from previous version, synapseRT will create Test Plan workflow and you have to assign this workflow to your workflow schemes.To do this foolow the steps of corresponding Installation Guide section. In the case of clean installation Test Plan Workflow will be assigned to the synapseRT workflow scheme automatically.
Using Subtests in place of Test Cases
If the feature to use Subtests instead of Test Cases in Test Plans is enabled on Dashboard configuration page, then Test Cases assigning process start a job that creates Subtests for the given Test Cases and assign them instead of Test Cases. Subtests inherit the custom fields values of the Test Cases. Only Test Case state custom field value always is In progress and Summary field contains summaries of the Test Plan and the Test Case connected by ":" sign e.g. "TP summary : TC summary". After Test Plan created you will see the job progress information in Test Case custom filed and on the Test Plan tab of the issue.
It is possible to cancel operation using the Button on the Test Plan tab. Current job also will be aborted when the Test Plan is updated during progress. If operation aborted, all created Subtests will be deleted silently.
When operation complete Test Case field of the Test Plan displays Subtests and their parents in the same way as it is for usual Test Cases. Test Plan tab displays the keys of parent Test Cases in the Parent column for Subtests childs only not for children Test Cases.
Test Cases display information on their Subtests on the Test Plans tabs:
Requirement and Test Case custom fields usage
To provide better usage for big projects with a lot of requirements and test cases Requirement and Test Case fields have special view in edit mode, as shown in the image below.
With the help of filters you can limit the list of Test Cases (two-level tree based on Test Suites) or left tree viewRequirements (multi-level tree based on Parent Requirements) you want to add to editing Bug or Test Case.
The right listbox shows currently selected issues that would be saved in the issue. To remove issue from selected issues select the removal issues and press arrow button with "left" arrow.
Please note - you shouldn't select all issues in the right listbox to save items for Requirement or Test Case field. All issues from the right box will be saved automatically after you press "Create" or "Update" button at the bottom of the screen.
If we add a Requirement to selected issues all child Requirements and SubRequirements that were displayed in the tree will be added automatically. It is possible to remove some of children with arrow button with "left" arrow
With Go2Group synapseRT, creating a Defect directly from a related Test Case is easy. Simply click on the
More Actions link found in Issue Operations section within the requirement and select
Create Bug item from popup menu, as shown below.
Please note: the "Create Bug" option is disabled on the Test Case page when the feature to use Subtests in place of Test Cases in Test Plans is enabled on synapseRT Dashboard Configuration page.
Fill in a summary for the Defect and update other fields as necessary
Please note - The Defect issue type is a custom issue type, created during the installation process.
Please note - Since the Defect was created within a specific Test Case, the corresponding Test Case and associated Requirements are already selected.
After the Defect has been created, we can now see the Test Cases and Requirements populated within the Defect, as shown on the image below
Go2Group synapseRT plugin allows you to use Bonfire Test Sessions. You just have to create Test Session for a Test Case and start it. If at least one bug was created, then the Test Case and connected Requirement will have Test Case States Failed: Test Case State will be changed automatically during one minute after Bug creation. If Test Session does not contain bugs, then Test Case State will be changed to Passed automatically after Test Session is complete.
See following step to use this functionality.
Firstly let's fail Test Session by bug creation.
1. Open the Create Issue link
2. Specify Requirement Summary, press Create button.
3. Open the Create Issue link
4. Specify Test Case Summary, connected Requirement.
5. Press Create button.
6. You will see that Bonfire Test Session link is in the Test Case State custom field.
7. Open this link. A frame will appear. There will be the link to Create Test Session.
8. Create Test Session.
9. New Test Session will appear in the Testing section.
10. Open the Operations of test session link in the Test Case State custom field.
11. Menu Test Session actions will contain the link to Create new Test Session and the link to Start/Pause existing Test Sessions. Open the Start/Pause link.
12. The list of Test Sessions will appear. Choose previously created Test Session.
13. You will see the page of this Test Session. On the JIRA pages will be a message now. This message is about current Test Session.
14. Open JIRA System Dashboard.
15. Open the Create Issue link
16. Specify Bug Summary.
17. Press Create button.
21. In one minute created Bug will be automatically connected to Requirement that is in Test Session.
22. Open the Test Cases tab in Activity section. You will see that the Test Case Status is Failed.
23. Open the Requirement tab in Activity section. You will see that the Requirement Status is Failed.
24. Open the Operations of test session link in the Test Case State custom field of the Test Case. The menu will contain the link to Complete existing Test Sessions. Open the Complete link.
25. Open the link to complete the Test Session.
26. The Bonfire dialog frame will appear. Specify Time Spent value (optional), link created bug to the Test Case and Complete Test Session.
27. You will see the Test Case was Failed and the Test Session now is complete in the Testing section.
28. Now we will pass Test Session. Open JIRA System Dashboard.
29. Now we have to create yet another Test Case and Requirement. So repeat steps 2?6:
30. On created Test Case page Create and Start Test Session as described above.
31. You will see the Test Session page. Complete Test Session.
32. A dialog frame will appear. Press the Complete Session button.
33. Completed Test Session will appear. Open the Test Case that is connected to Test Session.
34. You will see that Test Case State was automatically changed because Test Session does not have bugs.
Go2Group synapseRT plugin allows you to map your Jira projects to FishEye repositories. Once configured, synapseRT will display information on submitted changelists in the Source tabs of Jira issues and Jira project. FishEye Integration Configuration Guide you can find in the corresponding section of the Installation Docs.
When you submit a changelist, synapseRT maps it to the Issues which keys have been entered in the changelist comment. So if your FishEye repository is mapped to the Jira Project with key "SYNAPSETEST", and you commited a changelist which has comment "SYNAPSETEST-1 SYNAPSETEST-15 SYNAPSETEST-3" then Jira issues with issue keys SYNAPSETEST-1, SYNAPSETEST-3, SYNAPSETEST-15 will have an information on this changelist in their Source tabs.
In the following example we have installed and configured FishEye+Crucible and Jira instances connected together and configured Go2Group synapseRT plugin. We have commited several test changelists and now it is time to look at issues.
Open Traceability Dashboard. Click the Bugs button of the issue item. Bugs block will contain Bug issues information and the changesets comments mapped to the bugs. Changesets comments are the links to the Bug.
Now open an issue page and open Source tab. This tab includes information on all changesets mapped to the issue. All issue keys in the comments are the links to the issues.
Finally you can see all submitted changelists for the Project in Project's Source tab. All issue keys in the comments are the links to the issues.
Issue Navigator Search
It is possible to search in Requirement, Test Case and parent Requirement custom fields during ajax search.
1. Open JIRA System Dashboard.
2. Open the Issues link.
3. New search will open.
3.1 In the Issue Type select list choose Test Case.
3.2 Below the Issue Type select list will appear the link Refresh search. Click it.
4. Open the Custom Fields section.
5. Custom fields section will open.
6. Start typing in Requirement field. The list Test Cases that are connected to the Requirements for search criteria will appear.
7. The next step is to search in requirements.
7.1 In the Issue Type select list choose Requirement.
7.2 Below the Issue Type select list will appear the link Refresh search. Click it.
8. Start typing in Parent Requirement field. The list Requirements for search criteria will appear.
From Go2Group synapseRT v3.0 plugin has AJAX based interface namely custom fields (Requirement, Parent Requirement, Test Case), issue panels and synapseRT dashboards. This feature means less load to JIRA server and user's browser since data is loaded dynamically by portions. It allows to manage big projects which have big amount of issues (over 10k).
- AJAX custom fields.
Tree view fields load data only for current level of tree. When user click "+", the data for opened tree level is loaded dynamically.
Raw view custom fields have "More..." button to load the next portion of data.
- Issue panels collect data by small portions too. They have "More..." button to load data dynamically from server.
Traceability dashboard has tree view based traceability table. So data is loaded dynamically after pressing "+" sign.
Release Planning dashboard load user preferred amount of issues.
The issue limits for dashboards can be configured in SYNAPSE Dashboard configuration section in JIRA Administration.
More information about AJAX Dashboards is available in Dashboard section.
The Go2Group synapseRT dashboard provides an overview of requirement-related information, including traceability and planning. To access the synapseRT dashboard, simply click on the synapseRT link in JIRA's menu bar, as shown below.
By default Go2Group synapseRT dasboard is availible for project administrators. It is possible to add the other groups that will have access to synapseRT dashboard. You can find information about Dashboard configuration in the corresponding section of Installation Guide .
To access Traceability Dashboard, click the Traceability tab, as shown in the image below.
By default, the Traceability tab is loaded when a user clicks on the SYNAPSE menu link.
The Traceability Dashboard provides review traceability matrices. It includes Search filters block, Traceability table and Defects (Bugs) area.
SynapseRT provides many filters for issue search.
It's possible to search issues by Project. The Project select list (1) contains all Jira projects and only the issues of the selected project will be in search results. Project selection make available to choice Releases (2) and Components (3) for the selected Project. It allows to find easy issues for current Project Version and Component.
Additionally, in Release search the Requirement and Test Case Burndown Charts are active.
Test Suites (4) filter displays all Jira Test Suites if no Project was choosen. If Project filter is specified then TS filter contains Project's Test Suites.
Search by user is also available. It is easy to search issues in which the selected user is Assignee (5) and/or Reporter (6). And yet another search filter named Text (7). It allows to search issues with any text in Summary and Description.
All presented search filters except Release and Component can be used together or separately. Release and Component filters require specified Project in the select list (1).
Just choose your search options and press the Query button to save them and load search results
Issue Navigator filters
You can use Issue Navigator search queries on synapseRT Dashboards.
Just save your favorite issue search filters in Issue Navigator.
Then open synapseRT filters and you will see the list of your issue filters.
Select an item and press Query button.
Search results will be loaded on a page and the search panel will be minimized.
Search panel functionality
You can minimize search panel by Minimize link as it is shown on the images below. Additionally, after the Query button pressed search panel will be minimized automatically.
Minimized panel displays information about search parameters.
You also can hide the search panel. Then you will see a draggable icon. Short search info appers on hover this icon. Double click on this icon opens the search panel.
The Requirements and Test Cases which meet search conditions are displayed in the Traceability table. Requirements are listed vertically on the left, with Test Cases listed horizontally across the top (you can transpose this table using Transposition button as shown on image below). Each intersection table cell displays bug statuses and summaries and a border around. The border has color that represents the "worst" state between the states of corresponding Test Case and Requirement. Traceability table is AJAX based, see more in the AJAX section.
The number of the issues to be displayed is configured in the Dashboard section of synapseRT configuration. The rest of issues are available on the mini pages.
There are two modes of the table: Line view and Tree view.
Line table has all requirements displayed with indents on the left. The number of requirements to be displayed is configured in the Dashboard section of synapseRT configuration. The rest of issues are available on a mini pages.
Tree table displays tree view of requirements. The number of issues to be displayed in search result before user expanded/closed tree levels is also configured in synapseRT configuration. The rest of issues are available on a mini pages. You can expand/close tree levels using "+" and "-" buttons.
Each issue item in the table has several buttons and fields. See image below.
- Tree button appears only in the tree mode.
- Defects (Bugs) button shows the bugs which are assigned to the issue.
- Edit issue button opens the issue edit page.
- Issue info displays the popup with short information about many issue parameters such as a Status, Assignee, Components, etc.
- Summary field contains issue summary.
- Issue key field is a link to view issue in new window.
Issue information popup contains short information about many issue parameters such as Assignee, the number of Defects, Time Spent etc.
Issue bugs are shown below Traceability table after pressing Bugs button.
Next, we'll look at the Requirement and Test Case Planning tabs (Planning Dashboards) of the synapseRT dashboard.
The Planning Dashboard allows users to operate issue parameters during interactive actions with drag and drop. It includes Search panel, Issues section (Test Cases in Test Case Planning dashboard and Requirements in Requrement Planning dashboard) and Cork board.
The Search filters of Planning dashboards are basically the same filters in the Traceability dashboard. The difference is Order filter. This field defines Traceability work mode. It can be changed to Priority, Status, Test Case State and Test Suite in the Test Case Planning and Priority and Status in the Requirement planning. You can read about Test Suite mode in the Test Suite Management section of this page.
Issues section contains Issue items organized in columns or rows according to their Status, Priority etc. Column view is default for this Dashboard, you can Change View using corresponding link. The number of issues to be displayed on the page is defined in the Dashboard section of the synapseRT configuration. The rest of issues are available on the Pages.
Drag and drop functionality provides simple change Issue parameters as you can see below where Priority change process illustrated.
Forbidden Status change in the Status mode is the cause of warning message that contain information about status change action details.
Issue item contains Context menu, Issue info and Move to buttons, see more information below. It also includes issue key and summary information.
Context menu displays the link to View and Edit an issue.
Issue info button allows you to see short information about many issue parameters such as Assignee, Time Spent, the number of defects, etc.
Move to button allows you to move an issue without drag and drop. Just choose new value of the issue parameter in the menu and issue will be moved in corresponding column/row. Additionally, Move to menu displays information about number issues with different Test Case states in row/columns on the current page.
If you want to see information about number issues with different Test Case states in row/columns on the other pages you can see it in a popup over pages.
Please note: corks are assigned to project releases in Release filter. So to view/add the Cork for the Release choose this Release and press Query button.
The images below shows the Cork Board in the synapseRT Requirement/Test Case Planning dashboard.
You can create a Cork.
And Edit this Cork without reloading page.
After you save the Cork you can see your changes without reloading page.
Requirements summary dashboard provides export to XML functionality for Requirements keys and summaries. Open this dashboard using a link in the synapseRT menu.
Choose a Project and press Query button in order to load Requirements tree.
Use the XML... link to export Requirements tree to XML.
SynapseRT plugin provides an API to change the State of Test Cases (Subtests) of the given Test Plan. It allows to operate with plugin's servlet by GET requests using usual Jira REST API authentification.
The request structure is
Note: If Subtasks feature is enabled, then the plugin will search for Subtests of the given Test Cases and change State for them.
Response is XML-formatted and is described below.
Client App Example
In this section we will write simple App that will connect to the synapseRT servlet and change Test Case States.
We need username and password for authentification:
Then we generate authentificate token and define access point:
Now write a simple method to perform GET request:
Parsing request for errors and making result:
Finally we have this class:
Runnig App we can see result in console: