GitHub's issue tracker is a simple and lightweight tool used to track problems with an associated git repository.
-You can use this integration to sync new incidents, new comments, statuses, and releases (milestones) bidirectionally with SpiraTest, SpiraTeam or SpiraPlan (SpiraPlan from here on).
+You can use this integration to sync new incidents, new comments, statuses, pull requests, and releases (milestones) with SpiraTest, SpiraTeam or SpiraPlan (SpiraPlan from here on).
Set up data synchronization
-STOP! Please make sure you have first read the instructions to set up the data sync before proceeding!
+STOP! Please make sure you have first read the instructions to set up the data sync before proceeding!
This section outlines how to set up the integration service between GitHub and SpiraPlan. It assumes that you already have a working installation of SpiraPlan and a GitHub repository with an issue tracker. To setup the service, you must be logged into SpiraPlan as a user with System-Administrator level privileges.
@@ -4494,29 +4630,37 @@You need to fill out the following fields for the GitHub Data Sync plugin to work properly:
issues, pullrequests, and milestones (Typed as shown here). If this is left blank, issues and milestones are synced. Milestones cannot be synced alone - they must be paired with issues and/or pull requests. Click the "Save" button.
-NOTE: Leave any field called "(Not Used)" blank.
-For this step, please ensure that you are in the SpiraPlan project you would like to sync with GitHub. For this example, the project is called "GitHub Data Sync."
+NOTE: Leave any field called "(Not Used)" blank.
+If the display names of users on GitHub do not match the format of their names in SpiraPlan, then the auto-mapping feature will not work, and user mappings will need to be configured manually. If there is not a user mapping for a given GitHub account, the SpiraPlan account used by the data sync will be assigned as the creator of pull requests and the owner field will be left blank where relevant.
+To configure the mapping of users in the two systems, go to Administration > Users > View / Edit Users to see the list of users in the SpiraPlansystem. Click the "Edit" button for a particular user that has an equivalent user in GitHub:
+
Click on the "Data mapping" tab to list all the configured data-synchronization plug-ins for this user. In the text box labeled "GitHub ID", enter the GitHub username of the user. Click "Save" and the user in SpiraPlan will be mapped to that GitHub user. Repeat this for each user who will be active or used in both systems.
+For this step, please ensure that you are in the SpiraPlan product you would like to sync with GitHub. For this example, the product is called "Library Information System".
+
Click on the "View Project Mappings" button for GitHub Data Sync. You need to fill out the following fields to sync correctly:
+Click on the "View product Mappings" button for GitHub Data Sync. You need to fill out the following fields to sync correctly:
External Key -- The name of your GitHub repository. In the example above, where the URL in GitLab was https://github.com/octocat/Hello-World, you would simply enter "Hello-World" for this setting.
Active -- Set this to yes so that the Data Sync plug-in knows to synchronize with this project.
+Active -- Set this to yes so that the Data Sync plug-in knows to synchronize with this product.
Now click the "Status" button within the "Incident" section to map the Incident statuses together. The purpose of this is so that the GitHub Data Sync plug-in knows what the equivalent status is in GitHub for an incident status in SpiraPlan.
Congratulations, you have just integrated your Spira instance with GitHub's integrated issue tracker!
+Congratulations, you have just integrated your SpiraPlaninstance with GitHub's integrated issue tracker!
+Set Up GitHub As A Source Code Provider
+If you do not set up GitHub as a source code provider pull request syncing will not work. Once the source code integration is set up, pull request syncing will work after the cache in SpiraPlan has been.
+To sync pull requests, the GitHub repository that is being synced must be connected to the same product both as an issue tracker (as outlined in this guide) and as a source code provider. Pull requests are synced from GitHub into SpiraPlan only.
+Syncing pull requests has additional requirements in terms of product mappings and product template configuration for this feature to work. If you are not syncing Pull requests, you do not need to do this additional setup.
+To properly sync pull requests, there must be at least one task type with "Pull Request?" set to Yes in the template for the product(s) you are syncing. If there are multiple, the type which is the nearest to the top of the list will be selected by the data sync.
+
In task status mappings, there are 4 possible statuses from GitHub that need to be accounted for. The possible statuses are "open", "started", "closed", and "merged". These are case sensitive.
+These external keys mean the following:
+
You can get the SpiraPlan API Key from within the User Profile screen of SpiraPlan :
diff --git a/External-Bug-Tracking-Integration/img/Setting_up_Data_Synchronization_12.png b/External-Bug-Tracking-Integration/img/Setting_up_Data_Synchronization_12.png index 94559d74c..a771f822b 100755 Binary files a/External-Bug-Tracking-Integration/img/Setting_up_Data_Synchronization_12.png and b/External-Bug-Tracking-Integration/img/Setting_up_Data_Synchronization_12.png differ diff --git a/External-Bug-Tracking-Integration/img/Setting_up_Data_Synchronization_5.png b/External-Bug-Tracking-Integration/img/Setting_up_Data_Synchronization_5.png index 3eb97c1f9..57b03c2f3 100755 Binary files a/External-Bug-Tracking-Integration/img/Setting_up_Data_Synchronization_5.png and b/External-Bug-Tracking-Integration/img/Setting_up_Data_Synchronization_5.png differ diff --git a/External-Bug-Tracking-Integration/img/Setting_up_Data_Synchronization_5b.png b/External-Bug-Tracking-Integration/img/Setting_up_Data_Synchronization_5b.png index 5e0806182..dc9063a54 100755 Binary files a/External-Bug-Tracking-Integration/img/Setting_up_Data_Synchronization_5b.png and b/External-Bug-Tracking-Integration/img/Setting_up_Data_Synchronization_5b.png differ diff --git a/External-Bug-Tracking-Integration/img/Setting_up_Data_Synchronization_6.png b/External-Bug-Tracking-Integration/img/Setting_up_Data_Synchronization_6.png index 6b40b2c1a..256104a06 100755 Binary files a/External-Bug-Tracking-Integration/img/Setting_up_Data_Synchronization_6.png and b/External-Bug-Tracking-Integration/img/Setting_up_Data_Synchronization_6.png differ diff --git a/External-Bug-Tracking-Integration/img/Setting_up_Data_Synchronization_7.png b/External-Bug-Tracking-Integration/img/Setting_up_Data_Synchronization_7.png index dcf8f79ad..f99d3b7d6 100755 Binary files a/External-Bug-Tracking-Integration/img/Setting_up_Data_Synchronization_7.png and b/External-Bug-Tracking-Integration/img/Setting_up_Data_Synchronization_7.png differ diff --git a/External-Bug-Tracking-Integration/img/Setting_up_Data_Synchronization_8.png b/External-Bug-Tracking-Integration/img/Setting_up_Data_Synchronization_8.png index 77bd10c51..1a1c4969f 100755 Binary files a/External-Bug-Tracking-Integration/img/Setting_up_Data_Synchronization_8.png and b/External-Bug-Tracking-Integration/img/Setting_up_Data_Synchronization_8.png differ diff --git a/External-Bug-Tracking-Integration/img/Using_SpiraTeam_with_JIRA_5+_22.png b/External-Bug-Tracking-Integration/img/Using_SpiraTeam_with_JIRA_5+_22.png index 5a5b67bc7..b8441a590 100755 Binary files a/External-Bug-Tracking-Integration/img/Using_SpiraTeam_with_JIRA_5+_22.png and b/External-Bug-Tracking-Integration/img/Using_SpiraTeam_with_JIRA_5+_22.png differ diff --git a/External-Bug-Tracking-Integration/img/Using_SpiraTeam_with_JIRA_5+_50.png b/External-Bug-Tracking-Integration/img/Using_SpiraTeam_with_JIRA_5+_50.png index 7954ffba1..278162952 100755 Binary files a/External-Bug-Tracking-Integration/img/Using_SpiraTeam_with_JIRA_5+_50.png and b/External-Bug-Tracking-Integration/img/Using_SpiraTeam_with_JIRA_5+_50.png differ diff --git a/External-Bug-Tracking-Integration/img/Using_SpiraTeam_with_JIRA_5+_51.png b/External-Bug-Tracking-Integration/img/Using_SpiraTeam_with_JIRA_5+_51.png index 30a344eb7..c87e9e7e6 100755 Binary files a/External-Bug-Tracking-Integration/img/Using_SpiraTeam_with_JIRA_5+_51.png and b/External-Bug-Tracking-Integration/img/Using_SpiraTeam_with_JIRA_5+_51.png differ diff --git a/External-Bug-Tracking-Integration/img/Using_Spira_with_GitHub_216.png b/External-Bug-Tracking-Integration/img/Using_Spira_with_GitHub_216.png new file mode 100755 index 000000000..2e53638d2 Binary files /dev/null and b/External-Bug-Tracking-Integration/img/Using_Spira_with_GitHub_216.png differ diff --git a/External-Bug-Tracking-Integration/img/Using_Spira_with_GitHub_217.png b/External-Bug-Tracking-Integration/img/Using_Spira_with_GitHub_217.png new file mode 100755 index 000000000..06e9a2401 Binary files /dev/null and b/External-Bug-Tracking-Integration/img/Using_Spira_with_GitHub_217.png differ diff --git a/External-Bug-Tracking-Integration/img/Using_Spira_with_GitHub_218.png b/External-Bug-Tracking-Integration/img/Using_Spira_with_GitHub_218.png new file mode 100755 index 000000000..b08249d04 Binary files /dev/null and b/External-Bug-Tracking-Integration/img/Using_Spira_with_GitHub_218.png differ diff --git a/HowTo-Guides/Integrations-Troubleshoot/index.html b/HowTo-Guides/Integrations-Troubleshoot/index.html index b5e5f26c6..fb650fd8d 100755 --- a/HowTo-Guides/Integrations-Troubleshoot/index.html +++ b/HowTo-Guides/Integrations-Troubleshoot/index.html @@ -1174,6 +1174,13 @@ How to setup the Jira syncing integration + + +For cloud-hosted Spira instances you can use Inflectra's cloud data sync to simplify how you sync with third party providers like Jira. To configure a cloud data sync:
+Configure the username to use for the dataSync
+The Redirect URI (or return URL) can be found at the bottom of the Okta administration page in Spira.
+
First create the application in OneLogin
On most modern Windows 11 and Windows Server 2022+ installations, Microsoft .NET Framework v4.7.2 is usually already installed. On earlier operating systems, you may need to manually add the .NET 4.7.2 components to the factory configuration.
To see which version of the Microsoft .NET framework installed please follow the below steps:
b) SQL Server Authentication (advanced mode only)
This is the easiest option when the application and databases will be residing on different servers across the network. In this case, choose "SQL Server Authentication" under "Connection Information" section and provide SQL Server Login that has full sysadmin permissions -- e.g. the built in System Administrator (SA) account. The installer will use this SysAdmin account to create the database objects. The password for SA account is set in SQL Server itself and should be saved carefully.
-Note that using this account under the 'Connection Info' part of the installer is not a security risk, as the installer does not remember this login and after the database is created, it's never used again. With SQL Server authentication, the IIS application pool will run as a low-credentialed system user, typically the 'NETWORK SERVICE' account. This lets the application pool access the local system resources only. User listed under "Database Settings" for SpiraPlan® will use a special login (called "SpiraPlan" by default, created automatically) for normal application operations. The username should not be changed as it is used by the application to operate.
+Note that using this account for the 'Connection Info' fields is not a security risk as the installer does not remember this login and after the database is created. The credentials are used once and discarded.
+With SQL Server authentication, the IIS application pool will run as a low-credentialed system user, typically the 'NETWORK SERVICE' account. This lets the application pool access the local system resources only:
+Inside SQL Server SpiraPlan will use a dedicated login (called "SpiraPlan" by default, created automatically) for normal application operations. The username should not be changed as it is required by the application for it to operate.
Setting the Correct Server Instance
In the "Server" box, you need to enter the name of the Microsoft SQL Server instance that is running on your system; the installer will default it to the hostname of the server (which in many cases will be correct). The easiest way to find out the database server name is to:
To recover your system, restore the backup over top of the existing corrupted database. You can then try the upgrade again.
-If problems persist, contact the Inflectra support team, and they will explain how to retrieve the logs for remediation.
+If problems persist, please contact the Inflectra support team, and they will explain how to retrieve the logs for remediation.
There may be a few cases where you need to customize the installation or upgrade of SpiraPlan®. To enable the installer's advanced mode, make sure to check the "Advanced" checkbox at the relevant screen of the wizard.
Including the options listed above with "(advanced mode only)" next to them, Advanced mode lets you:
@@ -5210,13 +5212,9 @@Without a UserId/password listed in your connection string, Windows Authentication is used (the default). There are two different users to consider here:
-The 'sa' account is a built-in SQL account ('system admin'), and the password is usually set in SQL Server itself. Note that you can use this under the 'Connection Info' part of the installer - it's not a security risk, as the installer does not remember this login and after the database is created.
-Leave 'Database Settings' section unchanged in most circumstances (make sure the Database name is the actual database you'd like to upgrade).
+Without a UserId/password listed in your connection string, Windows Authentication is used (the default). When asked for the username/password under "Connection Info", that user needs to be a SQL Account that is a sys admin, since the database and logins are going to be created. The database user is listed under 'Database settings', and should be left as their defaults as the installer sets and creates those automatically.
+The 'sa' account is a built-in SQL account ('system admin'), and the password is usually set in SQL Server itself. Note that you can use this under the 'Connection Info' part of the installer. Please note that the installer does not remember this login after the database is created.
+Leave 'Database Settings' section unchanged, as filled by default (make sure the Database name is the actual database you'd like to upgrade).
Use this option when you already have another application server and database server configured and operational. Installation is very similar to a standard installation normally. However, when the page about the SQL Server and Database is displayed, it requires you to point to the existing SQL Server and Database.
Once you have setup a login provider, users will see a button for that provider on the Spira login page:
+
Below is a general set of instructions about how to set up the provider and Spira to work together. However, the providers may have changed their process or documentation, so please consult the provider about configuring their system.
Once the new requirement has been inserted, the item is switched to "Edit" mode so that you can rename the default name and choose a priority, status and/or author.
To view information about the follower, or to unfollow them from the item, hover over their avatar to display a user profile card.
For tasks, the component field works differently than it does normal as with other artifacts. The component field for a task is disabled and is derived from the component of any requirement that the task is associated with. If the task has no requirement associated with it, then the task's component field will be empty.
Read about how the comments works
Documentation version
This site was last updated for version 7.7.0.0 of SpiraTest, SpiraTeam, and SpiraPlan
Current available beta features
This documentation is for the entire Spira suite of products: SpiraTest, SpiraTeam, SpiraPlan, and all relevant addons and extensions.
Use the menu on the left to navigate to the different documentation pages. On each page the navigation on the right helps you move around the section of that specific page.
To search, use the text box at the top of the page. Already know the exact phrase you want to search for? Try putting the phrase in \"quotes\" to improve the results.
Please send comments and questions to:
Technical Publications Inflectra Corporation 8121 Georgia Ave, Suite 504 Silver Spring, MD 20910-4957 USA support@inflectra.com
"},{"location":"About/introduction-to-spira/","title":"Introduction to Spira","text":"The Spira\u2122 family of applications from Inflectra\u00ae are a powerful set of tools that help you manage your software lifecycle.
SpiraTest\u00ae is our powerful and easy to use requirements, test and defect management system, ideal for quality assurance teams.
SpiraTeam\u00ae is our integrated Application Lifecycle Management (ALM) system that manages your product's requirements, releases, test cases, issues and tasks in one unified environment.
SpiraPlan\u00ae expands on the features in SpiraTeam\u00ae to provide a complete Enterprise Agile Planning\u00ae solution that lets you manage risks, products, programs and the entire organization with ease.
"},{"location":"About/introduction-to-spira/#quality-assurance","title":"Quality Assurance","text":"Quality Assurance is a key component of the Software Development Life-Cycle (SDLC), which needs to be integrated into the planning and management of a program or product from its inception. Too often though, QA is implemented as Quality Control - whereby testing that the required functionality works as expected, is performed at the end, when it is most costly to make corrections and changes.
To manage QA across a product from day one, it is imperative that the original requirements are documented together with the use-cases that validate the desired functionality. These use-cases then form the basis of the test scripts that can be executed to validate that the functionality has been correctly built, and that the requirements have been satisfied. During the execution of these test scripts, failures may occur, which are recorded as incidents - either to be fixed or documented depending on the severity.
Typically, these activities require people to use at least three different types of software:
However, this stove-piped approach has many limitations and drawbacks, most importantly the fact that there is no traceability between the different artifacts. How can the product manager know that all the requirements have been tested? Conversely, how can the developer know which test script was responsible for a recorded bug -- needed to accurately reproduce the issue?
"},{"location":"About/introduction-to-spira/#product-management","title":"Product Management","text":"As described in the Agile Manifesto, traditional waterfall software methodologies and lifecycles have failed to deliver products on-time and on-budget. In addition, many systems built this way will fail to provide the expected business value as there is no ability to quickly refine the requirements as the product progresses.
Consequently, software development has been transformed with these new ideas and concepts, with new agile methodologies such as Scrum, and Kanban becoming common. However, the traditional tools of product management - requirements specifications, high level product plans, GANTT charts, white-board schedules and top-down task management - are too cumbersome and not well suited.
"},{"location":"About/legal-notices/","title":"Legal Notices","text":"This publication is provided as is without warranty of any kind, either express or implied, including, but not limited to, the implied warranties of merchantability, fitness for a particular purpose, or non-infringement.
This publication could include technical inaccuracies or typographical errors. Changes are periodically added to the information contained herein; these changes will be incorporated in new editions of the publication. Inflectra Corporation may make improvements and/or changes in the product(s) and/or program(s) and/or service(s) described in this publication at any time.
The sections in this guide that discuss internet web security are provided as suggestions and guidelines. Internet security is constantly evolving field, and our suggestions are no substitute for an up-to-date understanding of the vulnerabilities inherent in deploying internet or web applications, and Inflectra cannot be held liable for any losses due to breaches of security, compromise of data or other cyber-attacks that may result from following our recommendations.
The section of the manual that describes modifying the Windows System Registry (\"Registry\") should only be attempted by experienced Windows administrators who are familiar with its organization and contents. Inflectra\u00ae cannot be held liable for any losses due to damage to the system registry made by inexperienced personnel.
Spira\u2122, TaraVault\u00ae, SpiraPlan\u00ae, SpiraTeam\u00ae, SpiraTest\u00ae and Inflectra\u00ae are either trademarks or registered trademarks of Inflectra Corporation in the United States of America and other countries. Microsoft\u00ae, Windows\u00ae, Explorer\u00ae, Microsoft Project\u00ae and Visual SourceSafe\u00ae are registered trademarks of Microsoft Corporation. Subversion\u00ae is a registered trademark of Collabnet, Inc. iOS, iPod, iPad and iPhone are registered trademarks of Apple Corporation, Android\u00ae is a registered trademark of Google Corporation, and Kindle Fire\u00ae is a registered trademark of Amazon LLC. All other trademarks and product names are property of their respective holders.
"},{"location":"About/release-notes-addons-1/","title":"Release Notes for Spira Addons","text":"This page shows summary information about releases in Spira's addons, data syncs, integrations, and optional features.
"},{"location":"About/release-notes-addons-1/#may-2023","title":"May 2023","text":"Jira Cloud DataSync v5.4.2.0: this update includes a number of enhancements and bug fixes:
qTest: this update includes bug fixes and enhancements including:
ServiceNow DataSync v5.0.1.0: this update fixes bugs related to the new API standard introduced by the ServiceNow Tokyo 2022, expanding the compatibility of this dataSync plugin with the most recent SNOW version.
New features
New features
New features
New features
New features
New features
New features
New features
New features
New features
New features
Summary
Security and Performance improvements: enforced password expiration and restrictions, requirements management module now 400% faster
New artifact icons: more contemporary, visually striking, with a modular consistent design
New Features and FixesSummary
New Agile Task and Incident Boards
Program View of Releases & Incidents (SpiraPlan)
Graphing Enhancements and Custom Graphs
New featuresDocument Management
Program Management
Project Management
Reporting
Summary
Data-driven testing with test configurations
Exploratory testing: new testing mode to edit, move, and create test steps during exploratory testing sessions
Improved artifact details page: new designs, improved information flow, faster performance
New featuresSummary
Improved reporting: additional graphs and more dashboard layout choices
Planning board improvements
Testing improvements
New featuresSummary
Powerful new search
Improved program management tools
Seamless cross-product associations
New featuresSummary
Testing improvements: test case folders and test set folders
Electronic signature support
Workflows for releases
The app is 100% response across all sizes of device
New featuresWebhooks (inbound)
Navigation
Reporting
Other
Bug fixes and enhancements
Bug fix
Fix on-premise upgrades to installations that use SQL Authentication not completing successfully [IN:7076]
"},{"location":"About/release-notes-v6/#version-615-february-2022","title":"Version 6.15 (February 2022)","text":"Summary
Improves the welcome emails users receive on getting their brand new SpiraPlan user account. The emails are now more clear and easier to read.
Building on the overhaul we did to our rich text editor in 6.13, the editor is now more powerful and feature-packed than ever. The editor supports find and replace, has more formatting options for tables and images, and is more performant.
UI tweaks under the hood to improve the user experience, particularly for users with more limited product permissions.
New FeaturesRich text editor
tags) [IN:6887]\n
Testing
\nImprovements for those with limited permissions
\nOther
\nPatch Notes
\nSummary
\nView, edit, and add releases inline on the release mindmap, release Gantt chart, or task Gantt chart pages in a new popup View full details about each release without leaving the mindmap or Gantt chart, or edit and save changes right there. (SpiraTeam and SpiraPlan only)
\nView, edit, and add tasks inline on the task Gantt chart pages in a new popup View full details about each task without leaving the Gantt chart, or edit and save changes right there. (SpiraTeam and SpiraPlan only)
\nSupport for two new Single Sign On (SSO) providers: the popular OneLogin service and a generic OpenID provider. This makes it even easiser to integrate your external authentication system with Spira.
\nNew Features\nOAuth connectors are available for specific providers
\nProduct Release List Page Changes (SpiraTeam and SpiraPlan only)
\nProduct Task List Page Changes (SpiraTeam and SpiraPlan only)
\nOn-premise installer
\nFix text not wrapping when editing rich text fields of test steps on a test case details page (introduced in 6.13) [IN:6833]
\nFix the diagram tab for use case requirements with steps no longer rendering the diagram on the requirements details page (introduced in 6.13) [IN:6860]
\nFix details pages for artifacts that use workflows so that the comments settings in the workflow always control the comment box [IN:4917]
\nSummary
\nGive users increased flexibility when managing requirements with requirement types now always being user editable and controllable. Previously parent requirements (those with children) had a fixed type of \"Epic\" that users could never change. Now parent requirements can have any type at any time.
\nImprove the user experience and features of the built-in rich text editor. This lets users more easily add and view links, create checklists, highlight text, and strikethrough text
\nAdd support for more custom property types to let users customize even more how they use SpiraPlan. This release adds support for passwords (encrypted text), release, and automation host custom properties.
\nThe built-in diagram tools get even more powerful with additional shapes and option. You can now make diagrams that group individual shapes together to form kanban board diagrams and swim lane diagrams.
\nWe continue to round out our extensive API to let users automate more and more of their workflows in SpiraPlan. Each of our APIs (REST and SOAP) already had over 375 individual API calls. This release adds API calls to manage all template managed fields for specific artifacts.
\nImproved localization in the web application of fields that users are not able to customize (like requirement or test case statuses).
\nNew Features\nRequirements that have children (parent requirements) retain their type and are not forced to be \"Epics\" [RQ:3703]
\nAPIs
\nCustom Property Types
\nRich Text Editor
\nOther
\nSummary
\nNew installs come with improved sample data. On\u00a0first trying out SpiraPlan, users can select from a number of industry specific example products, programs, and portfolios to see how the tool can work for them.\u00a0
\nBug fixes and performance improvements
\nIndustry specific sample data installed with new installations
\nSummary
\nMulti-Factor Authentication (MFA) support for all users to improve security. Users can add a one-time password to Spira from within the application. Admins can enable/disable, monitor, and manage one-time passwords.
\nCreate and edit a wide array of diagrams live from within the application. This includes mindmaps, org charts, and general diagrams to meet all of your needs. Like all documents in the application, diagrams are versioned, have beautiful previews, can be downloaded, and can be controlled with robust workflows.
\nEdit requirements inline on the requirements mind-map page in a new popup. View full details about each requirement without leaving the mindmap, or edit and save changes right there. [IN:6570]
\nExcel365 addin support risks and test sets, and existing artifacts support even more fields. You can now update existing records using the tools. Advanced users can create new comments and test coverage and traceability links right from the spreadsheet.
\nNew Features\nFix the owner field not being set when owner data is sent on first creating a release (e.g. when cloning a release, or creating a release via the API) [IN:6619]
\nAPI
\nPatch Notes
\nSummary
\nPlanning Board enhancements (SpiraTeam and SpiraPlan): quality of life improvements, including: users can edit cards directly on the board in on-page popups (or view relevant information if you can't edit); improve tooltips, drag and drop; and more sensible defaults when creating items based on your view
\nWork faster and smarter with tasks (SpiraTeam and SpiraPlan): on the task list page you can now perform actions on a whole folders at once, not just specific tasks. This lets you quickly clone, export, or print tasks in folders.
\nNew Features\nPlanning Board
\nAPI
\nOther
\nSummary
\nImproved requirement document view (SpiraTeam and SpiraPlan): Users can now customize which fields to display; edit requirement names, descriptions, and other rich text fields; and display the requirement hierarchy position as an outline code (e.g. 1.2.11). Navigation and pagination have also been improved.
\nBaselining enhancements (SpiraTeam and SpiraPlan): There are now new views and existing views improved to make it easier to see what changed in a baseline.
\nAccess custom report data from external tools (SpiraPlan): First, we've added lots more reporting views to help build out even more queries (available in all editions of Spira). Next, SpiraPlan customers can use 3rd party tools like spreadsheets and database reporting packages to query and report against all custom report tables in the application via the ODATA standard (read our in-depth tutorial). This takes custom reports to a whole new level of integration and ease of use.
\nCustomize custom fields: Custom properties have been turned up to 100 (minus 1). You can now have 99 custom properties for each artifact in a template. Order your custom properties how you like, and add a useful tooltip description for users to read on details pages.
\nNOTE: Internet Explorer is no longer supported by SpiraTest, SpiraTeam, or SpiraPlan. You should use a modern and secure browser instead.
\nNew Features\nRequirements document view
\nCustom Properties
\nHistory and Baselining
\nReport Customization
\nOther
\nAdministration
\nEnhancements
\nBug fixes
\nSecurity fixes
\nSummary
\nBDD and Gherkin Support: Create and write BDD style requirements and test cases 100% in Spira using Gherkin syntax with automatic syntax highlighting. Managed through the documents repository, which includes workflow, checkout, and versioning support.
\nInline content editing: Write plain text, rich text, and markdown inside Spira and have all of the versioning and workflow capabilities at your disposal. Of course, you can link this content to your requirements, test cases, and other Spira artifacts.
\nNew Features\nTesting and test coverage
\nHome pages and reporting
\nAPI
\nOther
\nSummary
\nPull Requests (SpiraTeam and SpiraPlan): The Developing menu in the global navigation now includes Pull Requests, where you can create and manage pull requests. For each pull request you can see all of the relevant commits, their code changes, and discuss any code changes.
\nThe build details page has been overhauled to improve usability and bring the most important information to your fingertips. Key information is more clearly displayed at the top of the page and source code commits and artifact associations are more prominent.
\nSource code diff view (SpiraTeam and SpiraPlan): by default, source code files now collapse unchanged sections, making it easier to quickly review the changes in larger files. You can quickly toggle the page to view the entire file, if you need to.
\nRecording Product setting changes (SpiraTeam and SpiraPlan only): The application now automatically tracks when certain settings on a product change (turning baselining on and off, changing testing settings, or changing some planning options) and who made the change. This is our first step to better tracing admin level changes. Changes are shown on the product history page.
\nNew Features\nSource Code (SpiraTeam and SpiraPlan only)
\nEnhanced history tracking (SpiraTeam and SpiraPlan only)
\nSource Code / Development (SpiraTeam and SpiraPlan only)
\nOther
\nAPI
\nSummary
\nThis release focused on improving the experience and functionality for developers and development teams using SpiraTeam and SpiraPlan. On top of integrating with the top IDEs, your CI/CD processes, and unit test, this release brings massive improvements to our source code features.
\nWe have revamped the source code management module (SpiraTeam and SpiraPlan only), and for the first time, there is now a native code difference viewing capability in Spira. We have also improved views of branches, commits, files and given the source code system a huge performance boost. Note, source code is not included in SpiraTest.
\nView rendered markdown files directly in Spira with rich previews for documents and source code files. John Gruber's markdown format is an incredibly popular and easy way to write human readable plain text that renders as html with images, headings, lists, and more.
\nNew Features\nSource Code (SpiraTeam and SpiraPlan only)
\nOther
\nAPI
\nSummary
\nBaselining Enhancements (SpiraTeam and SpiraPlan only): with baselining enabled, you can now still revert recent changes in a product. Additionally, with baselining enabled, test coverage changes to requirements and releases are tracked and recorded. This release also includes a number of further bug fixes and enhancements.
\nNew features\nShow a warning about future deprecation (after March 31, 2021) on the login page if user is using Internet Explorer 11 [RQ:2987]
\nBaselining (SpiraTeam and SpiraPlan only)
\nSummary
\nPlanning Improvements (SpiraTeam and SpiraPlan only): Planning and kanban boards have some great new features like new display options and improved design. Set a product to estimate releases and requirements only with points (not hours). Use dynamic WIP limits on the planning board to help manage your kanban flow of requirements.
\nBaselines (SpiraTeam and SpiraPlan only): View all baselines created across all releases in a product, and drill down into a baseline to review every artifact that changed during that baselines period of activity.
\nPerformance Improvements: The most frequent power-hungry operations by users have been reworked from the ground up to maximize performance. Operations like updating test coverage is up to 300% faster.
\nNew features\nAdministering baselining within a product (SpiraTeam and SpiraPlan only)
\nProduct Planning (SpiraTeam and SpiraPlan only)
\nAgile and Planning (SpiraTeam and SpiraPlan only)
\nPerformance
\nTesting
\nOther
\nSummary
\nBaselining (SpiraTeam and SpiraPlan only): Enable baselining by product to add baselines to releases or sprints. Use baselines to create snapshots of the entire product at a specific point in time, for instance what it looked like at the start and then at the end of a sprint.
\nLearn: read our blog about this feature here, or read our documentation overview
\nTesting Settings: testing settings are now managed at the product, not system, level. Not only that but there are now lots more ways to tailor how testing behaves.
\nDevOps (SpiraTeam and SpiraPlan only): streamlined and improved traceability between source code commits, CI builds, DevOps pipelines, and SpiraPlan artifacts.
\nNew features\nUsers can create an Incident directly from a Task [RQ:2971]
\nCustom Reports
\nBaselining (SpiraTeam and SpiraPlan only)
\nSecurity Enhancements
\nImprove included sample templates
\nSource Code Management (SpiraTeam and SpiraPlan only)
\nTesting
\nHome pages
\nOther
\nSummary
\nImproved dashboard widgets: enhanced and new Recent Build widgets, let you get an easier handle on your CI/CD processes from program, portfolio, and enterprise home pages; a number of widgets on the program home page by default display data for active releases only to make their data more meaningful; a brand new product test summary table on the program home page provides important information at a glance.
\nNew features\nBaselining
\nEnterprise Dashboard (SpiraPlan only)
\nPorfolio Dashboard (SpiraPlan only)
\nProgram Dashboard
\nSample Data installed with new installations
\nBug fix
\nBug fix
\nSummary
\nPortfolio management (SpiraPlan only): Allow users to collect programs together into portfolios, which can then be collected into a single enterprise view. Key data (like percent complete) will flow from a product, all the way up to the enterprise view.
\nLearn: editing portfolios; letting users see portfolio and enterprise pages.
\nNew dashboard views to assess overall progress: Key data about percent complete for sprints, releases, products, programs, and portfolios will be displayed in a new widget on relevant dashboards. This will be based on the requirements that are part of each active sprint and release.
\nLearn: the portfolio dashboard; the enterprise dashboard.
\nNew release and task views to better manage workloads (SpiraTeam and SpiraPlan only): View all your relevant releases and tasks in new Gantt views. These let you see at a glance what is due when, and get an overview of the schedule of work and sprints.
\nLearn: release Gantt chart; release mind map; task Gantt chart.
\nNew features\nInstaller can upgrade successfully with required database additions [RQ:2850]
\nEnterprise Dashboard (SpiraPlan only)
\nPorfolio Dashboard (SpiraPlan only)
\nProgram Dashboard
\nProduct Dashboard
\nMy Page
\nRelease List Page Changes
\nProgram Release List Page (SpiraPlan only)
\nProduct Task List Page Changes
\nSample Data installed with new installations
\nCalculation Changes/Updates
\nPermissions to control access to portfolios and enterprise views (SpiraPlan only)
\nAdministration changes
\nBug fix
\nSummary
\nSingle Sign On (SSO) Support: Built in integration with a number of OAuth 2.0 providers to provide more seamless and secure sign-on to the application. Initial providers will include Azure AD, GitHub, GitLab, Google, Microsoft ADFS, and Okta.
\nImproved reporting: With a single release picker you can now update every graph (including custom graphs) on the main reporting page. Report formatting for Word has also been improved
\nNew features\nIntegration with OAuth2 Protocol
\nUsers will be able to register an account after signing into their OAuth account
\nAll OAuth providers will have their own library
\nSystem Administrators can managed Oauth providers and users connected using a provider
\nError States are managed
\nBusiness Code
\nOAuth connectors are available for specific providers
\nOther features
\nBug fixes and performance improvements
\nSummary
\nTaraVault unlimited for all SpiraTeam and SpiraPlan cloud users: To celebrate the start of a new decade, our cloud source code management solution, TaraVault, is now included at no extra charge, for all the users and repositories and branches you want.
\nImprovements to filters: Update your filters and shared filters easily. Create filters that also include information about which columns you have visible, their sort, order, and width. This is a great way for saving specific \u201cviews\u201d you and your teams need.
\nImproved navigation between folders and hierarchies: Each folder now has its own unique url, so you can share links to specific folders with your team. For requirements, releases, and all artifacts with folders new clickable breadcrumbs making it easy to go straight to an artifact\u2019s parent.
\nNew features\nSummary
\nSpiraTeam and SpiraPlan cloud users can use any source code provider: In addition to our source code provider, TaraVault, cloud customers can choose to use any Git or Subversion provider they wish.
\nBug fixes and UI improvements: The improvements include better access to the sidebars on all main pages, and improved search in dropdowns.
\nBug fixes and enhancements\nSummary
\nEnhanced product template management: Users can migrate a product from one template to another. This will help you consolidate your templates and streamline your administration more easily.
\nNew features\nBug fixes
\nTemporary fix to manage a bug introduced in the latest Chrome browser version
"},{"location":"About/release-notes-v6/#version-62-august-2019","title":"Version 6.2 (August 2019)","text":"Summary
\nAdditional Requirement List Views (SpiraTeam and SpiraPlan only): In addition to the current hierarchical list view of requirements, additional views will make it easier for users to work with requirements in ways that work for them at the time.
\nImproved Risk Associations (SpiraPlan only): Now you can add links between risks to and from other risks, as well as incidents, test cases, and requirements.
\nNew features\nBug fixes
\nSummary
\nDark Mode: The application follows the color scheme you use in your operating system, or you can set it manually. Dark mode makes every part of the application easier on the eyes and look more gorgeous than ever.
\nImprovements to Administration: With easier filtering and more intuitive controls for key pages like tables and managing workflow permissions, administration is now more user friendly than ever.
\nVersion 6 of our SOAP and REST APIs: Our existing APIs are as compatible as they can be with version 6 of SpiraPlan. The new API version will allow access to new features, such as those from templates.
\nNew features\nBug fixes
\nSummary
\nEnterprise Risk Management [SpiraPlan only]: Risks have their own types, statuses, workflows, and mitigations. New reports for risks, as well as charts and a risk cube have been added.
\nChanges to certain names in the system: Projects are now called Products; Project Groups are now Programs; and Iterations are now Sprints.
\nBetter manage your products (projects) with templates: Templates now control many aspects of a product (such as notifications, workflows, custom fields), and can control many products at once. Each existing product from 5.4 will have its own template. Every new product can have its own template or be managed by an existing template.
\nNew customizations at the template level: Requirement, Test Case, Document, and Task types are customizable. Documents can now be managed using workflows to allow you to control versioning and check-ins. Notifications now apply to products in a template and no longer the same system wide.
\nImprove navigation and new administration user interface: New login screens and a completely reworked navigation menu in the application make using SpiraPlan easier than ever. Navigation is more mobile friendly and intuitive. Administration menus are now only ever one click away.
\nNew features\nRisk Administration (Project Template)
\nRisks
\nProject Templates [RQ:1703]
\nSummary
As a developer I can use SOAP and REST APIs to manage system level custom properties and lists [RQ:4618]
As a program manager, I can plan out the necessary work of the program with **capabilities, linked to product requirements, and release management at the program level, so I can ensure the program objectives will be delivered**
As a program manager, I can monitor the progress of work in the program so I can analyze current performance and ensure the program is compliant with any reporting or audit standards
As a program manager, I can plan out the program delivery timetable with program milestones, so I can ensure we meet our program objectives on time
As a program manager, I want to monitor the progress of program milestones so I can analyze trends and ensure the program is compliant with any reporting or audit standards
As a new user, I can see relevant and meaningful sample data for program scaled agile, so I can easily understand how the tools works [RQ:4506]
Summary
This release includes a number of performance improvements and bug fixes to streamline user experience.
Bug fixes and enhancementsSummary
This release includes a number of performance improvements and bug fixes to streamline user experience.
Bug fixes and enhancementsPerformance improvements
Bug fixes
Summary
APIs
Cross-Cutting Functionality
Beta Planning Board
As a manager, I can use the new beta task board, so I can better oversee and track the work of my teams
Administration (SpiraPlan only)
Add an email option to never include the password in a new user confirmation email (when users are created by a system admin) [IN:7805]
APIs
Bug Fixes
Enhancements
Bug Fixes
Summary
Introducing our next generation planning board for SpiraTeam and SpiraPlan. Available as a beta alongside the existing planning board, the new board has a brand new look, big new features (including swimlanes), and simpler to use than ever.
SpiraPlan admins can create teams and assign members of a product to those teams (in beta). Currently teams are available exclusively on the beta planning board.
New FeaturesBeta Planning Board
There are useful main display modes that dictate how you use the boards
**The planning board makes it easy to customize how the board is organized to help you focus on the right information **
Planning board cards design updated with greater customization
Incident cards can be shown alongside requirement cards for certain views of the Planning Board
System Administration
Fix concurrency dates and concurrency checks to serialize using the Invariant Culture to avoid problems using certain cultural settings (for example, Thai) [IN:7499]
Logging in and out
On premise installer
Documentation and logging
Summary
Manage products in a whole new way (SpiraPlan only). New system level custom properties and custom lists let program users see and manage your products with custom data and through new dedicated pages and custom report options. You can use these new features for improved Project Portfolio Management, to implement product charts, and much more.
Along with existing support for creating and editing dynamic documents inside Spira (including diagrams and documents), the new spreadsheet editor lets you create simple spreadsheets to better organize your teams and track work. You can have multiple sheets, apply formatting to cells, use a wide number of functions, and even import from and export to Excel spreadsheets.
New FeaturesEmail all system administrators every time that the concurrent user limit is exceeded by a user trying to login but can't due to license issues [RQ:4361]
Improved Product Management and Customization
Summary
Cloud customers can now more easily and flexibly set up source code integration inside SpiraTeam and SpiraPlan. TaraVault is the default provider for Git or Subversion. Along with other quality of enhancements you can now, for each product, either user TaraVault or any other cloud based source code provider. This lets you pick the best provider for each product.
Our latest SpiraApp integrates SpiraPlan and OctoPerf seamlessly. Kick off load testing in OctoPerf directly from SpiraPlan and the results of the test get logged against each relevant test case.
New FeaturesSummary
SpiraApps bring a brand new of tailoring SpiraTest, SpiraTeam, and SpiraPlan to your needs. Dedicated SpiraApps will extend what is possible, each addressing a specific use case. This release introduces the first 7 SpiraApps and expect more to follow:
We have updated our data synchronization platform to improve ease of use and simplify setup for administrators, with tailored guidance and information right inside the app.
New FeaturesData synchronization
Testing
SpiraApps
SpiraApps Administration
SpiraApps Architecture
About
This roadmap outlines the functionality planned for future releases of the Spira platform (including SpiraTest, SpiraTeam, and SpiraPlan). Where not specified, a feature will be available in all Spira editions.
It is not set in stone. We are always listening to feedback from our customers and new ideas that will have the most impact to users.
It is not reflect all the work and changes we have planned. The roadmap focuses on large scale features. It does not include small scale features, enhancements, or bug fixes. We do not provide a public list of open bugs or enhancement requests at this time.
If you have any feedback or suggestions regarding this roadmap, please email us at support@inflectra.com.
"},{"location":"About/roadmap/#what-has-been-released","title":"What has been released","text":"Please take a look at our release notes to see a complete list of the changes (large and small) that we have recently delivered.
"},{"location":"About/roadmap/#q3-2023","title":"Q3 2023","text":"We will complete the new planning board rollout, and finish the first round of features for program level \"Scaled Agile\"
We will extend our \"Scaled Agile\" approach further with portfolio level features, like \"Portfolio Outcomes\" and \"Portfolio Milestones\", and deeper risk integration
"},{"location":"About/roadmap/#longer-term-thematic-ideas","title":"Longer term thematic ideas","text":"The list below are features that we are focused on delivering but not in the above timeline. We look for ways to deliver each (all or in part) with smaller enhancements in the short-term, or to integrate them into our timeline based on user feedback.
This section outlines how to use SpiraTest, SpiraPlan or SpiraTeam (hereafter referred to as SpiraTeam) in conjunction with the Atlassian's Bamboo continuous integration build servers. It assumes that you already have a working installation of SpiraTest, SpiraPlan or SpiraTeam v4.0 or later and a working installation of Bamboo v 5.0 or later. If you have an earlier version of SpiraTeam, you will need to upgrade to at least v4.0.
"},{"location":"Build-Server-Integration/Atlassian-Bamboo/#overview","title":"Overview","text":"Bamboo provides continuous integration services for software development, in any programming language using any build tool. It is a server-based system running that supports a variety of different version control systems. It supports SCM tools including CVS, Subversion, and Git, and can execute Apache Ant and Apache Maven based projects as well as arbitrary shell scripts and Tomcat.
When you use the SpiraTeam Add-on for Bamboo, it will allow you to associate each Bamboo project and plan with a corresponding project/release in SpiraTeam. Then, each time Bamboo creates a new build, a new build artifact will be created in SpiraTeam. Each build in SpiraTeam will be automatically linked to the incidents fixed, tasks implemented, requirements developed and source code commits committed.
"},{"location":"Build-Server-Integration/Atlassian-Bamboo/#installing-the-spirateam-add-on-for-bamboo","title":"Installing the SpiraTeam Add-on for Bamboo","text":"Go to the Inflectra website and open up the page that lists the various downloads available for SpiraTeam (http://www.inflectra.com/SpiraTeam/Downloads.aspx). Listed on this page will be the SpiraTeam Add-on for Bamboo. Right-click on this link and save the .zip file to your local computer.
Inside this .zip file will be a .jar file, extract the .jar file and save to a local folder on your system. After that, go to Bamboo Administration. You will need Bamboo administrator privileges to access this configuration page. Under Add-ons, click on the Manage Add-ons link and then on Upload Add-on on the left:
After that, click on Browse and select the .jar file extracted from the .zip archive downloaded from the Inflectra website. Then, click on Update.
After the installation of the SpiraTeam Add-on, you should see a welcome screen:
"},{"location":"Build-Server-Integration/Atlassian-Bamboo/#you-will-then-be-able-to-see-the-spirateam-add-on-in-the-user-installed-add-ons-list","title":"You will then be able to see the SpiraTeam Add-on in the User Installed Add-ons list :","text":""},{"location":"Build-Server-Integration/Atlassian-Bamboo/#_1","title":"Atlassian Bamboo","text":""},{"location":"Build-Server-Integration/Atlassian-Bamboo/#setting-up-the-spirateam-bamboo-add-on","title":"Setting-Up the SpiraTeam Bamboo Add-on","text":"Now that the add-on has been installed, you need to configure the settings for integration with SpiraTeam. To do this, go to the Project you want to communicate with SpiraTeam, and under the plan you want to receive notifications, click on Edit ( icon). In the Plan Configuration screen, go to the Notifications tab and click on Add Notification:
In the Add a new notification pop-up, select the appropriate event you want to receive notifications, and in the Recipient type box, select SpiraTeam:
After that, you will see some new fields to fill, they are:
URL - It is the URL you use to access your instance of SpiraTeam;
User Name: Your SpiraTeam user name;
Password: Your SpiraTeam password;
Project ID -- The numeric ID of the SpiraTeam Project that the Build belongs to. (e.g. for Project PR00001 just enter 1)
Release Version Number -- The version number of the SpiraTeam Release/Iteration that the Build belongs to. (e.g. for Release RL0004 with version number 1.0.0.0 you'd enter just 1.0.0.0)
After filling this boxes with appropriate information, click on Add button. Bamboo will then try to connect to the SpiraTeam Server, and check the Project/Release provided info. Once it validates your information, the connection settings will be saved. In case of error, follow the instructions on-screen and try again.
"},{"location":"Build-Server-Integration/Atlassian-Bamboo/#viewing-the-build-results-in-spirateam","title":"Viewing the Build Results in SpiraTeam","text":"Now that you have associated your Bamboo Project and Plan with a specific SpiraTeam project and release/iteration, you can use Bamboo to manage your software builds and have the results of the build be reported back into SpiraTeam. For example when the 'Plan1' build of TestProject 1 illustrated in the figure bellow is executed, it will report in Bamboo:
The corresponding build entry will also be created in SpiraTeam under the specified project and release/iteration:
If you have configured your Project Home to include the list of recent builds, the build information will also be displayed on the Project Home dashboard:
Clicking on either of the hyperlinks will allow you to navigate to the Build details page inside SpiraTeam:
This page will display the status (success / failure) and details of the build (imported from the Bamboo Console Output) together with a list of the associated incidents, test runs and source code commits. The following section will explain how to use your Source Code Management (SCM) system to take advantage of the SpiraTeam add-on and automatically link incidents and source code commits to the build information.
"},{"location":"Build-Server-Integration/Atlassian-Bamboo/#working-with-source-code-changesets","title":"Working with Source Code Changesets","text":"When your developers commit changes to your application's source into the SCM repository, they should make sure to link the commit to the appropriate artifacts in SpiraTeam. For example they may want to record that the commit fixes a specific incident or implements a specific feature (requirement).
Linking an artifact is very simple. All the developer needs to do is enter the artifact token in the following format:
[PREFIX:ID]
The first half, the Artifact Identifier, is a two-letter code that is used throughout SpiraTeam, and is visible on almost every page in the application. For example, a requirement's identifier is \"RQ\". Incidents are \"IN\", and tasks are \"TK\". The artifact ID is the number of the artifact. So by creating a commit message that reads:
SpiraTeam will automatically detect the tokens and will include links to them under the Associations tab for each commit detail in SpiraTeam.
Inside SpiraTeam, the system will use the same information to automatically link the list of associated commits to the build record:
If the commit message contains Incident tokens, the add-on will also automatically link those incidents to the appropriate build:
Similarly when you view the list of incidents inside SpiraTeam you will now be able to sort and filter the list by the associated build:
Congratulations! You are now able to use SpiraTeam and Bamboo to be able to manage your builds and have the build status integrated into your SpiraTeam project dashboard.
"},{"location":"Build-Server-Integration/Atlassian-Bamboo/#scheduling-test-sets-upon-successful-builds","title":"Scheduling Test Sets Upon Successful Builds","text":"One additional feature of the integration with SpiraTest and SpiraTeam (hereafter just SpiraTest) is the ability to have SpiraTest automatically schedule the execution of a test set whenever a build passes.
To do that, make sure the Test Set is associated with the SpiraTest release or iteration that is being built and then set the Schedule on Build field to \"Yes\" and optionally enter in the delay (after the build succeeds) that you want the test set to be scheduled for:
This means that you don't need to separately manage your build schedule in Bamboo and your test automation schedule in SpiraTest.
"},{"location":"Build-Server-Integration/CircleCI-Pipelines/","title":"CircleCI Pipelines","text":""},{"location":"Build-Server-Integration/CircleCI-Pipelines/#introduction","title":"Introduction","text":"SpiraTest, SpiraTeam, and SpiraPlan (from here on called SpiraPlan) integrated seamlessly with CircleCI in a number of ways. In this section we discuss SpiraPlan's CircleCI Pipelines reporting integration.
You can easily configure your CircleCI Pipelines to report against a release and create a new build in SpiraPlan each time they run. This let's you see the health of your CI/CD process within SpiraPlan.
CircleCI SpiraApp
You can also let end users start CircleCI Pipelines from within SpiraPlan itself. To do so you will need to enable and configure the CircleCI SpiraApp
The integration has two parts, which are discussed below:
Summary
{{base url}}/Services/Webhooks/BuildService.svc/CircleCI?username={{username}}&api-key={{api key}}The integration with CircleCI Pipelines works by having a dedicated custom field for CircleCI. This lets you link a release or sprint to a specific branch in a CircleCI repo. In SpiraPlan we need to specify the branch name. Then from CircleCI we configure our specific repo to talk to the correct SpiraPlan product.
The first step in SpiraPlan is to create a release custom property:
Next, we have to add the CircleCI project name into the SpiraPlan product description, so that the two are linked together.
Finally, in your SpiraPlan product itself (not administration):
In CircleCI we now need to setup our repo to talk to the SpiraPlan each time a Pipeline builds. To do this, you need to add a dedicated webhook. This means that when the CircleCI Pipeline(s) completes, CircleCI will send the results to SpiraPlan via that webhook. SpiraPlan processes that data and adds it as a build to the correct release, in the correct product.
The webhook URL
The webhook URL is made of different parts.
https://mysite.spiraservice.net. This is the start of every URL you use when using SpiraPlan/Services/Webhooks/BuildService.svc/CircleCI?username={{username}}&api-key={{api key}}The final URL will look like this: https://mysite.spiraservice.net/Services/Webhooks/BuildService.svc/CircleCI?username=circleci-pipelines&api-key={11111111-1111-1111-1111-111111111111}
When an Action on the CircleCI project next runs (either from CircleCI, or with the CircleCI SpiraApp) it will report its results to SpiraPlan. SpiraPlan finds the first product that has the project name in its description. SpiraPlan then looks the first release in that product that has the repo branch in the correct custom property that the CircleCI Pipeline was run against.
SpiraPlan creates a build against that release, with the key information, including the build status.
You can click on the build name/link to open its build details page. The build will also appear on any relevant widgets in SpiraPlan.
"},{"location":"Build-Server-Integration/GitHub-Actions/","title":"GitHub Actions","text":""},{"location":"Build-Server-Integration/GitHub-Actions/#introduction","title":"Introduction","text":"SpiraTest, SpiraTeam, and SpiraPlan (from here on called SpiraPlan) integrated seamlessly with GitHub in a number of ways. In this section we discuss SpiraPlan's GitHub Actions reporting integration.
You can easily configure your GitHub Actions to report against a release and create a new build in SpiraPlan each time they run. This let's you see the health of your CI/CD process within SpiraPlan.
GitHub SpiraApp
You can also let end users start GitHub Actions from within SpiraPlan itself. To do so you will need to enable and configure the GitHub SpiraApp
The integration has two parts, which are discussed below:
Summary
{{base url}}/Services/Webhooks/BuildService.svc/GitHub?username={{username}}&api-key={{api key}}The integration with GitHub actions works by having a dedicated custom field for GitHub. This lets you link a release or sprint to a specific branch in a GitHub repo. In SpiraPlan we need to specify the branch name only. Then from GitHub we configure our specific repo to talk to the correct SpiraPlan product.
The first step in SpiraPlan is to create a release custom property:
Next, in your SpiraPlan product:
In GitHub we now need to setup our repo to talk to the correct SpiraPlan product. Your GitHub repo/project will need to use Actions for the integration to work. You can add or edit Actions at any time - this will not impact the integration.
First, we have to add information to link up the GitHub repo and SpiraPlan, by adding the SpiraPlan product reference into the repo. To do this:
[PR:{{product id}}]. For example, \"[PR:1]\". You can have other text in the description, as long as the token is in there somewhere.Second, you need to add a dedicated webhook. This means that when the GitHub Action(s) completes, GitHub will send the results, along with the project description (and that SpiraPlan product token) to SpiraPlan via that webhook. SpiraPlan processes that data and adds it as a build.
The webhook URL
The webhook URL is made of different parts.
https://mysite.spiraservice.net. This is the start of every URL you use when using SpiraPlan/Services/Webhooks/BuildService.svc/GitHub?username={{username}}&api-key={{api key}}The final URL will look like this: https://mysite.spiraservice.net/Services/Webhooks/BuildService.svc/GitHub?username=github-actions&api-key={11111111-1111-1111-1111-111111111111}
When an Action on the GitHub project next runs (either from GitHub, or with the GitHub SpiraApp) it will report its results to SpiraPlan. SpiraPlan reads the product token to know what product the Action is for. SpiraPlan then looks the first release in that product that has the repo branch in the correct custom property that the GitHub Action was run against.
SpiraPlan creates a build against that release, with the key information, including the build status.
You can click on the build name/link to open its build details page. The build will also appear on any relevant widgets in SpiraPlan.
"},{"location":"Build-Server-Integration/GitLab-Pipelines/","title":"GitLab Pipelines","text":""},{"location":"Build-Server-Integration/GitLab-Pipelines/#introduction","title":"Introduction","text":"SpiraTest, SpiraTeam, and SpiraPlan (from here on called SpiraPlan) integrated seamlessly with GitLab in a number of ways. In this section we discuss SpiraPlan's GitLab Pipelines reporting integration.
You can easily configure your GitLab Pipelines to report against a release and create a new build in SpiraPlan each time they run. This let's you see the health of your CI/CD process within SpiraPlan.
GitLab SpiraApp
You can also let end users start GitLab Pipelines from within SpiraPlan itself. To do so you will need to enable and configure the GitLab SpiraApp
The integration has two parts, which are discussed below:
Summary
{{base url}}/Services/Webhooks/BuildService.svc/GitLab?username={{username}}&api-key={{api key}}The integration with GitLab Pipelines works by having a dedicated custom field for GitLab. This lets you link a release or sprint to a specific branch in a GitLab repo. In SpiraPlan we need to specify the branch name only. Then from GitLab we configure our specific repo to talk to the correct SpiraPlan product.
The first step in SpiraPlan is to create a release custom property:
Next, in your SpiraPlan product:
In GitLab we now need to setup our repo to talk to the correct SpiraPlan product. Your GitLab repo/project will need to use Pipelines for the integration to work. You can add or edit Actions at any time - this will not impact the integration.
First, we have to add information to link up the GitLab repo and SpiraPlan, by adding the SpiraPlan product reference into the repo. To do this:
[PR:{{product id}}]. For example, \"[PR:1]\". You can have other text in the description, as long as the token is in there somewhere.Second, you need to add a dedicated webhook. This means that when the GitLab Pipeline(s) completes, GitLab will send the results, along with the project description (and that SpiraPlan product token) to SpiraPlan via that webhook. SpiraPlan processes that data and adds it as a build.
The webhook URL
The webhook URL is made of different parts.
https://mysite.spiraservice.net. This is the start of every URL you use when using SpiraPlan/Services/Webhooks/BuildService.svc/GitLab?username={{username}}&api-key={{api key}}The final URL will look like this: https://mysite.spiraservice.net/Services/Webhooks/BuildService.svc/GitLab?username=gitlab-pipelines&api-key={11111111-1111-1111-1111-111111111111}
When an Action on the GitLab project next runs (either from GitLab, or with the GitLab SpiraApp)it will report its results to SpiraPlan. SpiraPlan reads the product token to know what product the Action is for. SpiraPlan then looks the first release in that product that has the repo branch in the correct custom property that the GitLab Pipeline was run against.
SpiraPlan creates a build against that release, with the key information, including the build status.
You can click on the build name/link to open its build details page. The build will also appear on any relevant widgets in SpiraPlan.
"},{"location":"Build-Server-Integration/Jenkins--Hudson/","title":"Jenkins / Hudson","text":"This section outlines how to use SpiraTest, SpiraTeam or SpiraPlan (hereafter referred to as SpiraPlan in conjunction with either the Jenkins or Hudson (hereafter referred to as Jenkins) continuous integration build servers. It assumes that you already have a working installation of SpiraTest, SpiraTeam or SpiraPlan v3.2 or later and a working installation of Jenkins/Hudson v2.7.3 or later. If you have an earlier version of SpiraPlan, you will need to upgrade to at least v3.2, and if you have any earlier version of Jenkins you will also need to upgrade it too.
Note: this integration is only available for Jenkins Freestyle Project items
"},{"location":"Build-Server-Integration/Jenkins--Hudson/#overview","title":"Overview","text":"Jenkins provides continuous integration services for software development, primarily in the Java programming language. It is a server-based system running in a servlet container such as Apache Tomcat. It supports SCM tools including CVS, Subversion, Git, Mercurial, Perforce and Clearcase, and can execute Apache Ant and Apache Maven based projects as well as arbitrary shell scripts and Windows batch commands.
When you use the SpiraPlan plugin for Jenkins, it will allow you to associate each Jenkins project with a corresponding project and release in SpiraPlan. Then, each time Jenkins creates a new build, a new build artifact will be created in SpiraPlan. Each build in SpiraPlan will be automatically linked to the incidents fixed, source code commits committed, and any SpiraPlan tokens in the Jenkins changelog will be parsed and turned into SpiraPlan artifact hyperlinks.
"},{"location":"Build-Server-Integration/Jenkins--Hudson/#installing-the-spiraplan-plug-in-for-jenkins","title":"Installing the SpiraPlan Plug-in for Jenkins","text":"The plug-in for SpiraPlan is available through the Jenkins Plugin Manager under the Available tab. Use the filter on the right of the screen to narrow down the plugins listed by typing spira. Check off Spira Importer and use the install that is best for your environment.
The Installing Plugins screen will show you the progress of the install.
After Jenkins has restarted, connect to your Jenkins server.
"},{"location":"Build-Server-Integration/Jenkins--Hudson/#setting-up-the-spiraplan-jenkins-plug-in","title":"Setting-Up the SpiraPlan Jenkins Plug-in","text":"Now that the plugin has been installed, you need to go back to the Jenkins homepage and click on the \"Manage Jenkins\" hyperlink followed by the \"Configure System\" hyperlink. This will bring up the main Jenkins configuration page. Scroll down to find the \"Spira Integeration\" section:
Enter in the URL you use to access your instance of SpiraPlan, together with a valid username and RSS key. You can find or generate the RSS Key from your user profile page inside Spira - read how to do so here. Make sure to include the curly braces - {ExampleRSS} - Once you have entered the values, click on the [Test Connection] button to verify that Jenkins can connect to SpiraPlan successfully. Once it has connected successfully, click the [Save] button at the bottom of the screen to save your connection settings.
"},{"location":"Build-Server-Integration/Jenkins--Hudson/#configuring-a-jenkins-job","title":"Configuring a Jenkins Job","text":"Now that you have setup the global SpiraPlan settings in Jenkins, next you need make a new item in Jenkins to associate each of your Jenkins Jobs with their corresponding SpiraPlan Product and Release/Sprint. To do this, go to the Jenkins Home Page and click in the upper left on New Item.
In the new Item page enter a meaningful name for the job and select Freestyle project. At the bottom left of the page click the OK button.
Scroll down in the Build Triggers page to the Build Environment Section. Under the section \"Build Environment\" select the checkbox marked \"Enable Spira Integration\". That will display the SpiraPlan configuration panel for this job:
Now you need to enter the following values:
Product ID -- The numeric ID of the SpiraPlan Product that the Build belongs to. (e.g. for Product PR1 enter \"1\")
Release Version Number -- The active version number of the SpiraPlan Release/Sprint that the Build belongs to. (e.g. for Release RL4 with version number 1.0.0.0 you'd enter \"1.0.0.0\")
Once you have entered in the Product ID and Release version number, click the [Verify Release] button and the plugin will connect to SpiraPlan and verify that the product exists, that the release/sprint is currently active, that the specified release/sprint exists in the product, and that the current user can connect to that product.
Once it has verified successfully, click the [Save] button at the bottom of the screen to save your Job configuration settings. You are now ready to use Jenkins with SpiraPlan.
"},{"location":"Build-Server-Integration/Jenkins--Hudson/#viewing-the-build-results-in-spiraplan","title":"Viewing the Build Results in SpiraPlan","text":"Now that you have associated your Jenkins job with a specific SpiraPlan product and active release/sprint, you can now use Jenkins to manage your software builds and have the results of the build be reported back into SpiraPlan. For example when the 'Build JUnit' job illustrated in the previous section is executed, it will report back the following result in Jenkins:
The corresponding build entry will also be created in SpiraPlan under the specified product and release/sprint:
If you have configured your Product Home to include the list of recent builds, the build information will also be displayed on the Project Home dashboard:
Clicking on either of the hyperlinks will allow you to navigate to the Build details page inside SpiraPlan:
This page will display the status (success / failure) and details of the build (from the Jenkins Console Output) together with a list of the associated incidents, test runs and source code commits. The following section will explain how to use your Source Code Management (SCM) system to take advantage of the Spira Importer plugin and automatically link incidents and source code commits to the build information.
"},{"location":"Build-Server-Integration/Jenkins--Hudson/#working-with-source-code-changesets","title":"Working with Source Code Changesets","text":"When your developers commit changes to your application's source into the SCM repository, they should make sure to link the commit to the appropriate artifacts in SpiraPlan. For example they may want to record that the commit fixes a specific incident or implements a specific feature (requirement).
Linking an artifact is very simple. All the developer needs to do is enter the artifact token in the following format:
[PREFIX:ID]
The first half, the Artifact Identifier, is a two-letter code that is used throughout SpiraPlan, and is visible on almost every page in the application. For example, a requirement's identifier is \"RQ\". Incidents are \"IN\", and tasks are \"TK\". The artifact ID is the number of the artifact. So by creating a commit message that reads:
SpiraPlan will automatically detect the tokens and will include links to them under the Associations tab for each commit detail in SpiraPlan.
In addition, when Jenkins creates the next build (that includes this commit), the plugin will automatically parse the commit message and convert the tokens into hyperlinks to the corresponding SpiraPlan artifact. That way, when developers view the build changelog in Jenkins, it will automatically include links to the SpiraPlan items:
Meanwhile, inside SpiraPlan, the system will use the same information to automatically link the list of associated commits to the build record:
If the commit message contains Incident tokens, the plugin will also automatically link those incidents to the appropriate build:
Similarly when you view the list of incidents inside SpiraPlan you will now be able to sort and filter the list by the associated build:
Congratulations! You are now able to use SpiraPlan and Jenkins to be able to manage your builds and have the build status integrated into your SpiraPlan project dashboard.
"},{"location":"Build-Server-Integration/Jenkins--Hudson/#scheduling-test-sets-upon-successful-builds","title":"Scheduling Test Sets Upon Successful Builds","text":"One additional feature of the integration with SpiraTest, SpiaTeam, and SpiraPlan (hereafter just SpiraPlan) is the ability to have SpiraPlan automatically schedule the execution of a test set whenever a build passes.
To do that, make sure the Test Set is associated with the SpiraPlan release or sprint that is being built and then set the Schedule on Build field to \"Yes\" and optionally enter in the delay (after the build succeeds) that you want the test set to be scheduled for:
This means that you don't need to separately manage your build schedule in Jenkins and your test automation schedule in SpiraTest.
"},{"location":"Build-Server-Integration/JetBrains-TeamCity/","title":"JetBrains TeamCity","text":"This section outlines how to use SpiraTest, SpiraPlan or SpiraTeam (hereafter referred to as SpiraTeam) in conjunction with the JetBrains' TeamCity continuous integration build servers. It assumes that you already have a working installation of SpiraTest, SpiraPlan or SpiraTeam v6.0 or later and a working installation of TeamCity v9.0.4 or later. If you have an earlier version of SpiraTeam, you will need to upgrade to at least v6.0.
"},{"location":"Build-Server-Integration/JetBrains-TeamCity/#overview","title":"Overview","text":"TeamCity provides continuous integration services for software development, primarily in the Java programming language. It is a server-based system running that supports a variety of different version control systems and build runners. It supports SCM tools including CVS, Subversion, Git, Mercurial, Perforce and Borland StarTeam, and can execute Apache Ant and Apache Maven based projects as well as arbitrary shell scripts and Windows batch commands.
When you use the SpiraTeam Plug-In for TeamCity, it will allow you to associate each TeamCity project with a corresponding project and release in SpiraTeam. Then, each time TeamCity creates a new build, a new build artifact will be created in SpiraTeam. Each build in SpiraTeam will be automatically linked to the incidents fixed, tasks implemented, requirements developed and source code commits committed.
"},{"location":"Build-Server-Integration/JetBrains-TeamCity/#installing-the-spirateam-plug-in-for-teamcity","title":"Installing the SpiraTeam Plug-in for TeamCity","text":"Go to the Inflectra website and open up the page that lists the various downloads available for SpiraTeam (http://www.inflectra.com/SpiraTeam/Downloads.aspx). Listed on this page will be the SpiraTeam Plug-In for TeamCity. Right-click on this link and save the Zip compressed folder to the TeamCity's Plug-In directory ($TEAMCITY_USER_HOME/plugins). After that, restart TeamCity for the plugin to take effect. It's also possible to install the Plug-In through the user interface of TeamCity via Administration > Plugins List > Upload Plugin Zip, choosing the zip-file from your file-system:
Do not forget to restart TeamCity for the plugin to take effect.
Once TeamCity has restarted, you can see the SpiraTeam Plug-In listed as one of the installed plugins:
"},{"location":"Build-Server-Integration/JetBrains-TeamCity/#setting-up-the-spirateam-teamcity-plug-in","title":"Setting-Up the SpiraTeam TeamCity Plug-in","text":"Now that the plugin has been installed, you need to configure the Global Settings for integration with SpiraTeam. To do this, go to Administration > Spira Global Settings:
You will need TeamCity administrator privileges to access this configuration page. Once in the Spira Global Settings page, enter in the URL you use to access your instance of SpiraTeam, together with a valid username and API Key. Once you have entered the values, click on the [Save] button. TeamCity will then verify if it can connect to SpiraTeam successfully.
Once it has connected successfully, your connection settings will be saved. In case of error, follow the instructions on-screen and try again.
After setting the global configurations appropriately, you will need to enable the notifications in TeamCity. To do this, go to My Settings & Tools, that can be accessed through clicking your TeamCity username (top right). Once there, click on the Notification Rules section, find the Spira Notifier for TeamCity section, and click its hyperlink:
Once in the page, click in Add new Rule. Then, inside the Send notification when section, select the events you want TeamCity notify SpiraTeam:
After selecting your preferences, click in the Save button.
"},{"location":"Build-Server-Integration/JetBrains-TeamCity/#configuring-a-teamcity-project","title":"Configuring a TeamCity Project","text":"Now that you have setup the Global SpiraTeam and Notifications settings in TeamCity, next you need to associate each of your TeamCity Projects with their corresponding SpiraTeam Project and Release/Iteration. To do this, click on the name of a project and then click on the \"Spira Project Configuration\" tab for that Project:
In this page you can check the URL of the SpiraTeam Server. If it is wrong, you can change it in the Spira Global Settings menu. It is also possible to check the Project ID associated with the project in TeamCity. This information can be useful for debugging/checking reasons.
To associate a TeamCity Project with a SpiraTeam Project, enter the following values:
Project ID -- The numeric ID of the SpiraTeam Project that the Build belongs to. (e.g. for Project PR00001 just enter 1)
Release Version Number -- The version number of the SpiraTeam Release/Iteration that the Build belongs to. (e.g. for Release RL0004 with version number 1.0.0.0 you'd enter just 1.0.0.0)
Once you have entered in the Project ID and Release version number, click the [Save] button and the plugin will connect to SpiraTeam and verify that the project exists, that the current user can connect to that project, and that the specified release/iteration exists in the project. Once it has verified successfully, it will save your Project configuration settings. In case of error, follow the instructions on-screen and try again. You are now ready to use TeamCity with SpiraTeam.
"},{"location":"Build-Server-Integration/JetBrains-TeamCity/#viewing-the-build-results-in-spirateam","title":"Viewing the Build Results in SpiraTeam","text":"Now that you have associated your TeamCity Project with a specific SpiraTeam project and release/ iteration, you can now use TeamCity to manage your software builds and have the results of the build be reported back into SpiraTeam. For example when the 'BuildConfigTest' build of Project 1 illustrated in the figure bellow is executed, it will report in TeamCity:
The corresponding build entry will also be created in SpiraTeam under the specified project and release/iteration:
If you have configured your Project Home to include the list of recent builds, the build information will also be displayed on the Project Home dashboard:
Clicking on either of the hyperlinks will allow you to navigate to the Build details page inside SpiraTeam:
This page will display the status (success / failure) and details of the build (imported from the TeamCity Console Output) together with a list of the associated incidents, test runs and source code commits. The following section will explain how to use your Source Code Management (SCM) system to take advantage of the SpiraTeam plugin and automatically link incidents and source code commits to the build information.
"},{"location":"Build-Server-Integration/JetBrains-TeamCity/#working-with-source-code-changesets","title":"Working with Source Code Changesets","text":"When your developers commit changes to your application's source into the SCM repository, they should make sure to link the commit to the appropriate artifacts in SpiraTeam. For example they may want to record that the commit fixes a specific incident or implements a specific feature (requirement).
Linking an artifact is very simple. All the developer needs to do is enter the artifact token in the following format:
[PREFIX:ID]
The first half, the Artifact Identifier, is a two-letter code that is used throughout SpiraTeam, and is visible on almost every page in the application. For example, a requirement's identifier is \"RQ\". Incidents are \"IN\", and tasks are \"TK\". The artifact ID is the number of the artifact. So by creating a commit message that reads:
SpiraTeam will automatically detect the tokens and will include links to them under the Associations tab for each commit detail in SpiraTeam.
Inside SpiraTeam, the system will use the same information to automatically link the list of associated commits to the build record:
If the commit message contains Incident tokens, the plugin will also automatically link those incidents to the appropriate build:
Similarly when you view the list of incidents inside SpiraTeam you will now be able to sort and filter the list by the associated build:
Congratulations! You are now able to use SpiraTeam and TeamCity to be able to manage your builds and have the build status integrated into your SpiraTeam project dashboard.
"},{"location":"Build-Server-Integration/JetBrains-TeamCity/#scheduling-test-sets-upon-successful-builds","title":"Scheduling Test Sets Upon Successful Builds","text":"One additional feature of the integration with SpiraTest and SpiraTeam (hereafter just SpiraTest) is the ability to have SpiraTest automatically schedule the execution of a test set whenever a build passes.
To do that, make sure the Test Set is associated with the SpiraTest release or iteration that is being built and then set the Schedule on Build field to \"Yes\" and optionally enter in the delay (after the build succeeds) that you want the test set to be scheduled for:
This means that you don't need to separately manage your build schedule in Jenkins and your test automation schedule in TeamCity.
"},{"location":"Build-Server-Integration/Microsoft-Azure-DevOps-Pipelines/","title":"Microsoft Azure DevOps Pipelines","text":"This section outlines how to use SpiraTest, SpiraPlan or SpiraTeam (hereafter referred to as SpiraPlan) in conjunction with Microsoft's Azure DevOps continuous integration platform called Azure DevOps Pipelines. It assumes that you already have a working installation of SpiraPlan v5.0 or later and have already setup Microsoft Azure DevOps Pipelines. If you have an earlier version of SpiraTeam, you will need to upgrade to at least v5.0.
"},{"location":"Build-Server-Integration/Microsoft-Azure-DevOps-Pipelines/#overview","title":"Overview","text":"Microsoft Azure DevOps provides tools for managing the entire application lifecycle, including source code management, reporting, automated builds, testing and release capabilities, for example. It supports version control using either its native TFS source code management system or Git. SpiraTeam has version control plugins for both TFS native and TFS with Git source code management options.
When you use the Spira Build Server Extension for Azure DevOps, it will allow you to associate different Azure DevOps projects with a corresponding project and release in SpiraPlan. Then, each time a DevOps pipeline creates a new build, a new build artifact will be created in SpiraPlan. Each build in SpiraTeam will be automatically linked to the incidents fixed, tasks implemented, requirements developed and source code commits committed.
"},{"location":"Build-Server-Integration/Microsoft-Azure-DevOps-Pipelines/#installing-the-spirateam-build-plug-in-for-azure-devops","title":"Installing the SpiraTeam Build Plug-in for Azure DevOps","text":"Go to the Inflectra website and open up the page that lists the various downloads available for SpiraTeam (http://www.inflectra.com/SpiraTeam/Downloads.aspx). Listed on this page will be the Azure DevOps Pipeline Plug-In. When you click on the link on this page, it will take you to the Azure DevOps Marketplace, where you can install the Spira extension into your DevOps instance:
After that, the plugin will be available in your instance of Azure DevOps.
"},{"location":"Build-Server-Integration/Microsoft-Azure-DevOps-Pipelines/#authenticating-with-spira","title":"Authenticating with Spira","text":"In DevOps, open the project you would like to have builds sync with Spira. Go to Project Settings > Pipelines > Service Connections
Under Service connections, click the \"New service connection\" button and click \"SpiraPlan Configuration.\" Under connection name, put something helpful like SpiraPlan Fred Bloggs
For SpiraPlan URL put the 'root' directory of your Spira instance, not including the end slash. For username, put the username you use to sign-in to Spira. For RSS Token, go to your user profile page in Spira, enable RSS Feeds and copy the token into DevOps. Now verify the connection by clicking \"Verify connection,\" if you entered everything correctly, you're good to go!
"},{"location":"Build-Server-Integration/Microsoft-Azure-DevOps-Pipelines/#adding-the-spira-build-task","title":"Adding the Spira Build Task","text":"Now in the pipeline you would like to add Spira support to, open the pipeline's YAML file and in the assistant to the right, search \"Spira\" and select \"Export data to Spira\" Select the service connection name you put in earlier, enter the ID of the project in Spira you would like your results sent to, the ID of the release you would like the builds to be associated with, and the base url of your DevOps instance (like https://dev.azure.com/fabrikam or https://fabrikam.visualstudio.com)
The other fields are used internally by the plugin and should be left as-is - DO NOT CHANGE THEM. Click \"Add\" and add the condition: succeededOrFailed() above inputs in the YAML snippet. This makes sure that the Spira task can access the current build status.
Now move the spira-build-task YAML Snippet to the end of the file so that it's executed last. This will make sure that the final result of the build gets recorded in Spira.
Here is an example YAML file:
trigger:\n- master\n\npool:\nvmImage: 'ubuntu-latest'\n\nsteps:\n- task: NodeTool@0\ninputs:\nversionSpec: '10.x'\ndisplayName: 'Install Node.js'\n- script: |\nnpm install\nnpm test\ndisplayName: 'npm install and test'\n- task: PublishTestResults@2\ncondition: succeededOrFailed()\ninputs:\ntestRunner: JUnit\ntestResultsFiles: '**/junitresults-*.xml'\n- task: spira-build-task@0\ncondition: succeededOrFailed()\ninputs:\nconnectedService: 'SpiraPlan Fred Bloggs'\nproject: '2'\nreleaseId: '20'\nbaseUrl: 'https://dev.azure.com/inflectra'\nbuildNumber: '$(Build.BuildNumber)'\nbuildStatus: '$(Agent.JobStatus)'\nbuildId: '$(Build.BuildId)'\nsourceVersion: '$(Build.SourceVersion)'\nprojectName: '$(System.TeamProject)'\nIf everything had been configured correctly a new build in DevOps will create a new build in Spira!
"},{"location":"Build-Server-Integration/Microsoft-Azure-DevOps-Pipelines/#viewing-the-build-results-in-spirateam","title":"Viewing the Build Results in SpiraTeam","text":"Now that you have associated your Azure DevOps pipeline with a specific SpiraTeam project and release/ iteration, you can now use Azure DevOps to manage your software builds and have the results of the build be reported back into SpiraPlan. For example, when a DevOps Pipeline runs, it will report in Azure DevOps something like the following:
The corresponding build entry will also be created in SpiraPlan under the specified project and release/iteration:
If you have configured your Project Home to include the list of recent builds, the build information will also be displayed on the Project Home dashboard:
Clicking on either of the hyperlinks will allow you to navigate to the Build details page inside SpiraTeam:
This page will display the status (success / failure) and details of the build.
Congratulations! You are now able to use SpiraPlan and Azure DevOps to be able to manage your builds and have the build status integrated into your SpiraPlan project dashboard.
"},{"location":"Build-Server-Integration/Microsoft-Azure-DevOps-Pipelines/#scheduling-test-sets-upon-successful-builds","title":"Scheduling Test Sets Upon Successful Builds","text":"One additional feature of the integration with SpiraPlan is the ability to have SpiraPlan automatically schedule the execution of a test set whenever a build passes.
To do that, make sure the Test Set is associated with the SpiraPlan release or iteration that is being built and then set the Schedule on Build field to \"Yes\" and optionally enter in the delay (after the build succeeds) that you want the test set to be scheduled for:
This means that you don't need to separately manage your build schedule in Azure DevOps and your test automation schedule in SpiraPlan.
"},{"location":"Email-Integration/Configuring-the-Email-Integration-Service/","title":"Configuring the Email Integration Service","text":"Once you have completed the installation, you can configure the email integration service by going to Start > Program Files > Inflectra SpiraTeam > Tools > Email Integration which will bring up the management interface.
"},{"location":"Email-Integration/Configuring-the-Email-Integration-Service/#connecting-to-the-spirateam-server","title":"Connecting to the SpiraTeam Server","text":"The first tab lets you specify the SpiraTeam instances that the email integration service will connect to. To add a new SpiraTeam server, click on the green Add (+) icon to switch the screen to allow you to enter a new server:
You need to enter the following information:
Click the \"Test\" button to verify the connection. Once it has passed, click the Save icon to save the new SpiraTeam server information.
To modify an existing SpiraTeam server instance, just click on its name in the server list. To delete a server, select its name in the server list and click the Delete icon (X).
Once you have entered all the SpiraTeam instances that you will be connecting to, click the \"Next\" button to move to the next tab and configure the mail server integration.
"},{"location":"Email-Integration/Configuring-the-Email-Integration-Service/#connecting-to-the-pop3-mail-server","title":"Connecting to the POP3 Mail Server","text":"The \"POP3 Accounts\" tab displays a list of all the configured mail servers:
Initially it will be empty, so just click the Add (+) icon to add a new mail server:
You need to enter the following information:
Using Gmail
If you use Google Workspace (gmail) make sure to take the following two steps. Note that personal gmail accounts are not supported.
To enable POP switch to an administrator account. This will open the Google Admin console. Follow https://support.google.com/a/answer/105694?hl=en to Google instructions to proceed.
To allow less secure app access - starting from May 30, 2022, \u200b\u200bGoogle no longer supports the use of third-party apps or devices which ask you to sign in to your Google Account using only your user name and password. This deadline does not apply to Google Workspace or Google Cloud Identity customers. For more information please refer to the Google Help: https://support.google.com/accounts/answer/6010255?hl=en#zippy=%2Cuse-more-secure-apps%2Cuse-an-app-password
"},{"location":"Email-Integration/Configuring-the-Email-Integration-Service/#configuring-the-advanced-settings","title":"Configuring the Advanced Settings","text":"Once you have finished configuring the SpiraTeam server instances and POP3 mail accounts, you can click on the \"Advanced Settings\" tab to setup special rules that prevent emails from specific accounts being processed as well as allow the email integration service to look for special mail headers and subject tokens that might indicate bulk / spam messages that should be ignored.
You can configure the following settings:
In addition, there are two other sub-tabs to the Advanced Settings tab that provide configuration options:
The \"Ignore Headers\" section allows you to specify any email message headers that if present in an email message will be ignored by the email integration service.
Note: Right now, the importer will only check the presence of a header, not its contents. As long as the header exists, even if it's value is null, the message will not be imported.
The \"Ignore Keywords\" section allows you to specify any keywords/phrases that if present in the subject-line or body of an email message will be ignored by the email integration service. Some mail servers that have built-in SPAM detection systems will automatically add SPAM-HIGH, SPAM-MEDIUM, SPAM-LOW to the subject line (for example).
The \"SpamAssasin\" section allows you to enable SpamAssasin utility, if you have a server that is running SpamAssasin. If this is enabled, messages marked as spam will not be imported, and be left on the mail server. You can use SpamAssasin's own level, or override the value. For information and support on SpamAssasin, see their website http://spamassasin.appache.org
"},{"location":"Email-Integration/Installing-the-Email-Integration-Service/","title":"Installing the Email Integration Service","text":"This section outlines how to install the SpiraTeam email integration service onto your environment. Depending on your environment you can install the email integration service on:
Your SpiraTeam application server
Your corporate mail server
A separate workstation that can connect to both SpiraTeam and your mail server
If your SpiraTeam installation is installed on-premise, then you can use options (1), (2) or (3), if your SpiraTeam installation is hosted by Inflectra as a Software as a Service (SaaS) subscription then you'd need to use either option (2) or (3).
Once you have downloaded the SpiraTeam email integration installation package (InflectraEmailIntegration.msi) from the Inflectra website you should download it onto the appropriate computer and double-click on it to run the Windows installer package:
You should click on the \"Next\" button, read the End User License Agreement, check the box that you agree with its terms and then click the \"Next\" button. This brings up the installation location page:
You should choose the appropriate place to install the email integration service and then click \"Next\". On the next screen click the \"Install\" button and it will complete the software installation.
Once the installation has completed, you will see the following new service listed in the Control Panel > Administrative Tools > Windows Services section:
The service should be listed to run in Automatic mode and should already be started.
Note: This email integration service is able to integrate with both KronoDesk and SpiraTeam from Inflectra, however the focus of this guide is the integration with SpiraTest, SpiraPlan and SpiraTeam (hereafter SpiraTeam) only.
"},{"location":"Email-Integration/Using-the-Email-Integration-Service-with-SpiraTeam/","title":"Using the Email Integration Service with SpiraTeam","text":"Once you have the email integration service configured, we recommend that you initially clear the Windows Application Log on the machine. This will allow you to quickly see any errors that occur due to misconfiguration. The event viewer can be found in Control Panel > Administrative Tools > Event Viewer.
Once you have the email integration enabled and running, any users that email in a support ticket to one of the \"watched\" email addresses will experience the following process:
The user emails incident.logger@mycompany.com with an incident to create.
The contents (including attachments) of the email will be parsed by the email integration service.
The application will look for tokens to decide if it should be inserted in the default project or another user-specified project.
The sender's email address will be queried to make sure that the user has access to create incident in the selected project. (If not, the system will then check the user's permissions for the default project.)
If the user has permission, the new incident is created.
The user will receive an automated email from the system letting them know that the incident was created:
SpiraTeam Incident \"Need New Security Settings updated in Documentation\" in project \"Project1\" has been changed.
Please log into SpiraTeam to view this Incident's details.
https://localhost/spirateam/6/Incident/2196.aspx
The user will not be subscribed to the ticket unless the user falls under normal Workflow Notification or Event Notification settings.
Any time the user gets a notification email from the server, they can reply to the email -- leaving the token in the subject line unaltered -- and their reply will be put into the ticket as a new comment. It's important that -- if enabled in the SpiraTeam application -- the separator line is not altered, and the reply is kept above the line. Any test under that line will not be imported. (If the separator line is altered, or the option is disabled in the SpiraTeam administration, then the entire email, including quotes and reply text, will be inserted.)
This section outlines the general data synchronization configuration to use any of the supported bug trackers with SpiraTest, SpiraPlan or SpiraTeam (hereafter referred to as Spira).
\u25ba Please read this section first, before performing the configuration steps specific to your bug-tracker.
The built-in data-synchronization service that comes with Spira, allows the quality assurance team to manage their requirements and test cases in Spira, execute their test runs, and then have the new defects/bugs generated during the run be automatically loaded into an external bug-tracker. Once the incidents are loaded into the external bug-tracker, the development team can then manage the lifecycle of these defects/bugs in their chosen tool, and have the status changes be reflected back in Spira.
In addition, any issues logged directly into the external bug-tracker will get imported into Spira as either new incidents or new requirements (depending on their type) so that they can be used as part of the planning and testing lifecycle.
There are three possible deployment options for the Spira data synchronization:
We shall provide the configuration steps for each option:
"},{"location":"External-Bug-Tracking-Integration/Setting-up-Data-Synchronization/#spira-external-tool-cloud-hosted","title":"Spira & External Tool Cloud Hosted","text":"Using the Customer Area to Manage the Spira DataSync
The \"Spira DataSync\" is a cloud based data synchronization tool that can be used to synchronize your cloud Spira to a number of cloud hosted external tools. Configuration is minimal and is managed from the Customer Area of your Inflectra account.
The Customer Area is your organization's dedicated portal on the Inflectra website for managing your account and subscriptions with us. It is used for:
Access to the Customer Area is restricted to only a couple of people in each organization. This is to ensure that only select authorized people are able to manage and make payments on their account.
If you do not have access to your organization's customer area, and you wish to edit or manage the \"Spira DataSync\" you will need to contact the owner of the Inflectra account in your organization. They will be able to assist you in configuring any settings as required.
When you sign up for Spira for a cloud-hosted trial, you can add on the Spira DataSync service to the trial for free. NOTE: the DataSync service is only free during the free trial period - there is a nominal charge for the service once you start your subscription.
Make sure to include the 'Spira DataSync' add-on with your trial.
If you did not include the Spira DataSync with your trial, you can add one at any time once your subscription starts. Go to the customer area; find the \"My Cloud Subscriptions\" section and click \"Customize\" next to the subscription you want to add the Spira DataSync to:
Once your trial (or subscription) is provisioned, you will be able to configure the connection to Spira by going to your secure Customer Area on our website. Click on the 'Configure' button associated with the Spira-DataSync addon row:
Enter a login and password that can connect to your Spira instance. This user, for all of the product(s) that will be synchronize with the external bug-tracker, needs to:
Click on the 'Test' button to verify the credentials, and once they validate, make sure the 'Active' flag is checked and then click 'Save'. You have now configured the synchronization.
Now navigate to your Spira instance. Go to System Administration > Integration > Data Sychronization to see a list of the plugins currently configured (as in the example below):
If you click on any of the 'Manage' buttons you will be taken to your Spira instance where you can complete the plugin configuration:
The steps for configuring each plugin are specific to each external bug-tracking tool. Please refer to the appropriate section in this document for the tool you are using.
"},{"location":"External-Bug-Tracking-Integration/Setting-up-Data-Synchronization/#spira-installed-on-premise","title":"Spira Installed On-Premise","text":"With Spira installed on-premise, there is a built-in Windows\u00ae service that is installed with Spira that is not running by default, but is available for data-synchronization.
The steps that need to be performed to configure integration are as follows:
Go to the Inflectra website and open up the page that lists the various downloads available for Spira (http://www.inflectra.com/SpiraTeam/Downloads.aspx). Listed on this page will be the data-synchronization plug-In for your desired bug-tracking tool. Right-click on this link and save the Zip compressed folder to the hard-drive of the server where Spira is installed.
Open up the compressed folder and extract the DLL assembly files and place them in the C:\\\\Program Files (x86)\\\\SpiraTeam\\\\DataSync folder (it may be SpiraTest or SpiraPlan depending on which product you're running). This folder should already contain the DataSyncService.exe and DataSyncService.exe.config files that are the primary files used for managing the data synchronization between Spira and other systems.
To configure the integration service, please open up the DataSyncService.exe.config file located in C:\\\\Program Files (x86)\\\\SpiraTeam\\\\DataSync with a text editor such as Notepad. Once open, it should look like:
<?xml version=\"1.0\" encoding=\"utf-8\"?>\n<configuration>\n<configSections>\n<sectionGroup name=\"applicationSettings\" type=\"System.Configuration.ApplicationSettingsGroup, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089\" >\n<section name=\"Inflectra.SpiraTest.DataSyncService.Properties.Settings\" type=\"System.Configuration.ClientSettingsSection, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089\" requirePermission=\"false\" />\n</sectionGroup>\n</configSections>\n<applicationSettings>\n<Inflectra.SpiraTest.DataSyncService.Properties.Settings>\n<setting name=\"PollingInterval\" serializeAs=\"String\">\n<value>600000</value>\n</setting>\n<setting name=\"WebServiceUrl\" serializeAs=\"String\">\n<value>http://localhost/SpiraTeam</value>\n</setting>\n<setting name=\"Login\" serializeAs=\"String\">\n<value>fredbloggs</value>\n</setting>\n<setting name=\"Password\" serializeAs=\"String\">\n<value>fredbloggs</value>\n</setting>\n<setting name=\"EventLogSource\" serializeAs=\"String\">\n<value>SpiraTeam Data Sync Service</value>\n</setting>\n<setting name=\"TraceLogging\" serializeAs=\"String\">\n<value>False</value>\n</setting>\n</Inflectra.SpiraTest.DataSyncService.Properties.Settings>\n</applicationSettings>\n</configuration>\nThe sections that need to be verified and possibly changed are the values for the following 4 setting XML tags above.
For each of these, check the following information:
The polling interval allows you to specify how frequently the data-synchronization service will ask Spira and the external system for new data updates. The value is specified in milliseconds and we recommend a value around 2-5 minutes (i.e. 120,000 - 300,000ms). The larger the number, the longer it will take for data to be synchronized, but the lower the network and server overhead. When you are using a bidirectional synchronization plugin, a shorter value with avoid conflicting changes being made in the system systems.
The base URL to your instance Spira. It is typically of the form http://<server name>/SpiraTeam. Make sure that when you enter this URL on a browser on the server itself, the application login page appears.
A valid login name and password to your instance of Spira. This user, for all of the product(s) that will be synchronize with the external bug-tracker, needs to:
Once you have made these changes, please refer to the section in this document that covers the specific bug-tracking tool you will be integrating with.
Note: If you are using the MS-TFS plugin on premise, you will also need to switch over your IIS application pool running Spira to \"Enable 32-bit Applications. You will also need to download the recompiled 32-bit version of the DataSyncService.exe application from our support knowledge base - KB14 - Using SpiraTeam Data Synchronization with TFS on a 64-bit system.
"},{"location":"External-Bug-Tracking-Integration/Setting-up-Data-Synchronization/#starting-the-data-synchronization-service","title":"Starting the Data-Synchronization Service","text":"When Spira is installed, a Windows Service -- SpiraTeam Data Sync Service -- is installed along with the web application. However to avoid wasting system resources, this service is initially set to run manually. To ensure continued synchronization of SpiraTeam with the external tool, we recommend starting the service and setting its startup-type to Automatic.
To make these changes, open up the Windows Control Panel, click on the \"Administrative Tools\" link, and then choose the Services option. This will bring up the Windows Service control panel:
Click on the 'SpiraTeam Data Sync Service' entry and click on the link to start the service. Then right-click the service entry and choose the option to set the startup type to 'Automatic'. This will ensure that synchronization continues after a reboot of the server.
"},{"location":"External-Bug-Tracking-Integration/Setting-up-Data-Synchronization/#spira-cloud-hosted-external-tool-on-premise","title":"Spira Cloud Hosted, External Tool On-Premise","text":"The Desktop Data Synchronization utility (hereafter referred to as the \"Desktop DataSync\") is a standalone utility than can be used to run the various Data Synchronization PlugIns without a server installation of Spira.
This is useful where you have your SpiraTeam instance cloud hosted, but the external tool is locally installed behind your firewall.
"},{"location":"External-Bug-Tracking-Integration/Setting-up-Data-Synchronization/#installation","title":"Installation","text":"To obtain the Desktop DataSync, go to the Inflectra website and under the \"Downloads and Add-Ons\" section you will find a Windows Installation (MSI) package that will install the Desktop DataSync onto your computer. The installer will install both a 64-bit version of the Desktop Data Sync and a 32-bit version. You should use the 64-bit version for all plugins except the Microsoft TFS plugin which will require the 32-bit version.
Next you need to download the appropriate plug-in(s) for the various bug-trackers (as described in the appropriate section of this document) and place the assemblies (DLL files) into the same folder that contains the DesktopDataSync.exe application:
"},{"location":"External-Bug-Tracking-Integration/Setting-up-Data-Synchronization/#usage","title":"Usage","text":"Once you have downloaded and installed the application and appropriate plug-ins, go to Start > Programs > Inflectra > Desktop DataSync to launch the application.
This will bring up the main options window of the application:
You should then enter the URL, login and password to your Spira installation and click [Test]. Assuming that this information is correct, you will see a confirmation message:
Now you should complete the configuation by setting the Polling Interval (how often the utility will synchronize data between Spira and the external system) and whether Trace Logging is enabled (useful when verifying your data mapping, but will fill up the application log, so leave unchecked for production use). Then click the [Update] button to save your settings or [Start] to save your settings and start synchronization immediately.
Once the Options window closes, the application will remain active in the system tray of your computer:
You can then use the right-click context menu to start synchronization, stop synchronization, view the status (if synchronization is running) or exit the application altogether.
During synchronization, any errors will be logged to the Windows Application Event Log and you can use those logs to diagnose any issues connecting to the external bug-tracker or any data mapping configuration changes that need to be made.
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-Asana/","title":"Using Spira with Asana","text":"This section outlines how to use SpiraTest, SpiraTeam or SpiraPlan (hereafter referred to as Spira) in conjunction with the Asana task tracking system.
Set up data synchronization
STOP! Please make sure you have first read the instructions to set up the data sync before proceeding!
Asana is a simple yet powerful cloud-based task management system used to track tasks. The built-in integration between Spira and Asana lets you create incidents and tasks in Spira and have them synchronize over to Asana as tasks.
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-Asana/#configuring-the-integration-service","title":"Configuring the Integration Service","text":"This section outlines how to set up the integration service between Asana and Spira. It assumes that you already have a working installation of Spira and a valid Asana account, workspace and project to integrate with. To setup the service, you must be logged into Spira as a user with System-Administrator level account.
Inside Spira, go to the Administration page and navigate to the Integration > Data Synchronization webpage. Check that you don't already have a Plug-In called \"AsanaDataSync\", as shown below:
If you already have a plug-in called AsanaDataSync, please click on its edit button, otherwise please click the Add button to create a new plug-in.
Now fill out this configuration page as follows:
You need to fill out the following fields for the Asana Data Sync plugin to work properly:
Name -- This needs to be set to AsanaDataSync
Caption -- This is the display name of the plug-in, generally something generic like \"Asana\" would work, but you should change it if you will be syncing with multiple Asana workspaces.
Description -- The description of what you're using the plug-in for. This field is entirely optional and is not used by the system in any way.
Connection Info -- The name of your Asana workspace, this is the name of your workspace or organization, not project.
Login -- Your Asana username / login
Password -- An Asana personal access token. For more information on personal access tokens, please refer to: https://asana.com/guide/help/api/api
Time Offset -- This should be set to 0, but if you find that changes are not being synced, try increasing the value to tell the plugin to offset timestamps
Custom 01-05 -- These fields are not used for Asana and can be left blank.
Once all those fields have been filled out, click the Add or Save button to save your changes.
For this step, please ensure that you are in the Spira project you would like to sync with Asana. For this example, the project is called \"Sample Empty Product 1\".
Click on the \"View Project Mappings\" button for Asana Data Sync. You need to fill out the following fields to sync correctly:
External Key -- The name of your Asana project. In our example, the project is called \"Sample Project\".
Active -- Set this to yes so that the Data Sync plug-in knows to synchronize with this project.
The project looks like this in Asana:
The Asana plugin will synchronize incidents and tasks, so you will need to setup the status mappings for incidents and tasks. We shall discuss each in turn.
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-Asana/#configuring-the-incident-status-mapping","title":"Configuring the Incident Status Mapping","text":"Now click the \"Status\" button within the \"Incident\" section to map the incident statuses together. The purpose of this is so that the Asana Data Sync plug-in knows what the equivalent status is in Asana for an incident status in Spira.
You must map every status in the system. Descriptions of the field are below:
External Key -- Either incomplete or completed, which are the only two statuses in Asana
Primary -- You must have exactly one primary key for incomplete and one for completed. This is what status the plug-in should set the incident in Spira to when the status in Asana changes.
Now click the \"Status\" button within the \"Task\" section to map the task statuses together. The purpose of this is so that the Asana Data Sync plug-in knows what the equivalent status is in Asana for an task status in Spira.
You must map every status in the system. Descriptions of the field are below:
External Key -- Either incomplete or completed, which are the only two statuses in Asana
Primary -- You must have exactly one primary key for incomplete and one for completed. This is what status the plug-in should set the task in Spira to when the status in Asana changes.
To configure the mapping of users in the two systems, you need to go to Administration > Users > View Edit Users, which will bring up the list of users in the system. Then click on the \"Edit\" button for a particular user that will be editing tasks in Asana:
Click on the 'Data Mapping' tab to list all the configured data-synchronization plug-ins for this user. In the text box next to the Asana Data-Sync plug-in you need to enter the login for this username in Asana. This will allow the data-synchronization plug-in to know which user in Spira match which equivalent user in Asana. Click Save once you've entered the appropriate login name. You should now repeat for the other users who will be active in both systems.
If you have set the \"Auto-Map Users\" option in the Asana plugin, you can skip this section completely.
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-Asana/#using-the-data-synchronization","title":"Using the Data Synchronization","text":"Assuming everything was done correctly, the plug-in should start working. If you are using Spira on-premise, start your Data Sync service and you can now start synchronizing incidents and tasks
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-Asana/#synchronizing-spira-incidents","title":"Synchronizing Spira Incidents","text":"When you log a new incident in Spira, for example:
It will appear in Asana as a new task:
Any of the following changes made in Asana will update back into Spira:
In addition, the Spira incident will automatically include a hyperlink to the corresponding item in Asana:
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-Asana/#synchronizing-spira-tasks","title":"Synchronizing Spira Tasks","text":"When you log a new task in Spira, for example:
It will appear in Asana as a new task:
Any of the following changes made in Asana will update back into Spira:
In addition, the Spira task will automatically include a hyperlink to the corresponding item in Asana:
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-Asana/#summary","title":"Summary","text":"Congratulations, you have just integrated your Spira instance with the Asana task tracking system.
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-Axosoft-14%2B/","title":"Using Spira with Axosoft 14+","text":"This section outlines how to use SpiraTest, SpiraPlan or SpiraTeam (hereafter referred to as SpiraTeam) in conjunction with the Axosoft defect tracking system (formerly known as OnTime). The built-in integration service allows the quality assurance team to manage their requirements and test cases in SpiraTeam, execute test runs in SpiraTest, and then have the new incidents generated during the run be automatically loaded into Axosoft.
Once the incidents are loaded into Axosoft as defects, the development team can then manage the lifecycle of these defects in Axosoft, and have the status changes in Axosoft be reflected back in SpiraTeam.
Set up data synchronization
STOP! Please make sure you have first read the instructions to set up the data sync before proceeding!
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-Axosoft-14%2B/#configuring-the-plug-in","title":"Configuring the Plug-In","text":"This section outlines how to configure the integration service to export incidents into Axosoft and pick up subsequent status changes in Axosoft and have them update SpiraTeam. It assumes that you already have a working installation of SpiraTest, SpiraPlan or SpiraTeam v4.0 or later and a working installation of Axosoft 14 or later (either hosted in the cloud or on-premise). If you have an earlier version of SpiraTeam, you will need to upgrade to at least v4.0 before trying to integrate with Axosoft.
The steps that need to be performed to configure integration with Axosoft are as follows:
Enable the REST API in Axosoft
Setup the plug-in in SpiraTeam to point to the correct instance of Axosoft
Configure the data field mappings between SpiraTeam and Axosoft
Start synchronization and verify data transfer
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-Axosoft-14%2B/#enable-the-rest-api-in-axosoft","title":"Enable the REST API in Axosoft","text":"First you will need to login to your instance of Axosoft and click on Tools > System Options. Then click on the 'Axosoft API Settings' section:
Check the box to 'Enable API' and then click on the [Manage API Keys] button:
On this screen you will need to enter the name of the application you are creating an API key for (e.g. \"Spira\") and then record the following two pieces of information:
Client ID
Client Secret
You will need these later on. Then click Save.
The Axosoft Client Secret is a long hash that will be of the form:
ykk8WD3eYfMJ6WbV1HtkutJv_w9jS2ah1tSbwqs-408Gp0_cPh5wTnjwfqPLN3-_oCSHPVG5tpFkETHBgxUBKbXaTzzVqYtKC9_S
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-Axosoft-14%2B/#configuring-the-plug-in_1","title":"Configuring the Plug-In","text":"The next step is to configure the plug-in within SpiraTeam so that the system knows how to access the Axosoft server. To start the configuration, please open up SpiraTeam in a web browser, log in using a valid account that has System-Administration level privileges and click on the System > Data Synchronization administration option from the left-hand navigation:
This screen lists all the plug-ins already configured in the system. Depending on whether you chose the option to include sample data in your installation or not, you will see either an empty screen or a list of sample data-synchronization plug-ins.
If you already see an entry for AxosoftDataSync you should click on its \"Edit\" link. If you don't see such an entry in the list, please click on the [Add] button instead. In either case you will be taken to the following screen where you can enter or modify the Axosoft Data-Synchronization plug-in:
You need to fill out the following fields for the Axosoft Plug-in to operate correctly:
Name -- this needs to be set to AxosoftDataSync. This needs to match the name of the plug-in DLL assembly that was copied into the C:\\Program Files\\SpiraTeam\\Bin folder (minus the .dll file extension). If you renamed the AxosoftDataSync.dll file for any reason, then you need to change the name here to match.
Description -- this should be set to a description of the plug-in. This is an optional field that is used for documentation purposes and is not actually used by the system.
Connection Info -- this should the full URL to Axosoft. This is typically something like: https://mysite.axosoft.com.
Login -- this should be set to the login that you use to access Axosoft through its web interface
Password -- this should be set to the password that you use to access Axosoft through its web interface
Time Offset -- normally this should be set to zero, but if you find that defects being changed in Axosoft are not being updated in SpiraTeam, try increasing the value as this will tell the data-synchronization plug-in to add on the time offset (in hours) when comparing date-time stamps.
Auto-Map Users -- This changes the way that the plugin maps users in SpiraTeam to those in Axosoft:
**Auto-Map = True **With this setting, all users in SpiraTeam need to have the same username as those in Axosoft. If this is the case then you do not need to perform the user-mapping task outlined in Configuring the User Mapping. This is a big time-saver if you can guarantee that all usernames are the same in both systems.
**Auto-Map = False **With this setting, users in SpiraTeam and Axosoft are free to have different usernames because you specify the corresponding Axosoft login for each user as outlined in Configuring the User Mapping.
Custom 01 -- This should contain the Client ID value from the Axosoft API Key screen
Custom 02 -- This should contain the Axosoft Client Secret that you obtained from the Axosoft API Key Screen.
Custom 03-05 -- these are not currently used by the Axosoft data-sync plug-in and can be left blank.
Next, you need to configure the data mapping between SpiraTeam and Axosoft. This allows the various projects, users, releases, incident statuses, priorities, severities and custom property values used in the two applications to be related to each other. This is important, as without a correct mapping, there is no way for the integration service to know that an \"Open\" incident in SpiraTeam is the same as an \"Open\" defect in Axosoft (for example).
The following mapping information needs to be setup in SpiraTeam:
The mapping of the project identifiers for the projects that need to be synchronized
The mapping of users in the system
The mapping of releases in the system
The mapping of the various standard fields in the system
The mapping of the various custom properties in the system
Each of these is explained in turn below:
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-Axosoft-14%2B/#configuring-the-project-mapping","title":"Configuring the Project Mapping","text":"From the data synchronization administration page, you need to click on the \"View Project Mappings\" hyperlink next to the Axosoft plug-in name. This will take you to the data-mapping home page for the currently selected project:
If the project name does not match the name of the project you want to configure the data-mapping for, click on the \"(Change Project)\" hyperlink to change the current project.
To enable this project for data-synchronization with Axosoft, you need to enter:
External Key -- This should be set to the name of the project token in Axosoft:
If you have a sub-project, you need to include both the parent and sub-project names separated by a forward slash (/), e.g. MyProject/SubProject1.
Active Flag -- Set this to 'Yes' so that SpiraTeam knows that you want to synchronize data for this project. Once the project has been completed, setting the value to \"No\" will stop data synchronization, reducing network utilization.
Click [Update] to confirm these settings. Once you have enabled the project for data-synchronization, you can now enter the other data mapping values outlined below.
Note: Once you have successfully configured the project, when creating a new project, you should choose the option to \"Create Project from Existing Project\" rather than \"Use Default Template\" so that all the project mappings get copied across to the new project.
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-Axosoft-14%2B/#configuring-the-user-mapping","title":"Configuring the User Mapping","text":"(This section can be skipped if you enabled the 'AutoMap Users' option earlier).
To configure the mapping of users in the two systems, you need to go to Administration > Users > View Edit Users, which will bring up the list of users in the system. Then click on the \"Edit\" button for a particular user that will be editing defects in Axosoft:
You will notice that in the Data Mapping tab for the user is a list of all the configured data-synchronization plug-ins. In the text box next to the Axosoft Data-Sync plug-in you need to enter the Login Name for this username in Axosoft. This will allow the data-synchronization plug-in to know which user in SpiraTeam match which equivalent user in Axosoft. Click [Update] once you've entered the appropriate login name. You should now repeat for the other users who will be active in both systems.
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-Axosoft-14%2B/#configuring-the-release-mapping","title":"Configuring the Release Mapping","text":"When the data-synchronization service runs, when it comes across a release/iteration in SpiraTeam that it has not seen before, it will create a corresponding Release in Axosoft. Similarly if it comes across a new Release in Axosoft that it has not seen before, it will create a new Release in SpiraTeam. Therefore when using both systems together, it is recommended that you only enter new Releases in one system and let the data-synchronization service add them to the other system.
To see this mapping, inside SpiraTeam, navigate to Planning > Releases and click on the Release/Iteration in question. Make sure you have the 'Overview' tab visible and expand the \"Details\" section of the release/iteration:
In addition to the standard fields and custom properties configured for Releases, you will see an additional text property called \"AxosoftDataSync ID\" that is used to store the mapped external identifier for the equivalent Version in Axosoft.
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-Axosoft-14%2B/#configuring-the-standard-field-mapping","title":"Configuring the Standard Field Mapping","text":"Now that the projects, user and releases have been mapped correctly, we need to configure the standard incident fields. To do this, go to Administration > System > Data Synchronization and click on the \"View Project Mappings\" for the AxosoftDataSync plug-in entry:
From this screen, you need to click on Priority, Severity and Status in turn to configure their values (Axosoft doesn't support different defect types):
a) Incident Status
Click on the \"Status\" hyperlink under Incident Standard Fields to bring up the Incident status mapping configuration screen:
The table lists each of the incident statuses available in SpiraTeam and provides you with the ability to enter the matching Axosoft defect status names for each one. You can map multiple SpiraTeam fields to the same Axosoft fields (e.g. New and Open in SpiraTeam are both equivalent to Open in Axosoft), in which case only one of the two values can be listed as Primary = Yes as that's the value that's used on the reverse synchronization (from Axosoft > SpiraTeam).
We recommend that you always point the New and Open statuses inside SpiraTeam to point to the \"Open\" status inside Axosoft and make Open in SpiraTeam the Primary status of the two. This is recommended so that as new incidents in SpiraTeam get synched over to Axosoft, they will get switched to the Open status in Axosoft which will then be synched back to \"Open\" in SpiraTeam. That way you'll be able to see at a glance which incidents have been synched with Axosoft and those that haven't.
Note: The Axosoft external key needs to exactly match the display name of the status inside Axosoft. If you change the name of a status in Axosoft, you'll need to update the value in the data-mapping configuration as well.
b) Incident Priority
Click on the \"Priority\" hyperlink under Incident Standard Fields to bring up the Incident Priority mapping configuration screen:
The table lists each of the incident priorities available in SpiraTeam and provides you with the ability to enter the matching Axosoft priority name for each one. You can map multiple SpiraTeam fields to the same Axosoft fields, in which case only one of the two values can be listed as Primary = Yes as that's the value that's used on the reverse synchronization (from Axosoft > SpiraTeam).
Note: The Axosoft external key needs to exactly match the display name of the priority inside Axosoft. If you change the name of a priority in Axosoft, you'll need to update the value in the data-mapping configuration as well.
c) Incident Severity
Click on the \"Severity\" hyperlink under Incident Standard Fields to bring up the Incident severity mapping configuration screen:
The table lists each of the incident severities available in SpiraTeam and provides you with the ability to enter the matching Axosoft severity name for each one. You can map multiple SpiraTeam fields to the same Axosoft fields, in which case only one of the two values can be listed as Primary = Yes as that's the value that's used on the reverse synchronization (from Axosoft > SpiraTeam).
Note: The Axosoft external key needs to exactly match the display name of the severity inside Axosoft. If you change the name of a severity in Axosoft, you'll need to update the value in the data-mapping configuration as well.
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-Axosoft-14%2B/#configuring-the-custom-property-mapping","title":"Configuring the Custom Property Mapping","text":"Now that the various SpiraTeam standard fields have been mapped correctly, we need to configure the custom property mappings. This is used for both custom properties in SpiraTeam that map to custom fields in Axosoft and also for custom properties in SpiraTeam that are used to map to standard fields in Axosoft (currently only Replication Procedures) that don't exist in SpiraTeam.
From the View/Edit Project Data Mapping screen, you need to click on the name of the Incident Custom Property that you want to add data-mapping information for. We will consider the three different types of mapping that you might want to enter:
a) Scalar Custom Properties
This refers to custom properties that have a simple user-entered value and don't need to have their specific options mapped between SpiraTeam and Axosoft. All of the custom property types except List and Multi-List fall into this category (e.g. Text, Date, User, Boolean, Decimal, Integer, etc.)
Click on the hyperlink of the text custom property under Incident Custom Properties to bring up the custom property mapping configuration screen. For text custom properties there will be no values listed in the lower half of the screen.
You need to lookup the display name of the custom field in Axosoft that matches this custom property in SpiraTeam. Once you have entered the id of the custom field, click [Update].
b) List Custom Properties
Click on the hyperlink of the list custom property under Incident Custom Properties to bring up the custom property mapping configuration screen. For list custom properties there will be a textbox for both the custom field itself and a mapping table for each of the custom property values that need to be mapped:
First you need to lookup the display name of the custom field in Axosoft that matches this custom property in SpiraTeam. This should be entered in the 'External Key' field below the name of the custom property.
Next for each of the Property Values in the table (in the lower half of the page) you need to enter the full name of the custom field value as specified in Axosoft.
Once you have updated the various mapping sections, you are now ready to use the service.
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-Axosoft-14%2B/#using-spirateam-with-axosoft","title":"Using SpiraTeam with Axosoft","text":"Now that the integration service has been configured and the service started, initially any incidents created in SpiraTeam for the specified projects will be imported into Axosoft and vice versa.
At this point we recommend opening the Windows Event Viewer and choosing the Application Log. In this log any error messages raised by the SpiraTeam Data Sync Service will be displayed. If you see any error messages at this point, we recommend immediately stopping the SpiraTeam service and checking the various mapping entries. If you cannot see any defects with the mapping information, we recommend sending a copy of the event log message(s) to Inflectra customer services (support@inflectra.com) who will help you troubleshoot the problem.
To use SpiraTeam with Axosoft on an ongoing basis, we recommend the following general processes be followed:
When running tests in SpiraTeam, defects found should be logged through the 'Add Incident' option as normal.
Developers can log new defects into either SpiraTeam or Axosoft. In either case they will get loaded into the other system.
Once created in one of the systems and successfully replicated to the other system, the incident should not be modified again inside SpiraTeam
At this point, the incident should not be acted upon inside SpiraTeam, and all data changes to the defect should be made inside Axosoft. To enforce this, you can modify the workflows set up in SpiraTeam so that the various fields are marked as inactive for all the incident statuses other than the \"New\" status. This will allow someone to submit an incident in SpiraTeam, but will prevent them making changes in conflict with Axosoft after that point.
As the defect progresses through the Axosoft workflow, changes to the status, priority, severity, and resolution will be updated automatically in SpiraTeam. In essence, SpiraTeam acts as a read-only viewer of these incidents.
You are now able to perform test coverage and incident reporting inside SpiraTeam using the test cases managed by SpiraTeam and the incidents managed on behalf of SpiraTeam inside Axosoft.
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-ClickUp/","title":"Using Spira with ClickUp","text":"ClickUp is a cloud based project management system that can be synced with SpiraTest, SpiraTeam or SpiraPlan (Spira from here on). This data sync lets you:
Details of how to set this up and things to watch out for are explained below.
Set up data synchronization
STOP! Please make sure you have first read the instructions to set up the data sync before proceeding!
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-ClickUp/#system-setup","title":"System Setup","text":"This section outlines how to set up the integration between ClickUp and Spira. It assumes you already have a working installation of Spira (Version 7.3+) as well as a workspace in ClickUp. To setup the service, you must be logged into a Spira user with System-Administrator level privileges.
Inside SpiraPlan, open the system admin menu and open the Integration > Data Synchronization page. Check if you see a plug-in called ClickUpDataSync, as shown below:
What do if the plug-in is not there
If you don't see the plug-in in the list, click the \"\"Add\" button at the top of the page. This opens the generic Data Sync plug-in details page. This is not yet customized to help you more easily set up the data sync. We recommend, adding just enough information now to create the plug-in. Then edit the plug-in after its made to complete the process.
To start, fill in the following fields:
Now click \"Add\" to save the plug-in and return you to the list of plug-ins. Then follow the instructions below.
With the plug-in place, click on its \"edit\" button to open its detailed settings page.
You need to fill out the following fields for the ClickUp Data Sync plugin to work properly:
login) here, and enter the actual token in the password field below)Custom 01 (Data Sync Directionality): This should contain one of these 3 options and determines how the data sync will function.
clickup_to_spira: sync new and updated information from ClickUp to Spiraspira_to_clickup: sync new information from Spira to ClickUp (see the box below for more information about how syncing from Spira to ClickUp works)bidirectional: sync both of the above options at onceCustom 02 (Artifact Sync Options): The types of information you want to sync, with the names in a comma separated list. requirements, tasks, incidents, releases, files, and associations are the choices. You may also put \"all\" to select all of these options. For example, you could enter: all, requirements, tasks, incidents, releases, files, associations, or requirements, incidents, releases. Note that not all of these artifacts sync in both directions (see the box below for more information)
Click the \"Save\" button.
How syncing from Spira to ClickUp works
Please note the following ways that the data sync from Spira to ClickUp works. These also apply when syncing from Spira to ClickUp with the sync direction set to bidirectional:
For this step, from the Data Synchronization page:
From the product's data mapping page for ClickUp, enter a value for the external key, set \"Active\" to \"Yes\", and click \"Save\".
How to configure external key: The external key contains the names of a Space to sync with this product, and also the name of the Workspace that space is in. This must be in the format of \"Workspace Name || Space Name\" (notice the double pipe | characters) and should match the capitalization of the names in ClickUp. Here is an example of what this looks like, and how it relates to ClickUp's UI:
Incompatible description formatting between platforms
Please note that text formatting in descriptions from either service cannot be mapped to the other, as their formats are not compatible. Complex structures such as tables may produce unintended results that are confusing in the opposite service when synced. The data sync does its best to turn both formats into plain text to keep the descriptions readable.
Click the \"Status\" button within the incident, task, or requirement section (You should do this for each artifact you intend to sync). From here, map each status in ClickUp to a status in Spira.
Note: If 1 mapped status in ClickUp is mapped to multiple statuses in Spira, you must choose which is the primary mapping. The primary mapping will be used when syncing from ClickUp to Spira.
Here is an example using ClickUp's \"Normal\" Status Template:
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-ClickUp/#configuring-priority-mappings","title":"Configuring priority mappings","text":"Priority mappings are very similar to status, except the values from ClickUp's priority field are not customizable.
Here is an example of how this would look using default Spira priorities with ClickUp's priorities:
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-ClickUp/#configuring-custom-property-mappings","title":"Configuring custom property mappings","text":"This section assumes the custom properties in Spira and ClickUp are of compatible types. Custom property syncing will not work and may cause the sync to fail if this is not adhered to. Below is a list of custom property types in Spira and which custom properties in ClickUp can map to them. Any custom property types besides the ones outlined here will not be attempted to be mapped into Spira. Fields marked with ** will only be synced from ClickUp to Spira due to formatting constraints.
Spira custom property type Matching ClickUp custom property type Text (not rich text) TextText AreaEmailUrlPhone Decimal Number DateDate & Time Date Boolean Checkbox List Dropdown Multiselect List Labels"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-ClickUp/#non-list-custom-properties","title":"Non-List Custom Properties","text":"To configure a non-list custom property in ClickUp to a custom property in Spira, set the external key to the name of the property in ClickUp (case sensitive). As an example, if there is a text field in ClickUp named \"Custom Text\", you would configure the mapping like this:
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-ClickUp/#list-custom-properties","title":"List Custom Properties","text":"To configure a list or multiselect list custom property, first follow the steps for a non-list property. After that, configure the options. It is important that these options match the exact capitalization in ClickUp. As an example, here is a multiselect list in Spira mapped to a labels custom property in ClickUp named \"Labels In ClickUp\" with the options \"Label 1\", \"Label 2\", \"Label 3\", and \"Label 4\":
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-ClickUp/#configuring-user-mappings","title":"Configuring User mappings","text":"Users must be configured manually for this data sync in order for the owner and creator fields to be assigned to that user during syncing.
To configure the mapping of users in the two systems, go to Administration > Users > View / Edit Users to see the list of users in the Spira system. Click the \"Edit\" button for a particular user that edits tasks in ClickUp:
Click on the \"Data mapping\" tab to list all the configured data-synchronization plug-ins for this user. In the text box labeled \"ClickUp ID\", enter the full name of the user in ClickUp. Click \"Save\" and the user will be mapped so long as the configuration was done correctly. Repeat this for each user who will be active in both systems.
NOTE: avoid having duplicate names for multiple users. If this is the case, you will need to change the name somehow in ClickUp to make them unique (for example, by adding any middle initial).
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-ClickUp/#using-the-data-synchronization","title":"Using the Data Synchronization","text":"Once the steps above have been carried out, the data sync will start working once you mark the \"Active\" option for the data sync at the system level and in all relevant products.
Congratulations, you have just integrated your Spira instance with the ClickUp project managing system.
Wait for the \"Status\" on the data sync to update to see if it was successful. If it failed, look at the event logs for error messages which may contain insights into what part of the configuration you need to fix.
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-GitHub/","title":"Using Spira with GitHub","text":"GitHub's issue tracker is a simple and lightweight tool used to track problems with an associated git repository.
You can use this integration to sync new incidents, new comments, statuses, and releases (milestones) bidirectionally with SpiraTest, SpiraTeam or SpiraPlan (SpiraPlan from here on).
Set up data synchronization
STOP! Please make sure you have first read the instructions to set up the data sync before proceeding!
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-GitHub/#configuring-the-integration-service","title":"Configuring the Integration Service","text":"This section outlines how to set up the integration service between GitHub and SpiraPlan. It assumes that you already have a working installation of SpiraPlan and a GitHub repository with an issue tracker. To setup the service, you must be logged into SpiraPlan as a user with System-Administrator level privileges.
Inside SpiraPlan, go to the Administration page and navigate to Integration > Data Synchronization. Check if you see a plug-in called GitHubDataSync, as shown below:
What do if the plug-in is not there
If you don't see the plug-in in the list, click the \"\"Add\" button at the top of the page. This opens the generic Data Sync plug-in details page. This is not yet customized to help you more easily set up the data sync. We recommend, adding just enough information now to create the plug-in. Then edit the plug-in after its made to complete the process.
To start, fill in the following fields:
Now click \"Add\" to save the plug-in and return you to the list of plug-ins. Now follow the instructions below.
With the plug-in place, click on its \"edit\" button to open its detailed settings page.
You need to fill out the following fields for the GitHub Data Sync plugin to work properly:
Click the \"Save\" button.
NOTE: Leave any field called \"(Not Used)\" blank.
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-GitHub/#configuring-project-mappings","title":"Configuring Project Mappings","text":"For this step, please ensure that you are in the SpiraPlan project you would like to sync with GitHub. For this example, the project is called \"GitHub Data Sync.\"
Click on the \"View Project Mappings\" button for GitHub Data Sync. You need to fill out the following fields to sync correctly:
External Key -- The name of your GitHub repository. In the example above, where the URL in GitLab was https://github.com/octocat/Hello-World, you would simply enter \"Hello-World\" for this setting.
Active -- Set this to yes so that the Data Sync plug-in knows to synchronize with this project.
Now click the \"Status\" button within the \"Incident\" section to map the Incident statuses together. The purpose of this is so that the GitHub Data Sync plug-in knows what the equivalent status is in GitHub for an incident status in SpiraPlan.
You must map every status in the system. Descriptions of the field are below:
External Key -- Either open or closed, which are the only two statuses in GitHub
Primary -- You must have exactly one primary key for open and one for closed. This is what status the plug-in should set the incident in SpiraPlan to when the status in GitHub changes.
Click \"Save\" and assuming everything was done correctly, the plug-in should work. Start your Data Sync service and verify that issues in GitHub appear inside SpiraPlan. Note that the Data Sync service is not running constantly, so it may take some time for changes to materialize.
Congratulations, you have just integrated your Spira instance with GitHub's integrated issue tracker!
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-GitLab/","title":"Using Spira with GitLab","text":"GitLab's issue tracker is a simple and lightweight tool used to track problems with an associated git repository.
You can use this integration to sync new incidents, new comments, statuses, and releases (milestones) bidirectionally with SpiraTest, SpiraTeam or SpiraPlan (SpiraPlan from here on).
Set up data synchronization
STOP! Please make sure you have first read the instructions to set up the data sync before proceeding!
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-GitLab/#configuring-the-integration-service","title":"Configuring the Integration Service","text":"This section outlines how to set up the integration service between GitLab and SpiraPlan. It assumes that you already have a working installation of SpiraPlan and a GitLab repository with an issue tracker. To setup the service, you must be logged into SpiraPlan as a user with System-Administrator level privileges.
Inside SpiraPlan, go to the Administration page and navigate to Integration > Data Synchronization. Check if you see a plug-in called GitLabDataSync as shown below:
What do if the plug-in is not there
If you don't see the plug-in in the list, click the \"\"Add\" button at the top of the page. This opens the generic Data Sync plug-in details page. This is not yet customized to help you more easily set up the data sync. We recommend, adding just enough information now to create the plug-in. Then edit the plug-in after its made to complete the process.
To start, fill in the following fields:
Now click \"Add\" to save the plug-in and return you to the list of plug-ins. Now follow the instructions below.
With the plug-in place, click on its \"edit\" button to open its detailed settings page.
You need to fill out the following fields for the GitLab Data Sync plugin to work properly:
Click the \"Save\" button.
NOTE: Leave any field called \"(Not Used)\" blank.
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-GitLab/#configuring-project-mappings","title":"Configuring Project Mappings","text":"For this step, please ensure that you are in the SpiraPlan project you would like to sync with GitLab. For this example, the project is called \"GitLab Data Sync.\"
Click on the \"View Project Mappings\" button for GitLab Data Sync. You need to fill out the following fields to sync correctly:
External Key -- The name of your GitLab repository. In the example above, where the URL in GitLab was https://gitlab.com/gitlab-examples/velociraptor, you would simply enter \"velociraptor\" for this setting.
Active -- Set this to yes so that the Data Sync plug-in knows to synchronize with this project.
Now click the \"Status\" button within the \"Incident\" section to map the Incident statuses together. The purpose of this is so that the GitLab Data Sync plug-in knows what the equivalent status is in GitLab for an incident status in SpiraPlan.
You must map every status in the system. Descriptions of the field are below:
External Key -- Either opened or closed, which are the only two statuses in GitLab
Primary -- You must have exactly one primary key for opened and one for closed. This is what status the plug-in should set the incident in SpiraPlan to when the status in GitLab changes.
To configure the mapping of users in the two systems, you need to go to Administration > Users > View Edit Users, which will bring up the list of users in the system. Then click on the \"Edit\" button for a particular user that will be editing issues in GitLab:
Click on the 'Data Mapping' tab to list all the configured data-synchronization plug-ins for this user. In the text box next to the GitLab Data-Sync plug-in you need to enter the login for this username in GitLab. This will allow the data-synchronization plug-in to know which user in SpiraTeam match which equivalent user in GitLab. Click [Save] once you've entered the appropriate login name. You should now repeat for the other users who will be active in both systems.
If you have set the \"Auto-Map Users\" option in the GitLab plugin, you can skip this section completely.
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-GitLab/#configuring-the-release-mapping","title":"Configuring the Release Mapping","text":"When the data-synchronization service runs, when it comes across a release/iteration in SpiraTeam that it has not seen before, it will create a corresponding \"Milesone\" in GitLab. Similarly, if it comes across a new Milestone in GitLab that it has not seen before, it will create a new Release in SpiraTeam. Therefore, when using both systems together, it is recommended that you only enter new Releases/Milestones in one system and let the data-synchronization service add them to the other system.
However, you may start out with the situation where you already have pre-existing Releases / Milestones in both systems that you need to associate in the data-mapping. If you don't do this, you may find that duplicates get created when you first enable the data-synchronization service. Therefore, for any Releases/Iterations that already exist in BOTH systems please navigate to Planning > Releases and click on the Release/Iteration in question. Make sure you have the 'Overview' tab visible and expand the \"Details\" section of the release/iteration:
In addition to the standard fields and custom properties, you will see an additional text property called \"GitLab ID\" that is used to store the mapped external identifier for the equivalent Milestone in GitLab. You need to locate the ID of the equivalent version in GitLab, enter it into this text-box and click [Save]. You should now repeat for all the other pre-existing releases.
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-GitLab/#using-the-data-synchronization","title":"Using the Data Synchronization","text":"Assuming everything was done correctly, the plug-in should start working. Start your Data Sync service and verify that issues in GitLab appear inside SpiraPlan. Note that the Data Sync service is not running constantly, so it may take some time for changes to materialize.
Congratulations, you have just integrated your Spira instance with GitLab's integrated issue tracker!
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-Monday/","title":"Using Spira with monday.com","text":"The monday.com products are cloud-based platforms that allows users to create their own applications and work management software with more than 50 integrations with other applications.
This page outlines how to use SpiraTest, SpiraTeam, or SpiraPlan (called Spira from here on) with monday.com products. This data sync engine lets you add new monday.com items to Spira as Tasks and Incidents (and vice versa). The data sync also lets you update artifacts and items in both systems/directions.
Set up data synchronization
STOP! Please make sure you have first read the instructions to set up the data sync before proceeding!
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-Monday/#configuring-the-plug-in","title":"Configuring the Plug-In","text":"Now that the data synchronization service / application itself is set up, we are ready to move to the next step. You need to tell Spira how to access your monday.com app. Inside Spira, go to the Administration page (as a system admin) and navigate to Integration > Data Synchronization. Check if you see a plug-in called MondayDataSync.
What do if the plug-in is not there
If you don't see the plug-in in the list, click the \"\"Add\" button at the top of the page. This opens the generic Data Sync plug-in details page. This is not yet customized to help you more easily set up the data sync. We recommend, adding just enough information now to create the plug-in. Then edit the plug-in after its made to complete the process.
To start, fill in the following field:
Now click \"Add\" to save the plug-in and return you to the list of plug-ins. Now follow the instructions below.
With the plug-in place, click on its \"edit\" button to open its detailed settings page. Now fill out this configuration page as follows:
You need to fill out the following fields for the monday.com Data Sync plug-in:
Sync Mode: This option allows choosing between unidirectional or bidirectional syncing of items and/or artifacts between the systems. The valid values are shown below. Please enter the sync mode you want exactly as written. If this field is left blank, the sync will be bidirectional:
monday_to_spira - new and updated items in monday.com are sent to Spira. No data or updates go from Spira to monday.comspira_to_monday - new and updated tasks and incidents in Spira are sent to monday.com. No data or updates go from monday.com to Spirabidirectional - new and updated items/artifacts go from monday.com to Spira, and from Spira to monday.comArtifact\u00a0Sync Mode: Use this field to set which artifacts and items get synced between the two systems. The valid values are shown below. By choosing \"tasks_only\", for example, you can limit the sync to just Tasks. If this field is blank, the data sync will look for changes in both artifacts.
Sync subitems?: Ignore this setting if you are using the spira_to_monday sync mode. Otherwise, if you want the monday.com subitems to be synced to Spira, please enter yes to this field. If you want the datasync to skip monday.com subitems, enter no. You can learn more about this below.
Once all those fields have been filled out, click the \"Save\" button to save your changes.
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-Monday/#configuring-project-mappings","title":"Configuring Project Mappings","text":"For this step, please ensure that you are in the Spira project you would like to sync with monday.com. For this example, the project is called \"Monday.com DS Team Management\".
Click on the \"View Project Mappings\" button for monday.com Data Sync. You need to fill out the following fields to sync correctly:
Workspace||Task Board,,Incident Board. Please enter your monday.com Workspace name followed by two pipe characters (||), then the monday.com board name you want to sync with Tasks in Spira followed by two commas (,,), and finally the monday.com board name you want to sync with Incidents in Spira. Please note that all the pipes and commas are always required. If you don't want to sync Incidents for example, your external key should be something such as myWorkspace||,,MyIncidentBoard. Make sure to enter the exact name of the workspace and board(s) on the product external key, otherwise the data may be synced to the wrong workspace and board(s).Use this as a reference to find the necessary names in monday.com:
The monday.com plugin can synchronize Incidents and Tasks, so you will need to set up the status mappings for these artifacts, accordingly to the Artifact Sync Mode you chose. We shall discuss each in turn.
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-Monday/#incident-status-mapping","title":"Incident Status Mapping","text":"Now click the \"Status\" button within the \"Incident\" section to map the incident statuses together. The purpose of this is so that the monday.com Data Sync plug-in knows what the equivalent status is in monday.com for an incident status in Spira. Please make sure this is called Status in monday.com.
You must map every status in the system. Descriptions of the field are below:
Select the \"Priority\" button within the \"Incident\" section to map the incident priorities together. The purpose of this is so that the monday.com Data Sync plug-in knows what the equivalent priority is in monday.com for an incident priority in Spira. Please make sure this is called Priority in monday.com.
You must map every priority in the system. Descriptions of the field are below:
Select the \"Type\" button within the \"Incident\" section to map the incident types together. The purpose of this is so that the monday.com Data Sync plug-in knows what the equivalent type is in monday.com for an incident type in Spira. Please make sure this is called Type in monday.com.
You must map every Type in the system. Descriptions of the field are below:
Now click the \"Severity\" button within the \"Incident\" section to map the incident severities together. Use the same logic as described in the Incident Priority Mapping section.
Click the \"Status\" button within the \"Task\" section to map the task statuses together. Use the same logic as described in the Incident Status Mapping section.
Click the \"Priority\" button within the \"Task\" section to map the task priorities together. Use the same logic as described in the Incident Priority Mapping section.
Click the \"Type\" button within the \"Task\" section to map the task types together. Use the same logic as described in the Incident Type Mapping section.
If you have set the \"Auto-Map Users\" option in the *monday.com plugin, you can skip this section completely.*
To configure the mapping of users in the two systems, you need to go to Administration > Users > View Edit Users, which will bring up the list of users in the system. Then click on the \"Edit\" button for a particular user that will be editing items in monday.com:
Click on the 'Data Mapping' tab to list all the configured data-synchronization plug-ins for this user. In the text box next to the Monday.com Data-Sync plug-in you need to enter the display name for this user in monday.com. This will allow the data-synchronization plug-in to know which user in Spira match which equivalent user in monday.com. Click Save once you've entered the appropriate login name. You should now repeat for the other users who will be active in both systems.
The flexibility of monday.com means some assumptions were made in the design of this data sync. Specific column names are mapped to their counterparts in SpiraPlan based on the list below. If a field is not present in monday.com, it will not be synced.
Spira Field monday.com Field Name monday.com Field Type Incident Description Description Text Incident Priority Priority Single Dropdown (Status) Incident Severity Severity Single Dropdown (Status) Incident Type Type Single Dropdown (Status) Incident Status Status Single Dropdown (Status) Incident Start Date Start Date Date Incident End Date End Date Date Incident Detected By Creator People Incident Owner Owner People Task Description Description Text Task Priority Priority Single Dropdown (Status) Task Type Type Single Dropdown (Status) Task Status Status Single Dropdown (Status) Task Start Date Start Date Date Task End Date End Date Date Task Creator Creator People Task Owner Owner PeopleIt's also possible to sync the monday.com item Group to a Spira custom property for Incidents and/or Tasks. To do that, in Spira:
Additionally, please make sure that the board(s)/workspace names provided as an External Key for a Spira Product are unique in the monday.com workspace/system, otherwise, the data may be synced to/from the wrong board/workspace.
Due to the nature of text fields in monday.com (only plain text is supported), descriptions will only be synced from Monday to Spira on creation and from Spira to Monday all the time.
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-Monday/#mondaycom-sub-items","title":"monday.com sub-items","text":"monday.com allows users to create sub-items for any item in the boards. By default, the data sync will sync these subitems in Spira. They will have their parent linked under the 'Associations' tab in Spira. To turn off the subitems sync feature, change the Sync subitems? property of the data sync to no. It's not possible to create subitems in monday.com from Spira.
Once everything has been setup correctly the plug-in should start working. If you are using Spira on-premise, start your Data Sync service and you can now start synchronizing incidents and/or tasks.
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-Monday/#synchronizing-spira-incidents","title":"Synchronizing Spira Incidents","text":"If you selected both or incidents_only as your Artifact\u00a0Sync Mode, and spira_to_monday or bidirectional as the Sync Mode, when you log a new incident in Spira, it will appear in monday.com as a new item of your Incidents Board:
If you selected monday_to_spira or bidirectional as the Sync Mode, when you add a new item in your monday.com Incidents Board, it will appear in Spira as a new Incident.
If you selected both or tasks_only as your Artifact\u00a0Sync Mode, and spira_to_monday or bidirectional as the Sync Mode, when you create a new task in Spira, it will appear in monday.com as a new item of your Tasks Board:
If you selected monday_to_spira or bidirectional as the Sync Mode, when you add a new item in your monday.com Tasks Board, it will appear in Spira as a new Task.
Congratulations, you have just integrated your Spira instance with the monday.com project managing system.
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-OnTime-11/","title":"Using Spira with OnTime 11","text":"This section outlines how to use SpiraTest, SpiraPlan or SpiraTeam (hereafter referred to as SpiraTeam) in conjunction with the OnTime 11+ defect tracking system from AxoSoft. The built-in integration service allows the quality assurance team to manage their requirements and test cases in SpiraTeam, execute test runs in SpiraTest, and then have the new incidents generated during the run be automatically loaded into OnTime.
Once the incidents are loaded into OnTime as defects, the development team can then manage the lifecycle of these defects in OnTime, and have the status changes in OnTime be reflected back in SpiraTeam.
Note: This section refers to integrating with the older SOAP API that was available in AxoSoft OnTime 11 (2010). This API was removed from AxoSoft OnTime in 2012 and we recommend you use the AxoSoft OnTime 14 Plugin instead that is described in section 10 above if you are using OnTime 14 or later.
\u25ba Note: The OnTime11 Plug-In is Not Available on the Inflectra Cloud-Based DataSync Service.
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-OnTime-11/#configuring-the-integration-service","title":"Configuring the Integration Service","text":"This section outlines how to configure the integration service to export incidents into OnTime and pick up subsequent status changes in OnTime and have them update SpiraTeam. It assumes that you already have a working installation of SpiraTest, SpiraPlan or SpiraTeam v2.3 or later and a working installation of OnTime 2010 or later. If you have an earlier version of SpiraTeam, you will need to upgrade to at least v2.3 before trying to integrate with OnTime.
The steps that need to be performed to configure integration with OnTime are as follows:
Install and configure the OnTime SDK if you have not already done so
Download the OnTime11 Data-Sync plug-in for SpiraTeam from our website
Setup the plug-in in SpiraTeam to point to the correct instance of OnTime
Configure the data field mappings between SpiraTeam and OnTime
Start the service and verify data transfer
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-OnTime-11/#install-and-configure-the-ontime-sdk","title":"Install and Configure the OnTime SDK","text":"The API for accessing OnTime remotely is a separate download from the main OnTime application, and should be downloaded and installed from AxoSoft's website onto your OnTime server. It typically adds a separate IIS virtual directory (e.g. http://servername/OnTimeSdk) to the existing OnTime virtual directory (e.g. http://servername/OnTime). Please make sure you have both virtual directories listed in IIS before continuing.
Once you have installed the OnTime SDK, you need to navigate to the location that it was installed (typically C:\\inetpub\\wwwroot\\OnTimeSdk) and open up the Web.Config file in Notepad and locate the \"appSettings\" part of the file:
<appSettings> <add key=\"ConnectionString\" value=\"server=SERVER;database=OnTime;uid=USER;pwd=PASSWORD;\"/>\n<add key=\"SecurityToken\" value=\"{66ACD352-16C0-4485-8498-8C461BE7CE44}\"/> <add key=\"WebServicesUser\" value=\"1\"/> <add key=\"EnableDataCache\" value=\"False\"/> </appSettings>\nYou need to make sure that you fill out the ConnectionString that points to the Microsoft SQL Server database that OnTime is connecting to. Also for the SecurityToken field you need to generate a new GUID and add it to the file. This security token will be used by SpiraTeam when it connects to the OnTime API. Once you have made the necessary changes, save the file.
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-OnTime-11/#download-the-ontime-plug-in","title":"Download the OnTime Plug-In","text":"Go to the Inflectra website and open up the page that lists the various downloads available for SpiraTeam (http://www.inflectra.com/SpiraTeam/Downloads.aspx). Listed on this page will be the OnTime11 Plug-In for SpiraTeam. Right-click on this link and save the Zip compressed folder to the hard-drive of the server where SpiraTeam is installed.
Open up the compressed folder and extract the OnTimeDataSync.dll file and place it in the C:\\Program Files\\SpiraTeam\\Bin folder (it may be SpiraTest or SpiraPlan depending on which product you're running). This folder should already contain the DataSyncService.exe and DataSyncService.exe.config files that are the primary files used for managing the data synchronization between SpiraTeam and other systems.
If you do not have an on-premise installation of SpiraTeam, but instead are using a hosted subscription provided by Inflectra (or a third party company) you will not have access to the DataSyncService background service. In such situations, you should use the Desktop DataSync application instead. This application is described in Appendix 1 and can be used instead of the server-based DataSyncService.
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-OnTime-11/#configuring-the-service","title":"Configuring the Service","text":"To configure the integration service, please open up the DataSyncService.exe.config file located in C:\\Program Files\\SpiraTeam\\Bin with a text editor such as Notepad. Once open, it should look like:
<configuration>\n<configSections>\n<sectionGroup name=\"applicationSettings\" type=\"System.Configuration.ApplicationSettingsGroup, System,\nVersion=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089\">\n<section name=\"Inflectra.SpiraTest.DataSyncService.Properties.Settings\" type=\"System.Configuration.ClientSettingsSection, System,\nVersion=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089\" requirePermission=\"false\" />\n</sectionGroup>\n</configSections>\n<applicationSettings>\n<Inflectra.SpiraTest.DataSyncService.Properties.Settings>\n<setting name=\"PollingInterval\" serializeAs=\"String\">\n<value>600000</value>\n</setting>\n<setting name=\"WebServiceUrl\" serializeAs=\"String\">\n<value>http://localhost/SpiraTeam</value>\n</setting>\n<setting name=\"Login\" serializeAs=\"String\">\n<value>fredbloggs</value>\n</setting>\n<setting name=\"Password\" serializeAs=\"String\">\n<value>fredbloggs</value>\n</setting>\n<setting name=\"EventLogSource\" serializeAs=\"String\">\n<value>SpiraTeam Data Sync Service</value>\n</setting>\n<setting name=\"TraceLogging\" serializeAs=\"String\">\n<value>False</value>\n</setting>\n</Inflectra.SpiraTest.DataSyncService.Properties.Settings>\n</applicationSettings>\n</configuration>\nThe sections that need to be verified and possibly changed are marked in yellow above. You need to check the following information:
The polling interval allows you to specify how frequently the data-synchronization service will ask SpiraTeam and the external system for new data updates. The value is specified in milliseconds and we recommend a value no smaller than 5 minutes (i.e. 300,000ms). The larger the number, the longer it will take for data to be synchronized, but the lower the network and server overhead.
The base URL to your instance SpiraTeam. It is typically of the form http://<server name>/SpiraTeam. Make sure that when you enter this URL on a browser on the server itself, the application login page appears.
A valid login name and password to your instance of SpiraTeam. This user needs to be a member of the project(s) that will be synchronized with OnTime and needs to have at least Incident create/modify/view permissions and Release create/modify/view permissions in these projects.
Once you have made these changes, save the file and proceed to the next stage.
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-OnTime-11/#configuring-the-plug-in","title":"Configuring the Plug-In","text":"The next step is to configure the plug-in within SpiraTeam so that the system knows how to access the OnTime server. To start the configuration, please open up SpiraTeam in a web browser, log in using a valid account that has System-Administration level privileges and click on the System > Data Synchronization administration option from the left-hand navigation:
This screen lists all the plug-ins already configured in the system. Depending on whether you chose the option to include sample data in your installation or not, you will see either an empty screen or a list of sample data-synchronization plug-ins.
If you already see an entry for OnTimeDataSync you should click on its \"Edit\" link. If you don't see such an entry in the list, please click on the [Add] button instead. In either case you will be taken to the following screen where you can enter or modify the OnTime Data-Synchronization plug-in:
You need to fill out the following fields for the OnTime Plug-in to operate correctly:
Name -- this needs to be set to OnTimeDataSync. This needs to match the name of the plug-in DLL assembly that was copied into the C:\\Program Files\\SpiraTeam\\Bin folder (minus the .dll file extension). If you renamed the OnTimeDataSync.dll file for any reason, then you need to change the name here to match.
Description -- this should be set to a description of the plug-in. This is an optional field that is used for documentation purposes and is not actually used by the system.
Connection Info -- this should the full URL to the OnTime SDK. This is typically something like: http://<OnTime server name>/OnTimeSdk. You may need to check in the IIS Management Console of the OnTime server to verify the virtual directory name.
Login -- this should be set to the GUID that you specified in the Web.Config file in step 13.1.1 above.
Password -- this should be left blank as it's not used by the OnTime data-sync plug-in.
Time Offset -- normally this should be set to zero, but if you find that defects being changed in OnTime are not being updated in SpiraTeam, try increasing the value as this will tell the data-synchronization plug-in to add on the time offset (in hours) when comparing date-time stamps. Also if your OnTime installation is running on a server set to a different time-zone, then you should add in the number of hours difference between the servers' time-zones here.
Auto-Map Users -- this is not currently used by the OnTime data-sync plug-in and can be ignored.
Custom 01 -- 05 -- these are not currently used by the OnTime data-sync plug-in and can be left blank.
Next, you need to configure the data mapping between SpiraTeam and OnTime. This allows the various projects, users, releases, incident statuses, priorities, severities and custom property values used in the two applications to be related to each other. This is important, as without a correct mapping, there is no way for the integration service to know that an \"Open\" incident in SpiraTeam is the same as an \"Open\" defect in OnTime (for example).
The following mapping information needs to be setup in SpiraTeam:
The mapping of the project identifiers for the projects that need to be synchronized
The mapping of users in the system
The mapping of releases in the system
The mapping of the various standard fields in the system
The mapping of the various custom properties in the system
Each of these is explained in turn below:
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-OnTime-11/#configuring-the-project-mapping","title":"Configuring the Project Mapping","text":"From the data synchronization administration page, you need to click on the \"View Project Mappings\" hyperlink next to the OnTime plug-in name. This will take you to the data-mapping home page for the currently selected project:
If the project name does not match the name of the project you want to configure the data-mapping for, click on the \"(Change Project)\" hyperlink to change the current project.
To enable this project for data-synchronization with OnTime, you need to enter:
External Key -- This should be set to the numeric ID of the project token in OnTime. You can find this in OnTime by selecting the project in the project explorer inside OnTime and then clicking the Edit icon. This brings up the project details screen:
The ID of the project is the value listed in the browser URL directly after the \"ProjectId=\" text. In the example above, the project ID would be 3.
Active Flag -- Set this to 'Yes' so that SpiraTeam knows that you want to synchronize data for this project. Once the project has been completed, setting the value to \"No\" will stop data synchronization, reducing network utilization.
Click [Update] to confirm these settings. Once you have enabled the project for data-synchronization, you can now enter the other data mapping values outlined below.
Note: Once you have successfully configured the project, when creating a new project, you should choose the option to \"Create Project from Existing Project\" rather than \"Use Default Template\" so that all the project mappings get copied across to the new project.
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-OnTime-11/#configuring-the-user-mapping","title":"Configuring the User Mapping","text":"To configure the mapping of users in the two systems, you need to go to Administration > Users > View Edit Users, which will bring up the list of users in the system. Then click on the \"Edit\" button for a particular user that will be editing defects in OnTime:
You will notice that below the Active flag for the user is a list of all the configured data-synchronization plug-ins. In the text box next to the OnTime Data-Sync plug-in you need to enter the Login ID for this username in OnTime. This will allow the data-synchronization plug-in to know which user in SpiraTeam match which equivalent user in OnTime. Click [Update] once you've entered the appropriate login name. You should now repeat for the other users who will be active in both systems.
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-OnTime-11/#configuring-the-release-mapping","title":"Configuring the Release Mapping","text":"When the data-synchronization service runs, when it comes across a release/iteration in SpiraTeam that it has not seen before, it will create a corresponding Release in OnTime. Similarly if it comes across a new Release in OnTime that it has not seen before, it will create a new Release in SpiraTeam. Therefore when using both systems together, it is recommended that you only enter new Releases in one system and let the data-synchronization service add them to the other system.
However you may start out with the situation where you already have pre-existing Releases in both systems that you need to associate in the data-mapping. If you don't do this, you may find that duplicates get created when you first enable the data-synchronization service. Therefore for any Releases/Iterations that already exist in BOTH systems please navigate to Planning > Releases and click on the Release/Iteration in question. Make sure you have the 'Overview' tab visible and expand the \"Details\" section of the release/iteration:
In addition to the standard fields and custom properties configured for Releases, you will see an additional text property called \"OnTimeDataSync ID\" that is used to store the mapped external identifier for the equivalent Version in OnTime. You need to locate the ID of the equivalent version in OnTime, enter it into this text-box and click [Save]. You should now repeat for all the other pre-existing releases.
Note: The OnTime ID can be found by looking at the URL inside OnTime when choosing to Edit the release in question. The URL will include the section: ReleaseId=X where X is the numeric ID of the version inside OnTime:
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-OnTime-11/#configuring-the-standard-field-mapping","title":"Configuring the Standard Field Mapping","text":"Now that the projects, user and releases have been mapped correctly, we need to configure the standard incident fields. To do this, go to Administration > System > Data Synchronization and click on the \"View Project Mappings\" for the OnTimeDataSync plug-in entry:
From this screen, you need to click on Priority, Severity and Status in turn to configure their values (OnTime doesn't support different defect types):
a) Incident Status
Click on the \"Status\" hyperlink under Incident Standard Fields to bring up the Incident status mapping configuration screen:
The table lists each of the incident statuses available in SpiraTeam and provides you with the ability to enter the matching OnTime defect status names for each one. You can map multiple SpiraTeam fields to the same OnTime fields (e.g. New and Open in SpiraTeam are both equivalent to Open in OnTime), in which case only one of the two values can be listed as Primary = Yes as that's the value that's used on the reverse synchronization (from OnTime > SpiraTeam).
We recommend that you always point the New and Open statuses inside SpiraTeam to point to the \"Open\" status inside OnTime and make Open in SpiraTeam the Primary status of the two. This is recommended so that as new incidents in SpiraTeam get synched over to OnTime, they will get switched to the Open status in OnTime which will then be synched back to \"Open\" in SpiraTeam. That way you'll be able to see at a glance which incidents have been synched with OnTime and those that haven't.
Note: The OnTime external key needs to exactly match the display name of the status inside OnTime. If you change the name of a status in OnTime, you'll need to update the value in the data-mapping configuration as well.
b) Incident Priority
Click on the \"Priority\" hyperlink under Incident Standard Fields to bring up the Incident Priority mapping configuration screen:
The table lists each of the incident priorities available in SpiraTeam and provides you with the ability to enter the matching OnTime priority name for each one. You can map multiple SpiraTeam fields to the same OnTime fields, in which case only one of the two values can be listed as Primary = Yes as that's the value that's used on the reverse synchronization (from OnTime > SpiraTeam).
Note: The OnTime external key needs to exactly match the display name of the priority inside OnTime. If you change the name of a priority in OnTime, you'll need to update the value in the data-mapping configuration as well.
c) Incident Severity
Click on the \"Severity\" hyperlink under Incident Standard Fields to bring up the Incident severity mapping configuration screen:
The table lists each of the incident severities available in SpiraTeam and provides you with the ability to enter the matching OnTime severity name for each one. You can map multiple SpiraTeam fields to the same OnTime fields, in which case only one of the two values can be listed as Primary = Yes as that's the value that's used on the reverse synchronization (from OnTime > SpiraTeam).
Note: The OnTime external key needs to exactly match the display name of the severity inside OnTime. If you change the name of a severity in OnTime, you'll need to update the value in the data-mapping configuration as well.
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-OnTime-11/#configuring-the-custom-property-mapping","title":"Configuring the Custom Property Mapping","text":"Now that the various SpiraTeam standard fields have been mapped correctly, we need to configure the custom property mappings. This is used for both custom properties in SpiraTeam that map to custom fields in OnTime and also for custom properties in SpiraTeam that are used to map to standard fields in OnTime (currently only Replication Procedures) that don't exist in SpiraTeam.
From the View/Edit Project Data Mapping screen, you need to click on the name of the Incident Custom Property that you want to add data-mapping information for. We will consider the three different types of mapping that you might want to enter:
a) Text Custom Properties
Click on the hyperlink of the text custom property under Incident Custom Properties to bring up the custom property mapping configuration screen. For text custom properties there will be no values listed in the lower half of the screen.
You need to lookup the display name of the custom field in OnTime that matches this custom property in SpiraTeam. Once you have entered the id of the custom field, click [Update].
b) List Custom Properties
Click on the hyperlink of the list custom property under Incident Custom Properties to bring up the custom property mapping configuration screen. For list custom properties there will be a textbox for both the custom field itself and a mapping table for each of the custom property values that need to be mapped:
First you need to lookup the display name of the custom field in OnTime that matches this custom property in SpiraTeam. This should be entered in the 'External Key' field below the name of the custom property.
Next for each of the Property Values in the table (in the lower half of the page) you need to enter the full name of the custom field value as specified in OnTime.
c) OnTime's Replication Procedures Field
If you want new defects in OnTime to be loaded with the \"replication prodcedures\" standard text field populated, then you will need to fill out this section. You first need to create an incident custom property in SpiraTeam of type 'TEXT' that will be used to store the environment description within SpiraTeam.
Then click on the hyperlink of this new list custom property under Incident Custom Properties to bring up the custom property mapping configuration screen:
All you need to do on this screen is enter the word \"ReplicationProcedures\" in the External Key textbox and the data-sync plug-in will know that this custom property is mapped to the built-in Replication Procedures field in OnTime. Note that there is no space between the words Replication and Procedures!!
Once you have updated the various mapping sections, you are now ready to start the service.
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-OnTime-11/#enabling-the-data-synchronization","title":"Enabling the Data-Synchronization","text":""},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-OnTime-11/#starting-the-service","title":"Starting the Service","text":"When SpiraTeam is installed, a Windows Service -- SpiraTeam Data Sync Service -- is installed along with the web application. However to avoid wasting system resources, this service is initially set to run manually. To ensure continued synchronization of SpiraTeam with OnTime, we recommend starting the service and setting its startup-type to Automatic.
To make these changes, open up the Windows Control Panel, click on the \"Administrative Tools\" link, and then choose the Services option. This will bring up the Windows Service control panel:
Click on the 'SpiraTeam Data Sync Service' entry and click on the link to start the service. Then right-click the service entry and choose the option to set the startup type to 'Automatic'. This will ensure that synchronization continues between SpiraTeam and OnTime after a reboot of the server.
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-OnTime-11/#using-spirateam-with-ontime","title":"Using SpiraTeam with OnTime","text":"Now that the integration service has been configured and the service started, initially any incidents created in SpiraTeam for the specified projects will be imported into OnTime.
At this point we recommend opening the Windows Event Viewer and choosing the Application Log. In this log any error messages raised by the SpiraTeam Data Sync Service will be displayed. If you see any error messages at this point, we recommend immediately stopping the SpiraTeam service and checking the various mapping entries. If you cannot see any defects with the mapping information, we recommend sending a copy of the event log message(s) to Inflectra customer services (support@inflectra.com) who will help you troubleshoot the problem.
To use SpiraTeam with OnTime on an ongoing basis, we recommend the following general processes be followed:
When running tests in SpiraTeam, defects found should be logged through the 'Add Incident' option as normal.
Once an incident has been created during the running of the test, it will now be populated across into OnTime as a defect. It will be populated with the information captured in SpiraTeam.
At this point, the incident should not be acted upon inside SpiraTeam, and all data changes to the defect should be made inside OnTime. To enforce this, you can modify the workflows set up in SpiraTeam so that the various fields are marked as inactive for all the incident statuses other than the \"New\" status. This will allow someone to submit an incident in SpiraTeam, but will prevent them making changes in conflict with OnTime after that point.
As the defect progresses through the OnTime workflow, changes to the status, priority, severity, and resolution will be updated automatically in SpiraTeam. In essence, SpiraTeam acts as a read-only viewer of these incidents.
You are now able to perform test coverage and incident reporting inside SpiraTeam using the test cases managed by SpiraTeam and the incidents managed on behalf of SpiraTeam inside OnTime.
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-Salesforce.com/","title":"Using Spira with Salesforce.com","text":"Salesforce objects are a highly customizable system that can be synced with SpiraTest, SpiraTeam or SpiraPlan (SpiraPlan from here on). This integration lets you carry out:
Set up data synchronization
STOP! Please make sure you have first read the instructions to set up the data sync before proceeding!
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-Salesforce.com/#configuring-salesforce","title":"Configuring Salesforce","text":"Before integrating with SpiraPlan, you need to properly configure Salesforce's Rest API service. To do this, create a dedicated \"Connected App\" in your Salesforce application, as described in these instructions.
Info
In the Salesforce Connected App, the property \u201cIP Relaxation\u201d MUST BE defined as \u201cRelax IP restrictions\u201d, otherwise there may be connection problems.
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-Salesforce.com/#configuring-the-integration-service","title":"Configuring the Integration Service","text":"This section outlines how to set up the integration service between Salesforce and SpiraPlan. It assumes you already have:
Inside SpiraPlan, go to the Administration page and navigate to Integration > Data Synchronization. Check if you see a plug-in called SalesforceDataSync as shown below:
What do if the plug-in is not there
If you don't see the plug-in in the list, click the \"\"Add\" button at the top of the page. This opens the generic Data Sync plug-in details page. This is not yet customized to help you more easily set up the data sync. We recommend, adding just enough information now to create the plug-in. Then edit the plug-in after its made to complete the process.
To start, fill in the following fields:
Now click \"Add\" to save the plug-in and return you to the list of plug-ins. Now follow the instructions below.
With the plug-in place, click on its \"edit\" button to open its detailed settings page.
Fill out this configuration page as follows:
The remaining two fields store information about the Salesforce objects to sync, and the field in each object that stores project information. These fields are used to sync only relevant items to the right Spira product. For instance, you have a field called \"Project\" and this can be set to either Project1 or Project2, depending on what specific Project that particular record is part of. In Spira you may sync records set to Project1 to ProductA and sync records set to Project2 to ProductB.
Enter the name of the object, then a comma, then the name of the project field of the object - if your object name or field name have spaces in them, you must replace them with a _. For example if you have the object \"My Requirement Object\", which uses a field called \"Project Name Field\" you must enter \"My_Requirement_Object,Project_Name_Field\". In other words:
Click the \"Save\" button.
NOTE: Leave any field called \"(Not Used)\" blank.
Important gotchas to be aware of
We assume you have not changed the default API names automatically generated by Salesforce to Objects and Fields. If you have customized these names, you must use these customized names instead. You can check the API names of objects and fields in Salesforce, by going to Setup > Object Manager > [Your Object] > Details and Fields & Relationships.
If your Project Field in Salesforce is a pick-up list that points to another Salesforce object (called \"Reference type\" or \"Lookup type\"), you must add a text field containing the name of the specific value from that object (i.e. the actual project name) you are pointing to. You must use this in Spira's \"Incidents Object\" / \"Requirements Object\" fields for the data sync to work.
Salesforce automatically adds the \"__c\" characters after a custom object/field name. You should not add that yourself to the end of the object/field names.
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-Salesforce.com/#configuring-project-mappings","title":"Configuring Project Mappings","text":"Now that you have configured how the Salesforce data-sync works at the system level, you now need to configure the plug-in for each specific SpiraPlan product.
Click on the \"View Project Mappings\" dropdown for the Salesforce Data Sync. Select your product, then click the arrow to the right. This takes you to the Product Admin Salesforce Data Sync screen. You need to fill out the following fields before the plug-in is ready:
A brief note about field syncing in Salesforce: The sheer customizability of Salesforce necessarily means we have had to make some assumptions. Specific field names of objects are mapped to their counterparts in SpiraPlan based on the exact names (case sensitive) in the list below. Fields with these exact names will be synced over to SpiraPlan. Other fields (unless linked to a custom field in SpiraPlan) will not be synced.
Warning
Note: Do not forget to map the standard fields Priority, Importance, Severity, Type and Status in the \"Standard Field Data Mapping\" menu of the Data Sync configuration. Otherwise, they won't be synced.
Note 2: In case your Salesforce instance does not allow creating/updating the \"Name\" field of the record, the add-on will try to update/create the field \"Title\" instead. For that, make sure you have this field configured in your instance.
Note 3: If you would like to see the Spira Incident ID in your Salesforce instance, just add the \"SpiraPlanID__c\" field in your corresponding object in Salesforce.
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-Salesforce.com/#configuring-the-incidentrequirement-status-mappings","title":"Configuring the Incident/Requirement Status Mappings","text":"If you don't have a status equivalent in your table, you can ignore this section.
Click the \"Status\" button within the \"Incident\" section to map the Incident statuses from SalesForce to SpiraPlan. This tells the Salesforce Data Sync plug-in what the equivalent status is in Salesforce for an incident status in SpiraPlan.
If you are syncing Requirements, repeat this exact process for Requirement statuses, by clicking the Requirement > Status button.
You must map every status in SpiraPlan to Salesforce. Descriptions of the field are below:
If you don't have a priority equivalent in your Salesforce object, you can ignore this section.
Click the Priority button within the Incident section to map incident priorities. This will tell the Salesforce Data Sync plug-in which priorities in Salesforce map to those in SpiraPlan. The process is identical for Requirement importance, so repeat these steps with Requirement > Importance instead if you are also/only syncing requirements.
You must map every priority/importance in SpiraPlan to Salesforce. Descriptions of the field are below:
This section assumes the custom properties in SpiraPlan and Salesforce are of the same type (integer -> integer, text -> text, etc.). Custom property syncing will not work otherwise. This applies to both requirement and incident custom properties.
Click on a custom property mapping for a property you would like to sync. For the \"External Key\" put the exact Salesforce field name.
If your custom property is a single-select list, for each custom value, put in the \"Label\" of the option in Salesforce (the text you see in the Salesforce main application). An example of mapping a single-select list is below:
If you have a multi-select list in SpiraPlan repeat the same steps as for a single-select, except instead of putting the Salesforce \"Label\" in the external key, put the Salesforce \"Value\" instead. You should have something like this:
If, in Salesforce, you have list dropdown that links to another Salesforce object then the value you enter in SpiraPlan must be the string for the ID of the object, not the name. For example, if your dropdown says \"Release 1\" in Salesforce, and it has an ID of \"6fghincx8dx\", in SpiraPlan enter \"6fghincx8dx\" into the appropriate field.
Warning
Make sure the values provided for \"External Key\" meet the conditions required by Salesforce. For instance, \"false/true\" for boolean values, matching values for lists, etc. If the artifact synchronization fails because of that, you will see an error in the System log like this:
Error when creating/updating artifact: [{\\\"message\\\":\\\"GXP: bad value for BOOL field...\nIf you have set the \"Auto-Map Users\" option set to yes in the Salesforce plugin, please skip this section.
To configure the mapping of users in the two systems, you need to go to Administration > Users > View Edit Users, which will bring up the list of users in the system. Click on the [Edit] button for a particular user that will be editing records in Salesforce:
Click on the 'Data Mapping' tab to list all the configured data-synchronization plug-ins for this user. In the text box labeled \"Salesforce Data Sync ID,\" enter the first and last name of the user as set in Salesforce. This will allow the data-synchronization plug-in to know which user in SpiraPlan matches an equivalent user in Salesforce. Click [Save] once you've entered the appropriate login name.
Repeat for other users who will be active in both systems.
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-Salesforce.com/#attachments-synchronization","title":"Attachments synchronization","text":"If an object in Salesforce has the \"Notes & Attachments\" section, the data sync will sync all files to SpiraPlan and any attachments on SpiraPlan Incidents will sync to Salesforce. If a new version of a pre-existing file is uploaded in Salesforce, this will be uploaded as a new version to the matching SpiraPlan attachment (new versions of attachments to SpiraPlan Incidents will be uploaded as new versions in Salesforce). Finally, if an attachment is deleted from a record in Salesforce, the file will be removed from the equivalent artifact in SpiraPlan.
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-Salesforce.com/#comments-synchronization","title":"Comments synchronization","text":"If an object in Salesforce has the \"Feed Post & Comments component\" configured, the comments posted on it will be synced to SpiraPlan and vice-versa.
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-Salesforce.com/#using-the-data-synchronization","title":"Using the Data Synchronization","text":"Once the above steps have been correctly carried out, the plug-in should start working. Start your Data Sync service and verify that records in Salesforce appear inside SpiraPlan as either incidents or requirements in the relevant product(s). Note that the Data Sync service is not running constantly, so it may take some time for changes to materialize.
Congratulations, you have just integrated your SpiraPlan instance with Salesforce!
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-ServiceNow/","title":"Using Spira with ServiceNow","text":"ServiceNow tables are a highly customizable system that can be synced with SpiraTest, SpiraTeam or SpiraPlan (SpiraPlan from here on). This integration service enables two-way syncing of new incidents and requirements with any table in ServiceNow and syncing of updates from ServiceNow into SpiraPlan. Attachments will only be synced with creation.
Set up data synchronization
STOP! Please make sure you have first read the instructions to set up the data sync before proceeding!
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-ServiceNow/#configuring-the-integration-service","title":"Configuring the Integration Service","text":"This section outlines how to set up the integration service between ServiceNow and SpiraPlan. It assumes that you already have a working installation of SpiraPlan and appropriate ServiceNow tables. To setup the service, you must be logged into SpiraPlan as a user with System-Administrator level privileges.
Inside SpiraPlan, go to the Administration page and navigate to Integration > Data Synchronization. Check if you see a plug-in called ServiceNowDataSync, as shown below:
What do if the plug-in is not there
If you don't see the plug-in in the list, click the \"\"Add\" button at the top of the page. This opens the generic Data Sync plug-in details page. This is not yet customized to help you more easily set up the data sync. We recommend, adding just enough information now to create the plug-in. Then edit the plug-in after its made to complete the process.
To start, fill in the following fields:
Now click \"Add\" to save the plug-in and return you to the list of plug-ins. Now follow the instructions below.
With the plug-in place, click on its \"edit\" button to open its detailed settings page.
You need to fill out the following fields for the ServiceNow Data Sync plugin to work properly:
Click the \"Save\" button.
NOTE: Leave any field called \"(Not Used)\" blank.
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-ServiceNow/#configuring-project-mappings","title":"Configuring Project Mappings","text":"For this step, please ensure that you are in a SpiraPlan project you would like to sync with ServiceNow. For this example, the project is called \"ServiceNowDataSync Test.\"
Click on the \"View Project Mappings\" button for the ServiceNow Data Sync. You need to fill out the following fields to sync correctly:
The spira_product example above is a 'choice' type with the choices shown below:
Type in the 'Label' field of the choice, not the 'Value.'
A brief note about field syncing in ServiceNow: The sheer configurability of ServiceNow meant some assumptions were made in the designing of this data sync. Specific column names are mapped to their counterparts in SpiraPlan based on the list below. If a field is not present in ServiceNow, it will simply not be synced.
SpiraPlan Field ServiceNow Column Name name / short_description (both will work) Description description Priority / Importance priority Author / Detected By opened_by Owner assigned_to Status state Incident Severity severity Type type"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-ServiceNow/#configuring-the-incidentrequirement-status-mappings","title":"Configuring the Incident/Requirement Status Mappings","text":"Now click the \"Status\" button within the \"Incident\" section to map the Incident statuses together. The purpose of this is so that the ServiceNow Data Sync plug-in knows what the equivalent status is in ServiceNow for an incident status in SpiraPlan. The process is identical for Requirement statuses, so repeat these steps with Requirement > Status instead if you are also/only syncing requirements.
If you don't have a status equivalent in your table, you can ignore this section.
You must map every status in SpiraPlan to ServiceNow. Descriptions of the field are below:
Here are the corresponding statuses in ServiceNow
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-ServiceNow/#configuring-the-incidentrequirement-type-mappings","title":"Configuring the Incident/Requirement Type Mappings","text":"Click the \"Type\" button for the relevant artifact to map the Incident or Requirent types between SpiraPlan and ServiceNow together. The process is identical to the mappings described previously, so repeat these steps with Incident and Requirement Types if you are syncing them.
You must map every type in SpiraPlan to ServiceNow. Descriptions of the field are below:
Now click the \"Priority\" button within the \"Incident\" section to map incident priorities. This will tell the ServiceNow Data Sync plug-in which priorities in ServiceNow map to those in SpiraPlan. The process is identical for Requirement importance, so repeat these steps with Requirement > Importance instead if you are also/only syncing requirements.
If you don't have a priority equivalent in your table, you can ignore this section.
You must map every priority/importance in SpiraPlan to ServiceNow. Descriptions of the field are below:
Here are the corresponding priorities in ServiceNow:
You can use the same logic to configure Incident Severity mappings.
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-ServiceNow/#cloning-servicenow-fields","title":"Cloning ServiceNow Fields","text":"Due to some of the assumptions made in the creation of this integration, it is often necessary to create a hidden compatibility layer between the fields you use in your ServiceNow table and those recognized by the SpiraPlan data sync. This section will lay out how to create 'hidden' fields that will be kept in sync with those in SpiraPlan.
A brief discussion about the requirements for this to work
These steps will show how to store description in complete notes when Spira creates an artifact in ServiceNow
Add a Filter Condition such that the field you're cloning with the Spira field is empty:
Under Actions, where it says \"---choose field --\" set it to the field you would like to be populated [\"Complete Notes\" in this example]
These steps will show you how to store complete notes in description when the user updates complete notes
These steps will show you how to store complete notes in description when the user creates a new artifact in ServiceNow
Add a Filter Condition such that the Spira field is empty:
Under Actions, where it says \"---choose field---\" set it to the Spira field you would like to be synced [\"Description\" in this example]
This section assumes the custom properties in SpiraPlan and ServiceNow are of the same type (integer -> integer, SingleSelect -> SingleSelect, etc.) Custom property syncing will not work otherwise. This applies to both requirement and incident custom properties.
Click on a custom property mapping for a property you would like to sync. For the \"External Key\" right below the \"Name\" field put the column name (not the column label), so for the Operating System field in ServiceNow, you would put in \"operating_system\" No extra work is required for user (sys_user references in ServiceNow), text, integer, or date fields.
If your custom property is a single-select list (choice in ServiceNow), for each custom value, put in the \"Label\" (not Value) of the choice in ServiceNow. So your single-select should look similar:
If you have a multi-select in SpiraPlan (List in ServiceNow), repeat the same steps as for a single-select, except instead putting \"Label\" in the external key, put \"Value\" instead. You should have something like this:
For these ServiceNow choices:
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-ServiceNow/#configuring-the-user-mapping","title":"Configuring the User Mapping","text":"If you have set the \"Auto-Map Users\" option set to yes in the ServiceNow plugin, you can skip this section completely.
To configure the mapping of users in the two systems, you need to go to Administration > Users > View Edit Users, which will bring up the list of users in the system. Then click on the \"Edit\" button for a particular user that will be editing issues in ServiceNow:
Click on the 'Data Mapping' tab to list all the configured data-synchronization plug-ins for this user. In the text box labeled \"ServiceNow Data Sync ID,\" you need to enter the first and last name of the user in ServiceNow. This will allow the data-synchronization plug-in to know which user in SpiraPlan matches with an equivalent user in ServiceNow. Click [Save] once you've entered the appropriate login name. You should now repeat for the other users who will be active in both systems.
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-ServiceNow/#using-the-data-synchronization","title":"Using the Data Synchronization","text":"Assuming everything was done correctly, the plug-in should start working. Start your Data Sync service and verify that issues in ServiceNow appear inside SpiraPlan. Note that the Data Sync service is not running constantly, so it may take some time for changes to materialize.
Congratulations, you have just integrated your SpiraPlan instance with ServiceNow!
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-VersionOne/","title":"Using Spira with VersionOne","text":"This section outlines how to use SpiraTest, SpiraPlan or SpiraTeam (hereafter referred to as SpiraTeam) in conjunction with the Version One (V1) project management system from Collabnet (hereafter called V1).
The built-in integration service allows the quality assurance team to manage their requirements and test cases in SpiraTeam, execute test runs in SpiraTeam, and then have the new incidents generated during the run be automatically loaded into V1 as new defects. In addition, user stories in V1 will be automatically added into SpiraTeam as new requirements that you can write test plans for.
Once the incidents are loaded into V1 as defects, the development team can then manage the lifecycle of these defects in V1, and have the status changes in V1 be reflected back in SpiraTeam.
Set up data synchronization
STOP! Please make sure you have first read the instructions to set up the data sync before proceeding!
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-VersionOne/#configuring-the-plug-in","title":"Configuring the Plug-In","text":"This section outlines how to configure the integration service to connect to V1. It assumes that you already have a working installation of SpiraTeam v5.0 or later and an existing provisioned instance of V1. If you have an earlier version of SpiraTeam, you will need to upgrade to at least v5.0 before trying to integrate with V1.
The steps that need to be performed to configure integration with V1 are as follows:
Setup the plug-in in SpiraTeam to point to the correct instance of V1
Configure the data field mappings between SpiraTeam and V1
Start synchronization and verify data transfer
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-VersionOne/#configuring-the-plug-in_1","title":"Configuring the Plug-In","text":"The next step is to configure the plug-in within SpiraTeam so that the system knows how to access the V1 instance. To start the configuration, please open up SpiraTeam in a web browser, log in using a valid account that has System-Administration level privileges and click on the System > Data Synchronization administration option from the left-hand navigation:
This screen lists all the plug-ins already configured in the system. Depending on whether you chose the option to include sample data in your installation or not, you will see either an empty screen or a list of sample data-synchronization plug-ins.
If you already see an entry for VersionOneDataSync you should click on its \"Edit\" link. If you don't see such an entry in the list, please click on the [Add] button instead. In either case you will be taken to the following screen where you can enter or modify the V1 Data-Synchronization plug-in:
You need to fill out the following fields for the V1 Plug-in to operate correctly:
Name -- this needs to be set to VersionOneDataSync. This needs to match the name of the plug-in DLL assembly that was copied into the C:\\Program Files (x86)\\SpiraTeam\\Bin folder (minus the .dll file extension). If you renamed the OnTimeDataSync.dll file for any reason, then you need to change the name here to match.
Caption -- this is the display name of the V1 plugin and it can be meaningful name such as \"Version One\", \"V1\", or \"V1 Instance 1\".
Description -- this should be set to a description of the plug-in. This is an optional field that is used for documentation purposes and is not actually used by the system.
Connection Info -- this should the full URL to V1. This is typically something like: https://www1.v1host.com/CompanyName.
Login -- this should be set to the login that you use to access V1 through its web interface. If you are using a V1 Access Token instead of a login and password, please use \"accesstoken\" as the login instead.
Password -- this should be set to the password that you use to access V1 through its web interface or the API access token. If the latter, please make sure to use the login name \"accesstoken\".
Time Offset -- normally this should be set to zero, but if you find that defects being changed in V1 are not being updated in SpiraTeam, try increasing the value as this will tell the data-synchronization plug-in to add on the time offset (in hours) when comparing date-time stamps.
Auto-Map Users -- This changes the way that the plugin maps users in SpiraTeam to those in V1:
**Auto-Map = True **With this setting, all users in SpiraTeam need to have the same username as those in V1. If this is the case then you do not need to perform the user-mapping task outlined in section 12.2.2. This is a big time-saver if you can guarantee that all usernames are the same in both systems.
**Auto-Map = False **With this setting, users in SpiraTeam and V1are free to have different usernames because you specify the corresponding V1login for each user as outlined in Configuring the User Mapping.
Custom 01 -- this should be set to \"True\" if you want the plugin to log warnings about missing user mappings
Custom 02-05 -- these are not currently used by the V1 data-sync plug-in and can be left blank.
Next, you need to configure the data mapping between SpiraTeam and V1. This allows the various projects, users, releases, incident statuses, priorities, severities and custom property values used in the two applications to be related to each other. This is important, as without a correct mapping, there is no way for the integration service to know that an \"Open\" incident in SpiraTeam is the same as an \"Open\" defect in V1 (for example).
The following mapping information needs to be setup in SpiraTeam:
The mapping of the project identifiers for the projects that need to be synchronized
The mapping of users in the system
The mapping of releases in the system
The mapping of the various incident standard fields in the system
The mapping of the various requirement standard fields in the system
Each of these is explained in turn below:
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-VersionOne/#configuring-the-project-mapping","title":"Configuring the Project Mapping","text":"From the data synchronization administration page, you need to click on the \"View Project Mappings\" hyperlink next to the V1 plug-in name. This will take you to the data-mapping home page for the currently selected project:
If the project name does not match the name of the project you want to configure the data-mapping for, click on the \"(Change Project)\" hyperlink to change the current project.
To enable this project for data-synchronization with V1, you need to enter:
External Key -- This should be set to the name of the project in V1:
If you have sub-projects, you can map to one of those using the syntax: Project/SubProject
Active Flag -- Set this to 'Yes' so that SpiraTeam knows that you want to synchronize data for this project. Once the project has been completed, setting the value to \"No\" will stop data synchronization, reducing network utilization.
Click [Update] to confirm these settings. Once you have enabled the project for data-synchronization, you can now enter the other data mapping values outlined below.
Note: Once you have successfully configured the project, when creating a new project, you should choose the option to \"Create Project from Existing Project\" rather than \"Use Default Template\" so that all the project mappings get copied across to the new project.
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-VersionOne/#configuring-the-user-mapping","title":"Configuring the User Mapping","text":"(This section can be skipped if you enabled the 'AutoMap Users' option earlier).
To configure the mapping of users in the two systems, you need to go to Administration > Users > View Edit Users, which will bring up the list of users in the system. Then click on the \"Edit\" button for a particular user that will be editing defects in V1:
You will notice that in the Data Mapping tab for the user is a list of all the configured data-synchronization plug-ins. In the text box next to the V1 Data-Sync plug-in you need to enter the Login Name for this username in V1. This will allow the data-synchronization plug-in to know which user in SpiraTeam match which equivalent user in V1. Click [Update] once you've entered the appropriate login name. You should now repeat for the other users who will be active in both systems.
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-VersionOne/#configuring-the-releaseiteration-mapping","title":"Configuring the Release/Iteration Mapping","text":"When the data-synchronization service runs, when it comes across a new Release or Sprint/Timebox in V1 that it has not seen before, it will create a new Release or Iteration in SpiraTeam. Therefore, when using both systems together, it is recommended that you only enter new Releases in V1 and let the data-synchronization service add them to SpiraTeam.
To see this mapping, inside SpiraTeam, navigate to Planning > Releases and click on the Release/Iteration in question. Make sure you have the 'Overview' tab visible and expand the \"Details\" section of the release/iteration:
In addition to the standard fields and custom properties configured for Releases, you will see an additional text property called \"V1DataSync ID\" that is used to store the mapped external identifier for the equivalent Version in V1.
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-VersionOne/#configuring-the-incident-field-mapping","title":"Configuring the Incident Field Mapping","text":"Now that the projects, user and releases have been mapped correctly, we need to configure the standard incident fields. To do this, go to Administration > System > Data Synchronization and click on the \"View Project Mappings\" for the V1DataSync plug-in entry:
From this screen, you need to click on Status, Priority, Type in turn to configure their values (V1 doesn't support different defect severities):
a) Incident Status
Click on the \"Status\" hyperlink under Incident Standard Fields to bring up the Incident status mapping configuration screen:
The table lists each of the incident statuses available in SpiraTeam and provides you with the ability to enter the matching V1 defect status names for each one. You can map multiple SpiraTeam fields to the same V1 fields (e.g. New and Open in SpiraTeam are both equivalent to Future in V1), in which case only one of the two values can be listed as Primary = Yes as that's the value that's used on the reverse synchronization (from V1 > SpiraTeam).
We recommend that you always point the New and Open statuses inside SpiraTeam to point to the \"Future\" status inside V1 and make Open in SpiraTeam the Primary status of the two. This is recommended so that as new incidents in SpiraTeam get synched over to V1, they will get switched to the Future status in V1 which will then be synched back to \"Open\" in SpiraTeam. That way you'll be able to see at a glance which incidents have been synched with V1 and those that haven't.
Note: The V1 external key needs to exactly match the display name of the status inside V1. If you change the name of a status in V1, you'll need to update the value in the data-mapping configuration as well.
b) Incident Priority
Click on the \"Priority\" hyperlink under Incident Standard Fields to bring up the Incident Priority mapping configuration screen:
The table lists each of the incident priorities available in SpiraTeam and provides you with the ability to enter the matching V1 priority name for each one. You can map multiple SpiraTeam fields to the same V1 fields, in which case only one of the two values can be listed as Primary = Yes as that's the value that's used on the reverse synchronization (from V1 > SpiraTeam).
Note: The V1 external key needs to exactly match the display name of the priority inside V1. If you change the name of a priority in V1, you'll need to update the value in the data-mapping configuration as well.
c) Incident Type
Click on the \"Type\" hyperlink under Incident Standard Fields to bring up the Incident type mapping configuration screen:
The table lists each of the incident types available in SpiraTeam and provides you with the ability to enter the matching V1 defect type name for each one. You can map multiple SpiraTeam fields to the same V1 fields, in which case only one of the two values can be listed as Primary = Yes as that's the value that's used on the reverse synchronization (from V1 > SpiraTeam).
Note: The V1 external key needs to exactly match the display name of the defect type inside V1. If you change the name of a defect type in V1, you'll need to update the value in the data-mapping configuration as well.
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-VersionOne/#configuring-the-requirement-field-mapping","title":"Configuring the Requirement Field Mapping","text":"Next, we need to configure the standard requirement fields. To do this, go to Administration > System > Data Synchronization and click on the \"View Project Mappings\" for the V1DataSync plug-in entry:
From this screen, you need to click on Priority, Severity and Status in turn to configure their values (V1 doesn't support different defect types):
a) Requirement Status
Click on the \"Status\" hyperlink under Requirement Standard Fields to bring up the Requirement status mapping configuration screen:
The table lists each of the requirement statuses available in SpiraTeam and provides you with the ability to enter the matching V1 user story status names for each one. You can map multiple SpiraTeam fields to the same V1 fields (e.g. Requested and Planned in SpiraTeam are both equivalent to Future in V1), in which case only one of the two values can be listed as Primary = Yes as that's the value that's used on the reverse synchronization (from V1 > SpiraTeam).
Note: The V1 external key needs to exactly match the display name of the status inside V1. If you change the name of a status in V1, you'll need to update the value in the data-mapping configuration as well.
b) Requirement Importance
Click on the \"Importance\" hyperlink under Requirement Standard Fields to bring up the Requirement Importance mapping configuration screen:
The table lists each of the requirement importances available in SpiraTeam and provides you with the ability to enter the matching V1 user story priority name for each one. You can map multiple SpiraTeam fields to the same V1 fields, in which case only one of the two values can be listed as Primary = Yes as that's the value that's used on the reverse synchronization (from V1 > SpiraTeam).
Note: The V1 external key needs to exactly match the display name of the priority inside V1. If you change the name of a priority in V1, you'll need to update the value in the data-mapping configuration as well.
c) Requirement Type
Click on the \"Type\" hyperlink under Requirement Standard Fields to bring up the requirement type mapping configuration screen:
The table lists each of the requirement types available in SpiraTeam and provides you with the ability to enter the matching V1 user story type name for each one. You can map multiple SpiraTeam fields to the same V1 fields, in which case only one of the two values can be listed as Primary = Yes as that's the value that's used on the reverse synchronization (from V1 > SpiraTeam).
Note: The V1 external key needs to exactly match the display name of the user story type inside V1. If you change the name of a user story type in V1, you'll need to update the value in the data-mapping configuration as well.
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-VersionOne/#mapping-a-custom-property-to-the-v1-display-id","title":"Mapping a Custom Property to the V1 Display ID","text":"Version One has two unique IDs for all artifacts, a display ID (e.g. D-23232) and a physical ID (Defect:11291). Now the built in Data Sync ID in SpiraTeam will contain the physical ID of the V1 artifact.
However, if you also want to see the V1 display IDs in SpiraTeam, you can map a custom property to the special V1DisplayId external key. This can be done for requirements:
And for incidents:
Once you have updated the various mapping sections, you are now ready to use the service.
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-VersionOne/#using-spirateam-with-v1","title":"Using SpiraTeam with V1","text":"Now that the integration service has been configured and the service started, initially any incidents created in SpiraTeam for the specified projects will be imported into V1 and vice versa. In addition, any existing user stories in V1 will get added to SpiraTeam as requirements.
At this point we recommend opening the Windows Event Viewer and choosing the Application Log. In this log any error messages raised by the SpiraTeam Data Sync Service will be displayed. If you see any error messages at this point, we recommend immediately stopping the SpiraTeam service and checking the various mapping entries. If you cannot see any defects with the mapping information, we recommend sending a copy of the event log message(s) to Inflectra customer services (support@inflectra.com) who will help you troubleshoot the problem.
To use SpiraTeam with V1 on an ongoing basis, we recommend the following general processes be followed:
When running tests in SpiraTeam, defects found should be logged through the 'Add Incident' option as normal.
Developers can log new defects into either SpiraTeam or V1. In either case they will get loaded into the other system.
Once created in one of the systems and successfully replicated to the other system, the incident should not be modified again inside SpiraTeam
User stories created in V1 will get added to SpiraTeam as requirements. You can now write test cases and associate them in SpiraTeam with these requirements.
As the defect progresses through the V1 workflow, changes to the status, priority, severity, and resolution will be updated automatically in SpiraTeam. In essence, SpiraTeam acts as a read-only viewer of these incidents.
You are now able to perform test coverage and incident reporting inside SpiraTeam using the requirements and test cases managed by SpiraTeam and the incidents managed on behalf of SpiraTeam inside V1.
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-YouTrack/","title":"Using Spira with JetBrains' YouTrack","text":"This section outlines how to use SpiraTest, SpiraTeam, or SpiraPlan (hereafter referred to as SpiraPlan) with JetBrains' YouTrack (YouTrack).
YouTrack issues can now be synchronized with SpiraPlan. This integration service enables two-way syncing of SpiraPlan incidents and, if specified, tasks with YouTrack issues. Once set up, by default, all issues in a YouTrack project will sync to Incidents in SpiraPlan. You can specify certain types of issues to sync as Tasks in SpiraPlan instead if you want.
Set up data synchronization
STOP! Please make sure you have first read the instructions to set up the data sync before proceeding!
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-YouTrack/#configuring-youtrack","title":"Configuring YouTrack","text":"Before integrating with SpiraPlan, you need to configure YouTrack to allow Rest API connections. There are a few different ways to do this. However, we recommend using a permanent token for authentication requests. You can generate your own permanent tokens in your YouTrack user profile. For instructions, please refer to the YouTrack documentation.
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-YouTrack/#configuring-the-integration-service","title":"Configuring the Integration Service","text":"This section outlines how to set up the integration service between YouTrack and SpiraPlan. It assumes you already have:
To configure the integration, login to your SpiraPlan application as a system administrator. Go to System Administration > Integrations > Data Synchronization (from the admin menu). This shows a list of all available data sync plug-ins.
If you already have a plug-in called \"YouTrackDataSync\", click on its \"edit\" button, otherwise click the \"Add\" button to create a new plug-in:
Fill out this configuration page as follows:
YouTrackDataSyncYouTrack Privileges
Please make sure that the provided YouTrack userName/userToken has privileges to access projects and report, assign, modify, open and close YouTrack issues. Otherwise, the datasync is not going to work as expected.
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-YouTrack/#configuring-project-mappings","title":"Configuring Project Mappings","text":"Now that you have configured how the YouTrack data-sync works at the system level, you now need to configure the plug-in for each specific SpiraPlan product.
Click on the \"View Project Mappings\" dropdown for the YouTrack Data Sync. Select your product, then click the arrow to the right. This takes you to the Product Admin YouTrack Data Sync screen. You need to fill out the following fields before the plug-in is ready:
In the YouTrackDataSync Product Data Mapping of your SpiraPlan project, you can map the SpiraPlan standard fields for incidents and tasks to a specific field value in YouTrack. To do that, click on the stardard property under the artifact type menu you want to map:
For example, clicking on Task > Priority allows you to map each YouTrack issue priority to an equivalent in SpiraPlan:
For SpiraPlan Incidents and Tasks, you can map Priority, Status and Types.
Syncing Tasks
If you configured the data sync to import some YouTrack issues as Tasks in SpiraPlan, please make sure you match the Custom 02 fields with the Task types as described in this section.
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-YouTrack/#configuring-custom-properties","title":"Configuring Custom Properties","text":"If you have custom properties in your SpiraPlan project, you will need to map them to YouTrack. To do that, click on a custom property mapping for a property you would like to sync. For the \"External Key\" put the exact YouTrack field name. An example is provided below:
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-YouTrack/#attachments-synchronization","title":"Attachments synchronization","text":"The datasync will save as Tasks/Incidents attachments in SpiraPlan the files associated with an issue in YouTrack, as well as their files in comments.
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-YouTrack/#using-the-data-synchronization","title":"Using the Data Synchronization","text":"Once the above steps have been correctly carried out, the plug-in should start working. Start your Data Sync service and verify that records in YouTrack appear inside SpiraPlan as either incidents or tasks (optional) in the relevant product(s). Note that the Data Sync service is not running constantly, so it may take some time for changes to materialize.
Congratulations, you have just integrated your SpiraPlan instance with YouTrack!
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-ClearQuest/","title":"Using SpiraTeam with ClearQuest","text":"This section outlines how to use SpiraTest, SpiraPlan or SpiraTeam (hereafter referred to as SpiraTeam) in conjunction with the ClearQuest defect tracking system. The built-in integration service allows the quality assurance team to manage their requirements and test cases in SpiraTeam, execute test runs in SpiraTest, and then have the new incidents generated during the run be automatically loaded into ClearQuest. Once the incidents are loaded into ClearQuest as defects, the development team can then manage the lifecycle of these defects in ClearQuest, and have the status changes in ClearQuest be reflected back in SpiraTeam. In addition, any issues logged directly into ClearQuest will get imported into SpiraTeam so that they can be linked to test cases and requirements.
\u25ba Note: The ClearQuest Plug-In is Not Available on the Inflectra Cloud-Based DataSync Service.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-ClearQuest/#configuring-the-integration-service","title":"Configuring the Integration Service","text":"This section outlines how to configure the integration service to export incidents into ClearQuest and pick up subsequent status changes in ClearQuest and have them be updated in SpiraTeam. It assumes that you already have a working installation of SpiraTest, SpiraPlan or SpiraTeam (v3.0 or higher) and a working installation of IBM Rational ClearQuest 7.0 or higher.
If you have an earlier version of SpiraTeam, you will need to upgrade to at least v3.0 before trying to integrate with ClearQuest.
The steps that need to be performed to configure integration with ClearQuest are as follows:
Download the latest ClearQuest Data-Sync plug-in for SpiraTeam from our website
Setup the plug-in in SpiraTeam to point to the correct instance of ClearQuest
Configure the data field mappings between SpiraTeam and ClearQuest
Start the service and verify data transfer
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-ClearQuest/#download-the-clearquest-plug-in","title":"Download the ClearQuest Plug-In","text":"Go to the Inflectra website and open up the page that lists the various downloads available for SpiraTeam (http://www.inflectra.com/SpiraTeam/Downloads.aspx). Listed on this page will be the ClearQuest Plug-In for SpiraTeam. Right-click on this link and save the Zip compressed folder to the hard-drive of the server where SpiraTeam is installed.
Open up the compressed folder and extract the ClearQuestDataSync.dll file and place it in the C:\\Program Files\\SpiraTeam\\Bin folder (it may be SpiraTest or SpiraPlan depending on which product you're running). This folder should already contain the DataSyncService.exe and DataSyncService.exe.config files that are the primary files used for managing the data synchronization between SpiraTeam and other systems.
You will then need to install the ClearQuest client application itself onto the SpiraTeam server. This is needed because the ClearQuest plugin communicates with the ClearQuest API which is part of the ClearQuest client installation. The SpiraTeam plugin will use a single ClearQuest user license when it connects to ClearQuest.
If you do not have an on-premise installation of SpiraTeam, but instead are using a hosted subscription provided by Inflectra (or a third party company) you will not have access to the DataSyncService background service. In such situations, you should use the Desktop DataSync application instead. This application is described in Appendix 1 and can be used instead of the server-based DataSyncService.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-ClearQuest/#configuring-the-service","title":"Configuring the Service","text":"To configure the integration service, please open up the DataSyncService.exe.config file located in C:\\Program Files\\SpiraTeam\\Bin with a text editor such as Notepad. Once open, it should look like:
<?xml version=\"1.0\" encoding=\"utf-8\"?>\n<configuration>\n<configSections>\n<sectionGroup name=\"applicationSettings\" type=\"System.Configuration.ApplicationSettingsGroup, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089\" >\n<section name=\"Inflectra.SpiraTest.DataSyncService.Properties.Settings\" type=\"System.Configuration.ClientSettingsSection, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089\" requirePermission=\"false\" />\n</sectionGroup>\n</configSections>\n<applicationSettings>\n<Inflectra.SpiraTest.DataSyncService.Properties.Settings>\n<setting name=\"PollingInterval\" serializeAs=\"String\">\n<value>600000</value>\n</setting>\n<setting name=\"WebServiceUrl\" serializeAs=\"String\">\n<value>http://localhost/SpiraTeam</value>\n</setting>\n<setting name=\"Login\" serializeAs=\"String\">\n<value>fredbloggs</value>\n</setting>\n<setting name=\"Password\" serializeAs=\"String\">\n<value>fredbloggs</value>\n</setting>\n<setting name=\"EventLogSource\" serializeAs=\"String\">\n<value>SpiraTeam Data Sync Service</value>\n</setting>\n<setting name=\"TraceLogging\" serializeAs=\"String\">\n<value>False</value>\n</setting>\n</Inflectra.SpiraTest.DataSyncService.Properties.Settings>\n</applicationSettings>\n</configuration>\nThe sections that need to be verified and possibly changed are marked in yellow above. You need to check the following information:
The polling interval allows you to specify how frequently the data-synchronization service will ask SpiraTeam and the external system for new data updates. The value is specified in milliseconds and we recommend a value no smaller than 5 minutes (i.e. 300,000ms). The larger the number, the longer it will take for data to be synchronized, but the lower the network and server overhead.
The base URL to your instance SpiraTeam. It is typically of the form http://<server name>/SpiraTeam. Make sure that when you enter this URL on a browser on the server itself, the application login page appears.
A valid login name and password to your instance of SpiraTeam. This user needs to be a member of the project(s) that will be synchronized with ClearQuest and needs to have at least Incident create/modify/view permissions and Release create/modify/view permissions in these projects.
Once you have made these changes, save the file and proceed to the next stage.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-ClearQuest/#configuring-the-plug-in","title":"Configuring the Plug-In","text":"The next step is to configure the plug-in within SpiraTeam so that the system knows how to access the ClearQuest server. To start the configuration, please open up SpiraTeam in a web browser, log in using a valid account that has System-Administration level privileges and click on the System > Data Synchronization administration option from the left-hand navigation:
This screen lists all the plug-ins already configured in the system. Depending on whether you chose the option to include sample data in your installation or not, you will see either an empty screen or a list of sample data-synchronization plug-ins.
If you already see an entry for ClearQuestDataSync you should click on its \"Edit\" link. If you don't see such an entry in the list, please click on the [Add] button instead. In either case you will be taken to the following screen where you can enter or modify the ClearQuest Data-Synchronization plug-in:
You need to fill out the following fields for the ClearQuest Plug-in to operate correctly:
Name -- this needs to be set to ClearQuestDataSync. This needs to match the name of the plug-in DLL assembly that was copied into the C:\\Program Files\\SpiraTeam\\Bin folder (minus the .dll file extension). If you renamed the ClearQuestDataSync.dll file for any reason, then you need to change the name here to match.
Description -- this should be set to a description of the plug-in. This is an optional field that is used for documentation purposes and is not actually used by the system.
Connection Info -- this should the name of the ClearQuest master database. In most installations this is simply called \"MASTR\".
Login -- this should be set to a valid login for your ClearQuest installation. The login needs to have permissions to create and view defects within ClearQuest.
Password -- this should be set to the password of the login specified above.
Time Offset -- normally this should be set to zero, but if you find that issues being changed in ClearQuest are not being updated in SpiraTeam, try increasing the value as this will tell the data-synchronization plug-in to add on the time offset (in hours) when comparing date-time stamps. Also if your ClearQuest installation is running on a server set to a different time-zone, then you should add in the number of hours difference between the servers' time-zones here.
Auto-Map Users -- this is not currently used and can be ignored.
Custom 01 -- This should be set to the word \"True\" if you want to have the plugin restrict synchronization to only loading new incidents from SpiraTeam > ClearQuest and updating existing items. This is useful if you want to prevent existing issues in ClearQuest from being loaded into SpiraTeam. Leave blank if you want the plugin to synchronize normally.
Custom 02 -- Sometimes you don't want all the incidents in SpiraTeam to be added to ClearQuest. You can optionally enter a filter definition in this box to restrict the incidents that get synchronized. The filter uses the following syntax:
[Property]=[Value|*]:[Property]=[Value|*]\\
For example, to limit the incidents to only have those where List01 = 5 and Text08 = \"Hello\" and Text05 is not blank you would use:
List01=5:Text08=Hello:Text05=*
Custom 03 -- ClearQuest doesn't have a built-in Detected in Release field. If you would like to map a custom ClearQuest field to the SpiraTeam Detected in Release, simply enter in the name of the ClearQuest field here.
Custom 04 -- ClearQuest doesn't have a built-in Resolved in Release field. If you would like to map a custom ClearQuest field to the SpiraTeam Resolved in Release, simply enter in the name of the ClearQuest field here.
Custom 05 -- This is the optional \"DBset\" value, when you have installations with more than one database set. If you have a single database set you can just leave this blank.
If you enter a field name in either Custom 03 or Custom 04, you will need to also map the various releases in SpiraTeam to their corresponding equivalent field value in ClearQuest. To do that, click on Planning > Releases and choose a specific release. Then in the \"ClearQuest DataSync ID\" field under the \"Custom Properties\" tab you need to enter the name of the equivalent ClearQuest release.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-ClearQuest/#configuring-the-data-mapping","title":"Configuring the Data Mapping","text":"Next, you need to configure the data mapping between SpiraTeam and ClearQuest. This allows the various projects, users, incident statuses, priorities, severities and custom property values used in the two applications to be related to each other. This is important, as without a correct mapping, there is no way for the integration service to know that a \"New\" item in SpiraTeam is equivalent to a \"Submitted\" item in ClearQuest (for example).
The following mapping information needs to be setup in SpiraTeam:
The mapping of the project identifiers for the projects that need to be synchronized
The mapping of users in the system
The mapping of the various standard fields in the system
The mapping of the various custom properties in the system
Each of these is explained in turn below:
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-ClearQuest/#configuring-the-project-mapping","title":"Configuring the Project Mapping","text":"From the data synchronization administration page, you need to click on the \"View Project Mappings\" hyperlink next to the ClearQuest plug-in name. This will take you to the data-mapping home page for the currently selected project:
If the project name does not match the name of the project you want to configure the data-mapping for, click on the \"(Change Project)\" hyperlink to change the current project.
To enable this project for data-synchronization with ClearQuest, you need to enter:
External Key -- This should be set to the name of the project database in ClearQuest that will be mapped to the specific SpiraTeam project.
Active Flag -- Set this to 'Yes' so that SpiraTeam knows that you want to synchronize data for this project. Once the project has been completed, setting the value to \"No\" will stop data synchronization, reducing network utilization.
Click [Update] to confirm these settings. Once you have enabled the project for data-synchronization, you can now enter the other data mapping values outlined below.
Note: Once you have successfully configured the project, when creating a new project, you should choose the option to \"Create Project from Existing Project\" rather than \"Use Default Template\" so that all the project mappings get copied across to the new project.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-ClearQuest/#configuring-the-user-mapping","title":"Configuring the User Mapping","text":"To configure the mapping of users in the two systems, you need to go to Administration > Users > View Edit Users, which will bring up the list of users in the system. Then click on the \"Edit\" button for a particular user that will be editing issues in ClearQuest:
You will notice that in the Data Mapping tab for the user, there is a list of all the configured data-synchronization plug-ins. In the text box next to the ClearQuest Data-Sync plug-in you need to enter the login for this username in ClearQuest. This will allow the data-synchronization plug-in to know which user in SpiraTeam match which equivalent user in ClearQuest. Click [Update] once you've entered the appropriate login name. You should now repeat for the other users who will be active in both systems.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-ClearQuest/#configuring-the-standard-field-mapping","title":"Configuring the Standard Field Mapping","text":"Now that the projects, user and releases have been mapped correctly, we need to configure the standard incident fields. To do this, go to Administration > System > Data Synchronization and click on the \"View Project Mappings\" for the ClearQuestDataSync plug-in entry:
From this screen, you need to click on Priority, Severity and Status in turn to configure their values:
a) Incident Status
Click on the \"Status\" hyperlink under Incident Standard Fields to bring up the Incident status mapping configuration screen:
The table lists each of the incident statuses available in SpiraTeam and provides you with the ability to enter the matching ClearQuest issue status name for each one. You can map multiple SpiraTeam fields to the same ClearQuest fields (e.g. Open and Reopen in SpiraTeam are both equivalent to Opened in ClearQuest), in which case only one of the two values can be listed as Primary = Yes as that's the value that's used on the reverse synchronization (from ClearQuest > SpiraTeam).
b) Incident Priority
Click on the \"Priority\" hyperlink under Incident Standard Fields to bring up the Incident Priority mapping configuration screen:
The table lists each of the incident priorities available in SpiraTeam and provides you with the ability to enter the matching ClearQuest priority name for each one. You can map multiple SpiraTeam fields to the same ClearQuest fields, in which case only one of the two values can be listed as Primary = Yes as that's the value that's used on the reverse synchronization (from ClearQuest > SpiraTeam).
c) Incident Severity
Click on the \"Severity\" hyperlink under Incident Standard Fields to bring up the Incident severity mapping configuration screen:
The table lists each of the incident severities available in SpiraTeam and provides you with the ability to enter the matching ClearQuest severity name for each one. You can map multiple SpiraTeam fields to the same ClearQuest fields, in which case only one of the two values can be listed as Primary = Yes as that's the value that's used on the reverse synchronization (from ClearQuest > SpiraTeam).
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-ClearQuest/#configuring-the-custom-property-mapping","title":"Configuring the Custom Property Mapping","text":"Now that the various SpiraTeam standard fields have been mapped correctly, we need to configure the custom property mappings. This is used for both custom properties in SpiraTeam that map to custom fields in ClearQuest and also for custom properties in SpiraTeam that are used to map to standard fields in ClearQuest (e.g. Project, Resolution) that don't exist in SpiraTeam.
From the View/Edit Project Data Mapping screen, you need to click on the name of the Incident Custom Property that you want to add data-mapping information for. We will consider the two different types of mapping that you might want to enter:
a) Text Custom Properties
Click on the hyperlink of the text custom property under Incident Custom Properties to bring up the custom property mapping configuration screen. For text custom properties there will be no values listed in the lower half of the screen.
You need to lookup the ID of the custom field in ClearQuest that matches this custom property in SpiraTeam. Once you have entered the id of the custom field, click [Update].
Note: The ID can be found by looking at the URL inside ClearQuest when choosing to View/Edit the Custom Field. The URL will include the section: id=X where X is the numeric ID of the Custom Field inside ClearQuest.
b) List Custom Properties
Click on the hyperlink of the list custom property under Incident Custom Properties to bring up the custom property mapping configuration screen. For list custom properties there will be a textbox for both the custom field itself and a mapping table for each of the custom property values that need to be mapped:
First you need to lookup the name of the field in ClearQuest that matches this custom property in SpiraTeam. This should be entered in the 'External Key' field below the name of the custom property. The easiest way to determine this is to use the ClearQuest Designer which lets you see all the fields associated with a ClearQuest defect:
Next for each of the Property Values in the table (in the lower half of the page) you need to enter the full name of the possible field values as displayed in the ClearQuest client application.
Once you have updated the various mapping sections, you are now ready to start the service.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-ClearQuest/#enabling-the-data-synchronization","title":"Enabling the Data-Synchronization","text":""},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-ClearQuest/#starting-the-service","title":"Starting the Service","text":"When SpiraTeam is installed, a Windows Service -- SpiraTeam Data Sync Service -- is installed along with the web application. However to avoid wasting system resources, this service is initially set to run manually. To ensure continued synchronization of SpiraTeam with ClearQuest, we recommend starting the service and setting its startup-type to Automatic.
To make these changes, open up the Windows Control Panel, click on the \"Administrative Tools\" link, and then choose the Services option. This will bring up the Windows Service control panel:
Click on the 'SpiraTeam Data Sync Service' entry and click on the link to start the service. Then right-click the service entry and choose the option to set the startup type to 'Automatic'. This will ensure that synchronization continues between SpiraTeam and ClearQuest after a reboot of the server.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-ClearQuest/#using-spirateam-with-clearquest_1","title":"Using SpiraTeam with ClearQuest","text":"Now that the integration service has been configured and the service started, initially any incidents created in SpiraTeam for the specified projects will be imported into ClearQuest and any existing defects in ClearQuest will get loaded into SpiraTeam
At this point we recommend opening the Windows Event Viewer and choosing the Application Log. In this log any error messages raised by the SpiraTeam Data Sync Service will be displayed. If you see any error messages at this point, we recommend immediately stopping the SpiraTeam service and checking the various mapping entries. If you cannot see any issues with the mapping information, we recommend sending a copy of the event log message(s) to Inflectra customer services (support@inflectra.com) who will help you troubleshoot the problem.
To use SpiraTeam with ClearQuest on an ongoing basis, we recommend the following general processes be followed:
When running tests in SpiraTest or SpiraTeam, defects found should be logged through the Test Execution Wizard as normal.
Developers using ClearQuest can log new defects into either SpiraTeam or ClearQuest. In either case they will get loaded into the other system.
Once created in one of the systems and successfully replicated to the other system, the incident should not be modified again inside SpiraTeam
At this point, the incident should not be acted upon inside SpiraTeam and all data changes to the issue should be made inside ClearQuest. To enforce this, you should modify the workflows set up in SpiraTeam so that the various fields are marked as inactive for all the incident statuses other than the \"New\" status. This will allow someone to submit an incident in SpiraTeam, but will prevent them making changes in conflict with ClearQuest after that point.
As the issue progresses through the customized ClearQuest workflow, changes to the type of issue, changes to its status, priority, description and resolution will be updated automatically in SpiraTeam. In essence, SpiraTeam acts as a read-only viewer of these incidents.
You are now able to perform test coverage and incident reporting inside SpiraTest/SpiraTeam using the test cases managed by SpiraTest/SpiraTeam and the incidents managed on behalf of SpiraTest/SpiraTeam inside ClearQuest.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-IBM-RTC/","title":"Using SpiraTeam with IBM RTC","text":"This section outlines how to use SpiraTest, SpiraPlan or SpiraTeam (hereafter referred to as SpiraTeam) in conjunction with the IBM Rational Team Concert (hereafter referred to as RTC) work item tracking system. The built-in integration service allows the quality assurance team to manage their requirements and test cases in SpiraTeam, execute test runs in SpiraTest, and then have the new incidents generated during the run be automatically loaded into RTC.
Once the incidents are loaded into RTC as work items, the development team can then manage the lifecycle of these work items in RTC, and have the status changes in RTC be reflected back in SpiraTeam. In addition, any issues logged directly into RTC will get imported into SpiraTeam so that they can be linked to test cases and requirements.
Set up data synchronization
STOP! Please make sure you have first read the instructions to set up the data sync before proceeding!
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-IBM-RTC/#configuring-the-plug-in","title":"Configuring the Plug-In","text":"The next step is to configure the plug-in within SpiraTeam so that the system knows how to access the RTC server. To start the configuration, please open up SpiraTeam in a web browser, log in using a valid account that has System-Administration level privileges and click on the System > Data Synchronization administration option from the left-hand navigation:
This screen lists all the plug-ins already configured in the system. Depending on whether you chose the option to include sample data in your installation or not, you will see either an empty screen or a list of sample data-synchronization plug-ins.
If you already see an entry for RtcDataSync you should click on its \"Edit\" link. If you don't see such an entry in the list, please click on the [Add] button instead. In either case you will be taken to the following screen where you can enter or modify the RTC Data-Synchronization plug-in:
You need to fill out the following fields for the RTC Plug-in to operate correctly:
Name -- this needs to be set to RtcDataSync. This needs to match the name of the plug-in DLL assembly that was copied into the C:\\Program Files\\SpiraTeam\\Bin folder (minus the .dll file extension). If you renamed the RtcDataSync.dll file for any reason, then you need to change the name here to match.
Description -- this should be set to a description of the plug-in. This is an optional field that is used for documentation purposes and is not actually used by the system.
Connection Info -- this should be the base URL for connecting to your instance of RTC (for example https://servername:9443/ccm).
Login -- this should be set to a valid login for your RTC installation. The login needs to have permissions to create and view work items within RTC.
Password -- this should be set to the password of the login specified above.
Time Offset -- normally this should be set to zero, but if you find that issues being changed in RTC are not being updated in SpiraTeam, try increasing the value as this will tell the data-synchronization plug-in to add on the time offset (in hours) when comparing date-time stamps. Also if your RTC installation is running on a server set to a different time-zone, then you should add in the number of hours difference between the servers' time-zones here.
Auto-Map Users -- this is not currently used and can be ignored.
Custom 01 -- this is not currently used and can be ignored
Custom 02 -- this is not currently used and can be ignored
Custom 03 -- this is not currently used and can be ignored
Custom 04 -- this is not currently used and can be ignored
Custom 05 -- this is not currently used and can be ignored
Next, you need to configure the data mapping between SpiraTeam and RTC. This allows the various projects, users, incident statuses, priorities, severities and custom property values used in the two applications to be related to each other. This is important, as without a correct mapping, there is no way for the integration service to know that a \"New\" item in SpiraTeam is equivalent to a \"New\" item in RTC (for example).
The following mapping information needs to be setup in SpiraTeam:
The mapping of the project identifiers for the projects that need to be synchronized
The mapping of the various standard fields in the system
The mapping of the various custom properties in the system
Each of these is explained in turn below:
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-IBM-RTC/#configuring-the-project-mapping","title":"Configuring the Project Mapping","text":"From the data synchronization administration page, you need to click on the \"View Project Mappings\" hyperlink next to the RTC plug-in name. This will take you to the data-mapping home page for the currently selected project:
If the project name does not match the name of the project you want to configure the data-mapping for, click on the \"(Change Project)\" hyperlink to change the current project.
To enable this project for data-synchronization with RTC, you need to enter:
External Key -- This should be set to the display name of the project in RTC that will be mapped to the specific SpiraTeam project.
Active Flag -- Set this to 'Yes' so that SpiraTeam knows that you want to synchronize data for this project. Once the project has been completed, setting the value to \"No\" will stop data synchronization, reducing network utilization.
Click [Update] to confirm these settings. Once you have enabled the project for data-synchronization, you can now enter the other data mapping values outlined below.
Note: Once you have successfully configured the project, when creating a new project, you should choose the option to \"Create Project from Existing Project\" rather than \"Use Default Template\" so that all the project mappings get copied across to the new project.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-IBM-RTC/#configuring-the-standard-field-mapping","title":"Configuring the Standard Field Mapping","text":"Now that the projects, user and releases have been mapped correctly, we need to configure the standard incident fields. To do this, go to Administration > System > Data Synchronization and click on the \"View Project Mappings\" for the RtcDataSync plug-in entry:
From this screen, you need to click on Status and Type in turn to configure their values:
a) Incident Status
Click on the \"Status\" hyperlink under Incident Standard Fields to bring up the Incident status mapping configuration screen:
The table lists each of the incident statuses available in SpiraTeam and provides you with the ability to enter the matching RTC work item status name for each one. You can map multiple SpiraTeam fields to the same RTC fields (e.g. Closed and Resolved in SpiraTeam are both equivalent to Complete in RTC), in which case only one of the two values can be listed as Primary = Yes as that's the value that's used on the reverse synchronization (from RTC > SpiraTeam).
b) Incident Type
Click on the \"Type\" hyperlink under Incident Standard Fields to bring up the Incident type mapping configuration screen:
The table lists each of the incident types available in SpiraTeam and provides you with the ability to enter the matching RTC work item type name for each one. You can map multiple SpiraTeam fields to the same RTC fields, in which case only one of the two values can be listed as Primary = Yes as that's the value that's used on the reverse synchronization (from RTC > SpiraTeam).
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-IBM-RTC/#configuring-the-custom-property-mapping","title":"Configuring the Custom Property Mapping","text":"Now that the various SpiraTeam standard fields have been mapped correctly, we need to configure the custom property mappings. This is used to associate custom properties in SpiraTeam that map to custom fields in RTC. From the View/Edit Project Data Mapping screen, you need to click on the name of the Incident Custom Property that you want to add data-mapping information for.
We will consider the two different types of mapping that you might want to enter:
a) Text Custom Properties
Click on the hyperlink of the text custom property under Incident Custom Properties to bring up the custom property mapping configuration screen. For text custom properties there will be no values listed in the lower half of the screen.
You need to obtain the fully qualified XML name of the custom field in RTC that matches this custom property in SpiraTeam from the RTC documentation. Once you have entered the name of the custom field, click [Update].
b) List Custom Properties
Click on the hyperlink of the list custom property under Incident Custom Properties to bring up the custom property mapping configuration screen. For list custom properties there will be a textbox for both the custom field itself and a mapping table for each of the custom property values that need to be mapped:
First you need to obtain the fully qualified XML name of the field in RTC that matches this custom property in SpiraTeam. This should be entered in the 'External Key' field below the name of the custom property. Then you need enter the possible values in RTC for the custom property, mapping each one to the corresponding SpiraTeam custom property value.
**Once you have updated the various mapping sections, you are now ready to use the service. **
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-IBM-RTC/#using-spirateam-with-rtc","title":"Using SpiraTeam with RTC","text":"Now that the integration service has been configured and the service started, initially any incidents created in SpiraTeam for the specified projects will be imported into RTC and any existing work items in RTC will get loaded into SpiraTeam
At this point we recommend opening the Windows Event Viewer and choosing the Application Log. In this log any error messages raised by the SpiraTeam Data Sync Service will be displayed. If you see any error messages at this point, we recommend immediately stopping the SpiraTeam service and checking the various mapping entries. If you cannot see any issues with the mapping information, we recommend sending a copy of the event log message(s) to Inflectra customer services (http://www.inflectra.com/Support) who will help you troubleshoot the problem.
To use SpiraTeam with RTC on an ongoing basis, we recommend the following general processes be followed:
When running tests in SpiraTest or SpiraTeam, defects found should be logged through the Test Execution Wizard as normal.
Developers using RTC can log new work items into either SpiraTeam or RTC. In either case they will get loaded into the other system.
Once created in one of the systems and successfully replicated to the other system, the incident should not be modified again inside SpiraTeam
At this point, the incident should not be acted upon inside SpiraTeam and all data changes to the issue should be made inside RTC. To enforce this, you should modify the workflows set up in SpiraTeam so that the various fields are marked as inactive for all the incident statuses other than the \"New\" status. This will allow someone to submit an incident in SpiraTeam, but will prevent them making changes in conflict with RTC after that point.
As the issue progresses through the customized RTC workflow, changes to the type of work item, changes to its status, description and custom fields will be updated automatically in SpiraTeam. In essence, SpiraTeam acts as a read-only viewer of these incidents.
You are now able to perform test coverage and incident reporting inside SpiraTest/SpiraTeam using the test cases managed by SpiraTest/SpiraTeam and the incidents managed on behalf of SpiraTest/SpiraTeam inside RTC.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-JIRA-3--4/","title":"Using SpiraTeam with JIRA 3 / 4","text":"This section outlines how to use SpiraTest, SpiraPlan or SpiraTeam (hereafter referred to as SpiraTeam) in conjunction with the JIRA issue/bug tracking system versions 3.0 -- 4.0. The built-in integration service allows the quality assurance team to manage their requirements and test cases in SpiraTeam, execute test runs in SpiraTest, and then have the new incidents generated during the run be automatically loaded into JIRA. Once the incidents are loaded into JIRA as issues, the development team can then manage the lifecycle of these issues in JIRA, and have the status changes in JIRA be reflected back in SpiraTeam.
In addition, if you are using JIRA 4.x or higher, any issues logged directly into JIRA will get imported into SpiraTeam so that they can be linked to test cases and requirements.
Set up data synchronization
STOP! Please make sure you have first read the instructions to set up the data sync before proceeding!
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-JIRA-3--4/#configuring-the-plug-in","title":"Configuring the Plug-In","text":"The next step is to configure the plug-in within SpiraTeam so that the system knows how to access the JIRA server. To start the configuration, please open up SpiraTeam in a web browser, log in using a valid account that has System-Administration level privileges and click on the System > Data Synchronization administration option from the left-hand navigation:
This screen lists all the plug-ins already configured in the system. Depending on whether you chose the option to include sample data in your installation or not, you will see either an empty screen or a list of sample data-synchronization plug-ins.
If you already see an entry for JiraDataSync you should click on its \"Edit\" link. If you don't see such an entry in the list, please click on the [Add] button instead. In either case you will be taken to the following screen where you can enter or modify the JIRA Data-Synchronization plug-in:
You need to fill out the following fields for the JIRA Plug-in to operate correctly:
Name -- this needs to be set to JiraDataSync. This needs to match the name of the plug-in DLL assembly that was copied into the C:\\Program Files\\SpiraTeam\\Bin folder (minus the .dll file extension). If you renamed the JiraDataSync.dll file for any reason, then you need to change the name here to match.
Description -- this should be set to a description of the plug-in. This is an optional field that is used for documentation purposes and is not actually used by the system.
Connection Info -- this should the full URL to the JIRA installation's web-service API. This is typically http://<jira server name>/rpc/soap/jirasoapservice-v2.
Login -- this should be set to a valid login to the JIRA installation. The login needs to have permissions to create and view issues and versions within JIRA.
Password -- this should be set to the password of the login specified above.
Time Offset -- normally this should be set to zero, but if you find that issues being changed in JIRA are not being updated in SpiraTeam, try increasing the value as this will tell the data-synchronization plug-in to add on the time offset (in hours) when comparing date-time stamps. Also if your JIRA installation is running on a server set to a different time-zone, then you should add in the number of hours difference between the servers' time-zones here.
The remaining fields work differently depending on which version of the plugin you are using (JIRA 3.x or JIRA 4.x):
a) JIRA 3.x Plugin
Please fill out the fields as follows:
Auto-Map Users -- this is not currently used and can be ignored.
Custom 01 -- This is used to specify a JIRA custom property that should be mapped to the built-in SpiraTeam Incident Severity field (which does not exist in JIRA). This can be left empty for now and will be discussed below in Configuring the Data Mapping.
Custom 02 -- 05 -- these are not currently used by the plug-in and should be left blank.
b) JIRA 4.x Plugin
Please fill out the fields as follows:
Auto-Map Users -- This changes the way that the plugin maps users in SpiraTeam to those in JIRA:
**Auto-Map = True **With this setting, all users in SpiraTeam need to have the same username as those in JIRA. If this is the case then you do not need to perform the user-mapping task. This is a big time-saver if you can guarantee that all usernames are the same in both systems.
Auto-Map = False **With this setting, users in SpiraTeam and JIRA are free to have different usernames because you specify the corresponding JIRA name for each user as outlined in Configuring the User Mapping. **
Custom 01 -- This is used to specify a JIRA custom property that should be mapped to the built-in SpiraTeam Incident Severity field (which does not exist in JIRA). This can be left empty for now and will be discussed below in Configuring the Data Mapping.
Custom 02 -- This should be set to the word \"True\" if you want to have the new issues submitted to JIRA be submitted using a specified SecurityLevel. If you're not using the security level feature of JIRA, leave the field blank.
Custom 03 -- This should be set to the word \"True\" if you want to have the plugin restrict synchronization to only loading new incidents from SpiraTeam to JIRA and updating existing items. This is useful if you want to prevent existing issues in JIRA from being loaded into SpiraTeam. Leave blank if you want the plugin to synchronize normally.
Custom 04 -- This should be set to the word \"True\" if you want to have the plugin copy file attachments from SpiraTeam to JIRA. This can use additional system resources and may fail if the files are too large for JIRA's API to handle. Leave the field blank if you want the default behavior -- which is to not synchronize attachments.
Custom 05 - When you click \"Force Resync\" inside SpiraTeam it will attempt to resynchronize all incidents/issues from 1/1/1900. Sometimes that causes the JIRA API to timeout or exceed the maximum allowed number of results if there are a large number of existing issues in JIRA.
You can set this field to a specific year (e.g. 1995) or year and month (e.g. 2010-11) to restrict how far back the system will look for existing issues. If you leave this field blank it will use the default value of \"1900-01\".
Note: For most users, we recommend leaving Custom 01 -- Custom 05 blank.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-JIRA-3--4/#configuring-the-data-mapping","title":"Configuring the Data Mapping","text":"Next, you need to configure the data mapping between SpiraTeam and JIRA. This allows the various projects, users, releases, incident types, statuses, priorities and custom property values used in the two applications to be related to each other. This is important, as without a correct mapping, there is no way for the integration service to know that an \"Enhancement\" in SpiraTeam is the same as a \"New Feature\" in JIRA (for example).
The following mapping information needs to be setup in SpiraTeam:
Each of these is explained in turn below:
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-JIRA-3--4/#configuring-the-project-mapping","title":"Configuring the Project Mapping","text":"From the data synchronization administration page, you need to click on the \"View Project Mappings\" hyperlink next to the JIRA plug-in name. This will take you to the data-mapping home page for the currently selected project:
If the project name does not match the name of the project you want to configure the data-mapping for, click on the \"(Change Project)\" hyperlink to change the current project.
To enable this project for data-synchronization with JIRA, you need to enter:
External Key -- This should be set to the name of the project token in JIRA. Typically this is a three-letter acronym for the project.
Active Flag -- Set this to 'Yes' so that SpiraTeam knows that you want to synchronize data for this project. Once the project has been completed, setting the value to \"No\" will stop data synchronization, reducing network utilization.
Click [Update] to confirm these settings. Once you have enabled the project for data-synchronization, you can now enter the other data mapping values outlined below.
Note: Once you have successfully configured the project, when creating a new project, you should choose the option to \"Create Project from Existing Project\" rather than \"Use Default Template\" so that all the project mappings get copied across to the new project.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-JIRA-3--4/#configuring-the-user-mapping","title":"Configuring the User Mapping","text":"To configure the mapping of users in the two systems, you need to go to Administration > Users > View Edit Users, which will bring up the list of users in the system. Then click on the \"Edit\" button for a particular user that will be editing issues in JIRA:
You will notice that below the Active flag for the user is a list of all the configured data-synchronization plug-ins. In the text box next to the JIRA Data-Sync plug-in you need to enter the login for this username in JIRA. This will allow the data-synchronization plug-in to know which user in SpiraTeam match which equivalent user in JIRA. Click [Update] once you've entered the appropriate login name. You should now repeat for the other users who will be active in both systems.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-JIRA-3--4/#configuring-the-release-mapping","title":"Configuring the Release Mapping","text":"When the data-synchronization service runs, when it comes across a release/iteration in SpiraTeam that it has not seen before, it will create a corresponding \"Version\" in JIRA. Similarly if it comes across a new Version in JIRA that it has not seen before, it will create a new Release in SpiraTeam. Therefore when using both systems together, it is recommended that you only enter new Releases/Versions in one system and let the data-synchronization service add them to the other system.
However you may start out with the situation where you already have pre-existing Releases/Version in both systems that you need to associate in the data-mapping. If you don't do this, you may find that duplicates get created when you first enable the data-synchronization service. Therefore for any Releases/Iterations that already exist in BOTH systems please navigate to Planning > Releases and click on the Release/Iteration in question. Make sure you have the 'Overview' tab visible and expand the \"Details\" section of the release/iteration:
In addition to the standard fields custom properties configured for Releases, you will see an additional text property called \"JiraDataSync ID\" that is used to store the mapped external identifier for the equivalent Version in JIRA. You need to locate the ID of the equivalent version in JIRA, enter it into this text-box and click [Save]. You should now repeat for all the other pre-existing releases.
Note: The JIRA ID can be found by looking at the URL inside JIRA when choosing to View/Edit the version name/description. The URL will include the section: id=X where X is the numeric ID of the version inside JIRA.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-JIRA-3--4/#configuring-the-standard-field-mapping","title":"Configuring the Standard Field Mapping","text":"Now that the projects, user and releases have been mapped correctly, we need to configure the standard incident fields. To do this, go to Administration > System > Data Synchronization and click on the \"View Project Mappings\" for the JiraDataSync plug-in entry:
From this screen, you need to click on Priority, Severity, Status and Type in turn to configure their values:
a) Incident Type
Click on the \"Type\" hyperlink under Incident Standard Fields to bring up the Incident type mapping configuration screen:
The table lists each of the incident types available in SpiraTeam and provides you with the ability to enter the matching JIRA issue type ID for each one. You can map multiple SpiraTeam fields to the same JIRA fields (e.g. Bug and Incident in SpiraTeam are both equivalent to Bug in JIRA), in which case only one of the two values can be listed as Primary = Yes as that's the value that's used on the reverse synchronization (from JIRA to SpiraTeam).
Note: The JIRA ID can be found by looking at the URL inside JIRA when choosing to View/Edit the Issue Type. The URL will include the section: id=X where X is the numeric ID of the Issue Type inside JIRA.
b) Incident Status
Click on the \"Status\" hyperlink under Incident Standard Fields to bring up the Incident status mapping configuration screen:
The table lists each of the incident statuses available in SpiraTeam and provides you with the ability to enter the matching JIRA issue status ID for each one. You can map multiple SpiraTeam fields to the same JIRA fields (e.g. New and Open in SpiraTeam are both equivalent to Open in JIRA), in which case only one of the two values can be listed as Primary = Yes as that's the value that's used on the reverse synchronization (from JIRA to SpiraTeam).
We recommend that you always point the New and Open statuses inside SpiraTeam to point to the ID for \"Open\" inside JIRA and make Open in SpiraTeam the Primary status of the two. This is recommended so that as new incidents in SpiraTeam get synched over to JIRA, they will get switched to the Open status in JIRA which will then be synched back to \"Open\" in SpiraTeam. That way you'll be able to see at a glance which incidents have been synched with JIRA and those that haven't.
Note: The JIRA ID can be found by looking at the URL inside JIRA when choosing to View/Edit the Issue Status. The URL will include the section: id=X where X is the numeric ID of the Issue Status inside JIRA.
c) Incident Priority
Click on the \"Priority\" hyperlink under Incident Standard Fields to bring up the Incident Priority mapping configuration screen:
The table lists each of the incident priorities available in SpiraTeam and provides you with the ability to enter the matching JIRA priority ID for each one. You can map multiple SpiraTeam fields to the same JIRA fields, in which case only one of the two values can be listed as Primary = Yes as that's the value that's used on the reverse synchronization (from JIRA to SpiraTeam).
Note: The JIRA ID can be found by looking at the URL inside JIRA when choosing to View/Edit the Priority. The URL will include the section: id=X where X is the numeric ID of the Priority inside JIRA.
d) Incident Severity (Optional)
Click on the \"Severity\" hyperlink under Incident Standard Fields to bring up the Incident severity mapping configuration screen:
Unlike the other incident standard fields, JIRA doesn't actually have a built-in field for storing the severity of an issue, so if you want to be able to see the SpiraTeam incident severity in JIRA, you'll need to create a JIRA custom list field to store the different severity values. If you don't want to synchronize severity values with JIRA, you can skip the rest of this section.
Once you have created a custom field in JIRA to contain the list of severity values, you need to now populate the above table with the name (Not the ID) of the severity custom property values inside JIRA and click Update. Secondly you need to go to the Plug-in configuration screen:
On this screen you need to enter the ID of the custom field that you're using to store severities in JIRA and populate the Custom 01 property with this value (see above). Note: The ID can be found by looking at the URL inside JIRA when choosing to View/Edit the Custom Field. The URL will include the section: id=X where X is the numeric ID of the Custom Field inside JIRA.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-JIRA-3--4/#configuring-the-custom-property-mapping","title":"Configuring the Custom Property Mapping","text":"Now that the various SpiraTeam standard fields have been mapped correctly, we need to configure the custom property mappings. This is used for both custom properties in SpiraTeam that map to custom fields in JIRA and also for custom properties in SpiraTeam that are used to map to standard fields in JIRA (Component, Environment, Resolution and SecurityLevel) that don't exist in SpiraTeam.
From the View/Edit Project Data Mapping screen, you need to click on the name of the Incident Custom Property that you want to add data-mapping information for. We will consider the four different types of mapping that you might want to enter:
a) Text Custom Properties
Click on the hyperlink of the text custom property under Incident Custom Properties to bring up the custom property mapping configuration screen. For text custom properties there will be no values listed in the lower half of the screen.
You need to lookup the ID of the custom field in JIRA that matches this custom property in SpiraTeam. Once you have entered the id of the custom field, click [Update].
Note: The ID can be found by looking at the URL inside JIRA when choosing to View/Edit the Custom Field. The URL will include the section: id=X where X is the numeric ID of the Custom Field inside JIRA.
b) List Custom Properties
Click on the hyperlink of the list custom property under Incident Custom Properties to bring up the custom property mapping configuration screen. For list custom properties there will be a textbox for both the custom field itself and a mapping table for each of the custom property values that need to be mapped:
First you need to lookup the ID of the custom field in JIRA that matches this custom property in SpiraTeam. This should be entered in the 'External Key' field below the name of the custom property. Note: The ID can be found by looking at the URL inside JIRA when choosing to View/Edit the Custom Field. The URL will include the section: id=X where X is the numeric ID of the Custom Field inside JIRA.
Next for each of the Property Values in the table (in the lower half of the page) you need to enter the full name (not the id this time) of the custom field value as specified in JIRA.
c) JIRA's Component Field
If your instance of JIRA requires that all new issues are submitted with a 'Component' then you will need to fill out this section. You first need to create an incident custom property in SpiraTeam of type 'LIST' that contains the various component names that exist inside JIRA.
Then click on the hyperlink of this new list custom property under Incident Custom Properties to bring up the custom property mapping configuration screen:
First you need to enter the word \"Component\" as the External Key of the custom property. This tells the data-sync plug-in that the custom property in SpiraTeam should be mapped to built-in Component field in JIRA.
Next for each of the Property Values in the table (in the lower half of the page) you need to enter the JIRA ID of the various Components that are configured in JIRA. The external ID can be found by looking at the URL inside JIRA which choosing to View/Edit the component name/description.
d) JIRA's Resolution Field
If you would like the values of the JIRA 'Resolution' field to be synchronized back to SpiraTeam, then you will need to fill out this section. You first need to create an incident custom property in SpiraTeam of type 'LIST' that contains the various resolution names that exist inside JIRA.
Then click on the hyperlink of this new list custom property under Incident Custom Properties to bring up the custom property mapping configuration screen:
First you need to enter the word \"Resolution\" as the External Key of the custom property. This tells the data-sync plug-in that the custom property in SpiraTeam should be mapped to built-in Resolution field in JIRA.
Next for each of the Property Values in the table (in the lower half of the page) you need to enter the JIRA ID of the various Resolutions that are configured in JIRA. The external ID can be found by looking at the URL inside JIRA which choosing to View/Edit the resolution name/description.
e) JIRA's Environment Field
If your instance of JIRA requires that all new issues are submitted with an 'Environment' description specified, then you will need to fill out this section. You first need to create an incident custom property in SpiraTeam of type 'TEXT' that will be used to store the environment description within SpiraTeam.
Then click on the hyperlink of this new list custom property under Incident Custom Properties to bring up the custom property mapping configuration screen:
All you need to do on this screen is enter the word \"Environment\" in the External Key textbox and the data-sync plug-in will know that this custom property is mapped to the built-in Environment field in JIRA.
f) JIRA's Security Level Field (JIRA 4.x Plug-In Only)
If your instance of JIRA requires that all new issues are submitted with a 'Security Level' then you will need to fill out this section. You first need to create an incident custom property in SpiraTeam of type 'LIST' that contains the various security levels that exist inside JIRA.
Then click on the hyperlink of this new list custom property under Incident Custom Properties to bring up the custom property mapping configuration screen.
First you need to enter the word \"SecurityLevel\" as the External Key of the custom property. This tells the data-sync plug-in that the custom property in SpiraTeam should be mapped to built-in Security Level field in JIRA.
Next for each of the Property Values in the table (in the lower half of the page) you need to enter the JIRA ID of the various Security Levels that are configured in JIRA. The external ID can be found by looking at the URL inside JIRA which choosing to View/Edit the security level name/description.
g) JIRA's Issue Key Field (JIRA 4.x Plug-In Only)
It can be convenient to create a SpiraTeam custom property to store the JIRA Issue Key (the ID used to identify an issue in JIRA). This allows you to display a list of incients in SpiraTest and see the corresponding JIRA ID in the same list. You first need to create an incident custom property in SpiraTeam of type 'TEXT' that will be used to store the JIRA issue key within SpiraTeam.
Then click on the hyperlink of this new list custom property under Incident Custom Properties to bring up the custom property mapping configuration screen:
All you need to do on this screen is enter the word \"JiraIssueKey\" in the External Key textbox and the data-sync plug-in will know that this custom property is mapped to the built-in Issue Key field in JIRA.
Once you have updated the various mapping sections, you are now ready to start using the system.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-JIRA-3--4/#using-spirateam-with-jira","title":"Using SpiraTeam with JIRA","text":"Now that the integration service has been configured and the service started, initially any incidents created in SpiraTeam for the specified projects will be imported into JIRA and if using JIRA 4.x, any existing issues in JIRA will get loaded into SpiraTeam
At this point we recommend opening the Windows Event Viewer and choosing the Application Log. In this log any error messages raised by the SpiraTeam Data Sync Service will be displayed. If you see any error messages at this point, we recommend immediately stopping the SpiraTeam service and checking the various mapping entries. If you cannot see any issues with the mapping information, we recommend sending a copy of the event log message(s) to Inflectra customer services (support@inflectra.com) who will help you troubleshoot the problem.
To use SpiraTeam with JIRA on an ongoing basis, we recommend the following general processes be followed:
When running tests in SpiraTest or SpiraTeam, defects found should be logged through the Test Execution Wizard as normal.
Developers using JIRA 4.x can log new defects into either SpiraTeam or JIRA. In either case they will get loaded into the other system.
Once created in one of the systems and successfully replicated to the other system, the incident should not be modified again inside SpiraTeam
At this point, the incident should not be acted upon inside SpiraTeam and all data changes to the issue should be made inside JIRA. To enforce this, you should modify the workflows set up in SpiraTeam so that the various fields are marked as inactive for all the incident statuses other than the \"New\" status. This will allow someone to submit an incident in SpiraTeam, but will prevent them making changes in conflict with JIRA after that point.
As the issue progresses through the customized JIRA workflow, changes to the type of issue, changes to its status, priority, description and resolution will be updated automatically in SpiraTeam. In essence, SpiraTeam acts as a read-only viewer of these incidents.
You are now able to perform test coverage and incident reporting inside SpiraTest/SpiraTeam using the test cases managed by SpiraTest/SpiraTeam and the incidents managed on behalf of SpiraTest/SpiraTeam inside JIRA.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-JIRA-5%2B/","title":"Using SpiraTeam with Jira Server (or DataCenter)","text":""},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-JIRA-5%2B/#introduction","title":"Introduction","text":"By integrating SpiraTest, SpiraTeam or SpiraPlan (called SpiraPlan from here on out) and Jira Server or Jira DataCenter (hereafter just Jira Server or Jira) your teams can work seamlessly across both applications.
For example, the quality assurance team can manage their requirements and test cases in SpiraPlan, and execute test runs in SpiraPlan. Incident generated during testing wil be automatically loaded into Jira Server as new issues. The development team, working in Jira, can then manage the lifecycle of these issues in Jira. When they change the issue status or add comments, these changes are quickly updated to match back in SpiraPlan. You can choose which sort of Jira issues are made into incidents in SpiraPlan, and which get created as requirements (based on the issue type). This can be used as part of the planning and testing lifecycle.
With this integration you can, for each project/product you want to sync up:
Set up data synchronization
STOP! Please make sure you have first read the instructions to set up the data sync before proceeding!
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-JIRA-5%2B/#configuring-the-plug-in","title":"Configuring the Plug-In","text":"This section outlines how to configure the integration service to export incidents into JIRA, import new issues from JIRA and pick up subsequent status changes in JIRA and have them update SpiraTeam. It assumes that you already have a working installation of SpiraTest, SpiraPlan or SpiraTeam and a working installation of JIRA.
The following versions of SpiraTeam and Jira Server are supported:
The JIRA 5.x plugin supports Jira 5.0 or later and SpiraTeam v5.0 or later
The JIRA 4.x plugin supports Jira 4.0 or later and SpiraTeam v3.0 or later (see Using SpiraTeam with JIRA 3 / 4)
The JIRA 3.x plugin supports Jira 3.0 or later and SpiraTeam v2.3 or later (see Using SpiraTeam with JIRA 3 / 4)
If you are using the Cloud version of Jira, please refer to the Jira Cloud Documentation instead.
If you have an earlier version of SpiraTeam, you will need to upgrade to at least v2.3 before trying to integrate with Jira Server.
The next step is to configure the plug-in within SpiraTeam so that the system knows how to access the Jira server. Inside SpiraPlan, go to the Administration page and navigate to Integration > Data Synchronization. Check if you see a plug-in called JiraServerDataSync, as shown below:
What do if the plug-in is not there
If you don't see the plug-in in the list, click the \"\"Add\" button at the top of the page. This opens the generic Data Sync plug-in details page. This is not yet customized to help you more easily set up the data sync. We recommend, adding just enough information now to create the plug-in. Then edit the plug-in after its made to complete the process.
To start, fill in the following fields:
Now click \"Add\" to save the plug-in and return you to the list of plug-ins. Now follow the instructions below.
With the plug-in place, click on its \"edit\" button to open its detailed settings page.
You need to fill out the following fields for the JIRA Plug-in to operate correctly:
Auto-Map Users: This changes the way that the plugin maps users in SpiraTeam to those in JIRA:
Severity Field: This is used to specify a JIRA custom property that should be mapped to the built-in SpiraTeam Incident Severity field (which does not exist in JIRA). This can be left empty for now and will be discussed below in Configuring the Data Mapping.
Sync Direction: This determines how the synchronization of incidents works:
Requirement Types: This should be set to a comma-separated list of IDs of any JIRA issue types that you want to be synchronized with SpiraTeam requirements instead of incidents. If you leave this blank, all JIRA issue types will be synchronized with incidents.
Note: For most users, we recommend leaving Severity Field, Task Types, Sync Direction, and Requirement Types fields blank.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-JIRA-5%2B/#configuring-the-data-mapping","title":"Configuring the Data Mapping","text":"Next, you need to configure the data mapping between SpiraTeam and JIRA. This allows the various projects, users, releases, incident types, statuses, priorities and custom property values used in the two applications to be related to each other. This is important, as without a correct mapping, there is no way for the integration service to know that an \"Enhancement\" in SpiraTeam is the same as a \"New Feature\" in JIRA (for example).
The following mapping information needs to be setup in SpiraTeam:
Each of these is explained in turn below. However, to make the data mapping process easier, we have a helpful utility that will help you connect to your JIRA instance (both cloud or server) and determine the matching IDs for the various fields in JIRA:
You can download it from this URL: https://www.inflectra.com/Downloads/JiraConfigurationHelper.zip
Once you have downloaded and unzipped the program, run the JiraConfigurationHelper.exe and the following screen will be displayed:
Enter in the URL, login and password/API Key for your JIRA instance and click Connect:
Choose the project in JIRA that you will be connecting to SpiraTest and then the list of issue types, issue statuses, issue priorities, components, versions and custom fields will be displayed. We will be using this tool later on when you want to get some of the ID values to populate in SpiraTest.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-JIRA-5%2B/#configuring-the-project-mapping","title":"Configuring the Project Mapping","text":"From the data synchronization administration page, you need to click on the \"View Project Mappings\" hyperlink next to the JIRA plug-in name. This will take you to the data-mapping home page for the currently selected project:
If the project name does not match the name of the project you want to configure the data-mapping for, click on the \"(Change Project)\" hyperlink to change the current project.
To enable this project for data-synchronization with JIRA, you need to enter:
External Key -- This should be set to the name of the project Key in JIRA. Typically, this is a short acronym for the project:
Active Flag -- Set this to 'Yes' so that SpiraTeam knows that you want to synchronize data for this project. Once the project has been completed, setting the value to \"No\" will stop data synchronization, reducing network utilization.
Click [Update] to confirm these settings. Once you have enabled the project for data-synchronization, you can now enter the other data mapping values outlined below.
Note: Once you have successfully configured the project, when creating a new project, you should choose the option to \"Create Project from Existing Project\" rather than \"Use Default Template\" so that all the project mappings get copied across to the new project.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-JIRA-5%2B/#configuring-the-user-mapping","title":"Configuring the User Mapping","text":"To configure the mapping of users in the two systems, you need to go to Administration > Users > View Edit Users, which will bring up the list of users in the system. Then click on the \"Edit\" button for a particular user that will be editing issues in JIRA:
Click on the 'Data Mapping' tab to list all the configured data-synchronization plug-ins for this user. In the text box next to the JIRA Data-Sync plug-in you need to enter the login for this username in JIRA. This will allow the data-synchronization plug-in to know which user in SpiraTeam match which equivalent user in JIRA. Click [Save] once you've entered the appropriate login name. You should now repeat for the other users who will be active in both systems.
If you have set the \"Auto-Map Users\" option in the JIRA plugin, you can skip this section completely.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-JIRA-5%2B/#configuring-the-release-mapping","title":"Configuring the Release Mapping","text":"When the data-synchronization service runs, when it comes across a release/iteration in SpiraTeam that it has not seen before, it will create a corresponding \"Version\" in JIRA. Similarly, if it comes across a new Version in JIRA that it has not seen before, it will create a new Release in SpiraTeam. Therefore, when using both systems together, it is recommended that you only enter new Releases/Versions in one system and let the data-synchronization service add them to the other system.
However, you may start out with the situation where you already have pre-existing Releases/Version in both systems that you need to associate in the data-mapping. If you don't do this, you may find that duplicates get created when you first enable the data-synchronization service. Therefore, for any Releases/Iterations that already exist in BOTH systems please navigate to Planning > Releases and click on the Release/Iteration in question. Make sure you have the 'Overview' tab visible and expand the \"Details\" section of the release/iteration:
In addition to the standard fields and custom properties, you will see an additional text property called \"Jira ID\" that is used to store the mapped external identifier for the equivalent Version in JIRA. You need to locate the ID of the equivalent version in JIRA, enter it into this text-box and click [Save]. You should now repeat for all the other pre-existing releases.
The JIRA ID can be found using the Jira Configuration Helper using the Versions tab:
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-JIRA-5%2B/#configuring-the-standard-field-mapping","title":"Configuring the Standard Field Mapping","text":"Now that the projects, user and releases have been mapped correctly, we need to configure the standard incident and requirement fields. To do this, go to Administration > System > Data Synchronization and click on the \"View Project Mappings\" for the JiraDataSync plug-in entry:
From this screen, you need to click on Priority, Severity, Component, Status and Type in turn to configure the incident field mappings. If you're using the option to have JIRA also synchronize some issue types as requirements, then you'll need to also configure the Requirement Importance, Type, Component and Status fields.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-JIRA-5%2B/#a-incident-type","title":"a) Incident Type","text":"Click on the \"Type\" hyperlink under Incident Standard Fields to bring up the Incident type mapping configuration screen:
The table lists each of the incident types available in SpiraTeam and provides you with the ability to enter the matching JIRA issue type ID for each one. You can map multiple SpiraTeam fields to the same JIRA fields (e.g. Bug and Incident in SpiraTeam are both equivalent to Bug in JIRA), in which case only one of the two values can be listed as Primary = Yes as that's the value that's used on the reverse synchronization (from JIRA to SpiraTeam).
The JIRA ID can be found by using the Issue Types tab of the Jira configuration helper:
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-JIRA-5%2B/#b-incident-status","title":"b) Incident Status","text":"Click on the \"Status\" hyperlink under Incident Standard Fields to bring up the Incident status mapping configuration screen:
The table lists each of the incident statuses available in SpiraTeam and provides you with the ability to enter the matching JIRA issue status ID for each one. You can map multiple SpiraTeam fields to the same JIRA fields (e.g. New and Open in SpiraTeam are both equivalent to Open in JIRA), in which case only one of the two values can be listed as Primary = Yes as that's the value that's used on the reverse synchronization (from JIRA to SpiraTeam).
We recommend that you always point the New and Open statuses inside SpiraTeam to point to the ID for \"Open\" inside JIRA and make Open in SpiraTeam the Primary status of the two. This is recommended so that as new incidents in SpiraTeam get synched over to JIRA, they will get switched to the Open status in JIRA which will then be synched back to \"Open\" in SpiraTeam. That way you'll be able to see at a glance which incidents have been synched with JIRA and those that haven't.
The JIRA ID can be found by using the Issue Statuses tab of the Jira configuration helper:
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-JIRA-5%2B/#c-incident-priority","title":"c) Incident Priority","text":"Click on the \"Priority\" hyperlink under Incident Standard Fields to bring up the Incident Priority mapping configuration screen:
The table lists each of the incident priorities available in SpiraTeam and provides you with the ability to enter the matching JIRA priority ID for each one. You can map multiple SpiraTeam fields to the same JIRA fields, in which case only one of the two values can be listed as Primary = Yes as that's the value that's used on the reverse synchronization (from JIRA to SpiraTeam).
The JIRA ID can be found by using the Issue Priorities tab of the Jira configuration helper:
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-JIRA-5%2B/#d-incident-component-optional","title":"d) Incident Component (Optional)","text":"Click on the \"Component\" hyperlink under Incident Standard Fields to bring up the Incident component mapping configuration screen:
The table lists each of the components available in SpiraTeam and provides you with the ability to enter the matching JIRA component ID for each one. You can map multiple SpiraTeam fields to the same JIRA fields, in which case only one of the two values can be listed as Primary = Yes as that's the value that's used on the reverse synchronization (from JIRA to SpiraTeam).
The JIRA ID can be found by using the Components tab of the Jira configuration helper:
:
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-JIRA-5%2B/#e-incident-severity-optional","title":"e) Incident Severity (Optional)","text":"Click on the \"Severity\" hyperlink under Incident Standard Fields to bring up the Incident severity mapping configuration screen:
Unlike the other incident standard fields, JIRA doesn't actually have a built-in field for storing the severity of an issue, so if you want to be able to see the SpiraTeam incident severity in JIRA, you'll need to create a JIRA custom list field to store the different severity values. If you don't want to synchronize severity values with JIRA, you can skip the rest of this section.
Once you have created a custom field in JIRA to contain the list of severity values, you need to now populate the above table with the name (Not the ID) of the severity custom property values inside JIRA and click Update. Secondly you need to go to the Plug-in configuration screen:
On this screen you need to enter the ID of the custom field that you're using to store severities in JIRA and populate the Severity Field property with this value (see above). The ID can be found by using the Custom Fields tab of the Jira Configuration Helper:
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-JIRA-5%2B/#f-requirement-status-optional","title":"f) Requirement Status (Optional)","text":"Click on the \"Status\" hyperlink under Requirement Standard Fields to bring up the Requirement status mapping configuration screen:
The table lists each of the requirement statuses available in SpiraTeam and provides you with the ability to enter the matching JIRA issue status ID for each one. You can map multiple SpiraTeam fields to the same JIRA fields, in which case only one of the two values can be listed as Primary = Yes as that's the value that's used on the reverse synchronization (from JIRA to SpiraTeam).
The JIRA ID can be found by using the Issue Statuses tab of the Jira configuration helper:
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-JIRA-5%2B/#g-requirement-importance-optional","title":"g) Requirement Importance (Optional)","text":"Click on the \"Importance\" hyperlink under Requirement Standard Fields to bring up the Requirement Importance mapping configuration screen:
The table lists each of the requirement importances available in SpiraTeam and provides you with the ability to enter the matching JIRA priority ID for each one. You can map multiple SpiraTeam fields to the same JIRA fields, in which case only one of the two values can be listed as Primary = Yes as that's the value that's used on the reverse synchronization (from JIRA to SpiraTeam).
The JIRA ID can be found by using the Issue Priorities tab of the Jira configuration helper:
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-JIRA-5%2B/#h-requirement-type-optional","title":"h) Requirement Type (Optional)","text":"Click on the \"Type\" hyperlink under Requirement Standard Fields to bring up the Requirement type mapping configuration screen:
The table lists each of the requirement types available in SpiraTeam and provides you with the ability to enter the matching JIRA issue type ID for each one. You can map multiple SpiraTeam fields to the same JIRA fields (e.g. Use Case and User Story in SpiraTeam are both equivalent to User Story in JIRA), in which case only one of the two values can be listed as Primary = Yes as that's the value that's used on the reverse synchronization (from JIRA to SpiraTeam).
The JIRA ID can be found by using the Issue Types tab of the Jira configuration helper:
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-JIRA-5%2B/#i-requirement-component-optional","title":"i) Requirement Component (Optional)","text":"Click on the \"Component\" hyperlink under Requirement Standard Fields to bring up the Requirement component mapping configuration screen:
The table lists each of the components available in SpiraTeam and provides you with the ability to enter the matching JIRA component ID for each one. You can map multiple SpiraTeam fields to the same JIRA fields, in which case only one of the two values can be listed as Primary = Yes as that's the value that's used on the reverse synchronization (from JIRA to SpiraTeam).
The JIRA ID can be found by using the Components tab of the Jira configuration helper:
:
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-JIRA-5%2B/#j-task-status-optional","title":"j) Task Status (Optional)","text":"Click on the \"Status\" hyperlink under Task Standard Fields to bring up the Task status mapping configuration screen:
The table lists each of the task statuses available in SpiraPlan and provides you with the ability to enter the matching JIRA issue status ID for each one. You can map multiple SpiraPlan fields to the same JIRA fields, in which case only one of the two values can be listed as Primary = Yes as that's the value that's used on the reverse synchronization (from JIRA to SpiraPlan).
The JIRA ID can be found by using the Issue Statuses tab of the Jira configuration helper. Please note, in Jira there are 5 default levels of Issue Priority, and only 4 (by default - this can be changed) in SpiraPlan.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-JIRA-5%2B/#k-task-priority-optional","title":"k) Task Priority (Optional)","text":"Click on the \"Priority\" hyperlink under Task Standard Fields to bring up the Task Priority mapping configuration screen:
The table lists each of the task priorities available in SpiraPlan and provides you with the ability to enter the matching JIRA priority ID for each one. You can map multiple SpiraPlan fields to the same JIRA fields, in which case only one of the two values can be listed as Primary = Yes as that's the value that's used on the reverse synchronization (from JIRA to SpiraPlan).
The JIRA ID can be found by using the Issue Priorities tab of the Jira configuration helper:
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-JIRA-5%2B/#l-task-type-optional","title":"l) Task Type (Optional)","text":"Click on the \"Type\" hyperlink under Task Standard Fields to bring up the Task type mapping configuration screen:
The table lists each of the task types available in SpiraPlan and provides you with the ability to enter the matching JIRA issue type ID for each one. You can map multiple SpiraPlan fields to the same JIRA fields (e.g. Management and Other in SpiraPlan are both equivalent to Task in JIRA), in which case only one of the two values can be listed as Primary = Yes as that's the value that's used on the reverse synchronization (from JIRA to SpiraPlan).
The JIRA ID can be found by using the Issue Types tab of the Jira configuration helper:
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-JIRA-5%2B/#configuring-the-custom-property-mapping","title":"Configuring the Custom Property Mapping","text":"Now that the various SpiraTeam standard fields have been mapped correctly, we need to configure the custom property mappings. This is used for both custom properties in SpiraTeam that map to custom fields in JIRA and also for custom properties in SpiraTeam that are used to map to standard fields in JIRA (Environment, Resolution and SecurityLevel) that don't exist in SpiraTeam.
From the View/Edit Project Data Mapping screen, you need to click on the name of the Incident or Requirement Custom Property that you want to add data-mapping information for. We will consider the four different types of mapping that you might want to enter:
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-JIRA-5%2B/#a-scalar-custom-properties","title":"a) Scalar Custom Properties","text":"This refers to custom properties that have a simple user-entered value and don't need to have their specific options mapped between SpiraTeam and JIRA. All of the custom property types except List and Multi-List fall into this category (e.g. Text, Date, User, Boolean, Decimal, Integer, etc.)
Click on the hyperlink of the scalar custom property under Incident/Requirement Custom Properties to bring up the custom property mapping configuration screen. For scalar custom properties, there will be no values listed in the lower half of the screen.
You need to lookup the ID of the custom field in JIRA that matches this custom property in SpiraTeam. Once you have entered the id of the custom field, click [Update].
The ID can be found by using the Custom Fields tab of the Jira Configuration Helper:
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-JIRA-5%2B/#b-list-custom-properties","title":"b) List Custom Properties","text":"This refers to custom properties that are either of type List or Multi-List. Click on the hyperlink of the list custom property under Incident/Requirement Custom Properties to bring up the custom property mapping configuration screen. For list custom properties there will be a textbox for both the custom field itself and a mapping table for each of the custom property values that need to be mapped:
First you need to lookup the ID of the custom field in JIRA that matches this custom property in SpiraTeam. This should be entered in the 'External Key' field below the name of the custom property. The ID can be found by using the Custom Fields tab of the Jira Configuration Helper:
Next for each of the Property Values in the table (in the lower half of the page) you need to enter the full name (not the id this time) of the custom field value as specified in JIRA:
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-JIRA-5%2B/#c-jiras-resolution-field","title":"c) JIRA's Resolution Field","text":"If you would like the values of the JIRA 'Resolution' field to be synchronized back to SpiraTeam, then you will need to fill out this section. You first need to create an incident custom property in SpiraTeam of type 'LIST' that contains the various resolution names that exist inside JIRA.
Then click on the hyperlink of this new list custom property under Incident Custom Properties to bring up the custom property mapping configuration screen:
First you need to enter the word \"Resolution\" as the External Key of the custom property. This tells the data-sync plug-in that the custom property in SpiraTeam should be mapped to built-in Resolution field in JIRA.
Next for each of the Property Values in the table (in the lower half of the page) you need to enter the JIRA ID of the various Resolutions that are configured in JIRA. The external ID can be found by looking at the URL inside JIRA which choosing to View/Edit the resolution name/description.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-JIRA-5%2B/#d-jiras-environment-field","title":"d) JIRA's Environment Field","text":"If your instance of JIRA requires that all new issues are submitted with an 'Environment' description specified, then you will need to fill out this section. You first need to create an incident custom property in SpiraTeam of type 'TEXT' that will be used to store the environment description within SpiraTeam.
Then click on the hyperlink of this new list custom property under Incident Custom Properties to bring up the custom property mapping configuration screen:
All you need to do on this screen is enter the word \"Environment\" in the External Key textbox and the data-sync plug-in will know that this custom property is mapped to the built-in Environment field in JIRA.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-JIRA-5%2B/#e-jiras-security-level-field","title":"e) JIRA's Security Level Field","text":"If your instance of JIRA requires that all new issues are submitted with a 'Security Level' then you will need to fill out this section. You first need to create an incident custom property in SpiraTeam of type 'LIST' that contains the various security levels that exist inside JIRA.
Then click on the hyperlink of this new list custom property under Incident Custom Properties to bring up the custom property mapping configuration screen.
First you need to enter the word \"SecurityLevel\" as the External Key of the custom property. This tells the data-sync plug-in that the custom property in SpiraTeam should be mapped to built-in Security Level field in JIRA.
Next for each of the Property Values in the table (in the lower half of the page) you need to enter the JIRA ID of the various Security Levels that are configured in JIRA. The external ID can be found by looking at the URL inside JIRA which choosing to View/Edit the security level name/description.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-JIRA-5%2B/#f-jiras-issue-key-field","title":"f) JIRA's Issue Key Field","text":"It can be convenient to create a SpiraTeam custom property to store the JIRA Issue Key (the ID used to identify an issue in JIRA). This allows you to display a list of incients in SpiraTest and see the corresponding JIRA ID in the same list. You first need to create an incident custom property in SpiraTeam of type 'TEXT' that will be used to store the JIRA issue key within SpiraTeam.
Then click on the hyperlink of this new list custom property under Incident Custom Properties to bring up the custom property mapping configuration screen:
All you need to do on this screen is enter the word \"JiraIssueKey\" in the External Key textbox and the data-sync plug-in will know that this custom property is mapped to the built-in Issue Key field in JIRA.
Once you have updated the various mapping sections, you are now ready to use the integration.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-JIRA-5%2B/#using-spirateam-with-jira","title":"Using SpiraTeam with JIRA","text":"Now that the integration service has been configured and the service started, initially any incidents created in SpiraTeam for the specified projects will be imported into JIRA and any existing issues in JIRA will get loaded into SpiraTeam as either incidents or requirements (depending on your configuration).
At this point we recommend opening the Windows Event Viewer and choosing the Application Log. In this log any error messages raised by the SpiraTeam Data Sync Service will be displayed. If you see any error messages at this point, we recommend immediately stopping the SpiraTeam service and checking the various mapping entries. If you cannot see any issues with the mapping information, we recommend sending a copy of the event log message(s) to Inflectra customer services (support@inflectra.com) who will help you troubleshoot the problem.
To use SpiraTeam with JIRA on an ongoing basis, we recommend the following general processes be followed:
When running tests in SpiraTest or SpiraTeam, defects found should be logged through the Test Execution Wizard as normal.
Developers can log new defects into either SpiraTeam or JIRA. In either case they will get loaded into the other system.
Once created in one of the systems and successfully replicated to the other system, the incident should not be modified again inside SpiraTeam
At this point, the incident should not be acted upon inside SpiraTeam and all data changes to the issue should be made inside JIRA. To enforce this, you should modify the workflows set up in SpiraTeam so that the various fields are marked as inactive for all the incident statuses other than the \"New\" status. This will allow someone to submit an incident in SpiraTeam, but will prevent them making changes in conflict with JIRA after that point.
As the issue progresses through the customized JIRA workflow, changes to the type of issue, changes to its status, priority, description and resolution will be updated automatically in SpiraTeam. In essence, SpiraTeam acts as a read-only viewer of these incidents.
You are now able to perform test coverage and incident reporting inside SpiraTest/SpiraTeam using the test cases managed by SpiraTest/SpiraTeam and the incidents managed on behalf of SpiraTest/SpiraTeam inside JIRA.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-Jira-Cloud/","title":"Using SpiraPlan with Jira Cloud","text":""},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-Jira-Cloud/#introduction","title":"Introduction","text":"By integrating SpiraTest, SpiraTeam or SpiraPlan (SpiraPlan from here on) and Jira Cloud your teams can work seamlessly across both applications.
For example, the quality assurance team can manage their requirements and test cases in SpiraPlan, and execute test runs in SpiraPlan. Incident generated during testing wil be automatically loaded into JIRA as new issues. The development team, working in Jira, can then manage the lifecycle of these issues in JIRA. When they change the issue status or add comments, these changes are quickly updated to match back in SpiraPlan. You can choose which sort of Jira issues are made into incidents in SpiraPlan, and which get created as requirements (based on the issue type). This can be used as part of the planning and testing lifecycle.
With this integration you can, for each project/product you want to sync up:
Prerequisites: The Jira Cloud plugin supports SpiraPlan v5.0 or later and the most recent version of Jira cloud hosted by Atlassian. For Jira Server, we have an alternate Jira Server plugin available.
DO THIS FIRST
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-Jira-Cloud/#set-up-the-data-synchronization","title":"Set up the data synchronization","text":"STOP! Please make sure you have first read the instructions to set up the data sync before proceeding!
Once you have completed the above you are ready to start configuring the plug-in.
You must also have a working installation of SpiraPlan and a cloud subscription to Jira.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-Jira-Cloud/#configuring-the-plug-in","title":"Configuring the Plug-In","text":"Now that the data synchronization service / application itself is set up, we are ready to move to the next step.
Now you need to configure the Jira integration to let you:
To do this, you need to tell SpiraPlan how to access your JIRA instance. Inside SpiraPlan, go to the Administration page and navigate to Integration > Data Synchronization. Check if you see a plug-in called JiraDataSync, as shown below:
What do if the plug-in is not there
If you don't see the plug-in in the list, click the \"\"Add\" button at the top of the page. This opens the generic Data Sync plug-in details page. This is not yet customized to help you more easily set up the data sync. We recommend, adding just enough information now to create the plug-in. Then edit the plug-in after its made to complete the process.
To start, fill in the following fields:
Now click \"Add\" to save the plug-in and return you to the list of plug-ins. Now follow the instructions below.
With the plug-in place, click on its \"edit\" button to open its detailed settings page.
You need to fill out the following fields for the JIRA Plug-in to operate correctly:
Auto-Map Users: This changes the way that the plugin maps users in SpiraPlan to those in JIRA:
Severity/Est. Points Field: This is used to specify the value(s) for Spira Incident Severity and/or Requirement Estimate Points based on JIRA custom properties . Please enter the Jira custom property IDs separated by a comma. Both fields are optional, but if you want to skip one, please enter it as 0. This can be left empty for now and will be discussed below in Configuring the Data Mapping.
Sync Direction: This determines how the synchronization of incidents works:
Requirement Types: This should be set to a comma-separated list of IDs of any JIRA issue types that you want to be synchronized with SpiraPlan requirements instead of incidents. If you leave this blank, all JIRA issue types will be synchronized with incidents (user stories/epics will not be synced at all).
Info
For most users, we recommend leaving these fields blank: \"Severity/Est. Points Field\"; \"Task Types\"; and \"Sync Direction\". Leave \"Requirement Types\" blank if you do not want sync user stories/requirements.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-Jira-Cloud/#configuring-the-data-mapping","title":"Configuring the Data Mapping","text":"Next, you need to configure the data mapping between SpiraPlan and JIRA. This allows the various products, users, releases, incident types, statuses, priorities and custom property values used in the two applications to be related to each other. This is important, as without a correct mapping, there is no way for the integration service to know that an \"Enhancement\" in SpiraPlan is the same as a \"New Feature\" in JIRA (for example).
The following mapping information needs to be setup in SpiraPlan:
Each of these is explained in turn below. However, to make the data mapping process easier, we have a helpful utility that will help you connect to your JIRA instance (both cloud or server) and determine the matching IDs for the various fields in JIRA:
You can download it from this URL: https://www.inflectra.com/Downloads/JiraConfigurationHelper.zip
Once you have downloaded and unzipped the program, run the JiraConfigurationHelper.exe and the following screen will be displayed:
Enter in the URL, login and password/API Key for your JIRA instance and click Connect:
Choose the project in JIRA that you will be connecting to SpiraPlan and then the list of issue types, issue statuses, issue priorities, components, versions and custom fields will be displayed. We will be using this tool later on when you want to get some of the ID values to populate in SpiraPlan .
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-Jira-Cloud/#configuring-the-project-mapping","title":"Configuring the Project Mapping","text":"From the data synchronization administration page, you need to click on the \"View Product Mappings\" hyperlink next to the JIRA plug-in name. This will take you to the data-mapping home page for the currently selected product:
If the project name does not match the name of the project you want to configure the data-mapping for, click on the \"(Change Project)\" hyperlink to change the current product.
To enable this project for data-synchronization with JIRA, you need to enter:
Click \"Update\" to confirm these settings. Once you have enabled the product for data-synchronization, you can now enter the other data mapping values outlined below.
Info
One SpiraPlan product can only be mapped to one Jira project, in other words it is a one-to-one mapping.
Once you have successfully configured the product, when creating a new product, you should choose the option to \"Create product from Existing product\" rather than \"Use Default Template\" so that all the product mappings get copied across to the new product.***
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-Jira-Cloud/#configuring-the-user-mapping","title":"Configuring the User Mapping","text":"If you have set the \"Auto-Map Users\" option in the JIRA plugin, you can skip this section completely.
To configure the mapping of users in the two systems, you need to go to Administration > Users > View Edit Users, which will bring up the list of users in the system. Then click on the \"Edit\" button for a particular user that will be editing issues in JIRA:
Click on the 'Data Mapping' tab to list all the configured data-synchronization plug-ins for this user.
In the text box next to the JIRA Data-Sync plug-in entry, you need to enter one of the following Jira user identifiers to allow the data-synchronization plug-in to know which user in SpiraPlan match which equivalent user in Jira:
Email Address
You can enter in the email address of the user in Jira. This will only work if the user has set their user profile to be public.
This requires that the profile has its email address visibility set to Anyone inside Jira
Atlassian AccountID
You can enter in the corresponding Atlassian AccountID value into this field. This will work regardless of whether the user's profile is public or private.
Click Save once you've entered the appropriate user identifier name.
Repeat the above steps for each user who is active in both systems.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-Jira-Cloud/#configuring-the-release-mapping","title":"Configuring the Release Mapping","text":"When the data-synchronization service runs, when it comes across a release/iteration in SpiraPlan that it has not seen before, it will create a corresponding \"Version\" in JIRA. Similarly, if it comes across a new Version in JIRA that it has not seen before, it will create a new Release in SpiraPlan. Therefore, when using both systems together, it is recommended that you only enter new Releases/Versions in one system and let the data-synchronization service add them to the other system.
However, you may start out with the situation where you already have pre-existing Releases/Version in both systems that you need to associate in the data-mapping. If you don't do this, you may find that duplicates get created when you first enable the data-synchronization service. Therefore, for any Releases/Iterations that already exist in BOTH systems please navigate to Planning > Releases and click on the Release/Iteration in question. Make sure you have the 'Overview' tab visible and expand the \"Details\" section of the release/iteration:
In addition to the standard fields and custom properties, you will see an additional text property called \"Jira ID\" that is used to store the mapped external identifier for the equivalent Version in JIRA. You need to locate the ID of the equivalent version in JIRA, enter it into this text-box and click [Save]. You should now repeat for all the other pre-existing releases.
The JIRA ID can be found using the Jira Configuration Helper using the Versions tab:
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-Jira-Cloud/#configuring-the-standard-field-mapping","title":"Configuring the Standard Field Mapping","text":"Now that the products, users and releases have been mapped correctly, we need to configure the standard incident and requirement fields. To do this, go to Administration > System > Data Synchronization and click on the \"View Product Mappings\" for the JiraDataSync plug-in entry:
From this screen, you need to click on Priority, Severity, Component, Status and Type in turn to configure the incident field mappings. If you're using the option to have JIRA also synchronize some issue types as requirements, then you'll need to also configure the Requirement Importance, Type, Component and Status fields.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-Jira-Cloud/#a-incident-type","title":"a) Incident Type","text":"Click on the \"Type\" hyperlink under Incident Standard Fields to bring up the Incident type mapping configuration screen:
The table lists each of the incident types available in SpiraPlan and provides you with the ability to enter the matching JIRA issue type ID for each one. You can map multiple SpiraPlan fields to the same JIRA fields (e.g. Bug and Incident in SpiraPlan are both equivalent to Bug in JIRA), in which case only one of the two values can be listed as Primary = Yes as that's the value that's used on the reverse synchronization (from JIRA to SpiraPlan).
The JIRA ID can be found by using the Issue Types tab of the Jira configuration helper:
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-Jira-Cloud/#b-incident-status","title":"b) Incident Status","text":"Click on the \"Status\" hyperlink under Incident Standard Fields to bring up the Incident status mapping configuration screen:
The table lists each of the incident statuses available in SpiraPlan and provides you with the ability to enter the matching JIRA issue status ID for each one. You can map multiple SpiraPlan fields to the same JIRA fields (e.g. New and Open in SpiraPlan are both equivalent to Open in JIRA), in which case only one of the two values can be listed as Primary = Yes as that's the value that's used on the reverse synchronization (from JIRA to SpiraPlan).
We recommend that you always point the New and Open statuses inside SpiraPlan to point to the ID for \"Open\" inside JIRA and make Open in SpiraPlan the Primary status of the two. This is recommended so that as new incidents in SpiraPlan get synched over to JIRA, they will get switched to the Open status in JIRA which will then be synched back to \"Open\" in SpiraPlan. That way you'll be able to see at a glance which incidents have been synched with JIRA and those that haven't.
The JIRA ID can be found by using the Issue Statuses tab of the Jira configuration helper:
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-Jira-Cloud/#c-incident-priority","title":"c) Incident Priority","text":"Click on the \"Priority\" hyperlink under Incident Standard Fields to bring up the Incident Priority mapping configuration screen:
The table lists each of the incident priorities available in SpiraPlan and provides you with the ability to enter the matching JIRA priority ID for each one. You can map multiple SpiraPlan fields to the same JIRA fields, in which case only one of the two values can be listed as Primary = Yes as that's the value that's used on the reverse synchronization (from JIRA to SpiraPlan).
The JIRA ID can be found by using the Issue Priorities tab of the Jira configuration helper:
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-Jira-Cloud/#d-incident-component-optional","title":"d) Incident Component (Optional)","text":"Click on the \"Component\" hyperlink under Incident Standard Fields to bring up the Incident component mapping configuration screen:
The table lists each of the components available in SpiraPlan and provides you with the ability to enter the matching JIRA component ID for each one. You can map multiple SpiraPlan fields to the same JIRA fields, in which case only one of the two values can be listed as Primary = Yes as that's the value that's used on the reverse synchronization (from JIRA to SpiraPlan).
The JIRA ID can be found by using the Components tab of the Jira configuration helper:
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-Jira-Cloud/#e-incident-severity-optional","title":"e) Incident Severity (Optional)","text":"Click on the \"Severity\" hyperlink under Incident Standard Fields to bring up the Incident severity mapping configuration screen:
Unlike the other incident standard fields, JIRA doesn't actually have a built-in field for storing the severity of an issue, so if you want to be able to see the SpiraPlan incident severity in JIRA, you'll need to create a JIRA custom list field to store the different severity values. If you don't want to synchronize severity values with JIRA, you can skip the rest of this section.
Once you have created a custom field in JIRA to contain the list of severity values, you need to now populate the above table with the name (Not the ID) of the severity custom property values inside JIRA and click Update. Secondly you need to go to the Plug-in configuration screen:
On this screen you need to enter the ID of the custom field that you're using to store severities in JIRA and populate the \"Severity/Est. Points\" property with this value (see above). The ID can be found by using the Custom Fields tab of the Jira Configuration Helper:
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-Jira-Cloud/#f-requirement-status-optional","title":"f) Requirement Status (Optional)","text":"Click on the \"Status\" hyperlink under Requirement Standard Fields to bring up the Requirement status mapping configuration screen:
The table lists each of the requirement statuses available in SpiraPlan and provides you with the ability to enter the matching JIRA issue status ID for each one. You can map multiple SpiraPlan fields to the same JIRA fields, in which case only one of the two values can be listed as Primary = Yes as that's the value that's used on the reverse synchronization (from JIRA to SpiraPlan).
The JIRA ID can be found by using the Issue Statuses tab of the Jira configuration helper. Please note, in Jira there are 5 default levels of Issue Priority, and only 4 (by default - this can be changed) in SpiraPlan.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-Jira-Cloud/#g-requirement-importance-optional","title":"g) Requirement Importance (Optional)","text":"Click on the \"Importance\" hyperlink under Requirement Standard Fields to bring up the Requirement Importance mapping configuration screen:
The table lists each of the requirement importances available in SpiraPlan and provides you with the ability to enter the matching JIRA priority ID for each one. You can map multiple SpiraPlan fields to the same JIRA fields, in which case only one of the two values can be listed as Primary = Yes as that's the value that's used on the reverse synchronization (from JIRA to SpiraPlan).
The JIRA ID can be found by using the Issue Priorities tab of the Jira configuration helper:
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-Jira-Cloud/#h-requirement-type-optional","title":"h) Requirement Type (Optional)","text":"Click on the \"Type\" hyperlink under Requirement Standard Fields to bring up the Requirement type mapping configuration screen:
The table lists each of the requirement types available in SpiraPlan and provides you with the ability to enter the matching JIRA issue type ID for each one. You can map multiple SpiraPlan fields to the same JIRA fields (e.g. Use Case and User Story in SpiraPlan are both equivalent to User Story in JIRA), in which case only one of the two values can be listed as Primary = Yes as that's the value that's used on the reverse synchronization (from JIRA to SpiraPlan).
The JIRA ID can be found by using the Issue Types tab of the Jira configuration helper:
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-Jira-Cloud/#i-requirement-component-optional","title":"i) Requirement Component (Optional)","text":"Click on the \"Component\" hyperlink under Requirement Standard Fields to bring up the Requirement component mapping configuration screen:
The table lists each of the components available in SpiraPlan and provides you with the ability to enter the matching JIRA component ID for each one. You can map multiple SpiraPlan fields to the same JIRA fields, in which case only one of the two values can be listed as Primary = Yes as that's the value that's used on the reverse synchronization (from JIRA to SpiraPlan).
The JIRA ID can be found by using the Components tab of the Jira configuration helper:
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-Jira-Cloud/#j-requirement-estimate-points-optional","title":"j) Requirement Estimate Points (Optional):","text":"To sync Estimate Points for Requirements in Spira, make sure you added Estimates to your Jira issues as Story points or have a numeric custom property in Jira to map against. Use the Configuration Helper tool to find its ID (under the 'Custom Fields' tab). Enter this ID in Spira, as the second attribute (after a comma ',') of the \"Severity/Est. Points Field\" on the DataSync configuration page. For example: '10001,10033' where 10001 is the Incident Severity property ID in Jira and 10033 is the field we are configuring, the Estimate Points property ID in Jira. Make sure this field was created as a numeric field in Jira, otherwise the sync won't happen.
Click on the \"Status\" hyperlink under Task Standard Fields to bring up the Task status mapping configuration screen:
The table lists each of the task statuses available in SpiraPlan and provides you with the ability to enter the matching JIRA issue status ID for each one. You can map multiple SpiraPlan fields to the same JIRA fields, in which case only one of the two values can be listed as Primary = Yes as that's the value that's used on the reverse synchronization (from JIRA to SpiraPlan).
The JIRA ID can be found by using the Issue Statuses tab of the Jira configuration helper. Please note, in Jira there are 5 default levels of Issue Priority, and only 4 (by default - this can be changed) in SpiraPlan.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-Jira-Cloud/#l-task-priority-optional","title":"l) Task Priority (Optional)","text":"Click on the \"Priority\" hyperlink under Task Standard Fields to bring up the Task Priority mapping configuration screen:
The table lists each of the task priorities available in SpiraPlan and provides you with the ability to enter the matching JIRA priority ID for each one. You can map multiple SpiraPlan fields to the same JIRA fields, in which case only one of the two values can be listed as Primary = Yes as that's the value that's used on the reverse synchronization (from JIRA to SpiraPlan).
The JIRA ID can be found by using the Issue Priorities tab of the Jira configuration helper:
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-Jira-Cloud/#m-task-type-optional","title":"m) Task Type (Optional)","text":"Click on the \"Type\" hyperlink under Task Standard Fields to bring up the Task type mapping configuration screen:
The table lists each of the task types available in SpiraPlan and provides you with the ability to enter the matching JIRA issue type ID for each one. You can map multiple SpiraPlan fields to the same JIRA fields (e.g. Management and Other in SpiraPlan are both equivalent to Task in JIRA), in which case only one of the two values can be listed as Primary = Yes as that's the value that's used on the reverse synchronization (from JIRA to SpiraPlan).
The JIRA ID can be found by using the Issue Types tab of the Jira configuration helper:
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-Jira-Cloud/#configuring-the-custom-property-mapping","title":"Configuring the Custom Property Mapping","text":"Now that the various SpiraPlan standard fields have been mapped correctly, we need to configure the custom property mappings. This is used for both custom properties in SpiraPlan that map to custom fields in JIRA and also for custom properties in SpiraPlan that are used to map to standard fields in JIRA (Environment, Resolution and SecurityLevel) that don't exist in SpiraPlan.
From the View/Edit Product Data Mapping screen, you need to click on the name of the Incident or Requirement Custom Property that you want to add data-mapping information for. We will consider the four different types of mapping that you might want to enter:
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-Jira-Cloud/#a-scalar-custom-properties","title":"a) Scalar Custom Properties","text":"This refers to custom properties that have a simple user-entered value and don't need to have their specific options mapped between SpiraPlan and JIRA. All of the custom property types except List and Multi-List fall into this category (e.g. Text, Date, User, Boolean, Decimal, Integer, etc.)
Click on the hyperlink of the scalar custom property under Incident/Requirement Custom Properties to bring up the custom property mapping configuration screen. For scalar custom properties, there will be no values listed in the lower half of the screen.
You need to lookup the ID of the custom field in JIRA that matches this custom property in SpiraPlan. Once you have entered the id of the custom field, click [Update].
The ID can be found by using the Custom Fields tab of the Jira Configuration Helper:
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-Jira-Cloud/#b-list-custom-properties","title":"b) List Custom Properties","text":"This refers to custom properties that are either of type List or Multi-List (in Jira called cascading, multiple choice or single choice).
Click on the hyperlink of the list custom property under Incident/Requirement Custom Properties to bring up the custom property mapping configuration screen. For list custom properties there will be a textbox for both the custom field itself and a mapping table for each of the custom property values that need to be mapped:
First you need to lookup the ID of the custom field in JIRA that matches this custom property in SpiraPlan. This should be entered in the 'External Key' field below the name of the custom property. The ID can be found by using the Custom Fields tab of the Jira Configuration Helper:
Next for each of the Property Values in the table (in the lower half of the page) you need to enter the full name (not the id this time) of the custom field value as specified in JIRA:
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-Jira-Cloud/#c-jiras-resolution-field","title":"c) JIRA's Resolution Field","text":"If you would like the values of the JIRA 'Resolution' field to be synchronized back to SpiraPlan, then you will need to fill out this section. You first need to create an incident custom property in SpiraPlan of type 'LIST' that contains the various resolution names that exist inside JIRA.
Then click on the hyperlink of this new list custom property under Incident Custom Properties to bring up the custom property mapping configuration screen:
First you need to enter the word \"Resolution\" as the External Key of the custom property. This tells the data-sync plug-in that the custom property in SpiraPlan should be mapped to built-in Resolution field in JIRA.
Next for each of the Property Values in the table (in the lower half of the page) you need to enter the JIRA ID of the various Resolutions that are configured in JIRA. The external ID can be found by looking at the URL inside JIRA which choosing to View/Edit the resolution name/description.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-Jira-Cloud/#d-jiras-environment-field","title":"d) JIRA's Environment Field","text":"If your instance of JIRA requires that all new issues are submitted with an 'Environment' description specified, then you will need to fill out this section. You first need to create an incident custom property in SpiraPlan of type 'TEXT' that will be used to store the environment description within SpiraPlan.
Then click on the hyperlink of this new list custom property under Incident Custom Properties to bring up the custom property mapping configuration screen:
All you need to do on this screen is enter the word \"Environment\" in the External Key textbox and the data-sync plug-in will know that this custom property is mapped to the built-in Environment field in JIRA.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-Jira-Cloud/#e-jiras-security-level-field","title":"e) JIRA's Security Level Field","text":"If your instance of JIRA requires that all new issues are submitted with a 'Security Level' then you will need to fill out this section. You first need to create an incident custom property in SpiraPlan of type 'LIST' that contains the various security levels that exist inside JIRA.
Then click on the hyperlink of this new list custom property under Incident Custom Properties to bring up the custom property mapping configuration screen.
First you need to enter the word \"SecurityLevel\" as the External Key of the custom property. This tells the data-sync plug-in that the custom property in SpiraPlan should be mapped to built-in Security Level field in JIRA.
Next for each of the Property Values in the table (in the lower half of the page) you need to enter the JIRA ID of the various Security Levels that are configured in JIRA. The external ID can be found by looking at the URL inside JIRA which choosing to View/Edit the security level name/description.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-Jira-Cloud/#f-jiras-issue-key-field","title":"f) JIRA's Issue Key Field","text":"To see the Jira ID on the Incident list page you need to create a SpiraPlan custom property to store the JIRA Issue Key (the ID used to identify an issue in JIRA). The Jira DataSync id field will always show up on the details page, but not the list page. So if you wish to see the Jira ID on the list page follow these steps:
Now that all the mappings are done, you are now ready to use the integration.
Once the data sync service starts, at first any incidents created in SpiraPlan for the specified products will be imported into JIRA and any existing issues in JIRA get loaded into SpiraPlan as either incidents or requirements (depending on your configuration). Please note that links between Jira issues will be imported as Requirements associations.
Checking the logs
At this point we recommend checking the event log for any errors or useful messages.
If you see any error messages, we recommend immediately stopping data-sync and checking the various mapping entries. If you cannot see any issues with the mapping information, we recommend sending a full copy of the event log message(s) to Inflectra customer services who will help you troubleshoot the problem.
To use SpiraPlan with JIRA on an ongoing basis, we recommend:
You are now able to perform test coverage and incident reporting inside SpiraPlan /SpiraPlan using the test cases managed by SpiraPlan /SpiraPlan and the incidents managed on behalf of SpiraPlan /SpiraPlan inside JIRA.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-Jira-Cloud/#jiras-issue-key-field","title":"JIRA's Issue Key Field","text":"SpiraPlan automatically stores the unique id for each Jira issue that syncs with a SpiraPlan artifact. This field is visible on the artifact details page, in the \"Properties\" section. The field in SpiraPlan will be named based off plugin name in System Admin > Data Synchronization. The unique key in this field matches the one you will see in Jira for an issue:
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-Jira-Cloud/#using-the-jira-cloud-connector","title":"Using the Jira Cloud Connector","text":"Once you have the data-synchronization established between SpiraPlan and Jira Cloud, we have an additional Atlassian marketplace connector that you can use (see https://marketplace.atlassian.com/apps/1218742/spiratest-app-for-jira):
You can install the connector by following these instructions:
Please enter the following information:
You can get the SpiraPlan API Key from within the User Profile screen of SpiraPlan :
What to do if you cannot connect
If you get a message in the connector on a user story saying that it can't connect, please try the following:
SaveThis section outlines how to use SpiraTest, SpiraPlan or SpiraTeam (hereafter referred to as SpiraTeam) in conjunction with the Mantis issue tracking system. The built-in integration service allows the quality assurance team to manage their requirements and test cases in SpiraTeam, execute test runs in SpiraTest, and then have the new incidents generated during the run be automatically loaded into Mantis.
Once the incidents are synchronized into Mantis, the development team can then manage the issues in Mantis and have the status changes and additional notes entered in Mantis be reflected back in SpiraTeam. In addition, any new issues logged into mantis will get imported into SpiraTeam so that they can be linked to test cases and requirements.
Set up data synchronization
STOP! Please make sure you have first read the instructions to set up the data sync before proceeding!
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-Mantis/#configuring-the-plug-in","title":"Configuring the Plug-In","text":"The next step is to configure the plug-in within SpiraTeam so that the system knows how to access the Mantis server. To start the configuration, open up SpiraTeam in a web browser, log in using a valid account that has System-Administration level privileges and click on the System > Data Synchronization administration option from the left-hand navigation:
This screen lists all the plug-ins already configured in the system. Depending on whether you chose the option to include sample data in your installation or not, you will see either an empty screen or a list of sample data-synchronization plug-ins.
If you already see an entry for MantisDataSync you should click on its \"Edit\" link. If you don't see such an entry in the list, please click on the [Add] button instead. In either case you will be taken to the following screen where you can enter or modify the Mantis Data-Synchronization plug-in:
You need to fill out the following fields for the Mantis Plug-in to operate correctly:
Name -- this needs to be set to MantisDataSync. This needs to match the name of the plug-in DLL assembly that was copied into the C:\\Program Files\\SpiraTeam\\Bin folder (minus the .dll file extension). If you renamed the MantisDataSync.dll file for any reason, then you need to change the name here to match.
Description -- this should be set to a description of the plug-in. This is an optional field that is used for documentation purposes and is not actually used by the system.
Connection Info -- this should the URL that you use to access your instance of Mantis (e.g. https://www.mycompany.com/bugs)
Login -- this should be set to a valid login to the Mantis installation. The login needs to have permissions to create and view issues and versions within Mantis for the projects that you will be syncing to SpiraTeam.
Password -- this should be set to the password of the login specified above.
Time Offset -- The time offset between the two servers, if the Mantis server is on a different server than SpiraTeam. For example, if the Mantis server's clock is set to Pacific Standard Time (PST) and the SpiraTeam server is set to Eastern Standard Time (EST), the Mantis server would be three hours behind SpiraTeam, so you would need to put -3 into this field.
Auto-Map Users -- If enabled and a mapped user is not found between the two systems, a search will be made comparing logins between SpiraTeam and Mantis for matching UserIDs. If one is found, than that user will be used. If not enabled and a match is not found, then the UserID used will be the connecting user for the Data Sync. (The SpiraTeam User for issues coming into SpiraTeam, and the Mantis Login for issues imported into Mantis.)
Custom 01 -- This field specifies whether or not a Resolution item in SpiraTeam, or a Note item in Mantis will be created when an issue is created in either system for a new issue. Valid values are True or False. Default (or blank) is True.
Custom 02 -- This field indicates whether or not to convert Carriage Returns and spaces in Mantis issues when synchronizing them into SpiraTeam. If enabled, then carriage returns will be converted to HTML breaks, and multiple spaces will be converted to non-breaking spaces to preserve formatting when importing into SpiraTeam. If disabled, then carriage returns and spaces will be left as-is. Valid values are True or False. Default (or blank) is True.
Custom 03 -- This field is only used when 'Auto-Map Users' is enabled and for Incidents synchronized from SpiraTeam into Mantis. If enabled, and the Auto-Map User did not find a user with a matching Login ID, then the Login ID will be set to the User in Spira, even if that user may not exist in Mantis. Depending on Mantis configuration, the user may be accepted, or it may default back to the Mantis UserID that the Data Sync runs under. Valid values are True or False. Default (or blank) is False.
Custom 04 -- If enabled, this option specifies whether or not to append the \"Additional Information\" and \"Steps To Reproduce\" fields to the end of the Description field in Spira. During transfer of new issues from Mantis to SpiraTeam, the Description field in SpiraTeam will consist of the Description field in Mantis appended by the Additional Information field in Mantis, and finally the Steps To Reproduce field in Mantis. If this option is disabled, only the Description will be transferred over. Valid values are True or False. Default (or blank) is False.
Custom 05 -- This is not currently used by the MantisDataSync, and can be left blank.
Next, you need to configure the data mapping between SpiraTeam and Mantis. This allows the various projects, users, releases, incident types, statuses, priorities and custom property values used in the two applications to be related to each other. This is important, as without a correct mapping, there is no way for the integration service to know that an \"Enhancement\" in SpiraTeam is the same as a \"Feature\" in Mantis (for example).
The following mapping information needs to be setup in SpiraTeam:
The linking between the project in SpiraTeam and the project in Mantis.
The linking of users between the two systems.
The linking of releases between the two systems.
The linking of standard SpiraTeam fields to Mantis fields.
The linking of custom SpiraTeam fields to Mantis custom fields.
Each of these is explained in turn below:
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-Mantis/#configuring-the-project-mapping","title":"Configuring the Project Mapping","text":"While working in the project you want to map, from the data synchronization administration page you need to click on the \"View Project Mappings\" hyperlink next to the Mantis plug-in name. This will take you to the data-mapping overview page:
If the project name does not match the name of the project you want to configure the data-mapping for, click on the \"(Change Project)\" hyperlink to change the current project.
To enable this project for data-synchronization with Mantis, you need to enter:
External Key -- This should be set to the ID of the project in Mantis. To get the ID of the Project in Mantis, log in as an administrator and go to Manage -> Manage Projects:
Then hover the mouse over the project name. The project ID will be displayed in the URL line as project_id=X where X is the numeric ID of the project.
Active Flag -- Set this to 'Yes' so that SpiraTeam knows that you want to synchronize data for this project. Once the project has been completed, setting the value to \"No\" will stop data synchronization, reducing network utilization.
Click [Update] to confirm these settings. Once you have enabled the project for data-synchronization, you can now enter the other data mapping values outlined below.
Note: Once you have successfully configured the project, when creating a new project, you should choose the option to \"Create Project from Existing Project\" rather than \"Use Default Template\" so that all the project mappings get copied across to the new project, if you are going to want to Sync the new project up to Mantis.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-Mantis/#configuring-the-user-mapping","title":"Configuring the User Mapping","text":"To configure the mapping of users in the two systems, you need to go to Administration > Users > View Edit Users, which will bring up the list of users in the system. Then click on the \"Edit\" button for a particular user that will be editing issues in Mantis:
You will notice that below the Active flag for the user is a list of all the configured data-synchronization plug-ins. In the text box next to the MantisDataSync ID you need to enter the Login ID of this user in Mantis. If you have the \"Automap Users\" checkbox enabled in the MantisDataSync plugin, then if no link is created, the system will scan for a matching Login ID from both systems and use a match. (If you then do not have Custom3 set to \"False\", then for data going into Mantis the User ID will be forced to that of the User ID in SpiraTeam.)
Once you have entered the Mantis Login ID in, click [Update]. You should now repeat for the other users who will be active in both systems.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-Mantis/#configuring-the-release-mapping","title":"Configuring the Release Mapping","text":"When the data-synchronization service runs and it comes across a release in SpiraTeam (or a Version in Mantis) that it has not linked before, it will create a corresponding entry in the other system. When starting out a new project, it is recommended that you let the MantisDataSync handle creation of the releases/versions in either system, and then edit the information once the link is made.
In cases where you are syncing up two existing projects in both systems, it is advised that you link any existing releases that exist in both systems manually, and then only create new releases in one system. To link a release in SpiraTeam up to a version in Mantis, please navigate to Planning > Releases and click on the Release/Iteration in question. Make sure you have the 'Overview' tab visible and expand the \"Details\" section of the release/iteration:
In addition to the standard fields and custom properties configured for Releases, you will see an additional text property called \"MantisDataSync ID\" that is used to store the mapped external identifier for the equivalent Release in Mantis. The Mantis ID of a version is the string that is in the
The Mantis Release ID can be found by going to Manage -> Manage Projects -> Versions and viewing a release's details:
The Mantis Release ID is the highlighted text field. Copy and paste this into the field in SpiraTeam. Depending on your regional settings in both applications, this field will likely be case-sensitive.
For versions imported into Mantis from SpiraTeam, the Version will have an \"(S)\" appended to the name, and for versions in SpiraTeam imported from Mantis the version field of the Release will have \"(M)\" appended to the name.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-Mantis/#configuring-the-standard-field-mapping","title":"Configuring the Standard Field Mapping","text":"Now that the projects, user and releases have been mapped correctly, we need to configure the standard incident fields. To do this, go to Administration > System > Data Synchronization and click on the \"View Project Mappings\" for the MantisDataSync plug-in entry:
From this screen, you need to set up the Priority, Severity, Status, and Type fields:
a) Incident Type
The Incident Type field is optional and can be linked to the Mantis Category selection.
If you do not link values, then all issues being imported into SpiraTeam from Mantis will be set to the Default Type (as specified in the \"View/Edit Types\" screen), and issues going from SpiraTeam into Mantis will be assigned to the first Category in the list. (Usually Mantis orders them alphabetically, but this may change depending on your installation. If you do not have any Categories set-up, then issues will not transfer over and error messages will be logged.) For existing issues, updates to this field will not be transferred.
The table lists each of the incident types available in SpiraTeam and provides you with the ability to enter the matching Mantis Category for each one. The value to put in External ID is the Category text:
The Mantis Release ID is the highlighted text field. Copy and paste this into the field in SpiraTeam. Depending on your regional settings in both applications, this field will likely be case-sensitive.
You can map multiple SpiraTeam fields to the same Mantis fields (e.g. Bug and Incident in SpiraTeam are both equivalent to category \"development\" in Mantis). In a situation like this, enter in the Mantis category in both Big and Incident external keys, and decide which one will be primary. For issues coming from Mantis into SpiraTeam, the one marked Primary will be used, and for issues being created in Mantis, the same category will be used to create the issue.
b) Incident Status
The Incident Status is an optional field to be linked to the Mantis field by the same name.
If you do not link values, then defaults will be used. For issues coming from Mantis into SpiraTeam, incidents will be marked as 'New' (as defined by the \"View/Edit Status\" in Administration), and for issues being transferred to Mantis, the default is 'new'. Note that if an issue has an Owner in SpiraTeam, then the default for the new issue in Mantis is 'assigned'. For existing issues, updates to the field will not be transferred over.
The table lists each of the incident types available in SpiraTeam and provides you with the ability to enter the matching Mantis Category for each one. The values to put in External Key is any one of the Status values in Mantis. By default in Mantis, the available statuses are:
The Mantis values are in the highlighted text field. Type these into the External Key field in SpiraTeam. Depending on your regional settings in both applications, this field will likely be case-sensitive.
You can map multiple SpiraTeam fields to the same Mantis fields, just like the Incident Type above.
c) Incident Priority & Severity
The Incident Priority and Severity are optional fields that are linked to Mantis fields by the same name.
If you do not link values, then defaults will be used. For issues coming from Mantis into SpiraTeam, incidents will leave those fields undefined (unset). For issues coming from SpiraTeam into Mantis, the default priority of 'normal' and severity of 'minor' is used. For existing issues, updates to the field will not be transferred over.
The table lists each of the priorities available in SpiraTeam and provides you with the ability to enter the matching Mantis priority for each one. (The table for Severities has the same functionality.) The values to put in External Key are any one of the Priority (or Severity) values in Mantis. By default in Mantis, the available values are:
The Mantis values are in the highlighted fields above. Type these into the External Key field in SpiraTeam. Depending on your regional settings in both applications, this field will likely be case-sensitive.
You can map multiple SpiraTeam fields to the same Mantis fields, just like described in Incident Type above.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-Mantis/#configuring-the-custom-property-mapping","title":"Configuring the Custom Property Mapping","text":"Now that the various SpiraTeam standard fields have been mapped correctly, we need to configure the custom property mappings. At the moment, only custom fields in Mantis can be linked to custom fields in SpiraTeam.
From the View/Edit Project Data Mapping screen, you need to click on the name of the Incident Custom Property that you want to add data-mapping information for. Both field types in SpiraTeam can be linked up to any of the supported field types in Mantis. Linking between the two systems is done in text values only -- that means that if you have a SpiraTeam custom list, then the values that will be put into Mantis will be the strings of the list. The same works for moving fields back from Mantis. Rules for linking different field types up are as follows:
SpiraTeam 'List' to Mantis 'Enum', 'List', or 'Multiselection': For linking these types of fields together, the available values must match. For example, if you have \"Windows\" as an item in your list in SpiraTeam, then in the associated field in Mantis, \"Windows\" must be an available item as well. In instances where there is no match, then the default will be used in either system. On a Multiselection-type field, for importing back into SpiraTeam, only the first (top) selected value will be stored.
SpiraTeam 'List' to Mantis 'Numeric', 'Float', 'Date', 'Text', or 'Email': In this case, the text value of the SpiraTeam list will be assigned to the Mantis field, and values must be exact. For example, if you linked a SpiraTeam List to a Mantis Date field, the value for the List must be a valid date, like \"1/1/2010\". If any value fails the Mantis validation, the value will be ignored and the custom field will be set blank or to default. When transferring a value back from Mantis into SpiraTeam, the text must equal an available item in the custom list, or the field will be left blank.
SpiraTeam 'Text' to Mantis 'Numeric', 'Float', 'Date', 'Text', or 'Email': In this case, text will be copied over as-is. Note that in some special cases, like the number, date, and e-mail fields, Mantis may apply formatting or verification on values transferred over.
SpiraTeam 'Text' to Mantis 'Enum', 'List', or 'Multiselection': When pulling data from Mantis, the SpiraTeam custom field will be translated as the field in Mantis displays. However, when transferring data to Mantis, if the text in the SpiraTeam field does not match an available item in the lists, then Mantis may leave the field blank or set it to the default value.
a) Mapping custom fields
For a SpiraTeam test field, all you need to do is link the custom field to the custom field in Mantis. To do this, click on the name of the custom field under the \"Custom Properties\" header in the MantisDataSync Project Mappings, and you will see a screen allowing you to enter the External Key:
insert screenshot of custom map text prop screen with mapping for belowIn the External Key field, put the name of your custom field in Mantis:
Once you have updated the various mapping sections, you are now ready to use the service.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-Mantis/#using-spirateam-with-mantis_1","title":"Using SpiraTeam with Mantis","text":"Now that the integration service has been configured and the service started, initially any incidents created in SpiraTeam for the specified projects will be imported into Mantis and any existing issues in Mantis will get loaded into SpiraTeam. After the first sync, we recommend opening the Windows Event Viewer and viewing the Application Log. Any errors (unable to connect messages, invalid required field mappings) and warnings (incomplete field mappings) will be displayed. If on Server 2008/Vista or later, you can filter by the Application name \"MantisDataSync\". If you see any error messages (or warning messages that you want to correct before continuing) at this point, we recommend immediately stopping the SpiraTeam service and checking the various mapping entries. If you cannot see any issues with the mapping information, we recommend sending a copy of the event log message(s) to Inflectra customer services (support@inflectra.com) who will help you troubleshoot the problem.
To use SpiraTeam with Mantis on an ongoing basis, we recommend the following general processes be followed:
When running tests in SpiraTest or SpiraTeam, defects found should be logged through the Test Execution Wizard as normal.
Developers using Mantis can log new defects into either SpiraTeam or Mantis. In either case they will get loaded into the other system.
Once created in one of the systems and successfully replicated to the other system, the incident should not be modified again inside SpiraTeam. Since Mantis is considered the master system for incidents/issues, all data changes to the issue should be made inside Mantis. To enforce this, you should modify the workflows set up in SpiraTeam so that the various fields are marked as inactive for all the incident statuses other than the \"New\" status. This will allow someone to submit an incident in SpiraTeam, but will prevent them from making changes in conflict with Mantis after that point.
As the issue progresses in Mantis, changes to the type of issue, changes to its status, priority, description and resolution will be updated automatically in SpiraTeam. In essence, SpiraTeam acts as a read-only viewer of these incidents.
You are now able to perform test coverage and incident reporting inside SpiraTeam using the test cases managed by SpiraTeam and the incidents managed on behalf of SpiraTeam inside Mantis.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-Redmine/","title":"Using SpiraTeam with Redmine","text":"This section outlines how to use SpiraTeam in conjunction with the open-source Redmine bug-tracking and project management system. The built-in integration service allows the quality assurance team to manage their requirements and test cases in SpiraTeam, execute test runs in SpiraTeam, and then have the new incidents generated during the run be automatically loaded into Redmine. Once the incidents are loaded into Redmine as issues, the development team can then manage the lifecycle of these issues in Redmine, and have the status changes in Redmine be reflected back in SpiraTeam.
In addition, any issues logged directly into Redmine will get imported into SpiraTeam so that they can be linked to test cases and requirements.
Set up data synchronization
STOP! Please make sure you have first read the instructions to set up the data sync before proceeding!
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-Redmine/#configuring-the-plug-in","title":"Configuring the Plug-In","text":"The next step is to configure the plug-in within SpiraTeam so that the system knows how to access the Redmine server. To start the configuration, please open up SpiraTeam in a web browser, log in using a valid account that has System-Administration level privileges and click on the System > Data Synchronization administration option from the left-hand navigation:
This screen lists all the plug-ins already configured in the system. Depending on whether you chose the option to include sample data in your installation or not, you will see either an empty screen or a list of sample data-synchronization plug-ins.
If you already see an entry for RedmineDataSync you should click on its \"Edit\" link. If you don't see such an entry in the list, please click on the [Add] button instead. In either case you will be taken to the following screen where you can enter or modify the Redmine Data-Synchronization plug-in:
You need to fill out the following fields for the Redmine Plug-in to operate correctly:
Name -- this needs to be set to RedmineDataSync. This needs to match the name of the plug-in DLL assembly that was copied into the C:\\Program Files\\SpiraTeam\\Bin folder (minus the .dll file extension). If you renamed the RedmineDataSync.dll file for any reason, then you need to change the name here to match.
Description -- this should be set to a description of the plug-in. This is an optional field that is used for documentation purposes and is not actually used by the system.
Connection Info -- this should be the base URL of the Redmine installation. As an example, for the public demo installation of Redmine, it would be: http://demo.redmine.org
Login -- this should be set to a valid login to the Redmine installation -- the login needs to have permissions to create and view bugs and versions within Redmine.
Password -- this should be set to the password of the login specified above.
Time Offset -- normally this should be set to zero, but if you find that issues being changed in Redmine are not being updated in SpiraTeam, try increasing the value as this will tell the data-synchronization plug-in to add on the time offset (in hours) when comparing date-time stamps. Also if your Redmine installation is running on a server set to a different time-zone, then you should add in the number of hours difference between the servers' time-zones here.
Auto-Map Users -- This changes the way that the plugin maps users in SpiraTeam to those in Redmine:
**Auto-Map = True **With this setting, all users in SpiraTeam need to have the same username as those in Redmine. If this is the case then you do not need to perform the user-mapping task. This is a big time-saver if you can guarantee that all usernames are the same in both systems.
**Auto-Map = False **With this setting, users in SpiraTeam and Redmine are free to have different usernames because you specify the corresponding Redmine name for each user as outlined in Configuring the User Mapping.
Custom 01 -- This should be set to the word \"false\" if you want to have the plugin restrict synchronization to not create any new incidents in Spira.
Custom 02 -- This should be set to the word \"false\" if you want to have the plugin restrict synchronization to not create any new issues in Redmine.
Custom 03 -- 05 -- these are not currently used by the Redmine data-sync plug-in and can be left blank.
Next, you need to configure the data mapping between SpiraTeam and Redmine. This allows the various projects, users, releases, incident types, statuses, priorities and custom property values used in the two applications to be related to each other. This is important, as without a correct mapping, there is no way for the integration service to know that an \"Duplicate\" incident in SpiraTeam is the same as a \"Rejected\" bug in Redmine (for example).
The following mapping information needs to be setup in SpiraTeam:
The mapping of the project identifiers for the projects that need to be synchronized
The mapping of users in the system
The mapping of releases (equivalent to Redmine versions) in the system
The mapping of the various standard fields in the system
The mapping of the various custom properties in the system
Each of these is explained in turn below:
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-Redmine/#configuring-the-project-mapping","title":"Configuring the Project Mapping","text":"From the data synchronization administration page, you need to click on the \"View Project Mappings\" hyperlink next to the Redmine plug-in name. This will take you to the data-mapping home page for the currently selected project:
If the project name does not match the name of the project you want to configure the data-mapping for, click on the \"(Change Project)\" hyperlink to change the current project.
To enable this project for data-synchronization with Redmine, you need to enter:
External Key -- This should be set to the name of the equivalent project in Redmine.
Active Flag -- Set this to 'Yes' so that SpiraTeam knows that you want to synchronize data for this project. Once the project has been completed, setting the value to \"No\" will stop data synchronization, reducing network utilization.
Click [Update] to confirm these settings. Once you have enabled the project for data-synchronization, you can now enter the other data mapping values outlined below.
Note: Once you have successfully configured the project, when creating a new project, you should choose the option to \"Create Project from Existing Project\" rather than \"Use Default Template\" so that all the project mappings get copied across to the new project.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-Redmine/#configuring-the-user-mapping","title":"Configuring the User Mapping","text":"To configure the mapping of users in the two systems, you need to go to Administration > Users > View Edit Users, which will bring up the list of users in the system. Then click on the \"Edit\" button for a particular user that will be editing issues in Redmine:
You will notice that in the special Data Mapping tab for the user is a list of all the configured data-synchronization plug-ins. In the text box next to the Redmine Data-Sync plug-in you need to enter the numeric ID for this user in Redmine. This will allow the data-synchronization plug-in to know which user in Redmine matches this SpiraTeam user. Click [Update] once you've entered the appropriate ID value. You should now repeat for the other users who will be active in both systems.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-Redmine/#configuring-the-release-mapping","title":"Configuring the Release Mapping","text":"Now that the projects and users have been mapped correctly, we need to configure the mapping between Releases/Iterations in SpiraTeam and Versions in Redmine. To do this, please navigate to Planning > Releases and click on the Release/Iteration in question. Make sure you have the 'Overview' tab visible and expand the \"Details\" section of the release/iteration:
In addition to the standard fields and custom properties configured for Releases, you will see an additional text property called \"RedmineDataSync ID\" that is used to store the mapped external identifier for the equivalent Version in Redmine. You need to enter the numeric ID of the equivalent version in Redmine, enter it into this text-box and click [Save]. You should now repeat for all the other releases and iterations in the project.
In addition, any Versions that have already been created in Redmine will be automatically imported into SpiraTeam if they do not already exist in SpiraTeam and they have not already been mapped.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-Redmine/#configuring-the-standard-field-mapping","title":"Configuring the Standard Field Mapping","text":"Now that the projects, user and releases have been mapped correctly, we need to configure the standard incident fields. To do this, go to Administration > System > Data Synchronization and click on the \"View Project Mappings\" for the RedmineDataSync plug-in entry:
From this screen, you need to click on Priority, Type and Status in turn to configure their values:
a) Incident Status
Click on the \"Status\" hyperlink under Incident Standard Fields to bring up the Incident status mapping configuration screen:
The table lists each of the incident statuses available in SpiraTeam and provides you with the ability to enter the matching Redmine bug status ID for each one. You can map multiple SpiraTeam fields to the same Redmine fields (e.g. Open and Assigned in SpiraTeam are both equivalent to \"In Progress\" (ID=2) in Redmine), in which case only one of the two values can be listed as Primary = Yes as that's the value that's used on the reverse synchronization (from Redmine > SpiraTeam).
b) Incident Priority
Click on the \"Priority\" hyperlink under Incident Standard Fields to bring up the Incident Priority mapping configuration screen:
The table lists each of the incident priorities available in SpiraTeam and provides you with the ability to enter the matching Redmine priority ID for each one. You can map multiple SpiraTeam fields to the same Redmine fields, in which case only one of the two values can be listed as Primary = Yes as that's the value that's used on the reverse synchronization (from Redmine > SpiraTeam).
c) Incident Type
Incident types in SpiraTeam are equivalent to Trackers in Redmine. Click on the \"Type\" hyperlink under Incident Standard Fields to bring up the Incident type mapping configuration screen:
The table lists each of the incident types available in SpiraTeam and provides you with the ability to enter the matching Redmine Tracker ID for each one. You can map multiple SpiraTeam fields to the same Redmine tracker values, in which case only one of the two values can be listed as Primary = Yes as that's the value that's used on the reverse synchronization (from Redmine > SpiraTeam).
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-Redmine/#configuring-the-custom-property-mapping","title":"Configuring the Custom Property Mapping","text":"Now that the various SpiraTeam standard fields have been mapped correctly, we need to configure the custom property mappings. This is used for custom properties in SpiraTeam that map to custom fields in Redmine. You will need to first make sure that the custom properties and associated custom lists have been created in both systems:
From the View/Edit Project Data Mapping screen, you need to click on the name of the Incident Custom Property that you want to add data-mapping information for:
We will consider the two different types of mapping that you might want to enter.
a) Scalar Custom Properties
This refers to custom properties that have a simple user-entered value and don't need to have their specific options mapped between SpiraTeam and Redmine. All of the custom property types except List and Multi-List fall into this category (e.g. Text, Date, Boolean, Decimal, Integer, etc.)
Click on the hyperlink of the scalar custom property under Incident Custom Properties to bring up the custom property mapping configuration screen. For scalar custom properties there will be no values listed in the lower half of the screen.
You need to enter the ID of the custom field in Redmine that matches this custom property in SpiraTeam. Once you have entered the id of the custom field, click [Update].
b) List Custom Properties
This refers to custom properties that are either of type List or Multi-List. Click on the hyperlink of the list custom property under Incident Custom Properties to bring up the custom property mapping configuration screen. For list custom properties there will be a textbox for both the custom field itself and a mapping table for each of the custom property values that need to be mapped:
First you need to find the ID of the custom field in Redmine that matches this custom property in SpiraTeam. This should be entered in the 'External Key' field below the name of the custom property.
Next for each of the Property Values in the table (in the lower half of the page) you need to enter the full name (not the id this time) of the custom field value as specified in Redmine.
Once you have updated the various mapping sections, you are now ready to use the service.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-Redmine/#using-spiratest-with-redmine","title":"Using SpiraTest with Redmine","text":"Now that the integration service has been configured and the service started, initially any incidents created in SpiraTeam for the specified projects will be imported into Redmine. At this point we recommend opening the Windows Event Viewer and choosing the Application Log. In this log any error messages raised by the Data Synchronization service will be displayed. If you see any error messages at this point, we recommend immediately stopping the service and checking the various mapping entries. If you cannot see any issues with the mapping information, we recommend sending a copy of the event log message(s) to Inflectra customer services (support@inflectra.com) who will help you troubleshoot the problem.
To use SpiraTeam with Redmine on an ongoing basis, we recommend the following general processes be followed:
When running tests in SpiraTeam, defects found should be logged through the Test Execution Wizard as normal.
Developers can log new defects into either SpiraTeam or Redmine. In either case they will get loaded into the other system.
Once created in one of the systems and successfully replicated to the other system, the incident should not be modified again inside SpiraTeam
All data changes to the issue should be made inside Redmine.
To enforce this, you can modify the workflows set up in SpiraTeam so that the various fields are marked as inactive for all the incident statuses other than the \"New\" status.
This will allow someone to submit an incident in SpiraTeam, but will prevent them making changes in conflict with Redmine after that point.
As the issue progresses through the Redmine workflow, changes to the status, priority, tracker, and target version will be updated automatically in SpiraTeam, and any notes added will be added to SpiraTeam as new comments. In essence, SpiraTeam acts as a read-only viewer of these incidents.
You are now able to perform test coverage and incident reporting inside SpiraTeam using the test cases managed by SpiraTeam and the incidents managed on behalf of SpiraTeam inside Redmine.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTest-with-Bugzilla/","title":"Using SpiraTest with Bugzilla","text":"This section outlines how to use SpiraTest in conjunction with the open-source Bugzilla bug tracking system. The built-in integration service allows the quality assurance team to manage their requirements and test cases in SpiraTest, execute test runs in SpiraTest, and then have the new incidents generated during the run be automatically loaded into Bugzilla. Once the incidents are loaded into Bugzilla as bugs, the development team can then manage the lifecycle of these bugs in Bugzilla, and have the status changes in Bugzilla be reflected back in SpiraTest.
In addition, if you are using Bugzilla 4.x or higher, any issues logged directly into Bugzilla will get imported into SpiraTeam so that they can be linked to test cases and requirements.
Set up data synchronization
STOP! Please make sure you have first read the instructions to set up the data sync before proceeding!
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTest-with-Bugzilla/#configuring-the-plug-in","title":"Configuring the Plug-In","text":"The next step is to configure the plug-in within SpiraTeam so that the system knows how to access the Bugzilla server. To start the configuration, please open up SpiraTeam in a web browser, log in using a valid account that has System-Administration level privileges and click on the System > Data Synchronization administration option from the left-hand navigation:
This screen lists all the plug-ins already configured in the system. Depending on whether you chose the option to include sample data in your installation or not, you will see either an empty screen or a list of sample data-synchronization plug-ins.
If you already see an entry for BugzillaDataSync you should click on its \"Edit\" link. If you don't see such an entry in the list, please click on the [Add] button instead. In either case you will be taken to the following screen where you can enter or modify the Bugzilla Data-Synchronization plug-in:
You need to fill out the following fields for the Bugzilla Plug-in to operate correctly:
Name -- this needs to be set to BugzillaDataSync. This needs to match the name of the plug-in DLL assembly that was copied into the C:\\Program Files\\SpiraTeam\\Bin folder (minus the .dll file extension). If you renamed the BugzillaDataSync.dll file for any reason, then you need to change the name here to match.
Description -- this should be set to a description of the plug-in. This is an optional field that is used for documentation purposes and is not actually used by the system.
Connection Info -- this should the full URL to the Bugzilla installation's web-service API. This is typically http://<Bugzilla server name>/xmlrpc.cgi
Login -- this should be set to a valid login to the Bugzilla installation -- typically an email address. The login needs to have permissions to create and view bugs within Bugzilla.
Password -- this should be set to the password of the login specified above.
Time Offset -- normally this should be set to zero, but if you find that issues being changed in Bugzilla are not being updated in SpiraTeam, try increasing the value as this will tell the data-synchronization plug-in to add on the time offset (in hours) when comparing date-time stamps. Also if your Bugzilla installation is running on a server set to a different time-zone, then you should add in the number of hours difference between the servers' time-zones here.
Auto-Map Users -- this is not currently used by the Bugzilla data-sync plug-in and can be ignored.
Custom 01 -- When connecting to Bugzilla, sometimes the connection gets dropped by the server without notifying the plug-in. This happens when using HTTP 1.1 Keep-Alive connections. If you set this property to \"False\", it will tell the plug-in to not-use HTTP keep-alives when connecting to Bugzilla, otherwise set it to \"True\".
Custom 02 -- When connecting to a Bugzilla instance that is running under HTTPS (SSL) this custom property can be set to determine if the plug-in should verify that the SSL certificate is a trusted root certificate. Set to \"True\" if you are using an SSL certificate that was issued by a trusted Certification Authority, and set to \"False\" if you are using a self-signed certificate.
Custom 03 -- 05 -- these are not currently used by the Bugzilla data-sync plug-in and can be left blank.
Next, you need to configure the data mapping between SpiraTeam and Bugzilla. This allows the various projects, users, releases, incident types, statuses, priorities and custom property values used in the two applications to be related to each other. This is important, as without a correct mapping, there is no way for the integration service to know that an \"Duplicate\" incident in SpiraTeam is the same as an \"UNCONFIRMED\" bug in Bugzilla (for example).
The following mapping information needs to be setup in SpiraTeam:
The mapping of the project identifiers for the projects that need to be synchronized
The mapping of users in the system
The mapping of releases (equivalent to Bugzilla versions) in the system
The mapping of the various standard fields in the system
The mapping of the various custom properties in the system
Each of these is explained in turn below:
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTest-with-Bugzilla/#configuring-the-project-mapping","title":"Configuring the Project Mapping","text":"From the data synchronization administration page, you need to click on the \"View Project Mappings\" hyperlink next to the Bugzilla plug-in name. This will take you to the data-mapping home page for the currently selected project:
If the project name does not match the name of the project you want to configure the data-mapping for, click on the \"(Change Project)\" hyperlink to change the current project.
To enable this project for data-synchronization with Bugzilla, you need to enter:
External Key -- This should be set to the name of the equivalent Product in Bugzilla.
Active Flag -- Set this to 'Yes' so that SpiraTeam knows that you want to synchronize data for this project. Once the project has been completed, setting the value to \"No\" will stop data synchronization, reducing network utilization.
Click [Update] to confirm these settings. Once you have enabled the project for data-synchronization, you can now enter the other data mapping values outlined below.
Note: Once you have successfully configured the project, when creating a new project, you should choose the option to \"Create Project from Existing Project\" rather than \"Use Default Template\" so that all the project mappings get copied across to the new project.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTest-with-Bugzilla/#configuring-the-user-mapping","title":"Configuring the User Mapping","text":"To configure the mapping of users in the two systems, you need to go to Administration > Users > View Edit Users, which will bring up the list of users in the system. Then click on the \"Edit\" button for a particular user that will be editing issues in Bugzilla:
You will notice that below the Active flag for the user is a list of all the configured data-synchronization plug-ins. In the text box next to the Bugzilla Data-Sync plug-in you need to enter the login for this username in Bugzilla. This will allow the data-synchronization plug-in to know which user in SpiraTeam match which equivalent user in Bugzilla. Click [Update] once you've entered the appropriate login name. You should now repeat for the other users who will be active in both systems.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTest-with-Bugzilla/#configuring-the-release-mapping","title":"Configuring the Release Mapping","text":"Now that the projects and users have been mapped correctly, we need to configure the mapping between Releases/Iterations in SpiraTeam and Versions in Bugzilla. To do this, please navigate to Planning > Releases and click on the Release/Iteration in question. Make sure you have the 'Overview' tab visible and expand the \"Details\" section of the release/iteration:
In addition to the standard fields and custom properties configured for Releases, you will see an additional text property called \"BugzillaDataSync ID\" that is used to store the mapped external identifier for the equivalent Version in Bugzilla. You need to enter the name of the equivalent version in Bugzilla, enter it into this text-box and click [Save]. You should now repeat for all the other releases and iterations in the project.
If you are using the plugin for Bugzilla 4.x then any Versions that have already been created in Bugzilla will be automatically imported into SpiraTeam if they do not already exist in SpiraTeam and they have not already been mapped.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTest-with-Bugzilla/#configuring-the-standard-field-mapping","title":"Configuring the Standard Field Mapping","text":"Now that the projects, user and releases have been mapped correctly, we need to configure the standard incident fields. To do this, go to Administration > System > Data Synchronization and click on the \"View Project Mappings\" for the BugzillaDataSync plug-in entry:
From this screen, you need to click on Priority, Severity and Status in turn to configure their values:
a) Incident Status
Click on the \"Status\" hyperlink under Incident Standard Fields to bring up the Incident status mapping configuration screen:
The table lists each of the incident statuses available in SpiraTeam and provides you with the ability to enter the matching Bugzilla bug status for each one. You can map multiple SpiraTeam fields to the same Bugzilla fields (e.g. New and Open in SpiraTeam are both equivalent to NEW in Bugzilla), in which case only one of the two values can be listed as Primary = Yes as that's the value that's used on the reverse synchronization (from Bugzilla > SpiraTeam).
We recommend that you always point the New and Open statuses inside SpiraTeam to point to the NEW status inside Bugzilla and make Open in SpiraTeam the Primary status of the two. This is recommended so that as new incidents in SpiraTeam get synched over to Bugzilla, they will get switched to the NEW status in Bugzilla which will then be synched back to \"Open\" in SpiraTeam. That way you'll be able to see at a glance which incidents have been synched with Bugzilla and those that haven't.
b) Incident Priority
Click on the \"Priority\" hyperlink under Incident Standard Fields to bring up the Incident Priority mapping configuration screen:
The table lists each of the incident priorities available in SpiraTeam and provides you with the ability to enter the matching Bugzilla priority for each one. You can map multiple SpiraTeam fields to the same Bugzilla fields, in which case only one of the two values can be listed as Primary = Yes as that's the value that's used on the reverse synchronization (from Bugzilla > SpiraTeam).
c) Incident Severity
Click on the \"Severity\" hyperlink under Incident Standard Fields to bring up the Incident severity mapping configuration screen:
The table lists each of the incident severities available in SpiraTeam and provides you with the ability to enter the matching Bugzilla severity for each one. You can map multiple SpiraTeam fields to the same Bugzilla fields, in which case only one of the two values can be listed as Primary = Yes as that's the value that's used on the reverse synchronization (from Bugzilla > SpiraTeam).
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTest-with-Bugzilla/#configuring-the-custom-property-mapping","title":"Configuring the Custom Property Mapping","text":"Now that the various SpiraTeam standard fields have been mapped correctly, we need to configure the custom property mappings. This is used for custom properties in SpiraTeam that are used to map to standard fields in Bugzilla (Component, Hardware, Operating System and Resolution) that don't exist in SpiraTeam. You need to make sure that you have first added custom lists in SpiraTeam that contain the list of Components, Hardware platforms and Operating Systems used in Bugzilla and that you have setup those lists as Custom Properties on the Incident artifact type.
Once that's done, from the View/Edit Project Data Mapping screen, you need to click on the name of the Incident Custom Property that you want to add data-mapping information for. We will consider the four different types of mapping that you might want to enter in turn:
a) Bugzilla's Component Field
If your instance of Bugzilla requires that all new bugs are submitted with a 'Component' then you will need to fill out this section. You first need to create an incident custom property in SpiraTeam of type 'LIST' that contains the various component names that exist inside Bugzilla.
Then click on the hyperlink of this new list custom property under Incident Custom Properties to bring up the custom property mapping configuration screen:
First you need to enter the word \"Component\" as the External Key of the custom property. This tells the data-sync plug-in that the custom property in SpiraTeam should be mapped to built-in Component field in Bugzilla.
Next for each of the Property Values in the table (in the lower half of the page) you need to enter the Bugzilla name of the various Components that are configured in Bugzilla.
b) Bugzilla's Operating System Field
If your instance of Bugzilla requires that all new issues are submitted with an 'Operating System' then you will need to fill out this section. You first need to create an incident custom property in SpiraTeam of type 'LIST' that contains the various operating system names that exist inside Bugzilla.
Then click on the hyperlink of this new list custom property under Incident Custom Properties to bring up the custom property mapping configuration screen:
First you need to enter the word \"OperatingSystem\" as the External Key of the custom property. This tells the data-sync plug-in that the custom property in SpiraTeam should be mapped to built-in Operating System field in Bugzilla.
Next for each of the Property Values in the table (in the lower half of the page) you need to enter the Bugzilla name of the various Operating System values that are configured in Bugzilla.
c) Bugzilla's Hardware Field
If your instance of Bugzilla requires that all new issues are submitted with a 'Hardware' value then you will need to fill out this section. You first need to create an incident custom property in SpiraTeam of type 'LIST' that contains the various hardware platform names that exist inside Bugzilla.
Then click on the hyperlink of this new list custom property under Incident Custom Properties to bring up the custom property mapping configuration screen:
First you need to enter the word \"Hardware\" as the External Key of the custom property. This tells the data-sync plug-in that the custom property in SpiraTeam should be mapped to built-in Hardware field in Bugzilla.
Next for each of the Property Values in the table (in the lower half of the page) you need to enter the Bugzilla name of the various Hardware platforms that are configured in Bugzilla.
d) Bugzilla's Resolution Field (Optional)
When incidents in SpiraTeam are updated with changes made in Bugzilla, the value of the Bugzilla resolution field (FIXED, INVALID, WONTFIX, LATER, REMIND, DUPLICATE, WORKSFORME, MOVED, DEPLOY) is used to populate the Resolution/Comments text box within SpiraTeam.
However the Resolution/Comments field in SpiraTeam cannot be displayed in the incident list page as it's a long text-field, so if you would like to be able to see the list of Bugzilla Resolution codes displayed in a list, it is necessary to add a TEXT custom property to Incidents that can be used to store this returned value and then be filtered in the list. The rest of this section describes how to map this text custom property so that it picks up the Resolution field values from Bugzilla.
To configure the mapping, click on the hyperlink of this new text custom property under Incident Custom Properties to bring up the custom property mapping configuration screen:
All you need to do on this screen is enter the word \"Resolution\" in the External Key textbox and the data-sync plug-in will know that this custom property is mapped to the built-in Resolution field in Bugzilla.
Once you have updated the various mapping sections, you are now ready to use the synchronization.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTest-with-Bugzilla/#using-spiratest-with-bugzilla_1","title":"Using SpiraTest with Bugzilla","text":"Now that the integration service has been configured and the service started, initially any incidents created in SpiraTeam for the specified projects will be imported into Bugzilla. At this point we recommend opening the Windows Event Viewer and choosing the Application Log. In this log any error messages raised by the Data Synchronization service will be displayed. If you see any error messages at this point, we recommend immediately stopping the service and checking the various mapping entries. If you cannot see any issues with the mapping information, we recommend sending a copy of the event log message(s) to Inflectra customer services (support@inflectra.com) who will help you troubleshoot the problem.
To use SpiraTeam with Bugzilla on an ongoing basis, we recommend the following general processes be followed:
When running tests in SpiraTeam, defects found should be logged through the 'Add Incident' option as normal.
Once an incident has been created during the running of the test, it will now be populated across into Bugzilla as a bug. It will be populated with the information captured in SpiraTeam.
At this point, the incident should not be acted upon inside SpiraTeam, and all data changes to the issue should be made inside Bugzilla. To enforce this, you can modify the workflows set up in SpiraTeam so that the various fields are marked as inactive for all the incident statuses other than the \"New\" status. This will allow someone to submit an incident in SpiraTeam, but will prevent them making changes in conflict with Bugzilla after that point.
As the issue progresses through the Bugzilla workflow, changes to the status, priority, severity, and resolution will be updated automatically in SpiraTeam. In essence, SpiraTeam acts as a read-only viewer of these incidents.
If you are using the plugin for Bugzilla 4.x, changes to the hardware, operating system and component will also be synchronized back into SpiraTeam. In addition, any comments added to the bug in Bugzilla 4.x will get added to the corresponding incident in SpiraTeam
You are now able to perform test coverage and incident reporting inside SpiraTeam using the test cases managed by SpiraTeam and the incidents managed on behalf of SpiraTeam inside Bugzilla.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTest-with-FogBugz/","title":"Using SpiraTest with FogBugz","text":"This section outlines how to use SpiraTest, SpiraPlan or SpiraTeam (hereafter referred to as SpiraTeam) in conjunction with the FogBugz issue/bug tracking system. The built-in integration service allows the quality assurance team to manage their requirements and test cases in SpiraTeam, execute test runs in SpiraTest, and then have the new incidents generated during the run be automatically loaded into FogBugz.
Once the incidents are loaded into FogBugz as cases, the development team can then manage the lifecycle of these cases in FogBugz, and have the status changes in FogBugz be reflected back in SpiraTeam. In addition, any cases logged into FogBugz will get imported into SpiraTeam so that they can be linked to test cases and requirements.
Set up data synchronization
STOP! Please make sure you have first read the instructions to set up the data sync before proceeding!
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTest-with-FogBugz/#configuring-the-plug-in","title":"Configuring the Plug-In","text":"The next step is to configure the plug-in within SpiraTeam so that the system knows how to access the FogBugz server. To start the configuration, please open up SpiraTeam in a web browser, log in using a valid account that has System-Administration level privileges and click on the System > Data Synchronization administration option from the left-hand navigation:
This screen lists all the plug-ins already configured in the system. Depending on whether you chose the option to include sample data in your installation or not, you will see either an empty screen or a list of sample data-synchronization plug-ins.
If you already see an entry for FogBugzDataSync you should click on its \"Edit\" link. If you don't see such an entry in the list, please click on the [Add] button instead. In either case you will be taken to the following screen where you can enter or modify the FogBugz Data-Synchronization plug-in:
You need to fill out the following fields for the FogBugz Plug-in to operate correctly:
Name -- this needs to be set to FogBugzDataSync. This needs to match the name of the plug-in DLL assembly that was copied into the C:\\Program Files\\SpiraTeam\\Bin folder (minus the .dll file extension). If you renamed the FogBugzDataSync.dll file for any reason, then you need to change the name here to match.
Caption -- this is the display name of the plugin, typically just \"FogBugz\". If you have multiple instances of FogBugz, they could have different captions.
Description -- this should be set to a description of the plug-in. This is an optional field that is used for documentation purposes and is not actually used by the system.
Connection Info -- this should the URL that you use to access your instance of FogBugz (e.g. https://mycompany.fogbugz.com)
Login -- this should be set to a valid login to the FogBugz installation. The login needs to have permissions to create and view cases and versions within FogBugz.
Password -- this should be set to the password of the login specified above.
Time Offset -- normally this should be set to zero, but if you find that cases being changed in FogBugz are not being updated in SpiraTeam, try increasing the value as this will tell the data-synchronization plug-in to add on the time offset (in hours) when comparing date-time stamps. Also if your FogBugz installation is running on a server set to a different time-zone, then you should add in the number of hours difference between the servers' time-zones here.
Auto-Map Users -- this is not currently used by the FogBugz data-sync plug-in and can be ignored.
Custom 01 -- When connecting to FogBugz, sometimes the connection gets dropped by the server without notifying the plug-in. This happens when using HTTP 1.1 Keep-Alive connections. If you set this property to \"False\", it will tell the plug-in to not-use HTTP keep-alives when connecting to FogBugz, otherwise set it to \"True\".
Custom 02 -- When connecting to a FogBugz instance that is running under HTTPS (SSL) this custom property can be set to determine if the plug-in should verify that the SSL certificate is a trusted root certificate. Set to \"True\" if you are using an SSL certificate that was issued by a trusted Certification Authority, and set to \"False\" if you are using a self-signed certificate.
Custom 03 -- Normally all rich text (HTML) descriptions in SpiraTeam are converted into plain text when added to FogBugz. However, more recent version of FogBugz can now support rich text. So if you have rich-text enabled in your instance of FogBugz, you should enter the world \"True\" in Custom 03 to enable rich text description transfer.
Custom 04 -- Normally you can leave this blank. However if you want to prevent the plugin from getting new cases from FogBugz (that did not originate in SpiraTest), set it to \"False\".
Custom 05 -- this is not currently used by the FogBugz data-sync plug-in and can be left blank.
Next, you need to configure the data mapping between SpiraTeam and FogBugz. This allows the various projects, users, releases, incident types, statuses, priorities and custom property values used in the two applications to be related to each other. This is important, as without a correct mapping, there is no way for the integration service to know that an \"Enhancement\" in SpiraTeam is the same as a \"Feature\" in FogBugz (for example).
The following mapping information needs to be setup in SpiraTeam:
The mapping of the project identifiers for the projects that need to be synchronized
The mapping of users in the system
The mapping of releases (equivalent to FogBugz releases/fix-fors) in the system
The mapping of the various standard fields in the system
The mapping of the various custom properties in the system
Each of these is explained in turn below:
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTest-with-FogBugz/#configuring-the-project-mapping","title":"Configuring the Project Mapping","text":"From the data synchronization administration page, you need to click on the \"View Project Mappings\" hyperlink next to the FogBugz plug-in name. This will take you to the data-mapping home page for the currently selected project:
If the project name does not match the name of the project you want to configure the data-mapping for, click on the \"(Change Project)\" hyperlink to change the current project.
To enable this project for data-synchronization with FogBugz, you need to enter:
External Key -- This should be set to the ID of the project in FogBugz. This can be found by navigating to Settings > Projects in FogBugz:
Then hover the mouse over the project name. The project ID will be displayed in the URL line as ixProject-X where X is the numeric ID of the project.
Active Flag -- Set this to 'Yes' so that SpiraTeam knows that you want to synchronize data for this project. Once the project has been completed, setting the value to \"No\" will stop data synchronization, reducing network utilization.
Click [Update] to confirm these settings. Once you have enabled the project for data-synchronization, you can now enter the other data mapping values outlined below.
Note: Once you have successfully configured the project, when creating a new project, you should choose the option to \"Create Project from Existing Project\" rather than \"Use Default Template\" so that all the project mappings get copied across to the new project.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTest-with-FogBugz/#configuring-the-user-mapping","title":"Configuring the User Mapping","text":"To configure the mapping of users in the two systems, you need to go to Administration > Users > View Edit Users, which will bring up the list of users in the system. Then click on the \"Edit\" button for a particular user that will be editing cases in FogBugz:
You will notice that below the Active flag for the user is a list of all the configured data-synchronization plug-ins. In the text box next to the FogBugz Data-Sync plug-in you need to enter the ID of this user in FogBugz. This will allow the data-synchronization plug-in to know which user in SpiraTeam match which equivalent user in FogBugz. The ID can be found in FogBugz by going to Settings > Users:
Then hover the mouse over the user's name. The user ID will be displayed in the URL line as ixPerson-X where X is the numeric ID of the user.
Back in SpiraTeam, click [Update] once you've entered the appropriate user ID in the mapping box. You should now repeat for the other users who will be active in both systems.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTest-with-FogBugz/#configuring-the-release-mapping","title":"Configuring the Release Mapping","text":"When the data-synchronization service runs, when it comes across a release/iteration in SpiraTeam that it has not seen before, it will create a corresponding Release/Fix-For in FogBugz. Similarly if it comes across a new Release/Fix-For in FogBugz that it has not seen before, it will create a new Release in SpiraTeam. Therefore when using both systems together, it is recommended that you only enter new Releases/Versions in one system and let the data-synchronization service add them to the other system.
However you may start out with the situation where you already have pre-existing Releases/Versions in both systems that you need to associate in the data-mapping. If you don't do this, you may find that duplicates get created when you first enable the data-synchronization service. Therefore for any Releases/Iterations that already exist in BOTH systems please navigate to Planning > Releases and click on the Release/Iteration in question. Make sure you have the 'Overview' tab visible and expand the \"Details\" section of the release/iteration:
In addition to the standard fields and custom properties configured for Releases, you will see an additional text property called \"FogBugzDataSync ID\" that is used to store the mapped external identifier for the equivalent Release in FogBugz. You need to locate the ID of the equivalent Release in FogBugz, enter it into this text-box and click [Save]. You should now repeat for all the other pre-existing releases.
The FogBugz Release ID can be found by going to Settings > Projects and viewing the releases:
Then hover the mouse over the release name. The release ID will be displayed in the URL line as ixFixFor-X where X is the numeric ID of the release.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTest-with-FogBugz/#configuring-the-standard-field-mapping","title":"Configuring the Standard Field Mapping","text":"Now that the projects, user and releases have been mapped correctly, we need to configure the standard incident fields. To do this, go to Administration > System > Data Synchronization and click on the \"View Project Mappings\" for the FogBugzDataSync plug-in entry:
From this screen, you need to click on Priority, Status and Type in turn to configure their values:
a) Incident Type
Click on the \"Type\" hyperlink under Incident Standard Fields to bring up the Incident type mapping configuration screen:
The table lists each of the incident types available in SpiraTeam and provides you with the ability to enter the matching FogBugz case category ID for each one. You can map multiple SpiraTeam fields to the same FogBugz fields (e.g. Bug and Incident in SpiraTeam are both equivalent to Bug in FogBugz), in which case only one of the two values can be listed as Primary - Yes as that's the value that's used on the reverse synchronization (from FogBugz > SpiraTeam).
The values for the category ID are fixed for FogBugz and should be:
Category Name Category ID Bug > 1 Feature > 2 Inquiry > 3So, depending on which types have been configured in SpiraTeam, you'll need to adjust the mapping so that the appropriate SpiraTeam types correspond to the equivalent FogBugz category.
b) Incident Status
Click on the \"Status\" hyperlink under Incident Standard Fields to bring up the Incident status mapping configuration screen:
The table lists each of the incident statuses available in SpiraTeam and provides you with the ability to enter the matching FogBugz case status ID for each one. You can map multiple SpiraTeam fields to the same FogBugz fields (e.g. New, Open, Assigned, and Reopen in SpiraTeam are all equivalent to Active in FogBugz), in which case only one of the four values can be listed as Primary - Yes as that's the value that's used on the reverse synchronization (from FogBugz > SpiraTeam).
We recommend that you always point the New, Open, Assigned and Reopen statuses inside SpiraTeam to point to the ID for \"Assigned\" inside FogBugz and make Assigned in SpiraTeam the Primary status of the four. This is recommended so that as new incidents in SpiraTeam get synched over to FogBugz, they will get switched to the Active status in FogBugz which will then be synched back to \"Assigned\" in SpiraTeam. That way you'll be able to see at a glance which incidents have been synched with FogBugz and those that haven't.
You also might want to consider changing the statuses in SpiraTeam to match the 16 discrete statuses in FogBugz to make things easier for your users. In which case you'll need to create the new statuses and configure the workflow (as described in the SpiraTeam Administration Guide).
The status IDs in FogBugz are fixed and should be:
Status ID Status Name > 1 Active > 2 Resolved (Fixed) > 3 Resolved (Not Reproducible) > 4 Resolved (Duplicate) > 5 Resolved (Postponed) > 6 Resolved (Won't Fix) > 7 Resolved (By Design) > 8 Resolved (Implemented) > 9 Resolved (Won't Implement) > 10 Resolved (Already Exists) > 11 Resolved (Responded) > 12 Resolved (Won't Respond) > 13 Resolved (SPAM) > 14 Resolved (Waiting For Info) > 15 Resolved (Completed) > 16 Resolved (Canceled)In addition to these statuses, FogBugz also has the concept of a 'Closed' case which is one where the case has been assigned to the special Closed user (user id 1). If you want to map a SpiraTeam status to this special closed status, for the external key just enter 'Closed' instead of a numeric ID and that will tell the plug-in to associate that SpiraTest status with the special condition of a FogBugz case that is assigned to the 'closed' user.
c) Incident Priority
Click on the \"Priority\" hyperlink under Incident Standard Fields to bring up the Incident Priority mapping configuration screen:
The table lists each of the incident priorities available in SpiraTeam and provides you with the ability to enter the matching FogBugz priority ID for each one. You can map multiple SpiraTeam fields to the same FogBugz fields, in which case only one of the two values can be listed as Primary - Yes as that's the value that's used on the reverse synchronization (from FogBugz > SpiraTeam).
Since both applications allow you to customize the priority list, we recommend that you modify the list in both systems to be the same and then map them one to one as this will be easier for users to understand. In the example above, we have switched over SpiraTeam to match the priorities in FogBugz, but you could do it the other way around as well.
The FogBugz Priority IDs can be found by going to Settings > Priorities and viewing the priorities:
The priority ID is the \"priority number\" value displayed in the left hand column.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTest-with-FogBugz/#configuring-the-custom-property-mapping","title":"Configuring the Custom Property Mapping","text":"Now that the various SpiraTeam standard fields have been mapped correctly, we need to configure the custom property mappings. This is used for custom properties in SpiraTeam that are used to map to standard fields in FogBugz (Computer, Version and Area) that don't exist in SpiraTeam.
From the View/Edit Project Data Mapping screen, you need to click on the name of the Incident Custom Property that you want to add data-mapping information for. We will consider the three different types of mapping that you typically will want to enter:
a) FogBugz's Computer Field
You first need to create an incident custom property in SpiraTeam of type 'TEXT' that will be used to store the Computer description within SpiraTeam.
Then click on the hyperlink of this new text custom property under Incident Custom Properties to bring up the custom property mapping configuration screen:
All you need to do on this screen is enter the word \"Computer\" in the External Key textbox and the data-sync plug-in will know that this custom property is mapped to the built-in Computer field in FogBugz.
b) FogBugz's Version Field
You first need to create an incident custom property in SpiraTeam of type 'TEXT' that will be used to store the Version description within SpiraTeam.
Then click on the hyperlink of this new text custom property under Incident Custom Properties to bring up the custom property mapping configuration screen:
All you need to do on this screen is enter the word \"Version\" in the External Key textbox and the data-sync plug-in will know that this custom property is mapped to the built-in Version field in FogBugz.
c) FogBugz's Area Field
You first need to create an incident custom property in SpiraTeam of type 'LIST' that will be used to store the list of project areas within SpiraTeam. You will need to create a new custom list to store the different possible values of area and then use that list when creating the new custom property.
Then back on the Data Mapping page, click on the hyperlink of this new list custom property under Incident Custom Properties to bring up the custom property mapping configuration screen:
First you need to enter the word \"Area\" as the External Key of the custom property. This tells the data-sync plug-in that the custom property in SpiraTeam should be mapped to built-in Area field in FogBugz.
Next for each of the Property Values in the table (in the lower half of the page) you need to enter the FogBugz ID of the various Areas that are configured in FogBugz. The FogBugz Area ID can be found by going to Settings > Projects and viewing the areas in the project:
Then hover the mouse over the area name. The area ID will be displayed in the URL line as ixArea-X where X is the numeric ID of the area.
d) FogBugz's Parent Case Field
FogBugz lets you link a new case with an existing 'parent' case. You can make this possible from within SpiraTeam by simply creating a new custom text property and mapping to the special External Key - Parent:
Users will then enter the FogBugz ID of an existing case when they a log a new SpiraTeam incidents and the data-synchronization system will know how to associate the two cases.
Once you have updated the various mapping sections, you are now ready to use the synchronization.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTest-with-FogBugz/#using-spirateam-with-fogbugz","title":"Using SpiraTeam with FogBugz","text":"Now that the integration service has been configured and the service started, initially any incidents created in SpiraTeam for the specified projects will be imported into FogBugz and any existing cases in FogBugz will get loaded into SpiraTeam. At this point we recommend opening the Windows Event Viewer and choosing the Application Log. In this log any error messages raised by the SpiraTeam Data Sync Service will be displayed. If you see any error messages at this point, we recommend immediately stopping the SpiraTeam service and checking the various mapping entries. If you cannot see any cases with the mapping information, we recommend sending a copy of the event log message(s) to Inflectra customer services (support@inflectra.com) who will help you troubleshoot the problem.
To use SpiraTeam with FogBugz on an ongoing basis, we recommend the following general processes be followed:
When running tests in SpiraTest or SpiraTeam, defects found should be logged through the Test Execution Wizard as normal.
Developers using FogBugz can log new defects into either SpiraTeam or FogBugz. In either case they will get loaded into the other system.
Once created in one of the systems and successfully replicated to the other system, the incident should not be modified again inside SpiraTeam. Since FogBugz is considered the master system for incidents/cases, all data changes to the case should be made inside FogBugz. To enforce this, you should modify the workflows set up in SpiraTeam so that the various fields are marked as inactive for all the incident statuses other than the \"New\" status. This will allow someone to submit an incident in SpiraTeam, but will prevent them making changes in conflict with FogBugz after that point.
As the case progresses through the FogBugz workflow, changes to the type of case, changes to its status, priority, description and resolution will be updated automatically in SpiraTeam. In essence, SpiraTeam acts as a read-only viewer of these incidents.
You are now able to perform test coverage and incident reporting inside SpiraTest/SpiraTeam using the test cases managed by SpiraTest/SpiraTeam and the incidents managed on behalf of SpiraTest/SpiraTeam inside FogBugz.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTest-with-MS-TFS/","title":"Using SpiraTest with Microsoft Azure DevOps (TFS)","text":"This section outlines how to use SpiraTest, SpiraPlan or SpiraTeam (hereafter referred to as SpiraTeam) in conjunction with the work item tracking functionality of Microsoft Azure DevOps, also known as Microsoft Team Foundation Server (TFS) hereafter referred to as TFS for brevity.
The built-in integration service allows the quality assurance team to manage their requirements and test cases in SpiraTeam, execute test runs in SpiraTest, and then have the new incidents generated during the run be automatically loaded into TFS. Once the incidents are loaded into TFS as work items, the development team can then manage the lifecycle of these work items in TFS, and have the status changes in TFS be reflected back in SpiraTeam.
Similarly, as the requirements are decomposed into discrete project tasks in SpiraTeam, the integration service will automatically load these new tasks into TFS as task work items where the development team can manage their lifecycle, with schedule and progress changes in TFS being reflected back in SpiraTeam.
Set up data synchronization
STOP! Please make sure you have first read the instructions to set up the data sync before proceeding!
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTest-with-MS-TFS/#configuring-the-plug-in","title":"Configuring the Plug-In","text":"The next step is to configure the plug-in within SpiraTeam so that the system knows how to access the TFS server. Inside SpiraPlan, go to the Administration page and navigate to Integration > Data Synchronization. Check if you see a plug-in called MsTfsDataSync, as shown below:
What do if the plug-in is not there
If you don't see the plug-in in the list, click the \"\"Add\" button at the top of the page. This opens the generic Data Sync plug-in details page. This is not yet customized to help you more easily set up the data sync. We recommend, adding just enough information now to create the plug-in. Then edit the plug-in after its made to complete the process.
To start, fill in the following fields:
Now click \"Add\" to save the plug-in and return you to the list of plug-ins. Now follow the instructions below.
With the plug-in place, click on its \"edit\" button to open its detailed settings page.
You need to fill out the following fields for the TFS Plug-in to operate correctly:
Auto-Map Users: This changes the way the plugin maps users in SpiraTeam to those in TFS:
Windows Domain: This is used to specify the Windows Active Directory Domain that the Windows user specified above is a member of. For Azure DevOps in the cloud, you should leave this field blank.
If you are using Microsoft Azure DevOps Online instead of a local TFS instance, you will need to use a Personal Access Token (PAT) to connect to the instance of Azure DevOps from SpiraTeam.
To get a PAT, login to Azure DevOps and access your user profile:
In the popup menu, Click on the Personal access tokens option. This will display the list of already issued/active personal access tokens:
Click on the + New Token button to create a new personal access token:
You can give it a logical name (e.g. \"Spira\") and give it permissions to:
Azure Devops will then create a personal access token that you should copy to the clipboard and store somewhere secure (e.g. a password manager):
You will now use this personal access token as the \"password\" that SpiraTeam will use to connect to Azure DevOps. For the username, you can just use your standard Azure DevOps login (in fact you can use anything, it will only be checking the PAT).
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTest-with-MS-TFS/#configuring-the-data-mapping","title":"Configuring the Data Mapping","text":"Next, you need to configure the data mapping between SpiraTeam and TFS. This allows the various projects, users, releases, incident types, statuses, priorities and custom property values used in the two applications to be related to each other. This is important, as without a correct mapping, there is no way for the integration service to know that a \"Not Reproducible\" incident in SpiraTeam is the same as a \"Closed + Cannot Reproduce\" bug work item in TFS (for example).
The following mapping information needs to be setup in SpiraTeam:
Note: If using SpiraTest, you do not need to setup the last two sets of mappings as Tasks are not available in SpiraTest.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTest-with-MS-TFS/#configuring-the-project-mapping","title":"Configuring the Project Mapping","text":"From the data synchronization administration page, you need to click on the \"View Project Mappings\" hyperlink next to the TFS plug-in name. This will take you to the data-mapping home page for the currently selected project:
If the project name does not match the name of the project you want to configure the data-mapping for, click on the \"(Change Project)\" hyperlink to change the current project.
To enable this project for data-synchronization with TFS, you need to enter:
External Key -- This should be set to the name of the project in TFS as visible from the Visual Studio Team Explorer or web interface:
OR
Active Flag -- Set this to 'Yes' so that SpiraTeam knows that you want to synchronize data for this project. Once the project has been completed, setting the value to \"No\" will stop data synchronization, reducing network utilization.
Click [Update] to confirm these settings. Once you have enabled the project for data-synchronization, you can now enter the other data mapping values outlined below.
Note: Once you have successfully configured the project, when creating a new project, you should choose the option to \"Create Project from Existing Project\" rather than \"Use Default Template\" so that all the project mappings get copied across to the new project.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTest-with-MS-TFS/#configuring-the-user-mapping","title":"Configuring the User Mapping","text":"To configure the mapping of users in the two systems, you need to go to Administration > Users > View Edit Users, which will bring up the list of users in the system. Then click on the \"Edit\" button for a particular user that will be editing work items in TFS:
You will notice that in the special Data Mapping tab, there is a list of all the configured data-synchronization plug-ins. In the text box next to the TFS Data-Sync plug-in you need to enter the full name of this Windows User (not the login). This is the name of the user as they appear inside work items within TFS:
This will allow the data-synchronization plug-in to know which user in SpiraTeam match which equivalent user in TFS. Click [Update] once you've entered the appropriate login name. You should now repeat for the other users who will be active in both systems.
If you have set the \"Auto-Map Users\" option in the TFS 2012 plugin, you can skip this section completely.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTest-with-MS-TFS/#configuring-the-release-mapping","title":"Configuring the Release Mapping","text":"When the data-synchronization service runs, when it comes across a release/iteration in SpiraTeam that it has not seen before, it will create a corresponding \"Iteration\" in TFS. Similarly if it comes across a new Iteration in TFS that it has not seen before, it will create a new Release/Iteration in SpiraTeam. Therefore when using both systems together, it is recommended that you only enter new Releases/Iterations in one system and let the data-synchronization service add them to the other system.
However you may start out with the situation where you already have pre-existing Releases/Iterations in both systems that you need to associate in the data-mapping. If you don't do this, you may find that duplicates get created when you first enable the data-synchronization service. Therefore for any Releases/Iterations that already exist in BOTH systems please navigate to Planning > Releases and click on the Release/Iteration in question. Make sure you have the 'Overview' tab visible and expand the \"Properties\" section of the release/iteration:
In addition to the standard fields and custom properties configured for Releases, you will see an additional text property called \"MsTfsDataSync ID\" that is used to store the mapped external identifier for the equivalent Version in TFS. You need to locate the ID of the equivalent Iteration in TFS, enter it into this text-box and click [Save]. You should now repeat for all the other pre-existing releases.
The TFS Iteration ID is not visible in the TFS user interface, but can instead be located by opening up the SQL Server that it's installed on, opening the 'TfsWorkItemTracking' database (in TFS 2010 it will named after your project collection instead) and locating the 'TreeNodes' table:
Once you have found the matching Iteration (by name), the numeric value stored in the ID column (the one on the left) is the value that needs to get added as the MsTfsDataSync ID inside SpiraTeam.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTest-with-MS-TFS/#configuring-the-standard-incident-field-mapping","title":"Configuring the Standard Incident Field Mapping","text":"Now that the projects, user and releases have been mapped correctly, we need to configure the standard incident fields. To do this, go to Administration > System > Data Synchronization and click on the \"View Project Mappings\" for the MsTfsDataSync plug-in entry:
From this screen, you need to click on Priority, Severity, Status and Type in turn to configure their values:
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTest-with-MS-TFS/#a-incident-type","title":"a) Incident Type","text":"Click on the \"Type\" hyperlink under Incident Standard Fields to bring up the Incident type mapping configuration screen:
The table lists each of the incident types available in SpiraTeam and provides you with the ability to enter the matching TFS work item type name for each one. To make this easier, we recommend that inside the Administration > Edit Incident Statuses screen you first make all incident types inactive except Risk, Issue and Bug since only those types make sense to synchronize with TFS.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTest-with-MS-TFS/#b-incident-status","title":"b) Incident Status","text":"Click on the \"Status\" hyperlink under Incident Standard Fields to bring up the Incident status mapping configuration screen:
The table lists each of the incident statuses available in SpiraTeam and provides you with the ability to enter the matching TFS work item State + Reason or State for each one.
TFS uses separate State (Active, Resolved, Closed) and Reason (Fixed, Duplicate, Not Fixed, etc.) code unlike SpiraTeam which uses a single status code. For maximum flexibility, the integration can work with either a mapped State or a mapped State+Reason.
If you want to have SpiraTeam statuses point to a specific TFS work item State and a specific Reason associated with that State, you need to concatenate the TFS State and Reason together with a 'plus' (+) sign so that the system knows that the incident status in SpiraTeam corresponds to that specific combination.
If you want to have SpiraTeam statuses simply point to a specific TFS work item State and let TFS assign the default Reason for that State, you simply map the SpiraTeam statuses to the State:
You can map multiple SpiraTeam fields to the same TFS fields (e.g. New and Open in SpiraTeam are both equivalent to 'Active+New' in TFS), in which case only one of the two values can be listed as Primary = Yes as that's the value that's used on the reverse synchronization (from TFS > SpiraTeam).
We recommend that you always point the New and Open statuses inside SpiraTeam to point to the \"Active+New\" TFS state+reason, and make Open in SpiraTeam the Primary status of the two. This is recommended so that as new incidents in SpiraTeam get synched over to TFS, they will get switched to the \"Active+New\" status in TFS which will then be synched back to \"Open\" in SpiraTeam. That way you'll be able to see at a glance which incidents have been synched with TFS and those that haven't.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTest-with-MS-TFS/#c-incident-priority","title":"c) Incident Priority","text":"Click on the \"Priority\" hyperlink under Incident Standard Fields to bring up the Incident Priority mapping configuration screen:
The table lists each of the incident priorities available in SpiraTeam and provides you with the ability to enter the matching TFS priority value for each one. To make this easier, we recommend that inside the Administration > Edit Incident Priorities screen you first make any statuses not used in TFS inactive in SpiraTeam.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTest-with-MS-TFS/#d-incident-severity","title":"d) Incident Severity","text":"Click on the \"Severity\" hyperlink under Incident Standard Fields to bring up the Incident Severity mapping configuration screen:
The table lists each of the incident severities available in SpiraTeam and provides you with the ability to enter the matching TFS severity value for each one. To make this easier, we recommend that inside the Administration > Edit Incident Severities screen you first make any statuses not used in TFS inactive in SpiraTeam.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTest-with-MS-TFS/#configuring-the-incident-custom-property-mapping","title":"Configuring the Incident Custom Property Mapping","text":"Now that the various SpiraTeam standard incident fields have been mapped correctly, we need to configure the custom property mappings. This is used for both custom properties in SpiraTeam that map to custom fields in TFS and also for custom properties in SpiraTeam that are used to map to standard fields in TFS (e.g. Area) that don't exist in SpiraTeam.
From the View/Edit Project Data Mapping screen, you need to click on the name of the Incident Custom Property that you want to add data-mapping information for:
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTest-with-MS-TFS/#a-tfss-area-field","title":"a) TFS's Area Field","text":"First you need to go to Administration > Edit Custom Lists and create a new custom list that contains all the different Areas that are being used in TFS.
Then you need to go to Administration > Edit Custom Properties and add a new list custom property onto the Incident artifact type called 'Area' and link it to the Area custom list you created in the previous step. This will now be available for mapping.
Now, back in the data-mapping page, click on the 'Area' hyperlink under Incident Custom Properties to bring up the custom property mapping configuration screen:
First you need to enter the word \"Area\" as the External Key of the custom property. This tells the data-sync plug-in that the custom property in SpiraTeam should be mapped to built-in Area field in TFS.
Next for each of the Property Values in the table (in the lower half of the page) you need to enter either the Area ID or the Area Path of the various Areas that are configured in TFS. The TFS Area ID is not visible in the TFS user interface, but can instead be located by opening up the SQL Server that it's installed on, opening the 'TfsWorkItemTracking' database (in TFS 2010 and later it will named after your project collection instead) and locating the 'TreeNodes' table:
Once you have found the matching Area (by name), the numeric value stored in the ID column (the one on the left) is the value that needs to get added as the External Key inside SpiraTeam.
For Azure DevOps in the cloud, it is usually easier to just map the areas to the appropriate paths instead (since the IDs are not easily found):
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTest-with-MS-TFS/#b-tfs-custom-fields","title":"b) TFS Custom Fields","text":"If the custom field in TFS is a list field, first you need to go to Administration > Edit Custom Lists in SpiraTeam and create a new custom list that contains all the different values that are being used in TFS.
Then for both list-fields and value-fields you need to go to Administration > Edit Custom Properties and add a new custom property onto the Incident artifact type with the name of the appropriate TFS field (e.g. Triage, Rank, etc.) and if a list-field, link it to the custom list you created in the previous step. The custom property will now be available for data-mapping.
Now, back in the data-synchronization data-mapping page, click on the hyperlink under Incident Custom Properties that corresponds to the custom property to bring up the custom property mapping configuration screen:
First you need to enter the full Reference Name of the TFS field as the External Key of the custom property. This tells the data-sync plug-in that the custom property in SpiraTeam should be mapped to this specific field in TFS. To see a list of fields and their reference names, you can run the following SQL query against your TFS database:
SELECT Name, ReferenceName FROM Fields ORDER BY Name
We have included a list of fields in the Agile process template in TFS Field Reference as a helpful reference.
Next for each of the Property Values in the table (in the lower half of the page) you need to enter the name of the field values as they appear in TFS as the External Key.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTest-with-MS-TFS/#configuring-the-standard-task-field-mapping","title":"Configuring the Standard Task Field Mapping","text":"Now that the projects, user, releases and incident fields have been mapped correctly, we need to configure the standard task fields. To do this, go to Administration > System > Data Synchronization and click on the \"View Project Mappings\" for the MsTfsDataSync plug-in entry:
From this screen, you need to click on Priority and Status in turn to configure their values:
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTest-with-MS-TFS/#a-task-status","title":"a) Task Status","text":"Click on the \"Status\" hyperlink under Task Standard Fields to bring up the Task status mapping configuration screen:
The table lists each of the task statuses available in SpiraTeam and provides you with the ability to enter the matching TFS work item State for each one. Unlike the mapping for incidents (see above) SpiraTeam does not track the reason codes associated with the tasks in MS TFS, so you only need to map the State names from TFS with the task status names.
You can map multiple SpiraTeam fields to the same TFS fields (e.g. Blocked, Completed and Deferred in SpiraTeam are all equivalent to State = Closed in TFS), in which case only one of the values can be listed as Primary = Yes as that's the value that's used on the reverse synchronization (from TFS > SpiraTeam).
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTest-with-MS-TFS/#b-task-priority","title":"b) Task Priority","text":"Click on the \"Priority\" hyperlink under Task Standard Fields to bring up the Task Priority mapping configuration screen:
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTest-with-MS-TFS/#c-task-type","title":"c) Task Type","text":"Click on the \"Type\" hyperlink under Task Standard Fields to bring up the Task Type mapping configuration screen:
The table lists each of the task type values available in SpiraTeam and provides you with the ability to enter the matching TFS work item type value for each one.
The table lists each of the task priorities available in SpiraTeam and provides you with the ability to enter the matching TFS priority value for each one.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTest-with-MS-TFS/#configuring-the-task-custom-property-mapping","title":"Configuring the Task Custom Property Mapping","text":"Now that the various SpiraTeam standard task fields have been mapped correctly, we need to configure the custom property mappings. This is used for both custom properties in SpiraTeam that map to custom fields in TFS and also for custom properties in SpiraTeam that are used to map to standard fields in TFS (e.g. Area) that don't exist in SpiraTeam.
From the View/Edit Project Data Mapping screen, you need to click on the name of the Task Custom Property that you want to add data-mapping information for:
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTest-with-MS-TFS/#a-tfss-area-field_1","title":"a) TFS's Area Field","text":"First you need to go to Administration > Edit Custom Lists and create a new custom list that contains all the different Areas that are being used in TFS.
Then you need to go to Administration > Edit Custom Properties and add a new list custom property onto the Task artifact type called 'Area' and link it to the Area custom list you created in the previous step. This will now be available for mapping.
Now, back in the data-mapping page, click on the 'Area' hyperlink under Task Custom Properties to bring up the custom property mapping configuration screen:
First you need to enter the word \"Area\" as the External Key of the custom property. This tells the data-sync plug-in that the custom property in SpiraTeam should be mapped to built-in Area field in TFS.
Next for each of the Property Values in the table (in the lower half of the page) you need to enter the ID or Path of the various Areas that are configured in TFS. The TFS Area ID is not visible in the TFS user interface, but can instead be located by opening up the SQL Server that it's installed on, opening the 'TfsWorkItemTracking' database (in TFS 2010 and later it will named after your project collection instead) and locating the 'TreeNodes' table:
Once you have found the matching Area (by name), the numeric value stored in the ID column (the one on the left) is the value that needs to get added as the External Key inside SpiraTeam.
For Azure DevOps in the cloud, it is usually easier to just map the areas to the appropriate paths instead (since the IDs are not easily found):
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTest-with-MS-TFS/#b-tfs-custom-fields_1","title":"b) TFS Custom Fields","text":"If the custom field in TFS is a list field, first you need to go to Administration > Edit Custom Lists in SpiraTeam and create a new custom list that contains all the different values that are being used in TFS.
Then for both list-fields and value-fields you need to go to Administration > Edit Custom Properties and add a new custom property onto the Task artifact type with the name of the appropriate TFS field (e.g. Discipline, Stack Rank, etc.) and if a list-field, link it to the custom list you created in the previous step. The custom property will now be available for data-mapping.
Now, back in the data-synchronization data-mapping page, click on the hyperlink under Task Custom Properties that corresponds to the custom property to bring up the custom property mapping configuration screen:
First you need to enter the full Reference Name of the TFS field as the External Key of the custom property. This tells the data-sync plug-in that the custom property in SpiraTeam should be mapped to this specific field in TFS. To see a list of fields and their reference names, you can run the following SQL query against your TFS database:
SELECT Name, ReferenceName FROM Fields ORDER BY Name
We have included a list of fields in the Agile process template in TFS Field Reference as a helpful reference.
Next for each of the Property Values in the table (in the lower half of the page) you need to enter the name of the field values as they appear in TFS as the External Key.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTest-with-MS-TFS/#configuring-the-standard-requirement-field-mapping-2012-plugin-only","title":"Configuring the Standard Requirement Field Mapping (2012 Plugin Only)","text":"Now that the projects, user, releases, incident and task fields have been mapped correctly, we need to configure the standard requirement fields. To do this, go to Administration > System > Data Synchronization and click on the \"View Project Mappings\" for the MsTfsDataSync plug-in entry:
From this screen, you need to click on Importance and Status in turn to configure their values:
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTest-with-MS-TFS/#a-requirement-status","title":"a) Requirement Status","text":"Click on the \"Status\" hyperlink under Requirement Standard Fields to bring up the Requirement status mapping configuration screen:
The table lists each of the requirement statuses available in SpiraTeam and provides you with the ability to enter the matching TFS work item State for each one. Unlike the mapping for incidents (see above) SpiraTeam does not track the reason codes associated with the requirements in MS TFS, so you only need to map the State names from TFS with the requirement status names.
You can map multiple SpiraTeam fields to the same TFS fields, in which case only one of the values can be listed as Primary = Yes as that's the value that's used on the reverse synchronization (from TFS > SpiraTeam).
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTest-with-MS-TFS/#b-requirement-importance","title":"b) Requirement Importance","text":"Click on the \"Importance\" hyperlink under Requirement Standard Fields to bring up the Requirement Importance mapping configuration screen:
The table lists each of the requirement importance values available in SpiraTeam and provides you with the ability to enter the matching TFS work item priority value for each one.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTest-with-MS-TFS/#c-requirement-type","title":"c) Requirement Type","text":"Click on the \"Type\" hyperlink under Requirement Standard Fields to bring up the Requirement Type mapping configuration screen:
The table lists each of the requirement type values available in SpiraTeam and provides you with the ability to enter the matching TFS work item type value for each one.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTest-with-MS-TFS/#configuring-the-requirement-custom-property-mapping","title":"Configuring the Requirement Custom Property Mapping","text":"Now that the various SpiraTeam standard requirement fields have been mapped correctly, we need to configure the custom property mappings. This is used for both custom properties in SpiraTeam that map to custom fields in TFS and also for custom properties in SpiraTeam that are used to map to standard fields in TFS (e.g. Area) that don't exist in SpiraTeam.
From the View/Edit Project Data Mapping screen, you need to click on the name of the Requirement Custom Property that you want to add data-mapping information for:
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTest-with-MS-TFS/#a-tfss-area-field_2","title":"a) TFS's Area Field","text":"First you need to go to Administration > Edit Custom Lists and create a new custom list that contains all the different Areas that are being used in TFS.
Then you need to go to Administration > Edit Custom Properties and add a new list custom property onto the Requirement artifact type called 'Area' and link it to the Area custom list you created in the previous step. This will now be available for mapping.
Now, back in the data-mapping page, click on the 'Area' hyperlink under Requirement Custom Properties to bring up the custom property mapping configuration screen:
First you need to enter the word \"Area\" as the External Key of the custom property. This tells the data-sync plug-in that the custom property in SpiraTeam should be mapped to built-in Area field in TFS.
Next for each of the Property Values in the table (in the lower half of the page) you need to enter the ID or Path of the various Areas that are configured in TFS. The TFS Area ID is not visible in the TFS user interface, but can instead be located by opening up the SQL Server that it's installed on, opening the 'TfsWorkItemTracking' database (in TFS 2010 and later it will named after your project collection instead) and locating the 'TreeNodes' table:
Once you have found the matching Area (by name), the numeric value stored in the ID column (the one on the left) is the value that needs to get added as the External Key inside SpiraTeam.
For Azure DevOps in the cloud, it is usually easier to just map the areas to the appropriate paths instead (since the IDs are not easily found):
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTest-with-MS-TFS/#b-tfs-custom-fields_2","title":"b) TFS Custom Fields","text":"If the custom field in TFS is a list field, first you need to go to Administration > Edit Custom Lists in SpiraTeam and create a new custom list that contains all the different values that are being used in TFS.
Then for both list-fields and value-fields you need to go to Administration > Edit Custom Properties and add a new custom property onto the Requirement artifact type with the name of the appropriate TFS field (e.g. Risk, Stack Rank, etc.) and if a list-field, link it to the custom list you created in the previous step. The custom property will now be available for data-mapping.
Now, back in the data-synchronization data-mapping page, click on the hyperlink under Requirement Custom Properties that corresponds to the custom property to bring up the custom property mapping configuration screen:
First you need to enter the full Reference Name of the TFS field as the External Key of the custom property. This tells the data-sync plug-in that the custom property in SpiraTeam should be mapped to this specific field in TFS. To see a list of fields and their reference names, you can run the following SQL query against your TFS database:
SELECT Name, ReferenceName FROM Fields ORDER BY Name
We have included a list of fields in the Agile process template in TFS Field Reference as a helpful reference.
Next for each of the Property Values in the table (in the lower half of the page) you need to enter the name of the field values as they appear in TFS as the External Key.
Once you have updated the various mapping sections, you are now ready to start the service.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTest-with-MS-TFS/#using-spirateam-with-tfs","title":"Using SpiraTeam with TFS","text":"Now that the integration service has been configured and the service started, initially any incidents already created in SpiraTeam for the specified projects will be imported into TFS and any requirements, tasks or bugs already created in TFS will be imported into SpiraTeam. At this point we recommend opening the Windows Event Viewer and choosing the Application Log. In this log any error messages raised by the SpiraTeam Data Sync Service will be displayed. If you see any error messages at this point, we recommend immediately stopping the SpiraTeam service and checking the various mapping entries. If you cannot see any work items with the mapping information, we recommend sending a copy of the event log message(s) to Inflectra customer services (support@inflectra.com) who will help you troubleshoot the problem.
To use SpiraTeam with TFS on an ongoing basis, we recommend the following general processes be followed:
When running tests in SpiraTest or SpiraTeam, defects found should be logged through the Test Execution Wizard as normal.
Once an incident has been created during the running of the test, it will now be populated across into TFS as a work item of type corresponding to the types setup in the incident type mappings.
At this point, the incident can be worked on in either system, with changes being synchronized to the other system. However in general we recommend that the QA/Testing team use SpiraTeam and the development team use TFS. E.g. the developers will mark the bugs as resolved in MSTS once they have completed fixing them and the QA team will either reopen or close then in SpiraTeam once they have had a change to verify the resolution.
You are now able to perform test coverage and incident reporting inside SpiraTest/SpiraTeam using the test cases managed by SpiraTest/SpiraTeam and the incidents managed collaboratively between SpiraTest/SpiraTeam and TFS.
You can create project requirements and associated tasks in either SpiraTeam or TFS, however the synchronization service is only unidirectional for requirements and tasks, so when you create or update a requirement or task in TFS, the change will be reflected in SpiraTeam, but not the other way around.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTest-with-MS-TFS/#description-handling","title":"Description Handling","text":"Whereas Spira has a single artifact Description field, ADO/TFS has three possible \"Description\" fields depending on the templates setup by an administrator:
Microsoft.VSTS.TCM.ReproSteps (rich text)Microsoft.VSTS.Common.DescriptionHtml (rich text)System.Description (plain text)The plugin checks for each of them in the order above. It will sync the Description in Spira with whichever one of these it finds first. So if you have both ReproSteps and Description (for example) then it will use ReproSteps.
If you need both fields in Spira, then we recommend making two separate rich text custom properties and map each of those to the ones in ADO/TFS.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTest-with-MS-TFS/#troubleshooting","title":"Troubleshooting","text":"In most cases once you have started the service, once it's up and running you will not see any error or warning messages from the Data-Sync service. However, if you have new users created in SpiraTeam that have not been mapped to users in TFS, when you assign incidents, requirements or tasks to those items, you may see warning messages in the Event Viewer letting you know which users needs to be mapped.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTest-with-MS-TFS/#tfs-field-reference","title":"TFS Field Reference","text":"The following fields are available in TFS for data-mapping when using the TFS agile process template:
Display Name Reference Name Accepted By Microsoft.VSTS.CodeReview.AcceptedBy Accepted Date Microsoft.VSTS.CodeReview.AcceptedDate Activated By Microsoft.VSTS.Common.ActivatedBy Activated Date Microsoft.VSTS.Common.ActivatedDate Activity Microsoft.VSTS.Common.Activity Application Launch Instructions Microsoft.VSTS.Feedback.ApplicationLaunchInstructions Application Start Information Microsoft.VSTS.Feedback.ApplicationStartInformation Application Type Microsoft.VSTS.Feedback.ApplicationType Area ID System.AreaId Area Level 1 System.AreaLevel1 Area Level 2 System.AreaLevel2 Area Level 3 System.AreaLevel3 Area Level 4 System.AreaLevel4 Area Level 5 System.AreaLevel5 Area Level 6 System.AreaLevel6 Area Level 7 System.AreaLevel7 Area Path System.AreaPath Assigned To System.AssignedTo Associated Context Microsoft.VSTS.CodeReview.Context Associated Context Code Microsoft.VSTS.CodeReview.ContextCode Associated Context Owner Microsoft.VSTS.CodeReview.ContextOwner Associated Context Type Microsoft.VSTS.CodeReview.ContextType Attached File Count System.AttachedFileCount Attached Files System.AttachedFiles Authorized As System.AuthorizedAs Authorized Date System.AuthorizedDate Automated Test Id Microsoft.VSTS.TCM.AutomatedTestId Automated Test Name Microsoft.VSTS.TCM.AutomatedTestName Automated Test Storage Microsoft.VSTS.TCM.AutomatedTestStorage Automated Test Type Microsoft.VSTS.TCM.AutomatedTestType Automation status Microsoft.VSTS.TCM.AutomationStatus BIS Links System.BISLinks Changed By System.ChangedBy Changed Date System.ChangedDate Changed Set System.ChangedSet Closed By Microsoft.VSTS.Common.ClosedBy Closed Date Microsoft.VSTS.Common.ClosedDate Closed Status Microsoft.VSTS.CodeReview.ClosedStatus Closed Status Code Microsoft.VSTS.CodeReview.ClosedStatusCode Closing Comment Microsoft.VSTS.CodeReview.ClosingComment Completed Work Microsoft.VSTS.Scheduling.CompletedWork Created By System.CreatedBy Created Date System.CreatedDate Description System.Description Due Date Microsoft.VSTS.Scheduling.DueDate External Link Count System.ExternalLinkCount Finish Date Microsoft.VSTS.Scheduling.FinishDate Found In Microsoft.VSTS.Build.FoundIn History System.History Hyperlink Count System.HyperLinkCount ID System.Id InAdminOnlyTreeFlag System.InAdminOnlyTreeFlag InDeletedTreeFlag System.InDeletedTreeFlag Integration Build Microsoft.VSTS.Build.IntegrationBuild Issue Microsoft.VSTS.Common.Issue Iteration ID System.IterationId Iteration Level 1 System.IterationLevel1 Iteration Level 2 System.IterationLevel2 Iteration Level 3 System.IterationLevel3 Iteration Level 4 System.IterationLevel4 Iteration Level 5 System.IterationLevel5 Iteration Level 6 System.IterationLevel6 Iteration Level 7 System.IterationLevel7 Iteration Path System.IterationPath Link Type System.Links.LinkType Linked Files System.LinkedFiles Local Data Source Microsoft.VSTS.TCM.LocalDataSource Node Name System.NodeName Node Type System.NodeType Not a field System.NotAField Original Estimate Microsoft.VSTS.Scheduling.OriginalEstimate Parameters Microsoft.VSTS.TCM.Parameters PersonID System.PersonId Priority Microsoft.VSTS.Common.Priority ProjectID System.ProjectId Rating Microsoft.VSTS.Common.Rating Reason System.Reason Related Link Count System.RelatedLinkCount Related Links System.RelatedLinks Remaining Work Microsoft.VSTS.Scheduling.RemainingWork Repro Steps Microsoft.VSTS.TCM.ReproSteps Resolved By Microsoft.VSTS.Common.ResolvedBy Resolved Date Microsoft.VSTS.Common.ResolvedDate Resolved Reason Microsoft.VSTS.Common.ResolvedReason Rev System.Rev Reviewed By Microsoft.VSTS.Common.ReviewedBy Revised Date System.RevisedDate Risk Microsoft.VSTS.Common.Risk Severity Microsoft.VSTS.Common.Severity Stack Rank Microsoft.VSTS.Common.StackRank Start Date Microsoft.VSTS.Scheduling.StartDate State System.State State Change Date Microsoft.VSTS.Common.StateChangeDate State Code Microsoft.VSTS.Common.StateCode Steps Microsoft.VSTS.TCM.Steps Story Points Microsoft.VSTS.Scheduling.StoryPoints System Info Microsoft.VSTS.TCM.SystemInfo Tags System.Tags Team Project System.TeamProject TF Server System.TFServer Title System.Title Tree System.Tree Watermark System.Watermark _Extension Marker System.ExtensionMarker _Kanban Column _Kanban.Column Work Item Form System.WorkItemForm Work Item FormID System.WorkItemFormId Work Item Type System.WorkItemType WorkItem System.WorkItem WorkItemLink System.WorkItemLink WorkItemTypeExtension System.WorkItemTypeExtensionFor a full list of the available TFS fields in the different process templates, please refer to: http://msdn.microsoft.com/en-us/library/vstudio/dd997792.aspx
"},{"location":"Help-Desk-Integration/KronoDesk/","title":"KronoDesk","text":"This section outlines how to integrate KronoDesk\u00ae into SpiraPlan\u00ae. This will enable KronoDesk agents to log incidents emerging from a ticket directly from the KronoDesk interface into SpiraPlan. They will also be able to see and review any SpiraPlan incidents already linked to existing KronoDesk tickets.
The integration is built-in to KronoDesk out of the box, with no add-ons necessary.
"},{"location":"Help-Desk-Integration/KronoDesk/#configuring-spiraplan","title":"Configuring SpiraPlan","text":"In order for KronoDesk to successfully connect to SpiraPlan to create incidents, you need to first enable the security permissions for REST API access. To do this, open up SpiraPlan and go to the Administration > System > Security Settings. Enter the URL domain of your KronoDesk into the \"Allowed Domains\" box. This tells SpiraPlan that REST API requests from this domain is authorized.
For non-production environments, you can set the value to \"*\" to allow all requests. We do not recommend this setting for production.
Each agent who wants to integrate KronoDesk with SpiraPlan needs to enter a SpiraPlan username and RSS Token into their user profile. In SpiraPlan, go to your User Profile page (if it's your user) or the Administration > Edit Users page, if you want to connect as a different user:
Make sure that Enable RSS Feeds is set to Active = Yes, and that there is an RSS Token. This is used as the REST API Key too. Make sure you have the following:
This is what you will use to connect from KronoDesk.
"},{"location":"Help-Desk-Integration/KronoDesk/#configuring-kronodesk","title":"Configuring KronoDesk","text":"Inside KronoDesk as an administrator, go to: Administration > Help Desk Settings > Spira Integration:
Enter the following information for your SpiraPlan instance:
When you click \"Test\", you should see the following:
If you see an authentication error, please check the login and RSS Token / API Key and try again.
Next, each user support agent in KronoDesk needs to connect their SpiraPlan user to their KronoDesk profile (using the information collected above). Each user needs to go to their User Profile in KronoDesk:
They should enter the Spira login and RSS Token and click Test:
Then click Save Changes to update the profile with this information.
"},{"location":"Help-Desk-Integration/KronoDesk/#using-kronodesk-with-spiraplan","title":"Using KronoDesk with SpiraPlan","text":"When you view a ticket in KronoDesk (and you have configured the connection to SpiraPlan), you will see a little toggle icon to show or hide incidents (the highlighted bug icon in the image below).
This means you are connected to SpiraPlan and can view any incidents logged against this help desk ticket.
To log a new incident in SpiraPlan based on the current help desk ticket, click on downward facing arrow on the right hand side of the ticket header (the \"more actions\" button). To \"Add New Incident\" make sure a SpiraPlan project is selected from the dropdown list (if the name of the product for the ticket matches the name of any SpiraPlan project, that project will be automatically selected for you):
This will display a dialog that lets you add a new incident to the linked instance of SpiraPlan. The system will prepopulate the description of the incident with the ticket description. You can edit this text or clear it completely and enter in custom content:
Once you click Add, the new incident is logged in SpiraPlan and linked to the current ticket:
If you click on the incident hyperlink, you will see that the incident is available in SpiraPlan:
In addition, in the Attachments tab of the Incident in Spiraplan, there is a hyperlink for the developers to see the original help desk ticket:
"},{"location":"Help-Desk-Integration/Zendesk/","title":"Zendesk","text":"This section outlines how to integrate Zendesk into SpiraTeam\u00ae. This will enable Zendesk agents to log incidents emerging from a ticket directly from the Zendesk interface into SpiraTeam\u00ae. They will also be able to see and review any SpiraTeam\u00ae incidents already linked to existing Zendesk tickets. The integration is in the form of a Zendesk app, available for free, from the Zendesk marketplace.
"},{"location":"Help-Desk-Integration/Zendesk/#overview-to-get-up-and-running","title":"Overview to Get Up and Running","text":"This section outlines the steps required to ensure that the links between Zendesk and Spirateam will work correctly.
"},{"location":"Help-Desk-Integration/Zendesk/#summary-of-requirements","title":"Summary of requirements","text":"There are a number of elements needed for both applications to successfully communicate:
Zendesk and SpiraTeam need to communicate and post data to one another cross domain. To ensure effective security SpiraTeam therefore needs to be accessible via HTTPS (i.e. using a certificate). If this is not already in place, contact your network administration for support.
Note: all SpiraTeam hosted accounts are already accessible via HTTPS (only).
Zendesk and SpiraTeam communicate through a security protocol called CORs to ensure that each application only receives data from trusted domains. The subdomain of your Zendesk account is required by SpiraTeam to validate any calls it receives.
Log in as a project-level administrator to SpiraTeam, go to the Administration home page and scroll to System > Security Settings.
At the bottom of the Security Settings page, enter the Zendesk subdomain in the \"Allowed Domains\" text box, making sure to include the full url (i.e including https:// before the domain address). Click <Update> for the changes to take effect. The url should be in the format of: \"https://yoursubdomain.zendesk.com\"
Important: if this field is left blank, NO domains will be allowed to interact with SpiraTeam via CORs. If an asterisk (*) is entered, ALL domains will be able to do so (not recommended).
The Zendesk app uses the details of a SpiraTeam user to authenticate with SpiraTeam. This needs to be, for the initial setup, a user with administrator privileges. We recommend creating a specific user account (such as \"Zendesk\"), so that the only incidents created by that account can be traced back to Zendesk.
Note: all tickets logged with Zendesk will be marked as originating from this user. This means that the Zendesk team do not need to have individual SpiraTeam logins.
Go to the Administration home page and scroll to Users > View / Edit Users.
Click the <Add User> button on the bottom right of the page.
Fill in the required fields (see below), and make sure that:
Click <Insert> to add the new user.
"},{"location":"Help-Desk-Integration/Zendesk/#install-and-configure-the-spirateam-app-in-zendesk","title":"Install and Configure the SpiraTeam App in Zendesk","text":"
First, find an install the free SpiraTeam App from within Zendesk. Only administrators on Zendesk can install apps. Navigate to the Admin panel, and select Marketplace from the Apps menu. Search for \"SpiraTeam\" in the search field on the right, or browse by \"Issues Tracking\".
You can also browse the Zendesk app website.
Once the application is installed, enter required information in the settings page of the app. Go to Admin > Apps > Manage in Zendesk to see the list of installed applications.
Make sure the application is enabled. Right click on the app's gear icon to change settings
In the settings screen, make sure all input boxes are correctly filled in. Enter the username and API key that you created inside SpiraTeam above, as well as the address of SpiraTeam. Make sure that the API key is an alphanumeric string contained within curly braces -- { }. Click <Update>.
"},{"location":"Help-Desk-Integration/Zendesk/#connecting-zendesk-to-spirateam","title":"Connecting Zendesk to SpiraTeam","text":"
Zendesk should now be able to communicate fully with SpiraTeam. In order for SpiraTeam to be informed that you are using the Zendesk app, simply navigate to any ticket, click on the app sidebar (on the right of the Zendesk window) and locate the SpiraTeam app. You should see a screen like that below, giving you a welcome message on the successful connection of Zendesk to SpiraTeam.
If you instead see a message like that below (note that you will also see a Zendesk service notification), please check your network settings, and double check through the steps outline above.
"},{"location":"Help-Desk-Integration/Zendesk/#connecting-spirateam-to-zendesk","title":"Connecting SpiraTeam to Zendesk","text":"
Zendesk can now retrieve information form SpiraTeam. For Zendesk to be able to write all the information it needs to SpiraTeam, you need to grant Zendesk access in each relevant project (i.e. any project that a Zendesk agent may need to submit an incident about).
If you wish, at this time you can change the account of the dedicated \"Zendesk\" user to no longer be an administrator. Make sure proper permissions are set so that the user has full access to incidents in all relevant projects.
In SpiraTeam, navigate to a project Zendesk will need access to. Go to the SpiraTeam administration panel and then Integration > Data Synchronization.
This will show you the list of current external tools that can synchronize custom data directly with SpiraTeam. Zendesk should appear as the last \"Plug-In\" in the table.
Click on <View Project Mappings>. Set Active to \"Yes\". Type in any value for External Key (this is a required field but because SpiraTeam does not write to Zendesk it is never used by the app). Click <Update>.
NOTES:
Repeat the above steps for every project Zendesk will need access to.
"},{"location":"Help-Desk-Integration/Zendesk/#creating-an-incident-in-spirateam","title":"Creating an Incident in SpiraTeam","text":"Zendesk agents are able to create an incident from within Zendesk that is logged directly into SpiraTeam. The app should not be visible to the public.
When an agent has a ticket, which raises an issue to pass to a development team, they open the app sidebar on the right hand side of Zendesk. They will see the following screen.
In order to log an incident, the agent must decide which project the issue relates to. SpiraTeam will list all active projects in the drop down list. If an agent is unsure which project to select, we recommend that they discuss the issue with the development team first. Select a project and click <Go>.
Zendesk will load fields specific to that project, including any custom properties or components. By default, as a minimum, the app collects Incident Type, Priority, Release, and Owner lists, all of which are required to be filled in, along with a subject field and a note.
By default, the subject field will be the same as the ticket's current subject, but the agent can change this to make as clear as possible to the developer -- changing the subject in the SpiraTeam app will NOT change the subject of the ticket itself.
The Notes to Developers is initially left blank, so that the agent can provide meaningful information. If the agent wants to include the comment history of the ticket after their own notes, click <Add comment history to description>. NOTE: clicking this repeatedly will paste in the comment history multiple times.
When a project has additional fields (such as components or custom properties), these are also displayed. The app provides a split view of the fields -- those that are required and those that are optional. The tab at the top of the app lets agents switch between both.
If the agent wishes to cancel logging the incident, or has chosen the wrong project, click the <Back> button.
Once the form has been filled in, click <Log Incident>. If any of the fields have been left blank a notification will display and the form will not be processed. Once everything has been entered correctly, Zendesk attempts to send the form to SpiraTeam, along with links to any attachments stored with the ticket.
If Zendesk is not successful, a warning notification will be displayed (see below), and the agent is asked to attempt again.
"},{"location":"Help-Desk-Integration/Zendesk/#reviewing-the-incident-in-spirateam","title":"Reviewing the Incident in SpiraTeam","text":"
Back in SpiraTeam the new incident should be visible within the main incident log. Details about the incident can be altered as needed, without risk of breaking the connection with Zendesk.
NOTE: On the incidents screen, you should notice a new field on the Overview page, called \"Zendesk ID\". This is the ID of the specific Zendesk ticket. Editing this field will break the connection and is not advised.
"},{"location":"Help-Desk-Integration/Zendesk/#reviewing-spirateam-incidents-linked-to-a-zendesk-ticket","title":"Reviewing SpiraTeam Incidents Linked to a Zendesk Ticket","text":"As soon as the incident has been successfully logged to SpiraTeam, the app in Zendesk will return to the screen showing lists of projects, in case another incident needs to be logged.
In addition, information about any incidents linked to the ticket are clearly shown, including the most up to date status from SpiraTeam so that the agent can clearly see whether an issue is resolved or not.
Hovering over a particular incident gives the agent quick access to the additional information directly in Spira.
"},{"location":"HowTo-Guides/Admins-orientation/","title":"Getting to Know Spira Administration","text":""},{"location":"HowTo-Guides/Admins-orientation/#how-to-know-what-if-anything-you-are-an-admin-of","title":"How to know what, if anything, you are an admin of","text":"You can read about the different types of administration here.
"},{"location":"HowTo-Guides/Admins-orientation/#admin-home-pages","title":"Admin home pages","text":"Users can only delete artifacts if their product role has the delete permission enable for that specific artifact. The exception to this is folders: users who have \"Bulk Edit\" permissions for the relevant artifact can also add, edit, and delete those artifacts folders.
Folder deletion: Documents, Tasks, Test Cases, and Test Sets have folders. Deleting folders is permanent and cannot be undone
Artifact deletion:
Read about the template workspace here.
"},{"location":"HowTo-Guides/Admins-templates/#how-to-create-a-new-template","title":"How to create a new template","text":"You cannot create a template by itself. You can only create a new template when creating a new product.
Administration > System > Workspace > View/Edit ProductsAdd to add a new productTemplate field. From here you can select an existing template or Create New Template.Create New Template optionInsertTo clone a template, you need to clone a product that uses the template you wish to clone
Administration > System > Workspace > View/Edit ProductsClone button on that product's rowClone templateCloneFor more information about changing a product's template see here.
Administration > System > Workspace > View/Edit ProductsEditChange TemplateNextIf you have 2+ products using the same template, but decide 1 products needs slightly different template settings, you need to branch its template off into a brand new template. This is possible, but requires a few different steps to make it work smoothly.
We have dedicated guides explaining this in detail for: Jira Cloud and Jira Server. Below is a very high level summary with further links
For more information about using login providers see the admin guide
Please Note
We have tried to give up to date and accurate information, but many providers do not themselves have correct information on their site. Hopefully they do not change things too much, but if they do and you cannot figure out what to do please contact our support team.
"},{"location":"HowTo-Guides/Login-providers/#azure-ad","title":"Azure AD","text":"To set up an Azure AD provider app with Spira you will need an Azure account with Azure AD set up with users as needed. For the steps below we have assumed Azure AD is set up in relatively standard way.
First, you need to set up the app registration, this app will give your users a specific connection to Spira. When creating an app registration you should:
SettingsDeveloper SettingsOauth Appssettings from the dropdownApplications in the lefthand sidebarThis guide assumes you already have an accessible ADFS (2016+) server, configured with users as required.
First, create the application group
Now, you need to get the specific URLs so Spira knows how to connect to your ADFS. You will need your server's base URL, to which you add the specific endpoints\u00a0
By default your urls will look like:
{server base URL}/adfs/oauth2/authorize{server base URL}/adfs/oauth2/token{server base URL}/adfs/userinfoFirst you need to create the application in Okta
Next, you need to get the necessary urls for connecting to Spira. You will need several urls specific to your Okta domain.
The authServerId will need to be configured based on your Okta setup. You can find more information about testing the server here:\u00a0https://developer.okta.com/docs/guides/customize-authz-server/test-authz-server/
Broadly, the urls may take the following shape (discuss with Okta if you run into any issues with these)
First create the application in OneLogin
Fill in the basic information about the new app:
Add existing users to the application to allow them to login to SpiraPlan using OneLogin via the \"Users\" tab
Next, you need to get the necessary information for connecting to Spira. You will need several urls specific to your OneLogin domain.
Use the \"Issuer URL\" (which will end in something like \"onelogin.com/oidc/2\") as the base url in SpiraPlan as below:
The generic OpenId providers accepts any standard compliant OAuth Provider. The required configuration will vary based on how each provider works. However, make sure that, as with other providers, that the return URI entered into the OpenId provider matches that inside SpiraPlan.
"},{"location":"HowTo-Guides/Permissions-Workflows/","title":"Permissions and Workflows","text":""},{"location":"HowTo-Guides/Permissions-Workflows/#how-do-spiras-permissions-and-workflows-work","title":"How do Spira's permissions and workflows work","text":"You give users specific roles to give them specific permissions. These permissions are mostly about what that role can do with each artifact in general. Users with a role that lets them view incidents can view every single incident in the product.
A workflow controls what a specific artifact will look like and how it can be edited. For example Bug1 may have lots of fields hidden, while Bug2 has every field visible. Bug1 and Bug2 look different because their display is controlled by different parts of a workflow system. One workflow step applies to Bug1 and a different workflow step applies to Bug2.
So roles let admins control who can see what in general. Workflow let admins control, if you can see something (say a bug), exactly how that bug (for example) should behave based the bug's state at the time. When you change an item's state (by changing this bug's status, for instance) you can change how it will look or behave.
How do you change an item's state? The most common way is changing the item's status. This is called a transition. Transitions are special because they let users make this big changes to something - for instance hiding or showing information. Because transitions can be so powerful, they can also be protected. An admin can control who can carry out each and every transition (including based on product roles).
Taken together, this system of roles and workflows, with their combination of permissions, statuses, and transitions, give admins a lot of power to customize how things should work. They are powerful, but also they can be fiddly. It can be confusing to a user or an admin why things work one way for one user, but differently for another.
The tips and tricks below should help work through the most common problems and stumbling blocks.
"},{"location":"HowTo-Guides/Permissions-Workflows/#what-does-a-workflow-do-and-control","title":"What does a workflow do and control","text":"Workflows are a way to control a number of things about your artifacts. A workflow is based on a series of steps (statuses) that you move the artifact through.
At each step you can control:
Transition are how you move from one step (status) to another. At each workflow step you can make as many transitions as you want. Each transition will move the workflow to a new step. For each transition you can control:
When you add a user to a product, you have to set the specific product role they should have. This grants them specific permissions to view certain data, edit other data, maybe the ability to delete some data too.
Each user has to be actively given a particular role for each product. In other words, you cannot make a user a member of a product without giving them a specific role. Likewise, you cannot make a user a \"Tester\" for any products they are or will be a member of.
"},{"location":"HowTo-Guides/Permissions-Workflows/#permissions","title":"Permissions","text":"The application ships with some built-in product roles but you can edit these roles or add new ones too. Each role defines if users with that role:
For example:
Your product role is used to control if you:
Product Role permissions control if users with that product role can or cannot delete a specific artifact. To stop users being able to delete artifacts, edit the product role. Make sure that the \"Delete\" checkboxes are NOT checked for all relevant artifacts.
"},{"location":"HowTo-Guides/Permissions-Workflows/#why-is-a-field-disabled-or-hidden-or-required","title":"Why is a field disabled or hidden or required","text":"Each field can be controlled by the relevant workflow to show, hide, disable, or be required. If you thought a field should be visible, but in reality it is hidden, this is the workflow at work.
The workflow controlling that specific artifact has a step that matches the current status of the specific artifact. That step sets whether each field is visible, disabled, hidden, or required. You need to work through how this is happening.
"},{"location":"HowTo-Guides/Permissions-Workflows/#how-to-make-a-field-required-or-hidden-or-disabled","title":"How to make a field required or hidden or disabled","text":"There are two ways that a field can be required. The best way to control this is through the workflow. This controls what fields are required, not required, disabled/read only, or hidden.
"},{"location":"HowTo-Guides/Permissions-Workflows/#workflow","title":"Workflow","text":"The below works for any artifact that has a workflow. Below we are changing the Incident workflow
Steps next to the workflowSaveCustom properties have a special option that says whether a blank value is allowed or not. If a blank value is allowed, then the field will onyl be required if the workflow step/status says so. If a blank value is not allowed then anytime you try to save an artifact with that field and the value is blank it will prompt you for a value.
To change if a blank value is allowed or not for a custom property: 1. Find the template that your product is using 2. As a template administrator go to Template Administration, find the artifact section you need, and click its \"Custom Properties\" link 4. Find the custom property you want to change 5. Click Edit Defintion 6. Go to the Options tab in the popup 7. Set the \"Allow Empty\" dropdown to Yes or No as desired 8. Hit Save
If you are looking at an artifact and the status has no button next to it, then you cannot change its status. The button (if there) shows which transitions you can do to move the artifact to a new status.
Why is this button missing? Either because:
Read more about these issues below
"},{"location":"HowTo-Guides/Permissions-Workflows/#why-does-a-user-not-see-the-right-transitions","title":"Why does a user not see the right transitions","text":"When a user goes to look at the detail of an artifact they may be able to change the status by transitioning from one status to another. This is called a transition. What transitions show up when for what users is controlled by a number of things.
To troubleshoot the issue you need to be a template administrator. The summary steps to review are below. Please refer to the admin guide for more information.
Save to commit any changesNote: the following does NOT apply to releases.
When you are looking at a specific artifact on its full details page, the fields you see or not and which transitions are available are determined by the workflow. However, you can have more than one actie workflow for each artifact. How can this be?
Because you can match a workflow to a specific type. This means that one type (say incidents of type bug) will use one workflow, but a different type (say incidents of type enhancement) will use a second workflow.
If you do not know why you are seeing what you are seeing for a workflow, it could be because a different workflow is actually controlling the artifact. You can check this by:
You can change the default workflow step for artifacts that let you edit their statuses.
On the relevant product template administration status page for an artifact (if present) one of the options is to pick a single default status. Changing the status will change the default status for every workflow of that artifact for that product template.
Artifacts that support editing of statuses, and picking a default workflow step are:
Other artifacts do not support editing of their statuses (Test Cases, Test Sets, Requirements, Releases, and Tasks)
"},{"location":"HowTo-Guides/Requirements/","title":"Requirements","text":""},{"location":"HowTo-Guides/Requirements/#how-to-fix-the-requirement-hierarchy","title":"How to fix the requirement hierarchy","text":"Sometimes the requirement list will not look as you expect (on the main list view or in the sidebar when looking at a single requirement). Some nodes may be hidden that should be visible, or vice versa. This can happen due to the combination of expanding/collapsing different nodes / parent requirements, and filtering requirements by different fields. You can get this back to normal by doing the following:
Clear Filter button above the table of requirements)Sometimes you may change the status of a requirement, then when you look at it again the status was the old status, not the new one you tried to change it to. What causes this?
When you run a test case or a test set it creates a \"Pending Test Run\". This is a test run that is in progress. You can see pending test runs in 2 places. From there you can also, if allowed, delete the pending test run. This will permanently delete the pending test run from everywhere for all users.
Pending test runs are works in progress and can be deleted (see above). Once a test has been finalized it becomes a Test Run. This is designed to be an immutable record of what happened during testing. Therefore we strongly discourage every deleting a test run. Instead we recommend running the test case or test set again. That is why, by default, no roles have permission to delete test runs.
If you really need to delete a test run then these are the steps to take:
Delete button that lets them to delete test runs.Refersh Test Status CacheNOTE: because we do not consider the above a usual workflow in SpiraPlan currently we do not maintain a history of test run deletions and modifications.
"},{"location":"HowTo-Guides/Testing/#how-to-change-a-test-result-after-the-test-has-been-run","title":"How to change a test result after the test has been run","text":"What do you do if a tester marked a step as passed or failed by accident? How can this be corrected? BEFORE the test is finished the tester can edit the results on the test execution screen.
Once the test run has been formally completed, the only way to update an execution status or an actual result is to rerun the test case or test set. For a test case: find the test case and hit Execute. For a test set you have a few options:
Let's say that you ran a test set with ten test cases in it. One of the test cases failed and now is ready for retest. Do you need to rerun the whole test set of ten test cases? Or is there a quicker way?
To update part of a test set result you can optionally selectively execute just part of it. There are two ways to do this:
Execute button just above the list of test cases (or from the context menu on the test case table). This will only execute those test cases.Test cases contain test steps. These steps can be edited in a number of ways: each step has properties that you can edit; you can add and remove steps; and you can change the order of the steps.
You may want to control who can edit test steps, and when they can edit them.
Control who can edit test steps: set your product roles so that only users with certain roles can modify test steps.
Control when anyone can edit test steps: using the test case workflow, you can control what fields of the test case are editable, disabled, hidden, or required. For each workflow step, make sure to review the \"Test Steps?\" row.
Together, controlling who, and when, give you a lot of flexibility in managing your test steps (and other artifacts too).
"},{"location":"HowTo-Guides/Testing/#setting-up-scheduled-test-automation","title":"Setting up scheduled test automation","text":"SpiraPlan gives users powerful ways to execute tests, integrate with external testing tools, and schedule automate testing right from inside the web application.
Executing scheduled automated test cases in SpiraPlan needs the following setup:
Automation Engine Itself: make sure you have an automation engine (application) installed and setup on a machine. For example, if using RemoteLaunch:
Automation Host: each product needs dedicated Automation Hosts. Setup one for each computer that is going to run an automated test case. Make sure that the token field is meaningful and unique (for example, that it is the same as the matching field in RemoteLaunch).
Test Set (with its test cases): create a test set to be the wrapper for your automated test (automated test cases can only be executed within a test set). Make sure to set the following fields on the test set:
Wait: when your planned dates go by, the automation engine will query for any tests that are now ready for its specific automation host and will then execute the test, reporting the results back to SpiraPlan.
From left to right, it has links and dropdowns for the following:
What is an artifact list page?
Clicking on a specific artifact from its page or elsewhere will open the artifact details page. What is an artifact details page?
This section outlines how to use SpiraTest, SpiraPlan or SpiraTeam (hereafter referred to as SpiraTeam) in conjunction with the Eclipse integrated development environment (IDE) for implementing Requirements, completing Tasks and fixing Incidents. Rather than develop a new user-interface from scratch, the SpiraTeam plug-in uses the generic Mylyn task-based interface that allows Eclipse users to manage their local tasks and tasks from any compatible repository in a single interface.
"},{"location":"IDE-Integration/Eclipse--Mylyn/#installing-the-eclipse-plug-in","title":"Installing the Eclipse Plug-In","text":"This section outlines how to install the SpiraTeam plug-in for Eclipse. It assumes that you already have a working installation of SpiraTest, SpiraPlan or SpiraTeam v6.0 or later and a working installation of Eclipse v4.6 (Neon) or later with the Mylyn plug-in installed.
If you have an earlier version of SpiraTeam, you will need to upgrade to at least v6.0 before trying to integrate with Eclipse.
To obtain the Eclipse plug-in, open up the Eclipse application and click on Help > Eclipse Marketplace. Enter \"SpiraTeam\" in the 'Find' text box. Once you hit enter, you should see the following result:
Click the Install button, accept the terms of the license and click \"Finish\". Eclipse will advise you that our software contains unsigned content, press \"OK\" to continue the installation. After you restart Eclipse, you can start to use our plug-in.
Alternatively, you can click Help > Install New Software. This will display the Eclipse installation wizard:
Enter https://www.inflectra.com/Downloads/Eclipse as the download site in the \"Work with:\" text box and uncheck the \"Group items by category\" checkbox. Once you hit enter, the wizard should display \"SpiraTeam\". Select the Feature's checkbox and click \"Next\" or \"Finish\" to tell Eclipse to download and install the feature and dependent plug-ins. During this process you may be asked to agree to our software license and to allow the installation of unsigned software. Once you have completed these steps, you should now have our SpiraTeam plug-in installed and ready to use.
To check that the individual plugins have been installed, you can go to Help > About Eclipse and then click on the [Installation Details] button. On the page that appears, click on the Plugins tab and you will see the two Inflectra plugins listed (Core and UI).
Now that you have the plug-ins installed, the next steps are:
Connect to the appropriate SpiraTeam repository
Download your assigned SpiraTeam artifacts (Requirements, Tasks and Incidents)
Work on the downloaded SpiraTeam artifacts
To connect to a SpiraTeam repository, you need to first display the appropriate Eclipse views. To do this, go to Window > Show View > \"Other...\" and then under the Tasks section, display both the Task Repositories view and the Task List view:
Once you have chosen to select the Task Repositories, the following tab will be displayed:
Where any existing repositories will listed along with the built-in \"Local\" repository that is used to manage tasks created natively within Eclipse/Mylyn.
To connect to a new SpiraTeam repository, right-click on the window and choose \"Add Task Repository...\" which will bring up the following selection box:
Choose the \"Spira\" repository entry and click [Next]. This will bring up the repository configuration dialog box:
On this screen, you need to fill out the information used to connect to your SpiraTeam server:
Server -- This should be the URL to the SpiraTeam instance that you are accessing.
Label -- This is a \"friendly\" name for that server that will be used inside Eclipse.
User ID -- This needs to be a valid username that has access to SpiraTeam.
Password -- This needs to be the correct API Key for the username specified. Although the Eclipse label says Password, you need to use the Spira username and API Key NOT password.
Once you have entered the information, click [Finish] to complete the \"Add Repository\" wizard. Once this has been done, Eclipse will ask you if you would like to add a new query for this repository. You can choose either Yes or No. The process for adding a new query to the SpiraTeam repository is described in the next section.
Once you have added the SpiraTeam repository, the repository list view should now look something like:
You can now add a new query by right-clicking on the SpiraTeam repository instance and choosing \"New Query...\". This will bring up the new query wizard:
Currently the SpiraTeam Eclipse/Mylyn plugin only supports the three predefined queries listed above. You can choose to add a list of Requirements, Incidents or Tasks that are assigned to you. Once you have added the appropriate queries (depending on which types of artifact get assigned to you), the list of Requirements, Incidents and or Tasks will be downloaded from the server and added to your Task List in Eclipse:
When you hover the mouse over any of the items in the list of Requirements, Incidents or Tasks, you will see a popup tooltip that provides additional information:
Artifacts in the list have various states, based on your interaction with them. Unread artifacts are those with new changes, which you haven't seen yet. These artifacts are denoted as having \"incoming changes\" (coming from repository). When you open and edit the artifact, it will have local modifications which haven't been sent to SpiraTeam repository yet (outgoing changes).
The following UI Legend explains meaning of various icons which are displayed in the Eclipse/Mylyn Task List:
As you can see, the different SpiraTeam artifacts are represented by different graphic overlays that let you know if the Eclipse/Mylyn task is really a SpiraTeam Requirement, Incident or Task.
To refresh the list of tasks in Eclipse, you can either right-click on the appropriate query folder and choose \"Synchronize\" or just press the F5 key on the keyboard.
Each of the different artifacts (Requirements, Incidents and Tasks) works slightly differently, so please refer to the appropriate section for details on how to view and edit.
"},{"location":"IDE-Integration/Eclipse--Mylyn/#viewing-and-editing-requirements-in-eclipse","title":"Viewing and Editing Requirements in Eclipse","text":"When you view the list of Requirements in the Eclipse task list, it will have the following general form:
Each Requirement is listed by name and number, together with its importance indicated by the equivalent Eclipse/Mylyn priority icon. To view the details of a specific Requirement, you should double-click on the Requirement, and the Requirements editor will be opened:
The Requirements editor screen is divided up into several sections:
Header -- this displays the name and ID of the Requirement, together with a graphical indication of its priority, its status, creation date and last-update date.
Attributes -- this displays the various SpiraTeam-specific attributes of the Requirement, including status, importance, scheduled release, component ID and planned effort. Any custom properties defined for the requirement will also be displayed.
Attachments -- this displays the list of documents, web-links and screenshots attached to the Requirement. You can also upload new files and screenshots to the Requirement from within Eclipse.
Description -- this displays the detailed description of the Requirement.
Comments -- this displays a threaded list of all the comments that have been added to the Requirement in SpiraTeam.
New Comment -- this allows you to add a new comment to the Requirement. The new comments will be sent to the SpiraTeam server when [Submit] is clicked.
People -- this displays the name and email address of the person who wrote the Requirement (author) and the person who it's currently assigned-to (owner).
Operations -- this contains the list of operations that can be performed on the Requirement. More information on operations can be found below.
You can make changes to the Requirement by simply changing the values in the appropriate dropdown list or editing the information in any of the text boxes. Once you have happy with the changes, you can update the version on the SpiraTeam server by clicking the [Submit] button. If there are any data validation errors, they will be displayed. Once you have corrected them, the Requirement changes will be accepted by the system.
In addition to making updates, you can perform the following actions on the Requirement:
Workflow Transitions -- these are the blue hyperlinks displayed directly above the [Submit] button in the actions tab. These allow you to change the status of the Requirement and when clicked, the fields in the Attributes section will change based on the new status. Note: changing the Type of the Requirement will disable the workflow transition hyperlinks until [Submit] is clicked.
Refresh the Requirement from the version on the server. This will update the local copy of the Requirement with the latest changes made on the SpiraTeam server.
Browse the version of the Requirement on the server. Clicking the \"globe\" icon will open up a browser and display the Requirement directly in SpiraTeam.
"},{"location":"IDE-Integration/Eclipse--Mylyn/#viewing-and-editing-tasks-in-eclipse","title":"Viewing and Editing Tasks in Eclipse","text":"When you view the list of Tasks in the Eclipse task list, it will have the following general form:
Each Task is listed by name and number, together with its priority indicated by the equivalent Eclipse/Mylyn priority icon. To view the details of a specific Task, you should double-click on the Task, and the Tasks editor will be opened:
The Tasks editor screen is divided up into several sections:
Header -- this displays the name and ID of the Task, together with a graphical indication of its priority, its status, creation date and last-update date.
Attributes -- this displays the various SpiraTeam-specific attributes of the Task, including status, scheduled release, priority, start-date, end-date, % complete, estimated effort, actual effort, the name/id of the Requirement it belongs to and its component. Any custom properties defined for the task will also be displayed.
Attachments -- this displays the list of documents, web-links and screenshots attached to the Task. You can also upload new files and screenshots to the Task from within Eclipse.
Description -- this displays the detailed description of the Task.
Comments -- this displays a threaded list of all the comments that have been added to the Task in SpiraTeam.
New Comment -- this allows you to add a new comment to the Task. The new comments will be sent to the SpiraTeam server when [Submit] is clicked.
People -- this displays the name and email address of the person who created the Task (creator) and the person who it's currently assigned-to (owner).
Operations -- this contains the list of operations that can be performed on the Task. More information on operations can be found below.
You can make changes to the task by simply changing the values in the appropriate dropdown list or editing the information in any of the text boxes. Once you have happy with the changes, you can update the version on the SpiraTeam server by clicking the [Submit] button. If there are any data validation errors (e.g. you have to enter a start-date to make the Task In-Progress), they will be displayed. Once you have corrected them, the Task changes will be accepted by the system.
In addition to making updates, you can perform the following actions on the Task:
Workflow Transitions -- these are the blue hyperlinks displayed directly above the [Submit] button in the actions tab. These allow you to change the status of the Task and when clicked, the fields in the Attributes section will change based on the new status. Note: changing the Type of the Task will disable the workflow transition hyperlinks until [Submit] is clicked.
Refresh the Task from the version on the server. This will update the local copy of the Task with the latest changes made on the SpiraTeam server.
Browse the version of the Task on the server. Clicking the \"globe\" icon will open up a browser and display the Task directly in SpiraTeam.
"},{"location":"IDE-Integration/Eclipse--Mylyn/#viewing-and-editing-incidents-in-eclipse","title":"Viewing and Editing Incidents in Eclipse","text":"When you view the list of Incidents in the Eclipse task list, it will have the following general form:
Each Incident is listed by name and number, together with its priority indicated by the equivalent Eclipse/Mylyn priority icon. To view the details of a specific Incident, you should double-click on the Incident, and the Incidents editor will be opened:
The Incidents editor screen is divided up into several sections:
Header -- this displays the name and ID of the Incident, together with a graphical indication of its priority, its status, creation date and last-update date.
Attributes -- this displays the various SpiraTeam-specific attributes of the Incident, including priority, severity, status, type, detected release, resolved release, verified release, start-date, closed-date, % complete, estimated effort, actual effort and component Id's. Any custom properties defined for the incident will also be displayed.
Attachments -- this displays the list of documents, web-links and screenshots attached to the Incident. You can also upload new files and screenshots to the Task from within Eclipse.
Description -- this displays the detailed description of the Incident.
Comments -- this displays a threaded list of all the comments that have been added to the Incident in SpiraTeam.
New Comment -- this allows you to add a new comment to the Incident. The new comments will be sent to the SpiraTeam server when [Submit] is clicked.
People -- this displays the name and email address of the person who found the Incident (detector) and the person who it's currently assigned-to (owner).
Operations -- this contains the list of operations that can be performed on the Incident. See below for more information on how to use this section.
You can make changes to the Incident by simply changing the values in the appropriate dropdown list or editing the information in any of the text boxes. Once you have happy with the changes, you can update the version on the SpiraTeam server by clicking the [Submit] button. If there are any data validation errors (e.g. you have to enter a start-date to make the Incident In-Progress), they will be displayed. Once you have corrected them, the Incident changes will be accepted by the system.
In addition to making simple updates, you can perform the following actions on the Incident:
Submit -- clicking the submit button will commit the changes made on the Incident to the SpiraTeam Server.
Workflow Transitions -- these are the blue hyperlinks displayed directly above the [Submit] button in the actions tab. These allow you to change the status of the Incident and when clicked, the fields in the Attributes section will change based on the new status. Note: changing the Type of the Incident will disable the workflow transition hyperlinks until [Submit] is clicked.
Refresh the Incident from the version on the server. This will update the local copy of the Incident with the latest changes made on the SpiraTeam server.
Browse the version of the Incident on the server. Clicking the \"globe\" icon will open up a browser and display the Incident directly in SpiraTeam.
"},{"location":"IDE-Integration/Jetbrains-IDEs/","title":"Jetbrains IDEs","text":"This section outlines how to use SpiraTest, SpiraPlan or SpiraTeam (hereafter referred to as SpiraTeam) in conjunction with any Jetbrains integrated development environment (IDE) for viewing Requirements, Tasks and Incidents. Rather than develop a new user-interface from scratch, the SpiraTeam plug-in uses the robust tool window functionality in Jetbrains IDEs which allows users to customize their experience.
"},{"location":"IDE-Integration/Jetbrains-IDEs/#installing-the-jetbrains-plug-in","title":"Installing the Jetbrains Plug-In","text":"This section outlines how to install the SpiraTeam plug-in for Jetbrains. It assumes that you already have a working installation of SpiraTest, SpiraPlan or SpiraTeam v5.0 or later and an up-to-date version of your Jetbrains IDE. For this tutorial we will be installing the plug-in in IntelliJ, Jetbrains' Java IDE.
If you have an earlier version of SpiraTeam, you will need to upgrade to at least v5.0 before trying to integrate with Jetbrains.
To obtain the Jetbrains plug-in, open up the Jetbrains settings dialog at File > Settings. This will open the settings dialog. Click on the \"Plugins\" section on the left. Your screen should look something like this:
Click on the \"Browse repositories\" button on the bottom of the screen, and enter \"SpiraTeam\" into the search bar. You should see the following result:
Click the Install button. After it has installed you will be asked to restart your IDE.
After your IDE has restarted, go to View > Tool Windows > SpiraTeam to open up the SpiraTeam Tool Window.
Click on the \"View Credentials\" button and put in your log-in credentials. Please note that you can obtain the RSS Token by going to your user profile inside SpiraTeam. If the RSS Token is blank, make sure to enable RSS, and click Save.
NOTE: this plugin lets users create artifacts in Spira, so please make sure that the user has create permissions for incidents and tasks to make full use of it.
Once you press the OK button, wait for the window to close. If your log-in information is correct, you should see the following screen in the SpiraTeam Tool Window:
"},{"location":"IDE-Integration/Jetbrains-IDEs/#viewing-requirements-tasks-and-incidents-in-jetbrains","title":"Viewing Requirements, Tasks and Incidents in Jetbrains","text":"Clicking on Requirements, Tasks or Incidents will expand a list of their respective item's that are open and are assigned to you. If, for instance, you have no open requirements assigned to you, you will not see the \"Requirements\" title in the SpiraTeam window. Here is an example of all three expanded:
Clicking on any requirement, task or incident will open up additional information in the bottom of the tool window. Clicking the title in this additional information panel will open the relevant item in SpiraTeam in your default browser.
"},{"location":"IDE-Integration/Jetbrains-IDEs/#creating-new-requirements-tasks-and-incidents-in-jetbrains","title":"Creating new Requirements, Tasks, and Incidents in Jetbrains","text":"Clicking the \"New\" button at the top of the SpiraTeam window or navigating to Tools > SpiraTeam > New Item will bring up the new item popup.
After you select your project and item type, the type, priority and owner fields will populate appropriately. If you do not wish to select a priority or owner, simply select \"---None --\" for either of them, and the field will not be populated in SpiraTeam.
Once you press OK, your artifact will be created and you will get a notification in the SpiraTeam Tool Window like this one:
Clicking on the notification label will dismiss it.
"},{"location":"IDE-Integration/Jetbrains-IDEs/#miscellaneous-functions","title":"Miscellaneous Functions","text":"If you want to change the user you are signed in as, you simply need to click on your username on the right of the \"Signed in as\" label.
Clicking the \"Refresh\" button will refresh your assigned items from the server, while the \"Home\" button will take you to your My Page in your default browser. Navigating to Tools > SpiraTeam will bring up another way of interacting with SpiraTeam
"},{"location":"IDE-Integration/Visual-Studio-2005---2008/","title":"Visual Studio 2005 - 2008","text":"This section outlines how to use SpiraTest, SpiraPlan or SpiraTeam (hereafter referred to as SpiraTeam) in conjunction with the Visual Studio (VS) integrated development environment (IDE) for viewing Requirements, completing Tasks and fixing Incidents.
The Add-In will operate in Visual Studio 2005 and 2008 but does require that the .NET framework version 3.5 SP1 is installed. It is normally installed with Visual Studio 2008 SP1 and Visual Studio 2010, but can be separately installed on a system with Visual Studio 2005 by downloading the installation file from Microsoft: http://www.microsoft.com/downloads/details.aspx?FamilyID=ab99342f-5d1a-413d-8319-81da479ab0d7
Visual Studio Express versions cannot support Add-Ins, you must at least have the standard version of the IDE for the Add-In to appear in the menu bar.
"},{"location":"IDE-Integration/Visual-Studio-2005---2008/#installing-the-visual-studio-add-in","title":"Installing the Visual Studio Add-In","text":"Download and execute the Add-In installation file from the Inflectra website. The add-in will be automatically added to VS's menu bar.
"},{"location":"IDE-Integration/Visual-Studio-2005---2008/#adding-and-assigning-spirateam-projects","title":"Adding and Assigning SpiraTeam Projects","text":"To view the Project Explorer, select \"SpiraTeam Project Explorer\" from the View menu. The tool window will open, and can be docked with any existing tool windows. When a solution is loaded that hasn't had any SpiraTeam projects assigned to it -- or if no solution is open -- the dialog will report so. If you have already assigned SpiraTeam projects to the open solution, they will each be loaded in a tree format in the tool window.
Visual Studio will remember the docking and location of the window, so that if you close it you can re-open it by selecting the menu option a second time. The window will re-open in the last position before it was closed.
Once the Project Explorer is open, click the \"Configuration\" button () in the Project Explorer's toolbar to open the SpiraTeam project dialog. Note that if you have no solution open, you can add, remove, and edit SpiraTeam projects, but you can only assign them to a solution when that solution is open:
Click the New button (
) to link to a new SpiraTeam project. The \"new SpiraTeam Project\" dialog will open. In the fields, enter in the following:
Server URL: The root address of your SpiraTeam installation. For example:
https://server1/SpiraTeam/ Do not put \"login.aspx\" or any other page address in this field.
User ID: Your user ID you use to log into the SpiraTeam application.
Password: Your password you use to log into the SpiraTeam application.
Once entered, click the \"Get Projects\" button. The add-in will connect to the server and get a list of projects that you are assigned to. Select the SpiraTeam project that you want to add, and click the \"Save\" button. Your project will appear in the dialog in the format of \"Project Name [Server]\". With a project selected in the left box, you can also Edit () and Delete ( ) the project.
With a solution loaded, you can select any number of SpiraTeam projects and assign them to the open Solution, by highlighting them, and clicking the \"Add >\" button. All projects assigned to the open solution will appear in the right side.
Clicking \"Save\" will return you to the IDE, and if you made any changes in the configuration, the Project Explorer will refresh and update its display.
"},{"location":"IDE-Integration/Visual-Studio-2005---2008/#viewing-spirateam-project-artifacts","title":"Viewing SpiraTeam Project Artifacts","text":"Once a solution is opened and there is a SpiraTeam project assigned, you can view the project's contents. At this time, the add-in will display the following items:
Incidents: Assigned to you, unassigned.
Tasks: Assigned to you, unassigned.
Requirements: Assigned to you.
By default, the Project Explorer will not show closed and completed items. However, by clicking the 'View Closed' () button in the toolbar, the Project Explorer will be updated to show closed and completed items as well.
Double-clicking on a node (or clicking on the item's arrow) will open that item up and show all the sub-items.
Clicking the Refresh () button on the toolbar will refresh the SpiraTeam projects in the Project Explorer. Double-clicking an artifact will open its details in the main tabbed document area for viewing and editing.
"},{"location":"IDE-Integration/Visual-Studio-2005---2008/#viewing-artifact-details","title":"Viewing Artifact Details","text":"By double-clicking an artifact in the Project Explorer, you can open the details for the item in the main tabbed-document view. All the details screens are very similar, here is the Incident Details view for reference:
The top of the window has the \"Save\" button, and any informational or warning messages will appear to the right of the Save button. The rest of the window has detail fields relating to the item, and depending on the current workflow, some fields may be required or disabled. (Note that at this time, Requirements are read-only.)
Once you make changes to the artifact, changes are saved to the server when the \"Save\" button is clicked.
Note that due to platform architecture differences, the HTML description may not appear and save exactly as entered, and there is no 'Source HTML' view. If visual integrity/layout is important, then we recommend editing the description and resolution fields in SpiraTeam's Web user interface instead.
"},{"location":"IDE-Integration/Visual-Studio-2005---2008/#data-concurrency-warnings","title":"Data Concurrency Warnings","text":"When trying to save an artifact, you may get a warning at the top of the window stating that the item was modified by another user. This error is telling you that changes were made to the item after the data on your screen was pulled from the server.
When this happens, you may see some fields highlighted in yellow or red. The colors represent data collisions:
Yellow -- Any field highlighted yellow is a field that you tried to change that wasn't changed by the other user.
Red -- Any field highlighted in red is a field that both you and the other user tried to change.
No Highlight -- Fields without a highlight were possibly changed by the other user, but you did not make any changes to those fields.
When a concurrency issue occurs, the new data is loaded from the server, losing your changes due to possible workflow collisions. Simply review the changed data and make your changes accordingly.
"},{"location":"IDE-Integration/Visual-Studio-2005---2008/#troubleshooting","title":"Troubleshooting","text":"The add-in is designed to capture all errors so that when something unexpected happens, work isn't lost. In most situations where an error occurs, a notification will be displayed of the error. In the Project Explorer, hover the mouse over the error node to get a full description of the error. Errors will also be logged to the desktop's Application Event Log.
A common symptom of an internal error is a blank or empty Details screen -- if this occurs when opening an artifact, save all your open work and restart Visual Studio. Contact support with the Application Event Log and inform them of the issue.
"},{"location":"IDE-Integration/Visual-Studio-2010/","title":"Visual Studio 2010","text":"This section outlines how to use SpiraTest, SpiraPlan or SpiraTeam (hereafter referred to as SpiraTeam) in conjunction with the Visual Studio (VS) integrated development environment (IDE) for viewing Requirements, completing Tasks and fixing Incidents.
This add-in is meant for use with Visual Studio 2010 or later and SpiraTest, SpiraPlan or SpiraTeam (hereafter referred to as SpiraTeam) version v4.0 or later. It does require that .NET v4.0 is installed; however this is required by Visual Studio 2010 by default.
"},{"location":"IDE-Integration/Visual-Studio-2010/#installing-the-visual-studio-add-in","title":"Installing the Visual Studio Add-In","text":"The Visual Studio 2010 version can be downloaded from the Inflectra SpiraTeam add-ons webpage:
Please do not use the version in the Visual Studio gallery, that is the newer Visual Studio 2012 extension which is not compatible with Visual Studio 2010.
"},{"location":"IDE-Integration/Visual-Studio-2010/#adding-and-assigning-spirateam-projects","title":"Adding and Assigning SpiraTeam Projects","text":"After installing, a new menu item will appear under the \"View\" menu.
To view the Project Explorer, select \"SpiraTeam Project Explorer\" from the View menu. The tool window will open, and may be docked like any other tool window. When a solution is loaded that hasn't had any SpiraTeam projects assigned to it -- or if no solution is open -- the tool window will give a message saying so. Once a project is loaded that contains linked SpiraTeam projects, or a SpiraTeam project is added to the current open solution, then the tool window will load in the SpiraTeam projects and display them.
To add, remove, and assign a SpiraTeam project to the open solution, click the Configuration Button in the Tool Window (), which will open the configuration dialog:
Click the New button () to link to a new SpiraTeam project. The \"new SpiraTeam Project\" dialog will open. In the fields, enter in the following:
Server URL: The root address of your SpiraTeam installation. For
example: https://server1/SpiraTeam/ Do not put \"login.aspx\" or any other page address in this field.
User ID: Your user ID you use to log into the SpiraTeam application.
Password: Your password you use to log into the SpiraTeam application.
Once entered, click the \"Get Projects\" button. The add-in will connect to the server and get a list of projects that you are assigned to. Select the SpiraTeam project that you want to add, and click the \"Save\" button. Your project will appear in the dialog in the format of \"Project Name [Server]\". With a project selected in the left box, you can also Edit () and Delete () the project.
With a solution loaded, you can select any number of SpiraTeam projects and assign them to the open Solution, by highlighting them, and clicking the \"Add >\" button. All projects assigned to the open solution will appear in the right side.
Clicking \"Save\" will return you to the IDE, and if you made any changes in the configuration, the Project Explorer will refresh and update its display.
"},{"location":"IDE-Integration/Visual-Studio-2010/#viewing-spirateam-project-artifacts","title":"Viewing SpiraTeam Project Artifacts","text":"Once a solution is opened and there is a SpiraTeam project assigned, you can view the project's contents. At this time, the add-in will display the following items:
Incidents: Assigned to you and unassigned.
Tasks: Assigned to you and unassigned.
Requirements: Assigned to you and unassigned.
By default, the Project Explorer will not show closed and completed items. However, by clicking the 'View Closed' () button in the toolbar, the Project Explorer will be updated to show closed and completed items as well.
Double-clicking on a node (or clicking on the item's arrow) will open that item up and show all the sub-items:
Clicking the Refresh () button on the toolbar will refresh the highlighted item in the tree, and all sub-items contained within it. SpiraTeam projects in the Project Explorer.
All items have a right-click menu, and the options available for items are as follows:
View Details: Opens the details of the item in a tool window inside the IDE.
View in Browser: Opens the details of the item in a browser.
Start/Stop Timer: For Tasks and Incidents only. Starts or Stops a work timer for that item.
Refresh List: For folders and project only. Refreshes the folder or project's contents.
Copy to Clipboard: Copies the artifact's token into the clipboard, for easy pasting into Version Control commits or descriptions.
By double-clicking an artifact in the Project Explorer, you can open the details for the item in the main tabbed-document view. All the details screens are very similar.
All of the fields closely match the fields as they appear in SpiraTeam's interface. The toolbar at top lets you Save the item, Refresh the details, and view the item in the browser if you so wish. Tasks and Incidents also have a Work Timer button on the toolbar, which lets a developer mark an item as being worked on, and when the developer stops working, it will update the fields with any time worked. Incident screens also have the Workflow steps up in the toolbar under the \"Change Status\" dropdown.
Once you make changes to the artifact, changes are saved to the server when the \"Save\" button is clicked.
Note: Due to platform architecture differences, the HTML description may not appear and save exactly as entered, and there is no 'Source HTML' view. If visual integrity/layout is important, then we recommend editing the description and resolution fields in SpiraTeam's Web user interface instead.
"},{"location":"IDE-Integration/Visual-Studio-2010/#data-concurrency-and-errors-while-saving","title":"Data Concurrency and Errors while Saving","text":"In the case an item was changed by someone else while the details screen was open, you will get an error indicating that the item was changed. There are two possible options at this point:
If the data that was changed locally does not conflict with any changes made by the other user, then you will be given the option to Merge or Reload the data.
If a field was changed locally that was also changed by another user, the only option that will be given will be to reload the data.
If you opt to merge, then changes taken from the other user will be merged with your changes, and the item will be saved to the server. However, if you choose to reload, then your changes will be lost and you will need to make your changes again.
For incidents, some fields may be marked as being required by the current workflow. In this case, the labels will be highlighted in bold. If you try to save an item without all required fields, an error will be displayed, and the field in error will be highlighted in red.
"},{"location":"IDE-Integration/Visual-Studio-2010/#troubleshooting","title":"Troubleshooting","text":"The add-in is designed to capture all errors so that when something unexpected happens, work isn't lost. In most situations where an error occurs, a notification will be displayed of the error. In the Project Explorer, hover the mouse over the error node to get a full description of the error. Errors will also be logged to the desktop's Application Event Log or a text file in case there was a problem connecting to the Event Log on the local computer.
A common symptom of an internal error is a blank or empty Details screen -- if this occurs when opening an artifact, save all your open work and restart Visual Studio. Contact support with the Application Event Log and inform them of the issue.
"},{"location":"IDE-Integration/Visual-Studio-Code/","title":"Visual Studio Code","text":"This plugin creates a new custom view which allows you to seamlessly view your assigned Spira Tasks, Requirements, and Incidents as well as create brand new Tasks right from Visual Studio Code.
"},{"location":"IDE-Integration/Visual-Studio-Code/#guide-basics","title":"Guide Basics","text":"Unfortunately, this plugin only works with version 5.3 and above of the Spira ALM suite. If you have an older version, you need to update to use this plugin.
This guide assumes you are familiar with Visual Studio Code and have already installed our plugin from the store.
"},{"location":"IDE-Integration/Visual-Studio-Code/#logging-in","title":"Logging in","text":"Open the command palette and type in 'credentials' as shown:
Hit return to begin the Spira authentication process. You should see an input box that asks you to type the base URL of your Spira service. This should access the 'root' directory of your Spira, not including the ending slash. An example is provided below:
Hit return when you typed in your URL to move on to the next step. You will be prompted to enter your Spira username, which you use when signing into your Spira subscription. See the example below for assistance.
After you entered your username, hit return to move onto your final step. You will be prompted to enter your RSS Token, which must be enabled in your user profile to work.
Here is the location of the RSS Token in your profile:
Here is a sample image of a (fake) RSS Token:
"},{"location":"IDE-Integration/Visual-Studio-Code/#viewing-your-assigned-requirements-tasks-and-incidents","title":"Viewing your Assigned Requirements, Tasks, and Incidents","text":"You should see a new icon on the left menu where the explorer, search bar, version control, etc are expanded from. Alternatively, you can expand the view by pressing alt+s Here is an image of the Spira icon:
Click on the new icon to open the Spira panel where you can see all of the Tasks, Requirements, and Incidents that are assigned to you. You can expand/collapse any of the different types of items. You should now see a view similar to this:
Clicking on one of the different items, 'Cannot log into the application' for instance will bring up a view similar to this:
Ctrl clicking on the url for the artifact will open the selected item in your default browser.
"},{"location":"IDE-Integration/Visual-Studio-Code/#refreshing-your-assigned-items-from-spira","title":"Refreshing your Assigned Items from Spira","text":""},{"location":"IDE-Integration/Visual-Studio-Code/#refreshing-automatically","title":"Refreshing Automatically","text":"By default, your assigned items are refreshed every 60 seconds. If you would like to change this, see Changing Auto-Refresh Time
Changing the setting will affect how often the server is pinged to refresh the list. If you put in 0 or below, the list will never automatically refresh, and a value between 1 and 5 will default to 5 seconds. If you changed the setting from 0 or below to above 0, please refresh manually as shown below:
"},{"location":"IDE-Integration/Visual-Studio-Code/#refreshing-manually","title":"Refreshing Manually","text":"Running 'Spira - Refresh' in the command palette or hitting alt+s, alt+r by default on windows will refresh manually.
"},{"location":"IDE-Integration/Visual-Studio-Code/#creating-a-new-task","title":"Creating a new Task","text":"You can easily create a new task in VS Code by running 'Spira - Create New Task' in the command palette or by hitting alt+s, alt+t on windows. This will take any highlighted text and dump it into the name prompt. Feel free to change the name if you like.
Hit return and select a project from the dropdown as shown below:
Hit return and you should see it in the Spira panel on the left and get a popup in the bottom right telling you it was a success!
"},{"location":"IDE-Integration/Visual-Studio-Code/#settings","title":"Settings","text":""},{"location":"IDE-Integration/Visual-Studio-Code/#changing-auto-refresh-time","title":"Changing Auto-Refresh Time","text":"By default, the panel will refresh every 60 seconds, but this can easily be changed or disabled altogether through settings. To change this, open up your settings and search for 'spira' as shown below:
"},{"location":"IDE-Integration/Visual-Studio-Code/#disabling-an-item-type","title":"Disabling an Item Type","text":"If you like, you can prevent displaying a particular item type. This can be particularly useful if you only want to view your assigned tasks, which should also decrease load times. To accomplish this, simply search 'spira' in settings and switch any of the 'showType' settings to false. See the image below for an example:
"},{"location":"IDE-Integration/Visual-Studio/","title":"Visual Studio","text":"This section outlines how to use SpiraTest, SpiraPlan or SpiraTeam (hereafter referred to as SpiraTeam) in conjunction with the Visual Studio (VS) integrated development environment (IDE) for viewing Requirements, completing Tasks and fixing Incidents.
This add-in is meant for use with Visual Studio 2012 or later and SpiraTest, SpiraPlan or SpiraTeam (hereafter referred to as SpiraTeam) version v5.0 or later. It does require that .NET v4.5 be installed; however this is required by Visual Studio 2012 by default.
"},{"location":"IDE-Integration/Visual-Studio/#installing-the-visual-studio-add-in","title":"Installing the Visual Studio Add-In","text":"The addin is downloadable from Microsoft's Visual Studio Gallery, or from within Visual Studio by going to Tools -> Extension Manager and searching for \"SpiraTeam\". If downloaded from within Visual Studio, after installation the IDE will need to be restarted. If downloaded from the browser, double-click on the VSIP file and it will walk you through the installation process.
"},{"location":"IDE-Integration/Visual-Studio/#adding-and-assigning-spirateam-projects","title":"Adding and Assigning SpiraTeam Projects","text":"After installing, a new menu item will appear under the \"View\" menu:
To view the Project Explorer, select \"SpiraTeam Project Explorer\" from the View menu. The tool window will open, and may be docked like any other tool window. When a solution is loaded that hasn't a SpiraTeam project assigned to it -- or if no solution is open -- the tool window will give a message saying so:
Once a project is loaded that contains linked SpiraTeam projects, or a SpiraTeam project is added to the current open solution, then the tool window will load in the SpiraTeam projects and display them.
To add, remove, and assign a SpiraTeam project to the open solution, click the SpiraTeam Configuration Button in the Tool Window (looks like a cog), which will open the configuration dialog:
In the fields, enter in the following:
Server URL: The root address of your SpiraTeam installation. For
example: https://server1/SpiraTeam/ Do not put \"login.aspx\" or any other page address in this field.
User ID: Your user ID you use to log into the SpiraTeam application.
Password: Your password you use to log into the SpiraTeam application.
Once entered, click the \"Get Projects\" button. The add-in will connect to the server and get a list of projects that you are assigned to.
Select the SpiraTeam project that you want to add, and click the \"Save\" button.
Clicking \"Save\" will return you to the IDE, and if you made any changes in the configuration, the Project Explorer will refresh and update its display.
"},{"location":"IDE-Integration/Visual-Studio/#viewing-spirateam-project-artifacts","title":"Viewing SpiraTeam Project Artifacts","text":"Once a solution is opened and there is a SpiraTeam project assigned, you can view the project's contents. At this time, the add-in will display the following items:
Users: Users in your Spira contacts list
Incidents: Assigned to you and open.
Tasks: Assigned to you and not completed.
Requirements: Assigned to you and not developed yet.
Double-clicking on a node (or clicking on the item's arrow) will open that item up and show all the sub-items:
Clicking the Refresh button on the toolbar will refresh the highlighted item in the tree, and all sub-items contained within it. SpiraTeam projects in the Project Explorer.
All items have a right-click menu, and the options available for items are as follows:
View in Browser: Opens the details of the item in your current web browser.
Refresh List: For folders and project only. Refreshes the folder or project's contents.
Copy to Clipboard: Copies the artifact's token into the clipboard, for easy pasting into Version Control commits or descriptions.
By double-clicking an artifact in the Project Explorer (or choosing View in Browser), you can open the details for the item in the current tab of your web browser:
In addition, when you select one of the items in the add-in treeview, the add-in will display the properties for that item in the standard Visual Studio properties window:
This lets you decide whether you want to open the item in SpiraTeam before actually doing so. In a similar vein, there is a helpful tooltip displayed for all items in the tree:
"},{"location":"IDE-Integration/Visual-Studio/#creating-a-task","title":"Creating a Task","text":"If you click on the (+) icon in the extension toolbar you will be able to quickly log a new task in SpiraTeam or SpiraPlan, making it easier to track new developer tasks and have them sync across machines:
Just enter the name of the new task and it will be created in SpiraTeam, then displayed in the task list:
"},{"location":"IDE-Integration/Visual-Studio/#troubleshooting","title":"Troubleshooting","text":"The add-in is designed to capture all errors so that when something unexpected happens, work isn't lost. In most situations where an error occurs, a notification will be displayed of the error. In the Project Explorer, hover the mouse over the error node to get a full description of the error.
Errors will also be logged to the desktop's Application Event Log or a text file in case there was a problem connecting to the Event Log on the local computer. Contact support with the Application Event Log and inform them of the issue.
"},{"location":"Migration-and-Integration/Importing-from-Google-Sheets/","title":"Importing from Google Sheets","text":"The web-based interface of SpiraTeam\u00ae is ideal for creating and managing all aspects of your projects. However when migrating requirements, release, tasks, incidents, and test cases with test steps for an existing project from another system, it is useful to be able to retrieve and load in a batch of artifacts, rather than having to manually enter them one at a time.
To simplify this task we've created a Google sheets add-on for SpiraTeam\u00ae that can import requirements, releases, tasks, and test cases with test steps from a generated spreadsheet into SpiraTeam\u00ae.
*This guide assumes you have a Google account with access to Google Drive and persistent access to the internet. It also assumes your instance of SpiraTeam (or SpiraTest, or SpiraPlan) is accessible over the internet so that Google Sheets can send data to it.
"},{"location":"Migration-and-Integration/Importing-from-Google-Sheets/#installing-the-spirateam-google-sheets-integration-add-on","title":"Installing the SpiraTeam\u00ae Google Sheets Integration Add-on","text":"Like most Google services installation is very simple and straightforward as long as you have a Google account.
Before connecting to SpiraTeam\u00ae with the add-on make sure that you're working on the first tab in the spreadsheet.
When the add-on fully loads you will be able to enter your SpiraTeam\u00ae log in credentials.
Spira URL : Please enter the web address that you use to access SpiraTeam\u00ae in your browser. This is usually of the form http://<hostname>/SpiraTeam. Make sure that you remove any suffixes from the address (e.g. Default.aspx).
RSS Token : Please enter your RSS token including the curly braces i.e {ExampleRSS}.
To activate your RSS Token:
Click on the User Profile menu in the application header
Click on \"My Profile\"
The string of numbers including the brackets listed in the RSS Token text box is your token.
If you don't see an RSS Token in that box, then click on 'Enable RSS Feeds' so that it is checked.
Click the button 'Generate New' to get a new RSS token.
Click [Update] to save your changes
Once you have successfully connected to SpiraTeam, you should now choose the appropriate Project and Artifact in the system to which you will be importing into SpiraTeam. As you make your selections more buttons will be enabled.
After the project and artifact have been selected both buttons below these dropdowns should now be clickable. One let's you start entering data to send to SpiraPlan, the other gets data from SpiraPlan.
"},{"location":"Migration-and-Integration/Importing-from-Google-Sheets/#preparing-your-template","title":"Preparing your Template","text":"The SpiraTeam Google Sheets Integration add-on dynamically generates a template for each artifact with the click of a button. After a valid project and artifact have been selected the [ Prepare Template ] button will be enabled. Click this button to generate the required template on the currently selected sheet.
Warning: make sure no data on this sheet is needed as the entire sheet will be wiped
"},{"location":"Migration-and-Integration/Importing-from-Google-Sheets/#filling-in-the-template","title":"Filling in The Template","text":"The above template is for requirements. Fields which have list of values to select from have dropdowns to make choosing the right values easy.
For an artifact to be created successfully in SpiraPlan it has to have certain fields filled in. These required fields are highlighted in bold black text. For example, the above screenshot is for requirements, where both the Name and Type field are required.
Different artifacts have different factors to take account of when entering the data:
Requirements: SpiraPlan allows a hierarchy of requirements (where each requirement can have children, who can, in turn, have child requirements of their own). To designate the hierarchy level of requirements, use the \">\" character. For example:
\"Parent Requirement\"
\"> Child of Parent\"
\"> Another child of parent\"
\">> Child of \"Another Child\"\"
\"A second parent requirement\"
Releases: are also hierarchical, and this is set on the sheet in the same way as requirements
Incidents and Tasks: neither of these artifacts have any special factors to take into account
Test Cases with Test Steps: The screenshot below shows the basic template for Test Cases. Please note the following points:
A test step must have a test case parent to be linked to and all test steps below a test case will become the steps for that test case.
There is no need to number the test steps -- SpiraPlan adds this information automatically
Because each row can either be a case or a step, there are columns for both -- some are only for test cases, others are only for tests steps
The lighter orange column names are ONLY for test step creation
Fields with black text are required: darker orange ones are needed for a test case, lighter orange ones for a test step
If a row has a mix of required fields in for both test cases and test steps, the addon won't know if it is a test case or a test step, so it will flag this an error
Below is a partially filled in test case with test steps template -- it is visually easy to see which rows are steps to which case.
"},{"location":"Migration-and-Integration/Importing-from-Google-Sheets/#import-into-spiraplan","title":"Import Into SpiraPlan","text":"Before importing new artifacts, make sure that you're on the correct tab and the dropdowns in the sidebar show the correct project and artifact type.
After the correct/required fields have been entered, click the [ Send to SpiraPlan] button to send your data to SpiraPlan\u00ae. You will see a popup showing overall progress.
When the artifact has been successfully created an ID number will be placed in the ID column. This is the ID straight from SpiraPlan.
If there are any errors for a particular row (eg if required fields have not all been filled in, or if there was some other problem with the data or on the SpiraPlan server) that row will be highlighted with a comment in column A explain the problem.
For hierarchical artifacts (ones with parents and children), the import process will stop as soon as any error is found, to ensure SpiraPlan does not create an incorrect hierarchy
"},{"location":"Migration-and-Integration/Importing-from-Google-Sheets/#get-data-from-spiraplan","title":"Get data From SpiraPlan","text":"To get all the data for the specified project and artifact from SpiraPlan, instead of going through the steps outlined in Preparing your Template to Import Into SpiraPlan above, click the [ Get From SpiraPlan ] button. This will first load up the template on the current sheet then automatically retrieve all data from SpiraPlan and add it to the sheet.
"},{"location":"Migration-and-Integration/Importing-from-Microsoft-Excel-%28Office365%29/","title":"Importing from Microsoft Excel (Office 2016+, iOS, web)","text":"This add-in works with Microsoft Excel 2016+, Excel in the cloud (via a web browser), and Excel on iPad OS. The add-in lets you import or export data to and from any product in your SpiraTest, SpiraTeam, or SpiraPlan application.
The add-in works for:
In legacy versions of this add-in, you needed to download a static excel template to help make sure you enter data into it in the correct way. However, this new add-in dynamically creates the sheet headers and cell validation based on the artifact and product you select.
"},{"location":"Migration-and-Integration/Importing-from-Microsoft-Excel-%28Office365%29/#installation","title":"Installation","text":"To install the add-in:
You can use this add-in with SpiraTest\u00ae, SpiraTeam\u00ae, or SpiraPlan\u00ae.
If you are using Excel in the browser, make sure your SpiraPlan is accessible over the internet.
If there is a problem connecting to Spira you will be notified with an error message.
After you have logged in click Logout to close your connection with Spira and take you back to the add-in's login page.
On-premise customers
If you have an on-premise Spira installation and you are not able to login to the add-in with valid credentials, please ask your local IT team to issue a self-signed certificate for your Spira instance, as some Excel versions require it.
"},{"location":"Migration-and-Integration/Importing-from-Microsoft-Excel-%28Office365%29/#2-choose-which-mode-to-use","title":"2. Choose which mode to use","text":"The add-in has three main modes: getting data from Spira, Sending data to Spira, and Administrator Functions. Please choose a mode to proceed. Only Spira administrator users can see the third button.
Once you have successfully connected the Excel add-in to your Spira app, you need to decide what you want to use this add-in for. You can go back and change your mind at any time.
"},{"location":"Migration-and-Integration/Importing-from-Microsoft-Excel-%28Office365%29/#get-data-from-spira-exporting","title":"Get data from Spira (exporting)","text":"This button will prompt you to pick a product and artifact to get from Spira and load into the spreadsheet (on the current active sheet). Getting data from Spira can be helpful to share with colleagues who are not using Spira. You can get up to 2,000 artifacts at a time. If there are more than 2,000 artifacts, use the \"Page\" option to get subsequent pages / batches of 2,000 artifacts (for example, selecting page 3, will retrieve artifacts 4001 to 6000). The pagination feature may not be available for all the artifacts.
Updating Data in Spira
Once you have the data from Spira loaded into Excel you can freely edit it. You can then, optionally, update the data in Spira by clicking the \"Update Spira\" button. This will send every artifact on the sheet back to Spira, updating each and every one. Each row will be sent in full to Spira - if you blank out a cell, that value will be blanked out in Spira.
If there are any errors during the update process you will see relevant explanations, with the specific cells (as relevant) that are causing the problem highlighted in red.
If you only wish to update a single artifact, we recommend deleting all the other rows of data to keep things clean.
You can only update artifacts that already exist in Spira. You cannot create new artifacts at the same time as updating.
"},{"location":"Migration-and-Integration/Importing-from-Microsoft-Excel-%28Office365%29/#send-data-to-spira-importing","title":"Send data to Spira (importing)","text":"This button will prompt you to pick a product and artifact to send new data to Spira (from the currently active sheet). Before you can enter data to send, the add-in creates a dynamic template for that specific product and artifact to make it easier for you to enter data correctly. Therefore if you have data already in your sheet, make sure to create a new worksheet for Excel to wipe and prepare for you.
Click \"Prepare Sheet\" to create this template for your chosen product and artifact. Do not alter the worksheet structure in any way after the template has been created (for example do not merge cells, change formatting or delete columns).
Once the template is ready you can start entering your new data2. Once you have entered in all required data, click the \"Send\" button to add the data to Spira. Note: cells highlighted in grey are not editable.
If there are any errors during the sending process you will see relevant explanations, with the specific cells (as relevant) that are causing the problem highlighted in red.
Show Advanced Fields (optional): When you enable this, you have more options when sending data to or updating data in Spira that are normally not available. This lets you create new comments and add associations between specific artifacts. Check the box 'Show Advanced Fields' to activate it for the two previous modes of operation.
"},{"location":"Migration-and-Integration/Importing-from-Microsoft-Excel-%28Office365%29/#administrator-functions","title":"Administrator Functions","text":"This mode is only available for Spira system administrators. When you login to the add-in with administrator credentials, you will see the \"Product Template and System Admin\" section, at the bottom of the second screen. Clicking the \"Get or Send data\" button in this section will let you:
Select this under \"Operations\" and click \"Prepare Data Template Sheet\" to load the template.
Populate the sheet with at least the required (bold) fields and hit \"Send Data\". The just-created new users will already be approved in Spira. If you try to make a new user with a username that already exists, no data will be created or updated in Spira. Instead, the username's ID will be shown in the first column.
"},{"location":"Migration-and-Integration/Importing-from-Microsoft-Excel-%28Office365%29/#add-new-artifact-folders-to-spira","title":"Add new Artifact Folders to Spira","text":"Select this option under \"Operations\", then select an Artifact type and a Product to create the folders. Then, click on \"Prepare Data Template\" to load the template spreadsheet. Enter the new folder data in the spreadsheet. Finally, hit \"Send Data\" and wait until the data is sent to Spira. To create subfolders, use a \"> \" character at the start of the \"Name\" field to mark the hierarchy. This is illustrated in the example below
Folder 1 (root level)\n> Folder 2 (subfolder of Folder 1)\n> Folder 3 (subfolder of Folder 1)\n> > Folder 4 (subfolder of Folder 3)\n> > > Folder 5 (subfolder of Folder 4)\n> Folder 6 (subfolder of Folder 1)\nFolder 7 (root level)\nSelect this under \"Operations\" and then select the product template you want to add the new list(s) and value(s). Then, click on \"Prepare Data Template Sheet\" to load the template. Populate the sheet with at least the required (bold) fields. Please note that you must reserve one row for a list and one or more for its values. Finally, hit \"Send Data\" and wait until the data is sent to Spira.
"},{"location":"Migration-and-Integration/Importing-from-Microsoft-Excel-%28Office365%29/#edit-existing-custom-lists-and-values","title":"Edit Existing Custom Lists and Values","text":"Select this under \"Operations\" and select the product template to edit the lists in, and then from the dropdown select either:
Now click on \"Get Data from Spira\" to load the template. Edit the sheet values freely. Remember to keep/provide new required (bold) fields. Additionally, you can add new values to existing lists, and also add brand new lists (with their values).
When ready, hit \"Send Updated Data\" and wait until the data is sent to Spira.
"},{"location":"Migration-and-Integration/Importing-from-Microsoft-Excel-%28Office365%29/#3-prepare-for-the-data-transfer","title":"3. Prepare for the data transfer","text":"This section is valid for the non-admin modes only (getting data and creating new data).
After you have chosen which mode to use, select the product and artifact from the dropdown menus.
For a given artifact, the required fields are:
Allow Empty at the custom property definition is toggled to NoWhen \"Show Advanced Fields\" is enabled you will see a column called \"New Comments\". This lets you create new comments in Spira when sending the relevant items to Spira
To add a new comment, enter the comment in the column \"New Comment\". When you send data to or update Spira, this will be saved as a new comment in the artifact.
Please note that you can only create new comments. You cannot get existing comments from Spira.
"},{"location":"Migration-and-Integration/Importing-from-Microsoft-Excel-%28Office365%29/#advanced-fields-associations","title":"Advanced Fields: associations","text":"When \"Show Advanced Fields\" is enabled you will may see columns that let you create associations between artifacts. This is an advanced feature because you need to know the exact IDs and type them in manually. For a more user friendly experience associating artifacts please use the main application.
To create an association between artifacts: - find the column of the artifact type you want to associate to (e.g.: \"New Linked Requirement(s)\") - enter the ID(s) of the artifact(s) to associate with. - associate multiple artifacts at a time using a comma-separated list of IDs, e.g.: 335,336,337.
Using the add-in, it's possible to associate:
Please note that you can only create new associations. You cannot get existing associations from Spira
"},{"location":"Migration-and-Integration/Importing-from-Microsoft-Excel-%28Office365%29/#entering-or-updating-data-for-different-artifacts","title":"Entering or Updating Data for different artifacts","text":""},{"location":"Migration-and-Integration/Importing-from-Microsoft-Excel-%28Office365%29/#requirements","title":"Requirements","text":"Indenting items: SpiraPlan lets you create a hierarchy of requirements (where each requirement can have children, who can, in turn, have child of their own). Use a \"> \" at the start of the \"Name\" field to mark a requirement a child of the row above it. This is illustrated in the example below
Indenting Example:\nItem 1\n> Item 2 child of item 1\n> Item 3 child of item 1\n> > Item 4 child of item 3\nStatus: when adding new Requirements, the status you see in Spira may not match the one you selected in the add-in. This is because the status is often calculated by the system itself. E.g.: the 'Requested' status is automatically updated to 'Planned' in Spira if the requirement is assigned to a Release. You can always get the data from Spira to see the most updated fields in the spreadsheet.
Estimate Points for Epics: will get replaced by the child requirement in Spira, even if you selected a different value in the add-in.
Changing the hierarchy by updating: you cannot change where a requirement is in the hierarchy when updating. Do not attempt to change any requirement's relative row or indentation - it will be ignored by the add-in.
"},{"location":"Migration-and-Integration/Importing-from-Microsoft-Excel-%28Office365%29/#releases","title":"Releases","text":"Indenting items: SpiraPlan lets you create a hierarchy of releases (where each release can have children, who can, in turn, have child of their own). Use a \"> \" at the start of the \"Name\" field to mark a release a child of the row above it. This is illustrated in the example below
Indenting Example:\nItem 1\n> Item 2 child of item 1\n> Item 3 child of item 1\n> > Item 4 child of item 3\nChanging the hierarchy by updating: you cannot change where a release is in the hierarchy when updating. Do not attempt to change any release's relative row or indentation - it will be ignored by the add-in.
"},{"location":"Migration-and-Integration/Importing-from-Microsoft-Excel-%28Office365%29/#test-cases-and-test-steps","title":"Test Cases and Test Steps","text":"Don't get confused between test cases and test steps
Test steps are an integral part of test cases so we let you view and add test cases and their steps together in the same table. This combination of two different artifacts can be confusing because they have different fields and requirements. Because each row can either be a case or a step, there are columns for both -- some are only for test cases, others are only for tests steps.
To create a test case with a step, fill in the test case fields in the first row. Then fill in the test step fields for the second row. Add more steps as needed in new rows. To add a second test case, start a new row and fill in the test case fields again.
Make sure: each row only fills in either the required test case or test step columns. If the system cannot tell whether an entry is a test case or step it is skipped over when sending to Spira.
Following is an example of how to add Test Cases and Test Steps to Spira:
"},{"location":"Migration-and-Integration/Importing-from-Microsoft-Excel-%28Office365%29/#incidents","title":"Incidents","text":"Remaining Effort: the add-in populates 'Remaining Effort' in Spira equally to the spreadsheet's entry for 'Estimated Effort'
"},{"location":"Migration-and-Integration/Importing-from-Microsoft-Excel-%28Office365%29/#tasks","title":"Tasks","text":"This artifact does not have any special factors to take into account.
"},{"location":"Migration-and-Integration/Importing-from-Microsoft-Excel-%28Office365%29/#test-sets","title":"Test Sets","text":"This artifact does not have any special factors to take into account.
"},{"location":"Migration-and-Integration/Importing-from-Microsoft-Excel-%28Office365%29/#risks","title":"Risks","text":"This artifact does not have any special factors to take into account.
"},{"location":"Migration-and-Integration/Importing-from-Microsoft-Excel-%28Office365%29/#components","title":"Components","text":"Only system administrators will see this entry in the dropdown for getting and sending data from/to Spira.
"},{"location":"Migration-and-Integration/Importing-from-Microsoft-Excel-%28Office365%29/#folders","title":"Folders","text":"Only system administrators will see this entry in the dropdown for sending data to Spira. You can create folder for different artifact types at the same time. Just select them under the Artifact column in the worksheet.
Only system administrators can Add/Edit Custom Lists and Values going to the second/third option of the \"Product Template/System Admin. Operation\"` menu. Please note that:
Only system administrators can create new users going to the first option of the \"Product Template/System Admin Operations\" menu.
"},{"location":"Migration-and-Integration/Importing-from-Microsoft-Excel-%28Office365%29/#other-actions-you-can-do-on-after-you-have-logged-in-to-the-add-in","title":"Other actions you can do on after you have logged in to the add-in","text":"What can the Excel365 add-in do that the Classic Excel add-in cannot?
What can the Excel Classic add-in do that the Excel365 add-in cannot?
NOTE The classic version of our Excel importer can create test runs. Please refer to the SpiraPlan TestRunner for Excel 365 add-in to use these functionalities in our new generation of add-ins.
Requires system administrator credentials\u00a0\u21a9\u21a9\u21a9\u21a9
Please note that you can currently only send a maximum of 10,000 rows of data to Spira at a a time.\u00a0\u21a9
Not compatible with Excel Professional 2016 and 2019 versions \u21a9
Danger
If you are using recent versions of Excel and Spira, then do not use this Add-In. This is legacy addon only.
Please use our Excel365 importer instead.
The web-based interface of SpiraTeam\u00ae is ideal for creating and managing requirements, test cases and incidents for a new project. However when migrating requirements, test cases, test steps and incidents for an existing project from another system or Microsoft Office document (e.g. Excel), it is useful to be able to load in a batch of artifacts, rather than having to manually enter them one at a time.
To simplify this task, SpiraTeam\u00ae comes with a Microsoft Excel Add-In that can export requirements, test cases, test steps and incidents from a populated Excel sheet into SpiraTeam\u00ae. In addition, the Add-In allows you to import those same artifacts back into the Excel sheet to make batch updates which can then be used to update the master copies on the server.
Note that this guide refers to SpiraTeam\u00ae, but the Excel Add-In can be used with SpiraTest\u00ae and SpiraPlan\u00ae as well. The only difference is that some of the artifact types may not be available in SpiraPlan/Test.
"},{"location":"Migration-and-Integration/Importing-from-Microsoft-Excel/#installing-the-microsoft-excel-add-in","title":"Installing the Microsoft Excel Add-In","text":"The first thing you need to do is to go to the \"Add-Ons and Downloads\" page of the Inflectra Website (it can be found in the SpiraTest, SpiraPlan or SpiraTeam sections), and download the MS-Office Add-Ins installation package. There are separate packages for the following versions of MS Office:
MS-Office 2003 Add-Ins -- these are compatible with Microsoft Office 2003 and 2007. They can connect to SpiraTeam v2.3 or later. They also require Microsoft .NET 3.5.
MS-Office 2007 Add-Ins -- these are compatible with Microsoft Office 2007 and 2010. They can connect to SpiraTeam v3.0 or later. They also require Microsoft .NET 4.0.
MS-Office 2010 Add-Ins -- these are compatible with Microsoft Office 2010 and later. They can connect to SpiraTeam v5.0 or later. They also require Microsoft .NET 4.0.
This installation package will install the add-ins for Microsoft Excel, Word and Project at the same time. If you don't have the correct version of Microsoft .NET installed or some of the necessary prerequisites, you will be given the opportunity to install them when you first run the installation package.
Once you have the Excel Add-In installed, the second thing you'll need to download is the SpiraImportTemplate Excel Sheet. This spreadsheet contains the necessary pre-formatted columns that are needed for the Add-In to easily recognize the data and know how to handle it. There are three versions of the template available - SpiraImportTemplate.xls for the Excel 2003 Add-In, SpiraImportTemplate.xlsx for the Excel 2007 Add-In and SpiraImportTemplate2010.xslx for the Excel 2010 Add-In.
Once you have downloaded the template, please double-click on it to open it up in MS-Excel. You will notice that there is an additional toolbar displayed in Excel which is used for importing/exporting data to/from SpiraTeam:
If you are using the MS-Excel 2007 or 2010 Add-In, you will see a modified version of the toolbar that makes use of the MS-Office Ribbon:
This toolbar allows you to connect to SpiraTeam, and perform the import/export. The process for using this toolbar is described below:
"},{"location":"Migration-and-Integration/Importing-from-Microsoft-Excel/#connecting-to-spirateam","title":"Connecting to SpiraTeam\u00ae","text":"The first thing you need to do is to click on the [Connect] button to specify the information used to connect to your instance of SpiraTeam:
Please enter the following information into the dialog box:
Spira URL: Please enter the web address that you use to access SpiraTeam\u00ae in your browser. This is usually of the form http://<hostname>/SpiraTeam. Make sure that you remove any suffixes from the address (e.g. Default.aspx).
User Name: Please enter the username that you use for logging in to SpiraTeam
Password: Please enter the password that you use for logging in to SpiraTeam
Remember Password: If you are using this Add-In on a private computer, you can check this option to have the system remember your credentials locally. Please do not use this option on a public computer and it will compromise the security of your SpiraTeam installation.
Once you have entered the necessary information, please click [Connect] to authenticate with the server. If the login information is invalid, you will see an error message appear, otherwise you will be connected and the list of projects and artifacts will be populated. If you want to end your session, you should just click the [Disconnect] button and the Add-In will close your connection.
"},{"location":"Migration-and-Integration/Importing-from-Microsoft-Excel/#choosing-the-project-and-artifact","title":"Choosing the Project and Artifact","text":"Once you have successfully connected to SpiraTeam, you should now choose the appropriate Project and Artifact in the system that you will be importing / exporting:
Or
The artifact choice will match the name of the Excel sheet in the template, so if you are going to be importing/exporting Requirements, you should choose \"Requirements\" from the dropdown list and then click on the \"Requirements\" tab inside the Excel import template.
Once you have selected the project and artifact, there are three buttons that you can now use:
Import: Clicking this button will retrieve the data from the SpiraTeam server and use that to populate the spreadsheet.
Export: Clicking this button will take the data in the spreadsheet and use it to add/update items in SpiraTeam.
Clear: This button allows you to quickly clear the data in the import template while leaving all the necessary headings and other information that the Add-In needs to be able to import/export data.
Options: (Only in MS-Excel 2007/2010 Add-Inx). This button allows you to change some of the import/export options.
The Excel Add-In is capable of either importing data from SpiraTeam into the Excel template or exporting data from the Excel template to SpiraTeam. However it is important to understand how the system knows whether to add new items to SpiraTeam or whether to update existing items:
If you start with a blank import spreadsheet and enter items into it, they will not have a value set on their ID column in the spreadsheet (this is always the first column in each sheet). When you perform an Export, it will add these as new items in SpiraTeam
If you start with a blank import spreadsheet and choose to Import data from SpiraTeam, those rows will include the ID of the item in the first column of the spreadsheet. You can either update those rows or add new rows in between. Any rows that have the ID column populated will be updated in SpiraTeam when you choose Export, whereas any newly added rows will be inserted in SpiraTeam.
To import/export releases, first you need to click on the \"Releases\" tab in the Excel sheet:
Next if you want to import the list of existing Releases from SpiraTeam, you should click on the [Clear] icon to first remove the sample information from the spreadsheet, then click [Import] to load the list of existing releases into the sheet. These items will all have the \"Rel #\" column populated so that the system knows to update them rather than insert them when you subsequently click [Export].
If you want to simply export a list of releases from a spreadsheet, then you need to either enter the releases into this specially formatted spreadsheet or cut and paste them in from another existing Excel sheet that you've been using to manage releases previously. Then click [Export] and the new items will be added to your instance of SpiraTeam.
The various columns that can be imported, and the rules for entering data are listed below:
Field name Description Rel # Stores the ID of the release. Should be left blank for new items being added to SpiraTeam Release Name The name of the release. This field supports indentation, so you need to use Excel's ability to Indent text fields to indicate how the items in the release hierarchy are organized Release Description The long description of the release. If you want it formatted, you need to add HTML tags such as <b> for bold Version Number The version number for the release; acts as the short name Active Whether this release is active or not. Should be set to either Y/N Iteration Whether this release is an Iteration or not. Should be set to either Y/N Creator The user that should listed as the release's creator. Needs to be the ID of the user (e.g. user US00005 would be entered as just 5) Start Date The date that work on the release is scheduled to start End Date The date that work on the release is scheduled to end # Resources The number of people / resources that are scheduled to work on the release. Non-Wk Days The number of non-working days that should be subtracted from the # available hours for work performed on the release. MS-Excel 2003/2007 Add-In Specific Fields TEXT-01 -- TEXT-10 The ten (10) custom text properties available in the project LIST-01 -- LIST-10 The ten (10) drop-down list properties available in the project. You need to enter the ID value of the custom property not the display name. E.g. if you have a custom property with ID - PV00005 you would enter just 5 in these boxes. MS-Excel 2010 Add-In Specific Fields Status The status of the release. It needs to be one of the values from the dropdown list Type The type of the release (major, minor, iteration or phase). It needs to be one of the values from the dropdown list CUS-01 -- CUS-30 The thirty (30) custom fields defined in the project. The value entered depends on the type of custom property: - List -- provide the numeric ID of the custom list value (e.g. PV00005 would be entered as just \"5\") - MultiList -- provide a comma-separated list of the numeric IDs of the custom list values (e.g. PV00005 and PV00003 would be entered as just \"5,3\") - Text -- enter the text, include HTML tags if rich-text - Decimal -- enter the number (e.g. 1.0) - Integer -- enter the number (e.g. 2) - Date -- enter the number in the current local time format (e.g. m/d/yyyy for the US, d/m/yyyy for Europe) - User -- enter the ID of the user - Boolean -- Enter either \"True\" or \"False\" Comment The description of a comment that should be appended to the item. If you want it formatted, you need to add HTML tags such as <b> for bold. Note that this field always appends, so if you want to add two comments, just enter the first value and click [Export], then replace it with the second value and click [Export]Note: the columns that are required are listed in bold type.
"},{"location":"Migration-and-Integration/Importing-from-Microsoft-Excel/#importingexporting-requirements","title":"Importing/Exporting Requirements","text":"To import/export requirements, first you need to click on the \"Requirements\" tab in the Excel sheet:
Next if you want to import the list of existing Requirements from SpiraTeam, you should click on the [Clear] icon to first remove the sample information from the spreadsheet, then click [Import] to load the list of existing requirements into the sheet. These items will all have the \"Req #\" column populated so that the system knows to update them rather than insert them when you subsequently click [Export].
If you want to simply export a list of requirements from a spreadsheet, then you need to either enter the requirements into this specially formatted spreadsheet or cut and paste them in from another existing Excel sheet that you've been using to manage requirements previously. Then click [Export] and the new items will be added to your instance of SpiraTeam.
The various columns that can be imported, and the rules for entering data are listed below:
Field name Description Req # Stores the ID of the requirement. Should be left blank for new items being added to SpiraTeam Requirement Name The name of the requirement. This field supports indentation, so you need to use Excel's ability to Indent text fields to indicate how the items in the requirement hierarchy are organized Requirement Description The long description of the requirement. If you want it formatted, you need to add HTML tags such as <b> for bold Importance The importance / priority of the requirement. It needs to be one of the values from the dropdown list. Status The status of the requirement. It needs to be one of the values from the dropdown list. If this is not specified, the requirement will default to the \"Requested\" status. Author The user that should listed as the requirement's author. Needs to be the ID of the user (e.g. user US00005 would be entered as just 5) Owner The user that should listed as the requirement's owner. Needs to be the ID of the user (e.g. user US00005 would be entered as just 5) MS-Excel 2003/2007 Add-In Specific Fields Release # The release that this requirement is scheduled for. Needs to be the ID of the release (e.g. release RL00005 would be entered as just 5) TEXT-01 -- TEXT-10 The ten (10) custom text properties available in the project LIST-01 -- LIST-10 The ten (10) drop-down list properties available in the project. You need to enter the ID value of the custom property not the display name. E.g. if you have a custom property with ID - PV00005 you would enter just 5 in these boxes. MS-Excel 2010 Add-In Specific Fields Release Version The release/iteration that this requirement is scheduled for. Needs to be the version number of the release (e.g. 1.0.1.1) Type The type of the requirement. It needs to be one of the values from the dropdown list. Estimate The estimate (in points) of the requirement. It should be a decimal number with one decimal place (e.g. 1.0, 2.5, etc.) Component This should be the Name of the Component the requirement is assigned-to. E.g. \"Component 1\" Linked Requirements Comma-separated list of requirement IDs (without the RQ prefix) that this requirement should be linked to (e.g. 204, 891) Note: This field only Exports to Spira and not the other way around CUS-01 -- CUS-30 The thirty (30) custom fields defined in the project. The value entered depends on the type of custom property: - List -- provide the numeric ID of the custom list value (e.g. PV00005 would be entered as just \"5\") - MultiList -- provide a comma-separated list of the numeric IDs of the custom list values (e.g. PV00005 and PV00003 would be entered as just \"5,3\") - Text -- enter the text, include HTML tags if rich-text - Decimal -- enter the number (e.g. 1.0) - Integer -- enter the number (e.g. 2) - Date -- enter the number in the current local time format (e.g. m/d/yyyy for the US, d/m/yyyy for Europe) - User -- enter the ID of the user - Boolean -- Enter either \"True\" or \"False\" Comment The description of a comment that should be appended to the item. If you want it formatted, you need to add HTML tags such as <b> for bold. Note that this field always appends, so if you want to add two comments, just enter the first value and click [Export], then replace it with the second value and click [Export]Note: the columns that are required are listed in bold type.
"},{"location":"Migration-and-Integration/Importing-from-Microsoft-Excel/#importingexporting-test-sets","title":"Importing/Exporting Test Sets","text":"To import/export test sets, first you need to click on the \"Test Sets\" tab in the Excel sheet:
Next if you want to import the list of existing Test Sets from SpiraTeam, you should click on the [Clear] icon to first remove the sample information from the spreadsheet, then click [Import] to load the list of existing test sets into the sheet. These items will all have the \"TX #\" column populated so that the system knows to update them rather than insert them when you subsequently click [Export].
If you want to simply export a list of test sets from a spreadsheet, then you need to either enter the test sets into this specially formatted spreadsheet or cut and paste them in from another existing Excel sheet that you've been using to manage test sets previously. Then click [Export] and the new items will be added to your instance of SpiraTeam.
The various columns that can be imported, and the rules for entering data are listed below:
Field name Description TX # Stores the ID of the test set. Should be left blank for new items being added to SpiraTeam Test Set Name The name of the test set. This field supports indentation, so you need to use Excel's ability to Indent text fields to indicate how the items in the test set hierarchy are organized Test Set Description The long description of the test set. If you want it formatted, you need to add HTML tags such as <b> for bold Folder Whether this item is a folder or not. Should be set to either Y/N Status The status of the test set. It needs to be one of the values from the dropdown list. Creator The user that should listed as the test set's creator. Needs to be the ID of the user (e.g. user US00005 would be entered as just 5) Owner The user that should listed as the test set's owner. Needs to be the ID of the user (e.g. user US00005 would be entered as just 5) Planned Date The date that the test set needs to be completed by. MS-Excel 2003/2007 Add-In Specific Fields Release # The release that this test set is scheduled for. Needs to be the ID of the release (e.g. release RL00005 would be entered as just 5) TEXT-01 -- TEXT-10 The ten (10) custom text properties available in the project LIST-01 -- LIST-10 The ten (10) drop-down list properties available in the project. You need to enter the ID value of the custom property not the display name. E.g. if you have a custom property with ID - PV00005 you would enter just 5 in these boxes. MS-Excel 2010 Add-In Specific Fields Release Version The release/iteration that this test set is scheduled for. Needs to be the version number of the release (e.g. 1.0.1.1) CUS-01 -- CUS-30 The thirty (30) custom fields defined in the project. The value entered depends on the type of custom property: - List -- provide the numeric ID of the custom list value (e.g. PV00005 would be entered as just \"5\") - MultiList -- provide a comma-separated list of the numeric IDs of the custom list values (e.g. PV00005 and PV00003 would be entered as just \"5,3\") - Text -- enter the text, include HTML tags if rich-text - Decimal -- enter the number (e.g. 1.0) - Integer -- enter the number (e.g. 2) - Date -- enter the number in the current local time format (e.g. m/d/yyyy for the US, d/m/yyyy for Europe) - User -- enter the ID of the user - Boolean -- Enter either \"True\" or \"False\" Comment The description of a comment that should be appended to the item. If you want it formatted, you need to add HTML tags such as <b> for bold. Note that this field always appends, so if you want to add two comments, just enter the first value and click [Export], then replace it with the second value and click [Export]Note: the columns that are required are listed in bold type.
"},{"location":"Migration-and-Integration/Importing-from-Microsoft-Excel/#importingexporting-test-cases","title":"Importing/Exporting Test Cases","text":"To import/export test cases, first you need to click on the \"Test Cases\" tab in the Excel sheet:
Next if you want to import the list of existing Test Cases from SpiraTeam, you should click on the [Clear] icon to first remove the sample information from the spreadsheet, then click [Import] to load the list of existing test cases into the sheet. These items will all have the \"Test #\" and \"Step #\" columns populated so that the system knows to update them rather than insert them when you subsequently click [Export].
If you want to simply export a list of test cases from a spreadsheet, then you need to either enter the test cases (including any test steps) into this specially formatted spreadsheet or cut and paste them in from another existing Excel sheet that you've been using to manage test cases previously. Then click [Export] and the new items will be added to your instance of SpiraTeam.
The various columns that can be imported, and the rules for entering data are listed below:
Field name Description Test # Stores the ID of the test case. Should be left blank for new items being added to SpiraTeam Test Case Name The name of the test case. This field supports indentation, so you need to use Excel's ability to Indent text fields to indicate how the items in the test case hierarchy are organized Test Case Description The long description of the test case. If you want it formatted, you need to add HTML tags such as <b> for bold Priority The priority of the test case. It needs to be one of the values from the dropdown list. Owner The user that should listed as the test case's owner. Needs to be the ID of the user (e.g. user US00005 would be entered as just 5) Row Type This is used to tell the Add-In what type of row this is. You should enter \"FOLDER\" if this row is a test folder, \"TestCase\" if it is a test case and \">TestStep\" if it is a test step belonging to a test case. These values should be selected from the dropdown list. Note: You should make sure that test step rows are located directly underneath the test case they are a part of. Step # Stores the ID of the test step. Should be left blank for new test steps being added to a test case Test Step Description The description of the test step. This should contain the description of the actions that the tester needs to take. If you want it formatted, you need to add HTML tags such as <b> for bold Expected Result The expected result of the test step. This should contain the description of what the tester should see if the step succeeds. If you want it formatted, you need to add HTML tags such as <b> for bold Sample Data The sample date for the test step. This should contain any sample data that the tester can use when testing the step. If you want it formatted, you need to add HTML tags such as <b> for bold MS-Excel 2003/2007 Add-In Specific Fields** Requirement The requirement that this test case should be mapped to. Needs to be the ID of the requirement (e.g. requirement RQ00005 would be entered as just 5). *Note that this field always appends, so if you want to add a test case to two requirements, run the export twice, once for each requirement. *Note: This field only Exports to Spira and not the other way around Release The release that this test case should be mapped to. Needs to be the ID of the release (e.g. release RL00005 would be entered as just 5). *Note that this field always appends, so if you want to add a test case to two releases, run the export twice, once for each release. *Note: This field only Exports to Spira and not the other way around Test Set The test set that this test case should be added to. Needs to be the ID of the test set (e.g. test set TX00005 would be entered as just 5). *Note that this field always appends, so if you want to add a test case to two test sets, run the export twice, once for each test set. *Note: This field only Exports to Spira and not the other way around TEXT-01 -- TEXT-10 The ten (10) custom text properties available in the project LIST-01 -- LIST-10 The ten (10) drop-down list properties available in the project. You need to enter the ID value of the custom property not the display name. E.g. if you have a custom property with ID - PV00005 you would enter just 5 in these boxes. MS-Excel 2010 Add-In Specific Fields Type The type of the test case. It needs to be one of the values from the dropdown list. Status The status of the test case. It needs to be one of the values from the dropdown list. Requirement The requirement(s) that this test case should be mapped to. Needs to be a comma-separated list of requirement IDs (e.g. requirements RQ00005 and RQ00008 would be entered as just \"5,8\"). Note: This field only Exports to Spira and not the other way around Release The release(s) that this test case should be mapped to. Needs to be a comma-separated list of release version numbers (e.g. releases 1.1.0.0 and 1.2.0.0 would be entered as \"1.1.0.0,1.2.0.0\"). Note: This field only Exports to Spira and not the other way around Test Set The test set(s) that this test case should be added to. Needs to be a comma-separated list of test set IDs (e.g. test sets TX00005 and TX00008 would be entered as just \"5,8\"). Note: This field only Exports to Spira and not the other way around Components This should be a comma-separated list of the Name of the Components the test case is assigned-to. E.g. Component 1, Component 2 CUS-01 -- CUS-30 The thirty (30) custom fields defined in the project. The value entered depends on the type of custom property: - List -- provide the numeric ID of the custom list value (e.g. PV00005 would be entered as just \"5\") - MultiList -- provide a comma-separated list of the numeric IDs of the custom list values (e.g. PV00005 and PV00003 would be entered as just \"5,3\") - Text -- enter the text, include HTML tags if rich-text - Decimal -- enter the number (e.g. 1.0) - Integer -- enter the number (e.g. 2) - Date -- enter the number in the current local time format (e.g. m/d/yyyy for the US, d/m/yyyy for Europe) - User -- enter the ID of the user - Boolean -- Enter either \"True\" or \"False\"Note: the columns that are required are listed in bold type.
"},{"location":"Migration-and-Integration/Importing-from-Microsoft-Excel/#importingexporting-incidents","title":"Importing/Exporting Incidents","text":"To import/export incidents, first you need to click on the \"Incidents\" tab in the Excel sheet:
Next if you want to import the list of existing Incidents from SpiraTeam, you should click on the [Clear] icon to first remove the sample information from the spreadsheet, then click [Import] to load the list of existing incidents into the sheet. These items will all have the \"Inc #\" column populated so that the system knows to update them rather than insert them when you subsequently click [Export].
If you want to simply export a list of incidents from a spreadsheet, then you need to either enter the incidents into this specially formatted spreadsheet or cut and paste them in from another existing Excel sheet that you've been using to manage incidents previously. Then click [Export] and the new items will be added to your instance of SpiraTeam.
The various columns that can be imported/exported, and the rules for entering data are listed below:
Field name Description Inc # Stores the ID of the incident. Should be left blank for new items being added to SpiraTeam Incident Name The name of the incident. Incident Description The long description of the incident. If you want it formatted, you need to add HTML tags such as <b> for bold Type The type of the incident. It needs to be one of the values from the dropdown list. Status The status of the incident. It needs to be one of the values from the dropdown list. Priority The priority of the incident. It needs to be one of the values from the dropdown list. Severity The severity of the incident. It needs to be one of the values from the dropdown list. Detector The user that found the incident. Needs to be the ID of the user (e.g. user US00005 would be entered as just 5). If left blank, it will default to the user logged in through the Add-In. Owner The user that the incident should be assigned to Needs to be the ID of the user (e.g. user US00005 would be entered as just 5) Detected Date The date that the incident was found. If this field is not populated, the current date is used instead Closed Date The date that the incident was closed. Do not enter a value in this field if the incident is not in a closed status. MS-Excel 2003 Add-In Specific Fields % Complete The completion percentage of the incident Detected Release The release that this incident was found in. Needs to be the ID of the release (e.g. release RL00005 would be entered as just 5) Resolved Release The release that this incident is scheduled to be fixed in. Needs to be the ID of the release (e.g. release RL00005 would be entered as just 5) TEXT-01 -- TEXT-10 The ten (10) custom text properties available in the project LIST-01 -- LIST-10 The ten (10) drop-down list properties available in the project. You need to enter the ID value of the custom property not the display name. E.g. if you have a custom property with ID - PV00005 you would enter just 5 in these boxes. Resolution The description of a resolution/comment that should be appended to the incident. If you want it formatted, you need to add HTML tags such as <b> for bold. Note that this field always appends, so if you want to add two comments, just enter the first value and click [Export], then replace it with the second value and click [Export] MS-Excel 2007 Add-In Specific Fields Detected Release The release that this incident was found in. Needs to be the ID of the release (e.g. release RL00005 would be entered as just 5) Resolved Release The release that this incident is scheduled to be fixed in. Needs to be the ID of the release (e.g. release RL00005 would be entered as just 5) Est. Effort The estimated effort associated with the task (entered as a whole number of minutes) Act. Effort The actual effort associated with number of minutes) Rem. Effort The remaining effort associated with the task (entered as a whole number of minutes) TEXT-01 -- TEXT-10 The ten (10) custom text properties available in the project LIST-01 -- LIST-10 The ten (10) drop-down list properties available in the project. You need to enter the ID value of the custom property not the display name. E.g. if you have a custom property with ID - PV00005 you would enter just 5 in these boxes. Resolution The description of a resolution/comment that should be appended to the incident. If you want it formatted, you need to add HTML tags such as <b> for bold. Note that this field always appends, so if you want to add two comments, just enter the first value and click [Export], then replace it with the second value and click [Export] MS-Excel 2010 Add-In Specific Fields Detected Release The release/iteration that this incident was found in. Needs to be the version number of the release (e.g. 1.0.1.1) Resolved Release The release/iteration that this is planned to be fixed in. Needs to be the version number of the release (e.g. 1.0.1.1) Components This should be a comma-separated list of the Name of the Components the incident is assigned-to. E.g. Component 1, Component 2 Est. Effort The estimated effort associated with the task (entered as a whole number of minutes) Act. Effort The actual effort associated with the task (entered as a whole number of minutes) Rem. Effort The remaining effort associated with the task (entered as a whole number of minutes) CUS-01 -- CUS-30 The thirty (30) custom fields defined in the project. The value entered depends on the type of custom property: - List -- provide the numeric ID of the custom list value (e.g. PV00005 would be entered as just \"5\") - MultiList -- provide a comma-separated list of the numeric IDs of the custom list values (e.g. PV00005 and PV00003 would be entered as just \"5,3\") - Text -- enter the text, include HTML tags if rich-text - Decimal -- enter the number (e.g. 1.0) - Integer -- enter the number (e.g. 2) - Date -- enter the number in the current local time format (e.g. m/d/yyyy for the US, d/m/yyyy for Europe) - User -- enter the ID of the user - Boolean -- Enter either \"True\" or \"False\" Comment The description of a comment that should be appended to the incident. If you want it formatted, you need to add HTML tags such as <b> for bold. Note that this field always appends, so if you want to add two comments, just enter the first value and click [Export], then replace it with the second value and click [Export]Note: the columns that are required are listed in bold type.
"},{"location":"Migration-and-Integration/Importing-from-Microsoft-Excel/#importingexporting-tasks","title":"Importing/Exporting Tasks","text":"To import/export tasks, first you need to click on the \"Tasks\" tab in the Excel sheet:
Next if you want to import the list of existing Tasks from SpiraTeam, you should click on the [Clear] icon to first remove the sample information from the spreadsheet, then click [Import] to load the list of existing tasks into the sheet. These items will all have the \"Inc #\" column populated so that the system knows to update them rather than insert them when you subsequently click [Export].
If you want to simply export a list of tasks from a spreadsheet, then you need to either enter the tasks into this specially formatted spreadsheet or cut and paste them in from another existing Excel sheet that you've been using to manage tasks previously. Then click [Export] and the new items will be added to your instance of SpiraTeam.
The various columns that can be imported, and the rules for entering data are listed below:
Field name Description Task # Stores the ID of the task. Should be left blank for new items being added to SpiraTeam Task Name The name of the task. Task Description The long description of the task. If you want it formatted, you need to add HTML tags such as <b> for bold Status The status of the task. It needs to be one of the values from the dropdown list. Priority The priority of the task. It needs to be one of the values from the dropdown list. Requirement The requirement that this task should be associated with. Needs to be the ID of the requirement (e.g. requirement RQ00005 would be entered as just 5). Owner The user that the task should be assigned to Needs to be the ID of the user (e.g. user US00005 would be entered as just 5) Start Date The date that work on the task is scheduled to start End Date The date that work on the task is scheduled to end Est. Effort The estimated effort associated with the task (entered as a whole number of minutes) Act. Effort The actual effort associated with the task (entered as a whole number of minutes) MS-Excel 2003 Add-In Specific Fields % Complete The completion percentage of the task Release # The release/iteration that this task is scheduled for. Needs to be the ID of the release/iteration (e.g. release RL00005 would be entered as just 5). TEXT-01 -- TEXT-10 The ten (10) custom text properties available in the project LIST-01 -- LIST-10 The ten (10) drop-down list properties available in the project. You need to enter the ID value of the custom property not the display name. E.g. if you have a custom property with ID - PV00005 you would enter just 5 in these boxes. **MS-Excel 2007 Add-In Specific Fields** Rem. Effort The remaining effort associated with the task (entered as a whole number of minutes) Release # The release/iteration that this task is scheduled for. Needs to be the ID of the release/iteration (e.g. release RL00005 would be entered as just 5). TEXT-01 -- TEXT-10 The ten (10) custom text properties available in the project LIST-01 -- LIST-10 The ten (10) drop-down list properties available in the project. You need to enter the ID value of the custom property not the display name. E.g. if you have a custom property with ID - PV00005 you would enter just 5 in these boxes. MS-Excel 2010 Add-In Specific Fields Type The type of the task. It needs to be one of the values from the dropdown list. Rem. Effort The remaining effort associated with the task (entered as a whole number of minutes) Release Version The release/iteration that this task is scheduled for. Needs to be the version number of the release (e.g. 1.0.1.1) CUS-01 -- CUS-30 The thirty (30) custom fields defined in the project. The value entered depends on the type of custom property: - List -- provide the numeric ID of the custom list value (e.g. PV00005 would be entered as just \"5\") - MultiList -- provide a comma-separated list of the numeric IDs of the custom list values (e.g. PV00005 and PV00003 would be entered as just \"5,3\") - Text -- enter the text, include HTML tags if rich-text - Decimal -- enter the number (e.g. 1.0) - Integer -- enter the number (e.g. 2) - Date -- enter the number in the current local time format (e.g. m/d/yyyy for the US, d/m/yyyy for Europe) - User -- enter the ID of the user - Boolean -- Enter either \"True\" or \"False\" Comment The description of a comment that should be appended to the task. If you want it formatted, you need to add HTML tags such as <b> for bold. Note that this field always appends, so if you want to add two comments, just enter the first value and click [Export], then replace it with the second value and click [Export]Note: the columns that are required are listed in bold type.
"},{"location":"Migration-and-Integration/Importing-from-Microsoft-Excel/#execute-test-cases-offline","title":"Execute Test Cases Offline","text":"As well as being able to import/export data, you can also use the import spreadsheet to execute test cases while disconnected from your network and then upload the results to SpiraTeam as a single batch.
To do this, when connected to the network, connect to the server using the Add-In [Connect] icon, select the project and \"Test Runs\", then click on the \"Test Runs\" in the spreadsheet:
Now you should click on the [Import] button, and the Add-In will load the list of Test Cases (and in the case of the MS-Office 2007/2010 Add-Ins, any Test Sets as well) that are currently assigned to you together with open cells (marked in green) that you can use to record the actual results of testing:
You can now disconnect from the network and perform the testing activities offline. Enter the following entries into the spreadsheet:
Status The execution status of that test step. It should be selected drop the dropdown list. The allowed values are: Failed / Passed / Blocked / Caution. Actual Result The long description of the actual result experienced during testing. If you want it formatted, you need to add HTML tags such as <b> for bold Incident Name If you want to log an incident associated with the test failure, enter the name of the incident here. The description of the incident will be pre-populated with the Test Step Description, Expected Result, and Actual Result.
Once you have finished testing and are connected back on the network, just click on the [Connect] icon to have the Add-In connect with the SpiraTeam server, choose the project name and \"Test Runs\" and then click [Export]. The test results will now be uploaded to the server.
Note: If you are using the MS-Excel 2007/2010 Add-Ins, you will also see the Test Set ID, Release ID and TX TC ID (Test-Set, Test Case unique ID). You can manually set a Release ID on test cases that were not part of a test set.
"},{"location":"Migration-and-Integration/Importing-from-Microsoft-Excel/#importing-custom-property-list-values","title":"Importing Custom Property List Values","text":"To import/export custom property values (for list custom properties), first you need to click on the \"Custom Values\" tab in the Excel sheet:
Next if you want to import the list of existing custom list values from SpiraTeam, you should click on the [Clear] icon to first remove the sample information from the spreadsheet, then click [Import] to load the list of existing custom list values into the sheet. These items will all have the \"Value #\" column populated so that the system knows to update them rather than insert them when you subsequently click [Export].
If you want to export a list of custom list values from a spreadsheet you first need to make sure that a list exists in the right template in Spira. You can only edit a list that already exists in Spira. Then you need to either enter the custom list ID and value name into this specially formatted spreadsheet or cut and paste them in from another existing Excel sheet that you've been using to manage the values previously. Then click [Export] and the new items will be added to your instance of SpiraTeam. NOTE: These values are initially added as inactive on the list. You will need to log into Spira to make the list values required active.
The various columns that can be imported, and the rules for entering data are listed below:
Field name Description Value # Stores the ID of the custom list value. Should be left blank for new items being added to SpiraTeam Custom List # The ID of the custom list that the value is being added to (with the CL prefix removed). For example custom list CL00005 would be entered as just \"5\" Custom Value Name The name of the custom value that you are inserting/updating in SpiraTeam
Note: the columns that are required are listed in bold type.
"},{"location":"Migration-and-Integration/Importing-from-Microsoft-Excel/#changing-the-importexport-options","title":"Changing the Import/Export Options","text":"In the MS-Excel 2007 and 2010 Add-Ins, you can change how the import/export works by clicking on the Options icon. This brings up the Options dialog box:
"},{"location":"Migration-and-Integration/Importing-from-Microsoft-Excel/#rich-text-setting","title":"Rich Text Setting","text":"When you import artifacts from SpiraTeam into MS-Excel, if they have a formatted description, by default all the HTML tags that are used to describe the formatting will be loaded into the Excel cell. This is useful if you plan on making changes and then updating SpiraTeam (since it will preserve the formatting).
However if you want to be able to more easily read the descriptions in Excel and do not plan on updating SpiraTeam, you can select the option to Remove the Formatting, which will convert the descriptions to plain-text before loading them into Excel.
"},{"location":"Migration-and-Integration/Importing-from-Microsoft-Excel/#test-run-date-setting","title":"Test Run Date Setting","text":"If you set a date for the 'Test Run Date', the importer will use that date to be the date the test runs were executed on, rather than the current date/time, which is used by default.
"},{"location":"Migration-and-Integration/Importing-from-Microsoft-Excel/#functionality-differences-from-microsoft-excel-365-plugin","title":"Functionality Differences from Microsoft Excel 365 plugin","text":"Excel Classic can (and the Excel 365 plugin cannot):
Excel 365 can (and the classic plugin cannot):
NOTE Excel Classic can create test runs. This functionality is in the SpiraPlan TestRunner Excel 365 addin, and not the Excel 365 import/export addin.
For more information about how the Excel Classic plugin works with version 6+ of SpiraPlan see this blog post.
"},{"location":"Migration-and-Integration/Importing-from-Microsoft-Project/","title":"Importing from Microsoft Project","text":"The web-based interface of SpiraTeam\u00ae is ideal for creating and managing requirements, releases/iterations and tasks for a new project. However when migrating requirements and tasks from an existing project, it is useful to be able to load in an existing project plan in batch and have SpiraTeam be able to interpret the data.
To simplify this task, SpiraTeam\u00ae comes with a Microsoft Project Add-In that can export requirements, releases and tasks from a populated MS-Project plan into SpiraTeam\u00ae. In addition, the Add-In allows you to import those same artifacts back into the MS-Project plan to make batch updates which can then be used to update the master copies on the server.
Note that this guide refers to SpiraTeam\u00ae, but the MS-Project Add-In can be used with SpiraPlan\u00ae as well.
"},{"location":"Migration-and-Integration/Importing-from-Microsoft-Project/#installing-the-microsoft-project-add-in","title":"Installing the Microsoft Project Add-In","text":"The first thing you need to do is to go to the \"Add-Ons and Downloads\" page of the Inflectra Website (it can be found in the SpiraPlan or SpiraTeam sections), and download the MS-Office Add-Ins installation package. There are separate packages for the following versions of MS Office:
MS-Office 2003 Add-Ins -- these are compatible with Microsoft Office 2003 and 2007. They can connect to SpiraTeam v2.3 or later. They also require Microsoft .NET 3.5.
MS-Office 2007 Add-Ins -- these are compatible with Microsoft Office 2007 and 2010. They can connect to SpiraTeam v3.0 or later. They also require Microsoft .NET 4.0.
MS-Office 2010 Add-Ins -- these are compatible with Microsoft Office 2010 and all later versions. They can connect to SpiraTeam v5.0 or later. They also require Microsoft .NET 4.0.
This installation package will install the add-ins for Microsoft Excel, Word and Project at the same time. If you don't have the correct version of Microsoft .NET installed or some of the necessary prerequisites, you will be given the opportunity to install them when you first run the installation package.
Once you have the MS-Project Add-In installed, the second thing you may want to download is the SampleProjectFile.mpp MS-Project plan. This project file contains a fully-populated project plan and is a good sample to test the import/export before using a real project plan.
Once you have downloaded the project file, please double-click on it to open it up in MS-Project. You will notice that there is an additional toolbar displayed in MS-Project which is used for importing/exporting data to/from SpiraTeam:
If you are using the MS-Project 2010 Add-In, you will see a modified version of the toolbar that makes use of the MS-Office Ribbon:
This toolbar allows you to connect to SpiraTeam, and perform the import/export. The process for using this toolbar is described below:
"},{"location":"Migration-and-Integration/Importing-from-Microsoft-Project/#connecting-to-spirateam","title":"Connecting to SpiraTeam\u00ae","text":"The first thing you need to do is to click on the [Connect] button to specify the information used to connect to your instance of SpiraTeam:
Please enter the following information into the dialog box:
Spira URL: Please enter the web address that you use to access SpiraTeam\u00ae in your browser. This is usually of the form http://<hostname>/SpiraTeam. Make sure that you remove any suffixes from the address (e.g. Default.aspx).
User Name: Please enter the username that you use for logging in to SpiraTeam
Password: Please enter the password that you use for logging in to SpiraTeam
Remember Password: If you are using this Add-In on a private computer, you can check this option to have the system remember your credentials locally. Please do not use this option on a public computer and it will compromise the security of your SpiraTeam installation.
Once you have entered the necessary information, please click [Connect] to authenticate with the server. If the login information is invalid, you will see an error message appear, otherwise you will be connected and the list of projects and artifacts will be populated. If you want to end your session, you should just click the [Disconnect] button and the Add-In will close your connection.
"},{"location":"Migration-and-Integration/Importing-from-Microsoft-Project/#choosing-the-project","title":"Choosing the Project","text":"Once you have successfully connected to SpiraTeam, you should now choose the appropriate Project in the system that you will be importing / exporting to / from:
Or
Once you have selected the project, there are three buttons that you can now use:
Import: Clicking this button will retrieve the data from the SpiraTeam server and use that to populate the MS-Project file.
Export: Clicking this button will take the data in the currently opened MS-Project file and use it to add/update items in SpiraTeam.
Clear: This button allows you to quickly clear the data in the current Project file so that you can import a clean version from the server.
The MS-Project Add-In is capable of either importing data from SpiraTeam into the project file or exporting data from the project file to SpiraTeam. However it is important to understand how the system knows whether to add new items to SpiraTeam or whether to update existing items:
If you start with a blank MS-Project file and enter tasks into it, they will not have a value set on their Text1 custom field. When you perform an Export, it will add these as new items in SpiraTeam
If you start with a blank import MS-Project file and choose to Import data from SpiraTeam, those tasks imported will include the ID of the item in SpiraTeam as their Text1 custom field. You can either update those tasks or add new tasks in between. Any tasks that have the Text1 custom property populated will be updated in SpiraTeam when you choose Export, whereas any newly added tasks will be inserted in SpiraTeam.
The Add-In will import the tasks from SpiraTeam into the MS-Project file based on the following rules:
Any Releases/Iterations in SpiraTeam will be added as zero-effort (milestone) tasks in the MS-Project plan.
Any Requirements in SpiraTeam that have at least one task under them, will be added as summary tasks in the MS-Project plan. Their indentation in the project plan will match the requirements' indentation in SpiraTeam
Any Tasks in SpiraTeam will be added as tasks in the MS-Project plan. The tasks will be nested directly under their parent requirement's equivalent task in MS-Project.
Any Requirements in SpiraTeam that have no tasks under them, will be added as zero-effort (milestone) tasks in the MS-Project plan. Their indentation in the project plan will match the requirements' indentation in SpiraTeam
The Add-In will export the tasks in the MS-Project file into SpiraTeam based on the following rules:
Any summary tasks or top-level tasks in the MS-Project file will be treated as Requirements when being exported to SpiraTeam.
Any non-summary tasks that have zero-effort (milestones) that are not originally Releases/Iterations will be treated as Requirements when being exported to SpiraTeam.
Any non-summary tasks that are NOT at the top-level will be treated as Tasks when being exported to SpiraTeam. They will be attached to the requirement that is their parent task in MS-Project.
The export function does not update any of the Release/Iteration items. They need to be updated in SpiraTeam.
If you want to prevent an MS-Project Task from being imported into SpiraTeam simply set the value of its Text1 column to the text \"IGNORE\" (without the quotes).
Be careful when you indent/outdent a task in MS-Project. If you take a non-summary item (which would be represented by a Task in SpiraTeam) and make it a summary item by adding child tasks, when you next run Export, it will get added as a new Requirement in SpiraTeam, with the child tasks added as Tasks. The old task will still remain in SpiraTeam and will need to be manually removed.
"},{"location":"Migration-and-Integration/Importing-from-Microsoft-Word-%28Office365%29/","title":"Importing from Microsoft Word (Office 2019+, iOS, Web)","text":"This add-in lets you import a list of requirements or test cases (with folders and test steps) into any product in your SpiraTest, SpiraTeam, or SpiraPlan application. It lets you specify how your document is organized using its styles and headings so the data added to SpiraPlan will be hierarchically structured in the same way. It supports importing rich text, tables, lists, and images.
This add-in requires:
a support version of Microsoft Word
SpiraTest\u00ae, SpiraTeam\u00ae, or SpiraPlan\u00ae application (called SpiraPlan from here on) version 6.3.0.1+
To install the add-in:
The add-in works with modern Word (docx) documents. The add-in has a number of settings to work flexibly with your existing Word files so that they can be imported into SpiraPlan without any changes. Please note that some preparation of the document may be required in some circumstances if the styles configuration does not fully meet your needs.
"},{"location":"Migration-and-Integration/Importing-from-Microsoft-Word-%28Office365%29/#connect-to-spiraplan","title":"Connect to SpiraPlan","text":"You can use this add-in with SpiraTest\u00ae, SpiraTeam\u00ae, or SpiraPlan\u00ae. If you are using Word in the browser, make sure SpiraPlan is accessible over the internet.
When you first open the add-in you will see the connection screen. Fill in the details and click \"Log In\" to connect the add-in to your SpiraPlan.
If there is a problem connecting to Spira you will be notified with an error message.
After you have logged in click Log-out to close your connection with SpiraPlan and return to the add-in's login page.
"},{"location":"Migration-and-Integration/Importing-from-Microsoft-Word-%28Office365%29/#select-a-product","title":"Select a Product","text":"After logging in, first you need to choose the product to import into. The dropdown shows all products you are a member of.
Once you have selected a product, you need to select to either import Requirements or Test Cases. This selection can be changed at any time.
"},{"location":"Migration-and-Integration/Importing-from-Microsoft-Word-%28Office365%29/#configure-the-styles","title":"Configure the styles","text":"Select the styles used in the document which represent either the hierarchy of requirements, or the test case folder names, test case names, and table configuration for test steps. These styles must be selected to match those used in the current document. Your style selections are saved as metadata within the document itself, so next time you open the document, the styles will be pre-populated for you.
"},{"location":"Migration-and-Integration/Importing-from-Microsoft-Word-%28Office365%29/#requirements","title":"Requirements","text":"You can select up to 5 indent levels to represent the hierarchical relationship of your requirements in your document. This hierarchy will be replicated when importing into SpiraPlan. Choose the relevant styles that match each indent level. These styles are used as headings for your requirements and will become the requirement names in SpiraPlan
Your requirements document must only increase the indent level once per requirement (your document can't have an Indent Level 1 requirement immediately followed by an Indent Level 3 requirement). If the requirements to import do not meet this condition, the add-in will display a relevant error.
"},{"location":"Migration-and-Integration/Importing-from-Microsoft-Word-%28Office365%29/#test-cases","title":"Test Cases","text":"It is common to organize test cases into groups or headings in your document. The add-in support 1 level of groupings and these will get converted into root level test case folders in SpiraPlan. Test case folder descriptions (text immediately below the folder heading in Word) will also be added to SpiraPlan
Select the style that matches your heading used to organize test cases into folders. Then select the style that matches the heading used for your test case names. Any test cases after that heading will be added into that folder. If there is already a folder with that name in SpiraPlan at the root level (case sensitive), relevant test cases will be added to that existing test case folder (in other words, a duplicate test case folder will not be created).
Test cases and their descriptions will be imported into SpiraPlan. Test step information will also be imported if present.
Test steps need to be in a table inside the relevant test case with rows for each test step. If the test case description has more than one table in it, the last table is assumed to be the one that contains the test steps. The other tables will not be imported into SpiraPlan at all.
The add-in supports tables with or without header rows. Use the \"Using header rows\" option to toggle between removing the first row (because it has table headers) or sending the first row as a test step. Select which columns match with each test step field.
Test step table rows with an empty description will get a default description added, and empty rows are ignored. If the table cannot be properly parsed to import into SpiraPlan an error will be shown. This can happen, for example, if a table does not have a description column at all, or the description column is completely blank, or the whole table is empty.
"},{"location":"Migration-and-Integration/Importing-from-Microsoft-Word-%28Office365%29/#validate-styles","title":"Validate Styles","text":"Once the configuration / selection of the styles is complete, click the \"Validate Styles\" button. This will check the document against your selections to make sure that there are no obvious problems. If there are you will see a popup with an explanation.
Once the validation is complete you will be able to start the import process.
"},{"location":"Migration-and-Integration/Importing-from-Microsoft-Word-%28Office365%29/#importing-into-spiraplan","title":"Importing into SpiraPlan","text":"By default, the add-in imports your entire document into SpiraPlan, based on your setup as described above.
If you want, you can also choose exactly what to import by selecting just part of the document (discussed more below).
Once you have decided what to import, click the \"Send to Spira\" button. During the import process you will see a popup showing its progress. Note that closing this pop-up will not stop the import process - to do that you will need to press the cancel button, or close or refresh the add-in (note that this will not un-do any already sent artifacts).
Selecting part of a document
To send only part of a document:
Make sure no lists within the selection contain styles which are set to any style selector - for instance if Heading 1 is your indent level 1 selection, lists may not contain any Heading 1 text - parsing will throw an error or even crash the add-in depending on the specific instance.
"},{"location":"Migration-and-Integration/Importing-from-Microsoft-Word-%28Office365%29/#troubleshooting","title":"Troubleshooting","text":"Documents are often, rich, complex, very long, and have been used for a number of years. Sometimes this means the add-in may struggle to correctly import all relevant artifacts. This can be for a variety of reasons:
How to work with legacy Word documents
Older Word documents (Created or edited in a version of Word 2016 or earlier) may not get imported correctly
Older versions of Word saved documents in a slightly different format than newer versions. Microsoft add-ins are not able to fully see all parts of these older document formats. Unfortunately, it is hard to know whether your document is in the newer or older format.
Practically, this means that when working with these older Word documents, the add-in:
Currently, the only automatic workaround we can recommend that fixes both of the above issues, is to:
There is no way, within Word itself, to update a document to the latest version automatically. If you are not able to use the above method, you may need to manually update all images and lists in your document:
images: there are two options here
Quicker for lots of images but complex. By default, Word will paste images with the setting \"Keep source formatting\", but this is not what we want, so we have to tell Word to not do this.
What can the Word365 add-in do that the Classic Word add-in cannot?
What can the Classic Word add-in do that the Word365 add-in cannot?
The web-based interface of SpiraTeam\u00ae is ideal for creating and managing requirements, test cases and incidents for a new project. However often an organization will often have existing requirements documentation and test case templates in Microsoft Word format that need to get easily migrated into SpiraTeam.
To simplify this task, SpiraTeam\u00ae comes with a Microsoft Word Add-In that can export requirements and test cases from a populated Word document into SpiraTeam\u00ae. Note that this guide refers to SpiraTeam\u00ae, but the Word Add-In can be used with SpiraTest\u00ae and SpiraPlan\u00ae as well. The only difference is that the Test Case import functionality will not be applicable for SpiraPlan\u00ae users.
"},{"location":"Migration-and-Integration/Importing-from-Microsoft-Word/#installing-the-microsoft-word-add-in","title":"Installing the Microsoft Word Add-In","text":"The first thing you need to do is to go to the \"Add-Ons and Downloads\" page of the Inflectra Website (it can be found in the SpiraTest, SpiraPlan or SpiraTeam sections), and download the MS-Office Add-Ins installation package. There are separate packages for the following versions of MS Office:
MS-Office 2003 Add-Ins -- these are compatible with Microsoft Office 2003 and 2007. They can connect to SpiraTeam v2.3 or later. They also require Microsoft .NET 3.5.
MS-Office 2007 Add-Ins -- these are compatible with Microsoft Office 2007 and 2010. They can connect to SpiraTeam v3.0 or later. They also require Microsoft .NET 4.0.
MS-Office 2010 Add-Ins -- these are compatible with Microsoft Office 2010 and later. They can connect to SpiraTeam v5.0 or later. They also require Microsoft .NET 4.0.
This installation package will install the add-ins for Microsoft Excel, Word and Project at the same time. If you don't have the correct version of Microsoft .NET installed or some of the necessary prerequisites, you will be given the opportunity to install them when you first run the installation package.
Once you have the Word Add-In installed, the second thing you'll need to download is the SampleWordDocument document. This sample document contains some example requirements and test cases that be exported into SpiraTeam. Also the documents make good templates if you're looking for a way to standardize the import of requirements and test cases. There are two versions of the document available - SampleWordDocument.doc for Word 2003 and SampleWordDocument.docx for Word 2007 and later.
Once you have downloaded the template, please double-click on it to open it up in MS-Word. You will notice that there is an additional toolbar displayed in Word which is used for exporting requirements and test cases to SpiraTeam:
If you are using the MS-Word 2007 or 2010 Add-In, you will see a modified version of the toolbar that makes use of the MS-Office Ribbon:
This toolbar allows you to connect to SpiraTeam, and perform the export. The process for using this toolbar is described below:
"},{"location":"Migration-and-Integration/Importing-from-Microsoft-Word/#connecting-to-spirateam","title":"Connecting to SpiraTeam\u00ae","text":"The first thing you need to do is to click on the [Connect] button to specify the information used to connect to your instance of SpiraTeam:
Please enter the following information into the dialog box:
Spira URL: Please enter the web address that you use to access SpiraTeam\u00ae in your browser. This is usually of the form http://<hostname>/SpiraTeam. Make sure that you remove any suffixes from the address (e.g. Default.aspx).
User Name: Please enter the username that you use for logging in to SpiraTeam
Password: Please enter the password that you use for logging in to SpiraTeam
Remember Password: If you are using this Add-In on a private computer, you can check this option to have the system remember your credentials locally. Please do not use this option on a public computer and it will compromise the security of your SpiraTeam installation.
Once you have entered the necessary information, please click [Connect] to authenticate with the server. If the login information is invalid, you will see an error message appear, otherwise you will be connected and the list of projects and artifacts will be populated. If you want to end your session, you should just click the [Disconnect] button and the Add-In will close your connection.
"},{"location":"Migration-and-Integration/Importing-from-Microsoft-Word/#choosing-the-project-and-artifact","title":"Choosing the Project and Artifact","text":"Once you have successfully connected to SpiraTeam, you should now choose the appropriate Project and Artifact in the system that you will be importing / exporting:
Or
Once you have selected the project and artifact, there are two buttons that you can now use:
Export: Clicking this button will take the currently selected data in the document and use it to add new items in SpiraTeam.
Style Mappings: This button allows you to change the parameters used by the Add-In when scanning the Word document to know where each requirement, test case and test step beings and ends.
The parameters selection varies by the type of information being exported, and will be discussed in the relevant artifact section below:
"},{"location":"Migration-and-Integration/Importing-from-Microsoft-Word/#exporting-requirements-into-spirateam","title":"Exporting Requirements into SpiraTeam","text":"To export requirements, first you need to open up the MS-Word document that contains the requirements to be exported. Then you need to click on the \"Style Mappings\" icon to display the style mapping configuration dialog box:
This dialog box allows you to tell the Add-In which styles are being used in the document to describe each level of Requirements in the hierarchy. When you run the Export, the Add-In will examine each paragraph in the document, and any item that matches one of these styles will be considered the start of a new requirement, and its indentation level will be based on the appropriate style.
Once you have verified that the styles match those used in your document, highlight the areas of the document that you wish to import and click the [Import] button. Once you have done this, the Add-In will scan the selected portions of the document and export the requirements into the system. During the export, the Add-In uses the following rules for dealing with the content:
The text that matches the selected style will be loaded as the Name field of the requirement
Any text located between the selected styles will be loaded into the Description field of the requirement. The Add-In will attempt to match the formatted used in the Word document. However because of some differences between MS-Word and HTML, it may not be exact.
Any embedded images will be added to the requirement as a file Attachment, with an embedded image tag added to Description field
To export test cases (and their test steps), first you need to open up the MS-Word document that contains the test cases to be exported. Then you need to click on the \"Style Mappings\" icon to display the style mapping configuration dialog box:
This dialog box allows you to tell the Add-In which styles are being used in the document to denote the name of the Test Folder and the name of the Test Case. For the test steps, the Add-In currently requires that they be organized in tables, with each column in the table being used consistently to describe one of the three Test Step fields. For the import to work correct, your tables need to have at least three (3) columns so that it can map them correctly. You can use the same column multiple times (e.g. the contents of column 2 would be imported into both the expected result and sample data).
Once you have verified that the styles and table columns match those used in your document, highlight the areas of the document that you wish to import and click the [Import] button. Once you have done this, the Add-In will scan the selected portions of the document and export the test cases and test steps into the system. During the export, the Add-In uses the following rules for dealing with the content:
The text that matches the selected style will be loaded as the Name field of the Test Folder or Test Case
Any text located between the selected styles will be loaded into the Description field of the Test Case. The Add-In will attempt to match the formatted used in the Word document. However because of some differences between MS-Word and HTML, it may not be exact.
Any embedded images will be added to the Test Case as a file Attachment, with an embedded image tag added to Description field
Any tables located between the selected styles will be treated as the Test Steps belonging to the previous test case. The fields for the Test Steps will be populated based on the index of the column.
Any text located in the table cells into the appropriate field of the Test Step. The Add-In will attempt to match the formatted used in the Word document. However because of some differences between MS-Word and HTML, it may not be exact.
The first row of the table is assumed to be a header row, so if you are seeing the first step of your document being omitted, it means that you need to add a header rows.
If there is an error during the import of either requirements or test cases, the error message will be stored in a text file called Spira_WordImport.log that can be found on the desktop of the user running the import:
"},{"location":"Migration-and-Integration/Importing-from-Microsoft-Word/#functionality-differences-to-the-microsoft-word365-plugin","title":"Functionality Differences to the Microsoft Word365 plugin","text":"What can the Word365 add-in do that the Classic Word add-in cannot?
What can the Classic Word add-in do that the Word365 add-in cannot?
This page outlines how to use the HP ALM Migration Tool to import projects from HP ALM (formerly known as HP Quality Center) into Spira.
What can be imported from HP ALM?
The migration tool will import the following artifacts:
To get started, you will need to install the migration tool onto a workstation that can access both your HP ALM server, and your Spira application.
You must already have a working installation of Spira v4.0 or later and a working version of HP ALM 11.5 or later. If you are using HP QualityCenter 10.0 or older, please refer to the migration tool and documentation here.
The Windows installation package can be downloaded from the \"Add-Ons & Downloads\" section of the Inflectra website. Once you have obtained the Windows Installer package, simply double-click on the package to begin the installation wizard which should display the following welcome page:
Click the <Next> button, accept the software license, then click <Next> again to choose the folder to install the migration tool to:
Choose the folder to install to, and then decide whether the application should be accessible by all users on the workstation or just the current user. Then click the <Install> button to start the installation process. It will confirm if you want to proceed, click <Next> then wait for it to finish.
"},{"location":"Migration-and-Integration/Migrating-from-HP-ALM/#using-the-hp-alm-migration-tool","title":"Using the HP ALM Migration Tool","text":""},{"location":"Migration-and-Integration/Migrating-from-HP-ALM/#connecting-to-hp-alm-and-choosing-artifacts","title":"Connecting to HP ALM and choosing artifacts","text":"Now that you have installed the migration tool, you can launch it at any time by going to Start > Programs > Inflectra > SpiraTest > Tools > HP ALM Importer. This will launch the migration tool application itself:
The first thing you need to do is to enter the URL for the instance of HP ALM that you want to import the information from (typically of the form http://<server name>/qcbin) together with a valid username and password.
Once you have entered this information, click the <Authenticate> button and the list of possible domains and projects will be populated. Select the HP ALM domain and project that you want to import from and click the <Login> button. If the user has permission to access this project, you will be see a message that the login was successful.
Assuming this is a new import session, i.e. you are not restoring a previous session, choose the types of artifact you want to import and then click the <Next> button to move to the next page in the import wizard:
"},{"location":"Migration-and-Integration/Migrating-from-HP-ALM/#connecting-to-spira-and-choosing-options","title":"Connecting to Spira and choosing options","text":"This page allows you to enter the URL, user name and password that you want to use to access the instance of Spira that you want to import to and click <Login>. Typically the URL is of the form (http://<server name>/SpiraTest). The version of the importer being used must be compatible with the version of Spira you're importing into; if not you will receive an error message.
You start the import process from the Spira login screen. There is an \"Import Options\" box. Here, you can check 'Verbose Logging' to add more log entries to the session log, which will be saved on the computer's Desktop. You can also choose to 'Resume Previous Import Session'. This option is explained below.
Click the <Start Import> button to begin the process of importing the various artifacts from HP ALM into Spira. Note that the importer will automatically create a new project in Spira to hold all the artifacts with the same name as that used in HP ALM.
"},{"location":"Migration-and-Integration/Migrating-from-HP-ALM/#import-progress","title":"Import progress","text":"During the import process, the importer shows the current session identifier (which is part of the session log name), as well as the progress and estimated remaining time for every artifact. The Event History at the bottom logs important events of the session. As each of the types of artifact are imported, the progress display will change (as shown above). Once the import has finished, you will receive a message to that effect and the <Done> button will be enabled. Clicking this button closes the importer. You can cancel the importing session at any time by clicking on 'Cancel and Close'. You should now log into Spira using the same username and password that was used for the import to view the imported project.
Note: Once you have migrated a project into Spira you will have the definitions of incident priorities and statuses from both Spira and HP ALM (this is because HP ALM doesn't use the same codes as Spira, so they will be imported).
You should go back in to the Administration screen and make all the standard Spira statuses and priorities inactive, and then create a new incident workflow using the imported HP ALM statuses.
"},{"location":"Migration-and-Integration/Migrating-from-HP-ALM/#restoring-a-failed-or-canceled-session","title":"Restoring a failed or canceled Session","text":"If you can cancel a session part way through, or the session fails for any reason, you can easily resume importing artifacts from that session. To do this:
ApplicationData]\\Spira_ALM_QC_Importer_Sessions). You should see then the identification of the session, followed by the artifacts previously selected for it:
At this point, you can add or remove artifacts from the session. Please note that artifacts that already started importing can not now be deselected. In our example, only Test Runs, Users, and Attachments are not disabled. Since we didn't select Attachments originally, if you check off that box, it will include attachments for new artifacts - changes will not be made to artifact attachments already imported to Spira. Press 'Start Import' and wait a few seconds until the program loads the previous session data and continues from the point it stopped previously:
Wait until the import session successfully ends. Congratulations, you have just imported your data from HP ALM to Spira!
"},{"location":"Migration-and-Integration/Migrating-from-HP-QualityCenter/","title":"Migrating from HP QualityCenter","text":"This is for Legacy HP QualityCenter installs only
You should only use this guide if you are using HP QualityCenter 10.0 or older.
If your HP QC/ALM installation is 11.5 or newer please follow the instructions here.
This section outlines how to use the included Migration Tool for importing Requirements, Test Cases, Test Runs and Incidents from HP QualityCenter (formerly known as Mercury TestDirector).
"},{"location":"Migration-and-Integration/Migrating-from-HP-QualityCenter/#installing-the-qualitycenter-migration-tool","title":"Installing the QualityCenter Migration Tool","text":"This section outlines how to install the migration tool for QualityCenter onto a workstation so that you can then migrate whole projects from QualityCenter to SpiraTest. It assumes that you already have a working installation of SpiraTest v3.0 or later. If you have an earlier version of SpiraTest you will need to upgrade to at least v3.0 before trying to migrate projects.
The Windows installation package can be downloaded from the 'Add-Ons & Downloads\" section of the Inflectra website. Once you have obtained the Windows Installer package, simply double-click on the package to begin the installation wizard which should display the following welcome page:
Click the <Next> button, accept the software license, then click <Next> again to choose the folder to install the migration tool to:
Choose the folder to install to, and then decide whether the application should be accessible by all users on the workstation or just the current user. Then click the <Install> button to start the installation process. It will confirm if you want to proceed, click <Next> then wait for it to finish.
"},{"location":"Migration-and-Integration/Migrating-from-HP-QualityCenter/#using-the-hp-qualitycenter-migration-tool","title":"Using the HP QualityCenter Migration Tool","text":"Now that you have installed the migration tool, you can launch it at any time by going to Start > Programs > SpiraTest > Tools > QualityCenter Importer. This will launch the migration tool application itself:
The first thing you need to do is to enter the URL for the instance of HP QualityCenter that you want to import the information from (typically of the form http://<server name>/qcbin) together with a valid username and password.
Note that the importer has only been tested against version 9.0 of Quality Center or later. It may not work correctly against previous versions. Once you have entered this information, click the <Authenticate> button and the list of possible domains and projects will be populated.
Select the QualityCenter domain and project that you want to import from and click the <Login> button:
Assuming that the user name selected has permission to access this project, you will be prompted with a message box indicating that the login was successful. Now choose the types of artifact you want to import and then click the <Next> button to move to the next page in the import wizard:
This page allows you to enter the URL, user name and password that you want to use to access the instance of SpiraTest that you want to import to and click <Login>. Typically the URL is of the form (http://<server name>/SpiraTest). The version of the importer being used must be compatible with the version of SpiraTest you're importing into; if not you will receive an error message.
Assuming that the login was successful, click the <Start Import> button to actually begin the process of importing the various artifacts from QualityCenter into SpiraTest. Note that the importer will automatically create a new project in SpiraTest to hold all the artifacts with the same name as that used in QualityCenter.
During the import process, as each of the types of artifact are imported, the progress display will change (as illustrated above). Once the import has finished, you will receive a message to that effect and the <Done> button will be enabled. Clicking this button closed the importer. You should now log into SpiraTest using the same user name and password that was used for the import to view the imported project.
The migration tool will import the following artifacts:
Note: Once you have migrated a project into SpiraTest you will have the definitions of incident priorities and statuses from both SpiraTest and QualityCenter (this is because QualityCenter doesn't use the same codes as SpiraTest, so they will be imported). You should go back in to the Administration screen and make all the SpiraTest statuses and priorities inactive.
"},{"location":"Migration-and-Integration/Migrating-from-IBM-Rational-Quality-Manager/","title":"Migrating from IBM Rational Quality Manager (RQM)","text":"This section outlines how to use the free Migration Tool for importing test plans, test cases, test suites, test scripts and test executions from IBM Rational Quality Manager (RQM) into Spira (SpiraTest, SpiraTeam or SpiraPlan).
"},{"location":"Migration-and-Integration/Migrating-from-IBM-Rational-Quality-Manager/#installing-the-rqm-migration-tool","title":"Installing the RQM Migration Tool","text":"This section outlines how to install the migration tool for RQM onto a workstation so that you can then migrate whole projects from RQM to Spira. It assumes that you already have a working installation of Spira v6.0 or later and a live instance of RQM to migrate from. If you have an earlier version of Spira you will need to upgrade to at least v6.0 before trying to migrate projects.
The Windows installation package can be downloaded from the 'Add-Ons & Downloads\" section of the Inflectra website. Once you have obtained the Windows Installer package, simply double-click on the package to begin the installation wizard which should display the following welcome page:
Click the <Next> button, accept the software license, then click <Next> again to choose the folder to install the migration tool to:
Choose the folder to install to, and then decide whether the application should be accessible by all users on the workstation or just the current user. Then click the <Install> button to start the installation process. It will confirm if you want to proceed, click <Next> then wait for it to finish.
"},{"location":"Migration-and-Integration/Migrating-from-IBM-Rational-Quality-Manager/#using-the-rqm-migration-tool","title":"Using the RQM Migration Tool","text":"Now that you have installed the migration tool, you can launch it at any time by going to Start > Programs > Inflectra > SpiraTest > Tools > IBM RQM Importer. This will launch the migration tool application itself:
The first thing you need to do is to enter the URL for the instance of RQM that you want to import the information from (typically of the form https://jazz.net/mycompany) together with a valid username and password.
Once you have entered this information, click the <Authenticate> button and the list of projects will be populated. Select the RQM project that you want to import from You can also choose to not import certain artifacts from RQM (e.g. test executions, etc.) then click the <Next> button to move to the next page in the import wizard:
This page allows you to enter the URL, user name and password that you want to use to access the instance of Spira that you want to import to and click <Login>. Typically, the URL is of the form (https://xxxx.spiraservice.net). The version of the importer being used must be compatible with the version of Spira you're importing into; if not you will receive an error message.
Assuming that the login was successful, click the <Start Import> button to actually begin the process of importing the various artifacts from RQM into Spira. Note that the importer will automatically create a new project in Spira to hold all the artifacts with the same name as that used in RQM.
During the import process, as each of the types of artifact are imported, the progress display will change (as illustrated above). Once the import has finished, you will receive a message to that effect and the <Done> button will be enabled. Clicking this button closed the importer. You should now log into SpiraTest using the same user name and password that was used for the import to view the imported project.
The migration tool will import the following artifacts from RQM:
Should the import fail for any reason, there will be a log file created on the Desktop of the person doing the import. The filename is usually: Spira_RQM_Import.log.
When you migrate an RQM project to Spira, the data will migrate as described below.
"},{"location":"Migration-and-Integration/Migrating-from-IBM-Rational-Quality-Manager/#test-plans-and-test-cases","title":"Test Plans and Test Cases","text":"The test plans and associated test cases from RQM will migrate into Spira test case folders and test cases:
becomes:
"},{"location":"Migration-and-Integration/Migrating-from-IBM-Rational-Quality-Manager/#test-scripts-and-test-steps","title":"Test Scripts and Test Steps","text":"The test scripts and associated manual test steps from RQM will migrate into Spira template test cases and test steps:
becomes:
In RQM, the test cases don't contain test steps themselves. Instead, the test case contain references to the test scripts, which contain the test steps.
Therefore when we migrate over the test cases from RQM to Spira, we create linked test cases from the test plan test cases to the test script test cases to maintain these relationships:
"},{"location":"Migration-and-Integration/Migrating-from-IBM-Rational-Quality-Manager/#test-runs-and-test-run-steps","title":"Test Runs and Test Run Steps","text":"The test executions from RQM contain test steps:
These are migrated over into Spira and test runs and test run steps:
"},{"location":"Migration-and-Integration/Migrating-from-Jira/","title":"Migrating from Atlassian Jira","text":"This section outlines how to use the included Migration Tool for importing projects, versions, requirements, issues, tasks and associated attachments from Atlassian Jira to SpiraTeam.
Note: This migration tool works with Jira Cloud, Server and Data Center editions.
"},{"location":"Migration-and-Integration/Migrating-from-Jira/#installing-the-jira-migration-tool","title":"Installing the Jira Migration Tool","text":"This section outlines how to install the migration tool for Jira onto a workstation so that you can then migrate whole projects from Jira to either SpiraTeam or SpiraPlan (hereafter referred to as SpiraTeam). It assumes that you already have a working installation of SpiraTeam v6.0 or later and a working version of Jira Cloud, Server or Data Center.
Minimum Version of Spira
You must be on at least SpiraTeam 6.13 to use this tool. If you have an earlier version of SpiraTeam you will need to upgrade to at least v6.13 before trying to migrate projects.
The Windows installation package can be downloaded from the 'Add-Ons & Downloads\" section of the Inflectra website. Once you have obtained the Windows Installer package, simply double-click on the package to begin the installation wizard which should display the following welcome page:
Click the <Next> button, accept the software license, then click <Next> again to choose the folder to install the migration tool to:
Choose the folder to install to, and then decide whether the application should be accessible by all users on the workstation or just the current user. Then click the <Install> button to start the installation process. It will confirm if you want to proceed, click <Next> then wait for it to finish.
"},{"location":"Migration-and-Integration/Migrating-from-Jira/#using-the-jira-migration-tool","title":"Using the Jira Migration Tool","text":"Now that you have installed the migration tool, you can launch it at any time by going to Start > Programs > Inflectra > SpiraTeam > Tools > Jira Importer. This will launch the migration tool application itself:
"},{"location":"Migration-and-Integration/Migrating-from-Jira/#connecting-to-jira","title":"Connecting to Jira","text":"The first thing you need to do is to enter the URL for the instance of Jira that you want to import the information from (typically of the form http://servername/jira for on-premise and https://myinstance.atlassian.net for cloud) together with a valid username and password (or API Key if using Jira Cloud).
Once you have entered this information, click the Login button and the list of possible Jira projects will be populated.
Select the Jira project that you want to import from, choose which artifacts (requirements, tasks incidents, users, attachments, etc.) you want to import, then click the Next button to move to the next page in the import wizard.
"},{"location":"Migration-and-Integration/Migrating-from-Jira/#connecting-to-spirateam","title":"Connecting to SpiraTeam","text":"This page allows you to enter the URL, user name and password (or Api Key if using SSO) that you want to use to access the instance of SpiraTeam that you want to import to and click Login. (Typically the URL is of the form http://servername/SpiraTeam for on-premise and https://myinstance.spiraservice.net for cloud). The version of the importer being used must be compatible with the version of SpiraTeam you're importing into; if not you will receive an error message.
Assuming that the login was successful, next choose the product template that you want the imported project to use. You can also select the option to '--- Create New Template ---' instead, which will instruct the importer to create a brand new product template for the import. We recommend this option for test imports to avoid affecting any production templates
Once you have chosen the template, click the Next button to move to the next page in the wizard:
"},{"location":"Migration-and-Integration/Migrating-from-Jira/#mapping-jira-issues-types-to-spirateam-artifacts","title":"Mapping Jira Issues Types to SpiraTeam Artifacts","text":"On this page you will map the different SpiraTeam artifacts to the different issue types in Jira. Currently, the following artifact types in SpiraTeam can be mapped to Jira issues: - Requirements (used for user stories, features, epics, etc.) - Tasks (used for tasks and sub-tasks) - Incidents (used for all other issue types such as bugs, defects, issues)
Once you have mapped the artfiacts, click the Start Import button to actually begin the process of importing the various artifacts from Jira into SpiraTeam.
"},{"location":"Migration-and-Integration/Migrating-from-Jira/#importer-progress","title":"Importer Progress","text":"Note that the importer will automatically create a new project in SpiraTeam to hold all the artifacts with the same name as that used in Jira.
During the import process, as each of the types of artifact are imported, the progress display will change (as illustrated above). Once the import has finished, you will receive a message to that effect and the Done button will be enabled. Clicking this button will close the importer. You should now log into SpiraTeam using the same user name and password that was used for the import to view the imported project.
"},{"location":"Migration-and-Integration/Migrating-from-Jira/#what-is-imported","title":"What is Imported?","text":"The migration tool will import the following artifacts:
Any of the Jira issue types that are mapped to requirements in SpiraTeam:
Will be imported into SpiraTeam as types of requirement:
"},{"location":"Migration-and-Integration/Migrating-from-Jira/#tasks","title":"Tasks","text":"Any of the Jira issue types that are mapped to tasks in SpiraTeam:
Will be imported into SpiraTeam as types of task:
"},{"location":"Migration-and-Integration/Migrating-from-Jira/#incidents","title":"Incidents","text":"Any of the Jira issue types that are mapped to incidents in SpiraTeam:
Will be imported into SpiraTeam as types of incident:
"},{"location":"Migration-and-Integration/Migrating-from-MS-Azure-DevOps/","title":"Migrating from MS Azure DevOps / TFS","text":"This section outlines how to use the free Migration Tool for importing users, releases, requirements, test plans, test suites, test cases, test runs, tasks and defects from Microsoft Azure DevOps (ADO) also known as Microsoft Team Foundation Server (TFS) into Spira.
"},{"location":"Migration-and-Integration/Migrating-from-MS-Azure-DevOps/#installing-the-ado-migration-tool","title":"Installing the ADO Migration Tool","text":"This section outlines how to install the migration tool for ADO onto a workstation so that you can then migrate whole projects from ADO into Spira (SpiraTest, SpiraTeam or SpiraPlan). It assumes that you already have a working installation of Spira v7.0 or later. If you have an earlier version of Spira you will need to upgrade to at least v7.0 before trying to migrate projects.
The Windows installation package can be downloaded from the 'Add-Ons & Downloads\" section of the Inflectra website. Once you have obtained the Windows Installer package, simply double-click on the package to begin the installation wizard which should display the following welcome page:
Click the Next button, accept the software license, then click Next again to choose the folder to install the migration tool to:
Choose the folder to install to, and then decide whether the application should be accessible by all users on the workstation or just the current user. Then click the Install button to start the installation process. It will confirm if you want to proceed, click Next then wait for it to finish.
Now that you have installed the migration tool, you can launch it at any time by going to Start > Programs > Spira > Tools > ADO/TFS Importer. This will launch the migration tool application itself:
The first thing you need to do is to enter the URL for the instance of ADO that you want to import.
For cloud ADO instances, the URL will normally be the https://dev.azure.com/account, where 'account' is the name of the ADO organization. You will also need to enter a valid username and Personal Access Token (PAT).
For on-premise TFS installations, the URL should include the project collection that you want to import the information from (typically of the form http://server:8080/tfs) together with a valid username, Windows\u00ae domain and password.
Once you have entered this information, click the Authenticate button and the list of possible projects will be populated in the Project dropdown list. Select the ADO project that you want to import from and either keep the Test Plan dropdown set to 'All Test Plans' or pick a specific test plan to import.
You can also at this point choose which optional items will be imported from ADO - users, requirements, tasks, bugs, test cases, test runs, attachments or test sets. Once you have chosen the project and/or test plan, click the Next button to go to the Spira configuration screen.
This page allows you to enter the URL, user name and password that you want to use to access the instance of Spira that you want to import to and click Login.
Typically the URL is of the form http://server-name/Spira for on-premise installations and https://mycompany.spiraservice.net for cloud instances. The version of the importer being used must be compatible with the version of Spira you're importing into; if not you will receive an error message.
Assuming that the login was successful, click the Next button to go to the next screen where you will map the different types of work item to Spira artifacts:
On this page you will map the different Spira artifacts to the different work item types in ADO. Currently, the following artifact types in Spira can be mapped to ADO work items: - Requirements (used for user stories, features, epics, etc.) - Tasks (used for tasks) - Incidents (used for all other issue types such as bugs, defects, issues)
Note that you don't need to explicitly map test cases as they are automatically handled.
Once you have mapped the work item types you will be importing, click the Start Import button to actually begin the process of importing the various artifacts from ADO into Spira. Note that the importer will automatically create a new project in Spira to hold all the artifacts with the same name as that used in ADO.
During the import process, as each of the types of artifact are imported, the progress display will change (as illustrated above). Once the import has finished, you will receive a message to that effect and the Done button will be enabled. Clicking this button closed the importer. You should now log into Spira using the same user name and password that was used for the import to view the imported project.
The migration tool will import the following artifacts:
Once the import has completed, please open up the the import log file Spira_ADOTFSImport.log that will be saved to the Windows Desktop of the user running the import. In this log file you will see what was imported, with any items that failed to import also listed.
This section outlines how to use the free Migration Tool for importing users, releases, requirements, test plans, test suites, test cases, test runs and defects from Microsoft Test Manager (MTM).
"},{"location":"Migration-and-Integration/Migrating-from-MS-Test-Manager/#installing-the-mtm-migration-tool","title":"Installing the MTM Migration Tool","text":"This section outlines how to install the migration tool for MTM onto a workstation so that you can then migrate whole projects from MTM into SpiraTest (or SpiraTeam). It assumes that you already have a working installation of SpiraTest v4.0 or later. If you have an earlier version of SpiraTest you will need to upgrade to at least v4.0 before trying to migrate projects.
The Windows installation package can be downloaded from the 'Add-Ons & Downloads\" section of the Inflectra website. Once you have obtained the Windows Installer package, simply double-click on the package to begin the installation wizard which should display the following welcome page:
Click the <Next> button, accept the software license, then click <Next> again to choose the folder to install the migration tool to:
Choose the folder to install to, and then decide whether the application should be accessible by all users on the workstation or just the current user. Then click the <Install> button to start the installation process. It will confirm if you want to proceed, click <Next> then wait for it to finish.
"},{"location":"Migration-and-Integration/Migrating-from-MS-Test-Manager/#using-the-mtm-migration-tool","title":"Using the MTM Migration Tool","text":"Now that you have installed the migration tool, you can launch it at any time by going to Start > Programs > SpiraTest > Tools > MTM Importer. This will launch the migration tool application itself:
The first thing you need to do is to enter the URL for the instance of Microsoft Team Foundation Server (TFS) that MTM is running on. The URL should include the project collection that you want to import the information from (typically of the form http://server:8080/tfs) together with a valid username, Windows\u00ae domain and password.
Once you have entered this information, click the <Authenticate> button and the list of possible projects will be populated in the Project dropdown list. Select the MTM project that you want to import from and either keep the Test Plan dropdown set to 'All Test Plans' or pick a specific test plan to import.
You can also at this point choose which optional items will be imported from MTM (users, test runs, attachments or test sets) -- test cases are always imported. Once you have chosen the project and/or test plan, click the <Next> button to go to the SpiraTest configuration screen.
This page allows you to enter the URL, user name and password that you want to use to access the instance of SpiraTest that you want to import to and click <Login>. Typically the URL is of the form (http://<server name>/SpiraTest). The version of the importer being used must be compatible with the version of SpiraTest you're importing into; if not you will receive an error message.
Assuming that the login was successful, click the <Start Import> button to actually begin the process of importing the various artifacts from MTM into SpiraTest. Note that the importer will automatically create a new project in SpiraTest to hold all the artifacts with the same name as that used in MTM.
During the import process, as each of the types of artifact are imported, the progress display will change (as illustrated above). Once the import has finished, you will receive a message to that effect and the <Done> button will be enabled. Clicking this button closed the importer. You should now log into SpiraTest using the same user name and password that was used for the import to view the imported project.
The migration tool will import the following artifacts:
This section outlines how to use the free Migration Tool for importing Users, Test Cases, Test Sets, Test Runs, Issues, Requirements and Attachments from PractiTest into SpiraPlan.
"},{"location":"Migration-and-Integration/Migrating-from-PractiTest/#installing-the-practitest-migration-tool","title":"Installing the PractiTest Migration Tool","text":"This section outlines how to install the migration tool for PractiTest onto a workstation so that you can then migrate whole projects from PractiTest to SpiraTest/SpiraTeam/SpiraPlan (SpiraPlan). It assumes that you already have a working installation of SpiraPlan v5.0 or later and a live instance of PractiTest to migrate from. If you have an earlier version of SpiraPlan you will need to upgrade to at least v5.0 before trying to migrate projects.
The Windows installation package can be downloaded from the \"Add-Ons & Downloads\" section of the Inflectra website. Double-click the package to begin the installation wizard. The wizard should display the following welcome page:
Click the Next button to choose the folder to install the migration tool to:
Choose the folder to install to, and then decide whether the application should be accessible by all users on the workstation or just the current user. Then, click Next. It will confirm if you want to proceed, click Next then wait for it to finish.
Now that you have installed the migration tool, you can launch it at any time by going to Start > Programs > Inflectra > SpiraPlan > Tools > PractiTest Importer. This will launch the migration tool application itself:
The first thing you need to do is to enter the user email for the instance of PractiTest that you want to import the information from, together with a valid API Token (provided under Account Settings on Practitest).
Once you have entered this information, click Authenticate and the list of projects will be populated. Select the PractiTest project you want to import from. You can also choose to not import certain artifacts from PractiTest (e.g. Issues, etc.) then click the Next button to move to the next page in the import wizard:
This page allows you to enter the URL, user name and password to access SpiraPlan that you want to import to. Enter the information and click Login. Typically, the URL is of the form (https://xxxx.spiraservice.net). The version of the importer being used must be compatible with the version of SpiraPlan you're importing into; if not you will receive an error message.
Assuming that the login was successful, click the Start Import button to actually begin the process of importing the various artifacts from PractiTest into SpiraPlan. Note that the importer will automatically create a new product in SpiraPlan to hold all the artifacts with the same name as that used in PractiTest. Note: if you run the importer on the same PractiTest project multiple times, it will create a new product in SpiraPlan each time.
During the import process, as each of the types of artifact are imported, the progress display will change (as illustrated above). Once the import has finished, you will receive a message to that effect and the Done button will be enabled. Click this button to close the importer. You can now log into SpiraPlan to view the imported project.
The migration tool will import the following artifacts from PractiTest:
If the Import Fails
In case the import fail for any reason, there will be a log file created on the Desktop of the computer doing the import. The filename is usually: Spira_PractiTest_Import.log . Please send this file to our support team if help is needed.
Importing Attachments
Because of a limitation in PractiTest, attachments can only be migrated from PractiTest after a delay of a certain number of seconds. So if you have 10 attachments, the migration tool will have to wait 5 seconds, for example, before importing each attachment. There is a user configurable delay in seconds that you can set for attachments. If the import fails because of attachments, try increasing this delay.
Due to a PractiTest limitation, if importing attachments, expect the process to take a few extra seconds per attachment. Note that this process may still result in an error because of limitations in the PractiTest API.\u00a0\u21a9
This feature is not currently available because of missing API calls in PractiTest. Hopefully it will be available in a future PractiTest update\u00a0\u21a9
This section outlines how to use the free Migration Tool for importing Projects, Test Suites, Test Cases, and Test Steps from the open source TestLink application into SpiraTest.
"},{"location":"Migration-and-Integration/Migrating-from-TestLink/#installing-the-testlink-migration-tool","title":"Installing the TestLink Migration Tool","text":"This section outlines how to install the migration tool for TestLink onto a workstation so that you can then migrate whole projects from TestLink to either SpiraTest, SpiraTeam or SpiraPlan (hereafter referred to as SpiraTest). It assumes that you already have a working installation of SpiraTest v5.0 or later and a live instance of TestLink to migrate from. If you have an earlier version of SpiraTest you will need to upgrade to at least v5.0 before trying to migrate projects.
The Windows installation package can be downloaded from the 'Add-Ons & Downloads\" section of the Inflectra website. Once you have obtained the Windows Installer package, simply double-click on the package to begin the installation wizard which should display the following welcome page:
Click the <Next> button, accept the software license, then click <Next> again to choose the folder to install the migration tool to:
Choose the folder to install to, and then decide whether the application should be accessible by all users on the workstation or just the current user. Then click the <Install> button to start the installation process. It will confirm if you want to proceed, click <Next> then wait for it to finish.
"},{"location":"Migration-and-Integration/Migrating-from-TestLink/#using-the-testlink-migration-tool","title":"Using the TestLink Migration Tool","text":"Now that you have installed the migration tool, you can launch it at any time by going to Start > Programs > Inflectra > SpiraTest > Tools > TestLink Importer. This will launch the migration tool application itself:
The first thing you need to do is to enter the URL for the instance of TestLink that you want to import the information from (typically of the form http://myserver/testlink) together with a valid API Key. If you don't have an API Key, you need to first login to TestLink using your normal username and password, then generate an API on the user profile page:
Once you have entered this information, click the <Authenticate> button and the list of projects will be populated. Select TestLink project that you want to import from then click the <Next> button to move to the next page in the import wizard:
This page allows you to enter the URL, user name and password that you want to use to access the instance of SpiraTest that you want to import to and click <Login>. Typically, the URL is of the form (https://xxxx.spiraservice.net). The version of the importer being used must be compatible with the version of SpiraTest you're importing into; if not you will receive an error message.
Assuming that the login was successful, click the <Start Import> button to actually begin the process of importing the various artifacts from TestLink into SpiraTest. Note that the importer will automatically create a new project in SpiraTest to hold all the artifacts with the same name as that used in TestLink.
During the import process, as each of the types of artifact are imported, the progress display will change (as illustrated above). Once the import has finished, you will receive a message to that effect and the <Done> button will be enabled. Clicking this button closed the importer. You should now log into SpiraTest using the same user name and password that was used for the import to view the imported project.
The migration tool will import the following artifacts from TestLink:
For example, the following TestLink project:
Now looks like this in SpiraTest (v5.4):
Should the import fail for any reason, there will be a log file created on the Desktop of the person doing the import. The filename is usually: Spira_TestLink_Import.log.
"},{"location":"Migration-and-Integration/Migrating-from-TestRail/","title":"Migrating from TestRail","text":"This section outlines how to use the free Migration Tool for importing Milestones, Test Cases, Test Suites, Test Plans, Test Runs, and Test Results from Gurock TestRail into SpiraTest.
"},{"location":"Migration-and-Integration/Migrating-from-TestRail/#installing-the-testrail-migration-tool","title":"Installing the TestRail Migration Tool","text":"This section outlines how to install the migration tool for TestRail onto a workstation so that you can then migrate whole projects from TestRail to either SpiraTest or SpiraTeam (hereafter referred to as SpiraTest). It assumes that you already have a working installation of SpiraTest v5.0 or later and a live instance of TestRail to migrate from. If you have an earlier version of SpiraTest you will need to upgrade to at least v5.0 before trying to migrate projects.
The Windows installation package can be downloaded from the 'Add-Ons & Downloads\" section of the Inflectra website. Once you have obtained the Windows Installer package, simply double-click on the package to begin the installation wizard which should display the following welcome page:
Click the <Next> button, accept the software license, then click <Next> again to choose the folder to install the migration tool to:
Choose the folder to install to, and then decide whether the application should be accessible by all users on the workstation or just the current user. Then click the <Install> button to start the installation process. It will confirm if you want to proceed, click <Next> then wait for it to finish.
"},{"location":"Migration-and-Integration/Migrating-from-TestRail/#using-the-testrail-migration-tool","title":"Using the TestRail Migration Tool","text":"Now that you have installed the migration tool, you can launch it at any time by going to Start > Programs > Inflectra > SpiraTest > Tools > TestRail Importer. This will launch the migration tool application itself:
The first thing you need to do is to enter the URL for the instance of TestRail that you want to import the information from (typically of the form https://xxxxx.testrail.net) together with a valid username and password.
Once you have entered this information, click the <Authenticate> button and the list of projects will be populated. Select TestRail project that you want to import from You can also choose to not import certain artifacts from TestRail (e.g. Milestones, etc.) then click the <Next> button to move to the next page in the import wizard:
This page allows you to enter the URL, user name and password that you want to use to access the instance of SpiraTest that you want to import to and click <Login>. Typically, the URL is of the form (https://xxxx.spiraservice.net). The version of the importer being used must be compatible with the version of SpiraTest you're importing into; if not you will receive an error message.
Assuming that the login was successful, click the <Start Import> button to actually begin the process of importing the various artifacts from TestRail into SpiraTest. Note that the importer will automatically create a new project in SpiraTest to hold all the artifacts with the same name as that used in TestRail.
During the import process, as each of the types of artifact are imported, the progress display will change (as illustrated above). Once the import has finished, you will receive a message to that effect and the <Done> button will be enabled. Clicking this button closed the importer. You should now log into SpiraTest using the same user name and password that was used for the import to view the imported project.
The migration tool will import the following artifacts from TestRail:
Should the import fail for any reason, there will be a log file created on the Desktop of the person doing the import. The filename is usually: Spira_TestRail_Import.log.
"},{"location":"Migration-and-Integration/Migrating-from-qTest/","title":"Migrating from qTest","text":"This section outlines how to use the free Migration Tool for importing Users, Test Cases, Test Sets, Test Runs, Defects, Releases, Requirements and Attachments from qTest into SpiraTest (or SpiraTeam, or SpiraPlan).
"},{"location":"Migration-and-Integration/Migrating-from-qTest/#installing-the-qtest-migration-tool","title":"Installing the qTest Migration Tool","text":"For the migration tool to work you need a working installation of SpiraTest/SpiraTeam/SpiraPlan v5.0 or later and a live instance of qTest to migrate from. You will also need a Windows machine to install the migration tool onto, that can access both SpiraPlan and qTest.
First, download the Windows installation package from the \"Add-Ons & Downloads\" section of the Inflectra website. Double-click the msi file to start the installation wizard. The first screen of this wizard will look like this:
Click the Next button to choose the folder to install the migration tool to:
Choose the folder to install to and then click Next. It will confirm if you want to proceed, click Next then wait for it to finish.
Now that you have installed the migration tool, you can launch it at any time by going to Start > Programs > Inflectra > SpiraTest > Tools > qTest Importer. This will launch the migration tool application itself:
First, enter the qTest information below and click Authenticate to verify your details (this will also retrieve the list of projects in qTest):
Next, select the qTest project that you want to import from. Now choose which artifacts you want to import from qTest (e.g. Defects, Requirements). NOTE: to import test cases, test sets, or test runs, the wizard needs to also import releases.
Click Next to move to the Connect to SpiraTest part of the import wizard:
On the Connect to SpiraTest page you have to enter your SpiraTest login information and click Login:
Once the wizard has verified its connection with SpiraTest and you are logged in, click the now enabled Start Import button. This begins the import process from qTest into SpiraPlan. The importer will automatically create a new product in SpiraPlan with the same name as that used in qTest. Note: if you run the importer on the same qTest project multiple times, it will create a new product in SpiraTest each time.
During the import process, as each artifact is imported, the progress display will change (as illustrated above). Once the import finishes the Done button will be enabled. Click this button to close the importer. You can now log into SpiraPlan to view the imported project.
The migration tool can import the following artifacts from qTest:
If the import fails
If the import fails for any reason, you will find a log file on the Desktop of the computer where the migration tool is installed. The filename will normally be \"Spira_qTest_Import.log\". Please send this file to our support team if help is needed.
"},{"location":"Migration-and-Integration/Project-Backup-and-Migration/","title":"Project Backup and Migration","text":"This application allows an entire project to be exported to a backup file, for archiving and offline storage of SpiraTeam projects. The base minimum SpiraTeam version required is 3.2 (014), and there is some data that is not backed up. Also there are separate versions of the backup and migration tool for SpiraTeam v3.2, v4.x and v5.x, and you need to use the appropriate version that matches your installations.
The migration tool does not support upgrading versions, i.e. you need to have the same version of SpiraTeam for both the import and export phase. If you have two different versions of SpiraTeam, you must first upgrade the older installation to the same version as the newer one.
"},{"location":"Migration-and-Integration/Project-Backup-and-Migration/#main-screen","title":"Main Screen","text":"When running the application, you will see the main screen, which gives you three main options: Export, Import, and Transfer:
"},{"location":"Migration-and-Integration/Project-Backup-and-Migration/#project-export","title":"Project Export","text":"Clicking the Export button will start the Export wizard, allowing you to save the project to a file.
On the first screen, enter in the SpiraTeam server URL, and the administrator account password. The administrator account must be used, so make sure that it is an active account (Active: Yes) in the application. When clicking the 'Next' button, it will verify the server and login information.
The second screen gives you the selection of the project to export. Select the project, and then click the 'Next' button.
On the third screen, select the location and name of the file you wish to export the project to. If the file already exists, it will be overwritten.
The next screen is the verification screen -- make sure you wish to start the export, and then click the 'Next' button. Once started, you cannot cancel or change any options. To change an option, click the 'Back' button at any time before starting the process to go back a screen.
Once finished, your output file will be created. You can store and backup the file as you need.
"},{"location":"Migration-and-Integration/Project-Backup-and-Migration/#project-import","title":"Project Import","text":"To import a project file into a new project in SpiraTeam, select the Import button on the main screen. This will start the Import wizard:
On the first screen, enter in the SpiraTeam server URL, and the administrator account password. The administrator account must be used, so make sure that it is an active account (Active: Yes) in the application. When clicking the 'Next' button, it will verify the server and login information.
The second screen allows you to enter in a name for the project created. You can enter in the name of an existing project, but a new project by that name will be created -- it will not import the project into an existing project.
The third screen is only present on the SpiraTeam v4.0 version of the migration tool. This is because the SpiraTeam 4.0 API requires that new user's be created with passwords of specific strength. Any user in the project file that is not present in the destination system will be created with the password that you specify:
You should enter a password, click the 'Test' button to make sure it will be accepted by SpiraTeam, and then click the 'Next' button. This will then display the fourth screen:
The fourth screen will let you select the PRJ Project file. Select the file by clicking on the folder button, and the application will verify the integrity of the file before performing the import:
The last screen will let you verify your settings before starting the import. If any changes need to be made, click the Back button. Once ready to import the project, click the 'Finish button to start the import.
If any error occurs during import, it's not recommended to use the project created in the application, although you can log in and view the data that was imported.
"},{"location":"Migration-and-Integration/Project-Backup-and-Migration/#project-transfer","title":"Project Transfer","text":"Selecting the 'Transfer' button will start the transfer wizard, which contains screens from both the Import and Export wizards, above.
The first two screens will let you select the SpiraTeam application to pull the project from, following the same information as the first two screens in the Export wizard.
The next three screens will ask for the new SpiraTeam application to create the project in and the default password for any new users that need to be created. These three screens follow the first three screens of the Import wizard, above. Note that the application will try to determine if you're trying to re-import the project into the same server, and advise that copying the project in the SpiraTeam UI is a better choice.
The final screen will provide a summary of the chosen settings. Once you click 'Next', the transfer process will start:
Once transfer starts, the entire project will be unloaded into a temporary directory on the computer running the application, and then the project will be imported into the new system.
"},{"location":"Migration-and-Integration/Project-Backup-and-Migration/#data-transferred","title":"Data Transferred","text":"SpiraTeam v3.2 Exported Imported Incidents \u2713 \u2713 Requirements \u2713 \u2713 Tasks \u2713 \u2713 Releases \u2713 \u2713 Test Cases \u2713 \u2713 Test Sets \u2713 \u2713 Test Runs \u2713 \u2713 Custom Properties \u2713 \u2713 Custom Lists \u2713 \u2713 Document Files \u2713 \u2713 Document Folders \u2713 \u2713 Document Types \u2713 Comments / Resolutions \u2713 \u2713 Datasync Mappings \u2713 Automation Hosts \u2713 \u2713 Automation Engines \u2713 \u2713 Project Roles \u2713 Project Users \u2713 \u27131The table on the left shows what data is backed up and restored. Future versions of the Migration tool and SpiraTeam may support exporting and importing more data.
The exported project file may be large, since the binary data of all the attachments are downloaded and contained within the file.
Once an export is completed, the migration tool will not delete the project from the system -- you must still do that through the UI. Any changes in the project will not automatically be updated in the export file; you must re-run the export.
Notes:
1Users imported back into v3.2 will be marked Active, even if they were originally inactive.
"},{"location":"RemoteLaunch-User-Guide/BadBoy/","title":"BadBoy","text":"Badboy is an automated website functional test automation system that lets you record website operations in Internet Explorer and generate test automation scripts that can be used to playback the test script against the website.
This section describes how you can use SpiraTest / SpiraTeam (hereafter SpiraTeam) together with RemoteLaunch to schedule and remotely launch instances of Badboy on different computers and have the testing results be transmitted back to SpiraTeam. This allows you to extend your SpiraTeam's test management capabilities to include automated Badboy tests.
Note: This integration requires at least version 3.0 of SpiraTest/Team and version 2.1 of Badboy.
"},{"location":"RemoteLaunch-User-Guide/BadBoy/#installing-the-badboy-engine","title":"Installing the Badboy Engine","text":"This section assumes that you already have a working installation of SpiraTest or SpiraTeam and have installed RemoteLaunch on the various test automation hosts following the instructions in RemoteLaunch Guide. Once those prerequisites are in place, please follow these steps:
Download and extract the BadboyAutomationEngine.zip file from the Inflectra website and locate the appropriate BadboyX.dll for the version of Badboy that you are using.
If you don't see the version listed, just use the nearest version that is lower than your current version.
Copy the file \"*Badboy*X.dll\" (where X is the appropriate version) into the \"extensions\" sub-folder of the RemoteLaunch installation.
Log in to SpiraTeam as a system administrator and go into SpiraTeam main Administration page and click on the \"Test Automation\" link under Integration.
Click the \"Add\" button to enter the new test automation engine details page. The fields required are as follows:
Name: This is the short display name of the automation engine. It can be anything that is meaningful to your users.
Description: This is the long description of the automation engine. It can be anything that is meaningful to your users. (Optional)
Active: If checked, the engine is active and able to be used for any project.
Token: This needs to be the assigned unique token for the automation engine and is used to tell RemoteLaunch which engine to actually use for a given test case. For Badboy this should be BadboyX where 'X' is the version number of the DLL file that you are using.
Once you have finished, click the \"Insert & Close\" button and you will be taken back to the Test Automation list page, with Badboy listed as an available automation engine.
You can modify the Badboy configuration for each of the specific automation hosts, by right-clicking on the RemoteLaunch icon in the system tray and choosing \"Configuration\". That will bring up the RemoteLaunch configuration page.
The Badboy 2.x engine adds its own tab to this page which allows you to configure how Badboy operates:
The following fields can be specified on this screen:
Trace Logging -- When selected, this will log additional trace and debugging information to the Windows Event Log. This should not be selected in a production environment.
"},{"location":"RemoteLaunch-User-Guide/BadBoy/#setting-up-the-automated-test-cases","title":"Setting up the Automated Test Cases","text":"This section describes the process for setting up a test case in SpiraTeam for automation and linking it to an automated Badboy test script.
First you need to display the list of test cases in SpiraTeam (by clicking Testing > Test Cases) and then add a new test case. Once you have added the new test case, click on it and select the \"Automation\" tab:
You need to enter the following fields:
Automation Engine - Choose the Badboy Automation Engine that you created in the previous section from the drop-down list.
Script Type -- This should be set to Linked as the integration with Badboy only supports referencing Badboy test script files and not physically uploading the test scripts into SpiraTeam.
Filename -- This needs to be the full path to the Badboy test script. To make this easier across different machines, you can use several constants for standard Windows locations (see example in screenshot):
[MyDocuments] -- The user's \"My Documents\" folder. The user indicated is the user that ran RemoteLaunch.
[CommonDocuments] -- The Public Document's folder.
[DesktopDirectory] -- The user's Desktop folder. The user indicated is the user that ran RemoteLaunch.
[ProgramFiles] -- Translated to the Program Files directory. For 64-bit machines, it's the 64-bit directory.
[ProgramFilesX86] -- Translated to the 32-bit Program Files directory.
Document Type -- This allows you to choose which document type the automated test script will be categorized under.
Document Folder --This allows you to choose which document folder the automated test script will be stored in.
Version -- The version of the test script (1.0 is used if no value specified)
Test Script -- This is not used with the Badboy Engine since it only supports linked test scripts.
Once you are happy with the values, click [Save] to update the test case. Now you are ready to schedule the automated test case for execution.
"},{"location":"RemoteLaunch-User-Guide/BadBoy/#using-parameterized-test-cases","title":"Using Parameterized Test Cases","text":"There is an advanced feature of SpiraTest/Team and RemoteLaunch that lets you pass parameters from SpiraTeam to your Badboy automated test script. This is very useful if you have a data-driven Badboy test script that defines input variables from an external data source.
To setup the automated test case for parameters, click on the \"Test Steps\" tab and click on \"Edit Parameters\":
The name of the parameter ${login} needs to match the name of the variable defined within the Badboy script in its variables configuration.
"},{"location":"RemoteLaunch-User-Guide/BadBoy/#executing-the-badboy-test-sets-from-spirateam","title":"Executing the Badboy Test Sets from SpiraTeam","text":"There are two ways to execute automated test cases in SpiraTeam:
Schedule the test cases to be executed on a specific computer (local or remote) at a date/time in the future
Execute the test cases right now on the local computer.
We shall outline both of these two scenarios in this section. However first we need to setup the appropriate automation hosts and test sets in SpiraTeam:
"},{"location":"RemoteLaunch-User-Guide/BadBoy/#configuring-the-automation-hosts-and-test-sets","title":"Configuring the Automation Hosts and Test Sets","text":"Go to Testing > Automation Hosts in SpiraTeam to display the list of automation hosts:
Make sure that you have created an Automation Host for each computer that is going to run an automated test case. The name and description can be set to anything meaningful, but the Token field must be set to the same token that is specified in the RemoteLaunch application on that specific machine.
Once you have at least one Automation Host configured, go to Testing > Test Sets to create the test sets that will contain the automated test case:
Note: Unlike manual test cases, automated test cases must be executed within a test set -- they cannot be executed directly from the test case.
Create a new Test Set to hold the Badboy automated test cases and click on its hyperlink to display the test set details page:
You need to add at least one automated test case to the test set and then configure the following fields:
Automation Host -- This needs to be set to the name of the automation host that will be running the automated test set.
Planned Date -- The date and time that you want the scenario to begin. (Note that multiple test sets scheduled at the exact same time will be scheduled by Test Set ID order.)
Status -- This needs to be set to \"Not Started\" for RemoteLaunch to pick up the scheduled test set. When you change the Planned Date, the status automatically switches back to \"Not Started\"
Type -- This needs to be set to \"Automated\" for automated testing
If you have parameterized test cases inside the automated test set you can set their values in three different ways:
Test Set Parameter Values -- this lets you set the same value of a parameter for all the test cases in the test set:
Test Case Parameter Values -- this lets you set a specific value for a parameter for a particular test case in the test set:
You set these values, by right-clicking on a row and choosing \"Edit Parameters\":
Once you have set the various test set fields (as described above), the Remote Launch instances will periodically poll SpiraTeam for new test sets. Once they retrieve the new test set, they will add it to their list of test sets to execute. Once execution begins they will change the status of the test set to \"In Progress\", and once test execution is done, the status of the test set will change to either \"Completed\" -- the automation engine could be launched and the test has completed -- or \"Blocked\" -- RemoteLaunch was not able to start the automation engine.
If you want to immediately execute the test case on your local computer, instead of setting the \"Automation Host\", \"Status\" and \"Planned Date\" fields, you can instead click the [Execute] icon on the test set itself. This will cause RemoteLaunch on the local computer to immediately start executing the current test set.
In either case, once all the test cases in the test set have been completed, the status of the test set will switch to \"Completed\" and the individual test cases in the set will display a status based on the results of the Badboy test:
Passed -- The Badboy automated test ran successfully and all the test steps in the test script passed and no assertions were thrown.
Failed -- The Badboy automated test ran successfully, but at least one test step failed or at least one assertion failed.
Caution -- The Badboy automated test run successfully, but at least one warning was logged in one of the test steps.
Blocked -- The Badboy automated test did not run successfully or at least one timeout error was recorded.
If you receive the \"Blocked\" status for either the test set or the test cases you should open up the Windows Application Event Log on the computer running RemoteLaunch and look in the event log for error messages.
Note: While the tests are executing you will see browser windows launch as Badboy executes the appropriate tests.
Once the tests have completed, you can log back into SpiraTeam and see the execution status of your test cases. If you click on a Test Run that was generated by Badboy, you will see the following information:
This screen indicates the status of the test run that was reported back from Badboy together with any messages or other information. The Test Name indicates the name of the test inside Badboy and the execution status corresponds the matching status inside Badboy as illustrated below:
Badboy Status SpiraTeam Status Succeeded Passed Failure Failed Warning Caution Assertion Failed Timeout BlockedIn addition, the detailed test report from Badboy is below. It will contain messages such as:
Suite: Test Suite 1
==============================================
Test: Test 3
---------------------------------- ------------
12 played, 12 succeeded, 0 failures, 0 assertions, 0 warnings, 0 timeouts ---------------------------------- ------------
Step: Step 2
---------------------------------- ------------
12 played, 12 succeeded, 0 failures, 0 assertions, 0 warnings, 0 timeouts ---------------------------------- ------------
Congratulations... You are now able to run Badboy automated functional tests and have the results be recorded within SpiraTest / SpiraTeam.
"},{"location":"RemoteLaunch-User-Guide/Command-Line/","title":"Command-Line","text":"In addition to the various pre-built plug-ins for different test automation engines, there is a generic command-line engine available that lets RemoteLaunch execute an arbitrary command-line program, capture the console output and send the output back to SpiraTeam as the test results. This is useful when you want to be able to use SpiraTeam to manage the scheduling and execution of automated testing using an in-house tool or a third-party tool that Inflectra has not yet built a plug-in for.
This section describes how you can use SpiraTest / SpiraTeam (hereafter SpiraTeam) together with RemoteLaunch to schedule and remotely launch instances of a command-line application on different computers and have the \"testing\" results be transmitted back to SpiraTeam. This allows you to extend your SpiraTeam's test management capabilities to include automation
Note: This integration requires at least version 4.0 of SpiraTest/Team and RemoteLaunch.
"},{"location":"RemoteLaunch-User-Guide/Command-Line/#installing-the-command-line-engine","title":"Installing the Command-Line Engine","text":"This section assumes that you already have a working installation of SpiraTest or SpiraTeam and have installed RemoteLaunch on the various test automation hosts following the instructions in RemoteLaunch Guide. Once those prerequisites are in place, please follow these steps:
Download and extract the CommandLineAutomationEngine.zip file from the Inflectra website and locate the CommandLine.dll
Copy the file \"CommandLine.dll\" into the \"extensions\" sub-folder of the RemoteLaunch installation.
Log in to SpiraTeam as a system administrator and go into SpiraTeam main Administration page and click on the \"Test Automation\" link under Integration.
Click the \"Add\" button to enter the new test automation engine details page. The fields required are as follows:
Name: This is the short display name of the automation engine. It can be anything that is meaningful to your users.
Description: This is the long description of the automation engine. It can be anything that is meaningful to your users. (Optional)
Active: If checked, the engine is active and able to be used for any project.
Token: This needs to be the assigned unique token for the automation engine and is used to tell RemoteLaunch which engine to actually use for a given test case. For Command-Line this should be simply \"CommandLine\".
Once you have finished, click the \"Insert & Close\" button and you will be taken back to the Test Automation list page, with Command-Line listed as an available automation engine.
You may need to modify the Command-Line configuration for some of the specific automation hosts, by right-clicking on the RemoteLaunch icon in the system tray and choosing \"Configuration\". That will bring up the RemoteLaunch configuration page. The Command-Line engine adds its own tab to this page which allows you to configure how the Command-Line engine operates:
The following fields can be specified on this screen:
RunAs Administrator -- This normally should not be checked. However if your automation tool requires Windows UAC elevation to operate, you will need to select this option. We recommend initially trying your tool with the value unchecked. Then, if you get an error message \"requires elevation\" in the test results you will need to select the option.
Log Results -- Normally the command-line engine will capture the output results from the command-line and send the results back to SpiraTeam as the test result. When you are executing a tool that directly integrates with SpiraTeam (e.g. a NUnit test suite that is already integrated with SpiraTeam) you don't want two different results to be sent back. In such a scenario, deselecting this option will prevent the command-line engine from sending back its own test result.
Default Status -- This specifies the execution status that will be returned to SpiraTeam in the event that none of the regular expressions (Regex) specified match the results returned from the test application. By default, the system will return \"Passed\" if none of the other regular expressions match correctly.
Pass Regex -- This is the regular expression that is used to match a passed test result. By default the system will search for the phrase \"Pass\" in the test output and return a Passed status if the match is successful.
Fail Regex -- This is the regular expression that is used to match a failed test result. By default the system will search for the phrases \"Fail\", \"Error\" and \"Fatal\" in the test output and return a Fail status if any of the matches are successful.
Caution Regex -- This is the regular expression that is used to match a caution test result. By default the system will search for the phrases \"Warning\" and \"Caution\" in the test output and return a Caution status if any of the matches are successful.
Blocked Regex -- This is the regular expression that is used to match a blocked test result. By default the system will search for the phrase \"Blocked\" in the test output and return a Blocked status if the match is successful.
Test Regular Expressions -- This text box lets you enter in some sample text and see how the Command-Line extension would interpret it. Once you have entered in the text, click \"Test Regular Expression...\" and the system will display a popup message box letting you know what the outcome of such a test would be interpreted as:
This section describes the process for setting up a test case in SpiraTeam for automation and either linking it to an existing test script file or entering a test script directly into SpiraTeam.
"},{"location":"RemoteLaunch-User-Guide/Command-Line/#attaching-a-command-line-test-script","title":"Attaching a Command-Line Test Script","text":"First you need to display the list of test cases in SpiraTeam (by clicking Testing > Test Cases) and then add a new test case. Once you have added the new test case, click on it and select the \"Automation\" tab:
You need to enter the following fields:
Automation Engine - Choose the Command-Line Automation Engine that you created in the previous section from the drop-down list.
Script Type -- This should be set to Attached for this case
Filename -- This needs to consist of the following sections separated by a pipe (|) character:
The full path to the command-line tool. To make this easier across different machines, you can use several constants for standard Windows locations:
[MyDocuments] -- The user's \"My Documents\" folder. The user indicated is the user that ran RemoteLaunch.
[CommonDocuments] -- The Public Document's folder.
[DesktopDirectory] -- The user's Desktop folder. The user indicated is the user that ran RemoteLaunch.
[ProgramFiles] -- Translated to the Program Files directory. For 64-bit machines, it's the 64-bit directory.
[ProgramFilesX86] -- Translated to the 32-bit Program Files directory.
Any arguments for the command-line tool, with the filename specified as {filename}. This special token will be replaced by the actual filename of the test script when RemoteLaunch downloads it from SpiraTeam. In addition, you can use the following additional tokens for some of the special SpiraTeam ID values:
[TestCaseId] -- the ID of the test case
[TestSetId] -- the ID of the test set
[ReleaseId] -- the ID of the release (if specified)
[ProjectId] -- the ID of the project
An example filename would be: C:\\Temp\\TestApp.exe|-arg1 -arg2 \"-arg3={filename}\"|
Document Type -- If using SpiraTeam (not SpiraTest) you can choose which document type the automated test script will be categorized under.
Document Folder -- If using SpiraTeam (not SpiraTest) you can choose which document folder the automated test script will be stored in.
Version -- The version of the test script (1.0 is used if no value specified)
Test Script -- This needs to contain the complete test script in whatever language and syntax is being expected by the command-line application
If you would like to have SpiraTeam pass any parameter values to this test script (this will be discussed in more detail later) you can specify them by using the syntax ${parameterName} inside the test script.
Once you are happy with the values, click [Save] to update the test case. Now you are ready to schedule the automated test case for execution.
"},{"location":"RemoteLaunch-User-Guide/Command-Line/#linking-a-command-line-test-script","title":"Linking a Command-Line Test Script","text":"First you need to display the list of test cases in SpiraTeam (by clicking Testing > Test Cases) and then add a new test case. Once you have added the new test case, click on it and select the \"Automation\" tab:
You need to enter the following fields:
Automation Engine - Choose the Command-Line Automation Engine that you created in the previous section from the drop-down list.
Script Type -- This should be set to Linked for this case
Filename -- This needs to consist of the following sections separated by a pipe (|) character:
The full path to the command-line tool. To make this easier across different machines, you can use several constants for standard Windows locations:
[MyDocuments] -- The user's \"My Documents\" folder. The user indicated is the user that ran RemoteLaunch.
[CommonDocuments] -- The Public Document's folder.
[DesktopDirectory] -- The user's Desktop folder. The user indicated is the user that ran RemoteLaunch.
[ProgramFiles] -- Translated to the Program Files directory. For 64-bit machines, it's the 64-bit directory.
[ProgramFilesX86] -- Translated to the 32-bit Program Files directory.
Any arguments for the command-line tool, including the filepath of the test script file that the command-line tool will be executing. In addition, you can use the following additional tokens for some of the special SpiraTeam ID values:
[TestCaseId] -- the ID of the test case
[TestSetId] -- the ID of the test set
[ReleaseId] -- the ID of the release (if specified)
[ProjectId] -- the ID of the project
The mask for converting any parameter values from SpiraTeam into valid command line arguments. If parameters are not accepted by the command-line tool, you can leave this section out.
The mask can include any symbols together with \"name\" to refer to the parameter name and \"value\" to refer to the parameter value.
Example 1: If you want parameters to provided in the form: -param1=value1 --param2=value2 you would use the following mask: -name=value
Example 2: If you want parameters to provided in the form: /param1:value1 /param2:value2 you would use the following mask: /name:value
An example filename would be: C:\\Temp\\TestApp.exe|-arg1 -arg2|-name=value
Document Type -- If using SpiraTeam (not SpiraTest) you can choose which document type the automated test script will be categorized under.
Document Folder -- If using SpiraTeam (not SpiraTest) you can choose which document folder the automated test script will be stored in.
Version -- The version of the test script (1.0 is used if no value specified)
Test Script -- This is not used when you are using the linked test script option
Once you are happy with the values, click [Save] to update the test case. Now you are ready to schedule the automated test case for execution.
"},{"location":"RemoteLaunch-User-Guide/Command-Line/#using-parameterized-test-cases","title":"Using Parameterized Test Cases","text":"There is an advanced feature of SpiraTest/Team and RemoteLaunch that lets you pass parameters from SpiraTeam to your command-line automated testing tool. This is very useful if you want to have a data-driven test script that be executed multiple times with different parameter values.
To setup the automated test case for parameters, click on the \"Edit Parameters\" hyperlink above the \"Test Script\" box:
The name of the parameter ${login} needs to match the name of a parameter accepted by the command-line tool.
"},{"location":"RemoteLaunch-User-Guide/Command-Line/#executing-the-command-line-test-sets-from-spirateam","title":"Executing the Command-Line Test Sets from SpiraTeam","text":"There are two ways to execute automated test cases in SpiraTeam:
Schedule the test cases to be executed on a specific computer (local or remote) at a date/time in the future
Execute the test cases right now on the local computer.
We shall outline both of these two scenarios in this section. However first we need to setup the appropriate automation hosts and test sets in SpiraTeam:
"},{"location":"RemoteLaunch-User-Guide/Command-Line/#configuring-the-automation-hosts-and-test-sets","title":"Configuring the Automation Hosts and Test Sets","text":"Go to Testing > Automation Hosts in SpiraTeam to display the list of automation hosts:
Make sure that you have created an Automation Host for each computer that is going to run an automated test case. The name and description can be set to anything meaningful, but the Token field must be set to the same token that is specified in the RemoteLaunch application on that specific machine.
Once you have at least one Automation Host configured, go to Testing > Test Sets to create the test sets that will contain the automated test case:
Note: Unlike manual test cases, automated test cases must be executed within a test set -- they cannot be executed directly from the test case.
Create a new Test Set to hold the Command-Line automated test cases and click on its hyperlink to display the test set details page:
You need to add at least one automated test case to the test set and then configure the following fields:
Automation Host -- This needs to be set to the name of the automation host that will be running the automated test set.
Planned Date -- The date and time that you want the scenario to begin. (Note that multiple test sets scheduled at the exact same time will be scheduled by Test Set ID order.)
Status -- This needs to be set to \"Not Started\" for RemoteLaunch to pick up the scheduled test set. When you change the Planned Date, the status automatically switches back to \"Not Started\"
Type -- This needs to be set to \"Automated\" for automated testing
If you have parameterized test cases inside the automated test set you can set their values in three different ways:
Test Set Parameter Values -- this lets you set the same value of a parameter for all the test cases in the test set:
Test Case Parameter Values -- this lets you set a specific value for a parameter for a particular test case in the test set:
You set these values, by right-clicking on a row and choosing \"Edit Parameters\":
Once you have set the various test set fields (as described above), the Remote Launch instances will periodically poll SpiraTeam for new test sets. Once they retrieve the new test set, they will add it to their list of test sets to execute. Once execution begins they will change the status of the test set to \"In Progress\", and once test execution is done, the status of the test set will change to either \"Completed\" -- the automation engine could be launched and the test has completed -- or \"Blocked\" -- RemoteLaunch was not able to start the automation engine.
If you want to immediately execute the test case on your local computer, instead of setting the \"Automation Host\", \"Status\" and \"Planned Date\" fields, you can instead click the [Execute] icon on the test set itself. This will cause RemoteLaunch on the local computer to immediately start executing the current test set.
In either case, once all the test cases in the test set have been completed, the status of the test set will switch to \"Completed\" and the individual test cases in the set will display a status based on the results of the command-line test:
Passed -- The automated test ran successfully and the results output to the console did not include any of the phrases -- FAIL, ERROR, FATAL, WARNING, CAUTION
Failed -- The automated test ran successfully, but one of the phrases -- FAIL, ERROR, FATAL -- was included in the console output
Caution -- The automated test ran successfully, but one of the phrases -- WARNING, CAUTION -- was included in the console output
Blocked -- The automated test did not run successfully
If you receive the \"Blocked\" status for either the test set or the test cases you should open up the Windows Application Event Log on the computer running RemoteLaunch and look in the event log for error messages.
Note: While the tests are executing you may see application windows launch as the command-line tool server executes the appropriate tests.
Once the tests have completed, you can log back into SpiraTeam and see the execution status of your test cases. If you click on a Test Run that was generated by the command-line tool, you will see the following information:
This screen indicates the status of the test run that was reported back from command-line tool together with any messages or other information. The execution status will be set according to the rules described above, the Message field will contain the first line of console output and the large details box will contain the full console output from the command-line tool.
Congratulations... You are now able to run a custom command-line run tests and have the results be recorded within SpiraTest / SpiraTeam.
"},{"location":"RemoteLaunch-User-Guide/Eggplant/","title":"Eggplant DAI","text":"Eggplant Digital Automation Intelligence (DAI) is a functional test automation system. Eggplant uses a command-line tool to allow users to more easily triggering automated tests remotely. RemoteLaunch's dedicated Eggplant engine uses this command-line tool to run automated tests in Eggplant, once triggered for a SpiraPlan test set. RemoteLaunch's Eggplant engine reports the results of the output from Eggplant back to SpiraPlan as test run results.
This page describes how you can use SpiraTest, SpiraTeam, or SpiraPlan (hereafter SpiraPlan) together with RemoteLaunch to schedule and remotely launch Eggplant DAI tests and have the results transmitted back to SpiraPlan. This allows you to extend your SpiraPlan's test management capabilities to include automation.
Note: This integration requires at least: SpiraTest/Team v4.0, RemoteLaunch, and Eggplant DAI v6.2.
"},{"location":"RemoteLaunch-User-Guide/Eggplant/#installing-the-eggplant-engine","title":"Installing the Eggplant Engine","text":"This section assumes that you already have a working installation of SpiraPlan and of RemoteLaunch as described here. Once these prerequisites are in place, please follow these steps:
Click the \"Add\" button to enter the new test automation engine details page. The fields required are as follows:
You can modify the Eggplant DAI configuration for each of the specific automation hosts, by right-clicking on the RemoteLaunch icon in the system tray and choosing \"Configuration\". That will bring up the RemoteLaunch configuration page.
The Eggplant DAI engine adds its own tab to this page which allows you to configure how it operates:
The following fields can be specified on this screen:
This section describes the process for setting up a test case in SpiraPlan for automation and either linking it to a command that triggers Eggplant DAI remote execution.
"},{"location":"RemoteLaunch-User-Guide/Eggplant/#attaching-a-command-line-test-script","title":"Attaching a Command-Line Test Script","text":"First, you need to display the list of test cases in SpiraPlan (by clicking Testing > Test Cases) and then add a new test case. Once you have added the new test case, click on it and select the \"Automation\" tab:
You need to enter the following fields:
Filename: This needs to consist of the following sections separated by a pipe (|) character:
The full path to the Eggplant command-line runner tool. To make this easier across different machines, you can use several constants for standard Windows locations:
The Eggplant Client Secret number and the Eggplant Client Id, separated by a comma (,)
The Eggplant Test Configuration ID number to associate with this Spira Test Case
An example of filename would be: C:\\Users\\eggplant-runner-Windows-6.1.2-1.exe|umthdbvwiuy76bXStxzL,32584136987|https://mycompany.dai.eggplant.cloud|15d0d5e8-c3frt-8541-v5t9-d423760925f2
Document Type: If using SpiraPlan (not SpiraTest) you can choose which document type the automated test script will be categorized under.
Once you are happy with the values, click [Save] to update the test case. Now you are ready to schedule the automated test case for execution.
"},{"location":"RemoteLaunch-User-Guide/Eggplant/#executing-the-test-sets-from-spiraplan","title":"Executing the Test Sets from SpiraPlan","text":"There are two ways to execute automated test cases in SpiraPlan:
We shall outline both of these two scenarios in this section. However, first we need to setup the appropriate automation hosts and test sets in SpiraPlan:
"},{"location":"RemoteLaunch-User-Guide/Eggplant/#configuring-the-automation-hosts-and-test-sets","title":"Configuring the Automation Hosts and Test Sets","text":"Go to Testing > Automation Hosts in SpiraPlan to display the list of automation hosts:
Make sure that you have created an Automation Host for each computer that is going to run an automated test case. The name and description can be set to anything meaningful, but the Token field must be set to the same token that is specified in the RemoteLaunch application on that specific machine.
Once you have at least one Automation Host configured, go to Testing > Test Sets to create the test sets that will contain the automated test case.
Note: Unlike manual test cases, automated test cases must be executed within a test set -- they cannot be executed directly from the test case.
Create a new Test Set to hold the Eggplant automated test cases and click on its hyperlink to display the test set details page:
You need to add at least one automated test case to the test set and then configure the following fields:
Once you have set the various test set fields (as described above), the RemoteLaunch instances will periodically poll SpiraPlan for new test sets. Once they retrieve the new test set, they will add it to their list of test sets to execute. Once execution begins they will change the status of the test set to \"In Progress\", and once test execution is done, the status of the test set will change to either \"Completed\" -- the automation engine could be launched and the test has completed -- or \"Blocked\" -- RemoteLaunch was not able to start the automation engine. If you want to immediately execute the test case on your local computer, instead of setting the \"Automation Host\", \"Status\" and \"Planned Date\" fields, you can instead click the [Execute] icon on the test set itself. This will cause RemoteLaunch on the local computer to immediately start executing the current test set.
In either case, once all the test cases in the test set have been completed, the status of the test set will switch to \"Completed\" and the individual test cases in the set will display a status based on the results of the Eggplant test:
If you receive the \"Blocked\" status for either the test set or the test cases you should open up the Windows Application Event Log on the computer running RemoteLaunch and look in the event log for error messages.
Note: While the tests are executing you may see application windows launch as the command-line tool server executes the appropriate tests. Please do not close them.
Once the tests have been completed, you can log back into SpiraPlan and see the execution status of your test cases. If you click on a Test Run that was generated by the command-line tool, you will see the following information:
This screen indicates the status of the test run that was reported back from the engine together with any messages or other information. The execution status will be set according to the rules described above, the Message field will contain a weblink for the detailed online results at Eggplant and the large details box will contain the full console output from the Eggplant command-line tool.
Congratulations! You are now able to run the Eggplant automated tests and have the results recorded within SpiraTest / SpiraPlan.
"},{"location":"RemoteLaunch-User-Guide/FitNesse/","title":"FitNesse","text":"FitNesse is a lightweight, open-source automated software testing framework that uses web-based Wikis to define the inputs and expected results from different combinations of input values and then compare the results with what is actually generated during testing. For more details on FitNesse, please refer to the FitNesse website: http://fitnesse.org
This section describes how you can use SpiraTest / SpiraTeam (hereafter SpiraTeam) together with RemoteLaunch to schedule and remotely launch instances of FitNesse on different computers and have the testing results be transmitted back to SpiraTeam. This allows you to extend your SpiraTeam's test management capabilities to include automated FitNesse acceptance tests.
Note: This integration requires at least version 4.0 of SpiraTest/Team and RemoteLaunch.
"},{"location":"RemoteLaunch-User-Guide/FitNesse/#installing-the-fitnesse-engine","title":"Installing the FitNesse Engine","text":"This section assumes that you already have a working installation of SpiraTest or SpiraTeam and have installed RemoteLaunch on the various test automation hosts following the instructions in RemoteLaunch Guide. Once those prerequisites are in place, please follow these steps:
Download and extract the FitNesseEngine.zip file from the Inflectra website and c*opy the file \"FitNesseEngine.dll\" into the \"extensions\" sub-folder of the RemoteLaunch installation.*
You may also need to verify that you have the full Microsoft .NET Framework 4.0 installed since that is needed by the FitNesse engine. RemoteLaunch itself only needs the .NET 4.0 Client Profile, so make sure you have the .NET 4.0 Framework Extended entry listed in the Program & Features section of the Windows Control Panel.
Log in to SpiraTeam as a system administrator and go into SpiraTeam main Administration page and click on the \"Test Automation\" link under Integration.
Click the \"Add\" button to enter the new test automation engine details page. The fields required are as follows:
Name: This is the short display name of the automation engine. It can be anything that is meaningful to your users.
Description: This is the long description of the automation engine. It can be anything that is meaningful to your users. (Optional)
Active: If checked, the engine is active and able to be used for any project.
Token: This needs to be the assigned unique token for the automation engine and is used to tell RemoteLaunch which engine to actually use for a given test case. For FitNesse this should be simply FitNesse.
Once you have finished, click the \"Insert & Close\" button and you will be taken back to the Test Automation list page, with FitNesse listed as an available automation engine.
You can modify the FitNesse configuration for each of the specific automation hosts, by right-clicking on the RemoteLaunch icon in the system tray and choosing \"Configuration\". That will bring up the RemoteLaunch configuration page. The FitNesse engine adds its own tab to this page which allows you to configure how FitNesse operates:
The following fields can be specified on this screen:
Server Host -- This should be the base URL for accessing the installation of FitNesse. Each of the FitNesse test cases will be a URL relative to this base URL.
Server Port -- This should be set to the TCP port that the FitNesse web server uses for displaying the FitNesse wiki web pages.
FitNesse Timeout -- This allows you to extend the timeout for executing FitNesse tests. This is useful if you find that the FitNesse tests take a long time to execute and RemoteLaunch is aborting the execution before they are finished.
"},{"location":"RemoteLaunch-User-Guide/FitNesse/#setting-up-the-automated-test-cases","title":"Setting up the Automated Test Cases","text":"This section describes the process for setting up a test case in SpiraTeam for automation and linking it to an existing FitNesse test case wiki page. Note: The FitNesse automation engine only supports Linked test scripts in SpiraTeam (not Attached).
First you need to display the list of test cases in SpiraTeam (by clicking Testing > Test Cases) and then add a new test case. Once you have added the new test case, click on it and go to the \"Automation\" section located in the \"Overview\" tab:
You need to enter the following fields:
Automation Engine - Choose the FitNesse Automation Engine that you created in the previous section from the drop-down list.
Script Type -- This should be set to Linked for FitNesse tests.
Filename -- This needs to be the relative URL of the FitNesse test case. I.e. if the FitNesse URL is http://myserver/FitNesse.UserGuide.TwoMinuteExample and the base URL setup in RemoteLaunch is http://myserver then the \"filename\" would be just FitNesse.UserGuide.TwoMinuteExample.
Document Type -- You can choose which document type the automated test script will be categorized under.
Document Folder -- You can choose which document folder the automated test script will be stored in.
Version -- The version of the test script (1.0 is used if no value specified)
Test Script -- This is not used when you are using the linked test script option
Once you are happy with the values, click [Save] to update the test case. Now you are ready to schedule the automated test case for execution.
"},{"location":"RemoteLaunch-User-Guide/FitNesse/#using-parameterized-test-cases","title":"Using Parameterized Test Cases","text":"The FitNesse automation engine does not currently support the passing of parameter values from SpiraTeam to the FitNesse test.
"},{"location":"RemoteLaunch-User-Guide/FitNesse/#executing-the-fitnesse-test-sets-from-spirateam","title":"Executing the FitNesse Test Sets from SpiraTeam","text":"There are three ways to execute automated test cases in SpiraTeam:
Schedule the test cases to be executed on a specific computer (local or remote) at a date/time in the future
Execute the test cases right now on the local computer.
Execute the test cases from the command-line or a build script
We shall outline each of these three scenarios in this section. However first we need to setup the appropriate automation hosts and test sets in SpiraTeam:
"},{"location":"RemoteLaunch-User-Guide/FitNesse/#configuring-the-automation-hosts-and-test-sets","title":"Configuring the Automation Hosts and Test Sets","text":"Go to Testing > Automation Hosts in SpiraTeam to display the list of automation hosts:
Make sure that you have created an Automation Host for each computer that is going to run an automated test case. The name and description can be set to anything meaningful, but the Token field must be set to the same token that is specified in the RemoteLaunch application on that specific machine.
Once you have at least one Automation Host configured, go to Testing > Test Sets to create the test sets that will contain the automated test case:
Note: Unlike manual test cases, automated test cases must be executed within a test set -- they cannot be executed directly from the test case.
Create a new Test Set to hold the FitNesse automated test cases and click on its hyperlink to display the test set details page:
You need to add at least one automated test case to the test set and then configure the following fields:
Automation Host -- This needs to be set to the name of the automation host that will be running the automated test set.
Planned Date -- The date and time that you want the scenario to begin. (Note that multiple test sets scheduled at the exact same time will be scheduled by Test Set ID order.)
Status -- This needs to be set to \"Not Started\" for RemoteLaunch to pick up the scheduled test set. When you change the Planned Date, the status automatically switches back to \"Not Started\"
Type -- This needs to be set to \"Automated\" for automated testing
Once you have set the various test set fields (as described above), the Remote Launch instances will periodically poll SpiraTeam for new test sets. Once they retrieve the new test set, they will add it to their list of test sets to be executed. Once execution begins they will change the status of the test set to \"In Progress\", and once test execution is done, the status of the test set will change to either \"Completed\" -- the automation engine could be launched and the test has completed -- or \"Blocked\" -- RemoteLaunch was not able to start the automation engine.
If you want to immediately execute the test case on your local computer, instead of setting the \"Automation Host\", \"Status\" and \"Planned Date\" fields, you can instead click the [Execute] icon on the test set itself. This will cause RemoteLaunch on the local computer to immediately start executing the current test set.
In either case, once all the test cases in the test set have been completed, the status of the test set will switch to \"Completed\" and the individual test cases in the set will display a status based on the results of the FitNesse test:
Passed -- The FitNesse automated test ran successfully and all the test conditions in the test script passed
Failed -- The FitNesse automated test ran successfully, but at least one test condition in the test script failed.
Blocked -- The FitNesse automated test did not run successfully
If you receive the \"Blocked\" status for either the test set or the test cases you should open up the Windows Application Event Log on the computer running RemoteLaunch and look in the event log for error messages.
Note: While the tests are executing you may see command windows appear as the FitNesse server executes the appropriate tests.
Once the tests have completed, you can log back into SpiraTeam and see the execution status of your test cases. If you click on a Test Run that was generated by FitNesse, you will see the following information:
This screen indicates the status of the test run that was reported back from FitNesse together with any messages or other information. The execution status will be set to PASSED if all the FitNesse rows report back OK and all the tests passed. If any of the rows failed or the tests don't pass, the overall execution status will be listed as FAILED.
You can see a step-by-step record of what happened by scrolling down to the \"Test Steps\" section:
In addition, you can scroll down to the \"Console Output\" section to get the FitNesse specific information:
The Message field will contain a summary of the number of tests executed and the number of wrong results and exceptions. The large details box contains the full command execution log as reported back from FitNesse:
Congratulations... You are now able to run FitNesse automated acceptance tests and have the results be recorded within SpiraTest / SpiraTeam.
"},{"location":"RemoteLaunch-User-Guide/HP-UFT--QTP/","title":"HP UFT / QTP","text":"HP\u00ae QuickTest Professional\u00ae (hereafter QTP) is an automated functional test automation system that lets you record application operations and generate VBA test automation scripts that can be used to playback the test script against the test application.
HP\u00ae Unified Functional Testing\u00ae (hereafter UFT) is an updated version of QTP that also includes functionality for web service testing.
This section describes how you can use SpiraTest / SpiraTeam (hereafter SpiraTeam) together with RemoteLaunch to schedule and remotely launch instances of QTP and UFT on different computers and have the testing results be transmitted back to SpiraTeam. This allows you to extend your SpiraTeam's test management capabilities to include automated QTP and UFT tests.
Note: This integration requires at least version 3.0 of SpiraTest/Team and version 9.0 of Quick Test Professional. For accessing UFT, you'd need at least version 4.0 of SpiraTest/Team and version 11.0 of UFT.
"},{"location":"RemoteLaunch-User-Guide/HP-UFT--QTP/#installing-the-uftqtp-engine","title":"Installing the UFT/QTP Engine","text":"This section assumes that you already have a working installation of SpiraTest or SpiraTeam and have installed RemoteLaunch on the various test automation hosts following the instructions in RemoteLaunch Guide. Once those prerequisites are in place, please follow these steps:
Download and extract the QuickTestProAutomationEngine.zip file from the Inflectra website and locate the appropriate QuickTestProX.dll or UftX.dll for the version of QTP or UFT that you are using.
If you don't see the version listed, just use the nearest version that is lower than your current version.
Copy the file \"QuickTestProX.dll\" or \"UftX.dll\" (where X is the appropriate version) into the \"extensions\" sub-folder of the RemoteLaunch installation.
Log in to SpiraTeam as a system administrator and go into SpiraTeam main Administration page and click on the \"Test Automation\" link under Integration.
Click the \"Add\" button to enter the new test automation engine details page. The fields required are as follows:
This section describes the process for setting up a test case in SpiraTeam for automation and linking it to an automated QTP or UFT test script.
First you need to display the list of test cases in SpiraTeam (by clicking Testing > Test Cases) and then add a new test case. Once you have added the new test case, click on it and select the \"Overview\" tab and scroll down to the 'Automation' section:
You need to enter the following fields:
Automation Engine - Choose the QTP/UFT Automation Engine that you created in the previous section from the drop-down list.
Script Type -- This should be set to Linked as the integration with QTP/UFT only supports referencing QTP/UFT test script folder paths and not physically uploading the test scripts into SpiraTeam.
Filename -- This needs to be the full path to the QTP/UFT test script folder (i.e. the folder that you open in QTP/UFT to run the test). To make this easier across different machines, you can use several constants for standard Windows locations (see example in screenshot):
[MyDocuments] -- The user's \"My Documents\" folder. The user indicated is the user that ran RemoteLaunch.
[CommonDocuments] -- The Public Document's folder.
[DesktopDirectory] -- The user's Desktop folder. The user indicated is the user that ran RemoteLaunch.
[ProgramFiles] -- Translated to the Program Files directory. For 64-bit machines, it's the 64-bit directory.
[ProgramFilesX86] -- Translated to the 32-bit Program Files directory.
Document Type -- If using SpiraTeam (not SpiraTest) you can choose which document type the automated test script will be categorized under.
Document Folder -- If using SpiraTeam (not SpiraTest) you can choose which document folder the automated test script will be stored in.
Version -- The version of the test script (1.0 is used if no value specified)
Test Script -- This is not used with the QTP/UFT Engine since it only supports linked test scripts.
Once you are happy with the values, click [Save] to update the test case. Now you are ready to schedule the automated test case for execution.
"},{"location":"RemoteLaunch-User-Guide/HP-UFT--QTP/#using-parameterized-test-cases","title":"Using Parameterized Test Cases","text":"There is an advanced feature of SpiraTest/Team and RemoteLaunch that lets you pass parameters from SpiraTeam to your QTP/UFT automated test script. This is very useful if you have a data-driven QTP/UFT test script that accepts input parameters from an external data source.
To setup the automated test case for parameters, click on the \"Test Steps\" tab and click on \"Edit Parameters\":
The name of the parameter ${login} needs to match the name of the input parameter defined within the QTP/UFT script in its input parameters configuration.
"},{"location":"RemoteLaunch-User-Guide/HP-UFT--QTP/#executing-the-qtpuft-test-sets-from-spirateam","title":"Executing the QTP/UFT Test Sets from SpiraTeam","text":"There are two ways to execute automated test cases in SpiraTeam:
Schedule the test cases to be executed on a specific computer (local or remote) at a date/time in the future
Execute the test cases right now on the local computer.
We shall outline both of these two scenarios in this section. However first we need to setup the appropriate automation hosts and test sets in SpiraTeam:
"},{"location":"RemoteLaunch-User-Guide/HP-UFT--QTP/#configuring-the-automation-hosts-and-test-sets","title":"Configuring the Automation Hosts and Test Sets","text":"Go to Testing > Automation Hosts in SpiraTeam to display the list of automation hosts:
Make sure that you have created an Automation Host for each computer that is going to run an automated test case. The name and description can be set to anything meaningful, but the Token field must be set to the same token that is specified in the RemoteLaunch application on that specific machine.
Once you have at least one Automation Host configured, go to Testing > Test Sets to create the test sets that will contain the automated test case:
Note: Unlike manual test cases, automated test cases must be executed within a test set -- they cannot be executed directly from the test case.
Create a new Test Set to hold the QTP/UFT automated test cases and click on its hyperlink to display the test set details page.
You need to add at least one automated test case to the test set:
Then configure the following fields:
Automation Host -- This needs to be set to the name of the automation host that will be running the automated test set.
Planned Date -- The date and time that you want the scenario to begin. (Note that multiple test sets scheduled at the exact same time will be scheduled by Test Set ID order.)
Status -- This needs to be set to \"Not Started\" for RemoteLaunch to pick up the scheduled test set. When you change the Planned Date, the status automatically switches back to \"Not Started\"
Type -- This needs to be set to \"Automated\" for automated testing
If you have parameterized test cases inside the automated test set you can set their values in three different ways:
Test Set Parameter Values -- this lets you set the same value of a parameter for all the test cases in the test set:
Test Case Parameter Values -- this lets you set a specific value for a parameter for a particular test case in the test set:
You set these values, by right-clicking on a row and choosing \"Edit Parameters\":
Once you have set the various test set fields (as described above), the Remote Launch instances will periodically poll SpiraTeam for new test sets. Once they retrieve the new test set, they will add it to their list of test sets to execute. Once execution begins they will change the status of the test set to \"In Progress\", and once test execution is done, the status of the test set will change to either \"Completed\" -- the automation engine could be launched and the test has completed -- or \"Blocked\" -- RemoteLaunch was not able to start the automation engine.
If you want to immediately execute the test case on your local computer, instead of setting the \"Automation Host\", \"Status\" and \"Planned Date\" fields, you can instead click the [Execute] icon on the test set itself. This will cause RemoteLaunch on the local computer to immediately start executing the current test set.
In either case, once all the test cases in the test set have been completed, the status of the test set will switch to \"Completed\" and the individual test cases in the set will display a status based on the results of the QTP/UFT test:
Passed -- The QTP/UFT automated test ran successfully and all the test conditions in the test script passed
Failed -- The QTP/UFT automated test ran successfully, but at least one test condition in the test script failed.
Blocked -- The QTP/UFT automated test did not run successfully
If you receive the \"Blocked\" status for either the test set or the test cases you should open up the Windows Application Event Log on the computer running RemoteLaunch and look in the event log for error messages.
Note: While the tests are executing you may see browser or application windows launch as QuickTest Pro (QTP) or Unified Functional Testing (UFT) executes the appropriate tests.
Once the tests have completed, you can log back into SpiraTeam and see the execution status of your test cases. If you click on a Test Run that was generated by QTP/UFT, you will see the following information:
This screen indicates the status of the test run that was reported back from QTP/UFT together with any messages or other information. The Test Name indicates the name of the test inside QTP/UFT, and the execution status corresponds the matching status inside QTP/UFT as illustrated below:
QTP/UFT Status SpiraTeam Status Passed Passed Failed Failed Warning Caution Stopped Blocked Not Applicable N/A (Any other status) Not RunIn addition, the detailed test report from QTP/UFT is below. It will contain messages such as:
QuickTest Professional
Test: Test1
Results Name: Res21
Run Started: 10/22/2010 - 11:49:06
Run Ended: 10/22/2010 - 11:49:10
Summary Results
======= =======
Passed: 0
Failed: 0
Warnings: 0
Detailed Results
======= =======
Iteration: 1
=============
Action: Log In To Flight
=============
Step: Login: Dialog
Step: Agent Name:.SetText: \"Bobba Fett\"
Step: Agent Name:.Type: \"<__MicTab>\"
Step: Password:.SetSecureText: \"4cc08e88683135b35bb8a7dab8442c69b8441f3e\"
Step: OK.Click:
Step: Flight Reservations: Dialog
Step: OK.Click:
Congratulations... You are now able to run QTP/UFT automated functional tests and have the results be recorded within SpiraTest / SpiraTeam.
"},{"location":"RemoteLaunch-User-Guide/JMeter/","title":"JMeter","text":"Apache JMeter is a free, open source Java desktop application designed to load test functional behavior and measure performance. It was originally designed for testing Web Applications but has since expanded to other test functions.
This section describes how you can use SpiraTest / SpiraTeam (hereafter SpiraTeam) together with RemoteLaunch to schedule and remotely launch instances of JMeter on different computers and have the testing results be transmitted back to SpiraTeam. This allows you to extend your SpiraTeam's test management capabilities to include automated JMeter performance tests.
Note: This integration requires at least version 3.0 of Spira (SpiraTest, SpiraTeam or SpiraPlan) and version 2.5 of JMeter.
"},{"location":"RemoteLaunch-User-Guide/JMeter/#installing-the-jmeter-engine","title":"Installing the JMeter Engine","text":"This section assumes that you already have a working installation of SpiraTest or SpiraTeam and have installed RemoteLaunch on the various test automation hosts following the instructions in RemoteLaunch Guide. Once those prerequisites are in place, please follow these steps:
Download and extract the JMeterEngine.zip file from the Inflectra website and locate the JMeter2.dll.
Copy the file JMeter2.dll into the extensions sub-folder of your RemoteLaunch installation.
Log in to SpiraTeam as a system administrator and go into SpiraTeam main Administration page and click on the \"Test Automation\" link under Integration.
Click the \"Add\" button to enter the new test automation engine details page. The fields required are as follows:
Name: This is the short display name of the automation engine. It can be anything that is meaningful to your users.
Description: This is the long description of the automation engine. It can be anything that is meaningful to your users. (Optional)
Active: If checked, the engine is active and able to be used for any project.
Token: This needs to be the assigned unique token for the automation engine and is used to tell RemoteLaunch which engine to actually use for a given test case. For JMeter this should be JMeter2 as illustrated in the image.
Once you have finished, click the Save button and you will be taken back to the Test Automation list page, with JMeter listed as an available automation engine.
Next, you will need to modify the JMeter configuration for each of the specific automation hosts, by right-clicking on the RemoteLaunch icon in the system tray and choosing \"Configuration\". That will bring up the RemoteLaunch configuration page.
The JMeter 2.x engine adds its own tab to this page which allows you to configure how JMeter operates:
The following fields can be specified on this screen:
JMeter Location -- This should point to the location on the host computer where JMeter is installed. You can click on the browse button and navigate to the location of the JMeter.bat file.
Trace Logging -- When selected, this will log additional trace and debugging information to the Windows Event Log. This should not be selected in a production environment.
"},{"location":"RemoteLaunch-User-Guide/JMeter/#ensuring-jmeter-is-logging-in-xml","title":"Ensuring JMeter is logging in XML","text":"By default, JMeter will log its output in CSV format. This format is not readable by RemoteLaunch, so you will need to update JMeter to log in XML format.
To make this change, locate the following file - jmeter.properties:
Open up this file and locate the following line:
# legitimate values: xml, csv, db. Only xml and csv are currently supported.\n # jmeter.save.saveservice.output_format=csv\nChange this to be:
# legitimate values: xml, csv, db. Only xml and csv are currently supported.\n jmeter.save.saveservice.output_format=xml\nThen save the jmeter.properties file.
"},{"location":"RemoteLaunch-User-Guide/JMeter/#setting-up-the-automated-test-cases","title":"Setting up the Automated Test Cases","text":"This section describes the process for setting up a test case in SpiraTeam for automation and linking it to an automated JMeter test script.
First you need to display the list of test cases in SpiraTeam (by clicking Testing > Test Cases) and then add a new test case. Once you have added the new test case, click on it and select the \"Automation\" tab:
You need to enter the following fields:
Automation Engine - Choose the JMeter Automation Engine that you created in the previous section from the drop-down list.
Script Type -- This should be set to Linked as the integration with JMeter only supports referencing JMeter test script files and not physically uploading the test scripts into SpiraTeam.
Filename -- This consists of the following elements:
The full path to the JMeter test script. To make this easier across different machines, you can use several constants for standard Windows locations (see example in screenshot):
[MyDocuments] -- The user's \"My Documents\" folder. The user indicated is the user that ran RemoteLaunch.
[CommonDocuments] -- The Public Document's folder.
[DesktopDirectory] -- The user's Desktop folder. The user indicated is the user that ran RemoteLaunch.
[ProgramFiles] -- Translated to the Program Files directory. For 64-bit machines, it's the 64-bit directory.
[ProgramFilesX86] -- Translated to the 32-bit Program Files directory.
Optionally you can include JMeter command-line arguments by separating them with a pipe (|) character.
Examples of Filenames you can enter in SpiraTeam include:
[MyDocuments]JMeter\\JMeter-SampleScript.jmx
[MyDocuments]JMeter\\JMeter-SampleScript.jmx|-P 81
[MyDocuments]JMeter\\JMeter-SampleScript.jmx|-P 81 -H 192.168.117.25
Document Type -- This allows you to choose which document type the automated test script will be categorized under.
Document Folder --This allows you to choose which document folder the automated test script will be stored in.
Version -- The version of the test script (1.0 is used if no value specified)
Test Script -- This is not used with the JMeter Engine since it only supports linked test scripts.
Once you are happy with the values, click [Save] to update the test case. Now you are ready to schedule the automated test case for execution.
"},{"location":"RemoteLaunch-User-Guide/JMeter/#using-parameterized-test-cases","title":"Using Parameterized Test Cases","text":"There is an advanced feature of SpiraTest/Team and RemoteLaunch that lets you pass parameters from SpiraTeam to your JMeter automated test script. This is very useful if you have a data-driven JMeter test script that expects specific JMeter properties to be passed to the test script.
To setup the automated test case for parameters, click on the \"Test Steps\" tab and click on \"Edit Parameters\":
The name of the parameter ${login} needs to match the name of the property defined within the JMeter script.
"},{"location":"RemoteLaunch-User-Guide/JMeter/#executing-the-jmeter-test-sets-from-spirateam","title":"Executing the JMeter Test Sets from SpiraTeam","text":"There are two ways to execute automated test cases in SpiraTeam:
Schedule the test cases to be executed on a specific computer (local or remote) at a date/time in the future
Execute the test cases right now on the local computer.
We shall outline both of these two scenarios in this section. However first we need to setup the appropriate automation hosts and test sets in SpiraTeam:
"},{"location":"RemoteLaunch-User-Guide/JMeter/#configuring-the-automation-hosts-and-test-sets","title":"Configuring the Automation Hosts and Test Sets","text":"Go to Testing > Automation Hosts in SpiraTeam to display the list of automation hosts:
Make sure that you have created an Automation Host for each computer that is going to run an automated test case. The name and description can be set to anything meaningful, but the Token field must be set to the same token that is specified in the RemoteLaunch application on that specific machine.
Once you have at least one Automation Host configured, go to Testing > Test Sets to create the test sets that will contain the automated test case:
Note: Unlike manual test cases, automated test cases must be executed within a test set -- they cannot be executed directly from the test case.
Create a new Test Set to hold the JMeter automated test cases and click on its hyperlink to display the test set details page:
You need to add at least one automated test case to the test set and then configure the following fields:
Automation Host -- This needs to be set to the name of the automation host that will be running the automated test set.
Planned Date -- The date and time that you want the scenario to begin. (Note that multiple test sets scheduled at the exact same time will be scheduled by Test Set ID order.)
Status -- This needs to be set to \"Not Started\" for RemoteLaunch to pick up the scheduled test set. When you change the Planned Date, the status automatically switches back to \"Not Started\"
Type -- This needs to be set to \"Automated\" for automated testing
If you have parameterized test cases inside the automated test set you can set their values in three different ways:
Test Set Parameter Values -- this lets you set the same value of a parameter for all the test cases in the test set:
Test Case Parameter Values -- this lets you set a specific value for a parameter for a particular test case in the test set:
You set these values, by right-clicking on a row and choosing \"Edit Parameters\":
Once you have set the various test set fields (as described above), the Remote Launch instances will periodically poll SpiraTeam for new test sets. Once they retrieve the new test set, they will add it to their list of test sets to be executed. Once execution begins they will change the status of the test set to \"In Progress\", and once test execution is done, the status of the test set will change to either \"Completed\" -- the automation engine could be launched and the test has completed -- or \"Blocked\" -- RemoteLaunch was not able to start the automation engine.
If you want to immediately execute the test case on your local computer, instead of setting the \"Automation Host\", \"Status\" and \"Planned Date\" fields, you can instead click the [Execute] icon on the test set itself. This will cause RemoteLaunch on the local computer to immediately start executing the current test set.
In either case, once all the test cases in the test set have been completed, the status of the test set will switch to \"Completed\" and the individual test cases in the set will display a status based on the results of the JMeter test:
Passed -- The JMeter automated test ran successfully and no failures or errors were logged.
Failed -- The JMeter automated test ran successfully, but at least one error or failure was logged.
Blocked -- The JMeter automated test did not run successfully.
If you receive the \"Blocked\" status for either the test set or the test cases you should open up the Windows Application Event Log on the computer running RemoteLaunch and look in the event log for error messages.
Note: While the tests are executing you will see a Windows command prompt open as JMeter executes the appropriate tests.
Once the tests have completed, you can log back into SpiraTeam and see the execution status of your test cases. If you click on a Test Run that was generated by JMeter, you will see the following information:
This screen indicates the status of the test run that was reported back from JMeter together with any messages or other information. The Test Name indicates the name of the test inside JMeter and the execution status corresponds the rules described above.
In addition, the detailed test report from JMeter is below. It will contain messages such as:
Response Assertion (http://www.inflectra.com/): failure=true, error=false, message='Test failed: text expected to contain /(?i)Purchase Our Products Online/' Response Assertion (http://www.inflectra.com/SpiraTest/Default.aspx): failure=true, error=false, message='Test failed: text expected to contain /(?i)Purchase Our Products Online/' Response Assertion (http://www.inflectra.com/Purchase/Default.aspx): failure=false, error=false, message='' Response Assertion (https://www.inflectra.com/Purchase/Default.aspx): failure=false, error=false, message=''
Congratulations... You are now able to run JMeter automated functional tests and have the results be recorded within SpiraTest, SpiraTeam, and SpiraPlan.
"},{"location":"RemoteLaunch-User-Guide/LoadRunner/","title":"LoadRunner","text":"HP\u00ae LoadRunner is a load testing system that lets you record application performance by a number of 'virtual users'.
This section covers installing and using the Engine to report back statistics of run scenarios.
Note: This integration requires at least version 3.0 of SpiraTest/Team and version 11 of LoadRunner. The extension has not been tested on previous versions of LoadRunner due to lack of availability of previous released versions.
"},{"location":"RemoteLaunch-User-Guide/LoadRunner/#installing-the-loadrunner11-engine","title":"Installing the LoadRunner11 Engine","text":"This section assumes that you already have a working installation of SpiraTest or SpiraTeam and have installed RemoteLaunch on the various test automation hosts following the instructions in RemoteLaunch Guide. Once those prerequisites are in place, please follow these steps:
Download and extract the LoadRunner11Engine.zip file from the Inflectra website.
Copy the files in the ZIP file into the \"extensions\" sub-folder of the RemoteLaunch installation.
Log in to SpiraTeam as a system administrator and go into SpiraTeam main Administration page and click on the \"Test Automation\" link under Integration.
Click the \"Add\" button to enter the new test automation engine details page. The fields required are as follows:
Name: This is the short display name of the automation engine. It can be anything that is meaningful to your users, and will be displayed in the dropdown when the user selects the Tester.
Description: This is the long description of the automation engine. It can be anything that is meaningful to your users. (Optional)
Active: If checked, the engine is active and able to be used for any project.
Token: This needs to be the assigned unique token for the automation engine and is used to tell RemoteLaunch which engine to actually use for a given test case. For LoadRunner, it needs to be \"LoadRunner11\".
Once you have finished, click the \"Insert & Close\" button and you will be taken back to the Test Automation list page, with LoadRunner listed as an available automation engine.
This section describes the process for setting up a test case in SpiraTeam for automation and linking it to a Load Runner Scenario.
First you need to display the list of test cases in SpiraTeam (by clicking Testing > Test Cases) and then add a new test case. Once you have added the new test case, click on it and select the \"Automation\" tab:
You need to enter the following fields:
Automation Engine - Choose the LoadRunner Automation Engine that you created in the previous section from the drop-down list.
Script Type -- For LoadRunner, all scenarios must be stored on the local testing machine so 'Linked' must be selected. If you select 'Attached', when the scenario is attempted to be executed it will be marked as blocked and skipped.
Filename -- This needs to be the full path to the LoadRunner Scenario (*.lrs) file. Certain tokens are allowed to be able to specify common locations across different operating systems. Note that the tokens are case-sensitive, and there are no spaces in them. A list of tokens are:
[MyDocuments] -- The user's \"My Documents\" folder. The user indicated is the user that ran RemoteLaunch.
[CommonDocuments] -- The Public Document's folder.
[DesktopDirectory] -- The user's Desktop folder. The user indicated is the user that ran RemoteLaunch.
[ProgramFiles] -- Translated to the Program Files directory. For 64-bit machines, it's the 64-bit directory.
[ProgramFilesX86] -- Translated to the 32-bit Program Files directory.
Document Type -- If using SpiraTeam (not SpiraTest) you can choose which document type the automated scenario will be categorized under.
Document Folder -- If using SpiraTeam (not SpiraTest) you can choose which document folder the automated scenario will be stored in.
Version -- The version of the scenario (1.0 is used if no value specified)
Test Script -- Not used.
Once you are happy with the values, click [Save] to update the test case. Now you are ready to schedule the automated test case for execution.
"},{"location":"RemoteLaunch-User-Guide/LoadRunner/#using-parameterized-test-cases","title":"Using Parameterized Test Cases","text":"There is an advanced feature of SpiraTest/Team and RemoteLaunch that lets you pass parameters from SpiraTeam to your LoadRunner scenario. This is very useful if you have a data-driven LoadRunner scenario that has custom parameters used that you would like to change based on the test.
To setup the automated test case for parameters, click on the \"Test Steps\" tab and click on \"Edit Parameters\":
The name of the parameter ${login} needs to match the name of the custom parameter defined in the LoadRunner scenario. Invalid parameters will be silently ignored by the LoadRunner engine. Parameters must have a unique name.
"},{"location":"RemoteLaunch-User-Guide/LoadRunner/#executing-the-loadrunner-scenario-from-spirateam","title":"Executing the LoadRunner Scenario from SpiraTeam","text":"There are two ways to execute a scenario in SpiraTeam:
Schedule the test cases to be executed on a specific computer (local or remote) at a date/time in the future
Execute the test cases right now on the local computer.
We shall outline both of these two scenarios in this section. However first we need to setup the appropriate automation hosts and test sets in SpiraTeam:
"},{"location":"RemoteLaunch-User-Guide/LoadRunner/#configuring-the-automation-hosts-and-test-sets","title":"Configuring the Automation Hosts and Test Sets","text":"Go to Testing > Automation Hosts in SpiraTeam to display the list of automation hosts:
Make sure that you have created an Automation Host for each computer that is going to run an automated test case. The name and description can be set to anything meaningful, but the Token field must be set to the same token that is specified as the Host name in the RemoteLaunch application on that specific machine.
Once you have at least one Automation Host configured, go to Testing > Test Sets to create the test sets that will contain the automated test case:
Note: Unlike manual test cases, automated test cases must be executed within a test set -- they cannot be executed directly from the test case.
Create a new Test Set to hold the LoadRunner test cases and click on its hyperlink to display the test set details page:
You need to add at least one automated test case to the test set and then configure the following fields:
Automation Host -- This needs to be set to the name of the automation host that will be running the automated test set.
Planned Date -- The date and time that you want the scenario to begin. (Note that multiple test sets scheduled at the exact same time will be scheduled by Test Set ID order.)
Status -- This needs to be set to \"Not Started\" for RemoteLaunch to pick up the scheduled test set. When you change the Planned Date, the status automatically switches back to \"Not Started\"
Type -- This needs to be set to \"Automated\" for automated testing
If you have parameterized test cases inside the automated test set you can set their values in three different ways:
Test Set Parameter Values -- this lets you set the same value of a parameter for all the test cases in the test set:
Test Case Parameter Values -- this lets you set a specific value for a parameter for a particular test case in the test set:
You set these values, by right-clicking on a row and choosing \"Edit Parameters\":
Once you have set the various test set fields (as described above), the Remote Launch instances will periodically poll SpiraTeam for new test sets. Once they retrieve the new test set, they will add it to their list of test sets to be executed. Once execution begins they will change the status of the test set to \"In Progress\", and once test execution is done, the status of the test set will change to either \"Completed\" -- the automation engine could be launched and the test has completed -- or \"Blocked\" -- RemoteLaunch was not able to start the automation engine.
If you want to immediately execute the test case on your local computer, instead of setting the \"Automation Host\", \"Status\" and \"Planned Date\" fields, you can instead click the [Execute] icon on the test set itself. This will cause RemoteLaunch on the local computer to immediately start executing the current test set.
In either case, once all the test cases in the test set have been completed, the status of the test set will switch to \"Completed\" and the individual test cases in the set will display a status based on the results of the LoadRunner execution:
Passed -- The Scenario ran and reported no error messages. Warning, Debug, and Informational messages may have been logged, however.
Failed -- The Scenario ran and at least one error message was reported.
Blocked -- There was an error with the Test Set or LoadRunner application.
If you receive the \"Blocked\" status for either the test set or the test cases you should open up the Windows Application Event Log on the computer running RemoteLaunch and look in the event log for error messages.
Note: While the tests are executing you may see browser or application windows launch as LoadRunner runs the scenario and connects VUsers to their tasks.
Once the tests have completed, you can log back into SpiraTeam and see the execution status of your test cases. If you click on a Test Run that was generated by LoadRunner, you will see the following information:
This screen indicates the status of the scenario that was reported back from LoadRunner together with any messages or other information. Because LoadRunner only reports statistics on the scenarios that was run, the test set will always be marked as passed -- regardless of how long it took, unless there were errors reported. If any errors are reported, the test will be marked as Failed.
The Message of the test will report the duration the scenario took, along with the count of VUsers that reported an error, the number that reported a pass, and the hits per minute on the application.
A more detailed report will be included in the test run's details -- the information above, and then any added Execution Messages and messages logged by the script in time order.
Note: LoadRunner's engine is very basic at this stage. If you have issues with a scenario not reporting or executing properly, please let Inflectra's support team know.
"},{"location":"RemoteLaunch-User-Guide/NeoLoad/","title":"NeoLoad","text":"Neotys NeoLoad is a performance and load testing system that lets you record application performance by a number of 'virtual users' and measure the performance against specified Service Level Agreement (SLA) metrics for the application. When you use NeoLoad with SpiraTest you can report back pass/fail/caution by comparing the actual results against the specified SLA metrics.
This section covers installing and using the Engine to report back statistics of run scenarios as well as the results of the test compared to the required SLAs.
Note: This integration requires at least version 4.0 of SpiraTest/Team and has been tested against version 5.0 of NeoLoad.
"},{"location":"RemoteLaunch-User-Guide/NeoLoad/#installing-the-neoload-engine","title":"Installing the NeoLoad Engine","text":"This section assumes that you already have a working installation of SpiraTest or SpiraTeam and have installed RemoteLaunch on the various test automation hosts following the instructions in RemoteLaunch Guide. Once those prerequisites are in place, please follow these steps:
Download and extract the NeoLoadEngine.zip file from the Inflectra website.
Copy the files in the ZIP file into the \"extensions\" sub-folder of the RemoteLaunch installation.
Log in to SpiraTeam as a system administrator and go into SpiraTeam main Administration page and click on the \"Test Automation\" link under Integration.
Click the \"Add\" button to enter the new test automation engine details page. The fields required are as follows:
Name: This is the short display name of the automation engine. It can be anything that is meaningful to your users, and will be displayed in the dropdown when the user selects the Tester.
Description: This is the long description of the automation engine. It can be anything that is meaningful to your users. (Optional)
Active: If checked, the engine is active and able to be used for any project.
Token: This needs to be the assigned unique token for the automation engine and is used to tell RemoteLaunch which engine to actually use for a given test case. For NeoLoad, it needs to be simply \"NeoLoad\".
Once you have finished, click the \"Insert & Close\" button and you will be taken back to the Test Automation list page, with NeoLoad listed as an available automation engine.
"},{"location":"RemoteLaunch-User-Guide/NeoLoad/#neoload-remotelaunch-settings","title":"NeoLoad RemoteLaunch Settings","text":"You will need to modify the NeoLoad configuration for each of the specific automation hosts, by right-clicking on the RemoteLaunch icon in the system tray and choosing \"Configuration\". That will bring up the RemoteLaunch configuration page. The NeoLoad engine adds its own tab to this page which allows you to configure how NeoLoad operates:
The following fields can be specified on this screen:
NeoLoad Location -- This should be folder containing the \"NeoLoadCmd.exe\" executable that will be used to actually run the automated tests.
Attach PDF Report -- NeoLoad has a built-in report generator that can create detailed Acrobat (PDF) format reports. Enabling this option will attach these reports to the test runs recorded in SpiraTeam.
Run as Administrator -- Sometimes NeoLoad needs to be run as a Windows elevated process, in which case, choose the \"Run as Administrator\" option.
"},{"location":"RemoteLaunch-User-Guide/NeoLoad/#setting-up-the-automated-test-cases","title":"Setting up the Automated Test Cases","text":"This section describes the process for setting up a test case in SpiraTeam for automation and linking it to a NeoLoad project and scenario.
First you need to display the list of test cases in SpiraTeam (by clicking Testing > Test Cases) and then add a new test case. Once you have added the new test case, click on it and go to the \"Automation\" section in the main \"Overview\" tab:
You need to enter the following fields:
Automation Engine - Choose the NeoLoad Automation Engine that you created in the previous section from the drop-down list.
Script Type -- For NeoLoad, all scenarios must be stored on the local testing machine so 'Linked' must be selected. If you select 'Attached', when the scenario is attempted to be executed it will be marked as blocked and skipped.
Filename -- This needs to be the full path to the NeoLoad project file (*.nlp) file followed by the name of the NeoLoad scenario. The two components need to be separated by a pipe (|) character. Certain tokens are allowed to be able to specify common locations across different operating systems. Note that the tokens are case-sensitive, and there are no spaces in them. A list of tokens are:
[MyDocuments] -- The user's \"My Documents\" folder. The user indicated is the user that ran RemoteLaunch.
[CommonDocuments] -- The Public Document's folder.
[DesktopDirectory] -- The user's Desktop folder. The user indicated is the user that ran RemoteLaunch.
[ProgramFiles] -- Translated to the Program Files directory. For 64-bit machines, it's the 64-bit directory.
[ProgramFilesX86] -- Translated to the 32-bit Program Files directory.
Document Type -- You can choose which document type the automated scenario will be categorized under.
Document Folder -- You can choose which document folder the automated scenario will be stored in.
Version -- The version of the scenario (1.0 is used if no value specified)
Test Script -- Not used.
Once you are happy with the values, click [Save] to update the test case. Now you are ready to schedule the automated test case for execution.
"},{"location":"RemoteLaunch-User-Guide/NeoLoad/#using-parameterized-test-cases","title":"Using Parameterized Test Cases","text":"Currently the NeoLoad automation engine does not support the passing of parameter values from SpiraTeam to NeoLoad.
"},{"location":"RemoteLaunch-User-Guide/NeoLoad/#executing-the-neoload-scenario-from-spirateam","title":"Executing the NeoLoad Scenario from SpiraTeam","text":"There are three ways to execute automated test cases in SpiraTeam:
Schedule the test cases to be executed on a specific computer (local or remote) at a date/time in the future
Execute the test cases right now on the local computer.
Execute the test cases from the command-line or a build script
We shall outline each of these three scenarios in this section. However first we need to setup the appropriate automation hosts and test sets in SpiraTeam:
"},{"location":"RemoteLaunch-User-Guide/NeoLoad/#configuring-the-automation-hosts-and-test-sets","title":"Configuring the Automation Hosts and Test Sets","text":"Go to Testing > Automation Hosts in SpiraTeam to display the list of automation hosts:
Make sure that you have created an Automation Host for each computer that is going to run an automated test case. The name and description can be set to anything meaningful, but the Token field must be set to the same token that is specified as the Host name in the RemoteLaunch application on that specific machine.
Once you have at least one Automation Host configured, go to Testing > Test Sets to create the test sets that will contain the automated test case:
Note: Unlike manual test cases, automated test cases must be executed within a test set -- they cannot be executed directly from the test case.
Create a new Test Set to hold the NeoLoad test cases and click on its hyperlink to display the test set details page:
You need to add at least one automated test case to the test set and then configure the following fields:
Automation Host -- This needs to be set to the name of the automation host that will be running the automated test set.
Planned Date -- The date and time that you want the scenario to begin. (Note that multiple test sets scheduled at the exact same time will be scheduled by Test Set ID order.)
Status -- This needs to be set to \"Not Started\" for RemoteLaunch to pick up the scheduled test set. When you change the Planned Date, the status automatically switches back to \"Not Started\"
Type -- This needs to be set to \"Automated\" for automated testing
Once you have set the various test set fields (as described above), the Remote Launch instances will periodically poll SpiraTeam for new test sets. Once they retrieve the new test set, they will add it to their list of test sets to be executed. Once execution begins they will change the status of the test set to \"In Progress\", and once test execution is done, the status of the test set will change to either \"Completed\" -- the automation engine could be launched and the test has completed -- or \"Blocked\" -- RemoteLaunch was not able to start the automation engine.
If you want to immediately execute the test case on your local computer, instead of setting the \"Automation Host\", \"Status\" and \"Planned Date\" fields, you can instead click the [Execute] icon on the test set itself. This will cause RemoteLaunch on the local computer to immediately start executing the current test set.
In either case, once all the test cases in the test set have been completed, the status of the test set will switch to \"Completed\" and the individual test cases in the set will display a status based on the results of the NeoLoad execution:
Passed -- The scenario ran and reported no error messages and all SLAs were passed.
Caution -- The scenario ran and at least one SLA reported back as acceptable
Failed -- The scenario ran and at least one error message was reported or at least one SLA was reported back as failed.
Blocked -- There was an error with the Test Set or NeoLoad application.
If you receive the \"Blocked\" status for either the test set or the test cases you should open up the Windows Application Event Log on the computer running RemoteLaunch and look in the event log for error messages.
Note: While the tests are executing you may see browser or application windows launch as NeoLoad runs the scenario and connects VUsers to their tasks.
Once the tests have completed, you can log back into SpiraTeam and see the execution status of your test cases. If you click on a Test Run that was generated by NeoLoad, you will see the following test run summary information:
This section of the screen indicates how long the test took to execute, the overall status, which release was being executed, which test set it was a part of and each of the key summary statistics, together with information on how they compared to the defined SLA:
N/A -- There was no SLA defined for this metric
Passed -- There is an SLA defined for this metric and it was passed.
Caution -- There is an SLA defined for this metric and it was considered less than a pass, but still acceptable.
Failed -- There is an SLA defined for this metric and it was not met successfully.
In addition, if you scroll down, in the \"Console Output\" section of the report there is more detailed information:
The Message of the test will report the number of total pages, number of total hits, number of total users, number of errors as well as the total count of virtual users.
In addition, more detailed information is displayed in the test run details:
Top 5 errors by page
Top 5 alerts by page
Top 5 average response times by page
Top 5 maximum response times by page
Finally, if you have chosen the option to attach the NeoLoad PDF report, in the Attachments section of the Test Run, that will be listed:
Congratulations... You are now able to run automated NeoLoad performance scenarios and have the results be recorded within SpiraTest / SpiraTeam.
"},{"location":"RemoteLaunch-User-Guide/Ranorex/","title":"Ranorex","text":"Ranorex is an automated functional test automation system that lets you record application operations and generate .NET language (C#, VB.NET) test automation scripts that can be used to playback the test script against the test application.
This section describes how you can use SpiraTest / SpiraTeam (hereafter SpiraTeam) together with RemoteLaunch to schedule and remotely launch instances of Ranorex on different computers and have the testing results be transmitted back to SpiraTeam. This allows you to extend your SpiraTeam's test management capabilities to include automated Ranorex tests.
This plugin was developed by one of our partners (step2IT GmbH) but has been formally tested by Inflectra and is fully supported by Inflectra.
Note: This integration requires at least version 3.0 of SpiraTest/Team and version 3.0 of Ranorex.
"},{"location":"RemoteLaunch-User-Guide/Ranorex/#installing-the-ranorex-engine","title":"Installing the Ranorex Engine","text":"This section assumes that you already have a working installation of SpiraTest or SpiraTeam and have installed RemoteLaunch on the various test automation hosts following the instructions in RemoteLaunch Guide. Once those prerequisites are in place, please follow these steps:
Download and extract the RanorexAutomationEngine.zip file from the Inflectra website and locate the appropriate RanorexAutomationEngine.dll for the version of Ranorex that you are using.
If you don't see the version listed, just use the nearest version that is lower than your current version.
Copy the file \"RanorexAutomationEngine.dll\" into the \"extensions\" sub-folder of the RemoteLaunch installation.
Log in to SpiraTeam as a system administrator and go into SpiraTeam main Administration page and click on the \"Test Automation\" link under Integration.
Click the \"Add\" button to enter the new test automation engine details page. The fields required are as follows:
Name: This is the short display name of the automation engine. It can be anything that is meaningful to your users.
Description: This is the long description of the automation engine. It can be anything that is meaningful to your users. (Optional)
Active: If checked, the engine is active and able to be used for any project.
Token: This needs to be the assigned unique token for the automation engine and is used to tell RemoteLaunch which engine to actually use for a given test case. For Ranorex this should always be RanorexEngine.
Once you have finished, click the \"Insert & Close\" button and you will be taken back to the Test Automation list page, with Ranorex listed as an available automation engine:
You can modify the Ranorex configuration for each of the specific automation hosts, by right-clicking on the RemoteLaunch icon in the system tray and choosing \"Configuration\". That will bring up the RemoteLaunch configuration page.
The Ranorex engine adds its own tab to this page which allows you to configure how Ranorex operates:
The following fields can be specified on this screen:
Result Path -- This is the folder where the results of Ranorex tests will be stored. The currently logged-in user needs to have Read/Write permissions over this folder.
Trace Logging -- When selected, this will log additional trace and debugging information to the Windows Event Log. This should not be selected in a production environment.
"},{"location":"RemoteLaunch-User-Guide/Ranorex/#setting-up-the-automated-test-cases","title":"Setting up the Automated Test Cases","text":"This section describes the process for setting up a test case in SpiraTeam for automation and linking it to an automated Ranorex test script.
First you need to display the list of test cases in SpiraTeam (by clicking Testing > Test Cases) and then add a new test case. Once you have added the new test case, click on it and select the \"Automation\" tab:
You need to enter the following fields:
Automation Engine - Choose the Ranorex Automation Engine that you created in the previous section from the drop-down list.
Script Type -- This should be set to Linked as the integration with Ranorex only supports referencing Ranorex test script files and not physically uploading the test scripts into SpiraTeam.
Filename -- This needs to be the full path to the Ranorex test suite.
To make this easier across different machines, you can use several constants for standard Windows locations (see example in screenshot):
[MyDocuments] -- The user's \"My Documents\" folder. The user indicated is the user that ran RemoteLaunch.
[CommonDocuments] -- The Public Document's folder.
[DesktopDirectory] -- The user's Desktop folder. The user indicated is the user that ran RemoteLaunch.
[ProgramFiles] -- Translated to the Program Files directory. For 64-bit machines, it's the 64-bit directory.
[ProgramFilesX86] -- Translated to the 32-bit Program Files directory.
If you'd like to pass parameters to Ranorex you can specify them by separating them from the filename with a pipe (\"|\") character. For example to run a specific Ranorex test case you can use the following \"filename\":
c:\\test\\mytestsuit.exe|/testcase:addDataTest
Document Type -- This allows you to choose which document type the automated test script will be categorized under.
Document Folder --This allows you to choose which document folder the automated test script will be stored in.
Version -- The version of the test script (1.0 is used if no value specified)
Test Script -- This is not used with the Ranorex Engine since it only supports linked test scripts.
Once you are happy with the values, click [Save] to update the test case. Now you are ready to schedule the automated test case for execution.
"},{"location":"RemoteLaunch-User-Guide/Ranorex/#using-parameterized-test-cases","title":"Using Parameterized Test Cases","text":"There is an advanced feature of SpiraTest/Team and RemoteLaunch that lets you pass parameters from SpiraTeam to your Ranorex automated test suite. This is very useful if you have a data-driven Ranorex test suite that defines input variables from an external data source.
To setup the automated test case for parameters, click on the \"Test Steps\" tab and click on \"Edit Parameters\":
The name of the parameter ${login} needs to match the name of the variable defined within the Ranorex script in its variables configuration.
"},{"location":"RemoteLaunch-User-Guide/Ranorex/#executing-the-ranorex-test-sets-from-spirateam","title":"Executing the Ranorex Test Sets from SpiraTeam","text":"There are two ways to execute automated test cases in SpiraTeam:
Schedule the test cases to be executed on a specific computer (local or remote) at a date/time in the future
Execute the test cases right now on the local computer.
We shall outline both of these two scenarios in this section. However first we need to setup the appropriate automation hosts and test sets in SpiraTeam:
"},{"location":"RemoteLaunch-User-Guide/Ranorex/#configuring-the-automation-hosts-and-test-sets","title":"Configuring the Automation Hosts and Test Sets","text":"Go to Testing > Automation Hosts in SpiraTeam to display the list of automation hosts:
Make sure that you have created an Automation Host for each computer that is going to run an automated test case. The name and description can be set to anything meaningful, but the Token field must be set to the same token that is specified in the RemoteLaunch application on that specific machine.
Once you have at least one Automation Host configured, go to Testing > Test Sets to create the test sets that will contain the automated test case:
Note: Unlike manual test cases, automated test cases must be executed within a test set -- they cannot be executed directly from the test case.
Create a new Test Set to hold the Ranorex automated test cases and click on its hyperlink to display the test set details page:
Lower down, the list of test cases in the test set are displayed:
You need to add at least one automated test case to the test set and then configure the following fields:
Automation Host -- This needs to be set to the name of the automation host that will be running the automated test set.
Planned Date -- The date and time that you want the scenario to begin. (Note that multiple test sets scheduled at the exact same time will be scheduled by Test Set ID order.)
Status -- This needs to be set to \"Not Started\" for RemoteLaunch to pick up the scheduled test set. When you change the Planned Date, the status automatically switches back to \"Not Started\"
Type -- This needs to be set to \"Automated\" for automated testing
If you have parameterized test cases inside the automated test set you can set their values in three different ways:
Test Set Parameter Values -- this lets you set the same value of a parameter for all the test cases in the test set:
Test Case Parameter Values -- this lets you set a specific value for a parameter for a particular test case in the test set:
You set these values, by right-clicking on a row and choosing \"Edit Parameters\":
Once you have set the various test set fields (as described above), the Remote Launch instances will periodically poll SpiraTeam for new test sets. Once they retrieve the new test set, they will add it to their list of test sets to execute. Once execution begins they will change the status of the test set to \"In Progress\", and once test execution is done, the status of the test set will change to either \"Completed\" -- the automation engine could be launched and the test has completed -- or \"Blocked\" -- RemoteLaunch was not able to start the automation engine.
If you want to immediately execute the test case on your local computer, instead of setting the \"Automation Host\", \"Status\" and \"Planned Date\" fields, you can instead click the [Execute] icon on the test set itself. This will cause RemoteLaunch on the local computer to immediately start executing the current test set.
In either case, once all the test cases in the test set have been completed, the status of the test set will switch to \"Completed\" and the individual test cases in the set will display a status based on the results of the Ranorex test:
Passed -- The Ranorex automated test ran successfully and all the test steps in the test script passed and no assertions were thrown.
Failed -- The Ranorex automated test ran successfully, but at least one test step failed or at least one assertion failed.
Caution -- The Ranorex automated test run successfully, but at least one warning was logged in one of the test steps.
Blocked -- The Ranorex automated test did not run successfully or at least one timeout error was recorded.
If you receive the \"Blocked\" status for either the test set or the test cases you should open up the Windows Application Event Log on the computer running RemoteLaunch and look in the event log for error messages.
Note: While the tests are executing you will see browser windows launch as Ranorex executes the appropriate tests.
Once the tests have completed, you can log back into SpiraTeam and see the execution status of your test cases. If you click on a Test Run that was generated by Ranorex, you will see the following information:
This screen indicates the status of the test run that was reported back from Ranorex together with any messages or other information. The Test Name indicates the name of the test inside Ranorex and the execution status corresponds the matching status inside Ranorex as illustrated below:
Ranorex Status SpiraTeam Status Success Passed Failed Failed
In addition, the detailed test report from Ranorex is available in the large text-box below. It will contain messages such as:
+-----------------------------------------------------------------------+ | [2011/10/14 14:08:32.795][Debug ][Logger]: Console logger | | starting. | | | | [2011/10/14 14:08:32.874][Info ][Test]: Test Suite 'WinForms | | Test' started. | | | | [2011/10/14 14:08:32.889][Info ][Test]: Test Case | | 'VS2005_Application_Test' started. | | | | [2011/10/14 14:08:33.467][Success][Test]: Test Module | | 'StartWinformsSample' completed with status 'Success'. | | | | [2011/10/14 14:08:33.467][Info ][Test]: Test Module | | 'CheckIfApplicationAlive' started. | | | | [2011/10/14 14:08:33.608][Info ][Validation]: Validating Exists | | on item 'WinFormsApp.ButtonTest_PushButton'. | | | | [2011/10/14 14:09:55.718][Failure][Test]: Test Case | | 'VS2005_Application_Test' completed with status 'Failed'. | | | | [2011/10/14 14:09:55.718][Failure][Test]: Test Suite 'WinForms | | Test' completed with status 'Failed'. | +-----------------------------------------------------------------------+
Congratulations... You are now able to run Ranorex automated functional tests and have the results be recorded within SpiraTest / SpiraTeam.
"},{"location":"RemoteLaunch-User-Guide/Rational-Functional-Tester/","title":"Rational Functional Tester","text":"IBM Rational Functional Tester (hereafter RFT) is software test automation tool used by quality assurance teams to perform automated regression testing. Testers create scripts by using a test recorder which captures a user's actions against their application under test. The recording mechanism creates a test script from the actions. The test script is produced as either a Java or Visual Basic.net application.
This section describes how you can use SpiraTest / SpiraTeam (hereafter SpiraTeam) together with RemoteLaunch to schedule and remotely launch instances of RFT on different computers and have the testing results be transmitted back to SpiraTeam. This allows you to extend your SpiraTeam's test management capabilities to include automated RFT tests.
Note: This integration requires at least version 3.0 of SpiraTest/Team.
"},{"location":"RemoteLaunch-User-Guide/Rational-Functional-Tester/#installing-the-rft-engine","title":"Installing the RFT Engine","text":"This section assumes that you already have a working installation of SpiraTest or SpiraTeam and have installed RemoteLaunch on the various test automation hosts following the instructions in RemoteLaunch Guide. Once those prerequisites are in place, please follow these steps:
Download and extract the RFTEngine.zip file from the Inflectra website and locate the appropriate RFTAutomationEngine.dll for the version of RFT that you are using.
If you don't see the version listed, just use the nearest version that is lower than your current version.
Copy the file \"RFTAutomationEngine.dll\" into the \"extensions\" sub-folder of the RemoteLaunch installation.
Log in to SpiraTeam as a system administrator and go into SpiraTeam main Administration page and click on the \"Test Automation\" link under Integration.
Click the \"Add\" button to enter the new test automation engine details page. The fields required are as follows:
Name: This is the short display name of the automation engine. It can be anything that is meaningful to your users.
Description: This is the long description of the automation engine. It can be anything that is meaningful to your users. (Optional)
Active: If checked, the engine is active and able to be used for any project.
Token: This needs to be the assigned unique token for the automation engine and is used to tell RemoteLaunch which engine to actually use for a given test case. For RFT this should always be RFTAutomationEngine.
Once you have finished, click the \"Insert & Close\" button and you will be taken back to the Test Automation list page, with RFT listed as an available automation engine.
You can modify the RFT configuration for each of the specific automation hosts, by right-clicking on the RemoteLaunch icon in the system tray and choosing \"Configuration\". That will bring up the RemoteLaunch configuration page.
The RFT engine adds its own tab to this page which allows you to configure how RFT operates:
The following fields can be specified on this screen:
RFT Location -- this is where the installation of RFT can be found. Typically it's C:\\Program Files\\IBM\\SDP\\FunctionalTester\\bin
Workspace Location -- This is the folder where the RFT test scripts and generated log files will be stored. The currently logged-in user needs to have Read/Write permissions over this folder. Typically it's:
C:\\Documents and Settings\\[User Name]\\IBM\\rationalsdp\\workspace on a Windows XP workstation or Windows 2003 server.
C:\\Users\\[User Name]\\IBM\\rationalsdp\\workspace on a Windows Vista, 7, 2008 or 2008 R2 computer.
Trace Logging -- When selected, this will log additional trace and debugging information to the Windows Event Log. This should not be selected in a production environment.
"},{"location":"RemoteLaunch-User-Guide/Rational-Functional-Tester/#setting-up-the-automated-test-cases","title":"Setting up the Automated Test Cases","text":"This section describes the process for setting up a test case in SpiraTeam for automation and linking it to an automated RFT test script.
First you need to display the list of test cases in SpiraTeam (by clicking Testing > Test Cases) and then add a new test case. Once you have added the new test case, click on it and select the \"Automation\" tab:
You need to enter the following fields:
Automation Engine - Choose the RFT Automation Engine that you created in the previous section from the drop-down list.
Script Type -- This should be set to Linked as the integration with RFT only supports referencing RFT test script files and not physically uploading the test scripts into SpiraTeam.
Filename -- This needs to consist of the following three components separated by a pipe (|) character (see the screenshot for an example):
The name of the RFT project that the test is mapped to
The name of the RFT script in the project that the test is mapped to
Either \"java\" or \"net\" depending on whether you have a Java or .NET test script
Document Type -- This allows you to choose which document type the automated test script will be categorized under.
Document Folder --This allows you to choose which document folder the automated test script will be stored in.
Version -- The version of the test script (1.0 is used if no value specified)
Test Script -- This is not used with the RFT Engine since it only supports linked test scripts.
Once you are happy with the values, click [Save] to update the test case. Now you are ready to schedule the automated test case for execution.
"},{"location":"RemoteLaunch-User-Guide/Rational-Functional-Tester/#using-parameterized-test-cases","title":"Using Parameterized Test Cases","text":"There is an advanced feature of SpiraTest/Team and RemoteLaunch that lets you pass parameters from SpiraTeam to your RFT automated test suite. This is very useful if you have a data-driven RFT test suite that defines input variables from an external data source.
To setup the automated test case for parameters, click on the \"Test Steps\" tab and click on \"Edit Parameters\":
The name of the parameter ${login} is actually not used when passing the data to RFT, only the values are passed. Therefore it's important that the parameters are stored in the order they are expected by your RFT test script.
"},{"location":"RemoteLaunch-User-Guide/Rational-Functional-Tester/#executing-the-rft-test-sets-from-spirateam","title":"Executing the RFT Test Sets from SpiraTeam","text":"There are two ways to execute automated test cases in SpiraTeam:
Schedule the test cases to be executed on a specific computer (local or remote) at a date/time in the future
Execute the test cases right now on the local computer.
We shall outline both of these two scenarios in this section. However first we need to setup the appropriate automation hosts and test sets in SpiraTeam:
"},{"location":"RemoteLaunch-User-Guide/Rational-Functional-Tester/#configuring-the-automation-hosts-and-test-sets","title":"Configuring the Automation Hosts and Test Sets","text":"Go to Testing > Automation Hosts in SpiraTeam to display the list of automation hosts:
Make sure that you have created an Automation Host for each computer that is going to run an automated test case. The name and description can be set to anything meaningful, but the Token field must be set to the same token that is specified in the RemoteLaunch application on that specific machine.
Once you have at least one Automation Host configured, go to Testing > Test Sets to create the test sets that will contain the automated test case:
Note: Unlike manual test cases, automated test cases must be executed within a test set -- they cannot be executed directly from the test case.
Create a new Test Set to hold the RFT automated test cases and click on its hyperlink to display the test set details page:
You need to add at least one automated test case to the test set and then configure the following fields:
Automation Host -- This needs to be set to the name of the automation host that will be running the automated test set.
Planned Date -- The date and time that you want the scenario to begin. (Note that multiple test sets scheduled at the exact same time will be scheduled by Test Set ID order.)
Status -- This needs to be set to \"Not Started\" for RemoteLaunch to pick up the scheduled test set. When you change the Planned Date, the status automatically switches back to \"Not Started\"
Type -- This needs to be set to \"Automated\" for automated testing
If you have parameterized test cases inside the automated test set you need to set their values by right-clicking on the test case and choosing \"Edit Parameters\":
Enter the parameter values and click \"Update\" to commit the change. This allows you to have the same test case in the test set multiple times with different data for each instance.
"},{"location":"RemoteLaunch-User-Guide/Rational-Functional-Tester/#executing-the-test-sets","title":"Executing the Test Sets","text":"Once you have set the various test set fields (as described above), the Remote Launch instances will periodically poll SpiraTeam for new test sets. Once they retrieve the new test set, they will add it to their list of test sets to execute. Once execution begins they will change the status of the test set to \"In Progress\", and once test execution is done, the status of the test set will change to either \"Completed\" -- the automation engine could be launched and the test has completed -- or \"Blocked\" -- RemoteLaunch was not able to start the automation engine.
If you want to immediately execute the test case on your local computer, instead of setting the \"Automation Host\", \"Status\" and \"Planned Date\" fields, you can instead click the [Execute] icon on the test set itself. This will cause RemoteLaunch on the local computer to immediately start executing the current test set.
In either case, once all the test cases in the test set have been completed, the status of the test set will switch to \"Completed\" and the individual test cases in the set will display a status based on the results of the RFT test:
Passed -- The RFT automated test ran successfully and all the test steps in the test script passed and no assertions were thrown.
Failed -- The RFT automated test ran successfully, but at least one test step failed or at least one assertion failed.
Caution -- The RFT automated test run successfully, but at least one warning was logged in one of the test steps.
Blocked -- The RFT automated test did not run successfully.
If you receive the \"Blocked\" status for either the test set or the test cases you should open up the Windows Application Event Log on the computer running RemoteLaunch and look in the event log for error messages.
Note: While the tests are executing you will see browser windows launch as RFT executes the appropriate tests.
Once the tests have completed, you can log back into SpiraTeam and see the execution status of your test cases. If you click on a Test Run that was generated by RFT, you will see the following information:
This screen indicates the status of the test run that was reported back from RFT together with any messages or other information. The Test Name indicates the name of the test inside RFT and the execution status corresponds the matching status inside RFT as illustrated below:
RFT Status SpiraTeam Status PASS Passed FAIL Failed WARNING CautionIn addition, the detailed test report from RFT is available in the large text-box below. It will contain messages such as:
07-Nov-2011 03:00:05.004 PM: Script Start - INFORMATION - Script start [Script1]
07-Nov-2011 03:00:05.035 PM: Simplified Script Group - INFORMATION - firefox.exe: self improvement - QuickStart Tutorials for Rational Functional Tester (RFT) - Stack Overflow - Mozilla Firefox
07-Nov-2011 03:00:05.035 PM: Timer Start - INFORMATION - Start timer: firefoxexeselfimprovementQuickSta_1
07-Nov-2011 03:00:25.535 PM: General - WARNING - Object Recognition is weak (above the warning threshold)
07-Nov-2011 03:00:49.488 PM: General - FAIL - Script1.testMain had an unhandled exception.
07-Nov-2011 03:00:49.488 PM: Script End - FAIL - Script end [Script1]
Exception occurred during playback of script [Script1] [CRFCN0019E: RationalTestScriptException on line 49 of script Script1 - com.rational.test.ft.ObjectNotFoundException: CRFCN0661W: The recognition score of the found object does not qualify the object as a match.
Looking for [GuiSubitemTestObject(Name: goToAWebSitetext, Map: GoToAWebSite)], best failing candidate score was [22500] with best failing description [{.class=.Text, .name=Go to a Web Site, .classIndex=0}].].
Congratulations... You are now able to run RFT automated functional tests and have the results be recorded within SpiraTest / SpiraTeam.
"},{"location":"RemoteLaunch-User-Guide/RemoteLaunch-Guide/","title":"RemoteLaunch Guide","text":"There are actually two separate versions of RemoteLaunch\u00ae that are available from Inflectra:
The first part of this section will describe how to use the Windows-only RemoteLaunch\u00ae GUI application and the second part will describe how to use the cross-platform RemoteLaunchX**\u2122** console application.
"},{"location":"RemoteLaunch-User-Guide/RemoteLaunch-Guide/#installing-remotelaunch","title":"Installing RemoteLaunch","text":"It is required that you install the program before copying or installing any test extensions for the program. Testing applications, like Selenium and QuickTest Pro can be installed with no regards to the client application -- if they are not installed by the time a test requiring them needs to be executed, the test extension will simply report an error or block for the specified test set.
There are no options to the installer except for installation path. If you do not use the default installation path (typically C:\\Program Files\\Inflectra\\Spira RemoteLaunch\\), then make a note of where the installation path is, because it will be needed to install test extensions later.
A test extension is a single or a set of DLLs that the program will read upon startup and provides a link in which testing applications (like TestComplete and Squish) to report test information and status back to SpiraTeam.
When you download a test extension, the ZIP file should contain at least one DLL file. Unless otherwise specified by a readme.txt file included in the compressed file, copy the DLL file to the \\extension directory located within Spira RemoteLaunch installation directory. (If no such folder exists, you must create it.)
If an extension is removed or added, the program must be restarted for the any changes to take effect. The program will only load up to the first number of extensions that the license allows. Additional extensions will not be loaded or used during testing.
RemoteLaunch runs in the background. To fully close RemoteLaunch you need to exit the application by right clicking on the icon in the task bar (usually in the lower right of your screen). This will cancel any currently running tests. Any scheduled tests, waiting to be executed will be paused until the program is restarted and polling resumed.
If, when you restart the application, the new engine tab does not show up in RemoteLaunch, Windows may have blocked the engine dll in the extensions folder. To resolve this block:
Spira RemoteLaunch has its own License key needed for using the program. You cannot use your existing SpiraTest/Plan/Team key in Spira RemoteLaunch. Upon the first launch of the program, you will be asked to update your license information:
Enter in your organization name and license key in the email that was sent when you purchased the license, or as listed on your customer information page at http://inflectra.com.
Trial licenses are good until the 28th day of the listed month. The next time the program is run after the 28th of the month, you will be prompted to re-enter a new permanent license key, or the program will be unusable.
The license key can be updated at any time by going to the Tray Menu and select Help -> About. Once the About screen opens up, click the Update button in the license details section to update or change license information.
"},{"location":"RemoteLaunch-User-Guide/RemoteLaunch-Guide/#using-remotelaunch","title":"Using RemoteLaunch","text":""},{"location":"RemoteLaunch-User-Guide/RemoteLaunch-Guide/#basic-unattended-operation","title":"Basic Unattended Operation","text":"When run, the program will start minimized to the system tray and will start its polling of the server. Polling will occur every 'x' minutes (60 by default) for any automated test sets that are scheduled to be run. When time comes for a test to be launched, it will start the test extension. The installed test extension will then perform the test and report results back to SpiraTeam. At the end of the test, the program will go back and resume scanning for tests that need to be executed.
No user input is ever needed from the application itself. However, testing applications may pop up dialogs needing user input. For existing Inflectra testing extensions, effort was put in to avoid as much user-interaction as possible, but in some cases it is unavoidable.
"},{"location":"RemoteLaunch-User-Guide/RemoteLaunch-Guide/#client-configuration","title":"Client Configuration","text":"By right clicking on the system tray icon and selecting \"Configuration\", the application's window will open to the configuration panel. The panel has the following options:
SpiraTeam Server Configuration:
Server Polling:
If an extension has custom configuration options, they will appear as separate tabs located after the Client Setup tab. The contents of each tab will vary depending on the extension. View the extension's documentation for options given in those extensions.
"},{"location":"RemoteLaunch-User-Guide/RemoteLaunch-Guide/#status-screen","title":"Status Screen","text":"The status screen is usually hidden, but can be brought up for display by double-clicking on the system tray icon. The top of the screen shows the current status, whether it's running a test or waiting to poll the server for an update. It will also show any errors present on the application, like a registration error or configuration issue. Under the status bar is a list of any pending or executing tests that are scheduled for this testing machine. The list will get cleared at every poll, so tests that have executed since the previous poll will still be on the list, and will show their execution status:
Green Arrow: A green arrow indicates that the test is still running, or RemoteLaunch is waiting for a reply from the testing engine / test application.
Blue Checkbox: A blue checkbox indicates that the test is completed, regardless of status of the individual test steps in the scheduled test set.
Red Error: A red error indicator indicates that the test extension or the testing application ran into an issue (outside of test results). In this case, any further tests that require the extension will be marked as blocked, as the issue needs to be corrected within the extension settings or testing application.
No Indication: No indication means that the test is currently awaiting for its scheduled date to start. Note that only one test will be launched at a time, so that if two tests are scheduled at the same time, the one with the lower TestSet ID will be executed first, then as soon as it's finished, the second scheduled test will be run.
By highlighting a test that has not been executed yet, you can click the Force Execute button. This will cause the selected test to have its scheduled date to the current time, causing it to be immediately executed (or, if another test is already running, next in line for execution).
At any time the Force Poll button can be clicked, causing RemoteLaunch to initiate an immediate poll of the SpiraTeam server to check for pending runs. The timers for the next server poll will be reset when the button is clicked.
"},{"location":"RemoteLaunch-User-Guide/RemoteLaunch-Guide/#tray-icon-menu","title":"Tray Icon Menu","text":"Instead of operating from the application window, all functions exist on the tray icon menu as well, as well as some additional commands:
Pause / Resume: The Pause/Resume option pauses or resumes the timers for polling and executing tests. If a test or server poll is already in progress, it will not cancel these. However, after they are finished, no further polls or tests will be run.
Poll Now: This will force a server poll for upcoming tests, and reset the poll timer.
Configuration: Opens the main window to the Configuration page.
Help -> About: Opens the About window, which displays the current license information and any loaded extensions.
Help -> View Help: Opens this PDF file in a browser.
Exit: Will completely exit the program. Doing this will cancel any tests currently running and shut down the program. Any tests that were waiting to be executed will not execute until the program is restarted and the polling is resumed.
You can double-click the try icon to bring up the main window on the Status page.
"},{"location":"RemoteLaunch-User-Guide/RemoteLaunch-Guide/#test-execution-and-reporting","title":"Test Execution and Reporting","text":"All test handling is performed by the extension that the automated tests are configured for. Test Sets that have multiple Test Cases, the Test Cases will all be executed in order, sequentially. (No parallel executing.)
At the start of execution for a Test Set, the test set will be updated in SpiraTeam as \"In Progress\". As tests are performed, the Test Cases will be updated with their status. The Test Set on the status screen will be marked with the executing icon.
Once the Test Set is completed, the status of the Test Set will be changed to \"Completed\", and will be marked on the status screen with a completed icon.
In case of an uncaught exception that is thrown by the testing extension, the Test Set will be marked \"Blocked\", and the Test Case will be recorded as Blocked. All other following tests will not be run and remain as Not Run. The Test Set must be reset to be executed again, and it is recommended to look into the cause of the error (recorded in the Blocked Test Case results) and correct it before rescheduling the test. This Test Set will be marked with and error icon.
The same results are applied in the case where a Test Set contains a Test Case that references a testing extension that is not installed. Install the extension and re-run the Test Set.
Executing , Completed , and Error Test Sets are marked with the icons next to their scheduled date in the Status screen. They will stay in the list until the next scheduled server poll. You cannot manually re-run them.
"},{"location":"RemoteLaunch-User-Guide/RemoteLaunch-Guide/#running-remotelaunch-from-a-build-script","title":"Running RemoteLaunch from a Build Script","text":"Normally you schedule tests in SpiraTeam using the Planned Date field of the test sets and let the various instances of RemoteLaunch poll SpiraTeam for upcoming tests. In addition (as described in the SpiraTeam User Manual) you can execute a test set on the local machine immediately by clicking the \"Execute\" button within SpiraTeam.
However there are situations where you want to be able to launch an automated test script using one of the supported engines from an external batch file or build script (e.g. as part of a continuous integration environment) and have those tests report their results back into SpiraTeam. You can achieve this by using the special command-line argument --testset which is passed to RemoteLaunch. For more details on this parameter see the next section.
"},{"location":"RemoteLaunch-User-Guide/RemoteLaunch-Guide/#command-line-arguments","title":"Command line arguments","text":"For debugging and additional options when running the program, the following command-line arguments are available:
-status Shows the Status screen upon startup. (Normal action is to run minimized to the system tray. -paused Starts the application with timers Paused instead of active. -poll Forces the program to do an initial poll upon startup. (Normal action is to wait the pending time before doing the initial poll.) -trace Enables tracelogging to the EventLog for debugging and watching tests execute. -logfile Forces events to be written to a text file instead of the Application EventLog. This option enables --trace as well. Files are located in the Local Application Data folder. (C:\\Users\\<user>\\AppData\\Local on Vista/Win7). -testset:[Test Set ID] Allows you to tell RemoteLaunch to execute a specific test set on the remote computer (e.g. -testset:45 runs test set TX00045) <filename> Must be the last item on the command line. This is a TST file downloaded from SpiraTeam to start immediate execution on."},{"location":"RemoteLaunch-User-Guide/RemoteLaunch-Guide/#using-remotelaunchx","title":"Using RemoteLaunchX","text":"When you need to run automated tests on a variety of different platforms (Windows, MacOS X, Linux, Unix, etc.) the RemoteLaunchX cross-platform automated testing agent is a better choice than the standard RemoteLaunch\u00ae GUI application.
To start using RemoteLaunchX, please go to the Customer Area of the Inflectra website and download the latest version of the RemoteLaunchX application. It will be packaged as a simple .zip compressed folder that you can extract onto the target computer:
The following four files are included:
RemoteLaunchX.jar -- this is the main application, packaged as a Java JAR file. This version of RemoteLaunch requires Java 1.8 SE or later to be installed.
config.properties -- this contains all the settings used by RemoteLaunchX. You will need to edit this file in a text editor to configure RemoteLaunchX for use.
RemoteLaunchX.bat -- this is a sample Windows\u00ae batch file that can be used to simplify running RemoteLaunchX on Windows\u00ae systems.
RemoteLaunchX.sh -- this is a sample UNIX/Linux/MacOS X shell script that can be used to run RemoteLaunchX on UNIX, Linux or Mac OS X.
In addition, there is a lib folder that also needs to be extracted. It contains various third-party libraries that RemoteLaunchX uses. Currently it only uses the Google json parser library (gson v2.8.6):
"},{"location":"RemoteLaunch-User-Guide/RemoteLaunch-Guide/#configuring-remotelaunchx","title":"Configuring RemoteLaunchX","text":"Once you have extracted the files listed above, open up the config.properties file in a text editor:
#This file contains the configuration data used by the RemoteLaunch-X application\n\n#Spira connection information\nserver-url = http://vm-win2012r2/SpiraTeam\nserver-login = fredbloggs\nserver-token = {XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}\n\n#The automation host token \nhost-token = MyHost1\n\n#The license key \nlicense-organization: TBD \nlicense-key: TBD\n\n#The regular expressions for each of the possible execution statuses\npass-regex = .*\nfail-regex = (?i).*(Error|Fail|Fatal).*\ncaution-regex = .*(Warning|Caution).*\nblocked-regex = .*(Blocked).*\n\n#Default status for output not matching any of the regular expressions above\ndefault-test-status = Not Run\nThe following changes need to be made to this configuration file:
server-url -- This is the URL of the SpiraTest or SpiraTeam installation (hereafter referred to as just SpiraTest). Be sure to not put /Login.aspx or any other page in the string, this should be just the root URL of the application's install.
server-login -- This is the SpiraTest login id of the user that you want the tests reported as. Note that while the application is polling and updating test results, if the user is logged into a web browser session, they will get kicked out.
server-token -- The RSS Token of the SpiraTest login listed above. Found in users profile page under the \"RSS Token\" field; you must have RSS Feeds enabled for this to work.
host-token -- This field is required, and uniquely identifies the local testing machine. Any scheduled tests assigned to the Automation Host on SpiraTest will get polled for this machine. Except in special circumstances, this ID should be unique among all testing machines. Important: This field must match the string that is entered into the Automation Host Details screen in the Token: field, or scheduled tests will not be recognized.
license-organization -- The name of the \"Organization\" that your RemoteLaunch license key was issued to. This is listed in the Customer Area of the Inflectra website alongside the license key. Note: RemoteLaunch and RemoteLaunchX use the same license keys, so you don't need to have a separate RemoteLaunchX one.
license-key -- The RemoteLaunch license key that is listed in the secure Customer Area of the Inflectra website
You should leave the four regex settings alone for now, they can be changed when you start executing tests and need to fine-tune how RemoteLaunchX interprets the results.
Now that you have configured the plugin, you can execute the RemoteLaunchX console application by either running the provided batch / shell command or just executing the JAR file directly:
Java --jar RemoteLaunchX.jar
When you run the application, the following should be output to the console:
Starting RemoteLaunch...
========================
Server URL: http://localhost/Spira
Server Login: fredbloggs
Automation Host: MyHost1
Checking License Key for: Inflectra Corporation
Production License Key in Use.
Testing connection to Spira...
Successfully connected to Spira.
WARNING: Unable to retrieve test runs for SpiraTest project PR2, so skipping this project - Automation Host with token 'MyHost1' doesn't exist in project PR2.
WARNING: Unable to retrieve test runs for SpiraTest project PR3, so skipping this project - Automation Host with token 'MyHost1' doesn't exist in project PR3.
Retrieved 0 test run(s) from SpiraTest.
Exiting RemoteLaunch...
========================
The system will report back zero Test Runs at this point because nothing has been scheduled in SpiraTest. In the next section we shall setup an automated test set that contains an automated test case.
"},{"location":"RemoteLaunch-User-Guide/RemoteLaunch-Guide/#setting-up-automated-tests-in-spiratest","title":"Setting up Automated Tests in SpiraTest","text":"This section assumes that you already have a working installation of SpiraTest or SpiraTeam and have installed RemoteLaunchX on the various test automation hosts following the instructions above. Once those prerequisites are in place, please follow these steps:
Log in to SpiraTeam as a system administrator and go into SpiraTeam main Administration page and click on the \"Test Automation\" link under Integration.
Click the \"Add\" button to enter the new test automation engine details page. The fields required are as follows:
Name: This is the short display name of the automation engine. It can be anything that is meaningful to your users.
Description: This is the long description of the automation engine. It can be anything that is meaningful to your users. (Optional)
Active: If checked, the engine is active and able to be used for any project.
Token: This needs to be the assigned unique token for the automation engine and is used to tell RemoteLaunch which engine to actually use for a given test case. For Command-Line this should be simply \"CommandLine\".
Once you have finished, click the \"Insert & Close\" button and you will be taken back to the Test Automation list page, with Command-Line listed as an available automation engine.
Next you need to display the list of test cases in SpiraTeam (by clicking Testing > Test Cases) and then add a new test case. Once you have added the new test case, click on it and select the \"Automation\" tab:
You need to enter the following fields:
Automation Engine - Choose the Command-Line Automation Engine that you created in the previous section from the drop-down list.
Script Type -- This can be set to Attached or Linked (see below for the difference).
Filename -- This needs to consist of the following three sections separated by a pipe (|) character:
2) Any arguments for the command-line tool. In addition, you can use the following additional tokens for some of the special RemoteLaunchX values:
3) The mask for converting any parameter values from SpiraTeam into valid command line arguments. If parameters are not accepted by the command-line tool, you can leave this section out.
The mask can include any symbols together with \"name\" to refer to the parameter name and \"value\" to refer to the parameter value.
Example 1: If you want parameters to be provided in the form: -param1=value1 --param2=value2 you would use the following mask: -name=value
Example 2: If you want parameters to be provided in the form: /param1:value1 /param2:value2 you would use the following mask: /name:value
Some example filenames would be: C:\\Temp\\TestApp.exe|-arg1 -arg2|-name=value C:\\Temp\\TestApp.exe|-arg1 -arg2 \"-arg3=[Filename]\"|
where the first one is for a Linked test and the second one is for an Attached test.
Document Type -- You can choose which document type the automated test script will be categorized under.
Document Folder -- You can choose which document folder the automated test script will be stored in.
Version -- The version of the test script (1.0 is used if no value specified)
Test Script -- For Attached test scripts, this needs to contain the complete test script in whatever language and syntax is being expected by the command-line application. For Linked test scripts, you should leave this blank.
If you would like to have SpiraTeam pass any parameter values to this test script you can specify them by using the syntax ${parameterName} inside the test script.
here is an advanced feature of SpiraTest/Team and RemoteLaunch that lets you pass parameters from SpiraTeam to your command-line automated testing tool. This is very useful if you want to have a data-driven test script that be executed multiple times with different parameter values.
To setup the automated test case for parameters, click on the \"Edit Parameters\" hyperlink above the \"Test Script\" box:
The name of the parameter ${login} needs to match the name of a parameter accepted by the command-line tool.
Once you are happy with the values, click [Save] to update the test case. Now you are ready to schedule the automated test case for execution.
Go to Testing > Automation Hosts in SpiraTeam to display the list of automation hosts:
Make sure that you have created an Automation Host for each computer that is going to run an automated test case. The name and description can be set to anything meaningful, but the Token field must be set to the same token that is specified in the RemoteLaunchX application on that specific machine.
Once you have at least one Automation Host configured, go to Testing > Test Sets to create the test sets that will contain the automated test case. Note: Unlike manual test cases, automated test cases must be executed within a test set -- they cannot be executed directly from the test case.
Create a new Test Set to hold the Command-Line automated test cases and click on its hyperlink to display the test set details page:
You need to add at least one automated test case to the test set and then configure the following fields:
Automation Host -- This needs to be set to the name of the automation host that will be running the automated test set.
Planned Date -- The date and time that you want the scenario to begin. (Note that multiple test sets scheduled at the exact same time will be scheduled by Test Set ID order.)
Status -- This needs to be set to \"Not Started\" for RemoteLaunch to pick up the scheduled test set. When you change the Planned Date, the status automatically switches back to \"Not Started\"
Type -- This needs to be set to \"Automated\" for automated testing
If you have parameterized test cases inside the automated test set you can set their values in three different ways:
Test Set Parameter Values -- this lets you set the same value of a parameter for all the test cases in the test set:
Test Case Parameter Values -- this lets you set a specific value for a parameter for a particular test case in the test set:
Test Configurations -- this lets you create a data grid of possible test parameters and execute the test set multiple times, once for each unique combination:
testset -- If you would like to force execution of a test set regardless of its status, you can use the -testset command-line option just as in RemoteLaunch. Simply add -testset:[ID] where [ID] is the ID of the test set you would like to execute. e.g. java -jar RemoteLaunchX.jar -testset:24 -testset:37
project -- If you would like to limit the projects scanned by RemoteLaunchX, you can use the -project command-line option. Simply add -project:[ID] where [ID] is the ID of the project. e.g. java -jar RemoteLaunchX.jar -project:1 project:6
Once you have set the various test set fields (as described above), you are now ready to execute RemoteLaunchX. You can execute the RemoteLaunchX console application by either running the provided batch / shell command or just executing the JAR file directly:
Java --jar RemoteLaunchX.jar
When you run the application, the following should be output to the console:
Starting RemoteLaunch...
========================
Server URL: http://localhost/Spira
Server Login: fredbloggs
Automation Host: MyHost1
Checking License Key for: Inflectra Corporation
Production License Key in Use.
Testing connection to Spira...
Successfully connected to Spira.
WARNING: Unable to retrieve test runs for SpiraTest project PR2, so skipping this project - Automation Host with token 'MyHost1' doesn't exist in projec PR2.
WARNING: Unable to retrieve test runs for SpiraTest project PR3, so skipping this project - Automation Host with token 'MyHost1' doesn't exist in projec PR3.
Retrieved 1 test run(s) from SpiraTest.
Executing test case TC18 with filename 'C:\\Windows\\System32\\ipconfig.exe|/all'
This is a Linked test script
Executing command 'C:\\Windows\\System32\\ipconfig.exe' with arguments '/all'
Execution Status = Passed
Exiting RemoteLaunch...
========================
This can be seen graphically below:
The console output will indicate which test sets are being executed and what the final result was. Inside SpiraTest, once execution begins the status of the test set will change from \"Not Started\" to \"In Progress\", and once test execution is done, the status of the test set will change to either \"Completed\" -- the automation engine could be launched and the test has completed (passed or failed) -- or \"Blocked\" -- RemoteLaunchX was not able to execute the test.
In addition, the individual test cases in the set will display a status based on the results of the command-line test that was executed:
Passed -- The automated test ran successfully and matched the PASS regular expression.
Failed -- The automated test ran successfully, and matched the FAIL regular expression.
Caution -- The automated test ran successfully, and matched the CAUTION regular expression.
Blocked -- The automated test did not run successfully or it matched the BLOCKED regular expression.
If you receive the \"Blocked\" status for either the test set or the test cases you should open up the Test Run that was recorded and the Console output section will contain the underlying error message(s).
Once the tests have completed, you can log back into SpiraTest and see the execution status of your test cases. If you click on a Test Run that was generated by the command-line tool, you will see the following information:
This screen indicates the status of the test run that was reported back from command-line tool together with any messages or other information. The execution status will be set according to the rules described above, the Message field will contain the first line of console output and the large details box will contain the full console output from the command-line tool.
Congratulations... You are now able to run a custom command-line test, and have the results be recorded within SpiraTest / SpiraTeam.
"},{"location":"RemoteLaunch-User-Guide/RemoteLaunch-Guide/#scheduling-remotelaunchx","title":"Scheduling RemoteLaunchX","text":"Unlike the main RemoteLaunch application, RemoteLaunchX does not have a built-in timer and so when executed it will run once, check for pending test sets and then exit. If you want to have it run on a periodic basis, you will need to schedule it externally. If you are using Microsoft Windows\u00ae you would use the Windows Task Scheduler and in other operating systems you would setup a CRON job. We recommend scheduling RemoteLaunchX to run every 5 minutes.
"},{"location":"RemoteLaunch-User-Guide/RemoteLaunch-Guide/#customizing-the-reporting","title":"Customizing the Reporting","text":"By default, RemoteLaunchX will use the following rules to determine if a test has passed, failed, blocked or passed with warnings (caution) Note that regular expressions are case sensitive by default. To make them case insensitive, simply add the (?i) flag to the beginning just as in the fail-regex below.
Passed -- The test completed and the console output didn't contain any of the error phrases listed in the other rules (below).
Failed -- The test completed and the console output contained the phrases \"Error\", \"Fail\" or \"Fatal\".
Caution -- The test completed and the console output contained the phrases \"Warning\", or \"Caution\".
Blocked -- The automated test did not run successfully or the console output contained the phrase \"Blocked\".
You can customize the reporting by changing the Regular Expressions (Regex) and the default test status stored in the config.properties files:
#The regular expressions for each of the possible execution statuses\n\npass-regex = .\\*\nfail-regex = (?i).\\*(Error\\|Fail\\|Fatal).\\*\ncaution-regex = .\\*(Warning\\|Caution).\\*\nblocked-regex = .\\*(Blocked).\\*\n\n#Default status for output not matching any of the regular expressions above\ndefault-test-status = Not Run\nSelenium Remote Control (RC) is a test tool that allows you to write automated web application user interface tests in any programming language against any HTTP website using any mainstream JavaScript-enabled browser. Selenium RC comes in two parts.
A server which can automatically launch and kill supported browsers, and acts as a HTTP proxy for web requests from those browsers.
Client applications that send commands to the Selenium-RC server in a special language (called Selenese) that tell it what operations to perform on the launched web browser.
This section describes how you can use SpiraTest / SpiraTeam (hereafter SpiraTeam) together with RemoteLaunch to schedule and remotely launch instances of Selenium-RC (hereafter just referred to as Selenium) on different computers and have the testing results be transmitted back to SpiraTeam. This allows you to extend your SpiraTeam's test management capabilities to include automated Selenium web tests.
Note: This integration requires at least version 3.0 of SpiraTest/Team and version 1.0 of Selenium-Remote Control.
"},{"location":"RemoteLaunch-User-Guide/Selenium/#installing-the-selenium-engine","title":"Installing the Selenium Engine","text":"This section assumes that you already have a working installation of SpiraTest or SpiraTeam and have installed RemoteLaunch on the various test automation hosts following the instructions in RemoteLaunch Guide. Once those prerequisites are in place, please follow these steps:
Click the \"Add\" button to enter the new test automation engine details page. The fields required are as follows:
Name: This is the short display name of the automation engine. It can be anything that is meaningful to your users.
Description: This is the long description of the automation engine. It can be anything that is meaningful to your users. (Optional)
Active: If checked, the engine is active and able to be used for any project.
Token: This needs to be the assigned unique token for the automation engine and is used to tell RemoteLaunch which engine to actually use for a given test case. For Selenium this should be SeleniumX where 'X' is the version number of the DLL file that you are using.
Once you have finished, click the \"Insert & Close\" button and you will be taken back to the Test Automation list page, with Selenium listed as an available automation engine.
You can modify the Selenium configuration for each of the specific automation hosts, by right-clicking on the RemoteLaunch icon in the system tray and choosing \"Configuration\". That will bring up the RemoteLaunch configuration page.
a) Selenium-RC 1.0
The Selenium 1.0 engine adds its own tab to this page which allows you to configure how Selenium operates:
The following fields can be specified on this screen:
Server Host -- This should be the name / IP address of the Selenium server. Typically this will be localhost because RemoteLaunch is usually installed on the Selenium server itself.
Server Port -- This should be set to the custom port that the Selenium server uses as a proxy when intercepting requests to the browser. The default value is 4444.
Browser String -- This needs to be the name of the browser that the Selenium server will launch. Common values include:
*firefox -- This will launch the Firefox web browser
*iexplore -- This will launch the Microsoft Internet Explorer web browser
*safari -- This will launch the Apple Safari web browser
Browser URL -- This needs to be the initial URL that you want the browser to open to
a) Selenium WebDriver 2.x
The Selenium 2.x engine adds its own tab to this page which allows you to configure how Selenium operates:
The following fields can be specified on this screen:
Browser Type -- This needs to be set to the type of browser that the Selenium webdriver will launch.
Browser URL -- This needs to be the initial URL that you want the browser to open to
"},{"location":"RemoteLaunch-User-Guide/Selenium/#setting-up-the-automated-test-cases","title":"Setting up the Automated Test Cases","text":"This section describes the process for setting up a test case in SpiraTeam for automation and either linking it to an existing Selenium test script file or entering a Selenium test script directly into SpiraTeam.
"},{"location":"RemoteLaunch-User-Guide/Selenium/#attaching-a-selenium-test-script","title":"Attaching a Selenium Test Script","text":"First you need to display the list of test cases in SpiraTeam (by clicking Testing > Test Cases) and then add a new test case. Once you have added the new test case, click on it and select the \"Automation\" tab:
You need to enter the following fields:
Automation Engine - Choose the Selenium Automation Engine that you created in the previous section from the drop-down list.
Script Type -- This should be set to Attached for this case
Filename -- Since the test script is going to be entered directly into SpiraTeam you can enter any name you like for the filename as long as it's logical and memorable.
Document Type -- you can choose which document type the automated test script will be categorized under.
Document Folder -- you can choose which document folder the automated test script will be stored in.
Version -- The version of the test script (1.0 is used if no value specified)
Test Script -- This needs to contain the complete Selenium test script written in Selenium IDE Selenese. Selenium IDE test scripts consist of three parts:
The command
The target of the command
The data to be used
You should enter the three components on each line separated by the Pipe (|) character. If you need to use a pipe character inside any of the components you can escape it with a backslash (\\|).
An example command would be type|q|hello
If the command doesn't need all three components, you can simply leave it out (for example open||http://www.inflectra.com)
If you would like to have SpiraTeam pass any parameter values to this test script (this will be discussed in more detail later) you can specify them by using the syntax ${parameterName}.
A complete sample script is illustrated below:
open||http://www.google.com/webhp
assertTitle||Google
type|q|${query}
click|btnG
waitForPageToLoad||5000
isTextPresent||${matchtext}
Once you are happy with the values, click [Save] to update the test case. Now you are ready to schedule the automated test case for execution.
"},{"location":"RemoteLaunch-User-Guide/Selenium/#linking-a-selenium-test-script","title":"Linking a Selenium Test Script","text":"First you need to display the list of test cases in SpiraTeam (by clicking Testing > Test Cases) and then add a new test case. Once you have added the new test case, click on it and select the \"Automation\" tab:
You need to enter the following fields:
Automation Engine - Choose the Selenium Automation Engine that you created in the previous section from the drop-down list.
Script Type -- This should be set to Linked for this case
Filename -- This needs to be the full path to the Selenium IDE test script file. To make this easier across different machines, you can use several constants for standard Windows locations:
[MyDocuments] -- The user's \"My Documents\" folder. The user indicated is the user that ran RemoteLaunch.
[CommonDocuments] -- The Public Document's folder.
[DesktopDirectory] -- The user's Desktop folder. The user indicated is the user that ran RemoteLaunch.
[ProgramFiles] -- Translated to the Program Files directory. For 64-bit machines, it's the 64-bit directory.
[ProgramFilesX86] -- Translated to the 32-bit Program Files directory.
Document Type -- If using SpiraTeam (not SpiraTest) you can choose which document type the automated test script will be categorized under.
Document Folder -- If using SpiraTeam (not SpiraTest) you can choose which document folder the automated test script will be stored in.
Version -- The version of the test script (1.0 is used if no value specified)
Test Script -- This is not used when you are using the linked test script option
The linked test script needs to be an HTML document that contains a table with three columns. Each row corresponds to a single Selenium action. Each of the columns in the row corresponds to the three Selenium command components:
The command
The target of the command
The data to be used
An example Selenium test script is illustrated below:
<html>\n <body>\n <table>\n <tr>\n <td>\n open\n </td>\n <td> \n </td>\n <td>\n http://www.google.com/webhp\n </td>\n </tr>\n <tr>\n <td>\n assertTitle</td>\n <td> \n </td>\n <td>\n Google</td>\n </tr>\n <tr>\n <td>\n type</td>\n <td> \n q</td>\n <td>\n ${query}</td>\n </tr>\n <tr>\n <td>\n click</td>\n <td> \n btnG</td>\n <td>\n </td>\n </tr>\n <tr>\n <td>\n waitForPageToLoad</td>\n <td> \n </td>\n <td>\n 5000</td>\n </tr>\n <tr>\n <td>\n isTextPresent</td>\n <td> \n </td>\n <td>\n ${matchtext}</td>\n </tr>\n </table>\n </body>\n</html>\nWhen opened in an HTML editing tool it looks like:
open http://www.google.com/webhp assertTitle Google type q ${query} click btnG waitForPageToLoad 5000 isTextPresent ${matchtext}If you would like to have SpiraTeam pass any parameter values to this test script (this will be discussed in more detail later) you can specify them by using the syntax ${parameterName}.
An example parameterized command is displayed in the third and sixth rows of the table above (${query} and ${matchtext}).
Once you are happy with the values, click [Save] to update the test case. Now you are ready to schedule the automated test case for execution.
"},{"location":"RemoteLaunch-User-Guide/Selenium/#using-parameterized-test-cases","title":"Using Parameterized Test Cases","text":"There is an advanced feature of SpiraTest/Team and RemoteLaunch that lets you pass parameters from SpiraTeam to your Selenium automated test script. This is very useful if you want to have a data-driven Selenium test script that be executed multiple times with different parameter values.
To setup the automated test case for parameters, click on the \"Test Steps\" tab and click on \"Edit Parameters\":
The name of the parameter ${login} needs to match the name of the input parameter defined within the Selenium script.
"},{"location":"RemoteLaunch-User-Guide/Selenium/#executing-the-selenium-test-sets-from-spirateam","title":"Executing the Selenium Test Sets from SpiraTeam","text":"There are two ways to execute automated test cases in SpiraTeam:
Schedule the test cases to be executed on a specific computer (local or remote) at a date/time in the future
Execute the test cases right now on the local computer.
We shall outline both of these two scenarios in this section. However first we need to setup the appropriate automation hosts and test sets in SpiraTeam:
"},{"location":"RemoteLaunch-User-Guide/Selenium/#configuring-the-automation-hosts-and-test-sets","title":"Configuring the Automation Hosts and Test Sets","text":"Go to Testing > Automation Hosts in SpiraTeam to display the list of automation hosts:
Make sure that you have created an Automation Host for each computer that is going to run an automated test case. The name and description can be set to anything meaningful, but the Token field must be set to the same token that is specified in the RemoteLaunch application on that specific machine.
Once you have at least one Automation Host configured, go to Testing > Test Sets to create the test sets that will contain the automated test case:
Note: Unlike manual test cases, automated test cases must be executed within a test set -- they cannot be executed directly from the test case.
Create a new Test Set to hold the Selenium automated test cases and click on its hyperlink to display the test set details page:
You need to add at least one automated test case to the test set and then configure the following fields:
Automation Host -- This needs to be set to the name of the automation host that will be running the automated test set.
Planned Date -- The date and time that you want the scenario to begin. (Note that multiple test sets scheduled at the exact same time will be scheduled by Test Set ID order.)
Status -- This needs to be set to \"Not Started\" for RemoteLaunch to pick up the scheduled test set. When you change the Planned Date, the status automatically switches back to \"Not Started\"
Type -- This needs to be set to \"Automated\" for automated testing
If you have parameterized test cases inside the automated test set you can set their values in three different ways:
Test Set Parameter Values -- this lets you set the same value of a parameter for all the test cases in the test set:
Test Case Parameter Values -- this lets you set a specific value for a parameter for a particular test case in the test set:
You set these values, by right-clicking on a row and choosing \"Edit Parameters\":
Once you have set the various test set fields (as described above), the Remote Launch instances will periodically poll SpiraTeam for new test sets. Once they retrieve the new test set, they will add it to their list of test sets to execute. Once execution begins they will change the status of the test set to \"In Progress\", and once test execution is done, the status of the test set will change to either \"Completed\" -- the automation engine could be launched and the test has completed -- or \"Blocked\" -- RemoteLaunch was not able to start the automation engine.
If you want to immediately execute the test case on your local computer, instead of setting the \"Automation Host\", \"Status\" and \"Planned Date\" fields, you can instead click the [Execute] icon on the test set itself. This will cause RemoteLaunch on the local computer to immediately start executing the current test set.
In either case, once all the test cases in the test set have been completed, the status of the test set will switch to \"Completed\" and the individual test cases in the set will display a status based on the results of the Selenium test:
Passed -- The Selenium automated test ran successfully and all the test conditions in the test script passed
Failed -- The Selenium automated test ran successfully, but at least one test condition in the test script failed.
Blocked -- The Selenium automated test did not run successfully
If you receive the \"Blocked\" status for either the test set or the test cases you should open up the Windows Application Event Log on the computer running RemoteLaunch and look in the event log for error messages.
Note: While the tests are executing you may see browser windows launch as the Selenium server executes the appropriate tests.
Once the tests have completed, you can log back into SpiraTeam and see the execution status of your test cases. If you click on a Test Run that was generated by Selenium, you will see the following information:
This screen indicates the status of the test run that was reported back from Selenium together with any messages or other information. The execution status will be set to PASSED if all the Selenium commands report back OK and all the tests passed. If any of the commands failed or the tests don't pass, the overall execution status will be listed as FAILED.
The Message field will contain a summary of the number of commands executed and the number of failed commands, with the large details box containing the full command execution log as reported back from Selenium:
open (, http://www.google.com/webhp) - OK
assertTitle (, Google) - OK
type (q, Philomene Long) - OK
click (btnG, ) - OK
waitForPageToLoad (, 5000) - OK
isTextPresent (, Philomene Long) - OK,true
Congratulations... You are now able to run Selenium automated web tests and have the results be recorded within SpiraTest / SpiraTeam.
"},{"location":"RemoteLaunch-User-Guide/SmarteScript/","title":"SmarteScript","text":"SmarteSoft\u2122 SmarteScript\u2122 (hereafter SmarteScript) is a Graphic User Interface (GUI) script-free functional test automation system that lets you record application operations by capturing the various testable objects of the application and then playback the operations to automatically test the application.
This section describes how you can use SpiraTest / SpiraTeam (hereafter SpiraTeam) together with RemoteLaunch to schedule and remotely launch instances of SmarteScript on different computers and have the testing results be transmitted back to SpiraTeam. This allows you to extend your SpiraTeam's test management capabilities to include automated SmarteScript tests.
Note: This integration requires at least version 3.0 of SpiraTest/Team and version 5.0 of SmarteScript.
"},{"location":"RemoteLaunch-User-Guide/SmarteScript/#installing-the-smartescript-engine","title":"Installing the SmarteScript Engine","text":"This section assumes that you already have a working installation of SpiraTest or SpiraTeam and have installed RemoteLaunch on the various test automation hosts following the instructions in RemoteLaunch Guide. Once those prerequisites are in place, please follow these steps:
Download and extract the SmarteScriptAutomationEngine.zip file from the Inflectra website and locate the appropriate SmarteScriptX.dll for the version of SmarteScript that you are using.
If you don't see the version listed, just use the nearest version that is lower than your current version.
Copy the file \"SmarteScriptX.dll\" (where X is the appropriate version) into the \"extensions\" sub-folder of the RemoteLaunch installation.
Log in to SpiraTeam as a system administrator and go into SpiraTeam main Administration page and click on the \"Test Automation\" link under Integration.
Click the \"Add\" button to enter the new test automation engine details page. The fields required are as follows:
Name: This is the short display name of the automation engine. It can be anything that is meaningful to your users.
Description: This is the long description of the automation engine. It can be anything that is meaningful to your users. (Optional)
Active: If checked, the engine is active and able to be used for any project.
Token: This needs to be the assigned unique token for the automation engine and is used to tell RemoteLaunch which engine to actually use for a given test case. For SmarteScript this should be SmarteScriptX where 'X' is the version number of the DLL file that you are using.
Once you have finished, click the \"Insert & Close\" button and you will be taken back to the Test Automation list page, with SmarteScript listed as an available automation engine.
This section describes the process for setting up a test case in SpiraTeam for automation and linking it to an automated SmarteScript test script.
First you need to display the list of test cases in SpiraTeam (by clicking Testing > Test Cases) and then add a new test case. Once you have added the new test case, click on it and select the \"Automation\" tab:
You need to enter the following fields:
Automation Engine - Choose the SmarteScript Automation Engine that you created in the previous section from the drop-down list.
Script Type -- This should be set to Linked as the integration with SmarteScript only supports referencing SmarteScript test script file (.ses) and not physically uploading the test scripts into SpiraTeam.
Filename -- This needs to be the full path to the SmarteScript test script (i.e. the .ses file that you open in SmarteScript to run the test). To make this easier across different machines, you can use several constants for standard Windows locations (see example in screenshot):
[MyDocuments] -- The user's \"My Documents\" folder. The user indicated is the user that ran RemoteLaunch.
[CommonDocuments] -- The Public Document's folder.
[DesktopDirectory] -- The user's Desktop folder. The user indicated is the user that ran RemoteLaunch.
[ProgramFiles] -- Translated to the Program Files directory. For 64-bit machines, it's the 64-bit directory.
[ProgramFilesX86] -- Translated to the 32-bit Program Files directory.
Document Type -- If using SpiraTeam (not SpiraTest) you can choose which document type the automated test script will be categorized under.
Document Folder -- If using SpiraTeam (not SpiraTest) you can choose which document folder the automated test script will be stored in.
Version -- The version of the test script (1.0 is used if no value specified)
Test Script -- This is not used with the SmarteScript Engine since it only supports linked test scripts.
Once you are happy with the values, click [Save] to update the test case. Now you are ready to schedule the automated test case for execution.
"},{"location":"RemoteLaunch-User-Guide/SmarteScript/#using-parameterized-test-cases","title":"Using Parameterized Test Cases","text":"SmarteScript does not support the passing of input test parameters so the SmarteScript automation engine does not support this feature of SpiraTeam or RemoteLaunch.
"},{"location":"RemoteLaunch-User-Guide/SmarteScript/#executing-the-smartescript-test-sets-from-spirateam","title":"Executing the SmarteScript Test Sets from SpiraTeam","text":"There are two ways to execute automated test cases in SpiraTeam:
Schedule the test cases to be executed on a specific computer (local or remote) at a date/time in the future
Execute the test cases right now on the local computer.
We shall outline both of these two scenarios in this section. However first we need to setup the appropriate automation hosts and test sets in SpiraTeam:
"},{"location":"RemoteLaunch-User-Guide/SmarteScript/#configuring-the-automation-hosts-and-test-sets","title":"Configuring the Automation Hosts and Test Sets","text":"Go to Testing > Automation Hosts in SpiraTeam to display the list of automation hosts:
Make sure that you have created an Automation Host for each computer that is going to run an automated test case. The name and description can be set to anything meaningful, but the Token field must be set to the same token that is specified in the RemoteLaunch application on that specific machine.
Once you have at least one Automation Host configured, go to Testing > Test Sets to create the test sets that will contain the automated test case:
Note: Unlike manual test cases, automated test cases must be executed within a test set -- they cannot be executed directly from the test case.
Create a new Test Set to hold the SmarteScript automated test cases and click on its hyperlink to display the test set details page:
You need to add at least one automated test case to the test set and then configure the following fields:
Automation Host -- This needs to be set to the name of the automation host that will be running the automated test set.
Planned Date -- The date and time that you want the scenario to begin. (Note that multiple test sets scheduled at the exact same time will be scheduled by Test Set ID order.)
Status -- This needs to be set to \"Not Started\" for RemoteLaunch to pick up the scheduled test set. When you change the Planned Date, the status automatically switches back to \"Not Started\"
Type -- This needs to be set to \"Automated\" for automated testing
Once you have set the various test set fields (as described above), the Remote Launch instances will periodically poll SpiraTeam for new test sets. Once they retrieve the new test set, they will add it to their list of test sets to execute. Once execution begins they will change the status of the test set to \"In Progress\", and once test execution is done, the status of the test set will change to either \"Completed\" -- the automation engine could be launched and the test has completed -- or \"Blocked\" -- RemoteLaunch was not able to start the automation engine.
If you want to immediately execute the test case on your local computer, instead of setting the \"Automation Host\", \"Status\" and \"Planned Date\" fields, you can instead click the [Execute] icon on the test set itself. This will cause RemoteLaunch on the local computer to immediately start executing the current test set.
In either case, once all the test cases in the test set have been completed, the status of the test set will switch to \"Completed\" and the individual test cases in the set will display a status based on the results of the SmarteScript test:
Passed -- The SmarteScript automated test ran successfully and all the test conditions in the test script passed
Failed -- The SmarteScript automated test ran successfully, but at least one test condition in the test script failed.
Blocked -- The SmarteScript automated test did not run successfully
If you receive the \"Blocked\" status for either the test set or the test cases you should open up the Windows Application Event Log on the computer running RemoteLaunch and look in the event log for error messages.
Note: While the tests are executing you may see browser or application windows launch as SmarteScript executes the appropriate tests.
Once the tests have completed, you can log back into SpiraTeam and see the execution status of your test cases. If you click on a Test Run that was generated by SmarteScript, you will see the following information:
This screen indicates the status of the test run that was reported back from SmarteScript together with any messages or other information. The Test Name indicates the name of the test inside SmarteScript, and the execution status corresponds the matching status inside SmarteScript.
Congratulations... You are now able to run SmarteScript automated functional tests and have the results be recorded within SpiraTest / SpiraTeam.
"},{"location":"RemoteLaunch-User-Guide/SoapUI/","title":"SoapUI (ReadyAPI)","text":"SmartBear SoapUI / ReadyAPI (hereafter SoapUI) is an open source Web Service testing tool for Service Oriented Architectures (SOAs). There is also a Pro version (Now known as ReadyAPI) that is released as a commercial product. Its functionality mainly covers Web Service Inspection, Invoking, Development, Simulation and Mocking, Functional testing, Load and Compliance testing. Productivity enhancement features can be found in ReadyAPI (previously known as SoapUI Pro).
This section describes how you can use SpiraPlan / SpiraTest / SpiraTeam (hereafter SpiraTeam) together with RemoteLaunch to schedule and remotely launch instances of soapUI on different computers and have the testing results be transmitted back to SpiraTeam. This allows you to extend your SpiraTeam's test management capabilities to include automated web service testing.
Note: This integration requires at least version 4.0 of SpiraPlan/Team/Test and an instance of SoapUI, SoapUI Pro, or ReadyAPI running on a Windows\u00ae platform.
"},{"location":"RemoteLaunch-User-Guide/SoapUI/#installing-the-soapui-engine","title":"Installing the SoapUI Engine","text":"This section assumes that you already have a working installation of SpiraTest or SpiraTeam and have installed RemoteLaunch on the various test automation hosts following the instructions in RemoteLaunch Guide. Once those prerequisites are in place, please follow these steps:
Download and extract the SoapUIEngine.zip file from the Inflectra website.
Extract the file \"soapUIEngine.dll\" from the compressed archive into the \"extensions\" sub-folder of the RemoteLaunch installation.
Log in to SpiraTeam as a system administrator and go into SpiraTeam main Administration page and click on the \"Test Automation\" link under Integration.
Click the \"Add\" button to enter the new test automation engine details page. The fields required are as follows:
Name: This is the short display name of the automation engine. It can be anything that is meaningful to your users. Description: This is the long description of the automation engine. It can be anything that is meaningful to your users. (Optional)
Active: If checked, the engine is active and able to be used for any project.
Token: This needs to be the assigned unique token for the automation engine and is used to tell RemoteLaunch which engine to actually use for a given test case. For soapUI this should be SoapUI.
Once you have finished, click the \"Insert & Close\" button and you will be taken back to the Test Automation list page, with SoapUI listed as an available automation engine.
You will need to modify the SoapUI configuration for each of the specific automation hosts, by right-clicking on the RemoteLaunch icon in the system tray and choosing \"Configuration\". That will bring up the RemoteLaunch configuration page. The SoapUI engine adds its own tab to this page which allows you to configure how SoapUI operates:
The following fields can be specified on this screen:
SOAP-UI Location -- This should be SOAP-UI Bin folder that contains the \"TestRunner.bat\" batch file that will be used to actually run the automated tests.
Installation Type -- This allows you to take advantage of the enhanced reporting available in the commercial \"Pro\" edition of SoapUI. Check the \"SOAP-UI Pro Installation\" box only if you are using the commercial version of SoapUI (known as SoapUI Pro).
Execution Type -- If this is a LoadUI performance test rather than a standard SoapUI functional test, check the box and RemoteLaunch will know to parse the load-test report format.
Trace Logging -- Normally this can be left unchecked unless you are diagnosing configuration issues and need additional logging.
"},{"location":"RemoteLaunch-User-Guide/SoapUI/#setting-up-the-automated-test-cases","title":"Setting up the Automated Test Cases","text":"This section describes the process for setting up a test case in SpiraTeam for automation and linking it to an existing SoapUI test suite and test case.
"},{"location":"RemoteLaunch-User-Guide/SoapUI/#linking-a-soapui-test-script","title":"Linking a SoapUI Test Script","text":"First you need to display the list of test cases in SpiraTeam (by clicking Testing > Test Cases) and then add a new test case. Once you have added the new test case, click on it and expand the \"Automation\" section of the Test Case Overview tab:
You need to enter the following fields:
Automation Engine - Choose the SoapUI Automation Engine that you created in the previous section from the drop-down list.
Script Type -- This should be set to Linked for this case
Filename -- This needs to be the full path to the SoapUi test project XML file or composite folder together with the test suite name and test case name separated by the pipe (|) symbol. You can also pass custom command line switches as an optional final segment
For standard tests, you use the format:
Project XML File|Test Suite Name|Test Case Name|Switches
For composite folder tests, you use the format:
Test Folder|Test Suite Name|Test Case Name|Switches
For example if the test suite was named \"Requirements Testing\" and the test case was named \"Get Requirements\" you'd use:
[MyDocuments]\\SpiraTest-4-0-Web-Service-soapui-project.xml|Requirements Testing|Get Requirements
To make this easier across different machines, you can use several constants for standard Windows locations:
[MyDocuments] -- The user's \"My Documents\" folder. The user indicated is the user that ran RemoteLaunch.
[CommonDocuments] -- The Public Document's folder.
[DesktopDirectory] -- The user's Desktop folder. The user indicated is the user that ran RemoteLaunch.
[ProgramFiles] -- Translated to the Program Files directory. For 64-bit machines, it's the 64-bit directory.
[ProgramFilesX86] -- Translated to the 32-bit Program Files directory.
Document Type -- You can choose which document type the automated test script will be categorized under.
Document Folder -- You can choose which document folder the automated test script will be stored in.
Version -- The version of the test script (1.0 is used if no value specified)
Test Script -- This is not used when you are using the linked test script option
Note: The example filename shown above was taken from a test project in SoapUI that has the following structure:
Once you are happy with the values, click [Save] to update the test case. Now you are ready to schedule the automated test case for execution.
"},{"location":"RemoteLaunch-User-Guide/SoapUI/#using-parameterized-test-cases","title":"Using Parameterized Test Cases","text":"There is an advanced feature of SpiraTest/Team and RemoteLaunch that lets you pass parameters from SpiraTeam to your SoapUI automated test. This is very useful if you have a data-driven SoapUI test that has custom project properties used that you would like to change based on the test.
To setup the automated test case for parameters, click on the \"Test Steps\" tab and click on \"Edit Parameters\":
The name of the parameter ${login} needs to match the name of the custom parameter defined in the SoapUI project properties. Invalid parameters will be silently ignored by the SoapUI engine. Parameters must have a unique name. Note that the plugin currently only supports \"Project Properties\" and not Global or System Properties.
"},{"location":"RemoteLaunch-User-Guide/SoapUI/#executing-the-soapui-test-sets-from-spirateam","title":"Executing the SoapUI Test Sets from SpiraTeam","text":"There are three ways to execute automated test cases in SpiraTeam:
Schedule the test cases to be executed on a specific computer (local or remote) at a date/time in the future
Execute the test cases right now on the local computer.
Execute the test cases from the command-line or a build script
We shall outline each of these three scenarios in this section. However first we need to setup the appropriate automation hosts and test sets in SpiraTeam:
"},{"location":"RemoteLaunch-User-Guide/SoapUI/#configuring-the-automation-hosts-and-test-sets","title":"Configuring the Automation Hosts and Test Sets","text":"Go to Testing > Automation Hosts in SpiraTeam to display the list of automation hosts:
Make sure that you have created an Automation Host for each computer that is going to run an automated test case. The name and description can be set to anything meaningful, but the Token field must be set to the same token that is specified in the RemoteLaunch application on that specific machine.
Once you have at least one Automation Host configured, go to Testing > Test Sets to create the test sets that will contain the automated test case:
Note: Unlike manual test cases, automated test cases must be executed within a test set -- they cannot be executed directly from the test case.
Create a new Test Set to hold the SoapUI automated test cases and click on its hyperlink to display the test set details page:
You need to add at least one automated test case to the test set and then configure the following fields:
Automation Host -- This needs to be set to the name of the automation host that will be running the automated test set.
Planned Date -- The date and time that you want the scenario to begin. (Note that multiple test sets scheduled at the exact same time will be scheduled by Test Set ID order.)
Status -- This needs to be set to \"Not Started\" for RemoteLaunch to pick up the scheduled test set. When you change the Planned Date, the status automatically switches back to \"Not Started\"
Type -- This needs to be set to \"Automated\" for automated testing
If you have parameterized test cases inside the automated test set you can set their values in three different ways:
Test Set Parameter Values -- this lets you set the same value of a parameter for all the test cases in the test set:
Test Case Parameter Values -- this lets you set a specific value for a parameter for a particular test case in the test set:
You set these values, by right-clicking on a row and choosing \"Edit Parameters\":
Once you have set the various test set fields (as described above), the Remote Launch instances will periodically poll SpiraTeam for new test sets. Once they retrieve the new test set, they will add it to their list of test sets to execute. Once execution begins they will change the status of the test set to \"In Progress\", and once test execution is done, the status of the test set will change to either \"Completed\" -- the automation engine could be launched and the test has completed -- or \"Blocked\" -- RemoteLaunch was not able to start the automation engine.
If you want to immediately execute the test case on your local computer, instead of setting the \"Automation Host\", \"Status\" and \"Planned Date\" fields, you can instead click the [Execute] icon on the test set itself. This will cause RemoteLaunch on the local computer to immediately start executing the current test set.
If you want to run the tests as part of a build script, just call RemoteLaunch.exe with the appropriate test set id passed into the command-line:
RemoteLaunch.exe --testset:18
In all cases, once all the test cases in the test set have been completed, the status of the test set will switch to \"Completed\" and the individual test cases in the set will display a status based on the results of the SoapUI test:
Passed -- The SoapUI automated test ran successfully and all the assertions in the test script passed
Failed -- The SoapUI automated test ran successfully, but at least one assertion in the test script failed.
Blocked -- The SoapUI automated test did not run successfully
If you receive the \"Blocked\" status for either the test set or the test cases you should open up the Windows Application Event Log on the computer running RemoteLaunch and look in the event log for error messages.
Note: While the tests are executing you may see application or browser windows launch as the SoapUI server executes the appropriate tests.
Once the tests have completed, you can log back into SpiraTeam and see the execution status of your test cases. If you click on a Test Run that was generated by SoapUI, you will see the following information:
This screen indicates the status of the test run that was reported back from SoapUI together with any messages or other information. The execution status will be set according to the worst-case assessment reported back from SoapUI. If you have zero(0) failures, then the status will display as Passed, otherwise it will display as Failed.
Under Console Output section you will see more detailed logging information (in both SoapUI and SoapUI Pro):
The Message field will contain a summary of the number of test steps completed, the number of assertions and the number of failed assertions. The Details field will contain the detailed trace of what happened, captured from the summary output log that is generated by SoapUI.
SoapUI Pro
If you have the commercial SoapUI Pro product and have configured RemoteLaunch so that it knows to use SoapUI Pro, in addition, the Test Steps section of the test run will contain more detailed reporting:
Where each test step corresponds to a step recorded in the SoapUI Pro results file.
Congratulations... You are now able to run SoapUI automated web-service tests and have the results be recorded within SpiraTest / SpiraTeam.
"},{"location":"RemoteLaunch-User-Guide/Squish/","title":"Squish","text":"Froglogic\u00ae Squish\u00ae (hereafter Squish) is a functional test automation system that lets you record application operations and generate test automation scripts in a variety of different scripting languages (JavaScript, Tcl, Python) that can be used to playback the test script against the test application.
This section describes how you can use SpiraTest / SpiraTeam (hereafter SpiraTeam) together with RemoteLaunch to schedule and remotely launch instances of Squish on different computers and have the testing results be transmitted back to SpiraTeam. This allows you to extend your SpiraTeam's test management capabilities to include automated Squish tests.
Note: This integration requires at least version 3.0 of SpiraTest/Team and version 4.0 of Squish running on a Windows\u00ae platform.
"},{"location":"RemoteLaunch-User-Guide/Squish/#installing-the-squish-engine","title":"Installing the Squish Engine","text":"This section assumes that you already have a working installation of SpiraTest or SpiraTeam and have installed RemoteLaunch on the various test automation hosts following the instructions in RemoteLaunch Guide. Once those prerequisites are in place, please follow these steps:
Download and extract the SquishAutomationEngine.zip file from the Inflectra website and locate the appropriate SquishX.dll for the version of Squish that you are using.
Copy the file \"SquishX.dll\" (where X is the appropriate version) into the \"extensions\" sub-folder of the RemoteLaunch installation.
Log in to SpiraTeam as a system administrator and go into SpiraTeam main Administration page and click on the \"Test Automation\" link under Integration.
Click the \"Add\" button to enter the new test automation engine details page. The fields required are as follows:
Name: This is the short display name of the automation engine. It can be anything that is meaningful to your users.
Description: This is the long description of the automation engine. It can be anything that is meaningful to your users. (Optional)
Active: If checked, the engine is active and able to be used for any project.
Token: This needs to be the assigned unique token for the automation engine and is used to tell RemoteLaunch which engine to actually use for a given test case. For Squish this should be SquishX where 'X' is the version number of the DLL file that you are using.
Once you have finished, click the \"Insert & Close\" button and you will be taken back to the Test Automation list page, with Squish listed as an available automation engine.
You will need to modify the Squish configuration for each of the specific automation hosts, by right-clicking on the RemoteLaunch icon in the system tray and choosing \"Configuration\". That will bring up the RemoteLaunch configuration page. The Squish engine adds its own tab to this page which allows you to configure how Squish operates:
The following fields can be specified on this screen:
Squish Location -- This should be folder containing the \"SquishRunner\" executable that will be used to actually run the automated tests.
Server Host -- This field can be set to the name of a remote Squish server if you did not install RemoteLaunch on the machine running the Squish server (optional).
Server Port -- This field can be set to the port being used by a remote Squish server if you did not install RemoteLaunch on the machine running the Squish server (optional).
Trace Logging -- This checkbox can be selected if you need to provide debugging information to Inflectra support personnel. Normally this should remain unchecked
Note: In most cases, the second and third fields can be left empty.
"},{"location":"RemoteLaunch-User-Guide/Squish/#setting-up-the-automated-test-cases","title":"Setting up the Automated Test Cases","text":"This section describes the process for setting up a test case in SpiraTeam for automation and either linking it to an existing Squish test suite, test case or entering a Squish test script directly into SpiraTeam.
Note: that the Squish engine only supports passing parameters to an attached test script and not to a linked test script.
"},{"location":"RemoteLaunch-User-Guide/Squish/#attaching-a-squish-test-script","title":"Attaching a Squish Test Script","text":"First you need to display the list of test cases in SpiraTeam (by clicking Testing > Test Cases) and then add a new test case. Once you have added the new test case, click on it and select the \"Automation\" tab:
You need to enter the following fields:
Automation Engine - Choose the Squish Automation Engine that you created in the previous section from the drop-down list.
Script Type -- This should be set to Attached for this case
Filename -- Since the test script is going to be entered directly into SpiraTeam you can enter any filename you like as long as the file extension matches the scripting language that you're using. After that you need to add any command-line parameters after the filename, separated by a pipe (|) symbol.
For example, to launch a web test using Javascript, you'd use: address_test.js|--wrapper Web
For example, to launch an application test using Python, you'd use: address_test.py|--aut <application>
Document Type -- If using SpiraTeam (not SpiraTest) you can choose which document type the automated test script will be categorized under.
Document Folder -- If using SpiraTeam (not SpiraTest) you can choose which document folder the automated test script will be stored in.
Version -- The version of the test script (1.0 is used if no value specified)
Test Script -- This needs to contain the complete Squish test script. Squish test scripts can be written in JavaScript, Python or TCL.
A complete sample script (illustrating the use of parameters) is illustrated below:
function main()\n{\n// open URL\nloadUrl(\":http://address.icefaces.org/address/\");\n\n// wait for the first entry object to be available\nwaitForObject(\":_id0:title_select-one\");\n\n// check that the submit button is disabled\ntest.compare(findObject(\":_id0:Submit_image\").disabled, true);\n\n// enter data\nselectOption(\":_id0:title_select-one\", \"${title}\");\nsetText(\":_id0:firstName_text\", \"${firstname}\");\nsetText(\":_id0:lastName_text\", \"${lastname}\");\nsetText(\":_id0:city_text\", \"${city}\");\n\n// check that after entering city, the state is automatically chosen correctly\nvar state = \"${state}\";\nsetFocus(\":_id0:state_text\");\nif (!test.verify(waitFor(\"findObject(':_id0:state_text').value == state\", 10000)))\n{\nclickButton(\":_id0:Reset_image\");\ncontinue;\n}\n\n// input ZIP\nselectOption(\":_id0:zipSelect_select-one\", \"${zip}\");\n\n// check that submit button is enabled now\nsetFocus(\":_id0:lastName_text\");\nif (!test.verify(waitFor(\"findObject(':_id0:Submit_image').disabled == false\", 10000)))\n{\nclickButton(\":_id0:Reset_image\");\n}\n\n// submit\nclickButton(\":_id0:Submit_image\");\n\n// wait for results page\nwaitForContextExists(\":response.iface\");\nwaitForObject(\":_id1:_id3_SPAN\");\n\n// verify that data is stored and displayed correctly\ntest.compare(findObject(\":_id1:_id3_SPAN\").innerText, firstName);\ntest.compare(findObject(\":_id1:_id6_SPAN\").innerText, state);\n\n// close browser\ncloseWindow(\":[Window]\");\n}\nOnce you are happy with the values, click [Save] to update the test case. Now you are ready to schedule the automated test case for execution.
"},{"location":"RemoteLaunch-User-Guide/Squish/#linking-a-squish-test-script","title":"Linking a Squish Test Script","text":"First you need to display the list of test cases in SpiraTeam (by clicking Testing > Test Cases) and then add a new test case. Once you have added the new test case, click on it and select the \"Automation\" tab:
You need to enter the following fields:
Automation Engine - Choose the Squish Automation Engine that you created in the previous section from the drop-down list.
Script Type -- This should be set to Linked for this case
Filename -- This needs to be the full path to the Squish test case or test suite folder.
If specifying a test case folder, you need to also provide the configuration command-line parameters after the filename, separated by a pipe (|) symbol. These are not needed if executing a test suite, since they are contained in the suite.conf file instead.
For example, to launch a web test case you'd use: [ProgramFiles]\\Froglogic\\squish-4.0.1-web-win32\\examples\\web\\suite_examples\\tst_icefaces_addressbook_datadriven|--wrapper Web
For example, to launch a web test suite you'd simply use: [ProgramFiles]\\Froglogic\\squish-4.0.1-web-win32\\examples\\web\\suite_examples
For example, to launch a web test case within a test suite you'd use the path of the test suite, followed by the pipe (|) symbol, followed by the test case name: [ProgramFiles]\\Froglogic\\squish-4.0.1-web-win32\\examples\\web\\suite_examples|tst_icefaces
To make this easier across different machines, you can use several constants for standard Windows locations:
[MyDocuments] -- The user's \"My Documents\" folder. The user indicated is the user that ran RemoteLaunch.
[CommonDocuments] -- The Public Document's folder.
[DesktopDirectory] -- The user's Desktop folder. The user indicated is the user that ran RemoteLaunch.
[ProgramFiles] -- Translated to the Program Files directory. For 64-bit machines, it's the 64-bit directory.
[ProgramFilesX86] -- Translated to the 32-bit Program Files directory.
Document Type -- If using SpiraTeam (not SpiraTest) you can choose which document type the automated test script will be categorized under.
Document Folder -- If using SpiraTeam (not SpiraTest) you can choose which document folder the automated test script will be stored in.
Version -- The version of the test script (1.0 is used if no value specified)
Test Script -- This is not used when you are using the linked test script option
Once you are happy with the values, click [Save] to update the test case. Now you are ready to schedule the automated test case for execution.
"},{"location":"RemoteLaunch-User-Guide/Squish/#using-parameterized-test-cases","title":"Using Parameterized Test Cases","text":"There is an advanced feature of SpiraTest/Team and RemoteLaunch that lets you pass parameters from SpiraTeam to your attached (not linked) Squish automated test script. This is very useful if you want to have a data-driven Squish test script that be executed multiple times with different parameter values.
To setup the automated test case for parameters, click on the \"Test Steps\" tab and click on \"Edit Parameters\":
The name of the parameter ${city} needs to match the name of the parameter defined within the attached Squish script.
"},{"location":"RemoteLaunch-User-Guide/Squish/#executing-the-squish-test-sets-from-spirateam","title":"Executing the Squish Test Sets from SpiraTeam","text":"There are two ways to execute automated test cases in SpiraTeam:
Schedule the test cases to be executed on a specific computer (local or remote) at a date/time in the future
Execute the test cases right now on the local computer.
We shall outline both of these two scenarios in this section. However first we need to setup the appropriate automation hosts and test sets in SpiraTeam:
"},{"location":"RemoteLaunch-User-Guide/Squish/#configuring-the-automation-hosts-and-test-sets","title":"Configuring the Automation Hosts and Test Sets","text":"Go to Testing > Automation Hosts in SpiraTeam to display the list of automation hosts:
Make sure that you have created an Automation Host for each computer that is going to run an automated test case. The name and description can be set to anything meaningful, but the Token field must be set to the same token that is specified in the RemoteLaunch application on that specific machine.
Once you have at least one Automation Host configured, go to Testing > Test Sets to create the test sets that will contain the automated test case:
Note: Unlike manual test cases, automated test cases must be executed within a test set -- they cannot be executed directly from the test case.
Create a new Test Set to hold the Squish automated test cases and click on its hyperlink to display the test set details page:
You need to add at least one automated test case to the test set and then configure the following fields:
Automation Host -- This needs to be set to the name of the automation host that will be running the automated test set.
Planned Date -- The date and time that you want the scenario to begin. (Note that multiple test sets scheduled at the exact same time will be scheduled by Test Set ID order.)
Status -- This needs to be set to \"Not Started\" for RemoteLaunch to pick up the scheduled test set. When you change the Planned Date, the status automatically switches back to \"Not Started\"
Type -- This needs to be set to \"Automated\" for automated testing
If you have parameterized test cases inside the automated test set you can set their values in three different ways:
Test Set Parameter Values -- this lets you set the same value of a parameter for all the test cases in the test set:
Test Case Parameter Values -- this lets you set a specific value for a parameter for a particular test case in the test set:
You set these values, by right-clicking on a row and choosing \"Edit Parameters\":
Once you have set the various test set fields (as described above), the Remote Launch instances will periodically poll SpiraTeam for new test sets. Once they retrieve the new test set, they will add it to their list of test sets to execute. Once execution begins they will change the status of the test set to \"In Progress\", and once test execution is done, the status of the test set will change to either \"Completed\" -- the automation engine could be launched and the test has completed -- or \"Blocked\" -- RemoteLaunch was not able to start the automation engine.
If you want to immediately execute the test case on your local computer, instead of setting the \"Automation Host\", \"Status\" and \"Planned Date\" fields, you can instead click the [Execute] icon on the test set itself. This will cause RemoteLaunch on the local computer to immediately start executing the current test set.
In either case, once all the test cases in the test set have been completed, the status of the test set will switch to \"Completed\" and the individual test cases in the set will display a status based on the results of the Squish test:
Passed -- The Squish automated test ran successfully and all the test conditions in the test script passed
Failed -- The Squish automated test ran successfully, but at least one test condition in the test script failed.
Blocked -- The Squish automated test did not run successfully
If you receive the \"Blocked\" status for either the test set or the test cases you should open up the Windows Application Event Log on the computer running RemoteLaunch and look in the event log for error messages.
Note: While the tests are executing you may see application or browser windows launch as the Squish server executes the appropriate tests.
Once the tests have completed, you can log back into SpiraTeam and see the execution status of your test cases. If you click on a Test Run that was generated by Squish, you will see the following information:
This screen indicates the status of the test run that was reported back from Squish together with any messages or other information. The execution status will be set according to the worst-case assessment reported back from Squish. The various Squish statuses are mapped to their nearest equivalent SpiraTeam statuses as illustrated below:
Squish Status SpiraTeam Status PASS Passed FAIL Failed WARNING Caution FATAL Blocked ERROR Failed
In addition, the Message field will contain a summary of the number of tests completed and the number of tests that reported an error, fatal, fail, pass or warning status.
2010-11-02T16:50:01-04:00 START_TEST suite_examples
2010-11-02T16:50:01-04:00 START_TEST tst_icefaces_addressbook_datadriven
2010-11-02T16:50:05-04:00 PASS Comparison 'true' and 'true' are equal
2010-11-02T16:50:25-04:00 PASS Verified True expression
2010-11-02T16:50:30-04:00 PASS Verified True expression
2010-11-02T16:50:32-04:00 PASS Comparison 'Reginald' and 'Reginald' are equal
2010-11-02T16:50:33-04:00 PASS Comparison 'CA' and 'CA' are equal
2010-11-02T16:50:40-04:00 PASS Comparison 'true' and 'true' are equal
2010-11-02T16:50:59-04:00 PASS Verified True expression
2010-11-02T16:51:09-04:00 PASS Verified True expression
2010-11-02T16:51:12-04:00 PASS Comparison 'Tanja' and 'Tanja' are equal
2010-11-02T16:51:12-04:00 PASS Comparison 'NY' and 'NY' are equal
Congratulations... You are now able to run Squish automated web tests and have the results be recorded within SpiraTest / SpiraTeam.
"},{"location":"RemoteLaunch-User-Guide/TestComplete/","title":"TestComplete","text":"SmarteBear\u2122 TestComplete\u2122 (hereafter TestComplete) is an automated functional test automation system that lets you record application operations and generate test automation scripts in a variety of languages (JavaScript, C#, VBScript). These test scripts can then be used to playback the test script against the test application and verify that it works correctly.
This section describes how you can use SpiraTest / SpiraTeam (hereafter SpiraTeam) together with RemoteLaunch to schedule and remotely launch instances of TestComplete on different computers and have the testing results be transmitted back to SpiraTeam. This allows you to extend your SpiraTeam's test management capabilities to include automated TestComplete tests.
Note: This integration requires at least version 3.0 of SpiraTest/Team and version 8.0 of TestComplete.
"},{"location":"RemoteLaunch-User-Guide/TestComplete/#installing-the-testcomplete-engine","title":"Installing the TestComplete Engine","text":"This section assumes that you already have a working installation of SpiraTest or SpiraTeam and have installed RemoteLaunch on the various test automation hosts following the instructions in RemoteLaunch Guide. Once those prerequisites are in place, please follow these steps:
Download and extract the TestCompleteAutomationEngine.zip file from the Inflectra website and locate the appropriate TestCompleteX.dll or TestExecuteX.dll for the version of TestComplete or TestExecute that you are using.
If you don't see the version listed, just use the nearest version that is lower than your current version.
Copy the file \"TestCompleteX.dll\" or \"TestExecuteX.dll\" (where X is the appropriate version) into the \"extensions\" sub-folder of the RemoteLaunch installation.
Log in to SpiraTeam as a system administrator and go into SpiraTeam main Administration page and click on the \"Test Automation\" link under Integration.
Click the \"Add\" button to enter the new test automation engine details page. The fields required are as follows:
Name: This is the short display name of the automation engine. It can be anything that is meaningful to your users.
Description: This is the long description of the automation engine. It can be anything that is meaningful to your users. (Optional)
Active: If checked, the engine is active and able to be used for any project.
Token: This needs to be the assigned unique token for the automation engine and is used to tell RemoteLaunch which engine to actually use for a given test case. For TestComplete this should be TestCompleteX where 'X' is the version number of the DLL file that you are using. For TestExecute this should be TestExecuteX where 'X' is the version number of the DLL file that you are using.
Note: We only use the major version numbers for the token name. So the DLLs TestComplete9.0.dll and TestComplete9.1.dll would both use Token = \"TestComplete9\".
You can modify the TestComplete configuration for each of the specific automation hosts, by right-clicking on the RemoteLaunch icon in the system tray and choosing \"Configuration\". That will bring up the RemoteLaunch configuration page.
The TestComplete engine adds its own tab to this page which allows you to configure how TestComplete operates:
The following fields can be specified on this screen:
Wait Time -- This should be set to the amount of time TestComplete needs on this workstation to close the currently open test. The default value is 10000ms (10 seconds). If you get error messages that TestComplete is still open, you need to increase this value.
Application Visible -- This allows you to configure whether the TestComplete application is displayed during test execution or is kept hidden. The default is for it to be hidden.
Close TC After Each Test -- When this is selected, the plugin will close the TestComplete application after each test executes. We generally recommend leaving this disabled as the startup and closedown of TestComplete can sometimes interfere with the tests being executed.
"},{"location":"RemoteLaunch-User-Guide/TestComplete/#setting-up-the-automated-test-cases","title":"Setting up the Automated Test Cases","text":"This section describes the process for setting up a test case in SpiraTeam for automation and linking it to an automated TestComplete test script.
First you need to display the list of test cases in SpiraTeam (by clicking Testing > Test Cases) and then add a new test case. Once you have added the new test case, click on it and select the \"Automation\" tab:
You need to enter the following fields:
Automation Engine - Choose the TestComplete Automation Engine that you created in the previous section from the drop-down list.
Script Type -- This should be set to Linked as the integration with TestComplete only supports referencing TestComplete test project/suite file paths and not physically uploading the test scripts into SpiraTeam.
Filename -- This is actually a compound of several different components that need to be entered, separated by the pipe (|) symbol. The syntax depends on whether we want to associate the SpiraTeam test case with a specific project item or with a specific test routine. If you want to use parameterized test cases, you need to link it with a specific routine (see below for more details on parameters).
If you want to execute a specific project item, the filename should consist of
Suite Filename|Project Name|Project Item Name
(e.g. [CommonDocuments]\\TestComplete 7 Samples\\Open Apps\\OrdersDemo\\C#\\TCProject\\Orders.pjs|Orders_C#_C#Script|ProjectTestItem1)
If you want to execute a specific test routine, the filename should consist of
Suite Filename|Project Name|Unit Name|Routine Name
(e.g. [CommonDocuments]\\TestComplete 7 Samples\\Scripts\\Hello\\Hello.pjs|Hello_C#Script|hello_cs|Hello)
In the case of executing a specific test routine, the last component (the routine name) is actually the name of the function in the test script itself.
As illustrated in the examples, for the Test Suite filename, you can use several constants for standard Windows locations to make things easier:
[MyDocuments] -- The user's \"My Documents\" folder. The user indicated is the user that ran RemoteLaunch.
[CommonDocuments] -- The Public Document's folder.
[DesktopDirectory] -- The user's Desktop folder. The user indicated is the user that ran RemoteLaunch.
[ProgramFiles] -- Translated to the Program Files directory. For 64-bit machines, it's the 64-bit directory.
[ProgramFilesX86] -- Translated to the 32-bit Program Files directory.
Document Type -- If using SpiraTeam (not SpiraTest) you can choose which document type the automated test script will be categorized under.
Document Folder -- If using SpiraTeam (not SpiraTest) you can choose which document folder the automated test script will be stored in.
Version -- The version of the test script (1.0 is used if no value specified)
Test Script -- This is not used with the TestComplete Engine since it only supports linked test scripts.
Once you are happy with the values, click [Save] to update the test case. Now you are ready to schedule the automated test case for execution.
"},{"location":"RemoteLaunch-User-Guide/TestComplete/#using-parameterized-test-cases","title":"Using Parameterized Test Cases","text":"There is an advanced feature of SpiraTest/Team and RemoteLaunch that lets you pass parameters from SpiraTeam to your TestComplete automated test script. This is very useful if you have a data-driven TestComplete test script that accepts input parameters. To use this feature you need to use the option described above to link the SpiraTest test case to an explicit test routine inside TestComplete. If you choose the option to link to a Project Item, any parameters passed will be ignored.
To setup the automated test case for parameters, click on the \"Test Steps\" tab and click on \"Edit Parameters\":
Since the parameters in SpiraTeam map to the function arguments inside a TestComplete test script the parameter names need to match the order of the arguments inside TestComplete (i.e. they are matched by position/order not by name).
Therefore we recommend using numbers for the parameter names so that it's easy to see which parameter value will be passed to which argument in the test script function.
"},{"location":"RemoteLaunch-User-Guide/TestComplete/#executing-the-testcomplete-test-sets-from-spirateam","title":"Executing the TestComplete Test Sets from SpiraTeam","text":"There are two ways to execute automated test cases in SpiraTeam:
Schedule the test cases to be executed on a specific computer (local or remote) at a date/time in the future
Execute the test cases right now on the local computer.
We shall outline both of these two scenarios in this section. However first we need to setup the appropriate automation hosts and test sets in SpiraTeam:
"},{"location":"RemoteLaunch-User-Guide/TestComplete/#configuring-the-automation-hosts-and-test-sets","title":"Configuring the Automation Hosts and Test Sets","text":"Go to Testing > Automation Hosts in SpiraTeam to display the list of automation hosts:
Make sure that you have created an Automation Host for each computer that is going to run an automated test case. The name and description can be set to anything meaningful, but the Token field must be set to the same token that is specified in the RemoteLaunch application on that specific machine.
Once you have at least one Automation Host configured, go to Testing > Test Sets to create the test sets that will contain the automated test case:
Note: Unlike manual test cases, automated test cases must be executed within a test set -- they cannot be executed directly from the test case.
Create a new Test Set to hold the TestComplete automated test cases and click on its hyperlink to display the test set details page:
You need to add at least one automated test case to the test set and then configure the following fields:
Automation Host -- This needs to be set to the name of the automation host that will be running the automated test set.
Planned Date -- The date and time that you want the scenario to begin. (Note that multiple test sets scheduled at the exact same time will be scheduled by Test Set ID order.)
Status -- This needs to be set to \"Not Started\" for RemoteLaunch to pick up the scheduled test set. When you change the Planned Date, the status automatically switches back to \"Not Started\"
Type -- This needs to be set to \"Automated\" for automated testing
If you have parameterized test cases inside the automated test set you can set their values in three different ways:
Test Set Parameter Values -- this lets you set the same value of a parameter for all the test cases in the test set:
Test Case Parameter Values -- this lets you set a specific value for a parameter for a particular test case in the test set:
You set these values, by right-clicking on a row and choosing \"Edit Parameters\":
Once you have set the various test set fields (as described above), the Remote Launch instances will periodically poll SpiraTeam for new test sets. Once they retrieve the new test set, they will add it to their list of test sets to execute. Once execution begins they will change the status of the test set to \"In Progress\", and once test execution is done, the status of the test set will change to either \"Completed\" -- the automation engine could be launched and the test has completed -- or \"Blocked\" -- RemoteLaunch was not able to start the automation engine.
If you want to immediately execute the test case on your local computer, instead of setting the \"Automation Host\", \"Status\" and \"Planned Date\" fields, you can instead click the [Execute] icon on the test set itself. This will cause RemoteLaunch on the local computer to immediately start executing the current test set.
In either case, once all the test cases in the test set have been completed, the status of the test set will switch to \"Completed\" and the individual test cases in the set will display a status based on the results of the TestComplete test:
Passed -- The TestComplete automated test ran successfully and all the test conditions in the test script passed
Failed -- The TestComplete automated test ran successfully, but at least one test condition in the test script failed.
Blocked -- The TestComplete automated test did not run successfully
If you receive the \"Blocked\" status for either the test set or the test cases you should open up the Windows Application Event Log on the computer running RemoteLaunch and look in the event log for error messages.
Note: While the tests are executing you may see browser or application windows launch as TestComplete executes the appropriate tests.
Once the tests have completed, you can log back into SpiraTeam and see the execution status of your test cases. If you click on a Test Run that was generated by TestComplete, you will see the following information:
This screen indicates the status of the test run that was reported back from TestComplete together with any messages or other information. The Test Name indicates the name of the test inside TestComplete, and the execution status corresponds to the matching status inside TestComplete as illustrated below:
TestComplete Status SpiraTest Status Passed Passed Failed Failed Warning Caution
In addition, the detailed test report from TestComplete is available in the \"Console Output\" text-box below. It will contain messages such as:
For the most detail, the \"Test Steps\" section will contain a step-by-step breakdown of each action taken in the automated test:
"},{"location":"RemoteLaunch-User-Guide/TestComplete/#screenshot-capture","title":"Screenshot Capture","text":"During the execution of the test, TestComplete will capture screenshots of the application being tested. These screenshots are uploaded to SpiraTest so that you have a complete record of the testing activities:
Congratulations... You are now able to run TestComplete automated functional tests and have the results be recorded within SpiraTest / SpiraTeam.
"},{"location":"RemoteLaunch-User-Guide/TestPartner/","title":"TestPartner","text":"Micro Focus\u2122 TestPartner\u2122 (hereafter TestPartner) is a Graphic User Interface (GUI) functional test automation system that lets you record application operations by capturing the various testable objects of the application and then playback the operations to automatically test the application.
This section describes how you can use SpiraTest / SpiraTeam (hereafter SpiraTeam) together with RemoteLaunch to schedule and remotely launch instances of TestPartner on different computers and have the testing results be transmitted back to SpiraTeam. This allows you to extend your SpiraTeam's test management capabilities to include automated TestPartner tests.
Note: This integration requires at least version 3.0 of SpiraTest/Team and version 6.0 of TestPartner*.*
"},{"location":"RemoteLaunch-User-Guide/TestPartner/#installing-the-testpartner-engine","title":"Installing the TestPartner Engine","text":"This section assumes that you already have a working installation of SpiraTest or SpiraTeam and have installed RemoteLaunch on the various test automation hosts following the instructions in RemoteLaunch Guide. Once those prerequisites are in place, please follow these steps:
Download and extract the TestPartnerAutomationEngine.zip file from the Inflectra website and locate the TestPartner.dll inside the zip archive.
Copy the file \"TestPartner.dll\" into the \"extensions\" sub-folder of the RemoteLaunch installation.
Log in to SpiraTeam as a system administrator and go into SpiraTeam main Administration page and click on the \"Test Automation\" link under Integration.
Click the \"Add\" button to enter the new test automation engine details page. The fields required are as follows:
Name: This is the short display name of the automation engine. It can be anything that is meaningful to your users.
Description: This is the long description of the automation engine. It can be anything that is meaningful to your users. (Optional)
Active: If checked, the engine is active and able to be used for any project.
Token: This needs to be the assigned unique token for the automation engine and is used to tell RemoteLaunch which engine to actually use for a given test case. For TestPartner this should just be TestPartner.
Once you have finished, click the \"Insert & Close\" button and you will be taken back to the Test Automation list page, with TestPartner listed as an available automation engine.
This section describes the process for setting up a test case in SpiraTeam for automation and linking it to an automated TestPartner test script.
First you need to display the list of test cases in SpiraTeam (by clicking Testing > Test Cases) and then add a new test case. Once you have added the new test case, click on it and select the \"Automation\" tab:
You need to enter the following fields:
Automation Engine - Choose the TestPartner Automation Engine that you created in the previous section from the drop-down list.
Script Type -- This should be set to Linked as the integration with TestPartner only supports referencing TestPartner test scripts (stored in the internal database) and not physically uploading the test scripts into SpiraTeam.
Filename -- This needs contain the project and test name from TestPartner with the appropriate parameter name describing which is the project name and which is the test name. The test name can be either a test script of a visual test. The syntax is:
-visualtest <test name> -project <project name> or
-testscript <script name> -project <project name>
Document Type -- If using SpiraTeam (not SpiraTest) you can choose which document type the automated test script will be categorized under.
Document Folder -- If using SpiraTeam (not SpiraTest) you can choose which document folder the automated test script will be stored in.
Version -- The version of the test script (1.0 is used if no value specified)
Test Script -- This is not used with the TestPartner Engine since it only supports linked test scripts.
Once you are happy with the values, click [Save] to update the test case. Now you are ready to schedule the automated test case for execution.
"},{"location":"RemoteLaunch-User-Guide/TestPartner/#using-parameterized-test-cases","title":"Using Parameterized Test Cases","text":"TestPartner does not support the passing of input test parameters so the TestPartner automation engine does not support this feature of SpiraTeam or RemoteLaunch.
"},{"location":"RemoteLaunch-User-Guide/TestPartner/#executing-the-testpartner-test-sets-from-spirateam","title":"Executing the TestPartner Test Sets from SpiraTeam","text":"There are three ways to execute automated test cases in SpiraTeam:
Schedule the test cases to be executed on a specific computer (local or remote) at a date/time in the future
Execute the test cases right now on the local computer.
Execute the test cases from the command-line or a build script
We shall outline each of these three scenarios in this section. However first we need to setup the appropriate automation hosts and test sets in SpiraTeam:
"},{"location":"RemoteLaunch-User-Guide/TestPartner/#configuring-the-automation-hosts-and-test-sets","title":"Configuring the Automation Hosts and Test Sets","text":"Go to Testing > Automation Hosts in SpiraTeam to display the list of automation hosts:
Make sure that you have created an Automation Host for each computer that is going to run an automated test case. The name and description can be set to anything meaningful, but the Token field must be set to the same token that is specified in the RemoteLaunch application on that specific machine.
Once you have at least one Automation Host configured, go to Testing > Test Sets to create the test sets that will contain the automated test case:
Note: Unlike manual test cases, automated test cases must be executed within a test set -- they cannot be executed directly from the test case.
Create a new Test Set to hold the TestPartner automated test cases and click on its hyperlink to display the test set details page:
You need to add at least one automated test case to the test set and then configure the following fields:
Automation Host -- This needs to be set to the name of the automation host that will be running the automated test set.
Planned Date -- The date and time that you want the scenario to begin. (Note that multiple test sets scheduled at the exact same time will be scheduled by Test Set ID order.)
Status -- This needs to be set to \"Not Started\" for RemoteLaunch to pick up the scheduled test set. When you change the Planned Date, the status automatically switches back to \"Not Started\"
Type -- This needs to be set to \"Automated\" for automated testing
Once you have set the various test set fields (as described above), the Remote Launch instances will periodically poll SpiraTeam for new test sets. Once they retrieve the new test set, they will add it to their list of test sets to execute. Once execution begins they will change the status of the test set to \"In Progress\", and once test execution is done, the status of the test set will change to either \"Completed\" -- the automation engine could be launched and the test has completed -- or \"Blocked\" -- RemoteLaunch was not able to start the automation engine.
If you want to immediately execute the test case on your local computer, instead of setting the \"Automation Host\", \"Status\" and \"Planned Date\" fields, you can instead click the [Execute] icon on the test set itself. This will cause RemoteLaunch on the local computer to immediately start executing the current test set.
In either case, once all the test cases in the test set have been completed, the status of the test set will switch to \"Completed\" and the individual test cases in the set will display a status based on the results of the TestPartner test:
Passed -- The TestPartner automated test ran successfully and all the test conditions in the test script passed
Failed -- The TestPartner automated test ran successfully, but at least one test condition in the test script failed.
Blocked -- The TestPartner automated test did not run successfully
If you receive the \"Blocked\" status for either the test set or the test cases you should open up the Windows Application Event Log on the computer running RemoteLaunch and look in the event log for error messages.
Note: While the tests are executing you may see browser or application windows launch as TestPartner executes the appropriate tests.
Once the tests have completed, you can log back into SpiraTeam and see the execution status of your test cases. If you click on a Test Run that was generated by TestPartner, you will see the following information:
This screen indicates the status of the test run that was reported back from TestPartner together with any messages or other information. The Test Name indicates the name of the test inside TestPartner, and the execution status corresponds the matching status inside TestPartner.
Congratulations... You are now able to run TestPartner automated functional tests and have the results be recorded within SpiraTest / SpiraTeam.
"},{"location":"RemoteLaunch-User-Guide/TestingAnywhere/","title":"TestingAnywhere","text":"TestingAnywhere is a powerful and easy to use automated software testing tool that allows users to automate any type of testing. Powerful GUI based recording capabilities and a no-programming required user interface allows testers to quickly set up even complex test cases. A built-in editor allows users to build tests that can be easily edited to allow for changes in the test cases.
This section describes how you can use SpiraTest / SpiraTeam (hereafter SpiraTeam) together with RemoteLaunch to schedule and remotely launch instances of TestingAnywhere on different computers and have the testing results be transmitted back to SpiraTeam. This allows you to extend your SpiraTeam's test management capabilities to include automated TestingAnywhere tests.
Note: This integration requires at least version 4.0 of SpiraTest/Team and RemoteLaunch.
"},{"location":"RemoteLaunch-User-Guide/TestingAnywhere/#installing-the-testinganywhere-engine","title":"Installing the TestingAnywhere Engine","text":"This section assumes that you already have a working installation of SpiraTest or SpiraTeam and have installed RemoteLaunch on the various test automation hosts following the instructions in RemoteLaunch Guide. Once those prerequisites are in place, please follow these steps:
Download and extract the TestingAnywhereEngine.zip file from the Inflectra website and locate the TestingAnywhereAutomationEngine.dll file contained within.
Copy the file \"TestingAnywhereAutomationEngine.dll\" into the \"extensions\" sub-folder of the RemoteLaunch installation.
Log in to SpiraTeam as a system administrator and go into SpiraTeam main Administration page and click on the \"Test Automation\" link under Integration.
Click the \"Add\" button to enter the new test automation engine details page. The fields required are as follows:
Name: This is the short display name of the automation engine. It can be anything that is meaningful to your users.
Description: This is the long description of the automation engine. It can be anything that is meaningful to your users. (Optional)
Active: If checked, the engine is active and able to be used for any project.
Token: This needs to be the assigned unique token for the automation engine and is used to tell RemoteLaunch which engine to actually use for a given test case. For TestingAnywhere this should simply be TestingAnywhere.
Once you have finished, click the \"Insert & Close\" button and you will be taken back to the Test Automation list page, with TestingAnywhere listed as an available automation engine.
You can modify the TestingAnywhere configuration for each of the specific automation hosts, by right-clicking on the RemoteLaunch icon in the system tray and choosing \"Configuration\". That will bring up the RemoteLaunch configuration page.
The TestingAnywhere engine adds its own tab to this page which allows you to configure how TestingAnywhere operates:
The following fields can be specified on this screen:
Player Location -- this is the folder where the TestingAnywhere player (TAPlayer.exe) can be found. Typically it's C:\\Program Files (x86)\\Testing Anywhere 9.0\\Testing Anywhere
Files Location -- This is the folder where the TestingAnywhere test scripts and generated log files will be stored. The currently logged-in user needs to have Read/Write permissions over this folder. Typically it's:
C:\\Documents And Settings\\[UserName]\\My Documents\\Testing Anywhere Files on a Windows XP workstation or Windows 2003 server.
C:\\Users\\[UserName]\\Documents\\Testing Anywhere Files on a Windows Vista, 7, 2008 or 2008 R2 computer.
Trace Logging -- When selected, this will log additional trace and debugging information to the Windows Event Log. This should not be selected in a production environment.
"},{"location":"RemoteLaunch-User-Guide/TestingAnywhere/#setting-up-the-automated-test-cases","title":"Setting up the Automated Test Cases","text":"This section describes the process for setting up a test case in SpiraTeam for automation and linking it to an automated TestingAnywhere test script.
First you need to display the list of test cases in SpiraTeam (by clicking Testing > Test Cases) and then add a new test case. Once you have added the new test case, click on it and select the \"Overview\" tab, and scroll down to the \"Automation\" section:
You need to enter the following fields:
Automation Engine - Choose the TestingAnywhere Automation Engine that you created in the previous section from the drop-down list.
Script Type -- This should be set to Linked as the integration with TestingAnywhere only supports referencing TestingAnywhere test script files and not physically uploading the test scripts into SpiraTeam.
Filename -- This needs to consist of the relative location of the TestingAnywhere test script to the test script root folder.
Document Type -- This allows you to choose which document type the automated test script will be categorized under.
Document Folder --This allows you to choose which document folder the automated test script will be stored in.
Version -- The version of the test script (1.0 is used if no value specified)
Test Script -- This is not used with the TestingAnywhere Engine since it only supports linked test scripts.
Once you are happy with the values, click [Save] to update the test case. Now you are ready to schedule the automated test case for execution.
"},{"location":"RemoteLaunch-User-Guide/TestingAnywhere/#executing-the-testinganywhere-test-sets-from-spirateam","title":"Executing the TestingAnywhere Test Sets from SpiraTeam","text":"There are two ways to execute automated test cases in SpiraTeam:
Schedule the test cases to be executed on a specific computer (local or remote) at a date/time in the future
Execute the test cases right now on the local computer.
We shall outline both of these two scenarios in this section. However first we need to setup the appropriate automation hosts and test sets in SpiraTeam:
"},{"location":"RemoteLaunch-User-Guide/TestingAnywhere/#configuring-the-automation-hosts-and-test-sets","title":"Configuring the Automation Hosts and Test Sets","text":"Go to Testing > Automation Hosts in SpiraTeam to display the list of automation hosts:
Make sure that you have created an Automation Host for each computer that is going to run an automated test case. The name and description can be set to anything meaningful, but the Token field must be set to the same token that is specified in the RemoteLaunch application on that specific machine.
Once you have at least one Automation Host configured, go to Testing > Test Sets to create the test sets that will contain the automated test case:
Note: Unlike manual test cases, automated test cases must be executed within a test set -- they cannot be executed directly from the test case.
Create a new Test Set to hold the TestingAnywhere automated test cases and click on its hyperlink to display the test set details page:
You need to add at least one automated test case to the test set and then configure the following fields:
Automation Host -- This needs to be set to the name of the automation host that will be running the automated test set.
Planned Date -- The date and time that you want the scenario to begin. (Note that multiple test sets scheduled at the exact same time will be scheduled by Test Set ID order.)
Status -- This needs to be set to \"Not Started\" for RemoteLaunch to pick up the scheduled test set. When you change the Planned Date, the status automatically switches back to \"Not Started\"
Type -- This needs to be set to \"Automated\" for automated testing
Once you have set the various test set fields (as described above), the Remote Launch instances will periodically poll SpiraTeam for new test sets. Once they retrieve the new test set, they will add it to their list of test sets to be executed. Once execution begins they will change the status of the test set to \"In Progress\", and once test execution is done, the status of the test set will change to either \"Completed\" -- the automation engine could be launched and the test has completed -- or \"Blocked\" -- RemoteLaunch was not able to start the automation engine.
If you want to immediately execute the test case on your local computer, instead of setting the \"Automation Host\", \"Status\" and \"Planned Date\" fields, you can instead click the [Execute] icon on the test set itself. This will cause RemoteLaunch on the local computer to immediately start executing the current test set.
In either case, once all the test cases in the test set have been completed, the status of the test set will switch to \"Completed\" and the individual test cases in the set will display a status based on the results of the TestingAnywhere test:
Passed -- The TestingAnywhere automated test ran successfully and all the test steps in the test script passed and no assertions were thrown.
Failed -- The TestingAnywhere automated test ran successfully, but at least one test step failed or at least one assertion failed.
Caution -- The TestingAnywhere automated test run successfully, but at least one warning was logged in one of the test steps.
Blocked -- The TestingAnywhere automated test did not run successfully.
If you receive the \"Blocked\" status for either the test set or the test cases you should open up the Windows Application Event Log on the computer running RemoteLaunch and look in the event log for error messages.
Note: While the tests are executing you will see browser windows launch as TestingAnywhere executes the appropriate tests.
Once the tests have completed, you can log back into SpiraTeam and see the execution status of your test cases. If you click on a Test Run that was generated by TestingAnywhere, you will see the following high-level test information:
This screen indicates the status of the test run that was reported back from TestingAnywhere together with the execution date/time.
If you scroll down to the 'Console Output' section, you will see:
Finally, to see the detailed test steps, look under the 'Test Steps' section:
Congratulations... You are now able to run TestingAnywhere automated functional tests and have the results be recorded within SpiraTest / SpiraTeam.
"},{"location":"RemoteLaunch-User-Guide/Tosca/","title":"Tricentis Tosca","text":"Tricentis Tosca is a software testing tool that is used to automate end-to-end testing for software applications. It is developed by Tricentis. Tricentis Tosca combines multiple aspects of software testing to test GUIs and APIs from a business perspective.
You can use SpiraTest together with RemoteLaunch to schedule and remotely launch instances of Tricentis Tosca on different computers and have the testing results be transmitted back to SpiraTest. This allows you to extend your SpiraTest\u2019s test management capabilities to include automated Tosca tests.
This page describes the steps for using SpiraTest with Tosca. The plugin works with all three editions of the Inflectra Spira platform, including SpiraTest, SpiraTeam and SpiraPlan. We will be referring to the product as 'SpiraTest' for brevity.
"},{"location":"RemoteLaunch-User-Guide/Tosca/#installing-the-tosca-engine","title":"Installing the Tosca Engine","text":"This section assumes that you already have a working installation of SpiraTest and have installed RemoteLaunch on the various test automation hosts following the instructions in RemoteLaunch Guide. Once those prerequisites are in place, please follow these steps:
ToscaEngine.dll from inside the zipfile. You may need to right-click on the DLL and choose Unblock in Windows to confirm that you want to use the downloaded file.ToscaEngine.dll into the \"extensions\" sub-folder of the RemoteLaunch installation.Tosca.Next you need to configure the Tosca configuration for each of the specific automation hosts, by right-clicking on the RemoteLaunch icon in the system tray and choosing \"Configuration\". That will bring up the RemoteLaunch configuration page.
The Tosca engine adds its own tab to this page which allows you to configure how Tosca operates:
The following fields can be specified on this screen:
C:\\Program Files (x86)\\TRICENTIS\\Tosca Testsuite\\ToscaCommander\\ToscaCI\\Client\\http://server:8080/DistributionServerService/ManagerService.svcOnce you have configured the plugin, click Save to save your changes.
"},{"location":"RemoteLaunch-User-Guide/Tosca/#setting-up-the-automated-test-cases","title":"Setting up the Automated Test Cases","text":"This section describes the process for setting up a test case in SpiraTest for automation and linking it to an automated Tosca test script.
Due to the way that Tosca executes tests and reports results, we need to actually create two kinds of test case in SpiraTest:
Note: If you only have the first kind of test cases, you will be able to run automated Tosca test suites, but the reporting will be limited to a simple pass/fail for the entire test suite rather than more granular test case level reporting.
"},{"location":"RemoteLaunch-User-Guide/Tosca/#creating-a-test-case-for-launching-a-tosca-suite","title":"Creating a Test Case for Launching a Tosca Suite","text":"Next, display the list of test cases in SpiraTest (by clicking Testing > Test Cases) and then click on the button to add a new test case. In this example, we have called it Tricentis Insurance Website (Test Event) and stored it in the Tosca Suites folder:
Once you have added the new test case, click on it and scroll down to view the \"Automation\" tab:
You need to enter the following fields:
TestEvents=, so that in our example we have the sample test event: TestEvents=Tricentis Insurance WebsiteOnce you are happy with the values, click [Save] to update the test case.
"},{"location":"RemoteLaunch-User-Guide/Tosca/#creating-additional-test-case-for-parsing-the-tosca-results","title":"Creating additional Test Case for Parsing the Tosca Results","text":"We recommend that you create additional test cases to map to specific test cases in the Tosca test suite. This is an optional feature, but if you don't map these test cases, you will not be able to get detailed reporting and test coverage metrics.
To get this additional level of reporting, create one SpiraTest test case for each of the different Tosca test cases in the Tosca suite, for example we created the following:
Each of these SpiraTest test cases will have a different format for the Automation section:
<Test Suite>|<Test Case>, so that in our example we have the following combination: Auto Insurance Website|Create a quote for Audi Automobile. The other test cases will have the same test suite name, but different test case names.Now you are ready to schedule the automated test case for execution in SpiraTest
"},{"location":"RemoteLaunch-User-Guide/Tosca/#executing-the-tosca-test-sets-from-spiratest","title":"Executing the Tosca Test Sets from SpiraTest","text":"There are two ways to execute automated test cases in SpiraTest:
We shall outline both of these two scenarios in this section. However first we need to setup the appropriate automation hosts and test sets in SpiraTest:
"},{"location":"RemoteLaunch-User-Guide/Tosca/#configuring-the-automation-hosts-and-test-sets","title":"Configuring the Automation Hosts and Test Sets","text":"Go to Testing > Automation Hosts in SpiraTest to display the list of automation hosts:
Make sure that you have created an Automation Host for each computer that is going to run an automated test case. The name and description can be set to anything meaningful, but the Token field must be set to the same token that is specified in the RemoteLaunch application on that specific machine.
Once you have at least one Automation Host configured, go to Testing > Test Sets to create the test set that will contain the automated test cases:
Note: Unlike manual test cases, automated test cases must be executed within a test set -- they cannot be executed directly from the test case. Create a new Test Set (for example Tricentis Insurance Website Suite), and click on its hyperlink to display the test set details page:
Lower down, the list of test cases in the test set are displayed:
You need to add at least one automated test case to the test set, but to get the best reporting, we recommend having the first test case in the test set be the Tosca Test Event that launches the test suite, and the subsequent test cases be the individual test cases that parse the test suite and extract the results specific to the individual test case.
For example, our first test case in the screenshot will launch the entire insurance website test suite that tries to use the sample website with three different car brands (BMW, Audi and Honda). Each individual car brand will create a unique test case result that we'd want to map to different requirements in SpiraTest.
Once you have added the appropriate test cases to the test set, the final step is to configure the main test set fields:
Once you have set the various test set fields (as described above), the Remote Launch instances will periodically poll SpiraTest for new test sets. Once they retrieve the new test set, they will add it to their list of test sets to execute. Once execution begins they will change the status of the test set to \"In Progress\", and once test execution is done, the status of the test set will change to either \"Completed\" -- the automation engine could be launched and the test has completed -- or \"Blocked\" -- RemoteLaunch was not able to start the automation engine.
If you want to immediately execute the test case on your local computer, instead of setting the \"Automation Host\", \"Status\" and \"Planned Date\" fields, you can instead click the [Execute] icon on the test set itself. This will cause RemoteLaunch on the local computer to immediately start executing the current test set.
In either case, once all the test cases in the test set have been completed, the status of the test set will switch to \"Completed\" and the individual test cases in the set will display a status based on the results of the Tosca test:
If you receive the \"Blocked\" status for either the test set or the test cases you should open up the Windows Application Event Log on the computer running RemoteLaunch and look in the event log for error messages.
Note: While the tests are executing you may see browser windows launch as Tosca executes the appropriate tests.
"},{"location":"RemoteLaunch-User-Guide/Tosca/#viewing-the-tosca-test-results","title":"Viewing the Tosca Test Results","text":"Once the tests have completed, you can log back into SpiraTest and see the execution status of your test cases. If you click on a Test Run that was generated by Tosca, you will see the following information:
This screen indicates the status of the test run that was reported back from Tosca together with any messages or other information. The Test Name indicates the name of the test inside Tosca and the execution status corresponds the matching status inside Tosca as described above.
Underneath this high-level test result, you will see the detailed Tosca test results that show each entry in the test script step by step:
Finally, there is the Console Output section which reports back the raw output from the Tosca test result XML file:
Congratulations... You are now able to run Tosca automated functional tests and have the results be recorded within SpiraTest, with the ability to have those test cases update the requirements test coverage and other enterprise quality metrics in the system.
"},{"location":"RemoteLaunch-User-Guide/WebLOAD/","title":"WebLOAD","text":"RadView WebLoad is a WebLOAD is a performance, scalability, and reliability testing solution for internet applications. WebLOAD is easy to use and delivers maximum testing performance and value. WebLOAD verifies the scalability and integrity of internet applications by generating a load composed of Virtual Clients that simulate real-world traffic. Probing Clients let you refine the testing process by acting as a single user that measures the performance of targeted activities, and provides individual performance statistics of the internet application under load.
This section covers installing and using the Engine to report back the success of a WebLoad protocol test scripts/agendas for the WebLOAD environment.
Info
This integration requires at least version 4.0 of SpiraTest/Plan and has been tested against version WebLOAD-Professional-12.2.0.087 of WebLoad.
"},{"location":"RemoteLaunch-User-Guide/WebLOAD/#installing-the-webload-engine","title":"Installing the WebLOAD Engine","text":"This section assumes that you already have a working installation of SpiraTest or SpiraPplan and have installed RemoteLaunch on the various test automation hosts following the instructions in RemoteLaunch Guide. Once those prerequisites are in place, please follow these steps:
Name: This is the short display name of the automation engine. It can be anything that is meaningful to your users, and will be displayed in the Automation Host dropdown when the user selects it in the test set.
Description: This is the long description of the automation engine. It can be anything that is meaningful to your users. (Optional)
Active: If checked, the engine is active and able to be used for any project.
Token: This needs to be the assigned unique token for the automation engine and is used to tell RemoteLaunch which engine, in this case WebLoad.dll, to actually use for a given test case. For WebLOAD, it needs to be simply \"WebLoad\". This is case sensitive, and if it does not match an error will be written to a Blocked test run that will be phrased using what was entered as the token. For example, if the token is misspelled, WebLpsd, the error message will say \u201cExtension 'WebLpsd' was not loaded or was in error condition. Could not run TC:73 in TX:29\u201d
Once you have finished, click the Insert & Close button and you will be taken back to the Test Automation list page, with WebLOAD listed as an available automation engine.
You will need to modify the WebLOAD configuration for each of the specific automation hosts, by right-clicking on the RemoteLaunch icon in the system tray and choosing \"Configuration\". That will bring up the RemoteLaunch configuration page. The WebLOAD engine adds its own tab to this page which allows you to configure how WebLOAD operates:
The following fields can be specified on this screen (make sure to hit Save after making any changes):
Tokens for Specifying File Locations
The full path to the WebLOAD Location and the Output Directory can be shortened via keywords for better visibility, and to make this easier across different machines, you can use several constants for standard Windows locations (see example in screenshot):
This section describes the process for setting up a test case in SpiraPlan for automation and linking it to an automated WebLOAD test script.
First you need to display the list of test cases in SpiraPlan (by clicking Testing > Test Cases) and then add a new test case. Once you have added the new test case, click on it and select the \"Overview\" tab and scroll down to the Automation section:
You need to enter the following fields:
Once you are happy with the values, click Save to update the test case. Now you are ready to schedule the automated test case for execution.
Currently the WebLOAD automation engine does not support the passing of parameter values from SpiraPlan to WebLOAD. Only the file path to the WebLOAD project file (*.tpl) file can be passed. Other parameters must be set in RemoteLaunch as illustrated earlier.
"},{"location":"RemoteLaunch-User-Guide/WebLOAD/#executing-webload-test-sets-from-spiraplan","title":"Executing WebLOAD Test Sets from SpiraPlan","text":"Before we can executed tests we need to setup the appropriate automation hosts and test sets in SpiraPlan. Once this is done, there are two ways to execute automated test cases in SpiraPlan:
Go to Testing > Automation Hosts from the main navbar in SpiraPlan to display the list of automation hosts.
Make sure you have created an Automation Host for each computer that is going to run an automated test case. The name and description can be set to anything meaningful, but the Token field must be set to the same token that is specified in the RemoteLaunch application on that specific machine.
Once you have at least one Automation Host configured, go to Testing > Test Sets to create the test sets that will contain the automated test case.
Info
Unlike manual test cases, automated test cases must be executed within a test set -- they cannot be executed directly from the test case.
Create a new Test Set to hold the WebLOAD automated test cases and click on its hyperlink to display the test set details page.
You need to add at least one automated test case to the test set and then configure the following fields:
Once you have set the various test set fields (as described above), the Remote Launch instances will periodically poll SpiraPlan for new test sets. Once they retrieve the new test set, they will add it to their list of test sets to be executed. Once execution begins they will change the status of the test set to \"In Progress\", and once test execution is done, the status of the test set will change to either:
If you want to immediately execute the test case on your local computer, instead of setting the \"Automation Host\", \"Status\" and \"Planned Date\" fields, you can instead click the [Execute] icon on the test set itself. This will cause RemoteLaunch on the local computer to immediately start executing the current test set.
In either case, once all the test cases in the test set have been completed, the status of the test set will switch to \"Completed\" and the individual test cases in the set will display a status based on the results of the WebLOAD test:
If you receive the \"Blocked\" status for either the test set or the test cases you should open up the Windows Application Event Log on the computer running RemoteLaunch and look in the event log for error messages.
Info
While the tests are executing you will see the WebLOAD application open as WebLOAD executes the appropriate tests.
Once the tests have completed, you can log back into SpiraPlan and see the execution status of your test cases. If you click on a Test Run that was generated by WebLOAD, you will see the following information:
This screen indicates the status of the test run that was reported back from WebLOAD together with any messages or other information. The Test Name indicates the name of the test inside WebLOAD and the execution status corresponds the rules described above.
In addition, the details in the test run from WebLOAD lists the input script and the parameters passed to the script so testers will know the file created that are correlated with tis test run in the output directory. Here is an example of a successful WebLOAD script run through SpiraPlan:
Results from results.xml: Passed Test \nFile Name: C:\\Users\\suzanne.bauer\\Documents\\WebLOAD\\Sessions\\input\\WebLOADFirstTest.tpl\nwith arguments: C:\\Users\\su.be\\Documents\\WebLOAD\\Sessions\\output\\WebLOADFirstTest20200228135424.ls /rc C:\\Users\\su.be\\Documents\\WebLOAD\\Sessions\\output\\results.xml /ar 300 \nCongratulations
You are now able to run WebLOAD automated functional tests and have the results be recorded within SpiraTest /SpiraTeam/ SpiraPlan.
"},{"location":"RemoteLaunch-User-Guide/Worksoft-Certify/","title":"Worksoft Certify","text":"Worksoft Certify is a test automation solution for enterprise applications including SAP, Workday, Salesforce.com, Oracle, and Web Apps. Built to test complex business processes that span multiple applications, Certify ensures that your software and business work exactly as planned.
This section describes how you can use SpiraTest, SpiraTeam, or SpiraPlan (hereafter SpiraTeam) together with RemoteLaunch to schedule and remotely launch instances of Worksoft Certify on different computers and have the testing results be transmitted back to SpiraTeam. This allows you to extend your SpiraTeam's test management capabilities to include automated Worksoft Certify tests.
Note: This integration requires at least version 5.0 of SpiraTeam and version 10.0 of Worksoft Certify.
"},{"location":"RemoteLaunch-User-Guide/Worksoft-Certify/#installing-the-worksoft-certify-engine","title":"Installing the Worksoft Certify Engine","text":"This section assumes that you already have a working installation of SpiraTeam and have installed RemoteLaunch on the various test automation hosts following the instructions in RemoteLaunch Guide. Once those prerequisites are in place, please follow these steps:
Download and extract the WorksoftCertifyEngine.zip file from the Inflectra website and locate the appropriate WorksoftCertifyEngine.dll for the version of Worksoft Certify that you are using.
Copy the file \"WorksoftCertifyEngine.dll\" into the \"extensions\" sub-folder of the RemoteLaunch installation.
Log in to SpiraTeam as a system administrator and go into SpiraTeam main Administration page and click on the \"Test Automation\" link under Integration.
Click the \"Add\" button to enter the new test automation engine details page. The fields required are as follows:
Name: This is the short display name of the automation engine. It can be anything that is meaningful to your users.
Description: This is the long description of the automation engine. It can be anything that is meaningful to your users. (Optional)
Active: If checked, the engine is active and able to be used for any project.
Token: This needs to be the assigned unique token for the automation engine and is used to tell RemoteLaunch which engine to actually use for a given test case. For Worksoft Certify this should always be WorksoftCertify.
Once you have finished, click the \"Insert & Close\" button and you will be taken back to the Test Automation list page, with Worksoft Certify listed as an available automation engine:
You can modify the Worksoft Certify configuration for each of the specific automation hosts, by right-clicking on the RemoteLaunch icon in the system tray and choosing \"Configuration\". That will bring up the RemoteLaunch configuration page.
The Worksoft Certify engine adds its own tab to this page which allows you to configure how Worksoft Certify operates:
The following fields can be specified on this screen:
Trace Logging -- When selected, this will log additional trace and debugging information to the Windows Event Log. This should not be selected in a production environment.
Certify User -- This should be populated with a valid username that can login to the Worksoft Certify database that you are using
Certify Password -- This should be populated with a valid password for the user specified in the previous field that can login to the Worksoft Certify database that you are using
Test Timeout -- This tells RemoteLaunch how long to let the Worksoft Certify tests run (in seconds) in the event one of the tests were to not finish property. Once the test report is generated, RemoteLaunch will stop execution, regardless of this setting.
Report Generation Time -- This is how long (in seconds) RemoteLaunch should wait after Worksoft Certify has finished before reading the test report (for sending to SpiraTeam). It ensures that Worksoft Certify has enough time to finish writing the report.
"},{"location":"RemoteLaunch-User-Guide/Worksoft-Certify/#setting-up-the-automated-test-cases","title":"Setting up the Automated Test Cases","text":"This section describes the process for setting up a test case in SpiraTeam for automation and linking it to an automated Worksoft Certify test script.
First you need to display the list of test cases in SpiraTeam (by clicking Testing > Test Cases) and then add a new test case. Once you have added the new test case, click on it and select the \"Automation\" section of the main \"Overview\" tab:
You need to enter the following fields:
Automation Engine - Choose the Worksoft Certify Automation Engine that you created in the previous section from the drop-down list.
Script Type -- This should be set to Linked as the integration with Worksoft Certify only supports referencing Worksoft Certify projects and not physically uploading the tests into SpiraTeam.
Filename -- This needs to contain the following elements at the very least:
/Process=\"xxxxx\" needs to specify the name of the Worksoft Certify process
/Project=\"xxxxx\" needs to specify the name of the Worksoft Certify project
You can also add other Worksoft Certify command line options - http://community.worksoft.com/Knowledge-Base/Worksoft-Products/Worksoft-Certify/certify-command-line-options.html
Document Type -- This allows you to choose which document type the automated test script will be categorized under.
Document Folder --This allows you to choose which document folder the automated test script will be stored in.
Version -- The version of the test script (1.0 is used if no value specified)
Test Script -- This is not used with the Worksoft Certify Engine since it only supports linked test scripts.
Once you are happy with the values, click [Save] to update the test case. Now you are ready to schedule the automated test case for execution.
"},{"location":"RemoteLaunch-User-Guide/Worksoft-Certify/#executing-the-worksoft-certify-test-sets-from-spirateam","title":"Executing the Worksoft Certify Test Sets from SpiraTeam","text":"There are two ways to execute automated test cases in SpiraTeam:
Schedule the test cases to be executed on a specific computer (local or remote) at a date/time in the future
Execute the test cases right now on the local computer.
We shall outline both of these two scenarios in this section. However first we need to setup the appropriate automation hosts and test sets in SpiraTeam:
"},{"location":"RemoteLaunch-User-Guide/Worksoft-Certify/#configuring-the-automation-hosts-and-test-sets","title":"Configuring the Automation Hosts and Test Sets","text":"Go to Testing > Automation Hosts in SpiraTeam to display the list of automation hosts:
Make sure that you have created an Automation Host for each computer that is going to run an automated test case. The name and description can be set to anything meaningful, but the Token field must be set to the same token that is specified in the RemoteLaunch application on that specific machine.
Once you have at least one Automation Host configured, go to Testing > Test Sets to create the test sets that will contain the automated test case:
Note: Unlike manual test cases, automated test cases must be executed within a test set -- they cannot be executed directly from the test case.
Create a new Test Set to hold the Worksoft Certify automated test cases and click on its hyperlink to display the test set details page:
Lower down, the list of test cases in the test set are displayed:
You need to add at least one automated test case to the test set and then configure the following fields:
Automation Host -- This needs to be set to the name of the automation host that will be running the automated test set.
Planned Date -- The date and time that you want the scenario to begin. (Note that multiple test sets scheduled at the exact same time will be scheduled by Test Set ID order.)
Status -- This needs to be set to \"Not Started\" for RemoteLaunch to pick up the scheduled test set. When you change the Planned Date, the status automatically switches back to \"Not Started\"
Type -- This needs to be set to \"Automated\" for automated testing
Once you have set the various test set fields (as described above), the Remote Launch instances will periodically poll SpiraTeam for new test sets. Once they retrieve the new test set, they will add it to their list of test sets to execute. Once execution begins they will change the status of the test set to \"In Progress\", and once test execution is done, the status of the test set will change to either \"Completed\" -- the automation engine could be launched and the test has completed -- or \"Blocked\" -- RemoteLaunch was not able to start the automation engine.
If you want to immediately execute the test case on your local computer, instead of setting the \"Automation Host\", \"Status\" and \"Planned Date\" fields, you can instead click the [Execute] icon on the test set itself. This will cause RemoteLaunch on the local computer to immediately start executing the current test set.
In either case, once all the test cases in the test set have been completed, the status of the test set will switch to \"Completed\" and the individual test cases in the set will display a status based on the results of the Worksoft Certify test:
Passed -- The Worksoft Certify automated test ran successfully and all the test steps in the test script passed and no assertions were thrown.
Failed -- The Worksoft Certify automated test ran successfully, but at least one test step failed or at least one assertion failed.
Blocked -- The Worksoft Certify automated test did not run successfully and reported back the aborted test status to RemoteLaunch.
If you receive the \"Blocked\" status for either the test set or the test cases you should open up the Windows Application Event Log on the computer running RemoteLaunch and look in the event log for error messages.
Note: While the tests are executing you will see browser windows launch as Worksoft Certify executes the appropriate tests.
Once the tests have completed, you can log back into SpiraTeam and see the execution status of your test cases. If you click on a Test Run that was generated by Worksoft Certify, you will see the following information:
This screen indicates the status of the test run that was reported back from Worksoft Certify together with any messages or other information. The Test Name indicates the name of the test inside Worksoft Certify and there will be detailed steps displayed that match the Worksoft Certify execution steps:
Each of the SpiraTeam execution status values corresponds the matching status inside Worksoft Certify as illustrated below:
Worksoft Certify Status SpiraTeam Status Passed Passed Failed Failed Aborted Blocked Skipped N/AIn addition, the detailed test report from Worksoft Certify is available in the large text-box below. It will contain messages such as:
Congratulations... You are now able to run Worksoft Certify automated functional tests and have the results be recorded within SpiraTest, SpiraTeam, or SpiraPlan.
"},{"location":"RemoteLaunch-User-Guide/ZAPTEST/","title":"ZAPTEST","text":"ZAPTEST is a cross-platform and cross-browser software testing solution. Using OCR and Image Based recognition, it's able to automate the testing process without any API, Framework or environment dependencies and work only with a Graphic User Interface
This section describes how you can use SpiraTest, SpiraTeam, or SpiraPlan (hereafter SpiraTeam) together with RemoteLaunch to schedule and remotely launch instances of ZAPTEST on different computers and have the testing results be transmitted back to SpiraTeam. This allows you to extend your SpiraTeam's test management capabilities to include automated ZAPTEST tests.
Note: This integration requires at least version 5.0 of SpiraTeam and version 11.0 of ZAPTEST.
"},{"location":"RemoteLaunch-User-Guide/ZAPTEST/#installing-the-zaptest-engine","title":"Installing the ZAPTEST Engine","text":"This section assumes that you already have a working installation of SpiraTeam and have installed RemoteLaunch on the various test automation hosts following the instructions in RemoteLaunch Guide. Once those prerequisites are in place, please follow these steps:
Download and extract the ZapTestEngine.zip file from the Inflectra website and locate the appropriate ZapTestEngine.dll for the version of ZAPTEST that you are using.
Copy the file \"ZapTestEngine.dll\" into the \"extensions\" sub-folder of the RemoteLaunch installation.
Log in to SpiraTeam as a system administrator and go into SpiraTeam main Administration page and click on the \"Test Automation\" link under Integration.
Click the \"Add\" button to enter the new test automation engine details page. The fields required are as follows:
Name: This is the short display name of the automation engine. It can be anything that is meaningful to your users.
Description: This is the long description of the automation engine. It can be anything that is meaningful to your users. (Optional)
Active: If checked, the engine is active and able to be used for any project.
Token: This needs to be the assigned unique token for the automation engine and is used to tell RemoteLaunch which engine to actually use for a given test case. For ZAPTEST this should always be ZapTest.
Once you have finished, click the \"Insert & Close\" button and you will be taken back to the Test Automation list page, with ZAPTEST listed as an available automation engine:
You can modify the ZAPTEST configuration for each of the specific automation hosts, by right-clicking on the RemoteLaunch icon in the system tray and choosing \"Configuration\". That will bring up the RemoteLaunch configuration page.
The ZAPTEST engine adds its own tab to this page which allows you to configure how ZAPTEST operates:
The following fields can be specified on this screen:
ZAPTEST Location -- You need to browse to the location of the Standalone ZAPTEST.EXE program (e.g. C:\\Program Files (x86)\\ZAP-fiX\\Standalone)
Trace Logging -- When selected, this will log additional trace and debugging information to the Windows Event Log. This should not be selected in a production environment.
Report Generation Time -- This is how long (in seconds) RemoteLaunch should wait after ZAPTEST has finished before reading the test report (for sending to SpiraTeam). It ensures that ZAPTEST has enough time to finish writing the report.
"},{"location":"RemoteLaunch-User-Guide/ZAPTEST/#setting-up-the-automated-test-cases","title":"Setting up the Automated Test Cases","text":"This section describes the process for setting up a test case in SpiraTeam for automation and linking it to an automated ZAPTEST test script.
First you need to display the list of test cases in SpiraTeam (by clicking Testing > Test Cases) and then add a new test case. Once you have added the new test case, click on it and select the \"Automation\" section of the main \"Overview\" tab:
You need to enter the following fields:
Automation Engine - Choose the ZapTest Automation Engine that you created in the previous section from the drop-down list.
Script Type -- This should be set to Linked as the integration with ZAPTEST only supports referencing ZAPTEST script files and not physically uploading the tests into SpiraTeam.
Filename -- This needs to contain the full path to a location on the computer running ZAPTEST where the test script can be found.
Document Type -- This allows you to choose which document type the automated test script will be categorized under.
Document Folder --This allows you to choose which document folder the automated test script will be stored in.
Version -- The version of the test script (1.0 is used if no value specified)
Test Script -- This is not used with the ZapTest Engine since it only supports linked test scripts.
Once you are happy with the values, click [Save] to update the test case. Now you are ready to schedule the automated test case for execution.
"},{"location":"RemoteLaunch-User-Guide/ZAPTEST/#executing-the-zaptest-test-sets-from-spirateam","title":"Executing the ZAPTEST Test Sets from SpiraTeam","text":"There are two ways to execute automated test cases in SpiraTeam:
Schedule the test cases to be executed on a specific computer (local or remote) at a date/time in the future
Execute the test cases right now on the local computer.
We shall outline both of these two scenarios in this section. However first we need to setup the appropriate automation hosts and test sets in SpiraTeam:
"},{"location":"RemoteLaunch-User-Guide/ZAPTEST/#configuring-the-automation-hosts-and-test-sets","title":"Configuring the Automation Hosts and Test Sets","text":"Go to Testing > Automation Hosts in SpiraTeam to display the list of automation hosts:
Make sure that you have created an Automation Host for each computer that is going to run an automated test case. The name and description can be set to anything meaningful, but the Token field must be set to the same token that is specified in the RemoteLaunch application on that specific machine.
Once you have at least one Automation Host configured, go to Testing > Test Sets to create the test sets that will contain the automated test case:
Note: Unlike manual test cases, automated test cases must be executed within a test set -- they cannot be executed directly from the test case.
Create a new Test Set to hold the ZAPTEST automated test cases and click on its hyperlink to display the test set details page:
Lower down, the list of test cases in the test set are displayed:
You need to add at least one automated test case to the test set and then configure the following fields:
Automation Host -- This needs to be set to the name of the automation host that will be running the automated test set.
Planned Date -- The date and time that you want the scenario to begin. (Note that multiple test sets scheduled at the exact same time will be scheduled by Test Set ID order.)
Status -- This needs to be set to \"Not Started\" for RemoteLaunch to pick up the scheduled test set. When you change the Planned Date, the status automatically switches back to \"Not Started\"
Type -- This needs to be set to \"Automated\" for automated testing
Once you have set the various test set fields (as described above), the Remote Launch instances will periodically poll SpiraTeam for new test sets. Once they retrieve the new test set, they will add it to their list of test sets to execute. Once execution begins they will change the status of the test set to \"In Progress\", and once test execution is done, the status of the test set will change to either \"Completed\" -- the automation engine could be launched and the test has completed -- or \"Blocked\" -- RemoteLaunch was not able to start the automation engine.
If you want to immediately execute the test case on your local computer, instead of setting the \"Automation Host\", \"Status\" and \"Planned Date\" fields, you can instead click the [Execute] icon on the test set itself. This will cause RemoteLaunch on the local computer to immediately start executing the current test set.
In either case, once all the test cases in the test set have been completed, the status of the test set will switch to \"Completed\" and the individual test cases in the set will display a status based on the results of the ZAPTEST:
Passed -- The ZAPTEST automated test ran completed execution and all the test steps in the test script passed and no failures or warnings were logged.
Failed -- The ZAPTEST automated test ran completed execution, but at least one test step failed.
Warning -- The ZAPTEST automated test ran completed execution, but at least one test step reported a warning, but no steps completely failed.
Blocked -- The ZAPTEST automated test failed to execute because of some configuration error.
If you receive the \"Blocked\" status for either the test set or the test cases you should open up the Windows Application Event Log on the computer running RemoteLaunch and look in the event log for error messages.
Note: While the tests are executing you will see browser windows launch as ZAPTEST executes the appropriate tests.
Once the tests have completed, you can log back into SpiraTeam and see the execution status of your test cases. If you click on a Test Run that was generated by ZAPTEST, you will see the following information:
This screen indicates the status of the test run that was reported back from ZAPTEST together with any messages or other information. The Test Name indicates the name of the test script that was executed and there will be detailed steps displayed that match the ZAPTEST execution steps:
Each of the SpiraTeam execution status values corresponds the matching status inside Worksoft Certify as illustrated below:
ZAPTEST Status SpiraTeam Status Passed Passed Failed Failed Warning Caution Information N/AIn addition, the detailed test report from ZAPTEST is available in the large text-box below. It will contain messages such as:
Congratulations... You are now able to run ZAPTEST automated functional tests and have the results be recorded within SpiraTest, SpiraTeam, or SpiraPlan.
"},{"location":"Reporting/Custom-Graph-Tutorial/","title":"Custom Graphs Tutorial and Introduction","text":""},{"location":"Reporting/Custom-Graph-Tutorial/#introduction","title":"Introduction","text":"One of the maxims I always tell developers is that regardless of what you build, customers will never be satisfied with the reports you offer or the integration that you provide. In fact, the two most underestimated tasks in software development are data feeds and reporting. So one of the nice features in our Spira platform is the ability to do custom graphing, so that you are not limited to just the graphs that ship with the system.
"},{"location":"Reporting/Custom-Graph-Tutorial/#creating-custom-graphs","title":"Creating Custom Graphs","text":"To create a custom report, go to: Administration > System Administration > Reporting > Edit Graphs:
When you click on the Edit Graphs link, you will be taken to the custom graph configuration page where you can add / modify custom graphs.
This page lets you create custom graphs and charts in the system that your users can run in the various products they have access to. Note that the graph definitions themselves are global to the system and therefore available in all products.
You can click the Edit button to modify an existing graph, or click Add New Custom Graph to create an new one. In either case, you will see the custom graph editing screen.
The graph list page has the following additional operations:
On the graph editing page, you can enter the following fields:
The Query box is where you can choose the Reportable Entity from the dropdown list and then use that base query to create your own custom query.
We recommend that you first choose the appropriate reportable entity from the dropdown list. In the example below, we have selected the \"Test Runs\" reportable entity:
This will automatically populate the following query in the Query editor:
select value R from SpiraTestEntities.R_TestRuns as R where R.PROJECT_ID = ${ProjectId}\nThis query tells Spira to select all of the rows in the R_TestRuns collection that are in the current product and include all of the columns in the final report. You cannot graph non-numeric columns, so usually we'd recommend clicking Display Data Grid to see all of the columns that you can use in the graph:
This will help you decide which columns are important for your graph. You can then adjust the query to only include those columns:
select R.EXECUTION_STATUS_NAME, COUNT (R.TEST_RUN_ID) as COUNT\nfrom SpiraTestEntities.R_TestRuns as R\nwhere R.PROJECT_ID = ${ProjectId}\ngroup by R.EXECUTION_STATUS_NAME\nIn this modified query, we have replaced the keyword value with the specific column names. We have also added an aggregation function called COUNT to count the number of test runs and group by the execution status name column. Spira uses a modified SQL language called Entity SQL created by Microsoft that we'll be discussing in more detail in later articles in this series.
You may have noticed that we had a special token in the query ${ProjectId}, this token will be evaluated during the generation of the graph and ensures that only items in the current product are included. If you want to include all the items in a specific Program, you should instead use the token ${ProjectGroupId}. If you don't use either token, the graph will include all the items in the entire system, across all products and programs.
There are some restrictions about the select clause of the query:
You can test out your modified query by clicking the Display Data Grid button again. For our example test runs query above the system will now display:
Then once you have verified the data makes sense, click on the three different Preview Graph buttons to see how the data will look as a donut, bar, or\u00a0 line graph.
Note
For donut graphs, only one data range is supported, for line/bar charts, you can have multiple ranges
"},{"location":"Reporting/Custom-Graph-Tutorial/#a-donut-chart","title":"a) Donut Chart","text":""},{"location":"Reporting/Custom-Graph-Tutorial/#b-bar-graph","title":"b) Bar Graph","text":""},{"location":"Reporting/Custom-Graph-Tutorial/#c-line-chart","title":"c) Line Chart","text":"Once you are happy with your graph design, make sure the Active flag is set to Yes and then click Save to publish the graph for your end users.
Warning
If you create a graph that doesn't have either ${ProjectId} or ${ProjectGroupId} in the WHERE clause you could end up displaying data to a user that shouldn't have permission to see that data.
"},{"location":"Reporting/Custom-Graph-Tutorial/#viewing-custom-graphs","title":"Viewing Custom Graphs","text":"Once published, the custom graphs can be displayed in the main Reports dashboard by your end users:
Once you have added an instance of the Custom Graphs to your dashboard, you can choose the specific graph, and the visualization type (donut, bar, and line currently):
You can display the data being used to generate the graph by clicking on the data-grid button in the bottom-left:
As with all of the graphs on the reporting dashboard, you can export the data-grid as a CSV / Excel sheet, and export the actual graph as an image (PNG, JPEG, and BMP formats supported).
"},{"location":"Reporting/Custom-Graph-Tutorial/#understanding-entity-sql-esql","title":"Understanding Entity SQL (ESQL)","text":"The language that we use for creating custom graphs and reports in Spira is called \"Entity SQL\" (abbreviated to ESQL). Please read our dedicated tutorial to learn how ESQL works and how it is similar and different to standard SQL. This includes an overview, Entity SQL Syntax Basics, and the differences Between ESQL and Traditional Database SQL.
"},{"location":"Reporting/Custom-Graph-Tutorial/#advanced-entity-sql-queries","title":"Advanced Entity SQL Queries","text":"Now that we have discussed the differences between traditional database SQL and Entity SQL, we will cover some more advanced queries and functions that customers typically will want to use when creating custom graphs with Spira.
At the top of this tutorial, we outlined a sample ESQL query to get the count of test runs by execution status:
select R.EXECUTION_STATUS_NAME, COUNT (R.TEST_RUN_ID) as COUNT\nfrom SpiraTestEntities.R_TestRuns as R\nwhere R.PROJECT_ID = ${ProjectId}\ngroup by R.EXECUTION_STATUS_NAME\nAs we discussed, when using ESQL queries to display custom graphs, there are some restrictions about the select clause of the query:
We will now be looking at some specific examples of graphs that users have asked us for help with, that we have some suggestions for...
"},{"location":"Reporting/Custom-Graph-Tutorial/#1-requirements-addedremoved-over-time","title":"1) Requirements Added/Removed Over Time","text":"For example, lets consider that you want to display a graph of requirements added and removed over time. To get a count of this we can query the SpiraTestEntities.R_HistoryChangeSets view to get a count of the changes, filter by additions and deletions, then use a combination of aggregation and the CAST operator to count the items added/removed:
select\nR.CHANGE_DATE as Timestamp,\ncount(CASE\nWHEN R.CHANGETYPE_NAME=\"Added\" THEN 1\nWHEN R.CHANGETYPE_NAME=\"Deleted\" THEN -1\nEND\n) AS Sum\nfrom SpiraTestEntities.R_HistoryChangeSets as R\nwhere\nR.ARTIFACT_TYPE_NAME = \"Requirement\"\ngroup by R.CHANGE_DATE\nThis will display the following data:
Timestamp Sum 2019-08-17T02:06:18 0 2019-08-23T02:51:18 0 2020-01-14T11:50:18 5 2020-01-14T11:50:18 7 2020-01-14T11:50:18 5 2020-01-14T11:50:18 9 2020-01-14T11:50:18 7 2020-01-14T11:50:18 6 2020-01-14T11:50:18 5 2020-01-14T11:50:18 7Which when displayed as a graph would look like:
However suppose you want to display this graph by day, not by unique timestamp (a reasonable request), you would use the TruncateTime canonical EntitySQL function and combine that with a different way of writing the GROUP BY clause:
select\nDatePart,\ncount(CASE\nWHEN R.CHANGETYPE_NAME=\"Added\" THEN 1\nWHEN R.CHANGETYPE_NAME=\"Deleted\" THEN -1\nEND\n) AS Sum\nfrom SpiraTestEntities.R_HistoryChangeSets as R\nwhere\nR.ARTIFACT_TYPE_NAME = \"Requirement\"\ngroup by TruncateTime(R.CHANGE_DATE) as DatePart\nThis would now give the following results instead:
<table class=\"table table-striped\">\n <tbody>\n <tr class=\"Header\">\n <th>DatePart</th>\n <th>Sum</th>\n </tr>\n <tr>\n <td>2019-08-17T00:00:00</td>\n <td>0</td>\n </tr>\n <tr>\n <td>2019-08-23T00:00:00</td>\n <td>0</td>\n </tr>\n <tr>\n <td>2020-01-14T00:00:00</td>\n <td>248</td>\n </tr>\n </tbody>\n</table>\nwhich could be graphed as follows:
"},{"location":"Reporting/Custom-Graph-Tutorial/#2-aggregating-data-over-time-periods","title":"2) Aggregating Data Over Time Periods","text":"A common need is the ability to aggregate data over multiple time periods. For example, in the query above, we had the list of requirements aggregated by day:
<table class=\"table table-striped\">\n <tbody>\n <tr class=\"Header\">\n <th>DatePart</th>\n <th>Sum</th>\n </tr>\n <tr>\n <td>2019-08-17T00:00:00</td>\n <td>0</td>\n </tr>\n <tr>\n <td>2019-08-23T00:00:00</td>\n <td>0</td>\n </tr>\n <tr>\n <td>2020-01-14T00:00:00</td>\n <td>248</td>\n </tr>\n </tbody>\n</table>\nSuppose we wanted to group the data over a 20 day time period. We would need to modify the query as follows:
select\nDatePart,\ncount(CASE\nWHEN R.CHANGETYPE_NAME=\"Added\" THEN 1\nWHEN R.CHANGETYPE_NAME=\"Deleted\" THEN -1\nEND\n) AS Sum\nfrom SpiraTestEntities.R_HistoryChangeSets as R\nwhere\nR.ARTIFACT_TYPE_NAME = \"Requirement\"\ngroup by AddDays(CreateDateTime(Year(R.CHANGE_DATE),1,1,0,0,0), (DayOfYear(R.CHANGE_DATE)/20)*20) as DatePart\nNow when you execute the query, the system is using the following functions to combines the dates down into 20 day ranges:
When executed, this will display:
<table class=\"table table-striped\">\n <tbody>\n <tr class=\"Header\">\n <th>DatePart</th>\n <th>Sum</th>\n </tr>\n <tr>\n <td>2019-08-09T00:00:00</td>\n <td>0</td>\n </tr>\n <tr>\n <td>2020-01-01T00:00:00</td>\n <td>248</td>\n </tr>\n </tbody>\n</table>\nor in graphical form:
"},{"location":"Reporting/Custom-Graph-Tutorial/#further-reading","title":"Further Reading","text":"How to use this page
SpiraPlan has a number of database views available for creating custom reports using ESQL queries. Below, each available table is listed with all of their exact field names.
"},{"location":"Reporting/Custom-Report-Tables/#artifact-associations","title":"Artifact Associations","text":"R_ArtifactAssociations ARTIFACT_LINK_TYPE_ID SOURCE_ARTIFACT_ID SOURCE_ARTIFACT_TYPE_ID DEST_ARTIFACT_ID DEST_ARTIFACT_TYPE_ID CREATOR_ID CREATION_DATE COMMENT SOURCE_ARTIFACT_TYPE_NAME DEST_ARTIFACT_TYPE_NAME CREATOR_NAME ARTIFACT_LINK_TYPE_NAME"},{"location":"Reporting/Custom-Report-Tables/#artifact-attachments","title":"Artifact Attachments","text":"R_ArtifactAttachments ARTIFACT_TYPE_ID ARTIFACT_ID ARTIFACT_TYPE_NAME ARTIFACT_NAME COMMENT CREATOR_ID CREATION_DATE CREATOR_NAME ATTACHMENT_ID PROJECT_ID ARTIFACT_STATUS_NAME"},{"location":"Reporting/Custom-Report-Tables/#artifact-types","title":"Artifact Types","text":"R_ArtifactTypes ARTIFACT_TYPE_ID NAME PREFIX"},{"location":"Reporting/Custom-Report-Tables/#attachments","title":"Attachments","text":"R_Attachments ATTACHMENT_ID ATTACHMENT_TYPE_ID AUTHOR_ID EDITOR_ID FILENAME DESCRIPTION UPLOAD_DATE EDITED_DATE SIZE CURRENT_VERSION PROJECT_ID PROJECT_ATTACHMENT_FOLDER_ID CONCURRENCY_DATE DOCUMENT_STATUS_ID DOCUMENT_TYPE_ID DOCUMENT_STATUS_NAME DOCUMENT_TYPE_NAME TAGS CUST_01... CUST_99 IS_KEY_DOCUMENT DOCUMENT_STATUS_IS_OPEN_STATUS PROJECT_IS_ACTIVE PROJECT_GROUP_ID PROJECT_NAME AUTHOR_NAME EDITOR_NAME ATTACHMENT_TYPE_NAME PROJECT_ATTACHMENT_FOLDER_NAME"},{"location":"Reporting/Custom-Report-Tables/#attachment-folders","title":"Attachment Folders","text":"R_AttachmentFolders PROJECT_ATTACHMENT_FOLDER_ID PROJECT_ID PARENT_PROJECT_ATTACHMENT_FOLDER_ID NAME PROJECT_NAME PROJECT_GROUP_ID"},{"location":"Reporting/Custom-Report-Tables/#attachment-versions","title":"Attachment Versions","text":"R_AttachmentVersions ATTACHMENT_VERSION_ID ATTACHMENT_ID AUTHOR_ID FILENAME DESCRIPTION UPLOAD_DATE SIZE VERSION_NUMBER IS_CURRENT CHANGESET_ID AUTHOR_NAME ATTACHMENT_TYPE_ID PROJECT_ID"},{"location":"Reporting/Custom-Report-Tables/#automation-hosts","title":"Automation Hosts","text":"R_AutomationHosts AUTOMATION_HOST_ID PROJECT_ID NAME DESCRIPTION TOKEN LAST_UPDATE_DATE IS_DELETED CUST_01... CUST_99 PROJECT_NAME PROJECT_GROUP_ID IS_ACTIVE IS_ATTACHMENTS CONCURRENCY_DATE LAST_CONTACT_DATE"},{"location":"Reporting/Custom-Report-Tables/#baselines","title":"Baselines","text":"See | this KB](https://www.inflectra.com/Support/KnowledgeBase/KB550.aspx) for some examples of using this custom report table |
R_Baselines BASELINE_ID PROJECT_ID CREATOR_USER_ID CHANGESET_ID RELEASE_ID NAME DESCRIPTION IS_ACTIVE IS_APPROVED IS_DELETED CREATION_DATE LAST_UPDATE_DATE CONCURRENCY_DATE BASELINE_CREATOR_LOGIN CHANGESET_CREATOR_ID CHANGESET_CREATOR_LOGIN ARTIFACT_TYPE_ID ARTIFACT_TYPE_NAME CHANGESET_DATE CHANGESET_TYPE_ID CHANGESET_TYPE_NAME"},{"location":"Reporting/Custom-Report-Tables/#builds","title":"Builds","text":"R_Builds BUILD_ID BUILD_STATUS_ID RELEASE_ID PROJECT_ID NAME DESCRIPTION"},{"location":"Reporting/Custom-Report-Tables/#capabilities","title":"Capabilities","text":"R_ProjectGroup_Capabilities CAPABILITY_ID PROJECT_GROUP_ID MILESTONE_ID STATUS_ID TYPE_ID PRIORITY_ID NAME DESCRIPTION IS_DELETED PERCENT_COMPLETE PROJECT_REQUIREMENT_COUNT INDENT_LEVEL CONCURRENCY_GUID CREATOR_ID OWNER_ID CREATION_DATE LAST_UPDATED_DATE IS_SUMMARY STATUS_NAME STATUS_IS_OPEN TYPE_NAME PRIORITY_NAME PRIORITY_COLOR PRIORITY_SCORE MILESTONE_NAME CREATOR_NAME OWNER_NAME PROJECT_GROUP_NAME CUST_01... CUST_30"},{"location":"Reporting/Custom-Report-Tables/#capability-priorities","title":"Capability Priorities","text":"R_ProjectGroup_Capability_Priorities PRIORITY_ID NAME COLOR IS_ACTIVE IS_DELETED SCORE"},{"location":"Reporting/Custom-Report-Tables/#capability-requirement-associations","title":"Capability Requirement Associations","text":"R_ProjectGroup_Capability_Project_Requirements CAPABILITY_ID REQUIREMENT_ID ARTIFACT_LINK_TYPE_ID CAPABILITY_NAME REQUIREMENT_NAME ARTIFACT_LINK_TYPE_NAME"},{"location":"Reporting/Custom-Report-Tables/#capability-statuses","title":"Capability Statuses","text":"R_ProjectGroup_Capability_Statuses STATUS_ID NAME POSITION IS_ACTIVE IS_DELETED IS_DEFAULT IS_OPEN ON_BOARD"},{"location":"Reporting/Custom-Report-Tables/#capability-types","title":"Capability Types","text":"R_ProjectGroup_Capability_Types TYPE_ID NAME IS_ACTIVE IS_DELETED IS_DEFAULT"},{"location":"Reporting/Custom-Report-Tables/#comments","title":"Comments","text":"R_Comments ARTIFACT_ID CREATOR_ID COMMENT_TEXT CREATION_DATE CREATOR_NAME ARTIFACT_TYPE_NAME"},{"location":"Reporting/Custom-Report-Tables/#components","title":"Components","text":"R_Components COMPONENT_ID PROJECT_ID NAME IS_DELETED IS_ACTIVE PROJECT_NAME PROJECT_GROUP_ID"},{"location":"Reporting/Custom-Report-Tables/#custom-lists","title":"Custom Lists","text":"R_CustomLists CUSTOM_PROPERTY_LIST_ID PROJECT_ID NAME IS_ACTIVE IS_SORTED_ON_VALUE PROJECT_NAME PROJECT_IS_ACTIVE PROJECT_TEMPLATE_ID"},{"location":"Reporting/Custom-Report-Tables/#custom-list-values","title":"Custom List Values","text":"R_CustomListValues CUSTOM_PROPERTY_VALUE_ID CUSTOM_PROPERTY_LIST_ID NAME PROJECT_ID CUSTOM_PROPERTY_LIST_NAME CUSTOM_PROPERTY_LIST_IS_ACTIVE PROJECT_NAME PROJECT_IS_ACTIVE IS_ACTIVE IS_DELETED DEPENDENT_CUSTOM_PROPERTY_LIST_ID PARENT_CUSTOM_PROPERTY_VALUE_ID"},{"location":"Reporting/Custom-Report-Tables/#custom-property-definitions","title":"Custom Property Definitions","text":"R_CustomPropertyDefinitions CUSTOM_PROPERTY_ID CUSTOM_PROPERTY_TYPE_ID PROJECT_ID ARTIFACT_TYPE_ID NAME PROPERTY_NUMBER IS_DELETED CUSTOM_PROPERTY_LIST_ID LEGACY_NAME PROJECT_NAME PROJECT_IS_ACTIVE ARTIFACT_TYPE_NAME CUSTOM_PROPERTY_TYPE_NAME CUSTOM_PROPERTY_LIST_NAME DEPENDENT_CUSTOM_PROPERTY_ID PROJECT_TEMPLATE_ID"},{"location":"Reporting/Custom-Report-Tables/#document-statuses","title":"Document Statuses","text":"R_DocumentStatuses DOCUMENT_STATUS_ID PROJECT_TEMPLATE_ID NAME POSITION IS_ACTIVE IS_OPEN_STATUS IS_DEFAULT PROJECT_TEMPLATE_NAME"},{"location":"Reporting/Custom-Report-Tables/#document-types","title":"Document Types","text":"R_DocumentTypes DOCUMENT_TYPE_ID PROJECT_TEMPLATE_ID DOCUMENT_WORKFLOW_ID NAME DESCRIPTION IS_ACTIVE IS_DEFAULT PROJECT_TEMPLATE_NAME"},{"location":"Reporting/Custom-Report-Tables/#events","title":"Events","text":"R_Events EVENT_TYPE_ID EVENT_TIME_UTC EVENT_TIME EVENT_CATEGORY EVENT_SEQUENCE EVENT_OCCURRENCE EVENT_CODE EVENT_DETAIL_CODE MESSAGE APPLICATION_PATH APPLICATION_VIRTUAL_PATH MACHINE_NAME REQUEST_URL EXCEPTION_TYPE DETAILS EVENT_TYPE_NAME"},{"location":"Reporting/Custom-Report-Tables/#global-system-custom-property-definitions","title":"Global / System Custom Property Definitions","text":"R_GlobalCustomPropertyDefinitions CUSTOM_PROPERTY_ID CUSTOM_PROPERTY_TYPE_ID CUSTOM_PROPERTY_TYPE_NAME WORKSPACE_TYPE_ID WORKSPACE_TYPE_NAME NAME PROPERTY_NUMBER IS_DELETED CUSTOM_PROPERTY_LIST_ID CUSTOM_PROPERTY_LIST_NAME POSITION DESCRIPTION"},{"location":"Reporting/Custom-Report-Tables/#global-system-custom-property-lists","title":"Global / System Custom Property Lists","text":"R_GlobalCustomLists CUSTOM_PROPERTY_LIST_ID NAME IS_ACTIVE IS_SORTED_ON_VALUE"},{"location":"Reporting/Custom-Report-Tables/#global-system-custom-property-list-values","title":"Global / System Custom Property List Values","text":"R_GlobalCustomListValues CUSTOM_PROPERTY_VALUE_ID NAME IS_ACTIVE IS_DELETED CUSTOM_PROPERTY_LIST_ID CUSTOM_PROPERTY_LIST_NAME CUSTOM_PROPERTY_LIST_IS_ACTIVE"},{"location":"Reporting/Custom-Report-Tables/#history-change-sets","title":"History Change-Sets","text":"R_HistoryChangeSets CHANGESET_ID USER_ID ARTIFACT_TYPE_ID ARTIFACT_ID CHANGE_DATE CHANGETYPE_ID PROJECT_ID REVERT_ID ARTIFACT_DESC CHANGETYPE_NAME USER_NAME ARTIFACT_TYPE_NAME SIGNATURE_HASH MEANING"},{"location":"Reporting/Custom-Report-Tables/#history-details","title":"History Details","text":"R_HistoryDetails FIELD_NAME OLD_VALUE FIELD_CAPTION NEW_VALUE OLD_VALUE_INT OLD_VALUE_DATE NEW_VALUE_INT NEW_VALUE_DATE CHANGESET_ID FIELD_ID CUSTOM_PROPERTY_ID ARTIFACT_ID USER_ID ARTIFACT_TYPE_ID CHANGE_DATE CHANGER_NAME CHANGE_NAME CHANGETYPE_ID"},{"location":"Reporting/Custom-Report-Tables/#incidents","title":"Incidents","text":"R_Incidents INCIDENT_ID PROJECT_ID PRIORITY_ID SEVERITY_ID INCIDENT_STATUS_ID INCIDENT_TYPE_ID OPENER_ID OWNER_ID DESCRIPTION CREATION_DATE CLOSED_DATE LAST_UPDATE_DATE DETECTED_RELEASE_ID RESOLVED_RELEASE_ID START_DATE COMPLETION_PERCENT ESTIMATED_EFFORT ACTUAL_EFFORT REMAINING_EFFORT PROJECTED_EFFORT IS_DELETED VERIFIED_RELEASE_ID PRIORITY_NAME PRIORITY_COLOR SEVERITY_NAME SEVERITY_COLOR INCIDENT_STATUS_NAME INCIDENT_TYPE_NAME OPENER_NAME OWNER_NAME DETECTED_RELEASE_VERSION_NUMBER RESOLVED_RELEASE_VERSION_NUMBER VERIFIED_RELEASE_VERSION_NUMBER PROJECT_GROUP_ID PROJECT_NAME CUST_01... CUST_99 NAME IS_ATTACHMENTS COMPONENT_IDS INCIDENT_STATUS_IS_OPEN_STATUS PROJECT_IS_ACTIVE INCIDENT_TYPE_IS_ISSUE INCIDENT_TYPE_IS_RISK CONCURRENCY_DATE RANK END_DATE DETECTED_BUILD_ID RESOLVED_BUILD_ID DETECTED_BUILD_NAME RESOLVED_BUILD_NAME"},{"location":"Reporting/Custom-Report-Tables/#incident-priorities","title":"Incident Priorities","text":"R_IncidentPriorities PRIORITY_ID PROJECT_TEMPLATE_ID NAME COLOR IS_ACTIVE SCORE PROJECT_TEMPLATE_NAME"},{"location":"Reporting/Custom-Report-Tables/#incident-severities","title":"Incident Severities","text":"R_IncidentSeverities SEVERITY_ID PROJECT_TEMPLATE_ID NAME COLOR IS_ACTIVE SCORE PROJECT_TEMPLATE_NAME"},{"location":"Reporting/Custom-Report-Tables/#incident-statuses","title":"Incident Statuses","text":"R_IncidentStatuses INCIDENT_STATUS_ID PROJECT_TEMPLATE_ID NAME IS_ACTIVE IS_OPEN_STATUS IS_DEFAULT PROJECT_TEMPLATE_NAME"},{"location":"Reporting/Custom-Report-Tables/#incident-types","title":"Incident Types","text":"R_IncidentTypes INCIDENT_TYPE_ID PROJECT_TEMPLATE_ID WORKFLOW_ID NAME IS_ACTIVE IS_ISSUE IS_DEFAULT PROJECT_TEMPLATE_NAME"},{"location":"Reporting/Custom-Report-Tables/#portfolios","title":"Portfolios","text":"R_Portfolios PORTFOLIO_ID NAME DESCRIPTION IS_ACTIVE START_DATE END_DATE PERCENT_COMPLETE REQUIREMENT_COUNT"},{"location":"Reporting/Custom-Report-Tables/#program-milestones","title":"Program Milestones","text":"R_ProjectGroup_Milestones PROJECT_GROUP_MILESTONE_ID PROJECT_GROUP_ID TYPE_ID STATUS_ID NAME DESCRIPTION IS_DELETED START_DATE END_DATE PERCENT_COMPLETE CHILDREN_START_DATE CHILDREN_END_DATE PROJECT_RELEASE_COUNT PROJECT_GROUP_REQUIREMENT_COUNT CONCURRENCY_GUID CREATOR_ID OWNER_ID CREATION_DATE LAST_UPDATED_DATE STATUS_NAME STATUS_IS_OPEN TYPE_NAME CREATOR_NAME OWNER_NAME PROJECT_GROUP_NAME CUST_01... CUST_30"},{"location":"Reporting/Custom-Report-Tables/#program-milestone-releases","title":"Program Milestone Releases","text":"R_ProjectGroup_Milestone_Project_Releases PROJECT_GROUP_MILESTONE_ID RELEASE_ID ARTIFACT_LINK_TYPE_ID PROJECT_GROUP_MILESTONE_NAME RELEASE_NAME ARTIFACT_LINK_TYPE_NAME"},{"location":"Reporting/Custom-Report-Tables/#program-milestone-statuses","title":"Program Milestone Statuses","text":"R_ProjectGroup_Milestone_Statuses STATUS_ID NAME IS_ACTIVE IS_DELETED IS_DEFAULT IS_OPEN"},{"location":"Reporting/Custom-Report-Tables/#program-milestone-types","title":"Program Milestone Types","text":"R_ProjectGroup_Milestone_Types TYPE_ID NAME IS_ACTIVE IS_DELETED IS_DEFAULT"},{"location":"Reporting/Custom-Report-Tables/#project-artifacts-sharing","title":"Project Artifacts Sharing","text":"Retrieves data about cross product associations
R_ProjectArtifactSharings SOURCE_PROJECT_ID DEST_PROJECT_ID ARTIFACT_TYPE_ID SOURCE_PROJECT_NAME DEST_PROJECT_NAME ARTIFACT_TYPE_NAME ARTIFACT_TYPE_PREFIX"},{"location":"Reporting/Custom-Report-Tables/#projects-products","title":"Projects (Products)","text":"R_Projects PROJECT_ID PROJECT_GROUP_ID NAME DESCRIPTION CREATION_DATE WEBSITE WORKING_HOURS WORKING_DAYS NON_WORKING_HOURS TASK_DEFAULT_EFFORT PROJECT_GROUP_NAME PROJECT_GROUP_DESCRIPTION IS_ACTIVE IS_TIME_TRACK_INCIDENTS IS_TIME_TRACK_TASKS IS_EFFORT_INCIDENTS IS_EFFORT_TASKS IS_TASKS_AUTO_CREATE REQ_DEFAULT_ESTIMATE REQ_POINT_EFFORT IS_REQ_STATUS_BY_TASKS IS_REQ_STATUS_BY_TEST_CASES IS_EFFORT_TEST_CASES IS_REQ_STATUS_AUTO_PLANNED PROJECT_TEMPLATE_ID START_DATE END_DATE PERCENT_COMPLETE REQUIREMENT_COUNT CUST_01... CUST_30"},{"location":"Reporting/Custom-Report-Tables/#project-groups-programs","title":"Project Groups (Programs)","text":"R_ProjectGroups PROJECT_GROUP_ID NAME DESCRIPTION WEBSITE PROJECT_TEMPLATE_ID IS_ACTIVE IS_DEFAULT PERCENT_COMPLETE START_DATE END_DATE PORTFOLIO_ID REQUIREMENT_COUNT"},{"location":"Reporting/Custom-Report-Tables/#project-product-membership","title":"Project (Product) Membership","text":"R_ProjectMembership PROJECT_ID USER_ID PROJECT_ROLE_ID PROJECT_NAME PROJECT_ROLE_NAME USER_NAME FIRST_NAME LAST_NAME DEPARTMENT IS_SYSTEM_ADMIN"},{"location":"Reporting/Custom-Report-Tables/#project-release-resources","title":"Project Release Resources","text":"R_ProjectReleaseResources PROJECT_ID USER_ID RELEASE_ID INCIDENT_EFFORT TASK_EFFORT"},{"location":"Reporting/Custom-Report-Tables/#releases","title":"Releases","text":"R_Releases RELEASE_ID PROJECT_ID CREATOR_ID NAME VERSION_NUMBER DESCRIPTION INDENT_LEVEL CREATION_DATE LAST_UPDATE_DATE START_DATE END_DATE RESOURCE_COUNT DAYS_NON_WORKING PLANNED_EFFORT AVAILABLE_EFFORT COUNT_BLOCKED COUNT_CAUTION COUNT_FAILED COUNT_NOT_APPLICABLE COUNT_NOT_RUN COUNT_PASSED TASK_COUNT TASK_PERCENT_ON_TIME TASK_PERCENT_LATE_FINISH TASK_PERCENT_NOT_START TASK_PERCENT_LATE_START TASK_ESTIMATED_EFFORT TASK_ACTUAL_EFFORT TASK_PROJECTED_EFFORT TASK_REMAINING_EFFORT IS_DELETED CREATOR_NAME FULL_NAME PROJECT_NAME PROJECT_GROUP_ID CUST_01... CUST_99 RELEASE_TYPE_ID RELEASE_STATUS_ID OWNER_ID IS_SUMMARY IS_ATTACHMENTS OWNER_NAME RELEASE_TYPE_NAME RELEASE_STATUS_NAME CONCURRENCY_DATE MILESTONE_ID PERCENT_COMPLETE PLANNED_POINTS REQUIREMENT_POINTS REQUIREMENT_COUNT"},{"location":"Reporting/Custom-Report-Tables/#release-test-case-mapping","title":"Release Test Case Mapping","text":"R_ReleaseTestCases RELEASE_ID TEST_CASE_ID RELEASE_NAME RELEASE_VERSION_NUMBER TEST_CASE_NAME PROJECT_ID PROJECT_NAME RELEASE_TYPE_ID RELEASE_TYPE_NAME EXECUTION_STATUS_ID EXECUTION_DATE ACTUAL_DURATION"},{"location":"Reporting/Custom-Report-Tables/#requirements","title":"Requirements","text":"R_Requirements REQUIREMENT_ID AUTHOR_ID OWNER_ID RELEASE_ID PROJECT_ID IMPORTANCE_ID NAME CREATION_DATE INDENT_LEVEL DESCRIPTION LAST_UPDATE_DATE COVERAGE_COUNT_TOTAL COVERAGE_COUNT_PASSED COVERAGE_COUNT_FAILED COVERAGE_COUNT_CAUTION COVERAGE_COUNT_BLOCKED TASK_COUNT TASK_ESTIMATED_EFFORT TASK_ACTUAL_EFFORT TASK_PROJECTED_EFFORT TASK_REMAINING_EFFORT TASK_PERCENT_ON_TIME TASK_PERCENT_LATE_FINISH TASK_PERCENT_NOT_START TASK_PERCENT_LATE_START IS_DELETED AUTHOR_NAME OWNER_NAME IMPORTANCE_NAME RELEASE_VERSION_NUMBER PROJECT_NAME PROJECT_GROUP_ID CUST_01... CUST_99 REQUIREMENT_TYPE_ID REQUIREMENT_STATUS_ID COMPONENT_ID IS_SUMMARY IS_ATTACHMENTS CONCURRENCY_DATE REQUIREMENT_STATUS_NAME REQUIREMENT_TYPE_NAME COMPONENT_NAME ESTIMATE_POINTS ESTIMATED_EFFORT RANK GOAL_ID START_DATE END_DATE PERCENT_COMPLETE"},{"location":"Reporting/Custom-Report-Tables/#requirement-incidents","title":"Requirement Incidents","text":"R_RequirementIncidents INCIDENT_ID DETECTED_RELEASE_ID IS_OPEN_STATUS"},{"location":"Reporting/Custom-Report-Tables/#requirement-steps","title":"Requirement Steps","text":"R_RequirementSteps REQUIREMENT_ID POSITION DESCRIPTION IS_DELETED CREATION_DATE LAST_UPDATE_DATE CONCURRENCY_DATE REQUIREMENT_NAME REQUIREMENT_LAST_UPDATE_DATE PROJECT_IS_ACTIVE PROJECT_PROJECT_GROUP_ID PROJECT_NAME"},{"location":"Reporting/Custom-Report-Tables/#requirement-test-case-coverage","title":"Requirement Test Case Coverage","text":"R_RequirementTestCases REQUIREMENT_ID TEST_CASE_ID REQUIREMENT_NAME TEST_CASE_NAME PROJECT_ID PROJECT_NAME"},{"location":"Reporting/Custom-Report-Tables/#requirement-test-step-coverage","title":"Requirement Test Step Coverage","text":"R_RequirementTestSteps TEST_STEP_ID REQUIREMENT_NAME POSITION STEP_DESCRIPTION EXPECTED_RESULT SAMPLE_DATA PROJECT_ID PROJECT_NAME"},{"location":"Reporting/Custom-Report-Tables/#requirement-types","title":"Requirement Types","text":"R_RequirementTypes REQUIREMENT_TYPE_ID REQUIREMENT_WORKFLOW_ID PROJECT_TEMPLATE_ID NAME ICON IS_ACTIVE IS_STEPS IS_DEFAULT IS_KEY_TYPE PROJECT_TEMPLATE_NAME"},{"location":"Reporting/Custom-Report-Tables/#risks","title":"Risks","text":"R_Risks RISK_ID RISK_IMPACT_ID RISK_STATUS_ID RISK_PROBABILITY_ID RISK_TYPE_ID PROJECT_ID CREATOR_ID OWNER_ID PROJECT_GROUP_ID RELEASE_ID COMPONENT_ID NAME DESCRIPTION IS_DELETED CREATION_DATE LAST_UPDATE_DATE CONCURRENCY_DATE REVIEW_DATE GOAL_ID CLOSED_DATE IS_ATTACHMENTS RISK_PROBABILITY_NAME RISK_PROBABILITY_COLOR RISK_PROBABILITY_SCORE RISK_IMPACT_NAME RISK_IMPACT_COLOR RISK_IMPACT_SCORE RISK_EXPOSURE RISK_STATUS_NAME RISK_STATUS_IS_OPEN RISK_TYPE_NAME CREATOR_NAME OWNER_NAME RELEASE_VERSION_NUMBER RELEASE_NAME COMPONENT_NAME GOAL_NAME PROJECT_IS_ACTIVE PROJECT_PROJECT_GROUP_ID PROJECT_NAME CUST_01... CUST_99"},{"location":"Reporting/Custom-Report-Tables/#risk-impacts","title":"Risk Impacts","text":"R_RiskImpacts RISK_IMPACT_ID PROJECT_TEMPLATE_ID NAME COLOR IS_ACTIVE POSITION SCORE PROJECT_TEMPLATE_NAME"},{"location":"Reporting/Custom-Report-Tables/#risk-mitigations","title":"Risk Mitigations","text":"R_RiskMitigations RISK_ID POSITION DESCRIPTION IS_DELETED CREATION_DATE LAST_UPDATE_DATE CONCURRENCY_DATE IS_ACTIVE REVIEW_DATE RISK_NAME RISK_REVIEW_DATE PROJECT_IS_ACTIVE PROJECT_PROJECT_GROUP_ID PROJECT_NAME"},{"location":"Reporting/Custom-Report-Tables/#risk-probabilities","title":"Risk Probabilities","text":"R_RiskProbabilities RISK_PROBABILITY_ID PROJECT_TEMPLATE_ID NAME COLOR IS_ACTIVE POSITION SCORE PROJECT_TEMPLATE_NAME"},{"location":"Reporting/Custom-Report-Tables/#risk-statuses","title":"Risk Statuses","text":"R_RiskStatuses RISK_STATUS_ID NAME IS_ACTIVE IS_DEFAULT IS_OPEN POSITION PROJECT_TEMPLATE_ID PROJECT_TEMPLATE_NAME"},{"location":"Reporting/Custom-Report-Tables/#risk-types","title":"Risk Types","text":"R_RiskTypes RISK_TYPE_ID NAME IS_ACTIVE IS_DEFAULT PROJECT_TEMPLATE_ID RISK_WORKFLOW_ID PROJECT_TEMPLATE_NAME"},{"location":"Reporting/Custom-Report-Tables/#source-code-associations","title":"Source Code Associations","text":"R_SourceCodeAssociations ARTIFACT_SOURCE_CODE_REVISION_ID ARTIFACT_TYPE_ID ARTIFACT_ID REVISION_KEY COMMENT CREATION_DATE ARTIFACT_TYPE_NAME ARTIFACT_TYPE_PREFIX"},{"location":"Reporting/Custom-Report-Tables/#source-code-commits","title":"Source Code Commits","text":"R_SourceCodeCommits VERSION_CONTROL_SYSTEM_ID PROJECT_ID REVISION_ID NAME REVISION_KEY AUTHOR_NAME MESSAGE UPDATE_DATE CONTENT_CHANGED PROPERTIES_CHANGED VERSION_CONTROL_SYSTEM_NAME VERSION_CONTROL_SYSTEM_DESCRIPTION VERSION_CONTROL_SYSTEM_IS_ACTIVE PROJECT_NAME BRANCH_NAME BRANCH_PATH BRANCH_IS_HEAD"},{"location":"Reporting/Custom-Report-Tables/#tasks","title":"Tasks","text":"R_Tasks TASK_ID TASK_STATUS_ID PROJECT_ID REQUIREMENT_ID RELEASE_ID CREATOR_ID OWNER_ID TASK_PRIORITY_ID NAME DESCRIPTION CREATION_DATE LAST_UPDATE_DATE START_DATE END_DATE COMPLETION_PERCENT ESTIMATED_EFFORT ACTUAL_EFFORT PROJECTED_EFFORT REMAINING_EFFORT IS_DELETED TASK_STATUS_NAME OWNER_NAME CREATOR_NAME TASK_PRIORITY_NAME PROJECT_NAME PROJECT_GROUP_ID RELEASE_VERSION_NUMBER CUST_01... CUST_99 TASK_TYPE_ID TASK_FOLDER_ID IS_ATTACHMENTS CONCURRENCY_DATE REQUIREMENT_NAME TASK_TYPE_NAME COMPONENT_ID COMPONENT_NAME RISK_ID"},{"location":"Reporting/Custom-Report-Tables/#task-priorities","title":"Task Priorities","text":"R_TaskPriorities TASK_PRIORITY_ID PROJECT_TEMPLATE_ID NAME IS_ACTIVE COLOR SCORE PROJECT_TEMPLATE_NAME"},{"location":"Reporting/Custom-Report-Tables/#task-types","title":"Task Types","text":"R_TaskTypes TASK_TYPE_ID PROJECT_TEMPLATE_ID TASK_WORKFLOW_ID NAME POSITION IS_ACTIVE IS_DEFAULT IS_PULL_REQUEST PROJECT_TEMPLATE_NAME"},{"location":"Reporting/Custom-Report-Tables/#test-cases","title":"Test Cases","text":"R_TestCases TEST_CASE_ID EXECUTION_STATUS_ID TEST_CASE_PRIORITY_ID PROJECT_ID AUTHOR_ID NAME OWNER_ID DESCRIPTION EXECUTION_DATE CREATION_DATE LAST_UPDATE_DATE AUTOMATION_ENGINE_ID AUTOMATION_ATTACHMENT_ID ESTIMATED_DURATION IS_DELETED EXECUTION_STATUS_NAME TEST_CASE_PRIORITY_NAME AUTHOR_NAME OWNER_NAME AUTOMATION_ENGINE_NAME PROJECT_NAME PROJECT_GROUP_ID CUST_01... CUST_99 CONCURRENCY_DATE TEST_CASE_STATUS_ID TEST_CASE_TYPE_ID TEST_CASE_FOLDER_ID IS_ATTACHMENTS IS_TEST_STEPS ACTUAL_DURATION TEST_CASE_STATUS_NAME TEST_CASE_TYPE_NAME COMPONENT_IDS IS_SUSPECT"},{"location":"Reporting/Custom-Report-Tables/#test-case-folders","title":"Test Case Folders","text":"R_TestCaseFolders TEST_CASE_FOLDER_ID PARENT_TEST_CASE_FOLDER_ID PROJECT_ID NAME DESCRIPTION EXECUTION_DATE LAST_UPDATE_DATE ESTIMATED_DURATION ACTUAL_DURATION COUNT_PASSED COUNT_FAILED COUNT_BLOCKED COUNT_CAUTION COUNT_NOT_RUN COUNT_NOT_APPLICABLE PROJECT_NAME PROJECT_GROUP_ID"},{"location":"Reporting/Custom-Report-Tables/#test-case-incidents","title":"Test Case Incidents","text":"R_TestCaseIncidents INCIDENT_ID DETECTED_RELEASE_ID RESOLVED_RELEASE_ID VERIFIED_RELEASE_ID IS_OPEN_STATUS"},{"location":"Reporting/Custom-Report-Tables/#test-case-types","title":"Test Case Types","text":"R_TestCaseTypes TEST_CASE_TYPE_ID PROJECT_TEMPLATE_ID TEST_CASE_WORKFLOW_ID NAME IS_ACTIVE POSITION IS_DEFAULT IS_EXPLORATORY IS_BDD PROJECT_TEMPLATE_NAME"},{"location":"Reporting/Custom-Report-Tables/#test-configuration-entries","title":"Test Configuration Entries","text":"R_TestConfigurationEntries TEST_CONFIGURATION_SET_ID POSITION TEST_CONFIGURATION_SET_NAME IS_TEST_CONFIGURATION_SET_ACTIVE CUSTOM_PROPERTY_VALUE_ID TEST_CASE_PARAMETER_NAME TEST_CASE_PARAMETER_VALUE PROJECT_NAME PROJECT_GROUP_ID"},{"location":"Reporting/Custom-Report-Tables/#test-configuration-sets","title":"Test Configuration Sets","text":"R_TestConfigurationSets TEST_CONFIGURATION_SET_ID PROJECT_ID NAME DESCRIPTION IS_ACTIVE IS_DELETED CREATION_DATE LAST_UPDATED_DATE CONCURRENCY_DATE PROJECT_NAME PROJECT_GROUP_ID"},{"location":"Reporting/Custom-Report-Tables/#test-runs","title":"Test Runs","text":"R_TestRuns TEST_RUN_ID TEST_CASE_ID NAME DESCRIPTION ESTIMATED_DURATION ACTUAL_DURATION TEST_RUN_TYPE_ID TESTER_ID EXECUTION_STATUS_ID START_DATE END_DATE RUNNER_NAME RUNNER_TEST_NAME RUNNER_ASSERT_COUNT RUNNER_MESSAGE RUNNER_STACK_TRACE EXECUTION_STATUS_NAME TESTER_NAME TEST_RUNS_PENDING_ID RELEASE_ID TEST_SET_ID TEST_SET_TEST_CASE_ID RELEASE_NAME RELEASE_VERSION_NUMBER TEST_SET_NAME TEST_RUN_TYPE_NAME AUTOMATION_HOST_ID AUTOMATION_HOST_NAME AUTOMATION_ENGINE_ID BUILD_ID BUILD_NAME TEST_RUN_FORMAT_ID PROJECT_NAME PROJECT_GROUP_ID CUST_01... CUST_99 IS_ATTACHMENTS IS_DELETED CONCURRENCY_DATE PROJECT_ID CHANGESET_ID TEST_CONFIGURATION_ID"},{"location":"Reporting/Custom-Report-Tables/#test-run-incidents","title":"Test Run Incidents","text":"R_TestRunIncidents INCIDENT_ID DETECTED_RELEASE_ID RESOLVED_RELEASE_ID VERIFIED_RELEASE_ID IS_OPEN_STATUS"},{"location":"Reporting/Custom-Report-Tables/#test-run-steps","title":"Test Run Steps","text":"R_TestRunSteps TEST_RUN_STEP_ID EXECUTION_STATUS_ID TEST_CASE_ID TEST_STEP_ID TEST_RUN_ID DESCRIPTION POSITION EXPECTED_RESULT SAMPLE_DATA ACTUAL_RESULT EXECUTION_STATUS_NAME TEST_CASE_NAME PROJECT_ID PROJECT_NAME PROJECT_GROUP_ID START_DATE END_DATE ACTUAL_DURATION"},{"location":"Reporting/Custom-Report-Tables/#test-sets","title":"Test Sets","text":"R_TestSets TEST_SET_ID PROJECT_ID RELEASE_ID TEST_SET_STATUS_ID CREATOR_ID OWNER_ID AUTOMATION_HOST_ID TEST_RUN_TYPE_ID RECURRENCE_ID NAME DESCRIPTION CREATION_DATE PLANNED_DATE LAST_UPDATE_DATE IS_DELETED CONCURRENCY_DATE RELEASE_VERSION_NUMBER PROJECT_NAME TEST_CASE_COUNT TEST_SET_STATUS_NAME CREATOR_NAME OWNER_NAME PROJECT_ACTIVE_YN AUTOMATION_HOST_NAME TEST_RUN_TYPE_NAME RECURRENCE_NAME PROJECT_GROUP_ID CUST_01... CUST_99 TEST_SET_FOLDER_ID IS_ATTACHMENTS BUILD_EXECUTE_TIME_INTERVAL ESTIMATED_DURATION ACTUAL_DURATION COUNT_PASSED COUNT_FAILED COUNT_CAUTION COUNT_BLOCKED COUNT_NOT_RUN COUNT_NOT_APPLICABLE EXECUTION_DATE IS_DYNAMIC DYNAMIC_QUERY IS_AUTO_SCHEDULED TEST_CONFIGURATION_SET_ID"},{"location":"Reporting/Custom-Report-Tables/#test-set-folders","title":"Test Set Folders","text":"R_TestSetFolders TEST_SET_FOLDER_ID PROJECT_ID PARENT_TEST_SET_FOLDER_ID NAME DESCRIPTION CREATION_DATE LAST_UPDATE_DATE EXECUTION_DATE ESTIMATED_DURATION ACTUAL_DURATION COUNT_PASSED COUNT_FAILED COUNT_CAUTION COUNT_BLOCKED COUNT_NOT_RUN COUNT_NOT_APPLICABLE PROJECT_NAME PROJECT_GROUP_ID"},{"location":"Reporting/Custom-Report-Tables/#test-set-incidents","title":"Test Set Incidents","text":"R_TestSetIncidents INCIDENT_ID DETECTED_RELEASE_ID RESOLVED_RELEASE_ID VERIFIED_RELEASE_ID IS_OPEN_STATUS"},{"location":"Reporting/Custom-Report-Tables/#test-set-test-cases","title":"Test Set Test Cases","text":"R_TestSetTestCases TEST_SET_TEST_CASE_ID TEST_SET_ID TEST_CASE_ID OWNER_ID POSITION TEST_SET_NAME TEST_CASE_NAME OWNER_NAME PROJECT_ID PROJECT_NAME PLANNED_DATE IS_SETUP_TEARDOWN"},{"location":"Reporting/Custom-Report-Tables/#test-steps","title":"Test Steps","text":"R_TestSteps TEST_STEP_ID TEST_CASE_ID EXECUTION_STATUS_ID DESCRIPTION LINKED_TEST_CASE_ID POSITION EXPECTED_RESULT SAMPLE_DATA LAST_UPDATE_DATE IS_DELETED EXECUTION_STATUS_NAME TEST_CASE_NAME PROJECT_ID PROJECT_NAME PROJECT_GROUP_ID CUST_01... CUST_99 IS_ATTACHMENTS CONCURRENCY_DATE PRECONDITION"},{"location":"Reporting/Custom-Report-Tables/#users","title":"Users","text":"R_Users USER_NAME EMAIL_ADDRESS IS_ACTIVE CREATION_DATE LDAP_DN FIRST_NAME LAST_NAME MIDDLE_INITIAL DEPARTMENT LAST_UPDATE_DATE TIMEZONE LAST_OPENED_PROJECT_ID IS_APPROVED LAST_LOGIN_DATE LAST_ACTIVITY_DATE"},{"location":"Reporting/Custom-Report-Tutorial/","title":"Custom Reports Tutorial and Introduction","text":""},{"location":"Reporting/Custom-Report-Tutorial/#introduction","title":"Introduction","text":"One of the maxims I always tell developers is that regardless of what you build, customers will never be satisfied with the reports you offer or the integration that you provide. In fact the two most underestimated tasks in software development are data feeds and reporting. A great feature of SpiraPlan (and SpiraTest and SpiraTeam) is the ability to do custom reporting, so that you are not limited to only the reports that ship with the system. This guide explains how to use these powerful custom reporting features.
How to get more info and gotchas
You need to be a Spira system administrator to create or modify reports because they have the potential to affect all products in the system. To get to reports go to: Administration > System Administration > Reporting > Edit Reports:
From here you can either make a copy of one of the existing Spira built-in reports or create completely new report from scratch. The decision of which choice to make will depend on whether:
Once you have created your custom report, click on the Edit button for the report to go to the report details page. This displays a list of formats, sections, and the header and footer of the report.
When you edit a report you will see the following different items that can be changed/edited:
There are two types of report section that you can use in your report:
A report you create can have a mixture of the two sections, for example you could start the report with the standard project name and description and follow that with a custom section that displays a table of custom data (e.g. a risk cube or other table of data).
"},{"location":"Reporting/Custom-Report-Tutorial/#how-to-create-and-edit-a-custom-report","title":"How to Create and Edit a Custom Report","text":"In this tutorial you will learn how to:
The first thing we need to do is make a copy of one of the standard reports s that we can change it. For your safety, Spira will not let you modify the original copy of the report. To create a copy:
Clone next to the report you want to clone. In this example, we are going to make a copy of the \"Test Case Summary Report\":When editing a report, you can change the following fields:
For this example, we will edit the second Standard Section of the \"Test Case Summary Report\" clone. This report is a table-based layout. We will:
Under the list of 'Standard Sections', click the Customize button next to the 'Test Case List' section. This will show the edit dialog box for this section of the report:
Here, you can edit the following parts of the report section:
Feel free to edit the\u00a0Header\u00a0and\u00a0Footer\u00a0to make your section more readable, for example include a section heading or some introductory text. You might want to add a horizontal line (\\) to the footer to mark the end the report section.
The full contents of the\u00a0Template\u00a0section looks like the example below:
<?xml version=\"1.0\" encoding=\"utf-8\"?>\n<xsl:stylesheet version=\"1.0\" xmlns:xsl=\"http://www.w3.org/1999/XSL/Transform\" xmlns:msxsl=\"urn:schemas-microsoft-com:xslt\" exclude-result-prefixes=\"msxsl\">\n<xsl:template match=\"/TestCaseData\">\n<table class=\"DataGrid\" style=\"width:100%\">\n<tr>\n<th>Test #</th>\n<th>Name</th>\n<th>Description</th>\n<th>Priority</th>\n<xsl:if test=\"TestCase/TestSteps\">\n<th>Test Step</th>\n<th>Test Step Description</th>\n<th>Test Step Expected Result</th>\n<th>Test Step Sample Data</th>\n</xsl:if>\n<th>Status</th>\n<th>Author</th>\n<th>Owner</th>\n<th>Automation Engine</th>\n<th>Est. Duration</th>\n<th>Created On</th>\n<th>Last Modified</th>\n<th>Last Executed</th>\n<xsl:for-each select=\"TestCase[1]/CustomProperties/CustomProperty\">\n<th>\n<xsl:value-of select=\"Alias\" />\n</th>\n</xsl:for-each>\n</tr>\n<xsl:for-each select=\"TestCase\">\n<tr>\n<td>\n<xsl:value-of select=\"TestCaseId\" />\n</td>\n<td>\n<xsl:attribute name=\"style\">\npadding-left: <xsl:value-of select=\"string-length(IndentLevel)*2\" />\npx;\n </xsl:attribute>\n<if test=\"FolderYn='Y'\">\n<b><xsl:value-of select=\"Name\" /></b>\n</if>\n<if test=\"FolderYn='N'\">\n<xsl:value-of select=\"Name\" />\n</if>\n</td>\n<td>\n<xsl:value-of select=\"Description\" disable-output-escaping=\"yes\" />\n</td>\n<td>\n<xsl:value-of select=\"TestCasePriorityName\" />\n</td>\n<if test=\"TestSteps\">\n<td></td>\n<td></td>\n<td></td>\n<td></td>\n</if>\n<td>\n<xsl:value-of select=\"ExecutionStatusName\" />\n</td>\n<td>\n<xsl:value-of select=\"AuthorName\" />\n</td>\n<td>\n<xsl:value-of select=\"OwnerName\" />\n</td>\n<td>\n<xsl:value-of select=\"AutomationEngineName\" />\n</td>\n<td class=\"Timespan\">\n<xsl:value-of select=\"EstimatedDuration\" />\n</td>\n<td class=\"Date\">\n<xsl:call-template name=\"format-date\">\n<xsl:with-param name=\"datetime\" select=\"CreationDate\" />\n<\\xsl:call-template>\n </td>\n<td class=\"Date\">\n<xsl:call-template name=\"format-date\">\n<xsl:with-param name=\"datetime\" select=\"LastUpdateDate\" />\n<\\xsl:call-template>\n </td>\n<td class=\"Date\">\n<xsl:call-template name=\"format-date\">\n<xsl:with-param name=\"datetime\" select=\"ExecutionDate\" />\n<\\xsl:call-template>\n </td>\n<xsl:for-each select=\"CustomProperties/CustomProperty\">\n<td>\n<xsl:value-of select=\"Value\" />\n</td>\n</xsl:for-each>\n</tr>\n<xsl:for-each select=\"TestSteps/TestStep\">\n<tr>\n<td></td>\n<td></td>\n<td></td>\n<td></td>\n<td>\n<xsl:value-of select=\"position()\" />\n</td>\n<td>\n<xsl:value-of select=\"Description\" disable-output-escaping=\"yes\" />\n<xsl:value-of select=\"' '\" />\n<xsl:value-of select=\"LinkedTestCaseName\" />\n</td>\n<td>\n<xsl:value-of select=\"ExpectedResult\" disable-output-escaping=\"yes\" />\n</td>\n<td>\n<xsl:value-of select=\"SampleData\" disable-output-escaping=\"yes\" />\n</td>\n<td>\n<xsl:value-of select=\"ExecutionStatusName\" />\n</td>\n<td></td>\n<td></td>\n<td></td>\n<td></td>\n<td></td>\n<td></td>\n</tr>\n</xsl:for-each>\n</xsl:for-each>\n</table>\n</xsl:template>\n<xsl:template name=\"format-date\">\n<xsl:param name=\"datetime\" />\n<xsl:variable name=\"date\" select=\"substring-before($datetime, 'T')\" />\n<xsl:variable name=\"year\" select=\"substring-before($date, '-')\" />\n<xsl:variable name=\"month\" select=\"substring-before(substring-after($date, '-'), '-')\" />\n<xsl:variable name=\"day\" select=\"substring-after(substring-after($date, '-'), '-')\" />\n<xsl:variable name=\"time\" select=\"substring-before(substring-after($datetime, 'T'), '.')\" />\n<xsl:variable name=\"monthname\">\n<xsl:choose>\n<xsl:when test=\"$month='01'\">\n<xsl:value-of select=\"'Jan'\" />\n</xsl:when>\n<xsl:when test=\"$month='02'\">\n<xsl:value-of select=\"'Feb'\" />\n</xsl:when>\n<xsl:when test=\"$month='03'\">\n<xsl:value-of select=\"'Mar'\" />\n</xsl:when>\n<xsl:when test=\"$month='04'\">\n<xsl:value-of select=\"'Apr'\" />\n</xsl:when>\n<xsl:when test=\"$month='05'\">\n<xsl:value-of select=\"'May'\" />\n</xsl:when>\n<xsl:when test=\"$month='06'\">\n<xsl:value-of select=\"'Jun'\" />\n</xsl:when>\n<xsl:when test=\"$month='07'\">\n<xsl:value-of select=\"'Jul'\" />\n</xsl:when>\n<xsl:when test=\"$month='08'\">\n<xsl:value-of select=\"'Aug'\" />\n</xsl:when>\n<xsl:when test=\"$month='09'\">\n<xsl:value-of select=\"'Sep'\" />\n</xsl:when>\n<xsl:when test=\"$month='10'\">\n<xsl:value-of select=\"'Oct'\" />\n</xsl:when>\n<xsl:when test=\"$month='11'\">\n<xsl:value-of select=\"'Nov'\" />\n</xsl:when>\n<xsl:when test=\"$month='12'\">\n<xsl:value-of select=\"'Dec'\" />\n</xsl:when>\n<xsl:otherwise>\n<xsl:value-of select=\"''\" />\n</xsl:otherwise>\n</xsl:choose>\n<xsl:variable>\n<xsl:value-of select=\"concat($day, '-' ,$monthname, '-', $year , ' ', $time)\" />\n</xsl:template>\n</xsl:stlyesheet>\nThis is the underlying template that reads the data in Spira and turns it into a simple HTML table containing all of the columns and rows to be reported on. As you can see, it includes the HTML elements for the table:
<table class=\"DataGrid\" style=\"width:100%\">\nThe template also includes XSLT selectors for looping through all of the test cases in the Spira product:
<xsl:for-each select=\"TestCase\">\nBefore we can successfully modify the report, we need to understand what data is being returned by Spira.
"},{"location":"Reporting/Custom-Report-Tutorial/#viewing-the-data-available-for-reporting","title":"Viewing the Data Available for Reporting","text":"To see the data that is available for reporting, you need to open up another browser tab and then go to the\u00a0Reports\u00a0section of Spira:
Now click on the 'Test Case Summary' report from the left-hand navigation. This displays the Report Configuration page:
Create Report\u00a0buttonSpira will generate the report in \"raw XML format\":
<Report>\n<Title>\nTest Case Summary Report\n </Title>\n<ProjectData>\n<Project>\n<ArtifactPrefix>PR</ArtifactPrefix>\n<ArtifactType>Project</ArtifactType>\n<ArtifactToken>PR-1</ArtifactToken>\n<ArtifactId>1</ArtifactId>\n<ProjectId>1</ProjectId>\n<ProjectGroupId>2</ProjectGroupId>\n<Name>Library Information System</Name>\n<Description>\nSample application that allows users to manage books, authors and lending records for a typical branch library\n </Description>\n<CreationDate>2005-11-30T19:00:00</CreationDate>\n<Website>www.libraryinformationsystem.org</Website>\n<IsActive>True</IsActive>\n</Project>\n</ProjectData>\n<TestCaseData>\n<TestCase>\n<TestCaseId>1</TestCaseId>\n<ProjectId>1</ProjectId>\n<ExecutionStatusId>4</ExecutionStatusId>\n<AuthorId>2</AuthorId>\n<OwnerId>2</OwnerId>\n<TestCasePriorityId />\n<AutomationEngineId />\n<AutomationAttachmentId />\n<Name>l Tests</Name>\n<Description />\n<IndentLevel>A</IndentLevel>\n<ExecutionDate>3-11-30T19:00:00</ExecutionDate>\n<CreationDate>3-11-30T19:00:00</CreationDate>\n<LastUpdateDate>3-11-30T19:00:00</LastUpdateDate>\n<ConcurrencyDate>3-11-30T19:00:00</ConcurrencyDate>\n<EstimatedDuration />\n<VisibleYn>Y</VisibleYn>\n<FolderYn>Y</FolderYn>\n<ExpandedYn>Y</ExpandedYn>\n<ActiveYn>Y</ActiveYn>\n<AttachmentsYn>N</AttachmentsYn>\n<TestStepsYn>N</TestStepsYn>\n<FolderCountPassed>1</FolderCountPassed>\n<FolderCountFailed>3</FolderCountFailed>\n<FolderCountCaution>1</FolderCountCaution>\n<FolderCountBlocked>1</FolderCountBlocked>\n<FolderCountNotRun>0</FolderCountNotRun>\n<FolderCountNotApplicable>0</FolderCountNotApplicable>\n<ExecutionStatusName>N/A</ExecutionStatusName>\n<AuthorName>Fred Bloggs</AuthorName>\n<OwnerName>Fred Bloggs</OwnerName>\n<ProjectName />\n<TestCasePriorityName />\n<AutomationEngineName />\n<Custom_01 />\n<Custom_02 />\n...\n <Custom_30 />\n<IsDeleted>False</IsDeleted>\n<CustomProperties>\n<CustomProperty>\n<Alias>URL</Alias>\n<Name>Custom_01</Name>\n<Type>Text</Type>\n</CustomProperty>\n<CustomProperty>\n<Alias>Test Type</Alias>\n<Name>Custom_02</Name>\n<Type>List</Type>\n</CustomProperty>\n</CustomProperties>\n<Discussions />\n</TestCase>\n...\n <TestCaseData>\n</TestCaseData>\n</TestCaseData>\n</Report>\nThis fragment of the report lets you see all of the data that is available for displaying in your report. You can navigate this hierarchy of information using the special XSLT selection language called XPATH. This lets you query the data returned from Spira to retrieve specific data elements that can be displayed in the report. Before we start modifying the report XSLT to use this data, we first need to get a basic understanding of XPATH itself.
"},{"location":"Reporting/Custom-Report-Tutorial/#understanding-xpath","title":"Understanding XPATH","text":"(this section includes material from the website: http://www.whoishostingthis.com/resources/xslt/)
XPath is used to navigate through elements and attributes in an XML document. XPath uses path expressions to select nodes or node-sets in an XML document. These path expressions look very much like the expressions you see when you work with a traditional computer file system.
In XPath, there are seven kinds of nodes:
XML documents are treated as trees of nodes. The topmost element of the tree is called the root element.
In the examples that follow we shall be using the following simple XML document:
<?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<bookstore>\n<book>\n<title lang=\"en\">Harry Potter</title>\n<author>J K. Rowling</author>\n<year>2005</year>\n<price>29.99</price>\n</book>\n</bookstore>\nThis document contains the following node types:
XPath uses path expressions to select nodes in an XML document. The node is selected by following a path or steps. The most useful path expressions are listed below:
Expression Description nodename Selects all nodes with the name \\\"nodename\\\" / Selects from the root node // Selects nodes in the document from the current node that match the selection no matter where they are . Selects the current node .. Selects the parent of the current node @ Selects attributesIn the table below we have listed some path expressions and the result of the expressions if used on our sample document:
Path Expression Result bookstore Selects all nodes with the name \\\"bookstore\\\" /bookstore Selects the root element bookstore Note:\u00a0If the path starts with a slash ( / ) it always represents an absolute path to an element! bookstore/book Selects all book elements that are children of bookstore //book Selects all book elements no matter where they are in the document bookstore//book Selects all book elements that are descendant of the bookstore element, no matter where they are under the bookstore element //\\@lang Selects all attributes that are named lang"},{"location":"Reporting/Custom-Report-Tutorial/#predicates","title":"Predicates","text":"Predicates are used to find a specific node or a node that contains a specific value. Predicates are always embedded in square brackets.
In the table below we have listed some path expressions with predicates and the result of the expressions:
Path Expression Result /bookstore/book[1] Selects the first book element that is the child of the bookstore element /bookstore/book[last()] Selects the last book element that is the child of the bookstore element /bookstore/book[last()-1] Selects the last but one book element that is the child of the bookstore element /bookstore/book[position()\\<3] Selects the first two book elements that are children of the bookstore element //title[\\@lang] Selects all the title elements that have an attribute named lang //title[\\@lang='en'] Selects all the title elements that have a \\\"lang\\\" attribute with a value of \\\"en\\\" /bookstore/book[price>35.00] Selects all the book elements of the bookstore element that have a price element with a value greater than 35.00 /bookstore/book[price>35.00]/title Selects all the title elements of the book elements of the bookstore element that have a price element with a value greater than 35.00"},{"location":"Reporting/Custom-Report-Tutorial/#selecting-unknown-nodes","title":"Selecting Unknown Nodes","text":"XPath wildcards can be used to select unknown XML nodes:
Wildcard Description * Matches any element node @* Matches any attribute node node() Matches any node of any kindIn the table below we have listed some path expressions and the result of the expressions:
Path Expression Result /bookstore/* Selects all the child element nodes of the bookstore element //* Selects all elements in the document //title[@*] Selects all title elements which have at least one attribute of any kind"},{"location":"Reporting/Custom-Report-Tutorial/#selecting-several-paths","title":"Selecting Several Paths","text":"By using the | operator in an XPath expression you can select several paths.
In the table below we have listed some path expressions and the result of the expressions:
Path Expression Result //book/title | //book/price Selects all the title AND price elements of all book elements //title | //price Selects all the title AND price elements in the document /bookstore/book/title | //price Selects all the title elements of the book element of the bookstore element AND all the price elements in the documentNow that we understand the basics of XPath we can use that knowledge to modify our XSLT template to change the data that is included in our report.
"},{"location":"Reporting/Custom-Report-Tutorial/#modifying-the-report-xml-template","title":"Modifying the Report XML Template","text":"In the standard report it will display a list of test cases with various standard fields plus all of the custom properties (it uses an XSLT for-each loop to dynamically add all of the custom properties). For our example, we want to do the following:
To remove the test steps, delete the following sections from the XSLT template:
<xsl:if test=\\\"TestCase/TestSteps\\\">\n<th>Test Step</th>\n<th>Test Step Description</th>\n<th>Test Step Expected Result</th>\n<th>Test Step Sample Data</th>\n</xsl:if>\n<xsl:if test=\"TestSteps\">\n<td><td>\n<td></td>\n<td></td>\n<td></td>\n</xsl:if>\nThis removes the four columns related to test steps.
"},{"location":"Reporting/Custom-Report-Tutorial/#removing-the-creation-date","title":"Removing the Creation Date","text":"To remove the creation date, delete the header cell and body cell:
<th>Created On</th>\nand
<td class=\"Date\">\\\n <xsl:call-template name=\"format-date\">\n<xsl:with-param name=\"datetime\" select=\"CreationDate\" />\n</xsl:call-template>\\\n</td>\nNow to add the cell headers, we just need to add two \\ tags to the header of the table. This is done by adding:
<th>% Passed</th>\n<th>% Failed</th>\nNow to actually get the data, we need to use the following XPATH queries:
Note: the mathematical operators for XPATH are: + (add), * (multiply), - (subtract), and div (division). The slash is not used for division because it is already used as a node path separator.
So the section we need to add to the table body in the report would be:
<td>\n<xsl:value-of select=\"FolderCountPassed div (FolderCountPassed + FolderCountFailed + FolderCountCaution + FolderCountNotRun + FolderCountBlocked) * 100\" />\n%\n</td>\n<td>\n<xsl:value-of select=\"FolderCountFailed div (FolderCountPassed + FolderCountFailed + FolderCountCaution + FolderCountNotRun + FolderCountBlocked) * 100\" />\n%\n</td>\nNow that have make the changes, the complete XSLT template will be:
<?xml version=\"1.0\" encoding=\"utf-8\"?>\n<xsl:stylesheet version=\"1.0\" xmlns:xsl=\"http://www.w3.org/1999/XSL/Transform\" xmlns:msxsl=\"urn:schemas-microsoft-com:xslt\" exclude-result-prefixes=\"msxsl\">\n<xsl:template match=\"/TestCaseData\">\n<table class=\"DataGrid\" style=\"width:100%\">\n<tr>\n<th>Test #</th>\n<th>Name</th>\n<th>Description</th>\n<th>Priority</th>\n<th>Status</th>\n<th>Author</th>\n<th>Owner</th>\n<th>Automation Engine</th>\n<th>Est. Duration</th>\n<th>% Passed</th>\n<th>% Failed</th>\n<th>Last Modified</th>\n<th>Last Executed</th>\n<xsl:for-each select=\"TestCase[1]/CustomProperties/CustomProperty\">\n<th>\n<xsl:value-of select=\"Alias\" />\n</th>\n</xsl:for-each>\n</tr>\n<xsl:for-each select=\"TestCase\">\n<tr>\n<td>\n<xsl:value-of select=\"TestCaseId\" />\n</td>\n<td>\n<xsl:attribute name=\"style\">\npadding-left: <xsl:value-of select=\"string-length(IndentLevel)*2\" />\npx;\n </xsl:attribute>\n<if test=\"FolderYn='Y'\">\n<b><xsl:value-of select=\"Name\" /></b>\n</if>\n<if test=\"FolderYn='N'\">\n<xsl:value-of select=\"Name\" />\n</if>\n</td>\n<td>\n<xsl:value-of select=\"Description\" disable-output-escaping=\"yes\" />\n</td>\n<td>\n<xsl:value-of select=\"TestCasePriorityName\" />\n</td>\n<td>\n<xsl:value-of select=\"ExecutionStatusName\" />\n</td>\n<td>\n<xsl:value-of select=\"AuthorName\" />\n</td>\n<td>\n<xsl:value-of select=\"OwnerName\" />\n</td>\n<td>\n<xsl:value-of select=\"AutomationEngineName\" />\n</td>\n<td class=\"Timespan\">\n<xsl:value-of select=\"EstimatedDuration\" />\n</td>\n<td>\n<xsl:value-of select=\"FolderCountPassed div (FolderCountPassed + FolderCountFailed + FolderCountCaution + FolderCountNotRun + FolderCountBlocked) * 100\" />\n%\n </td>\n<td>\n<xsl:value-of select=\"FolderCountFailed div (FolderCountPassed + FolderCountFailed + FolderCountCaution + FolderCountNotRun + FolderCountBlocked) * 100\" />\n%\n </td>\n<td class=\"Date\">\n<xsl:call-template name=\"format-date\">\n<xsl:with-param name=\"datetime\" select=\"LastUpdateDate\" />\n</xsl:call-template>\n</td>\n<td class=\"Date\">\n<xsl:call-template name=\"format-date\">\n<xsl:with-param name=\"datetime\" select=\"ExecutionDate\" />\n</xsl:call-template>\n</td>\n<xsl:for-each select=\"CustomProperties/CustomProperty\">\n<td>\n<xsl:value-of select=\"Value\" />\n</td>\n</xsl:for-each>\n</tr>\n<xsl:for-each select=\"TestSteps/TestStep\">\n<tr>\n<td></td>\n<td></td>\n<td></td>\n<td></td>\n<td>\n<xsl:value-of select=\"position()\" />\n</td>\n<td>\n<xsl:value-of select=\"Description\" disable-output-escaping=\"yes\" />\n<xsl:value-of select=\"' '\" />\n<xsl:value-of select=\"LinkedTestCaseName\" />\n</td>\n<td>\n<xsl:value-of select=\"ExpectedResult\" disable-output-escaping=\"yes\" />\n</td>\n<td>\n<xsl:value-of select=\"SampleData\" disable-output-escaping=\"yes\" />\n</td>\n<td>\n<xsl:value-of select=\"ExecutionStatusName\" />\n</td>\n<td></td>\n<td></td>\n<td></td>\n<td></td>\n<td></td>\n<td></td>\n</tr>\n</xsl:for-each>\n</xsl:for-each>\n</table>\n</xsl:template>\n<xsl:template name=\"format-date\">\n<param name=\"datetime\" />\n<xsl:variable name=\"date\" select=\"substring-before($datetime, 'T')\" />\n<xsl:variable name=\"year\" select=\"substring-before($date, '-')\" />\n<xsl:variable name=\"month\" select=\"substring-before(substring-after($date, '-'), '-')\" />\n<xsl:variable name=\"day\" select=\"substring-after(substring-after($date, '-'), '-')\" />\n<xsl:variable name=\"time\" select=\"substring-before(substring-after($datetime, 'T'), '.')\" />\n<xsl:variable name=\"monthname\">\n<xsl:choose>\n<xsl:when test=\"$month='01'\">\n<xsl:value-of select=\"'Jan'\" />\n</xsl:when>\n<xsl:when test=\"$month='02'\">\n<xsl:value-of select=\"'Feb'\" />\n</xsl:when>\n<xsl:when test=\"$month='03'\">\n<xsl:value-of select=\"'Mar'\" />\n</xsl:when>\n<xsl:when test=\"$month='04'\">\n<xsl:value-of select=\"'Apr'\" />\n</xsl:when>\n<xsl:when test=\"$month='05'\">\n<xsl:value-of select=\"'May'\" />\n</xsl:when>\n<xsl:when test=\"$month='06'\">\n<xsl:value-of select=\"'Jun'\" />\n</xsl:when>\n<xsl:when test=\"$month='07'\">\n<xsl:value-of select=\"'Jul'\" />\n</xsl:when>\n<xsl:when test=\"$month='08'\">\n<xsl:value-of select=\"'Aug'\" />\n</xsl:when>\n<xsl:when test=\"$month='09'\">\n<xsl:value-of select=\"'Sep'\" />\n</xsl:when>\n<xsl:when test=\"$month='10'\">\n<xsl:value-of select=\"'Oct'\" />\n</xsl:when>\n<xsl:when test=\"$month='11'\">\n<xsl:value-of select=\"'Nov'\" />\n</xsl:when>\n<xsl:when test=\"$month='12'\">\n<xsl:value-of select=\"'Dec'\" />\n</xsl:when>\n<xsl:otherwise>\n<xsl:value-of select=\"''\" />\n</xsl:otherwise>\n</xsl:choose>\n</xsl:variable>\n<xsl:value-of select=\"concat($day, '-' ,$monthname, '-', $year , ' ', $time)\" />\n</xsl:template>\n</xsl:stylesheet>\nClick on the\u00a0Save\u00a0button to save your section and then the main\u00a0Save\u00a0button to save the report. You can now run the report through the main reports center and get something like:
Now we have learned how to modify one of the standard reports and use XSLT, XPATH and a 'standard section' to reformat how the data appears. You can use your knowledge of XPATH and XSLT to make more sophisticated changes. For example you could delete the entire XSLT default template and create a new template that displays a simple list of test cases, or a table of just test case names and IDs.
"},{"location":"Reporting/Custom-Report-Tutorial/#how-to-make-custom-queries","title":"How to Make Custom Queries","text":"In this article we shall be creating a whole new custom report that has a custom header, footer and a custom section that displays data based on a custom ESQL (Entity SQL) query. This is useful in cases where you have some special metrics that you want to be able publish in a report.
"},{"location":"Reporting/Custom-Report-Tutorial/#create-the-new-report","title":"Create the New Report","text":"First, go to Administration > System Administration > Reporting > Edit Reports.
and click on the\u00a0Add New Report\u00a0option. This will bring up the create new report page:
Enter the Name and Description of your new report (the description is optional and is used to describe the purpose of the report, the text is not displayed in the report itself). For example, we will enter:
Now enter in some text for the header and footer of the report (these will be displayed at the top and bottom of the entire report):
For our report, we'll choose the following formats and category:
The format choice is up to you, however the\u00a0category is important\u00a0because:
Before you add a custom section, let's include the name of the project and its description into the top of the report, underneath the header. To do that, click on the\u00a0Add New Standard Section\u00a0button and that will display the Standard Section dialog box:
On this page, choose the 'Product Overview' section from the dropdown list and then click 'Create Default Template' to display the standard XSLT template used for this report. This will populate the\u00a0Template\u00a0field with the standard Project Overview XSLT template. As described above, you can modify this XSLT to adjust how the Project Overview is displayed.
Click on the\u00a0Save\u00a0button.
Now we need to add our new custom section that contains our ESQL query. Click on the\u00a0Add New Custom Section\u00a0button and the new custom section dialog is displayed:
In this dialog box, we need to enter the name of the new section, a description, header, footer and then our ESQL query that is used to retrieve the data we need. For this example we'll enter:
Now in the query section, choose\u00a0'Releases'\u00a0as the base query to use. This will insert the following query:
select value R from SpiraTestEntities.R_Releases as R where R.PROJECT_ID = ${ProjectId}
Click on the\u00a0Preview Results\u00a0button to display the table of all the release fields. From this we can see what we want to include in the query:
Now change the query to only include the data that we want:
select R.NAME, R.VERSION_NUMBER, R.COUNT_PASSED, R.COUNT_FAILED, R.COUNT_NOT_RUN, R.COUNT_BLOCKED, R.COUNT_CAUTION from SpiraTestEntities.R_Releases as R where R.PROJECT_ID = ${ProjectId}\nThis will display the release name, and the test case counts for the current project. It will also include the deleted releases, so we need to add on a clause to the\u00a0WHERE\u00a0part of the query to make sure they are excluded:
select R.NAME, R.VERSION_NUMBER, R.COUNT_PASSED, R.COUNT_FAILED, R.COUNT_NOT_RUN, R.COUNT_BLOCKED, R.COUNT_CAUTION from SpiraTestEntities.R_Releases as R where R.PROJECT_ID = ${ProjectId}\nand R.IS_DELETED = False\nClick on the\u00a0Preview Results\u00a0button again to display the data we want:
To change the names of the columns to look a bit nicer, we can change the generated template. To do this, first click\u00a0Create Default Template\u00a0to generate the standard XSLT template for this query:
<?xml version=\"1.0\" encoding=\"utf-8\"?>\n<xsl:stylesheet version=\"1.0\" xmlns:xsl=\"http://www.w3.org/1999/XSL/Transform\" xmlns:msxsl=\"urn:schemas-microsoft-com:xslt\" exclude-result-prefixes=\"msxsl\">\n<xsl:template match=\"/RESULTS\">\n<table class=\"DataGrid\">\n<tr>\n<th>NAME</th>\n<th>VERSION_NUMBER</th>\n<th>COUNT_PASSED</th>\n<th>COUNT_FAILED</th>\n<th>COUNT_NOT_RUN</th>\n<th>COUNT_BLOCKED</th>\n<th>COUNT_CAUTION</th>\n</tr>\n<xsl:for-each select=\"ROW\">\n<tr>\n<td><xsl:value-of select=\"NAME\"/></td>\n<td><xsl:value-of select=\"VERSION_NUMBER\"/></td>\n<td><xsl:value-of select=\"COUNT_PASSED\"/></td>\n<td><xsl:value-of select=\"COUNT_FAILED\"/></td>\n<td><xsl:value-of select=\"COUNT_NOT_RUN\"/></td>\n<td><xsl:value-of select=\"COUNT_BLOCKED\"/></td>\n<td><xsl:value-of select=\"COUNT_CAUTION\"/></td>\n</tr>\n</xsl:for-each>\n</table>\n</xsl:template>\n</xsl:stylesheet>\nTo change the column headings to make them look better, we can change the template to look like this:
<?xml version=\"1.0\" encoding=\"utf-8\"?>\n<xsl:stylesheet version=\"1.0\" xmlns:xsl=\"http://www.w3.org/1999/XSL/Transform\" xmlns:msxsl=\"urn:schemas-microsoft-com:xslt\" exclude-result-prefixes=\"msxsl\">\n<xsl:template match=\"/RESULTS\">\n<table class=\"DataGrid\">\n<tr>\n<th>Release</th>\n<th>Version</th>\n<th># Passed</th>\n<th># Failed</th>\n<th># Not Run</th>\n<th># Blocked</th>\n<th># Caution</th>\n</tr>\n<xsl:for-each select=\"ROW\">\n<tr>\n<td><xsl:value-of select=\"NAME\"/></td>\n<td><xsl:value-of select=\"VERSION_NUMBER\"/></td>\n<td><xsl:value-of select=\"COUNT_PASSED\"/></td>\n<td><xsl:value-of select=\"COUNT_FAILED\"/></td>\n<td><xsl:value-of select=\"COUNT_NOT_RUN\"/></td>\n<td><xsl:value-of select=\"COUNT_BLOCKED\"/></td>\n<td><xsl:value-of select=\"COUNT_CAUTION\"/></td>\n</tr>\n</xsl:for-each>\n</table>\n</xsl:template>\n</xsl:stylesheet>\nOnce you are happy with the result, click on the\u00a0Save\u00a0button on the custom section and then the\u00a0Save\u00a0button on the report editing screen itself.
You can now run the report through the main reports center and get something like:
Release Version # Passed # Failed # Not Run # Blocked # Caution Library System Release 1 1.0.0.0 0 2 4 0 1 Library System Release 1 SP1 1.0.1.0 3 0 3 1 0 Library System Release 1 SP2 1.0.2.0 2 0 5 0 0"},{"location":"Reporting/Custom-Report-Tutorial/#conclusion_1","title":"Conclusion","text":"Now we have learned how to create a custom report and a use a combination of standard sections and custom sections to product a report that includes data specific to your business. You can use your knowledge of SQL and XSLT to make more sophisticated changes. For example, you could join multiple tables and use SQL aggregation functions to generate summary reports from other parts of the system.
The language that we use for creating custom graphs and reports in Spira is called \"Entity SQL\" (abbreviated to ESQL). Please read our dedicated tutorial to learn how ESQL works and how it is similar and different to standard SQL.
"},{"location":"Reporting/Custom-Reporting-Tokens/","title":"Tokens for Custom Reporting","text":""},{"location":"Reporting/Custom-Reporting-Tokens/#introduction","title":"Introduction","text":"When creating custom reports or custom graphs, you can use special tokens in your query. These are evaluated during the generation of the report or graph to make sure that your report is dynamically limited to the specific context the user is in when they run the report. These are listed below.
You do not have to use these tokens. You can hard code a report to query only against a specific value that the token would return dynamically (eg set the ProjectId to 1 rather than to the current ProjectId of the product the user is in). You can also exclude that part of the query entirely, so that the report will include all the items in the entire system, with no restriction by a token / that field.
"},{"location":"Reporting/Custom-Reporting-Tokens/#available-tokens","title":"Available Tokens","text":"This token limits the data to the release selected in the release dropdown. For custom graphs this is the dropdown on the main reporting page. For custom reports, this dropdown is shown at the bottom of the report configuration page in a section called \"Custom Section Filters\".
If \"All Releases\" is selected, custom graphs/reports using this token display no data. If a specific release is selected, then the graph will display data for that release only.
Example query:
select R.EXECUTION_STATUS_NAME, COUNT (R.TEST_RUN_ID) as COUNT\nfrom SpiraTestEntities.R_TestRuns as R\nwhere R.PROJECT_ID = ${ProjectId} and R.RELEASE_ID = ${ReleaseId}\ngroup by R.EXECUTION_STATUS_NAME\nThis token limits the data to the selected release and to data from that release's children.
If \"All Releases\" is selected data against all active releases in the current product will be returned. For example, if your custom graph shows requirements by release, with \"All Releases\" selected, the graph will show any requirement with an active release set on the release field (which matches the list of releases in the release dropdown). In other words, requirements with no release set will not be included.
If a specific release is selected that does not have any active children data for that release only will be returned.
If a release with active children is selected data for that release and all of its active children (ie any children shown in the release dropdown at the top of the page) will be returned.
Please note: an \"active\" release is one with a status of Planned, In Progress, or Completed.
Example query (note the use of \"in\" before the token):
select R.EXECUTION_STATUS_NAME, COUNT (R.TEST_RUN_ID) as COUNT\nfrom SpiraTestEntities.R_TestRuns as R\nwhere R.PROJECT_ID = ${ProjectId} and R.RELEASE_ID in {${ReleaseAndChildIds}}\ngroup by R.EXECUTION_STATUS_NAME\nOData is an open protocol that lets you easily query data, over the web. Exclusive to SpiraPlan (6.9+), with OData you can directly query the raw data in your database in a secure and safe way. Whenever you use OData in SpiraPlan you are communicating through a secure intermediary (the application itself) to get data from read-only reporting views. Tools like Excel, PowerBI, Tableau support OData and can therefore communicate with SpiraPlan to access this data with just a few clicks.
With OData you don't need to be a SQL expert to generate rich and dynamic insights into your data. If you can fiddle with a spreadsheet, you can stich tables of data from SpiraPlan (\"joins\" in database language) to get just the data you need. What sort of insights can you get with OData and SpiraPlan reporting views? Here are some examples:
In this tutorial series we will be using Excel and its built-in Power Query to communicate with SpiraPlan. Over this series we will build up to creating the final example listed above: a list of the most reopened bugs. This is not meant as a tutorial of Power Query itself, there are lots of those online. But if you don't know how to use Power Query don't worry, you will still be able to follow along
"},{"location":"Reporting/OData-Tutorial/#connecting-excel-and-spiraplan-using-odata","title":"Connecting Excel and SpiraPlan using OData","text":"In the first tutorial you will learn how to:
Not all SpiraPlan users can connect to OData to see live data. Access to OData lets you see all data across all products in your entire system - it is not restricted by product membership or product role permissions. Therefore you need to think carefully about who can and should have this read-only access.
Two types of users can use OData:
Each user can be one, both, or neither of these. Admins can turn these settings on or off in the admin user profile screens.
Before carrying on with this tutorial make sure you are either a system or report admin, are using SpiraPlan, and are on at least version 6.9.0.0.
"},{"location":"Reporting/OData-Tutorial/#connect-excel-and-spiraplan","title":"Connect Excel and SpiraPlan","text":"Open Excel and find the Get Data > From OData Feed button. This should be in the Data ribbon, under Get Data > From Other Sources.
Once you click this button you will see a popup. Stick with \"Basic\" and enter the special OData url for your SpiraPlan. This is the \"base url\" for your application with \"api/odata\" added at the end. If your site is at https://mycompany.spiraservice.net/ then your OData url will be https://mycompany.spiraservice.net/api/odata. Click OK.
Once Excel connects to SpiraPlan you see a popup \"Navigator\" where you can see all the different data views you can access (\"query\"). There is a lot here and a lot to explore. You can access pretty much all the information in your application, across all its products and templates, from these views. But if you click on now to take a look you will not be able to see anything. That's because you have not authenticated yet with Spira. You have to authenticate to view this data for obvious security reasons.
To authenticate you need to pieces of information:
You can find both of these on your Profile page in the application.
In Excel, the easiest way to add your authentication information is to click on one of the view names. It will fail, then show you a dialog box like this:
Click on \"Basic\" on the left, then fill it in as below and click Connect.
You should now see a preview of the table you clicked on. Here we are looking at incidents. You can see a few rows of data, not everything.
To see all the data you have two options:
We will finish this first tutorial by clicking \"Load\". Your new sheet with Incident data in should look something like this...
You can now: connect Excel and Spira together using OData and view data from Spira live in Excel. In the next tutorial we will build a simple query to filter the data to just those parts we are interested in
"},{"location":"Reporting/OData-Tutorial/#writing-your-first-query","title":"Writing your first query","text":"In this tutorial you will learn how to use Excel's Power Query to filter down all the Incidents in your SpiraPlan application. You will end up with a list of incidents in a single product, sorted by priority. You do not need any coding or SQL skills - everything you do will feel very similar to how you normal use Excel itself.
To get started:
The Power Query interface looks very similar to Excel
The Power Query Editor window is made up of:
To make the data easier to look at and filter, the first thing to do is get rid of columns we don't need. Ther are well over 100 columns (because of all the custom fields we include) and that is way too many.
Click on the \"Choose Columns\" button from the Home ribbon. Only select the following columns (make sure the rest are unchecked), and then click OK
You should now see a table of data like the one below. We are showing all the records still, but only 5 columns. The query settings sidebar has an extra line at the end that says \"Removed Other Columns.\" This is what we just did. You can undo the action by deleting it from the sidebar, or change which columns to show by double clicking on it.
"},{"location":"Reporting/OData-Tutorial/#filtering-data","title":"Filtering data","text":"Just like when filtering data on a sheet, the column names have dropdown arrows to open the filtering popup.
You have filtered your data! That's all there is to it. It is really easy. What is cool, is that we are not hiding rows of our table like we do in Excel normally. We are actually changing the query we are sending to SpiraPlan so that SpiraPlan is only sending us the information we have asked for.
Let's filter again. This time filter on the INCIDENT_TYPE_NAME column. Below we are filtering to show Bugs and Enhancements. So we are now seeing only certain types of incidents in a single product. You can see below we have a new entry in the list of Applied Steps in the right hand sidebar - for our Filtering Rows work.
"},{"location":"Reporting/OData-Tutorial/#sorting-data","title":"Sorting data","text":"Sorting data is just as easy as filtering data. Click on the dropdown arrow for the column you want to sort by and click \"Sort Ascending\" or \"Sort Descending\". That's all there is to it. You can, if you want, sort by multiple columns at once. In the example below, we are sorting ascending by the NAME column. Again, there is a new entry in the list of Applied Steps in the right hand sidebar - for our Sorting Rows.
Hopefully, this feels very straightforward, because it is. In the background Excel is creating the right OData query to send to SpiraPlan, which is then writing a secure query to the database to get just the data you need. But you don't need to think about any of that.
In the next tutorial we are going to try another query with incidents and make things more complicated by combining data across two tables at once.
"},{"location":"Reporting/OData-Tutorial/#combining-two-lots-of-data","title":"Combining two lots of data","text":"In this tutorial we will start to see the real power of reporting using OData. Until now we have been filtering and sorting a single list of incidents. Now we are going to do the same filtering and sorting but now across two tables joined together. Combining (joining) data in this way let's us do things with SpiraPlan's data like:
We are going to focus on the final example above in this tutorial, and add to it in the next tutorial
"},{"location":"Reporting/OData-Tutorial/#preparing-our-incident-data","title":"Preparing our incident data","text":"From the end of our last tutorial we had a list of bugs and enhancements in a single product. We can see names for things like the product (project in database terms), status, and type. This is what we see in SpiraPlan itself.
Behind each status name is a unique number identified (ID). This lets us change, for example, the status name, but still make sure the incidents with that status show with that updated name.
To properly match data across different tables of data we should match on this ID fields. Do this:
Excel has asked SpiraPlan for this extra data and is now showing it to us. But notice that you are now seeing all incidents again, and \"Removed Other Columns\" is highlighted in the list of Applied Steps. Click on the bottom step \"Sorted Rows\". This will apply all the steps that follow our now updated \"Removed Other Columns.\" This is a great feature - we can, within limits, edit previous steps we have made to our query, then go back to our most current step in the process. We now have the same list of incidents we ended the last tutorial with, but showing this extra column.
"},{"location":"Reporting/OData-Tutorial/#joining-queries-together","title":"Joining queries together","text":"The process for joining data across two tables (queries as Power Query calls them) is:
Right now we are only showing Incident data. To join it up with Incident Status data we need to add that table as a new query. To do that, carry out the following steps:
We now have two different queries that are completely independent from each other. We want to connect them together. For each incident we want to get extra information about its status. The main query is Incidents, and the secondary query is IncidentStatuses. So click on the Incidents query in the Queries sidebar to make sure we are viewing our Incident query again. Now, carry out the following steps:
We now see the output of our merge query. Our query looks very similar - it has the same number of rows, but has gained an extra column \"IncidentStatuses\" at the right. The Applied Steps list has a new entry too: \"Merged Queries.\" We know that merge has worked, but we can't see any extra data yet. That's because Project data is collapsed: in each cell in the IncidentStatuses column we see the word Table, which tells us that there is a whole set of data hiding inside that cell, waiting for us to look at it.
This is the 3rd and final step of the merge - choosing which columns to show from our extra data we have merged in. To the right of the IncidentStatuses column name you will see the little button looks different. It is not a dropdown arrow but a weird double arrow. Click this to choose how to expand the data from the IncidentStatuses data into new columns. You will see the familiar column picker. Only select the IS_OPEN_STATUS field and click OK.
The table is updated with an extra column called \"IncidentStatuses.IS_OPEN_STATUS\" and the Applied Steps list has a new entry \"Expanded IncidentStatuses.\"
In this simple example we have added extra information to each incident row about the incident status that applies to that incident.
The same principles can be used for combining data from many other tables together. The critical thing for this to work is that there are columns that match between the two tables you want to join. Imagine, for instance, if we match INCIDENT_ID from Incidents with INCIDENT_STATUS_ID from IncidentStatuses. The data may look interesting but it would be nonsense and not useable. It should almost always be obvious by the column name how it will match up with other columns in different tables.
As a final step in this tutorial, let's do something with this extra data we have. We now know which incidents are open or closed but that IS_OPEN_STATUS flag (TRUE = open, FALSE = closed). Filter on the \"IncidentStatuses.IS_OPEN_STATUS\" column the same as any other column, and select only the open incidents (TRUE). This added a new Applied Step \"Filtered Rows1.\"
This query is really easy to do on the list of Incidents using SpiraPlan itself. We have replicated that functionality using OData to talk between Excel and SpiraPlan. In this way you can easily compare SpiraPlan and your query to see if the results match. As you can see the image above and the one below show the same exact incidents in the same order (because have applied the same filter and sorting in both places).
In the final tutorial we are going to build on the query we have built but rapidly extend it with a number of other joins and semi-advanced filtering.
"},{"location":"Reporting/OData-Tutorial/#building-complex-queries","title":"Building complex queries","text":"In this tutorial we start with the output from the previous tutorial: a list of open bugs and enhancements for one product. By the end of this tutorial we will have a spreadsheet of data that shows, for a portfolio, the number of open bugs and enhancements each user is assigned. That's quite a transformation so let's get started.
Your data should look a little like that below. You can see here that we have incidents across different products, assigned to a handful of different users, who together work in two different departments (QA and Software Engineering).
Now we have three more merges and expanding columns to do:
Projects
ProjectGroups
Portfolios
The query should now have a total of 14 columns. It combines data across 6 different tables from SpiraPlan to show us details about the user assigned to each incident and the program, and portfolio each incident is in. Your data should look something like that below (note the list of Applied Steps). If at anytime you have done something wrong, remember you can edit a step, or delete a step entirely and do it again.
We're ready for the final stage: grouping data. This will let us count up the number of incidents assigned to each user. Follow the steps below:
.
This results in a condensed query of data that has unique rows for each user in each portfolio. The right hand column is called Count and is the number of open bugs and enhancements that the user has in that portfolio.
.
Click \"Close and Load from the ribbon to load this data into Excel. From here you can do anything with the data you want. For instance, you can turn it into a pivot table to tell you how many open bugs and enhancements there are, in total, in each portfolio.
This brings us to the end of the OData tutorial series. Hopefully you can see the power of OData and the ease with which you can interrogate your data and draw out insights from it. You can create much more complex data that we have done here, or use more complex reporting tools to create live data dashboards that let you extend SpiraPlan with customized queries that make sense to your organization.
"},{"location":"Reporting/Understanding-Entity-SQL/","title":"Understanding Entity SQL","text":""},{"location":"Reporting/Understanding-Entity-SQL/#understanding-entity-sql-esql","title":"Understanding Entity SQL (ESQL)","text":"This guide explains how you can use Entity SQL to write queries to pull back the data you need when working with custom reports in SpiraPlan.
The language that we use for creating custom graphs and reports in Spira is called \"Entity SQL\" (abbreviated to ESQL) and is based on the standard database Structured Query Language (SQL) but modified by Microsoft to work against a conceptual object oriented data structure rather than a traditional relational database. According to the Microsoft Entity SQL website:
Entity SQL is a SQL-like language that enables you to query conceptual models in the Entity Framework. Conceptual models represent data as entities and relationships, and Entity SQL allows you to query those entities and relationships in a format that is familiar to those who have used SQL.
"},{"location":"Reporting/Understanding-Entity-SQL/#entity-sql-syntax-basics","title":"Entity SQL Syntax Basics","text":"Similar to database SQL, ESQL supports query that consists of the following parts:
select properties or object\nfrom entity collection as alias\njoin other entity collections on relationship\nwhere conditions\ngroup by properties\norder by properties\nWhen using ESQL with Spira's reporting system, the entity collections you can use are the ones generated from the 'Add New Query' dropdown discussed in the previous article. For example, you have:
The R_xxx prefix is used to distinguish the entities available for reporting from the core entities used by Spira internally for its data access. You will only ever be able query the R_ prefixed entities from within the Spira reporting system.
A simple query used to retrieve all of the requirements in project 1 sorted by hierarchical order then ID would be:
select value RQ\nfrom SpiraTestEntities.R_Requirements as RQ\nwhere RQ.PROJECT_ID = 1\norder by RQ.INDENT_LEVEL, RQ.REQUIREMENT_ID\nA more complex query that selects specific requirement properties (vs. the entire object), joins to other table (e.g. to get test case object properties as well) would be:
select RQ.REQUIREMENT_ID, RQ.NAME as REQUIREMENT_NAME, TC.TEST_CASE_ID, TC.NAME as TEST_CASE_NAME\nfrom SpiraTestEntities.R_Requirements as RQ\njoin SpiraTestEntities.R_RequirementTestCases as RT on RQ.REQUIREMENT_ID = RT.REQUIREMENT_ID\njoin SpiraTestEntities.R_TestCases as TC on RT.TEST_CASE_ID = TC.TEST_CASE_ID where RQ.PROJECT_ID = 1\norder by RQ.NAME, TC.NAME\nFinally, you can add on an aggregation function and group by to group by one property and aggregate the other properties against this. For example to get a count of the test cases associated with each requirement, instead of the test case names would be:
select RQ.REQUIREMENT_ID, RQ.NAME as REQUIREMENT_NAME, COUNT(TC.TEST_CASE_ID) as TEST_CASE_COUNT\nfrom SpiraTestEntities.R_Requirements as RQ\njoin SpiraTestEntities.R_RequirementTestCases as RT on RQ.REQUIREMENT_ID = RT.REQUIREMENT_ID\njoin SpiraTestEntities.R_TestCases as TC on RT.TEST_CASE_ID = TC.TEST_CASE_ID\nwhere RQ.PROJECT_ID = 1\ngroup by RQ.REQUIREMENT_ID, RQ.NAME\norder by TEST_CASE_COUNT desc, RQ.REQUIREMENT_ID\nIn this last case, we're sorting the list of requirements by the count of associated test cases (in descending order).
So now that we have seen some example queries, let's examine each of the parts of the query in turn:
"},{"location":"Reporting/Understanding-Entity-SQL/#the-select-clause","title":"The SELECT Clause","text":"The select clause of an ESQL query can consist of either:
So for example we could have:
select value RQ\nthat selects all of the properties in the requirements table (i.e. all the columns).
Alternatively you could select specific properties (columns) from one or more object:
select RQ.REQUIREMENT_ID, RQ.NAME as REQUIREMENT_NAME, TC.TEST_CASE_ID, TC.NAME as TEST_CASE_NAME\nIn this case, we omit the value prefix since it's not evaluating all of the properties of an object. Since two of the properties have the same name (\"NAME\") we are using the as operator to give the property returned a unique name. This is important. If you try and return back two properties with the same name, Spira will give the following error message:
You get this error message because the Entity framework will try and create a name like (NAME #1) that is not allowed by the Spira reporting system. So make sure you used actual named aliases when the same property name is used more than once.
Finally you can use the following aggregations in the SELECT clause to aggregate data from properties that are not being grouped (see later for information on the group by clause):
A full list of Entity SQL aggregate functions can be found on the Microsoft ESQL reference website.
For example, we can count how many times one property appears relative to another column:
select RQ.REQUIREMENT_ID, RQ.NAME as REQUIREMENT_NAME, COUNT(TC.TEST_CASE_ID) as TEST_CASE_COUNT\nNote that in this case we recommend you always specify an alias for the result of the aggregation function using the as operator. If you forget, you'll get the same error message as before:
"},{"location":"Reporting/Understanding-Entity-SQL/#the-from-clause","title":"The FROM Clause","text":"The from clause in ESQL is relatively simple, it contains the primary object collection being queried and an alias that will be used to reference its properties in the other parts of the query:
from SpiraTestEntities.R_Requirements as RQ\nIf you are only going to need to work with the properties from a single object collection then you don't need to have any join clauses in your query. However if you are going to need data from multiple object collections, then you will need to use the join clause to add in those other collections. A simple join clause looks like:
join SpiraTestEntities.R_RequirementTestCases as RT on RQ.REQUIREMENT_ID = RT.REQUIREMENT_ID\nwhere you add the name of the entity collection being joined, the alias to refer to it with, and the comparison operator (in this case an equality) used to make the join.
Entity SQL supports the following types of join:
The where clause in ESQL lets you filter the results by one or more condition. In addition to the standard ESQL syntax, you can use the special Spira tokens to filter by dynamic data in the system:
The where clause consists of a set of conditions that are joined by a boolean operator:
Generally and operators have higher precedence than or operators, so you will need to use parenthesis when you want to have or operators that are higher precedence than an and.
For example:
where (RQ.PROJECT_ID = 1 or RQ.PROJECT_ID = 2) and RQ.IS_DELETED = 0\nmeans that you will retrieve any un-deleted requirement that is in project 1 or project 2, whereas this would mean something completely different:
where RQ.PROJECT_ID = 1 or RQ.PROJECT_ID = 2 and RQ.IS_DELETED = 0\nthis would retrieve all (including deleted) requirements in project 1, and any un-deleted ones from project 2.
The type of operator you can use in the various conditions include:
Greater than
= Greater than or equals
For example you might have a compound conditional clause such as:
where RQ.PROJECT_ID >= 1 and RQ.PROJECT_ID <= 4 and RQ.IS_DELETED = 0 and (RQ.TASK_ACTUAL_EFFORT + RQ.TASK_REMAINING_EFFORT) > 0\nIn the discussion of the select clause we mentioned that you can use aggregation functions such as count, sum, min, max, etc. If you use these in the select clause, then any object properties that are not being aggregated need to be included in the group by clause:
group by RQ.REQUIREMENT_ID, RQ.NAME\nIf you don't have any aggregation functions, you can still use a group by clause to simply group similar rows, but generally speaking you omit the group by clause if there are no aggregation functions in the select list.
"},{"location":"Reporting/Understanding-Entity-SQL/#sorting-and-order-by","title":"Sorting and ORDER BY","text":"Finally, you typically want to sort the data by one or more of the object properties, this is done by having an order by clause at the end of the query:
order by TEST_CASE_COUNT desc, RQ.REQUIREMENT_ID asc\nThe syntax of the order by clause is:
If you sort by a property (e.g. requirement name) that could be held by multiple rows, it is recommended to always add a final sort clause by a guaranteed unique ID such as the primary key REQUIREMENT_ID since that will ensure the results are consistent each time. This is known as 'stable sorting'
"},{"location":"Reporting/Understanding-Entity-SQL/#differences-between-esql-and-traditional-database-sql","title":"Differences Between ESQL and Traditional Database SQL","text":"Now that we have covered the basics of writing an Entity SQL (ESQL) query, we'll discuss some of the differences and limitations between ESQL and traditional database SQL.
"},{"location":"Reporting/Understanding-Entity-SQL/#no-support-for","title":"No Support for *","text":"Database SQL supports the unqualified * syntax as an alias for the entire row, and the qualified * syntax (t.*) as a shortcut for the fields of that table. In addition, database SQL allows for a special count(*) aggregate, which includes nulls.
Entity SQL does not support the * construct. Database SQL queries of the form:
select * from T\nand
select T1.* from T1, T2...\ncan be expressed in Entity SQL as
select value t from T as t\nand
select value t1 from T1 as t1, T2 as t2...\nrespectively.
Additionally, these constructs handle inheritance (value substitutability), while the select * variants are restricted to top-level properties of the declared type. Entity SQL does not support the count(*) aggregate. Use count(0) instead.
Entity SQL supports aliasing of group by keys. Expressions in the select clause and having clause must refer to the group by keys via these aliases. For example, this Entity SQL syntax:
SELECT k1, count(t.a), sum(t.a)\nFROM T AS t\nGROUP BY t.b + t.c AS k1\n...is equivalent to the following database SQL:
"},{"location":"Reporting/Understanding-Entity-SQL/#sql","title":"SQL","text":"SELECT b + c, count(*), sum(a)\nFROM T\nGROUP BY b + c\nEntity SQL supports two kinds of aggregates.
Collection-based aggregates operate on collections and produce the aggregated result. These can appear anywhere in the query, and do not require a group by clause. For example:
SELECT t.a AS a, count({1,2,3}) AS b FROM T AS t\nEntity SQL also supports SQL-style aggregates. For example:
SELECT a, sum(t.b) FROM T AS t GROUP BY t.a AS a\nDatabase SQL allows ORDER BY clauses to be specified only in the topmost SELECT .. FROM .. WHERE block. In Entity SQL you can use a nested ORDER BY expression and it can be placed anywhere in the query, but ordering in a nested query is not preserved.
-- The following query will order the results by the last name \nSELECT C1.FirstName, C1.LastName FROM AdventureWorks.Contact AS C1\nORDER BY C1.LastName -- In the following query ordering of the nested query is ignored. \nSELECT C2.FirstName, C2.LastName FROM (SELECT C1.FirstName, C1.LastName FROM AdventureWorks.Contact as C1 ORDER BY C1.LastName) as C2 In database SQL, identifier comparison is based on the settings of the current database and the database platform being used (SQL Server, Oracle, MySQL, etc.). In Entity SQL, identifiers are always case insensitive and accent sensitive (that is, Entity SQL distinguishes between accented and unaccented characters; for example, 'a' is not equal to '\u1ea5'). Entity SQL treats versions of letters that appear the same but are from different code pages as different characters.
"},{"location":"Reporting/Understanding-Entity-SQL/#group-by-clause-differences","title":"Group By Clause Differences","text":"Entity SQL also imposes additional restrictions on queries involving group by clauses. Expressions in the select clause and having clause of such queries may only refer to the group by keys via their aliases. The following construct is valid in most database SQL variants but are not in Entity SQL:
SELECT t.x + t.y FROM T AS t group BY t.x + t.y\nTo do this in Entity SQL:
SELECT k FROM T AS t GROUP BY (t.x + t.y) AS k\nAll column references in Entity SQL must be qualified with the table alias. The following construct (assuming that a is a valid column of table T) is valid in database SQL but not in Entity SQL.
SQL:
SELECT a FROM T\nThe Entity SQL form is
SELECT t.a AS A FROM T AS t\nThe table aliases are optional in the from clause. The name of the table is used as the implicit alias. Entity SQL allows the following form as well:
SELECT Tab.a FROM Tab\nDatabase SQL uses the \".\" notation for referencing columns of (a row of) a table. Entity SQL extends this notation (borrowed from programming languages) to support navigation through properties of an object.
For example, if p is an expression of type Person, the following is the Entity SQL syntax for referencing the city of the address of this person.
p.Address.City In database SQL, if you want to refer to a collection of possible values, you would use an IN clause together with a set of values contained within parenthesis:
SQL
SELECT t.a FROM T as t WHERE t.b IN (1,2,3)\nIn Entity SQL, the syntax for a collection of values is based on braces / curly brackets instead:
ESQL
select t.a from T as t where t.b in { 1,2,3 }\nThere are some differences between how literal values and types are represented in Entity SQL vs. Database SQL:
DATETIME '2006-12-25 01:01:00.000'\nN'hello'.(cast(null as Int16))\nThe following database SQL functionality is not available in Entity SQL.
This section outlines how to use the included Importer for importing folders, projects, modules and requirements from an IBM Rational DOORS database into a project in SpiraTest\u00ae, SpiraPlan\u00ae or SpiraTeam\u00ae (hereafter referred to as SpiraTeam).
"},{"location":"Requirements-Management-Integration/Importing-From-DOORS/#installing-the-importer","title":"Installing the Importer","text":"This section outlines how to install the importer onto a workstation so that you can then import requirements from DOORS into SpiraTeam. It assumes that you already have a working installation of SpiraTeam v3.0 or later and a working installation of DOORS 9.0 or later.
You can download the Importer from the Inflectra's website under \"Downloads and Add-Ons\". When downloaded, double-click the MSI file. Follow the instructions in the MSI file to install the importer.
"},{"location":"Requirements-Management-Integration/Importing-From-DOORS/#importing-from-a-doors-database","title":"Importing from a DOORS Database","text":"Now that you have installed the integration adapter, you can launch it at any time by going to Start > Programs > SpiraTest > Tools > IBM Rational DOORS Adapter. This will launch the import application itself. You will be shown an introduction screen. Click 'Next' to get to the second screen:
You need to click on the [Launch DOORS] button to connect to the locally installed DOORS client. Then you can enter in your DOORS login/password to access the system:
Once you have successfully authenticated with DOORS, you have the option of importing ALL the requirements in the DOORS database into a SpiraTeam project or selecting just a specific item (folder, project or module) in the DOORS hierarchy. To select a specific item, click on the \"Populate Item List\" button and choose the item from the dropdown list.
Then click Next to continue to the screen where you enter your SpiraTeam server and project information:
On this screen, you need to enter the SpiraTeam Server URL, the username and password you use to log onto the system, then click the Get Projects button. The program will connect to the server and get a list of all available projects. Select the project you want to import into under the Project & Requirement section.
The Root Requirement box is for specifying a base requirement to load all the DOORS elements into. If left blank, then the importer will create a single placeholder requirement that all of the DOORS folders, projects, modules and requirements will be nested under.
If you have a requirement already in SpiraTeam, and want the DOORS items to appear inside it, then you need to enter the requirement number into the Root Requirement text box. For example, if you have a requirement named \"DOORS Requirements\" with a number of RQ1920, then put 1920 into the Root Requirement field and run the import. When import is finished, the SpiraTeam requirements will be nested underneath.
Note: At this time, Link Modules are not imported from DOORS databases.
Once the fields have been populated, click Next to get to the summary screen.
The summary screen tells you what will actions will be performed, and once you have verified the information, click the Import button to start the import:
Anything flagged with a red
failed, green
means that they succeeded. Once finished, click Finish to get to the last page of the wizard:
If the Minimize to System Tray option is selected, when you click Finish or exit the from the application, it will minimize to the system tray. Once in the system tray, you can right-click on the icon and the it will give you the option to either re-import from the same project or select another project for a fresh import. If the option is not selected, the program will exit, and you can re-launch the importer to import from the same or another DOORS database.
"},{"location":"Requirements-Management-Integration/Importing-From-DOORS/#using-the-system-tray-shortcut-menu","title":"Using the System Tray Shortcut Menu","text":"When the application is minimized to the system tray, there are several shortcuts available:
Double-Clicking the icon will bring the importer back to the first screen, allowing you to import another DOORS database.
Right-clicking will give a shortcut menu with the following options:
Exit -- Close the program entirely.
Rerun Import -- Will provide you the screen to re-launch the last import you just ran.
Show Window -- Same as double-clicking on the icon, will bring the wizard back to the first screen, allowing new input options to be set.
At this time, only formal modules are imported into SpiraTeam from DOORS. The folders, projects and modules in DOORS become summary requirements in SpiraTeam and the actual requirements in each module are simply nested as child requirements in SpiraTeam. In addition, the following fields are brought over into SpiraTeam from DOORS according to the following mapping table:
DOORS Field SpiraTeam Field Heading Name Short Text Description Long Text Description Number Name DOORS Object ID Custom Text Property TEXT_01
Using this adapter, you can manage the appropriate artifacts in IBM Rational DOORS and then periodically re-run the import application to update SpiraTeam. The application will remember that the project was already used for an initial load and will simply update the requirements as appropriate as well as add any additional ones added.
Note that any changes to the requirement hierarchy are not reflected. This allows you to change the organization of the artifacts in SpiraTeam to make them easier to use without the changes being overwritten on the next import cycle.
Finally, should you want to start again and re-import a project from scratch that has already been imported once before, you may do so by re-running the Importer, and entering in -1 as the Root Requirement. This will not delete requirements from SpiraTeam, only remove mappings, so the next time you run the importer on this file, all new requirements will be created.
Note: This option is irreversible and should be performed with care.
"},{"location":"Requirements-Management-Integration/Importing-From-EnterpriseArchitect/","title":"Importing From EnterpriseArchitect","text":"This section outlines how to use the included Importer for importing Requirements, Features, and Screens from a Sparx Enterprise Architect (EA) project file into SpiraTeam.
"},{"location":"Requirements-Management-Integration/Importing-From-EnterpriseArchitect/#installing-the-importer","title":"Installing the Importer","text":"This section outlines how to install the importer onto a desktop so that you can then import requirements and use cases from EA into SpiraTest. It assumes that you already have a working installation of SpiraTest v3.0 or later and a working installation of Enterprise Architect.
Important: You must install the integration adapter on the same desktop that has the installed copy of Enterprise Architect.
You can download the Importer from the Inflectra's website under \"Downloads and Add-Ons\". When downloaded, double-click the MSI file. Follow the instructions in the MSI file to install the importer.
"},{"location":"Requirements-Management-Integration/Importing-From-EnterpriseArchitect/#importing-from-an-ea-project-file","title":"Importing from an EA Project File","text":"Now that you have installed the integration adapter, you can launch it at any time by going to Start > Programs > SpiraTeam > Tools > Enterprise Architect Importer. This will launch the import application itself. You will be shown an introduction screen. Click 'Next' to get to the second screen:
Click the folder button () to open the file open dialog. In this dialog, select the Enterprise Architect Project file (*.EAP) that you want to use for importing. If the file has access credentials required, enter the username and password needed to access the file.
Once the file is selected, click Next to continue to the screen where you enter your SpiraTeam project information:
If the file you selected in the previous step was already lined to a SpiraTeam project, that information will be automatically populated in the fields, and you can click Next to proceed.
Otherwise, enter in the SpiraTeam Server URL, your username and password used to log onto the system with and click the Get Projects button. The program will connect to the server and get a list of all available projects. Select the project you want to import into under the Project & Requirement section.
The Root Requirement box is for specifying a base requirement to load all the EA elements into. If left blank, then the root folders in the EAP's model will be root requirement folders in the SpiraTeam Project.
For example, if your EAP file has a tree that looks like:
Then the requirements imported into SpiraTeam will appear like:
Note that the folder \"Non-Functional Requirements\" does not appear in the list. Folders that have no importable elements will not get imported into SpiraTeam. At this time, only \"Requirement\", \"Feature\", and \"Screen\" elements are imported.
If you had a requirement already in SpiraTeam, and wanted the \"Requirements Model\" to appear in it, then enter the requirement number into the Root Requirement text box. For example, if I have a requirement named \"EA Requirements\" with a number of RQ1920, then put 1920 into the Root Requirement field and run the import. When import is finished, the SpiraTeam requirement tree will look like:
Once the fields are entered, click Next to get to the summary screen. The summary screen tells you what will be done, and once it's reviewed, click the Import button to start importing:
Anything flagged with a red
failed, green
means that they succeeded. Once finished, click Finish to get to the last page of the wizard:
If the Minimize to System Tray option is selected, when you click Finish or exit the form, the application will minmiize to the system tray and give you some quick actions to re-import from the same file or select another file. Otherwise the program will exit, and you can re-launch the importer to import from the same or another EAP file.
"},{"location":"Requirements-Management-Integration/Importing-From-EnterpriseArchitect/#using-the-system-tray-shortcut-menu","title":"Using the System Tray Shortcut Menu","text":"When the application is minimized to the system tray, there are several shortcuts available:
Double-Clicking the icon will bring the importer back to the first screen, allowing you to import another EAP file.
Right-clicking will give a shortcut menu with the following options:
Exit -- Close the program entirely.
Rerun Import -- Will provide you the screen to re-launch the last import you just ran.
Show Window -- Same as double-clicking on the icon, this will cause the wizard to appear back on the first screen, allowing new input options to be set.
At this time, only elements that are Requirements, Features, or Screens are imported. All three types are imported into Requirements within SpiraTeam, and most fields are brought over into SpiraTeam from EA. Mapping for fields are as follows:
Enterprise Architect Field SpiraTeam Field Short Description / Name Name Notes Description (with HTML) Priority Importance: EA Value : SpiraTeam Value High : High Medium : Medium Low : Low Status Status: EA Value : SpiraTeam Value Approved : Accepted Implemented: In Progress Validated : Completed Mandatory : Requested Proposed : Requested (None) : Requested Author (not transferred, always set to user who ran the import last) Release (not transferred) Owner (not transferred) Planned Effort (not transferred) Alias Custom Text Property #1 Element Type ('Requirement', 'Feature', 'Screen', etc) Custom Text Property #2 Phase Custom Text Property #3 Version Custom Text Property #4 Difficulty Custom Text Property #5When a mapping is made, a Tagged Value is saved into the EAP file with the name of SPIRA::Mapping. The number of the value is the requirement number within SpiraTeam. If the requirement is deleted from SpiraTeam, and the mapping value in the EA project still exists, the item will not be re-imported into SpiraTeam. Similarly, folders are also given a SPIRA::Mapping value, and if a new Requirement element is created within a folder that was deleted in SpiraTeam, it will not be added. If you need to remove all mappings from the EAP file, you may do so by re-running the Importer, and entering in -1 as the Root Requirement. Note that this will not delete requirements from SpiraTeam, only remove mappings, so the next time you run the importer on this file, all new requirements will be created.
"},{"location":"Requirements-Management-Integration/Importing-From-Jama-Contour/","title":"Importing From Jama Contour","text":"This section outlines how to use the included Importer for importing Requirements, Features, and Use Cases from projects residing in Jama Contour\u2122 projects into equivalent projects in SpiraTest\u00ae, SpiraPlan\u00ae or SpiraTeam\u00ae (hereafter referred to as SpiraTeam).
"},{"location":"Requirements-Management-Integration/Importing-From-Jama-Contour/#installing-the-importer","title":"Installing the Importer","text":"This section outlines how to install the importer onto a workstation so that you can then import requirements and use cases from Contour into SpiraTeam. It assumes that you already have a working installation of SpiraTeam v3.0 or later and a working installation of Jama Contour.
You can download the Importer from the Inflectra's website under \"Downloads and Add-Ons\". When downloaded, double-click the MSI file. Follow the instructions in the MSI file to install the importer.
"},{"location":"Requirements-Management-Integration/Importing-From-Jama-Contour/#importing-from-a-contour-project","title":"Importing from a Contour Project","text":"Now that you have installed the integration adapter, you can launch it at any time by going to Start > Programs > SpiraTest > Tools > Jama Contour Adapter. This will launch the import application itself. You will be shown an introduction screen. Click 'Next' to get to the second screen:
You need to enter the Contour Server URL (including the port number if appropriate), the username and password you use to log onto the system, then click the Get Projects button. The program will connect to the server and get a list of all available projects. Select the project you want to import into under the Project section. Once the project is selected, click Next to continue to the screen where you enter your SpiraTeam server and project information:
On this screen, you need to enter the SpiraTeam Server URL, the username and password you use to log onto the system, then click the Get Projects button. The program will connect to the server and get a list of all available projects. Select the project you want to import into under the Project & Requirement section.
The Root Requirement box is for specifying a base requirement to load all the Contour elements into. If left blank, then the root folders in the Contour's explorer will be root requirement folders in the SpiraTeam Project.
For example, if your Jama Contour project has a tree that looks like:
Then the requirements imported into SpiraTeam will appear like:
Note: At this time, change request and defect items are not imported from Contour projects.
If you have a requirement already in SpiraTeam, and want the Contour requirements to appear inside it, then you need to enter the requirement number into the Root Requirement text box. For example, if you have a requirement named \"Contour Requirements\" with a number of RQ1920, then put 1920 into the Root Requirement field and run the import. When import is finished, the SpiraTeam requirement tree will look like:
Once the fields have been populated, click Next to get to the summary screen.
The summary screen tells you what will actions will be performed, and once you have verified the information, click the Import button to start the import:
Anything flagged with a red
failed, green
means that they succeeded. Once finished, click Finish to get to the last page of the wizard:
If the Minimize to System Tray option is selected, when you click Finish or exit the from the application, it will minimize to the system tray. Once in the system tray, you can right-click on the icon and the it will give you the option to either re-import from the same project or select another project for a fresh import. If the option is not selected, the program will exit, and you can re-launch the importer to import from the same or another Contour project.
"},{"location":"Requirements-Management-Integration/Importing-From-Jama-Contour/#using-the-system-tray-shortcut-menu","title":"Using the System Tray Shortcut Menu","text":"When the application is minimized to the system tray, there are several shortcuts available:
Double-Clicking the icon will bring the importer back to the first screen, allowing you to import another Contour project.
Right-clicking will give a shortcut menu with the following options:
Exit -- Close the program entirely.
Rerun Import -- Will provide you the screen to re-launch the last import you just ran.
Show Window -- Same as double-clicking on the icon, will bring the wizard back to the first screen, allowing new input options to be set.
At this time, only requirements are imported into SpiraTeam from Contour. All the various types in Contour are imported as Requirements into SpiraTeam. In addition, the following fields are brought over into SpiraTeam from Contour according to the following mapping table:
Jama Contour Field SpiraTeam Field Name Name Description Description (with HTML) Priority Importance: Contour Value : SpiraTeam Value High : High Medium : Medium Low : Low Status Status: Contour Value : SpiraTeam Value Draft : Requested Approved : Accepted Completed : Completed Rejected : Rejected (None) : Requested Author (not transferred, always set to user who ran the import last) Release Release / Iteration Owner (not transferred) Planned Effort (not transferred) Item Type Custom Text Property #1 Document Key Custom Text Property #2 Item Type Category Custom Text Property #3"},{"location":"Requirements-Management-Integration/Importing-From-Jama-Contour/#keeping-jama-and-spira-in-sync","title":"Keeping Jama and Spira in Sync","text":"Using this adapter, you can manage the appropriate artifacts in Contour and then periodically re-run the import application to update Spira. The application will remember that the project was already used for an initial load and will simply update the requirements as appropriate as well as add any additional ones added. If you are using SpiraTeam v3.1 or later, the update process will also delete any artifacts removed in Contour.
Note that any changes to the requirement hierarchy in Contour are not reflected. This allows you to change the organization of the artifacts in SpiraTeam to make them easier to use without the changes being overwritten on the next import cycle.
Finally, should you want to start again and re-import a project from scratch that has already been imported once before, you may do so by re-running the Importer, and entering in -1 as the Root Requirement. This will not delete requirements from SpiraTeam, only remove mappings, so the next time you run the importer on this file, all new requirements will be created. Note: This option is irreversible and should be performed with care.
"},{"location":"Requirements-Management-Integration/Importing-From-ReqIF-Files/","title":"Importing From Requirements Interchange Format (ReqIF) Files","text":"The SpiraTeam ReqIF Importer imports requirements, specifications, custom properties, relationships and other information from Requirements Interchange Format (ReqIF) files into SpiraTeam.
"},{"location":"Requirements-Management-Integration/Importing-From-ReqIF-Files/#installing-the-importer","title":"Installing the Importer","text":"This section outlines how to install the importer onto a desktop so that you can then import requirements from ReqIF files into SpiraTeam. It assumes that you already have a working installation of SpiraTest, SpiraTeam, or SpiraPlan (hereafter SpiraTeam) v6.0 or later.
You can download the Importer from the Inflectra's website under \"Downloads and Add-Ons\". When downloaded, double-click the MSI file. Follow the instructions in the MSI file to install the importer.
"},{"location":"Requirements-Management-Integration/Importing-From-ReqIF-Files/#importing-from-a-reqif-requirements-file","title":"Importing from a ReqIF Requirements File","text":"Now that you have installed the integration adapter, you can launch it at any time by going to Start > Programs > SpiraTeam > Tools > ReqIF Importer. This will launch the import application itself. You will be shown an introduction screen.
Click 'Next' to get to the second screen:
Click the folder button () to open the file open dialog. In this dialog, select the Requirements Interchange Format (*.reqif) file that you want to use for importing.
Choose the requirements attributes you want from the .ReqIF file model to map to the Name and Description fields in SpiraTeam. Any other fields will be imported as custom properties.
Once the file is selected, and the name/description attributes mapped, click Next to continue to the screen where you enter your SpiraTeam project information:
If the file you selected in the previous step was already lined to a SpiraTeam project, that information will be automatically populated in the fields, and you can click Next to proceed.
Otherwise, enter in the SpiraTeam Server URL, your username and password used to log onto the system with and click the Get Projects button. The program will connect to the server and get a list of all available projects. Select the project you want to import into under the Project & Requirement section.
The Root Requirement box is for specifying the name of the parent requirement in SpiraTeam, that all the imported requirements will be nested under. The system will default this to the name of the ReqIF file unless you choose something else.
Once the fields are entered, click Next to get to the summary screen. The summary screen tells you what will be done, and once it's reviewed, click the Import button to start importing:
Anything flagged with a: - red failed - green means that they succeeded
Once finished, click Finish to get to the last page of the wizard:
If anything failed, you can view the details import log at the following location:
\nC:\\ProgramData\\SpiraTeamReqIFImporter.log\n"},{"location":"Requirements-Management-Integration/Importing-From-ReqIF-Files/#reqif-spirateam-importing-notes","title":"ReqIF & SpiraTeam Importing Notes","text":"
For example, if you import the sample Sample-Model.reqif file that is supplied with the importer, you will see the following requirements in SpiraTeam:
In addition, the importer will create the necessary custom properties as needed automatically:
If you run the same import twice, the importer will create a new requirements hierarchy each time, but it will reuse the existing custom properties if they are already defined in the SpiraTeam product.
"},{"location":"Requirements-Management-Integration/Importing-From-RequisitePro/","title":"Importing From RequisitePro","text":"This section outlines how to use the included Integration Adapter for importing Requirements, and Use Cases from IBM Rational\u00ae RequisitePro\u00ae into SpiraTest\u00ae.
"},{"location":"Requirements-Management-Integration/Importing-From-RequisitePro/#installing-the-integration-adapter","title":"Installing the Integration Adapter","text":"This section outlines how to install the integration adapter for RequisitePro onto a workstation so that you can then import requirements and use cases from RequisitePro into SpiraTest. It assumes that you already have a working installation of SpiraTest v2.2 or later and a working installation of RequisitePro v7.0 or later. If you have an earlier version of SpiraTest or RequisitePro, you will need to upgrade to at least v2.2 and v7.0 respectively before trying to import data.
To obtain the version of the migration tool that is compatible with your version of SpiraTest, you simply need to log-in as a project-level administrator to SpiraTest, go to the Administration home page and download the Integration Adapter Windows Installer package (.msi). This process is described in the SpiraTest Administration Guide in more detail.
Important: You must install the integration adapter on the same workstation that has the installed copy of RequisitePro. Once you have obtained the Windows Installer package, simply double-click on the package to begin the installation wizard which should display the following welcome page:
Click the <Next> button to choose the folder to install the integration adapter to:
Choose the folder to install to, and then decide whether the application should be accessible by all users on the workstation or just the current user. Then click the <Next> button to start the installation process. It will confirm if you want to proceed, click <Next> then wait for it to finish.
"},{"location":"Requirements-Management-Integration/Importing-From-RequisitePro/#importing-from-requisitepro_1","title":"Importing From RequisitePro","text":"Now that you have installed the integration adapter, you can launch it at any time by going to Start > Programs > SpiraTest > Tools > RequisitePro Adapter. This will launch the import application itself:
The first thing you need to do is to click the <Browse> button and select the Rational RequisitePro project file (.rqs) that you want to import from. You also need to select a valid username and password for that project. Once you have done this, click the <Login> button to verify that the project file can be opened.
The button marked <Clear Project Cache> will be explained later on.
Assuming that the user name selected has permission to access this project, you will be prompted with a message box indicating that the login was successful. Now click the <Next> button to move to the next page in the import wizard:
This page allows you to enter the URL, user name and password that you want to use to access the instance of SpiraTest that you want to import to and click <Login>. Typically the URL is of the form (http://<server name>/SpiraTest). The version of the importer being used must be compatible with the version of SpiraTest you're importing into; if not you will receive an error message.
Assuming that the login was successful, click the <Start Import> button to actually begin the process of importing the various artifacts from RequisitePro into SpiraTest. Note that the first time the importer sees a particular project file, it will create a new project in SpiraTest to hold all the artifacts with the same name as that used in RequisitePro.
During the import process, as each of the types of artifact are imported, the progress display will change (as illustrated above). Once the import has finished, you will receive a message to that effect and the <Done> button will be enabled. Clicking this button closed the importer. You should now log into SpiraTest using the same user name and password that was used for the import to view the imported project.
"},{"location":"Requirements-Management-Integration/Importing-From-RequisitePro/#using-requisitepro-with-spiratest","title":"Using RequisitePro with SpiraTest","text":"Once you have completed this initial import, you will now have two systems that can be used together to manage your project's lifecycle. How they should be used together depends on which methodology you have been using in your RequisitePro project:
Traditional Mode -- In this mode, RequisitePro only contains product requirements and software requirements. These are both loaded into SpiraTest's requirements matrix and can be used as a starting point for developing the necessary test case coverage. In this mode, requirements are managed in RequisitePro and all other artifacts are managed in SpiraTest.
Use Cases Mode -- In this mode, RequisitePro contains features, supplementary requirements and use cases. The features and supplementary requirements are loaded into SpiraTest's requirements matrix, and the use cases are loaded into SpiraTest's test case list. Note that these use cases do not contain any test steps. In this mode, requirements and test cases are managed in RequisitePro, and test steps, test runs and incidents are managed in SpiraTest.
Regardless of the mode employed, you can manage the appropriate artifacts in RequisitePro and then periodically re-run the import application to update SpiraTest. The application will remember that the project was already used for an initial load and will simply update the requirements and/or test cases as appropriate as well as add any additional ones added.
Note that this update process does not delete any artifacts removed in RequisitePro and any changes to the requirement or use case hierarchies are not reflected. This allows you to change the organization of the artifacts in SpiraTest to make them easier to use without the changes being overwritten on the next import cycle.
Finally, should you want to start again and re-import a project from scratch that has already been imported once before, you should choose the <Clear Project Cache> button on the first screen which will remove all the stored history of all previously loaded projects. This option is irreversible and should be performed with care.
"},{"location":"Requirements-Management-Integration/Importing-From-VersionOne/","title":"Importing From VersionOne","text":"This section outlines how to use the included Importer for importing Iterations/Sprints, Epics and Stories/Backlog Items from projects residing in VersionOne projects into equivalent projects in SpiraTest\u00ae, SpiraPlan\u00ae or SpiraTeam\u00ae (hereafter referred to as SpiraTeam).
"},{"location":"Requirements-Management-Integration/Importing-From-VersionOne/#installing-the-importer","title":"Installing the Importer","text":"This section outlines how to install the importer onto a workstation so that you can then import requirements and use cases from VersionOne into SpiraTeam. It assumes that you already have a working installation of SpiraTeam v3.0 or later and a working installation of VersionOne 8.0 or later.
You can download the Importer from the Inflectra's website under \"Downloads and Add-Ons\". When downloaded, double-click the MSI file. Follow the instructions in the MSI file to install the importer.
"},{"location":"Requirements-Management-Integration/Importing-From-VersionOne/#importing-from-a-versionone-project","title":"Importing from a VersionOne Project","text":"Now that you have installed the integration adapter, you can launch it at any time by going to Start > Programs > SpiraTest > Tools > VersionOne Adapter. This will launch the import application itself. You will be shown an introduction screen. Click 'Next' to get to the second screen:
You need to enter the VersionOne Server URL (including the port number if appropriate), the username and password you use to log onto the system, then click the Get Projects button. If you choose 'Use Windows Authentication' it will use the credentials of the currently logged-in user and disable the username/password text boxes.
The program will connect to the server and get a list of all available projects. Select the project you want to import into under the Project section. Once the project is selected, click Next to continue to the screen where you enter your SpiraTeam server and project information:
On this screen, you need to enter the SpiraTeam Server URL, the username and password you use to log onto the system, then click the Get Projects button. The program will connect to the server and get a list of all available projects. Select the project you want to import into under the Project & Requirement section.
The Root Requirement box is for specifying a base requirement to load all the VersionOne elements into. If left blank, then the importer will create a single placeholder requirement that all of the VersionOne epics and backlog items will be nested under.
If you have a requirement already in SpiraTeam, and want the VersionOne items to appear inside it, then you need to enter the requirement number into the Root Requirement text box. For example, if you have a requirement named \"VersionOne Requirements\" with a number of RQ1920, then put 1920 into the Root Requirement field and run the import. When import is finished, the SpiraTeam requirements will be nested underneath.
Note: At this time, change request and defect items are not imported from VersionOne projects.
Once the fields have been populated, click Next to get to the summary screen.
The summary screen tells you what will actions will be performed, and once you have verified the information, click the Import button to start the import:
Anything flagged with a red
failed, green
means that they succeeded. Once finished, click Finish to get to the last page of the wizard:
If the Minimize to System Tray option is selected, when you click Finish or exit the from the application, it will minimize to the system tray. Once in the system tray, you can right-click on the icon and the it will give you the option to either re-import from the same project or select another project for a fresh import. If the option is not selected, the program will exit, and you can re-launch the importer to import from the same or another VersionOne project.
"},{"location":"Requirements-Management-Integration/Importing-From-VersionOne/#using-the-system-tray-shortcut-menu","title":"Using the System Tray Shortcut Menu","text":"When the application is minimized to the system tray, there are several shortcuts available:
Double-Clicking the icon will bring the importer back to the first screen, allowing you to import another VersionOne project.
Right-clicking will give a shortcut menu with the following options:
Exit -- Close the program entirely.
Rerun Import -- Will provide you the screen to re-launch the last import you just ran.
Show Window -- Same as double-clicking on the icon, will bring the wizard back to the first screen, allowing new input options to be set.
At this time, only requirements and iterations/sprints are imported into SpiraTeam from VersionOne. The epics in VersionOne become summary requirements in SpiraTeam and the backlog items / stories become child requirements in SpiraTeam. In addition, the following fields are brought over into SpiraTeam from VersionOne according to the following mapping table:
VersionOne Field SpiraTeam Field Name Name Description Description (with HTML) Priority Importance: VersionOne Value : SpiraTeam Value High : High Medium : Medium Low : Low Status Status: VersionOne Value : SpiraTeam Value Future : Requested Accepted : Accepted Done : Completed In Progress : In Progress Author (not transferred, always set to user who ran the import last) Iteration/Sprint Release / Iteration Owner (not transferred) Estimate Planned Effort (not transferred) VersionOne ID Custom Text Property TEXT_01 VersionOne Display ID Custom Text Property TEXT_02Using this adapter, you can manage the appropriate artifacts in VersionOne and then periodically re-run the import application to update SpiraTeam. The application will remember that the project was already used for an initial load and will simply update the requirements as appropriate as well as add any additional ones added. If you are using SpiraTeam v3.1 or later, the update process will also delete any artifacts removed in VersionOne.
Note that any changes to the requirement hierarchy are not reflected. This allows you to change the organization of the artifacts in SpiraTeam to make them easier to use without the changes being overwritten on the next import cycle.
Finally, should you want to start again and re-import a project from scratch that has already been imported once before, you may do so by re-running the Importer, and entering in -1 as the Root Requirement. This will not delete requirements from SpiraTeam, only remove mappings, so the next time you run the importer on this file, all new requirements will be created.
Note: This option is irreversible and should be performed with care.
"},{"location":"Spira-Administration-Guide/","title":"Welcome to the SpiraPlan Administration Guide","text":"How to use this guide
This documentation is designed for all administrators of SpiraTest, SpiraTeam, or SpiraPlan.
To find the section you need, open the \"Admin Guide\" section from the site navigation to see all available chapters.
If you are installing Spira on your own servers, please read the \"Installing Spira\" chapter carefully. This is not required if you are hosted in the cloud by Inflectra.
We recommend that all new administrators read the section \"System Administration\" to get an overview of the administration functions in the application.
"},{"location":"Spira-Administration-Guide/Installing-SpiraPlan/","title":"Installing SpiraPlan\u00ae","text":"This section outlines how to:
The minimum hardware and software requirements for running the SpiraPlan\u00ae system are:
Server Requirements Requirement Minimum Specification Processor: Intel\u00ae or AMD\u00ae x86 or x64 compatible processor Memory: 4 GB, 8 GB recommended Operating System: Windows Server 2016+ (recommended) Windows Server 2012 R1 & R2 Windows 10 (for demoing) Database: Microsoft SQL Server 2016+ Microsoft SQL Server 2016+ Express Edition* Web Server: Internet Information Services (IIS) 7.0 or higher ASP.NET Web Extensions 4.7.2 or higherNote: Please consider there are some limitations for FREE SQL Express [That may significantly affect performance thus we don't recommend it to be used on production/handling large amounts of data).
Client Requirements Web Browser: Microsoft Edge Mozilla Firefox Google Chrome (Desktop and Android) Apple Safari (Desktop and iOS) Opera Other Components: Microsoft Excel 2010+ (optional) Microsoft Word 2010+ (optional) Microsoft Project 2010+ (optional)*Note that SpiraPlan\u00ae can be loaded onto either Windows Server or workstation editions, provided that the IIS web-server is installed and that SQL Server is available as a database engine. However, Windows workstation editions can only support a maximum of 5 concurrent user web sessions. In general, unless there are only going to be a couple of client machines hitting the server, we recommend using Windows Server.
"},{"location":"Spira-Administration-Guide/Installing-SpiraPlan/#system-prerequisites","title":"System Prerequisites","text":"Assuming that you have already installed the appropriate version of Microsoft Windows onto your computer (or that has been pre-installed for you), make sure that the various prerequisites have been correctly added to your installation before trying to install SpiraPlan\u00ae. The SpiraPlan\u00ae installer will check to ensure that the various prerequisites are in place, and will abort the installation if any are missing, indicating to you what action needs to be taken.
We recommend that you install / configure the prerequisites in the following order:
On most modern Windows 11 and Windows Server 2022+ installations, Microsoft .NET Framework v4.7.2 is usually already installed. On earlier operating systems, you may need to manually add the .NET 4.7.2 components to the factory configuration.
To see which version of the Microsoft .NET framework installed please follow the below steps:
You can find the version under \u201cProduct version\u201d property. See the below screenshot:
To install the .NET Framework, launch your browser and enter the URL: https://www.inflectra.com/CustomerArea. Once you have logged-in to the customer area, under the \"My Downloads\" section there will be hyperlinks to download and install the appropriate version of the .NET Framework (version 4.7.2 at time of writing). Click on the option to download and install the .NET Framework, and follow the instructions provided. Once you have completed the install, verify that the installation was successful by looking in the \"Administrative Tools\" folder as illustrated above. You also need to make sure that .NET 4.7.2 has been installed if necessary.
"},{"location":"Spira-Administration-Guide/Installing-SpiraPlan/#install-sql-server-version-2016-or-higher","title":"Install SQL Server version 2016 (or higher)","text":"If you do not have a SQL Server instance ready, you can install the appropriate version of the database software, following the instructions provided with the installation. For basic or trial use, we recommend SQL Server Express Edition. This free version of SQL Server will offer sufficient performance where performance and storage are not important (such as during a trial). SQL Express can be downloaded from either the customer area of our website (http://www.inflectra.com/CustomerArea) or directly from Microsoft's website.
You must setup the built-in SA (SysAdmin) account on SQL Server. Make sure SQL Server setup allows mixed-mode authentication so it allows both SQL Server and Windows logins:
SA user is required during the installation/upgrade to create the Database and required Logins, and this can be done using a SysAdmin user only.
Ensure you have enabled the Full-Text Indexing feature enabled prior running installer of Spira application.
"},{"location":"Spira-Administration-Guide/Installing-SpiraPlan/#ensure-that-iis-is-installed","title":"Ensure that IIS is installed","text":"On Windows Server OS installations, IIS is usually installed as part of the factory configuration, whereas on Windows workstation OS installations, you typically need to manually add the components to the factory configuration. The steps that you need to take to verify its installation are listed below:
On Windows 8 or 8.1, to install IIS, you need to click Start > Control Panel > Programs and Features or type appwiz.cpl in Run, then choose the option to \"Turn Windows features on or off\". This will bring up the list of features and roles that can be configured on the server:
"},{"location":"Spira-Administration-Guide/Installing-SpiraPlan/#windows-10","title":"Windows 10","text":"On Windows 10 and Windows 11, to install IIS, you need to click Start > Control Panel > Programs and Features or type appwiz.cpl in Run, then choose the option to \"Turn Windows features on or off\". This will bring up the list of features and roles that can be configured on the server:
Make sure that the following features are enabled within the 'Internet Information Services' folder:
Web Management Tools
IIS 6 Management Compatibility
World Wide Web Services
Application Development Features
Common HTTP Features
In the same panel ('Turn Windows Features on or off') you also need to check that the following features are enabled in the '.NET Framework 4.6 Advanced Services' folder:
.NET Framework 4.6 Advanced Services
WCF Services
To verify that this IIS is now installed, type \"http://localhost\" into the browser's address bar. You should see a screen displaying the initial IIS startup page:
"},{"location":"Spira-Administration-Guide/Installing-SpiraPlan/#windows-server-2012-2016-2019","title":"Windows Server 2012, 2016, 2019","text":"On Windows Server 2012, 2016, 2019, you need to click on Server Manager, then under the \"Roles\" heading, choose the option to \"Add Role\" (Add Roles and Features in Windows Server 2019+) followed by selecting the new role \"Web Server (IIS)\" or using a PowerShell command Install-WindowsFeature -name Web-Server -IncludeManagementTools
Then click \"Next\" to bring up the role configuration screen:
Make sure that the following features are enabled:
Web Server (IIS)
Application Development
Management Tools
WCF Services
Once IIS and .NET are both installed, make sure the Active Server Pages (ASP.NET) components that allow IIS to access the .NET framework are correctly configured. If you installed .NET after IIS, then ASP.NET is typically configured for you. But if you installed IIS afterwards, then further manual steps may be necessary.
To verify that ASP.NET has been correctly configured, click on Start > Control Panel > Administrative Tools > Internet Information Services (IIS) Manager to launch the IIS administrative console:
You should see a section called \"ASP.NET\" occupying the top third of the IIS screen. If not, then you need to go back to Ensure that ASP.NET is installed and make sure that you chose the option to install ASP.NET when installing IIS.
"},{"location":"Spira-Administration-Guide/Installing-SpiraPlan/#installing-the-software","title":"Installing the Software","text":"Once all of the prerequisites are correctly installed, you are now ready to install SpiraPlan\u00ae. To start and successfully finish the installation you will need the items listed below (all of which are available in the customer area of the Inflectra\u00ae website):
To start the installation, double-click on the SpiraPlan\u00ae installation package (it will have a filename in the form of SpiraPlan-vX.X.X.exe). The Installer will display the following dialog box:
"},{"location":"Spira-Administration-Guide/Installing-SpiraPlan/#select-an-installation-type","title":"Select an Installation Type","text":"Click the \"Next\" button to start the installation wizard. The wizard will gather information about what you want to do and how you want to do it. Before any changes are made to your system (installing web-server files and database components) you will get a chance to review everything again.
"},{"location":"Spira-Administration-Guide/Installing-SpiraPlan/#review-the-license-agreement-and-prerequisites","title":"Review the License Agreement and Prerequisites","text":"If installing a fresh installation or upgrading, after making your selection the next screen provides a copy of the SpiraPlan\u00ae End User License Agreement (EULA). Please read this carefully as it describes the legal contract between you -- the user of the software -- and Inflectra\u00ae Corporation, the developer and publisher. Once you have read the agreement and understood your rights and obligations, select the radio button marked \"I accept the terms in the License Agreement\" and click the \"Next\" button.
The next page of the wizard will display a list of the required pre-requisites. The installer does not attempt to verify if these pre-requisites have been met or not. The information is displayed for information purposes only. If a pre-requisite is missing the application may display incorrectly.
"},{"location":"Spira-Administration-Guide/Installing-SpiraPlan/#license-information","title":"License Information","text":"The next stage of the wizard (for installing and upgrading) is to enter license information:
You need to enter:
The installer will verify the license information as you enter it. If the details entered are valid then the information will be displayed beneath the entry fields. This allows you to check that the correct application and license will be installed. On clicking Next, the installer will warn you of any discrepancies, and will not allow you to proceed until valid information has been provided.
If for any reason you are unable to get the provided license key to work, please contact Inflectra\u00ae customer support for help resolving the issue.
"},{"location":"Spira-Administration-Guide/Installing-SpiraPlan/#choose-an-installation-location-advanced-mode-only","title":"Choose an Installation Location (advanced mode only)","text":"If you checked \"advanced\" at the start of the installation process, you will have the option to choose where the application is installed. You can choose an existing folder or make a new one and select that. By default it is C:\\Program Files (x86)\\[Application Name]).
"},{"location":"Spira-Administration-Guide/Installing-SpiraPlan/#web-server-configuration","title":"Web Server Configuration","text":"Choose which web site to install SpiraPlan\u00ae into using the available dropdown, which should list all available web sites in IIS on this machine. The Default Web Site will be preselected and is the best option in most circumstances.
Virtual Directory (advanced mode only)
If installing in advanced mode, then on this screen you will able to change the name of the web-site URL that will be used to access the system. By default, users would need to type into their browsers: http://\"server name\"/[product name]. Should you want to have a different name change the name in the Virtual Directory box, otherwise simply accept the default name and click \"Next\".
Note: The installer will check to make sure that the name you have chosen is not already in use, and will warn you if it is.
"},{"location":"Spira-Administration-Guide/Installing-SpiraPlan/#connect-to-the-database","title":"Connect to the Database","text":"SpiraPlan\u00ae has an application (installed into a default folder on your system), a website (configured above), and a database. The next screen tells the installer how to connect to the database server on your system.
a) Windows Authentication
This is the easiest option when the application and database will be residing on the same server. It is the only option available for authentication during a standard installation. In this case, choose the \"Windows Authentication\" option and the Login/Password boxes will be disabled. In this case, the installer will connect to the database using your current Windows login to create the application database objects, and SpiraPlan\u00ae will connect to the database during normal operation using either the ASPNET or NETWORK SERVICE Windows accounts (it depends on the version of the operating system).
b) SQL Server Authentication (advanced mode only)
This is the easiest option when the application and databases will be residing on different servers across the network. In this case, choose \"SQL Server Authentication\" under \"Connection Information\" section and provide SQL Server Login that has full sysadmin permissions -- e.g. the built in System Administrator (SA) account. The installer will use this SysAdmin account to create the database objects. The password for SA account is set in SQL Server itself and should be saved carefully.
Note that using this account under the 'Connection Info' part of the installer is not a security risk, as the installer does not remember this login and after the database is created, it's never used again. With SQL Server authentication, the IIS application pool will run as a low-credentialed system user, typically the 'NETWORK SERVICE' account. This lets the application pool access the local system resources only. User listed under \"Database Settings\" for SpiraPlan\u00ae will use a special login (called \"SpiraPlan\" by default, created automatically) for normal application operations. The username should not be changed as it is used by the application to operate.
Setting the Correct Server Instance
In the \"Server\" box, you need to enter the name of the Microsoft SQL Server instance that is running on your system; the installer will default it to the hostname of the server (which in many cases will be correct). The easiest way to find out the database server name is to:
For SQL Server Express edition installations, the Server name is usually the name of your computer followed by \"\\SQLEXPRESS\", so for example, if your computer is called MyComputer, the server name would be MyComputer\\SQLEXPRESS or simply use .\\SQLEXPRESS (Omitting the second part (called the instance name) would lead to a \"host not found\" error):
You can also choose whether to install the sample products or not - typically we recommend installing the sample products for evaluation installations and excluding them for production installs.
"},{"location":"Spira-Administration-Guide/Installing-SpiraPlan/#complete-the-installation","title":"Complete the Installation","text":"Once you have entered the various pieces of information, click \"Next\". The installer will attempt to connect to the database using the provided information, and it will display an error message if any of the information is incorrect. Assuming the information is correct, the following screen will be displayed:
Once you have confirmed that everything is correct, click the \"Install\" button to actually begin the process of installing SpiraPlan\u00ae onto your system. The installer will then display a progress bar as the installation proceeds. Once the installation is complete, the installer will provide confirmation, or display information about any problems it encountered.
Click the \"Finish\" button to complete the installation.
Congratulations! You have successfully installed SpiraPlan\u00ae onto your system. If you type http://localhost/SpiraPlan into your browser you should see the SpiraPlan\u00ae login page. If for any reason you don't see the login page, please contact Inflectra\u00ae support team.
"},{"location":"Spira-Administration-Guide/Installing-SpiraPlan/#upgrading","title":"Upgrading","text":"You can upgrade any SpiraPlan version that is 5.4.0.4 or newer using the latest installer (for instance you can upgrade from 5.4 to 7.7, or from 6.9.0.1 to 7.7 using the exact same installer exe). To upgrade from versions older than 5.4.0.4 you first need to upgrade to 5.4.0.4 and then upgrade to the latest version.
For example, to upgrade from SpiraTest v2.3.1 to v5.4, you would first upgrade from SpiraTest v2.3.1 > v3.2, then upgrade from SpiraTest v3.2 > v4.2, next step is to upgrade from v4.2 > 5.4
To upgrade an existing installation:
The next screen provides a copy of the SpiraPlan\u00ae End User License Agreement (EULA). Please read this carefully as it describes the legal contract between you -- the user of the software -- and Inflectra\u00ae Corporation, the developer and publisher. Once you have read the agreement and understood your rights and obligations, select the radio button marked \"I accept the terms in the License Agreement\" and click the \"Next\" button.
The next page of the wizard will display a list of the required pre-requisites and whether the installer could find them or not. The checks here are not fool-proof (in particular where a question mark is shown) so it is recommended to manually check the prerequisites in full as described above. The system will not require all prerequisites to be met before allowing the installation, but the application may display incorrectly if any are missing.
"},{"location":"Spira-Administration-Guide/Installing-SpiraPlan/#license-information_1","title":"License Information","text":"The next stage of the wizard is to enter license information:
You need to enter:
The installer will verify the license information as you enter it. If the details entered are valid then the information will be displayed beneath the entry fields. This allows you to check that the correct application and license will be installed. On clicking Next, the installer will warn you of any discrepancies, and will not allow you to proceed until valid information has been provided.
If for any reason you are unable to get the provided license key to work, please contact Inflectra\u00ae customer support for help resolving the issue.
"},{"location":"Spira-Administration-Guide/Installing-SpiraPlan/#upgrade-location","title":"Upgrade location","text":"The installer points the upgrade to the default installation location for the licensed version. If this is not correct, click the folder icon to select the proper installation location.
After verifying the location, the installer will display the screen that shows the summary of actions to be performed. Confirm to proceed with the upgrade.
In case of problems, a backup of the existing database is made when upgrading. The backup can be manually selected to ensure safety of the current database. The location is given on the summary screen, and is usually the default backup directory for SQL Server.
To recover your system, restore the backup over top of the existing corrupted database. You can then try the upgrade again.
If problems persist, contact the Inflectra support team, and they will explain how to retrieve the logs for remediation.
"},{"location":"Spira-Administration-Guide/Installing-SpiraPlan/#advanced-install-scenarios","title":"Advanced Install Scenarios","text":"There may be a few cases where you need to customize the installation or upgrade of SpiraPlan\u00ae. To enable the installer's advanced mode, make sure to check the \"Advanced\" checkbox at the relevant screen of the wizard.
Including the options listed above with \"(advanced mode only)\" next to them, Advanced mode lets you:
Without a UserId/password listed in your connection string, Windows Authentication is used (the default). There are two different users to consider here:
The 'sa' account is a built-in SQL account ('system admin'), and the password is usually set in SQL Server itself. Note that you can use this under the 'Connection Info' part of the installer - it's not a security risk, as the installer does not remember this login and after the database is created.
Leave 'Database Settings' section unchanged in most circumstances (make sure the Database name is the actual database you'd like to upgrade).
"},{"location":"Spira-Administration-Guide/Installing-SpiraPlan/#adding-an-application-server","title":"Adding An Application Server","text":"Use this option when you already have another application server and database server configured and operational. Installation is very similar to a standard installation normally. However, when the page about the SQL Server and Database is displayed, it requires you to point to the existing SQL Server and Database.
All other actions during this install matches those in a standard installation.
"},{"location":"Spira-Administration-Guide/Installing-SpiraPlan/#upgrading-an-existing-database","title":"Upgrading an existing Database","text":"Use this option in two rare cases:
These steps in this option are the same as if you were upgrading the application normally. You will be asked for the SQL Server and Database information for your database.
Once the installer connects and verifies the version of the database to be installed, you will be prompted with an additional Options screen with two options:
The Microsoft Internet Information Services (IIS) web-server and SQL Server database are powerful tools to managing web-based applications. However it is important to make sure that they are correctly secured to prevent unauthorized access to applications being hosted on them. This is a fast-changing field and beyond the scope of this guide to address, however we recommend reading the following article for details on how to secure IIS:
http://www.iis.net/learn/manage/configuring-security
In addition to the steps outlined in this article, it is important to note that by default, all web pages served by IIS using the HTTP protocol are unencrypted, and as such, the usernames and passwords used by SpiraPlan\u00ae to log into the application can be read by network sniffing tools. If you are using SpiraPlan\u00ae purely within an intranet environment, this may not be an issue. However, if you are externally hosting SpiraPlan\u00ae onto a publicly accessible website, we recommend installing a Secure Sockets Layer (SSL) encryption certificate, and restricting all web-traffic to the secure HTTPS protocol instead.
"},{"location":"Spira-Administration-Guide/Installing-SpiraPlan/#troubleshooting","title":"Troubleshooting","text":"Every time the installer attempts an operation (like an install or upgrade), it stores a log file. This is located at \"c:\\ProgramData\\Inflectra\\SpiraPlan\". Each log file is labelled with the date and time of the operation. Please share the relevant files with the Inflectra support team if you need help troubleshooting the required operation.
"},{"location":"Spira-Administration-Guide/Product-Changing-Template/","title":"Product: Changing the Template a Product Uses","text":""},{"location":"Spira-Administration-Guide/Product-Changing-Template/#introduction","title":"Introduction","text":"Each product in Spira has a template that controls the bulk of how that product is configured and will work for end users. Each product is controlled by one template, though each template can control many products at once. A template affects a product\u2019s fields, custom properties, workflows, and more.
If you change a product\u2019s template, you are not changing the core data inside the product. But you are changing how that product will work. This is not something to do lightly. There is a deep connection between a product and its template. When you change templates, you are changing the workflows, and also all the links in the product from the old template to the new template.
It\u2019s like trying to change out the engine in a car by replacing it with parts from another engine. If that new engine has different pistons and gears then the car will look the same, with the same seats, the same windows, and the same doors. It will just run a little differently. Below, we explain in gory detail:
As mentioned above, only those standard fields controlled by templates can change when changing templates for a product. Let\u2019s call these fields \u201cdynamic fields\u201d No other standard fields (i.e. non custom fields) in the product will change in any way. The dynamic fields in SpiraPlan are below (not all of these are available in SpiraTeam or SpiraTest):
For each of the dynamic fields above the system will:
As mentioned above, only custom fields of type list or multilist are affected by changing templates. No other custom field changes in any way and custom lists are also completely unchanged.
Matching custom fields between templates is more complicated than for standard fields. Before the system can match values of custom list/multilist fields, it checks that the custom field in the old template has a matching field in the new template.
A custom list/multilist field has a match between the templates if:
If all the above conditions are met, the system will:
When you look at the history for artifacts after the template has been changed, you won\u2019t see any difference. Behind the scenes, references to dynamic fields and custom list/multilist fields, are updated to the new template.
This so that, where possible, when you try and revert a history change, the reverted data updates the artifact to the new template - not the old one. If there was no match found when changing templates, then reverting history will not revert that particular field.
"},{"location":"Spira-Administration-Guide/Product-Changing-Template/#what-about-test-configurations","title":"What about test configurations?","text":"Test configurations use the template\u2019s custom lists. So when you change templates to a new template with different custom lists, what will happen? The system will:
As you will see above, the process of changing templates is not without risks. We flag many of these risks to you during the process itself to guide you. Below are five steps to help you prepare for changing to a product's template.
This page displays a list of changes made to items within the selected product. By default, items are shown in chronological order - with the most recent at the top.
The following artifact changes are recorded:
If baselining is enabled for this product, changes to assocations, test coverage, and positions of test steps, use case steps, and mitigations are recorded. Certain changes to artifacts are not recorded, such as location changes (indenting, outdenting) and comment additions.
Additionally, certain product administration changes are recorded and displayed. These include turning baselining on and off for a product, all testing settings, and some planning options (for example Work In Progress Limits).
There are a handful of change types recorded and displayed here:
Note: When upgrading from a version before v3.1, each individual field changed will be considered a unique change, due to how previous versions recorded history. However, as soon as the application is upgraded, simultaneous changes will be grouped together based on their last-update date.
This screen allows the administrator several options (below). NOTE: if baselining is enabled for this product you will not be able to purge all, and you will only be able to revert recent changes (those made since the last baseline for this product was created).
The history details screen displays information on the selected change set:
The History Details screen will show basic information as well as fields that were changed in this change set. Shown here is the Change ID, the date and time that the change was made, the user that made the change, the change type, the artifact affected, and the set of fields affected.
If a set of fields were affected (Standard or Custom), then the list of fields will be listed below. In the example above, the change was a Modification, and 5 fields were changed. In other change types, no fields will be displayed.
If the artifact is still available in the system, you can click the Artifact or click the 'View Item' button in the toolbar to view the item as it is currently. However, if the item has been deleted, a warning label will be displayed (as above in the example screenshot), the View Item links will be disabled, and a new option, \"Purge\" will appear on the toolbar.
If baselining is turned on
If baselining is enabled for this product, you will only be able to revert or purge recent history items (those made since the last baseline for this product was created).
"},{"location":"Spira-Administration-Guide/Product-General-Settings/#purging-items","title":"Purging Items","text":"Items that have been deleted by any user still remain in the database, but do not affect statistics or reports, and do not show up in reports and cannot be viewed. The artifacts are still in the database, however, and can be restored by clicking on the Restore button in the toolbar.
Purging an individual item can only be done while viewing one of its history detail screens. Once an item is purged, you will be taken back to the history list screen. All the previous history items for the artifact will be removed, and replaced with a single \"Purged\" history item.
Items that are purged cannot be restored into the database, as unique identifiers will be wiped from the database, so be sure that you are sure you want to purge an item before doing so.
You can purge all items in the product at once by clicking the \"Purge All\" button located on the History List page. This will take some time depending on how many deleted items are in your database, and it is recommended that the database files be compressed in SQL Management Studio afterwards to free up space and compress clustered indexes.
"},{"location":"Spira-Administration-Guide/Product-General-Settings/#reverting-items","title":"Reverting Items","text":"Reverting an artifact will attempt to reset all fields back to the selected change set, reverting all changes made after the selected change set as well. In certain cases, the artifact will not be able to be reverted -- cases like this could be caused by other items having been deleted or purged. (For example, if Requirement #1 was linked to Release #4, and that Release does not exist anymore.) In cases like this, no fields will be reverted and the artifact will remain unchanged.
Reverting an item will cause it to be undeleted if it has been deleted.
You can revert multiple items from the History List page -- however, the only items that can be reverted back are Deletes and Modifications. All other types will be ignored. When selecting multiple items, you can select more than a single change set for a specific artifact, the artifact will be rolled back to the earliest change set selected.
"},{"location":"Spira-Administration-Guide/Product-General-Settings/#product-associations","title":"Product Associations","text":"By default, all products in SpiraPlan are completely self-contained. Artifacts in one product can only be linked or associated with artifacts in the same product. However, for some customers, they need a way to share artifacts between products. This administration screen lets the product admin specify which other products can access artifacts in the current product:
Permissions when sharing artifacts across products
When you share artifacts from the current product to another product, the permissions and membership in the other product determine who can see what items. You therefore need to think about the impact of this before enabling cross product associations.
For example: Marie is a member of Product A and can see its requirements. She is not a member of Product B and cannot see anything in Product B at all. If Product B shares its requirements with Product A, anyone who can see Product A's requirements (like Marie can) will now be able to see (not edit - only see) all of Product B's requirements too.
"},{"location":"Spira-Administration-Guide/Product-General-Settings/#what-artifacts-can-be-shared-across-products","title":"What artifacts can be shared across products","text":"You can share the following artifacts from one product to another:
When you share the above artifacts from the sharing product to another product, members of that product can now see (read only) all artifacts of that type from the sharing product. Users can see these artifacts in a number of places in the other product (the one being shared with). For example:
To share artifacts with another product, click on the 'Add' button in the toolbar:
Select the name of the product you want to share with and choose which artifact(s) you want to share with this product:
When you click the 'Add' button, SpiraPlan will add the new product association to the list.
You can change the product association (for example to change which artifacts are shared) by clicking on the 'Edit' button to the right. This updates the association list.
To remove an association, simply select its checkbox and click 'Remove'.
"},{"location":"Spira-Administration-Guide/Product-General-Settings/#data-synchronization","title":"Data Synchronization","text":"This pages shows a list of all active integration plug-ins that the product is actively synchronizing with. Available plugins are set system wide.
In the above example, only TFS is active for this particular product. Clicking on \"View Product Mappings\" will display a detailed page for configuring this product to work with this plug-in. Here you can set the external key to use in the external application and map all relevant fields between Spira and this application. To read about how to configure this page, refer to the guide for your particular external bug tracking tool.
"},{"location":"Spira-Administration-Guide/Product-General-Settings/#product-data-tools","title":"Product Data Tools","text":"This page contains several different data management tools that can be used to identify certain data issues in the system and correct them. There are two main sections to this page -- Data Caching and Indentation Hierarchy:
Database Indexes: In order to improve the performance of SpiraPlan\u00ae, it can be beneficial to refresh the database indexes. Clicking the \"Refresh\" button illustrated above will refresh all relevant database indexes across all SpiraPlan products. If for any reason performance seems to be slower than usual after a large import of data (for instance from Excel, or using the product migration tool) or after a recent database upgrade, you should consider refreshing the indexes. Depending on the size of the database, this could take some time. Please keep the web page open throughout the process to ensure it can complete successfully.
Data Caching: In order to improve the performance of SpiraPlan\u00ae, certain types of product data are cached. Very occassionally, the cache can get behind the data in the actual database. In such cases, refreshing the cache will make sure the cache is fully up to date and correct data is therefore displayed in the application. If users report this kind of problem in one of the cache areas, click the relevant Refresh Cache button.
Indentation Hierarchy: The Requirement and Releases pages use an \"Indent\" system for managing the hierarchy of information. This allows requirements and test cases to be nested under parent items and be rapidly searched and filtered on. Sometimes if a move/copy operation is interrupted (due to a network outage, etc.) the hierarchy may get corrupted. If you suspect a problem with either of these artifacts, click the \"Check\" button. Once the check has run, if you see a red Error message instead of the Green OK that means problems were found. If that happens, click the \"Correct\" button and the system will correct the indent levels.
Clicking on the Source Code link in the administration menu will, if a source code provider has been set up by a system administrator, show a screen like the one below.
The first thing you need to do (regardless of whether you'll be overriding any of the settings) is to make the provider active for the current product. To do this, change the toggle to \"Yes\" and click [Save]:
Now you can decide whether you want to override any of the default settings for this product. Any field left blank will automatically get its settings from the default values entered at the system level. In the example above, we have specified a product-specific repository path, login and password. Once you have correctly configured the product, click [Save] to commit the changes.
To improve performance, SpiraPlan will cache some of the data it receives from the source code provider. Normally SpiraPlan will know when to update the cached data based on changes made in the source code system automatically. However, sometimes you may wish to force the cache to refresh right now. To do so, click the \"Refresh Cache\" button. If you ever want to wipe the cache completely and have it rebuild from scratch, click \"Clear Cache\".
You are now ready to use SpiraPlan\u00ae in conjunction with the source code tool you selected. For details on how to use the Source Code integration features of SpiraPlan, please see here.
"},{"location":"Spira-Administration-Guide/Product-General-Settings/#baselines","title":"Baselines","text":"NOTE: read about how baselining works and how to get started with it here
This page displays a list of all baselines in the product. You can only access this page in products where baselining has been turned on.
The table of baselines has the following columns:
Name: baseline name
Name (this links to the baseline details page)
To filter and sort the list of baselines, use the filter and sort controls at the top of the table.
"},{"location":"Spira-Administration-Guide/Product-General-Settings/#baseline-details","title":"Baseline Details","text":"This page displays detailed information about a single baseline. You cannot edit information about the baseline on this page. That can only be done from the release details page.
Information about the baseline is divided into 4 sections:
Why do we show the previous baseline?
A baseline is created against a point in time (more precisely, against a specific change event in this product). This is the end of the baseline. To know what happened during a baseline you need to know when a baseline starts. The start of a baseline is immediately after the end of the last baseline. If this is the first baseline in a product, then the baseline starts at the start of the product.
For example, let's say we start a new product. A few days later we create baseline 1. A week later we add baseline 2. Baseline 1 runs from the moment we created the product until the moment we created the baseline. More precisely, baseline 1 runs from the first change ID of the product, to the change ID that the baseline is linked to. Baseline 2 meanwhile runs from the moment baseline 1 was created through to the moment baseline 2 was created.
"},{"location":"Spira-Administration-Guide/Product-General-Settings/#artifacts-changed-in-a-baseline","title":"Artifacts changed in a baseline","text":"To filter and sort the list of artifacts shown in the table, use the filter and sort controls at the top of the table.
This table of artifacts only shows artifacts that changed in the baseline (between when this baseline was created and the previous baseline). Each artifact is only shown once, even if it changed multiple times. The changes that happened to the artifact are combined into a single description so you can easily see a summary of what happened to the artifact during the baseline (for example, was it only modified, or added then modified, or modified then deleted).
This table shows the following information:
This page displays detailed information about the changes made to a specific artifact for a specific baseline. This is a great way to see what happened to an artifact in the baseline.
Information about the artifact at this baseline is divided into 3 sections:
The table of changes is very similar to what you see on the history tab when looking at an artifact. The key difference is that here only a subset of the history is displayed: only those changes that fall within the baseline. All other changes to the artifact are not shown.
This table shows the following columns. You can apply a filter using any of the fields except for Change ID (because this is already filtered to show the key range for the baseline).
The SpiraApps page shows product administrators every SpiraApp currently active in the system, sorted alphabetically1.
For each SpiraApp in the list you see:
Available operations
The SpiraApp Settings page shows any product level settings available for the particular SpiraApp. For more detailed information about each SpiraApp, what they do, and how to work with them refer to the dedicated SpiraApp documentation
If the SpiraApp has no product settings you can still access the page but there will be no settings to edit.
If the SpiraApp has products settings you will see:
Within each group a list of available settings:
Click the \"Save\" button to commit any edits.
SpiraApps are shown even if they will not fully function in your application. For instance, the FMEA SpiraApp is only compatible with SpiraPlan but will still show in the list if you are using SpiraTest or SpiraTeam.\u00a0\u21a9
The Product Administration Home page is accessible to users whose product role includes product admin permission. There are multiple ways to navigate to it:
It provides Product Owners with quick access to important information.
As with other dashboards, you can edit these widgets, their position, and what is shown, using the two buttons in the top right (the cog and the plus).
"},{"location":"Spira-Administration-Guide/Product-Home/#product-overview","title":"Product Overview","text":"This widget displays general information about the product. To edit this information, click \u201cView Details\u201d.
"},{"location":"Spira-Administration-Guide/Product-Home/#product-history-changes","title":"Product History Changes","text":"This widget shows the latest history changes in the product. By default, 5 items are shown, but this number can be changed. To view the complete Product History list, click View All.
"},{"location":"Spira-Administration-Guide/Product-Home/#product-membership","title":"Product Membership","text":"This widget shows a list of product members. By default, 10 users are shown, but this number can be changed. To view the complete Product Membership list and edit it, click View All.
"},{"location":"Spira-Administration-Guide/Product-Home/#components","title":"Components","text":"This widget shows the active components for the product. By default, 5 components are shown, but this number can be changed. To view or edit the complete list of components, click View All.
"},{"location":"Spira-Administration-Guide/Product-Home/#source-code","title":"Source Code","text":"If a source code provider has been set up by a system administrator and is active for the current product, it will be displayed here. Click View Details to configure it.
"},{"location":"Spira-Administration-Guide/Product-Home/#spiraapps","title":"SpiraApps","text":"This widget shows a list of all active SpiraApps at the system level. It shows the SpiraApp icon and name, its system active status (which will always be Yes), and whether or not it is enabled for the product.
"},{"location":"Spira-Administration-Guide/Product-Home/#data-synchronization","title":"Data Synchronization","text":"If any Data Sync plug-ins have been set up by a system administrator, they will be displayed here. Click View Details to see more details and to configure them for the current product.
"},{"location":"Spira-Administration-Guide/Product-Planning/","title":"Product: Planning","text":""},{"location":"Spira-Administration-Guide/Product-Planning/#planning-options","title":"Planning Options","text":"The Planning Options page lets you configure the schedule and calendar options for the various product estimation and planning modules. The settings are specific to each product. The page is divided into a number of collapsible sections.
"},{"location":"Spira-Administration-Guide/Product-Planning/#general","title":"General","text":"Work In Progress (WIP) limits set the maximum number of requirements that the product team can efficiently manage at each stage of their Kanban process. Using WIP limits can be a useful way for teams to manage their work, allowing them to get through their work faster. This is done by focusing only tasks that can be done now (in other words, the work that can in-progress at any one time).
This feature, not available in SpiraTest, is an optional way of using the Planning Board. To not use the feature at all, leave the fields in each of the columns in the table blank.
To make use of WIP limits you need to:
The multipliers and percentages for releases and sprints are independent of one another.
Example WIP Limit
Clicking on the \"Testing Settings\" link brings up a list of options that the administrator can configure regarding testing. Select from the options displayed (as illustrated below) and click \"Save\" to commit the changes.
You can enable or disable the following settings:
Test Case Execution: the following settings affect the test execution rules / experience of all testers in the products
Auto Unassign Tests:
Execute Only From Test Sets: (default = no) when turned on testers will not be able to execute Test Cases. They will only be able to execute Test Sets.
SpiraPlan lets you define a list of Components for each product. These components represent the main functional areas of the system and artifacts can be associated with each of the defined components.
This page lets you display the list of components based on three predefined filters:
From this page you can click on the 'Add Component' option to add a new component in the list:
After entering the name of the new component and choosing its Active status, click on 'Save' to commit the new item. To edit an existing component, edit its name and Active status and click 'Save'. To delete a component, click the 'Delete' option next to its name. Once deleted, an item can be undeleted by changing the display to 'All' and then clicking 'Undelete'.
"},{"location":"Spira-Administration-Guide/Product-Users/","title":"Product: Users","text":""},{"location":"Spira-Administration-Guide/Product-Users/#product-membership","title":"Product Membership","text":"The following page is displayed when you choose the \"Product Membership\" link from the Administration menu:
This page displays the name of the current product together with a list of all the users who are currently members of the product along with their currently assigned product role. If you want to modify the membership for a different product, click the \"Change Product\" button to be taken back to View/Edit Products screen where you can select a different product.
To modify the role of a user assigned to the product, change the role for that user's entry in the drop-down menu and click the \"Save\" button.
To remove a user from the product, check the box to the left of the user's name and click the \"Delete\" button. Note that this only removes them from the product, not the entire system. See the product roles documentation for more information.
To add a user to the product, so that they can access its information, click the \"Add\" button and you will be taken to the following screen that lists all the users in the system that are not currently members of the product:
You now should narrow down the list of users by entering filter criteria and clicking [Filter]; you can also sort the results to make viewing easier. Once you have located the appropriate user(s), just select a product role for them from the drop-down list and click [Add] to add them to the product in the specified role.
"},{"location":"Spira-Administration-Guide/Product-Users/#team-membership","title":"Team Membership","text":"In beta, available in SpiraPlan only
System admins can enable beta functionality across the application for their users from the System Admin > General Settings page.
SpiraPlan lets product admins take teams that have been created at the system level, and assign product members to any active team on a product by product basis. You can use these teams in different ways in different products, but the most common way is to group people together based on your organizational or functional structure.
This page displays the name of the current product and a list of all the users who are currently members of the product (sorted alphabetically by full name). For each product member you can see their:
To change a user's current team, change the selected value in the dropdown. Once all changes to teams are made click \"Save\" to commit the changes.
Only currently active teams are shown. If a user is not in any team (for this product), or in an inactive or deleted team, their team will show as \"-- None --\".
"},{"location":"Spira-Administration-Guide/Program-Capabilities/","title":"Program Capabilities","text":"These features are only available in SpiraPlan
"},{"location":"Spira-Administration-Guide/Program-Capabilities/#statuses","title":"Statuses","text":"The following screen is displayed when you choose the \"Statuses\" link from the Capabilities section of the system administration menu:
The screen displays a list of all the defined statuses in the system. By default, it displays only the active statuses. Display all statuses (active and inactive) by selecting \"All\" from the \"Displaying\" dropdown.
To edit an existing status: change the name, open check-box, set a default status, a position, and/or change the active flag then click \"Save\". Note that:
The following screen is displayed when you choose the \"Types\" link from the Capabilities section of the system administration menu:
The screen displays a list of all the defined types in the system. By default, it displays only the active types. Display all types (active and inactive) by selecting \"All\" from the \"Displaying\" dropdown.
To edit an existing type: change the name, set a default type, and/or change the active flag then click \"Save\". Note that:
The following screen is displayed when you choose the \"Priority\" link from the Capabilities section of the system administration menu:
The screen displays a list of all the defined priorities in the system. By default, it displays only the active priorities. Display all priorities (active and inactive) by selecting \"All\" from the \"Displaying\" dropdown.
To edit an existing type: change the name, color, score, and active flag then click \"Save\". Note that:
Clicking this link from the Capabilities section of the system administration menu will open the system custom properties page for capabilities.
"},{"location":"Spira-Administration-Guide/Program-Milestones/","title":"Program Milestones","text":"These features are only available in SpiraPlan
"},{"location":"Spira-Administration-Guide/Program-Milestones/#statuses","title":"Statuses","text":"The following screen is displayed when you choose the \"Statuses\" link from the Program Milestones section of the system administration menu:
The screen displays a list of all the defined statuses in the system. By default, it displays only the active statuses. Display all statuses (active and inactive) by selecting \"All\" from the \"Displaying\" dropdown.
To edit an existing status: change the name, open check-box, set a default status, a position, and/or change the active flag then click \"Save\". Note that:
The following screen is displayed when you choose the \"Types\" link from the Program Milestones section of the system administration menu:
The screen displays a list of all the defined types in the system. By default, it displays only the active types. Display all types (active and inactive) by selecting \"All\" from the \"Displaying\" dropdown.
To edit an existing type: change the name, set a default type, and/or change the active flag then click \"Save\". Note that:
Clicking this link from the Program Milestones section of the system administration menu will open the system custom properties page for program milestones.
"},{"location":"Spira-Administration-Guide/System-Administration/","title":"System Administration","text":""},{"location":"Spira-Administration-Guide/System-Administration/#introduction","title":"Introduction","text":"Now that you have successfully installed SpiraPlan\u00ae, this section of the guide outlines how to perform the typical administrative tasks necessary for setting up products and programs in the system, managing users and verifying the license information.
"},{"location":"Spira-Administration-Guide/System-Administration/#types-of-administrator","title":"Types of administrator","text":"To perform these tasks, you need to login to the system with a user that has some level of \"administration\" permissions within the system. There are four different sections to administration, and each has its own permission. These sections and their permissions are:
System Administration: tasks like approving new users, creating new products, changing security settings, or viewing the logs all happen at the system-wide level of administration. There is a special \"System Administrator\" flag that can be assigned to any user (by an existing system admin only). Any user that has this flag can perform any system administrator task. Please note that a special \"administrator\" user is created by the installer. You should initially login to SpiraPlan\u00ae with the username administrator, and the password PleaseChange. Change this password as soon as possible to something that is secure yet memorable by clicking on the \"User Profile\" link.
Product Administration: a product admin can make changes specific to that product and that product only. For instance, they can add or remove users from a product. Once a user is made a product admin, they can perform all the actions in the product administration section. Each individual product has a defined set of users who are members of that product. Each member is assigned a specific role (many users can share the same role), and a role can be set to be a product admin. Please note, that when a system admin creates a product, they are automatically added as \"Product Owner\".
Program Administration: just like with products, some aspects of a program are managed in the program section of administration. Anyone who is assigned the role of \"Program Owner\" on a program can perform these administrative functions.
Template Administration: end users of the application will work with products and sometimes programs. However, behind the scenes of every product is a template. This template controls the bulk of how that product is configured and will work for the end users. Each product is controlled by one template, though each template can control many products at once. Making a change to a template in template administration will immediately affect all products controlled by that template. Such changes to a template include changing the name of incident types, changing the colors used to indicate requirement priorities, or changing custom properties. Please note that template admin permissions are managed by the same roles that manage product admin permissions and that apply to members of each product. You can read more about how template admin permissions work here.
Report Administration: a report admin can administer custom reports and graphs (create, edit, delete). They can also access custom report data in 3rd party tools via OData and the API. These functions are also available to system admins under System Administration. However report admins can only access the reporting functions and pages - they have no access to any other admin functions. There is a special \"Report Administrator\" flag that can be assigned to any user (by an existing system admin only). Any user that has this flag can perform any report administrator task.
Once you have logged in as an administrator, you can click the \"Administration\" link which can be found on the right-hand side of the global navigation at the top of any page:
This will display the context aware administration menu popup. This menu will show different sections depending on where you are in the application and your administrative privileges. For example, only system administrators see the \"System: Admin Home\" section shown at the bottom of the screenshot below.
In the screenshot below you can see that administration links are being shown for three different sections:
Library Information System -- which is a product
The template called Sample Template: Agile (this is the template the controls the above product)
System wide administration
This menu only shows the links to one product, one template, or one program at a time (and System Admin all the time to system administrators). Because this user is currently viewing a page in the product 'Library Information System', admin items for that product and its template are visible.
You can see that the \"Requirements\" sub section is highlighted. This is because the user is currently on a requirements page of the 'Library Information System' product (either in the main application or in template administration). The highlighting serves no function other than to guide the user to where they may wish to focus.
Below is an example of an administration menu where a user is a Program Owner but with no other access to administration. This menu is much barer than the one above, because the administrative options this user has are that much more limited. This user only has admin access to Sample Program One. If they navigate to a different program page or to a product page in the application, they would not see the admin menu at all.
If a user wants to see what, if any, parts of the system they have administrative access to, they can do so at any time. Clicking on the workspace dropdown on the global navigation will show them the list of workspaces they have access to. Below, you can see that products are grouped into programs, and there is a dedicated Templates section at the bottom. Any workspace the user has administrative access to has a superscript gray cog to the right of that workspace's name.
If this user wants to access the admin menu for \"Sample Barebones Product\", first that cog tells them they can do so. By clicking on that workspace's name, they will be switched to that workspace and then they can click on the admin button to get the right menu.
In the screenshot above at the top there is a \"System Administration\" workspace. This is visible because this user is a system administrator. Clicking this will take the user directly to the System Administration home page.
The Administration home page, like all admin pages, is divided into two areas:
the skinny left-hand bar. Clicking this will show the context-aware administration menu discussed above
the main pane that displays the available options for the selected page.
This home page shows a number of useful widgets with information about the system. You can edit these widgets, their position, and what is shown, using the two buttons in the top right (the cog and the plus).
Product and Template administration home pages also show useful data and links relevant to them. On most admin pages for products and templates the name of the current product or template is shown at the top of the page in a heading. These names are hyperlinks that will open the product or template administration home page.
When you first install the system, we suggest three main tasks to perform as the system administrator to get familiar with the basics and to help colleagues start to use the application:
These tasks typically need to be performed before any other users can use the system, since there will be no logins or products available other than the sample ones provided during the installation.
Below is the admin menu for a user who is a report administrator but has no other active admin roles. The only menu options available are for custom reports and graphs.
The rest of this guide explores each area of administration in order, grouped by administration section.
"},{"location":"Spira-Administration-Guide/System-Administration/#how-user-permissions-are-set","title":"How user permissions are set","text":"As described above there are 4 different types of administrator. There are also different permission models for accessing the application itself (ie not the administration pages). How do you set each of these permissions so that a user can only see / use what they are supposed to?
Product roles have two special flags. Changing these flags immediately affect anyone with that particular role:
Permissions for programs are more simple and managed on a per program basis:
Each user profile has two special flags about permissions, which affect the entire system, but only for one user at a time (they are completely separate to product and program permissions):
System administrators and product roles
Note: if a user is a System Administrator, it will force that user to always have the 'Product Owner' role on all their assigned products, regardless of the chosen role. If you disable this option, they will then revert back to their true role.*
"},{"location":"Spira-Administration-Guide/System-Custom-Properties/","title":"System Custom Properties","text":"These features are only available in SpiraPlan
Spira allows you to customize different workspaces or program-level artifacts. For each type (e.g. products, program capabilities, or program milestones) you can create up to 30 system custom properties. System custom properties are shared across every relevant workspace or program-level artifact in the system. For example, all products will share the same set of available custom properties; and all capabilities will share a different set of available custom properties. These system custom properties are visible in the following places:
You can create a variety of different types of custom properties. You can create as many custom lists as you need with each having as many values as you need. Custom lists are shared at the system level and available for any custom property to use. This page describes how to setup different custom lists and custom properties for relevant workspaces and artifacts.
"},{"location":"Spira-Administration-Guide/System-Custom-Properties/#edit-custom-properties","title":"Edit Custom Properties","text":"To access the custom properties definitions for a specific workspace or artifact, you must be a system administrator. Open the system admin menu and click the relevant link, either in the \"Custom Properties\" or relevant artifact sub-section of the menu. This opens the custom properties page for that workspace or artifact where you can quickly see the name, field number, type, and actions (edit and delete) for each custom property.
In the example below we see 7 custom properties defined for products. The custom properties page has rows for each available custom property.
To edit an existing custom property definition click the \"Edit Definition\" button for that specific property. To add a new definition click the \"Add Definition\" button. In either case the following dialog will be displayed:
For each custom property you set the following fields on the main definition tab:
Different types of custom properties supported:
Each custom property can have optional settings applied to it to further control the custom property. Note: not all settings are available for all property types. These settings are on the Options tab of the dialog:
When finished, click the Save button.
Renaming or Removing Custom Properties
When changing a custom property's type or removing a custom property, the data is not actually removed from the workspace or artifact. Therefore, if you change a custom property from a date type to a text custom property, the field may display the old date value until it is changed by the user.
"},{"location":"Spira-Administration-Guide/System-Custom-Properties/#edit-custom-lists","title":"Edit Custom Lists","text":"If you are planning on having any list-based custom properties at the system level, you need to create and populate the system custom lists that the user will be able to select from. These lists are stored separately from the individual custom property definitions so that you can have one set of values (e.g. list of operating systems under test) be reused by multiple custom properties.
The following screen is displayed when you choose the \"Custom Lists\" link from the Administration menu:
The screen displays all the system level custom lists currently defined, together with the number of values associated with each list. By default the screen will initially be empty so the first thing you need to do is click \"Add List\" to create a new custom list:
After changing the name of the list, and specifying whether the values will be ordered by their name or the order in which they were entered (called by ID), you can either click \"Save\" to commit the change, or click the \"Add Value\" option to add some list values:
This is the set of values that the user will select from the drop-down list when the custom property is displayed. You can change the display to include:
To add a new custom list value, click the \"Add Value\" button and a new row will be added to the list which you can now edit. To edit an existing custom list value, change the name in the textbox and click \"Save\". To delete a custom list value, click on the \"Delete\" hyperlink. If you want to remove an item from the list temporarily, you can set its Active dropdown list to 'No', if you want to remove an item permanently, just click the 'Delete' button.
To edit an existing custom list, click the \"Edit Values\" button to display the custom list name and list of associated values (which is the same screen as the one displayed for a new list). To remove a custom list from the template, just click on the \"Remove\" button next to the custom list and the list and all its associated values will be deleted from the template.
Recovering deleted list values
If you delete a custom list value, there is an option to undelete by changing the display selection to \"All\" and clicking the 'Undelete' button next to a deleted value.
"},{"location":"Spira-Administration-Guide/System-Home/","title":"System: Home Page","text":"The System Administration Home page is only accessible to users with the special \"System Administrator\" flag on their profile. There are multiple ways to navigate to it:
It provides system administrators with quick access to important information.
As with other dashboards, you can edit these widgets, their position, and what is shown, using the two buttons in the top right (the cog and the plus).
"},{"location":"Spira-Administration-Guide/System-Home/#system-information","title":"System Information","text":"The system information widget displays an overview of your Spira instance, including license information and the number of currently-active users, as well as links to detailed information.
"},{"location":"Spira-Administration-Guide/System-Home/#manage-sample-data","title":"Manage Sample Data","text":"On fresh installations that include the sample data that ships with the application there is a button on this widget to direct you to the admin page to set and manage sample data. This can be helpful if want to start with a clean slate following a trial and not have the sample data cluttering your system.
"},{"location":"Spira-Administration-Guide/System-Home/#event-log","title":"Event Log","text":"This widget shows the latest events from the system event log. By default, 5 events are shown, but this number can be changed. To view the complete event log, click View All.
"},{"location":"Spira-Administration-Guide/System-Home/#pending-user-requests","title":"Pending User Requests","text":"If you have enabled the ability for users to register for new SpiraPlan accounts themselves, any pending requests will be listed here. To accept or deny the requests, click View All. By default the list is limited to 5. This number can be adjusted.
"},{"location":"Spira-Administration-Guide/System-Home/#data-synchronization","title":"Data Synchronization","text":"This widget shows a list of active data-synchronization services, together with the status and date/time of the last synchronization.
"},{"location":"Spira-Administration-Guide/System-Integration/","title":"System: Integration","text":""},{"location":"Spira-Administration-Guide/System-Integration/#data-synchronization","title":"Data Synchronization","text":"SpiraPlan\u00ae is capable of synchronizing its data with a variety of other systems, including but not limited to requirements management systems and standalone bug-tracking tools. The various integration plug-ins for SpiraPlan\u00ae and the steps for configuring the data-synchronization settings are described in the SpiraTest External Bug-Tracking Integration Guide. Each individual tool has its own separate guide that builds on this setup guide.
If you are synchronizing data between SpiraPlan and one of these other systems, the 'Data Synchronization' administration page will show a list of available data-synchronizations services:
In the example above, we have six plug-ins available, with only Azure DevOps (ADO) active. For ADO, the data sync is active for a single product: Library Information System (Sample).
This table shows the following information about each data sync plug-in:
operations you can perform on each data sync.
Above the table you can add a new data sync or refresh the status of the page to ensure that you are seeing the most up to date information.
"},{"location":"Spira-Administration-Guide/System-Integration/#source-code-integration","title":"Source Code Integration","text":"This section refers to the functionality available to on-premise customers of SpiraPlan or those customers that have disabled TaraVault. If you are using the cloud / hosted version of SpiraPlan and have not disabled TaraVault, please refer to TaraVault Configuration instead.
SpiraPlan\u00ae is capable of integrating with a variety of source code / Software Configuration Management (SCM) tools such as Git, Subversion, CVS and TFS. This allows you to browse the source code repositories using the SpiraPlan web interface, and more importantly link commits in these tools to artifacts in SpiraPlan. This provides the end-to-end traceability from code commits/check-ins to the tasks, incidents and requirements that necessitated the code change.
The information on using the various source code providers for SpiraPlan\u00ae and the steps for configuring the provider-specific settings are described elsewhere - for example for Git.
To configure a source code provider, you need to click on the System Administration > Integration > Source Code link in the Administration navigation to bring up the list of configured source code providers:
By default the only provider listed will be the TestVersionControlProvider which is used for demonstration purposes only, and can be deleted from a production system by clicking on the \"Delete\" button to the right of it.
To edit the system wide settings for an existing source code provider, click on the \"Edit\" button on the far right of the row for that provider. You can edit the same settings that were shown above when you first created that provider.
If you want to change the settings for a particular product (including to turn that provider on or off for the product):
To add a new source code provider, click the \"Add\" button at the bottom to go to the Plug-in details page:
When finished, click the \"Insert\" button and you will be taken back to the Source Code integration list page, with new provider listed as an available plug-in:
"},{"location":"Spira-Administration-Guide/System-Integration/#test-automation","title":"Test Automation","text":"SpiraPlan\u00ae can be used to manage the development, scheduling and execution of automated unit, functional and load tests written using a variety of test automation engines (e.g. HP QuickTest Pro, SmarteScript, TestComplete, etc.). This section allows you to configure the different engines that are available in your environment so that the testers know which tools they can use to schedule tests with.
The information on using the various test automation engines for SpiraPlan\u00ae and the steps for configuring the engine-specific settings are described in the SpiraTest/Team RemoteLaunch Automated Testing Integration Guide.
To configure a test automation engine, you need to click on the Administration > Integration > Test Automation link in the Administration navigation to bring up the list of configured test automation engines:
To add a new test automation engine, click the \"Add\" button to enter the Automation Engine details page. The fields required are as follows:
Name: The name of the test automation engine that you're adding. This can be set to any name of your choice that would make sense to your users.
Description: The description is used for any comments or additional information that you need to use to describe the automation engine.
Active: If checked, the automation engine is active and able to be used in any product.
Token: This needs to match the name of the Automation Engine DLL file that you're using (see the SpiraTest/Team Automated Testing Integration Guide for more details on your specific tool) for the specific automation engine.
When finished, click the \"Insert\" button and you will be taken back to the test automation engine list page, with new automation engine listed.
To edit the settings for an existing test automation engine, just click on the \"Edit\" link next to the name of the engine and you will be able to edit the same settings that were shown above when you first created it.
Once you have made the appropriate changes, click the [Save] button to commit them.
You are now ready to use SpiraPlan\u00ae in conjunction with the test automation engine you added. For details on how to use the test automation features of SpiraPlan, please refer to the SpiraPlan\u00ae User Manual.
"},{"location":"Spira-Administration-Guide/System-Integration/#floating-licenses","title":"Floating Licenses","text":"Cloud users of SpiraPlan who have a floating license subscription addon to your SpiraPlan will see a \"Floating Licenses\" section in the Integrations section of the system administration menu. For example, if you have Rapise floating licenses, you will see this menu item and page.
Read more about how to purchase and use Rapise floating licenses.
When you go to the Floating Licenses page you will see how many floating licenses are available as well as how many are currently in use (initially the list will be empty):
Once you have floating licenses available, when you connect, for example, Rapise to Spira, Rapise automatically requests a floating license from Spira. The application will use that license until Rapise is closed or a SpiraPlan administrator clicks the End Session button in SpiraPlan.
The floating licenses page will show how many licenses are available and information about each currently active session. A system admin can end a session at any time by clicking the \"End Session\" button on a specific session.
"},{"location":"Spira-Administration-Guide/System-Reporting/","title":"System: Reporting","text":"SpiraPlan has a powerful set of reports and charts available out of the box that cover most product's needs. However, there is often a need to be able to generate custom reports and graphs that are specific to your organization. In this section, you can create custom graphs and reports for your users to use.
"},{"location":"Spira-Administration-Guide/System-Reporting/#edit-reports","title":"Edit Reports","text":"The \"Edit Reports\" administration page lets you create custom reports in the system that your users can run in the various products they have access to. Note that the report definitions themselves are global to the system and therefore available in all products.
The list of report definitions contains both the standard (default) reports that ship with the system and any custom reports that you have defined. However, any of the reports listed with the \"Default\" option checked will not be editable. So, if you want to modify one of the built-in reports to make it better suit your needs, you should instead click on the \"Clone\" button next to the report and make a copy of the report that you can then modify. You can view any of the default reports by clicking on the associated \"View\" button.
To edit an existing non-default report, click on the \"Edit\" button. To add a new report from scratch, click on the \"Add New Report\" option at the bottom of the list. Either of these will take you to the Report editing screen:
The top-half of this screen (illustrated above) lets you specify the name of the report, the long description (displayed in tooltips but not in the report itself) and a rich-text footer and header. The header and footer will be displayed at the top and bottom of the generated report.
In addition, you can specify whether the report is active (and therefore can be used in the SpiraPlan reports center) and which report category heading the report will appear in. This is also used to determine which role(s) are able to run the report (e.g. a user that has permissions to view requirements will be able to run all reports listed under the \"Requirement Reports\" category).
The lower-half of the screen displays the list of formats, standard sections and custom sections that make up the report:
The list of formats is fixed in the system, you can simply choose which formats this specific report will be available in. The reporting engine will take care of converting your report into the target format, you just need to specify which type(s) are applicable.
a) Standard Sections
The list of standard sections contains a list of the various pre-defined report sections that are to be included in the report. A standard section consists of a set of nested queries and embedded elements that will return back data. For example, the \"Requirements Details\" section consists of a list of all the requirements in a product, together with the associated test cases, tasks, custom properties, attachments, discussions, change history, source code commits, and other related items.
With a standard section, you cannot change the underlying data query, but you can change the header, footer and XSLT template used to format the results:
When you either click on \"Add New Standard Section\" or the \"Customize\" link next to an existing standard section, the popup dialog illustrated above will be displayed. On this page you can change the following fields:
Name -- Choose the name of the standard report section you want to use from the dropdown list. Changing the name of the section will automatically update the Description field below.
Description -- This is the description of the report section, it is not displayed in the final report.
Header -- This is the header that will be displayed before the dynamic data retrieved as part of the report section. You can enter in formatted rich text in this field.
Footer -- This is the footer that will be displayed after the dynamic data retrieved as part of the report section. You can enter in formatted rich text in this field.
Template -- This is the eXtensible Markup Language Stylesheet Transform (XSLT) used to transform the raw XML data from the report query into the final HTML display format. When you choose/change the name dropdown list, clicking on the \"Create Default Template\" will populate this field with the default template used to render the data.
When you first create a new standard report section, we recommend using the option to \"Create Default Template\". This will then allow you to run the report in the main reports center and have all the available data fields displayed in the standard format. If you would like to customize the content of the section, you have several options:
Customize Header/Footer -- if you want to keep the data and layout as-is, you can simply add a custom header and footer to add organization specific information into the report.
Customize the Data/Layout -- if you want to customize how the data is displayed and formatted, you will need to edit the XSLT Template. You can learn more about XSLT at W3Schools. However, the recommended approach is to first run the \"Raw XML\" format report from the main SpiraPlan reports center. An example XML report is partially shown below:
\u201c?xml version=\"1.0\" encoding=\"UTF-8\" standalone=\"yes\"?\u201d\n\u201cReport\u201d\n \u201cTitle\u201d\n Requirements Detailed Report\n \u201c/Title\u201d\n \u201cProductData\u201d\n \u201cProduct\u201d\n \u201cProjectId\u201d1\u201d/ProjectId\u201d\n \u201cProjectGroupId\u201d2\u201d/ProjectGroupId\u201d\n \u201cName\u201dLibrary Information System\u201d/Name\u201d\n \u201cDescription\u201dSample application that allows users to manage books, authors and lending records for a typical branch library\u201d/Description\u201d\n \u201cWebsite\u201dwww.libraryinformationsystem.org\u201d/Website\u201d\n \u201cCreationDate\u201d2005-11-30T19:00:00\u201d/CreationDate\u201d\n \u201cActiveYn\u201dY\u201d/ActiveYn\u201d\n \u201cWorkingHours\u201d8\u201d/WorkingHours\u201d\n \u201cWorkingDays\u201d5\u201d/WorkingDays\u201d\n \u201cNonWorkingHours\u201d0\u201d/NonWorkingHours\u201d\n \u201cTimeTrackIncidentsYn\u201dY\u201d/TimeTrackIncidentsYn\u201d\n \u201cTimeTrackTasksYn\u201dY\u201d/TimeTrackTasksYn\u201d\n \u201cEffortIncidentsYn\u201dY\u201d/EffortIncidentsYn\u201d\n \u201cEffortTasksYn\u201dY\u201d/EffortTasksYn\u201d\n \u201cTasksAutoCreateYn\u201dY\u201d/TasksAutoCreateYn\u201d\n \u201cReqDefaultEffort\u201d480\u201d/ReqDefaultEffort\u201d\n \u201cTaskDefaultEffort\u201d360\u201d/TaskDefaultEffort\u201d\n \u201cProductGroupName\u201dInternal Products\u201d/ProductGroupName\u201d\n \u201c/Product\u201d\n \u201c/ProductData\u201d\n \u201cRequirementData\u201d\n \u201cRequirement\u201d\n \u201cRequirementId\u201d1\u201d/RequirementId\u201d\n \u201cProjectId\u201d1\u201d/ProjectId\u201d\n \u201cScopeLevelId\u201d3\u201d/ScopeLevelId\u201d\n \u201cAuthorId\u201d2\u201d/AuthorId\u201d\n \u201cName\u201dFunctional System Requirements\u201d/Name\u201d\n \u201cCreationDate\u201d2003-11-30T19:00:00\u201d/CreationDate\u201d\n \u201cLastUpdateDate\u201d2003-11-30T19:00:00\u201d/LastUpdateDate\u201d\n \u201cIndentLevel\u201dAAA\u201d/IndentLevel\u201d\n \u201cExpandedYn\u201dY\u201d/ExpandedYn\u201d\n \u201cVisibleYn\u201dY\u201d/VisibleYn\u201d\n \u201cSummaryYn\u201dY\u201d/SummaryYn\u201d\n \u201cAttachmentsYn\u201dN\u201d/AttachmentsYn\u201d\n \u201cCoverageCountTotal\u201d21\u201d/CoverageCountTotal\u201d\n \u201cCoverageCountPassed\u201d10\u201d/CoverageCountPassed\u201d\n \u201cCoverageCountFailed\u201d3\u201d/CoverageCountFailed\u201d\n \u201cCoverageCountCaution\u201d1\u201d/CoverageCountCaution\u201d\n \u201cCoverageCountBlocked\u201d1\u201d/CoverageCountBlocked\u201d\n \u201cPlannedEffort\u201d8700\u201d/PlannedEffort\u201d\n \u201cTaskEstimatedEffort\u201d11400\u201d/TaskEstimatedEffort\u201d\n \u201cTaskActualEffort\u201d7570\u201d/TaskActualEffort\u201d\n \u201cTaskProjectedEffort\u201d3855\u201d/TaskProjectedEffort\u201d\n \u201cTaskRemainingEffort\u201d11485\u201d/TaskRemainingEffort\u201d\n \u201cTaskCount\u201d42\u201d/TaskCount\u201d\n \u201cTaskPercentOnTime\u201d59\u201d/TaskPercentOnTime\u201d\n \u201cTaskPercentLateFinish\u201d6\u201d/TaskPercentLateFinish\u201d\n \u201cTaskPercentNotStart\u201d7\u201d/TaskPercentNotStart\u201d\n \u201cTaskPercentLateStart\u201d28\u201d/TaskPercentLateStart\u201d\n \u201cScopeLevelName\u201dIn Progress\u201d/ScopeLevelName\u201d\n \u201cAuthorName\u201dFred Bloggs\u201d/AuthorName\u201d\n \u201cHasDiscussionChanged\u201dfalse\u201d/HasDiscussionChanged\u201d\n \u201cIsDeleted\u201dfalse\u201d/IsDeleted\u201d\n \u201cCustomProperties\u201d\n \u201cCustomProperty\u201d\n \u201cAlias\u201dURL\u201d/Alias\u201d\n \u201cName\u201dCustom_01\u201d/Name\u201d\n \u201cType\u201dText\u201d/Type\u201d\n \u201c/CustomProperty\u201d\n \u201cCustomProperty\u201d\n \u201cAlias\u201dDifficulty\u201d/Alias\u201d\n \u201cName\u201dCustom_02\u201d/Name\u201d\n \u201cType\u201dList\u201d/Type\u201d\n \u201c/CustomProperty\u201d\n \u201cCustomProperty\u201d\n \u201cAlias\u201dRequirement Type\u201d/Alias\u201d\n \u201cName\u201dCustom_03\u201d/Name\u201d\n \u201cType\u201dList\u201d/Type\u201d\n \u201c/CustomProperty\u201d\n \u201cCustomProperty\u201d\n \u201cAlias\u201dNotes\u201d/Alias\u201d\n \u201cName\u201dCustom_04\u201d/Name\u201d\n \u201cType\u201dText\u201d/Type\u201d\n \u201c/CustomProperty\u201d\n \u201cCustomProperty\u201d\n \u201cAlias\u201dReview Date\u201d/Alias\u201d\n \u201cName\u201dCustom_05\u201d/Name\u201d\n \u201cType\u201dDate\u201d/Type\u201d\n \u201c/CustomProperty\u201d\n \u201cCustomProperty\u201d\n \u201cAlias\u201dDecimal\u201d/Alias\u201d\n \u201cName\u201dCustom_06\u201d/Name\u201d\n \u201cType\u201dDecimal\u201d/Type\u201d\n \u201c/CustomProperty\u201d\n \u201c/CustomProperties\u201d\n \u201cDiscussions /\u201d\n \u201cTestCases /\u201d\n \u201cTasks /\u201d\n \u201cAttachments /\u201d\n \u201cHistory\u201d\n \u201cHistoryChangeSetType\u201d\n \u201cChangeTypeId\u201d1\u201d/ChangeTypeId\u201d\n \u201cChangeTypeName\u201dModified\u201d/ChangeTypeName\u201d\n \u201c/HistoryChangeSetType\u201d\n \u201cHistoryChangeSetType\u201d\n \u201cChangeTypeId\u201d2\u201d/ChangeTypeId\u201d\n \u201cChangeTypeName\u201dDeleted\u201d/ChangeTypeName\u201d\n \u201c/HistoryChangeSetType\u201d\n \u201cHistoryChangeSetType\u201d\n \u201cChangeTypeId\u201d3\u201d/ChangeTypeId\u201d\n \u201cChangeTypeName\u201dAdded\u201d/ChangeTypeName\u201d\n \u201c/HistoryChangeSetType\u201d\n \u201cHistoryChangeSetType\u201d\n \u201cChangeTypeId\u201d4\u201d/ChangeTypeId\u201d\n \u201cChangeTypeName\u201dPurged\u201d/ChangeTypeName\u201d\n \u201c/HistoryChangeSetType\u201d\n \u201cHistoryChangeSetType\u201d\n \u201cChangeTypeId\u201d5\u201d/ChangeTypeId\u201d\n \u201cChangeTypeName\u201dRollback\u201d/ChangeTypeName\u201d\n \u201c/HistoryChangeSetType\u201d\n \u201cHistoryChangeSetType\u201d\n \u201cChangeTypeId\u201d6\u201d/ChangeTypeId\u201d\n \u201cChangeTypeName\u201dUndelete\u201d/ChangeTypeName\u201d\n \u201c/HistoryChangeSetType\u201d\n \u201cHistoryChangeSetType\u201d\n \u201cChangeTypeId\u201d7\u201d/ChangeTypeId\u201d\n \u201cChangeTypeName\u201dImported\u201d/ChangeTypeName\u201d\n \u201c/HistoryChangeSetType\u201d\n \u201cHistoryChangeSetType\u201d\n \u201cChangeTypeId\u201d8\u201d/ChangeTypeId\u201d\n \u201cChangeTypeName\u201dExported\u201d/ChangeTypeName\u201d\n \u201c/HistoryChangeSetType\u201d\n \u201c/History\u201d\n \u201cRequirements /\u201d\n \u201cIncidents /\u201d\n \u201cSourceCodeRevisions /\u201d\n \u201c/Requirement\u201d\n \u201c/RequirementData\u201d\n\u201c/Report\u201d\nThis XML data is then converted by the XSLT template into HTML format so that it can be included into the final generated report. An example fragment of the XSLT template looks like:
\u201c?xml version=\"1.0\" encoding=\"utf-8\"?\u201d\n\u201cxsl:stylesheet version=\"1.0\" xmlns:xsl=\"http://www.w3.org/1999/XSL/Transform\" xmlns:msxsl=\"urn:schemas-microsoft-com:xslt\" exclude-result-prefixes=\"msxsl\"\u201c\n \u201cxsl:template match=\"/RequirementData\"\u201c\n \u201cxsl:for-each select=\"Requirement\"\u201c\n \u201cdiv\u201d\n \u201cxsl:attribute name=\"style\"\u201c\n padding-left: \u201cxsl:value-of select=\"string-length(IndentLevel)*2\"/\u201dpx;\n \u201c/xsl:attribute\u201d\n \u201cxsl:if test=\"SummaryYn='Y'\"\u201c\n \u201cdiv class=\"Title2\"\u201c\n RQ:\u201dxsl:value-of select=\"RequirementId\"/\u201d - \u201cxsl:value-of select=\"Name\"/\u201d\n \u201c/div\u201d\n \u201cdiv class=\"Description\"\u201c\n \u201cxsl:value-of select=\"Description\" disable-output-escaping=\"yes\"/\u201d\n \u201c/div\u201d\n \u201cbr /\u201d\n \u201c/xsl:if\u201d\n \u201cxsl:if test=\"SummaryYn='N'\"\u201c\n \u201cxsl:attribute name=\"style\"\u201c\n padding-left: \u201cxsl:value-of select=\"string-length(IndentLevel)*2\"/\u201dpx;\n \u201c/xsl:attribute\u201d\n \u201cdiv class=\"Title3\"\u201c\n RQ:\u201dxsl:value-of select=\"RequirementId\"/\u201d - \u201cxsl:value-of select=\"Name\"/\u201d\n \u201c/div\u201d\n \u201cp\u201d\n \u201cxsl:value-of select=\"Description\" disable-output-escaping=\"yes\"/\u201d\n \u201c/p\u201d\n \u201c/xsl:if\u201d\n \u201c/div\u201d\n \u201c/xsl:for-each\u201d\n \u201c/xsl:template\u201d\nSo using a combination of XSLT and the Raw XML report format, you can generate a customized view of the standard report section that will be included in the final report.
Sometimes, however you want to be able to create a completely custom report that includes customized data as well as a custom format. In which case you need to use a custom report section instead.
b) Custom Section
Back on the main report details page, if you click on \"Add New Custom Section\", the following dialog box will be displayed:
On this page you can enter / change the following fields:
Name -- Enter the name of the new custom report section that you will be adding to the report. This is not displayed in the final report
Description -- This is the description of the custom section, it is not displayed in the final report.
Header -- This is the header that will be displayed before the dynamic data retrieved as part of the report section. You can enter in formatted rich text in this field.
Footer -- This is the footer that will be displayed after the dynamic data retrieved as part of the report section. You can enter in formatted rich text in this field.
Active -- You should make sure this checkbox is checked if you want the custom section to appear in the final report.
Further down on the page you can actually enter the custom query and associated XSLT template:
On this page you need to first choose the appropriate reportable entity from the dropdown list. In the example illustrated above, we have selected the \"Requirements\" reportable entity. This will automatically populate the following query in the Query editor:
select value R from SpiraTestEntities.R_Requirements as R where R.PROJECT_ID = ${ProjectId}
This query tells SpiraPlan to select all of the rows in the R_Requirements collection that are in the current product and include all of the columns in the final report. This generally will result in more columns than is desirable, so you should click on the \"Preview Results\" option to view a list of the various columns and the sample data. That will help you decide which columns are important for your report. You can then adjust the query to only include those columns:
select R.REQUIREMENT_ID, R.NAME from SpiraTestEntities.R_Requirements as R where R.PROJECT_ID = ${ProjectId}
In this modified query, we have replaced the keyword value with the specific column names. When you use the \"Preview Results\" option on this query, you will only see the two desired columns:
Once you have verified that the data being returned matches your requirements, click on the \"Create Default Template\" option and SpiraPlan will automatically generate a new XSLT template that displays just these columns in a nice table format:
You can now click the [Save] button to save your changes to the report.
You may have noticed that we had a special token in the query {ProjectId}**, this token will be evaluated during the generation of the report and ensures that only items in the current product are included. If you want to include all the items in a specific Program, you should instead use the token **. If you don't use either token, the report will include all the items in the entire system, across all products and groups.
For example:
select value R from SpiraTestEntities.R_Requirements as R where R.PROJECT_ID = ${ProjectId} will display all the requirements in the specific product
select value R from SpiraTestEntities.R_Requirements as R where R.PROJECT_GROUP_ID = ${ProjectGroupId} will display all the requirements in the specific program
select value R from SpiraTestEntities.R_Requirements as R will display all the requirements in the entire system
For more information on creating custom report queries, please refer to the knowledge base articles on the Inflectra customer support website: http://www.inflectra.com/Support.
Warning: If you create a report that doesn't have either ${ProjectId} or ${ProjectGroupId} in the WHERE clause you could end up displaying data to a user that shouldn't have permission to see that data.
"},{"location":"Spira-Administration-Guide/System-Reporting/#edit-graphs","title":"Edit Graphs","text":"The \"Edit Graphs\" administration page lets you create custom graphs and charts in the system that your users can run in the various products they have access to. Note that the graph definitions themselves are global to the system and therefore available in all products.
When you click on the 'Edit Graphs' menu option, the system will display a list of any existing custom graphs that have been already defined (it will not list the standard graphs that come with the system):
To add a new graph, click on the 'Add New Custom Graph' option in the bottom of the table:
This is the same screen you will see if you click on the Edit button for an existing graph. In addition, the graph list page has the following additional operations:
Clone -- this will make a copy of the graph with '- Copy' appended to the name
Delete -- this will permanently delete the selected custom graph.
On the graph editing page, you can enter the following fields:
Name -- This is the short name of the graph that will be displayed to users when they choose to display a custom graph.
Description -- This is the longer description of the graph, and should be used to explain what the data in the graph shows, what the purpose of the graph is and how the data should be interpreted. This is what the user will see when they click on the help link on the graph.
Active -- If you set this to \"No\", the graph will not be accessible by end users
Position -- use this to specify the relative position of the graph in the list of custom graphs.
Query -- this is where you enter the actual query used to generate the graph data. We shall discuss this below.
Entering the Query
We recommend that you first choose the appropriate reportable entity from the dropdown list. In the example illustrated above, we have selected the \"Test Runs\" reportable entity.
This will automatically populate the following query in the Query editor:
select value R from SpiraTestEntities.R_TestRuns as R where R.PROJECT_ID = ${ProjectId}
This query tells SpiraPlan to select all of the rows in the R_TestRuns collection that are in the current product and include all of the columns in the final report. You cannot graph non-numeric columns, so usually we'd recommend clicking Display Data Grid to see all of the columns that you can use in the graph:
This will help you decide which columns are important for your graph. You can then adjust the query to only include those columns:
select R.EXECUTION_STATUS_NAME, COUNT (R.TEST_RUN_ID) as COUNT
from SpiraTestEntities.R_TestRuns as R
where R.PROJECT_ID = ${ProjectId}
group by R.EXECUTION_STATUS_NAME
In this modified query, we have replaced the keyword value with the specific column names. We have also added an aggregation function called COUNT to count the number of test runs and group by the execution status name column. SpiraPlan uses a modified SQL language called Entity SQL. For more information on creating custom graph queries, please refer to the knowledge base articles on the Inflectra customer support website: http://www.inflectra.com/Support.
When you click Display Data Grid, you will now see:
The graphing module requires that the first column be the list of categories to display on the x-axis of the graph. It can be any format (text, numeric, dates, etc.). The remaining columns have to be numeric and will be used to display the different data ranges. The column name will be used to display the data range. For donut graphs, only one data range is supported, for line/bar charts, you can have multiple ranges.
You can see how the graph looks in the three different styles (donuts, bar, line):
a) Donut Graph
b) Bar Graph
c) Line Graph
Once you are happy with your custom graph, click the Save button to commit the changes. If the Active flag is set to \"Yes\" then the graph will be available for end users to use.
Warning: If you create a graph that doesn't have either ${ProjectId} or ${ProjectGroupId} in the WHERE clause you could end up displaying data to a user that shouldn't have permission to see that data.
"},{"location":"Spira-Administration-Guide/System-Users/","title":"System: Users","text":""},{"location":"Spira-Administration-Guide/System-Users/#view-edit-users","title":"View / Edit Users","text":"The following screen is displayed when you choose the \"View/Edit Users\" link from the Administration menu:
This screen displays the list of all approved users in the system (by default it only shows active users, but you can use the dropdown at the top to view inactive or all users). It shows the following fields:
You can filter the list using the filter row above. When you click the \"Filter\" button, the list of users will be filtered by the criteria you entered. You can clear the filter selection by clicking the \"Clear Filters\" button. To sort the list of users, click on the appropriate arrow icon located in the header row of each field (one each for ascending / descending). In addition, the list of users is paginated into groups of fifteen (15). You can step through the different pages by clicking the page numbers at the bottom of the user list.
Why can't I find a user?
The user list shows all approved users. So if you are looking for a user that you think should exist but they are not in this list, then they are not approved. Check the list of pending user requests to see if the user is there waiting to be approved.
"},{"location":"Spira-Administration-Guide/System-Users/#add-a-new-user","title":"Add a new user","text":"To add a new user to the system, click the \"Add\" button at the bottom of the user list, and a new screen will be displayed that allows you to enter the new user information:
On this screen, you can:
System administrators and product roles
Note: if a user is a System Administrator, that user will always have the 'Product Owner' role on all their assigned products, regardless of the chosen role. If they stop being a system admin, they will then revert back to their true role.
When creating a new user, you can also set their role for products. A user can be assigned a role to multiple products at once, by checking the required checkboxes in the dropdown list of products. The same role will be applied across all products.
Notifying Newly Created Users
The new user created as above will get an email with the subject \"New Spira Account\". The email contains the new user's assigned username and password, along with the login URL.
"},{"location":"Spira-Administration-Guide/System-Users/#edit-an-existing-user","title":"Edit an existing user","text":"In a similar way, to edit the details of an existing user, click the \"Edit\" hyperlink in the user list box, and you will be taken to the following screen that allows you modify the user details:
On this screen you can edit key information and security about the user:
If your Spira accounts are managed by an external LDAP directory server, you can edit a user's LDAP information on this page. In LDAP-Managed mode you enter the fully Distinguished Name (DN) for that user in your corporate LDAP server and provide no password. SpiraPlan\u00ae will then query your corporate LDAP server for the password information, reducing the number of passwords that a user needs to remember. Please see the sections on Importing LDAP Users and LDAP Configuration for more details.
If a user's account uses an external provider for authentication (like LDAP or Okta) you can unlink the user from that authentication provider on this page. Click the Unlink Account button to display a popup that requires you to add the new security information for that user.
Once you have made the necessary changes, click the \"Save\" button to commit them. If you decide that you want to ignore the changes, click the \"Cancel\" button and the changes will be discarded.
At the top of the page you can also see information relating to the activity of the user on the system, such as when they last logged in.
In addition, there are three tabs that allow you to: - add/remove the user from products - update the data-mapping used when synchronizing artifacts that are assigned or created by the current user - where relevant, specify whether the user can access the linked TaraVault\u2122 source code management service
If you click on the \"Product Membership\" tab you will be shown a list of products that the user is currently a member of:
You can change the role that the user has on the various products, by choosing the appropriate role from the drop-down list and then clicking [Save]. To remove the user from a product, select its checkbox and then click [Delete]. To add a user to a new product, click on the [Add] button and then choose the product and associated role from the list of products on the screen that is displayed:
Then click [Add] to add the selected product(s) to the user's product membership.
To view/change the list of usernames that a user has in an external bug-tracking system, click on the \"Data Mapping\" tab. This section is used by the SpiraPlan data-synchronization service to map incidents from SpiraPlan to other bug-tracking systems
Please see the SpiraPlan External Bug-Tracking Integration Guide for more details on using the data-mapping tab.
If you click on the TaraVault membership tab, you can choose whether or not the user has access the linked TaraVault source code repository. This service is only available for hosted/cloud instances of SpiraPlan, and more details can be found in LDAP Configuration.
"},{"location":"Spira-Administration-Guide/System-Users/#importing-ldap-users","title":"Importing LDAP Users","text":"If your organization already has an LDAP compatible user management system in place (e.g. Windows Active Directory, Novell eDirectory, OpenLDAP, IBM Tivoli, etc.), then instead of having to manually enter users one by one into SpiraPlan\u00ae, you can simply import them from your LDAP Server. Before doing this however, you need to first setup the LDAP Configuration.
Once you have setup your LDAP server configuration in SpiraPlan\u00ae, clicking on the \"Import Users From and LDAP Server\" will bring up the following screen:
This screen lists all the users available in the LDAP server that have not been already imported into SpiraPlan\u00ae. The users are listed by name along with their login, email address and fully distinguished LDAP name (DN). You can narrow down the list by entering partial name matches in any of the fields displayed and clicking [Filter] and/or you can sort the results by clicking on the directional arrows in the field headings.
Select the checkbox of any users you want to import and click \"Import\" to complete the operation. These users can now login to SpiraPlan\u00ae and use their existing LDAP login and password information.
"},{"location":"Spira-Administration-Guide/System-Users/#login-providers","title":"Login Providers","text":"You can connect your organization's identity provider for Single Sign On (SSO) authentication with Spira. This works for both on premise and cloud versions of the application. We currently support integration with:
On the Provider List page you can see a list of all available providers, their status (active or inactive), and how many, if any, users are logging in to the application using that provider. To configure a particular provide, click the \"Edit\" button for that row.
On the provider details page you can set a provider to active or inactive. Different providers have different required fields. For your provider, make sure to fill in the required fields with the specific information that the provider generates for you. Every provider needs at least a client id and client secret. For users to be able to login using the provider make sure to set the provider to active and hit Save. This will make sure that the right button shows up on the login screen.
Note that you can only deactivate a provider that does not have any users linked to it.
"},{"location":"Spira-Administration-Guide/System-Users/#how-to-set-up-a-provider-to-integrate-with-spira","title":"How to set up a provider to integrate with Spira","text":"Below is a general set of instructions about how to set up the provider and Spira to work together. However, the providers may have changed their process or documentation, so please consult the provider about configuring their system.
Create a new application / OAuth access with the provider
https://inflectra.spiraservice.netA guide to set up each provider, and the specific permissions they each need are available here:
Go back to Spira and enter the information for the required fields into the provider page and hit save.
Before rolling out the provider to your users be aware that the provider likely communicates to your Spira application over the internet so your users may not be able to log in to Spira if that provider service goes down. Because of this, the root admin is not able to connect to Spira using a provider in this way.
"},{"location":"Spira-Administration-Guide/System-Users/#active-sessions","title":"Active Sessions","text":"Sometimes a system administrator will want to know who is logged into the system right now, and how many total users are logged in. The 'Active User Sessions' page display a list of all the users who currently have active sessions in the system. Each user is displayed along with their user ID, whether they're connected through the application or via a third-party add-on, and the date they last logged-in.
Administrators can end a session that is in use to make it available for others. This is useful when you at your maximum number of concurrent sessions allowed by your license. This blocks anyone else from logging in - so if they really need to login, someone else has to logout. Clicking the \u2018End Session\u2019 button to the right of the user\u2019s name will end their session, making it available for another user.
Ending a session is not the same as logging out: ending a session does not fully logout the user - it only provides a window for someone to login. If no one logs in and that user keeps using the app, their session will be restarted.
If a user's session is replaced by another user: the first user will now be logged out. They will now be unable to access the system and any unsaved data will be lost.
"},{"location":"Spira-Administration-Guide/System-Users/#pending-requests","title":"Pending Requests","text":"If you have enabled the ability for users to register for new SpiraPlan accounts themselves, clicking on the \"Pending Requests\" administration option allows you to view a list of all the outstanding requests for new user accounts:
For each pending user request you can choose to either Approve or Deny the request:
Approve -- clicking this option will approve the user. They will get an email letting them know that they have been approved and can now log into the system.
Delete -- clicking this option will delete the pending user request from the system.
"},{"location":"Spira-Administration-Guide/System-Users/#view-edit-product-roles","title":"View / Edit Product Roles","text":"Read an overview of how permissions work across the application and all its workspaces.
"},{"location":"Spira-Administration-Guide/System-Users/#default-product-roles","title":"Default Product Roles","text":"There are six (6) default product roles that a user may be assigned to a product with:
The Special case of user administrator
The System Administrator (with a user id of 1) is automatically added to every product as a Product Owner, and can never be removed as Product Owner, made inactive or made a different role on the product.
"},{"location":"Spira-Administration-Guide/System-Users/#role-wide-customizations","title":"Role wide customizations","text":"You can make changes to the permissions associated with each of these default roles, and also create as many additional roles as you like. To customize the roles in your installation of SpiraPlan\u00ae, click on the \"View / Edit Roles\" link in the Administration menu:
The screen lists all of the roles currently configured in the system (both active and inactive) together with the name, description, and an active flag. You can create new roles by clicking the \"Add\" button which will create a new default role entry in the list. You can edit the name, description and associated permissions of a role by clicking on the appropriate \"Edit\" button. You can delete an existing role, by clicking the \"Delete\" button. Note that you cannot delete any of the default roles, but can instead make them inactive.
Clicking on the edit button will take you to the following screen:
On the top of the screen, you can edit the name, description, product admin, limited view and active flags:
Underneath the role wide customizations, you can specify the various artifact-specific permissions for the role:
These permission options allow you to specify if a user can view, create, delete, or modify (in three different ways) each type of artifact in the product:
Bulk Edit: lets users modify items outside of the scope of any workflow in a number of places. This means users can bypass workflow restrictions, allowing them to make status changes (including without electronic signatures) and not enter fields required by workflows. This permission should be applied carefully. Note that you can deny status changes in this with the \"Status bulk edit\" flag on the edit template page. Bulk edit works in the following places:
Note: The permission needed to execute a test case is the \"Create + Test Run\" permission since that initiates the creation of a new test run.
"},{"location":"Spira-Administration-Guide/System-Users/#cross-artifact-permissions","title":"Cross artifact permissions","text":"In addition, there are some permissions that can be specified for each role, that apply across all relevant artifacts:
This section lets you specify if the role allows users to add new documents to the product, edit existing documents, delete documents, edit the document folders, and view/edit source code commits.
"},{"location":"Spira-Administration-Guide/System-Users/#view-edit-teams","title":"View / Edit Teams","text":"In beta, available in SpiraPlan only
System admins can enable beta functionality across the application for their users from the System Admin > General Settings page.
SpiraPlan lets you define a list of Teams. These teams are created system wide, and product members can then be assigned any active team on a product by product basis. You can use these teams in different ways in different products, but the most common way is to group people together based on your organizational or functional structure.
This page lets you display the list of teams sorted alphabetically by name, based on three predefined filters:
Click the 'Add Team' button at the bottom of the list to add a new team:
After entering the name of the new team, optionally entering a description, and choosing its Active status (active by default), click 'Save' to commit the new item. To edit an existing team, change its name, description, or active status and click 'Save'. To delete a team, click the 'Delete' option for that row. Once deleted, an item can be undeleted by changing the display to 'All' and then clicking 'Undelete'.
Learn about how to manage team membership at the product level.
"},{"location":"Spira-Administration-Guide/System-Workspaces/","title":"System: Workspaces","text":"There are up to 3 levels of workspaces that you can use to organize all of your data within Spira. Products are where all your tests, requirements, and bugs live. These are grouped inside of Programs. In SpiraPlan you can group programs inside of Portfolios. Each of these workspaces is discussed below, as are Templates - a special type of workspace for controlling parts of how products and programs work.
All workspaces share certain ways of working: they all have a name and description, then can all be made active or inactive. An inactive workspace is completely inaccessible to any user.
The following screen is displayed when you choose the \"View/Edit Products\" link from the administration menu:
This screen displays the list of products in the system (both inactive and active) together with their program, template, date of creation, and active status. Clicking on either the \"View\" link in the right-hand column or the name of the product will change the currently selected product to one clicked.
By default the table shows you only the active products, but you can select a different option from the dropdown above the table. You can filter the list of products by either choosing an active status, program, or entering a portion of the name or date into the appropriate text box. When you click the \"Filter\" button, the list of products will be filtered by the criteria you entered. You can clear the filter selection by clicking the \"Clear Filters\" button. To sort the list of products, just click on the appropriate arrow icon located in the header row of each field (one each for ascending / descending) In addition, the list of products is paginated into groups of fifteen (15). You can step through the different pages by clicking the page numbers at the bottom of the product list.
To permanently delete a product, click the \"Delete\" button to the right of the product details. Doing so will show a popup where the admin will be required to correctly type the name of the selected product. Product deletion is irreversible and will delete all the artifacts associated with the product. If you want to temporarily delete a product, set its Active flag to 'No' instead. To make a copy of a product to reuse its test cases, releases, test sets and requirements, click the \"Copy\" link to the right of the product. NOTE: this will not make a copy of any historical information, test runs or incidents.
"},{"location":"Spira-Administration-Guide/System-Workspaces/#product-cloning","title":"Product cloning","text":"To clone a product, select a product and click the \"Clone\" button.
The popup dialog gives you the following options:
Whichever copy / clone option you choose, product settings (planning options and testing settings), components and product membership will all be copied over to the new product.
Full clone of the product: this option (the default) creates a new product that is effectively a clone of the original. The original product is not updated in any way. The new product will have copies of every artifact (including custom properties), along with all attachments, comments, and associations. This is very useful if you want to create an archived copy of a product, or want to split a product out into multiple products. Cloning creates the raw data but it does not also calculate test coverage or task progress for the new product. This final process can take a long time, and may not always be necessary. You can calculate this information at any time from the product admin Data Tools page, and after this coverage and traceability should look identical between the original and new product.
While we attempt to create as perfect a clone as possible using this method, there are some limitations to this process:
Reset copy of the product: this option creates a partial clone of the original product and then resets certain key fields. This provides a new product that can be used as a base for new work taking the original as a starting point.
All artifacts are cloned in the same way as the full clone option (e.g. comments and associations are copied) except for the following artifacts which are not copied over at all:
For those artifacts that are copied, the following fields are reset to be either blank or to their default value:
The same limitations listed above for a full clone also apply to this reset copy option.
Cloning the template: this will create a clone of the original product's template and make sure that the new cloned/copied product uses this cloned template. This can be really useful if you want to create a new independent product and template compared to the original.
"},{"location":"Spira-Administration-Guide/System-Workspaces/#add-a-new-product","title":"Add a new product","text":"To add a new product to the system, click the \"Add\" button at the bottom of the product list, and a new screen will be displayed that allows you to enter the new product information:
You need to:
Once you are satisfied with the information, click the \"Insert\" button to actually create the new product.
"},{"location":"Spira-Administration-Guide/System-Workspaces/#edit-a-product","title":"Edit a product","text":"In a similar way, to edit the details of an existing product, click the \"Edit\" button in the right hand column of the product list box, and you will be taken to the following screen that allows you modify the product details:
On this screen you can:
Once you have made the necessary changes, click the \"Save\" button to commit them. If you decide that you want to ignore the changes, click the \"Cancel\" button and the changes will be discarded.
What happens when you make a product inactive
If you set a product's active flag to \"No\" then it will be hidden from the global navigation for all users. This is the recommended alternative to deleting a product (because deletion is permanent).
"},{"location":"Spira-Administration-Guide/System-Workspaces/#viewedit-programs","title":"View/Edit Programs","text":"The following screen is displayed when you choose the \"View/Edit Programs\" link from the Administration menu:
This screen displays the list of programs in the system (both inactive and active) together with their portfolio (SpiraPlan only), template, web site URL, date of creation and active status. Programs are used to relate products that are in the same department/division/organization or are for a common customer, client, etc. When products are in the same program, a user that is a member of the program can see the special Program Dashboard that displays key metrics from all the products in the program combined. Also, such users will have observer-level access to the contained products without needing to be explicitly added to each product.
You can filter the list of programs by either choosing an active status, or entering a portion of the name, web-site or date into the appropriate text box. When you click the \"Filter\" button, the list of programs will be filtered by the criteria you entered. You can clear the filter selection by clicking the \"Clear Filters\" button. To sort the list of programs, just click on the appropriate arrow icon located in the header row of each field (one each for ascending / descending) In addition, the list of programs is paginated into groups of fifteen (15). You can step through the different pages by clicking the page numbers at the bottom of the list.
To permanently delete a program, you should click the \"Delete\" button to the right of the program details. Any products contained in the program will not be deleted, but instead just moved to the default program. There has to be at least one program in the system at all times, so the program designated as the 'default' one will not be available for deletion.
"},{"location":"Spira-Administration-Guide/System-Workspaces/#add-a-new-program","title":"Add a new program","text":"To add a new program to the system, click the \"Add\" button at the bottom of the program list, and a new screen will be displayed that allows you to enter the new program information:
You need to enter:
Once you are satisfied with the information, click the \"Insert\" button to actually create the new program.
"},{"location":"Spira-Administration-Guide/System-Workspaces/#edit-a-program","title":"Edit a program","text":"In a similar way, to edit the details of an existing program, click the \"Edit\" button in the right-hand column of the program list box, and you will be taken to the following screen that allows you modify the program details. Please note that this is the only administrative page in the program administration section.
On the top part of this screen you can edit the name, description, website URL, portfolio (SpiraPlan only), active flag and default flag. Once you have made the necessary changes, click the \"Save\" button to commit them. If you decide that you want to ignore the changes, click the \"Cancel\" button and the changes will be discarded.
What happens when you make a program inactive
If you set a programs's active flag to \"No\" then it will be hidden from the global navigation for all users. All products in that program will also be hidden from the global navigation for all users.
In addition, the lower part of the screen allows you to view/edit the users that are members of the program and also see which products are in the program:
"},{"location":"Spira-Administration-Guide/System-Workspaces/#program-user-membership","title":"Program User Membership","text":"This tab allows you to see which users are members of the program and which program role they have:
The two program roles are \"Executive\" and \"Program Owner\":
Executive -- This role allows the user to see this program's homepage, which contains all the key metrics for the contained products displayed in an aggregated manner. In addition, the user is automatically granted 'observer' permissions for all the products in the program.
Program Owner -- This role consists of all the permissions granted to the \"Executive\" role above, but in addition allows the user to make changes to the Program itself in the Administration section.
To change the role of an existing program member, just change the role in the drop-down list and click [Save]. To remove a member from the program, just select the appropriate checkboxes and click [Delete]. Finally, to add a new user to the program, click on the [Add] button:
You now should narrow down the list of users by entering filter criteria and clicking [Filter]. Once you have located the appropriate user(s), just select a program role for them from the drop-down list and click [Add] to add them to the program in the specified role.
"},{"location":"Spira-Administration-Guide/System-Workspaces/#program-product-list","title":"Program Product List","text":"This tab allows you to see the list of products that are contained within the current program. Clicking on the name of the product will take you to the details page for that product:
"},{"location":"Spira-Administration-Guide/System-Workspaces/#viewedit-portfolios","title":"View/Edit Portfolios","text":"Please note that portfolios are only available in SpiraPlan
The following screen is displayed when you choose the \"View/Edit Portfolios\" link from the Administration menu:
This screen displays the list of portfolios in the system (both inactive and active) together with their description, ID, and active status. Portfolios are used to relate programs together.
You can filter the list of portfolios by either choosing an active status, or entering a portion of the name. When you click the \"Filter\" button, the list of portfolios will be filtered by the criteria you entered. You can clear the filter selection by clicking the \"Clear Filters\" button. To sort the list of portfolios, click on the appropriate arrow icon located in the header row of each field (one each for ascending / descending) In addition, the list of portfolios is paginated into groups of fifteen (15). You can step through the different pages by clicking the page numbers at the bottom of the list.
To permanently delete a portfolio, click the \"Delete\" button to the right of the portfolio details. No programs (or their products) in the portfolio will be deleted - the programs' portfolios will instead be reset to \"none\".
"},{"location":"Spira-Administration-Guide/System-Workspaces/#add-a-new-portfolio","title":"Add a new portfolio","text":"To add a new portfolio to the system, click the \"Add\" button at the bottom of the portfolio list, and a new screen will be displayed that allows you to enter the new portfolio information:
You need to enter:
Once you are satisfied with the information, click the \"Insert\" button to actually create the new portfolio.
"},{"location":"Spira-Administration-Guide/System-Workspaces/#edit-a-portfolio","title":"Edit a portfolio","text":"In a similar way, to edit the details of an existing portfolio, click the \"Edit\" button in the right-hand column of the portfolio list box, and you will be taken to the following screen that allows you modify the portfolio details.
On the top part of this screen you can edit the name, description, and active flag. Once you have made the necessary changes, click the \"Save\" button to commit them. If you decide that you want to ignore the changes, click the \"Cancel\" button and the changes will be discarded.
At the bottom of the screen you can see all the programs that belong to this portfolio.
What happens when you make a portfolio inactive
If you set a portfolio's active flag to \"No\" then it will be hidden from the global navigation for all users. Any programs in the portfolio and all products in those programs will also be hidden from the global navigation for all users.
"},{"location":"Spira-Administration-Guide/System-Workspaces/#viewedit-templates","title":"View/Edit Templates","text":"The following screen is displayed when you choose the \"View/Edit Templates\" link from the administration menu:
This screen displays the list of templates in the system (both inactive and active) with their active status.
You can filter the list of products by either choosing an active status, ID, or entering a portion of the name into the appropriate text box. When you click the \"Filter\" button, the list of templates will be filtered by the criteria you entered. You can clear the filter selection by clicking the \"Clear Filter\" button. To sort the list of templates, click on the appropriate arrow icon located in the header row of each field (one each for ascending / descending).
To permanently delete a template, click the \"Delete\" button to the right of the template details. This is irreversible. If you want to temporarily delete a template, set its Active flag to 'No' instead. Neither of these actions will be possible if any product (active or inactive) is controlled by the template.
To add a new template to the system, you need to create a new template when creating a new product (as described in View/Edit Products). To edit the details of an existing template, click the \"Edit\" button in the right hand column of the template list box, and you will be taken to the following screen that allows you modify the template details:
On this screen you can edit the template's:
Once you have made the necessary changes, click the \"Save\" button to commit them. If you decide that you want to ignore the changes, click the \"Cancel\" button and the changes will be discarded.
"},{"location":"Spira-Administration-Guide/System-Workspaces/#included-templates","title":"Included Templates","text":"SpiraPlan ships with four different templates. Together these will cover most of your needs. You can easily clone and customize one of these templates to meet your exact needs. Or you can start from scratch. Below is a brief description of each of the includes templates:
Info
This page is accessible under the Workspace subsection of the system admin menu. It is visible when you first get a new application. But as soon as the application gets updated to a new version, the page is no longer accessible and you will not see the entry in the admin menu.
The application includes different types of sample data, some about specific industries, to help you understand how the application works. For example, how products fit inside a program, or how different artifacts work together. There are six sample data sets available in the application. A system administrator can change which of these are available at any one time. The admin can make all available, none available, or anywhere in between.
When you load this page the sample data sets currently active will have the checkbox next to them checked. By default the \"Basic Samples\" are the only ones enabled. To change which sample data sets are active, check the relevant checkboxes and click save.
Please note that for users to be able to see these samples they can either login with a user who is already a member of the data or they can be added as a member by a system admin. The users with username \"administrator\" and \"fredbloggs\" have access to all of the sample data by default.
"},{"location":"Spira-Administration-Guide/System-Workspaces/#delete-sample-data","title":"Delete Sample Data","text":"If you click the \"Delete\" button, a popup will show a warning. If you decide to proceed the system will attempt to delete all sample data, including users, products, artifact information, programs, and portfolios. This method will not delete:
Tip
If you do not want users to see the sample data but do not want to permanently delete that data:
These inactive items will still be visible on the relevant administration pages, but no one will see them in the main application.
"},{"location":"Spira-Administration-Guide/System/","title":"System","text":""},{"location":"Spira-Administration-Guide/System/#general-settings","title":"General Settings","text":"The general settings page allows you to configure SpiraPlan\u00ae to better match your environment and setup. In the current version, you can specify the default language, or configure the folder used to store document attachments:
The available settings include:
C:\\Program Files\\SpiraPlan\\Attachments folder located inside the main SpiraPlan\u00ae installation root. However you may want to have the documents stored on a remotely mounted drive or on a different hard disk partition. In which case you can simply change the folder pointed to in the text-box illustrated above and then click [Update] to commit the change.The below toggle is only available in cloud hosted versions of SpiraTeam and SpiraPlan.
Not exclusively using TaraVault
If you set/leave the \"Use TaraVault for source code\" toggle discussed above to Yes, then you will only have access to the TaraVault admin pages at both the system and product level administration.
If you set the \"Use TaraVault for source code\" toggle to No, the administration menu will work a little differently for you. The system admin menu will always show two links for source code management in the Integration sub-section. This allows to easily access and configure TaraVault and any third party providers at any time. Meanwhile, the product admin menu will adapt to how you have setup source code for that particular product:
The \"File Types List\" administration page allows you to view all the different filetypes that are recognized by SpiraPlan and add or edit the associated icon, name, description and MIME type:
If you click on the \"Edit\" button next to a filetype, or click on the \"Add\" button at the bottom of the screen, the system will display the page that lets you add or edit a filetype entry:
On this page you can enter/edit the file extension that's used to recognize the type of file uploaded, the description of the file type (displayed in popup tooltips), the MIME type (used to determine how the browser handles the file type) and the path to the icon image. Once you are satisfied with the values, you can click on the \"Save\" button to confirm the changes.
"},{"location":"Spira-Administration-Guide/System/#license-details","title":"License Details","text":"Info
This page is accessible under the System subsection of the sytem admin menu. It is only visible if you have Spira installed on premise.
The license details page displays the information about the installed license for the particular instance of SpiraPlan\u00ae being used. This will display less information for hosted customers. The information displayed for self-hosted customers includes: the product name (e.g. SpiraPlan), the license version (e.g. v6.0.0.0), type of license in effect (x-user fixed, x-user concurrent, demonstration, enterprise, etc.), the expiration date (if any) of the license, the organization that the license belongs to, and the number of users concurrently logged-in right now. This last piece of information is useful as it helps administrators track down how many licenses are currently in use.
A sample page is illustrated below:
To change the license key used by the system (for example, if to upgrade from Trial edition to Standard edition), you do not need to reinstall SpiraPlan\u00ae. All you need to do is change the organization and license key text-boxes to match the license key and organization name found in the customer area of our website (http://www.inflectra.com/CustomerArea) and click the \"Save\" button.
If there is an issue with the license key (e.g. a trial version that is passed its expiration date, or where the license key doesn't match the organization name) an error will be displayed describing the specific issue with the information you entered. If you are unable to get the system to work with the license key information, please contact Inflectra\u00ae customer support at: support@inflectra.com.
"},{"location":"Spira-Administration-Guide/System/#ldap-configuration","title":"LDAP Configuration","text":"As described previously, you can configure SpiraPlan\u00ae to use an external LDAP server for importing new user profiles into the system, and for authenticating users -- instead of having to store separate passwords inside SpiraPlan\u00ae. However, you need to first configure the LDAP server settings. To do this, click on the \"LDAP Configuration\" link the Administration navigation:
You need to fill out the various configuration settings for your LDAP server, each of which is explained in more detail below:
The \"Security Settings\" administration page lets you specify the various security settings within SpiraPlan to match your organization's policies and processes:
The following settings can be changed within the system, once you are satisfied, click the \"Save\" button to commit the changes:
2-Step Authentication tips
This section refers to the functionality available to hosted/cloud customers of SpiraPlan. If you are using the on-premise version of SpiraPlan, please refer to Version Control Integration instead.
TaraVault\u00ae is the hosted source code repository and software configuration management (SCM) system provided by Inflectra. When you signed-up or purchased a subscription to either SpiraPlan or SpiraTeam, it will have come with an entry-level subscription to TaraVault.
When you first click on the Administration > TaraVault administration page, you will see the following screen:
This lets you know that you have not yet activated your TaraVault account with Inflectra. When you click on the [Activate TaraVault] button you will see the following:
This will let you see how many TaraVault SCM users your subscription allows and also the name of the TaraVault instance that your SpiraPlan instance is associated with.
Each product in SpiraPlan has its own corresponding TaraVault product, and each TaraVault product can be configured to use one of the two different SCM providers:
Subversion (SVN) -- This is a simple, centralized version control system (VCS) that works best for teams that want to have a centralized SCM environment with only one central instance of the SCM repository. Subversion only allows a single branch to be managed and is generally easier to understand conceptually.
Git -- This is a more powerful, distributed version control system (DVCS) that works best for teams that want to have multiple distributed instances of their source code repository. Git offers superior merging and branching functionality to Subversion but is generally more complicated to understand conceptually.
For the current SpiraPlan product you can choose the type of provider you wish to use, enter the name of the TaraVault product and click Activate:
Since you cannot change the type or name of the TaraVault product once activated, please review your entries and click [OK] to confirm the new product activation.
Once the product activation has been completed, the screen will display the following:
The screen will display the name of the linked TaraVault product as well as the list of TaraVault SCM users that are configured to use this TaraVault product -- this list will not necessarily be all of the users in the SpiraPlan product, just those that need to connect to TaraVault to commit source code into the repository.
If you want to deactivate this TaraVault product, click the [Deactivate] button and the product will be removed from TaraVault.
To improve performance, SpiraPlan will cache some of the data it receives from TaraVault. Normally SpiraPlan will know when to update the cached data based on changes made in TaraVault automatically. However sometimes you may wish to flush the cached data completed, to do this, click on the [Clear Cache] button.
To add new SCM users to the TaraVault product, click on the 'Add Users' link to add new SCM users to the product.
"},{"location":"Spira-Administration-Guide/System/#event-log","title":"Event Log","text":"The \"System Event Log\" administration page lets you view all of the errors, warning and other diagnostic messages that have been logged in the system:
Each event entry is displayed along with the date-time it occurred, the type of event (error, warning, information, success audit, failure audit), category (application, source code provider, data-synchronization) and the short name. To view the full message, click on the \"View Item\" hyperlink:
The popup dialog box will display the full error message log and stack trace in a moveable dialog box. This information should be provided to Inflectra customer support if you log a help desk ticket.
"},{"location":"Spira-Administration-Guide/System/#email-configuration","title":"Email Configuration","text":"The Email Configuration page is split into two sections. The first section covers email notification details, and the second section configures how email from the application is sent.
To use the internal IIS's default virtual SMTP server, leave all fields blank. The virtual server must then be configured to use proper SMTP server and network configuration. If you want the application to contact an SMTP server directly, use the following fields:
Example settings for connecting to Gmail/Google Mail for sending notifications:
The SpiraApps page shows system administrators every SpiraApp currently installed, sorted alphabetically1.
For each SpiraApp in the list you see:
Available operations
The SpiraApp Settings page shows any system wide settings available for the particular SpiraApp. For more detailed information about each SpiraApp, what they do, and how to work with them refer to the dedicated SpiraApp documentation
If the SpiraApp has no settings you can still access the page but there will be no settings to edit.
If the SpiraApp has system level settings you will see:
Within each group a list of available settings:
Click the \"Save\" button to commit any edits.
"},{"location":"Spira-Administration-Guide/System/#system-history-changes","title":"System History Changes","text":"This page displays a list of relevant changes made to system level artifacts. Currently, only changes to product custom properties are recorded.
The system history list page shows system administrators all the currently recorded changes made at the system level. By default, items are shown in chronological order with the most recent at the top. The list can be filtered. Each history entry shows:
Change Type: what sort of change was made:
Workspace: the workspace type of that artifact (product, program, portfolio, or system)
The system history details screen will show basic information as well as fields that were changed in this change set.
The top part of the page shows relevant properties: change date, changed by, change type, workspace, artifact type, artifact (name).
Below this, the change actions are shown. This shows one row for each field that was changed in this change set. It shows:
SpiraApps are shown even if they will not fully function in your application. For instance, the FMEA SpiraApp is only compatible with SpiraPlan but will still show in the list if you are using SpiraTest or SpiraTeam.\u00a0\u21a9
SpiraPlan allows you to customize many of its artifacts1 by adding user-defined custom properties in addition to the built-in fields. Custom properties show in the application in the following places.
You can create a variety of different types of custom properties. You can create as many custom lists as you need with each having as many values as you need. Custom lists are not artifact specific, but can be used by any artifact. This section describes how to setup different custom lists and custom properties in your templates.
"},{"location":"Spira-Administration-Guide/Template-Custom-Properties/#edit-custom-properties","title":"Edit Custom Properties","text":"To access an artifact's custom properties, open the template admin menu and click the relevant link (artifacts with their own sub-sections in the menu list \"Custom Properties\" in that sub-section, all other artifacts are listed under the \"Custom Properties\" sub-section). This opens the custom property page for that artifact where you can quickly see the name, field number, type, legacy name, and actions (edit and delete) for each custom property.
In the example below we are looking at the requirements custom property page, which currently has 7 custom properties defined. The custom properties page has rows for available custom properties for that artifact type in the current template.
Artifacts in SpiraPlan can have up to 99 different custom properties per artifact-type, per template.
To edit an existing custom property definition click the \"Edit Definition\" button for that specific property. To add a new definition click the \"Add Definition\" button. In either case the following dialog will be displayed:
For each custom property you set the following fields on the main definition tab:
Different types of custom properties supported:
Each custom property can have optional settings applied to it to further control the custom property. Note: not all settings are available for all property types. These settings are on the Options tab of the dialog:
Note
Setting 'Allow Empty' to No will override any workflow step definitions, and will always require a value to be entered in, even if the workflow is configured to have the field disabled!
When finished, click the Save button.
Renaming or Removing Custom Properties
When changing a custom property's type or removing a custom property, the data is not actually removed from the artifact. Therefore, if you change a custom property from a date type to a text custom property, the field may display the old date value until it is changed by the user.
"},{"location":"Spira-Administration-Guide/Template-Custom-Properties/#edit-custom-lists","title":"Edit Custom Lists","text":"If you are planning on having any list based custom properties in your template, then you first need to create and populate the custom template lists that the user will be able to select from. These lists are stored separately from the individual artifact types so that you can have one set of values (e.g. list of operating systems under test) be reused by multiple artifact types.
The following screen is displayed when you choose the \"Custom Lists\" link from the Administration menu:
The screen displays all the custom lists currently defined within the template, together with the number of values associated with each list. By default the screen will initially be empty so the first thing you need to do is click \"Add List\" to create a new custom list:
After changing the name of the list, and specifying whether the values will be ordered by their name or the order in which they were entered (called by ID), you can either click \"Save\" to commit the change, or click the \"Add Value\" option to add some list values:
This is the set of values that the user will select from the drop-down list when the custom property is displayed. You can change the display to include:
To add a new custom list value, click the \"Add Value\" button and a new row will be added to the list which you can now edit. To edit an existing custom list value, change the name in the textbox and click \"Save\". To delete a custom list value, click on the \"Delete\" hyperlink. If you want to remove an item from the list temporarily, you can set its Active dropdown list to 'No', if you want to remove an item permanently, just click the 'Delete' button.
To edit an existing custom list, you just need to click on the \"Edit Values\" button to display the custom list name and list of associated values (which is the same screen as the one displayed for a new list). To remove a custom list from the template, just click on the \"Remove\" button next to the custom list and the list and all its associated values will be deleted from the template.
Recovering deleted list values
Even if you delete a custom list value, there is an option to undelete by simply changing the display selection to \"All\" and clicking the 'Undelete' hyperlink next to a deleted value.
the following artifacts support custom properties: requirements, releases, documents, test cases, test steps, test sets, test runs, automation hosts, incidents, tasks, risks.\u00a0\u21a9
SpiraPlan\u00ae includes a built-in web-based document management system that allows you to upload and share documents between product team members. These documents are stored in folders, categorized by a series of user-defined meta-tags and can also be associated with other artifacts in the system (e.g. requirements, incidents, etc.).
The set of administrative options located under the \"Documents\" heading allow the Template Owner to configure how the documents are organized in their particular template.
"},{"location":"Spira-Administration-Guide/Template-Documents/#document-types","title":"Document Types","text":"When users upload documents into a SpiraPlan product, they are required to specify the type of document that is being uploaded. The list of document types is configurable by the Template Owner for each individual template.
When you click on Documents \"Types\", you can edit the list of types available:
By default, each template will be created with a single document type called 'Default'. You can add additional document types and/or change the name of the ones already created. If you decide that you no longer want to use a specific document type, you can set its active flag to \"No\".
The only requirement is that each template needs to have at least one active document type available, and that there is one active type designated as the default type. The default type is the option that will be initially selected when a user uploads a file / URL to the template's product(s).
"},{"location":"Spira-Administration-Guide/Template-Documents/#document-statuses","title":"Document Statuses","text":"The following screen is displayed when you choose the \"Statuses\" link from the Documents section of the administration menu:
The screen displays a list of all the defined document statuses for the current template. By default, the screen will be populated with the standard SpiraPlan\u00ae document statuses. To edit an existing document status, change the name, open check-box, set it as the default status and/or change the active flag then click \"Save\".
You can't delete an existing document status, but to prevent it appearing in any drop-down-lists, change its active flag to \"No\" and click \"Save\". To add a new document status, click the \"Add\" button and a new row will be added to the list which you can now edit.
The open check-box allow you to specify if the document status should be considered open or not, which means it is would be eligible for display in the various sections of the user's home page and the product home page that list open document. The default radio button allows you to specify which document status should be the default for newly created documents. This is the status that a new document will be set to when first created, and acts as the first step in the document workflow. Note that you must have at least one active incident status, and you cannot set a document status as the default.
"},{"location":"Spira-Administration-Guide/Template-Documents/#document-workflows","title":"Document Workflows","text":"Clicking on the \"Workflows\" link in the Administration menu Documents section brings up the list of defined document workflows for the current template. A workflow is a predefined sequence of document statuses linked together by \"workflow transitions\" to enable a newly created document to be reviewed, prioritized, assigned, resolved and closed, as well as to checking documents in and out of the system. The workflow list screen for a sample template is illustrated below:
To modify the name, default status, notify and/or active flags, change the values in the appropriate text-box, radio-button, check-box or drop-down list and click the \"Save\" button. To add a new workflow, click the \"Add\" button and a new workflow will be created with the standard SpiraPlan\u00ae steps and transitions.
You can have as many document workflows as you like in a template, but only one can be marked as the default. Each document type is assigned to a workflow; this allows you to have different document types follow different paths from creation of closure. However, when a new document type is created, it will be initially associated with the template's default workflow.
Note: You can only assign an active workflow to a document type, and similarly you cannot make a workflow inactive that is currently linked to a document type. This is important as all document types need to be linked to an active workflow at all times.
"},{"location":"Spira-Administration-Guide/Template-Documents/#workflow-details","title":"Workflow Details","text":"Clicking on the \"Steps\" button of a workflow brings up the following screen that lists all the workflow steps and workflow transitions that comprise the workflow:
This page lists in the left-most column all the various document statuses defined for the template. The next column lists all the possible transitions that can occur from that status. In addition, to the right of each transition is the name of the resulting destination status that the transition leads to. E.g. from the Under Review status, depending on your role (see later) you can move the document to either Approved, Rejected or Draft depending on which transition the user takes.
Clicking on the name of a step or transition takes you to the appropriate details page (see below) where you can set the properties of the step or transition respectively. To delete an existing transition, click the \"x\" button after the transition name, and to add a new transition, click the \"Add Transition\" button in the Operations column.
"},{"location":"Spira-Administration-Guide/Template-Documents/#edit-workflow-transition","title":"Edit Workflow Transition","text":"When you click on the transition name link from the previous screen, you are taken to the workflow transition details screen:
The top part of the screen is the \"workflow browser\" which illustrates how the transition relates to the workflow as a whole. It displays the current transition in the middle, with the originating and destination steps listed to either side. Clicking on either document status name will take you to the appropriate workflow step details page. This allows you to click through the whole workflow from start to finish without having to return to the workflow details page.
If a digital signature from the user is required to authorize and record the transition, set the toggle to yes for \"Require Electronic Signature\".
Each transition has a series of conditions which need to be satisfied for a user to actually execute the transition (i.e. move the document from the originating status to the destination status).
"},{"location":"Spira-Administration-Guide/Template-Documents/#edit-workflow-step","title":"Edit Workflow Step","text":"When you click on the document status name link from either of the previous screens, you are taken to the workflow step details screen:
The top part of the screen is the \"workflow browser\" which illustrates how the step relates to the workflow as a whole. It displays the current document status in the middle, with the possible originating and destination transitions listed to either side. Clicking on either workflow transition name will take you to the appropriate workflow transition details page. This allows you to click through the whole workflow from start to finish without having to return to the workflow details page.
This page allows you to define the behavior of the various document fields (i.e. those that are a standard part of SpiraPlan\u00ae such as Type):
This page also allows you to define the behavior of the various document custom properties for this particular step in the workflow:
You can set each of the fields/custom properties as being:
After you have made the desired changes, click \"Save\".
Note that the \"Versions\" field has a special meaning. It related to the Versions tab on the Document details page. When hidden, users are not able to see any version information (the whole tab is hidden). When disabled, users cannot upload a new version. When required, a new version must have been recently uploaded by the current user for the document to be saved, and no changes made to the document between the version being uploaded and now.
"},{"location":"Spira-Administration-Guide/Template-Documents/#example-workflow","title":"Example Workflow","text":"Below is a diagram that shows an example workflow (the one used by the sample product \"Library Information System\") for documents.
"},{"location":"Spira-Administration-Guide/Template-Home/","title":"Template: Home Page","text":"The Template Administration Home page is accessible to users whose product role includes template admin permission. It provides template administrators with quick access to important information. There are multiple ways to navigate to it:
This widget shows a list of its owners. Click the Edit link to go to the template editing page. From here you can edit a number of properties about the template, including its name.
"},{"location":"Spira-Administration-Guide/Template-Home/#product-list","title":"Product List","text":"This widget shows a list of the products which use this template.
"},{"location":"Spira-Administration-Guide/Template-Home/#links","title":"Links","text":"This widget provides an alternate way to access the template-specific configuration pages.
"},{"location":"Spira-Administration-Guide/Template-Incidents/","title":"Template: Incidents","text":"In addition to being able to create custom properties and values for incidents (same as for all artifacts in SpiraPlan\u00ae), you can also change the values populated in many of the standard fields used in the incident tracker -- types, statuses, priorities and severities. The process for changing each of these is described below:
"},{"location":"Spira-Administration-Guide/Template-Incidents/#edit-types","title":"Edit Types","text":"The following screen is displayed when you choose the \"Types\" link from the Incidents section of the administration menu:
The screen displays a list of all the defined incident types for the current template. By default the screen will be populated with the standard SpiraPlan\u00ae incident types. To edit an existing incident type, change the name, associated workflow, issue check-box, risk check-box, set a default type and/or change the active flag then click \"Save\".
You can't delete an existing incident type, but to prevent it appearing in any drop-down-lists, all you need to do is change its active flag to \"No\" and click \"Save\". To add a new incident type, click the \"Add\" button and a new row will be added to the list which you can now edit.
The associated workflow drop-down list allows you to specify which workflow the incident type will follow. This is a very powerful feature since it allows you to configure different workflows for different incident types; i.e. a bug may follow a workflow geared to identification and resolution, whereas a risk may only need a much simpler set of steps and actions.
The issue check-boxes allow you to specify if the incident type is an issue, which means it would be eligible for display in the issue section of the product home page. The default radio button allows you to specify which incident type should be the default for newly created incidents. This is the type that a new incident will be set to unless changed by the creator of the incident. Note that you must have at least one active incident type, and you cannot set an inactive type as the default.
"},{"location":"Spira-Administration-Guide/Template-Incidents/#edit-statuses","title":"Edit Statuses","text":"The following screen is displayed when you choose the \"Statuses\" link from the Incidents section of the administration menu:
The screen displays a list of all the defined incident statuses for the current template. By default, the screen will be populated with the standard SpiraPlan\u00ae incident statuses. To edit an existing incident status, change the name, open check-box, set it as the default status and/or change the active flag then click \"Save\".
You can't delete an existing incident status, but to prevent it appearing in any drop-down-lists, all you need to do is change its active flag to \"No\" and click \"Save\". To add a new incident status, click the \"Add\" button and a new row will be added to the list which you can now edit.
The open check-box allow you to specify if the incident status should be considered open or not, which means it is would be eligible for display in the various sections of the user's home page and the product home page that list open incidents. The default radio button allows you to specify which incident status should be the default for newly created incidents. This is the status that a new incident will be set to when first created, and acts as the first step in the incident workflow. Note that you must have at least one active incident status, and you cannot set an inactive status as the default.
"},{"location":"Spira-Administration-Guide/Template-Incidents/#priorities","title":"Priorities","text":"The following screen is displayed when you choose the \"Priorities\" link from the Incidents section of the administration menu:
The screen displays a list of all the defined incident priorities for the current template. By default, the screen will be populated with the standard SpiraPlan\u00ae incident priorities. To edit an existing incident priority, change the name, color and/or change the active flag then click \"Save\". Note that you can either enter the hexadecimal RRGGBB code for the color or use the pop-up color picker.
You can't delete an existing incident priority, but to prevent it appearing in any drop-down-lists, all you need to do is change its active flag to \"No\" and click \"Save\". To add a new incident priority, click the \"Add\" button and a new row will be added to the list which you can now edit.
"},{"location":"Spira-Administration-Guide/Template-Incidents/#severities","title":"Severities","text":"The following screen is displayed when you choose the \"Severities\" link from the Incidents section of the administration menu:
The screen displays a list of all the defined incident severities for the current template. By default, the screen will be populated with the standard SpiraPlan\u00ae incident severities. To edit an existing incident severity, change the name, color and/or change the active flag then click \"Save\". Note that you can either enter the hexadecimal RRGGBB code for the color or use the pop-up color picker.
You can't delete an existing incident severity, but to prevent it appearing in any drop-down-lists, all you need to do is change its active flag to \"No\" and click \"Save\". To add a new incident severity, click the \"Add\" button and a new row will be added to the list which you can now edit.
"},{"location":"Spira-Administration-Guide/Template-Incidents/#incident-workflows","title":"Incident Workflows","text":"Clicking on the \"Workflows\" link in the Administration menu brings up the list of defined incident workflows for the current template. A workflow is a predefined sequence of incident statuses linked together by \"workflow transitions\" to enable a newly created incident to be reviewed, prioritized, assigned, resolved and closed, as well as to handle exception cases such as the case of a duplicate or non-reproducible incident. The workflow list screen for a sample template is illustrated below:
To modify the name, default status, notify and/or active flags, change the values in the appropriate text-box, radio-button, check-box or drop-down list and click the \"Save\" button. To add a new workflow, click the \"Add\" button and a new workflow will be created with the standard SpiraPlan\u00ae steps and transitions.
You can have as many workflows as you like in a template, but only one can be marked as the default. Each incident type is assigned to a workflow; this allows you to have different incident types follow different paths from creation of closure. However when a new incident type is created, it will be initially associated with the template's default workflow. The steps and transitions that make up the default workflow are illustrated in the diagram below:
flowchart LR\n A(open status)\n B(closed status)\n\n New --> Open;\n New --> Assigned;\n Assigned --> Duplicate;\n Assigned ---> Resolved;\n Assigned ---> NR[Not Reproducible];\n Resolved --> Closed;\n Open --> Assigned;\n Open --> Duplicate;\n Reopen --> Assigned;\n Reopen <--> Duplicate;\n Reopen <--> Resolved;\n Reopen <--> NR;\n Closed --> Reopen;\n\n style B fill:#f9f\n style Closed fill:#f9f\n style NR fill:#f9f\n style Duplicate fill:#f9f\n style Resolved fill:#f9fThe notify flag is used to tell SpiraPlan\u00ae whether that particular workflow should have email notifications turned on or off. You define what transitions and which recipients should receive the emails in the workflow transition editor (see below), but you can globally turn on/off notifications here as well. This is useful if you find that the notifications are becoming an annoyance, or if the email server is unavailable for a period of time.
Note: You can only assign an active workflow to an incident type, and similarly you cannot make a workflow inactive that is currently linked to an incident type. This is important as all incident types need to be linked to an active workflow at all times.
"},{"location":"Spira-Administration-Guide/Template-Incidents/#edit-workflow-details","title":"Edit Workflow Details","text":"Clicking on the \"Steps\" button of a workflow brings up the following screen that lists all the workflow steps and workflow transitions that comprise the workflow:
This page lists in the left-most column all the various incident statuses defined for the template. The next column lists all the possible transitions that can occur from that status. In addition, with each transition is listed the name of the resulting destination status that the transition leads to. E.g. from the assigned status, depending on your role (see later) you can move the incident to either duplicate, resolves or not-reproducible depending on which transition the user takes.
Clicking on the name of a step or transition takes you to the appropriate details page (see below) where you can set the properties of the step or transition respectively. To delete an existing transition, click the \"x\" button after the transition name, and to add a new transition, click the \"Add Transition\" button in the Operations column.
"},{"location":"Spira-Administration-Guide/Template-Incidents/#edit-workflow-transition","title":"Edit Workflow Transition","text":"When you click on the transition name link from the previous screen, you are taken to the workflow transition details screen:
The top part of the screen is the \"workflow browser\" which illustrates how the transition relates to the workflow as a whole. It displays the current transition in the middle, with the originating and destination steps listed to either side. Clicking on either incident status name will take you to the appropriate workflow step details page. This allows you to click through the whole workflow from start to finish without having to return to the workflow details page.
This part of the screen lets you change the name of the transition and specify the subject line of any email notifications sent as part of this transition. To view the list of special tokens that can be used in the email subject, click on the \"Display Email Subject Special Tokens\" hyperlink:
If a digital signature from the user is required to authorize and record the transition, set the toggle to yes for \"Require Electronic Signature\".
Each transition has a series of conditions which need to be satisfied for a user to actually execute the transition (i.e. move the incident from the originating status to the destination status):
Each transition also has a set of notification rules that allow you to specify who should get an email notification if the transition is executed.
Both the conditions and notifications allow you to set three types of user role:
The detector of the incident can be allowed to execute the transition, and/or be notified when the transition occurs. For example, when an incident is marked as Resolved, the detector should be the only one who's allowed to move it to Closed. Similarly when an incident is moved from Assigned to Resolved, the detector should probably be notified so that he knows to log in and verify that it has been resolved satisfactorily.
The owner of the incident can be allowed to execute the transition, and/or be notified when the transition occurs. For example, when an incident is marked as Assigned, the assigned owner should be the only one who's allowed to move it to Resolved. Similarly when an incident is moved from Open to Assigned, the owner should probably be notified so that he knows to log in and begin resolving the incident.
A user with a specified role can be allowed to execute the transition, and/or be notified when the transition occurs regardless of whether they are the detector or owner. For example a user with role \"Manager\" might want the power to close all incidents regardless of ownership status, and might also want to be notified when any incident is marked as Not-Reproducible.
You can set any of these conditions by changing the drop-down list > and/or check-boxes and clicking the appropriate \"Save\" button.
"},{"location":"Spira-Administration-Guide/Template-Incidents/#edit-workflow-step","title":"Edit Workflow Step","text":"When you click on the incident status name link from either of the previous screens, you are taken to the workflow step details screen:
The top part of the screen is the \"workflow browser\" which illustrates how the step relates to the workflow as a whole. It displays the current incident status in the middle, with the possible originating and destination transitions listed to either side. Clicking on either workflow transition name will take you to the appropriate workflow transition details page. This allows you to click through the whole workflow from start to finish without having to return to the workflow details page.
This page allows you to define the behavior of the various incident fields (i.e. those that are a standard part of SpiraPlan\u00ae such as Priority):
This page also allows you to define the behavior of the various incident custom properties for this particular step in the workflow:
You can set each of the fields/custom properties as being:
For example, when an incident is in the New status, you might make the owner field hidden (since a detector shouldn't need to know who will ultimately own it), when it gets to the Open status, you might make the field active, and when it gets to the Assigned status, you might make it active and required. This allows you to tailor the information gathered to the appropriate place in the workflow.
After you have made the desired changes, click \"Save\".
"},{"location":"Spira-Administration-Guide/Template-Incidents/#example-workflow","title":"Example Workflow","text":"Below is a diagram that shows an example workflow (the one used by the sample product \"Library Information System\") for incidents.
"},{"location":"Spira-Administration-Guide/Template-Notifications/","title":"Template: Notifications","text":"Each template has a separate notification system. This lets admins control what events trigger a notification being sent (via email), with what subject line, and who it should go to. You can create as many event triggers as you want, to give you fine grained control over when notifications are created. Each template has a single notification template (email body with tokens) per artifact. You can have, for example, 20 different requirement event triggers for a product template, each with their own rules and subjects; but they will all send the same email body, because they will all use the same requirement notification template.
To configure emails across the entire system see Email Configuration.
"},{"location":"Spira-Administration-Guide/Template-Notifications/#notification-templates","title":"Notification Templates","text":"Notification templates are used by notification events, and are defined for each supported artifact type1 in the template.
To edit a template, click the Edit button. To send a test email notification to yourself using the current template, click the Test button.
Clicking the Edit button will take you to a page similar to the following. Depending on the artifact type you selected, the list of available fields will vary.
On this screen you are presented with the same rich text editor available elsewhere in the application. Displayed in it is the current template (with template tags showing) for the artifact. Template tags start with a $ (dollar sign) and then a string name enclosed in {} parentheses. When email notifications are sent, tokens will be replaced with specific information from the artifact that the notification is being sent for. Invalid tokens will be stripped from the template text. Clicking the link \"(Display Email Template Field Tokens\" to see a list of available tokens to insert into the textbox for easy selecting and editing.
If HTML notifications are disabled, the template will be converted to plain text before sending.
When finished, click the update button to save your new template. The new template will take effect immediately.
"},{"location":"Spira-Administration-Guide/Template-Notifications/#notification-events","title":"Notification Events","text":"The Notification Events section is where template administrators can set up when and to whom notifications are sent out to users of the system. Clicking on the Notification Events link will present you with a list of all events defined for the current template:
Note: These events can handle all changes to any of the artifacts except changes handled by Status changes to Incidents. Incident status changes are handled through the Workflow configuration.
When clicking on the Edit or Add buttons, you will be presented with the event details screen:
The top section defines general configuration items for the event:
The Artifact Fields will let you configure which fields will cause this notification to send an email notification:
Selected fields are treated in an OR-based query, so that if you have two or more fields checked for an event, the event will send a notification if either of the two fields are changed. Depending on the artifact type configured above, the available fields will vary.
The last section is the configuration of whom to send the notifications to:
If a user belongs to more than one group or they have manually signed up to receive notifications to any changes in the artifact, they will only receive one notification for the artifact change.
Document, Incident, Release, Requirement, Risk, Task, Test Case, Test Set\u00a0\u21a9
Clicking on the \"Release Workflows\" link under the Planning heading, brings up the list of defined release workflows for the current template. A workflow is a predefined sequence of release statuses linked together by \"workflow transitions\" to enable a newly created release to be reviewed, prioritized, assigned, developed and tested, as well as to handle exception cases such as the case of a cancelled or deferred release. The workflow list screen for the sample template is illustrated below:
The screen displays a list of all the standard release types in the system. The associated workflow drop-down list allows you to specify which workflow the release type will follow. This is a very powerful feature since it allows you to configure different workflows for different release types; i.e. a Major release may follow a different process than an iteration.
You can have as many workflows as you like in a template, but only one can be marked as the default. Each release type must be assigned to a workflow. To modify the name, default flag, and/or active flag of an existing workflow, change the values in the appropriate text-box, radio-button, or drop-down list and click the \"Save\" button. To add a new workflow, click the 'Add Workflow' link and a new workflow will be created with the standard SpiraPlan\u00ae steps and transitions.
Note: You can only assign an active workflow to a release type, and similarly you cannot make a workflow inactive that is currently linked to a release type. This is important as all release types need to be linked to an active workflow at all times.
"},{"location":"Spira-Administration-Guide/Template-Releases/#edit-workflow-details","title":"Edit Workflow Details","text":"Clicking on the 'Steps' hyperlink of a workflow brings up the following screen that lists all the workflow steps and workflow transitions that comprise the workflow:
This page lists in the left-most column all the various release statuses defined in the system. The next column lists all the possible transitions that can occur from that status. In addition, with each transition is listed the name of the resulting destination status that the transition leads to. E.g. from the Planned status, depending on your role (see later) the user can move the release to either Cancelled, Deferred, or In Progress, depending on which transition the user takes.
Clicking on the name of a step or transition takes you to the appropriate details page (see below) where you can set the properties of the step or transition respectively. To delete an existing transition, click the 'x button after the transition name, and to add a new transition, click the 'Add Transition' button in the Operations column.
"},{"location":"Spira-Administration-Guide/Template-Releases/#edit-workflow-transition","title":"Edit Workflow Transition","text":"When you click on the transition name link from the previous screen, you are taken to the workflow transition details screen:
The top part of the screen is the \"workflow browser\" which illustrates how the transition relates to the workflow as a whole. It displays the current transition in the middle, with the originating and destination steps listed to either side. Clicking on either task status name will take you to the appropriate workflow step details page. This allows you to click through the whole workflow from start to finish without having to return to the workflow details page.
This part of the screen lets you change the name of the transition. If a digital signature from the user is required to authorize and record the transition, set the toggle to yes for \"Require Electronic Signature\".
In addition, each transition has a series of conditions which need to be satisfied for a user to actually execute the transition (i.e. move the release from the originating status to the destination status):
The conditions section allows you to set three types of user role:
The author of the release can be allowed to execute the transition. For example, when a release is marked as Completed, the author might be allowed to move it to In Progress if there is still work remaining.
The owner of the release can be allowed to execute the transition. For example, when a release is marked as In Progress, the assigned owner should be the only one who's allowed to move it to Competed.
A user with a specified role can be allowed to execute the transition regardless of whether they are the author or owner. For example a user with role \"Manager\" might want the power to defer all releases regardless of ownership status.
You can set any of these conditions by changing the drop-down list > and/or check-boxes and clicking the appropriate \"Save\" button.
"},{"location":"Spira-Administration-Guide/Template-Releases/#edit-workflow-step","title":"Edit Workflow Step","text":"When you click on the release status name link from either of the previous screens, you are taken to the workflow step details screen:
The top part of the screen is the \"workflow browser\" which illustrates how the step relates to the workflow as a whole. It displays the current release status in the middle, with the possible originating and destination transitions listed to either side. Clicking on either workflow transition name will take you to the appropriate workflow transition details page. This allows you to click through the whole workflow from start to finish without having to return to the workflow details page.
This page allows you to define the behavior of the various release fields (i.e. those that are a standard part of SpiraPlan\u00ae such as Priority):
This page also allows you to define the behavior of the various release custom properties for this particular step in the workflow:
You can set each of the fields/custom properties as being:
For example, when a release is in the Planned status, you might make the owner field hidden (since the author shouldn't need to know who will ultimately own it), when it gets to the In Progress status, you might make the field enabled and required, and when it gets to the Completed status, you might make it disabled. This allows you to tailor the information gathered to the appropriate place in the workflow.
Set the fields as desired and click \"Save\".
"},{"location":"Spira-Administration-Guide/Template-Releases/#example-workflow","title":"Example Workflow","text":"Below is a diagram that shows an example workflow (the one used by the sample product \"Library Information System\") for releases.
"},{"location":"Spira-Administration-Guide/Template-Requirements/","title":"Template: Requirements","text":"This section contains administrative options that are specific to the requirements functionality in the system.
"},{"location":"Spira-Administration-Guide/Template-Requirements/#importance","title":"Importance","text":"The following screen is displayed when you choose the \"Importance\" link from the Requirements section of the administration menu:
The screen displays a list of all the defined requirement importances for the current template. By default the screen will be populated with the standard SpiraPlan\u00ae requirement importances. To edit an existing requirement importance, change the name, color, score (this is used for ranking the different items -- the item with the lowest score will appear at the top of dropdown lists in the application), and/or change the active flag then click \"Save\".
Note that you can either enter the hexadecimal RRGGBB code for the color or use the pop-up color picker.
You can't delete an existing requirement importance, but to prevent it appearing in any drop-down-lists, change its active flag to \"No\" and click \"Save\". To add a new requirement importance, click the \"Add\" button and a new row will be added to the list which you can now edit.
"},{"location":"Spira-Administration-Guide/Template-Requirements/#statuses","title":"Statuses","text":"In beta, available in SpiraTeam and SpiraPlan only
System admins can enable beta functionality across the application for their users from the System Admin > General Settings page.
Requirement statuses are fixed. Admins cannot add or rename requirement statuses. The requirement status page lets template admins manage how these statuses are displayed to users on relevant planning boards (currently the beta planning board only).
This page shows every requirement status (in the same order you will see them on the requirement workflow pages). For each status you can:
By default, no statuses have a position or are toggled to show. In this state, the board will show all statuses that have a transition in and out (across all active workflows), in the default order.
If you turn on one or more statuses to show on boards, then those statuses will always show (whether or not they have transitions). Statuses that show and do not have a position are shown before those that do have a position. In the example below, the following statuses will show in the following order:
The following screen is displayed when you choose the \"Types\" link from the Requirements section of the administration menu:
The screen displays a list of all the defined requirement types for the current template. By default the screen will be populated with the standard SpiraPlan\u00ae requirement types. To edit an existing requirement type, change the name, associated workflow, issue check-box, risk check-box, set a default type and/or change the active flag then click \"Save\".
You can't delete an existing requirement type, but to prevent it appearing in any drop-down-lists, change its active flag to \"No\" and click \"Save\". To add a new requirement type, click the \"Add\" button and a new row will be added to the list which you can now edit.
The associated workflow drop-down list allows you to specify which workflow the requirement type will follow. This is a very powerful feature since it allows you to configure different workflows for different requirement types; i.e. a User Story may follow a simpler review process than a Feature or Use Case requirement.
The Has Steps check-box allows you to specify if the requirement type should be able to contain scenario steps (as is typical with use cases).
The default radio button allows you to specify which requirement type should be the default for newly created requirements. This is the type that a new requirement will be set to unless changed by the creator of the requirement. Note that you must have at least one active requirement type, and you cannot set an inactive type as the default.
"},{"location":"Spira-Administration-Guide/Template-Requirements/#workflows","title":"Workflows","text":"Clicking on the \"Workflow\" link under the Requirements heading, brings up the list of defined requirement workflows for the current template. A workflow is a predefined sequence of requirement statuses linked together by \"workflow transitions\" to enable a newly created requirement to be reviewed, prioritized, assigned, developed and tested, as well as to handle exception cases such as the case of a rejected or obsolete requirement. The workflow list screen for the sample template is illustrated below:
You can have as many workflows as you like in a template, but only one can be marked as the default. Each requirement type must be assigned to a workflow. To modify the name, default flag, and/or active flag of an existing workflow, change the values in the appropriate text-box, radio-button, or drop-down list and click the \"Save\" button. To add a new workflow, click the 'Add Workflow' link and a new workflow will be created with the standard SpiraPlan\u00ae steps and transitions.
Note: You cannot make a workflow inactive that is currently linked to a requirement type. This is important as all requirement types need to be linked to an active workflow at all times.
"},{"location":"Spira-Administration-Guide/Template-Requirements/#edit-workflow-details","title":"Edit Workflow Details","text":"Clicking on the 'Steps' button of a workflow brings up the following screen that lists all the workflow steps and workflow transitions that comprise the workflow:
This page lists in the left-most column all the various requirement statuses defined in the system. The next column lists all the possible transitions that can occur from that status. In addition, with each transition is listed the name of the resulting destination status that the transition leads to. E.g. from the Requested status, depending on your role (see later) the user can move the requirement to either Accepted or Under Review, depending on which transition the user takes.
Clicking on the name of a step or transition takes you to the appropriate details page (see below) where you can set the properties of the step or transition respectively. To delete an existing transition, click the 'x button after the transition name, and to add a new transition, click the 'Add Transition' button in the Operations column.
"},{"location":"Spira-Administration-Guide/Template-Requirements/#edit-workflow-transition","title":"Edit Workflow Transition","text":"When you click on the transition name link from the previous screen, you are taken to the workflow transition details screen:
The top part of the screen is the \"workflow browser\" which illustrates how the transition relates to the workflow as a whole. It displays the current transition in the middle, with the originating and destination steps listed to either side. Clicking on either requirement status name will take you to the appropriate workflow step details page. This allows you to click through the whole workflow from start to finish without having to return to the workflow details page.
This part of the screen lets you change the name of the transition. If a digital signature from the user is required to authorize and record the transition, set the toggle to yes for \"Require Electronic Signature\".
In addition, each transition has a series of conditions which need to be satisfied for a user to actually execute the transition (i.e. move the requirement from the originating status to the destination status):
The conditions section allows you to set three types of user role:
The author of the requirement can be allowed to execute the transition. For example, when a requirement is marked as Completed, the author might be allowed to move it to Obsolete when it's no longer applicable.
The owner of the requirement can be allowed to execute the transition. For example, when a requirement is marked as Under Review, the assigned owner should be the only one who's allowed to move it to Accepted.
A user with a specified role can be allowed to execute the transition regardless of whether they are the author or owner. For example a user with role \"Manager\" might want the power to close all requirements regardless of ownership status.
You can set any of these conditions by changing the drop-down list > and/or check-boxes and clicking the appropriate \"Save\" button.
"},{"location":"Spira-Administration-Guide/Template-Requirements/#edit-workflow-step","title":"Edit Workflow Step","text":"When you click on the requirement status name link from either of the previous screens, you are taken to the workflow step details screen:
The top part of the screen is the \"workflow browser\" which illustrates how the step relates to the workflow as a whole. It displays the current requirement status in the middle, with the possible originating and destination transitions listed to either side. Clicking on either workflow transition name will take you to the appropriate workflow transition details page. This allows you to click through the whole workflow from start to finish without having to return to the workflow details page.
This page allows you to define the behavior of the various requirement fields (i.e. those that are a standard part of SpiraPlan\u00ae such as Importance):
This page also allows you to define the behavior of the various requirement custom properties for this particular step in the workflow:
You can set each of the fields/custom properties as being:
For example, when a requirement is in the Requested status, you might make the owner field hidden (since the author shouldn't need to know who will ultimately own it), when it gets to the Accepted status, you might make the field enabled, and when it gets to the In Progress status, you might make it enabled and required. This allows you to tailor the information gathered to the appropriate place in the workflow.
After you have made the desired changes, click \"Save\".
"},{"location":"Spira-Administration-Guide/Template-Requirements/#example-workflow","title":"Example Workflow","text":"Below is a diagram that shows an example workflow (the one used by the sample product \"Library Information System\") for requirements.
"},{"location":"Spira-Administration-Guide/Template-Risks/","title":"Template: Risks","text":"This section contains administrative options that are specific to the risk functionality in the system.
"},{"location":"Spira-Administration-Guide/Template-Risks/#edit-types","title":"Edit Types","text":"The following screen is displayed when you choose the \"Types\" link from the Incidents section of the administration menu:
The screen displays a list of all the defined risk types for the current template. By default, the screen will be populated with the standard SpiraPlan\u00ae risk types. To edit an existing type, change the name, associated workflow, set a default type and/or change the active flag then click \"Save\".
You can't delete an existing risk type, but to prevent it appearing in any drop-down-lists, change its active flag to \"No\" and click \"Save\". To add a new type, click the \"Add\" button and a new row will be added to the list which you can now edit.
The associated workflow drop-down list allows you to specify which workflow the type will follow. This is a very powerful feature since it allows you to configure different workflows for different risk types.
The default radio button allows you to specify which type should be the default for newly created risks. This is the type that a new risk will be set to unless changed by the creator of the risk. Note that you must have at least one active risk type, and you cannot set an inactive type as the default.
"},{"location":"Spira-Administration-Guide/Template-Risks/#edit-statuses","title":"Edit Statuses","text":"The following screen is displayed when you choose the \"Statuses\" link from the Risks section of the administration menu:
The screen displays a list of all the defined risk statuses for the current template. By default, the screen will be populated with the standard SpiraPlan\u00ae risks statuses. To edit an existing status, change the name, open check-box, set it as the default status and/or change the active flag then click \"Save\".
You can't delete an existing risk status, but to prevent it appearing in any drop-down-lists, change its active flag to \"No\" and click \"Save\". To add a new risk status, click the \"Add\" button and a new row will be added to the list which you can now edit.
The open check-box allow you to specify if the risk status should be considered open or not, which means it is would be eligible for display in the various sections of the user's home page and the product home page that list open risks. The default radio button allows you to specify which risk status should be the default for newly created risks. This is the status that a new risk will be set to when first created, and acts as the first step in the risk workflow. Note that you must have at least one active status, and you cannot set an inactive status as the default.
"},{"location":"Spira-Administration-Guide/Template-Risks/#impact","title":"Impact","text":"The following screen is displayed when you choose the \"Impact\" link from the Risks section of the administration menu. The impact of a risk specifies how serious it will be if the risk happens.
The screen displays a list of all the defined risk impacts for the current template. By default, the screen will be populated with the standard SpiraPlan\u00ae risk impacts. To edit an existing impact: change the name, color, score (which is used, together with a risks probability to calculate its exposure), position, or change the active flag then click \"Save\". Note that you can either enter the hexadecimal RRGGBB code for the color or use the pop-up color picker.
You can't delete an existing impact, but to prevent it appearing in any drop-down-lists, change its active flag to \"No\" and click \"Save\". To add a new impact, click the \"Add\" button and a new row will be added to the list which you can now edit.
"},{"location":"Spira-Administration-Guide/Template-Risks/#probability","title":"Probability","text":"The following screen is displayed when you choose the \"Probability\" link from the Risks section of the administration menu:
The screen displays a list of all the defined risk probabilities for the current template. By default, the screen will be populated with the standard SpiraPlan\u00ae risk probabilities. To edit an existing probability: change the name, color, score (which is used, together with a risks impact to calculate its exposure), position, or change the active flag then click \"Save\". Note that you can either enter the hexadecimal RRGGBB code for the color or use the pop-up color picker.
You can't delete an existing risk probability, but to prevent it appearing in any drop-down-lists, change its active flag to \"No\" and click \"Save\". To add a new risk probability, click the \"Add\" button and a new row will be added to the list which you can now edit.
"},{"location":"Spira-Administration-Guide/Template-Risks/#risk-workflows","title":"Risk Workflows","text":"Clicking on the \"Workflows\" link in the Administration menu brings up the list of defined risk workflows for the current template. A workflow is a predefined sequence of risk statuses linked together by \"workflow transitions\" to enable a newly created risk to be reviewed, prioritized, assigned, resolved and closed. The workflow list screen for a sample template is illustrated below:
To modify the name, default status, notify and/or active flags, change the values in the appropriate text-box, radio-button, check-box or drop-down list and click the \"Save\" button. To add a new workflow, click the \"Add\" button and a new workflow will be created with the standard SpiraPlan\u00ae steps and transitions.
You can have as many workflows as you like in a template, but only one can be marked as the default. Each risk type is assigned to a workflow; this allows you to have different risk types follow different paths from creation of closure. However, when a new risk type is created, it will be initially associated with the template's default workflow.
Note: You can only assign an active workflow to a risk type, and similarly you cannot make a workflow inactive that is currently linked to a risk type. This is important as all risk types need to be linked to an active workflow at all times.
"},{"location":"Spira-Administration-Guide/Template-Risks/#edit-workflow-details","title":"Edit Workflow Details","text":"Clicking on the \"Steps\" button of a workflow brings up the following screen that lists all the workflow steps and workflow transitions that comprise the workflow:
This page lists in the left-most column all the various risk statuses defined for the template. The next column lists all the possible transitions that can occur from that status. In addition, with each transition is listed the name of the resulting destination status that the transition leads to. E.g. from the evaluated status, depending on your role (see elsewhere in this manual) you can move the risk to either rejected, or open depending on which transition the user takes.
Clicking on the name of a step or transition takes you to the appropriate details page (see below) where you can set the properties of the step or transition respectively. To delete an existing transition, click the \"x\" button after the transition name, and to add a new transition, click the \"Add Transition\" button in the Operations column.
"},{"location":"Spira-Administration-Guide/Template-Risks/#edit-workflow-transition","title":"Edit Workflow Transition","text":"When you click on the transition name link from the previous screen, you are taken to the workflow transition details screen:
The top part of the screen is the \"workflow browser\" which illustrates how the transition relates to the workflow as a whole. It displays the current transition in the middle, with the originating and destination steps listed to either side. Clicking on either risk status name will take you to the appropriate workflow step details page. This allows you to click through the whole workflow from start to finish without having to return to the workflow details page.
If a digital signature from the user is required to authorize and record the transition, set the toggle to yes for \"Require Electronic Signature\".
Each transition has a series of conditions which need to be satisfied for a user to actually execute the transition (i.e. move the incident from the originating status to the destination status).
"},{"location":"Spira-Administration-Guide/Template-Risks/#edit-workflow-step","title":"Edit Workflow Step","text":"When you click on the incident status name link from either of the previous screens, you are taken to the workflow step details screen:
The top part of the screen is the \"workflow browser\" which illustrates how the step relates to the workflow as a whole. It displays the current risk status in the middle, with the possible originating and destination transitions listed to either side. Clicking on either workflow transition name will take you to the appropriate workflow transition details page. This allows you to click through the whole workflow from start to finish without having to return to the workflow details page.
This page allows you to define the behavior of the various risk fields (i.e. those that are a standard part of SpiraPlan\u00ae such as probability):
This page also allows you to define the behavior of the various risk custom properties for this particular step in the workflow:
You can set each of the fields/custom properties as being:
After you have made the desired changes, click \"Save\".
"},{"location":"Spira-Administration-Guide/Template-Risks/#example-workflow","title":"Example Workflow","text":"Below is a diagram that shows an example workflow (the one used by the sample product \"Library Information System\") for risks.
"},{"location":"Spira-Administration-Guide/Template-Tasks/","title":"Template: Tasks","text":"This section contains administrative options that are specific to task functionality in the system.
"},{"location":"Spira-Administration-Guide/Template-Tasks/#priority","title":"Priority","text":"The following screen is displayed when you choose the \"Priority\" link from the Tasks section of the administration menu:
The screen displays a list of all the defined task priorities for the current template. By default, the screen will be populated with the standard SpiraPlan\u00ae task priorities. To edit an existing task priority, change the name, color, score (this is used for ranking the different items -- the item with the lowest score will appear at the top of dropdown lists in the application), and/or change the active flag then click \"Save\".
Note that you can either enter the hexadecimal RRGGBB code for the color or use the pop-up color picker.
You can't delete an existing task priority, but to prevent it appearing in any drop-down-lists, change its active flag to \"No\" and click \"Save\". To add a new task priority, click the \"Add\" button and a new row will be added to the list which you can now edit.
"},{"location":"Spira-Administration-Guide/Template-Tasks/#types","title":"Types","text":"When you choose the \"Types\" link from the Tasks section of the administration menu you will see the following page:
The page shows a list of all the defined task types for the current template. By default, the screen will be populated with the standard SpiraPlan\u00ae task types and only show the active types. To view inactive or all types, use the \"Displaying\" dropdown near the top.
You can change the following information about each type:
To add a new type, click the \"Add\" button and a new row will be added to the list for you to edit.
Once you have made any changes you need to make, click \"Save\".
"},{"location":"Spira-Administration-Guide/Template-Tasks/#task-workflows","title":"Task Workflows","text":"Clicking on the \"Task Workflows\" link under the Planning heading, brings up the list of defined task workflows for the current template. A workflow is a predefined sequence of task statuses linked together by \"workflow transitions\" to enable a newly created task to be reviewed, prioritized, assigned, developed and tested, as well as to handle exception cases such as the case of a blocked or deferred task. The workflow list screen for the sample template is illustrated below:
You can have as many workflows as you like in a template, but only one can be marked as the default. Each task type must be assigned to a workflow. To modify the name, default flag, and/or active flag of an existing workflow, change the values in the appropriate text-box, radio-button, or drop-down list and click the \"Save\" button. To add a new workflow, click the 'Add Workflow' link and a new workflow will be created with the standard SpiraPlan\u00ae steps and transitions.
Note: You can only assign an active workflow to a task type, and similarly you cannot make a workflow inactive that is currently linked to a task type. This is important as all task types need to be linked to an active workflow at all times.
"},{"location":"Spira-Administration-Guide/Template-Tasks/#edit-workflow-details","title":"Edit Workflow Details","text":"Clicking on the 'Steps' hyperlink of a workflow brings up the following screen that lists all the workflow steps and workflow transitions that comprise the workflow:
This page lists in the left-most column all the various task statuses defined in the system. The next column lists all the possible transitions that can occur from that status. In addition, with each transition is listed the name of the resulting destination status that the transition leads to. E.g. from the Not Started status, depending on your role (see later) the user can move the task to either Deferred or In Progress, depending on which transition the user takes.
Clicking on the name of a step or transition takes you to the appropriate details page (see below) where you can set the properties of the step or transition respectively. To delete an existing transition, click the 'x button after the transition name, and to add a new transition, click the 'Add Transition' button in the Operations column.
"},{"location":"Spira-Administration-Guide/Template-Tasks/#edit-workflow-transition","title":"Edit Workflow Transition","text":"When you click on the transition name link from the previous screen, you are taken to the workflow transition details screen:
The top part of the screen is the \"workflow browser\" which illustrates how the transition relates to the workflow as a whole. It displays the current transition in the middle, with the originating and destination steps listed to either side. Clicking on either task status name will take you to the appropriate workflow step details page. This allows you to click through the whole workflow from start to finish without having to return to the workflow details page.
This part of the screen lets you change the name of the transition. If a digital signature from the user is required to authorize and record the transition, set the toggle to yes for \"Require Electronic Signature\".
In addition, each transition has a series of conditions which need to be satisfied for a user to actually execute the transition (i.e. move the task from the originating status to the destination status):
The conditions section allows you to set three types of user role:
The author of the task can be allowed to execute the transition. For example, when a task is marked as Completed, the author might be allowed to move it to In Progress if there is still work remaining.
The owner of the task can be allowed to execute the transition. For example, when a task is marked as In Progress, the assigned owner should be the only one who's allowed to move it to Competed.
A user with a specified role can be allowed to execute the transition regardless of whether they are the author or owner. For example a user with role \"Manager\" might want the power to defer all tasks regardless of ownership status.
You can set any of these conditions by changing the drop-down list > and/or check-boxes and clicking the appropriate \"Save\" button.
"},{"location":"Spira-Administration-Guide/Template-Tasks/#edit-workflow-step","title":"Edit Workflow Step","text":"When you click on the task status name link from either of the previous screens, you are taken to the workflow step details screen:
The top part of the screen is the \"workflow browser\" which illustrates how the step relates to the workflow as a whole. It displays the current task status in the middle, with the possible originating and destination transitions listed to either side. Clicking on either workflow transition name will take you to the appropriate workflow transition details page. This allows you to click through the whole workflow from start to finish without having to return to the workflow details page.
This page allows you to define the behavior of the various task fields (i.e. those that are a standard part of SpiraPlan\u00ae such as Priority):
This page also allows you to define the behavior of the various task custom properties for this particular step in the workflow:
You can set each of the fields/custom properties as being:
For example, when a task is in the Not Started status, you might make the owner field hidden (since the author shouldn't need to know who will ultimately own it), when it gets to the In Progress status, you might make the field enabled and required, and when it gets to the Completed status, you might make it disabled. This allows you to tailor the information gathered to the appropriate place in the workflow.
After you have made the desired changes, click \"Save\".
"},{"location":"Spira-Administration-Guide/Template-Tasks/#example-workflow","title":"Example Workflow","text":"Below is a diagram that shows an example workflow (the one used by the sample product \"Library Information System\") for tasks.
"},{"location":"Spira-Administration-Guide/Template-Test-Cases/","title":"Template: Test Cases","text":"This section contains administrative options that are specific to the testing functionality in the system.
"},{"location":"Spira-Administration-Guide/Template-Test-Cases/#priority","title":"Priority","text":"The following screen is displayed when you choose the \"Priority\" link from the Test Cases section of the administration menu:
The screen displays a list of all the defined test case priorities for the current template. By default, the screen will be populated with the standard SpiraPlan\u00ae test case priorities. To edit an existing test case priority, change the name, color, score (this is used for ranking the different items -- the item with the lowest score will appear at the top of dropdown lists in the application), and/or change the active flag then click \"Save\".
Note that you can either enter the hexadecimal RRGGBB code for the color or use the pop-up color picker.
You can't delete an existing test case priority, but to prevent it appearing in any drop-down-lists, change its active flag to \"No\" and click \"Save\". To add a new test case priority, click the \"Add\" button and a new row will be added to the list which you can now edit.
"},{"location":"Spira-Administration-Guide/Template-Test-Cases/#types","title":"Types","text":"The following screen is displayed when you choose the \"Types\" link from the Test Cases section of the administration menu:
The screen displays a list of all the defined test case types for the current template. By default, the screen will be populated with the standard SpiraPlan\u00ae test case types. To edit an existing test case type, change the name, associated workflow, issue check-box, risk check-box, set a default type and/or change the active flag then click \"Save\".
You can't delete an existing test case type, but to prevent it appearing in any drop-down-lists, change its active flag to \"No\" and click \"Save\". To add a new test case type, click the \"Add\" button and a new row will be added to the list which you can now edit.
The associated workflow drop-down list allows you to specify which workflow the test case type will follow. This is a very powerful feature since it allows you to configure different workflows for different test case types; i.e. a User Story may follow a simpler review process than a Feature or Use Case test case.
The Is Exploratory check-box allows you to specify if the test case type should be able to be executed in exploratory mode (which allows more editing of the test case and its steps during execution). Note that this mode is only available to users with a certain permission level and when executing an individual test case.
The default radio button allows you to specify which test case type should be the default for newly created test cases. This is the type that a new test case will be set to unless changed by the creator of the test case. Note that you must have at least one active test case type, and you cannot set an inactive type as the default.
"},{"location":"Spira-Administration-Guide/Template-Test-Cases/#test-case-workflows","title":"Test Case Workflows","text":"Clicking on the \"Workflows\" link under the Test Cases section, brings up the list of defined test case workflows for the current template. A workflow is a predefined sequence of test cases statuses linked together by \"workflow transitions\" to enable a newly created test case to be reviewed, prioritized, assigned, and tested, as well as to handle exception cases such as the case of a rejected or obsolete test case. The workflow list screen for the sample template is illustrated below:
You can have as many workflows as you like in a template, but only one can be marked as the default. Each test case type must be assigned to a workflow. To modify the name, default flag, and/or active flag of an existing workflow, change the values in the appropriate text-box, radio-button, or drop-down list and click the \"Save\" button. To add a new workflow, click the 'Add Workflow' link and a new workflow will be created with the standard SpiraPlan\u00ae steps and transitions. The steps and transitions that make up the default workflow are illustrated in the diagram below:
flowchart LR\n Draft --> Rejected;\n Draft <--> Ready-for-Review;\n Ready-for-Review <--> Approved;\n Ready-for-Review <--> Rejected;\n Approved <--> Ready-for-Test;\n Ready-for-Test <--> Obsolete;Note: You can only assign an active workflow to a test case type, and similarly you cannot make a workflow inactive that is currently linked to a test case type. This is important as all test case types need to be linked to an active workflow at all times.
"},{"location":"Spira-Administration-Guide/Template-Test-Cases/#edit-workflow-details","title":"Edit Workflow Details","text":"Clicking on the 'Steps' button of a workflow brings up the following screen that lists all the workflow steps and workflow transitions that comprise the workflow:
This page lists in the left-most column all the various test case statuses defined in the system. The next column lists all the possible transitions that can occur from that status. In addition, with each transition is listed the name of the resulting destination status that the transition leads to. E.g. from the Draft status, depending on your role (see elsewhere in this manual) the user can move the test case to either Rejected, or Ready for Review, depending on which transition the user takes.
Clicking on the name of a step or transition takes you to the appropriate details page (see below) where you can set the properties of the step or transition respectively. To delete an existing transition, click the 'x button after the transition name, and to add a new transition, click the 'Add Transition' button in the Operations column.
"},{"location":"Spira-Administration-Guide/Template-Test-Cases/#edit-workflow-transition","title":"Edit Workflow Transition","text":"When you click on the transition name link from the previous screen, you are taken to the workflow transition details screen:
The top part of the screen is the \"workflow browser\" which illustrates how the transition relates to the workflow as a whole. It displays the current transition in the middle, with the originating and destination steps listed to either side. Clicking on either task status name will take you to the appropriate workflow step details page. This allows you to click through the whole workflow from start to finish without having to return to the workflow details page.
This part of the screen lets you change the name of the transition. If a digital signature from the user is required to authorize and record the transition, set the toggle to yes for \"Require Electronic Signature\".
In addition, each transition has a series of conditions which need to be satisfied for a user to actually execute the transition (i.e. move the test case ease from the originating status to the destination status):
The conditions section allows you to set three types of user role:
The author of the test case can be allowed to execute the transition. For example, when a test case is marked as Ready for Review, the author might be allowed to move it to Ready to Test.
The owner of the test case can be allowed to execute the transition. For example, when a test case is marked as Approved, the assigned owner should be the only one who's allowed to move it to Ready for Test.
A user with a specified role can be allowed to execute the transition regardless of whether they are the author or owner. For example a user with role \"Manager\" might want the power to approve all test cases regardless of ownership status.
You can set any of these conditions by changing the drop-down list > and/or check-boxes and clicking the appropriate \"Save\" button.
"},{"location":"Spira-Administration-Guide/Template-Test-Cases/#edit-workflow-step","title":"Edit Workflow Step","text":"When you click on the test case status name link from either of the previous screens, you are taken to the workflow step details screen:
The top part of the screen is the \"workflow browser\" which illustrates how the step relates to the workflow as a whole. It displays the current test case status in the middle, with the possible originating and destination transitions listed to either side. Clicking on either workflow transition name will take you to the appropriate workflow transition details page. This allows you to click through the whole workflow from start to finish without having to return to the workflow details page.
This page allows you to define the behavior of the various test case fields (i.e. those that are a standard part of SpiraPlan\u00ae such as Priority):
This page also allows you to define the behavior of the various test case custom properties for this particular step in the workflow:
You can set each of the fields/custom properties as being:
For example, when a test case is in the Draft status, you might make the owner field hidden (since the author shouldn't need to know who will ultimately own it), when it gets to the Ready for Review status, you might make the field enabled and required, and when it gets to the Approve status, you might make it disabled. This allows you to tailor the information gathered to the appropriate place in the workflow.
After you have made the desired changes, click \"Save\".
Note that two test case fields have special meanings:
Below is a diagram that shows an example workflow (the one used by the sample product \"Library Information System\") for test cases.
"},{"location":"Spira-Administration-Guide/Testing-Settings/","title":"Testing Settings","text":"In 6.5.2 this page moved here.
"},{"location":"Spira-User-Manual/","title":"Welcome to the SpiraPlan User Manual","text":"How to use this manual
This documentation is designed for all users of SpiraTest, SpiraTeam, or SpiraPlan.
It can be read 'cover to cover' or you can dip into a specific section for key information.
To find the section you need, open the \"User Manual\" section from the site navigation to see all available chapters.
This manual is built around a few core areas:
The Product section is by far the biggest part of this manual. This section is further divided up into 5 areas: planning, testing, developing, tracking, reporting. These areas mirror how you navigate around a product inside SpiraPlan itself.
"},{"location":"Spira-User-Manual/Appendix-1-Keyboard-Shortcuts/","title":"Appendix 1: Keyboard Shortcuts","text":"SpiraPlan\u00ae includes an array of keyboard shortcuts to speed up navigation and use of the application. All functionality can be performed using a mouse and clicking and therefore using a keyboard shortcut is never required. However, keyboard shortcuts can be an efficient way of performing common tasks. A list of the keyboard shortcuts and what they do is available throughout the application in two ways:
There are two main ways of using the shortcuts: either pressing a key or key(s) at the same time (indicated by a single key or \"a + b\"); or pressing a number of keys in succession as with normal typing (indicated by \"a ... b\"). The popup menu explaining the shortcuts is illustrated below (please note that the keyboard shortcuts displayed will vary depending on the current page:
"},{"location":"Spira-User-Manual/Application-Wide/","title":"Common Elements Across the Application","text":"There are lots of different artifacts in the application (described here). This means each artifact has its own settings, uses, and logical links to other artifacts, and reporting. Each artifact is different but they also share many similarities. These are explained below.
"},{"location":"Spira-User-Manual/Application-Wide/#artifact-list-pages","title":"Artifact List Pages","text":"When you first visit an artifact section in the app (by clicking on the relevant link in the global navigation bar), you will be taken to the artifact list page. This may look something like below (this image is of the requirements list page) with a grid of data - each row representing a single artifact, and often a sidebar on the left with charts or links:
"},{"location":"Spira-User-Manual/Application-Wide/#filtering","title":"Filtering","text":"You can easily filter artifact lists as you can see in the screen-shot below. Here, we are filtering Requirements by the status \"Requested\":
To filter the list:
Filter icon or press the ENTER key to apply the filtersNote that the NAME field is searched using a \"like\" comparison, so that searching for \"database\" would match \"Database is ready\", \"There is a database\", \"The data in the database is correct\", and so on. All other freetext fields need to be exact matches (e.g. dates or numbers).
To clear the current filter (whether it is saved or not), either click the Clear Filters button above the table (as you can see in the screenshot above), or go to Filter > Clear Filter from the operations toolbar.
You can do a number of things with filters. First let's talk about using the Filters button on the operations toolbar (at the top of the page just below the main navigation bar).
To reuse a filter, save it by going to Filter > Save Filter from the operations toolbar. Give your new filter a name and click Save.
By default, when you save a filter it will also save your column selection information. Uncheck the box next to \"Save the column selection with the filter\" if you do not want to save this information.
When you apply a saved filter with column selection information, the system will show the specific columns visible (including their relative ordering and width) to match those in the filter. This means that you can Show/Hide different columns, filter on them, and save the entire combination as a saved view. When you switch between saved views, the system will show/hide and reposition the columns associated with the view automatically.
To share the filter with other members of the product, in the Save Filter dialog, check the box next to \"Share with other members of the product\".
To update an existing filter, go to Filter > Save Filter and click on Update Existing. You will see a dropdown of all your saved filters. Pick one, and then click Save. This will update the filter itself, any sort applied, whether it is shared or not, or if it should save the column selection with the filter.
To see your saved filters for this artifact, go to Filter > Retrieve Filter. Apply the filter by selecting it.
From your \"My Page\" you can see all your save filters across all artifacts and products. You can also delete any filter from there. This is all through the My Saved Searches widget.
"},{"location":"Spira-User-Manual/Application-Wide/#quick-filter-side-panel","title":"Quick Filter Side Panel","text":"As a shortcut, the left hand panel on artifact list pages includes a set of Quick Filters. Click the name of the filter in this panel to apply it. This panel is NOT visible for list pages that do not have a side panel at all - i.e. Releases, Automation Hosts, Test Configurations, and Resources.
The quick filter panel shows a list of all saved filters created by you (with an icon of a person) or shared by others (with an icon of a group of people) for the current artifact.
For Requirements, Test Cases, Incidents, Risks, and Tasks the quick filter panel also shows a list of Components for the current product. Picking a component will filter the list to only show those associated with that component.
For Requirements and Test Runs the quick filter panel additionally shows a dropdown for Releases. Picking a release will filter the list to only show items that are set for that particular release.
"},{"location":"Spira-User-Manual/Application-Wide/#sorting","title":"Sorting","text":"Many artifact lists let you sort by a specific column (either ascending or descending). To change the column being sorted, click on the up or down arrow icon next to the title of that column. Click the other icon will reverse the sort order. The currently sorted column is indicated by the darker arrow. When you save a filter it will always save the selected sort.
"},{"location":"Spira-User-Manual/Application-Wide/#show-hide-columns","title":"Show / Hide Columns","text":"This drop-down list allows you to change the fields that are displayed in the artifact list as columns for the current product. To show a column that is not already displayed, simply select that column from the list of \"Show...\" column names and to hide an existing column, simply select that column from the list of \"Hide...\" column names. This is stored on a per-product basis, so you can have different display settings for each product that you are a member of. The fields can be any of the built-in fields or any of the custom properties set up by the product owner.
"},{"location":"Spira-User-Manual/Application-Wide/#right-click-context-menu","title":"Right-Click Context Menu","text":"SpiraPlan\u00ae provides a shortcut -- called the context menu - for accessing some of the most commonly used functions, so that you don't need to move your mouse up to the toolbar each time. To access the context menu, right-click on any of the rows in the artifacts list and the following menu will be displayed (the one below is specific to requirements - different artifacts have different options in the context menu):
"},{"location":"Spira-User-Manual/Application-Wide/#export-to-another-product","title":"Export to Another Product","text":"You can export the following artifacts from the current product to any other product that you have access to:
The artifacts will be exported from the current product to the destination product. Any file attachments will also be copied to the destination product. If the destination product uses the same product template then standard and custom fields will be copied over in full - but this will not necessarily be possible if the destination product uses a different product (the system will try and match up fields as best it can).
Note: when exporting a requirement that has children, the requirement itself and all of its children are exported to the destination product.
To export one or more of a particular artifact:
Tools > Export to Product from the toolbarExportTo view details about a specific artifact, you need to go to the artifact's detail page. Clicking on an item on the artifact list page will open the corresponding detail page.
Most of these details pages are made up of three areas;
the left pane with artifact list navigation options and information
the right pane's header, which displays: the operations toolbar; the editable name of the selected artifact; and the info bar (with a shaded background), which also contains the workflow status transitions
the right pane's tabbed interface with rich information related to the artifact
Please note that on smaller screen sizes the left navigation pane is not displayed. While the navigation pane has a link to take you back to the artifact list, on mobile devices a 'back' button is shown on the left of the operations toolbar.
The navigation pane can be collapsed by clicking on the \"-\" button, or expanded by clicking anywhere on the gray title area. On desktops the user can also control the exact width of the navigation pane by dragging and dropping a red handle that appears on hovering at the rightmost edge of the navigation pane.
The navigation pane often shows a list of the peer artifacts to the one selected. This list is useful as a navigation shortcut.
"},{"location":"Spira-User-Manual/Application-Wide/#breadcrumbs","title":"Breadcrumbs","text":"For folders and hierarchical / tree view artifacts at the top of the details page right hand side you will see the breadcrumb trail, where relevant.
If the artifact you are looking at is in a folder, above its name you will see a breadcrumb trail for the full folder path. It will be in the form of Grandparent Folder / Parent Folder. You can click on any part of this breadcrumb / path to navigate to that folder.
Artifacts that have folders are: documents, test cases, test sets, and tasks.
Requirements and releases exist in a hierarchy with other requirements and releases. For these you will also see a breadcrumb, but instead of showing folders it will show the hierarchy to the container requirements or releases. Clicking on the breadcrumb link will take you to the specific requirement or release clicked on.
Tip: when navigating to folders (for all artifacts that support them), the URL in your browser's address bar will change. Each folder has a unique, sharable URL that you can give to someone to display the list of artifacts with the appropriate folder selected. You can also open up multiple folders in different browser tabs and easily toggle between them from the same browser.
"},{"location":"Spira-User-Manual/Application-Wide/#workflows","title":"Workflows","text":"A number of artifacts can be controlled using workflows (these include requirements, releases, test cases, documents, risks, incidents, and tasks). Depending on the user's role and whether they are listed as the owner or author of the artifact, displayed in the info bar beneath the artifact name is the current workflow status and an Operations button. When you click this button you will see a set of allowed workflow operations - called transitions (below we are looking at that for a requirement):
These workflow transitions specify, given a starting status, which statuses you can move the artifact to. After changing the status of the artifact by clicking on a transition, the form on the overview tab may change. Different fields may be visible, enabled, or required.
For example, a requested requirement has its \"Release\" field hidden, but once the requirement is planned, that release field is visible and required. The types of change allowed and the fields that are enabled/visible/required will depend on how your product administrator has set up the workflow. Administrators should refer to the Administration Guide for details on configuring workflows.
Once you've made the changes to the appropriate artifact fields, you can either click \"Save\", \"Save and Close\", or \"Save and New\" to commit the changes or \"Refresh\" to discard the changes and reload the artifact from the database. In addition you can print the current artifact by clicking \"Print\", which will display a printable version of the page in a separate window.
Workflows are managed by the product's template. Read more about workflow administration for:
Any workflow transition (moving from one status to another) can be set to require an electronic signature. If enabled for a particular workflow operation an electronic signature is required to confirm the status change. Confirmation requires entering the users password, and a message explaining the meaning of this operation.
Workflow operations requiring a digital signature are marked with a padlock icon:
On attempting to save changes made after clicking a workflow operation that requires a digital signature you will be presented with a popup like the one below:
How to digitally sign if using OAuth
If you login to Spira using an OAuth / Single Sign On provider like Google or Okta, instead of entering your password use your RSS Key. This is visible on your My Profile page.
"},{"location":"Spira-User-Manual/Application-Wide/#emailing","title":"Emailing","text":"Using the \"Email\" button on the toolbar, you can send an email containing details of the artifact to an email address or another user on the system:
You can specify the subject line for the email, and either a list of email addresses, separated by semicolons, or an existing product user. The content of the email is specified in the product template's Notification Templates. Notification events can also be set up to automatically email users meeting specific conditions whenever a certain event happens (eg a particular field changes).
"},{"location":"Spira-User-Manual/Application-Wide/#followers","title":"Followers","text":"To be notified of any changes made to the current artifact via email, click the \"Subscribe\" button. If you already subscribed, the button will instead let you \"Unsubscribe\" to stop receiving emails about that particular artifact. Depending on your role, you may also see a dropdown arrow to the right of this button. This will let you subscribe others in the product to this artifact.
You can also quickly see who is following an artifact under the \"People\" section in the Overview tab.
To view information about the follower, or to unfollow them from the item, hover over their avatar to display a user profile card.
"},{"location":"Spira-User-Manual/Application-Wide/#overview","title":"Overview","text":"The Overview tab is divided into a number of different sections. Each of these can be collapsed or expanded by clicking on the title of that section. This tab displays information about all the main fields of the artifact, as well as descriptions, comments, and other information.
Many artifacts have a comments section that allows you to add and view discussions relating to the artifact:
Existing comments are displayed in order underneath the textbox in date order (either newest first or oldest first). To add a new comment, enter it into the textbox, and click the \"Add Comment\" button.
"},{"location":"Spira-User-Manual/Application-Wide/#comments","title":"Comments","text":"The Comments section of an artifact lets you add and view comments related to that artifact:
There are two parts to comments:
Viewing existing comments:
Adding a new comment:
Deleting comments: Users can delete comments that were made in error or that are no longer relevant. Who can delete what comments?
Note that certain system created comments \"permanent\" and cannot be deleted, even by system administrators. For example, comments are added when you create a test case from a use case and are marked as \"permanent\" behind the scenes.
"},{"location":"Spira-User-Manual/Application-Wide/#attachments","title":"Attachments","text":"The attachment tab displays the list of documents, screenshots or web-links (URLs) that have been \"attached\" to the artifact. The documents can be in any format, though SpiraPlan\u00ae will only display icons for certain known types.
The attachment list includes the filename/URL that was originally uploaded together with the file-size (in KB), name of the person who attached it and the date uploaded. In addition, if you position the pointer over the filename and hold it there for a few seconds, a detailed description is displayed as a tooltip.
To actually view the document, click on the filename hyperlink and a new web browser window will open. Depending on the type of file, this window will either display the document / web-page or prompt you for a place to save it on your local computer. To remove an existing attachment from an artifact, click the \"Remove\" button and the attachment will be removed from the list. Using the standard filter/sort options you can also sort and filter the list of attachments to make it more manageable.
If you are using SpiraPlan or SpiraTeam (but not SpiraTest) you can also choose to include file attachments stored in a linked version control system (e.g. Git, Subversion, CVS, Perforce, etc.) by selecting the \"Include Source Code Documents\" option.
To attach a new document to the artifact, you need to first click the \"Add New\" button to display the new attachment dialog box:
There are three different types of item that can be attached to an artifact:
To upload a file, choose \"File\" as the type and then click the Browse button and select the file from your local computer, optionally enter a detailed description then click the \"Upload\" button. The document will be copied from your computer and attached to the artifact.
To attach a web-link (URL) to the artifact, you need to choose \"URL\" as the type and then enter the fully qualified URL (e.g. http://mywebsite.com?Document=1), an optional description and then click the \"Upload\" button to attach the web-link.
To attach a screenshot to the artifact, you need to choose \"Screenshot\" as the type and then copy the image to your computer's clipboard (e.g. on Windows computers, the PRINT SCREEN button captures the current page and adds to the clipboard). Once the image is in the clipboard, paste it into the editor using CTRL+V (or the equivalent keystroke for your operating system) and the item will appear in the preview window. You can then fill in the other fields and click \"Upload\" to attach the image.
Note: If you are using a non-Windows\u00ae computer (e.g. Macintosh\u00ae) that doesn't put file extensions on filenames (e.g. .xls for an Excel sheet) automatically, then you will need to manually add the file extension to the filename before uploading if you want it to be displayed with the correct icon in the attachment list.
You can also associate an existing document (that's already stored in SpiraPlan) with the artifact. To do that, click on the \"Add Existing\" button to bring up the add file association dialog box:
You can then choose to either associate a document stored in the SpiraPlan Documents repository or (in the case of SpiraPlan/SpiraTeam but not SpiraTest) from the linked source code repository. In either case you first select the appropriate folder, and then pick the document(s) from the file list on the right. In the case of a source code file association you can also add a comment.
"},{"location":"Spira-User-Manual/Application-Wide/#history","title":"History","text":"This tab displays the list of changes that have been performed on the artifact since its creation. An example change history for a requirement is shown below:
The change history displays the date that each change was made, together with the fields that were changed, the old and new values and the person who made the change. This allows a complete audit trail to be maintained of all changes in the system. In addition, if you are logged in as a product administrator you can also click on the \"Admin View\" hyperlink to revert any unwanted changes.
"},{"location":"Spira-User-Manual/Application-Wide/#associations","title":"Associations","text":"You can associate artifacts to one another. For instance, you can associate (or link) one requirement to another requirement, or a test case to a risk. The following artifacts have association tabs:
From the associations tab you can see and manage the list of artifacts associated with the specific artifact you are looking at. You can even make links between artifacts across different products (if the admin has set this up). The image below shows the association tab for a requirement.
The requirements and risks in this list are those a user has decided are relevant to the current artifact. They therefore created a direct link between them.
Each association is for product level associations displayed with the:
In addition, when using SpiraPlan or SpiraTeam, the system automatically scans the source code repository for any commits, across all branches, that are linked to this artifact.
You can perform the following actions on the list of associations:
To create a new association, click the \"Add\" button to display the add association panel (below is an example from requirements):
If you know the ID of the artifact you want to associate, you can enter its ID prefixed by the appropriate token (eg \"RQ\" for requirement):
Otherwise choose the Artifact Type (and Product if making a cross-product association) from the dropdowns:
You can narrow down your search by entering a keyword:
Artifacts that have folders let you choose a folder to narrow your search. When attempting to add an association to a requirement, you can choose a parent requirement from the list to narrow down the results:
Once you have a list of artifacts, select the checkboxes of the items you want to associate with the current artifact and click the 'Save' button.
You can add a comment that explains the rationale for the association and choose the type of association being created:
What can you associate to what?
Assocation Tab Of Available artifacts Documents Requirements, Releases, Test Cases, Test Sets, Test Runs, Test Steps, Automation Hosts, Tasks, Incidents, Risks Incidents Requirements, Test Steps, Tasks, Incidents, Risks Releases Releases, Requirements Requirements Releases, Requirements, Incidents, Risks Risks Requirements, Incidents, Risks, Test Cases Source code commits Requirements, Releases, Test Cases, Test Sets, Test Runs, Test Steps, Automation Hosts, Tasks, Incidents, Risks Source code files Requirements, Releases, Test Cases, Test Sets, Test Runs, Test Steps, Automation Hosts, Tasks, Incidents, Risks Tasks Tasks, Incidents Test cases (in SpiraTeam and SpiraPlan only) Tasks, Risks Program Capabilities (SpiraPlan only) Requirements (the tab is called requirements, comments and association type not supported) Program Milestones (SpiraPlan only) Releases (the tab is called releases, comments and association type not supported)"},{"location":"Spira-User-Manual/Application-Wide/#rich-text-editor","title":"Rich Text Editor","text":"There are two ways to enter and edit text in SpiraPlan: plain text or rich text. Plain text is used for short and simple text - like artifact names, instant messages, or short notes in custom properties. When users need to enter more text and style it in a particular way, they use the built-in rich text editor. This is used for artifact descriptions and comments, as well dedicated rich text documents in the Documents Repository. Rich text fields can be as long as you need, and can replace traditional documents entirely.
SpiraPlan's rich text editor is responsive, fully featured, and intuitive to use. As such, it does not require special instruction. For information, below is a list of supported features in the rich text editor.
Formatting options:
Inserting content:
Images and screenshots
Tables using the powerful table editor. After table creation you can:
code blocks
seperator lines
Editing content: use the magnifying glass button on the toolbar to access find and replace functionality.
In many places the editor can also be made full screen to help editing of larger documents. To enter full screen mode, click on the computer monitor icon at the far right of the toolbar. Are you using dark mode? No problem - the editor works great in dark mode.
"},{"location":"Spira-User-Manual/Application-Wide/#beta-boards","title":"Beta Boards","text":"In beta, available in SpiraTeam and SpiraPlan
System admins can enable beta functionality across the application for their users from the System Admin > General Settings page.
To access the beta board, navigate to the relevant board as normal. This loads the standard planning or artifact board. Then click on the \"Try the Beta\" button the top-right to go to the new beta board.
You will now stay on the beta boards for the remainder of your session. To leave the beta, click on \"Exit the Beta\". This will return you to the old boards.
"},{"location":"Spira-User-Manual/Application-Wide/#page-structure","title":"Page Structure","text":"The beta boards are designed to provide a consistent user interface across its different views and:
The board pages are structured like this (in this example we are looking at the Planning Board but the high level features and layout is consistent across all boards):
Boards have the option to have multiple, separate boards displayed. This is used when you want to display a complete board for each item in a selection (for example each release). Inside each group, the rows and columns will show based on your selections. For example, when you are displaying the Release Backlog on the Planning Board, you may want to group by release. In the screenshot below of the Planning Board we have columns set to status, and rows to component
There are buttons in the header area of each group that let you:
Additionally, at the top of all the groups, there are buttons to expand/collapse all groups at once.
"},{"location":"Spira-User-Manual/Application-Wide/#board-columns","title":"Board Columns","text":"Inside each of the boards you can choose to organize the cards by column. Unlike groups and rows, this selection is required. For example, in the screenshot below we are displaying the Planning Board's product backlog with columns set to \"priority\".
There are no expand/collapse buttons for columns.
"},{"location":"Spira-User-Manual/Application-Wide/#board-rows","title":"Board Rows","text":"Inside each of the boards you can organize the cards into rows. This is optional. For example, in the screenshot below we are displaying the Planning Board' product backlog with rows set to \"parent\". In the example, the grouping is by component and the board is smart enough to know that it should only show you those parents in rows that are tagged with that component (so different component groups will show different parent requirements as their rows).
Note that when rows is set to parent / parent requirement, rows are also included for parents with no unplanned children.
There are buttons by the title of each row that let you expand/collapse that row.
"},{"location":"Spira-User-Manual/Application-Wide/#board-viewing-by-release-or-sprint","title":"Board Viewing by release or sprint","text":"When organizing by release or sprint there are a number of special features available in the header row (where you see the release/sprint name).
The group title will show additional information about the release or sprint on the right hand side of the group header. Hover on the group header to see this information in full. This shows:
When you move a card between releases or sprints, the fields described above may be recalculated. For effort fields, all child tasks of requirements in that release/sprint are used for calculations. For example, moving a requirement on a board into a sprint will increase the sprint's utilized effort by the hours of the relevant tasks in that requirement, and decrease the sprint's remaining effort by the same amount.
"},{"location":"Spira-User-Manual/Application-Wide/#board-viewing-by-person","title":"Board Viewing by Person","text":"When organizing by person there are a number of special features available in the header row (where you see the person's name).
Grouping by team and rows by person
When grouping by team, there is one group for every team. If rows is set to \"by person\", then within each team, all members of that team are shown. So if Amy is a member of the dev team, they will have a row in the dev team group and not in any other group.
"},{"location":"Spira-User-Manual/Application-Wide/#board-what-cards-show-when","title":"Board what cards show when","text":"What cards show on the board depends on how the viewing controls are set. In additional the following broad principles apply:
requirement cards:
Cards can be moved between any cell on the board a card is currently in. You can also move cards between groups, if you are grouping by a particular field. Moving a card updates all relevant fields about that item. For instance, moving a card to a different row and column will change that cards values for both fields at once.
You can also move cards within a cell to change their order. When you drop a card, it will be inserted between the relevant cards in the cell, or at the top or bottom of the list. Moving a card between cells and dropping the card within a list of cards will place the card in that exact position.
Click on a card to select it. Click on more cards to add them to your selection. Then click and drag on any selected to move them together.
Things to be aware of
Cards are disabled (cannot be moved) if any of the following are true:
Viewing cards: to view more information about the card you can click on the card's name to open a popup with much more detail; or ctrl/cmd+click on the card's name to open the full details page for that artifact. Information shown in the popup includes all standard and custom fields with fields being shown or hidden based on the workflow step that applies to that specific card. Users who cannot bulk edit the artifact but who can add comments can add comments when viewing the card.
Editing cards: users with bulk edit permissions can edit a planning board card at any time by clicking on the card's name (this includes letting you add a new comment). This opens a popup with full information about that card. At all times, which fields are shown, required, or hidden is based on the workflow step that applies to that specific card. To save any changes you must fill in all required fields. Please note: you cannot change the status in this edit mode, to do so open the artifact's detail page (you can do this from the popup by clicking the button next to the artifact's id at the top).
Add new cards: if you are able to create the primary artifact for a board (e.g. requirements on the Planning Board) then you will see plus (add) symbols at the top of each cell of the board. Clicking any of these will open a popup screen with all relevant fields available. Some of these fields may be pre-populated based on what cell you click the add button for. For instance, if your cell is for a specific status and release, both of those fields will preselected. The fields visible and required is driven based on what workflow step will apply to that new card.
"},{"location":"Spira-User-Manual/Automation-Host-Management/","title":"Automation Host Management","text":""},{"location":"Spira-User-Manual/Automation-Host-Management/#automation-host-list","title":"Automation Host List","text":"This section outlines how to use the Automation Host Management features of SpiraPlan\u00ae to manage the different host systems that will be running automated tests in your environment. Typically when scheduling automated tests you will want to execute the same tests on multiple computers running different environments.
SpiraPlan allows you to build a master list of automation hosts in each product, which can be used to schedule test sets containing automated test cases against.
When you click on the Testing > Automation Hosts global navigation link, you will open the automation host list page:
The automation host list screen displays all the automation hosts entered for the current product, in a filterable, sortable grid. The grid displays the automation host ID together with fields such as name, description, last updated date, token, and any custom properties. The choice of columns displayed is configurable per-user, per-product, giving extensive flexibility when it comes to viewing and searching automation hosts.
In addition, you can view a more detailed description of the automation host by positioning the mouse pointer over the host name hyperlink and waiting for the popup \"tooltip\" to appear. If you click on the host name hyperlink, you will be taken to the automation host details page. Clicking on any of the pagination links at the bottom of the page will advance you to the next set of hosts in the list according to the applied filter and sort-order. There is also a drop-down-list at the bottom of the page which allows you to specify how many rows should be displayed in each page, helping accommodate different user preferences.
One special column that is unique to automation hosts is the \"Token\" field. This needs to contain a short textual identifier that uniquely identifies each automation host in the product. This will be used by each host computer to identify itself to SpiraPlan.
"},{"location":"Spira-User-Manual/Automation-Host-Management/#filtering-sorting","title":"Filtering & Sorting","text":"Read about how to create and manage filters, and how to sort the artifact list.
"},{"location":"Spira-User-Manual/Automation-Host-Management/#new-host","title":"New Host","text":"Clicking on the \"New Host\" button adds a new automation host to the bottom of the automation host list with a default name and token.
"},{"location":"Spira-User-Manual/Automation-Host-Management/#delete","title":"Delete","text":"Clicking on the \"Delete\" button deletes the automation hosts whose check-boxes have been selected in the host list.
"},{"location":"Spira-User-Manual/Automation-Host-Management/#refresh","title":"Refresh","text":"Clicking on the \"Refresh\" button reloads the list of automation hosts; this is useful when new hosts are being added by other users, and you want to make sure you have the most up-to-date list displayed.
"},{"location":"Spira-User-Manual/Automation-Host-Management/#show-hide-columns","title":"Show / Hide Columns","text":"This drop-down list allows you to change the fields that are displayed in the host list as columns for the current product. To show a column that is not already displayed, simply select that column from the list of \"Show...\" column names and to hide an existing column, simply select that column from the list of \"Hide...\" column names. This is stored on a per-product basis, so you can have different display settings for each product that you are a member of. The fields can be any of the built-in fields or any of the custom properties set up by the product owner.
"},{"location":"Spira-User-Manual/Automation-Host-Management/#edit","title":"Edit","text":"Each automation host in the list has an \"Edit\" button in its right-most column. When you click this button or just double-click on any of the cells in the row, you change the item from \"View\" mode to \"Edit\" mode. The various columns are made editable, and \"Save\" buttons are displayed in the last column.
If you click \"Edit\" on more than one row, the \"Save\" buttons are only displayed on the first row, and you can make changes to all the editable rows and then update the changes by clicking the one \"Save\" button. Also, if you want to make the same change to multiple rows (e.g. to change five automation hosts from Active = No to Active = Yes), you can click on the \"fill\" icon to the right of the editable item, which will propagate the new value to all editable items in the same column.
If you want to edit lots of items, first select their checkboxes and then click the \"Edit\" button on the same row as the Filters and it will switch all the selected items into edit mode.
When you have made your updates, you can either click \"Save\"to commit the changes, or \"Cancel\" to revert back to the original information. Alternatively, pressing the <ENTER> key will commit the changes and pressing the <ESCAPE> key will cancel the changes.
"},{"location":"Spira-User-Manual/Automation-Host-Management/#automation-host-details","title":"Automation Host Details","text":"When you click on an automation host entry in the host list, you are taken to the automation host details page illustrated below:
This page is made up of three areas; the left pane is the navigation window, the upper part of the right pane contains the automation host name and ID, and the bottom part of the right pane displays different information associated with the automation host.
The navigation pane consists of a link that will take you back to the host list, as well as a list of the peer automation hosts to the one selected. This latter list is useful as a navigation shortcut; you can quickly view the peer hosts by clicking on the navigation links without having to first return to the host list page. The navigation list can be switched between two different modes:
The list of hosts matching the current filter
The list of all hosts, irrespective of the current filter
The top part of the right pane allows you to view and/or edit the details of the particular automation host. You can edit the various fields (name, description, token, etc.) and custom properties. Once you are satisfied with the changes, click either the \"Save\" button or the alternative options from the \"Save\" dropdown list. In addition you can delete the current automation host by clicking \"Delete\", or discard any changes made by clicking \"Refresh\".
"},{"location":"Spira-User-Manual/Automation-Host-Management/#overview","title":"Overview","text":"This tab shows the fields and description associated with the automation host. Standard and custom fields are grouped by type (eg all date and time fields are grouped together).
"},{"location":"Spira-User-Manual/Automation-Host-Management/#test-runs","title":"Test Runs","text":"This tab displays the list of all the test runs executed against the automation host. Each test run is listed together with the date of execution, the name of the test case, the name of the tester, the release/version of the system that the test was executed against, the name of the test set (if applicable), the overall execution status for the test case in that run and a link to the actual test run details. In addition, you can choose to display any of the custom properties associated with the test run.
The \"Show/hide columns\" drop-down list allows you to change the fields that are displayed in the test run list as columns. To show a column that is not already displayed, simply select that column from the list of \"Show...\" column names and to hide an existing column, simply select that column from the list of \"Hide...\" column names. The displayed columns can be any standard field or custom property.
You can also filter the results by choosing items from the filter options displayed in the sub-header row of each field and clicking the \"Filter\" button. In addition, you can quickly sort the list by clicking on one of the directional arrow icons displayed in the header row of the appropriate field.
"},{"location":"Spira-User-Manual/Automation-Host-Management/#attachments","title":"Attachments","text":"Read about how the attachments tab works
"},{"location":"Spira-User-Manual/Automation-Host-Management/#history","title":"History","text":"Read about how the history tab works
"},{"location":"Spira-User-Manual/Commits/","title":"Commits","text":"Go here to read about how to connect your source code to your SpiraPlan product.
"},{"location":"Spira-User-Manual/Commits/#linking-to-artifacts-in-commit-messages","title":"Linking To Artifacts In Commit Messages","text":"When developers are working on source code, it is often to fix a bug, create a feature described in a user story, or deal with a task. SpiraPlan lets you trace what commits (and therefore file changes) contributed to a bug fix. To do this SpiraPlan reads commit messages for special tokens that it turns into links between the commit and those artifacts. If SpiraPlan finds any links in the commit message it automatically creates the association between the commit and the artifact(s). You can view these associations from the commit details page, or from the associations tab of any artifact.
How does this work? The commit message has to contain one or more artifact token. For example [TK:123], or [IN:456], or [RQ:789]. These tokens are short and do not get in the way of the rest of the commit message. Artifact tokens are in the following format: [{artifact identifier}:{artifact id}]
The first half of the token is a two-letter code, used throughout SpiraPlan and visible on almost every page in the application. For example, a requirement's identifier is \"RQ\". Incidents are \"IN\", and test cases are \"TC\". The artifact ID is the number of the artifact. If you go to the details page for an artifact, you will always see this artifact token near the top of the page. Clicking on it copies it to your clipboard. Then you can paste it into your commit message.
Note: If you forget to add the association during the commit, go to the details page for that commit in SpiraPlan, and click 'Add Association' to add the association at any time.
"},{"location":"Spira-User-Manual/Commits/#commit-list","title":"Commit List","text":"When you click on Developing > Commits on the global navigation bar, you will be taken to the commits list screen. This shows you all commits in the current branch. You can change the branch, sort and filter this list, or browse the different pages of commits (up to 500 commits can be displayed on the page at any one time).
Above the list of commits is the action toolbar. This lets you perform the following functions:
For each commit you can see the following information (you can sort or filter on all of these):
When you click on a commit link (for example, from the commit list), you open the commit details page for that commit. This page shows you information about the commit, the files it includes, the branches it appears in, and other artifacts it is associated with.
The page is made up of two areas:
The detailed information available at the top of the page is the:
There are 3 tabs on this page that each show additional information about the commit. These are discussed below.
"},{"location":"Spira-User-Manual/Commits/#files","title":"Files","text":"This shows the list of files changed in this commit. You can sort or filter the list by any of its columns:
This shows the list of all branches that the commit appears in, listed in alphabetical order. Clicking on a branch changes your selected branch to that branch.
A commit exists in any branch that was made from the branch the commit was originally committed in, and that was made after this commit. There is no single \"original\" or \"main\" branch for a commit, because all the different git branches are considered equal. Deleted branches are not shown.
"},{"location":"Spira-User-Manual/Commits/#associations","title":"Associations","text":"This shows all current associations between this commit and any artifacts in SpiraPlan. This lets you to see which requirements, test cases, incidents, tasks, etc. are linked to the commit. Clicking on the artifact name will take you to the appropriate artifact page (assuming your user has permissions to access that information).
You can also add artifact associations to many other artifacts in the system from this panel. Read more about how to manage and add associations to this artifact.
"},{"location":"Spira-User-Manual/Commits/#commit-file-details","title":"Commit File Details","text":"Files are changed as source code develops. Each commit adds or changes or removes files. This pages allows you to see exactly how a file was changed between one commit and the next. For example, you could see that one function was added, and that another line of code was deleted. Or you can see how an image file looked before and after the commit.
SpiraPlan supports showing before and after previews of all file types that it can show previews for elsewhere in the application (for example, text files and images). For text files (things like code, markdown, and plain text), SpiraPlan will also show a line by line comparison of both file versions.
This page is made up of three areas:
the bottom of the left-hand pane shows the currently selected branch, and the other commits in this branch that changed the file currently being viewed (the icon represents the commit action for this file). Newer commits are at the top.
the right-hand pane shows detailed information about the file for the particular commit. This pane is discussed more below.
The detailed information available at the top of the page is:
There are 3 tabs on this page that each show additional information about the file at the specific commit. These are discussed below.
"},{"location":"Spira-User-Manual/Commits/#changes","title":"Changes","text":"This shows you, for support file types (text files), the line by line changes that were made to the file in this commit. Above the diff view you can see:
Each line that changed is highlighted based off the sort of edit that was made, and a symbol in the left hand gutter shows this too. Line numbers are also displayed. In the unified view (shown above) lines are either added or removed (shown in green or red; and with a \"+\" or \"-\" gutter symbol respectively).
In the split view (shown above) lines can be marked as added, deleted, or edited (shown in green, red, or blue; and with a \"+\", \"-\", or \"~\" gutter symbol respectively). In split, where a line was edited, we highlight the specific parts of the line that were changed.
"},{"location":"Spira-User-Manual/Commits/#previous-commit","title":"Previous Commit","text":"This shows you the preview of the complete file as it was at the previous commit (the commit name is shown in the tab label). Image files as well as text files are previewed. Markdown files are shown as rendered HTML.
"},{"location":"Spira-User-Manual/Commits/#current-commit","title":"Current Commit","text":"This shows you the preview of the complete file as it was at the commit currently being viewed (the commit name is shown in the tab label). Image files as well as text files are previewed. Markdown files are shown as rendered HTML.
Note: The first commit for a file adds the entire file. So when viewing the file at that first commit, you will only see this \"Current Commit\" tab, with a full preview of the file that was added in that commit.
Some older source code management systems (e.g. CVS, Visual SourceSafe) do not have the formal concept of branches, so the dropdown list will simply list the one main branch (usually called \"Trunk\").\u00a0\u21a9
This section outlines the document management features of SpiraPlan\u00ae that can be used to upload, manage, edit, and share documents between product members. This module includes support for:
Document management is fully integrated into the rest of the system: you can attach documents to other artifacts (e.g. requirements, test cases, etc.) and any ones you add on an artifact (including screenshots) are automatically connected to the product documentation repository.
"},{"location":"Spira-User-Manual/Document-Management/#document-list","title":"Document List","text":"When you choose the Documents artifact from the global navigation bar, you open the product documents list screen illustrated below:
This screen is made up of three sections:
The main toolbar has operations you can perform on the document list or selected documents. You can:
Read about how to create and manage filters, and how to sort the artifact list.
"},{"location":"Spira-User-Manual/Document-Management/#add-new-document","title":"Add New Document","text":"To create a new document, click the Add New button. This opens the \"Add New Document\" dialog box for uploading a single file (not multiple). Drag and drop a file onto the upload box, or click to browse for a file on your device. Each type of \"Add New Document\" dialog (see below) will let you:
The Add New button has a dropdown with more options - each option shows you a slightly different dialog box (the bottom part is the same but the top part differs).
Add New button itself): for uploading a fileNote: If you are using a non-Windows\u00ae computer (e.g. Macintosh\u00ae) that doesn't put file extensions on filenames (e.g. .xls for an Excel sheet) automatically, then you will need to manually add the file extension to the filename before uploading if you want it to be displayed with the correct icon in the attachment list.
"},{"location":"Spira-User-Manual/Document-Management/#add-new-inline-documents","title":"Add New Inline Documents","text":"The Add New dropdown has options for creating several files that are not uploaded at all. Instead you choose a file name (and enter description and tag and type information), then when you click \"Add\" you are taken straight to the blank document, so you can start editing it live inside SpiraPlan itself from the document details page.
When you hover the mouse pointer over any of the documents displayed in the document list, an information panel will be displayed that contains the name, description, version, document type and meta-tags of the document.
You can click on the document URL to actually open the document itself in a new window, click on the meta-tag links to find related documents that contain the same meta-tag, or click on \"View Details\" to see more information regarding the document, including an ability to edit its meta-information and see the different versions of the document.
"},{"location":"Spira-User-Manual/Document-Management/#edit-document-folders","title":"Edit Document Folders","text":"If you are a product administrator, you will see the \"Edit\" and \"Add\" buttons beneath the folder tree:
This lets you add, edit and delete task folders in the product. To add a new folder, click the \"Add\" button:
Choose the parent folder that you want to add the new folder under (or None if you are adding a new top-level folder) from the dropdown list and then enter the name of the new folder. Then click 'Add' save the new folder.
To edit or delete an existing folder, click the 'Edit' button to switch the folder tree to edit mode:
To edit or delete a specific folder, click on the 'Edit' button next to the folder:
You can change the parent folder and/or name of the folder and click \"Update\" to commit the change or click \"Delete\" to delete the folder entirely (including its contents).1
"},{"location":"Spira-User-Manual/Document-Management/#document-details","title":"Document Details","text":"When you click on an item in the document list described above, you are taken to the document details page illustrated below:
This page is made up of three areas;
Refresh.Please note that on smaller screen sizes the navigation pane is not displayed. While the navigation pane has a link to take you back to the documents list, on mobile devices a 'back' button is shown on the left of the operations toolbar.
The navigation pane can be collapsed by clicking on the \"-\" button, or expanded by clicking anywhere on the gray title area. On desktops the user can also control the exact width of the navigation pane by dragging and dropping a red handle that appears on hovering at the rightmost edge of the navigation pane.
The navigation pane consists of a link that will take you back to the product document list, as well as a list of other documents in the current folder. This latter list is useful as a navigation shortcut; you can quickly view the detailed information of all the peer documents by clicking on the navigation links without having to first return to the main document list page.
"},{"location":"Spira-User-Manual/Document-Management/#emailing","title":"Emailing","text":"Read about emailing a document to colleagues using Spira.
"},{"location":"Spira-User-Manual/Document-Management/#followers","title":"Followers","text":"Read about how to add and manage followers to an artifact.
"},{"location":"Spira-User-Manual/Document-Management/#workflows","title":"Workflows","text":"Read about using workflows to change the status of your document.
For documents, you can, depending on how the product administrator has set this up, use workflows to control who can add a new version to a document when. This can be useful for \"checking-out\" a document, during which time it is locked. When the document is checked back in the workflow can require that the person checking in the document upload a new version (make sure you upload the version before changing the status).
"},{"location":"Spira-User-Manual/Document-Management/#preview","title":"View","text":"This tab shows the currently active version of the document. You can view the document contents here for many different file types (notably plain text files, code files, feature/BDD files, rich text html documents, spreadsheets, diagrams (including mindmaps and org charts), and images).
If a format cannot be previewed (for example a PDF or Microsoft Word document), the following message is displayed:
When viewing diagrams, mindmaps, or orgcharts there is a button above the diagram that you let you directly download an SVG of the diagram (you can download the diagram from the Versions tab but this downloads the raw data, not a formatted diagram).
"},{"location":"Spira-User-Manual/Document-Management/#edit","title":"Edit","text":"When you create a new inline document the document opens to this tab, showing you the blank document. Make your changes by either:
Click Save to save the document and automatically create a new version (this version becomes the new active version). You can change the document from the Edit tab at any time (if allowed by the workflow and permissions).
You can only create inline documents from the list page for a few file formats, but there are many other file types that, once uploaded, can be edited inline. These include plain text file, including code files.
The Edit tab will show the text, but it is not fully formatted. Go to the view tab to see the formatted view with syntax highlighting applied.
"},{"location":"Spira-User-Manual/Document-Management/#editing-diagrams","title":"Editing Diagrams","text":"SpiraPlan supports three types of diagrams:
When editing any diagram, you will see a simple toolbar above the editing area. This toolbar lets:
The picker (diagrams only) shows all available objects available that you can add to your diagram. To add a new object, click on it from the picker, or drag it from the picker into the editor area. There are three types of object:
The editor area shows the diagram with all its nodes or shapes and connections. The diagram will be effectively identical to how it looks on the View tab. The main different being the dot grid background pattern in the editor area. The editor area lets you:
The formatting palette shows you all ways you can format a selected shape. The options available will vary based on which diagram type is being edited. In general you can edit a shape's:
When editing a diagram type you can also select a specific connector and edit its:
The SpiraPlan spreadsheet is a feature rich spreadsheet application that supports many common spreadsheet features. It is intuitive and easy to use, and should feel immediately familiar. It can work as a full spreadsheet replacement for a wide variety of use cases, with the benefit of all the data and versioning living directly inside Spira. Please note that the spreadsheet is not as powerful as desktop or dedicated web apps and will not be the best solution for handling things like very large data sets, or complex models.
Spreadsheet features:
Importing from and exporting to Excel: Go to
Formulas (including across sheets): work as in other spreadsheet applications. Here is a simple example to sum three cells: =sum(A1:A3). See our full guide to all supported functions below.
Formatting: use the menu to change
Rows and columns: add, remove, and resize
Locking cells: Right-click a cell/a range of cells you want to lock/unlock. Choose the Lock/Unlock cell option in the appeared context menu.
Data validation (to create a drop-down list):
Common keyboard shortcuts for things like undo, redo, copy, paste
This tab allows you to view and/or edit the document's details (thinks like the description, author, tags, any custom fields). Make any changes and then click Save to commit the changes.
Read about how the comments works
"},{"location":"Spira-User-Manual/Document-Management/#document-versions","title":"Document Versions","text":"This tab displays the list all the different versions that exist for the current document. When you first create a new document there will be only a single version (e.g. v1.0). As you change and update the document you do not need to create a whole new document. Instead, upload new versions or edit the document inline (if possible). This will create new versions of the file - you can have as many versions as you need and should give each a unique version number to help track them.
Each version in the list is displayed with its:
One version will have a checkmark in the Active column. This is the currently active version - this is the version users see when they open the document (including the preview on the view tab). All other versions will have two buttons in the Operations column: \"Delete\" (to completely remove that version) and \"Make Active\" (to switch the active version to this version).
To upload a new version click the 'Upload New Version' hyperlink:
In the popup dialog, you need to drag the file to be uploaded onto the upload icon (or click on the icon to browse to the file), enter a description of the changes made, a new version number and whether the new version should be made the active one, then click the Upload button to confirm the changes.
Note: This option is only available for files. You cannot add a new URL version or change the URL.
"},{"location":"Spira-User-Manual/Document-Management/#associations","title":"Associations","text":"You can associate a document to many other artifacts in the system from this tab. If you originally uploaded the document as an attachment to an artifact, then the initial association will be already listed. Read more about how to manage and add associations to this artifact
"},{"location":"Spira-User-Manual/Document-Management/#attachments","title":"Attachments","text":"Read about how the attachment tab works
"},{"location":"Spira-User-Manual/Document-Management/#history","title":"History","text":"Read about how the history tab works
"},{"location":"Spira-User-Manual/Document-Management/#annex-of-spreadsheet-functions","title":"Annex of Spreadsheet Functions","text":""},{"location":"Spira-User-Manual/Document-Management/#boolean-operators","title":"Boolean operators","text":"You can compare two values via using logical expressions that in any given case will only return either TRUE or FALSE.
Operator Example Description = =A1=B1 Returns TRUE if the value in cell A1 is equal to the value in cell B1; otherwise, FALSE. <> =A1<>B1 Returns TRUE if the value in cell A1 is not equal to the value in cell B1; otherwise, FALSE. > =A1>B1 Returns TRUE if the value in cell A1 is greater than the value in cell B1; otherwise, FALSE. < =A1<B1 Returns TRUE if the value in cell A1 is less than the value in cell B1; otherwise, FALSE. >= =A1>=B1 Returns TRUE if the value in cell A1 is greater than or equal to the value in cell B1; otherwise, FALSE. <= =A1<=B1 Returns TRUE if the value in cell A1 is less than or equal to the value in cell B1; otherwise, FALSE."},{"location":"Spira-User-Manual/Document-Management/#date-functions","title":"Date functions","text":"Function Formula Description DATE =DATE(year,month,day) Combines three separate values (year, month, and day) and returns a date. DATEDIF =DATEDIF(start_date,end_date,unit) Returns the number of days, months, or years between two dates. The unit argument is used to define which type of information you want returned. DATEVALUE =DATEVALUE(date_text) Converts a date that is stored as text to a serial number. DAY =DAY(date) Returns the day of the month as a number between 1 to 31 from a specified date. DAYS =DAYS(end_date, start_date) Returns the number of days between two dates. DAYS360 =DAYS360(start_date,end_date,[method]]) Returns the number of days between 2 dates, based on a 360-day year (twelve 30-days months). EDATE =EDATE(start_date, months) Returns the date on the same date of the month, n months in the past or future. EOMONTH =EOMONTH(start_date, months) Returns the date for the last day of the month, n months before or after the specified start date. ISOWEEKNUM =ISOWEEKNUM(date) Returns the number of the ISO week number of the year for the specified date. MONTH =MONTH(date) Returns the month of the year of the specified date. NETWORKDAYS =NETWORKDAYS(start_date, end_date, [holidays]) Returns the number of whole working days between two dates. Working days exclude weekends and any dates specified in holidays. NETWORKDAYSINTL =NETWORKDAYSINTL(start_date, end_date, [weekend], [holidays]) Returns the number of whole working days between two dates. The optional weekend parameter is used to specify which days of the week are considered weekends. Weekend days and holidays are not considered as workdays. NOW =NOW() Returns the current date. TIMEVALUE added in v4.3 =TIMEVALUE(time_text) Returns the decimal number of the time represented by a text string WEEKDAY =WEEKDAY(date,[return_type]) Returns the day of the week for the specified date. The return_type argument is used to define which day of the week is considered the first day. WEEKNUM =WEEKNUM(date,[return_type]) Returns the week number for the specified date. The return_type argument is used to define which day of the week is considered the first day. WORKDAY =WORKDAY(start_date, days, [holidays]) Returns the date of the nearest working day n days in the future or past. Working days exclude weekends and any dates specified in holidays. WORKDAYINTL =WORKDAYINTL(start_date, days, [weekend], [holidays]) Returns the date of the nearest working day n days in the future or past. The optional weekend parameter is used to specify which days of the week are considered weekends. Weekend days and holidays are not considered as workdays. YEAR =YEAR(date) Returns the year of the specified date. YEARFRAC =YEARFRAC(start_date, end_date, [basis]) Returns the year of the specified date. The optional basis argument is used to define the type of day count basis."},{"location":"Spira-User-Manual/Document-Management/#financial-functions","title":"Financial functions","text":"Function Formula Description ACCRINT =ACCRINT(issue, id, sd, rate, par, frequency, [basis], [calc_method]), where:* issue - the issue date of the security;* id - the security's first interest date;* sd - the security's settlement date;* rate - the security's annual coupon rate;* par - the security's par value, $1,000 by default;* frequency - the number of coupon payments per year (1 for annual payments);* basis - optional, the type of day count basis to use;* calc_method - optional, the way to calculate the total accrued interest when the date of settlement is later than the date of first interest (0 or 1(default)). Returns the accrued interest for a security that pays periodic interest. BINOM.DIST added in v4.3 =BINOM.DIST(number_s, trials, probability_s, cumulative), where:* number_s - the number of successes in trials;* trials - the number of independent trials;* probability_s - the probability of success on each trial;* cumulative - if TRUE, then BINOM.DIST returns the cumulative distribution function; if FALSE (use 0), it returns the probability mass function. Returns the individual term binomial distribution probability. BINOM.DIST.RANGE added in v4.3 =BINOM.DIST.RANGE(trials, probability_s, number_s, [number_s2]), where:* trials - the number of independent trials (must be \u2265 0);* probability_s - the probability of success in each trial (must be \u2265 0 and \u2264 1);* number_s - the number of successes in trials (must be \u2265 0 and \u2264 trials);* number_s2 - optional. If provided, returns the probability that the number of successful trials will fall between number_s and number_s2 ([number_s2] must be \u2265 number_s and \u2264 trials). Returns the probability of a trial result using a binomial distribution. BINOM.INV added in v4.3 =BINOM.INV(trials, probability_s, alpha), where:* trials - the number of Bernoulli trials;* probability_s - the probability of success in each trial (must be \u2265 0 and \u2264 1);* alpha - the criterion value (must be \u2265 0 and \u2264 1); Returns the smallest value for which the cumulative binomial distribution is greater than or equal to a criterion value. BITLSHIFT added in v4.3 =BITLSHIFT(number, shift_amount), where:* number - the number to be shifted (must be an integer greater than or equal to 0)* shift_amount - the amount of bits to shift, if negative, shifts bits to the right instead Returns a number shifted left by the specified number of bits. BITOR added in v4.3 =BITOR(number1, number2), where:* number1 - a decimal number (must be greater than or equal to 0 and no larger than 2^48 - 1);* number2 - a decimal number (must be greater than or equal to 0 and no larger than 2^48 - 1); Returns a decimal number representing the bitwise OR of two numbers. BITRSHIFT added in v4.3 =BITRSHIFT(number, shift_amount), where:* number - the number to be shifted (must be an integer greater than or equal to 0);* shift_amount - the amount of bits to shift, if negative shifts bits to the left instead; Returns a number shifted right by the specified number of bits. BITXOR added in v4.3 =BITXOR(number1, number2), where:* number1 - a decimal number (must be greater than or equal to 0 and no larger than 2^48 - 1);* number2 - a decimal number (must be greater than or equal to 0 and no larger than 2^48 - 1); Returns a decimal number representing the bitwise XOR of two numbers. COMPLEX added in v4.3 =COMPLEX(real_num, i_num, [suffix]), where:* real_num - the real coefficient of the complex number;* i_num - the imaginary coefficient of the complex number;* suffix - optional (\"i\" by default) - the suffix for the imaginary component of the complex number; (must be lowercase \"i\" or \"j\") . Converts real and imaginary coefficients into a complex number of the form x + yi or x + yj. CORREL added in v4.3 =CORREL(array1, array2), where:* array1 - a range of cell values;* array2 - a second range of cell values; Text, logical values, or empty cells are ignored. Cells with zero values are included. The arrays must have equal number of data points. Returns the correlation coefficient of two cell ranges. COVAR added in v4.3 =COVAR(array1, array2), where:* array1 - The first cell range of integers;* array2 - The second cell range of integers; Text, logical values, or empty cells are ignored. Cells with zero values are included. The arrays must have equal number of data points. Returns covariance, the average of the products of deviations for each data point pair in two data sets. COVARIANCE.P added in v4.3 =COVARIANCE.P(array1, array2), where:* array1 - The first cell range of integers;* array2 - The second cell range of integers; Text, logical values, or empty cells are ignored. Cells with zero values are included. The arrays must have equal number of data points. Returns population covariance, the average of the products of deviations for each data point pair in two data sets. COVARIANCE.S added in v4.3 =COVARIANCE.S(array1, array2), where:* array1 - The first cell range of integers;* array2 - The second cell range of integers; Text, logical values, or empty cells are ignored. Cells with zero values are included. The arrays must have equal number of data points. Returns the sample covariance, the average of the products of deviations for each data point pair in two data sets. DB =DB(cost, salvage, life, period, [month]), where:* cost - the initial cost of the asset;* salvage - the value of the asset at the end of the depreciation;* life - the number of periods over which the asset is being depreciated;* period - the period to calculate depreciation for;* month - optional, the number of months in the first year, 12 by default. Calculates the depreciation of an asset for a specified period using the fixed-declining balance method. DDB =DDB(cost, salvage, life, period, [factor]), where:* cost - the initial cost of the asset;* salvage - the value of the asset at the end of the depreciation;* life - the number of periods over which the asset is being depreciated;* period - the period to calculate depreciation for;* factor - optional, the rate at which the balance declines, 2 (the double-declining balance method) by default Calculates the depreciation of an asset for a specified period using the double-declining balance method or another method you specify. DEC2BIN added in v4.3 =DEC2BIN(number), where:* number - the decimal integer you want to convert (must be greater than -512 but less than 511); Converts a decimal number to binary. DEC2HEX added in v4.3 =DEC2HEX(number), where:* number - the decimal integer you want to convert (must be greater than -549755813888 but less than 549755813887); Converts a decimal number to hexadecimal. DEC2OCT added in v4.3 =DEC2OCT(number), where:* number - the decimal integer you want to convert (must be greater than -536870912 but less than 536870911); Converts a decimal number to octal. DELTA added in v4.3 =DELTA(number1, [number2]), where:* number1 - the first number;* number2 - optional, the second number. If omitted, number2 is assumed to be zero. Tests two numbers for equality. Returns 1 if number1 = number2; returns 0 otherwise. DEVSQ added in v4.3 =DEVSQ(number1, [number2], ...), where:* number1, number2,... - from 1 to 255 arguments for which you want to calculate the sum of squared deviations; Text, logical values, or empty cells are ignored. Cells with zero values are included. Returns the sum of squares of deviations of data points from their sample mean. DOLLARDE =DOLLARDE(fractional_dollar, fraction) Converts a dollar price specified as an integer part and a fraction part into a dollar price displayed as a decimal number. DOLLARFR =DOLLARFR(decimal_dollar, fraction) Converts a decimal number into fractional dollar number. EFFECT =EFFECT(nominal_rate, npery) nominal_rate must be >= 0, npery must be > 1. Returns the effective annual interest rate on the base of the nominal annual interest rate and the number of compounding periods per year you specify. Works with numeric values. ERF added in v4.3 =ERF(lower_limit, [upper_limit]), where:* lower_limit - the lower bound for integrating ERF;* upper_limit - the upper bound for integrating ERF. If omitted, ERF integrates between 0 and lower_limit. Returns the error function integrated between lower_limit and upper_limit. ERFC added in v4.3 =ERFC(x), where:* x - the lower bound for integrating ERFC Returns the complementary ERF function integrated between x and infinity. EXP added in v4.3 =EXP(number), where:* number - the power that e is raised to Returns the result of the constant e (which equals 2.71828182845904) raised to the power of a number. FISHER added in v4.3 =FISHER(x), where:* x - the value for which you want to calculate the transformation Calculates the Fisher transformation for a supplied value. FISHERINV added in v4.3 =FISHERINV(y), where:* y - the value for which you want to perform the inverse of the transformation Calculates the inverse of the Fisher transformation and returns a value between -1 and +1. FV =FV(rate, nper, pmt, [pv], [type]), where:* rate - the interest rate per period. For monthly payments, rate = rate/12;* nper - the total number of payment periods in an annuity. For monthly payments, nper=nper*12;* pmt - the payment made each period;* pv - optional, the present value, or the lump-sum amount that a series of future payments is worth right now, 0 by default;* type - optional, 0(default) - the payments are due at the end of the period, 1 - at the beginning of the period. Calculates the future value of an investment. FVSCHEDULE =FVSCHEDULE(principal, schedule), where:* principal - the present value;* schedule - an array of interest rates to apply. The values in the array can be numbers or blank cells; any other value produces the error value. Blank cells are taken as zeros. Returns the future value of an initial principal (=present value) after applying a series of compound interest rates. GAMMA added in v4.3 =GAMMA(number) If Number is a negative integer or 0, GAMMA returns the #Error value. Returns the gamma function value. GEOMEAN added in v4.3 =GEOMEAN(number1, [number2], ...) where:* number1, number2,... - from 1 to 255 arguments for which you want to calculate the mean; Text, logical values, or empty cells are ignored. Cells with zero values are included. Returns the geometric mean of an array or range of positive data. GESTEP added in v4.3 =GESTEP(number, [step]) where:* number - the value to test against step;* step - optional, the threshold value. If you omit a value for step, GESTEP uses zero; Returns 1 if number \u2265 step; returns 0 (zero) otherwise. HARMEAN added in v4.3 =HARMEAN(number1, [number2], ...) where:* number1, number2,... - from 1 to 255 arguments for which you want to calculate the mean; Text, logical values, or empty cells are ignored. Cells with zero values are included. Returns the harmonic mean of a data set. HEX2BIN added in v4.3 =HEX2BIN(number) where:* number - the hexadecimal number you want to convert. Number can't contain more than 10 characters; Converts a hexadecimal number to binary. HEX2DEC added in v4.3 =HEX2DEC(number) where:* number - the hexadecimal number you want to convert. Number can't contain more than 10 characters; Converts a hexadecimal number to decimal. HEX2OCT added in v4.3 =HEX2OCT(number) where:* number - the hexadecimal number you want to convert. Number can't contain more than 10 characters; Converts a hexadecimal number to octal. IMABS added in v4.3 =IMABS(inumber) where:* inumber - a complex number Returns the absolute value of a complex number in the format x + yi or x + yj. IMAGINARY added in v4.3 =IMAGINARY(inumber) where:* inumber - a complex number Returns the imaginary coefficient of a complex number given in the format x + yi or x + yj. IMCONJUGATE added in v4.3 =IMCONJUGATE(inumber) where:* inumber - a complex number Returns the complex conjugate of a complex number given in the format x + yi or x + yj. IMCOS added in v4.3 =IMCOS(inumber) where:* inumber - a complex number Returns the cosine of a complex number given in the format x + yi or x + yj. IMCOSH added in v4.3 =IMCOSH(inumber) where:* inumber - a complex number Returns the hyperbolic cosine of a complex number given in the format x + yi or x + yj. IMCOT added in v4.3 =IMCOT(inumber) where:* inumber - a complex number Returns the cotangent of a complex number given in the format x + yi or x + yj. IMCSC added in v4.3 =IMCSC(inumber) where:* inumber - a complex number Returns the cosecant of a complex number given in the format x + yi or x + yj. IMCSCH added in v4.3 =IMCSCH(inumber) where:* inumber - a complex number Returns the hyperbolic cosecant of a complex number given in the format x + yi or x + yj. IMDIV added in v4.3 =IMDIV(inumber1, inumber2) where:* inumber1 - the complex numerator or dividend* inumber2 - the complex denominator or divisor Returns the quotient of two complex numbers given in the format x + yi or x + yj. IMEXP added in v4.3 =IMEXP(inumber) where:* inumber - a complex number Returns the exponential of a complex number given in the format x + yi or x + yj. IMLN added in v4.3 =IMLN(inumber) where:* inumber - a complex number Returns the natural logarithm of a complex number given in the format x + yi or x + yj. IMPOWER added in v4.3 =IMPOWER(inumber, number) where:* inumber - a complex number* number - the power to which you want to raise the complex number Returns a complex number in x + yi or x + yj text format raised to a power. IMPRODUCT added in v4.3 =IMPRODUCT(inumber1, [inumber2], ...) where:* inumber1, inumber2,... - from 1 to 255 complex numbers to multiply Returns the product of 1 to 255 complex numbers given in the format x + yi or x + yj. IMREAL added in v4.3 =IMREAL(inumber) where:* inumber - a complex number Returns the real coefficient of a complex number given in the format x + yi or x + yj. IMSEC added in v4.3 =IMSEC(inumber) where:* inumber - a complex number Returns the secant of a complex number given in the format x + yi or x + yj. IMSECH added in v4.3 =IMSECH(inumber) where:* inumber - a complex number Returns the hyperbolic secant of a complex number given in the format x + yi or x + yj. IMSIN added in v4.3 =IMSIN(inumber) where:* inumber - a complex number Returns the sine of a complex number given in the format x + yi or x + yj. IMSINH added in v4.3 =IMSINH(inumber) where:* inumber - a complex number Returns the hyperbolic sine of a complex number given in the format x + yi or x + yj. IMSQRT added in v4.3 =IMSQRT(inumber) where:* inumber - a complex number Returns the square root of a complex number given in the format x + yi or x + yj. IMSUB added in v4.3 =IMSUB(inumber1, inumber2) where:* inumber1 - a complex number from which to subtract inumber2;* inumber2 - the complex number to subtract from inumber1 Returns the difference of two complex numbers given in the format x + yi or x + yj. IMSUM added in v4.3 =IMSUB(inumber1, [inumber2], ...) where:* inumber1, inumber2,... - from 1 to 255 complex numbers to add Returns the sum of two or more complex numbers given in the format x + yi or x + yj. IMTAN added in v4.3 =IMTAN(inumber) where:* inumber - a complex number Returns the tangent of a complex number given in the format x + yi or x + yj. IPMT =IPMT(rate, per, nper, pv, [fv], [type]), where:* rate - the interest rate per period. For monthly payments, rate = rate/12;* per - the period for which you want to find the interest and must be in the range between 1 and nper;* nper - the total number of payment periods in an annuity. For monthly payments, nper=nper*12;* pv - the present value, or the lump-sum amount that a series of future payments is worth right now;* fv - optional, the future value, 0 by default;* type - optional, 0(default) - the payments are due at the end of the period, 1 - at the beginning of the period. Returns the interest payment for a given period for an investment based on periodic, constant payments and a constant interest rate. IRR =IRR(values, [guess]), where:* values - an array or reference to cells that contain values. The array must contain at least one positive value and one negative value;* guess - optional, an estimate for expected IRR, .1 (=10%) by default. Returns the internal rate of return (IRR) for a series of cash flows that occur at regular intervals. ISPMT =ISPMT(rate, per, nper, pv), where:* rate - the interest rate for the investment. For monthly payments, rate = rate/12;* per - the period for which you want to find the interest and must be in the range between 1 and nper;* nper - the total number of payment periods for the investment. For monthly payments, nper=nper*12;* pv - the present value of the investment. For a loan, pv is the loan amount. Calculates the interest paid (or received) for the specified period of a loan (or investment) with even principal payments. LARGE added in v4.3 =LARGE(array, k), where:* array - the array or range of data for which you want to determine the k-th largest value;* k - the position (from the largest) in the array or cell range of data to return. Returns the k-th largest value in an array. MEDIAN added in v4.3 =MEDIAN(number1, [number2], ...), where:* number1, number2,... - from 1 to 255 numbers for which you want to calculate the median; Returns the median of the given numbers. NOMINAL =NOMINAL(effect_rate, npery), effect_rate must be >= 0, npery must be > 1. Returns the nominal annual interest rate on the base of the effective rate and the number of compounding periods per year you specify. NPER =NPER(rate,pmt,pv,[fv],[type]), where:* rate - the interest rate per period. For monthly payments, rate = rate/12;* pmt - the payment made each period;* pv - the present value, or the lump-sum amount that a series of future payments is worth right now;* fv - optional, the future value, 0 by default;* type - optional, 0(default) - the payments are due at the end of the period, 1 - at the beginning of the period. Returns the number of periods for an investment based on periodic, constant payments and a constant interest rate. NPV =NPV(rate,value1,[value2],...), where:* rate - the rate of discount over one year;* value1, value2,... - from 1 to 254 values representing cash flows (future payments and income). Empty cells, logical values, text, or error values are ignored. Calculates the net present value of an investment by using a discount rate and a series of future payments (negative values) and income (positive values). OCT2BIN added in v4.3 =OCT2BIN(number), where:* number - the octal number you want to convert. It can't contain more than 10 characters; Converts an octal number to binary. OCT2DEC added in v4.3 =OCT2DEC(number), where:* number - the octal number you want to convert. Number may not contain more than 10 octal characters (30 bits) Converts an octal number to decimal. OCT2HEX added in v4.3 =OCT2HEX(number), where:* number - the octal number you want to convert. Number may not contain more than 10 octal characters (30 bits) Converts an octal number to hexadecimal. PDURATION =PDURATION(rate, pv, fv), where:* rate - the interest rate per period. For monthly payments, rate = rate/12;* pv - the present value of the investment;* fv - the desired future value of the investment. All arguments must be positive values. Returns the number of periods required by an investment to reach a specified value. PERCENTILE added in v4.3 =PERCENTILE(array, k), where:* array - an array of data values;* k - the percentile value between 0 and 1, inclusive. Returns the k-th percentile of values in a range. PERCENTILE.EXC added in v4.3 =PERCENTILE.EXC(array, k), where:* array - an array of data values;* k - the percentile value between 0 and 1, exclusive. Returns the k-th percentile of values in a range. PERCENTILE.INC added in v4.3 =PERCENTILE.INC(array, k), where:* array - an array of data values;* k - the percentile value between 0 and 1, inclusive. Returns the k-th percentile of values in a range. PERMUT added in v4.3 =PERMUT(number, number_chosen), where:* number - the total number of items;* number_chosen - the number of items in each combination. Returns the number of permutations for a given number of items. PMT =PMT(rate, nper, pv, [fv], [type]), where:* rate - the interest rate for the loan. For monthly payments, rate = rate/12;* nper - the total number of months of payments for the loan. For monthly payments, nper=nper*12;* pv - the present value (or the current total amount of loan);* fv - optional, the future value, 0 by default;* type - optional, 0(default) - the payments are due at the end of the period, 1 - at the beginning of the period. Calculates the monthly payment for a loan based on constant payments and a constant interest rate. PPMT =PPMT(rate, per, nper, pv, [fv], [type]), where:* rate - the interest rate per period. For monthly payments, rate = rate/12;* per - the period for which you want to find the interest and must be in the range between 1 and nper;* nper - the total number of payment years in an annuity. For monthly payments, nper=nper*12;* pv - the present value - the total amount that a series of future payments is worth now;* fv - the desired future value or a cash balance.* type - optional, 0(default) - the payments are due at the end of the period, 1 - at the beginning of the period. Returns the payment on the principal for a specified period for an investment based on periodic, constant payments and a constant interest rate. PV =PV(rate, nper, pmt, [fv], [type]), where:* rate - the interest rate per period. For monthly payments, rate = rate/12;* nper - the total number of payment years in an annuity. For monthly payments, nper=nper*12;* pmt - the payment made each period. If pmt is omitted, you must include the fv argument;* fv - optional, the desired future value or a cash balance.* type - optional, 0(default) - the payments are due at the end of the period, 1 - at the beginning of the period. Returns the present value of a loan or an investment, based on a constant interest rate. QUARTILE added in v4.3 =QUARTILE(array, quart), where:* array - the array or cell range of numeric values;* quart - indicates which value to return (0-4). Returns the quartile of a data set. QUARTILE.EXC added in v4.3 =QUARTILE(array, quart), where:* array - the array or cell range of numeric values;* quart - indicates which value to return (1-3). Returns the quartile of the data set, based on percentile values from 0..1, exclusive. QUARTILE.INC added in v4.3 =QUARTILE.INC(array, quart), where:* array - the array or cell range of numeric values;* quart - indicates which value to return (0-4). Returns the quartile of a data set, based on percentile values from 0..1, inclusive. SIGN added in v4.3 =SIGN(number), where:* number - any real number Defines the sign of a number. Returns 1 if the number is positive, zero (0) if the number is 0, and -1 if the number is negative. SMALL added in v4.3 =SMALL(array, k), where:* array - an array or range of numeric values;* k - the position (from 1 - the smallest value) in the data set. Returns the k-th smallest value based on its position in the data set. STEYX added in v4.3 =STEYX(known_y's, known_x's), where:* known_y's - an array or range of dependent data points;* known_x's - an array or range of independent data points. Text, logical values, or empty cells are ignored. Zero values are included. Returns the standard error of the predicted y-value for each x in the regression. SYD added in v4.3 =SYD(cost, salvage, life, per), where:* cost - the initial cost of the asset;* salvage - the asset value at the end of the depreciation;* life - the number of periods over which the asset is depreciated;* per - the period and must use the same units as life. Returns the sum-of-years' digits depreciation of an asset for a specified period. TBILLPRICE added in v4.3 =TBILLPRICE(settlement, maturity, discount), where:* settlement - the settlement date of the Treasury bill;* maturity - the maturity date of the Treasury bill;* discount - the Treasury bill's percentage discount rate. Returns the price per $100 face value for a Treasury bill. TBILLYIELD added in v4.3 =TBILLYIELD(settlement, maturity, pr), where:* settlement - the settlement date of the Treasury bill;* maturity - the maturity date of the Treasury bill;* pr - the Treasury bill's price per $100 face value. Returns the yield for a Treasury bill. WEIBULL added in v4.3 =WEIBULL(x, alpha, beta, cumulative), where:* x - the value at which the function must be calculated (must be \u2265 0);* alpha - the alpha parameter to the distribution (must be > 0);* beta - the beta parameter to the distribution (must be > 0);* cumulative - the logical (true/false) argument which defines the type of distribution to be used. If True - Weibull cumulative distribution function, if False - Weibull probability density function Returns the Weibull distribution. WEIBULL.DIST added in v4.3 =WEIBULL(x, alpha, beta, cumulative), where:* x - the value at which the function must be calculated (must be \u2265 0);* alpha - the alpha parameter to the distribution (must be > 0);* beta - the beta parameter to the distribution (must be > 0);* cumulative - the logical (true/false) argument which defines the type of distribution to be used. If True - Weibull cumulative distribution function, if False - Weibull probability density function Returns the Weibull distribution."},{"location":"Spira-User-Manual/Document-Management/#information-functions","title":"Information functions","text":"Function Formula Description ISBINARY =ISBINARY(value) Returns TRUE if the value is binary; otherwise, returns FALSE. ISBLANK =ISBLANK(A1) Returns TRUE if a cell is empty; otherwise, returns FALSE. ISEVEN =ISEVEN(number) Returns TRUE if a number is even, or FALSE if number is odd. Works with integer numbers. ISNONTEXT =ISNONTEXT(value) Returns TRUE if a cell contains any value except text; otherwise, returns FALSE. ISNUMBER =ISNUMBER(value) Returns TRUE if a cell contains a number; otherwise, returns FALSE. ISODD =ISODD(number) Returns TRUE if a number is odd, or FALSE if number is even. Works with integer numbers. ISTEXT =ISTEXT(value) Returns TRUE if a value is text; otherwise, returns FALSE. N =N(value) Returns a value converted to a number."},{"location":"Spira-User-Manual/Document-Management/#lookup-functions","title":"Lookup functions","text":"Function Formula Description HLOOKUP added in v4.3 =HLOOKUP(lookup_value, table_array, row_index, [range_lookup]), where:* lookup_value - the value to search for;* table_array - the table from which to retrieve a value;* column_index_num - the row number in the table from which to retrieve a value;* range_lookup - optional (1 by default): 0 - exact match, 1 - approximate match Looks up a value in a horizontal table INDEX added in v4.3 =INDEX(array, row_num, [column_num]), where:* array - a range of cells or an array constant;* row_num - the row position in the reference or array;* column_num - optional, the column position in the reference or array. Returns the value at a given location in a range or array. LOOKUP added in v4.3 =LOOKUP(lookup_value, lookup_vector, [result_vector]), where:* lookup_value - the value to search for;* lookup_vector - the one-row, or one-column range to search;* result_vector - optional, the one-row, or one-column range of results. Looks up a value in a one-column or one-row range, and retrieves a value from the same position in another one-column or one-row range. MATCH added in v4.3 =MATCH(lookup_value, lookup_array, [match_type]), where:* lookup_value - the value that you want to match in lookup_array;* lookup_array - the range of cells;* match_type - optional (1 by default): 1- finds the largest value that is less than or equal to lookup_value 0 - finds the value that is exactly equal to lookup_value -1 - finds the smallest value that is greater than or equal to lookup_value Searches for a specified item in a range of cells, and then returns the relative position of that item in the range. VLOOKUP added in v4.3 =VLOOKUP(lookup_value, table_array, column_index_num, [range_lookup]), where:* lookup_value - the value to search for in the first column of a table;* table_array - the table from which to retrieve a value;* column_index_num - the column number in the table from which to retrieve a value;* range_lookup - optional (1 by default): 0 - exact match, 1 - approximate match Looks up a value in a vertical table by matching on the first column XLOOKUP added in v4.3 =XLOOKUP(lookup_value, lookup_array, return_array, [if_not_found], [match_mode]), where:* lookup_value - the value to search for;* lookup_array - the array or range to search;* return_array - the array or range to return;* if_not_found - optional, if a valid match is not found, returns the [if_not_found] text you supply;* match_mode - optional (0 by default): 0 - Exact match -1 - Exact match. If not found, returns the next smaller item 1 - Exact match. If not found, returns the next larger item Searches a range or an array, and then returns the item corresponding to the first match it finds. If no match exists, then XLOOKUP can return the closest (approximate) match. XMATCH added in v4.3 =XMATCH(lookup_value, lookup_array, [match_mode]), where:* lookup_value - the value that you want to match in lookup_array;* lookup_array - the range of cells;* match_mode - optional, 0 - exact match (default), -1 - exact match or next smallest, 1 - exact match or next larger Performs a lookup and returns a position in vertical or horizontal ranges."},{"location":"Spira-User-Manual/Document-Management/#math-functions","title":"Math functions","text":"Function Description ABS Returns the absolute value of a number. The absolute value of a number is always positive. ACOS Returns the arccosine, or inverse cosine, of a number. The arccosine is the angle whose cosine is number. The number must be from -1 to 1, inclusive. The returned angle is given in radians in the range 0 (zero) to pi. ACOSH Returns the inverse hyperbolic cosine of a number. The number must be greater than or equal to 1. ACOT Returns the principal value of the arc-cotangent, or inverse cotangent, of a number. The returned angle is given in radians in the range 0 (zero) to pi. ACOTH Returns the inverse hyperbolic cotangent of a number. The absolute value of the number must be greater than 1. ADD Returns the sum of two values. Empty cells, logical values like TRUE, or text are ignored. ARABIC Converts a Roman numeral to an Arabic numeral. ASIN Returns the arcsine, or inverse sine, of a number. The arcsine is the angle whose sine is number. The number must be from -1 to 1, inclusive. The returned angle is given in radians in the range -pi/2 to pi/2. ASINH Returns the inverse hyperbolic sine of a number. The inverse hyperbolic sine is the value whose hyperbolic sine is number. Works with real numbers. ATAN Returns the arctangent, or inverse tangent, of a number. The arctangent is the angle whose tangent is number. The returned angle is given in radians in the range -pi/2 to pi/2. Works with the tangent of the angle you want. ATAN2 Returns the arctangent of (x,y) coordinates. The arctangent is returned in radians between -pi and pi, excluding -pi. ATANH Returns the inverse hyperbolic tangent of a number. Number must be between -1 and 1 (excluding -1 and 1). Works with real numbers. AVEDEV added in v4.3 Returns the average of the absolute deviations of data points from their mean. Empty cells, logical values, text, or error values in the array or reference are ignored. Cells with the value 0 are included. AVERAGE Calculates the average (arithmetic mean) of a group of numbers. Logical values, empty cells and cells that contain text in the array or reference are ignored However, cells with the value zero are included. AVERAGEA added in v4.3 Calculates the average (arithmetic mean) of the values in the list of arguments. Arguments can be the following: numbers; names, arrays, or references that contain numbers; text representations of numbers; or logical values, such as TRUE and FALSE, in a reference. Empty cells and text values in the array or reference are ignored. BASE Converts a number into the supplied base (radix). The number should be an integer and greater than or equal to 0 and less than 2^53. The base radix is what we want to convert the number into. It must be an integer from 2 to 36, inclusive. BITAND added in v4.3 Returns a bitwise 'AND' of two numbers. The number must be an integer and greater than or equal to 0 and less than (2^48)-1. CEILING Returns a number rounded up to the nearest integer or to the nearest multiple of the specified significance. COMBIN Returns the number of combinations for two given integer numbers: the number of items (number) and the number of items in each combination (number_chosen):* number should be greater than or equal to zero; also, it should be greater than or equal to the number_chosen;* number_chosen must be greater than or equal to zero. COMBINA Returns the number of combinations for two given integer numbers and includes repetitions. The numbers are: the number of items (number) and the number of items in each combination (number_chosen):* number should be greater than or equal to zero; also, it should be greater than or equal to the number_chosen;* number_chosen must be greater than or equal to zero. COS Returns the cosine of an angle specified in radians. COSH Returns the hyperbolic cosine of a real number. CSC Returns the cosecant of an angle specified in radians. CSCH Return the hyperbolic cosecant of an angle specified in radians. COT Returns the cotangent of the an angle specified in radians. COTH Returns the hyperbolic cotangent of a hyperbolic angle. COUNT Counts the number of cells that contain numbers, and counts numbers within the list of arguments. Empty cells, logical values, text, or error values in the array or reference are not counted. COUNTA Counts the number of cells that contain numbers, text, logical values, error values, and empty text (\"\"); cells with zero values are excluded. The function does not count empty cells. COUNTBLANK Returns the number of empty cells from a specified range. Cells with zero values are not counted. DECIMAL Converts a text representation of a number in a given base (radix) into a decimal number. The base radix must be an integer from 2 to 36, inclusive. DEGREES Converts radians into degrees. DIVIDE Returns the result of dividing one number by another. EQ Returns TRUE if the first argument is equal to the second; otherwise FALSE. EVEN Returns a number rounded up to the nearest even integer. FACT Returns the factorial of a number. The number must be from 1 to n. If number is not an integer, it is truncated. FACTDOUBLE Returns the double factorial of a number. The number must be from 1 to n. If number is not an integer, it is truncated. FLOOR Rounds number down, toward zero, to the nearest multiple of the specified significance. The significant must be from 1 to n. If the sign of number is positive, a value is rounded down and adjusted toward zero. If the sign of number is negative, a value is rounded down and adjusted away from zero. GCD Returns the greatest common divisor of two or more integers. The function takes from 1 to 255 numeric values which are expected to be integers. If any value is not an integer, it is truncated. GT Returns TRUE if the first argument is greater than the second; otherwise FALSE. GTE Returns TRUE if the first argument is greater than or equal to the second; otherwise FALSE. INT Returns a number rounded down to the nearest integer. LN Returns the natural logarithm of a positive real number. LOG Returns the logarithm of a positive real number to the base you specify. If base is omitted, it is assumed to be 10. LOG10 Returns the base-10 logarithm of a positive real number. LT Returns TRUE if the first argument is less than the second; otherwise FALSE. LTE Returns TRUE if the first argument is less than or equal to the second; otherwise FALSE. MAX Returns the largest value in a set of values. The function ignores empty cells, the logical values TRUE and FALSE, and text values. If the arguments contain no numbers, MAX returns 0 (zero). MIN Returns the smallest number in a set of values. Empty cells, logical values, or text in the array or reference are ignored. If the arguments contain no numbers, MIN returns 0 (zero). MINUS Returns the difference of two numbers. MOD Returns the remainder after number is divided by divisor. The result has the same sign as divisor. MROUND Returns a number rounded to the nearest multiple of the specified significance. The values of number and multiple must have the same sign. MULTINOMIAL Returns the ratio of the factorial of a sum of values to the product of factorials. The function takes from 1 to 255 numeric values which must be greater than or equal to 0. MULTIPLY Returns the result of multiplying two numbers. NE Returns TRUE if the first argument is not equal to the second; otherwise FALSE. ODD Returns a number rounded up to the nearest odd integer. PI Returns the number 3.14159265358979 (the mathematical constant pi, accurate to 15 digits). POW Returns the result of a number raised to a given power. Works with real numbers. POWER Returns the result of a number raised to a given power. Works with real numbers. PRODUCT Multiplies all the numbers given as arguments and returns the product. Only numbers in the array or reference are multiplied. Empty cells, logical values, and text in the array or reference are ignored. QUOTIENT Returns the result of integer division without the remainder. Works with real numbers. RADIANS Converts degrees to radians. RAND Returns a random number that is greater than or equal to 0 and less than 1. Returns a new random number each time your spreadsheet recalculates. RANDBETWEEN Returns a random number between two specified numbers. Returns a new random number each time your spreadsheet recalculates. ROMAN Converts an arabic numeral to roman. ROUND Returns a number rounded to a specified number of digits. ROUNDDOWN Returns a number rounded down to a specified number of digits. ROUNDUP Returns a number rounded up to a specified number of digits. SEC Returns the secant of an angle specified in radians. Works with numeric values. SECH Returns the hyperbolic secant of an angle specified in radians. Works with numeric values. SIN Returns the sine of an angle specified in radians. SINH Returns the hyperbolic sine of a real number. SQRT Returns a positive square root of a number. SQRTPI Returns the square root of a number multiplied by pi. The number must be greater than or equal to 0. STDEV Calculates standard deviation based on data that represents a sample of population. The standard deviation is a measure of how widely values are dispersed from the average value (the mean). Empty cells, logical values, text, or error values in the array or reference are ignored. STDEVA Calculates standard deviation based on a sample. The standard deviation is a measure of how widely values are dispersed from the average value (the mean). Empty cells and text values in the array or reference are ignored. STDEVP Calculates standard deviation based on the entire population of numbers. The standard deviation is a measure of how widely values are dispersed from the average value (the mean). Empty cells, logical values, text, or error values in the array or reference are ignored. STDEVPA Calculates standard deviation based on the entire population given as arguments, including text (evaluate as 0) and logical values (evaluate as 1 for TRUE, and as 0 for FALSE). The standard deviation is a measure of how widely values are dispersed from the average value (the mean). If an argument is an array or reference, only values in that array or reference are used. Empty cells and text values in the array or reference are ignored. Error values cause errors. STDEV.S added in v4.3 Estimates standard deviation based on a sample (ignores logical values and text in the sample). The standard deviation is a measure of how widely values are dispersed from the average value (the mean). If an argument is an array or reference, only values in that array or reference are used. Empty cells, logical values, text, or error values in the array or reference are ignored. Error values cause errors. SUBTOTAL Returns a subtotal in a list or database. SUM Returns the sum of supplied values. Empty cells, logical values like TRUE, or text are ignored. SUMPRODUCT Multiplies range of cells or arrays and returns the sum of products. For valid products only numbers are multiplied. Empty cells, logical values, and text are ignored. Treats array entries that are not numeric as if they were zeros. SUMSQ Returns the sum of the squares of the arguments. Empty cells, logical values, text, or error values in the array or reference are ignored. SUMX2MY2 Returns the sum of the difference of squares of corresponding values in two arrays. The arguments should be either numbers or names, arrays, or references that contain numbers. Empty cells, logical values, text, or error values in the array or reference are ignored. Zero values are included. SUMX2PY2 Returns the sum of the sum of squares of corresponding values in two arrays. The arguments should be either numbers or names, arrays, or references that contain numbers. Empty cells, logical values, text, or error values in the array or reference are ignored. Zero values are included. SUMXMY2 Returns the sum of squares of differences of corresponding values in two arrays. The arguments should be either numbers or names, arrays, or references that contain numbers. Empty cells, logical values, text, or error values in the array or reference are ignored. Zero values are included. TAN Returns the tangent of an angle specified in radians. TANH Returns the hyperbolic tangent of a real number. TRUNC Truncates a number to an integer by removing the fractional part of the number. VAR Returns the variance based on a sample. Empty cells, logical values, text, or error values in the array or reference are ignored. VARA Returns the variance based on a sample of the population, including text (evaluate as 0) and logical values (evaluate as 1 for TRUE, and as 0 for FALSE). Empty cells and text values in the array or reference are ignored. VARP Returns the variance of a population based on an entire population of numbers. Empty cells, logical values, text, or error values in the array or reference are ignored. VARPA Returns the variance of a population based on an entire population, including text (evaluate as 0) and logical values (evaluate as 1 for TRUE, and as 0 for FALSE). Empty cells and text values in the array or reference are ignored. VAR.S added in v4.3 Returns the variance based on a sample (ignores logical values and text in the sample). Empty cells, logical values, text, or error values in the array or reference are ignored."},{"location":"Spira-User-Manual/Document-Management/#regex-functions","title":"Regex functions","text":"Function Formula Description REGEXREPLACE =REGEXREPLACE(text, regular_expression, replacement) Replaces a part of a text string with a different text string using regular expressions. REGEXMATCH =REGEXMATCH(text, regular_expression) Returns TRUE if a text string matches the pattern in the regular expression and FALSE if it doesn't. REGEXEXTRACT =REGEXEXTRACT(text, regular_expression) Returns the part of the string that matches the pattern in the regular expression."},{"location":"Spira-User-Manual/Document-Management/#string-functions","title":"String functions","text":"Function Formula Description ARRAYTOTEXT added in v4.3 =ARRAYTOTEXT(array, [format]) Returns an array of text values from any specified range, based on the format you specify (0 - concise (default) or 1 - strict format) CHAR =CHAR(number) Returns the character (from the character set used by your computer) specified by a number. Number must be between 1 and 255. CLEAN =CLEAN(text) Removes characters, which are not printed when you use the print option, from the text. CODE =CODE(text) Returns a numeric code for the first character in a text string. CONCATENATE =CONCATENATE(A1,\"\",B2:C3) Joins two or more text strings into one string. DOLLAR =DOLLAR(number, decimals) Converts a number to text using the currency format, based on the number of digits to the right/left of the decimal point you specify (by default, 2). EXACT =EXACT(text1, text2) Compares two strings and returns TRUE if they are exactly the same; otherwise, returns FALSE. FIND =FIND(find_text, within_text, [start_num]) Returns the position (as a number) of one text string inside another, starting at the position you specify (by default, 1). FIXED =FIXED(number, [decimals], [no_commas]) Rounds a number to the specified number of decimals, formats the number in decimal format using a period and commas, and converts the result to text. If no_commas is set to 1, the returned text won't include commas. JOIN =JOIN(separator, value1, value2,...) Concatenates values using a specified separator. LEFT =LEFT(text, count) Returns the first character or characters in a text string, based on the number of characters you specify. LEN =LEN(text) Returns the length of the specified string. LOWER =LOWER(text) Converts all letters in the specified string to lowercase. MID =MID(text, start, count) Returns a specific number of characters from a text string, starting at the position you specify, based on the number of characters you specify. NUMBERVALUE =NUMBERVALUE (text, [decimal_separator], [group_separator]) Converts a number in text format to numeric value, using specified decimal and group separators. PROPER =PROPER(text) Sets the first character in each word to uppercase and converts all other characters to lowercase. REPLACE added in v4.3 =REPLACE(old_text, start_num, num_chars, new_text), where:* old_text - the text in which you want to replace some characters;* start_num - the position of the character in old_text that you want to replace with new_text;* num_chars - the number of characters to be replaced in old_text;* new_text - the text that will replace characters in old_text. Replaces part of a text string, based on the number of characters you specify, with a different text string. REPT =REPT(text, number_times) Repeats text a specified number of times. RIGHT =RIGHT(text, count) Returns the last character or characters (rightmost) in a text string, based on the number of characters you specify. SEARCH =SEARCH(find_text, within_text, [start_num]) Returns the position (as a number) of the first character of find_text inside within_text, starting at the position you specify (by default, 1). SUBSTITUTE =SUBSTITUTE(text, old_text, new_text, [instance_num]) Replaces old text with new text in a text string. If you specify instance_num, only that instance of old_text is replaced; otherwise, all instances are replaced. T =T(value) returns text when given a text value and an empty string (\"\") for numbers, dates, and the logical TRUE/FALSE values. TRIM =TRIM(text) Removes all spaces from text except for single spaces between words. UPPER =UPPER(text) Converts text to uppercase."},{"location":"Spira-User-Manual/Document-Management/#other-functions","title":"Other functions","text":"Function Formula Description AND =AND(logical1, [logical2], ...) Returns either TRUE or FALSE depending on whether multiple conditions are met or not. CHOOSE =CHOOSE(index_num, value1, [value2], ...) Returns a value from the list of value arguments based on a position or index you specify. FALSE =FALSE() Returns the logical value FALSE. IF =IF(condition, [value_if_true], [value_if_false]) Returns one value if a condition is TRUE and another value if it's FALSE. NOT =NOT(logical) Returns the opposite of a given logical or Boolean value. OR =OR(logical1, [logical2], ...) Returns TRUE if at least one of the logical expressions is TRUE; otherwise, FALSE. TRUE =TRUE() Returns the logical value TRUE.when navigating to folders (for all artifacts that support them), the URL in your browser's address bar will change. Each folder has a unique, sharable URL that you can give to someone to display the list of artifacts with the appropriate folder selected. You can also open up multiple folders in different browser tabs and easily toggle between them from the same browser.\u00a0\u21a9
Who Can Access the Enterprise Homepage?
To access the enterprise homepage first, you need to be using SpiraPlan. Second, your user must be a Portfolio Viewer. System Administrators can control this setting on a user by user basis. If you are a Portfolio Viewer you will also be able to access the Enterprise Homepage.
If you are NOT a portfolio viewer, you can still see how your organization structures its portfolios, programs, and products from the workspace dropdown.
When you navigate to the Enterprise view from the global navigation bar you will be taken to the Enterprise homepage:
This page summarizes all of the information across the whole application (your whole enterprise) in a \"one-stop-shop\". You will see a small \"i\" in a circle at the top right of each widget. Hovering or clicking on this will show you information about that chart.
In a similar manner to other home pages in the application (like the 'My Page'), the Enterprise Home is loaded in 'view mode'. To switch the page to 'edit mode', click the button with the cog icon () on the right.
In 'edit mode', each widget can be:
Together, these editing options let you change the page to suit your needs. If you close a widget and then later want to open it again click the \"+ Add\" button at the top of the page (next to the 'edit mode' button). This brings up a list of all the widgets you can add onto the page (including a list of 'Closed Widgets'). You can choose where on the page each widget should go.
Please note
Any changes you make to this page (e.g. editing, moving, closing widgets) will only affect your user and on this particular home page. They do not affect any other user.
By default, the Enterprise home page shows the following widgets and are described in more details below:
This chart shows the proportion of all active requirements that have been completed across all active portfolios in your enterprise. When 100% of the requirements are completed, the color changes so that it is easy to tell what is in progress vs completed.
"},{"location":"Spira-User-Manual/Enterprise-Homepage/#top-open-risks","title":"Top Open Risks","text":"This widget lists the top risks logged against any of the active products in the application, ordered by exposure. Clicking on the risk name will open the risk details page for the risk in question. Note: you can configure the widget settings to control the maximum number of risks to show.
"},{"location":"Spira-User-Manual/Enterprise-Homepage/#portfolios-completion","title":"Portfolios: Completion","text":"This chart shows the progress of each portfolio in the enterprise. The left-hand chart shows progress from the start to end date of the portfolio. The bar's color indicates how on track the schedule is against requirement completion. The right-hand chart shows the proportion of requirements across active workspaces in the portfolio that have been completed.
Schedule Progress color definitions:
Example
A portfolio started a week ago and will finish in a week. Therefore its schedule is 50% of the way through (1 week down, 1 week to go).
The Schedule Progress bar will show as 50% (if you click \"Displaying\" button to \"As Numbers\" it will show 7 days).
This portfolio has a total of 20 requirements (summed up from all its program, their products, and their active releases). Let's say that 15 of these are completed. That's 75% complete. So the Requirements Complete bar will show 75% (if you click \"Displaying\" button to \"As Numbers\" it will show 15 completed).
So the schedule is half way through but we are three quarters done with the work (the requirements). So we are ahead of schedule (awesome!). The schedule bar will therefore have the \"Ahead of Schedule\" color.
What if, instead of finishing next week, we were supposed to finish last week? Well, the schedule bar would be flagged as \"Behind Schedule\". This is because we are only 75% complete on the work, but the end date is in the past.
Tip: You can hover over a bar to get more information.
"},{"location":"Spira-User-Manual/Enterprise-Homepage/#portfolios-relative-size","title":"Portfolios: Relative Size","text":"This chart shows the number of active requirements in each active portfolio. Hovering over a segment will show its percentage of all requirements (this is visually represented by the size of the donut wedge). Please note, portfolios with no active requirements are not shown.
"},{"location":"Spira-User-Manual/Enterprise-Homepage/#schedule","title":"Schedule","text":"This Gantt chart shows all active portfolios, programs, products, releases, and sprints in the enterprise. Each bar spans from the item's start date to end date. The darker shaded portion of each bar tells you how complete its requirements are.
"},{"location":"Spira-User-Manual/Enterprise-Homepage/#recent-builds","title":"Recent Builds","text":"This widget displays a list of the most recent builds for each active release (organized alphabetically by portfolio, program, and product; in each product the builds are listed by date). For each build it shows:
You can change the number of builds the widget should show in the widget's settings (the default is 15).*
"},{"location":"Spira-User-Manual/Functionality-Overview/","title":"Functionality Overview","text":"This section outlines the functionality provided by SpiraPlan\u00ae in the areas of requirements management, test case management, release planning, sprint planning, incident tracking, task management and product / user management.
Please note, that SpiraPlan\u00ae is designed for use on a very wide range of devices from desktops, to tablets, to smartphones. This guide is written using desktop conventions (e.g. using 'click' throughout where 'tap' would apply on mobile devices) but the functionality remains very similar throughout the application across all devices and platforms. See Mobile Access for more information.
"},{"location":"Spira-User-Manual/Functionality-Overview/#requirements-management","title":"Requirements Management","text":"SpiraPlan\u00ae provides the ability to create, edit and delete product scope / requirements in a hierarchical organization that resembles a typical scope matrix. Each requirement is associated with a particular importance level and a status identifier that designates where the requirement is in the development lifecycle (requested, planned, in-progress and completed). The requirements can be organized according to which part of the system they relate to (called the Component) as well as being organized into different types (features, qualities, use cases, etc.). Certain types (such as use cases) allow you to define the scenario steps that help describe that requirement.
In addition, each requirement can be mapped to one or more test cases that can be used to validate that the functionality works as expected. This mapping is called the \"Requirement Test Coverage\", since the test cases \"cover\" the requirement so that if all the tests can be executed successfully, then the requirement is validated.
At the same time, from a development perspective, the team begins initial estimation of the lowest-level requirements in the requirements matrix to determine the complexity and associated resourcing. Once the high-level release schedule has been determined, the requirements can then be prioritized and scheduled against the appropriate release according to their business priority.
Once the release is underway, the requirements are further decomposed into their constituent low-level product tasks that can be assigned to the product team. The system will track the progress and revised estimates for the tasks and display them against the requirements so that risks to the schedule can be quickly determined.
"},{"location":"Spira-User-Manual/Functionality-Overview/#test-case-management","title":"Test Case Management","text":"SpiraPlan\u00ae provides the ability to create, edit and delete product test cases that are stored in a hierarchical folder structure that resembles Windows Explorer \u00ae. Each test case consists of a set of test steps that represent the individual actions a user must take to complete the test. These test steps also contain a description of the expected result and any sample data elements that the tester should use when performing the action. When a user executes a test case, the results are stored in a test run that contains the success/failure status of each test step as well as the actual observed result that the tester experienced.
In addition each test case is mapped to one or more requirements that the test is effectively validating, providing the test coverage for the requirement. During the execution of the test case, each failure can be optionally used to record a new incident, which can then be managed in the incident tracking module (see below). This provides complete traceability from a recorded incident to the underlying requirement that was not satisfied.
To streamline the assignment and tracking of multiple test cases, SpiraPlan\u00ae allows users to select groups of test cases and arrange them into test sets. Each test set can contain test cases from a variety of different folders and can be associated with a specific release of the system being tested.
"},{"location":"Spira-User-Manual/Functionality-Overview/#test-automation","title":"Test Automation","text":"As well as being able to store and manage manual test cases, SpiraPlan\u00ae can be used to manage the scheduling and execution of automated test scripts for a variety of third-party test automation engines. This allows you to centrally plan your automated testing and monitor the results of automated unit, functional and load testing remotely. For example, you could schedule a set of automated functional tests to run on five different machines (each with a different browser/OS combination) at 2:00 AM and have the results be ready for the next morning.
"},{"location":"Spira-User-Manual/Functionality-Overview/#release-planning","title":"Release Planning","text":"SpiraPlan\u00ae provides the ability to track different versions / releases of the application being tested. Each product in the system can be decomposed into an unlimited number of specific product releases, denoted by name and version number. Requirements and Test Cases developed during the design phase can then be assigned to these different releases. When a tester executes a series of test cases, they are able to choose the version of the product being tested and the resulting test run information is then associated with that release.
From a product planning perspective, the releases are the major milestones in the product, which are further sub-divided into sprints which are separate mini-products with associated product scope and tasks. The product's requirements are scheduled at a high-level against the releases and the detailed tasks are scheduled against specific sprint within the release.
In addition, all incidents raised during the testing process are associated with this release, allowing the development team to easily determine which version of the product is affected. Finally as the incidents are resolved and verified during the testing phase, the appropriate release can be selected to indicate which release the incident was resolved and/or verified in.
"},{"location":"Spira-User-Manual/Functionality-Overview/#sprint-planning","title":"Sprint Planning","text":"As described in Release Planning, in addition to high-level product releases, SpiraPlan\u00ae can also track the individual sprints that comprise a release, giving the product manager the option to manage agile methodology products within the SpiraPlan\u00ae environment. Unlike the release planning stage, where high-level requirements are estimated and scheduled, the sprint planning phase involves assigning each of the requirements, incidents and tasks in the product backlog against a specific sprint until the available effort in the sprint has been completely allocated.
When you first create sprints, you specify the start and end-dates together with the notional number of product resources assigned to the sprint and any non-working days. SpiraPlan\u00ae uses this information to calculate the planned effort available to the sprint, from which it will subtract the estimated task and incident effort values to determine how much effort is available to schedule.
"},{"location":"Spira-User-Manual/Functionality-Overview/#incident-tracking","title":"Incident Tracking","text":"SpiraPlan\u00ae provides the ability to create, edit, assign, track, manage and close incidents that are raised during the testing of the software system under development. These incidents can be categorized into bugs, enhancements, issues, training items, limitations, change requests, and risks, and each type has its own specific workflow and business rules. Typically each incident is raised initially as a 'New' item of type 'Incident'. Following the review by the product manager and customer, they are changed to one of the other specific types, given a priority (critical, high, medium or low), and status changed to 'Open'. Once it is assigned to a developer for fixing, it is changed to status 'Assigned'.
The developer now works to correct the incident, after which time its status changes to 'Fixed' or 'Not Reproducible' depending on the actions taken (or not taken). Finally the product manager and customer verify that it has indeed been fixed, and the status is changed to 'Closed'. SpiraPlan\u00ae provides robust sorting and filtering of all the incidents in the system, as well as the ability to view the incidents associated with particular test cases and test runs, enabling drill-down from the requirements coverage display, right through to the open incidents that are affecting the requirement in question.
"},{"location":"Spira-User-Manual/Functionality-Overview/#task-management","title":"Task Management","text":"As described above, in addition to storing the requirements for a product, SpiraPlan\u00ae includes the capability of drilling each lowest-level requirement down further into a series of work items called 'Tasks'. These tasks are the discrete activities that each member of the development team would need to carry out for the requirement to be fulfilled. Each task can be assigned to an individual user as well as associated with a particular release or sprint. The system can then be used by the product manager to track the completion of the different tasks to determine if the product is on schedule.
The tasks can be organized into different folders as well as categorized by different types (development, testing, infrastructure, etc.), each of which can have its own workflow which defines the process by which the task changes status during the product lifecycle.
"},{"location":"Spira-User-Manual/Functionality-Overview/#products-and-users","title":"Products and Users","text":"SpiraPlan\u00ae supports the management of an unlimited number of users and products, which can be administered through the same web interface as the rest of the application. All artifacts (requirements, tests and incidents) are associated with a particular product, and each user of the system can be given a specific role for the particular product. So, a power user of one software product may be merely an observer of another. That way, a central set of users can be managed across the enterprise, whilst devolving product-level administration to the manager of the product. In addition to these administration functions, each user profile and product has its own personalized dashboard view of all the pertinent and relevant information. This feature reduces the information overload associated with managing such a rich source of product information, and allows a single user or product snapshot to be viewable at all times for rapid decision-making.
"},{"location":"Spira-User-Manual/Functionality-Overview/#document-management","title":"Document Management","text":"SpiraPlan\u00ae includes an integrated document management collaboration system that can be used to upload, manage and share documents between the different members of the product. This module includes support for uploading files and URLs, versioning of documents, the ability to organize into folders and categorize and search using meta-tags.
"},{"location":"Spira-User-Manual/Functionality-Overview/#risk-management","title":"Risk Management","text":"SpiraPlan\u00ae (not available in SpiraTest or SpiraTeam) enables a complete risk management workflow. This module aids in the analyzing and categorizing of risks based on their Probability and their impact, which produces a calculated risk exposure. The tool tracks both risks and their mitigations, and provides dynamic risk reporting tools.
"},{"location":"Spira-User-Manual/Functionality-Overview/#source-code-tracking","title":"Source Code Tracking","text":"SpiraTeam\u00ae and SpiraPlan\u00ae let you browse your source code from within the main web application. This is an excellent way to browse all a product's code files, commits, and how a file changed in a commit (the 'diff'). There is no need to install version control software on your own computer or to clone the source code to your machine. All users can link source code commits with any SpiraPlan\u00ae artifact. This gives you traceability from requirements, incidents, tasks, and more to right code changes. This let you easily see what code was edited to implement a feature, or fix a bug. If the bug is reopened later, you can quickly see the associated source code commits to check if the changes made actually did fix things properly.
"},{"location":"Spira-User-Manual/Functionality-Overview/#build-management","title":"Build Management","text":"SpiraPlan\u00ae integrates with a variety of continuous integration / automated build servers so that the results of automated builds can be displayed in SpiraPlan linked to the associated release or sprint. In addition, the results of automated tests and source code operations can be linked to the build events, providing traceability from a specific build to the bugs that were fixed, tests that were run, and source code files that were modified.
"},{"location":"Spira-User-Manual/Functionality-Overview/#instant-messenger","title":"Instant Messenger","text":"SpiraPlan\u00ae comes with a build-in integrated instant messaging capability. This lets users see which users are currently logged-into the system, maintain a list of contacts and where available, send short instant messages to other users. Any messages exchanged can then be posted to relevant artifacts in the system as permanent comments.
"},{"location":"Spira-User-Manual/Functionality-Overview/#miscellaneous","title":"Miscellaneous","text":""},{"location":"Spira-User-Manual/Functionality-Overview/#artifact-relationships","title":"Artifact Relationships","text":"The sections above have outlined the different features and functions available in the system, and have described the various artifacts managed in the system (e.g. products, users, requirements, tests, etc.). To aid in understanding how the information is related, the following diagrams illustrates the relationships between the different artifacts and entities:
Figure 1: The main entities that comprise a SpiraTest product.
Figure 2: The relationships between the various SpiraTest entities
With these overall concepts in mind, the rest of this help manual will outline the functionality in each of the SpiraPlan\u00ae screens, and provide specific information on how to manage each of the artifacts illustrated above. Note that this manual does not explain the Administration-level functionality of the system; for that, please refer to the SpiraPlan\u00ae Administration Guide.
"},{"location":"Spira-User-Manual/Functionality-Overview/#artifact-naming-conventions","title":"Artifact Naming Conventions","text":"On various screens in the system, you will see lists of artifacts (requirements, test cases, etc.) together with a unique identification number. In order to make it easier to recognize at a glance which type of artifact the identification number refers to, SpiraPlan\u00ae uses a system of two-letter prefixes which help identify the type of artifact being displayed. The current prefixes used by the system are:
Artifact Prefix Artifact Prefix Product PR Program PG User US Incident Type IT Requirement RQ Incident Priority IP Requirement Step RS Incident Severity IV Test Case TC Workflow WK Test Step TS Workflow Transition WT Test Run TR Custom Property Values PV Test Run Step RS Product Role RX Incident IN Task TK Incident Status IS Test Set TX Custom List CL Document DC Document Type DT Document Folder DF Automation Host AH Build BL Release/Sprint RL Component CP Risk RK Risk Mitigation RMIn addition, certain artifacts in the system are displayed with an icon that helps distinguish them from each other, and provides additional context on the state of the artifact:
Icon Artifact Description Program Product Summary Requirement Detailed Requirement Use Case Requirement Use Case Scenario Step Folder Test Case with Test Steps Test Case without Test Steps Test Set Test Run Test Step Linked Test Case Test Automation Host Test Configuration Release Iteration / Sprint Component Task Incident Risk Risk Mitigation Source Code Commit Product User Build Artifact has an Attachment"},{"location":"Spira-User-Manual/Incident-Tracking/","title":"Incident Tracking","text":"This section outlines how the incident/defect tracking features of SpiraPlan\u00ae can be used to manage key product artifacts during the software development lifecycle. In addition to managing the defects raised during the execution of test cases in the test management module, the Incident Tracker is also a powerful risk/issue/bug tracking system in its own right. When coupled with the product dashboard it is a powerful tool for representing all the key risks and issues associated with a product in a single, graphical format.
Unlike a standalone bug/issue tracking tool however, you can trace the incidents/defects back to the test case and the underlying requirement that generated them, giving the product manager unprecedented power in analyzing the \"in-process\" quality of a system during its lifecycle. This power is clearly illustrated in the \"Requirement Incident Count\" pane in the Product Home dashboard (see User/Product Management > Requirements Coverage).
"},{"location":"Spira-User-Manual/Incident-Tracking/#incident-list","title":"Incident List","text":"When you click on the Tracking > Incidents global navigation link, you will initially be taken to the incidents list screen illustrated below:
The incident list screen displays all the incidents entered for the current product, in a filterable, sortable grid. The grid displays the incident number together with fields such as incident type (bug, issue, risk, etc.), status (new, open, etc.), priority, name, assigned owner, detection date, detector, closed date, etc. The choice of columns displayed is configurable per-user, per-product, giving extensive flexibility when it comes to viewing and searching incidents.
The sidebar on the left gives you quick access to saved filters, along with some useful charts to get an at-a-glance view of incidents for this product. These charts are:
In addition, you can view a more detailed description of the incident (along with a resolution if any) by positioning the mouse pointer over the incident name hyperlink and waiting for the popup \"tooltip\" to appear. If you click on the incident name hyperlink, you will be taken to the incident details page described in Incident Tracking > Incident Details. Clicking on any of the pagination links at the bottom of the page will advance you to the next set of incidents in the list according to the applied filter and sort-order. There is also a drop-down-list at the bottom of the page which allows you to specify how many rows should be displayed in each page, helping accommodate different user preferences.
"},{"location":"Spira-User-Manual/Incident-Tracking/#filtering-sorting","title":"Filtering & Sorting","text":"Read about how to create and manage filters, and how to sort the artifact list.
Incidents can be filtered in special ways when filtering by incident status or incident type:
Clicking on the \"New Incident\" button takes you to the new incident screen. This is essentially the same screen as the incident details screen shown in Incident Details except, depending on how the workflow has been configured for this product, certain fields may be disabled.
"},{"location":"Spira-User-Manual/Incident-Tracking/#delete","title":"Delete","text":"Clicking on the \"Delete\" button deletes the incidents whose check-boxes have been selected in the incident list.
"},{"location":"Spira-User-Manual/Incident-Tracking/#refresh","title":"Refresh","text":"Clicking on the \"Refresh\" button simply reloads the list of incidents; this is useful when new incidents are being added by other users, and you want to make sure you have the most up-to-date list displayed.
"},{"location":"Spira-User-Manual/Incident-Tracking/#show-hide-columns","title":"Show / Hide Columns","text":"This drop-down list allows you to change the fields that are displayed in the incident list as columns for the current product. To show a column that is not already displayed, simply select that column from the list of \"Show...\" column names and to hide an existing column, simply select that column from the list of \"Hide...\" column names. This is stored on a per-product basis, so you can have different display settings for each product that you are a member of. The fields can be any of the built-in fields or any of the custom properties set up by the product owner.
"},{"location":"Spira-User-Manual/Incident-Tracking/#edit","title":"Edit","text":"Each incident in the list has an \"Edit\" button display in its right-most column. When you click this button or just double-click on any of the cells in the row, you change the item from \"View\" mode to \"Edit\" mode. The various columns are made editable, and \"Save\" buttons are displayed in the last column:
If you click \"Edit\" on more than one row, the \"Save\" buttons are only displayed on the first row, and you can make changes to all the editable rows and then update the changes by clicking the one \"Save\" button. Also, if you want to make the same change to multiple rows (e.g. to change five incidents from \"Resolved\" status to \"Closed\"), you can click on the \"fill\" icon to the right of the editable item, which will propagate the new value to all editable items in the same column.
If you want to edit lots of items, first select their checkboxes and then click the \"Edit\" button on the same row as the Filters and it will switch all the selected items into edit mode.
When you have made your updates, you can either click \"Save\" to commit the changes, or \"Cancel\" to revert back to the original information. Alternatively, pressing the <ENTER> key will commit the changes and pressing the <ESCAPE> key will cancel the changes.
"},{"location":"Spira-User-Manual/Incident-Tracking/#cloning-incidents","title":"Cloning Incidents","text":"To create a clone of an existing incident or set of incidents, simply select the check-boxes of the incidents you want to copy and then click \"Clone\" under the Edit menu (or click \"Clone\" from the \"New\" dropdown menu from the Incident's details page). This will make a copy of the current incident with its name prefixed 'Copy of ....' to distinguish itself from the original. Any file attachments will also be copied along with the incident itself.
When cloning Incidents please note that:
Read about how to export artifacts from one product to another.
"},{"location":"Spira-User-Manual/Incident-Tracking/#creating-requirement-from-incidents","title":"Creating Requirement from Incidents","text":"Sometimes you may have enhancements logged that now need to be converted into formal requirements. This may be useful for sprint planning or so test cases and tasks can be made from it. There is a shortcut to create new requirements from selected incidents (1 or more); and it automatically creates an association between each new requirement and the corresponding incident.1
To use this feature:
To quickly print a single incident or list of incidents you can select the items' checkboxes and then click Tools > Print Items. This will display a popup window containing a printable version of the selected items. You can also save the report in a variety of common formats from the same Tools menu.
"},{"location":"Spira-User-Manual/Incident-Tracking/#incident-details","title":"Incident Details","text":"When you click on an incident item in the incident list, or click the \"New Incident\" button (as described in Incident List), you are taken to the incident details page illustrated below:
This page is made up of three areas:
the left pane is the navigation window where you can quickly jump to other incidents;
the upper part of the right pane contains the incident name and key information about it (it's ID number, and what type of incident it is), as well as the current status (see below); and
the bottom part of the right pane displays different information associated with the incident across a number of tabs.
The navigation pane consists of a link that will take you back to the incidents list, as well as a list of the peer incidents to the one selected. This latter list is useful as a navigation shortcut; you can quickly view the peer incidents by clicking on the navigation links without having to first return to the incidents list page. The navigation list can be switched between four different modes:
In addition to the left hand navigation, you can enter a specific incident number in the text-box in the toolbar and click the \"Find\" button. In the same toolbar, there is also a shortcut for creating a copy of the current by clicking the \"Clone\" button.
"},{"location":"Spira-User-Manual/Incident-Tracking/#editing-an-existing-incident","title":"Editing an Existing Incident","text":"When editing an existing incident, the fields that are available and the fields that are required will depend on your stage in the incident workflow. Read about using workflows to change the status of your artifact, and how electronic signatures can further control how you progress an incident through the workflow.
You can print the current incident by clicking Tools > Print, which will display a printable version of the page in a separate window. Alternatively, you can export the incident to a number of formats by selecting the appropriate option from the Tools menu.
"},{"location":"Spira-User-Manual/Incident-Tracking/#inserting-a-new-incident","title":"Inserting a New Incident","text":"If you are creating a new incident, the fields that are available and the fields that are required will depend on how your product has been for configured. For example, some products may require that all incidents be started with Status=New and Type=Incident, others may allow you to specify the incident type. The types of change allowed will depend on how your product administrator has setup the system for you. Administrators should refer to the SpiraPlan Administration Guide for details on configuring the incident workflows to meet their needs.
Once you've filled out the appropriate incident fields, you can either click \"Save\" or one of the options from the \"Save\" dropdown list to commit the changes or click on \"Back to Incident List\" to discard the insertion and return back to the incident list.
"},{"location":"Spira-User-Manual/Incident-Tracking/#overview-comments","title":"Overview - Comments","text":"Read about how the comments works
"},{"location":"Spira-User-Manual/Incident-Tracking/#overview-dates-and-times","title":"Overview -- Dates and Times","text":"This section displays the general schedule and completion status of the specific incident. You can enter/edit:
Any custom date fields set up by the system administrator or product owner will also appear in this section (as shown below with the Review Date field).
Calculating Incident Progress
To help you better track incidents, there are three special calculated fields used for showing the progress of the incident:
Projected Effort is calculated by adding \"Actual Effort\" and \"Remaining Effort\" together.
Percent Complete is calculated as follows:
(Est. Effort - Remaining Effort) / Est. Effort * 100The Progress Indicator is a colorful progress bar of the percent completion:
Progress Indicator Color Incident Progress % Start Date Value Fully gray 0% None or in the future Fully yellow 0% In the past Partly green Between 0% and 100% Anything Fully green 100% AnythingExamples of the progress indicator are shown in the screenshots below:
Note, that unlike for tasks, the progress bar will never be red (because incidents do not have an end (due) date).
"},{"location":"Spira-User-Manual/Incident-Tracking/#attachments","title":"Attachments","text":"Read about how the attachments tab works
"},{"location":"Spira-User-Manual/Incident-Tracking/#associations","title":"Associations","text":"You can associate other incidents, requirements, test steps, tasks, and risks to an incident from this tab.
The incidents and tasks in this list are ones that a user has decided are relevant to the current one and has created a direct link between them. In the case of requirements and test cases, the association can be either due to the creator of an incident directly linking the incident to the requirement or test step, or it can be the result of a tester executing a test-run and creating an incident during the test run. In this latter case, the check-box to the left of the association will be unavailable as the link is not editable.
Read more about how to manage and add associations to this artifact
"},{"location":"Spira-User-Manual/Incident-Tracking/#history","title":"History","text":"Read about how the history tab works
"},{"location":"Spira-User-Manual/Incident-Tracking/#creating-a-requirement-from-an-incident","title":"Creating a Requirement from an Incident","text":"Sometimes you may have an enhancement logged that now needs to be converted into a formal requirement. This may be useful for sprint planning or so test cases and tasks can be made from it. There is a shortcut to create a new requirement from the current incident; and it automatically creates an association between the new requirement and the incident.1
To use this feature:
Add buttonCreate Requirement from this Incident button Read about emailing an incident to colleagues.
"},{"location":"Spira-User-Manual/Incident-Tracking/#incident-followers","title":"Incident Followers","text":"Read about how to add and manage followers to an artifact
"},{"location":"Spira-User-Manual/Incident-Tracking/#incident-board","title":"Incident Board","text":"The incident board is an alternative to the incident list page designed to let you view the incidents planned for the current product. You can access this feature by clicking on the Board icon in the top-right of the Incidents list page. You can switch back to the Incident list page by clicking on the Table view.
The incident board has the following different display modes:
All Releases
Release (select a specific release from the release dropdown - only incidents with a Planned Release matching this selection will be displayed)
Sprint (select a specific sprint from the release dropdown - only incidents with a Planned Release matching this selection will be displayed)
Each of these views is described below.
Planning Boards and Editing
Moving cards: Please note that the purpose of a planning board or Kanban board, is to make it straightforward for users to move cards around the interface to plan out their work. Therefore we do not enforce workflow restrictions on the planning board when moving cards. Therefore only users with permissions to bulk edit the relevant artifact can move cards. If the template admin has prevented status changes while bulk editing, then noone can change a card's status by moving its card on the planning.
Viewing cards: to view more information about the card you can: turn on Detailed View; hover on the card name to see a rich tooltip; click on the card's id to open a popup with much more detail; or ctrl/cmd+click on the card's id to open the full details page for that artifact. Information shown in the popup includes all standard and custom fields with fields being shown or hidden based on the workflow step that applies to that specific card.
Editing cards: users with bulk edit permissions can edit a planning board card at any time by click on the card's id (including adding a new comment). This opens a popup with full information about that card. At all times, which fields are shown, required, or hidden is based on the workflow step that applies to that specific card. To save any changes you must fill in all required fields. Please note: you cannot change the status in this edit mode, to do so open the artifact's detail page (you cand do this from the popup by clicking the button next to the artifact's id at the top).
Add new cards: if you are able to create the requirements then you will see plus (add) symbols in different locations on the board. Clicking any of these will open an popup screen with all relevant fields available. Some of these fields may be prepopulated based on what add button you clicked and how you are using the board. For instance, if you are viewing for a release, that release will be preselected. And if you are grouping by person and click on a particular person, that person will be set as the owner of the artifact. The fields visible and required is driven based on what workflow step will apply to that new card.
"},{"location":"Spira-User-Manual/Incident-Tracking/#incidents-by-priority","title":"Incidents -- By Priority","text":"This view is designed to let you see the list of planned incidents organized by priority. Each of the possible priority values is displayed on the left-hand side and the incidents displayed in the same row on the right:
The top section will contain the list of incidents that are not assigned a priority, with the other sections containing the incidents that have been assigned to the specific priority.
"},{"location":"Spira-User-Manual/Incident-Tracking/#incidents-by-status","title":"Incidents -- By Status","text":"This view is designed to let you see the incidents in the current product / release / sprint organized by their status. Each incident status (not started, in progress, completed, blocked, deferred) is displayed as a heading, with the incidents displayed in the same column underneath:
You can click on the expand/collapse icons to hide any statuses that are not relevant.
Depending on the view (all releases, release, or sprint), there may be sections with the release and sprint name. You can drag and drop the incidents between statuses or to/from the release/sprint backlog. Any incidents not assigned to a release/sprint will be listed in the (Unassigned Items) section at the top.
"},{"location":"Spira-User-Manual/Incident-Tracking/#incidents-by-person","title":"Incidents - By Person","text":"This view is designed to let you see the incidents in the current product / release / sprint organized by resource / person. Each of the users that is a member of the current product is displayed as a heading, with the incidents displayed in the same column underneath:
You can click on the expand/collapse icons to hide any people that are not relevant. The system will display a progress bar for each resource to illustrate the allocation for that resource. Any resource that has a progress bar that is completely green has been fully scheduled and should not have any additional incidents assigned. If the progress bar for that resource turns red, it means that they have been over-scheduled and you need to reassign some of the incidents.
Depending on the view (all releases, release, or sprint), there may be sections with the release and sprint name; they contain incidents that are scheduled for the current release or sprint but have not yet been assigned to a resource. You can drag and drop the incidents between resources or to/from the release/sprint backlog (as long as the item has a status that let's you set or edit its owner field). Any incidents not assigned to a resource and release/sprint will be listed in the (Unassigned Items) section at the top.
"},{"location":"Spira-User-Manual/Incident-Tracking/#incidents-by-release","title":"Incidents - By Release","text":"This view is only available when you are displaying the incident board for 'all releases'. Each of the active releases defined for the current product is displayed as a heading. Incidents are displayed in the release column that matches their Planned Release.
You can drag and drop the incidents between the different releases. Once the incident has been added to the release, the utilized effort for the release will increase, and the available effort will decrease by the same amount.
Note: The system will allow you to assign more incidents to a release than it is possible to complete, however this will result in a negative value for 'available effort'. If this happens, the \"Available Effort\" value will be displayed in red, and you need to rebalance the items, extend the release length or add product personnel resources to the release.
Clicking on the release hyperlinks in the headers will switch the incident board into the release view.
"},{"location":"Spira-User-Manual/Incident-Tracking/#incidents-by-sprint","title":"Incidents - By Sprint","text":"This view is only available when you are displaying the incident board for a specific release. Each of the sprints defined for the current release is displayed as a heading. Incidents are displayed in the sprint column that matches their Planned Release. This view is commonly used in Scrum products:
You can drag and drop the incidents between the different sprints. Once the incident has been added to the sprint, the utilized effort for the sprint will increase, and the available effort will decrease by the same amount.
Note: The system will allow you to assign more incidents to a sprint than it is possible to complete, however this will result in a negative value for 'available effort'. If this happens, the \"Available Effort\" value will be displayed in red, and you need to rebalance the items, extend the sprint length or add product personnel resources to the sprint.
Clicking on the sprint hyperlinks in the headers will switch the incident board into the sprint view.
To create a requirement from an incident, the user needs must have the permission to create requirements (which makes sense).
The creation process does not enforce the relevant requirement workflow to make sure that all required fields are filled in.
What gets copied over from the incident to the new requirement:
\u21a9\u21a9
This section describes the functionality available in SpiraPlan\u00ae when accessing the system from a mobile device such as an iOS\u00ae smartphone / tablet (iPod Touch\u00ae, iPhone\u00ae and iPad\u00ae) or an Android\u00ae smartphone / tablet (Galaxy, Nexus, Droid, Kindle Fire\u00ae, etc.).
The application has been designed to be fully \"responsive\", which means that it will dynamically rearrange the page based on the screen-sized used, to create an optimal experience on any device. As much as possible the application provides a consistent set of functions for any device. However, in order to make using the application on smaller devices as easy as possible, necessarily the experience on say, a smartphone, is less complete than on a desktop.
Whenever this user guide has referred to performing an action by 'clicking' if the same functionality is available, then 'tapping' on a mobile device will yield the same result. Due to the limitations of mobile devices, hovering over an element to display a \"tooltip\" is not possible.
Below, some illustrations of how the application looks at different screen sizes are provided.
"},{"location":"Spira-User-Manual/Mobile-Access/#my-page","title":"My Page","text":"Desktop (a tablet in landscape mode will appear largely identical)
Table in portrait mode
Smartphone in portrait mode
"},{"location":"Spira-User-Manual/Mobile-Access/#my-profile","title":"My Profile","text":"Desktop (a tablet in landscape mode will appear largely identical)
Tablet in portrait mode
Smartphone in portrait mode
"},{"location":"Spira-User-Manual/Mobile-Access/#example-list-page","title":"Example List Page","text":"Desktop (a tablet in landscape mode will appear largely identical)
Tablet in portrait mode
Smartphone in portrait mode
"},{"location":"Spira-User-Manual/Mobile-Access/#example-details-page","title":"Example Details Page","text":"Desktop (a tablet in landscape mode will appear largely identical)
Tablet in portrait mode
Smartphone in portrait mode
"},{"location":"Spira-User-Manual/Mobile-Access/#test-execution","title":"Test Execution","text":"Desktop (a tablet in landscape mode will appear largely identical)
Tablet in portrait mode
Smartphone in portrait mode
"},{"location":"Spira-User-Manual/Planning-Board/","title":"Planning Board","text":"The SpiraPlan planning board is a great way to visualize the backlog items (requirements, tasks, test cases and incidents) planned for your product. Based on the principles of agile methodologies such as Scrum and Kanban, the planning board is a great tool for planning agile products.
Planning Boards and Editing
Moving cards: Please note that the purpose of a planning board or Kanban board, is to make it straightforward for users to move cards around the interface to plan out their work. Therefore we do not enforce workflow restrictions on the planning board when moving cards. Therefore only users with permissions to bulk edit the relevant artifact can move cards. If the template admin has prevented status changes while bulk editing, then noone can change a card's status by moving its card on the planning.
Viewing cards: to view more information about the card you can: turn on Detailed View; hover on the card name to see a rich tooltip; click on the card's id to open a popup with much more detail; or ctrl/cmd+click on the card's id to open the full details page for that artifact. Information shown in the popup includes all standard and custom fields with fields being shown or hidden based on the workflow step that applies to that specific card. Users who cannot bulk edit the artifact but who can add comments can add comments when viewing the card.
Editing cards: users with bulk edit permissions can edit a planning board card at any time by clicking on the card's id (including adding a new comment). This opens a popup with full information about that card. At all times, which fields are shown, required, or hidden is based on the workflow step that applies to that specific card. To save any changes you must fill in all required fields. Please note: you cannot change the status in this edit mode, to do so open the artifact's detail page (you can do this from the popup by clicking the button next to the artifact's id at the top).
Add new cards: if you are able to create the requirements then you will see plus (add) symbols in different locations on the board. Clicking any of these will open an popup screen with all relevant fields available. Some of these fields may be prepopulated based on what add button you clicked and how you are using the board. For instance, if you are viewing for a release, that release will be preselected. And if you are grouping by person and click on a particular person, that person will be set as the owner of the artifact. The fields visible and required is driven based on what workflow step will apply to that new card.
To access the SpiraPlan product planning board, select a product and go to Artifacts > Planning Board and the following screen will be displayed:
By default, the system will display the product planning board in the product backlog view, with the backlog organized by component. You can change the view by click on the 'Planning' drop down list:
The 'Group By' dropdown list is used to change how the view is organized. This list of options available in the 'Group By' dropdown will depend on the view being displayed.
The planning board will include the following backlog items:
Requirements and Incidents -- these are displayed as 'story cards' and are the primary items that can be moved in the planning board.
Tasks and Test Cases -- these are secondary artifacts and are considered part of a requirement. So within the planning board they are displayed as being part of a specific requirement, and if you move a requirement, the associated tasks and test cases will move as well.
The backlog items themselves can be configured to display in different ways. The choice of display will depend on how many backlog items you have to display, how large your screen is and what information you need. The display is controlled by the four checkboxes at the top of the planning board:
Numerical rankings are also shown. The ranking numbers go from left to right and top to bottom. They indicate the relative ordering and priority of the various story cards and defects.
Regardless of the view, backlog items can be moved using \"drag and drop\" between the different parts of the planning board. To drag and drop multiple items, you should first select the items so that they are highlighted. Then you can drag and drop the entire selection:
You can add new requirement backlog items by clicking the \"+\" button. This will display the following dialog box:
On this screen you can enter the fields for a new requirement, click \"Add Requirement\" and the requirement will be added to the appropriate section of the planning board.
In some of the views of the planning board there will be more data that can be displayed on one screen, in which case you will be able to scroll the planning board left and right using the specially provided arrow buttons.
Each of the views is now described in more detail in the sections below.
What statuses show when grouping by status?
When you group by statuses, the statuses you see will change based on what you are looking at. Specifically, the statuses you see when on the product backlog view are different than those you see when looking at the \"All Releases\" view, or a single release or sprint.
The statuses shown are based on the template's workflows.
The product backlog view is designed to let you view the backlog items that have been created for the product and have not yet been assigned to a specific release or sprint. The backlog items can be requirements or incidents, and in the case of requirements, you can see the tasks and test cases associated with a specific requirement.
In this view you can drag and drop the backlog items from one section (e.g. component) to another and also rearrange the backlog items in their relative order. By default, the items are sorted according to their priority/importance value (the color of which is indicated in the left-hand side of the story card), but you can drag and drop them into a different order. This is particularly useful when you have several items of the same priority and you need to rank them. This process is typically called backlog grooming.
"},{"location":"Spira-User-Manual/Planning-Board/#product-backlog-by-component","title":"Product Backlog -- By Component","text":"This view is designed to let you see the product backlog organized by Component. Each of the components is displayed on the left-hand side and the backlog items displayed in the same row on the right. The backlog items can be requirements (with associated tasks and test cases) or incidents.
The top section will contain the list of items that are not assigned to a component, with the other sections containing the items that belong to the specific component.
"},{"location":"Spira-User-Manual/Planning-Board/#product-backlog-by-parent","title":"Product Backlog -- By Parent","text":"This view is designed to let you see the product backlog organized by parent requirements (those with at least one child requirement). Each of the parents is displayed on the left-hand side in a hierarchical structure, and the backlog items displayed in the same row on the right. The backlog items can be child requirements (with associated tasks and test cases) or incidents. In this view the incidents are the ones linked to the parent requirement through an association.
The top section will contain the list of items that are not assigned to a parent requirement, with the other sections containing the items that are children of the specific parent.
"},{"location":"Spira-User-Manual/Planning-Board/#product-backlog-by-priority","title":"Product Backlog -- By Priority","text":"This view is designed to let you see the product backlog organized by requirement importance. Each of the possible importance values is displayed on the left-hand side and the backlog items displayed in the same row on the right. The backlog items in this view will only be requirements (with associated tasks and test cases).
The top section will contain the list of items that are not assigned a priority, with the other sections containing the items that have been assigned to the specific priority.
"},{"location":"Spira-User-Manual/Planning-Board/#product-backlog-by-status","title":"Product Backlog -- By Status","text":"This view is designed to let you see the product backlog organized by requirement status. Each of the possible status values (for an unscheduled item) is displayed as a heading, with the backlog items displayed in the same column underneath. The backlog items in this view will only be requirements (with associated tasks and test cases). This view is commonly called a Kanban board:
Each of the vertical sections is one of the requirements' statuses, in order of the requirement lifecycle (Requested > Accepted). Once a requirement is assigned to a release or sprint it will come automatically 'Planned' and not appear in this view. You can drag and drop the requirements between the different statuses.
"},{"location":"Spira-User-Manual/Planning-Board/#release-planning","title":"Release Planning","text":"The 'All Releases' option lets you view all of the backlog items that have already been assigned to a release - and are therefore not in the product backlog. The backlog items can be requirements or incidents, and in the case of requirements, you can see the tasks and test cases associated with a specific requirement.
The lower section of the board allows you to view the items by either by release, priority, status, or person. Each section below will discuss each option in turn.
"},{"location":"Spira-User-Manual/Planning-Board/#release-planning-by-component","title":"Release Planning -- By Component","text":"This view is designed to let you see items across all releases organized by Component. Each of the components is displayed on the left-hand side and the backlog items displayed in the same row on the right. The backlog items can be requirements (with associated tasks and test cases) or incidents.
The top section will contain the list of items that are not assigned to a component, with the other sections containing the items that belong to the specific component.
"},{"location":"Spira-User-Manual/Planning-Board/#release-planning-by-parent","title":"Release Planning -- By Parent","text":"This view is designed to let you see items across all releases organized by parent requirement. Each of the parents is displayed on the left-hand side in a hierarchical structure, and the items are displayed in the same row on the right. The items can be child requirements (with associated tasks and test cases) or incidents. In this view the incidents are the ones linked to the parent requirement through an association.
The top section will contain the list of items that are not assigned to a parent requirement, with the other sections containing the items that are children of the specific parent.
"},{"location":"Spira-User-Manual/Planning-Board/#release-planning-by-priority","title":"Release Planning -- By Priority","text":"This view is designed to let you see the list of items across all releases, organized by requirement importance. Each of the possible importance values is displayed on the left-hand side and the items displayed in the same row on the right. The items in this view will only be requirements (with associated tasks and test cases).
The top section will contain the list of items that are not assigned a priority, with the other sections containing the items that have been assigned to the specific priority.
"},{"location":"Spira-User-Manual/Planning-Board/#release-planning-by-release","title":"Release Planning -- By Release","text":"This release planning view is designed to let you view the items across all releases that have been created for the product and associate them with different releases defined for the product
The 'Unassigned Items' section at the top allows you to see all the items not currently planned, and you can then drag and drop them into one of the lower sections that correspond to a specific release. Using the scroll arrows you can cycle through the releases and move any items from one release to another.
The header of each release section shows the overall progress and utilization of the release:
Clicking on the Release hyperlink will switch the planning board into the Release Backlog view described below.
"},{"location":"Spira-User-Manual/Planning-Board/#release-planning-by-status","title":"Release Planning -- By Status","text":"This view is designed to let you see the product planned items organized by requirement status. Each of the possible status values (for a planned item) is displayed as a heading, with the items displayed in the same column underneath. The items in this view will only be requirements (with associated tasks and test cases). This view is commonly called a Kanban board:
Each of the vertical sections is one of the requirements' statuses, in order of the requirement lifecycle (Planned > Completed). You can click on the expand/collapse icons to hide any statuses that are not used. You can drag and drop the requirements between the different statuses. If you have the planning options enabled to have requirements status' automatically update based on changes to the associated tasks and test cases, then items will automatically move between the statuses based on tasks being completed and test cases being executed.
"},{"location":"Spira-User-Manual/Planning-Board/#release-planning-by-person","title":"Release Planning -- By Person","text":"This view is designed to let you see the product planned items organized by resource / person. Each of the users that is a member of the current release is displayed as a heading, with the items displayed in the same column underneath. The items in this view can be either requirements (with associated tasks and test cases) or incidents.
You can click on the expand/collapse icons to hide any resources that are not relevant. Above the resource headings there is a section with the release name; that contains items that are scheduled for the current release but have not yet been assigned to a resource. You can drag and drop the items between resources (as long as the item has a status that let's you set or edit its owner field). Or you can move them to/from the release backlog. Any items not assigned to a resource and release will be listed in the (Unassigned Items) section at the top.
"},{"location":"Spira-User-Manual/Planning-Board/#release-backlog-planning","title":"Release Backlog Planning","text":"The release backlog view is designed to let you view the backlog items that have been assigned to the selected release. You can always see the items not currently assigned to any release by expanding the 'Unassigned Items' section and then drag those items into the current release.
The lower section of the board allows you to segment the items by either iteration/sprint (typically used in Scrum), by status (typically used in Kanban), or by person.
"},{"location":"Spira-User-Manual/Planning-Board/#release-backlog-by-component","title":"Release Backlog -- By Component","text":"This view is designed to let you see the release backlog organized by Component. Each of the components is displayed on the left-hand side and the backlog items displayed in the same row on the right. The backlog items can be requirements (with associated tasks and test cases) or incidents.
The top section will contain the list of items that are not assigned to a component, with the other sections containing the items that belong to the specific component.
"},{"location":"Spira-User-Manual/Planning-Board/#release-backlog-by-parent","title":"Release Backlog -- By Parent","text":"This view is designed to let you see the release backlog organized by parent requirement. Each of the parents is displayed on the left-hand side in a hierarchical structure, and the items are displayed in the same row on the right. The items can be child requirements (with associated tasks and test cases) or incidents. In this view the incidents are the ones linked to the parent requirement through an association.
The top section will contain the list of items that are not assigned to a parent requirement, with the other sections containing the items that are children of the specific parent.
"},{"location":"Spira-User-Manual/Planning-Board/#release-backlog-by-priority","title":"Release Backlog -- By Priority","text":"This view is designed to let you see the list of planned backlog items in the current release, organized by requirement importance. Each of the possible importance values is displayed on the left-hand side and the backlog items displayed in the same row on the right. The backlog items in this view will only be requirements (with associated tasks and test cases).
The top section will contain the list of items that are not assigned a priority, with the other sections containing the items that have been assigned to the specific priority.
"},{"location":"Spira-User-Manual/Planning-Board/#release-backlog-by-sprint","title":"Release Backlog -- By Sprint","text":"This view is designed to let you see the release backlog organized by iteration / sprint. Each of the sprints defined for the current release is displayed as a heading, with the backlog items displayed in the same column underneath. The backlog items in this view can be either requirements (with associated tasks and test cases) or incidents. This view is commonly called a Scrum board:
You can drag and drop the requirements between the different sprints. If you schedule a requirement for a specific sprint, all the child tasks that have not yet been started, will follow the parent requirement in being associated with the sprint. Once the backlog item has been added to the sprint, the utilized effort for the sprint will increase, and the remaining effort will decrease by the same amount.
Note: The system will allow you to assign more backlog items to an sprint than it is possible to complete, however this will result in a negative value for 'remaining effort'. If this happens, the \"Remaining\" value will be displayed in red - as will the sprint header area and the cards column. This alerts you that you need to rebalance the items, extend the sprint length, or add product personnel resources to the sprint.
Clicking on the Sprint hyperlinks in the headers will switch the planning board into the Sprint Backlog view described below.
"},{"location":"Spira-User-Manual/Planning-Board/#release-backlog-by-status","title":"Release Backlog -- By Status","text":"This view is designed to let you see the release backlog organized by requirement status. Each of the possible status values (for a planned item) is displayed as a heading, with the backlog items displayed in the same column underneath. The backlog items in this view will only be requirements (with associated tasks and test cases). This view is commonly called a Kanban board:
Each of the vertical sections is one of the requirements' statuses, in order of the requirement lifecycle (Planned > Completed). You can click on the expand/collapse icons to hide any statuses that are not used. You can drag and drop the requirements between the different statuses. If you have the planning options enabled to have requirements status' automatically update based on changes to the associated tasks and test cases, then items will automatically move between the statuses based on tasks being completed and test cases being executed.
"},{"location":"Spira-User-Manual/Planning-Board/#release-backlog-by-person","title":"Release Backlog -- By Person","text":"This view is designed to let you see the release backlog organized by resource / person. Each of the users that is a member of the current release is displayed as a heading, with the backlog items displayed in the same column underneath. The backlog items in this view can be either requirements (with associated tasks and test cases) or incidents.
You can click on the expand/collapse icons to hide any resources that are not relevant. The system will display a progress bar for each resource to illustrate the allocation for that resource. Any resource that has a progress bar that is completely green has been fully scheduled and should not have any additional items assigned. If the progress bar for that resource turns red, it means that they have been over-scheduled and you need to reassign some of the items.
Above the resource headings there is a section with the release name; that contains backlog items that are scheduled for the current release but have not yet been assigned to a resource (as long as the item has a status that let's you set or edit its owner field). You can drag and drop the backlog items between resources or to/from the release backlog. Any backlog items not assigned to a resource and release will be listed in the (Unassigned Items) section at the top.
"},{"location":"Spira-User-Manual/Planning-Board/#sprint-backlog-planning","title":"Sprint Backlog Planning","text":"The sprint backlog view is designed to let you view the backlog items that have been assigned to the selected iteration / sprint. You can always see the items not currently assigned to any release or sprint by expanding the 'Unassigned Items' section and then drag those items into the current release or sprint.
The lower section of the board allows you to segment the items by either status (typically used in Kanban), or by person. You can also view the Task artifacts by person or status for the current sprint.
"},{"location":"Spira-User-Manual/Planning-Board/#sprint-backlog-by-component","title":"Sprint Backlog -- By Component","text":"This view is designed to let you see the sprint backlog organized by Component. Each of the components is displayed on the left-hand side and the backlog items displayed in the same row on the right. The backlog items can be requirements (with associated tasks and test cases) or incidents.
The top section will contain the list of items that are not assigned to a component, with the other sections containing the items that belong to the specific component.
"},{"location":"Spira-User-Manual/Planning-Board/#sprint-backlog-by-parent","title":"Sprint Backlog -- By Parent","text":"This view is designed to let you see the sprint backlog organized by parent requirement. Each of the parents are displayed on the left-hand side in a hierarchical structure, and the items are displayed in the same row on the right. The items can be child requirements (with associated tasks and test cases) or incidents. In this view the incidents are the ones linked to the parent requirement through an association.
The top section will contain the list of items that are not assigned to a parent requirement, with the other sections containing the items that are children of the specific parent.
"},{"location":"Spira-User-Manual/Planning-Board/#sprint-backlog-by-priority","title":"Sprint Backlog -- By Priority","text":"This view is designed to let you see the list of planned backlog items in the current sprint, organized by requirement importance. Each of the possible importance values is displayed on the left-hand side and the backlog items displayed in the same row on the right. The backlog items in this view will only be requirements (with associated tasks and test cases).
The top section will contain the list of items that are not assigned a priority, with the other sections containing the items that have been assigned to the specific priority.
"},{"location":"Spira-User-Manual/Planning-Board/#sprint-backlog-by-status","title":"Sprint Backlog -- By Status","text":"This view is designed to let you see the sprint plan organized by requirement status. Each of the possible status values (for a planned item) is displayed as a heading, with the backlog items displayed in the same column underneath. The backlog items in this view will only be requirements (with associated tasks and test cases).
Each of the vertical sections is one of the requirements' statuses, in order of the requirement lifecycle (Planned > Completed). You can drag and drop the requirements between the different statuses. If you have the planning options enabled to have requirements status' automatically update based on changes to the associated tasks and test cases, then items will automatically move between the statuses based on tasks being completed and test cases being executed.
"},{"location":"Spira-User-Manual/Planning-Board/#sprint-backlog-by-person","title":"Sprint Backlog -- By Person","text":"This view is designed to let you see the sprint plan organized by resource / person. Each of the users that is a member of the current sprint is displayed as a heading, with the backlog items displayed in the same column underneath. The backlog items in this view can be either requirements (with associated tasks and test cases) or incidents.
You can click on the expand/collapse icons to hide any resources that are not relevant. The system will display a progress bar for each resource to illustrate the allocation for that resource. Any resource that has a progress bar that is completely green has been fully scheduled and should not have any additional items assigned. If the progress bar for that resource turns red, it means that they have been over-scheduled and you need to reassign some of the items.
Above the resource headings there are sections with the release and sprint name; they contain backlog items that are scheduled for the current release or sprint but have not yet been assigned to a resource. You can drag and drop the backlog items between resources or to/from the release/sprint backlog (as long as the item has a status that let's you set or edit its owner field). Any backlog items not assigned to a resource and release/sprint will be listed in the (Unassigned Items) section at the top.
"},{"location":"Spira-User-Manual/Planning-Board/#work-in-progress-limits","title":"Work In Progress Limits","text":"If the product is using Work in Progress (WIP) limits set, they will be shown in a little pill shaped badge on each relevant status, along with the number of requirement cards in that status for that release/sprint.
Read more about how to set up and use WIP limits.
"},{"location":"Spira-User-Manual/Planning-Board/#beta-planning-board","title":"Beta planning board","text":"In beta, available in SpiraTeam and SpiraPlan
System admins can enable beta functionality across the application for their users from the System Admin > General Settings page.
To learn more about how the planning board is structured or how to enter the beta please refer to our general information about the beta boards.
"},{"location":"Spira-User-Manual/Planning-Board/#views-summary","title":"Views summary","text":"Details about what combinations of views is possible and how each feature works is discussed in detail the sections below. For ease of reference, here is a summary of the different options available (you cannot select the same value for multiple view options at the same time):
View options Product Backlog Release Backlog Sprint Backlog Releases Not Available Open releases (excluding sprints) Open sprints Open parents Grouping Component Priority Component Priority Release Team Component Priority Sprint Team Columns Priority Status Priority Person Status Priority Person Status Rows Component Parent Requirement Component Person Parent Requirement Component Person Parent Requirement"},{"location":"Spira-User-Manual/Planning-Board/#view-controls-planning","title":"View controls - Planning","text":"The planning board has three different planning options. They impact what options are available in the other toolbar controls, and how the boards display:
Release backlog: lets managers review planned or in progress work items. This view displays all the planned items (based on status) so that the project manager can:
Sprint backlog: lets managers review work in a release and its sprint, or for a single sprint. This view displays all the planned items in a release and its sprints so that the product owner or manager can:
The release selector is only visible when the planning dropdown is set to either the release backlog or the sprint backlog.
When viewing the release backlog the dropdown will show:
When viewing the sprint backlog the dropdown will show:
Read about this here.
"},{"location":"Spira-User-Manual/Planning-Board/#columns","title":"Columns","text":"Read about this here.
What statuses show
What statuses shown on the board depends on how the template has been configured. In short:
Read about this here.
"},{"location":"Spira-User-Manual/Planning-Board/#customizing-the-cards","title":"Customizing the cards","text":"You can customize what information is shown on each card. For each artifact the following fields are always shown:
You can toggle whether to show each of the following features:
Note that the test coverage mini section shows the number of test cases covering the requirement in parentheses after its title. The task progress mini section shows the number of the requirement's child tasks in parentheses after its title.
Here's a typical card with all of the features described above turned off.
In the example below, is a card with all of the features described above turned on.
Finally, you can, based on your view, toggle other artifact cards to show. When this option is available you can toggle relevant artifact cards (eg Incidents) on or off. See below to learn what cards and card artifact show when.
"},{"location":"Spira-User-Manual/Planning-Board/#what-cards-show-when","title":"What cards show when","text":"Read about this here. In addition to the rules explained there, the following rules apply to how incident card display on the planning board:
Incidents have a priority field, which is different to the requirement importance field. These two fields are customized independently by template administrators.
However on the planning board, when organizing by priority, you may see both requirement cards and incident cards (if set to show). This is because the system automatically matches up incident priority and requirement importance. It does based on their names. If a requirement importance has an exactly matching incident priority (case sensitive), then any incidents with that priority will show in that \"priority\" column on the planning board. You can move incident cards between priorities and as long as there is match, the incident priority will be updated.
"},{"location":"Spira-User-Manual/Planning-Board/#what-cards-show-when-viewing-the-product-backlog","title":"What cards show when viewing the product backlog","text":"The following cards will show in this view (in combination with the relevant principles described above):
The following rules apply to what cards will show (note that more than one of these rules may apply at once):
View selected Requirements shown Incidents shown Release is all releases (Group by is not release) all requirements with a release set incidents with a planned release Release is a single release (Group by is not release) requirements with that release, or any of its child sprints incidents with that release as its planned release Group is release (Groups that are for a release) requirements with that release, or any of its child sprints incidents with that release as its planned release Group is release (in the \"unassigned\" group) requirements with no release incidents with no planned release"},{"location":"Spira-User-Manual/Planning-Board/#what-cards-show-when-viewing-the-sprint-backlog","title":"What cards show when viewing the sprint backlog","text":"The following rules apply to what cards will show (note that more than one of these rules may apply at once):
View selected Requirements shown Incidents shown Release is a single release (Group by is not release) requirements with that release, or any of its child sprints incidents with that release as its planned release Release is a single sprint (Group by is not release) requirements with that sprint incidents with that sprint as its planned release Group is sprint (Groups that are for a sprint or release) requirements with that specific sprint or release incidents with that sprint or release as its planned release Group is sprint (in the \"unassigned\" group) requirements with no release incidents with no planned release"},{"location":"Spira-User-Manual/Planning-Board/#moving-and-ordering-cards","title":"Moving and ordering cards","text":"Read about this here.
"},{"location":"Spira-User-Manual/Planning-Board/#viewing-by-release-or-sprint","title":"Viewing by release or sprint","text":"Read about this here.
"},{"location":"Spira-User-Manual/Planning-Board/#viewing-by-person","title":"Viewing by Person","text":"Read about this here.
"},{"location":"Spira-User-Manual/Planning-Board/#status-and-work-in-progress-limits","title":"Status and Work in Progress Limits","text":"When viewing by status and either grouping by releases/sprints or displaying for a release/sprint, extra information may show on each status column. If the product is using Work in Progress (WIP) limits set, the relevant limit for each status will show in a little pill shaped badge in the header for that status, along with the number of requirement cards in that status for that release/sprint. For example, if the limit is 3 and there are 2 cards then the pill will read \"\u2154\" - 2 of 3 requirements.
There are different colors to indicate the status of the WIP limit:
Read more about how to set up and use WIP limits.
"},{"location":"Spira-User-Manual/Planning-Board/#editing-and-viewing-cards","title":"Editing and viewing cards","text":"Read about this here.
"},{"location":"Spira-User-Manual/Planning-Board/#example-use-cases","title":"Example use cases","text":""},{"location":"Spira-User-Manual/Planning-Board/#scrum-projects","title":"Scrum Projects","text":"For Scrum projects, the boards support the most important agile ceremonies and planning activities. For example, you can show all the unplanned items in the product backlog for backlog grooming. In this example we are displaying user stories by parent (or epic) as rows, grouped by component and categorized into columns by priority.
Release planning: for a typical release planning section, you can use the following release backlog view. In this example, we are displaying all the releases, with the ability to take items from the product backlog (at the top) and assign them to a specific release.
Sprint planning: for a sprint planning session, the following view will let you assign work to each sprint from the release backlog:
Finally, you can drill down to look at an individual sprint and see the team's progress. This is useful for daily standup meetings:
"},{"location":"Spira-User-Manual/Planning-Board/#kanban-projects","title":"Kanban Projects","text":"For Kanban projects, in addition to the functionality described above, you have the ability to see the different releases by status, with the Work In Progress Limits clearly visible in each of the swim-lanes. In this example, we are showing the release backlog for a specific release, with the columns set to display by status and the planning options set to include WIP limits for the In-Progress and Developed columns.
"},{"location":"Spira-User-Manual/Portfolio-Homepage/","title":"Portfolio Homepage","text":""},{"location":"Spira-User-Manual/Portfolio-Homepage/#overview","title":"Overview","text":"Who Can Access the Portfolio Homepage?
To access the portfolio homepage first, you need to be using SpiraPlan. Second, your user must be a Portfolio Viewer. System Administrators can control this setting on a user by user basis. If you are a Portfolio Viewer you will also be able to access the Enterprise Homepage.
If you are NOT a portfolio viewer, you can still see how your organization structures its portfolios, programs, and products from the workspace dropdown.
When you navigate to a Portfolio from the global navigation bar or from any link to it in the application, you will be taken to the homepage of that portfolio:
This page summarizes all of the information about the portfolio in a \"one-stop-shop\". You will see a small \"i\" in a circle at the top right of each widget. Hovering or clicking on this will show you information about that chart.
In a similar manner to other home pages in the application (like the 'My Page'), the Portfolio Home is loaded in 'view mode'. To switch the page to 'edit mode', click the button with the cog icon () on the right.
In 'edit mode', each widget can be:
Together, these editing options let you change the page to suit your needs. If you close a widget and then later want to open it again click the \"+ Add\" button at the top of the page (next to the 'edit mode' button). This brings up a list of all the widgets you can add onto the page (including a list of 'Closed Widgets'). You can choose where on the page each widget should go.
Please note
Any changes you make to this page (e.g. editing, moving, closing widgets) will only affect your user and on this particular home page. They do not affect any other user.
By default, the Enterprise home page shows the following widgets and are described in more details below
This widget displays the description of the portfolio.
"},{"location":"Spira-User-Manual/Portfolio-Homepage/#requirement-completion","title":"Requirement Completion","text":"This chart shows the proportion of all active requirements that have been completed across all active programs in this portfolio. When 100% of the requirements are completed, the color changes so that it is easy to tell what is in progress vs completed.
"},{"location":"Spira-User-Manual/Portfolio-Homepage/#top-open-risks","title":"Top Open Risks","text":"This widget lists the top risks logged against any of the products in the portfolio, ordered by exposure. Clicking on the risk name will open the risk details page for the risk in question. Note: you can configure the widget settings to control the maximum number of risks to show.
"},{"location":"Spira-User-Manual/Portfolio-Homepage/#programs-completion","title":"Programs: Completion","text":"This chart shows the progress of each program in this portfolio. The left-hand shows progress from the start to end date of the program. The bar's color indicates how on track the schedule is against requirement completion. The right-hand chart shows the proportion of requirements across active workspaces in the program that have been completed.
Schedule Progress color definitions:
Example
A program started a week ago and will finish in a week. Therefore its schedule is 50% of the way through (1 week down, 1 week to go).
The Schedule Progress bar will show as 50% (if you click \"Displaying\" button to \"As Numbers\" it will show 7 days).
This program has a total of 20 requirements (summed up from all its products and their active releases). Let's say that 15 of these are completed. That's 75% complete. So the Requirements Complete bar will show 75% (if you click \"Displaying\" button to \"As Numbers\" it will show 15 completed).
So the schedule is half way through but we are three quarters done with the work (the requirements). So we are ahead of schedule (awesome!). The schedule bar will therefore have the \"Ahead of Schedule\" color.
What if, instead of finishing next week, we were supposed to finish last week? Well, the schedule bar would be flagged as \"Behind Schedule\". This is because we are only 75% complete on the work, but the end date is in the past.
Tip: You can hover over a bar to get more information.
"},{"location":"Spira-User-Manual/Portfolio-Homepage/#programs-relative-size","title":"Programs: Relative Size","text":"This chart shows the number of active requirements in each active program. Hovering over a segment will show its percentage of all requirements (this is visually represented by the size of the donut wedge). Please note, programs with no active requirements are not shown.
"},{"location":"Spira-User-Manual/Portfolio-Homepage/#schedule","title":"Schedule","text":"This Gantt chart shows all active programs, products, releases, and sprints in this portfolio. Each bar spans from the item's start date to end date. The darker shaded portion of each bar tells you how complete its requirements are.
"},{"location":"Spira-User-Manual/Portfolio-Homepage/#recent-builds","title":"Recent Builds","text":"This widget displays a list of the most recent builds for each active release (organized alphabetically by program and then product; in each product the builds are listed by date). For each build it shows:
You can change the number of builds the widget should show in the widget's settings (the default is 15).
"},{"location":"Spira-User-Manual/Product-Homepage/","title":"Product Homepage","text":""},{"location":"Spira-User-Manual/Product-Homepage/#overview","title":"Overview","text":"When you click on either the \"Product Home\" tab or the name of the product in the \"My Page\" product list, you will be taken to the homepage of the specific product in question:
This page summarizes all of the information regarding the product into a comprehensive, easily digestible form that provides a \"one-stop-shop\" for people interested in understanding the overall status of the product at a glance. It contains summary-level information for all types of artifact (requirements, test cases, incidents, etc.) that you can use to drill-down into the appropriate section of the application.
You will see a small \"i\" in a circle at the top right of every chart. Hovering or clicking on this will show you information about that chart.
In addition to viewing the product home page, you can choose to filter by a specific release, to get the homepage for just that release (and any child sprints).
Just like the 'My Page', the Product Home dashboard is initially loaded in 'view mode' with pre-configured set of widgets. The Product Home has 3 versions you can quickly switch between. While each of these can be customized as you want, by default they are designed to help different types of product member -- be they managers, testers, or developers.
To download an image of the entire dashboard click the 'picture' button beneath the currently selected view.
To switch the page to 'edit mode', you should click on the button with the cog icon () below the currently selected Product Home view.
Once in 'edit mode', each of the 'widgets' displayed on the product homepage can be minimized by clicking on the arrow icon () in the top-left of the window, or closed by clicking-on the cross icon () in the top-right of the window. In addition, the widgets allow you change their settings by clicking on the settings icon ().This allows you to customize your view of the product to reflect the types of information that are relevant to you. If you have closed a widget that you subsequently decide you want to reopen, you can rectify by clicking the \"Add Items\" button at the top of the page, and locating the closed item from the list of 'Closed Widgets'.
By default, the product home page shows the \"General\" view. The following table shows which widgets are displayed on the different views of the 'Product Home':
Widget Name General Development Testing Product Overview Y Y Y Activity Stream Y Y Shared Searches Y Schedule Y Requirement Completion Y Requirement Incident Count Y Y Y Requirements Coverage Y Y Requirements Graphs Y Y Requirements Regression Coverage Y Requirements Summary Y Y Y Release Task Progress Y Y Release Test Summary Y Y Releases/Sprints Completion Y Releases/Sprints Relative Size Y Recent Builds Y Tag Cloud Test Case Progress By Day Y Test Execution Status Y Y Test Set Status Y All Pending Test Runs Y Test Run Progress Y Incident Aging Y Incident Open Count Y Y Y Incident Test Coverage Incident Summary Y Y Y Top Open Issues Y Y Risk Summary Y Top Open Risks Y Late Finishing Tasks Y Y Late Starting Tasks Y Task Graphs Y Y Source Code Commits YPlease note that different widgets are shown by default for the \"Developer\" and for the \"Tester\" views.
If you click on the \"+ Add\" items button it will display the list of any additional widgets that are available for that view. Below is what this looks like for the 'General' view:
You can add the additional widgets by selecting the appropriate checkbox, choosing the destination location (left side vs. right side) and then click the \"Add\" button.
Each of the different widgets listed is described in more detail below:
"},{"location":"Spira-User-Manual/Product-Homepage/#product-overview","title":"Product Overview","text":"This section displays:
This section shows a list of the most recent changes made by any product member anywhere in the product. It only displays changes to artifacts that the current user is allowed to view (based on their product role). Here is an example activity item - you can see that it displays information about the user who made the change, what was changed, how it was changed, and when:
System Administrator modified Incident [IN:1] - Cannot log into the application | Tuesday, November 2, 2021 2:01:34 PM
You can configure how many recent changes to display.
Clicking the \"View All\" button at the top of this section will open the \"Activity List\" page. This page shows every change ever made in the product in a single, paginated list for artifacts that the current user is allowed to view (based on their product role).The list can be sorted on or filtered by any field. The list shows the following columns:
This section lists any filters/searches have been saved from the various artifact list screens throughout the application and marked as shared filters. This allows users to store specific combinations of searches that the product team needs to perform on a regular basis (e.g. display all newly logged incidents, display all requirements that are completed but have no test coverage).
The name of the saved search is displayed along with an icon that depicts which artifact it's for and the person who created it. Clicking on the name of the saved search will take you to the appropriate screen in the product and set the search parameters accordingly. If you are the creator of the saved search, clicking the \"Delete\" button next to the saved search will delete it. Clicking on the RSS icon will allow you to subscribe to the specific search so that it will be displayed in your RSS newsreader. This allows you to setup customized lists of information that can be displayed outside of SpiraPlan.
"},{"location":"Spira-User-Manual/Product-Homepage/#schedule","title":"Schedule","text":"This Gantt chart shows all active releases1 and sprints in this product. Each bar spans from the item's start date to end date. The darker shaded portion of each bar tells you how complete its requirements are.
"},{"location":"Spira-User-Manual/Product-Homepage/#requirement-completion","title":"Requirement Completion","text":"This chart shows the proportion of all active requirements that have been completed across all active releases in this product. When 100% of the requirements are completed, the color changes so that it is easy to tell what is in progress vs completed.
"},{"location":"Spira-User-Manual/Product-Homepage/#requirement-incident-count","title":"Requirement Incident Count","text":"This section displays a count of the total number of incidents, and the number of open incidents mapped against requirements in the system, sorted by the requirements that have the most open incidents first. This section is useful for determining the parts of the application that have the most instability, as you can look at the requirements that have yielded the greatest number of incidents. Clicking on any of the requirements hyperlinks will take you to the detail page for the requirement in question. You can configure in the settings whether to include requirements with no open incidents, and also how many rows of data to display.
"},{"location":"Spira-User-Manual/Product-Homepage/#requirements-coverage","title":"Requirements Coverage","text":"This section consists of a bar graph that displays the aggregated count of requirements test coverage for the product. The Passed, Failed, Blocked, Caution and Not-Run bars indicate the total count of requirements that have tests covering them, allocated across the execution status of the covering tests. For example, if a requirement is covered by four tests, two that have passed, one that has failed and one that has not yet been run, the counts would be passed = 0.5, failed = 0.25 and not-run 0.25. These fractional quantities are then summed across all the requirements to give the execution status breakdown of the covered requirements.
In addition to the five statuses for the covered requirements, the sixth (\"Not Covered\") bar depicts the total number of requirements that have no tests covering them, putting the five other bars into perspective. Typically a product is in good health if the \"Not Covered\" bar is zero, and the count of \"Passed\" requirements is greater than \"Failed\", \"Caution\" or \"Not Run\". The greatest risk lies with the \"Blocked\", \"Not Covered\" and \"Not Run\" status codes, since the severity/quantity of any bugs lurking within is not yet fully known.
If you position the mouse pointer over any of the four bars, the color of the bar changes slightly and the underlying raw data is displayed as a tooltip, together with the percentage equivalent. Clicking on the any of the bars in the chart will take you to the requirements list page with the corresponding filters set.
When you filter the product home by release/sprint, this widget will filter the requirements coverage graph to only include requirements that are specifically mapped to the selected release/sprint. This is useful when you want to determine the test coverage of new requirements that are being added to the specific release/sprint. If instead you want to determine the regression test coverage for a release, you should add the separate \"Requirements Regression Coverage\" widget to the page instead.
"},{"location":"Spira-User-Manual/Product-Homepage/#requirements-graphs","title":"Requirements Graphs","text":"This widget lets you quickly view four different graphs used when measuring the progress of requirements in an agile methodology. They are described in more detail in Reports.
Requirement Velocity -- this graph shows the actual velocity delivered in each product release and/or sprint compared to the product average and the rolling average.
Requirement Burnup -- this graph shows the cumulative number of story points outstanding for each release/sprint in the product with separate lines for the actual and ideal burnup overlaid on top of a bar-graph that shows the completed story points per release/sprint.
Requirement Burndown -- this graph shows the remaining number of story points that needs to be done for each release/sprint in the product with separate lines for the actual and ideal burndown overlaid on top of a bar-graph that shows the completed story points per release/sprint.
Requirements Coverage -- this graph shows the number of requirements that have test cases that are passed, failed, blocked, cautioned, not run as well those requirements that do not have any test cases (not covered). Unlike the main Requirements Coverage graph on the home page, this one is segmented by requirement importance.
For each of the three graphs you can click on the \"Display Data Grid\" link to display a grid of the underlying data that is represented in the graph and also there are options to save the graph in a variety of different image formats.
"},{"location":"Spira-User-Manual/Product-Homepage/#requirements-regression-coverage","title":"Requirements Regression Coverage","text":"This section consists of a bar graph that displays the aggregated count of requirements test coverage for the product in a similar fashion to the 'Requirements Coverage' widget:
However, unlike the 'Requirements Coverage' widget, when you filter the product home by release/sprint, this widget will filter the requirements coverage graph to include all requirements (regardless of release/sprint), but only considering covering test cases that are associated with the selected release/sprint. This is useful when you want to determine the regression requirements test coverage of a specific release (i.e. does running all the tests relevant to this release cover all the necessary requirements, not just new requirements).
"},{"location":"Spira-User-Manual/Product-Homepage/#requirements-summary","title":"Requirements Summary","text":"This section consists of a summary table that displays the aggregate count of requirements in the system broken-down by importance (on the x-axis) and status (on the y-axis). This allows the product manager to determine how many critical vs. low priority enhancements are waiting to be implemented, vs. actually being implemented. In addition, it makes a distinction between those requirements simply requested and those actually planned for implementation, so the product manager can see what the backlog is between the customer's demands, and the plan in place. Clicking on the \"View Details\" button at the top of the table takes you to the Requirement list page. Clicking on the individual values in the cells will display the requirements list with the filter set to match the importance and status of the value.
"},{"location":"Spira-User-Manual/Product-Homepage/#release-task-progress","title":"Release Task Progress","text":"This widget allows you to quickly ascertain the task progress of each of the active releases that make up the current product in one snapshot. Each release is displayed together with a graphical display that illustrates the completion percentage and status with different colored bars. In addition, if you hover the mouse over the graphical display it will display a tooltip that provides a more detailed description of the number of tasks in each status.
Each release will display the aggregate progress of any tasks directly assigned to itself, together with the task progress of any child sprints that are contained within the Release. Clicking on one of the releases will drill you down one level further and display the task progress for the parent release as well as each of the child sprints separately:
"},{"location":"Spira-User-Manual/Product-Homepage/#release-test-summary","title":"Release Test Summary","text":"This widget allows you to quickly ascertain the test execution status of each of the active releases that make up the current product in one snapshot. Each release is displayed together with a graphical display that illustrates the execution status with different colored bars. In addition, if you hover the mouse over the graphical display it will display a tooltip that provides a more detailed description of the number of tests in each status.
Each release will display the aggregate status of any test cases directly assigned to itself, together with the test status of any child sprints that are contained within the Release. Clicking on one of the releases will drill you down one level further and display the test execution status for the parent release as well as each of the child sprints separately:
"},{"location":"Spira-User-Manual/Product-Homepage/#releasessprints-completion","title":"Releases/Sprints Completion","text":"This chart shows the progress of each active release with requirements attached in this product. The left-hand chart shows progress from the start to end date of the release. The bar's color indicates how on track the schedule is against requirement completion. The right-hand chart shows the proportion of requirements in the release that have been completed.
Displaying for a Release
Normally this widget does not show sprints. However if you have set the dashboard to display information for a particular release, this widget will show any children of that release - including any sprints. The specific release you are displaying for is not shown in the widget.
Schedule Progress color definitions:
Example
A release started a week ago and will finish in a week. Therefore its schedule is 50% of the way through (1 week down, 1 week to go).
The Schedule Progress bar will show as 50% (if you click \"Displaying\" button to \"As Numbers\" it will show 7 days).
This release has a total of 20 requirements (summed up from all its active child releases and sprints, if any). Let's say that 15 of these are completed. That's 75% complete. So the Requirements Complete bar will show 75% (if you click \"Displaying\" button to \"As Numbers\" it will show 15 completed).
So the schedule is half way through but we are three quarters done with the work (the requirements). So we are ahead of schedule (awesome!). The schedule bar will therefore have the \"Ahead of Schedule\" color.
What if, instead of finishing next week, we were supposed to finish last week? Well, the schedule bar would be flagged as \"Behind Schedule\". This is because we are only 75% complete on the work, but the end date is in the past.
Tip: You can hover over a bar to get more information.
"},{"location":"Spira-User-Manual/Product-Homepage/#releasessprints-relatize-size","title":"Releases/Sprints Relatize Size","text":"This chart shows the number of active requirements in each active release. Hovering over a segment will show its percentage of all requirements (this is visually represented by the size of the donut wedge). Please note, releases with no active requirements are not shown.
Displaying for a Release
Normally this widget does not show sprints. However if you have set the dashboard to display information for a particular release, this widget will show any children of that release - including any sprints. The specific release you are displaying for is not shown in the widget. The widget will also show sprints if you ONLY have ative sprints in this product (i.e. if there are no active major or minor releases at all).
"},{"location":"Spira-User-Manual/Product-Homepage/#recent-builds","title":"Recent Builds","text":"This widget displays a list of the most recent builds that have been performed as part of the current release or sprint:
For each build it will display whether the build succeeded or failed, the date the build occurred and the name of the build together with a hyperlink to the build details. Note: If no release or sprint is selected then the widget will not display any data.
"},{"location":"Spira-User-Manual/Product-Homepage/#tag-cloud","title":"Tag Cloud","text":"This widget lets you see the list of document tags being used in the product:
The size of the tag name indicates the relative frequency of its usage in the product. Clicking on a document tag will open up the Document List page with the filter set to the tag you clicked on. This will display a list of related documents that have been tagged with the same tag name.
"},{"location":"Spira-User-Manual/Product-Homepage/#test-case-cumulative-progress","title":"Test Case Cumulative Progress","text":"This section consists of a chart that displays the last 30 days of test case executions cumulatively. That means it will display for each day, the total number of test cases executed plus the status from any previous days that have not been changed. Any test cases not executed up to that point will be considered \"not run\" and will appear in the \"not run\" category. For example, if you have 10 test cases created on day 1 you will see 10 test cases \"not run\" on day 1. On day 2, you execute 5 test cases and fail them all, you will now see 5 test cases failed and 5 not run. On day 3, you execute 3 of the previous 5 test cases and pass them. You will now see 3 test cases passed, 2 failed and 5 not run.
"},{"location":"Spira-User-Manual/Product-Homepage/#test-execution-status","title":"Test Execution Status","text":"This section consists of a bar graph that displays the aggregated count of test cases in each execution status for the product. Note that this graph does not consider past test-runs when calculating the totals in each status (Passed, Failed, Not Run, etc.), it simply looks at each test-case and uses the last-run status as the best health indicator. Thus if a test case that previously passed, has subsequently failed upon re-execution, it will be considered a failure only.
If you position the mouse pointer over any of the five bars, the color of the bar changes slightly and the underlying raw data is displayed as a tooltip, together with the percentage equivalent. Clicking on any of the bars will bring up the product test case list with the appropriate filter applied.
In addition to the bar-chart, there is also a display of the total number of test runs recorded for the product, and a list of the five most recent days of recorded test-runs, together with the daily count.
"},{"location":"Spira-User-Manual/Product-Homepage/#test-set-status","title":"Test Set Status","text":"This section consists of a bar graph that displays the aggregated count of test cases in each execution status for each test set in the product:
Therefore if you have the same test cases stored in multiple test sets, then this widget will display the total test case count for all combinations of test set. This is useful if you have the same test cases being executed in different environments -- represented by different test sets -- and you need to make sure that the tests passed successfully in all environments.
If you position the mouse pointer over any of the five bars, the color of the bar changes slightly and the underlying raw data is displayed as a tooltip, together with the percentage equivalent. Clicking on any of the bars brings up the product test set list page with the appropriate filter applied. In addition to the bar-chart, there is also a display of (up to) the five most overdue test sets in the product.
"},{"location":"Spira-User-Manual/Product-Homepage/#all-pending-test-runs","title":"All Pending Test Runs","text":"This section lists all the test runs that are currently being executed by testers in the product. Until a test case or test set is fully executed, a pending test run entry is stored in the system so that you can continue execution at a later date.
Any pending test run can be either deleted or reassigned to another member of the product. NOTE: only product administrators can delete or reassign test runs from this widget.
"},{"location":"Spira-User-Manual/Product-Homepage/#test-run-progress","title":"Test Run Progress","text":"This section consists of a chart that displays the last 30 days of test run activity, broken down, for each day, by the test run status. This is a useful chart to quickly track the testing activity of the product -- this is not the same as overall product status.
"},{"location":"Spira-User-Manual/Product-Homepage/#incident-aging","title":"Incident Aging","text":"This section displays the number of days incidents have been left open in the system. The chart is organized as a histogram, with the count of incidents on the y-axis and different age intervals on the x-axis.
"},{"location":"Spira-User-Manual/Product-Homepage/#incident-open-count","title":"Incident Open Count","text":"This section show a bar chart to visualize the breakdown of all open incidents in the product by priority. The chart's bar match the color assigned to that priority. Clicking on the \"View Details\" link at the top of the widget opens the Incident list page.
"},{"location":"Spira-User-Manual/Product-Homepage/#incident-summary","title":"Incident Summary","text":"This section consists of a summary table that displays the aggregate count of incidents in the system broken-down by priority (on the x-axis) and status (on the y-axis). This allow the product manager to determine how many critical vs. low priority incidents are waiting to be addressed, and how many new items need to be categorized and assigned. Clicking on the \"View Details\" link at the top of the table opens the Incident list page. Clicking on the individual values in the cells will display the incident list with the filter set to match the priority and status of the value.
By default this summary table displays the total count of all incidents -- regardless of type, however my changing the drop-down list to a specific incident type (e.g. bug, enhancement, issue, etc.), the product manager can filter the summary table to just items of that type. You can also configure in the settings whether to use Priority or Severity for the x-axis
"},{"location":"Spira-User-Manual/Product-Homepage/#incident-test-coverage","title":"Incident Test Coverage","text":"This section displays a bar-graph that illustrates the execution status of any test cases that previously failed and resulted in the generation of an incident that has subsequently been resolved. This is very useful when a test case was executed in Release 1.0 and an incident was logged. That incident has now been resolved in Release 1.1 (and is in a closed status) but we need to know that the test case that caused the failure has been successfully re-run. Any test cases listed as Blocked, Caution, Not-Run, Not Applicable, or Failed in this graph need to be executed to verify that all resolved bugs in the release have truly been fixed.
"},{"location":"Spira-User-Manual/Product-Homepage/#top-open-issues","title":"Top Open Issues","text":"Issues are a subset of Incidents. Admins can control which types of incident should be considered issues. All incidents that have a type marked in this way are considered \"issues.\"
This widget shows a breakdown of the top issues logged in the product, in order of decreasing priority. Issues that do not have a priority are listed at the top, since critical issues could be lurking in that list. Only open issues are shown. Clicking on the issue's hyperlink opens incident details page for that issue.
You can configure in the settings whether to use Priority or Severity for the display, and also how many rows of data to display.
"},{"location":"Spira-User-Manual/Product-Homepage/#risk-summary","title":"Risk Summary","text":"This section displays a two dimensional matrix of the open risks logged against the product of impact against probability. Combined these two dimensions are reflected in the risks exposure and each differently colored rectangle in the matrix represents one possible exposure. The number of risks that have a particular exposure are shown inside each rectangle as appropriate. Clicking on that number will take you to the risk list page filtered by the relevant exposure.
"},{"location":"Spira-User-Manual/Product-Homepage/#top-open-risks","title":"Top Open Risks","text":"This widget displays a breakdown of the top open risks in the product, in order of decreasing risk exposure. For each row you see:
You can edit the widget to: show/hide the risk owner column; show/hide the risk type column; and the number of rows to display (max of 50).
"},{"location":"Spira-User-Manual/Product-Homepage/#late-finishing-tasks","title":"Late Finishing Tasks","text":"This section displays the list of any product tasks that have not yet been completed, but whose scheduled end date has already elapsed. A graphical progress bar is included with each task in the grid, so that you can easily see which tasks are nearest completion.
"},{"location":"Spira-User-Manual/Product-Homepage/#late-starting-tasks","title":"Late Starting Tasks","text":"This section displays the list of any product tasks that have not yet started, but whose scheduled start date has already elapsed:
Each task is listed along with its owner, priority and due-date so that you quickly ascertain how many days late it will be starting, how important it is to the product, and who needs to be contacted to get more information.
"},{"location":"Spira-User-Manual/Product-Homepage/#task-graphs","title":"Task Graphs","text":"This widget lets you quickly view the three main graphs used when measuring the progress of tasks in an agile methodology:
This section consists of a chart that displays the last 3 months of code commits to the product (if you are using the source code functionality of the application). Commits are aggregated by week. The chart is color coded by bottom quartile, the middle 50%, and the top quartile of activity.
Above the chart is a branch selector. This shows you the current branch and lets you choose which branch in the source code repository to view. This is stored for your user across the whole product, which means that you will see information for this same branch in other relevant places - eg when viewing files, or when viewing commits.
Below the chart is a list of the five most recent commits, along with the date they were made (hovering over the commit name will show a tooltip with the commit message and exact time of the commit). Click the \"View All\" button to open the commit list page.
any release / sprint / phase with a status that is not \"Closed\", \"Deferred\", or \"Cancelled\".\u00a0\u21a9
These features are only available in SpiraPlan
Capabilities and Program Milestones give you powerful ways to manage delivery of features and releases across multiple products at once - in other words at a program level. Capabilities let you define cross-product, program-level features (requirements). You can customize capabilities with system-wide types, statuses, priorities, and fully customizable fields. You can link capabilities to product requirements to track their progress at a higher level, and tag them with a program milestone to manage their delivery timetable.
Use cases for capabilities
You can think of capabilities as program-level requirements. With deep customizations, you can use them in a variety of different ways. Here are a few to help guide you using them.
A capability's Progress is a special field that shows a mini chart. This chart represents the percentage completion of all relevant requirements associated directly to the capability.
The percentaged complete is calculated by dividing the number of \"completed requirements\" (described below) by the total number of requirements associated to the capability. A \"completed requirement\" is a requirement with a status of either \"Tested\", \"Completed\", or \"Released\". Hover over the mini chart to see more specific information.
Examples
To access capabilities, navigate to a program and then open the artifact dropdown. Select \"Capabilities\". This will open the capability list page. The capability list is a hierarchical collection of the capabilities. You can move the capabilities to a specific position in the hierarchy (above or below another specific capability), and you can indent capabilities to create parent and child capabilities. You can only have one level of indentation (in other words, you cannot have children that themselves also have children). At first, the list will be empty.
"},{"location":"Spira-User-Manual/Program-Capabilities/#list-page-toolbar-operations","title":"List page toolbar operations","text":"You can carry out a number of useful operations with the toolbar:
Insert this button has several features to add new capabilities (see below). When added the new capability is in \"Edit\" mode so you can set its name and other information.
Insert or New Capability from the button's dropdownChild Capability button from the dropdown Insert with nothing selected. Note that if the list goes over more than one page, the new capability will be at the bottom of the last pageDelete: deletes all currently selected capabilities. If any of them is a parent, their child capabilities are also deleted. If all the children are deleted from a parent, it changes back into a non-parent
Edit: this will switch any selected capabilities into Edit mode. You can achieve the same thing by clicking the \"Edit\" button at the top of the list itself. You can switch on edit mode for capabilities one at a time by clicking the \"Edit\" button for each specific row or by double clicking one of the cells in a row. When in edit mode, the row will show a \"Save\" button to commit the changes, and \"Cancel\" to discard them. The edit menu also has a dropdown of other options
Show / Hide Columns: By default the following columns are shown: ID, name, progress, type, status, and owner. The columns dropdown lets you change the columns shown (for standard and custom properties). Toggle a column's visibility by clicking on it from the dropdown. The shown columns is saved for each user and for each program.
Using the cut and paste buttons described above, you can move capabilities around the hierarchy. Alternatively, you can select the capabilities and drag and drop them into their new position.
"},{"location":"Spira-User-Manual/Program-Capabilities/#capability-details","title":"Capability Details","text":"When you click on a capability it will open its capability details page:
This page is made up of three areas;
Please note that on smaller screen sizes the navigation pane is not displayed. While the navigation pane has a link to take you back to the list page, on mobile devices a 'back' button is shown on the left of the operations toolbar.
The navigation pane can be collapsed by clicking on the \"-\" button, or expanded by clicking anywhere on the gray title area. On desktops the user can also control the exact width of the navigation pane by dragging and dropping a red handle that appears on hovering at the rightmost edge of the navigation pane.
The navigation pane shows a list of capabilities. This list is useful as a navigation shortcut - you can quickly view the peer capabilities by clicking on the navigation links, without having to first return to the list page. The navigation list can be switched between two different modes:
Save: to save the current item
Refresh: refreshes the name, info bar information, and overview tab for the item
New: adds a new item immediately below the current capability (and if the current capability is a child the new item is added as a child to the same parent)
Delete: deletes the current capability. If it is a parent, its child capabilities are also deleted
The info bar shows the following information for the capability: name, icon (different for parent and children), ID, type, status, and progress mini chart
"},{"location":"Spira-User-Manual/Program-Capabilities/#overview","title":"Overview","text":"The Overview tab is divided into a number of different sections. Each of these can be collapsed or expanded by clicking on the title of that section. Each section displays fields of a similar type. For instance, all fields regarding dates are grouped together in the \"Dates and Times\" area.
The bottom most section contains the long, formatted description, followed by any rich text custom fields. You can enter rich text or paste in from a word processing program or web page into these fields. Note that you are not able to paste screenshots into these description boxes
"},{"location":"Spira-User-Manual/Program-Capabilities/#requirement-associations","title":"Requirement Associations","text":"You can associate requirements from any product inside the current program to a capability from this tab. Any requirements linked to the capability feed into the progress calculation of the capability. The associated requirements show the following information: name, status, product name, owner, and ID.
Read more about how to manage and add associations to this artifact
"},{"location":"Spira-User-Manual/Program-Homepage/","title":"Program Homepage","text":""},{"location":"Spira-User-Manual/Program-Homepage/#overview","title":"Overview","text":"When you navigate to a Program from the global navigation bar or from any link to it in the application, you will be taken to the homepage of that program:
This page summarizes all of the information about the program in a \"one-stop-shop\". The Program Homepage has 3 versions you can quickly switch between. While each of these can be customized as you want, by default they are designed to help different types of user: managers, testers, and developers.
You will see a small \"i\" in a circle at the top right of each widget. Hovering or clicking on this will show you information about that chart.
In a similar manner to other home pages in the application (like the 'My Page'), the Program Home is loaded in 'view mode'. To switch the page to 'edit mode', click the button with the cog icon () on the right.
In 'edit mode', each widget can be:
Together, these editing options let you change the page to suit your needs. If you close a widget and then later want to open it again (or the widget is not visible on the page) click the \"+ Add\" button at the top of the page (next to the 'edit mode' button). This brings up a list of all the widgets you can add onto the page (including a list of 'Closed Widgets'). You can choose where on the page each widget should go.
Please note
Any changes you make to this page (e.g. editing, moving, closing widgets) will only affect your user and on this particular home page. They do not affect any other user.
By default, the program home page shows the \"General\" view. The following table shows which widgets are displayed on the different views of the 'Product Home':
Widget Name General Development Testing Program Overview Y Y Y Product List Y Y Y Products: Completion Y Products: Relative Size Y Schedule Y Requirement Completion Y Y Requirements Coverage Y Y Recent Builds Y Y Test Execution Status Y Y Incident Aging Y Y Top Open Issues Y Y Top Open Risks Y Task Progress Y"},{"location":"Spira-User-Manual/Program-Homepage/#program-overview","title":"Program Overview","text":"This section displays the name of the program, together with a brief description, the web-site that points to any additional information about the program, and the names of the owners of the program. In SpiraPlan, if the program is part of a portfolio, the portfolio name is also shown.
"},{"location":"Spira-User-Manual/Program-Homepage/#product-list","title":"Product List","text":"This section lists all the active products that make up the program, together with the name, description, program and date of creation. To view the description of the product, simply position the mouse pointer over the link, and a tooltip window will popup containing the description.
"},{"location":"Spira-User-Manual/Program-Homepage/#products-completion","title":"Products: Completion","text":"This chart shows the progress of each active release with requirements attached in this product. The left-hand chart shows progress from the start to end date of the release. The bar's color indicates how on track the schedule is against requirement completion. The right-hand chart shows the proportion of requirements in the release that have been completed.
Schedule Progress color definitions:
Example
A product started a week ago and will finish in a week. Therefore its schedule is 50% of the way through (1 week down, 1 week to go).
The Schedule Progress bar will show as 50% (if you click \"Displaying\" button to \"As Numbers\" it will show 7 days).
This product has a total of 20 requirements (summed up from all of its active releases). Let's say that 15 of these are completed. That's 75% complete. So the Requirements Complete bar will show 75% (if you click \"Displaying\" button to \"As Numbers\" it will show 15 completed).
So the schedule is half way through but we are three quarters done with the work (the requirements). So we are ahead of schedule (awesome!). The schedule bar will therefore have the \"Ahead of Schedule\" color.
What if, instead of finishing next week, we were supposed to finish last week? Well, the schedule bar would be flagged as \"Behind Schedule\". This is because we are only 75% complete on the work, but the end date is in the past.
Tip: You can hover over a bar to get more information.
"},{"location":"Spira-User-Manual/Program-Homepage/#products-relative-size","title":"Products: Relative Size","text":"This chart shows the number of active requirements in each active product. Hovering over a segment will show its percentage of all requirements (this is visually represented by the size of the donut wedge). Please note, products with no active requirements are not shown.
"},{"location":"Spira-User-Manual/Program-Homepage/#schedule","title":"Schedule","text":"This Gantt chart shows all active releases and sprints in this program. Each bar spans from the item's start date to end date. The darker shaded portion of each bar tells you how complete its requirements are.
"},{"location":"Spira-User-Manual/Program-Homepage/#requirement-completion","title":"Requirement Completion","text":"This chart shows the proportion of all active requirements that have been completed across all active products in this program. When 100% of the requirements are completed, the color changes so that it is easy to tell what is in progress vs completed.
"},{"location":"Spira-User-Manual/Program-Homepage/#requirements-coverage","title":"Requirements Coverage","text":"This section consists of a bar graph that displays the aggregated count of requirements test coverage for the entire program. The Passed, Failed, Blocked, Caution and Not-Run bars indicate the total count of requirements that have tests covering them, allocated across the execution status of the covering tests
Under the main bar graph is displayed a table containing each product in the program and a colored bar illustrating the specific requirements coverage distribution for that product. That way you can see both the aggregate coverage and also the relative coverage for the products. You can choose to show the aggregate bar graph, and/or the product-specific requirements coverage from the widget settings.
By default, this widget shows data for active releases only in each product in the program. You can choose to show data for all releases in all products of the program from the widget settings.
"},{"location":"Spira-User-Manual/Program-Homepage/#task-progress","title":"Task Progress","text":"This section consists of a bar graph that displays the aggregated count of tasks by progress category for the entire program. The 'On Schedule', 'Late Finish', 'Late Start' and 'Not Started' bars indicate the total count of tasks that are in that category for all the products in the program.
Under the main bar graph is displayed a table containing each product in the program and a colored bar illustrating the specific task progress for that product (using the same coloring convention as the main graph). That way you can see both the aggregate task progress and also the relative progress for each product. You can choose to show the aggregate bar graph, and/or the product-specific task progress from the widget settings.
By default, this widget shows data for active releases only in each product in the program. You can choose to show data for all releases in all products of the program from the widget settings.
"},{"location":"Spira-User-Manual/Program-Homepage/#test-execution-status","title":"Test Execution Status","text":"This section consists of a bar graph that displays the aggregated count of test cases by execution status for the entire program. The Passed, Failed, Blocked, Caution and Not-Run bars indicate the total count of test cases that are in that category for all the products in the program.
Under the main bar graph is displayed a table showing each product in the program with the following information:
By default, this widget shows data for active releases only in each product in the program.
In the widget settings you can choose to:
This section displays the number of days incidents have been left open in the system. The chart is organized as a histogram, with the count of incidents on the y-axis (for all products in the program) and different age intervals on the x-axis.
Under the main bar graph is displayed a table containing each product in the program and a colored bar illustrating the distribution of open incidents by priority for that product. That way you can see both the aggregate aging for the program and also the relative priority of open incidents for each product. You can configure in the widget settings whether you want to see the aggregate aging histogram, and/or the product-specific incident count by priority.
"},{"location":"Spira-User-Manual/Program-Homepage/#top-open-issues","title":"Top Open Issues","text":"This section displays a breakdown of the top issues logged against any of the products in the program, in order of decreasing priority. Note that items not given a priority are listed at the top, since critical issues could be lurking in that list, and the product manager will want to immediately review these to assign priorities. Clicking on the issue item hyperlink will take you to the incident details page for the issue in question (see Incident Tracking > Incident Details). You can configure in the settings whether to use Priority or Severity for the display, and also how many rows of data to display.
"},{"location":"Spira-User-Manual/Program-Homepage/#top-open-risks","title":"Top Open Risks","text":"This widget lists the top risks logged against any of the products in the portfolio, ordered by exposure. Clicking on the risk name will open the risk details page for the risk in question. Note: you can configure the widget settings to control the maximum number of risks to show.
"},{"location":"Spira-User-Manual/Program-Homepage/#recent-builds","title":"Recent Builds","text":"This widget displays a list of the most recent builds for each active release (organized alphabetically by product; in each product the builds are listed by date). For each build it shows:
You can change the number of builds the widget should show in the widget's settings (the default is 15).
"},{"location":"Spira-User-Manual/Program-Homepage/#product-test-summary","title":"Product Test Summary","text":"This table shows an information-dense, but easy to understand assessment of each product by a number of key metrics. It shows each product in the program, together with:
The program incident list is only available in SpiraPlan. If you are using SpiraPlan, to access the program incident list, you must be a member of the program (i.e. a program owner or executive).
The program incident list lets you see all of the incidents (bugs, enhancements, issues, risks, etc.) in the current program, displayed in an integrated table view showing incidents':
You can access this feature by clicking on the Incidents menu entry in the program navigation. You can filter and sort by specific product, or by the various fields displayed in the table.
"},{"location":"Spira-User-Manual/Program-Management/","title":"Program Management","text":""},{"location":"Spira-User-Manual/Program-Management/#redirects","title":"Redirects","text":"These features are only available in SpiraPlan
Program Milestones and Capabilities give you powerful ways to manage delivery of features and releases across multiple products at once - in other words at a program level. Program milestones let you define cross-product, program-level date goals / milestones (like releases or sprints). You can customize program milestones with system-wide types, statuses, and fully customizable fields. You can link program milestones to product releases to track their scheduling at a higher level. Program milestones also let you track capabilities' delivery.
Use cases for program milestones
You can think of program milestones as program-level releases. With deep customizations, you can use them in a variety of different ways. Here are a few to help guide you using them.
A program milestone's Progress is a special field that shows a mini chart. This chart represents the percentage completion of all relevant capabilities associated directly to the program milestone.
The percentaged complete is calculated by dividing the number of \"closed capabilities\" (based on their current status) by the total number of capabilities associated to the program milestone. Hover over the mini chart to see more specific information.
The mini chart shows different colors to help you quickly see if progress is on or off track:
Progress %age Start date End date Mini chart color 0 In the future Anything Gray 0 In the past Anything Yellow Above 0, Below 100 Anything In the future Green (remaining is gray) Above 0, Below 100 Anything In the past Red (remaining is gray) 100 Anything Anything GreenExamples
Program milestones have start and end dates. This lets you manually set the range when work for the program milestone starts and ends. In addition, each program milestone has a \"Child Start Date\" and a \"Child End Date\". These dates are set automatically based on all of the releases associated to the program milestone:
Examples
In this example, we have the following releases across a number of products
Release Start Date End Date Sprint 1 May 3rd May 20th Sprint 2 May 15th June 2nd Sprint 3 May 22nd June 5th Sprint 4 May 1st June 10thWhen we associate these to different program milestones the child start and end dates get automatically set as follows:
Program milestone Associated releases Child start date Child end date First Sprint 1, Sprint 2 May 3rd June 2nd Second Sprint 1, Sprint 4 May 1st June 10th Third Sprint 2, Sprint 3 May 15th June 5th"},{"location":"Spira-User-Manual/Program-Milestones/#milestone-list","title":"Milestone List","text":"To access program milestones, navigate to a program and then open the artifact dropdown. Select \"Program Milestones\". This will open the program milestone list page. The list is a flat, sortable collection of the program milestones.
"},{"location":"Spira-User-Manual/Program-Milestones/#list-page-toolbar-operations","title":"List page toolbar operations","text":"You can carry out a number of useful operations with the toolbar:
When you click on a program milestone it will open its program milestone details page:
This page is made up of three areas;
Please note that on smaller screen sizes the navigation pane is not displayed. While the navigation pane has a link to take you back to the list page, on mobile devices a 'back' button is shown on the left of the operations toolbar.
The navigation pane can be collapsed by clicking on the \"-\" button, or expanded by clicking anywhere on the gray title area. On desktops the user can also control the exact width of the navigation pane by dragging and dropping a red handle that appears on hovering at the rightmost edge of the navigation pane.
The navigation pane shows a list of program milestones. This list is useful as a navigation shortcut - you can quickly view the peer program milestones by clicking on the navigation links, without having to first return to the list page. The navigation list can be switched between two different modes:
Save: to save the current item
Refresh: refreshes the name, info bar information, and overview tab for the item
New: opens the new program milestone details page, where you can enter its information and hit save to actually create the item
Delete: deletes the current program milestone
The info bar shows the following information for the program milestone: name, icon, ID, type, status, and progress mini chart
"},{"location":"Spira-User-Manual/Program-Milestones/#overview","title":"Overview","text":"The Overview tab is divided into a number of different sections. Each of these can be collapsed or expanded by clicking on the title of that section. Each section displays fields of a similar type. For instance, all fields regarding dates are grouped together in the \"Dates and Times\" area.
The bottom most section contains the long, formatted description, followed by any rich text custom fields. You can enter rich text or paste in from a word processing program or web page into these fields. Note that you are not able to paste screenshots into these description boxes
"},{"location":"Spira-User-Manual/Program-Milestones/#release-associations","title":"Release Associations","text":"You can associate releases from any product inside the current program to a program milestone from this tab. Any releases linked to the program milestone feed into the child start and end dates of the program milestone. The associated releases show the following information: name, type, status, start date, end date, product name, owner, and ID.
Read more about how to manage and add associations to this artifact
"},{"location":"Spira-User-Manual/Program-Milestones/#capability-associations","title":"Capability Associations","text":"When you create or edit capabilities, you can optionally set their program milestone. On this tab you can see all capabilities currently linked to the program milestone. Any capability linked to the program milestone feed into the progress of the program milestone. The associated capabilities show the following information: name, type, status, owner, and ID.
You can refresh the list of capabilities, or filter the list.
"},{"location":"Spira-User-Manual/Program-Planning-Board/","title":"Planning Board","text":""},{"location":"Spira-User-Manual/Program-Planning-Board/#program-planning-board","title":"Program Planning Board","text":"The program planning board is only available in SpiraPlan. If you are using SpiraPlan, to access the program planning board, you must be a member of the program (i.e. a program owner or executive).
The program planning board is designed to let you view the backlog items that need to be planned for all of the products in a specific program as well as view all of the planned items in each of the individual products. It is designed to let you see a product-group wide view of all requirements and associated test cases and tasks. You can access this feature by clicking on the Planning menu entry in the program navigation.
The program planning board has the following views:
Each of these views is described below.
"},{"location":"Spira-User-Manual/Program-Planning-Board/#program-backlog-by-priority","title":"Program Backlog -- by Priority","text":"This view is designed to let you see the program backlog organized by requirement importance. Each of the possible importance values is displayed on the left-hand side and the backlog items displayed in the same row on the right. The backlog items in this view will only be requirements (with associated tasks and test cases).
The top section will contain the list of items that are not assigned a priority, with the other sections containing the items that have been assigned to the specific priority.
"},{"location":"Spira-User-Manual/Program-Planning-Board/#program-backlog-by-status","title":"Program Backlog -- by Status","text":"This view is designed to let you see the program backlog organized by requirement status. Each of the possible status values (for an unscheduled item) is displayed as a heading, with the backlog items displayed in the same column underneath. The backlog items in this view will only be requirements (with associated tasks and test cases). This view is commonly called a Kanban board:
Each of the vertical sections is one of the requirements' statuses, in order of the requirement lifecycle (Requested > Accepted). Once a requirement is assigned to a release or sprint it will come automatically 'Planned' and not appear in this view. You can drag and drop the requirements between the different statuses.
"},{"location":"Spira-User-Manual/Program-Planning-Board/#all-products-by-priority","title":"All Products -- by Priority","text":"This program planning view is designed to let you see all of the backlog items that have been scheduled for all of the products in the current program, organized by requirement importance/priority.
Each of the possible importance values is displayed on the left-hand side and the backlog items displayed in the same row on the right. The backlog items in this view will only be requirements (with associated tasks and test cases).
The top section will contain the list of items that are not assigned a priority, with the other sections containing the items that have been assigned to the specific priority.
"},{"location":"Spira-User-Manual/Program-Planning-Board/#all-products-by-product","title":"All Products -- by Product","text":"The program planning view is designed to let you view the open (not-completed) backlog items currently planned per product. The backlog items are themselves only requirements, however you can see the tasks and test cases associated with a specific requirement.
Clicking on the product hyperlink will switch the planning board into the Product Backlog view described below.
"},{"location":"Spira-User-Manual/Program-Planning-Board/#all-products-by-status","title":"All Products -- by Status","text":"This view is designed to let you see the scheduled backlog items for the entire program organized by requirement status. Each of the possible status values (for a planned item) is displayed as a heading, with the backlog items displayed in the same column underneath. The backlog items in this view will only be requirements (with associated tasks and test cases). This view is commonly called a Kanban board:
Each of the vertical sections is one of the requirements' statuses, in order of the requirement lifecycle (Planned > Completed). You can click on the expand/collapse icons to hide any statuses that are not used. You can drag and drop the requirements between the different statuses. If you have the planning options enabled to have requirements status' automatically update based on changes to the associated tasks and test cases, then items will automatically move between the statuses based on tasks being completed and test cases being executed.
"},{"location":"Spira-User-Manual/Program-Planning-Board/#all-products-by-person","title":"All Products -- by Person","text":"This view is designed to let you see the program backlog organized by resource / person. Each of the users that is a member of any of the products in the current program is displayed as a heading, with the backlog items displayed in the same column underneath.
You can click on the expand/collapse icons to hide any resources that are not relevant. Above the resource headings there is a section called 'Unassigned Items'; that contains backlog items that are scheduled but have not yet been assigned to a person.
"},{"location":"Spira-User-Manual/Program-Planning-Board/#product-by-priority","title":"Product -- by Priority","text":"This program planning view is designed to let you see all of the backlog items that have been scheduled for all of the products in the current program, organized by requirement importance/priority.
Each of the possible importance values is displayed on the left-hand side and the backlog items displayed in the same row on the right. The backlog items in this view will only be requirements (with associated tasks and test cases).
The top section will contain the list of items that are not assigned a priority, with the other sections containing the items that have been assigned to the specific priority.
"},{"location":"Spira-User-Manual/Program-Planning-Board/#product-by-status","title":"Product -- by Status","text":"This view is designed to let you see the product backlog organized by requirement status. Each of the possible status values (for a planned item) is displayed as a heading, with the backlog items displayed in the same column underneath. The backlog items in this view will only be requirements (with associated tasks and test cases). This view is commonly called a Kanban board:
Each of the vertical sections is one of the requirements' statuses, in order of the requirement lifecycle (Planned > Completed). You can click on the expand/collapse icons to hide any statuses that are not used. You can drag and drop the requirements between the different statuses. If you have the planning options enabled to have requirements status' automatically update based on changes to the associated tasks and test cases, then items will automatically move between the statuses based on tasks being completed and test cases being executed.
"},{"location":"Spira-User-Manual/Program-Planning-Board/#product-by-person","title":"Product -- by Person","text":"This view is designed to let you see the product backlog organized by resource / person. Each of the users that is a member of the current product is displayed as a heading, with the backlog items displayed in the same column underneath.
You can click on the expand/collapse icons to hide any resources that are not relevant. Above the resource headings there is a section with the product name; that contains backlog items that are scheduled for the current product but have not yet been assigned to a person.
"},{"location":"Spira-User-Manual/Program-Products/","title":"Program Products","text":"This page outlines how to access and use the program product pages. These pages are only available in SpiraPlan.
From the program product pages you can view information about each product in the program.
"},{"location":"Spira-User-Manual/Program-Products/#product-list","title":"Product List","text":"To access the program product list page, you must be a member of the program (i.e. a program owner or executive). From the program, open the \"artifact\" dropdown as shown below and click \"Products\"
.
The program product list shows all of the products in the current program, displayed in an integrated table view showing products':
The toolbar above the grid lets you:
You can sort the list by most columns (any with the ascending and descending arrows).
You can filter by entering (or selecting) a value in each required column to filter on. Read about how to create and manage filters (note that this page does not let you save and share named filters).
Clicking on a product name / link will open the program product details page.
"},{"location":"Spira-User-Manual/Program-Products/#product-details","title":"Product Details","text":"This page is made up of three areas:
The navigation pane has a link to take you back to the product list, as well as a list of products in the program. This list is useful as a navigation shortcut - click on any product to quickly view its details. The navigation list can be switched between two different modes:
The top part of the right pane has buttons to refresh the product information or save any changes made. The product logo beneath this (to the left of the product ID) can be clicked to open the product home page for that product.
If you have the required permissions for that product (see below) you can edit some of its fields. Many of the fields are always read only and can only be edited by system administrators from the System Admin Product Edit page. The fields that are editable on this page are:
Once you are satisfied with any changes you have made, click the \"Save\" button. To quickly discard any changes, click \"Refresh\".
"},{"location":"Spira-User-Manual/Program-Products/#editing-the-product-details","title":"Editing the product details","text":"To edit the product information for a particular product from the product details page you must meet at least one of the following conditions:
The program release plan is only available in SpiraPlan. If you are using SpiraPlan, to access the program release plan, you must be a member of the program (i.e. a program owner or executive).
The program release plan lets you see all of the products in the current program, together with their releases, sprints, and phases displayed in an integrated hierarchical view:
You can access this feature by clicking on the Releases menu entry in the program navigation.
This view lets you see all the releases, sprints, and phases with the following information (each column can be shown or hidden as needed):
You can expand and collapse the products and releases to display the appropriate level of detail as well as filter by the various fields in the grid.
"},{"location":"Spira-User-Manual/Program-Releases/#release-traceability-and-coverage","title":"Release Traceability and Coverage","text":"From the release list page you can see a number of columns that show calculated data for each release, based off:
This allows you to see at a glance the state of play about a number of key metrics for the release.
"},{"location":"Spira-User-Manual/Program-Releases/#requirements-completion","title":"Requirements Completion","text":"This column shows a mini chart that shows the percentage completion of all relevant requirements assigned to the release (or that are rolling up from the releases children).
The percentaged complete is worked out by dividing the number of \"completed requirements\" (described below) by the total number of requirements assigned to the release. A \"completed requirement\" is a requirement with a status of either \"Tested\", \"Completed\", or \"Released\".
"},{"location":"Spira-User-Manual/Program-Releases/#requirement-count-and-points","title":"Requirement Count and Points","text":"These columns (not shown by default) show you the sum of all requirements assigned to the release; and the sum of all the points scored to all those requirements respectively.
"},{"location":"Spira-User-Manual/Program-Releases/#test-coverage","title":"Test coverage","text":"This column shows a mini chart that shows the sum of each execution statuses against the release. It is calculated from the latest test run executed against that release for each test case that is assigned to that release. If you execute a test case against a release, and that test case is not by itself assigned to the release, the information for that test run will not be included.
If you hover the mouse over the mini chart it will display a tooltip that provides a more detailed description of the number of tests in each execution status.
Each release will display the aggregate status of any test cases directly assigned to itself, together with the test execution status of any child sprints that are contained within the release.
"},{"location":"Spira-User-Manual/Program-Releases/#task-progress","title":"Task Progress","text":"This columns shows a mini chart of the count of all active tasks1 assigned to the release, by progress category for the release. The 'On Schedule', 'Late Finish', 'Late Start' and 'Not Started' bars indicate the total count of tasks that are in that category.
If you hover the mouse over the mini chart it will display a tooltip that provides a more detailed description of the number of tasks in each category.
How are the different categories calculated?
any task with a status that is not one of the following: \"Rejected\", \"Obsolete\", \"Duplicate\".\u00a0\u21a9
Often, developers work on features or hotfixes in specific branches. Once development is complete, the code is ready to merged into the central branch (typically main, or development) ahead of release. Pull requests are a way to flag that the feature branch is ready for merging. A pull request lets the developer(s) of the feature ask colleagues to review the code, assess if changes are needed, and if everything looks good approve the pull request / merge into the main branch.
If your SpiraPlan product is connected to a source code repository, you will be able to use SpiraPlan's pull request functionality. This lets you create a pull request, select the branch you want reviewed, the branch the code will be pulled / merged into, and assign a team member to review the request. The reviewer can explore the code that was changed in the branch add comments or notes to the pull request, and move it through a workflow as needed. The requester can track any changes made to the pull request, so they can, as needed, make additional changes to their code.
SpiraPlan's pull request feature leverages the Task artifact. Tasks have different types. You can set any of these tasks types to be treated as a pull request task. Task types are managed via template administration. By default, templates have a task type called \"Pull Request\" which is flagged as being treated as a pull request. You can turn this off, or make other types also be treated as pull requests. If you have different workflows for different types of code (for instance a hotfix pull request may require a different workflow to a feature pull requests), it may make sense to have multiple task types being flagged as pull requests. You can then set each task type to use a different task workflow.
"},{"location":"Spira-User-Manual/Pull-Requests/#pull-request-list","title":"Pull Request List","text":"To view the list of pull requests in a product, the following three conditions need to be met:
Note: to carry out operations on pull requests (like create, delete, modify) you need those specific permissions for tasks.
"},{"location":"Spira-User-Manual/Pull-Requests/#view-pull-requests","title":"View Pull Requests","text":"When you click on Developing > Pull Requests on the global navigation bar, you will be taken to the pull requests list screen. This shows you all pull requests in the product. You can sort and filter this list, or browse the different pages of pull requests (up to 500 pull requests can be displayed on the page at any one time).
Above the list of pull requests is the action toolbar. This lets you perform the following functions:
The list of pull requests shows the following information about each pull request:
When you click the \"New Pull Request\" button you will see a popup dialog as below.
This dialog has the following fields to fill in:
Once the popup has been filled in click \"Create\" to add the pull request.
"},{"location":"Spira-User-Manual/Pull-Requests/#pull-requests-on-the-task-list","title":"Pull Requests on the Task List","text":"Pull requests are a special type of task. Only tasks with a pull request type are shown on the pull request list page. On the main task list page you can see all tasks, including pull requests. Pull requests have the special pull request icon next to the name. You can filter and order tasks and this will affect pull requests as if they are normal tasks. On the main task list page you cannot show special pull requests fields (like Merge From and Merge To). You can also view pull requests on the task board.
If you can create a new task from the task list you can create a pull request. However, you will not be able to set the Merge From or Merge To fields. That can only be done on the pull requests list page.
"},{"location":"Spira-User-Manual/Pull-Requests/#pull-request-details","title":"Pull Request Details","text":"Clicking on a pull request from anywhere in the application will open its details page. Here you can see and edit all information about the pull request, transition it through the workflow, add comments and more. This functionality is described in more detail on the task details page.
The pull request details page is different to the task details page in two specific ways:
From the pull request's commits tab, you can see a list of all commits that were made on the Merge From branch that are not in the Merge To branch. This lets you easily see all the changes that the pull request is asking to bring into the Merge To branch.
For each commit you can see the following information (you can sort or filter on all of these):
This section outlines how to use the Release Management features of SpiraPlan\u00ae to manage different versions of the system being tested in a particular product. This is an optional feature of the system, and you can manage the testing for a product successfully without tracking individual releases. Typically, when you develop a system, it is important to ensure that features introduced in successive versions do not impair existing functionality - this is known as regression testing.
In such situations, you will want to be able to execute the same set of test scripts against multiple versions of the system and be able to track failures by version. A feature that works correctly in version 1.0 may fail in version 1.1, and the maintenance team may be testing the existing lifecycle of v1.0 in parallel with the development team testing v1.1. Therefore, by developing a master set of releases/versions in the Release Management module, you can have the different testing teams correctly assign their testing actions to the appropriate version.
There are two types of release artifact in SpiraPlan\u00ae - product releases that are displayed with the release icon and represent major or minor versions of the system, and release Sprints that are displayed with the sprint icon. Note: Sprints can be contained within a Release, but not the other way round.
The main differences between releases and sprints are as follows:
From the release list page you can see a number of columns that show calculated data for each release, based off:
This allows you to see at a glance the state of play about a number of key metrics for the release.
"},{"location":"Spira-User-Manual/Release-Management/#requirements-completion","title":"Requirements Completion","text":"This column shows a mini chart that shows the percentage completion of all relevant requirements assigned to the release (or that are rolling up from the releases children).
The percentaged complete is worked out by dividing the number of \"completed requirements\" (described below) by the total number of requirements assigned to the release. A \"completed requirement\" is a requirement with a status of either \"Tested\", \"Completed\", or \"Released\".
"},{"location":"Spira-User-Manual/Release-Management/#requirement-count-and-points","title":"Requirement Count and Points","text":"These columns (not shown by default) show you the sum of all requirements assigned to the release; and the sum of all the points scored to all those requirements respectively.
"},{"location":"Spira-User-Manual/Release-Management/#test-coverage","title":"Test coverage","text":"This column shows a mini chart that shows the sum of each execution statuses against the release. It is calculated from the latest test run executed against that release for each test case that is assigned to that release. If you execute a test case against a release, and that test case is not by itself assigned to the release, the information for that test run will not be included.
If you hover the mouse over the mini chart it will display a tooltip that provides a more detailed description of the number of tests in each execution status.
Each release shows the overall execution status of test cases assigned to that release for that release. For each test case the execution status shown is the most recent result from when that test case was run against that particular release (if at all). Note: a major release will also show the results from test cases assigned to it directly that are also assigned to and run against its child sprints.
"},{"location":"Spira-User-Manual/Release-Management/#task-progress","title":"Task Progress","text":"This columns shows a mini chart of the count of all active tasks1 assigned to the release, by progress category for the release. The 'On Schedule', 'Late Finish', 'Late Start' and 'Not Started' bars indicate the total count of tasks that are in that category.
If you hover the mouse over the mini chart it will display a tooltip that provides a more detailed description of the number of tasks in each category.
How are the different categories calculated?
Rollup of effort from requirements associated to the release are summed together in the relevant release effort fields. Other artifacts's effort values can also be included in these calculations, controlled on the Planning Options page of product administration.
Task effort calculations are described in more detail here.
"},{"location":"Spira-User-Manual/Release-Management/#baselining","title":"Baselining","text":"NOTE: Baselining is only available in SpiraTeam and SpiraPlan.
What is baselining in SpiraPlan
Baselining allows you to take a snapshot of the entire product at a specific point in time. You can use this feature to see the state of every test case, requirement, and incident as they were the moment that baseline was created. You can see how an artifact changed between 2 baselines (or between the baseline and when the product was first created if you are looking at the earliest baseline).
In SpiraPlan, we attach baselines to a release, as well as to the state of the product changes. This is to help you more easily use baselines as part of your release planning and review: baselines are, in effect, tied to the progress of your releases and sprints. You may wish to create a baseline when your release starts, and then create another when it is released. You may create a baseline at the end of every sprint and then use your baselines to see what happened between those two sprints.
Once a product has baselines, product owners can explore each baseline to see what artifacts were added, changed, or deleted in a baseline.
Here is a step by step overview on getting started with baselines:
Below is more information below about how to create, edit, delete, and view your baselines against a specific release.
Product admins / product owners can use the dedicated admin list page to see all baselines across all releases in a product. They can also explore a baseline in detail, to see all the artifacts changed, added, or deleted in a baseline.
What is captured when baselining is turned on? Baselining leverages the change tracking tools built into SpiraPlan already. It does this by using the history stored against each artifact in the product to track what has changed between any two baselines. Some additional information is captured only when baselining is turned on (both for baselining use and general history tracking):
When you click on the Planning > Releases global navigation link, you will initially be taken to the release list screen illustrated below:
The release list will contain all the releases and sprints associated with current product. When you create a new product, this list will initially be empty, and you will have to use the \"Insert\" button to start adding releases and sprints to the product. The hierarchical organization of releases in the list is configurable, so you can organize the various releases in the way that makes most sense for a particular product. Typically you have the major releases as the top-level items, with sub-releases, builds and sprints as the lower-level items.
All of the releases in the list have a release-name, together with the assigned version number for that release, the start-date and end-date for the release, the number of estimated product personnel working on that release, the planned effort for the release, the total effort currently scheduled (as tasks), the available effort for new tasking, the release id, the type of each release, its status, and a set of custom properties defined by the product owner.
For those releases that have test cases mapped against them, the execution status of the various test cases associated with the release is displayed in aggregate for each item as a graphical bar diagram. If you position the mouse over the execution status indicator you will see the detailed execution information displayed as a tooltip.
For those releases that have at least one requirement task associated with them, they will display a block graph that illustrates the relative numbers of task that are on-schedule (green), late-starting (yellow), late-finishing (red) or just not-started (grey). These values are weighted by the effort of the task, so that larger, more complex tasks will be change the graph more than the smaller tasks. To determine the exact task progress information, position the mouse pointer over the bar-chart and the number of associated tasks, along with the details of how many are in each status will be displayed as a \"tooltip\".
Clicking on a release's hyperlink will take you to the release details page for the item in question.
"},{"location":"Spira-User-Manual/Release-Management/#filtering","title":"Filtering","text":"Read about how to create and manage filters.
"},{"location":"Spira-User-Manual/Release-Management/#insert","title":"Insert","text":"The \"Insert\" button has an attached dropdown menu that lets you:
If you insert a release or sprint (not as a child) the new item is inserted above the currently selected item -- i.e. at the same level in the hierarchy but visually above the release with the checked checkbox. If you insert an item with no release selected, the item is inserted at the bottom of the list (at the same level in the hierarchy as the item release or sprint that was previously at the bottom).
If you insert a child release or sprint, the new item is inserted below the currently selected item - i.e. nested insde the selected release as a child (a sprint cannot have child sprints or releases).
Once the new release has been inserted, the item is switched to \"Edit\" mode so you can change its name, version number or other information.
"},{"location":"Spira-User-Manual/Release-Management/#delete","title":"Delete","text":"Clicking on the \"Delete\" button deletes all the releases whose check-boxes have been selected. If any of the releases have child releases/sprint, then the child releases and sprints are also deleted.
"},{"location":"Spira-User-Manual/Release-Management/#indent","title":"Indent","text":"Clicking on the \"Indent\" button indents all the releases whose check-boxes have been selected. Note: you cannot indent a release or sprint if it is below a sprint, as sprints are not allowed to have child items.
"},{"location":"Spira-User-Manual/Release-Management/#outdent","title":"Outdent","text":"Clicking on the \"Outdent\" button de-indents all the releases whose check-boxes have been selected.
"},{"location":"Spira-User-Manual/Release-Management/#refresh","title":"Refresh","text":"Clicking on the \"Refresh\" button simply reloads the release list. This is useful as other people may be modifying the list of releases at the same time as you, and after stepping away from the computer for a short-time, you should click this button to make sure you are viewing the most current release list for the product.
"},{"location":"Spira-User-Manual/Release-Management/#edit","title":"Edit","text":"Each release/sprint in the list has an \"Edit\" button display in its right-most column. When you click this button or click on any of the cells in the row, you change the item from \"View\" mode to \"Edit\" mode. The various columns are made editable, and \"Save\" buttons are displayed in the last column:
If you click \"Edit\" on more than one row, the \"Save\" buttons are only displayed on the first row, and you can make changes to all the editable rows and then update the changes by clicking the one \"Save\" button. Also, if you want to make the same change to multiple rows (e.g. to change five releases from \"active\" to \"inactive\"), you can click on the \"fill\" icon to the right of the editable item, which will propagate the new value to all editable items in the same column.
If you want to edit lots of items, first select their checkboxes and then click the \"Edit\" button on the same row as the Filters and it will switch all the selected items into edit mode.
When you have made your updates, you can either click \"Save\" to commit the changes, or \"Cancel\" to revert back to the original information. Alternatively, pressing the <ENTER> key will commit the changes and pressing the <ESCAPE> key will cancel the changes.
"},{"location":"Spira-User-Manual/Release-Management/#show-level","title":"Show Level","text":"Choosing an indent level from the 'Show Level' drop down box allows you to quickly and easily view the entire release list at a specific indent level. For example you may want to see all releases drilled-down to the third level of detail. To do this you would simply choose 'Level 3' from the list, and the releases will be expanded / collapsed accordingly.
"},{"location":"Spira-User-Manual/Release-Management/#show-hide-columns","title":"Show / Hide Columns","text":"This drop-down list allows you to change the fields that are displayed in the release list as columns for the current product. To show a column that is not already displayed, simply select that column from the list of \"Show...\" column names and to hide an existing column, simply select that column from the list of \"Hide...\" column names. This is stored on a per-product basis, so you can have different display settings for each product that you are a member of. The fields can be any of the built-in fields or any of the custom properties set up by the product owner.
"},{"location":"Spira-User-Manual/Release-Management/#copying-releasessprints","title":"Copying Releases/Sprints","text":"To copy a release/sprint or set of releases/sprints, simply select the check-boxes of the release/sprint you want to copy and then select the Edit > Copy Items menu option. This will copy the current release/sprint selection to the clipboard. Then you should select the place where you want the releases/sprints to be inserted and choose the Edit > Paste Items option.
The releases/sprints will now be copied into the destination location you specified. The name of the copied releases/sprints will be prefixed with \"Copy of...\" to distinguish them from the originals. Note that copied releases/sprints will also include the test mapping information from the originals.
Copying parent and child releases together
If you want to copy a parent release and its children only select the parent release. You do not need to also select each of its child releases.
"},{"location":"Spira-User-Manual/Release-Management/#cloning-releasessprints","title":"Cloning Releases/Sprints","text":"To clone a release/sprint or set of releases/sprints, open particular release and select \"Clone\" from the New menu option. Please note that if you're cloning from the child release details page then only child release will be cloned. If you're cloning the parent release then all the children releases is getting cloned as well.
When cloning (or copying) a release note that:
To move a release/sprint in the hierarchy, there are two options:
Click on the release/sprint you want to move and drag the icon to the location you want it moved. An empty space will appear to show you where it will be inserted. Once you have the requirement positioned at the correct place that you want it inserted, just release the mouse button. To move multiple items simply select their checkboxes and then drag-and-drop one of the selected items
Alternatively you can simply select the check-boxes of the release/sprint you want to move and then select the Edit > Cut Items menu option. This will cut the current release/sprint selection to the clipboard. Then you should select the place where you want the release/sprint to be inserted and choose the Edit > Paste Items option. The release/sprint will now be moved into the destination location you specified.
Read about how to export artifacts from one product to another.
"},{"location":"Spira-User-Manual/Release-Management/#creating-test-sets-from-releases","title":"Creating Test Sets from Releases","text":"As a shortcut you can click the Tools > Create Test Set option to create a new test set for each of selected releases. The created test sets will include all of the test cases associated with a release. This is useful in regression testing when you have created a new release and want to be able to quickly assign a tester to ensure that all the functionality in the release works as expected.
"},{"location":"Spira-User-Manual/Release-Management/#printing-or-saving-items","title":"Printing or Saving Items","text":"To quickly print a single release/sprint or list of releases/sprints you can select the items' checkboxes and then click Tools > Print Items. This will display a popup window containing a printable version of the selected items. You can also save the report in a variety of common formats from the same Tools menu.
"},{"location":"Spira-User-Manual/Release-Management/#right-click-context-menu","title":"Right-Click Context Menu","text":"SpiraPlan\u00ae provides a shortcut -- called the context menu - for accessing some of the most commonly used functions, so that you don't need to move your mouse up to the toolbar each time. To access the context menu, right-click on any of the rows in the release list and the following menu will be displayed:
You can now choose any of these options as an alternative to using the icons in the toolbar
"},{"location":"Spira-User-Manual/Release-Management/#releases-additional-list-views","title":"Releases Additional List Views","text":"In SpiraTeam and SpiraPlan, there are two additional release list views. These views are:
You can pick between each of these views using the view selection button group at the top right of any requirement list page.
"},{"location":"Spira-User-Manual/Release-Management/#release-gantt-chart","title":"Release Gantt Chart","text":"This displays all active releases and sprints2 nested in the same hierarchy as on the main release list page. Any release that has active children has an expand / collapse toggle to the left of its name. To the right of the release names is the timeline bar, which graphically shows the length of each release between their start and end dates in individual horizontal bars.
Part of a release may be shaded darker than normal, from its left (see Library System Release 1.1 below). This represents the requirements completion percentage for that release. So if a release bar stretches for 3 months and 33% of its requirements are complete, the first month of the bar will be shaded darker.
The names of the releases on the left or in the horizontal bar are clickable and will open the specific release.
Above the Gantt chart is a toolbar that lets you:
Add button to add a new release (or open the dropdown to add a new sprint or phase). Once you click Add you will have a popup to fill in information about the new release and then click Add Release. Adding the release inserts it at the bottom of the release hierarchy at the same indent level as the previous last release in the hierarchy.To view more information about a release, click its name from the left hand sidebar or in the relevant Gantt bar. This will open popup with much more detail. If you ctrl/cmd+click on the release name it will open the full details page for that artifact. Information shown in the popup includes all standard and custom fields. These fields are visible or hidden based on the workflow step that applies to that specific release.
You can edit releases straight from the Gantt chart. Users with bulk edit permissions can edit a release (including adding a new comment) at any time by clicking on the release name. This opens a popup with full information about that release. At all times, which fields are shown, required, or hidden is based on the workflow step that applies to that specific release. To save any changes you must fill in all required fields. Please note: you cannot change the status in this edit mode, to do so open the artifact's detail page (you can do this from the popup by clicking the button next to the artifact's id at the top).
Note: only fields that users are able to edit are shown - fields that are always read only (like the creation date) are not shown in this view.
"},{"location":"Spira-User-Manual/Release-Management/#releases-mind-map","title":"Releases Mind Map","text":"The releases Mind Map / Pert chart displays the first 5,000 releases in the release hierarchy of the product as a connected tree view / mindmap. The root node shows the name of the product at the top. The top most level nodes are connected underneath this, with their successive children shown from top to bottom.
For each release the map displays the name and ID of the release, with a tooltip that additionally shows the release's version number. Each node is color coded by the release type: product is the darkest; major and minor releases are less dark; sprints and phases are the lightest.
Clicking on the node will take you to the details page for that release.
There are several other display options:
To view more information about a release, click its name. This will open popup with much more detail. If you ctrl/cmd+click on the release name it will open the full details page for that artifact. Information shown in the popup includes all standard and custom fields. These fields are visible or hidden based on the workflow step that applies to that specific release.
You can edit releases straight from the mindmap. Users with bulk edit permissions can edit a release (including adding a new comment) at any time by clicking on the release name. This opens a popup with full information about that release. At all times, which fields are shown, required, or hidden is based on the workflow step that applies to that specific release. To save any changes you must fill in all required fields. Please note: you cannot change the status in this edit mode, to do so open the artifact's detail page (you can do this from the popup by clicking the button next to the artifact's id at the top).
Note: only fields that users are able to edit are shown - fields that are always read only (like the creation date) are not shown in this view.
"},{"location":"Spira-User-Manual/Release-Management/#release-details","title":"Release Details","text":"When you click on release item in the release list, you are taken to the release details page illustrated below:
This page is made up of three areas;
Please note that on smaller screen sizes the navigation pane is not displayed. While the navigation pane has a link to take you back to the releases list, on mobile devices a 'back' button is shown on the left of the operations toolbar.
The navigation pane can be collapsed by clicking on the \"-\" button, or expanded by clicking anywhere on the gray title area. On desktops the user can also control the exact width of the navigation pane by dragging and dropping a red handle that appears on hovering at the rightmost edge of the navigation pane.
The navigation pane consists of a link that will take you back to the release list, as well as a list of the other releases in the current product. This latter list is useful as a navigation shortcut; you can quickly view the test run information of all the other releases by clicking on the navigation links without having to first return to the release list page. The navigation list can be switched between two different modes:
The top part of the right pane allows you to view and/or edit the details of the particular release. In addition you can delete the current artifact by choosing \"Delete\", discard any changes made by clicking \"Refresh\", or print or export it by clicking one of the options from the Tools dropdown menu.
The lower part of the right pane can be in one of seven possible modes that can be selected: \"Overview\", \"Incidents\", \"Reqs & Tasks\", \"Test Cases\", \"Test Runs\", \"Attachments\", and \"History\". Each of the different views is described separately below.
"},{"location":"Spira-User-Manual/Release-Management/#emailing","title":"Emailing","text":"Read about emailing an artifact to colleagues using Spira.
"},{"location":"Spira-User-Manual/Release-Management/#followers","title":"Followers","text":"Read about how to add and manage followers to an artifact.
"},{"location":"Spira-User-Manual/Release-Management/#workflows-and-statuses","title":"Workflows and Statuses","text":"Releases can have the following statuses: planned, in progress, completed, closed, deferred, and cancelled. Note that releases marked as closed, deferred, or cancelled cannot be associated with other artifacts -- for example an incident's planned release cannot be a cancelled release.
Read about using workflows to change the status of your artifact.
"},{"location":"Spira-User-Manual/Release-Management/#overview-details","title":"Overview -- Details","text":"The Overview tab is divided into a number of different sections. Each of these can be collapsed or expanded by clicking on the title of that section. It displays the description, fields and comments associated with the requirement.
The top part of this tab displays the various standard fields and custom properties associated with the requirement. Fields (both standard and custom) are grouped under the collapsible headings (marked by orange text and underline) in the screenshot below. For instance, all fields regarding dates are grouped together in the \"Dates and Times\" area.
When you make changes to the release/sprint's start-date, end-date, number of product personnel resources, or number of non-working person days, the system will automatically calculate how many hours of effort (planned effort) are available in the release/sprint for assigning tasks. As you begin assigning tasks -- either through the Tasks tab or the Sprint Planning screen -- the total estimated effort of the tasks is subtracted from this planned effort to give the \"available effort\".
"},{"location":"Spira-User-Manual/Release-Management/#overview-detailed-information","title":"Overview -- Detailed Information","text":"The Detailed Information section contains the long, formatted description of the requirement, as well as any rich text custom fields. You can enter rich text or paste in from a word processing program or web page into these fields. Clicking on the shaded areas of one of these detailed fields will display the rich text toolbar.
"},{"location":"Spira-User-Manual/Release-Management/#overview-comments","title":"Overview - Comments","text":"Read about how the comments works
"},{"location":"Spira-User-Manual/Release-Management/#overview-builds","title":"Overview - Builds","text":"This section displays the list of builds associated with the current release/sprint. Each build is listed together with its name, creation date, status (whether the build succeeded or failed), and last updated date. Clicking on the hyperlink for the build name will open up the Build Details page.
You can also filter the results by choosing items from the filter options displayed in the sub-header row of each field and clicking the \"Apply Filter\" button. In addition, you can quickly sort the list by clicking on one of the directional arrow icons displayed in the header row of the appropriate field.
"},{"location":"Spira-User-Manual/Release-Management/#incidents","title":"Incidents","text":"This tab displays the incidents associated with the selected release. The incident list can be one of three modes:
Detected in this Release -- this will display a list of all the incidents that were detected during the testing of the selected release. This is useful in determining if there are open incidents associated with a release that need to be dealt with.
Resolved in this Release -- This will display a list of all the incidents that have been reportedly resolved in this release. This is useful for double-checking that all the resolved incidents for a release have indeed been fixed.
Verified in this Release -- This will display a list of the incidents that have been verified as being fixed in this release. This is useful for generating release notes for a specific release indicating what changes and enhancements have been made in the release.
Regardless of the mode, each incident is listed together with the type, status, priority, name, owner, detector, detection date and a link to the actual incident details:
To change between the three modes outlined above, select the desired mode from the drop-down list contained within the header of the incident list table.
You can perform the following actions:
Refresh -- updates the list of incidents from the server, useful if other people are adding incidents to this release at the same time.
You can filter the results by choosing items from the filter options displayed in the sub-header row of each field and clicking the \"Filter\" button. In addition, you can quickly sort the list by clicking on one of the directional arrow icons displayed in the header row of the appropriate field.
Edit -- Clicking the \"Edit\" button to the right of the incident allows you to edit the incident inline directly on this screen. This functionality is limited to product owners.
Show/Hide Columns -- Allows you to choose which incident columns are visible
"},{"location":"Spira-User-Manual/Release-Management/#reqs-tasks","title":"Reqs & Tasks","text":"This tab displays the list of requirements (excluding parent requirements - in other words it displays 'user stories') and their associated child tasks that need to be completed for the release/sprint to be completed:
Each of the requirements and associated tasks is displayed together with its:
Clicking on a requirement will bring up the requirement details page. Clicking the triangle by a requirement will expand/collapse its list of tasks. Clicking on a task name will bring up the Task Details page which is described in more detail in Task Tracking > Task Details. This allows you to edit the details of an existing task.
You can perform the following actions on a task from this screen:
This tab shows the test coverage information for the release in question:
The tab displays a grid containing the test cases already mapped to this release. You can filter that list by the test case type, name, status, execution status, execution date, priority, product name and ID. You can remove an existing test case by selecting its check box and clicking the 'Delete' button. This doesn't delete the test case, just removes it from the release.
Hovering the mouse over the names of the test cases will display a \"tooltip\" consisting of the test case name, place in the folder structure and a detailed description.
To add a new test case to the release, simply click on the 'Add' button:
You can search for a test case by its ID if you know it (make sure to include the \"TC\" prefix):
Otherwise, you can search for the test cases by choosing a folder from the dropdown and/or entering a partial name match:
One you have found the desired test case(s), simply select their check boxes and click the 'Save' button to add them to the current release.
Finally, as a shortcut you can click the \"Create Test Set from This Release\" link to create a new test set from this release, that will include all of the test cases associated with this release. This is useful in regression testing when you have created a new release and want to be able to quickly assign a tester to ensure that all the functionality in the release works as expected.
"},{"location":"Spira-User-Manual/Release-Management/#test-runs","title":"Test Runs","text":"This view displays the list of all the test runs executed against the release. Each test run is listed together with the date of execution, the name of the test case, the name of the tester, the release/version of the system that the test was executed against, the name of the test set (if applicable), the overall execution status for the test case in that run and a link to the actual test run details. In addition, you can choose to display any of the custom properties associated with the test run.
The \"Show/hide columns\" drop-down list allows you to change the fields that are displayed in the test run list as columns. To show a column that is not already displayed, simply select that column from the list of \"Show...\" column names and to hide an existing column, simply select that column from the list of \"Hide...\" column names. The displayed columns can be any standard field or custom property.
You can also filter the results by choosing items from the filter options displayed in the sub-header row of each field and clicking the \"Filter\" link. In addition, you can quickly sort the list by clicking on one of the directional arrow icons displayed in the header row of the appropriate field.
"},{"location":"Spira-User-Manual/Release-Management/#attachments","title":"Attachments","text":"Read about how the attachments tab works
"},{"location":"Spira-User-Manual/Release-Management/#baselines","title":"Baselines","text":"NOTE: Baselining is only available in SpiraTeam and SpiraPlan and this tab will be only then be visible if baselining has been turned on for a product.
This view displays the list of all baselines created for this release. If you have permissions for releases to create/modify/delete then you can perform the same actions for baselines.
You can view the following information about a baseline here:
To add a new baseline, click the New Baseline button. This will be disabled if you are not able to create releases. This will open up a small form. The name field is required, but the description field is optional. Enter the information and hit Add. NOTE: a baseline's description is plain text only.
You can edit an existing baseline as long as you can edit the specific release the baseline belongs to. If you see Edit buttons on the table of baselines that means you can edit. You can edit a baselines name, its description, and whether it is active or not.
If you can delete releases you can delete any baseline on any release. To do so click select the baselines to delete (put a checkmark next to it) and click the Delete button.
To filter and sort the list of baselines, use the filter and sort controls at the top of the table.
"},{"location":"Spira-User-Manual/Release-Management/#history","title":"History","text":"Read about how the history tab works
"},{"location":"Spira-User-Manual/Release-Management/#build-details","title":"Build Details","text":"When you click on a build entry in the build list, you are taken to the build details page illustrated below:
This page is made up of three areas:
The navigation panel has:
The top part of the right panel shows:
Beneath the header bar are a number of collapsible sections, each of which show specific information about the build or links between the build and other parts of the system. This sections are: \"Commits\", \"Associations\", \"Test Runs\", \"Incidents\", and \"Full Log\". These are described below.
the details of the build including a detailed description of why it succeeded or failed. Since builds are populated from an external Continuous Integration server the build information will always be read-only inside the SpiraPlan user interface.
"},{"location":"Spira-User-Manual/Release-Management/#commits","title":"Commits","text":"This section shows all source code commits included in the current build. The grid can be sorted and filtered by using the appropriate controls.
"},{"location":"Spira-User-Manual/Release-Management/#associations","title":"Associations","text":"This section shows a list of SpiraPlan artifacts associated with the build. This is automatically populated by all artifacts listed as tokens in the commit messages of the commits included in the build.
"},{"location":"Spira-User-Manual/Release-Management/#incidents_1","title":"Incidents","text":"This section shows the list of incidents that have been fixed in the current build. The grid can be sorted and filtered by using the appropriate controls. Note: if the build has no incidents the section will be hidden.
"},{"location":"Spira-User-Manual/Release-Management/#test-runs_1","title":"Test Runs","text":"This section displays a list of all the tests that have been executed against the current build. The grid can be sorted and filtered by using the appropriate controls. Note: if the build has no test runs the section will be hidden.
"},{"location":"Spira-User-Manual/Release-Management/#full-log","title":"Full Log","text":"This section displays the full console log readout that was returned from SpiraPlan by the build tool. This lets you view any detailed messages or errors. Note: this displays a maximum of two million characters (more than enough under normal circumstances) - longer logs are collapsed to show the first and last one million characters.
any task with a status that is not one of the following: \"Rejected\", \"Obsolete\", \"Duplicate\".\u00a0\u21a9
any release / sprint / phase with a status that is not \"Closed\", \"Deferred\", or \"Cancelled\".\u00a0\u21a9\u21a9
This section describes the reporting features of SpiraPlan\u00ae, including an overview of each of the report types that are available. When you click on the \"Reports\" tab on the global navigation bar, you will initially be taken to the reports home page illustrated below:
"},{"location":"Spira-User-Manual/Reports-Center/#overview","title":"Overview","text":"This page consists of four main areas:
The right-hand pane is a dashboard that contains the set of graph widgets configured by the current user. By default the dashboard will display: the Incident Progress Rate, Test Run Progress Rate, Requirement Summary, Test Case Summary, Incident Aging and Task Burndown. When \"All Releases\" is selected from the dropdown release picker, some widgets show information for every single release and sprint, and others only for active releases/sprints1:
In addition to the graphs displayed by default, you can click on the \"Add Items\" buttons to add additional graphs to the reporting dashboard:
Each of the graphs is described in more detail in Summary Graphs to Date-Range Graphs.
"},{"location":"Spira-User-Manual/Reports-Center/#reports-configuration","title":"Reports Configuration","text":"The configuration page for each report differs slightly, but the general format is illustrated below (please note all sections are shown in orange text with a line beneath and are shown here in the collapsed state -- click the orange text to expand the section):
You can configure the reports in the following ways:
"},{"location":"Spira-User-Manual/Reports-Center/#report-format","title":"Report Format","text":"This allows you to specify the display format of the report. Depending on the specific report, they can be:
This allows you to determine which types of information to include in the report. This varies by report type, but includes the dependent items related to the artifact being reported on (attachments, test steps, coverage, history, etc.)
"},{"location":"Spira-User-Manual/Reports-Center/#filters","title":"Filters","text":"Standard Field Filters -- This allows you to constrain the range of data being reported on, based on the various fields associated with the artifact in question. These filters are typically selections from multi-valued-dropdown lists and date-ranges.
Custom Property Filters -- This allows you to constrain the range of data being reported on, based on the custom fields associated with the artifact by your product administrator. These filters can be either freetext or drop-down lists.
Sort Options - This option is only available for the non-hierarchical data reports (i.e. for test cases, test sets, test runs, incidents and tasks) and allows you to specify the sort order of the results returned in the report. For the hierarchical-data based reports the sort order is always the order of the hierarchy.
"},{"location":"Spira-User-Manual/Reports-Center/#saving-and-sharing","title":"Saving and Sharing","text":"Report Name -- If you would like to save the report configuration so that you can quickly re-run it at a later date, you just need to enter a name for the report and indicate (by selecting the checkbox or not) whether you want this report to be private or shared by all members of the product.
To save the generated report into the documents repository for the product, check the checkbox. This will load two extra inputs:
Once you have selected the format, elements and filters, clicking the \"Create Report\" button launches the report in a new window. If you saved the generated report to documents, you can view that report in the folder you selected at any time, as with any other document.
Each of the reports is described below:
"},{"location":"Spira-User-Manual/Reports-Center/#requirement-reports","title":"Requirement Reports","text":""},{"location":"Spira-User-Manual/Reports-Center/#requirements-summary-report","title":"Requirements Summary Report","text":"This report displays all of the requirements defined for the current product in the order they appear in the requirements list. The requirement's details and coverage status are displayed in a summary list form:
"},{"location":"Spira-User-Manual/Reports-Center/#requirements-detailed-report","title":"Requirements Detailed Report","text":"This printable report displays all of the requirements defined for the current product in the order they appear in the requirements list. For each individual requirement, the name, priority, author, status and coverage status are displayed, along with tables containing the list of covering test cases, these test cases' test runs, linked incidents/requirements, associated tasks, attached documents, and the change history:
"},{"location":"Spira-User-Manual/Reports-Center/#requirements-plan","title":"Requirements Plan","text":"This report displays a complete work breakdown structure of the product from a requirements perspective, including all requirements and tasks organized by schedule:
"},{"location":"Spira-User-Manual/Reports-Center/#requirements-traceability-matrix","title":"Requirements Traceability Matrix","text":"This report displays a matrix of the requirements in the system with their list of covering test cases and associated, mapped requirements:
"},{"location":"Spira-User-Manual/Reports-Center/#test-case-reports","title":"Test Case Reports","text":""},{"location":"Spira-User-Manual/Reports-Center/#test-case-summary-report","title":"Test Case Summary Report","text":"This report displays all of the test cases defined for the current product in the order they appear in the test case list. The test case's details and execution status are displayed in a summary grid form with the test steps optionally displayed:
"},{"location":"Spira-User-Manual/Reports-Center/#test-case-detailed-report","title":"Test Case Detailed Report","text":"This report displays all of the test cases defined for the current product in the order they appear in the test case list. The test case's details and execution status are displayed, along with sub-tables containing the list of test steps, test runs, attached documents, the change history, and a list of any associated open incidents:
"},{"location":"Spira-User-Manual/Reports-Center/#test-set-summary-report","title":"Test Set Summary Report","text":"This report displays all of the test sets defined for the current product in the order they appear in the test set list. The test set's details and execution status are displayed in a summary list form:
"},{"location":"Spira-User-Manual/Reports-Center/#test-set-detailed-report","title":"Test Set Detailed Report","text":"This report displays all of the test sets defined for the current product in the order they appear in the test set list. The test set's details and execution status are displayed, along with sub-tables containing the list of test cases, test runs, attached documents, and the change history:
"},{"location":"Spira-User-Manual/Reports-Center/#printable-test-scripts","title":"Printable Test Scripts","text":"This printable report is useful when you want to be able to conduct the testing activities offline on paper, or when testers need paper copies of the test script in addition to using the online test execution wizard.
In either case, this report simply displays all of the test cases defined for the current product in the order they appear in the test case list together with their detailed test steps and a list of any attached documents.
"},{"location":"Spira-User-Manual/Reports-Center/#test-run-summary-report","title":"Test Run Summary Report","text":"This report displays all of the test runs defined for the current product. The test run's details and execution status are displayed in a summary grid form:
"},{"location":"Spira-User-Manual/Reports-Center/#test-run-detailed-report","title":"Test Run Detailed Report","text":"This report displays all of the test runs defined for the current product in date order (most recent first). The test run's details and execution status are displayed, along with sub-tables containing the list of test run steps, and a list of any associated open incidents:
"},{"location":"Spira-User-Manual/Reports-Center/#test-case-traceability","title":"Test Case Traceability","text":"This report displays a matrix of the test cases in the system with the list of mapped releases, incidents and test sets:
"},{"location":"Spira-User-Manual/Reports-Center/#incident-reports","title":"Incident Reports","text":""},{"location":"Spira-User-Manual/Reports-Center/#incident-summary-report","title":"Incident Summary Report","text":"This report displays all of the incidents tracked for the current product. Incident information is displayed in a summary list/table form:
"},{"location":"Spira-User-Manual/Reports-Center/#incident-detailed-report","title":"Incident Detailed Report","text":"This printable report displays all of the incidents tracked for the current product sorted by incident number. For each individual incident, the name, type, priority, status, opener, owner and close date are displayed, along with tables containing the detailed description and resolutions as well as a tabular list of attached documents, linked requirements/incidents and the change history:
"},{"location":"Spira-User-Manual/Reports-Center/#task-reports","title":"Task Reports","text":""},{"location":"Spira-User-Manual/Reports-Center/#task-summary-report","title":"Task Summary Report","text":"This report displays all of the tasks tracked for the current product. The task's details are displayed in a summary list form:
"},{"location":"Spira-User-Manual/Reports-Center/#task-detailed-report","title":"Task Detailed Report","text":"This report displays all of the tasks tracked for the current product. The task's details are displayed, along with a tabular list of attached documents and the change history:
"},{"location":"Spira-User-Manual/Reports-Center/#release-reports","title":"Release Reports","text":""},{"location":"Spira-User-Manual/Reports-Center/#release-summary-report","title":"Release Summary Report","text":"This report displays all of the releases and sprints defined for the current product in the order they appear in the release/sprint hierarchy. The release's details are displayed in a summary list form:
"},{"location":"Spira-User-Manual/Reports-Center/#release-detailed-report","title":"Release Detailed Report","text":"This report displays all of the releases and sprints defined for the current product in the order they appear in the release/sprint hierarchy. The release's details are displayed, along with sub-tables containing the list of requirements added, mapped test cases, test runs executed, incidents resolved, attached documents, scheduled tasks and the change history:
"},{"location":"Spira-User-Manual/Reports-Center/#release-plan-report","title":"Release Plan Report","text":"This report displays a complete work breakdown structure of the product from a release perspective, including all releases, sprints, requirements, tasks and incidents organized by schedule:
"},{"location":"Spira-User-Manual/Reports-Center/#summary-graphs","title":"Summary Graphs","text":""},{"location":"Spira-User-Manual/Reports-Center/#requirements-summary-graph","title":"Requirements Summary Graph","text":"The requirements summary graph shows how many requirements are currently in a product. The number of requirements is displayed according to the criteria that you specify. You can specify the type of data displayed along the x-axis, and the requirement information which is used to group the data. When you first open the graph you will be asked to pick the field that you would like to display on the x-axis and the field that you would like to group the data by. Once you have chosen the appropriate fields the graph will be displayed:
In this version of the report, the x-axis represents the requirements' status, and the individual bars are grouped by requirement importance. Each data-value can be viewed by positioning the mouse pointer over the bar, and a \"tooltip\" will pop-up listing the actual data value.
If a specific release is currently selected for the whole page, then Release is selected from one of the graph dropdowns, the graph shows only data for the specific release and its child sprints, if any.
Clicking on the \"Display Data Grid\" button will display the underlying data that is being used to generate the graph:
Clicking on the \"Download Data as CSV\" button will export the datagrid into Comma Separated Values (CSV) format that can be opened in MS-Excel. Some browsers also support the ability to save the graph as an image file (JPEG, PNG and GIF formats).
"},{"location":"Spira-User-Manual/Reports-Center/#test-case-summary-graph","title":"Test Case Summary Graph","text":"The test case summary graph shows how many test cases are currently in a product. The number of test cases is displayed according to the criteria that you specify. You can specify the type of data displayed along the x-axis, and the test case information which is used to group the data. When you first open the graph you will be asked to pick the field that you would like to display on the x-axis and the field that you would like to group the data by. Once you have chosen the appropriate fields the graph will be displayed:
In this version of the report, the x-axis represents the test case execution status, and the individual bars are grouped by test case priority. Each data-value can be viewed by positioning the mouse pointer over the bar, and a \"tooltip\" will pop-up listing the actual data value. Clicking on the \"Display Data Grid\" button will display the underlying data that is being used to generate the graph. In addition, clicking on the \"Download Data as CSV\" button will export the datagrid into Comma Separated Values (CSV) format that can be opened in MS-Excel. Some browsers also support the ability to save the graph as an image file (JPEG, PNG and GIF formats).
"},{"location":"Spira-User-Manual/Reports-Center/#test-run-summary-graph","title":"Test Run Summary Graph","text":"The test run summary graph shows how many test runs are currently in a product. The number of test runs is displayed according to the criteria that you specify. You can specify the type of data displayed along the x-axis, and the test run information which is used to group the data. When you first open the graph you will be asked to pick the field that you would like to display on the x-axis and the field that you would like to group the data by. Once you have chosen the appropriate fields the graph will be displayed:
In this version of the report, the x-axis represents the test run execution status, and the individual bars are grouped by test run type. If a specific release is currently selected for the whole page, then Release is selected from one of the graph dropdowns, the graph shows only data for the specific release and its child sprints, if any.
Each data-value can be viewed by positioning the mouse pointer over the bar, and a \"tooltip\" will pop-up listing the actual data value. Clicking on the \"Display Data Grid\" button will display the underlying data that is being used to generate the graph. In addition, clicking on the \"Download Data as CSV\" button will export the datagrid into Comma Separated Values (CSV) format that can be opened in MS-Excel. Some browsers also support the ability to save the graph as an image file (JPEG, PNG and GIF formats).
"},{"location":"Spira-User-Manual/Reports-Center/#incident-summary-graph","title":"Incident Summary Graph","text":"The incident summary graph shows how many incidents are currently in a product. The number of incidents is displayed according to the criteria that you specify. You can specify the type of data displayed along the x-axis, and the incident information which is used to group the data. When you first open the graph you will be asked to pick the field that you would like to display on the x-axis and the field that you would like to group the data by. Once you have chosen the appropriate fields the graph will be displayed:
In this version of the report, the x-axis represents the incidents' status, and the individual bars are grouped by the type of incident. For incidents, the whole-page release selection applies to the incident Detected Release field.
Each data-value can be viewed by positioning the mouse pointer over the bar, and a \"tooltip\" will pop-up listing the actual data value. Clicking on the \"Display Data Grid\" button will display the underlying data that is being used to generate the graph. In addition, clicking on the \"Download Data as CSV\" button will export the datagrid into Comma Separated Values (CSV) format that can be opened in MS-Excel. Some browsers also support the ability to save the graph as an image file (JPEG, PNG and GIF formats).
"},{"location":"Spira-User-Manual/Reports-Center/#task-summary-graph","title":"Task Summary Graph","text":"The task summary graph shows how many tasks are currently in a product. The number of tasks is displayed according to the criteria that you specify. You can specify the type of data displayed along the x-axis, and the task information which is used to group the data. When you first open the graph you will be asked to pick the field that you would like to display on the x-axis and the field that you would like to group the data by. Once you have chosen the appropriate fields the graph will be displayed:
In this version of the report, the x-axis represents the tasks' priority, and the individual bars are grouped by the status of task. If a specific release is currently selected for the whole page, then Release is selected from one of the graph dropdowns, the graph shows only data for the specific release and its child sprints, if any.
Each data-value can be viewed by positioning the mouse pointer over the bar, and a \"tooltip\" will pop-up listing the actual data value. Clicking on the \"Display Data Grid\" button will display the underlying data that is being used to generate the graph. In addition, clicking on the \"Download Data as CSV\" button will export the datagrid into Comma Separated Values (CSV) format that can be opened in MS-Excel. Some browsers also support the ability to save the graph as an image file (JPEG, PNG and GIF formats).
"},{"location":"Spira-User-Manual/Reports-Center/#test-set-summary-graph","title":"Test Set Summary Graph","text":"The test set summary graph shows how many test set are currently in a product. The number of test sets is displayed according to the criteria that you specify. You can specify the type of data displayed along the x-axis, and the test set information which is used to group the data. When you first open the graph you will be asked to pick the field that you would like to display on the x-axis and the field that you would like to group the data by. Once you have chosen the appropriate fields the graph will be displayed:
In this version of the report, the x-axis represents the test set status, and the individual bars are grouped by the name of the tester (owner). If a specific release is currently selected for the whole page, then Release is selected from one of the graph dropdowns, the graph shows only data for the specific release and its child sprints, if any.
Each data-value can be viewed by positioning the mouse pointer over the bar, and a \"tooltip\" will pop-up listing the actual data value. Clicking on the \"Display Data Grid\" button will display the underlying data that is being used to generate the graph. In addition, clicking on the \"Download Data as CSV\" button will export the datagrid into Comma Separated Values (CSV) format that can be opened in MS-Excel. Some browsers also support the ability to save the graph as an image file (JPEG, PNG and GIF formats).
"},{"location":"Spira-User-Manual/Reports-Center/#snapshot-graphs","title":"Snapshot Graphs","text":""},{"location":"Spira-User-Manual/Reports-Center/#requirements-coverage-graph","title":"Requirements Coverage Graph","text":"The requirements coverage graph shows how many requirements are currently in a product, according to their test coverage status.
The x-axis of the report represents the various test execution statuses that a requirement can have as its coverage status (plus the Not-Covered status), and the individual bars are grouped by the requirements importance. Each data-value can be viewed by positioning the mouse pointer over the bar, and a \"tooltip\" will pop-up listing the actual data value.
Clicking on the \"Display Data Grid\" button will display the underlying data that is being used to generate the graph. In addition, clicking on the \"Download Data as CSV\" button will export the datagrid into Comma Separated Values (CSV) format that can be opened in MS-Excel. Some browsers also support the ability to save the graph as an image file (JPEG, PNG and GIF formats).
"},{"location":"Spira-User-Manual/Reports-Center/#requirements-burndown-graph","title":"Requirements Burndown Graph","text":"The Requirements Burndown graph shows the remaining number of story points that needs to be completed for each release/sprint in the product with separate lines for the estimated and ideal burndown. In addition, the graph includes bars for the completed number of story points in each time period on the x-axis:
The y-axis of the graph displays the total remaining number of story points that needs to be done (the actual burndown), with a blue line indicating the ideal burndown. In addition, there are bars displayed at each interval of the x-axis that shows the completed number of story points for that interval.
The x-axis display will change based on the selection of the dropdown release picker:
Clicking on the \"Display Data Grid\" button will display the underlying data that is being used to generate the graph. In addition, clicking on the \"Download Data as CSV\" button will export the datagrid into Comma Separated Values (CSV) format that can be opened in MS-Excel. Some browsers also support the ability to save the graph as an image file (JPEG, PNG and GIF formats).
"},{"location":"Spira-User-Manual/Reports-Center/#requirements-burnup-graph","title":"Requirements Burnup Graph","text":"The Requirements Burnup graph shows the cumulative number of story points outstanding for each release/sprint in the product with separate lines for the estimated and ideal burnup. In addition, the graph includes bars for the number of completed story points in each time period on the x-axis.
The y-axis of the graph displays the cumulative increase in number of story points for the product (the actual burnup), with a blue line indicating the ideal burnup. In addition, there are bars displayed at each interval of the x-axis that shows the number of completed story points for that interval.
The x-axis display will change based on the selection of the dropdown release picker:
Clicking on the \"Display Data Grid\" button will display the underlying data that is being used to generate the graph. In addition, clicking on the \"Download Data as CSV\" button will export the datagrid into Comma Separated Values (CSV) format that can be opened in MS-Excel. Some browsers also support the ability to save the graph as an image file (JPEG, PNG and GIF formats).
"},{"location":"Spira-User-Manual/Reports-Center/#requirements-velocity-graph","title":"Requirements Velocity Graph","text":"The Requirements Velocity graph shows the total number of story points that have been completed (or planned to be completed) in a particular release, sprint or time-period (called the velocity). The actual velocity is displayed along with the overall average velocity (in blue) and the rolling average velocity (in green):
The y-axis display will change based on the selection of the dropdown release picker:
Clicking on the \"Display Data Grid\" button will display the underlying data that is being used to generate the graph. In addition, clicking on the \"Download Data as CSV\" button will export the datagrid into Comma Separated Values (CSV) format that can be opened in MS-Excel. Some browsers also support the ability to save the graph as an image file (JPEG, PNG and GIF formats).
"},{"location":"Spira-User-Manual/Reports-Center/#incident-aging-graph","title":"Incident Aging Graph","text":"The incident aging graph displays the number of days incidents have been left open in the system with the count of incidents on the y-axis and different age intervals on the x-axis. Each bar-chart color represents a different incident priority, giving a product manager a snapshot view of the age of open incidents by priority and detected release. For this chart, \"open\" is defined as any incident with an empty \"Closed On\" date. The incident status is not used for this chart.
This report can be filtered by the type of incident, so for example you can see the aging of just bugs, or just issues for the product in question. Clicking on the \"Display Data Grid\" button will display the underlying data that is being used to generate the graph. In addition, clicking on the \"Download Data as CSV\" button will export the datagrid into Comma Separated Values (CSV) format that can be opened in MS-Excel. Some browsers also support the ability to save the graph as an image file (JPEG, PNG and GIF formats).
"},{"location":"Spira-User-Manual/Reports-Center/#incident-turnaround-time-graph","title":"Incident Turnaround Time Graph","text":"The incident turnaround time graph displays the number of days incidents have taken to be closed (from the time they were first raised) in the system with the count of incidents on the y-axis and different turnaround time intervals on the x-axis. Each bar-chart color represents a different incident priority, giving a product manager a snapshot view of the turnaround time of incidents by priority and detected release. For this chart, \"closed\" is defined as any incident with a \"Closed On\" date. The incident status is not used for this chart.
This report can be filtered by the type of incident, so for example you can see the turnaround time of just bugs, or just issues for the product in question. Clicking on \"Display Data Grid\" button will display the underlying data that is being used to generate the graph. In addition, clicking on the \"Download Data as CSV\" button will export the datagrid into Comma Separated Values (CSV) format that can be opened in MS-Excel. Some browsers also support the ability to save the graph as an image file (JPEG, PNG and GIF formats).
"},{"location":"Spira-User-Manual/Reports-Center/#task-velocity-chart","title":"Task Velocity Chart","text":"The Task Velocity graph shows the total estimated and actual effort (in number of hours) delivered in each product release and/or sprint:
The y-axis of the graph displays the total estimated and actual effort delivered (in hours). The x-axis display will change based on the selection of the dropdown release picker:
Clicking on the \"Display Data Grid\" button will display the underlying data that is being used to generate the graph. In addition, clicking on the \"Download Data as CSV\" button will export the datagrid into Comma Separated Values (CSV) format that can be opened in MS-Excel. Some browsers also support the ability to save the graph as an image file (JPEG, PNG and GIF formats).
"},{"location":"Spira-User-Manual/Reports-Center/#task-burnup-chart","title":"Task Burnup Chart","text":"The Task Burnup graph shows the cumulative amount of work outstanding for each release/sprint in the product with separate lines for the estimated and ideal burnup. In addition, the graph includes bars for the remaining and completed effort in each time period on the x-axis.
The y-axis of the graph displays the cumulative increase in work (in hours) for the product (the actual burnup), with a blue line indicating the ideal burnup. In addition, there are bars displayed at each interval of the x-axis that shows the remaining effort and completed effort for that interval.
The x-axis display will change based on the selection of the dropdown release picker:
Clicking on the \"Display Data Grid\" button will display the underlying data that is being used to generate the graph. In addition, clicking on the \"Download Data as CSV\" button will export the datagrid into Comma Separated Values (CSV) format that can be opened in MS-Excel. Some browsers also support the ability to save the graph as an image file (JPEG, PNG and GIF formats).
"},{"location":"Spira-User-Manual/Reports-Center/#task-burndown-chart","title":"Task Burndown Chart","text":"The Task Burndown graph shows the effort (in hours) on the y-axis. The x-axis shows releases/sprints - the releases/sprints shown changes as you change the release selector at the top of the page. To be useful tasks in the product have to have their effort fields populated (specifically Estimated Effort and Remaining Effort).
The blue line on the graphs indicates the ideal burndown. The other line shows the estimated actual burndown. The graph also shows bars for the remaining and completed effort for each relevant release/sprint.
The x-axis display will change based on the selection of the dropdown release picker:
Clicking on the \"Display Data Grid\" button shows the underlying data used to generate the graph. Clicking the Download Data as CSV exports the data into Comma Separated Values (CSV) file. Some browsers support saving the graph as an image (JPEG, PNG and GIF formats).
The Test Run Progress Rate Graph shows how many tests have been executed for the selected release/sprint for a specific date range, and what execution status was recorded. The graph can be displayed for all test case types or for a specific type.
In this version of the report, the y-axis represents the number of test runs executed in each 24 hour period, and the x-axis represents a specific week in the time-span. Each data-bar can be viewed by positioning the mouse pointer over the point, and a \"tooltip\" will pop-up listing the actual data value. You can filter the report by the release/sprint that the test run was executed against, and also change the date range. If you choose a smaller date-range, the x-axis will switch from weekly to daily and if you choose a larger date-range, the x-axis will switch to monthly.
Clicking on the \"Display Data Grid\" button will display the underlying data that is being used to generate the graph. In addition, clicking on the \"Download Data as CSV\" button will export the datagrid into Comma Separated Values (CSV) format that can be opened in MS-Excel. Some browsers also support the ability to save the graph as an image file (JPEG, PNG and GIF formats).
"},{"location":"Spira-User-Manual/Reports-Center/#test-case-progress-rate-graph","title":"Test Case Progress Rate Graph","text":"The Test Case Progress Rate Graph displays the number of test case executions for the specified date range, against the specified release/sprint, ignoring the status from any previous days. Any test cases not executed that day will be considered \"not run\" and will appear in the \"not run\" category.
For example, if you have 10 test cases created on day 1 you will see 10 test cases \"not run\" on day 1. On day 2, you execute 5 test cases and fail them all, you will now see 5 test cases failed and 5 not run. On day 3, you execute 3 of the previous 5 test cases and pass them. You will now see 3 test cases passed, 0 failed and 7 not run.
"},{"location":"Spira-User-Manual/Reports-Center/#test-case-cumulative-progress-graph","title":"Test Case Cumulative Progress Graph","text":"The Test Case Cumulative Progress Graph displays the number of test case executions cumulatively over the specified date range, against the specified release/sprint. That means it will display for each day, the total number of test cases executed plus the status from any previous days that have not been changed. Any test cases not executed up to that point will be considered \"not run\" and will appear in the \"not run\" category.
For example, if you have 10 test cases created on day 1 you will see 10 test cases \"not run\" on day 1. On day 2, you execute 5 test cases and fail them all, you will now see 5 test cases failed and 5 not run. On day 3, you execute 3 of the previous 5 test cases and pass them. You will now see 3 test cases passed, 2 failed and 5 not run.
"},{"location":"Spira-User-Manual/Reports-Center/#incident-progress-rate-graph","title":"Incident Progress Rate Graph","text":"The incident progress rate chart displays the total number of incidents created and closed over a particular date-range, either for all incident types or for a specific incident type:
In this version of the report, the y-axis represents the number of incidents (either created or closed in a 24 hour period), and the x-axis represents a specific day in the time-span. Each data-point can be viewed by positioning the mouse pointer over the point, and a \"tooltip\" will pop-up listing the actual data value. You can filter the report by the type of incident, and also change the date range (e.g. displaying only the bugs for the date range). If you choose a smaller date-range, the x-axis will switch from weekly to daily and if you choose a larger date-range, the x-axis will switch to monthly.
Clicking on the \"Display Data Grid\" button will display the underlying data that is being used to generate the graph. In addition, clicking on the \"Download Data as CSV\" button will export the datagrid into Comma Separated Values (CSV) format that can be opened in MS-Excel. Some browsers also support the ability to save the graph as an image file (JPEG, PNG and GIF formats).
"},{"location":"Spira-User-Manual/Reports-Center/#cumulative-incident-count-graph","title":"Cumulative Incident Count Graph","text":"The cumulative incident count chart displays the cumulative total number of incidents logged in the system for the current product over a particular date-range, either for all incident types or for a specific incident type. The report displays two data series, one illustrating the total count of all incidents, the other the total count of all open incidents (i.e. with status not set to fixed or closed):
In this version of the report, the y-axis represents the number of incidents, and the x-axis represents a specific week in the time-span. Each data-point can be viewed by positioning the mouse pointer over the point, and a \"tooltip\" will pop-up listing the actual data value. You can also filter the type of incident being reported, as well as change the date interval. If you choose a smaller date-range, the x-axis will switch from weekly to daily and if you choose a larger date-range, the x-axis will switch to monthly.
Clicking on the \"Display Data Grid\" button will display the underlying data that is being used to generate the graph. In addition, clicking on the \"Download Data as CSV\" button will export the datagrid into Comma Separated Values (CSV) format that can be opened in MS-Excel. Some browsers also support the ability to save the graph as an image file (JPEG, PNG and GIF formats).
"},{"location":"Spira-User-Manual/Reports-Center/#open-incident-count-graph","title":"Open Incident Count Graph","text":"The open incident count chart displays the net number of open incidents in the system for the current product over a particular date-range categorized by incident priority, either for all incident types or for a specific incident type. For this chart, \"open\" is defined as any incident with an empty \"Closed On\" date. The incident status is not used for this chart.
In this version of the report, the y-axis represents the number of incidents, and the x-axis represents a specific week in the time-span. The exact count of each bar in the stacked histogram can be viewed by positioning the mouse pointer over the bar, and a \"tooltip\" will pop-up listing the actual data value. You can also filter the type of incident being reported, as well as change the date interval. If you choose a smaller date-range, the x-axis will switch from weekly to daily and if you choose a larger date-range, the x-axis will switch to monthly.
Clicking on the \"Display Data Grid\" button will display the underlying data that is being used to generate the graph. In addition, clicking on the \"Download Data as CSV\" button will export the datagrid into Comma Separated Values (CSV) format that can be opened in MS-Excel. Some browsers also support the ability to save the graph as an image file (JPEG, PNG and GIF formats).
"},{"location":"Spira-User-Manual/Reports-Center/#incident-count-by-status-graph","title":"Incident Count by Status Graph","text":"The incident status count chart displays the number of open incidents in the system for the current product over a particular date-range categorized by incident status, either for all incident types or for a specific incident type. For this chart, \"open\" is defined as any incident with an empty \"Closed On\" date. The incident status is not used for this chart.
In this version of the report, the y-axis represents the number of incidents, and the x-axis represents a specific week in the time-span. The exact count of each bar in the stacked histogram can be viewed by positioning the mouse pointer over the bar, and a \"tooltip\" will pop-up listing the actual data value. You can also filter the type of incident being reported, as well as change the date interval. If you choose a smaller date-range, the x-axis will switch from weekly to daily and if you choose a larger date-range, the x-axis will switch to monthly.
Clicking on the \"Display Data Grid\" button will display the underlying data that is being used to generate the graph. In addition, clicking on the \"Download Data as CSV\" button will export the datagrid into Comma Separated Values (CSV) format that can be opened in MS-Excel. Some browsers also support the ability to save the graph as an image file (JPEG, PNG and GIF formats).
"},{"location":"Spira-User-Manual/Reports-Center/#custom-graphs","title":"Custom Graphs","text":"These are the graphs that a SpiraPlan administrator has created in the Administration section of the system and published for use by end users. They rely on specific ESQL data queries, so the data represented will depend on the query created by the administrator.
To add a custom graph to your reports dashboard, click on the Add Items icon and click on the \"Custom Graphs\" button to show available custom graphs:
Once you add the Custom Graphs widget to your dashboard, it will look just like any other graph:
You can view the graph description from the \"i\" (for information) button at the top right of the graph. You can change the graph display between the three display types: donut, bar, and line. The donut style of graph is only available for reports with a single data series:
Clicking on the \"Data Grid\" icon will display the underlying data that is being used to generate the graph.
In addition, clicking on the \"Download Data as CSV\" button will export the data grid into Comma Separated Values (CSV) format that can be opened in MS-Excel.
Some browsers also support the ability to save the graph as an image file (JPEG, PNG and GIF formats).
"},{"location":"Spira-User-Manual/Reports-Center/#risk-reports","title":"Risk Reports","text":""},{"location":"Spira-User-Manual/Reports-Center/#risk-summary-report","title":"Risk Summary Report","text":"This report displays all of the risks tracked for the current project. The risks are displayed, along with a tabular list of mitigations, tasks, comments, attached documents, and change history:
"},{"location":"Spira-User-Manual/Reports-Center/#risk-detailed-report","title":"Risk Detailed Report","text":"This report displays all of the risks tracked for the current project. The risks are displayed in a summary table form:
An active release or sprint is one that has a status of either: \"Planned\", \"In Progress\", or \"Completed\"\u00a0\u21a9
This section outlines how the requirements management features of SpiraPlan\u00ae can be used to develop a requirements / scope matrix for a product, and how you can map any existing test-cases to the requirements. Typically when starting a product, developing the requirements list is the first activity after the Administrator has set up the product in the system.
"},{"location":"Spira-User-Manual/Requirements-Management/#requirement-traceability-and-coverage","title":"Requirement Traceability and Coverage","text":"From the requirement list page you can see a number of columns that show calculated data for each requirement, based off:
This allows you to see at a glance the state of play about a number of key metrics for the requirement.
"},{"location":"Spira-User-Manual/Requirements-Management/#test-coverage","title":"Test coverage","text":"This column shows a mini chart for the sum of each execution status against the requirement. It is calculated from the current execution status of each test case assigned to that requirement. If a requirement has no test case coverage then the mini chart will be empty. All requirements with at least one test case mapped against them will show a mini chart. For example, if a requirement has 3 test cases assigned to it, then the mini chart will show the results for those 3 test cases. If 2 of those test cases have passed and one has still not been run, the mini chart will show a green bar (for pass) that is \u2154 the length of the chart, and a gray bar (for not run) that is \u2153 the length of the bar.
If you hover the mouse over the mini chart it will display a tooltip that provides a more detailed description of the number of tests in each execution status.
When you have a hierarchy of requirements, the total number of test cases included in the mini chart is the sum of all of the test cases assigned to each of its children, added to the number of test cases directly assigned to the parent requirement.
Example: How Test Coverage Rolls up to Parent RequirementsThe left-hand sidebar on the requirements list page shows an donut chart of aggregate requirement test coverage in the product. It shows segments for each test execution status. It calculates the number for each execution status segment as follows:
Requirements with at least one task associated with them will display a task progress mini chart in the Task Progress column. This is a mini chart of the count of all active tasks1 assigned to the requirement. Each part of the chart represents the relative size of that progress category for the requirement. The progress categories are 'On Schedule', 'Late Finish', 'Late Start' and 'Not Started'.
If you hover the mouse over the mini chart it will display a tooltip that provides a more detailed description of the number of tasks in each category.
How are the different categories calculated?
On Schedule (green) tasks:
Running Late (red) tasks:
Starting Late (yellow) tasks:
Not Started (gray) tasks:
For each requirement each effort column is calculated from the sum of effort from all tasks assigned to that requirement. These values are aggregated to any parent requirements:
Task effort calculations are described in more detail here.
"},{"location":"Spira-User-Manual/Requirements-Management/#standard-requirements-and-parent-requirements","title":"Standard Requirements and Parent Requirements","text":"Requirements come in two main flavors (Both can be mapped against test cases for test coverage):
Standard requirements are any requirements that are not parents (do not have children). These are shown in normal-type and with a normal icon (for either a requirement or a use case). Standard requirements, unlike parent requirements, can:
Parent requirements are any requirement that has at least one child inside it. Parents are shown in bold-type and have a special parent requirement icon. They are marked as \"Yes\" when viewing the \"Is Parent?\" column on the requirement list pages. Parent requirements get some information based on their children (and are therefore always read only):
status, which is based on the status of their children:
When you indent a requirement under an existing requirement, the normal requirement becomes a parent requirement. When you outdent a child item, its parent will return to a standard requirement immediately, if it has no other children.
In all other ways these two requirement flavors are the same. For example, both can have any requirement type, both can be assigned to a release, or to a specific owner, and both follow the relevant workflow for their current type.
"},{"location":"Spira-User-Manual/Requirements-Management/#requirements-list","title":"Requirements List","text":"When you click on the Planning > Requirements link on the global navigation bar, you will initially be taken to the requirements list screen illustrated below:
Each requirement is, by default, displayed along with its importance/priority (ranked from \"Critical\" to \"Low\"), its completion status (from \"Requested\" to \"Completed\"), the version of the software that the requirement is planned for, and graphical indicators that represents its test coverage status and its task progress.
The requirements list consists of a hierarchical arrangement of the various requirements and functionalities that need to be provided by the system in question. The structure is very similar to the Work Breakdown Structure (WBS) developed in Microsoft Product\u00ae, and users of that software package will find this very familiar to use. When you create a new product, this list will be empty.
"},{"location":"Spira-User-Manual/Requirements-Management/#insert","title":"Insert","text":"Click the Insert button to add requirements. This button let's you add requirements in different ways:
Once the new requirement has been inserted, the item is switched to \"Edit\" mode so that you can rename the default name and choose a priority, status and/or author.
"},{"location":"Spira-User-Manual/Requirements-Management/#delete","title":"Delete","text":"Clicking on the \"Delete\" button deletes all the requirements whose check-boxes have been selected. If any of the items are summary items, the child requirements are also deleted. If all the children are deleted from a summary item, it changes back into a non-summary item.
"},{"location":"Spira-User-Manual/Requirements-Management/#indent","title":"Indent","text":"Clicking on the \"Indent\" button indents all the requirements whose check-boxes have been selected. If any of the items are made children of a requirement that had no previous children, it will be changed from a detail item into a summary item.
"},{"location":"Spira-User-Manual/Requirements-Management/#outdent","title":"Outdent","text":"Clicking on the \"Outdent\" button de-indents all the requirements whose check-boxes have been selected. If any of the items were the only children of a summary requirement item, then that item will be changed back from a summary item to a detail item.
"},{"location":"Spira-User-Manual/Requirements-Management/#refresh","title":"Refresh","text":"Clicking on the \"Refresh\" button simply reloads the requirements list (not the entire page). This is useful as other people may be modifying the list of requirements at the same time as you, and after stepping away from the computer for a short-time, you should click this button to make sure you are viewing the most current requirements list for the product.
"},{"location":"Spira-User-Manual/Requirements-Management/#edit","title":"Edit","text":"Each requirement in the list has an \"Edit\" button display in its right-most column. When you click this button or just double-click on any of the cells in the row, you change the item from \"View\" mode to \"Edit\" mode. The various columns are made editable, and \"Update\" buttons are displayed in the last column:
If you click \"Edit\" on more than one row, the \"Update\" buttons are only displayed on the first row selected. You can make changes to all the editable rows and then update the changes by clicking the one \"Update\" button. Also, if you want to make the same change to multiple rows (e.g. to change five requirements from \"In Progress\" status to \"Completed\"), you can click on the \"fill\" icon to the right of the editable item, which will propagate the new value to all editable items in the same column.
If you want to edit lots of items, first select their checkboxes and then click the [Edit] button on the same row as the Filters and it will switch all the selected items into edit mode.
When you have made your updates, you can either click \"Save\" to commit the changes, or \"Cancel\" to revert back to the original information. Alternatively, pressing the <ENTER> key will commit the changes and pressing the <ESCAPE> key will cancel the changes.
"},{"location":"Spira-User-Manual/Requirements-Management/#show-level","title":"Show Level","text":"Choosing an indent level from the 'Show Level' drop down box allows you to quickly and easily view the entire requirements list at a specific indent level. For example you may want to see all requirements drilled-down to the third level of detail. To do this you would simply choose 'Level 3' from the list, and the requirements will be expanded / collapsed accordingly.
"},{"location":"Spira-User-Manual/Requirements-Management/#filtering","title":"Filtering","text":"Read about how to create and manage filters.
"},{"location":"Spira-User-Manual/Requirements-Management/#show-hide-columns","title":"Show / Hide Columns","text":"This drop-down list allows you to change the fields that are displayed in the requirement list as columns for the current product. To show a column that is not already displayed, simply select that column from the list of \"Show...\" column names and to hide an existing column, simply select that column from the list of \"Hide...\" column names. This is stored on a per-product basis, so you can have different display settings for each product that you are a member of. The fields can be any of the built-in fields or any of the custom properties set up by the product owner.
"},{"location":"Spira-User-Manual/Requirements-Management/#copying-requirements","title":"Copying Requirements","text":"To copy a requirement or set of requirements, simply select the check-boxes of the requirements you want to copy and then select the Edit > Copy Items menu option. This will copy the current requirements selection to the clipboard. Then you should select the place where you want the requirements to be inserted and choose the Edit > Paste Items option.
The requirements will now be copied into the destination location you specified. The name of the copied requirements will have \" - Copy\" at the end, to distinguish them from the originals. Note that copied requirements will also include the test coverage information from the originals.
"},{"location":"Spira-User-Manual/Requirements-Management/#moving-requirements","title":"Moving Requirements","text":"To move a requirement in the requirements hierarchy, there are two options:
Once you have the requirement positioned at the correct place that you want it inserted, just release the mouse button. To move multiple items simply select their checkboxes and then drag-and-drop one of the selected items.
Read about how to export artifacts from one product to another.
"},{"location":"Spira-User-Manual/Requirements-Management/#creating-test-cases-from-requirements","title":"Creating Test Cases from Requirements","text":"To quickly create test cases from a group of requirements, all you need to do is select the check-boxes of the appropriate requirements and then click Tools > Create Test Cases. This will then create new test cases based on the selected requirements.
"},{"location":"Spira-User-Manual/Requirements-Management/#creating-a-test-set-from-requirements","title":"Creating a Test Set from Requirements","text":"To quickly create a new test set from a group of requirements, all you need to do is select the check-boxes of the appropriate requirements and then click Tools > Create Test Set. This will then create new test set containing the test cases that are already mapped to the selected requirement(s).
"},{"location":"Spira-User-Manual/Requirements-Management/#printing-items","title":"Printing Items","text":"To quickly print a single requirement or list of requirements you can select the items' checkboxes and then click Tools > Print Items. This will open a new window containing a printable version of the selected items.
"},{"location":"Spira-User-Manual/Requirements-Management/#focus-on-branch","title":"Focus-On Branch","text":"Sometimes you will see a list of filtered requirements displayed and you would like to view all of the items that in the same branch of the requirements tree, even those that don't match the current filter. To view the branch, select the checkbox of the branch and then click Tools > Focus on, and the system will clear the current filters and then expand just the selected branch.
"},{"location":"Spira-User-Manual/Requirements-Management/#right-click-context-menu","title":"Right-Click Context Menu","text":"SpiraPlan\u00ae provides a shortcut -- called the context menu - for accessing some of the most commonly used functions, so that you don't need to move your mouse up to the toolbar each time. To access the context menu, right-click on any of the rows in the requirements list and the following menu will be displayed:
You can now choose any of these options as an alternative to using the icons in the toolbar.
"},{"location":"Spira-User-Manual/Requirements-Management/#viewing-requirements-from-shared-products","title":"Viewing Requirements from Shared Products","text":"If you are displaying the requirements list for a product has required shared from other products, you will see the option on the top-right to view the requirements from the shared product(s):
If you choose the option to show the requirement from 'All Products' and not just the current product, the shared products are displayed, grouped under the name of the product they are being shared from:
Note: Any requirements shared from other products will be read-only and won't display any of their custom properties. However you can expand/collapse these shared requirements and filter using the standard fields.
"},{"location":"Spira-User-Manual/Requirements-Management/#requirements-additional-list-views","title":"Requirements Additional List Views","text":"In SpiraTeam and SpiraPlan, there are four additional requirement list views. They are designed to better serve the needs of the Business Analyst community who often need different views of requirements than the project teams and project managers. These views are:
You can pick between each of these views using the view selection button group at the top right of any requirement list page.
Note: you can only view requirements from the current product in these four additional views, whether or not you are sharing requirements from other products with this product.
"},{"location":"Spira-User-Manual/Requirements-Management/#requirements-sorted-list","title":"Requirements Sorted List","text":"This view lets you view the requirements in a flat, sortable list that does not show the requirements hierarchy. You can still see the hierarchy of an item by hovering the mouse over its name to display the tooltip.
This view lets you sort or filter on any of the visible fields.
One major benefit of this view is that when you filter by a field, you only get the items that are a direct match, unlike in the hierarchical grid view, where you also get its parents displayed. It can be useful to displaying a list of only parent requirements.
"},{"location":"Spira-User-Manual/Requirements-Management/#toolbar","title":"Toolbar","text":"When cloning the requirements note that:
followers, comments, and history are not cloned
Tools: this dropdown allows to export requirements, create test cases or create test sets from requirements, or to print items.
To access the context menu, right-click on any of the rows in the requirements sorted list and the following menu will be displayed:
You can now choose any of these options as an alternative to using the icons in the toolbar.
"},{"location":"Spira-User-Manual/Requirements-Management/#requirements-agile-board","title":"Requirements Agile Board","text":"This view is similar to the existing Planning Board but only displays requirements, whereas the primary planning board will also include incidents / defects. This gives the requirements page consistency with the tasks and incidents pages that already have a Grid / Board view selector option.
"},{"location":"Spira-User-Manual/Requirements-Management/#requirements-document-view","title":"Requirements Document View","text":"This view shows the hierarchical organization of the requirements in a product. Instead of being displayed in a grid form, they are displayed in a document format that is designed to be readable from top to bottom, like a traditional requirements document. You can edit the name and description fields inline to update your document as you read through it, as well as change what fields are visible, to tailor the document to your needs.
"},{"location":"Spira-User-Manual/Requirements-Management/#requirements-document-navigation","title":"Requirements Document Navigation","text":"The sidebar shows all the parent requirements in the product2, in their hierarchy. Clicking on a parent requirement will load that parent with all its children2 into the document view (and save this view for the next time you are on this page for this product). There is a special link at the top of the list of parent requirements called \"Level 1 (root)\" and clicking on this will load all requirements at the root level (level 1)2. This is the default view you will see when you first visit the documents view. Looking at \"Level 1 (root)\" is particularly useful if you need to view or edit standalone requirements (requirements that do not have a parent or any children).
When you click a parent requirement (or \"Level 1 (root)\") from the sidebar, the documents view will show a page of the first 50 requirements. If there are more than 50 requirements you can quickly change pages by using the pagination options at the top right.
"},{"location":"Spira-User-Manual/Requirements-Management/#requirements-document-options","title":"Requirements Document Options","text":"For each requirement, the following fields are always displayed at the top of the requirement:
The following fields are displayed by default (but can be hidden) in a header bar, below the requirement name:
The following fields are always displayed, and below the header bar:
Additionally you can choose to show the following fields in the header bar:
To show or hide any of the optional fields, click the \"Show/Hide fields\" dropdown at the top of the screen and choose your action. When you change which fields are shown, the data will reload to reflect that choice (if you have unsaved changes you will be prompted to discard them or save your changes).
Next to the \"Show/Hide fields\" dropdown is a print button. Clicking this will allow you to print all the requirements in the current page. If you are on page 2 of 3 in the documents view, you will print all of page 2's requirements only.
"},{"location":"Spira-User-Manual/Requirements-Management/#editing-the-requirements-documents","title":"Editing the requirements documents","text":"To edit the requirements on the documents view your user must have Bulk Edit permissions for requirements in that product. If you have this permission, you will see an edit icon to the far right of each requirement name. Click this to edit that requirement. You can edit the following fields:
In the screenshot below we are editing RQ:1. You can see this because of the requirement name is highlighted, and there are two icons on the far right (save and cancel), instead of the edit icon. RQ:2 is not being edited: we can see the edit icon on the far left. Look at the very top of the documents view and you see in the screenshot a helpful message showing \"Editing 1 item(s), with 0 unsaved change(s).\"
In this next screenshot, we are editing RQ:1 still, but also now RQ:2. We are currently making changes to RQ:1 (its save icon is now bigger and orange telling us it can be saved). The header message clearly tells us that we have unsaved changes on this page. This is a helpful way of tracking requirements you need to save, because if you are editing several at a time, not all will be on screen at once.
To save your changes, click the save icon. To discard your changes, click the X icon / cancel. If there was a problem saving the requirement you will see an error message explaining the issue.
"},{"location":"Spira-User-Manual/Requirements-Management/#requirements-mindmap","title":"Requirements Mindmap","text":"This mindmap displays the first 5,000 requirements in a product as a connected tree view / mindmap. The root node shows the name of the product on the left hand side. The top most level nodes are connected to the left of this, with their successive children shown from left to right.
For each requirement the map displays the name and ID of the requirement, with a tooltip that shows the description and any comments. Each node is color coded by its priority / importance value.
As well as showing the primary hierarchy, there is an option to turn on the display of requirement associations. This will let you see all of the associations as dotted lines. For associations that denote dependencies there is an arrow and dotted line that shows the direction of the dependency. For simple relationship (relates to) associations, there is a dotted line without an arrow. The system will display either the comment or type of association, depending what was entered when the association was created.
There are several other display options:
To view more information about a requirement, click its name. This will open popup with much more detail. If you ctrl/cmd+click on the requirement name it will open the full details page for that artifact. Information shown in the popup includes all standard and custom fields with fields being shown or hidden based on the workflow step that applies to that specific requirement.
You can edit requirements straight from the mindmap. Users with bulk edit permissions can edit a requirement (including adding a new comment) at any time by clicking on the requirement name. This opens a popup with full information about that requirement. At all times, which fields are shown, required, or hidden is based on the workflow step that applies to that specific requirement. To save any changes you must fill in all required fields. Please note: you cannot change the status in this edit mode, to do so open the artifact's detail page (you can do this from the popup by clicking the button next to the artifact's id at the top).
Note: only fields that users are able to edit are shown - fields that are always read only (like the creation date) are not shown in this view.
"},{"location":"Spira-User-Manual/Requirements-Management/#requirement-details","title":"Requirement Details","text":"When you click on a requirement item in the requirements list described in Requirements Management > Requirements List, you are taken to the requirement details page illustrated below:
This page is made up of three areas;
Please note that on smaller screen sizes the navigation pane is not displayed. While the navigation pane has a link to take you back to the requirements list, on mobile devices a 'back' button is shown on the left of the operations toolbar.
The navigation pane can be collapsed by clicking on the \"-\" button, or expanded by clicking anywhere on the gray title area. On desktops the user can also control the exact width of the navigation pane by dragging and dropping a red handle that appears on hovering at the rightmost edge of the navigation pane.
The navigation pane shows a list of the peer requirements to the one selected. This list is useful as a navigation shortcut; you can quickly view the coverage information of all the peer requirements by clicking on the navigation links without having to first return to the requirements list page. The navigation list can be switched between three different modes:
The bottom part of the right pane can be switched between six views: \"Overview\", \"Test Coverage\", \"Tasks\", \"Attachments\", \"History\" and \"Associations\", each of which will be described in more detail below.
"},{"location":"Spira-User-Manual/Requirements-Management/#toolbar-operations","title":"Toolbar Operations","text":"Sometimes you may want to split a requirement into two: the original requirement, and a new requirement (based off the original one). The two requirements are associated together after this process. To do this click Tools > Split. This will bring up the requirement split dialog shown below.
In this dialog you are focusing on the new requirement you are creating from performing the split. Here you can:
To complete the split click the Split button.
Notes about how requirement splitting works
New estimate:
Status:
Tasks are not moved or cloned from the original requirement to the new requirement
The Overview tab is divided into a number of different sections. Each of these can be collapsed or expanded by clicking on the title of that section. It displays the description, fields and comments associated with the requirement.
The top part of this tab displays the various standard fields and custom properties associated with the requirement. Fields (both standard and custom) are grouped under the collapsible headings (marked by orange text and underline) in the screenshot below. For instance, all fields regarding dates are grouped together in the \"Dates and Times\" area.
"},{"location":"Spira-User-Manual/Requirements-Management/#overview-detailed-information","title":"Overview -- Detailed Information","text":"The Detailed Information section contains the long, formatted description of the requirement, as well as any rich text custom fields. You can enter rich text or paste in from a word processing program or web page into these fields. Clicking on the shaded areas of one of these detailed fields will display the rich text toolbar.
"},{"location":"Spira-User-Manual/Requirements-Management/#overview-comments","title":"Overview - Comments","text":"Read about how the comments works
"},{"location":"Spira-User-Manual/Requirements-Management/#overview-scenario","title":"Overview -- Scenario","text":"If you are editing a 'Use Case' type of requirement, there will be a special 'Scenario' section where you can enter in the scenario steps that define the use case:
This section displays the various steps that a user would perform when carrying out the defined use case. The list of use case steps displays the position number, and the description. If a test case is created from this use-case, the steps will be used to create the test steps.
Clicking on the \"Insert Step\" button inserts a new step before the currently selected (by means of the check-box) step. Clicking the \"Insert Step\" button without selecting an existing step will insert a new step at the end of the list. When a new step is inserted, the fields are displayed in \"Edit\" mode, so the description, field is editable, allowing you to enter the data:
To move the steps in the list, click on the step you want to move and drag it to the location you want it moved.
"},{"location":"Spira-User-Manual/Requirements-Management/#test-coverage_1","title":"Test Coverage","text":"This tab shows the test coverage information for the requirement in question:
The tab displays a grid containing the test cases already mapped to this requirement. You can filter that list by the test case type, name, status, execution status, execution date, priority, product name and ID. You can remove an existing test case by selecting its check box and clicking the 'Delete' button. This doesn't delete the test case, just removes it from the requirement.
Hovering the mouse over the names of the test cases will display a \"tooltip\" consisting of the test case name, place in the folder structure and a detailed description.
To add a new test case to the requirement, simply click on the 'Add' button:
You can search for a test case by its ID if you know it (make sure to include the \"TC\" prefix):
Otherwise, you can search for the test cases by choosing a folder from the dropdown and/or entering a partial name match:
One you have found the desired test case(s), select their check boxes and click the 'Save' button to add them to the current requirement:
Finally, as a shortcut you can click the \"Create Test Case from This Requirement\" button to create a new test case in the list of covered test cases that will be automatically linked to this requirement. This is useful when you have created a new requirement and want to generate an initial covering test to be fleshed-out later.
"},{"location":"Spira-User-Manual/Requirements-Management/#tasks","title":"Tasks","text":"This tab shows the list of product tasks that need to be completed for the requirement to be satisfied:
Each of the tasks is displayed together with, by default, its name, description (by hovering the mouse over the name), progress, priority, start-date, current owner, estimated effort, projected effort and numeric task identifier. Clicking on the task name will bring up the Task Details page. This allows you to edit the details of an existing task.
You can perform the following actions on a task from this screen:
The system has a series of shortcuts that simplify the editing of requirements and tasks (these can be changed as required in product administration):
Read about how the attachments tab works
"},{"location":"Spira-User-Manual/Requirements-Management/#history","title":"History","text":"Read about how the history tab works
"},{"location":"Spira-User-Manual/Requirements-Management/#associations","title":"Associations","text":"You can associate other requirements, incidents, or risks to a requirement from this tab.
The associated requirements and risks are those a user has decided are relevant to the current requirement and has created a direct link between them. In the case of incidents, the association can be either due to the creator of an incident directly linking the incident to the requirement, or it can be the result of a tester executing a test-run and creating an incident during the test run. In this latter case, the check-box to the left of the association will be unavailable as the link is not editable.
Read more about how to manage and add associations to this artifact
"},{"location":"Spira-User-Manual/Requirements-Management/#use-case-diagrams","title":"Use Case Diagrams","text":"Requirements with a list of defined steps displays an extra tab called \"Diagram\". This display the list of steps as a process flow diagram rather than as a simple list.
You still write the scenario in the main Overview tab as a list of steps, however that list of steps will render as a diagram on this tab. Every step is displayed in the diagram. To make the diagram easier to read, only the first part of the step description is rendered in the diagram.
any task with a status that is not one of the following: \"Rejected\", \"Obsolete\", \"Duplicate\".\u00a0\u21a9
limited to the first 5000 requirements\u00a0\u21a9\u21a9\u21a9
This section outlines how you can use the Resource Tracking features of SpiraPlan\u00ae and SpiraTeam\u00ae to view the total workload for each of the product personnel resources assigned to a specific product. This allows you to verify that the work is evenly distributed amongst the product members and that no individual resource is overloaded.
When you click Tracking > Resources on the global navigation bar, you will initially be taken to the product resources list screen illustrated below:
This screen lists all the personnel (product resources) that belong to the current product together with the total value of the projected effort of all the work assigned to them, the available effort based on the length of the current release/sprint, and the remaining effort (the difference between the previous two values). The effort is shown for tasks and incidents as well as a total of the two together.
Using the dropdown on the far right, you can display the workload:
You can also display the workload for the entire program by selecting the program from the product/program selector from the navigation bar
There is a colored progress bar column called \"Allocation\" that graphically illustrates the % of the person's available effort that has been scheduled. If a person is over-scheduled, this bar will turn red. In addition, if any product resources have been assigned more work that they have time to complete during the length of the release/sprint, the background color of the remaining effort value will be also be colored in red, indicating that you need to offload some of the work to other product resources.
Clicking on a resource name will take you to the Resource Details page.
"},{"location":"Spira-User-Manual/Resource-Tracking/#resource-details","title":"Resource Details","text":"The resource details page will show you what artifacts a resource has been assigned, and time values for the items. A small panel on the left will show current configured values for the product for # of hours per workday, # of days per week, and how many non-work hours per month there are.
There are two options related to the instant messenger beneath the user's avatar. When you click the \"Send Message\" button it will open up a new instant message window to start a conversation with the selected resource. If the resource is not a contact of the current user, clicking the \"Add Contact\" button adds the selected resource to the user's 'My Contacts' list on the 'My Page' dashboard. Similarly if the resource is already a contact of the current user, clicking 'Remove Contact' will remove the resource as a contact.
Tabs along the bottom will show assigned requirements and tasks, incidents, test cases, test sets and recent actions. The views for each item are a subset of available columns, to show progress and completion information for all items listed. Clicking on an artifact's name will take you to the artifact details page. The data in all of these tabs can be filtered by all releases, by a release and its children, or by a specific sprint.
"},{"location":"Spira-User-Manual/Resource-Tracking/#reqs-tasks","title":"Reqs & Tasks","text":"This tab displays the list of requirements and child tasks that are assigned to the current resource:
"},{"location":"Spira-User-Manual/Resource-Tracking/#incidents","title":"Incidents","text":"This tab displays the list of incidents that are assigned to the current resource:
"},{"location":"Spira-User-Manual/Resource-Tracking/#test-cases","title":"Test Cases","text":"This tab displays the list of test cases that are assigned to the current resource:
"},{"location":"Spira-User-Manual/Resource-Tracking/#test-sets","title":"Test Sets","text":"This tab displays the list of test sets that are assigned to the current resource:
"},{"location":"Spira-User-Manual/Resource-Tracking/#actions","title":"Actions","text":"This tab displays the list of recent actions make by the user in the product. It lets you quickly see all the changes they have made:
This can be useful when auditing the changes made by a specific user.
"},{"location":"Spira-User-Manual/Risks-Management/","title":"Risks Management","text":"This section outlines the risk management features of SpiraPlan\u00ae (not available in SpiraTest or SpiraTeam) and how they can be used to help understand, track, and mitigate risks across your products. The expected principle ways of managing risks is through assigning values to each risk's probability and impact. These two fields, multiplied together, represent the potential (negative) exposure from the risk: a highly likely risk that would have a large impact has a higher exposure (and should be managed with a higher priority) than an unlikely risk which will not have much real world impact.
"},{"location":"Spira-User-Manual/Risks-Management/#risks-list","title":"Risks List","text":"When you click on the Tracking > Risks global navigation link, you will initially be taken to the risks list screen illustrated below:
The risk list screen displays all the risks entered for the current product, in a filterable, sortable grid. The grid displays the risk number together with fields such as risk type (schedule, financial, etc.), status (open, evaluated, etc.), probability, impact, and exposure (calculated from the probability and impact). The choice of columns displayed is configurable per-user, per-product, giving extensive flexibility when it comes to viewing and searching risks.
The sidebar on the left gives you quick access to saved filters, along with useful charts to get an at-a-glance view of risks for this product.
In addition, you can view a more detailed description of the risk (along with any mitigations) by positioning the mouse pointer over the incident name hyperlink and waiting for the popup \"tooltip\" to appear. If you click on the risk name hyperlink, you will be taken to the risk details page. Clicking on any of the pagination links at the bottom of the page will advance you to the next set of risks in the list according to the applied filter and sort-order. There is also a drop-down-list at the bottom of the page which allows you to specify how many rows should be displayed in each page, helping accommodate different user preferences.
"},{"location":"Spira-User-Manual/Risks-Management/#filtering-sorting","title":"Filtering & Sorting","text":"Read about how to create and manage filters, and how to sort the artifact list.
"},{"location":"Spira-User-Manual/Risks-Management/#new-risk","title":"New Risk","text":"Clicking on the \"New Risk\" button takes you to the new risk screen. This is essentially the same screen as the risk details screen except, depending on how the workflow has been configured for your product, certain fields may be disabled. For more details on setting and up configuring workflow for your product, please refer to the SpiraTest Administration Guide.
"},{"location":"Spira-User-Manual/Risks-Management/#delete","title":"Delete","text":"Clicking on the \"Delete\" button deletes the risk(s) whose check-boxes have been selected in the risk list.
"},{"location":"Spira-User-Manual/Risks-Management/#refresh","title":"Refresh","text":"Clicking on the \"Refresh\" button simply reloads the list of risks; this is useful when new risks are being added by other users, and you want to make sure you have the most up-to-date list displayed.
"},{"location":"Spira-User-Manual/Risks-Management/#show-hide-columns","title":"Show / Hide Columns","text":"This drop-down list allows you to change the fields that are displayed in the risk list as columns for the current product. To show a column that is not already displayed, select that column from the list of \"Show...\" column names and to hide an existing column, select that column from the list of \"Hide...\" column names. This is stored on a per-product basis, so you can have different display settings for each product you are a member of. The fields can be any of the built-in fields or any of the custom properties set up by the product owner.
"},{"location":"Spira-User-Manual/Risks-Management/#edit","title":"Edit","text":"Each risk in the list has an \"Edit\" button display in its right-most column. When you click this button or double-click on any of the cells in the row, you change the item from \"View\" mode to \"Edit\" mode. The various columns are made editable, and \"Save\" buttons are displayed in the last column:
If you click \"Edit\" on more than one row, the \"Save\" buttons are only displayed on the first row, and you can make changes to all the editable rows and then update the changes by clicking the one \"Save\" button. Also, if you want to make the same change to multiple rows (e.g. to change five risks from \"Resolved\" status to \"Closed\"), you can click on the \"fill\" icon to the right of the editable item, which will propagate the new value to all editable items in the same column.
If you want to edit lots of items, first select their checkboxes and then click the \"Edit\" button on the same row as the Filters and it will switch all the selected items into edit mode.
When you have made your updates, you can either click \"Save\" to commit the changes, or \"Cancel\" to revert back to the original information. Alternatively, pressing the <ENTER> key will commit the changes and pressing the <ESCAPE> key will cancel the changes.
"},{"location":"Spira-User-Manual/Risks-Management/#cloning-risks","title":"Cloning Risks","text":"To create a clone of an existing risk or set of risks, select the check-boxes of the risks you want to copy and then click Edit then \"Clone\". You can also clone a rsiks from its detailed view (using the dropdown next to the \"New\" button). Cloning a risk makes a copy of the selected risk with '... - Copy' added at the end of its name. When cloning risks note that:
Read about how to export artifacts from one product to another.
"},{"location":"Spira-User-Manual/Risks-Management/#printing-items","title":"Printing Items","text":"To quickly print a single risk or list of risks you can select the items' checkboxes and then click Tools > Print Items. This will display a popup window containing a printable version of the selected items. You can also save the report in a variety of common formats from the same Tools menu.
"},{"location":"Spira-User-Manual/Risks-Management/#risk-details","title":"Risk Details","text":"When you click on a risk item in the risks list, you are taken to the risk details page illustrated below:
This page is made up of three areas;
Please note that on smaller screen sizes the navigation pane is not displayed. While the navigation pane has a link to take you back to the risks list, on mobile devices a 'back' button is shown on the left of the operations toolbar.
The navigation pane can be collapsed by clicking on the \"-\" button, or expanded by clicking anywhere on the gray title area. On desktops the user can also control the exact width of the navigation pane by dragging and dropping a red handle that appears on hovering at the rightmost edge of the navigation pane.
The navigation pane shows a list of the peer risks to the one selected. This list is useful as a navigation shortcut; you can quickly view the coverage information of all the peer risks by clicking on the navigation links without having to first return to the risks list page. The navigation list can be switched between three different modes:
The bottom part of the right pane can be switched between four views: \"Overview\", \"Tasks\", \"Attachments\", \"History\", each of which will be described in more detail below.
"},{"location":"Spira-User-Manual/Risks-Management/#emailing","title":"Emailing","text":"Read about emailing a document to colleagues using Spira.
"},{"location":"Spira-User-Manual/Risks-Management/#followers","title":"Followers","text":"Read about how to add and manage followers to an artifact.
"},{"location":"Spira-User-Manual/Risks-Management/#workflows","title":"Workflows","text":"Read about using workflows to change the status of your artifact.
"},{"location":"Spira-User-Manual/Risks-Management/#overview-details","title":"Overview - Details","text":"The Overview tab is divided into a number of different sections. Each of these can be collapsed or expanded by clicking on the title of that section. It displays the description, fields and comments associated with the risk.
The top part of this tab displays the various standard fields and custom properties associated with the risk. Fields (both standard and custom) are grouped under the collapsible headings (marked by orange text and underline) in the screenshot below. For instance, all fields regarding dates are grouped together in the \"Dates and Times\" area.
"},{"location":"Spira-User-Manual/Risks-Management/#overview-detailed-information","title":"Overview -- Detailed Information","text":"The Detailed Information section contains the long, formatted description of the risk, as well as any rich text custom fields. You can enter rich text or paste in from a word processing program or web page into these fields. Clicking on the shaded areas of one of these detailed fields will display the rich text toolbar.
"},{"location":"Spira-User-Manual/Risks-Management/#overview-mitigations","title":"Overview -- Mitigations","text":"The mitigations section is where you can enter information about any plans or ideas about how the risk in question can be mitigated, in other words how its impact or probability can and/or will be lowered. The list of mitigations displays the position number, and the description, and date fields.
Clicking on the \"Add\" button inserts a new mitigation before the currently selected (by means of the check-box) step. Clicking the \"Add\" button without selecting an existing step will insert a new mitigation at the end of the list. When a new mitigation is inserted, its fields are displayed in \"Edit\" mode, so the description and review date fields are editable, allowing you to enter the data:
To move the mitigations around in the list, click and hold on the mitigation you want to move and drag it to the location desired.
If at least one mitigation is selected (using the checkboxes on the left-hand side), then clicking \"Clone\" will clone those mitigations and add them to the bottom of the list.
"},{"location":"Spira-User-Manual/Risks-Management/#overview-comments","title":"Overview - Comments","text":"Read about how the comments works
"},{"location":"Spira-User-Manual/Risks-Management/#tasks","title":"Tasks","text":"This tab shows the list of product tasks that need to be completed for the risk to be properly managed/mitigated:
Each of the tasks is displayed together with, by default, its name, description (by hovering the mouse over the name), progress, priority, start-date, current owner, estimated effort, projected effort and numeric task identifier. Clicking on the task name will bring up the Task Details page. This allows you to edit the details of an existing task.
You can perform the following actions on a task from this screen:
Note that if you create a new task on the risks page, the component, release/sprint, and owner are automatically copied from the parent risk. You can change these suggested values before clicking \"Save\"
"},{"location":"Spira-User-Manual/Risks-Management/#attachments","title":"Attachments","text":"Read about how the attachments tab works
"},{"location":"Spira-User-Manual/Risks-Management/#associations","title":"Associations","text":"You can associate other risks, incidents, test cases, and requirements to a risk from this tab. Read more about how to manage and add associations to this artifact
Read about how the history tab works
"},{"location":"Spira-User-Manual/Source-Code/","title":"Source Code","text":""},{"location":"Spira-User-Manual/Source-Code/#introduction","title":"Introduction","text":"SpiraTeam\u00ae's and SpiraPlan\u00ae's source code integration features let you:
SpiraPlan integrates with many different source code / Software Configuration Management (SCM). You can connect SpiraPlan and your source code using Inflectra's cloud-hosted TaraVault or plugins for the different SCM's (including Git and Subversion). If you want to learn more about using a source code provider, read our intro guides to using Git and using Subversion.
This section outlines SpiraPlan's source code features, whatever type of source code provider you are using. The Commit section outlines viewing and working with commits and the changes made in them.
"},{"location":"Spira-User-Manual/Source-Code/#getting-started-with-source-code","title":"Getting Started With Source Code","text":"To use the source code features in SpiraPlan you need to do 3 things:
Once these steps are complete, the source code will be viewable within SpiraPlan. The rest of this section assumes these steps have all been taken.
"},{"location":"Spira-User-Manual/Source-Code/#troubleshooting-source-code-integration","title":"Troubleshooting Source Code Integration","text":"Integration with a source code provider can sometimes not work as you expect:
When you click on Developing > Source Code on the global navigation bar, you will be taken to the source code repository file list screen. This shows you all file in the current folder and the current branch. You can change the branch, sort and filter this list, or browse the different pages of files (up to 500 files can be displayed on the page at any one time).
Deleted Files
Once a file has been deleted you will no longer be able to view that file from the list of files, or view information about that file. There is a current limitation that means the commit where a file was deleted is not able to show this file deletion.
This screen consists of two sections:
Above the list of files is the action toolbar. This lets you perform the following functions:
For each file you can see the following information (you can sort or filter on all of these):
When you click on a file link (for example, from the source code file list), you open the file details page for that file. This page shows you information about the file, its commit history, and where relevant a file preview. It also shows you links to other relevant files, commits, or artifacts.
The page is made up of three areas:
The detailed information available at the top of the page is:
There are 3 tabs on this page that each show additional information about the file. These are discussed below.
"},{"location":"Spira-User-Manual/Source-Code/#preview","title":"Preview","text":"This shows, where possible, a preview of the file. Image files are previewed, as are text files (for example, code), and markdown files (as HTML rendered previews). For code, syntax highlighting is applied based on the code file type (using the file extension) and line numbers are also shown.
Note that if you save a file with an incorrect extension (e.g. using .txt for a JavaScript file) it may not display the correct color-coding.
"},{"location":"Spira-User-Manual/Source-Code/#history","title":"History","text":"This shows the full commit history for that file in the current branch. The list of commits is paginated and up to 500 rows of commits can be shown at one time. You can also filter this list of commits.
Each commit is displayed with:
This shows all current associations between this file and any artifacts in SpiraPlan. This lets you to see which requirements, test cases, incidents, tasks, etc. are linked to the file. Clicking on the artifact name will take you to the appropriate artifact page (assuming your user has permissions to access that information).
You can also add artifact associations to many other artifacts in the system from this panel. Read more about how to manage and add associations to this artifact.
"},{"location":"Spira-User-Manual/Source-Code/#source-code-revision-list","title":"Source Code Revision List","text":"Updated documentation is here.
"},{"location":"Spira-User-Manual/Source-Code/#source-code-revision-details","title":"Source Code Revision Details","text":"Updated documentation is here.
Some older source code management systems (e.g. CVS, Visual SourceSafe) do not have the formal concept of branches, so the dropdown list will simply list the one main branch (usually called \"Trunk\").\u00a0\u21a9
Task Tracking in SpiraPlan\u00ae and SpiraPlan\u00ae lets you view and manage tasks assigned to each person in the product. Each task can be assigned to an individual user and linked to a particular release or sprint. Product managers can track the the progress of tasks to see if the product is on schedule.
Tasks can be organized into different folders and categorized by different types (development, testing, infrastructure, etc.), each of which can have its own workflow which defines the way the task can change status during the product lifecycle.
Tasks can be used in a number of different parts of the system to manage and track work:
When you click on the Tracking > Tasks global navigation link, you will initially be taken to the tasks list screen illustrated below:
The task list screen displays all the tasks entered for the current product by folder, in a filterable, sortable grid. The grid displays the task number together with fields such as priority, name, assigned owner, start date, end date, scheduled release, etc. The choice of columns displayed is configurable per-user, per-product, giving extensive flexibility when it comes to viewing and searching tasks.
In addition, you can view a more detailed description of the task by positioning the mouse pointer over the task name hyperlink and waiting for the popup \"tooltip\" to appear. If you click on the task name hyperlink, you will be taken to the task details page Clicking on any of the pagination links at the bottom of the page will advance you to the next set of tasks in the list according to the applied filter and sort-order. There is also a drop-down-list at the bottom of the page which allows you to specify how many rows should be displayed in each page, helping accommodate different user preferences.
"},{"location":"Spira-User-Manual/Task-Tracking/#task-progress","title":"Task Progress","text":"One special column that is unique to tasks is the 'progress indicator'. This illustrates graphically both the percentage completion of the task and also if the task is either starting late or finishing late. The following table illustrates the different type of status that can be conveyed by the indicator:
Indicator Display Progress Description Task has not yet started, but the scheduled start date is still in the future. Task has not yet started, and the start date has elapsed. This is considered a 'Late Starting Task' Task has started, and is approximately 25% complete. The scheduled end date is still in the future. Task has started, and is approximately 50% complete. However the scheduled end date has elapsed already. This is a considered a 'Late Finishing Task'. Task has been 100% completed.Essentially, the gray section of the bar indicates the % of the task yet to be completed, and the green/red section of the bar indicates the % of the task that has already been completed. If the bar changes from green to red it means that the end date has been reached and the task is not yet complete, and if the background changes from gray to yellow it means that the task has not yet started, but the scheduled start date has passed.
"},{"location":"Spira-User-Manual/Task-Tracking/#task-folders","title":"Task Folders","text":"SpiraPlan lets you group product tasks into different folders to make organization easier. In the left-hand Quick Filters panel, the system displays the various task folders defined in the product:
If you are a product administrator, you will see the 'Edit' and 'Add' buttons beneath the folder tree, this lets you add, edit and delete task folders in the product. To add a new folder, click the 'Add' button:
Choose the parent folder that you want to add the new folder under (or None if you are adding a new top-level folder) from the dropdown list and then enter the name of the new folder. Then click 'Add' to save the new folder.
To edit or delete an existing folder, simply click the \"Edit\" button to switch the folder tree to edit mode. To edit or delete a specific folder, click on the \"Edit\" button next to the folder:
You can change the parent folder and/or name of the folder and click \"Update\" to commit the change or click \"Delete\" to delete the folder entirely.
To move a task / tasks between folders, click and drag the relevant task/tasks from the table on the right, and drag them over the desired folder in the tree view on the left. The destination folder will be highlighted to show where the task will be placed.1
"},{"location":"Spira-User-Manual/Task-Tracking/#actions","title":"Actions","text":"Cloning Tasks: To create a clone of a task, a set of tasks, or a folder of tasks, select the check-boxes of the tasks you want to clone and then click \"Clone\". This will make a clone of the current task in the current folder with its name changed to add \" - Copy\" added to the end, to distinguish itself from the original. When cloning a folder of tasks, only the folder name gets changed. When cloning tasks note that:
all standard fields (like status and owner) are cloned
{: #duplicating-tasks} - Exporting Tasks to Another Product: Read about how to export artifacts from one product to another. {: #exporting-tasks-to-another-product} - Printing and Saving Items: To quickly print a single task, a list of tasks, or a folder of tasks you can select the items' checkboxes and then click Tools > Print Items. This will display a popup window containing a printable version of the selected items. You can also save the report in a variety of common formats from the same Tools menu.
"},{"location":"Spira-User-Manual/Task-Tracking/#edit","title":"Edit","text":"Each task in the list has an \"Edit\" button display in its right-most column. When you click this button or just click on any of the cells in the row, you change the item from \"View\" mode to \"Edit\" mode. The various columns are made editable, and \"Save\" buttons are displayed in the last column:
If you click \"Edit\" on more than one row, the \"Save\" buttons are only displayed on the first row, and you can make changes to all the editable rows and then update the changes by clicking the one \"Save\" button. Also, if you want to make the same change to multiple rows (e.g. to change five tasks from \"Not Started\" status to \"In Progress\"), you can click on the \"fill\" icon to the right of the editable item, which will propagate the new value to all editable items in the same column.
If you want to edit lots of items, first select their checkboxes and then click the \"Edit\" button on the same row as the Filters and it will switch all the selected items into edit mode.
When you have made your updates, you can either click \"Save\" to commit the changes, or \"Cancel\" to revert back to the original information. Alternatively, pressing the <ENTER> key will commit the changes and pressing the <ESCAPE> key will cancel the changes.
"},{"location":"Spira-User-Manual/Task-Tracking/#task-additional-list-views","title":"Task Additional List Views","text":"There are two additional task list views. These views are:
You can pick between each of these views using the view selection button group at the top right of any requirement list page.
"},{"location":"Spira-User-Manual/Task-Tracking/#task-board","title":"Task Board","text":"The task board is an alternative to the task list page designed to let you view the tasks planned for the current product. You can access this feature by clicking on the Board icon in the top-right of the Tasks list page. You can switch back to the Task list page by clicking on the Table view.
The task board has the following different display modes:
All Releases
Release
Sprint
Each of these views is described below.
Planning Boards and Editing
Moving cards: Please note that the purpose of a planning board or Kanban board, is to make it straightforward for users to move cards around the interface to plan out their work. Therefore we do not enforce workflow restrictions on the planning board when moving cards. Therefore only users with permissions to bulk edit the relevant artifact can move cards. If the template admin has prevented status changes while bulk editing, then noone can change a card's status by moving its card on the planning.
Viewing cards: to view more information about the card you can: turn on Detailed View; hover on the card name to see a rich tooltip; click on the card's id to open a popup with much more detail; or ctrl/cmd+click on the card's id to open the full details page for that artifact. Information shown in the popup includes all standard and custom fields with fields being shown or hidden based on the workflow step that applies to that specific card.
Editing cards: users with bulk edit permissions can edit a planning board card at any time by click on the card's id (including adding a new comment). This opens a popup with full information about that card. At all times, which fields are shown, required, or hidden is based on the workflow step that applies to that specific card. To save any changes you must fill in all required fields. Please note: you cannot change the status in this edit mode, to do so open the artifact's detail page (you cand do this from the popup by clicking the button next to the artifact's id at the top).
Add new cards: if you are able to create the requirements then you will see plus (add) symbols in different locations on the board. Clicking any of these will open an popup screen with all relevant fields available. Some of these fields may be prepopulated based on what add button you clicked and how you are using the board. For instance, if you are viewing for a release, that release will be preselected. And if you are grouping by person and click on a particular person, that person will be set as the owner of the artifact. The fields visible and required is driven based on what workflow step will apply to that new card.
"},{"location":"Spira-User-Manual/Task-Tracking/#tasks-by-priority","title":"Tasks -- By Priority","text":"This view is designed to let you see the list of planned tasks organized by priority. Each of the possible priority values is displayed on the left-hand side and the tasks displayed in the same row on the right:
The top section will contain the list of tasks that are not assigned a priority, with the other sections containing the tasks that have been assigned to the specific priority.
"},{"location":"Spira-User-Manual/Task-Tracking/#tasks-by-status","title":"Tasks -- By Status","text":"This view is designed to let you see the tasks in the current product / release / sprint organized by their status. Each task status (not started, in progress, completed, blocked, deferred) is displayed as a heading, with the tasks displayed in the same column underneath:
You can click on the expand/collapse icons to hide any resources that are not relevant.
Depending on the view (all releases, release, or sprint), there may be sections with the release and sprint name. You can drag and drop the tasks between statuses or to/from the release/sprint backlog. Any tasks not assigned to a release/sprint will be listed in the (Unassigned Items) section at the top.
"},{"location":"Spira-User-Manual/Task-Tracking/#tasks-by-person","title":"Tasks - By Person","text":"This view is designed to let you see the tasks in the current product / release / sprint organized by resource / person. Each of the users that is a member of the current product is displayed as a heading, with the tasks displayed in the same column underneath. This view is often called the Task Board:
You can click on the expand/collapse icons to hide any resources that are not relevant. The system will display a progress bar for each resource to illustrate the allocation for that resource. Any resource that has a progress bar that is completely green has been fully scheduled and should not have any additional tasks assigned. If the progress bar for that resource turns red, it means that they have been over-scheduled and you need to reassign some of the tasks.
Depending on the view (all releases, release, or sprint), there may be sections with the release and sprint name; they contain tasks that are scheduled for the current release or sprint but have not yet been assigned to a resource. You can drag and drop the tasks between resources or to/from the release/sprint backlog (as long as the item has a status that let's you set or edit its owner field). Any tasks not assigned to a resource and release/sprint will be listed in the (Unassigned Items) section at the top.
"},{"location":"Spira-User-Manual/Task-Tracking/#tasks-by-release","title":"Tasks - By Release","text":"This view is only available when you are displaying the task board for 'all releases'. Each of the active releases defined for the current product is displayed as a heading, with the tasks displayed in the same column underneath
You can drag and drop the tasks between the different releases. Once the task has been added to the release, the utilized effort for the release will increase, and the available effort will decrease by the same amount.
Note: The system will allow you to assign more tasks to a release than it is possible to complete, however this will result in a negative value for 'available effort'. If this happens, the \"Available Effort\" value will be displayed in red, and you need to rebalance the items, extend the release length or add product personnel resources to the release.
Clicking on the release hyperlinks in the headers will switch the task board into the release view.
"},{"location":"Spira-User-Manual/Task-Tracking/#tasks-by-sprint","title":"Tasks - By Sprint","text":"This view is only available when you are displaying the task board for a specific release. Each of the sprints defined for the current release is displayed as a heading, with the tasks displayed in the same column underneath. This view is commonly used in Scrum products:
You can drag and drop the tasks between the different sprints. Once the task has been added to the sprint, the utilized effort for the sprint will increase, and the available effort will decrease by the same amount.
Note: The system will allow you to assign more tasks to a sprint than it is possible to complete, however this will result in a negative value for 'available effort'. If this happens, the \"Available Effort\" value will be displayed in red, and you need to rebalance the items, extend the sprint length or add product personnel resources to the sprint.
Clicking on the sprint hyperlinks in the headers will switch the task board into the sprint view.
"},{"location":"Spira-User-Manual/Task-Tracking/#tasks-by-requirement","title":"Tasks - By Requirement","text":"This option is only available when you are displaying the task board for a specific release or sprint.
In this case, the left hand side displays the requirements currently assigned to the current release / sprint, and the right hand column contains the tasks (in a card format) that are associated with that specific requirement, complete with color-coded progress bars. This view lets you quickly see all of the current user stories being worked, and the progress of completing the related tasks, in a single unified view.
"},{"location":"Spira-User-Manual/Task-Tracking/#beta-task-board","title":"Beta task board","text":"In beta, available in SpiraTeam and SpiraPlan
System admins can enable beta functionality across the application for their users from the System Admin > General Settings page.
To learn more about how the task board is structured or how to enter the beta please refer to our general information about the beta boards.
"},{"location":"Spira-User-Manual/Task-Tracking/#views-summary","title":"Views summary","text":"Details about what combinations of views is possible and how each feature works is discussed in detail the sections below. For ease of reference, here is a summary of the different options available (you cannot select the same value for multiple view options at the same time):
Releases can display \"all releases\" or a specific releases. The dropdown shows all open releases and sprints.
View options All releases A specific release or sprint Grouping Priority Release Status Type Person Team ... and Requirement Columns Priority Release Status Type Person ... and Requirement Rows Priority Release Status Type Person ... and Requirement"},{"location":"Spira-User-Manual/Task-Tracking/#view-controls","title":"View controls","text":"The release dropdown shows:
Read about how grouping works.
Read about how to use columns.
Read about how to use rows.
Read about what cards show when.
"},{"location":"Spira-User-Manual/Task-Tracking/#customizing-the-cards","title":"Customizing the cards","text":"You can customize what information is shown on each card. For each artifact the following fields are always shown:
You can toggle whether to show each of the following features:
Below is an example of a task card showing all available data
"},{"location":"Spira-User-Manual/Task-Tracking/#moving-and-ordering-cards","title":"Moving and ordering cards","text":"Read about this here.
"},{"location":"Spira-User-Manual/Task-Tracking/#editing-and-viewing-cards","title":"Editing and viewing cards","text":"Read about this here.
"},{"location":"Spira-User-Manual/Task-Tracking/#viewing-by-release-or-sprint","title":"Viewing by release or sprint","text":"Read about this here.
"},{"location":"Spira-User-Manual/Task-Tracking/#viewing-by-person","title":"Viewing by Person","text":"Read about this here.
"},{"location":"Spira-User-Manual/Task-Tracking/#task-gantt-chart","title":"Task Gantt Chart","text":"This displays all active releases and sprints2 nested in the same hierarchy as on the main release list page (releases or sprints without any tasks are also shown). It also displays any task that are assigned to one of these releases.
Any release that has active children or open tasks has an expand / collapse toggle to the left of its name. This will show the child releases and/or the assigned tasks
To the right of the names is the timeline bar, which graphically shows the length of each release (blue) and task (green) between their start and end dates in individual horizontal bars. The names of the releases and tasks on the left or in the horizontal bars are clickable and will open the specific release or task.
Part of a release or task may be shaded darker than normal, from its left - this is based on how complete the release or task is.
Above the Gantt chart is a toolbar that lets you:
Add button to add a new dispaly a popup to fill in information about the new task. The new task's release is filled in if you select a release on the Gantt chart, or otherwise by the release you are filtering the page on (see below). Click Add Task to add the task into the product.To view more information about a release or task, click its name from the left hand sidebar or in the relevant Gantt bar. This will open popup with much more detail. If you ctrl/cmd+click on the artifact's name it will open the full details page for that artifact. Information shown in the popup includes all standard and custom fields. These fields are visible or hidden based on the workflow step that applies to that specific release or to that specific task.
You can edit releases and tasks straight from the Gantt chart. Users with bulk edit permissions for releases or tasks can edit each respective artifact (including adding a new comment) at any time by clicking on the artifact name. This opens a popup with full information about that artifact. At all times, which fields are shown, required, or hidden is based on the workflow step that applies to that specific artifact. To save any changes you must fill in all required fields. Please note: you cannot change the status in this edit mode, to do so open the artifact's detail page (you can do this from the popup by clicking the button next to the artifact's id at the top).
Note: only fields that users are able to edit are shown - fields that are always read only (like the creation date) are not shown in this view.
"},{"location":"Spira-User-Manual/Task-Tracking/#task-details","title":"Task Details","text":"When you click on a task item in the lists displayed on either the main task list page or on the requirement / release details pages, you are taken to the task details page illustrated below:
This page is made up of three areas;
the left pane displays the tasks list navigation;
the right pane's header, which displays: the operations toolbar; the folder the task is in; the editable name of the selected task; and the info bar (with a shaded background), which also contains the workflow status transitions (see below); and
the right pane's tabbed interface with rich information related to the task.
Please note that on smaller screen sizes the navigation pane is not displayed. While the navigation pane has a link to take you back to the tasks list, on mobile devices a 'back' button is shown on the left of the operations toolbar.
The navigation pane can be collapsed by clicking on the \"-\" button, or expanded by clicking anywhere on the gray title area. On desktops the user can also control the exact width of the navigation pane by dragging and dropping a red handle that appears on hovering at the rightmost edge of the navigation pane.
The navigation pane consists of a link that will take you back to the task list, as well as a list of tasks, and another list of the other related tasks, nested under their parent task. This latter list is useful as a navigation shortcut; you can quickly view the peer tasks by clicking on the navigation links without having to first return to the tasks list pages. The navigation list can be switched between five different modes:
Current Filter - The list of tasks matching the current filter organized by task folder
All Items - The list of all tasks, irrespective of the current filter, organized by task folder
Assigned - The list of tasks assigned to the current user grouped by their parent requirement
For Release - The list of tasks assigned to the current release or sprint, grouped under that parent release/sprint.
For Requirement -- The list of tasks associated to the same requirement as the current task as well as other tasks at the same level in the requirement hierarchy.
The lower part of the right pane can be in one of four possible tabs that can be selected: \"Overview Properties\", \"Attachments\", \"History\" and \"Associations\". Each of the different views is described separately below.
"},{"location":"Spira-User-Manual/Task-Tracking/#toolbar-operations","title":"Toolbar Operations","text":"Sometimes you may want to split a task into two: the original task, and a new task (based off the original one). The two tasks are associated together after this process. To do this click Tools > Split. This will bring up the task split dialog shown below.
In this dialog you are focusing on the new task you are creating from performing the split. Here you can:
To complete the split click the Split button.
Notes about how the split works:
The Overview tab is divided into a number of different sections. Each of these can be collapsed or expanded by clicking on the title of that section. It displays the description, fields and comments associated with the task.
The top part of this tab displays the various standard fields and custom properties associated with the task. Fields (both standard and custom) are grouped under the collapsible headings (marked by orange text and underline) in the screenshot below. For instance, all fields regarding dates are grouped together in the \"Dates and Times\" area.
"},{"location":"Spira-User-Manual/Task-Tracking/#effort-fields","title":"Effort Fields","text":"You can enter/edit the start-date, end-date (i.e. the due-date), estimated, actual and remaining effort. From this the system will calculate the progress, percentage complete and projected final effort.
The different effort values mean the following:
Note: If the actual effort is not specified, the projected effort will be the same as the estimated effort.
Note: if the task is currently assigned to a release or sprint, the start-date and end-date of the task must lie within the date-range of the parent release/sprint. If your task looks like it will not be completed in the available timeframe, you will need to contact the product manager to get them to either extend the date-range of the task, or consider moving the task to the next sprint.
"},{"location":"Spira-User-Manual/Task-Tracking/#followers_1","title":"Followers","text":"Using the \"Subscribe\" button on the toolbar, you can quickly follow the item, and receive updates on certain changes to it. Depending on your role, you may also see a dropdown to this button, which let's you add another product member as a follower to this item.
You can also quickly see who is following an incident under the \"People\" section in the Overview tab.
To view information about the follower, or to unfollow them from the item, hover over their avatar to display a user profile card.
"},{"location":"Spira-User-Manual/Task-Tracking/#overview-comments","title":"Overview -- Comments","text":"Read about how the comments works
"},{"location":"Spira-User-Manual/Task-Tracking/#attachments","title":"Attachments","text":"Read about how the attachments tab works
"},{"location":"Spira-User-Manual/Task-Tracking/#associations","title":"Associations","text":"You can associate other tasks and to a task from this tab. Read more about how to manage and add associations to this artifact
"},{"location":"Spira-User-Manual/Task-Tracking/#commits","title":"Commits","text":"Tasks that are pull requests will show the commits tab. Read more about the commits tab.
"},{"location":"Spira-User-Manual/Task-Tracking/#history","title":"History","text":"Read about how the history tab works
"},{"location":"Spira-User-Manual/Task-Tracking/#creating-an-incident-from-a-task","title":"Creating an Incident from a Task","text":"Sometimes you may have a task logged to, say, fix something before release, that now needs to be converted into an Incident (because it won't be able to get fixed before release). This workflow is useful because Incidents usually are more public facing, and have more process around them than tasks. There is a shortcut to create a new incident from the current task; and it automatically creates an association between the new incident and the task (and if the task is linked to a requirement an association is added between that requirement and the new incident too).3
To use this feature:
Add buttonCreate Incident from this Task button when navigating to folders (for all artifacts that support them), the URL in your browser's address bar will change. Each folder has a unique, sharable URL that you can give to someone to display the list of artifacts with the appropriate folder selected. You can also open up multiple folders in different browser tabs and easily toggle between them from the same browser.\u00a0\u21a9
any release / sprint / phase with a status that is not \"Closed\", \"Deferred\", or \"Cancelled\".\u00a0\u21a9\u21a9
To create an incident from a task, the user needs must have the permission to create incidents (which makes sense).
The creation process does not enforce the relevant incident workflow to make sure that all required fields are filled in.
What gets copied over from the task to the new incident:
\u21a9
This section outlines how the use-case / test-case management features of SpiraPlan\u00ae can be used to develop the business use-cases for the system, which specify how the different pieces of functionality are expected to work in practice. In addition, these use/test-cases form the basis of the business specification of the system when associated with the underlying requirements matrix. Typically when starting a new product:
However when migrating existing products into SpiraPlan\u00ae, you may need to migrate the test-case list first, and then add the supporting requirements matrix afterwards.
"},{"location":"Spira-User-Manual/Test-Case-Management/#test-case-list","title":"Test Case List","text":"When you click on the Testing > Test Cases link on the global navigation bar, you will initially be taken to the test case list screen illustrated below:
The test case list consists of a hierarchical arrangement of the various test folders and test cases. The structure is very similar to the folder structure in Microsoft Windows\u00ae Explorer, and users will find this very familiar and intuitive to use. A folder tree is on the left hand side---with triangle icons to expand / collapse each folder. Contents of the selected folder (the one marked in bold on the folder tree) are shown on the right hand side.
When you create a new product, this list will initially be empty, and you will have to use the \"New Test Case\" button to start adding test cases to the system. A new product will also not have any test folders---only the base \"Root\" folder will be visible. To add a test folder, you click the \"Add' button at the bottom of the folder tree on the left.
The list shows all test folders (shown with a folder icon), and test cases (shown with a document icon) inside the currently selected folder. You can place test folders and test cases into test folders.2 All of the items in the list have a name, together with the most recent execution status (passed, failed or not-run), and owner, author, execution date, active flag and test case number. Clicking on a test case's hyperlink will take you to the test case details page for the item in question.
It is important to understand that only test cases are assigned a status themselves; the test folders instead display a test execution bar graph that illustrates the aggregate execution status of its child test-cases. Thus, if the test folder contains two test cases, one of which passed, and one of which wasn't run, the graph will display 50% green and 50% gray.
To determine the exact aggregate test folder execution status information, position the mouse pointer over the bar-chart, and the number of tests in each of the execution statuses (passed, failed, not-run, blocked, caution) will be displayed as a \"tooltip\". Note that if you change the owner of a test folder, then all the child test cases will be assigned the same owner. This allows you to more easily associate entire folders to test cases to be executed by a specific user.
"},{"location":"Spira-User-Manual/Test-Case-Management/#add-a-test-case","title":"Add a Test Case","text":"Click the \"New Test Case\" button will add a test case in the currently displayed folder (ie the one marked in bolder on the folder tree and also shown in the yellow information box). The new test case will be added at the bottom of the list.
Once the new test case has been inserted, the item is switched to \"Edit\" mode so that you can rename the default name and choose an owner and/or author. Note that all new test cases are initially set with an execution status of \"Not Run\".
"},{"location":"Spira-User-Manual/Test-Case-Management/#delete","title":"Delete","text":"Clicking on the \"Delete\" button deletes all the test cases and/or test folders whose check-boxes have been selected. If any of the items are test folders, then the entire contents of that folder will also be deleted (as you would expect in Microsoft Windows\u00ae Explorer or OS X Finder).
"},{"location":"Spira-User-Manual/Test-Case-Management/#execute","title":"Execute","text":"Clicking on the \"Execute Tests\" button (accessed from the \"Tools\" menu or context menu) executes all the test cases selected, together with all the test cases contained with any selected test folders. The test execution functionality of SpiraPlan\u00ae is explained in more detail in Test Step Details. NOTE: if the product does not allow you to execute test cases this button will not be available.
"},{"location":"Spira-User-Manual/Test-Case-Management/#refresh","title":"Refresh","text":"Clicking on the \"Refresh\" button simply reloads the test case list. This is useful as other people may be modifying the list of test cases at the same time as you, or executing specific test cases, and after stepping away from the computer for a short-time, you can click this button to make sure you are viewing the most current test case list for the product.
"},{"location":"Spira-User-Manual/Test-Case-Management/#editing-a-test-case","title":"Editing a Test Case","text":"Each test case in the list has an \"Edit\" button in its right-most column. When you click this button (or double-click on any of the cells in the row), you change the item from \"View\" mode to \"Edit\" mode. The various columns are made editable, and \"Update\" buttons are displayed in the last column:
If you click \"Edit\" on more than one row, the \"Update\" buttons are only displayed on the first row, and you can make changes to all the editable rows and then update the changes by clicking the one \"Update\" button. Also, if you want to make the same change to multiple rows (e.g. to change the owner of five test cases from \"Fred Bloggs\" to \"Joe Smith\"), you can click on the \"fill\" icon to the right of the editable item, which will propagate the new value to all editable items in the same column.
If you want to edit lots of items, first select their checkboxes and then click the \"Edit\" button on the same row as the Filters (ie the topmost edit button) and it will switch all the selected items into edit mode.
When you have made your updates, you can either click \"Update\" to commit the changes, or \"Cancel\" to revert back to the original information. Alternatively, pressing the <ENTER> key will commit the changes and pressing the <ESCAPE> key will cancel the changes.
"},{"location":"Spira-User-Manual/Test-Case-Management/#editing-a-test-folder","title":"Editing a Test Folder","text":"Test folders shown on the right hand list pane do not have an \"Edit\" button. To edit a test folder, first click the \"Edit\" button at the bottom of the left hand folder tree. This will place the whole folder tree into edit mode---each folder will get a small \"Edit\" button of its own.
Clicking on the \"Edit\" button of the folder you want to edit will display a pop up dialog. This allows you to: move the folder into a new or different parent folder; edit the name of the folder; or add a more detailed description. Click \"Update\" to commit the changes, \"Cancel\" to revert back to the original information, or \"Delete\" to delete the folder (and all of its contents). Note that on clicking \"Delete\" a warning box will appear to make sure you don't accidentally delete something.
"},{"location":"Spira-User-Manual/Test-Case-Management/#show-hide-columns","title":"Show / Hide Columns","text":"This drop-down list allows you to change the fields that are displayed in the test case list as columns for the current product. To show a column that is not already displayed, simply select that column from the list of \"Show...\" column names and to hide an existing column, simply select that column from the list of \"Hide...\" column names. This is stored on a per-product basis, so you can have different display settings for each product that you are a member of. The fields can be any of the built-in fields or any of the custom properties set up by the product owner.
Note: If you hide the 'execution status' column, the test case folders will no longer show the count of test cases contained within the folder.
"},{"location":"Spira-User-Manual/Test-Case-Management/#filtering-sorting","title":"Filtering & Sorting","text":"Read about how to create and manage filters, and how to sort the artifact list.
"},{"location":"Spira-User-Manual/Test-Case-Management/#viewing-the-test-status-for-a-release","title":"Viewing the Test Status for a Release","text":"By default, when you view the list of test cases, it will display an aggregate status for all releases of the product. I.e. the test list will include all the test cases in the system (regardless of which release they apply to) and the execution status will reflect the most recent test run -- regardless of which release it was for.
To change the test case list to just display test cases and execution status for a particular release, change the release selected in the drop-down list located in the top-right from \"All Releases\" to a specific release:
As illustrated in the example above, when the drop-down list is changed to select a specific release, the list of test cases is filtered to just those mapped to the release in question. In addition, the execution status for the test cases will only reflect test runs for that specific release (and any child sprints if applicable). As can be seen in our example, many test cases that have been run for other releases now show the \"Not Run\" status since they've not been run for this specific release.
As a shortcut, when you select a specific release for viewing, subsequent execution of any of the test cases via the Tools > Execute Tests menu option will default the test run to the selected release.
"},{"location":"Spira-User-Manual/Test-Case-Management/#copying-test-cases","title":"Copying Test Cases","text":"To copy one or more test cases, select the check-boxes of the test cases (or test case folder) you want to copy and then select Edit > Copy Items from the menu. This will copy the current test case / test case folder selection to the clipboard. Then select the place you want the test cases to be inserted and choose the Edit > Paste Items option.
The test cases will now be copied to the destination you specified. The name of the copied test cases will have \" - Copy\" added to the end to distinguish them from the originals. If you are copying test case folders, only the top level folders' name(s) will will have \" - Copy\" added to the end - the new copies of items in the folder will have the same names as the originals.
"},{"location":"Spira-User-Manual/Test-Case-Management/#blocking-and-unblocking-test-cases","title":"Blocking and Unblocking Test Cases","text":"To designate one or more test cases as blocked, select the check-boxes of the test cases and then select the Edit > Block Test Cases menu option. This temporarily blocks test cases so that testers know they are not available for testing. Unlike actually executing the test cases and recording an execution status, no test run is recorded and summary metrics (such as requirements test coverage and test set status) are not updated. Likewise, to unblock test cases, select their check-boxes and then select the Edit > Unblock Test Cases menu option. This changes their Execution Status from Blocked to Not Run. The Edit menu will be enabled if the current user has Test Case > Bulk Edit permission.
"},{"location":"Spira-User-Manual/Test-Case-Management/#moving-test-cases-or-folders","title":"Moving Test Cases or Folders","text":"There are two options for moving test cases or folders:
Once you have the test case/folder positioned at the correct place that you want it inserted, just release the mouse button. To move multiple items simply select their checkboxes and then drag-and-drop one of the selected items.
Read about how to export artifacts from one product to another.
"},{"location":"Spira-User-Manual/Test-Case-Management/#adding-test-cases-to-a-release-test-set-or-requirement","title":"Adding Test Cases to a Release, Test Set or Requirement","text":"To quickly add a series of test cases to a Release, Test Set or Requirement, select the check-boxes of the appropriate test cases and then click Tools > Add to Release / Test Set / Requirement. This will bring up a dialog box displaying either a list of available releases, test sets or requirements (depending on which option was chosen):
Once you have chosen the destination release / test set / requirement, clicking \"Add\" will add the selected test cases to that specific destination release / test set / requirement.
"},{"location":"Spira-User-Manual/Test-Case-Management/#printing-items","title":"Printing Items","text":"To quickly print a single test case, test folder or list of test cases you can select the items' checkboxes and then click Tools > Print Items. This will create a printable report of the selected items in a new window.
"},{"location":"Spira-User-Manual/Test-Case-Management/#right-click-context-menu","title":"Right-Click Context Menu","text":"SpiraPlan\u00ae provides a shortcut -- called the context menu - for accessing some of the most commonly used functions, so that you don't need to move your mouse up to the toolbar each time. To access the context menu, right-click on any of the rows in the test case list and the following menu will be displayed:
You can now choose any of these options as an alternative to using the icons in the toolbar.
"},{"location":"Spira-User-Manual/Test-Case-Management/#test-case-details","title":"Test Case Details","text":"When you click on a test case item in the test case list, you are taken to the test case details page illustrated below:
This page is made up of three areas;
The navigation pane consists of a link that will take you back to the test case list, as well as a list of the peer test cases to the one selected. This latter list is useful as a navigation shortcut: you can quickly view the detailed information of all the peer test cases by clicking on the navigation links without having to first return to the test cases list page. The navigation list can be switched between three different modes:
The operations toolbar lets you, amongst standard operations like save and delete:
RefreshTools dropdown menuExecute button will immediately prepare the current test case for execution and then take you to the test execution screen. NOTE: if the product does not allow you to execute test cases this button will not be available.When cloning test cases note that:
The lower part of the right pane can be switched between a number of different views by clicking the appropriate tab. Initially the pane will be in \"Overview\" mode, but it can be switched to \"Requirements Coverage\", \"Test Runs\", \"Releases\", \"Incidents\", \"Attachments\", \"History\", and \"Test Sets\" modes if so desired. Each of these views is described below.
"},{"location":"Spira-User-Manual/Test-Case-Management/#emailing","title":"Emailing","text":"Read about emailing an artifact to colleagues using Spira.
"},{"location":"Spira-User-Manual/Test-Case-Management/#followers","title":"Followers","text":"Read about how to add and manage followers to an artifact.
"},{"location":"Spira-User-Manual/Test-Case-Management/#workflows","title":"Workflows","text":"Read about using workflows to change the status of your artifact.
"},{"location":"Spira-User-Manual/Test-Case-Management/#overview-details","title":"Overview - Details","text":"The Overview tab is divided into a number of different sections. Each of these can be collapsed or expanded by clicking on the title of that section. This tab displays the fields, detailed information, and comments associated with the test case.
The top part of this tab displays the various standard fields and custom properties associated with the test case. Fields (both standard and custom) are grouped under the collapsible headings (marked by orange text and underline) in the screenshot below. For instance, all fields regarding dates are grouped together in the \"Dates and Times\" area.
The Detailed Information section contains the long, formatted description of the test case, as well as any rich text custom fields. You can enter rich text or paste in from a word processing program or web page. Clicking on the shaded areas of one of these detailed fields will display the rich text toolbar.
The Suspect flag is automatically set on an approved test case, when one of the requirements linking to it changes1. This lets you quickly find all the test cases impacted by a specific requirement change. For this to happen the requirement needs to be in an Accepted or later status (i.e. not Rejected, Rejected, Under Review, Obsolete) and the test case needs to be an approved status (i.e. not Draft, Obsolete, Rejected).
"},{"location":"Spira-User-Manual/Test-Case-Management/#overview-test-steps","title":"Overview - Test Steps","text":"This view displays the name of the test case together with all the defined test steps that a tester would need to perform to verify that the functionality works as expected. The list of test steps displays the position number, the description, the expected result, some suggested sample data and the most recent execution status of the individual test step:
Note: Test steps that are marked with a hyperlink and test case icon (e.g. \"Call Login to Application\" in the screen shot above) are in fact linked test cases. Linked test cases are a useful way of reusing existing test steps from other test cases. For example if you want to have a set of steps be in more than one test case (e.g. a login step) then you would create a separate test case just containing these steps, then have all the other test cases just link to it. This avoids the need to have duplicate test steps throughout the product.
If you click on the step number hyperlink (e.g. Step 2) you will be taken to the test step details page which allows you to perform additional editing of a specific test step as well as attach documents, associate pre-existing incidents and view the change history.
"},{"location":"Spira-User-Manual/Test-Case-Management/#insert-step","title":"Insert Step","text":"Clicking on the \"Insert Step\" button inserts a new test step before the currently selected (by means of the check-box) test step. Clicking the \"Insert Step\" button without selecting a test step will insert a new step at the end of the list. When a new step is inserted, the fields are displayed in \"Edit\" mode, so the description, expected result and sample data fields are editable, allowing you to enter the data:
Once you have entered the necessary information, you can click either \"Save and New\" to commit the changes. If you choose \"Save and New\" another new row will be inserted which is useful if you intend on entering lots of rows at once, whereas clicking \"Save\" will commit only the current row.
"},{"location":"Spira-User-Manual/Test-Case-Management/#insert-link","title":"Insert Link","text":"Clicking on the \"Insert Link\" button brings up the following dialog box that allows you to either choose an existing test case to be inserted or create a new test case and step with parameters:
When linking an existing test case, first select its parent folder from the dropdown. Then select the name of the test case you want to insert as a link from the list. If the test case has declared parameters you will see a list of parameters to fill out.
If it makes sense for your tests you can fill out the parameter values and then click \"Add\". The system will insert the test case as a link. These paramter values are passed down to the linked test at execution. These values override any default parameter values set on the test case. If a test step was already selected the link is inserted above that test step, otherwise the link is added at the end of the test step list.
If you want to create a test step with specific parameters and parameter values, you can do so by clicking the \"Create New Test Case\". This will change the dialog to one where you can assign a folder, name, and parameters to a new test case. On clicking the \"Add\" button: the new test case is created; a test step is created within that new test case; the parameters specified in the dialog are assigned to that test step, with the values set as the defaults for the step; and the new test case is added as a linked test case in the list of test steps.
"},{"location":"Spira-User-Manual/Test-Case-Management/#delete_1","title":"Delete","text":"Clicking on the \"Delete\" button deletes the currently selected test steps, and reorders the test step position numbers to close any gaps in numbering.
"},{"location":"Spira-User-Manual/Test-Case-Management/#clone","title":"Clone","text":"Clicking on the \"Clone\" button makes a duplicate of the current test step or linked test case and inserts the copied version directly above the original one.
When cloning the test step note that:
Click the \"Import\" button to import all the test steps of another test case. When you click the button a popup will let you choose a single test case to import steps from. Only users who can modify the current test case and who can create test steps can use this functionality.
"},{"location":"Spira-User-Manual/Test-Case-Management/#refresh_1","title":"Refresh","text":"Clicking on the \"Refresh\" button simply reloads the list of test steps. This is useful if other people are making changes to the test list and you want to make sure that you have the most current version.
"},{"location":"Spira-User-Manual/Test-Case-Management/#show-hide-columns_1","title":"Show / Hide Columns","text":"By default the test step list screen will display the Description, Expected Result and Sample Data fields. However the Expected Result and Sample Data fields are optional and can be hidden if necessary to make more space. If you have configured custom properties for test steps, you can use the Show/Hide features to display one or more of your custom properties instead. These fields will then be editable in this grid-view.
"},{"location":"Spira-User-Manual/Test-Case-Management/#editing-test-steps","title":"Editing Test Steps","text":"To modify an existing Test Step you simply need to click on the \"Edit\" button to the right of the step, or just double-click on the cells in the row. That will switch the selected row into Edit mode. The various columns are turned into editable text-boxes, and \"Save\" and \"Cancel\" buttons are displayed in the last column:
If you click \"Edit\" on more than one row, the \"Save\" buttons are only displayed on the first row, and you can make changes to all the editable rows and then save the changes by clicking the one \"Save\" button. Also, if you want to make the same change to multiple rows, you can click on the \"fill\" icon to the right of the editable item, which will propagate the new value to all editable items in the same column. When you have made your changes, you can either click \"Save\" to commit the changes, or \"Cancel\" to revert back to the original information.
"},{"location":"Spira-User-Manual/Test-Case-Management/#editing-test-links","title":"Editing Test Links","text":"To modify an existing Test Link you simply need to click on the \"Edit\" button to the right of the step, or double click on the cells in the row. This will open up the special dialog box used for editing the parameter values to pass into the specific linked test case:
This allows you to edit the parameters being passed from the current test step to the linked test case without having to recreate the test link from scratch. To commit the change click \"Save\" to close the dialog box, or click \"Cancel\" to revert back to the original information.
"},{"location":"Spira-User-Manual/Test-Case-Management/#moving-test-steps","title":"Moving Test Steps","text":"To move test steps in the list, click on the row you want to move and drag it where you want it moved to within the list of test steps. An empty space will appear to show you where it will be inserted.
"},{"location":"Spira-User-Manual/Test-Case-Management/#parameters","title":"Parameters","text":"Test cases can have parameters associated with them. This lets a single test case get called multiple times by another test case (as a link) and have different parameters passed in each case, making the operation different.
Parameter Example
You have a test case \"login to application\". This test case has 2 parameters: username; and password. It has default values for these parameters of \"user\" and \"correct-password\". We set the Sample Data field to read: \"Username = ${username}, and password = ${password}\". You can reuse this test case in other test cases by linking links.
Hopefully, the above example begins to show you the flexibility of parameters. You can add the same test case as a linked step multiple times and pass down / override different values each time - useful for testing different logins. You can link test cases together in more complex ways - with test cases nested inside each other.
With complex test case / link structures, you can still pass down parameter values. Building on the above example, let's add the test case \"Can login successfully\" to a new, third, test case called \"Can login and logout successfully\". We now have 3 test cases in a chain. When we add \"Can login successfully\" as a link we can only edit one of the original parameters: only \"password\". We are not able to edit \"username\". This is because when you override a parameter value in a link once, you cannot override from higher up in the chain.
In other words, during execution, parameter values are set by the linked step's defaults if no parent test case overrides them; and by the test case parent closest to the originating linked step that sets an overriding value for a parameter.
To view / change the parameters associated with the current test case, click on the \"Edit Parameters\" button in the toolbar to see and edit the list of current parameters for this test case:
Existing parameters are shown in a list. For each parameter you can:
insert the parameter token at the current cursor position. To do this:
To add a new parameter to the test case, use the form at the bottom of the popup dialog. Set the token name and (optionally) a default value then click \"Add\", and then \"Save\".
"},{"location":"Spira-User-Manual/Test-Case-Management/#overview-automation","title":"Overview - Automation","text":"The Automation section displays the automated test script associated with the test case. To activate this section, choose an Automation Engine from the dropdown in the section. Automation can only run if it has an engine that it will run on - the application / framework that will actually run the script (e.g. Rapise). You can set up automation engines in system administration.
There are three types of automated test:
The screenshot below illustrates a sample Rapise automated test script attached to a test case:
The automation screen includes the following fields that you should populate when using SpiraPlan\u00ae to store an automated test script:
Read about how the comments works
"},{"location":"Spira-User-Manual/Test-Case-Management/#requirements-coverage","title":"Requirements Coverage","text":"This tab displays the requirements coverage information for the test case in question:
The table shows the requirements, if any, mapped to this test case. Clicking on the hyperlinked names will jump you to the details screen for the item in question.
To map the test case to an additional requirement, click the \"Add\" button to display the add association panel. You can search by the ID (if known) prefixed with the appropriate token (e.g. \"RQ:4\" to search for requirement 4). You can also browse by parent requirement, or search by name. Select the requirements you want and then click the \"Save\" button\". This will add the selected requirement(s) only (and not their children if they are parent requirements). This will also add any releases assigned to the requirement(s) not already linked to the test case.
From the same add association panel there is a shortcut to \"Create Requirement from This Test Case\". This button will create a new requirement in the list of covered requirements that will be automatically linked to this test case. This is useful when you have created a new test case and want to generate an initial placeholder requirement to be fleshed-out later.
Finally, to remove coverage for this test case, select any of the added requirements (those in the bottom table) and click the \"Remove\" button. Note that this will remove the requirements and does not change the release coverage of the test case.
"},{"location":"Spira-User-Manual/Test-Case-Management/#test-runs","title":"Test Runs","text":"This view displays the name of the test case together with a list of the previous execution runs that the test case has been put through. Each test run is listed together with the date of execution, the name of the test case, the name of the test set (if applicable), the name of the tester, the release/version of the system that the test was executed against, the overall execution status for the test case in that run and a link to the actual test run details. In addition, you can choose to display any of the custom properties associated with the test run.
The \"show/hide columns\" drop-down list allows you to change the fields that are displayed in the test run list as columns. To show a column that is not already displayed, simply select that column from the list of \"Show...\" column names and to hide an existing column, simply select that column from the list of \"Hide...\" column names. The displayed columns can be any standard field or custom property.
You can also filter the results by choosing items from the filter options displayed in the sub-header row of each field and clicking the \"Filter\" button. In addition, you can quickly sort the list by clicking on one of the directional arrow icons displayed in the header row of the appropriate field.
"},{"location":"Spira-User-Manual/Test-Case-Management/#releases","title":"Releases","text":"This tab displays the name of the test case together with the release mapping information for the test case in question. It functions in a similar way to the Requirements Coverage tab described above: the table at the bottom of the panel shows the releases, if any, mapped to this test case. Clicking on the hyperlinked names will jump you to the details screen for the item in question. You can search for and add releases to this list using the \"Add\" button, or remove them using the \"Remove\" button. Adding the release(s) will only add the release(s) selected (and not their children, if any). However, when adding a sprint, the sprint's immediate parent release (if it has one) is also added.
"},{"location":"Spira-User-Manual/Test-Case-Management/#incidents","title":"Incidents","text":"This tab displays the list of incidents associated with the current test case. The incidents have either been created during an execution of the test case (and are thereby linked to one of the test runs and their steps) or manually linked to one of the test steps in the test case from the Incidents tab of the test step details page.
Each incident is listed together with (by default) the type, status, priority, name, owner, detector, detection date and a link to the actual incident details. On this tab you can perform the following actions:
In this tab, the main pane displays the list of documents that have been \"attached\" to the test case. The documents can be in any format, though SpiraPlan\u00ae will only display an icon for certain known types.
The attachment list includes the filename that was originally uploaded together with the file-size (in KB), name of the person who attached it and the date uploaded. In addition, if you position the pointer over the filename and hold it there for a few seconds, a detailed description is displayed as a tooltip.
To actually view the document, simply click on the filename hyperlink and a new web browser window will open. Depending on the type of file, this window will either display the document or prompt you for a place to save it on your local computer. To delete an existing attachment from a test case, simply click the \"Remove\" button and the attachment will be removed from the list.
To attach a new document to the test case, you need to first click the \"Add New\" link to display the new attachment dialog box:
There are three different types of item that can be attached to a test case:
To upload a file, choose \"File\" as the type and then click the Browse button and select the file from your local computer, optionally enter a detailed description then click the \"Upload\" button. The document will be copied from your computer and attached to the artifact.
To attach a web-link (URL) to the artifact, you need to choose \"URL\" as the type and then enter the fully qualified URL (e.g. http://mywebsite.com?Document=1), an optional description and then click the \"Upload\" button to attach the web-link.
To attach a screenshot to the artifact, you need to choose \"Screenshot\" as the type and then copy the image to your computer's clipboard (e.g. on Windows computers, the PRINT SCREEN button captures the current page and adds to the clipboard). Once the image is in the clipboard, paste it into the editor using CTRL+V (or the equivalent keystroke for your operating system) and the item will appear in the preview window. You can then fill in the other fields and click \"Upload\" to attach the image.
Note: If you are using a non-Windows\u00ae computer (e.g. Macintosh\u00ae) that doesn't put file extensions on filenames (e.g. .xls for an Excel sheet) automatically, then you will need to manually add the file extension to the filename before uploading if you want it to be displayed with the correct icon in the attachment list.
You can also associate an existing document (that's already stored in SpiraTeam) with the test case. To do that, click on the \"Add Existing\" button to bring up the add file association dialog box:
You can then choose to either associate a document stored in the SpiraPlan Documents repository or (in the case of SpiraPlan/SpiraTeam but not SpiraTest) from the linked source code repository. In either case you first select the appropriate folder, and then pick the document(s) from the file list on the right. In the case of a source code file association you can also add a comment.
"},{"location":"Spira-User-Manual/Test-Case-Management/#history","title":"History","text":"In this tab, the main pane displays the list of changes that have been performed on the test case artifact since its creation. An example test case change history is depicted below:
The change history displays the date that each change was made, together with the fields that were changed, the old and new values and the person who made the change. This allows a complete audit trail to be maintained of all changes in the system. In addition, if you are logged in as a product administrator you can also click on the \"Admin View\" button to navigate to where you can revert any unwanted changes.
"},{"location":"Spira-User-Manual/Test-Case-Management/#test-sets","title":"Test Sets","text":"In this tab, the main pane displays the test sets that contain the current test case. Each test set is listed together with its name, release, the date of last execution, the owner, the status, the execution status, and a link to the actual test set details. In addition, you can choose to display any of the custom properties associated with the test set.
The \"show/hide columns\" drop-down list allows you to change the fields that are displayed in the test set list as columns. To show a column that is not already displayed, simply select that column from the list of \"Show...\" column names and to hide an existing column, simply select that column from the list of \"Hide...\" column names. The displayed columns can be any standard field or custom property.
You can also filter the results by choosing items from the filter options displayed in the sub-header row of each field and clicking the \"Filter\" button. In addition, you can quickly sort the list by clicking on one of the directional arrow icons displayed in the header row of the appropriate field.
"},{"location":"Spira-User-Manual/Test-Case-Management/#associations","title":"Associations","text":"You can associate tasks and risks to a test case from this tab (which is only available to SpiraTeam and SpiraPlan users). Apart from creating links to an existing task from this tab, any tasks created during exploratory test execution will also be shown here.
Read more about how to manage and add associations to this artifact
"},{"location":"Spira-User-Manual/Test-Case-Management/#test-step-details","title":"Test Step Details","text":"When you click on one of the hyperlinks next to a test step in the test step list (see above), you will be taken to the test step details screen illustrated below:
This page is made up of three areas; the left pane is the navigation window, the upper part of the right pane contains the test step detailed information itself, and the bottom part of the right pane contains related information about the test step.
The navigation pane consists of a link that will take you back to the test step list, as well as a list of the peer test steps to the one selected. This latter list is useful as a navigation shortcut; you can quickly view the detailed information of all the peer test steps by clicking on the navigation links without having to first return to the test step list page. You can also switch between seeing the list of test steps with the current filter applier or simply unfiltered.
The top part of the right pane allows you to view and/or edit the details of the particular test step. You can edit the various fields (description, expected result and sample data) and custom properties. Once you are satisfied with them, click any \"Save\" button on the page to commit the changes.
If you can create test steps and want to add a new test step to the test case:
The lower part of the right pane can be switched between four different views by clicking the appropriate tab. Initially the pane will be on \"Incidents\" tab, but it can be switched to \"Attachments\", \"History\" or \"Requirements\" tabs if so desired. Each of the views is described separately below.
"},{"location":"Spira-User-Manual/Test-Case-Management/#incidents_1","title":"Incidents","text":"In this mode, the main pane displays a list of any incidents that are associated with this test step. They can either be linked indirectly due to being logged during a test run, or directly linked after the fact:
Each incident is listed together with the type, status, priority, name, owner, detector, detection date and a link to the actual incident details. You can customize the fields that are displayed using the \"Show/Hide Columns\" option. In addition, you can perform the following operations:
Refresh -- updates the list of incidents from the server, useful if other people are adding incidents to this release at the same time.
You can also filter the results by choosing items from the filter options displayed in the sub-header row of each field and clicking the \"Filter\" button. In addition, you can quickly sort the list by clicking on one of the directional arrow icons displayed in the header row of the appropriate field.
Edit -- Clicking the \"Edit\" button to the right of the incident allows you to edit the incident inline directly on this screen.
To create a new association between this test step and an existing incident, click the \"Link Incident\" button which will display the following panel:
You need to choose the specific incident(s) you want to link to, either by choosing the item from the scrolling selection box, or searching for them by name or ID. Before adding the chosen incidents you can add a comment that explains the rationale for the association.
"},{"location":"Spira-User-Manual/Test-Case-Management/#attachments_1","title":"Attachments","text":"Read about how the attachments tab works
"},{"location":"Spira-User-Manual/Test-Case-Management/#history_1","title":"History","text":"Read about how the history tab works
"},{"location":"Spira-User-Manual/Test-Case-Management/#requirements","title":"Requirements","text":"Normally within SpiraTest, you will link the test cases in a product with your requirements to describe which requirements are covered by each of the test cases. When all of the tests for a requirement pass, the requirement is considered fully tested.
However, in some industries (for example when developing Defense systems) there is an additional requirement to report on the traceability between the individual test steps and the requirements. For customers that have such a requirement, this tab lets you associate the current test step with specific requirements.
The tab displays a grid containing the requirements already mapped to this test step. You can filter that list by the requirement type, name, status, importance, product name and ID. You can remove an existing requirement by selecting its check box and clicking the 'Delete' button. This doesn't delete the requirement, just removes it from the test step.
Hovering the mouse over the names of the requirements will display a \"tooltip\" consisting of the requirement name, place in the hierarchy and a detailed description.
To add a new test case to the requirement, click the 'Add' button:
You can search for a requirement by its ID if you know it (make sure to include the \"RQ\" prefix):
Otherwise, you can search for the requirements by choosing a parent requirement from the dropdown and/or entering a partial name match:
One you have found the desired requirement(s), simply select their check boxes and click the 'Save' button to add them to the current test step:
"},{"location":"Spira-User-Manual/Test-Case-Management/#execute-test-cases","title":"Execute Test Case(s)","text":""},{"location":"Spira-User-Manual/Test-Case-Management/#test-run-list","title":"Test Run List","text":""},{"location":"Spira-User-Manual/Test-Case-Management/#test-run-details","title":"Test Run Details","text":""},{"location":"Spira-User-Manual/Test-Case-Management/#test-set-list","title":"Test Set List","text":""},{"location":"Spira-User-Manual/Test-Case-Management/#test-set-details","title":"Test Set Details","text":""},{"location":"Spira-User-Manual/Test-Case-Management/#automation-host-list","title":"Automation Host List","text":""},{"location":"Spira-User-Manual/Test-Case-Management/#automation-host-list_1","title":"Automation Host List","text":""},{"location":"Spira-User-Manual/Test-Case-Management/#test-configuration-list","title":"Test Configuration List","text":""},{"location":"Spira-User-Manual/Test-Case-Management/#test-configuration-details","title":"Test Configuration Details","text":"only certain changes to a requirement will trigger the suspect flag. These are any change to standard field only. Changes to comments, assocations, attachments, use case steps, and custom properties will not trigger the suspect flag.\u00a0\u21a9
when navigating to folders (for all artifacts that support them), the URL in your browser's address bar will change. Each folder has a unique, sharable URL that you can give to someone to display the list of artifacts with the appropriate folder selected. You can also open up multiple folders in different browser tabs and easily toggle between them from the same browser.\u00a0\u21a9
This section outlines how to use the Test Configuration features of SpiraPlan\u00ae to create and manage different configurations of parameters that tests (both manual and automated) can be run against. This offers tools to quickly create every combination of different parameters.
When you click on the Testing > Test Configuration global navigation link, you will initially be taken to the test configuration list screen illustrated below:
The test configuration list screen displays all the test configurations for the current product, in a filterable, sortable grid. The grid displays the name, creation date, last updated date, ID, and whether the test configuration is active.
In addition, you can view a more detailed description of the test configuration by positioning the mouse pointer over the host name hyperlink and waiting for the popup \"tooltip\" to appear. If you click on the host name hyperlink, you will be taken to the test configuration details page. Clicking on any of the pagination links at the bottom of the page will advance you to the next set of hosts in the list according to the applied filter and sort-order. There is also a drop-down-list at the bottom of the page which allows you to specify how many rows should be displayed in each page, helping accommodate different user preferences.
"},{"location":"Spira-User-Manual/Test-Configuration-Management/#filtering-sorting","title":"Filtering & Sorting","text":"Read about how to create and manage filters, and how to sort the artifact list.
"},{"location":"Spira-User-Manual/Test-Configuration-Management/#new-test-configuration","title":"New Test Configuration","text":"Clicking on the \"New Configuration\" button adds a new test configuration to the bottom of the list with a default name.
"},{"location":"Spira-User-Manual/Test-Configuration-Management/#delete","title":"Delete","text":"Clicking on the \"Delete\" button deletes the test configurations whose check-boxes have been selected in the host list.
"},{"location":"Spira-User-Manual/Test-Configuration-Management/#refresh","title":"Refresh","text":"Clicking on the \"Refresh\" button reloads the list of test configurations; this is useful when new configurations are being added by other users, and you want to make sure you have the most up-to-date list displayed.
"},{"location":"Spira-User-Manual/Test-Configuration-Management/#edit","title":"Edit","text":"Each test configuration in the list has an \"Edit\" button in its right-most column. When you click this button or just double-click on any of the cells in the row, you change the item from \"View\" mode to \"Edit\" mode. The various columns are made editable, and \"Save\" buttons are displayed in the last column.
If you click \"Edit\" on more than one row, the \"Save\" buttons are only displayed on the first row, and you can make changes to all the editable rows and then update the changes by clicking the one \"Save\" button. Also, if you want to make the same change to multiple rows (e.g. to change five test configurations from Active = No to Active = Yes), you can click on the \"fill\" icon to the right of the editable item, which will propagate the new value to all editable items in the same column.
If you want to edit lots of items, first select their checkboxes and then click the \"Edit\" button on the same row as the Filters and it will switch all the selected items into edit mode.
When you have made your updates, you can either click \"Save\"to commit the changes, or \"Cancel\" to revert back to the original information. Alternatively, pressing the <ENTER> key will commit the changes and pressing the <ESCAPE> key will cancel the changes.
"},{"location":"Spira-User-Manual/Test-Configuration-Management/#test-configuration-details","title":"Test Configuration Details","text":"When you click on a test configuration entry in the list, you are taken to the test configuration details page illustrated below:
This page is made up of three areas; the left pane is the navigation window, the upper part of the right pane contains the test configuration name and ID, and the bottom part of the right pane displays different information associated with the test configuration.
The navigation pane consists of a link that will take you back to the test configuration list, as well as a list of the peer test configurations to the one selected. This latter list is useful as a navigation shortcut; you can quickly view the peer configurations by clicking on the navigation links without having to first return to the list page. The navigation list can be switched between two different modes:
The list of configurations matching the current filter
The list of all configurations, irrespective of the current filter
The right pane allows you to view and/or edit the details of the particular test configuration. You can edit the various fields (name, description, etc.) and custom properties. Once you are satisfied with the changes, click either the \"Save\" button or the alternative options from the \"Save\" dropdown list. In addition you can delete the current automation host by clicking \"Delete\", or discard any changes made by clicking \"Refresh\".
"},{"location":"Spira-User-Manual/Test-Configuration-Management/#overview","title":"Overview","text":"This tab shows the fields and description associated with the test configuration. Standard and custom fields are grouped by type (eg all date and time fields are grouped together).
"},{"location":"Spira-User-Manual/Test-Configuration-Management/#overview-test-configuration-entries","title":"Overview -- Test Configuration Entries","text":"This section shows the list of all entries from this test configuration, and that would be used by a test set to populate parameters. Each row represents a single unique combination of the parameters (shown on the header row of the table).
Entries can be reordered by dragging and drop one row or more. Individual entries can also be removed by checking the checkbox for that entry and then clicking \"Remove\" button.
To create new entries, first click the \"Populate\" button. This will display the following panel:
You must select a parameter from the left dropdown (which contains a list of all parameters defined in test cases in the current product), and a custom list with which to populate the parameter. Then click the \"Add\" button. For instance, the screenshot below would create a configuration using every operating system defined by the custom list \"Operating System\" and assigning these to the parameter called \"operatingSystem.\"
Note: Custom lists are usually used in SpiraPlan for custom fields on various artifacts. However, you can create custom lists that are solely for the purpose of test configurations, should you so wish -- for instance, to contain a list of usernames.
Once you are happy with the lists and parameters selected, click the \"Populate\" button. This will overwrite all existing entries in this test configuration. It will create every combination based on the lists specified. So if you select two parameters, each with a list that has ten items, one hundred entries will be created in the test configuration.
"},{"location":"Spira-User-Manual/Test-Configuration-Management/#test-sets","title":"Test Sets","text":"This tab displays the list of all the test sets that are using the test configuration. Each test set is listed together with its name, release, the date of last execution, the owner, the status, the execution status, and a link to the actual test set details. In addition, you can choose to display any of the custom properties associated with the test set.
The \"Show/hide columns\" drop-down list allows you to change the fields that are displayed in the test set list as columns. To show a column that is not already displayed, simply select that column from the list of \"Show...\" column names and to hide an existing column, simply select that column from the list of \"Hide...\" column names. The displayed columns can be any standard field or custom property.
You can also filter the results by choosing items from the filter options displayed in the sub-header row of each field and clicking the \"Filter\" button. In addition, you can quickly sort the list by clicking on one of the directional arrow icons displayed in the header row of the appropriate field.
"},{"location":"Spira-User-Manual/Test-Execution/","title":"Execution of Test Case(s)","text":""},{"location":"Spira-User-Manual/Test-Execution/#introduction","title":"Introduction","text":"Customizing Test Execution
There are a number of ways that a product admin can tailor or customize test execution. Certain features can be disabled / enabled via the testing settings page. The below describes using test execution with default settings and flags the key places where customizing these settings can change testers' experiences.
This section describes how a tester can follow the steps defined for a series of test cases and record what actually happened in the process. In addition, recorded failures of test cases can be used to automatically generate new incidents that will be added to the incident tracking module and, optionally, to tasks.
You start test case execution in SpiraPlan by either:
If you execute a test set then the values of the selected release and custom list properties for the test run are automatically populated from the test set, whereas if you directly execute a test case itself, those values can be chosen by the tester.
If you attempt to execute a single test case that you are in the middle of testing (from either a test case, group of test cases, or a test set) a popup will ask if you want to resume one of those existing, not-yet-completed pending test runs, or start a new test run. The popup will show the five most recent relevant pending test runs with their dates and names.
Regardless of the route taken to launch the test execution module, the first screen that will be displayed will look like the following:
Before actually executing the test scripts, you need to select the release (if not already set) and optionally the specific build of the system that you will be testing against. You can also specify any test run custom properties that have been defined by the product owner. This ensures that the resulting test runs and incidents are associated with the correct release of the system, and that the test runs are mapped to the appropriate custom properties (e.g. operating system, platform, browser, etc.).
If you have not configured any releases for the product, then the release drop-down list will be disabled and the test runs/incidents will not be associated with any particular release. If the test run was launched from a test set, the release and any list custom properties will be pre-populated from the test set itself and will not be changeable on this screen (unless they weren't set by the test set).
Once you have chosen the appropriate release name and/or custom properties, click the \"Next\" button to begin executing test steps. By default you will see the default test execution module, shown below.
There is a second test execution view: the exploratory test execution module. This has much in common with standard test execution but differs in a number of important ways. You will automatically see this module if the following three conditions are met;
The screen is divided up into three main areas (each is explained in more detail in the sections below):
The header area at the top of the page, which displays the name (if any) of the test run, along with the selected release. This section also contains buttons to control how the \"test execution area\" looks and functions for the tester.
The Progress Bar, which shows a summary graphical view of the whole test run. The progress bar also has a number of navigation buttons to help you move around the test run, or to leave the test execution page. Between the buttons are indicator blocks. For test runs with relatively few test steps, each indicator block represents a single test step. A tall dotted line is used to indicate the end of one test case and the start of another. When there are many test steps to a test run, each indicator block represents a test case. Hovering over an indicator block will display a tooltip with information about the test step or case represented. The color of the indicator block matches the color of any assigned execution status for the test step or test case (see below).
The rest of the page contains the \"test execution area\". This has details about all of the steps in the test run. It can be used to both navigate between test cases and test steps, as well as to actions on any test case or test step (for instance assigning an execution status or logging an incident). This area can look markedly different depending on which display mode a user has selected. However, in every mode, a tester will be able to readily view the name and description of the test step (and at times the parent test case), along with the description of the test step, instructions for carrying out it, and any expected results. The test can then compare the results with those listed as expected. As described below, depending on how the actual system responds, you will use the buttons and fields on the page to record what actually happened.
Note: on first accessing this screen, the user will be given a guided tour of many of the features of this page. This can be accessed at any time via the options menu (discussed below)
"},{"location":"Spira-User-Manual/Test-Execution/#display-modes","title":"Display Modes","text":"The display mode toolbar is at the top right of the test execution screen. There are three different display modes. Each display mode has two sub-modes, using simple graphical images to indicate what they do (each pair of buttons to change sub-mode becomes visible on activating a particular display mode).
All of these modes affect how the test cases and test steps are displayed in the \"test execution area\". The different views have been designed to suit different ways of testing, depending on how your organization works; or the needs of a tester for a particular test.
There are three parts in the \"test execution area\", which are visible or hidden depending on the view.
There are three main display modes:
Split mode: shows a simplified list of test steps on the left (in the table) and full details about the currently selected test step on the right (in the inspector). The sub modes in the split view either show a narrow table and wide inspector, or a wide table and narrow inspector.
Table mode: in this mode the table takes up the full width of the \"test execution area\", with both the inspector and iframe completely hidden. The list of test cases and steps displays all the information about each---the same information as is shown in the inspector. This view makes it easy to quickly scan through a number of test steps and take quick actions on many steps in sequence. The sub-modes in this view either expand or collapse any fields with more than one line or text in them. This is helpful to give either a very detailed or summary view to the table. Note too that every field that takes up more than one line will have a little expand or collapse button to its left, allowing for control of individual fields as needed.
Mini mode: this mode fills the entire \"test execution area\" with the inspector, or a combination of the inspector and iframe. The table is completely hidden in this mode. The mini mode is designed to help you maximize space for the inspector or to allow you to test a website in the embedded mini browser (in the iframe) right next to a narrow inspector.
"},{"location":"Spira-User-Manual/Test-Execution/#navigating-around-a-test-run","title":"Navigating Around a Test Run","text":"There are several ways to move through the different cases and steps of a particular test run. In the default \"split\" mode you are guided through a test run in order, however at any time, in any display mode, you can easily and quickly move steps. Note that if you click on a test case, the first test step in that test case will be selected as well.
Using the progress bar buttons: the left-hand side of the progress bar has three buttons: backward, forward, and play/pause (the last of these is discussed in more detail below). Clicking on the backward or forward buttons will move to the previous or next progress bar indicator block (and the associated test step or test case).
Using the progress bar indicator blocks: clicking on any indicator block will immediately focus the test execution area on that test step or test case.
Using the table: when the table view is visible (in either split mode or table mode) clicking on any item will immediately focus the test execution area on that test step or test case.
Progressing through steps using the inspector: when the inspector is visible (in split or mini display mode), on properly setting a status for a test step (see Viewing and Recording Execution Details for further details), the next test step is automatically loaded into the inspector. If you were on step 3 of 5, you would be moved to step 4. If you were on the last step of a test case, you will be moved to the next test case, if one is available.
Pause/Play button: the time spent on every test step is recorded, by default, during test execution. This allows an accurate assessment of exactly how long a test run took to complete and these timing details are saved with the test run and its results. If you wish to pause the behind-the-scenes timer (for instance if taking a break) click the pause/play button. To resume the time click it again.
The currently selected progress bar indicator block will be outlined with a peach border. The currently selected test case and test step on the table view will be indicated with a peach bar along their left edge, and will also be highlighted in a light peach.
"},{"location":"Spira-User-Manual/Test-Execution/#viewing-and-recording-execution-details","title":"Viewing and Recording Execution Details","text":"There is a small icon to the left of each test step title and test case title. For test steps this is a circle, for test cases a square note. Once a status has been recorded for a test step (or once a test case has been assigned a status based on the statuses of its test steps) these icons will be filled with a visual indicator of its current status. The icons both become colored and are given a small symbol, based on the status. In the inspector view the associated button to that status has a gray bar beneath it.
The same colors and symbols used to show a status are used on the buttons to record a status. The colors and symbols used are: green / tick = \"Passed\"; yellow / stop sign = \"Blocked\"; orange / warning triangle = \"Caution\", red / cross = \"Failed\", gray / dash = \"Not Run\".
Depending on the display mode and device, the buttons may show the text name of the status along with the symbol (see examples below---the top button set is that on the inspector, the bottom from the table (when the display mode is set to table).
NOTE: by default all of the above buttons are visible during testing. However, a product admin can remove any or all of the \"Caution\", \"Blocked\", or \"N/A\" buttons on the testing settings page.
The various statuses when recorded against test steps will appear as below, respectively:
You will notice that softer shades are used above compared to the buttons. Similarly soft shades are also used on the progress bar indicator blocks, as shown below.
The status of a test case is determined by its test steps. If any of the steps are marked as \"Caution\", \"Blocked\", or \"Fail\" then the overall test case is marked with the most severe status of those statuses applied to any of the test steps from \"Caution\", to \"Blocked\", to \"Fail\" (e.g. if one is marked as \"Caution, the test case will be marked \"Caution\"; but if one is marked as \"Caution\", and another \"Blocked\", the case will be marked \"Blocked). If all the test steps passed, or if steps are marked either passed or \"N/A\", then the overall test case is marked as \"Passed\"; any other case results in the test case being marked as \"Not Run\".
If the expected results are indeed observed, then you simply need to click the \"Pass\" button to mark the test step as passed, and advance to the next test step, or if all the steps have passed, you can click \"Pass All\" to pass all the steps at once (this ability can be disabled by product admins in testing settings).
On the inspector, the \"Pass All\" button is visible via a dropdown to the right of the \"Pass\" button whenever the parent test case information is also displayed with the test step (typically only for the first step in a test case). This is illustrated in the screen shot below:
When in the table display mode, the \"Pass All\" button is shown on the right-hand side of the test case row, as illustrated below:
Below the main pane there are two optional sections. The first one allows you to log an incident in the system associated with the test step. For failures this will typically be used to log a bug relating to the failure. However even if you pass a step you can still log an incident, which may be useful for logging non-critical cosmetic items that are not serious enough for a failure to be recorded. This tab also displays any pre-existing incidents that were associated with the test step being viewed.
The second tab displays a list of attachments that are related to the current test case and/or test step. This list initially contains any documents that have been attached to either the test case in general or the test step in particular. However as you perform the testing, you can attach additional documents to this list that are relevant to the test results (e.g. screenshots of an error page); these attached documents will be associated with both the test run itself and any incidents that are created.
Once all the test steps have passed, you will be automatically be taken to the first step in the next test; if it is the last test case being executed, the <Finish> button will be displayed instead.
If the actual results differ from those expected, you need to enter a description of the actual result observed and click one of Fail, Caution, or Blocked buttons (if enabled). If you don't enter anything into the actual result description box, the system will display an error message and re-prompt you again for input. By default, you will not see this prompt for passing a step, however product admins can force testers to enter an actual result when passing a step on the testing settings page.
In the inspector, the actual results text box is shown in the first tab below the information provided to the tester for a test step, as illustrated below:
In the table display mode, previously entered actual results are always visible (below the information provided to the tester for a test step). On attempting to mark a step as anything other than \"Pass\" the actual results text box will automatically be displayed.
You can also choose to manually show the actual results text box by selecting \"Actual Result\" option from the \"+\" dropdown menu.
"},{"location":"Spira-User-Manual/Test-Execution/#saving-screenshots-to-a-test-step","title":"Saving Screenshots to a Test Step","text":"Often, testers will want to provide visual documentation of what they have found during the testing process. A screenshot of what they are testing is a great way to do this. To add a screenshot to the results of a test step, first copy your screenshot to the clipboard. Next, paste the screenshot into the actual results text box.
"},{"location":"Spira-User-Manual/Test-Execution/#recording-extra-information","title":"Recording Extra Information","text":""},{"location":"Spira-User-Manual/Test-Execution/#incidents","title":"Incidents","text":"In addition to logging the result of a test step, you can optionally choose to generate a new incident at the point of logging the execution status of a test step. When the incident form is visible (see below) enter a name, select a type and fill in any other required fields. The description for the new incident is automatically populated from the test step details. To add the new incident either click the Add button at the bottom of the incident form, or clicking an execution status button for that test step.
The newly created incident will also be linked to the test step, allowing traceability from within the incidents module. The functionality for managing incidents is described in more detail in Incident Tracking.
If the inspector is visible, go to the \"Incidents\" tab. This will show any already linked incidents, show a detailed form for creating a new incident.
You can instead link the test step to an existing incident (by clicking the \"Link Existing Incident\" button). The following popup will be displayed, where you can either enter an incident ID (if known), or choose one from the list.
When in the table display mode, open the \"+\" dropdown menu to show options to either add a new incident or link an existing incident. Click on the option required to display the appropriate popup. Note that on clicking Add the incident will be immediately linked to the selected test step.
NOTE: via testing settings the product admin can require every test step to have an incident linked to it. If this setting has been enabled and the test step does NOT have an incident already AND you are not passing the step, in order to move to the next step you will need to create a new incident or link to an existing one.
"},{"location":"Spira-User-Manual/Test-Execution/#attachments","title":"Attachments","text":"If you need to attach documents to the test run (in addition to any screenshots), you can either attach a new or link an existing document. From the inspector, go to the \"Attachments\" tab to see any documents already linked, or to add a document as needed. In the table display mode, select either \"Add New Attachment\" or \"Link Existing Attachment\" from the \"+\" dropdown menu. See Attachments for additional information about how to the different available options (e.g. either upload a document, url link, or screenshot, or to link a document or from source code).
"},{"location":"Spira-User-Manual/Test-Execution/#tasks","title":"Tasks","text":"By default you will not see a Task tab during test execution. But a \"Tasks\" tab will be visible if:
The task tab allows the tester to quickly create tasks based on the current test step. These tasks are attached to the test run as a whole, so any previously entered tasks will be visible even when changing steps. Creating a task is a light touch way of communicating with others about your findings and alerting them that some work is likely required to fix or clarify a feature. It is quicker to enter and manage than an incident.
When creating a task the following fields are available:
Tasks are shown as a list of cards with their left edge showing their priority by color. On creation a task's status will be gray -- showing that no priority has yet been set. The title of the task can be clicked to open the details page for that task.
"},{"location":"Spira-User-Manual/Test-Execution/#leaving-the-test-execution-page","title":"Leaving the Test Execution Page","text":"If you are not able complete the whole test run in a single session, click the \"Leave\" button on the right of the progress bar---shown with an eject symbol (see below). This will return you to the page where you began the execution from. You can resume testing at a later date by locating the test run on your 'My Page' under 'My Pending Test Runs' and choosing to resume testing. Note that the system will remember every result you have logged, along with the last test step you were working so you can pick up right where you left off.
Once either all steps in a test have an execution status recorded, or at least one step in each test case has been recorded with any status other than \"Pass\" the test run can be finished. An orange button at the far right of the progress bar with a stop symbol will appear (see below). Clicking this button will save and archive the entire test run (so it can no longer be amended) and the page will automatically exit the test execution page.
"},{"location":"Spira-User-Manual/Test-Execution/#extra-test-execution-options","title":"Extra Test Execution Options","text":"There are a number of ways that some users may wish to alter the test execution page, depending on how they work. Options to change this are available from the menu button to the right of the display buttons.
The following actions are available from this dropdown menu:
Refresh: this simply reloads the test run data. This is useful if other people are working on different test cases within the same test run and you want to make sure that you have the most current information about the statuses they have recorded.
Always show test case: by default, the inspector only shows the test case details when the first test step of a test case is displayed. Checking this item will mean that the test case details will be shown on every test step.
Show custom properties: by default, only a handful of system fields are shown for the test case and test step. If your organization places important and relevant information into custom fields as well, you can check this item to make them visible in the inspector for every case and step. Note that these fields will not be visible in the table display mode.
Show guided tour: if you missed or want to revisit the visual guided tour of the test execution page, click this button to run the tour again.
"},{"location":"Spira-User-Manual/Test-Execution/#exploratory-test-execution","title":"Exploratory Test Execution","text":"As mentioned above, there are a number of conditions that must be satisfied for a test to run in exploratory mode. Exploratory testing is designed for relatively experienced testers and rather than to record the results of a pre-determined set of steps, to instead adjust and create the testing sequence during the act of testing itself. During exploratory testing test steps can be added, removed, edited, moved freely, at any time.
Care must therefore be taken that this form of testing and of recording the results of a test are used appropriately. The conditions set by the system are one means of limiting its use.
When starting exploratory testing the main screen will resemble the one below. Note that it looks broadly similar to that for standard test execution and is made up of three different areas:
All fields in the right hand details area, or the top part of the page can often be edited. Their contents and associated label will be grayed out if they are read only fields (for instance if they are information from a custom property). To edit a field, click on it, change the text as required, then click out of the field. The information will be automatically saved. Note that any test steps that come from a link test case will be read only and as such their contents cannot be edited, nor can they be deleted.
Just like with normal test execution, you can navigate between steps using the list of steps on the left; and steps can be passed, or failed using the execution status toolbar on the right hand section of the page. The unique actions you can take on test steps (besides editing their fields) are below:
add a step: click on the plus button beneath the list of test steps on the left
clone an existing step: when you hover a test step in the list, you will see a button appear on its right. Click on this to show a mini menu with an option to clone the step. This will create a clone, at the bottom of the list of test steps, with a blank actual result
delete an existing step: if you have more than one test step, any editable test step can be deleted. Click on the button for that step (as explained above) and click delete from the mini menu.
move an existing step: to move an editable step click and drag it to the desired location in the test step list.
Below the main detailed section there are two or three tabs. SpiraTest users will only see two tabs -- incidents and attachements. SpiraPlan users may see the additional tasks tab (if enabled by the product admin).
The toolbar at the top right of the page has a number of buttons:
When you click on the Testing > Test Runs global navigation link, you will be taken to the test run list screen illustrated below:
The test run list screen displays all the individual test executions performed in the current product, in a filterable, sortable grid. The grid displays the test run number together with fields such as execution status, name, assigned tester, execution date, test set, specified release, etc. The choice of columns displayed is configurable per-user, per-product, giving extensive flexibility when it comes to viewing and searching test runs.
In addition, you can view a more detailed description of the test run by hovering over the test run name hyperlink to display a \"tooltip\". If you click on this test run hyperlink, you will be taken to the test run details page described in the next section. Clicking on any of the pagination links at the bottom of the page will advance you to the next set of test runs in the list according to the applied filter and sort-order. There is also a drop-down-list at the bottom of the page which allows you to specify how many rows should be displayed in each page, helping accommodate different user preferences.
The sidebar shows a chart of the last 30 days of test run activity, broken down, for each day, by the test run status. This is a useful chart to quickly track the testing activity of the product -- this is not the same as overall product status. (For info, this chart matches that on the Product Homepage's Test Run Progress widget)
"},{"location":"Spira-User-Manual/Test-Run-Management/#refresh","title":"Refresh","text":"Clicking on the \"Refresh\" button simply reloads the test run list. This is useful as other people may be completing test runs, and after stepping away from the computer for a short-time, you can click this button to make sure you are viewing the most current test run list for the product.
"},{"location":"Spira-User-Manual/Test-Run-Management/#show-hide-columns","title":"Show / Hide Columns","text":"This drop-down list allows you to change the fields that are displayed in the test run list as columns for the current product. To show a column that is not already displayed, simply select that column from the list of \"Show...\" column names and to hide an existing column, simply select that column from the list of \"Hide...\" column names. This is stored on a per-product basis, so you can have different display settings for each product that you are a member of. The fields can be any of the built-in fields or any of the custom properties set up by the product owner.
"},{"location":"Spira-User-Manual/Test-Run-Management/#filtering-sorting","title":"Filtering & Sorting","text":"Read about how to create and manage filters, and how to sort the artifact list.
"},{"location":"Spira-User-Manual/Test-Run-Management/#printing-items","title":"Printing Items","text":"To quickly print a single test run or list of test runs you can select the items' checkboxes and then click the Print icon. This will display a popup window containing a printable version of the selected items.
"},{"location":"Spira-User-Manual/Test-Run-Management/#test-run-details","title":"Test Run Details","text":"When you click on any of the individual test runs in the test run list, you are taken to the Test Run details page (not to be confused with the Test Case details page) shown below:
This page consists of three panes:
The left hand navigation pane displays a list of related test runs with a color indicator for their current execution status. The display dropdown will let you choose whether the list contains test runs that are for the same release, test case or test set, or are just a filtered/unfiltered list based on your last search in the main test run list page.
The top right area shows headline information about the test run details of the test run itself
The main pane on the right displays tabs for detailed information about the test run, and its associations. The overview tab is initially loaded and shows the name, description, release, test set, estimated and actual duration, tester name, test run type, automation host fields, along with others, including custom fields. Underneath this is shown the list of test run steps, and any console output from a test automation engine such as Rapise, NUnit, JUnit, QTP, or Selenium.
There is a button on the main test run toolbar called 'Re-Test\". If you click this button, SpiraPlan will launch the test execution wizard for this specific test case, with current release and/or test set already selected for you. This is a handy way of quickly re-running a failed test that has been addressed by the developers. NOTE: this button will not display if the product does not allow you to execute test cases (instead only letting you execute test sets).
"},{"location":"Spira-User-Manual/Test-Run-Management/#editing-a-test-run","title":"Editing a Test Run","text":"When reviewing the test run, you may find that you need to change the results of the test run (e.g. the user selected the wrong release or custom property value). Many of the fields are editable at a later date, and to make changes, just modify the appropriate fields and click any \"Save\" button.
"},{"location":"Spira-User-Manual/Test-Run-Management/#deleting-the-test-run","title":"Deleting the Test Run","text":"If you need to delete a test run that was erroneously captured, all you need to do is click on the link to access the invalid test run and then click the \"Delete\" button to remove it from the system. This will then force the system to update the status of the test case itself from the other logged test runs.
"},{"location":"Spira-User-Manual/Test-Run-Management/#test-run-steps","title":"Test Run Steps","text":"In the case of a manual test run, this section displays all the steps of the test case as they appeared during the test run in question. This means that if the test steps were changed after running the test, the list here will reflect the original information.
Each test run step is displayed along with the description, expected result, suggested sample data, a link back to the current version of the test step in question, the actual result and the execution status for this step in this particular test run. Where an actual result was recorded, an additional \"View Incidents\" button will be displayed. This allows you to view any incidents that are associated with this particular test run step:
Clicking on the link will open up a popup dialog box that displays a list of all the incidents associated with the selected test run step. Each of the incidents listed will reflect the most up-to-date information regarding that incident, including its type, status, priority, name, assigned owner, detection date and who first detected it. Clicking on the incident name will take you to the details page for that incident, which is described in Incident Tracking > Incident Details.
If you have modify all permissions for test runs you will be able to click the small link button at the right of the test run step. This is the \"link existing incident\" button. This will display a popup that lets you link an existing incident to the selected test run step.
"},{"location":"Spira-User-Manual/Test-Run-Management/#console-output","title":"Console Output","text":"In the case of an automated test run, this tab will display the details of the test run as reported from the test runner application. These details will vary depending on the type of automated tool being used, but typically they include the name of the automated test runner, the number of assertions raised, the name of the corresponding test case in the tool, the status of the test run and a detailed error message, and the stack-trace in the case of a failure. An example test run as reported from the NUnit automated test runner is illustrated below:
Details on how to use SpiraPlan\u00ae in conjunction with an automated testing tool are provided in the SpiraPlan\u00ae Automated Testing Integration Guide, which can be downloaded from the Inflectra\u00ae website.
"},{"location":"Spira-User-Manual/Test-Run-Management/#attachments","title":"Attachments","text":"Read about how the attachments tab works
"},{"location":"Spira-User-Manual/Test-Run-Management/#history","title":"History","text":"Read about how the history tab works
"},{"location":"Spira-User-Manual/Test-Run-Management/#incidents","title":"Incidents","text":"This tab displays the list of incidents associated with the current test run. The incidents have either been linked during test execution or can be linked to a test run step from the Overview tab of the test run details page.
Each incident is listed together with (by default) the type, status, priority, name, owner, detector, detection date and a link to the actual incident details. On this tab you can perform the following actions:
This tab is only visible to users of SpiraPlan. It shows the list of tasks associated with the current test run. Tasks can only be added to a test run created from an exploratory test case. These tasks will have been logged during the execution of the test.
"},{"location":"Spira-User-Manual/Test-Set-Management/","title":"Test Set Management","text":""},{"location":"Spira-User-Manual/Test-Set-Management/#test-set-list","title":"Test Set List","text":"As well as being able to organize test cases into folders, you can also create separate groupings of test cases called test sets which can then be assigned to testers as a package. To view the list of test sets for a product, click on Testing > Test Sets in the global navigation:
The test set list consists of hierarchical list of all the test sets in the current product organized into folders. The structure is very similar to the folder structure in Microsoft Windows\u00ae Explorer, and users will find this very familiar and intuitive to use. A folder tree is on the left hand side---with triangle icons to expand / collapse each folder. Contents of the selected folder (the one marked in bold on the folder tree) are shown on the right hand side.1
When you create a new product, this list will initially be empty, and you will have to use the \"New Test Set\" button to start adding test sets to the system.
Each test set is listed along with the number of test cases contained (in parenthesis), the aggregate execution status of the contained test cases (using a graphical bar-chart), the date that the test set has been scheduled to be executed (planned date), the date that it was last executed, the person currently assigned to execute the test set, the status and the test set id. Clicking on a test set's hyperlink will take you to the test set details page for the item in question.
Note: the test set status is separate from the execution status of the individual test cases and represents where the test set is in its lifecycle:
Clicking on the \"Delete\" button deletes the currently selected test sets. It will delete the association between the test set and its contained test cases, but it will not delete the test cases themselves.
"},{"location":"Spira-User-Manual/Test-Set-Management/#refresh","title":"Refresh","text":"Clicking on the \"Refresh\" button simply reloads the list of test sets. This is useful if other people are making changes to the test set list and you want to make sure that you have the most current version.
"},{"location":"Spira-User-Manual/Test-Set-Management/#focus-on","title":"Focus On","text":"The \"Focus On\" button is a useful when you have performed a filter on the list of test sets and then wish to quickly navigate to the folder of a particular test set shown in the list. After selecting a test set, clicking the button will move the left hand folder tree to the folder that contains the selected test set. It will also change the list view on the right to show all of the test sets within that folder (i.e. the selected test set and its siblings).
"},{"location":"Spira-User-Manual/Test-Set-Management/#edit","title":"Edit","text":"Each test set in the list has an \"Edit\" button in its right-most column. When you click this button, double-click on any of the cells in the row, or select a row and click the \"Edit\" button in the toolbar at the top of the page. This will change the item from \"View\" mode to \"Edit\" mode. The various columns are made editable, and \"Save\" and \"Cancel\" buttons are displayed in the last column:
If you click \"Edit\" on more than one row, the \"Save\" buttons are only displayed on the first row, and you can make changes to all the editable rows and then update the changes by clicking the one \"Save\" button. Also, if you want to make the same change to multiple rows (e.g. to change the owner of five test sets from \"Fred Bloggs\" to \"Joe Smith\"), you can click on the \"fill\" icon to the right of the editable item, which will propagate the new value to all editable items in the same column.
If you want to edit lots of items, first select their checkboxes and then click the \"Edit\" button on the same row as the Filters and it will switch all the selected items into edit mode.
When you have made your updates, you can either click \"Save\" to commit the changes, or \"Cancel\" to revert back to the original information. Alternatively, pressing the <ENTER> key will commit the changes and pressing the <ESCAPE> key will cancel the changes.
"},{"location":"Spira-User-Manual/Test-Set-Management/#show-hide-columns","title":"Show / Hide Columns","text":"This drop-down list allows you to change the fields that are displayed in the test set list as columns for the current product. To show a column that is not already displayed, simply select that column from the list of \"Show...\" column names and to hide an existing column, simply select that column from the list of \"Hide...\" column names. This is stored on a per-product basis, so you can have different display settings for each product that you are a member of. The fields can be any of the built-in fields or any of the custom properties set up by the product owner.
"},{"location":"Spira-User-Manual/Test-Set-Management/#filtering-sorting","title":"Filtering & Sorting","text":"Read about how to create and manage filters, and how to sort the artifact list.
"},{"location":"Spira-User-Manual/Test-Set-Management/#viewing-the-test-status-for-a-release","title":"Viewing the Test Status for a Release","text":"By default, when you view the list of test sets, it will display an aggregate status for all releases of the product. This means that the list shows:
If you change what release to display data for, by selecting a release from the dropdown in the top right, the list will show:
As a shortcut, when you select a specific release for viewing, subsequent execution of any of the test sets via the Tools > Execute Tests menu option will default the test run to the selected release.
"},{"location":"Spira-User-Manual/Test-Set-Management/#copying-test-sets","title":"Copying Test Sets","text":"To copy one or more test sets, select the check-boxes of the test sets (or test set folder) you want to copy and then select Edit > Copy Items from the menu. This will copy the current test set / test set folder selection to the clipboard. Then select the place you want the test sets to be inserted and choose the Edit > Paste Items option.
The test sets will now be copied to the destination you specified. The name of the copied test sets will have \" - Copy\" added to the end to distinguish them from the originals. If you are copying test set folders, only the top level folders' name(s) will will have \" - Copy\" added to the end - the new copies of items in the folder will have the same names as the originals.
"},{"location":"Spira-User-Manual/Test-Set-Management/#moving-test-sets","title":"Moving Test Sets","text":"There are two options for moving test sets or folders:
Once you have the test set/folder positioned at the correct place that you want it inserted, just release the mouse button. To move multiple items simply select their checkboxes and then drag-and-drop one of the selected items.
To quickly print a single test set, test set folder or list of test sets you can select the items' checkboxes and then click Tools > Print Items. This will display a popup window containing a printable version of the selected items.
Alternatively you can save the selected items into a number of formats, available via the Tools dropdown.
"},{"location":"Spira-User-Manual/Test-Set-Management/#right-click-context-menu","title":"Right-Click Context Menu","text":"SpiraPlan\u00ae provides a shortcut -- called the context menu - for accessing some of the most commonly used functions, so that you don't need to move your mouse up to the toolbar each time. To access the context menu, right-click on any of the rows in the test set list and the following menu will be displayed:
You can now choose any of these options as an alternative to using the icons in the toolbar.
"},{"location":"Spira-User-Manual/Test-Set-Management/#test-set-details","title":"Test Set Details","text":"When you click on a test set item in the test set list described in the previous section, you are taken to the test set details page illustrated below:
This page is made up of three areas:
The navigation pane consists of a link that will take you back to the test set list, as well as a list of the peer test sets to the one selected. This latter list is useful as a navigation shortcut; you can quickly view the detailed information of all the peer test sets by clicking on the navigation links without having to first return to the test sets list page. The navigation list can be switched between three different modes:
The operations toolbar lets you, amongst standard operations like save and delete:
create a duplicate of the current artifact by clicking Clone - note that:
export to a number of files formats or print it via one of the options in the Tools dropdown menu
Execute button will execute all the test cases in the set against the release specified in the test set and then take you to the test execution screenAt the top of the pane, you will see the test set's:
Initially the pane will be set to the \"Overview\" tab, but it can be switched to \"Test Runs\", \"Attachments\", \"Incidents\" and \"History\" tabs. Each of these is described separately below.
"},{"location":"Spira-User-Manual/Test-Set-Management/#overview-details","title":"Overview -- Details","text":"The top part of this tab displays the various standard fields and custom properties associated with the test set. Fields (both standard and custom) are grouped under the collapsible headings (marked by orange text and underline) in the screenshot below. For instance, all fields regarding releases are in the \"Releases\" group and dates are grouped together in the \"Dates and Times\" area.
The Display For field in the \"Releases\" section tells you what release execution status results are displaying for the test set. This field controls the results for the test set overall and also for its individual test cases. This field is read only. To change it, you must use the \"Display For\" dropdown on the list page.
The Detailed Information section contains the long, formatted description of the test case, as well as any rich text custom fields. You can enter rich text or paste in from a word processing program or web page. Clicking on the shaded areas of one of these detailed fields will display the rich text toolbar.
If you have test configuration sets defined in your product, you can assign them to a specific Test Set and use them for both manual and automated testing by setting the Configuration dropdown value. If you have a test configuration associated with the test set, when you execute the test set, SpiraPlan will generate a test run entry for each of the test configuration entries multiplied by each of the test cases in the set.
The Description section contains the long, formatted description of the test set. You can enter rich text or paste in from a word processing program or web page.
Manual or Automated Test Sets
Test Sets can be marked as either for \"Manual\" or \"Automated\" test runs (via the \"Type\" field).
How do you say when the test set should execute? You have two options.
Use the Planned Date field:
Use the Schedule on Build field:
Test cases can have parameters associated with them. This enables one test case to be called several times and have different parameters passed in each case, making the operation different. E.g. you could have a generic \"login to application\" test case that others call as an initial step, which could be provided with different login information depending on the calling test case. In addition these parameters may be used by certain test automation engines.
The Parameters section on the test set page lets you set a shared value for all of the parameters contained within the different test cases of the test set. The screenshot below shows that there are three parameters contained in the test cases that have been set at the test set level. In this example, every case that has a Parameter called 'browserName' will have its value set to 'Safari'. This is a quick way of setting values for many test cases at once. Test Set Values will override any default values of a Parameter (defined for each specific test case).
You can add any additional Parameters not already set by clicking on the \"Add Parameter Value\" button. In this example, you can see that one of the parameters not yet set is called 'url'.
You can also delete an existing Parameter specified for the whole test set by clicking the \"Delete\" button in the Operations column of the Parameter in question. Clicking the \"Edit\" button will let you alter the Test Set Value.
Note that the Default Value is derived from the test cases that use a specific Parameter. It is shown in this table for information only---to help testers know what value will be run in the absence of specifying a Test Set Value.
"},{"location":"Spira-User-Manual/Test-Set-Management/#overview-test-cases","title":"Overview - Test Cases","text":"This section displays the list of test cases currently contained within the test set. You can add, remove, reposition and remove test cases from the list. The execution status displayed next to each test case is the most recent execution status of the test case when run in the context of the current test set and, if specified, the release we are displaying data for.
To move the test cases, click the test case icon and drag it to the appropriate position in the list.
To modify an existing Test Case click the \"Edit\" button in the right-most column, or double-click on the cells in the row. That will switch the selected row into Edit mode. The Owner and Planned Date fields (if visible) can then be set at the test case level. Setting the owner field here is useful if you want the different test cases in the set to be executed by different testers (e.g. in integrated, scenario tests).
To add a new test case to the Test Set, click on the \"Add\" button to display the panel:
First, select the folder containing the test cases desired. You can then select the checkboxes of the individual test cases that you want to add to the test set (note: clicking the checkbox in the header row of the table will select ever test case in the currently selected folder). Once you have selected the desired items, click the \"Save\" button to add them to the test set.
As discussed above in Overview - Parameters, test cases can have parameters defined with specific values. These are created on the Test Case details page. If you need to specify different values for a parameter for different test cases in the test set, you can override both any default parameter values and any test set parameter values. To do so, click \"Edit Parameters\" for the required test case in this view. You can do this by either select the checkbox of a test set and click \"Edit Parameters\" at the top of the section, or right-click on the test case and choose \"Edit Parameters\":
You can then specify the values of the parameters that the test set will pass to this specific test case. Once you have entered / modified the values, click \"Save\" to commit the changes.
Matching execution status of test cases to the test set
The execution status shown for the test set at the top of the page is calculated from the most recent test run of the whole set for the release being displayed for (or most recent across all releases, if displaying for all releases). The execution status for the test cases in the test set is calculated in the same way.
As you change your test set over time, you may add and remove test cases. The list of test cases is always the currently included test cases. This means that if you are showing results for an old release, and since then you have REMOVED test cases from the test set, you will not see those test cases and their execution statuses in this list. The same happens if you have since ADDED test cases: they will show as Not Run, even if the test set's execution status has no Not Runs. When it was executed these new test cases weren't there to be run.
In this way, the overall test set execution status may not always match what you see in the test case list.
"},{"location":"Spira-User-Manual/Test-Set-Management/#overview-comments","title":"Overview - Comments","text":"Read about how the comments works
"},{"location":"Spira-User-Manual/Test-Set-Management/#test-runs","title":"Test Runs","text":"This tab displays the list of all the test runs executed against the test set. Each test run is listed together with the date of execution, the name of the test case, the name of the tester, the release/version of the system that the test was executed against, the overall execution status for the test case in that run and a link to the actual test run details. In addition, you can choose to display any of the custom properties associated with the test run.
The \"Show/hide columns\" drop-down list allows you to change the fields that are displayed in the test run list as columns. To show a column that is not already displayed, simply select that column from the list of \"Show...\" column names and to hide an existing column, simply select that column from the list of \"Hide...\" column names. The displayed columns can be any standard field or custom property.
You can also filter the results by choosing items from the filter options displayed in the sub-header row of each field and clicking the \"Filter\" button. In addition, you can quickly sort the list by clicking on one of the directional arrow icons displayed in the header row of the appropriate field.
"},{"location":"Spira-User-Manual/Test-Set-Management/#attachments","title":"Attachments","text":"Read about how the attachments tab works
"},{"location":"Spira-User-Manual/Test-Set-Management/#history","title":"History","text":"Read about how the history tab works
"},{"location":"Spira-User-Manual/Test-Set-Management/#incidents","title":"Incidents","text":"This tab displays the list of incidents associated with the current test set. Each incident will either have been: created during the execution of a test case in the test set (and are thereby linked to one of the test runs); or manually linked to one of the test steps in a test case of the set.
when navigating to folders (for all artifacts that support them), the URL in your browser's address bar will change. Each folder has a unique, sharable URL that you can give to someone to display the list of artifacts with the appropriate folder selected. You can also open up multiple folders in different browser tabs and easily toggle between them from the same browser.\u00a0\u21a9
This section outlines how you can log into SpiraPlan\u00ae, view your personalized home-page that lists the key tasks that you need to focus on, and drill-down into each of your assigned products in a single dashboard view. In addition to your personal homepage, each of your products has its own dashboard that depicts the overall product health and status in a single comprehensive view.
"},{"location":"Spira-User-Manual/User-Product-Management/#login-screen","title":"Login Screen","text":"Upon entering the SpiraPlan\u00ae URL provided by your system administrator into your browser, you will see the following login screen:
You need to enter your given user-name and password into the system in the appropriate boxes then click the Log In button to gain access to the application. Normally you only remain logged in to the application whilst in active use, and you will be asked to log-in again after either closing the browser or 20 minutes of inactivity. To prevent this, and to stay logged-in to SpiraPlan\u00ae regardless of browser window closing or inactivity, select the \"Keep me logged in\" check-box before clicking the Log In button. Note that this setting is specific to each individual computer you are logging-in from, and that it will be reset when you explicitly log-out with the log-out link.
If you have enabled 2-step authentication once you have entered your username and password correctly you will need to enter a valid one-time password.
If for any reason you are unable to login with the provided username/password combination, and error message will be displayed. If you cannot remember the correct log-in information, click on the \"Forgot your password\" link and your password will be emailed to the email address currently on file. The reset password screen is illustrated below:
If you don't have a SpiraPlan\u00ae account setup, clicking on the \"Register for an account?\" link will take you to a form that you need to fill-in, which will be forwarded to the system administrator, who will need to approve your account before it is active in the system. This screen is illustrated below:
In addition, the system will prevent you logging on to the system with the same username at the same time on multiple computers. This is to avoid the system getting confused by a user trying to make contradictory actions at the same time. If for any reason you do try and log in to the system when you already have an active session in progress, you will see the following screen:
You have two choices: you can either click the \"Log Out\" link and try logging in as a different user, or if you want to log-off any other active sessions (e.g. you closed the browser and the session is still listed as active), simply click the \"Sign Off The Other Locations\" link, and you will be logged in to the application.
Since SpiraPlan\u00ae is licensed to organizations for a specific number of concurrent users -- unless they have purchased an unlimited Enterprise license -- only a fixed number of users may be active at the same time. So, for example if an organization has a five (5) concurrent user license and a sixth user tries to log-in, they will be presented with the following screen:
This means that one of the other users who is already logged-in, needs to click the \"Log Out\" button so that one of the concurrent licenses is freed for your use. If the user has logged out by closing the browser, the system may not have detected the logout. In this case, the other user needs to log back in, and then click the \"Log Out\" link.
"},{"location":"Spira-User-Manual/User-Product-Management/#logging-in-using-an-external-provider","title":"Logging in Using An External Provider","text":"If your organisation uses a Single Sign On / OAuth provider like Okta or Google, underneath the standard username and password field you will see a button for each enabled provider.
To login using your account with this provider:
Login. You are now connected to this provider!Once you have a SpiraPlan user that authenticates with the provider, to log in to Spira click the provider button on the login page.
"},{"location":"Spira-User-Manual/User-Product-Management/#my-page","title":"My Page","text":"Once you have successfully logged in, you will initially be taken to your personalized home page called \"My Page\". Please note, that the very first time you log in you will be asked if you want to take a quick orientation tour of the application (which will look similar to the screenshot below).
Note that once you have successfully logged-in and chosen a product, SpiraPlan\u00ae remembers this selection, and on subsequent log-ins will automatically select that product, and highlight it for you in the \"My Products\" list.
Your homepage contains all the information relevant to you---consolidated onto a single page for you to take immediate action. By default the page lists the information for all products that you are a member of. However, you can choose to filter by the current product, to get a more focused list.
Next to some of the widgets is an RSS icon (
), this allows you to subscribe to the information as a Really Simple Syndication (RSS) newsfeed. This can be useful if you want to be notified about recently assigned items without having to setup email notifications or being logged into SpiraPlan continuously. If you don't see an RSS icon next to the widgets on your My Page it means that you have not enabled RSS newsfeeds in your profile. For more details on configuring your RSS preferences, please refer to My Profile.
Initially the page is loaded in 'view mode' which means that the various 'widgets' on the page are displayed with minimum visual clutter (no toolbars or control icons) that makes it easy to scan the items on the page and see what work has been assigned. To switch the page to 'edit mode', click on the button with the cog icon () on the right:
In this mode, each of the 'widgets' displayed on the page can be minimized by clicking on the arrow icon () in the top-left of the window, or closed by clicking-on the cross icon () in the top-right of the window. This allows you to customize your page to reflect the types of information that are relevant. If you have closed a widget that you subsequently decide you want to reopen, you can add them back to the page display by clicking the \"Add Items\" button at the top of the page. In addition, the various widgets have a \"settings\" icon () that allows you to customize how that widget appears. The settings are specific to each widget and in general allow you to specify how many rows of data are displayed and what columns are displayed.
You can move and reposition the various widgets on the dashboard by clicking the mouse on the title bar of the widget you want to move and dragging it to the desired location. This change will be remembered when you next login to the system. Once you have the dashboard configured the way you like it, you can click \"Return to Normal View\" to switch back to 'view mode'.
When you load your 'My Page' for the first time it will consists of the following main elements:
However these are not the only widgets available. If you click on the \"Add/Remove\" items hyperlink it will display the list of any additional widgets that are available:
You can add the additional widgets by selecting the appropriate checkbox, choosing the destination location (left side vs. right side) and then click the [Add] button. The additional widgets available in the My Page are:
This widgets shows the most recent products you have visited. Each time you visit a page for a different product the list of most recent products is updated. By default, it shows the five most recent products -- this can be edited in the widget edit controls to any number fifty or less.
For each recent product visited, the widget shows name for:
Each product name is a link to that product's home page. The program and portfolio names are links to the relevant home pages if you have access to view those home pages.
"},{"location":"Spira-User-Manual/User-Product-Management/#recent-artifacts","title":"Recent Artifacts","text":"This widgets shows the most recent artifacts you have visited. If you last looked at Requirement X in Product Y then Requirement X will show at the top of the list. The widget will show specific artifacts across all artifact types and all products. By default, it shows the five most recent artifacts -- this can be edited in the widget edit controls to any number fifty or less.
For each recent artifact, the widget shows:
If \"All Products\" is selected at the top of the My Page, the list shows the most recent artifact across all products.
If \"Current Product\" is selected at the top of the My Page, the list shows only the recent artifacts that are from the current product (if any).
"},{"location":"Spira-User-Manual/User-Product-Management/#my-saved-searches","title":"My Saved Searches","text":"This section lists any filters/searches you have saved from the various artifact list screens throughout the application. This allows you to store specific combinations of searches that you need to perform on a regular basis (e.g. display all newly logged incidents, display all requirements that are completed but have no test coverage).
The name of the saved search is displayed along with an icon that depicts which artifact it's for and the product it refers to. Clicking on the name of the saved search will take you to the appropriate screen in the product and set the search parameters accordingly. Clicking the \"Delete\" button next to the saved search will delete it. Clicking on the RSS icon will allow you to subscribe to the specific search so that it will be displayed in your RSS newsreader. This allows you to setup customized lists of information that can be displayed outside of SpiraPlan.
"},{"location":"Spira-User-Manual/User-Product-Management/#my-assigned-requirements","title":"My Assigned Requirements","text":"This section lists all the requirements you have been made owner of, across all the different products you are a member of. This typically means that the product manager has assigned you to be responsible for either developing the supporting test cases or decomposing the requirement into its detailed work breakdown structure of product tasks. The requirement name is displayed, along with its status (requested, accepted, in-progress, etc.) and its importance. Requirements are included based on their importance: the list is ordered by importance (highest at top) and requirements with the same importance are ordered by their IDs.
"},{"location":"Spira-User-Manual/User-Product-Management/#my-assigned-test-cases","title":"My Assigned Test Cases","text":"This section lists all the test cases you are the owner of, across all products you are a member of. This typically means that the product or test manager has assigned you to be responsible for executing these test scripts. Test cases are included based on their last execution status and date: the list is ordered by execution status (failed at the top), test cases with the same execution status are ordered by last execution date, and if those match, then by their IDs. For each test case in the list you can see:
If you edit the widget you can: change the number of rows to show; show or hide the last executed date; and show or hide and the workflow status.
"},{"location":"Spira-User-Manual/User-Product-Management/#my-assigned-test-sets","title":"My Assigned Test Sets","text":"This section lists all the test sets (groups of test cases) you are the owner of, across all products you are a member of. This typically means that the product or test manager has assigned you to be responsible for executing the test cases contained within the test set against a specified release of the system under test. Test sets are included based on their planned date: this list is ordered by planned date (oldest at top) and test sets with the same planned are ordered by their IDs. For each test set in the list you can see:
This section lists any test runs that you started executing in the test case module but haven't yet completed. Until a test case or test set is fully executed, a pending test run entry is stored in the system so that you can continue execution at a later date.
Any pending test run can be either deleted or resumed by clicking on the appropriate button. In addition, there is the option to reassign the test run to another user that is a member of the product.
"},{"location":"Spira-User-Manual/User-Product-Management/#my-assigned-tasks","title":"My Assigned Tasks","text":"This section lists all the product tasks that you have been made the owner of across all the different products you are a member of. This typically means that the manager of the product in question has assigned development tasks to you that need to be completed so that a release can be completed and/or a requirement can be fulfilled. The tasks are listed by priority: tasks with no priority at the top, and after that the highest priority tasks. In addition, each task is displayed with a progress indicator that graphically illustrates its completion against schedule. See Task Tracking -- task management for details of the different progress indicators.
Clicking on the task name hyperlink will take you to the task details page. This page will describe the task in more detail, illustrate which requirement and release it is associated with, and also allow you to view the change log of actions that have been performed on it.
"},{"location":"Spira-User-Manual/User-Product-Management/#my-assigned-incidents","title":"My Assigned Incidents","text":"This section lists all the open incidents you are the owner of, across all the different products you are a member of. This typically means that the product manager has assigned you to be responsible for resolving the incident. In the case of a bug, this can mean actually fixing the problem, whereas for other incident types (e.g. training item) it may mean simply documenting a workaround. In either event, this section highlights the open incidents you need to manage, ranked by priority (incidents with no priority are at the top) and categorized by type, with the open date displayed to give you a sense of the age of the incident.
Clicking on the incident name hyperlink takes you to the incident details page) that describes the incident in more detail, and allows you to add new information or change its status to indicate actions taken. In addition, if you position the mouse pointer over the name of the incident, a more detailed description is displayed as a \"tooltip\".
"},{"location":"Spira-User-Manual/User-Product-Management/#my-detected-incidents","title":"My Detected Incidents","text":"This section lists all the open incidents that you have detected, across all the different products you are a member of. These incidents are not necessarily ones that you need to take an active role in resolving, but since you were the originator -- either by executing a test case or just logging a standalone incident -- you can watch them to make sure that they are resolved in a timely manner. The incidents shown are ranked by last updated date (most recent at the top).
Clicking on the incident name hyperlink takes you to the incident details page) that describes the incident in more detail, and allows you to add new information or change its status to indicate actions taken. In addition, if you position the mouse pointer over the name of the incident, a more detailed description is displayed as a \"tooltip\".
"},{"location":"Spira-User-Manual/User-Product-Management/#quick-launch","title":"Quick Launch","text":"This widget allows users to quickly record a new incident in any of the products that they belong to. It's a shortcut that avoids having to first select a product, go to Tracking > Incidents and then click \"New Incident\". Instead you simply choose the product from the dropdown list and click the arrow icon to bring up the new incident creation screen.
"},{"location":"Spira-User-Manual/User-Product-Management/#my-contacts","title":"My Contacts","text":"This widget displays a list of any other users in the system that you have listed as a personal contact:
Each user is displayed along with their graphical avatar, department and a colored indicator that lets you know if they are online or not. If they are online you can then send them an instant message (which will be described later in Global Navigation. To remove an existing contact, just click on the 'Remove' button. To add a new user, simply locate them in the Tracking > Resources page and then use the <Add As Contact> button.
"},{"location":"Spira-User-Manual/User-Product-Management/#my-saved-reports","title":"My Saved Reports","text":"This section lists any reports you have saved from the reports center. This allows you to store specific combinations of report elements, format, filters and sorts (see the section on Reporting for more details on how to configure a report) for reports that you need to run on a regular basis.
"},{"location":"Spira-User-Manual/User-Product-Management/#my-subscribed-artifacts","title":"My Subscribed Artifacts","text":"This widget displays a list of all the artifacts in the system that you have subscribed to (by clicking on the Subscribe icon on the item). You can display the item by simply clicking on the hyperlink. In addition, if changes are made to any of the artifacts an email notification will be sent to you. You can click on the \"Unsubscribe\" button to remove the item from this list.
"},{"location":"Spira-User-Manual/User-Product-Management/#my-news-feeds","title":"My News Feeds","text":"This widget allows you to subscribe to an external newsfeed and have the results be displayed inside SpiraPlan. By default it will be set to the newsfeed from the Inflectra website that displays a list of recent company and product announcements. You can add multiple instances of the widget to the dashboard, allowing you to read multiple news sources at once. Typical uses for this widget are to add news from product management and testing news sites/blogs or to add information from other tools in your organization that can display their data in RSS format.
"},{"location":"Spira-User-Manual/User-Product-Management/#my-assigned-risks-spiraplan-only","title":"My Assigned Risks (SpiraPlan only)","text":"This section lists all the risks you are the owner of across all the different products you are a member of. Clicking on the risk name hyperlink will take you to the risk details page. This page will describe the risk in more detail. Risks are shown ranked by their exposure (the highest exposure at the top), risks with the same exposure are ordered by their IDs.
"},{"location":"Spira-User-Manual/User-Product-Management/#my-assigned-documents","title":"My Assigned Documents","text":"This section lists all the documents you are the owner of across all the different products you are a member of. Clicking on the risk name hyperlink will take you to the documents details page. This page will describe the documents in more detail. The list is ranked by last updated date.
"},{"location":"Spira-User-Manual/User-Product-Management/#global-navigation","title":"Global Navigation","text":"Regardless of the page you are on, SpiraPlan\u00ae will always display the global navigation bar, consisting of a number of different sections, depending on the user and where they are in the system.
Under some of the icons and headings are secondary menu options that display when you click on the section in question. The sections and menus available in the global navigation are show below:
Artifacts Selector: when visible, this shows the name of the current artifact for the current workspace. Clicking it will show all your available artifacts and clicking any of these will change you to that artifacts main page. For product workspaces these artifacts are grouped as follows:
Reporting
User Profile Icon
Administration Icon: This is visible if you are a system administrator, or if you are an owner/administrator of the current workspace or its template. Clicking the icon will display the relevant administration menu. This is described in the separate SpiraPlan Administration Guide.
SpiraPlan includes a global search that can be used to search across product and artifact type for items that include the entered keywords in either the name or description field. Clicking on the search icon in the global navigation will let you type in your search term. You will also see a popup below the search box that gives you quick access to recent artifacts you have looked at, and also to your most recent searches. After you search for something you see all matching results:
You can search for individual keywords by entering them in the search box and clicking the arrow button on the right. You can search for phrases by enclosing the words in double quotes. You can also search for a specific artifact by its unique two-letter prefix and ID number.
For example, searching on book name will find any artifacts that include either of the two words book and name in the name or description. Searching on \"book name\" will only return items that have that exact phrase in either the name or description. Searching on TC2 will display just the Test Case with ID=2:
When you get a list of search results, you can choose to order by relevance (the default) or by most recent. Searching by relevance finds the artifacts that have the greatest match with the keywords:
The search by date is useful when you want to find recent items that match the search keywords:
In addition, you can filter the results by artifact type and/or product to narrow down the search:
For example, if you filter by requirement, the list of results will be narrowed accordingy:
"},{"location":"Spira-User-Manual/User-Product-Management/#log-out","title":"Log Out","text":"Clicking on the \"Log Out\" link will immediately log you out of your current session and return you to the login page. If you had set the \"Keep Me Logged In\" option during your previous login, that setting will be reset; so if you want to avoid having to keep logging-in, you'll need to re-check that box during your next log-in.
"},{"location":"Spira-User-Manual/User-Product-Management/#documentation","title":"Documentation","text":"Clicking on this link on any page will bring up the online version of this manual shown below:
Clicking on any of the triangles expand links in the left hand table of contents will open up the detailed list of topics for each of the main areas of the system. In each area, clicking on one of the individual links will open the appropriate section in the help manual. By default, the reading-pane will open to the help item that is most closely related to the screen you happened to be on when you clicked the \"Help\" link.
You can search the index by using the \"Index\" tab.
If you want to share a specific help page with a colleague in your organization, send them the url from the address bar.
"},{"location":"Spira-User-Manual/User-Product-Management/#choosing-a-workspace","title":"Choosing a Workspace","text":"Workspaces in SpiraPlan set out the scope for the data you want to view and interact with. The most common workspace type is a product:
A product contains all the requirements, sprints, defects, and tests associated to it.
Programs are groups of products, where you can look across all the products in that program at once
Choosing, for example, a Product or Program from the list of your assigned workspaces in the drop-down-menu allows you to quickly and easily jump between workspace regardless of the page you happen to be on. When you choose a new workspace, you will be taken to the same page in the selected workspace (assuming that you have permissions to view that page). Any workspace with a little cog at the end is a workspace that you are an owner/admin of.
You can use CTRL+click to open the new product in a separate browser tab:
"},{"location":"Spira-User-Manual/User-Product-Management/#show-onboarding-tours","title":"Show Onboarding Tours","text":"When you first login to SpiraTeam, the system will show you a welcome page, together with a tour that walks you through the key features of the application. If you would like to see that again, you need to click on the \"Show Onboarding Tours\" option, under the user profile menu. SpiraPlan will then display the onboarding tour main dialog again:
You can click 'No Thanks to dismiss it, or 'Yes Please' to start the tour.
"},{"location":"Spira-User-Manual/User-Product-Management/#instant-messenger","title":"Instant Messenger","text":"The Spira instant messenger is available in both SpiraTeam\u00ae and SpiraPlan\u00ae and allows you to send short messages instantaneously to other users in the system. You can see the status of other users by looking for the small green circle next to the list of users in the 'My Contacts' widget as well as the various user fields in the system:
When a user is online and available to communicate with, the small circle will be filled-in green. If you click on the green circle, it will open up the instant messenger window for that user:
You can then enter in a message to the other user, which will then cause a conversation window to open inside their web browser with your message displayed. The other user can then enter in their responses, allowing the two users to have a real-time conversation:
To make it easier to see what's new, all unread messages are displayed in a message box with a darker shade. In addition, the user's avatar image is displayed at the start of each message group.
If the message window appears on a SpiraPlan\u00ae window that contains a specific artifact (e.g. a requirement, test case, task, etc.) there will be the option to 'Post as Comments'. If you click this option, any messages selected with a checkbox will be automatically posted to the current artifact as comments. This is useful if you have a conversation related to a specific item and you want to have the outcome permanently recorded as part of the audit trail. Otherwise, instant messages will be automatically purged from the system after 90 days.
"},{"location":"Spira-User-Manual/User-Product-Management/#my-profile","title":"My Profile","text":"When you click on the \"My Profile\" button (the top item in the user dropdown) in the global navigation, you will be taken to the page in the system that allows you to view and edit your personal profile:
You can change your user information including your first-name, last-name, middle-initial, avatar icon, department and your choice of start-page. Clicking the \"Save\" button will commit the changes, whereas clicking <Cancel> returns you back to either \"Product Home\" or \"My Page\" depending on whether you have a product currently selected or not.
If you want to be able to subscribe to RSS feeds of the information assigned to you in the \"My Page\", make sure that the \"Enable RSS Feeds\" switch is set to \"Yes\" and an RSS token has been generated underneath.
You can change your start page to be any of the following:
My Page -- When you first log-in, you will be taken to your \"My Page\" dashboard
Last Opened Product -- When you first login-in, you will be taken to the home page for the product you last had open
Last Opened Program - When you first login-in, you will be taken to the home page for the program you last had open
In addition to being able to update your user information, you can also change your password. To change your password, on the Account Security tab, fill in the three fields in the Change Password box with your current password, and new password repeated for verification. Click \"Save\". If the password fields were not correctly filled in, you will see a warning message at the top of the page.
You can also change the current password retrieval question and answer by entering in your current password (for security reasons) as well as the new password question and answer.
Note: If your SpiraPlan user profile is linked to an account stored in an external LDAP server, the change password option is disabled. This is because the system uses the password held in the external server. To change the password in this case, please contact your system administrator who will be able to help you change the password in your LDAP environment.
"},{"location":"Spira-User-Manual/User-Product-Management/#2-step-authentication","title":"2-Step Authentication","text":"2-Step Authentication lets you make sure on logging you have to enter your password and also a one-time password for added security. The 2-Step Authentication box on the Account Security tab:
Click on the link in the box to 2-Step Authentication Settings Page. If not yet enabled , the page will walk you through adding 2-step authentication. If already enabled, the page will let you remove the authentication or update it.
To add or update your one-time password you need to scan the QR code into a suitable 2-step authentication app. These are available across device types (desktops, smartphones, tablets). For example, apps like Google Authenticator and 1Password can readily scan the QR code.
Once scanned, enter in the six digit code in your authenticator app within its thirty second window onto the page and click \"Submit.\"
"},{"location":"Spira-User-Manual/User-Product-Management/#ldap-information","title":"LDAP Information","text":"If your account authenticates using LDAP, this tab will show you information about the configured LDAP options for your account. This is for reference only.
"},{"location":"Spira-User-Manual/User-Product-Management/#login-provider","title":"Login Provider","text":"If your account authenticates using an external provider (like Google or Okta), this tab will show you information about which provider you are using.
Click the Unlink Account button to stop using the external provider. The popup will make you enter new security information. You will use this, along with your username, to login to SpiraPlan, once the unlinking process is complete
Here you can configure the email address that the application will send notifications to, and whether or not you want to receive email notifications.
If the Enable Notifications cannot be changed, it means that the system is either not configured to send out notifications, or the administrator has disabled user's ability to opt out of notifications being sent.
"},{"location":"Spira-User-Manual/User-Product-Management/#regional-settings","title":"Regional Settings","text":"This tab will display the current culture and timezone associated with your profile:
By default all profiles will be set to use the application's default culture and timezone. This means that the language, number formats and timezone used in the application will be the ones decided by the person who installed the system. However there are cases where you want to use a different language, timezone or number format (for example, a German employee working in the German office of a French company might want to use the German culture instead of French). You can change the culture and/or timezone to any of the options listed in the dropdown list.
Note: The system will only be installed with a certain number of language packs, so in some cases a selected culture will only change the number formats and not the languages displayed.
"},{"location":"Spira-User-Manual/User-Product-Management/#actions","title":"Actions","text":"This tab displays the list of recent actions that you have performed in the system (across all products):
You can search and filter the grid to find changes by product, change date range, artifact type and type of change (added, deleted, or modified).
"},{"location":"Spira-User-Manual/User-Product-Management/#my-timecard","title":"My Timecard","text":"When you click on My Page > My Timecard the system will display a timecard that allows you to enter the effort worked on incidents and tasks currently assigned to you (across all your products):
The system will only include products that have time-tracking enabled for incidents and tasks, so if some of your assigned incidents or tasks are missing, please check with the product owner of the products affected to have them enable time-tracking.
Each task or incident will be displayed along with its priority, severity, start-date, end-date, product name effort remaining and effort expended to date. For each item you can then indicate the additional actual effort performed (which will be added to the \"actual effort\") and modify the amount of hours remaining. Once you are satisfied, click [Submit Timecard] to commit the changes.
"},{"location":"Spira-User-Manual/User-Product-Management/#redirects","title":"Redirects","text":"What are SpiraApps?
SpiraApps let you tailor SpiraTest, SpiraTeam, and SpiraPlan to your needs. Dedicated SpiraApps extend what is possible, each addressing a specific use case.
One of the key attributes of the Spira platform is that it is a complete, integrated turnkey solution for companies that need to develop, test and manage their software applications. However there are specific features that are needed by different industries and methodologies that are better served by a more extensible set of \u2018add-on\u2019 features to the core system. For example, working in healthcare you have to comply with 21 CFR Part 11, whereas in automotive you need to support ISO 26262. SpiraApps allow Inflectra and its customers and partners to easily, safely, and seamlessly provide niche features for different industries and needs.
Currently, Inflectra Corporation creates and manages all available SpiraApps, and they are distributed through installing or upgrading SpiraPlan itself.
Inside Spira, administrators can browse the list of available SpiraApps. From here they can activate, configure, and then enable for relevant products. SpiraApps functionality is limited to each product they are enabled for - in other words, they do not work in programs, portfolios, or system wide.
"},{"location":"SpiraApps/#getting-started-with-a-spiraapp","title":"Getting Started with a SpiraApp","text":"Here is a quick overview of how to start using a SpiraApp (we recommend also reading the documentation for the SpiraApp too):
System admins can see which SpiraApps are currently installed on the by going to the System Administration > System > SpiraApps page.
Meanwhile, product admins can see which SpiraApps are available to use in their product(s) by going to the Product Administration > General Settings > SpiraApps page. Only SpiraApps that a system has activated at the system level are available for use in products.
"},{"location":"SpiraApps/#setting-up-a-spiraapp","title":"Setting up a SpiraApp","text":"Some SpiraApps have system-wide settings that need to configured for the SpiraApp to work properly. For instance, if a SpiraApp integrates with a third party service, you may need to store login credentials (securely) in the SpiraApp's system settings.
Many SpiraApps have product-specific settings. For the SpiraApp to function correctly, you will need to fill in these settings. For example, if you want to use the SpiraApp to add default descriptions to all new tasks created on the task details page, you have to tell the SpiraApp what description to use.
Once system and product level settings have been configured, the SpiraApp will be ready to use. Depending on the SpiraApp, end users may need to prepare specific artifacts to work with the SpiraApp. They will do this by editing artifacts and their fields in exactly the same way as normal. For example, if a SpiraApp lets you integrate a third party CI/CD tool, you will use releases to start a build on that service: each release may link to a different build job or pipeline in that service, and you have to add that information to dedicated custom fields on the release.
"},{"location":"SpiraApps/#end-user-experience","title":"End User Experience","text":"End users likely will not know they are using a SpiraApp at all. They will interact with the SpiraApp functionality in the same way as any other part of the system.
"},{"location":"SpiraApps/#what-can-spiraapps-do","title":"What can SpiraApps do","text":"SpiraApps can work in the following places:
SpiraApps can do a range of different types of things:
Some SpiraApps may use only one of the features, others may use multiple. Some may be available in a single part of the application, others across multiple places and pages.
"},{"location":"SpiraApps/#available-spiraapps","title":"Available SpiraApps","text":"You can learn more about each of the currently available SpiraApps by accessing the other pages in this section of the documentation (see the menu on the left).
"},{"location":"SpiraApps/CircleCI/","title":"CircleCI SpiraApp","text":"This SpiraApp lets you integrate SpiraPlan and CircleCI so users can launch pipelines from Spira and see their results in Spira as builds.
About this SpiraApp
This SpiraApp has two independent parts (you do not need one for the other to work):
To record builds in SpiraPlan, you must setup the webhook integration with CircleCI.
To configure this SpiraApp that lets users manually kick off a new Pipeline, you must additionally do the following:
"},{"location":"SpiraApps/CircleCI/#system-settings","title":"System settings","text":"To find the slug:
circleci-branch-name for Releases in the product's template. Note: you may already have a custom property for this already if you setup the webhook integration - if you have, do not create a second one.To use the SpiraApp to start a new CircleCI Pipeline go to a release in that product.
You must make sure the custom property \"circleci-branch-name\" has the exact name of the branch in the relevant repo (for instance \"develop\") that you are building the release/sprint against. Note: this field is used by both the CircleCI SpiraApp and the CircleCI webhook integration.
Once the release has the branch name filled in, at any time you can click on the CircleCI button in the top toolbar. This opens the dropdown. Click \"Run Pipeline\" to start the pipeline on CircleCI. You will see an info message telling you the Pipeline has started.
Because a pipeline can take a while to run, do not expect to automatically see the build as soon as the info popup goes away. It may take a few minutes or more for the build to be recorded (if this part of the integration has been configured).
"},{"location":"SpiraApps/Default-Descriptions/","title":"Default Descriptions SpiraApp","text":"Some of this SpiraApp's functionality is not compatible with SpiraTest or SpiraTeam
This SpiraApp lets users to create artifacts from their details pages with pre-populated default descriptions. These descriptions are added automatically when creating new artifacts from the relevant details page. The following artifacts are supported: requirements, releases, test cases, incidents, tasks, and risks.
About this SpiraApp
Once the SpiraApp has been activated system wide, and enabled for a product you can edit its product settings to add/update the default descriptions for the relevant artifacts.
Enter the default description desired in each of the rich text boxes. If a rich text box is left blank, no default description will be added when making that artifact. You can use all available formatting options, except for pasting images.
"},{"location":"SpiraApps/Default-Descriptions/#using-the-spiraapp","title":"Using the SpiraApp","text":"Any default description set is automatically added as the description when any user creates a new artifact (not a clone of an existing artifact):
Once the new artifact has been created, the user can continue to edit the newly created artifact as normal, including editing the description. Once an artifact has been created there is no way to reset or reinsert the default description for that artifact.
Note when creating artifacts (like requirements) on the list page, the default description is not added. You must create the artifact from the standard details page.
"},{"location":"SpiraApps/FMEA/","title":"FMEA SpiraApp","text":"This SpiraApp is only compatible with SpiraPlan
This SpiraApp extends the built-in risk functionality by supporting FMEA with a dedicated FMEA SpiraApp that calculates the Risk Priority Number (RPN) by multiplying together values for the risk's probability, impact, and detectability. It also provides a replacement \"Top Open Risks\" widget for the product home page and reporting home page that is ranked by and shows the RPN.
About this SpiraApp
To effectively implement FMEA in your product, you have to set up the fields that will store the FMEA data (detectability and the RPN itself). You can also optionally configure how the \"Top Open Risks by Risk Priority Number\" widget will display.
"},{"location":"SpiraApps/FMEA/#product-template-setup","title":"Product Template Setup","text":"In the product template for each product that uses FMEA, you need to setup a few different fields:
1. Create a detectability list to store all the options available for detectability
2. Create a detectability property to set the detectability of each risk
3. Create a custom property to store the calculated RPN
4. Optionally, update workflows. This is not required, but we recommend making the following changes to all risk workflows in templates whose products will use FMEA:
Once the FMEA SpiraApp has been activated system wide, and enabled for a product, there are a number of settings:
Custom Properties: these must be filled in for the FMEA SpiraApp to work.
RPN Thresholds: these are optional fields to fill but we recommend filling them in if you intend for users to show the \"Top Open Risks by Risk Priority Number\" widget. The widget shows a list of risks by RPN score. The score can have three colors: red, yellow, or green. Fill in these threshold fields to determine what scores get which color. Unless both of these values are filled in, RPNs will not have any color on the widget.
Note that if your 3 values for RPN (probability, impact, and detectability) all range from 1 through 5, RPN scores will be in the range 1-125.
Other: you can optionally set the RPN Widget Number of Rows to set the maximum number of rows that every user will be able to see when using the widget. If blank every user will see up to 5 rows. You can enter any number here, but note that the widget will display a maximum of 50 rows (even if you enter a larger value).
"},{"location":"SpiraApps/FMEA/#using-the-spiraapp","title":"Using the SpiraApp","text":""},{"location":"SpiraApps/FMEA/#risk-details-page","title":"Risk Details Page","text":"The core functionality of the FMEA SpiraApp is to allow users to set detectability on a risk, and using that value and the risks probablity and impact, calculate a Risk Priority Number (RPN). Users do this on the risk details page.
While on the risk details page (either creating a new risk or editing an existing one) they will see, as per workflow, fields for probability, impact, and detectability. If all three of these fields have a value, then the RPN score for the risk is calculated and saved to the RPN field. Every time the underlying RPN fields are changed, while on this page, the RPN will be updated to reflect that.
The RPN is shown in the dedicated RPN custom property. The Risk Exposure is still calculated and shown at the top of the page, and is independent of the RPN.
On the risk list page: users can but should not edit the RPN; editing risk probability, impact, or detectability on the risk list page will not update the RPN
"},{"location":"SpiraApps/FMEA/#using-the-top-open-risks-by-risk-priority-number-widget","title":"Using the Top Open Risks by Risk Priority Number Widget","text":"This widget displays a breakdown of the top open risks in the product, in order of decreasing RPN score. The widget is available on any of the product home pages, and on the product reporting home page.
Risks in the widget are filtered by any release currently selected for the page. To add the widget to a page, edit the page and then open the \"SpiraApp Widgets\" section. Add the widget to the section of the page you want.
The number of rows shown matches that in the product settings for this SpiraApp. For each row you see:
Because the Detectability and RPN fields are custom properties, they can be viewed and queried in the same way as any other custom property. For example you can see this information on the:
This SpiraApp lets you integrate SpiraPlan and GitHub so users can launch Actions from Spira and see their results in Spira as builds.
About this SpiraApp
This SpiraApp has two independent parts (you do not need one for the other to work):
To record builds in SpiraPlan, you must setup the webhook integration with GitHub.
To configure this SpiraApp that lets users manually kick off a new Action, you must additionally do the following:
"},{"location":"SpiraApps/GitHub/#system-settings","title":"System settings","text":"github-branch-name for Releases in the product's template. Note: you may already have a custom property for this already if you setup the webhook integration - if you have, do not create a second one.github-workflow-id for Releases in the product's template.To use the SpiraApp to start a new GitHub Action go to a release in that product.
You must make sure:
Once the release has the branch name filled in, at any time you can click on the GitHub button in the top toolbar. This opens the dropdown. Click \"Run Action\" to start the Action on GitHub. You will see an info message telling you the Action has started.
Because a Action can take a while to run, do not expect to automatically see the build as soon as the info popup goes away. It may take a few minutes or more for the build to be recorded (if this part of the integration has been configured).
"},{"location":"SpiraApps/GitLab/","title":"GitLab SpiraApp","text":"This SpiraApp lets you integrate SpiraPlan and GitLab so users can launch pipelines from Spira and see their results in Spira as builds.
About this SpiraApp
This SpiraApp has two independent parts (you do not need one for the other to work):
To record builds in SpiraPlan, you must setup the webhook integration with GitLab.
To configure this SpiraApp that lets users manually kick off a new Pipeline, you must additionally do the following:
"},{"location":"SpiraApps/GitLab/#system-settings","title":"System settings","text":"gitlab-branch-name for Releases in the product's template. Note: you may already have a custom property for this already if you setup the webhook integration - if you have, do not create a second one.To use the SpiraApp to start a new GitLab Pipeline go to a release in that product.
You must make sure the custom property \"gitlab-branch-name\" has the exact name of the branch in the relevant repo (for instance \"develop\") that you are building the release/sprint against. Note: this field is used by both the GitLab SpiraApp and the GitLab webhook integration.
Once the release has the branch name filled in, at any time you can click on the GitLab button in the top toolbar. This opens the dropdown. Click \"Run Pipeline\" to start the pipeline on GitLab. You will see an info message telling you the Pipeline has started.
Because a pipeline can take a while to run, do not expect to automatically see the build as soon as the info popup goes away. It may take a few minutes or more for the build to be recorded (if this part of the integration has been configured).
"},{"location":"SpiraApps/OctoPerf/","title":"OctoPerf SpiraApp","text":"This SpiraApp lets you integrate SpiraPlan (and SpiraTest and SpiraTeam) and OctoPerf so users can launch Actions from Spira and see their results in Spira as builds.
About this SpiraApp
This SpiraApp has two interdependent parts that are both required for full functionality:
Note that only OctoPerf tests launched from SpiraPlan using this SpiraApp will create associated SpiraPlan test runs
"},{"location":"SpiraApps/OctoPerf/#system-settings","title":"System settings","text":"https://api.octoperf.com, while OctoPerf on-premise customers should enter their on premise URLoctoperf-scenario-id for Test Cases in the product's template.octoperf-benchresult-id for Test Cases in the product's template.This step is not required, but we strongly recommend updating your workflows to make the \"octoperf-benchresult-id\" custom property either hidden or disabled for all workflow steps. This is field is used to store data sent from OctoPerf so that Spira can match up the the results to the correct test case.
"},{"location":"SpiraApps/OctoPerf/#webhook-setup-in-octoperf","title":"Webhook Setup in OctoPerf","text":"To complete the next part of the setup, login to your OctoPerf Application.
Create a notification: go to the notifications page in OctoPerf and add a new notification with the specific settings below:
{{base url}}/Services/Webhooks/BuildService.svc/OctoPerf?username={{username}}&api-key={{api key}}. This is the url that OctoPerf uses to talk to SpiraPlan. See the example below.The webhook URL
The webhook URL is made of different parts.
https://mysite.spiraservice.net. This is the start of every URL you use when using SpiraPlan/Services/Webhooks/TestService.svc/OctoPerf?username={{username}}&api-key={{api key}}The final URL will look like this: https://mysite.spiraservice.net/Services/Webhooks/TestService.svc/OctoPerf?username=hobikdoc&api-key={11111111-1111-1111-1111-111111111111}
[PR:1]) appears in the name field. Note: you need to complete the above step for every OctoPerf scenario that you want to connect to SpiraPlan. Each scenario must have the product token in its name.
"},{"location":"SpiraApps/OctoPerf/#using-the-spiraapp","title":"Using the SpiraApp","text":"To use the SpiraApp to start a new OctoPerf Action go to a test case in that product.
You must make sure:
the custom property \"octoperf-scenario-id\" is correctly filled in. To find scenario id:
Once the test case has the scenario id filled in, at any time you can click on the OctoPerf button in the top toolbar. This opens the dropdown. Click \"Start Test Scenario\" to start the test scenario on OctoPerf. You will see an info message telling you the Action has started.
Because a test can take a while to run, do not expect to automatically see the test run and updated test execution status as soon as the info popup goes away. It may take a few minutes or more for the test run to be recorded. The test run created will have information about the test scenario in the Console Output, including a link to view the full report in OctoPerf itself.
The execution status is determined based on the test status passed from OctoPerf:
OctoPerf SpiraPlan Passed Passed Failed Failed Error Blocked"},{"location":"SpiraApps/Requirement-Multi-Approvers/","title":"Requirement Multi Approvers","text":"This SpiraApp functionality is limited to SpiraTeam and SpiraPlan
This SpiraApp lets you create groups of customizable tasks against requirements to ensure multiple named users must approve a requirement before it can progress through the workflow. Product admins can create groups of tasks with a consistent description and name style, but with specific assigned users and types. Requirement users can create these task groups that link to the relevant requirement. Widgets on the product home page and My Page help users manage these approval tasks. Note that Tasks are not available in SpiraTest.
About this SpiraApp
Once the SpiraApp has been activated system wide, the system admin can set the number of approval tasks that should be shown on the My Page widget. If this setting is left blank then five tasks will be shown. You can show up to a maximum of fifty approval tasks.
"},{"location":"SpiraApps/Requirement-Multi-Approvers/#product-template-setup","title":"Product Template Setup","text":"In the product template for each product that uses the requirement multi approvers, you need to setup a dedicated custom field. This powers the SpiraApp's widgets. Create a boolean task custom property called \"IsApprovalTask\" exactly.
"},{"location":"SpiraApps/Requirement-Multi-Approvers/#product-settings","title":"Product Settings","text":"Once the SpiraApp has been activated system wide, and enabled for a product you can edit its product settings.
First, pick the \"IsApprovalTask\" custom property from the dropdown for the IsApprovalTask Flag field. This will make sure that the product home page widget will work correctly.
To create a multi approval group, fill in Multi Approval Groups text box. Each group should be on its own line. For each group you specify:
Start each line with the group name, then a \"|\", then the task name prefix followed by \"|\", then the task type followed by \"|\", then a comma separated list of usernames. Your final line should be in this format: List name | Task name prefix | Task type name | username, username, username\u2026
Example multi approval groups
Business Review | Pending Approval: | Management | amycribbins, bernardtyler, fredbloggs
In this example we are creating a group:
QA Review | | | amycribbins, fredbloggs
In this example we are creating a group:
All approval tasks across all groups can share a default task description. Fill in the Task Description rich text field with any required text. This lets you provide standard instructions to all approvers.
Finally, you can set the number of approval tasks that should be shown on the product home page widget. If this setting is left blank then five tasks will be shown. You can show up to a maximum of fifty approval tasks.
"},{"location":"SpiraApps/Requirement-Multi-Approvers/#using-the-spiraapp","title":"Using the SpiraApp","text":""},{"location":"SpiraApps/Requirement-Multi-Approvers/#requirement-details-page","title":"Requirement Details Page","text":"When a user goes to the requirement details page, they will see an extra button in the toolbar. To add a group of multi approval tasks they should follow these steps:
A message will show at the top of the page stating that the tasks are being created. This message will disappear after all the approval tasks have been created. You can see the new tasks on the requirement's task tab. Below is an example.
Each of the multi approval tasks created has the following fields set:
This widget displays open multi approval tasks in the product (or for the release in that product if the page is set to display for a particular release). Approval tasks are shown in order of when they were created (oldest first). The widget is available on any of the product home pages. To add the widget to a page, edit the page and then open the \"SpiraApp Widgets\" section. Add the widget to the section of the page you want.
The number of rows shown matches that in the product settings for this SpiraApp (up to a maximum of 50). For each row you see:
Note that only approval tasks that have the IsApprovalTask custom property present and set to Yes will show on the widget.
This widget displays open multi approval tasks assigned to the current user. Approval tasks are shown in order of when they were created (oldest first). When the My Page is set to show content for \"All Products\" the widgets shows approval tasks system wide. When the My Page is set to show content for \"Current Product\" the widgets only shows approval tasks (if any) in the current product.
To add the widget to a page, edit the page and then open the \"SpiraApp Widgets\" section. Add the widget to the section of the page you want.
The number of rows shown matches that in the system settings for this SpiraApp (up to a maximum of 50). For each row you see:
Note that only approval tasks that have the IsApprovalTask custom property present and set to Yes will show on the widget.
"},{"location":"SpiraApps/Task-Test-Presets/","title":"Task and Test Presets SpiraApp","text":"Some of this SpiraApp's functionality is not compatible with SpiraTest
This SpiraApp lets users quickly create preset tasks or tests cases for a specific requirement or release. In this way, users can with a single click create, for example, 8 preset development tasks against a requirement, or generate a handful of approval tasks for another requirement. Note that Tasks are not available in SpiraTest.
About this SpiraApp
Once the SpiraApp has been activated system wide, and enabled for a product you can edit its product settings.
To create task or test case presets, fill in the relevant text boxes (tasks and test cases for requirements, and tasks and test cases for releases). Each preset should be on its own line.
Start each line with the preset name, then a colon, then a comma separated list of artifact names. To give the artifact a type add a | and the type name after the artifact name.
Example task preset
Development Checklist:Design Screen,Develop Screen,Write Test Cases|Testing,Update Documentation.
In this example we are creating a preset:
When a user goes to the requirement or release details page, they will see an extra button in the toolbar. To add a preset group of tasks or test cases they should follow these steps:
A message will show at the top of the page stating how many tasks or test cases are being created. This message will disappear after all the artifacts have been created. You can see the new items by going to the relevant tab. Below is an example task tab of a requirement where we have added some preset tasks.
"},{"location":"SpiraApps/Task-Test-Presets/#extra-details-to-be-aware-of","title":"Extra details to be aware of","text":"This SpiraApp lets you integrate SpiraPlan and the Worx desktop application.
About this SpiraApp
If the SpiraCapture icon doesn't appear at the top right of your screen, go to chrome://extensions to make sure the extension is enabled (check that the toggle in the bottom right of the extension card is lit up blue, if not click it to turn on the extension).
"},{"location":"SpiraCapture/User-Guide/#how-to-start-capturing","title":"How to start capturing","text":"To start capturing click the SpiraCapture icon in the toolbar, which should bring the SpiraCapture menu.
You should see a \"Start capturing\" button to capture the current tab. **Note: ** this will only capture the current tab you are on! If you would like to capture other tabs repeat this step. **Warning: ** if you have just enabled the extension, you need to refresh the tab before capturing will work.
You can tell if SpiraCapture is capturing the current tab, because the SpiraCapture icon in the toolbar will show in color. When it is not capturing a tab, the icon is shown in grayscale.
"},{"location":"SpiraCapture/User-Guide/#what-event-triggers-data-to-be-captured","title":"What event triggers data to be captured?","text":"A number of events trigger SpiraCapture to capture how the user is interacting with the current browser tab:
Additionally, there are a few ways that data can be captured manually by the tester, by interacting with the SpiraCapture menu. These give users flexibility in organizing the captured data to reflect their test.
Clicking the SpiraCapture icon from the browser toolbar will show the SpiraCapture menu. This gives you access to the main functionality of the extension.
When you click the \"View data\" link from the SpiraCapture menu the tab that opens shows all data collected. This page is divided into three parts:
Each of these areas is explained in more detail below.
"},{"location":"SpiraCapture/User-Guide/#the-event-list","title":"The event list","text":"The event list is shown on the left hand side of the page. Every event is shown in chronological order, broken down into testing steps (which can be manually created by the user and incremented automatically over time).
Each step has a heading which shows the name of the step and the time that particular step started. If the step contains any notes, a pin icon is shown in the step heading. This is designed to help you see which steps have notes in as these are likely the steps that you want to examine more closely. Clicking on the step heading will collapse or expand the events inside the step.
Each event shows certain standard information to make it easy to navigate and browse the data.
Each event also has a checkbox on its left. Checking the checkbox will mark that event as selected. Only selected events are sent through to Spira when logging new incidents.
"},{"location":"SpiraCapture/User-Guide/#the-preview-window","title":"The preview window","text":"Clicking on an event with a screenshot will display in the large preview window on the right hand side of the page. This is helpful if you want to see a screenshot in more detail.
"},{"location":"SpiraCapture/User-Guide/#the-action-bar","title":"The action bar","text":"The action bar has four buttons:
You can send all selected events to Spira as a single new incident. Once connected to Spira, as explained below, you choose a product, fill out the incident creation form and then create your incident. The selected events, including their screenshots, will be saved into the description field of the new incident.
"},{"location":"SpiraCapture/User-Guide/#connect-to-spira","title":"Connect to Spira","text":"First, make sure you have enabled API access to Spira. You do this from your Profile Page from within the Spira application. Make sure you enable rss and generate an RSS Token. This RSS token is the same token you use for API access, which is what SpiraCaptures uses.
Note This can be disabled be you or your administrator make sure you have it enabled if you would like to use this feature see warnings section below
Clicking the Send selected events to Spira button will show a popup. The first time you see this popup you will need to enter your connection credentials:
Once you are logged in to your Spira (and have your events selected) the popup will require at least 3 fields to be selected/filled in.
Once these have been filled in, click the \"Send data to Spira\" button to connect to your Spira application and upload the incident. Once the incident has been created you will see a link next to the send button that will open the incident in Spira for you.
"},{"location":"SpiraCapture/User-Guide/#potential-gotchas","title":"Potential Gotchas","text":"In this guide we will learn about the different parts of the application, how to use them, and how they fit together.
You don't need to know how to use the application already, and you don't need to be familiar with application management tools, or agile, or waterfall.
All you need to get started is the application itself.
You say SpiraTest, I say SpiraPlan
The SpiraPlan family of applications comes in 3 different editions:
Whatever flavor of Spira you have (we will say \"Spira\" from here on) you can use this Quick Start Guide. To learn more about the differences between the different Spira editions, take a look at our detailed comparison chart
"},{"location":"SpiraPlan-Quick-Start-Guide/#introduction","title":"Introduction","text":"Let's go on a journey together. In fact, let's go to Mars! For a vacation. We deserve it. In this Quick Start Guide we use SpiraPlan to help us plan and prepare for our Mars trip.
This Guide is split into different parts, the different stages of our preparation before the big launch.
We recommend doing things in order if you can. This will really let you see the power of how SpiraPlan helps you connect your work together. This in turn helps you better understand your progress and better meet your goals. That being said, this is your time and your time is precious. We have designed this guide so that you can dip into any part you want at ant time. However you approach it and whatever edition of Spira you have, there will be clear signposts and tips to guide you along the way.
Enough explaining, let's start doing...
"},{"location":"SpiraPlan-Quick-Start-Guide/#start-using-the-application","title":"Start using the application","text":"What you will learn
You have a brand new SpiraPlan application ready to go. This is either in the cloud or on-premise. First, go to the home page of the application in your browser to get to the login page:
Login using the default admin account:
You are now logged-in and will see the \"My Page\". The My Page looks pretty empty right now. This is normal.
The first time you log in you will see a popup that gives you a quick orientation of the application. Please follow this guide first.
Getting Help in the App
On every page of the application there is a link to go to the documentation for that specific page. Feel free to use that at any time.
To access it: click your icon / avatar in the upper right to open the user menu, then click on the link called \"Documentation\"
"},{"location":"SpiraPlan-Quick-Start-Guide/#products","title":"Products","text":"To start getting things done in the application you need to select a workspace to explore, manage, or work on. The most common and important workspace is the product. This is where you and your team will spend most of their time in SpiraPlan. Products are long running areas of work with tangible outputs or goals. This can be a software or hardware product that gets new regular new releases, patches, and features. A product can also be used like a project, where the focus may be a different kind of output or to manage a process.
For this tutorial we want to start with an empty product that has no data in it. By default, the system ships with a couple like this.
The \"Sample Program\" in this screenshot is a program. Programs are used to group products together. Programs can themselves get grouped together into portfolios. We are not going to get into that though.
"},{"location":"SpiraPlan-Quick-Start-Guide/#artifacts","title":"Artifacts","text":"Artifacts are the building blocks of a product in SpiraPlan. Artifacts contain all of the data in the product. Each artifact holds different data and is used in different ways. For instance, requirements are one artifact, and releases are another. They work differently, and are not interchangable. There are artifacts to help you test, plan, track bugs and tasks, and more.
Throughout this guide we will be moving between the different artifacts in our sample product. This will help us focus on one type of activity at a time. You will also see how all these different artifacts fit together like neat little puzzle pieces.
Let's Start
How to access legacy quick start guidesThe legacy version of the quick start guides are available for SpiraTest, SpiraTeam, and SpiraPlan. Click on the name of the product to access its legacy guide.
"},{"location":"SpiraPlan-Quick-Start-Guide/do-the-work/","title":"Doing the work","text":"The story so far (1)
We are going on a vacation to Mars (2). It's a long journey. Like you should do before any big trip, we started by planning out what we have to do. We made some reqirements, tasks, sprints, and even thought about the risks. Now its time to stop planning and start doing.
Workflows are a way of moving an artifact (like a task or requirement) through a series of steps. These steps take the artifact from its creation to its end point. Workflows give you control about the who, how, and what of moving an artifact through specific steps.
For example, a task going from not done to done. In SpiraPlan the task starts as \"Not Started\" and transitions through the workflow steps to \"Completed\". You can mark the task as \"In Progress\" when you have started work but not finished it yet. Maybe the task doesn't end up \"Completed\" - it may get blocked or become obsolete. All of these options are possible with workflows.
If you are starting the quick start guide here
This part of the guide only works if you have already made some requirements and (optionally) tasks for those requirements. If you haven't done this, please go back and do so now.
There are two different ways to \"do the work\" in this part of the guide - you only need to do one:
Using SpiraTest or did not follow all steps on the Plan page?
Skip ahead
We have 4 requirements. We made 4 tasks as well, but one of those tasks never got attached to a requirement. We never added a task to \"Prepare the spaceship\". So why do all 4 requirements show a filled in task progress bar? This is because of a feature called \"rollup\". The task progress from a requirement's children \"rollup\" to the parent. The task progress bar of \"Prepare the spaceship\" is a rolled up combination of the task progress of its two children.
Why are 3 of the task progress bars yellow? Because the tasks have start dates in the past and have not yet started. In SpiraPlan we consider these tasks to be \"starting late\". We never directly set their start dates, but the tasks got their start and end dates from the releases (sprints) they are linked to. The remaining task progress bar is gray because, although it too is still not started, its start date is in the future. Your task progress bars may look a little different if you choose different dates for your sprints.
We are not going to work on the requirements themselves, instead we do the work on the tasks we made.
Let's now complete another task. We will record this in a different way. On the list page, where we are now, you can make any changes to any task at any time. Workflows only let you do certain things at certain times. For the workflow to control what we can do we need to be on the details page for a task.
You may have missed it but as soon as the task status was at \"In Progress\" some names of the different fields went bold and got a star by them. This means they are now required. Most of these required fields are already filled in. But one, \"Owner\" is still blank.
We will now move the task through to completed
3 for 3 hours of work0Let's check our progress.
The task progress bars for 3 requirements are now green. This makes sense because it is the tasks linked to these requirements that we completed. The statuses have also changed. They all had statuses of \"Planned\" and now 3 have the status of \"Developed\". This happened automatically because all the tasks linked to these requirements are now complete. The system sees the requirement has tasks and judges that all the work for those requirements in stored in the tasks. So when the tasks are done, the requirement is done. For now done = \"Developed\": we have done the work but have not yet verified that work.
Why are statuses changing by themselves for requirements?
Requirements do not need to work like explained above. You can set your product up so that whatever you do with tasks, the requirements' statuses do not change. In this quick start guide, we are showing one way of using SpiraPlan, but you do not need to work this way.
Requirement Name Status Prepare the spaceship Developed > Pack my suitcase Developed > Take the right amount of rocket fuel Developed Get a cool spacesuit Planned"},{"location":"SpiraPlan-Quick-Start-Guide/do-the-work/#completing-standalone-requirements","title":"Completing Standalone Requirements","text":"Already completed tasks (above)?
Skip ahead
Let's now finish development on another requirement. We will record this in a different way. On the list page, where we are now, you can make any changes to any requirement at any time. Workflows only let you do certain things at certain times. For the workflow to control what we can do we need to be on the details page for a requirement.
You may have missed it but some fields names of the different fields are shown in bold and have a star by them. This means they are required. Most of these required fields are already filled in. But one, \"Importance\" is still blank.
We will now move the task through to completed
Let's check our progress.
We changed the statuses of 2 requirements, but 3 requirements now have different statuses. They all had statuses of \"Planned\" and now 3 have the status of \"Developed\". This happened automatically because when all of a parent requirement's children change their status, the parent status changes too.
Requirement Name Status Prepare the spaceship Developed > Pack my suitcase Developed > Take the right amount of rocket fuel Developed Get a cool spacesuit Planned"},{"location":"SpiraPlan-Quick-Start-Guide/do-the-work/#summary","title":"Summary","text":"You're doing great!
What's next? According to our requirements all our work to prepare the spaceship is developed, but we need to know for sure. In the next part, we will check our work, to make sure our tasks and requirements do what they are supposed to.
"},{"location":"SpiraPlan-Quick-Start-Guide/plan/","title":"Plan","text":"We will spend the first chunk of this guide planning things out. We start by outlining the big features and goals we need to deliver. Then we break those down into smaller tasks. Once we know the scope of the work we can plan out our time. This let's us plan out when we need to do each of our tasks and deliver on our goals. With that the planning is almost complete. Before we move onto the next section we should think about the risks that things could go wrong, or go off track.
The story so far (1)
We are going on a vacation to Mars (2). It's a long journey. So it's a good idea to plan it out first, instead of jumping into the first rocket for Mars you can find. We've logged into SpiraPlan and we are ready to go.
Requirements are also known as features, or user stories. Different frameworks and methodologies call them different things and use them in different ways. SpiraPlan is methodology agnostic so you can use requirements however you want.
Often, as you work with requirements or features you need to structure your requirements with some nested inside others. SpiraPlan gives you full support for hierarchically arranging your requirements.
We've decided on our vacation destination: Mars. Currently, we're on Earth, don't have a rocket, and have got a lot to do. We need to make a list of our big goals. SpiraPlan uses \"Requirements\" as the artifact (the item type in the application) for tracking these major goals.
Not all features are available in SpiraTest. SpiraTeam takes SpiraTest and adds some features, SpiraPlan adds even more. Below you can see the requirements page as it looks for SpiraTest. Only features that SpiraTest supports are available in the app. Compared to SpiraTeam or SpiraPlan it does not have the \"Task Progress\" column, because SpiraTest does not include tasks.
In the rest of this guide we normally show screenshots of SpiraPlan. If you are using SpiraTest or SpiraTeam you may see columns or tabs or widgets on certain screenshots that you do not have. This is expected.
Let's make some requirements. In SpiraPlan, there is almost always more than one way to do something, but let's start out simple.
Prepare the spaceshipGet a cool spacesuitWe've made a great start. We have two requirements. Let's add a couple more and see how easy it is to nest requirements inside others.
Pack my suitcaseTake the right amount of rocket fuelYou will see your 4 requirements and the top one has a different icon. This shows us that it is a parent requirement that has children nested inside it.
Requirement Name Position Prepare the spaceship Parent > Pack my suitcase Child > Take the right amount of rocket fuel Child Get a cool spacesuit By itself Other ways to add and position requirementsIf you have a list of requirements and want to make one a child of the requirement above it, select the requirement and click the \"Indent\" button on the toolbar. Use the \"Outdent\" button to move a child requirement out one level.
You can also right click on a requirement to indent or outdent them.
Click and drag requirements to move them around and change the order.
Select a requirement then click the \"Insert\" button. This adds a new requirement above the selected requirement.
Click the \"Insert\" button with no requirements selected. The new requirement is added at the end of the list of requirements as a sibling of the requirement above it.
"},{"location":"SpiraPlan-Quick-Start-Guide/plan/#make-tasks","title":"Make Tasks","text":"Skip this section if you are not using SpiraTeam or SpiraPlan
Skip ahead
Tasks are available in SpiraTeam and SpiraPlan. Tasks are used to define specific chunks of work to do.
They can be used in lots of different ways in SpiraPlan. A great way to use tasks is to link them to big pieces of work, to better manage and track what has to get done when. You can create tasks for requirements, that are then tied to sprints, so you can easily see your progress in finishing all relevant tasks.
"},{"location":"SpiraPlan-Quick-Start-Guide/plan/#tasks-from-requirements","title":"Tasks from Requirements","text":"Start here if you have created requirements
Otherwise skip ahead
We wrote out some top features we need for our Mars vacation to be a success. These requirements are very broad. It is a good idea to break them down into smaller chunks of work - tasks. Let's create some tasks for some of our requirements!
Congratulations! You have made one task. In real life you would make a few more so that the requirement has 2 or 3 or more tasks on it. For now, let's try making a task on a different requirement
We've made tasks directly from a requirement. These tasks are directly linked to the requirement. But we can also make tasks a different way, which we will try now.
"},{"location":"SpiraPlan-Quick-Start-Guide/plan/#standalone-tasks","title":"Standalone Tasks","text":"Book a spacesuit test fittingSet 'out of office' before launch dayWe now four tasks in total (two if you have only created standalone tasks). The task we made about our spacesuit fitting is actually part of our requirement (if you made it) to get a cool spacesuit. We made this task independently of that requirement, but we can still link them together.
Releases let you create a list of different releases or sprints for the product. They can be nested to create a hierarchy of releases.
Releases let you divide up your product or project into smaller blocks of time. If preparing for our vacation to Mars will take a year, you can use releases to plan what you will do every two weeks, or every month. Because releases are mostly time bound, their start and end dates are really important. You can have multiple releases on the go at the same time.
In SpiraPlan releases have lots of special properties. By themselves they are simple, but as you link up more and more things (using other artifacts) the more powerful releases become.
We're making good progress with our Mars vacation. We have worked out the top areas of work left to do and made some tasks for them. Next, we move from thinking about the what to thinking about the when. That's where releases come in.
The main list in the middle of the page is empty. Let's change that.
Build spaceship. Good news! We've already finished building the spaceship. Let's make this clear by marking this release as finishedLet's add two more releases - these won't be completed yet.
Prep for launch as the name of the new release2.0Lift off and a \"Version #\" of 3.0. Leave the \"Status\" as \"Planned\"The story so far
We have planned out the things we need to get done before we head to Mars. And we've created releases so we can track what we do and when we need to do it.
Currently, our what (things to do) are not linked up to our when (releases). Let's fix that.
If you have not made any requirements or tasks you can go back and do that now or skip this section.
"},{"location":"SpiraPlan-Quick-Start-Guide/plan/#set-releases-for-requirements","title":"Set Releases for Requirements","text":"First, we are going to set the release for our requirements.
Skip this section if you are not using SpiraTeam or SpiraPlan
Skip ahead
Let's hook our tasks up to releases.
Look at the release column of your tasks. Three of them already have a release set. This is because they are linked to requirements, and we just set the release for the requirements. That release information flows from the requirement to any of their linked tasks.
Why is the Task Progress bar yellow for some tasks?
Because the release these tasks are linked to has been started (its status is \"In Progress\") but the tasks have not started yet, we flag their progress as yellow
Our two tasks do not have a release yet, so let's change that.
Skip this section if you are not using SpiraPlan
Skip ahead
Risks let you set up a full risk management solution for your products. You can log and track risks at any time and link them up to releases as well as other artifacts.
Each risk can have a probability and an impact to help you analyze each risk's exposure. Add risk mitigations to track how you are treating the risk.
The more we think about this vacation to Mars, the more we realize it is kind of risky. These risks may make our trip of a lifetime kind of suck. Just thinking about all the ways things can go wrong is not very productive. Instead, we should write things down so we can manage the risks and not be scared of them.
Fly right on past Mars for the name (at the top of the page)Spaceship computer turns evil for the name (at the top of the page)Let's now add some ideas about how we can manage (or mitigate) this risk. We do so by creating mitigations, because we really, really need that computer to treat us well.
Be its friendKnow how to turn it off into the descriptionYou have created two mitigations on this risk and created two risks in total.
Risk Name (with mitigations) Release Fly right on past Mars 2.0 - Prep for launch Spaceship computer turns evil 3.0 - Lift off > Be its friend N/A > Know how to turn it off N/A"},{"location":"SpiraPlan-Quick-Start-Guide/plan/#summary","title":"Summary","text":"Congratulations we have now finished planning!
Our vacation to Mars is taking shape. But there is still lots more to do. In the next part of this quick start guide we will learn how to manage our work with SpiraPlan and get things done.
"},{"location":"SpiraPlan-Quick-Start-Guide/review/","title":"Review and Next Steps","text":"The story so far (1)
We are going on a vacation to Mars (2). We've been busy planning, preparing, and checking things for the long journey ahead. Are we ready to leave or not? What is left to do? That's what we are going to find out in this final core section of the SpiraPlan Quick Start Guide.
If you haven't followed the guide all the way through
We are going to see how the different artifacts link together. So, you really need to have done all the parts of the quick start guide to see this in action on your installation. If you haven't, you will be able to see how things could work, which will still be useful.
We left on the test case list page. We have two test cases and one of them has failed. Before going to Mars you want your tests to all pass, so you know that the trip will go as smoothly as possible.
We already have a hint with that failed test that our trip may need a little more work. Let's look around and find out.
The first 3 requirements are for release 2.0 (the one we are currently working on).
The statuses are also still at Developed. They haven't moved to \"Tested\" because our testing is not complete yet
Open the Artifact dropdown from the global navigation and click \"Releases\" under the Planning section
We have three releases. One was finished before we started this guide, one has not yet started, and the third (release 2.0) is the one we are working on. This is the one our requirements, and by extension, tasks and tests are linked to.
From a quick glance here, we can see that the \"Prep for launch\" release is not ready. We are not going to take action on this yet. Instead, let's take a look at one more place to review things. This time at the product wide level.
"},{"location":"SpiraPlan-Quick-Start-Guide/review/#reviewing-the-product","title":"Reviewing the Product","text":"There's a lot of information on the Product Home Page. The page is divided into widgets that each display different information. Together they give you a useful overview of the state of your product. You can customize how this page looks for you for every product. Below is the default view you will see when looking at the page for the first time.
What can we see from these widgets?
This quick start guide ends here. We've done a lot together, but the rest is up to you.
For this vacation to happen you need:
tasks done
tests to pass
bugs to be fixed
risks to be managed
requirements completed
releases to be ready
Even if we only focus on the \"Prep for launch\" release, apart from the tasks, you still have a lot to do. You can stop here, just like this guide. Or you can play around and and see if you can get this release 100% ready.
SPOILERS: Hints to finish the releaseWant some help about what you need to do, to get everything looking great? We've got you!
What success looks likeSpecific stepsRequirements:
Release 2:
Product Home Page: the screenshot below only displays data for the \"Prep for launch\" release (using the dropdown in the top left). The layout here is customized with specific widgets that show that our requirements, risks, and incidents are all looking good.
Collectively, these will move the three requirements in release 2.0 to the Tested Status. This in turn will make the requirement completion and test coverage for release 2.0 go 100% green.
"},{"location":"SpiraPlan-Quick-Start-Guide/review/#how-to-learn-more-or-get-more-help","title":"How to learn more or get more help","text":"We have lots more ways to help you get to know SpiraPlan better!
First, there is our online documentation that you are already reading. Here are some helpful links:
There is also the Inflectra support portal. Here you can read knowledge base articles, ask questions in the forum, or log a ticket with the support team.
"},{"location":"SpiraPlan-Quick-Start-Guide/test/","title":"Checking the Work","text":"The story so far (1)
We are going on a vacation to Mars (2). It's a long journey. We spent time planning the trip, and then doing the most important tasks. Before we blast off without a care in the world, let's check that we did everything right.
There's a lot to check before going on any trip. All the more so when traveling over 100 million miles. We need to stay focused. We made a few releases and work happens in each.
Let's focus on just one of those releases \"Prep for launch\". Three of our requirements should get delivered in this release / sprint. Because of our work in finishing tasks on these requirements, they all have a status of \"developed\". This is perfect, because it means the development (doing) work is done. The next step is to verify things. In SpiraPlan, we verify with the Test Case artifact.
"},{"location":"SpiraPlan-Quick-Start-Guide/test/#create-some-tests","title":"Create some Tests","text":"If you are starting the quick start guide here
Don't worry! You can create tests and execute them without doing the earlier steps in this guide. Some of the details may not apply to you, importantly linking our tests to requirements and releases. But don't let that stop you.
Test Cases are the main unit of testing in SpiraPlan. A Test Case defines a scenario or user flow that you want to verify. A Test Case is made up of Test Steps. These steps are the sequence the tester needs to go through and check. Each test step is an opportunity to verify functionality is working as it should, or recording where there are problems.
First you create your test cases, then you execute them. Test execution records the results of what you did or found. You can execute the same test many times and keep a list of records of what happened each time. These are called Test Runs. This system means you have test cases that you can reuse very efficiently. Each test run logs the execution status of that run (eg pass or fail). Together with requirements and releases, test cases help you have full traceability across your whole product.
Verify suitcase is well packedCheck if the spaceship computer seems niceDidn't make any requirements?
Skip Ahead
This is great. We have already created two test cases. We could start running these tests now, but first let's hook these tests up to requirements and releases.
These actions link each test case to the correct requirement. Because the requirements are already connected to a release, the test cases are automatically linked to the correct releases. So by adding a requirement to a test case we also added a release. Neat. You can link many requirements to a test case. And you can independently add many releases to a test case as well. Our setup for now looks like this:
Test Case Name Requirement Coverage Release Coverage Check if the spaceship computer seems nice Prepare the spaceship 2.0 - Prep for launch Verify suitcase is well packed Pack my suitcase 2.0 - Prep for launch"},{"location":"SpiraPlan-Quick-Start-Guide/test/#execute-a-test-case","title":"Execute a Test Case","text":"Test Execution in SpiraPlan has a dedicated module for running manual tests. This makes it easy for testers to see what they have to test each step of the way. They can quickly record results and log bugs. SpiraPlan also supports other types of tests, including automated tests and unit tests. These tests are not managed from the test execution module.
Now that we have a very simple test case, we can execute it to check if things are working as they should. Above, we said that test cases in SpiraPlan are made up of Test Steps, which are the steps the tester needs to go through and check. You can add as many steps as you want to a test case, and customize them to exactly your needs.
We didn't make any test steps on our test cases. Without steps there's nothing to actually verify! Don't worry, SpiraPlan automatically made a test step each time we made a test case. These test steps are emtpy, but they are enough for us to try out executing tests.
This will launch a popup showing you that the Test Run is being prepared for execution from the test case. Once it finishes, you will see the Test Execution Wizard. On this screen you can: pick a release to execute the test run against; and set any test run custom properties. You can see that the Release is currently set to \"1.0.0.0 - Build Spaceship\", because it is the first release in the list.
The test case is about our suitcase packing, which is part of our sprint to prepare for launch (release 2.0). So let's make sure to run the test against the correct release.
When you go to this page for the first time, you can go through a guided tour of how the page works
As a tester, you move through each of the test steps in the test run in order. Each test step needs a result: Pass, Fail, Blocked, Caution, or Not Applicable (N/A). If you enter any status other than Pass you need to enter a value for the \"Actual Result\". For a pass status, the Actual Result is optional.
We only have one test step. If we thought our packing was great, we could mark the step as Passed. That means the whole test run has passed, so we could finish the test run and officially log its results. That's no fun, so let's do something else.
Cannot close suitcase because of all the snacksBefore we finish testing, we have one more thing to do. We failed the test and now we should log this failure with an incident.
Why create an incident?
Creating an incident (or a bug) during testing is the perfect way to capture what is wrong so someone can fix it (like a developer, or here whoever has to pack the bags). The incident is linked to the exact test step that failed.
You can then track this bug outside of testing. Once the bug is fixed, the tester can rerun the test case and see if things are fixed.
There are too many snacks to fit in the suitcaseAfter clicking \"Add\" the incident is created and the Incident tab shows us that the incident is linked to this test step.
We are now ready to finish our test.
This will take you back to the Test Case list page. Here we see the two test cases, and we can see that \"Verify suitcase is well packed\" is marked as failed.
Test Case Name Execution Status Check if the spaceship computer seems nice Not Run (gray) Verify suitcase is well packed Failed (red)"},{"location":"SpiraPlan-Quick-Start-Guide/test/#summary","title":"Summary","text":"Almost there!
In the next and final part of this quick start guide we will review where things stand for our Mars vacation. How can SpiraPlan help us work out if we are ready to blast off, or if we are destined to stay stuck on Earth? Let's find out.
"},{"location":"SpiraPlan-Quick-Start-Guide-Legacy/","title":"SpiraPlan Quick Start Guide","text":"Want to access the new and improved Quick Start Guide?
This SpiraPlan quick start guide still works great, but we have a newer and greater quick start guide. Please feel free to check it out.
"},{"location":"SpiraPlan-Quick-Start-Guide-Legacy/#logging-in-and-selecting-a-product","title":"Logging In and Selecting a Product","text":"Once you have installed a self-hosted trial or signed up for a hosted trial of SpiraPlan, you should see the following login screen in your web browser:
Enter the following default details to start using the system:
Login: administrator
Password: PleaseChange
Once logged-in, you are shown your \"My Page\". The very first time you log in you will be able to take a quick orientation tour of the application (as shown in the screenshot below).
The My Page looks pretty empty right now. This is normal.
For this tutorial we want to start with an empty product that has no data in it, so click the hyperlink under 'My Products' for 'Sample Empty Product 2' / 'Sample Program'. That will select the empty product. Now to see the homepage for the product you just selected, click on the hexagon in the top left:
The product home page shows various widgets containing key product metrics. These are empty now, because the product has no data in it. In the rest of this guide we are going to fix that.
"},{"location":"SpiraPlan-Quick-Start-Guide-Legacy/#define-the-requirements","title":"Define the Requirements","text":"On the main Navigation bar, click Artifacts > Requirements to display the product's requirements list page:
The terminology in SpiraPlan is designed to be methodology agnostic. The table below shows how the terms used in SpiraPlan relate to some common methodologies:
SpiraPlan Extreme Programming Scrum AgileUP / DSDM Summary Requirement Epic Epic Feature Group Requirement User Story Backlog Item Requirement Task Task Task Task Release Release Release Release Sprint Iteration Sprint IterationAt first, the requirements list will be empty. Click the 'Insert' button in the toolbar to create your first requirement. Hit 'Save and New' (shown as buttons on the right of the new requirement in the list table) to add each new requirement after that except for the last requirement. After entering the last requirement, hit \"Save\" button. Below is the list of requirement names to add:
Functional Requirements
Module 1
System must allow entry of users
System must allow the modification of users
System must allow the deletion of users
Module 2
System should allow administrators to setup notifications
You should now have a simple, flat requirements list, like the one below:
Next, we are going to indent the requirements. This will give us a hierarchy, with some requirements being children of others.
To indent, select the checkboxes of all the requirements below 'Functional Requirements' and click 'Indent'. This makes 'Functional Requirements' the parent and all the other requirements its children.
Now, select the three requirements immediately below 'Module 1' and click 'Indent' again. This makes these three requirements children of 'Module 1' (and grandchildren of 'Functional Requirements').
Repeat for the requirement below 'Module 2' by right-clicking on this last requirement and choosing 'Indent' from the popup context menu.
You should now have a list that looks like:
We now have a nicely grouped set of requirements. Let's enter more information about them, starting with setting their types and priorities.
Save button.You now have a prioritized list of user story requirements:
The next thing we can do is assign estimates to each requirement. This is something that the developers or business analysts may do based on the complexity and scope of each. The 'Estimates' column is not visible yet, so first we need to show it. To do that, click on the 'Show/Hide Columns' dropdown list and select 'Show Estimate (points)':
By default, all the requirements will have been assigned a default estimate of 1.0 point. A point is not a defined number of hours, but an indication of the size of the requirement. The estimates should reflect how big each of the requirements are relative to each other.
To change the estimates:
Click the \"select all\" checkbox at the top of the list
Click on the top 'Edit' button in the right-hand column. The requirements should be in editable mode again.
Enter the following estimates for the requirements
Click Save
Your requirements should now look like this (with each parent's estimates automatically summing up the estimates of their children):
We have created a list of prioritized, estimated requirements, which is a great way to start our product. In the next section we are going to enter releases and sprints.
"},{"location":"SpiraPlan-Quick-Start-Guide-Legacy/#create-the-release-and-iteration-plan","title":"Create the Release and Iteration Plan","text":"On the main navigation bar, click out of 'Requirements' and select 'Releases' menu option to display the product's release list page:
The release list will be empty. Click the 'Insert' button in the toolbar to create your first release. Hit 'Save and New' (shown as buttons on the right of the new release in the list table) to add each new release after that. Below is the list of release names to add:
Release 1.0
Release 1.1
You should have a list of releases like this:
We need to add one additional level of detail to each release -- the list of sprints that will take place in each release.
Let's add some sample sprints for the first release:
Insert > Child ReleaseSave And NewSave on the final sprint's row. You should have three sprints added to the list, all children of Release 1.0.
Finally, let's specify the number of resources assigned to each sprint and release.
Edit button on the toolbarSaveWe have defined the high-level schedule for Release 1.0. The next stage is to have the developers take each of the requirements defined so far and define the various tasks needed to deliver them. Each task will have its own estimate associated with it. In addition, you can optionally specify date ranges and priorities to each of the individual tasks.
To start adding tasks, go to the main navigation bar and click out of Releases and hit Requirements to display the requirements list. Click on the hyperlink for the first requirement (\"System must allow entry of users\") and the requirement's details page will be displayed:
Notice that under 'Dates and Times' column on the right, the system displays an initial resource estimate of 1.5 points and 12 hours. This is based on an initial product setting of 8 hours per story point. Once you start adding tasks and getting metrics based on the actual team velocity (how many story points they can accomplish in a given time frame), the system can update that conversion metric.
Click on the 'Tasks' tab to display the list of tasks defined for this requirement. The list is empty, so let's change that:
New Task button (this adds a new task and associates it with this requirement)Save.The new task has now been added:
We have more tasks to add. The table below shows 12 tasks in total to add to 4 different requirements. This includes the one we just created for completeness.
Requirement / Task Est. Estimate System must allow entry of users Create user data tables 10.0h Develop user business object 10.0h Build user creation screens 20.0h System must allow the modification of users Extend user business object to handle updates 5.0h Add user list page 15.0h Add user details page 20.0h Add user permissions page 15.0h System must allow the deletion of users Extend user business object to handle deletes 5.0h Update user list page to add delete functionality 10.0h System should allow administrators to setup notifications Create user administration home 15.0h Add user settings for notifications to database 10.0h Create user notifications administration page 20.0hOn the main Navigation bar, click again on 'Requirements'. You should now have the following requirements list page. In this screenshot we have hidden the 'Author' field and shown the 'Task Effort' field to show the detailed task effort aggregated up to the requirements.
The total number of hours for these tasks divided by the total number of story points gives a number a lot more than the 8 hours that the system assumes. We can update the system to better estimate the number of hours to deliver each story point.
To update the metric, go to the three cogs dropdown menu on the rightmost corner of the main Navigation Bar, locate Planning and click Planning Options:
As you can see, the system lists 8.0 hours as the current number of hours required to deliver a single story point of functionality. Now that we have some actual tasks in the product, click on the 'Suggest 'button to have the system provide its suggestion of the new metric:
Click the 'Apply' button to update the planning metric, and then click the main Save button at the very bottom of the page to confirm the change.
Click on the Artifacts > Test Cases menu option to display the product's test case list page:
The test case list is empty and the only folder visible in the 'Folders' tree on the left-hand side is 'Root'.
Add button underneath the folder treeAddYou now have a new folder in the 'Folders' tree view. To show it, click 'Refresh'.
Save And NewRepeat the above steps to create 3 more test cases:
You should now have the following test case list:
Next, we need to enter detailed test steps to each test case, and link each test to the appropriate requirements.
In the 'Description' box under 'Detailed Information' section, enter a brief overview of the test case (something like \"this test case verifies that you can add new users to the system and that all of the fields get saved correctly.\").
Scrolling down to the 'Test Steps' section, you will see a single test step has been automatically created for you with some suggested text:
This test case needs 3 test steps.
Click 'Edit' on 'Step 1' and enter the first set of parameters below.
Click Save and then 'Insert Step' to add the second test step and enter its information from below
Click 'Save and New' to make the third step
Once you've entered its information click Save
You should now have the following test steps in the test case:
Next, we need to link this test case to the requirement(s) that it validates.
Choose the 'System must allow the entry of users' requirement
Click the Save button beneath the list of requirements to add the test case to this requirement
Let's repeat the process for the other test cases, adding a couple of test steps to each. Then link the test cases to the requirements according to this table just like you did above:
Test Case Requirement Test ability to add new users System must allow entry of users Test ability to edit existing users System must allow the modification of users Test ability to delete existing users System must allow the deletion of users Test ability to edit notifications System should allow administrators to setup notificationsWe have created test cases and set up their test coverage. Next, we need to specify which releases and sprints they can be tested in.
Select the checkbox of each test case in the 'Functional Tests' folder.
Click on 'Tools' drop-down menu on the toolbar
Click 'Add to Release'
Select 'Release 1.0
Click Add.
You have added all the tests to the overarching Release. Finally, we want to add the tests to the different sprints, based off the data in the table below.
Select the checkbox of each relevant test case in the 'Functional Tests' folder.
Click on 'Tools' drop-down menu on the toolbar
Click 'Add to Release'
Select the appropriate sprint
Click Add
You typically want to include previous functionality in each of the successive iterations to ensure regression coverage. That is what we have done here. This means that each sprint includes new test cases for the new requirements, as well as existing test cases for pre-existing functionality.
"},{"location":"SpiraPlan-Quick-Start-Guide-Legacy/#planning-the-sprint","title":"Planning the Sprint","text":"We have requirements that have tasks, and tests connected to them. What we haven't done yet is scope out which requirements go in which sprint.
Each backlog item (requirement or incident) is represented by a virtual \"story card\" in the iteration. The left-hand side of each item displays the priority color. The progress bar near the bottom of each item depicts the progress of the item. You can flip through each iteration to see the work planned by clicking the left/right arrow buttons at the sides of the screen.
Now drag the two highest priority requirements (the ones with Importance = 1 - Critical) to the first iteration:
In the screenshots above the cards are showing more information then you may see by default. Extra information can be shown by toggling the buttons at the top right of the planning board
To see more information about each requirement, enable the 'Detailed View' option
To see the individual tasks associated with each requirement, select the 'Tasks' option
To see the individual tests associated with each requirement, select the 'Test Cases' option
You can determine how much time has been scheduled in the first sprint and how much time is remaining. Although we have spare time available in Iteration 1, we will leave room left for fixing incidents, so next, drag and drop the remaining two requirements to Iteration 2:
"},{"location":"SpiraPlan-Quick-Start-Guide-Legacy/#assigning-the-requirements-tasks","title":"Assigning the Requirements & Tasks","text":"Now that we have planned which requirements (user stories) and tasks are planned for each sprint, we can assign tasks to the appropriate developer(s). The process you follow will depend on your methodology (e.g. in Scrum the developers pick the tasks, but in Extreme Programming the product manager usually assigns tasks).
To assign the tasks, go to the main Navigation Bar and click on Artifact > Tasks to display the main tasks list page:
Click on the 'Board' option on the top-right of the screen to change to the Kanban board view:
You can see at a glance which tasks are in each status (in this case, they are all marked as 'Not Started'). To see the distribution of tasks by person for a specific sprint, change the release selection to 'Release 1.0 Iteration 1', and the 'Group By' dropdown to 'By Person':
For our sample product, we have two product members listed (included ourselves). As an example, select the first four tasks (which are all priority = 1 - Critical) and drag them to your user's section:
Now you can clearly see the four tasks that have been assigned to your user. To simulate how this would appear to a developer, click on the main SpiraPlan icon (in the top-left) to display your user's \"My Page\" dashboard:
This page lists all the development tasks that have been assigned to your user. Click on the task \"Create user data tables\" to display the task details page:
This task has been estimated at 10.0 hours and is currently not started. The next step is to start working on the assigned task and report back progress. As an example:
Operations button and choose 'Start Task'Save at the top of the pageThe progress indicator will reflect the changes and the new comment will have been added.
Now click on the other three assigned tasks, start them, and specify the following:
Requirement / Task Est. Estimate Actual Effort Remaining Effort Create user data tables 10.0h 3.0h 5.0h Develop user business object 10.0h 2.0h 7.5h Build user creation screens 20.0h 3.0h 18.0h Extend user business object to handle updates 5.0h 0.5h 4.0hAfter updating the assigned tasks, the 'My Page' dashboard will show all these changes:
Similarly, for the product manager, click on Requirements from the artifact dropdown in the global Navigation Bar to display the requirements list. This will show the task progress as it impacts the various requirements:
"},{"location":"SpiraPlan-Quick-Start-Guide-Legacy/#scheduling-the-testing-activities","title":"Scheduling the Testing Activities","text":"Now that we have created our test plan for each release and sprint, we need to schedule the test cases for execution by our testers. As an example, we'll create a single test set (also known as a test suite) that contains a list of test cases to be executed by a specific tester.
On the main Navigation Bar, click on Artifacts >Test Sets menu option to display the product's test set list page:
At first, the test set list will be empty and the 'Folders' tree on the left will only show 'Root'.
Add button beneath the folder treeAdd button.SaveYou should now have the following test set list:
Click on the hyperlink for the test set to bring up the test set details page:
Let's add the appropriate test cases to this set. Click the Add button in the 'Test Cases' section halfway down the page to bring up the following panel:
Select the following test cases and click the Save button:
You should now have the following displayed:
Next, let's assign this test set to a specific release and to a particular tester. To do that, choose the following values for the following fields and click Save:
You have now scheduled this test set to be executed by your user by the end of today against the first iteration of release 1.0:
"},{"location":"SpiraPlan-Quick-Start-Guide-Legacy/#running-tests-and-logging-incidents","title":"Running Tests and Logging Incidents","text":"Now that you have scheduled the test set, if you go to the 'My Page' by clicking on the SpiraPlan logo in the top-left, you'll see your newly assigned test set down on the left:
Click the 'Execute' button (with the play icon) to the right of this new test set. That will start the test execution wizard:
On the first screen, the release dropdown list will have been automatically pre-selected to the release specified in the test set. Click 'Next' to move to the first test step in the first test case:
Note that when you first visit this page, you will be shown a quick guided tour of how the page works.
As a tester, you can progress through each of the test steps in each test case in the test set in turn. For each test step you can enter Pass, Fail, Blocked, Caution, or Not Applicable. If you enter any status other than Pass you need to enter a value for the 'Actual Result'. For a pass status, the Actual Result is optional.
Click the 'Pass' button to pass the first test step. As soon as you do, the test will automatically progress to the second test step:
Now for the second test step, enter in the actual result field \"Unable to enter the sample data as the fields were disabled\". Before clicking the Fail button, we also want to enter in the following fields in the Incident form (accessed by clicking the \"Incidents\" tab):
Name: Error displaying user fields
Type: Bug
Priority: 2 - High
Now click the 'Fail' button and you will have recorded a test failure and a new incident/defect:
Now that we have logged the test failure and the new incident/defect, click on a hexagon on the main navigation bar on the left of \"Sample Empty Product 2\" option.
You'll be taken to the product homepage with the requirements and test case metrics now visible in individual widgets (like the Test Execution Status widget shown below):
If you go to the Artifacts > Test Sets page, you also see the status of our test set:
If you go to the Artifacts > Requirements page, you'll see the different requirements' test coverage and the status of the tests associated with each requirement:
The next step in the process is to triage the logged defect and assign it to a developer to be fixed.
"},{"location":"SpiraPlan-Quick-Start-Guide-Legacy/#triaging-issues-and-defects","title":"Triaging Issues and Defects","text":"Now that a new incident has been logged, the next step in the process is to review the incident and assign it to a developer to be fixed. First, click on the Artifacts > Incidents menu item. This will display the incident list page for the product. You can also view the same list of incidents in a Kanban board view.
In either view, click on the hyperlink for the new incident \"Error displaying user fields\". This will display the incident details page:
Save button in the top toolbar.The incident will be assigned to your user for fixing.
To see what a developer would see in real life, go back to the \"My Page\" by clicking on the orange SpiraPlan icon in the top-left of the main Navigation Bar on the top of the screen:
You can see that you've been assigned an incident under the \"My Assigned Incidents\" widget (on the right-hand side). Now click on the hyperlink for the incident to bring up the incident details page:
The status is 'Assigned' and the comment from the product manager is clearly visible. To help you reproduce the issue, you can click on the \"Associations\" tab to display the test run and requirements associated with this incident:
If you click on the test run hyperlink \"Test ability to add new users\", you will see the detailed information about the test execution that resulted in the bug being logged:
This allows the developer to retrace the steps taken by the tester and attempt to reproduce the issue. We are going to assume we can reproduce and fix the issue so we can go right ahead and resolve the incident.
Operations drop-down menu and select 'Resolve Incident'.Fill in the following fields:
Click Save on the main toolbar.
The incident will now change from Assigned > Resolved and an email will be sent to the tester letting them know that they need to retest the test case and close the incident.
"},{"location":"SpiraPlan-Quick-Start-Guide-Legacy/#reviewing-your-product","title":"Reviewing Your Product","text":"You can check on the overall status of the product by clicking the hexagon on the main navigation bar. This will take you to the product home page. Below is what this home page looks like for a more complete product than we have been working through in this quick start guide.
Note how you can change between several views (the buttons on the right) to show different information based on your role or current needs, or only show data for a particular release (see the dropdown beneath the product name on the left).
"},{"location":"SpiraPlan-Quick-Start-Guide-Legacy/#reviewing-a-program","title":"Reviewing a Program","text":"In addition to having dashboards that let you monitor the performance of your product, SpiraPlan has several views available at the program level. These let you group products together into a common program and report on them as a whole.
To see this in action, click on the \"Sample Program One\" link in the main navigation bar.
You can click on the Artifacts > Planning Board tab to display the Program Planning Board (which is similar to the one we used previously for products, except that it is works across multiple products):
There are additional program views that let you see the Releases and Incidents at a program level. Click Artifacts > Releases:
Congratulations
Congratulations! You have now completed the software development and testing lifecycle using SpiraPlan. For more information about any of the features, please refer to the SpiraPlan User Manual.
"},{"location":"SpiraTeam-Quick-Start-Guide/","title":"SpiraTeam Quick Start Guide","text":"Want to access the new and improved Quick Start Guide?
This SpiraTeam quick start guide still works great, but we have a newer and greater quick start guide. Please feel free to check it out.
"},{"location":"SpiraTeam-Quick-Start-Guide/#logging-in-and-selecting-a-product","title":"Logging In and Selecting a Product","text":"Once you have installed a self-hosted trial or signed up for a hosted trial of SpiraTeam, you should see the following login screen in your web browser:
Enter the following default details to start using the system:
Login: administrator
Password: PleaseChange
Once logged-in, you are shown your \"My Page\". The very first time you log in you will be able to take a quick orientation tour of the application (as shown in the screenshot below).
The My Page looks pretty empty right now. This is normal.
For this tutorial we want to start with an empty product that has no data in it, so click the hyperlink under 'My Products' for 'Sample Empty Product 2' / 'Sample Program'. That will select the empty product. Now to see the homepage for the product you just selected click on the hexagon in the top left:
The product home page shows various widgets containing key product metrics. These are empty now, because the product has no data in it. In the rest of this guide we are going to fix that.
"},{"location":"SpiraTeam-Quick-Start-Guide/#define-the-requirements","title":"Define the Requirements","text":"On the main Navigation bar, click Artifacts > Requirements to display the product's requirements list page:
The terminology in SpiraTeam is designed to be methodology agnostic. The table below shows how the terms used in SpiraTeam relate to some common methodologies:
SpiraPlan Extreme Programming Scrum AgileUP / DSDM Summary Requirement Epic Epic Feature Group Requirement User Story Backlog Item Requirement Task Task Task Task Release Release Release Release Sprint Iteration Sprint IterationAt first, the requirements list will be empty. Click the 'Insert' button in the toolbar to create your first requirement. Hit 'Save and New' (shown as buttons on the right of the new requirement in the list table) to add each new requirement after that except for the last requirement. After entering the last requirement, hit \"Save\" button. Below is the list of requirement names to add:
Functional Requirements
Module 1
System must allow entry of users
System must allow the modification of users
System must allow the deletion of users
Module 2
System should allow administrators to setup notifications
You should now have a simple, flat requirements list, like the one below:
Next, we are going to indent the requirements. This will give us a hierarchy, with some requirements being children of others.
To indent, select the checkboxes of all the requirements below 'Functional Requirements' and click 'Indent'. This makes 'Functional Requirements' the parent and all the other requirements its children.
Now, select the three requirements immediately below 'Module 1' and click 'Indent' again. This makes these three requirements children of 'Module 1' (and grandchildren of 'Functional Requirements')
Repeat for the requirement below 'Module 2' by right-clicking on this last requirement and choosing 'Indent' from the popup context menu.
You should now have a list that looks like:
We now have a nicely group set of requirements. Let's enter more information about them, starting with setting their types and priorities.
Click the ''select all' checkbox at the top of the list (the checkbox just above the checkbox for 'Functional Requirements')
Click on the top 'Edit' button in the right-hand column of that same row. That will make all the requirement rows editable:
Change the 'Type' to 'User Story' for some of the requirements - in the example screenshot all requirements that are children (have a single diamond icon and a non bold name) are now user stories.
Choose whatever values you like for the 'Importance' field for each of the requirements.
Click the 'Save' button.
You now have a prioritized list of user story requirements:
The next thing we can do is assign estimates to each requirement. This is something that the developers or business analysts may do based on the complexity and scope of each. The 'Estimates' column is not visible yet, so first we need to show it. To do that, click on the 'Show/Hide Columns' dropdown list and select 'Show Estimate (points)'.:
By default, all the requirements will have been assigned a default estimate of 1.0 point. A point is not a defined number of hours, but an indication of the size of the requirement. The estimates should reflect how big each of the requirements are relative to each other.
To change the estimates:
Click the \"select all\" checkbox at the top of the list
Click on the top 'Edit' button in the right-hand column. The requirements should be in editable mode again.
Enter the following estimates for the requirements
Click 'Save'
Your requirements should now look like this (with each parent's estimates automatically summing up the estimates of their children):
We have created a list of prioritized, estimated requirements, which is a great way to start our product. In the next section we are going to enter releases and sprints.
"},{"location":"SpiraTeam-Quick-Start-Guide/#create-the-release-and-iteration-plan","title":"Create the Release and Iteration Plan","text":"On the main navigation bar, click out of 'Requirements' and select 'Releases' menu option to display the product's release list page:
The release list will be empty. Click the 'Insert' button in the toolbar to create your first release. Hit 'Save and New' (shown as buttons on the right of the new release in the list table) to add each new release after that. Below is the list of release names to add
Release 1.0 -- version number 1.0.0.0
Start Date: Today's Date
End Date: Today's Date + 2 months
Release 1.1 -- version number 1.1.0.0
Start Date: Today's Date + 2 months
End Date: Today's Date + 4 months
You should have a list of releases like this:
We need to add one additional level of detail to each release -- the list of sprints that will take place in each release.
Let's add some sample sprints for the first release.
Select the checkbox for Release 1.0 and, from the toolbar, click Insert > Child Release.
Choose a name for the new sprint
Make sure its 'Type' is set to 'sprint'
Specify its date-range. We recommend making each sprint last 2-weeks and have each one scheduled in series
click 'Save And New'.
Repeat steps 2-5 above, then steps 2-4 and then finally click 'Save' on the final sprint's row. You should have three sprints added to the list, all children of Release 1.0
Finally, let's specify the number of resources assigned to each sprint and release.
Click on the 'Show/Hide Columns' dropdown list and select 'Show # Resources' column
Select the three checkboxes for the sprints of \"Release 1.0\"
Click the 'Edit' button on the toolbar.
Adjust the # resources for the sprints to 2.
Click 'Save':
We have defined the high-level schedule for Release 1.0. The next stage is to have the developers take each of the requirements defined so far and define the various tasks needed to deliver them. Each task will have its own estimate associated with it. In addition, you can optionally specify date-ranges and priorities to each of the individual tasks.
To start adding tasks, go to the main navigation bar and click out of Releases and hit Requirements to display the requirements list. Click on the hyperlink for the first requirement (\"System must allow entry of users\") and the requirement's details page will be displayed:
Notice that under 'Dates and Times' column on the right, the system displays an initial resource estimate of 1.5 points and 12 hours. This is based on an initial product setting of 8 hours per story point. Once you start adding tasks and getting metrics based on the actual team velocity (how many story points they can accomplish in a given time frame), the system can update that conversion metric.
Click on the 'Tasks' tab to display the list of tasks defined for this requirement. The list is empty, so let's change that:
Because we want to enter the estimated effort for each task, before entering the tasks, first click on the 'Show/Hide Columns' dropdown list and hit the 'Show Est. Effort' column.
Click the 'New Task' button (this adds a new task and associated it with this requirement)
Set the task's name to \"Create user data tables\"
Choose a 'Priority' level
Set the 'Est. effort' to 10.0h.
Click 'Save'.
The new task has now been added:
We have more tasks to add. The table below shows 12 tasks in total to add to 4 different requirements. This includes the one we just created for completeness.
Requirement / Task Est. Estimate System must allow entry of users Create user data tables 10.0h Develop user business object 10.0h Build user creation screens 20.0h System must allow the modification of users Extend user business object to handle updates 5.0h Add user list page 15.0h Add user details page 20.0h Add user permissions page 15.0h System must allow the deletion of users Extend user business object to handle deletes 5.0h Update user list page to add delete functionality 10.0h System should allow administrators to setup notifications Create user administration home 15.0h Add user settings for notifications to database 10.0h Create user notifications administration page 20.0hOn the main Navigation bar, click again on 'Requirements'. You should now have the following requirements list page. In this screenshot we have hidden the 'Author' field and shown the 'Task Effort' field to show the detailed task effort aggregated up to the requirements.
The total number of hours for these tasks divided by the total number of story points, gives a number a lot more than the 8 hours that the system assumes. We can update the system to better estimate the number of hours to deliver each story point.
To update the metric, go to the three cogs dropdown menu on the rightmost corner of the main Navigation Bar, locate Planning and click Planning Options:
As you can see, the system lists 8.0 hours as the current number of hours required to deliver a single story point of functionality. Now that we have some actual tasks in the product, click on the 'Suggest' button to have the system provide its suggestion of the new metric:
Click the 'Apply' button to update the planning metric, and then click the main 'Save' button at the very bottom of the page to confirm the change.
"},{"location":"SpiraTeam-Quick-Start-Guide/#adding-the-test-cases","title":"Adding the Test Cases","text":"Click on the Artifacts > Test Cases menu option to display the product's test case list page:
The test case list is empty and the only folder visible in the 'Folders' tree on the left-hand side is 'Root'.
Click on the 'Add' button underneath the folder tree,
Enter the new folder name 'Functional Tests'.
Click 'Add'.
Click on this folder from the 'Folders' tree on the left
Click 'New Test Case' from the toolbar.
Enter \"Test ability to add new users\" for the name of this new test case
Click 'Save And New'
Repeat the above steps to create 3 more test cases:
Test ability to edit existing users
Test ability to delete existing users
Test ability to edit notifications
You should now have the following test case list:
Next, we need to enter detailed test steps to each test case, and link each test to the appropriate requirements.
In the 'Description' box under 'Detailed Information' section, enter a brief overview of the test case (something like \"this test case verifies that you can add new users to the system and that all of the fields get saved correctly.\").
Scrolling down to the 'Test Steps' section, you will see a single test step has been automatically created for you with some suggested text:
This test case needs 3 test steps.
Click 'Edit' on 'Step 1' and enter the first set of parameters below.
Click 'Save' and then 'Insert Step' to add the second test step and enter its information from below
Click 'Save and New' to make the third step
Once you've entered its information click 'Save'
You should now have the following test steps in the test case:
Next, we need to link this test case to the requirement(s) that it validates.
Choose the 'System must allow the entry of users' requirement
Click the 'Save' button beneath the list of requirements to add the test case to this requirement
Let's repeat the process for the other test cases, adding a couple of test steps to each. Then link the test cases to the requirements according to this table just like you did above:
Test Case Requirement Test ability to add new users System must allow entry of users Test ability to edit existing users System must allow the modification of users Test ability to delete existing users System must allow the deletion of users Test ability to edit notifications System should allow administrators to setup notificationsWe have created test cases and set up their test coverage. Next, we need to specify which releases and sprints they can be tested in.
Select the checkbox of each test case in the 'Functional Tests' folder.
Click on 'Tools' drop-down menu on the toolbar
Click 'Add to Release'
Select 'Release 1.0
Click 'Add'.
You have added all the tests to the overarching Release. Finally, we want to add the tests to the different sprints, based off the data in the table below.
Select the checkbox of each relevant test case in the 'Functional Tests' folder.
Click on 'Tools' drop-down menu on the toolbar
Click 'Add to Release'
Select the appropriate sprint
Click 'Add'
You typically want to include previous functionality in each of the successive iterations to ensure regression coverage. That is what we have done here. This means that each sprint includes new test cases for the new requirements, as well as existing test cases for pre-existing functionality.
"},{"location":"SpiraTeam-Quick-Start-Guide/#planning-the-sprint","title":"Planning the Sprint","text":"We have requirements that have tasks, and tests connected to them. What we haven't done yet is scope out which requirements go in which sprint.
On the main Navigation Bar, click on the Planning > Planning Board option on the main menu to display the product backlog planning board.
Make sure the 'Group By' dropdown on the left is set to \"By Priority\"
Make sure all requirements are visible by checking the left-most column and ensuring that all priority levels are shown in an expanded view (downward facing triangle signs)
To view the iteration plan for a specific release, select 'Release 1.0' on the 'Planning:' drop down menu on the top left.
Choose 'By Sprint' from the drop-down 'Group By' menu. That will display the sprint plan for the selected release (currently empty)
Each backlog item (requirement or incident) is represented by a virtual \"story card\" in the iteration. The left-hand side of each item displays the priority color. The progress bar near the bottom of each item depicts the progress of the item. You can flip through each iteration to see the work planned by clicking the left/right arrow buttons at the sides of the screen.
Now drag the two highest priority requirements (the ones with Importance = 1-Critical) to the first iteration:
In the screenshots above the cards are showing more information then you may see by default. Extra information can be shown by toggling the buttons at the top right of the planning board
To see more information about each requirement, enable the 'Detailed View' option
To see the individual tasks associated with each requirement, select the 'Tasks' option
To see the individual tests associated with each requirement, select the 'Test Cases' option
You can determine how much time has been scheduled in the first sprint and how much time is remaining. Although we have spare time available in Iteration 1, we will leave room left for fixing incidents, so next, drag and drop the remaining two requirements to Iteration 2:
"},{"location":"SpiraTeam-Quick-Start-Guide/#assigning-the-requirements-tasks","title":"Assigning the Requirements & Tasks","text":"Now that we have planned which requirements (user stories) and tasks are planned for each sprint, we can assign tasks to the appropriate developer(s). The process you follow will depend on your methodology (e.g. in Scrum the developers pick the tasks, but in Extreme Programming the product manager usually assigns tasks).
To assign the tasks, go to the main Navigation Bar and click on Artifact > Tasks to display the main tasks list page:
Click on the 'Board' option on the top-right of the screen to change to the Kanban board view:
You can see at a glance which tasks are in each status (in this case, they are all marked as 'Not Started'). To see the distribution of tasks by person for a specific sprint, change the release selection to 'Release 1.0 Iteration 1', and the 'Group By' dropdown to 'By Person':
For our sample product, we have two product members listed (included ourselves). As an example, select the first four tasks (which are all priority = 1 -- Critical) and drag them to your user's section:
Now you can clearly see the four tasks that have been assigned to your user. To simulate how this would appear to a developer, click on the main SpiraTeam icon (in the top-left) to display your user's \"My Page\" dashboard:
This page lists all the development tasks that have been assigned to your user. Click on the task \"Create user data tables\" to display the task details page:
This task has been estimated at 10.0 hours and is currently not started. The next step is to start working on the assigned task and report back progress. As an example:
click the workflow 'Operations' and chose 'Start Task'.
Then under 'Dates and Times' enter an 'Actual Effort' of 3.0 hours, and a 'Remaining Effort' of 5.0 hours.
In the 'Comments' section below, add a comment: \"Added initial set of data tables\",
Click 'Save' at the top of the page.
The progress indicator will reflect the changes and the new comment will have been added.
Now click on the other three assigned tasks, start them, and specify the following:
Requirement / Task Est. Estimate Actual Effort Remaining Effort Create user data tables 10.0h 3.0h 5.0h Develop user business object 10.0h 2.0h 7.5h Build user creation screens 20.0h 3.0h 18.0h Extend user business object to handle updates 5.0h 0.5h 4.0hAfter updating the assigned tasks, the 'My Page' dashboard will show all these changes:
Similarly, for the product manager, On the main Navigation Bar, clicking on Artifacts > Requirements to display the requirements list will show the task progress as it impacts the various requirements:
"},{"location":"SpiraTeam-Quick-Start-Guide/#scheduling-the-testing-activities","title":"Scheduling the Testing Activities","text":"Now that we have created our test plan for each release and sprint, we need to schedule the test cases for execution by our testers. As an example, we'll create a single test set (also known as a test suite) that contains a list of test cases to be executed by a specific tester.
On the main Navigation Bar, click on Artifacts >Test Sets menu option to display the product's test set list page:
At first, the test set list will be empty and the 'Folders' tree on the left will only show 'Root'.
Click the 'Add' button beneath the folder tree
Enter the new folder name 'Test Cycle #1'
Click the 'Add' button.
Click on the folder you just made
Click 'New Test Set' from the toolbar.
Enter the name of the new test set 'Testing new functionality'
Click 'Save'
You should now have the following test set list:
Click on the hyperlink for the test set to bring up the test set details page:
Let's add the appropriate test cases to this set.
Locate 'Root' drop down menu under 'Test Cases' section.
Choose the 'Functional Tests' folder and the test cases in that folder will be displayed:
Test ability to add new users
Test ability to edit existing users
You should now have the following displayed:
Next, let's assign this test set to a specific release and to a particular tester. To do that, choose the following values for the following fields and click 'Save':
Owner = System Administrator (your user)
Scheduled = Release 1.0 - Iteration 1
Planned Date = (Today's Date).
You have now scheduled this test set to be executed by your user by the end of today against the first iteration of release 1.0:
"},{"location":"SpiraTeam-Quick-Start-Guide/#running-tests-and-logging-incidents","title":"Running Tests and Logging Incidents","text":"Now that you have scheduled the test set, if you go to the 'My Page' by clicking on the SpiraTeam logo in the top-left, you'll see your newly assigned test set down on the left:
Click the 'Execute' button (with the play icon) to the right of this new test set. That will start the test execution wizard:
On the first screen, the release dropdown list will have been automatically pre-selected to the release specified in the test set. Click 'Next' to move to the first test step in the first test case:
Note that when you first visit this page, you will be shown a quick guided tour of how the page works.
As a tester, you can progress through each of the test steps in each test case in the test set in turn. For each test step you can enter Pass, Fail, Blocked, Caution, or Not Applicable. If you enter any status other than Pass you need to enter a value for the 'Actual Result'. For a pass status, the Actual Result is optional.
Click the 'Pass' button to pass the first test step. As soon as you do, the test will automatically progress to the second test step:
Now for the second test step, enter in the actual result field \"Unable to enter the sample data as the fields were disabled\". Before clicking the Fail button, we also want to enter in the following fields in the Incident form (accessed by clicking the \"Incidents\" tab):
Name = Error displaying user fields
Type = Bug
Priority = 2 -- High
Now click the 'Fail' button and you will have recorded a test failure and a new incident/defect:
Now that we have logged the test failure and the new incident/defect, click on a hexagon on the main navigation bar on the left of \"Sample Empty Product 2\" option.
You'll be taken to the product homepage with the requirements and test case metrics now visible in individual widgets (like the Test Execution Status widget shown below):
If you go to the Artifacts > Test Sets page, you also see the status of our test set:
If you go to the Artifacts > Requirements page, you'll see the different requirements' test coverage and the status of the tests associated with each requirement:
The next step in the process is to triage the logged defect and assign it to a developer to be fixed.
"},{"location":"SpiraTeam-Quick-Start-Guide/#triaging-issues-and-defects","title":"Triaging Issues and Defects","text":"Now that a new incident has been logged, the next step in the process is to review the incident and assign it to a developer to be fixed. First, click on the Artifacts > Incidents menu item. This will display the incident list page for the product. You can also view the same list of incidents in a Kanban board view.
In either view, click on the hyperlink for the new incident \"Error displaying user fields\". This will display the incident details page:
In the 'Operations' dropdown menu underneath the incident name on the top of the page, select 'Assign Incident' option. This will switch the status of the incident from New > Assigned.
Location the 'People' section and set the 'Owner' field to System Administrator (your user)
Add a new comment in the 'Comments' section at the bottom of the page. Type \"Assigning this to you to fix. Issue was found during testing.\"
Click the 'Save' button in the top toolbar.
The incident will be assigned to your user for fixing.
To see what a developer would see in real life, go back to the \"My Page\" by clicking on the orange SpiraTeam icon in the top-left of the main Navigation Bar on the top of the screen:
You can see that you've been assigned an incident under the \"My Assigned Incidents\" widget (on the right-hand side). Now click on the hyperlink for the incident to bring up the incident details page:
The status is 'Assigned' and the comment from the product manager is clearly visible. To help you reproduce the issue, you can click on the \"Associations\" tab to display the test run and requirements associated with this incident:
If you click on the test run hyperlink \"Test ability to add new users\", you will see the detailed information about the test execution that resulted in the bug being logged:
This allows the developer to retrace the steps taken by the tester and attempt to reproduce the issue. We are going to assume we can reproduce and fix the issue so we can go right ahead and resolve the incident.
Make your way back to the incident details screen: Artifacts> Incidents > Error displaying user fields' Hyperlink.
Click on the workflow 'Operations' drop-down menu and select 'Resolve Incident'.
Fill in the following fields
Click 'Save' on the main toolbar
The incident will now change from Assigned > Resolved and an email will be sent to the tester letting them know that they need to retest the test case and close the incident.
"},{"location":"SpiraTeam-Quick-Start-Guide/#reviewing-your-product","title":"Reviewing Your Product","text":"You can check on the overall status of the product by clicking the hexagon on the main navigation bar. This will take you to the product home page. Below is what this home page looks like for a more complete product than we have been working through in this quick start guide.
Note how you can change between several views (the buttons on the right) to show different information based on your role or current needs, or only show data for a particular release (see the dropdown beneath the product name on the left).
Congratulations! You have now completed the software development and testing lifecycle using SpiraTeam. For more information about any of the features, please refer to the SpiraTeam User Manual.
"},{"location":"SpiraTest-Quick-Start-Guide/","title":"SpiraTest Quick Start Guide","text":"Want to access the new and improved Quick Start Guide?
This SpiraTest quick start guide still works great, but we have a newer and greater quick start guide. Please feel free to check it out.
"},{"location":"SpiraTest-Quick-Start-Guide/#logging-in-and-selecting-a-product","title":"Logging in and Selecting a Product","text":"Once you have installed a self-hosted trial or signed up for a hosted trial of SpiraTest, you should see the following login screen in your web browser:
Enter the following default details to start using the system:
Login: administrator
Password: PleaseChange
Once logged-in, you are shown your \"My Page\". The very first time you log in you will be able to take a quick orientation tour of the application (as shown in the screenshot below).
The My Page looks pretty empty right now. This is normal.
For this tutorial we want to start with an empty product that has no data in it, so click the hyperlink under 'My Products' for 'Sample Empty Product 2' / 'Sample Program'. That will select the empty product. Now to see the homepage for the product you just selected click on the hexagon in the top left:
The product home page shows various widgets containing key product metrics. These are empty now, because the product has no data in it. In the rest of this guide we are going to fix that.
"},{"location":"SpiraTest-Quick-Start-Guide/#define-the-requirements","title":"Define the Requirements","text":"On the main Navigation bar, click Artifacts > Requirements to display the product's requirements list page:
The terminology in SpiraTest is designed to be methodology agnostic. The table below shows how the terms used in SpiraTest relate to some common methodologies:
SpiraPlan Extreme Programming Scrum AgileUP / DSDM Summary Requirement Epic Epic Feature Group Requirement User Story Backlog Item Requirement Task Task Task Task Release Release Release Release Sprint Iteration Sprint IterationAt first, the requirements list will be empty. Click the 'Insert' button in the toolbar to create your first requirement. Hit 'Save and New' (shown as buttons on the right of the new requirement in the list table) to add each new requirement after that except for the last requirement. After entering the last requirement, hit \"Save\" button. Below is the list of requirement names to add:
Functional Requirements
Module 1
System must allow entry of users
System must allow the modification of users
System must allow the deletion of users
Module 2
System should allow administrators to setup notifications
You should now have a simple, flat requirements list, like the one below:
Next, we are going to indent the requirements. This will give us a hierarchy, with some requirements being children of others.
To indent, select the checkboxes of all the requirements below 'Functional Requirements' and click 'Indent'. This makes 'Functional Requirements' the parent and all the other requirements its children.
Now, select the three requirements immediately below 'Module 1' and click 'Indent' again. This makes these three requirements children of 'Module 1' (and grandchildren of 'Functional Requirements')
Repeat for the requirement below 'Module 2' by right-clicking on this last requirement and choosing 'Indent' from the popup context menu.
You should now have a list that looks like:
We now have a nicely group set of requirements. Let's enter more information about them, starting with setting their types and priorities.
Click the ''select all' checkbox at the top of the list (the checkbox just above the checkbox for 'Functional Requirements')
Click on the top 'Edit' button in the right-hand column of that same row. That will make all the requirement rows editable:
Change the 'Type' to 'User Story' for some of the requirements - in the example screenshot all requirements that are children (have a single diamond icon and a non bold name) are now user stories.
Choose whatever values you like for the 'Importance' field for each of the requirements.
Click the 'Save' button.
You now have a prioritized list of user story requirements:
The next thing we can do is assign estimates to each requirement. This is something that the developers or business analysts may do based on the complexity and scope of each. The 'Estimates' column is not visible yet, so first we need to show it. To do that, click on the 'Show/Hide Columns' dropdown list and select 'Show Estimate (points)'.:
By default, all the requirements will have been assigned a default estimate of 1.0 point. A point is not a defined number of hours, but an indication of the size of the requirement. The estimates should reflect how big each of the requirements are relative to each other.
To change the estimates:
Click the \"select all\" checkbox at the top of the list
Click on the top 'Edit' button in the right-hand column. The requirements should be in editable mode again.
Enter the following estimates for the requirements
Click 'Save'
Your requirements should now look like this (with each parent's estimates automatically summing up the estimates of their children):
We have created a list of prioritized, estimated requirements, which is a great way to start our product. In the next section we are going to enter releases and sprints.
"},{"location":"SpiraTest-Quick-Start-Guide/#create-the-release-and-iteration-plan","title":"Create the Release and Iteration Plan","text":"On the main navigation bar, click out of 'Requirements' and select 'Releases' menu option to display the product's release list page:
The release list will be empty. Click the 'Insert' button in the toolbar to create your first release. Hit 'Save and New' (shown as buttons on the right of the new release in the list table) to add each new release after that. Below is the list of release names to add
Release 1.0 -- version number 1.0.0.0
Start Date: Today's Date
End Date: Today's Date + 2 months
Release 1.1 -- version number 1.1.0.0
Start Date: Today's Date + 2 months
End Date: Today's Date + 4 months
You should have a list of releases like this:
We need to add one additional level of detail to each release -- the list of sprints that will take place in each release.
Let's add some sample sprints for the first release.
Select the checkbox for Release 1.0 and, from the toolbar, click Insert > Child Release.
Choose a name for the new sprint
Make sure its 'Type' is set to 'sprint'
Specify its date-range. We recommend making each sprint last 2-weeks and have each one scheduled in series
click 'Save And New'.
Repeat steps 2-5 above, then steps 2-4 and then finally click 'Save' on the final sprint's row. You should have three sprints added to the list, all children of Release 1.0
Finally, let's specify the number of resources assigned to each sprint and release.
Click on the 'Show/Hide Columns' dropdown list and select 'Show # Resources' column
Select the three checkboxes for the sprints of \"Release 1.0\"
Click the 'Edit' button on the toolbar.
Adjust the # resources for the sprints to 2.
Click 'Save'
Now that we have the releases and sprints scheduled, we now need to assign our previously defined requirements to the different releases.
On the main navigation bar, click on Artifacts' drop-down menu and click Requirements to display the requirements list.
Click the 'select all' checkbox at the top of the list
Click the top 'Edit' button on the main tool bar. That will make all the cells editable.
Now choose the release/sprint for each of the lower-level requirements
Click 'Save'
Notice that all the requirements have automatically changed status from 'Requested' to 'Planned', this is because they have been assigned a specific release/iteration.
"},{"location":"SpiraTest-Quick-Start-Guide/#build-the-test-plan","title":"Build the Test Plan","text":"On the main Navigation bar, click on the Artifacts drop-down menu and select Test Cases menu option to display the product's test case list page:
The test case list is empty and the only folder visible in the 'Folders' tree on the left-hand side is 'Root'.
Click on the 'Add' button underneath the folder tree,
Enter the new folder name 'Functional Tests'.
Click 'Add'.
Click on this folder from the 'Folders' tree on the left
Click 'New Test Case' from the toolbar.
Enter \"Test ability to add new users\" for the name of this new test case
Click 'Save And New'
Repeat the above steps to create 3 more test cases:
Test ability to edit existing users
Test ability to delete existing users
Test ability to edit notifications
You should now have the following test case list:
Next, we need to enter detailed test steps to each test case, and link each test to the appropriate requirements.
In the 'Description' box under 'Detailed Information' section, enter a brief overview of the test case (something like \"this test case verifies that you can add new users to the system and that all of the fields get saved correctly.\").
Scrolling down to the 'Test Steps' section, you will see a single test step has been automatically created for you with some suggested text:
This test case needs 3 test steps.
Click 'Edit' on 'Step 1' and enter the first set of parameters below.
Click 'Save' and then 'Insert Step' to add the second test step and enter its information from below
Click 'Save and New' to make the third step
Once you've entered its information click 'Save'
You should now have the following test steps in the test case:
Next, we need to link this test case to the requirement(s) that it validates.
Choose the 'System must allow the entry of users' requirement
Click the 'Save' button beneath the list of requirements to add the test case to this requirement
Let's repeat the process for the other test cases, adding a couple of test steps to each. Then link the test cases to the requirements according to this table just like you did above:
Test Case Requirement Test ability to add new users System must allow entry of users Test ability to edit existing users System must allow the modification of users Test ability to delete existing users System must allow the deletion of users Test ability to edit notifications System should allow administrators to setup notificationsWe have created test cases and set up their test coverage. Next, we need to specify which releases and sprints they can be tested in.
Select the checkbox of each test case in the 'Functional Tests' folder.
Click on 'Tools' drop-down menu on the toolbar
Click 'Add to Release'
Select 'Release 1.0
Click 'Add'.
You have added all the tests to the overarching Release. Finally, we want to add the tests to the different sprints, based off the data in the table below.
Select the checkbox of each relevant test case in the 'Functional Tests' folder.
Click on 'Tools' drop-down menu on the toolbar
Click 'Add to Release'
Select the appropriate sprint
Click 'Add'
You typically want to include previous functionality in each of the successive iterations to ensure regression coverage. That is what we have done here. This means that each sprint includes new test cases for the new requirements, as well as existing test cases for pre-existing functionality.
"},{"location":"SpiraTest-Quick-Start-Guide/#scheduling-the-testing-activities","title":"Scheduling the Testing Activities","text":"Now that we have created our test plan for each release and sprint, we need to schedule the test cases for execution by our testers. As an example, we'll create a single test set (also known as a test suite) that contains a list of test cases to be executed by a specific tester.
On the main Navigation Bar, click on Artifacts >Test Sets menu option to display the product's test set list page:
At first, the test set list will be empty and the 'Folders' tree on the left will only show 'Root'.
Click the 'Add' button beneath the folder tree
Enter the new folder name 'Test Cycle #1'
Click the 'Add' button.
Click on the folder you just made
Click 'New Test Set' from the toolbar.
Enter the name of the new test set 'Testing new functionality'
Click 'Save'
You should now have the following test set list:
Click on the hyperlink for the test set to bring up the test set details page:
Let's add the appropriate test cases to this set.
Locate 'Root' drop down menu under 'Test Cases' section.
Choose the 'Functional Tests' folder and the test cases in that folder will be displayed:
Test ability to add new users
Test ability to edit existing users
You should now have the following displayed:
Next, let's assign this test set to a specific release and to a particular tester. To do that, choose the following values for the following fields and click 'Save':
Owner = System Administrator (your user)
Scheduled = Release 1.0 - Iteration 1
Planned Date = (Today's Date).
You have now scheduled this test set to be executed by your user by the end of today against the first iteration of release 1.0:
"},{"location":"SpiraTest-Quick-Start-Guide/#running-tests-and-logging-incidents","title":"Running Tests and Logging Incidents","text":"Now that you have scheduled the test set, if you go to the 'My Page' by clicking on the SpiraTest logo in the top-left, you'll see your newly assigned test set down on the left:
Click the 'Execute' button (with the play icon) to the right of this new test set. That will start the test execution wizard:
On the first screen, the release dropdown list will have been automatically pre-selected to the release specified in the test set. Click 'Next' to move to the first test step in the first test case:
Note that when you first visit this page, you will be shown a quick guided tour of how the page works.
As a tester, you can progress through each of the test steps in each test case in the test set in turn. For each test step you can enter Pass, Fail, Blocked, Caution, or Not Applicable. If you enter any status other than Pass you need to enter a value for the 'Actual Result'. For a pass status, the Actual Result is optional.
Click the 'Pass' button to pass the first test step. As soon as you do, the test will automatically progress to the second test step:
Now for the second test step, enter in the actual result field \"Unable to enter the sample data as the fields were disabled\". Before clicking the Fail button, we also want to enter in the following fields in the Incident form (accessed by clicking the \"Incidents\" tab):
Name = Error displaying user fields
Type = Bug
Priority = 2 -- High
Now click the 'Fail' button and you will have recorded a test failure and a new incident/defect:
Now that we have logged the test failure and the new incident/defect, click on a hexagon on the main navigation bar on the left of \"Sample Empty Product 2\" option.
You'll be taken to the product homepage with the requirements and test case metrics now visible in individual widgets (like the Test Execution Status widget shown below):
If you go to the Artifacts > Test Sets page, you also see the status of our test set:
If you go to the Artifacts > Requirements page, you'll see the different requirements' test coverage and the status of the tests associated with each requirement:
The next step in the process is to triage the logged defect and assign it to a developer to be fixed.
"},{"location":"SpiraTest-Quick-Start-Guide/#triaging-issues-and-defects","title":"Triaging Issues and Defects","text":"Now that a new incident has been logged, the next step in the process is to review the incident and assign it to a developer to be fixed. First, click on the Artifacts > Incidents menu item. This will display the incident list page for the product.
Click on the hyperlink for the new incident \"Error displaying user fields\". This will display the incident details page:
In the 'Operations' dropdown menu underneath the incident name on the top of the page, select 'Assign Incident' option. This will switch the status of the incident from New > Assigned.
Location the 'People' section and set the 'Owner' field to System Administrator (your user)
Add a new comment in the 'Comments' section at the bottom of the page. Type \"Assigning this to you to fix. Issue was found during testing.\"
Click the 'Save' button in the top toolbar.
The incident will be assigned to your user for fixing.
To see what a developer would see in real life, go back to the \"My Page\" by clicking on the orange SpiraTest icon in the top-left of the main Navigation Bar on the top of the screen:
You can see that you've been assigned an incident under the \"My Assigned Incidents\" widget (on the right-hand side). Now click on the hyperlink for the incident to bring up the incident details page:
The status is 'Assigned' and the comment from the product manager is clearly visible. To help you reproduce the issue, you can click on the \"Associations\" tab to display the test run and requirements associated with this incident:
If you click on the test run hyperlink \"Test ability to add new users\", you will see the detailed information about the test execution that resulted in the bug being logged:
This allows the developer to retrace the steps taken by the tester and attempt to reproduce the issue. We are going to assume we can reproduce and fix the issue so we can go right ahead and resolve the incident.
Make your way back to the incident details screen: Artifacts> Incidents > Error displaying user fields' Hyperlink.
Click on the workflow 'Operations' drop-down menu and select 'Resolve Incident'.
Fill in the following fields
Click 'Save' on the main toolbar
The incident will now change from Assigned > Resolved and an email will be sent to the tester letting them know that they need to retest the test case and close the incident.
"},{"location":"SpiraTest-Quick-Start-Guide/#reviewing-your-product","title":"Reviewing Your Product","text":"You can check on the overall status of the product by clicking the hexagon on the main navigation bar. This will take you to the product home page. Below is what this home page looks like for a more complete product than we have been working through in this quick start guide.
Note how you can change between several views (the buttons on the right) to show different information based on your role or current needs, or only show data for a particular release (see the dropdown beneath the product name on the left).
Congratulations, you have now completed the testing lifecycle using SpiraTest. For more information about any of the features, please refer to the SpiraTest User Manual.
"},{"location":"TaraVault-User-Manual/Activating-TaraVault/","title":"Activating TaraVault","text":""},{"location":"TaraVault-User-Manual/Activating-TaraVault/#introduction","title":"Introduction","text":"TaraVault\u00ae is the secure source code and file hosting service from Inflectra that allows you to host source code and other assets in our secure cloud, integrated with our SpiraPlan\u00ae application lifecycle management system.
This guide assumes that the reader is familiar with both SpiraPlan/SpiraTeam and the appropriate SCM platform (Git and/or Subversion). For information regarding how to use SpiraPlan/Team, please refer to the User Manual.
You can use either Git or Subversion with TaraVault. If you want to learn more about each of these and which is right for you, read our intro guides to using Git and using Subversion.
"},{"location":"TaraVault-User-Manual/Activating-TaraVault/#activation","title":"Activation","text":"To activate TaraVault:
NOTE: If you don't see the above link it will because you are: self-hosted, are using SpiraTest, or are not a system administrator. Please contact Inflectra customer services to upgrade to SpiraTeam or SpiraPlan, if needed.
If TaraVault is not yet activated, the TaraVault page displays a message explaining just that. This is normal. Click 'Activate TaraVault' to activate TaraVault. Once this succeeds, the page will change to look like the image below.
This shows you you the following information:
Now that TaraVault is active, you can:
Once you have activated TaraVault, you can begin to provision specific products to use source code with TaraVault and assign users to commit code or files into the TaraVault repositories. Note: All SpiraPlan users with roles that let them view source code, can view the code in the application, even if they are not a TaraVault user.
"},{"location":"TaraVault-User-Manual/Provisioning-Projects-%26-Users/#provisioning-products","title":"Provisioning Products","text":"When you provision a product with TaraVault you are setting up TaraVault's source code to be fully integrated into the SpiraPlan product. To do this:
This opens the TaraVault product administration page. In the screenshot below we have selected the 'Library Information System' sample product:
To provision this product with TaraVault:
Click 'Activate' to complete the TaraVault setu for this product.
In the screenshot below we have chosen 'libraryinformationsystem' as the product name and 'Git' as the type. The application will now:
Once TaraVault has been activated on a product, you can perform the following actions:
By default, the built-in system administrator account will be automatically enabled for TaraVault and will be added as a member of all TaraVault products. To enable other users to commit code/files to a TaraVault repository, go to Administration > Users > View/Edit Users menu item.
Click on the user you want to add to TaraVault. This will show their user details page. On this page, if TaraVault is active, you will see a TaraVault tab. From here you can enable a specific Spira user for TaraVault:
Now change the setting to \"YES\" and the following screen appears:
Enter a TaraVault password and click 'Save'. The user is now added to TaraVault and you can add them to specific TaraVault products.
To add a user to TaraVault products, make sure you are on their admin user details page. On the TaraVault tab click \"Add Products\".
You can now choose which TaraVault products to add the user to - select Yes for each active TaraVault product they should be added to. Then click Save.
The user will now be listed for those specific TaraVault products.
On the admin user details page, on the TaraVault tab:
And on the Product Admin > Source Code page:
You can see in the example above we have two users listed under the current product Library Information System. If you click on any of the 'Edit Users' you can make changes to the TaraVault user settings page.
From here you can:
Individual users can see their own TaraVault profile from the main Spira profile page. They need to click on the 'My Profile' link under their user's avatar on the main Spira navigation page:
This page displays the current user's TaraVault login and password (masked). They can update the password for connecting to TaraVault.
"},{"location":"TaraVault-User-Manual/Provisioning-Projects-%26-Users/#connecting-to-the-source-code-repository","title":"Connecting to the Source Code Repository","text":"Individual users can see the connection information they can use for connecting via. Git or Subversion by going to Developing > Source Code:
This dialog displays the connection string they should use to connect to the current product (the format will depend on whether the user is using Git or Subversion) along with the login and password.
They can click on the blurred password option to reveal their actual password. This is necessary since they will need to know the password to use when connecting to Subversion / Git using their desired SCM client (e.g. TortoiseSVN, TortoiseGit, etc.).
"},{"location":"TaraVault-User-Manual/Using-Git/","title":"Using Git","text":"Git is a Distributed Version Control System (DVCS) system that keeps track of software commits and allows many developers to work on a given project without necessarily being connected to a common network since it doesn't rely on a central repository, but instead distributes copies of the entire source code repository to each user's workstation.
"},{"location":"TaraVault-User-Manual/Using-Git/#git-basics","title":"Git Basics","text":"The major difference between Git and most other VCS (e.g. Subversion described in the previous section) is the way Git thinks about its data. Conceptually, most other systems store information as a list of file-based changes. These systems (CVS, Subversion, Perforce, Bazaar, and so on) think of the information they keep as a set of files and the changes made to each file over time.
Git doesn't think of or store its data this way. Instead, Git thinks of its data more like a set of snapshots of a miniature filesystem. Every time you commit, or save the state of your project in Git, it basically takes a picture of what all your files look like at that moment and stores a reference to that snapshot. To be efficient, if files have not changed, Git doesn't store the file again, just a link to the previous identical file it has already stored. Git thinks about its data more like a stream of snapshots:
This is an important distinction between Git and nearly all other VCSs. It makes Git reconsider almost every aspect of version control that most other systems copied from the previous generation. This makes Git more like a mini filesystem with some incredibly powerful tools built on top of it, rather than simply a VCS.
Another major difference between Git and Subversion is that Git has built-in support for 'branches' instead of relying on a specific folder structure. In Git, Branches are used to develop features isolated from each other. The master branch is the \"default\" branch when you create a repository. You can then use other branches for development and merge them back to the master branch upon completion.
"},{"location":"TaraVault-User-Manual/Using-Git/#working-with-remotes","title":"Working with Remotes","text":"To be able to work on any Git project, you need to know how to manage your remote repositories. Remote repositories the versions of your project that are hosted TaraVault itself. Collaborating with others involves managing these remote repositories and pushing and pulling data to and from them when you need to share work. Managing remote repositories includes knowing how to add remote repositories, remove remotes that are no longer valid, manage various remote branches and define them as being tracked or not, and more.
This is in stark contrast to Subversion where every commit and update is being performed directly on the central TaraVault remote repository. So when you make changes to your local repository, the will need to explicitly synchronized with TaraVault for other users to see them, and for them to appear in Spira:
"},{"location":"TaraVault-User-Manual/Using-Git/#getting-started-with-git","title":"Getting Started with Git","text":"This section assumes that you have already provisioned at least one Git project in TaraVault following the steps in Activating TaraVault and Provisioning Projects & Users. So you should now have a TaraVault user/password and a Git project with a connection URL:
The next step is to actually connect to this repository using a Git client and commit some source code. We recommend using a GUI tool such as TortoiseGit but you can use any standard Git client with TaraVault (command-line or GUI-based) just as well. In our examples we shall be using TortoiseGit.
The first thing we need to do is perform an initial 'clone' of our remote Git repository into a local repository. This will also do an implicit checkout from the local repository into the working directory.
Assuming that you have already installed TortoiseGit, you would now create a folder to hold all of your Git projects (in our example we shall use C:\\Temp\\Git) and right-click and choose \"Git Clone\":
The following dialog box will appear:
You need to enter the following:
URL-- needs to be the TaraVault Git connection string listed under 'My Profile' for the current project.
Directory -- needs to be the local name of the folder for the local repository. Typically it is best to make it the same as the name of the project in TaraVault (e.g. C:\\Temp\\Git\\libraryinformationsystem in this example)
When you click on the 'OK' button, the following authentication dialog box will appear:
Enter your TaraVault Git username, and then click 'OK'. Then the following will appear:
Enter your TaraVault password and then click 'OK' again. The success dialog will appear:
You will now get a folder C:\\Temp\\Git\\sampleapplicationone that is completely empty apart from a special .git folder that is used by Git internally.
Now that you have your Git local repository and working folder available, you are ready to start using Git.
"},{"location":"TaraVault-User-Manual/Using-Git/#adding-files-to-the-master-branch","title":"Adding Files to the Master Branch","text":"Now that you have your Git repository ready, we shall simulate working on a real project. You can now copy some code and folders into the empty working folder (which will be set to use the 'master' branch). In this example we shall add some sample Inflectra code:
Select all the files and folders and choose TortoiseGit > Add. That will display the following dialog box:
Select all the files and click OK.
Click on [OK] to commit the files to the local repository. Note that this does not send them to the remote TaraVault repository at this stage since this is a distributed version control system and all commits are done locally.
Enter in the appropriate commit message and then click [OK] to complete the local commit. The following screen will be displayed:
At this stage, we are not ready to 'Push' the repository to TaraVault so just click 'Close'.
Now, open up one of the files (we shall modify the SampleTestSuite\\AssemblyInfo.cs file in our example) and make a change to it. Then right-click on the top-level 'sampleapplicationone' folder and choose Git Commit -> \"master\" to commit the change. Make sure you add a comment:
Click OK and the change (known as a commit) will now be committed into the 'master' branch of the local repository.
"},{"location":"TaraVault-User-Manual/Using-Git/#working-with-branches","title":"Working with Branches","text":"Now that we have the primary development line in our master branch, we can work on a separate version of the code in a different branch, and then at a later date merge back in the changes to the 'master' branch. For example we might be working on an experimental new feature and we only want to merge it into the 'master' when it is internally stable and all the unit tests pass.
We shall create a new named branch in our local repository using TortoiseGit. To do that right-click on the top-level folder (sampleapplicationone) and then click Tortoise Git > Create Branch:
This will display the following dialog box:
Enter in the name of the new branch (we have chosen 'experimental' in the example shown) and click [OK] to create the new branch. Since we want to start working in this new branch, we should now using TortoiseGit > Switch/Checkout to switch to this new branch:
Click [OK] to confirm the switch. Now all your changes will be made on this branch.
Now, let's simulate making a code change on the 'experimental' branch we made. To do that, change one of the files in the folder structure and then right-click Git Commit -> \"experimental\":
That will display the commit dialog box:
Enter in a comment in the 'Message' text box that describes the purpose of the change. Then click [OK]. On the success dialog box that appears, click 'Close'.
Now unlike other VCS such as Subversion, we have made all of these changes in the local Git repository. Once you are ready to share your changes with your team, you need to 'Push' the local branches to the remote TaraVault repository.
To do this, right-click on the top-level folder (sampleapplicationone) and choose TortoiseGit > Push. The following dialog box will be displayed:
In this case we want to push all branches (master and experimental) to TaraVault, so select the checkbox 'Push all branches'. Then click 'OK' to push the changes:
Once they have been pushed, we are now ready to view the repository within Spira.
"},{"location":"TaraVault-User-Manual/Using-Git/#using-git-with-spiraplan","title":"Using Git with SpiraPlan","text":"Click on the \"Source Code\" or \"Commits\" menu items under the Developing tab to navigate and browse the source code repository.
You can read more about working with source code in SpiraPlan at the links below:
Subversion is a version control system (VCS) -- also known as a revision control system (RCS). That is, Subversion manages files and directories, and the changes made to them, over time. This allows you to recover older versions of your data or examine the history of how your data changed.
Some version control systems are also software configuration management (SCM) systems. These systems are specifically tailored to manage trees of source code and have many features that are specific to software development---such as natively understanding programming languages, or supplying tools for building software. Subversion, however, is not one of these systems. It is a general system that can be used to manage any collection of files, though it is often used for SCM, handling source code files
"},{"location":"TaraVault-User-Manual/Using-Subversion/#repository-layout","title":"Repository Layout","text":"Before we get started with using Subversion, we need to discuss the standard folder layout. For TaraVault to display its branches, folders, files and commits correctly in Spira you need to follow this layout for all your Subversion projects:
These three concepts are explained below:
Trunk is the main folder containing all the data. This is the main line of current development for the project.
A Branch contains copy of the trunk files and directories. These are used to denote older or non-primary versions of the Trunk. You may still commit changes into these branches. For example you may be still fixing bugs on an older version whilst primary development is occurring on the latest version.
Tags can also be referred as milestone. This is a check-point to indicate that your project has reached a certain point. You can use this to mark various releases. Unlike a branch, you cannot commit changes into a tag.
An example setup for such a project could look like:
The same folders and files are typically stored inside each of the Branches, Tags and the Trunk. We shall illustrate this more closely when we get started in the next section.
"},{"location":"TaraVault-User-Manual/Using-Subversion/#getting-started-with-subversion","title":"Getting Started with Subversion","text":"This section assumes that you have already provisioned at least one Subversion project in TaraVault following the steps in Activating TaraVault and Provisioning Projects & Users. So you should now have a TaraVault user/password and a Subversion project with a connection URL:
The next step is to actually connect to this repository using a Subversion client and commit some source code. We recommend using a GUI tool such as TortoiseSVN but you can use any standard Subversion client with TaraVault (command-line or GUI-based) just as well. In our examples we shall be using TortoiseSVN.
The first thing we need to do is perform an initial 'check-out' of our repository into a new working folder (that will initially be empty).
Assuming that you have already installed TortoiseSVN, you would now create a folder to hold all of your Subversion projects (in our example we shall use C:\\Temp\\Subversion) and right-click and choose TortoiseSVN > Check Out:
The following dialog box will appear:
You need to enter the following:
URL of repository -- needs to be the TaraVault connection string listed under 'My Profile' for the current project.
Checkout Directory -- needs to be the local name of the folder for this project. Typically it is best to make it the same as the name of the project in TaraVault (e.g. C:\\Temp\\Subversion\\libraryinformationsystem in this example)
When you click on the 'OK' button, the following authentication dialog box will appear:
Enter your TaraVault username/password, choose 'Save authentication' and then click 'OK'. You will now get a folder C:\\Temp\\Subversion\\libraryinformationsystem that is completely empty apart from a special _svn (or .svn) folder that is used by TortoiseSVN internally.
Now that you have your Subversion working folder downloaded, you should add the following three folders right now:
Trunk
Branches
Tags
Once you have added them to Windows Explorer, select them all and choose TortoiseSVN > Add:
This will display the following:
Once they are added, then choose TortoiseSVN > Commit to commit these folders to the TaraVault repository. That will display the following dialog box:
Typically you should add a message to describe what you did. Then click 'OK' and the three layout folders will now be added to your TaraVault subversion repository.
"},{"location":"TaraVault-User-Manual/Using-Subversion/#adding-files-to-the-trunk","title":"Adding Files to the Trunk","text":"Now that you have your Subversion repository layout setup, we shall simulate working on a real project. You can now copy some code and folders into the Trunk top-level folder for your project. In this example we shall add some sample Inflectra code:
Select all the files and folders and choose TortoiseSVN > Add, then after adding the files and folders, choose TortoiseSVN > Commit to add these files to the repository.
Now, open up one of the files (we shall modify the SampleTestSuite\\AssemblyInfo.cs file in our example) and make a change to it. Then right-click on Trunk and choose TortoiseSVN > Commit to commit the change. Make sure you add a comment:
Click OK and the change (known as a /commit) will now be committed into TaraVault.
"},{"location":"TaraVault-User-Manual/Using-Subversion/#branching-and-tagging","title":"Branching and Tagging","text":"Now that we have the primary development line in our Trunk, we can branch and tag a specific version of the code before we make other changes. For example we might be releasing a version and then making changes specific only to the next version.
We shall create both a branch and a tag from the current Trunk. Firstly, to create a Branch, right-click on Trunk and choose TortoiseSVN > Branch/Tag:
Change the 'To path' from /Trunk to /Branches/v2.0.0.0. You can either branch the latest commit (called the HEAD revision) or a specific commit:
We also recommend adding a 'Log message' to describe the purpose of making the branch. Once you are happy with your choice, click 'OK' to confirm the branch. Once that is done, a copy of the Trunk will now be available under the Branches/v2.0.0.0 folder. To see this, right-click on Branches and choose TortoiseSVN > Update:
Similarly, to make a Tag, right-click on Trunk and choose TortoiseSVN > Branch/Tag, and change the 'To path' from /Trunk to /Tags/v1.0.0.0:
Once that has been completed, right-click on the Tags folder and choose TortoiseSVN > Update:
The main difference between a Branch and a Tag is that you can continue to make changes on a Branch, whereas a Tag is a fixed snapshot of the Trunk and cannot be modified. To illustrate this, let's simulate making a bug fix on the v2.0 branch we made. To do that, change one of the files in the /Branches/v1.0.0.0 folder structure and then right-click TortoiseSVN > Commit:
Click 'OK' and we are now ready to view the repository within Spira.
"},{"location":"TaraVault-User-Manual/Using-Subversion/#using-subversion-with-spiraplan","title":"Using Subversion with SpiraPlan","text":"Click on the \"Source Code\" or \"Commits\" menu items under the Developing tab to navigate and browse the source code repository.
You can read more about working with source code in SpiraPlan at the links below:
UnitJS is an assertion library for JavaScript, running on Node.js or a web browser. It works with various test runner and unit testing frameworks, including Mocha, Karma, Protractor, and QUnit.
SpiraTest currently includes a pre-built extension for the MochaJS test runner and our sample code illustrates it working with UnitJS. However, we supply the source code to the extension, so you can easily adapt it for other runners such as Protractor.
"},{"location":"Unit-Testing-Integration/Integrating-UnitJS-%26-NodeJS/#using-the-spiratest-mochajs-reporter","title":"Using the SpiraTest MochaJS Reporter","text":"Mocha is a feature-rich JavaScript test framework running on Node.js and in the browser, making asynchronous testing simple and fun. Mocha tests run serially, allowing for flexible and accurate reporting, while mapping uncaught exceptions to the correct test cases.
An example UnitJS test running Mocha looks something like:
var test = require('unit.js');\n\ndescribe('Example Test', function(){\n\nit('sample pass', function(){\n\n// just for example of tested value\n\nvar example = 'hello world';\n\ntest\n\n.string(example)\n\n.startsWith('hello')\n\n.match(/\\[a-z\\]/)\n\n.given(example = 'you are welcome')\n\n.string(example)\n\n.endsWith('welcome')\n\n.contains('you')\n\n.when('\"example\" becomes an object', function(){\n\nexample = {\n\nmessage: 'hello world',\n\nname: 'Nico',\n\njob: 'developper',\n\nfrom: 'France'\n\n};\n\n})\n\n.then('test the \"example\" object', function(){\n\ntest\n\n.object(example)\n\n.hasValue('developper')\n\n.hasProperty('name')\n\n.hasProperty('from', 'France')\n\n.contains({message: 'hello world'})\n\n;\n\n})\n\n.if(example = 'bad value')\n\n.error(function(){\n\nexample.badMethod();\n\n})\n\n;\n\n});\n\nit('sample fail', function(){\n\n// just for example of tested value\n\nvar example = 'not hello world';\n\ntest\n\n.string(example)\n\n.startsWith('hello')\n\n.match(/\\[a-z\\]/)\n\n.given(example = 'you are welcome')\n\n.string(example)\n\n.endsWith('welcome')\n\n.contains('you')\n\n.when('\"example\" becomes an object', function(){\n\nexample = {\n\nmessage: 'hello world',\n\nname: 'Nico',\n\njob: 'developper',\n\nfrom: 'France'\n\n};\n\n})\n\n.then('test the \"example\" object', function(){\n\ntest\n\n.object(example)\n\n.hasValue('developper')\n\n.hasProperty('name')\n\n.hasProperty('from', 'France')\n\n.contains({message: 'hello world'})\n\n;\n\n})\n\n.if(example = 'bad value')\n\n.error(function(){\n\nexample.badMethod();\n\n})\n\n;\n\n});\n\n});\nIn this sample, we have one test suite \"Example Test\" that has two tests -- \"sample pass\" and \"sample fail\" inside it. When you run this test using Mocha using the command line:
node ./node_modules/mocha/bin/mocha .\\test\\example2.js
You get the following:
What we want is to have this test suite report back against a matching test case in SpiraTest.
To do that we need to download and unzip the UnitJS-MochaJS-Reporter.zip file from the Inflectra website and extract the contents to the same location as your test framework. The reporter subfolder contains two NodeJS modules:
SpiraReporter.js -- this contains the Mocha custom reporter used for sending the results to SpiraTest
SpiraClient.js -- this contains the JavaScript module that sends a test result back to SpiraTest. It is used by SpiraReporter.js but can also be used directly in your code if you want to report back results without using Mocha.
To use this custom reporter with your Mocha test framework, you simply need to do these two things:
Add the reporter name to the command line used to invoke Mocha
Add some configuration code to your UnitJS test suite to tell Mocha how to connect to your instance of SpiraTest.
The first part is very straightforward, just add the Reporter to your Mocha command line:
node ./node_modules/mocha/bin/mocha .\\test\\example2.js --reporter .\\reporter\\SpiraReporter
For the second part, you need to add the following code to your test suite at the top:
var SpiraReporter = require('../reporter/SpiraReporter.js');\n\n//set the SpiraTest options\n\nglobal.spiraOptions = {\n\nprojectId: 1,\n\ntestCaseId: 4,\n\nreleaseId: 1,\n\ntestSetId: null,\n\nlogin: 'fredbloggs',\n\napiKey: '{7A05FD06-83C3-4436-B37F-51BCF0060483}',\n\nprotocol: 'http',\n\nhost: '127.0.0.1',\n\nvdir: 'spira'\n\n};\nThe second line defines the connection and test case information used for reporting back to SpiraTest. Here's what you need to put in each of the required configuration options:
protocol -- this needs to be set to either \"http\" or \"https\" depending on how you connect to SpiraTest
host -- this needs to be the name or IP address of the host running SpiraTest. For cloud customers, it will be something like mycompany.spiraservice.net
port -- this is usually 80 for http and 443 for https unless you are running SpiraTest on a custom port
vdir -- this is the name of any path used after the hostname. For example, if your URL is https://demo.spiraservice.net/mysite then the vdir would be \"mysite\". If your URL is just https://mycompany.spiraservice.net then you can leave the vdir blank or just not set a value for it.
login -- this should be a login that has access to the project in SpiraTest with permissions to create test runs.
apiKey -- this should be the API Key (also known as the RSS Token) for the login specified
projectId -- this should be the numeric ID of the project that the test case belongs to (e.g. if the project is PR56 just use 56)
testCaseId -- this should be the numeric ID of the test case that you want this Mocha test suite to report against (e.g. if the test case in question is TC23 just use 23)
In addition, there are two optional configuration parameters you can use:
releaseId -- If you would like the recorded test run to be reported against a specific release, iteration or phase in SpiraTest, you need to specify the ID of the release in question (e.g. for release RL18 just use 18)
testSetId - If you would like the recorded test run to be reported against a specific test set in SpiraTest, you need to specify the ID of the test set in question (e.g. for test set TX35 just use 35)
With those values set, when you run the test suite using the command line:
node ./node_modules/mocha/bin/mocha .\\test\\example2.js --reporter .\\reporter\\SpiraReporter
The results of the test suite will be displayed inside the Mocha console:
When you login to SpiraTest and view the test case being executed, you will now see the automated test runs reported back from Mocha:
Clicking on one of the MochaJS Reporter test runs will bring up a screen that provides the detailed test run report from Mocha:
The Console Output section gives more detailed information:
Congratulations... You are now able to run UnitJS automated tests using Mocha and the SpiraTest custom reporter and have the results be recorded within SpiraTest. The sample test suites example.js and example2.js are provided with the installation.
"},{"location":"Unit-Testing-Integration/Integrating-with-Cypress/","title":"Cypress Reporter for Spira","text":"This is a sample cypress project that uploads Cypress test results automatically to Inflectra's SpiraTest, SpiraTeam or SpiraPlan (hereafter just Spira).
It is implemented as a custom reporter that you can easily add to your existing Cypress projects and have the benefit of the test results and screenshots automatically upload against the corresponding Spira test case.
"},{"location":"Unit-Testing-Integration/Integrating-with-Cypress/#installing-the-cypress-reporter","title":"Installing the Cypress Reporter","text":"To install the Spira custom reporter, simply download the Spira-Cypress-Reporter.zip zip file and extract the contents (consisting of the reporter folder) and place in your Cypress project at the same level as the cypress folder. For example:
To use the custom Spira reporter in your Cypress project, you just add it to the Cypress command line:
npx cypress run --browser edge --spec \"cypress\\e2e\\1-getting-started\\todo.cy.js\" --reporter \"reporter\\SpiraReporter\"\nor you modify the cypress.config.js to include the report. We recommend this method since it avoids need to add it to the command-line each time.
However before you can use the reporter, you will need to configure it to point to Spira, and map the Cypress spec files to specified Spira test cases.
"},{"location":"Unit-Testing-Integration/Integrating-with-Cypress/#configuring-the-cypress-reporter","title":"Configuring the Cypress Reporter","text":"Locate the cypress.config.js file from the root of your Cypress project. Open this up in your favorite text/code editor, for example Visual Studio Code. This file contain something similar to the following:
const { defineConfig } = require(\"cypress\");\n\nmodule.exports = defineConfig({\ne2e: {\nsetupNodeEvents(on, config) {\non('task', { log(message) {\nconsole.log(message)\nreturn null\n},\n})\n},\n}\n});\nDepending on how you have Cypress configured, you may have additional settings.
Now we need to modify it to enable the Spira custom reporter and configure its settings:
const { defineConfig } = require(\"cypress\");\n\nmodule.exports = defineConfig({\ne2e: {\nsetupNodeEvents(on, config) {\non('task', { log(message) {\nconsole.log(message)\nreturn null\n},\n})\n},\n},\nreporter: 'reporter/SpiraReporter',\nreporterOptions: {\nprojectId: 1,\nreleaseId: 1,\ntestSetId: null,\nlogin: 'fredbloggs',\napiKey: '{7A05FD06-83C3-4436-B37F-51BCF0060483}',\nprotocol: 'https',\nhost: 'demo-us.spiraservice.net',\nvdir: 'mysite',\nmapping: {\n\"with a checked task\": 4,\n\"with a checked task 2\": 5\n}\n}\n});\nNotice that we have added reporterOptions object that specifies how the Cypress reporter will communicate with Spira:
PR:5 would be just 5)RL:2 would be just 2)TX:3 would be just 3)http or httpsmysite) or just empty if you have a URL that is just the domain (e.g. https://mysite.spiraservice.net)The mapping section is where we map the name of each test suite in a spec file with a corresponding Spira test case. For example, if we have a spec file that has this context section:
context('with a checked task', () => {\nbeforeEach(() => {\ncy.contains('Pay electric bill')\n.parent()\n.find('input[type=checkbox]')\n.check()\n})\nThen the name of the test suite wiuld be with a checked task and then we map that to a test case in SpiraTest, for example TC:5. For our sample tests, we have the following example mapping:
mapping: {\n \"with a checked task\": 4,\n \"with a checked task 2\": 5\n}\nSo we are mapping: - with a checked task to Spira test case TC:4 - with a checked task 2 to Spira test case TC:5
We have now finished our configuration of the reporter, and can run the tests.
"},{"location":"Unit-Testing-Integration/Integrating-with-Cypress/#running-a-cypress-test","title":"Running a Cypress Test","text":"You can execute the tests using the Cypress command-line, launch-pad, CI tool or whatever method you currently use. For example, to execute one of the sample tests in this repository, you can use:
npx cypress run --browser edge --spec \"cypress\\e2e\\1-getting-started\\todo.cy.js\"\nto run the entire folder of tests, you can use:
npx cypress run --browser edge --spec \"cypress\\e2e\\1-getting-started\"\nThe system will then execute the test and let you know that it is reporting back to Spira:
"},{"location":"Unit-Testing-Integration/Integrating-with-Cypress/#viewing-the-results-in-spira","title":"Viewing the Results in Spira","text":"Once the Cypress tests have finished running, you can view the results in Spira:
If you click on one of the runs, you will see the details of that specific execution, including the pass/fail steps and the actions recorded:
In addition, if you choose one of the failed runs, you will see that any screenshots have been automatically uploaded as well:
If you click on the picture link, you can view the uploaded image/screenshot directly in Spira:
Congratulations! You have now run your first Cypress test and reported back the results to Spira!
"},{"location":"Unit-Testing-Integration/Integrating-with-Cypress/#where-can-i-obtain-spira","title":"Where Can I Obtain Spira?","text":"If you would like to learn more about the Inflectra Spira suite, please go to the following website: - SpiraTest, powerful requirements and test management - SpiraTeam, agile planning and test management for teams - SpiraPlan, enterprise planning and testing platform
"},{"location":"Unit-Testing-Integration/Integrating-with-JUnit/","title":"JUnit","text":"The directions for using JUnit 5 and JUnit 4 are in different sections below:
"},{"location":"Unit-Testing-Integration/Integrating-with-JUnit/#installing-the-junit-5-extension","title":"Installing the JUnit 5 Extension","text":"This section outlines how to install the SpiraTest Extension for JUnit 5 onto a workstation so that you can then run automated JUnit tests against a Java application and have the results be recorded as test runs inside SpiraTest. It assumes that you already have a working installation of SpiraTest v5.0 or later. If you have an earlier version of SpiraTest you will need to upgrade to at least v5.0 before trying to use this extension. You will also need to have at least version 5.0 of Junit. If you are using an earlier version, please visit www.junit.org to obtain the latest version.
To obtain the version of the JUnit extension that is compatible with your version of SpiraTest, you simply need to log-in as a project-level administrator to SpiraTest, go to the Administration home page and download the JUnit Extension compressed archive (.zip). This process is described in the SpiraTest Administration Guide in more detail.
The JUnit extension is provided as a compressed zipfile that includes both the binaries (packaged as a JAR-file) and the source code (stored in a folder structure that mirrors the Java classpath). The JAR-file binary was compiled for use on a Windows x86 platform, other platforms (e.g. Linux) will require you to compile the Java source files into the appropriate Java classfiles before using the extension. The rest of this section will assume that you are using the pre-compiled JAR-file.
Once you have downloaded the Zip archive, you need to uncompress it into a folder of your choice on your local system. Assuming that you uncompressed it to the C:\\Program Files\\JUnit Extension folder, you should have the following folder structure created:
C:\\Program Files\\JUnit Extension
C:\\Program Files\\JUnit Extension\\com
C:\\Program Files\\JUnit Extension\\com\\inflectra
C:\\Program Files\\JUnit Extension\\com\\inflectra\\spiratest
C:\\Program Files\\JUnit Extension\\com\\inflectra\\spiratest\\addons
C:\\Program Files\\JUnit Extension\\com\\inflectra\\spiratest\\addons\\junitextension
C:\\Program Files\\JUnit Extension\\com\\inflectra\\spiratest\\addons\\junitextension\\samples
The JAR-file is located in the root folder, the source-code for the extension can be found in the \"junitextension\" subfolder, and the sample test fixture can be found in the \"samples\" subfolder.
Now to use the extension within your test cases, you need to first make sure that the JAR-file is added to the Java classpath. The method for doing this is dependent on the platform you're using, so please refer to FAQ on www.junit.org for details on the appropriate method for your platform. As an example, on a Windows platform, the JAR-file would be added to the classpath by typing the following:
set CLASSPATH=%CLASSPATH%; C:\\\\Program Files\\\\JUnit Extension\\\\JUnitExtension.jar
Once you have completed this step, you are now ready to begin using your JUnit test fixtures with SpiraTest.
"},{"location":"Unit-Testing-Integration/Integrating-with-JUnit/#using-junit-5-with-spiratest","title":"Using JUnit 5 with SpiraTest","text":"The typical code structure for a JUnit test fixture coded in Java is as follows:
package com.inflectra.spiratest.addons.junitextension.samples;\n\nimport org.junit.jupiter.api.BeforeEach;\nimport org.junit.jupiter.api.Test;\nimport static org.junit.jupiter.api.Assertions.assertEquals;\nimport static org.junit.jupiter.api.Assertions.assertTrue;\n\n\n/**\n * Some simple tests using the ability to return results back to SpiraTest\n *\n * @author Inflectra Corporation\n * @version 4.0.0\n */\npublic class SimpleTest {\nprotected int fValue1;\nprotected int fValue2;\n\n/**\n * Sets up the unit test\n */\n@BeforeEach\npublic void setUp() {\nfValue1 = 2;\nfValue2 = 3;\n}\n\n/**\n * Tests the addition of the two values\n */\n@Test\npublic void testAdd() {\ndouble result = fValue1 + fValue2;\n\n// forced failure result == 5\nassertTrue(result == 6);\n}\n\n/**\n * Tests division by zero\n */\n@Test\npublic void testDivideByZero() {\nint zero = 0;\nint result = 8 / zero;\n}\n\n/**\n * Tests two equal values\n */\n@Test\npublic void testEquals() {\nassertEquals(12, 12);\nassertEquals(12L, 12L);\nassertEquals(new Long(12), new Long(12));\n\nassertEquals(12, 13, \"Size\");\nassertEquals(12.0, 11.99, 0.0, \"Capacity\");\n}\n\n/**\n * Tests success\n */\n@Test\npublic void testSuccess() {\n//Successful test\nassertEquals(12, 12);\n}\n}\nThe Java class is marked as a JUnit test fixture by applying the @BeforeEach attribute to the setup method, and the @Test attribute to each of the test assertion methods individually -- highlighted in yellow above. When you open up the class in a JUnit runner or execute from the command line it loads all the test classes and executes all the methods marked with @Test in turn.
Each of the Assert statements is used to test the state of the application after executing some sample code that calls the functionality being tested. If the condition in the assertion is true, then execution of the test continues, if it is false, then a failure is logged and JUnit moves on to the next test method.
So, to use SpiraTest with JUnit, each of the test cases written for execution by JUnit needs to have a corresponding test case in SpiraTest. These can be either existing test cases that have manual test steps or they can be new test cases designed specifically for automated testing and therefore have no defined test steps. In either case, the changes that need to be made to the JUnit test fixture for SpiraTest to record the JUnit test run are illustrated below:
package com.inflectra.spiratest.addons.junitextension.samples;\n\nimport com.inflectra.spiratest.addons.junitextension.*;\n\nimport org.junit.jupiter.api.BeforeEach;\nimport org.junit.jupiter.api.Test;\nimport static org.junit.jupiter.api.Assertions.assertEquals;\nimport static org.junit.jupiter.api.Assertions.assertTrue;\n\n\n/**\n * Some simple tests using the ability to return results back to SpiraTest\n *\n * @author Inflectra Corporation\n * @version 5.0.0\n */\n@SpiraTestConfiguration(\n//following are REQUIRED\nurl = \"https://demo-us.spiraservice.net/mysite\",\nlogin = \"fredbloggs\",\nrssToken = \"{XXXXXXXXXXXXXXXX}\", // make sure to use your API/RSS key and not your login password\nprojectId = 1,\n//following are OPTIONAL\nreleaseId = 7,\ntestSetId = 1\n)\n\npublic class SimpleTest {\nprotected int fValue1;\nprotected int fValue2;\n\n/**\n * Sets up the unit test\n */\n@BeforeEach\npublic void setUp() {\nfValue1 = 2;\nfValue2 = 3;\n}\n\n/**\n * Tests the addition of the two values\n */\n@Test\n@SpiraTestCase(testCaseId = 2)\npublic void testAdd() {\ndouble result = fValue1 + fValue2;\n\n// forced failure result == 5\nassertTrue(result == 6);\n}\n\n/**\n * Tests division by zero\n */\n@Test\n@SpiraTestCase(testCaseId = 3)\npublic void testDivideByZero() {\nint zero = 0;\nint result = 8 / zero;\n}\n\n/**\n * Tests two equal values\n */\n@Test\n@SpiraTestCase(testCaseId = 4)\npublic void testEquals() {\nassertEquals(12, 12);\nassertEquals(12L, 12L);\nassertEquals(new Long(12), new Long(12));\n\nassertEquals(12, 13, \"Size\");\nassertEquals(12.0, 11.99, 0.0, \"Capacity\");\n}\n\n/**\n * Tests success\n */\n@Test\n@SpiraTestCase(testCaseId = 5)\npublic void testSuccess() {\n//Successful test\nassertEquals(12, 12);\n}\n}\nThe overall class is marked with a new @SpiraTestConfiguration attribute that contains the following pieces of information needed to access the SpiraTest test repository:
URL - The URL to the instance of SpiraTest being accessed. This needs to start with http:// or https://.
Login - A valid username for the instance of SpiraTest.
In addition, each of the individual test methods needs to be mapped to a specific test case within SpiraTest. This is done by adding a @SpiraTestCase attribute to the test method together with the ID of the corresponding test case in SpiraTest. The Test Case ID can be found on the test cases list page (click the \"Test Cases\" tab).
-- The test methods must be marked as public or the test results will not appear in Spira --
For these attributes to be available in your test fixture, you also need to add a reference to the com.inflectra.spiratest.addons.junitextension package. This package is bundled within the supplied JAR-file library for Windows, and can be compiled from the provided source .java files on other platforms.
Now all you need to do is compile your code and then launch JUnit by executing the test fixture through the command line, or through your choice of IDE, e.g. Eclipse, IntelliJ). We shall show one example of each:
"},{"location":"Unit-Testing-Integration/Integrating-with-JUnit/#a-executing-junit-5-tests-using-command-line","title":"a) Executing JUnit 5 Tests using Command Line","text":"To execute JUnit 5 tests using the command line, you need to download the junit-platform-console-standalone.jar JUnit 5 package from Maven and use that to run the tests.
For our sample test, you would use the following command to launch the JUnit tests:
java -jar \"C:\\AutomatedTesting\\JUnitExtension\\junit-platform-console-standalone-1.8.0-M1.jar\"--classpath=\"C:\\AutomatedTesting\\JUnitExtension\\JUnit 5\\bin\" -classpath=\"C:\\AutomatedTesting\\JUnitExtension\\Jars\\JUnit_5_Extension_jar\\JUnit 5 Extension.jar\" --select-class=com.inflectra.spiratest.addons.junitextension.samples.SimpleTest
This includes both the SpiraTest extension JAR and the sample tests being executed on the classpath and the class name of the sample tests in the select argument.
When executed it will report back to the command line:
and the results will also appear in SpiraTest.
"},{"location":"Unit-Testing-Integration/Integrating-with-JUnit/#b-executing-junit-5-tests-using-eclipse","title":"b) Executing JUnit 5 Tests using Eclipse","text":"To execute the tests in Eclipse, simply open your automated test script in an Eclipse project, ensure you have the JUnit Eclipse plugin installed, and finally make sure you add a reference to the SpiraTest JUnit 5 Extension.jar JAR file:
Then when you choose the option to Run As a JUnit 5 it will execute the tests:
If for any reason you don't see the test results appear in SpiraTest, make sure you have the correct test IDs mapped. If you still don't see the results, check the Console tab inside Eclipse for any errors connecting to SpiraTest:
"},{"location":"Unit-Testing-Integration/Integrating-with-JUnit/#viewing-the-test-results-in-spiratest","title":"Viewing the Test Results in SpiraTest","text":"Once the test has run using one of the previous methods, you can view the test cases in SpiraTest, you should see a JUnit automated test run displayed in the list of executed test runs:
Clicking on one of the JUnit test runs will bring up a screen that provides information regarding what JUnit test method failed, what the error was, together with the associated code stack-trace:
Congratulations... You are now able to run JUnit 5 automated tests and have the results be recorded within SpiraTest. The sample test fixture SimpleText.java is provided with the installation.
"},{"location":"Unit-Testing-Integration/Integrating-with-JUnit/#installing-the-junit-4-extension","title":"Installing the JUnit 4 Extension","text":"This section outlines how to install the SpiraTest Extension for JUnit onto a workstation so that you can then run automated JUnit tests against a Java application and have the results be recorded as test runs inside SpiraTest. It assumes that you already have a working installation of SpiraTest v3.0 or later. If you have an earlier version of SpiraTest you will need to upgrade to at least v3.0 before trying to use this extension. You will also need to have version 4.0 of JUnit. To use version 5.0 of JUnit, please visit Installing the JUnit 5 Extension
To obtain the version of the JUnit extension that is compatible with your version of SpiraTest, you simply need to log-in as a project-level administrator to SpiraTest, go to the Administration home page and download the JUnit Extension compressed archive (.zip). This process is described in the SpiraTest Administration Guide in more detail.
The JUnit extension is provided as a compressed zipfile that includes both the binaries (packaged as a JAR-file) and the source code (stored in a folder structure that mirrors the Java classpath). The JAR-file binary was compiled for use on a Windows x86 platform, other platforms (e.g. Linux) will require you to compile the Java source files into the appropriate Java classfiles before using the extension. The rest of this section will assume that you are using the pre-compiled JAR-file.
Once you have downloaded the Zip archive, you need to uncompress it into a folder of your choice on your local system. Assuming that you uncompressed it to the C:\\Program Files\\JUnit Extension folder, you should have the following folder structure created:
C:\\Program Files\\JUnit Extension
C:\\Program Files\\JUnit Extension\\com
C:\\Program Files\\JUnit Extension\\com\\inflectra
C:\\Program Files\\JUnit Extension\\com\\inflectra\\spiratest
C:\\Program Files\\JUnit Extension\\com\\inflectra\\spiratest\\addons
C:\\Program Files\\JUnit Extension\\com\\inflectra\\spiratest\\addons\\junitextension
C:\\Program Files\\JUnit Extension\\com\\inflectra\\spiratest\\addons\\junitextension\\samples
The JAR-file is located in the root folder, the source-code for the extension can be found in the \"junitextension\" subfolder, and the sample test fixture can be found in the \"samples\" subfolder.
Now to use the extension within your test cases, you need to first make sure that the JAR-file is added to the Java classpath. The method for doing this is dependent on the platform you're using, so please refer to FAQ on www.junit.org for details on the appropriate method for your platform. As an example, on a Windows platform, the JAR-file would be added to the classpath by typing the following:
set CLASSPATH=%CLASSPATH%; C:\\Program Files\\JUnit Extension\\JUnitExtension.jar
Once you have completed this step, you are now ready to begin using your JUnit test fixtures with SpiraTest.
"},{"location":"Unit-Testing-Integration/Integrating-with-JUnit/#using-junit-4-with-spiratest","title":"Using JUnit 4 with SpiraTest","text":"The typical code structure for a JUnit test fixture coded in Java is as follows:
package com.inflectra.spiratest.addons.junitextension.samples;\n\nimport static org.junit.Assert.*;\nimport junit.framework.JUnit4TestAdapter;\nimport org.junit.Before;\nimport org.junit.Test;\nimport org.junit.runner.*;\nimport org.junit.runner.notification.*;\n\nimport java.util.*;\n\n/**\n * Some simple tests using JUnit 4\n * \n * @author Inflectra Corporation\n * @version 2.3.0\n *\n */\npublic class SimpleTest\n{\nprotected int fValue1;\nprotected int fValue2;\n\n/**\n * Sets up the unit test\n */\n@Before\npublic void setUp()\n{\nfValue1= 2;\nfValue2= 3;\n}\n\n/**\n * Tests the addition of the two values\n */\n@Test\npublic void testAdd()\n{\ndouble result = fValue1 + fValue2;\n\n// forced failure result == 5\nassertTrue (result == 6);\n}\n\n/**\n * Tests division by zero\n */\n@Test\npublic void testDivideByZero()\n{\nint zero = 0;\nint result = 8 / zero;\nresult++; // avoid warning for not using result\n}\n\n/**\n * Tests two equal values\n */\n@Test\n\npublic void testEquals()\n{\nassertEquals(12, 12);\nassertEquals(12L, 12L);\nassertEquals(new Long(12), new Long(12));\n\nassertEquals(\"Size\", 12, 13);\nassertEquals(\"Capacity\", 12.0, 11.99, 0.0);\n}\n\n/**\n * Tests success\n */\n@Test\npublic void testSuccess()\n{\n//Successful test\nassertEquals(12, 12);\n}\n\n/**\n * Entry point for command line execution\n * \n * @param args The command line arguments\n */\npublic static void main (String[] args)\n{\n//Instantiate the JUnit core\nJUnitCore core = new JUnitCore();\n\n//Finally run the test fixture\ncore.run (SimpleTest.class);\n}\n\n/**\n * Entry point for JUnit 4.x runners\n * \n * @return Handle to the test framework\n */\npublic static junit.framework.Test suite() {\nreturn new JUnit4TestAdapter(SimpleTest.class);\n}\n}\nThe Java class is marked as a JUnit test fixture by applying the @Before attribute to the setup method, and the @Test attribute to each of the test assertion methods individually -- highlighted in yellow above. When you open up the class in a JUnit runner or execute from the command line it loads all the test classes and executes all the methods marked with @Test in turn.
Each of the Assert statements is used to test the state of the application after executing some sample code that calls the functionality being tested. If the condition in the assertion is true, then execution of the test continues, if it is false, then a failure is logged and JUnit moves on to the next test method.
So, to use SpiraTest with JUnit, each of the test cases written for execution by JUnit needs to have a corresponding test case in SpiraTest. These can be either existing test cases that have manual test steps or they can be new test cases designed specifically for automated testing and therefore have no defined test steps. In either case, the changes that need to be made to the JUnit test fixture for SpiraTest to record the JUnit test run are illustrated below:
package com.inflectra.spiratest.addons.junitextension.samples;\n\nimport static org.junit.Assert.*;\nimport junit.framework.JUnit4TestAdapter;\nimport org.junit.Before;\nimport org.junit.Test;\nimport org.junit.runner.*;\nimport org.junit.runner.notification.*;\n\nimport com.inflectra.spiratest.addons.junitextension.*;\n\nimport java.util.*;\n\n/**\n * Some simple tests using the ability to return results back to SpiraTest\n * \n * @author Inflectra Corporation\n * @version 2.3.0\n *\n */\n@SpiraTestConfiguration(\nurl=\"http://sandman/SpiraTest\",\nlogin=\"fredbloggs\",\npassword=\"fredbloggs\",\nprojectId=1,\nreleaseId=1,\ntestSetId=1\n)\npublic class SimpleTest\n{\nprotected int fValue1;\nprotected int fValue2;\n\n/**\n * Sets up the unit test\n */\n@Before\npublic void setUp()\n{\nfValue1= 2;\nfValue2= 3;\n}\n\n/**\n * Tests the addition of the two values\n */\n@Test\n@SpiraTestCase(testCaseId=5)\npublic void testAdd()\n{\ndouble result = fValue1 + fValue2;\n\n// forced failure result == 5\nassertTrue (result == 6);\n}\n\n/**\n * Tests division by zero\n */\n@Test\n@SpiraTestCase(testCaseId=5)\npublic void testDivideByZero()\n{\nint zero = 0;\nint result = 8 / zero;\nresult++; // avoid warning for not using result\n}\n\n/**\n * Tests two equal values\n */\n@Test\n@SpiraTestCase(testCaseId=6)\npublic void testEquals()\n{\nassertEquals(12, 12);\nassertEquals(12L, 12L);\nassertEquals(new Long(12), new Long(12));\n\nassertEquals(\"Size\", 12, 13);\nassertEquals(\"Capacity\", 12.0, 11.99, 0.0);\n}\n\n/**\n * Tests success\n */\n@Test\n@SpiraTestCase(testCaseId=6)\npublic void testSuccess()\n{\n//Successful test\nassertEquals(12, 12);\n}\n\n/**\n * Entry point for command line execution\n * \n * @param args The command line arguments\n */\npublic static void main (String[] args)\n{\n//Instantiate the JUnit core\nJUnitCore core = new JUnitCore();\n\n//Add the custom SpiraTest listener\ncore.addListener(new SpiraTestListener());\n\n//Finally run the test fixture\ncore.run (SimpleTest.class);\n}\n\n/**\n * Entry point for JUnit 4.x runners\n * \n * @return Handle to the test framework\n */\npublic static junit.framework.Test suite() {\nreturn new JUnit4TestAdapter(SimpleTest.class);\n}\n}\nThe overall class is marked with a new @SpiraTestConfiguration attribute that contains the following pieces of information needed to access the SpiraTest test repository:
URL - The URL to the instance of SpiraTest being accessed. This needs to start with http:// or https://.
Login - A valid username for the instance of SpiraTest.
Password - A valid password for the instance of SpiraTest.
Project Id - The ID of the project (this can be found on the project homepage in the \"Project Overview\" section)
Release Id (Optional) - The ID of the release to associate the test run with. This can be found on the releases list page (click on the Planning > Releases tab). If you don't want to specify a release, just use the value -1.
Test Set Id (Optional) -- The ID of the test set to associate the test run with. This can be found on the test set list page (click on the Testing > Test Sets tab). If you don't want to specify a test set, just use the value -1. If you choose a test set that is associated with a release, then you don't need to explicitly set a release id (i.e. just use -1). However if you do set a release value, it will override the value associated with the test set.
In addition, each of the individual test methods needs to be mapped to a specific test case within SpiraTest. This is done by adding a @SpiraTestCase attribute to the test method together with the ID of the corresponding test case in SpiraTest. The Test Case ID can be found on the test cases list page (click the \"Test Cases\" tab).
For these attributes to be available in your test fixture, you also need to add a reference to the com.inflectra.spiratest.addons.junitextension package. This package is bundled within the supplied JAR-file library for Windows, and can be compiled from the provided source .java files on other platforms.
Now all you need to do is compile your code and then launch JUnit by executing the test fixture through the command line (or through your choice of IDE, e.g. Eclipse). E.g. for our sample test, you would use the following command:
java com.inflectra.spiratest.addons.junitextension.samples.SimpleTest
Once the test has run, you can view the test cases in SpiraTest, you should see a JUnit automated test run displayed in the list of executed test runs:
Clicking on one of the JUnit test runs will bring up a screen that provides information regarding what JUnit test method failed, what the error was, together with the associated code stack-trace:
Congratulations... You are now able to run JUnit automated tests and have the results be recorded within SpiraTest. The sample test fixture SimpleText.java is provided with the installation.
"},{"location":"Unit-Testing-Integration/Integrating-with-Jasmine/","title":"Integrating with Jasmine","text":"Jasmine is a behavior-driven development framework for testing JavaScript code. It does not depend on any other JavaScript frameworks. It does not require a DOM. And it has a clean, obvious syntax so that you can easily write tests.
Some key features of Jasmine are:
The Spira Reporter for Jasmine will integrate JasmineJS with Spira. It will create a test run in Spira for each test spec executed in Jasmine.
"},{"location":"Unit-Testing-Integration/Integrating-with-Jasmine/#setting-up-the-integration","title":"Setting up the integration","text":"Install the integration by running npm i jasmine-spiratest in the root directory of your tests. Inside each test spec file, import the SpiraReporter with var SpiraReporter = require('jasmine-spiratest') then put the line jasmine.getEnv().addReporter(new SpiraReporter(spiraCredentials)); where spiraCredentials is an object of the format below. You can see a full sample test spec at the bottom of this page.
{\n \"url\": \"https://doctor/SpiraPlan\",\n \"username\": \"fredbloggs\",\n \"token\": \"{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}\",\n \"projectId\": 1,\n \"releaseId\": 1,\n \"testSetId\": 1,\n \"testCases\": {\n \"default\": 20,\n \"should multiply correctly\": 21,\n \"should solve exponents and logarithms correctly\": 16\n }\n}\nFields are required unless otherwise noted.
Field Description url The root URL of your SpiraTest instance without a '/' at the end username The username you use to sign into SpiraTest token Your RSS Token. Found in your profile page as the RSS Token field. You must have RSS Feeds enabled for this to work projectId The ID of the product you would like the Test Runs to be filed under releaseId OPTIONAL - Use if you would like to associate created test runs with a release testSetId OPTIONAL - Use if you would like to associated created test runs with a test set testCases Must contain the default field within it and, optionally, specific test cases for a given test spec name default Inside the testCases field, this is the ID of the default test case mapped to a created test run OPTIONAL - Use as many times as you would like to map a the created test run for a spec to a particular test case in SpiraTest. Note that capitalization, special characters and spaces are ignored both in testCases and the spec itself Once you have added the SpiraReporter to the jasmine environment in each file as described above, you are all set!"},{"location":"Unit-Testing-Integration/Integrating-with-Jasmine/#using-the-spiratest-reporter","title":"Using the SpiraTest Reporter","text":"Run npm test or however you ran jasmine before and you should see test runs created in the product you specified.
describe(\"Test having two specs\", () => {\n var SpiraReporter = require('jasmine-spiratest');\n\n jasmine.getEnv().addReporter(new SpiraReporter({\n \"url\": \"https://doctor/SpiraPlan\",\n \"username\": \"fredbloggs\",\n \"token\": \"{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}\",\n \"projectId\": 1,\n \"releaseId\": 1,\n \"testSetId\": 1,\n \"testCases\": {\n \"default\": 20,\n \"equality works\": 21,\n \"addition works\": 16\n }\n }));\n\n describe(\"Test basic JavaScript\", () => {\n it(\"Equality works...\", () => {\n expect(2).toEqual(2);\n });\n it(\"Addition works\", () => {\n expect(3 + 2).toEqual(5);\n });\n it(\"Multiplication works\", () => {\n expect(4 * 5).toEqual(20);\n });\n });\n});\nThis reporter will integrate JestJS with Inflectra's ALM suite. It will create a test run in Spira for each test executed in Jest.
"},{"location":"Unit-Testing-Integration/Integrating-with-Jest/#guide-basics","title":"Guide Basics","text":"Unfortunately, this integration will work with SpiraTest/SpiraTeam/SpiraPlan (hereafter refered to as SpiraTest) version 5.0 and above and at least Jest 24.x. If you have an older version, you will need to update to use this reporter.
This guide assumes a basic familiarity with both SpiraTest and the Jest testing framework.
"},{"location":"Unit-Testing-Integration/Integrating-with-Jest/#setting-up-the-integration","title":"Setting up the integration","text":"Install the integration by running npm i jest-spiratest in the root directory of your tests. Inside your package.json file, add the jest field with the format as shown below. You can see a full sample package.json at the bottom of this README.
\"reporters\": [\n\"default\",\n[\n\"jest-spiratest\",\n{\n\"url\": \"https://doctor/SpiraPlan\",\n\"username\": \"fredbloggs\",\n\"token\": \"{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}\",\n\"projectId\": 1,\n\"releaseId\": 1,\n\"testSetId\": 1,\n\"testCases\": {\n\"default\": 20,\n\"storesCorrectly\": 21,\n\"javascriptWorks\": 16\n}\n}\n]\n]\nField | Description --- | --- | url | The root URL of your SpiraTest instance without a '/' at the end username | The username you use to sign into SpiraTest token | Your RSS Token. Foundin your profile page as the RSS Token field. You must have RSS Feeds enabled for this to work projectId | The ID of the project you would like the Test Runs to be filed under releaseId | OPTIONAL - Use if you would like to associate created test runs with a release testSetId | OPTIONAL - Use if you would like to associated created test runs with a test set testCases | Must contain the default field within it and, optionally, specific test cases for a given test spec name default | Inside the testCases field, this is the ID of the default test case mapped to a created test run <test_name> | OPTIONAL - Use as many times as you would like to map a the created test run to a particular test case in SpiraTest. Note that capitalization, special characters and spaces are ignored both in testCases and the test declaration
Once you have added the SpiraReporter to jest as described above, you are all set!
"},{"location":"Unit-Testing-Integration/Integrating-with-Jest/#using-the-spiratest-reporter","title":"Using the SpiraTest Reporter","text":"Actually, you don't do anything different! Just run npm test or however you ran jest before and you should see test runs created in the project you specified!
package.json with SpiraTest Integration","text":"{\n\"name\": \"sample\",\n\"scripts\": {\n\"test\": \"jest\"\n},\n\"jest\": {\n\"reporters\": [\n\"default\",\n[\n\"jest-spiratest\",\n{\n\"url\": \"https://doctor/SpiraPlan\",\n\"username\": \"fredbloggs\",\n\"token\": \"{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}\",\n\"projectId\": 1,\n\"releaseId\": 1,\n\"testSetId\": 1,\n\"testCases\": {\n\"default\": 20,\n\"storesCorrectly\": 21,\n\"javascriptWorks\": 16\n}\n}\n]\n]\n}\n}\nThis section describes how to use SpiraTest in conjunction with the unit testing features provided by Microsoft Visual Studio Team System (MS VSTS) Test -- commonly known as MS-Test.
"},{"location":"Unit-Testing-Integration/Integrating-with-MS-Test/#installing-the-ms-test-extension","title":"Installing the MS-Test Extension","text":"This section outlines how to install the SpiraTest extension for Microsoft Visual Studio Team System Test (MS-Test) onto a workstation so that you can then run automated MS-Test tests against a .NET application and have the results be recorded as test runs inside SpiraTest. It assumes that you already have a working installation of SpiraTest v2.3 or later. If you have an earlier version of SpiraTest you will need to upgrade to at least v2.3 before trying to use this add-in. You will also need to have either Visual Studio Team System 2005 or later or Visual Studio 2008 Professional or later, since earlier versions do not come with the test automation features.
To obtain the latest version of the SpiraTest extension, you can either access the administration section of SpiraTest, and click on the Add-Ins & Downloads link or simply visit the Inflectra corporate downloads webpage (http://www.inflectra.com/Products/Downloads.aspx) and then download the compressed archive (.zip) that contains the extension and associated sample files.
The MS-Test extension is provided as a compressed zipfile that includes both the binaries (packaged as a .NET dll assembly) and the source code (stored in a Visual Studio project folder structure). The rest of this section will assume that you are using the pre-compiled assembly.
Once you have downloaded the Zip archive, you need to uncompress it into a folder of your choice on your local system. Assuming that you uncompressed it to the C:\\Program Files\\SpiraTest\\MSTest Extension folder, you should have the following folder structure created:
C:\\Program Files\\SpiraTest\\MSTest Extension
C:\\Program Files\\SpiraTest\\MSTest Extension\\SampleMSTest
C:\\Program Files\\SpiraTest\\MSTest Extension\\SampleMSTest\\Properties
C:\\Program Files\\SpiraTest\\MSTest Extension\\SpiraTestMSExtension
C:\\Program Files\\SpiraTest\\MSTest Extension\\SpiraTestMSExtension\\Properties
C:\\Program Files\\SpiraTest\\MSTest Extension\\SpiraTestMSExtension\\Web References
The pre-built assembly SpiraTestMSTestExtension.dll is located in the root folder, the source-code for the extension can be found in the \"SpiraTestMSExtension\" subfolder, and the sample test fixture can be found in the \"SampleMSTest\" subfolder.
Now to use the extension within your test cases, you need to first make sure that the SpiraTestMSTestExtension.dll assembly is added to the project references. Once you have completed this step, you are now ready to begin using your MS-Test test fixtures with SpiraTest.
"},{"location":"Unit-Testing-Integration/Integrating-with-MS-Test/#using-ms-test-with-spiratest","title":"Using MS-Test with SpiraTest","text":"The typical code structure for a Visual Studio Team System Test (MS-Test) test fixture coded in C# is as follows:
using System;\nusing System.Threading;\nusing Microsoft.VisualStudio.TestTools.UnitTesting;\n\nnamespace Inflectra.SpiraTest.AddOns.SpiraTestMSTestExtension.SampleMSTest\n{\n/// <summary>\n/// Sample test fixture that tests the SpiraTest integration\n/// Written by Paul Tissue. Packed by Inflectra Corporation\n/// </summary>\n[\n TestClass\n ]\npublic class SpiraTestCaseAttributeTest\n{\n/// <summary>\n/// Test fixture state\n/// </summary>\nprotected static int testFixtureState = 1;\n\n/// <summary>\n/// Constructor method\n/// </summary>\npublic SpiraTestCaseAttributeTest()\n{\n//Delegates to base\n\n//Set the state to 2\ntestFixtureState = 2;\n}\n\n/// <summary>\n/// Sample test that asserts a failure and overrides the default configuration\n/// </summary>\n[\n TestMethod\n ]\npublic void SampleFail()\n{\n//Verify the state\nAssert.AreEqual(2, testFixtureState, \"*Real Error*: State not persisted\");\n\n//Failure Assertion\nAssert.AreEqual(1, 0, \"Failed as Expected\");\n}\n\n/// <summary>\n/// Sample test that succeeds - uses the default configuration\n/// </summary>\n[\n TestMethod\n ]\npublic void SamplePass()\n{\n//Verify the state\nAssert.AreEqual(2, testFixtureState, \"*Real Error*: State not persisted\");\n\n//Successful assertion\nAssert.AreEqual(1, 1, \"Passed as Expected\");\n}\n\n/// <summary>\n/// Sample test that does not log to SpiraTest\n/// </summary>\n[\n TestMethod,\n ExpectedException(typeof(AssertFailedException))\n ]\npublic void SampleIgnore()\n{\n//Verify the state\nAssert.AreEqual(2, testFixtureState, \"*Real Error*: State not persisted\");\n\n//Failure Assertion\nAssert.AreEqual(1, 0, \"Failed as Expected\");\n}\n}\n}\nThe .NET class is marked as a MS-Test unit test fixture by applying the [TestClass] attribute to the class as a whole, and the [TestMethod] attribute to each of the test assertion methods individually -- shown above. When you open up the class in Visual Studio and click Tests > Run > Run All Tests in Solution it loads all the test classes marked with [TestClass] and executes all the methods marked with [TestMethod] in turn.
Each of the Assert statements is used to test the state of the application after executing some sample code that calls the functionality being tested. If the condition in the assertion is true, then execution of the test continues, if it is false, then a failure is logged and MS-Test moves on to the next test method.
So, to use SpiraTest with MS-Test, each of the test cases written for execution by MS-Test needs to have a corresponding test case in SpiraTest. These can be either existing test cases that have manual test steps or they can be new test cases designed specifically for automated testing and therefore have no defined test steps. In either case, the changes that need to be made to the MS-Test test fixture for SpiraTest to record the MS-Test test run are illustrated below:
using System;\nusing System.Threading;\nusing Microsoft.VisualStudio.TestTools.UnitTesting;\n\nnamespace Inflectra.SpiraTest.AddOns.SpiraTestMSTestExtension.SampleMSTest\n{\n/// <summary>\n/// Sample test fixture that tests the SpiraTest integration\n/// Written by Paul Tissue. Packed by Inflectra Corporation\n/// </summary>\n[\n TestClass\n ]\npublic class SpiraTestCaseAttributeTest : MSTestExtensionsTestFixture\n{\n/// <summary>\n/// Test fixture state\n/// </summary>\nprotected static int testFixtureState = 1;\n\n/// <summary>\n/// Constructor method\n/// </summary>\npublic SpiraTestCaseAttributeTest()\n{\n//Delegates to base\n\n//Set the state to 2\ntestFixtureState = 2;\n}\n\n/// <summary>\n/// Sample test that asserts a failure and overrides the default configuration\n/// </summary>\n[\n TestMethod,\n SpiraTestCase(5),\n SpiraTestConfiguration(\"http://localhost/SpiraTest\", \"fredbloggs\", \"fredbloggs\", 1, 1, 2)\n ]\npublic void SampleFail()\n{\n//Verify the state\nAssert.AreEqual(2, testFixtureState, \"*Real Error*: State not persisted\");\n\n//Failure Assertion\nAssert.AreEqual(1, 0, \"Failed as Expected\");\n}\n\n/// <summary>\n/// Sample test that succeeds - uses the default configuration\n/// </summary>\n[\n TestMethod,\n SpiraTestCase(6)\n ]\npublic void SamplePass()\n{\n//Verify the state\nAssert.AreEqual(2, testFixtureState, \"*Real Error*: State not persisted\");\n\n//Successful assertion\nAssert.AreEqual(1, 1, \"Passed as Expected\");\n}\n\n/// <summary>\n/// Sample test that does not log to SpiraTest\n/// </summary>\n[\n TestMethod,\n ExpectedException(typeof(AssertFailedException))\n ]\npublic void SampleIgnore()\n{\n//Verify the state\nAssert.AreEqual(2, testFixtureState, \"*Real Error*: State not persisted\");\n\n//Failure Assertion\nAssert.AreEqual(1, 0, \"Failed as Expected\");\n}\n}\n}\nAnd the following settings need to be added to the .config file associated with the test fixture assembly:
<?xml version=\"1.0\"?>\n<configuration>\n<configSections>\n<sectionGroup name=\"applicationSettings\" type=\"System.Configuration.ApplicationSettingsGroup, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089\" >\n<section name=\"Inflectra.SpiraTest.AddOns.SpiraTestMSTestExtension.Properties.Settings\" type=\"System.Configuration.ClientSettingsSection, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089\" requirePermission=\"false\" />\n</sectionGroup>\n</configSections>\n<applicationSettings>\n<Inflectra.SpiraTest.AddOns.SpiraTestMSTestExtension.Properties.Settings>\n<setting name=\"Url\" serializeAs=\"String\">\n<value>http://localhost/SpiraTest</value>\n</setting>\n<setting name=\"Login\" serializeAs=\"String\">\n<value>fredbloggs</value>\n</setting>\n<setting name=\"Password\" serializeAs=\"String\">\n<value>fredbloggs</value>\n</setting>\n<setting name=\"ProjectId\" serializeAs=\"String\">\n<value>1</value>\n</setting>\n<setting name=\"ReleaseId\" serializeAs=\"String\">\n<value>1</value>\n</setting>\n<setting name=\"TestSetId\" serializeAs=\"String\">\n<value>1</value>\n</setting>\n<setting name=\"RecordTestRun\" serializeAs=\"String\">\n<value>True</value>\n</setting>\n</Inflectra.SpiraTest.AddOns.SpiraTestMSTestExtension.Properties.Settings>\n</applicationSettings>\nFirstly the settings in the .config file indicate the following information to the test fixture:
The URL to the instance of SpiraTest being accessed. This needs to start with http:// or https://.
A valid username and password for the instance of SpiraTest.
The ID of the project (this can be found on the project homepage in the \"Project Overview\" section)
(Optional) The ID of the release to associate the test-run with. This can be found on the releases list page (click on the Planning > Releases tab)
(Optional) The ID of the test set to associate the test-run with. This can be found on the test set list page (click on the Testing > Test Sets tab)
A flag that tells MS-Test whether or not to record the results in SpiraTest.
Next, the test fixture class needs to be derived from the MSTestExtensionsTestFixture base class so that the test runner knows that the test class will be reporting back to SpiraTest.
In addition, each of the individual test methods needs to be mapped to a specific test case within SpiraTest. This is done by adding a [SpiraTestCase] attribute to the test method together with the ID of the corresponding test case in SpiraTest. The Test Case ID can be found on the test cases list page (click the \"Test Cases\" tab).
In addition you can also override the default SpiraTest configuration settings from the .config file by adding the [SpiraTestConfiguration] attribute directly to the test method and specifying the SpiraTest URL, authentication information, project id, release id (optional) and test set id (optional). An example of this is shown above for the SampleFail() method.
Now all you need to do is compile your code, launch Visual Studio, run the test fixtures as you would normally do, and when you view the test cases in SpiraTest, you should see a MSTest automated test run displayed in the list of executed test runs:
Clicking on one of the MSTest test runs will bring up a screen that provides information regarding what MSTest test method failed, what the error was, together with the associated code stack-trace:
Congratulations. You are now able to run MSTest automated tests and have the results be recorded within SpiraTest. The sample test project SampleMSTest is provided with the installation.
"},{"location":"Unit-Testing-Integration/Integrating-with-NUnit/","title":"Integrating with NUnit","text":""},{"location":"Unit-Testing-Integration/Integrating-with-NUnit/#nunit-3","title":"NUnit 3","text":"SpiraTest/SpiraTeam/SpiraPlan (hereon called SpiraPlan) integrates seamlessly with NUnit 3, using our dedicated NUnit add-in. The add-in lets you run unit tests against a .NET application and get the results recorded in SpiraPlan as a test run against a specific test case. The add-in is designed to let you run your suite of unit tests against the application as part of your CI/CD pipeline. The add-in does not - and does not need to - integrate with your CI/CD engine.
To use the add-in you must have:
Please follow the steps below to download and install the add-in:
Once copied, open the NUnit addins file:
addins\\SpiraTestNUnitAddIn.dllSpiraTestNUnitAddIn.dllUsing NUnit and the console runner from NuGet
If integrating via NuGet, find the location of the the version of the NUnit Console Runner referenced by the PATH variable in your windows environment variables.
When installing the console runner via NuGet, this PATH variable will not be set for you. We recommended you do this manually. You should set this new PATH variable to a filepath which ends at the folder containing the nunit3-console.exe you wish to execute.
If you've followed all the steps correctly, the SpiraPlan NUnit add-in should now be properly installed. For reference your nunit.bundle.addins file may look something like this:
addins/nunit.v2.driver.dll\naddins/nunit-v2-result-writer.dll\naddins/nunit-project-loader.dll\naddins/vs-project-loader.dll\naddins/teamcity-event-listener.dll\naddins/SpiraTestNUnitAddIn.dll\nFor this example, we will be using the following sample test fixture:
using NUnit.Framework;\n\nnamespace SampleTestSuite\n{\n[TestFixture]\nclass SampleTest\n{\nint One, Two;\n[SetUp]\nprotected void SetUp()\n{\nOne = 1;\nTwo = 2;\n}\n[Test]\npublic void TestAdd()\n{\nint Result = One + Two;\n//will succeed\nAssert.AreEqual(Result, 3);\n}\n[Test]\npublic void TestMultiply()\n{\nint Result = One * Two;\n//will fail\nAssert.AreEqual(Result, 3);\n}\n[Test]\npublic void TestConcat()\n{\nstring Result = string.Concat(One, Two);\n//will fail\nAssert.AreEqual(Result, \"21\");\n} }\n}\nCreate a new file called (exactly) SpiraConfig.json. We recommend creating one of these files for your entire solution and saving it in a convenient location. This can be in the root folder of your unit tests, or the root folder of your whole solution.
{\n\"credentials\": {\n\"url\": \"localhost/SpiraPlan\",\n\"username\": \"fredbloggs\",\n\"token\": \"{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}\",\n\"project_id\": 1,\n\n\"release_id\": 5,\n\"test_set_id\": 1\n},\n\"test_cases\": {\n\"default\": 20,\n\"TestAdd\": 21,\n\"TestMultiply\": 22\n}\n}\nYou can also avoid setting specific test case IDs through the JSON file and instead place the TestCaseId's directly in the test suite's code. These 2 methods can be used together, with the test suite property for TestCaseId taking priority over the ID set in the JSON file. If using properties you still need the JSON file to store credentials and the \"default\" test case ID.
A minimum JSON file, if only using properties for test case ids is:
{\n\"credentials\": {\n\"url\": \"localhost/SpiraPlan\",\n\"username\": \"fredbloggs\",\n\"token\": \"{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}\",\n\"project_id\": 1,\n\n\"release_id\": 5,\n\"test_set_id\": 1\n},\n\"test_cases\": {\n\"default\": 20\n}\n}\nAn example of using properties inside C# is:
using NUnit.Framework;\n\nnamespace SampleTestSuite\n{\n[TestFixture]\nclass SampleTest\n{\nint One, Two;\n[SetUp]\nprotected void SetUp()\n{\nOne = 1;\nTwo = 2;\n}\n//testcaseid is not case sensitive - any capitalization scheme will work\n[Test, Property(\"testcaseid\", 234)]\npublic void TestAdd()\n{\nint Result = One + Two;\n//will succeed\nAssert.AreEqual(Result, 3);\n}\n[Test, Property(\"TestCaseId\", 235)]\npublic void TestMultiply()\n{\nint Result = One * Two;\n//will fail\nAssert.AreEqual(Result, 3);\n}\n[Test, Property(\"TESTCASEID\", 236)]\npublic void TestConcat()\n{\nstring Result = string.Concat(One, Two);\n//will fail\nAssert.AreEqual(Result, \"21\");\n} }\n}\nFor the plugin to work, you must have credentials, and an assigned test case ID for each test either through the JSON file or the test file. Any combination of the 2 test case ID assignment methods can be used, and will not block the other one from working. The TestCaseId property assigned in test code will take priority over TestCaseId's assigned through the JSON file. If a test case id cannot be found for a given method in either of these locations and there is no default, a warning will be logged above the NUnit test summary which says which method was not reported to Spira.
In the credentials group you must specify:
In the test_cases group, put the following:
Good practice tips
You can have multiple SpiraConfig.json files - one per subfolder in your projects's unit test folder, for example. This can help with maintenance of the json file.
However, when running the test cases it will likely be easier and less error prone to have a single SpiraConfig.json folder for every test in every fixture. If following this approach make sure that each unit test method name is globally unique.
"},{"location":"Unit-Testing-Integration/Integrating-with-NUnit/#running-the-tests-with-nunit","title":"Running the Tests with NUnit","text":"To execute the tests, you should use the NUnit console runner. To do this we need to do two things:
Example command line commands
In this example:
To correctly run the tests and record the results to SpiraPlan, run the following two commands:
cd C:\\TestProjectnunit3-console \"C:\\TestProject\\bin\\Release\\SampleTestSuite.dll\" (If you installed NUnit via NuGet and have not assigned the PATH variable for this console command, you will have to manually reference the NUnit3-console.exe file using a file path instead - This must be inside of quotes just like the second part of the command is)Once you run your tests with the NUnit Console Runner, you should see the results in SpiraPlan:
Clicking on one of the test runs will show you the results:
Congratulations... You are now able to run NUnit automated tests and have the results be recorded within SpiraPlan.
"},{"location":"Unit-Testing-Integration/Integrating-with-NUnit/#installing-the-nunit-2x-add-in","title":"Installing the NUnit 2.x Add-In","text":"This section outlines how to install the SpiraTest Add-In for NUnit onto a workstation so that you can then run automated NUnit tests against a .NET application and have the results be recorded as test runs inside SpiraTest. It assumes that you already have a working installation of SpiraTest v2.2 or later. If you have an earlier version of SpiraTest you will need to upgrade to at least v2.2 before trying to use this add-in. You will also need to have either version v2.5.5 or v2.6.3 of NUnit, since there are two versions of the add-in that have been compiled with the v2.5.5 and v2.6.3 NUnit APIs. If you are using a different version, please visit www.nunit.org to obtain the appropriate version (2.5.5 or 2.6.3).
To obtain the version of the add-in that is compatible with your version of SpiraTest, you simply need to go to http://www.inflectra.com/SpiraTest/Downloads.aspx or http://www.inflectra.com/SpiraTeam/Downloads.aspx and download the NUnit Add-In zipfile.
Once you have obtained the NUnit Zipfile from our website, you should extract all the files from zip archive into a temporary folder on your computer (e.g. C:\\Temp).
Next, you should copy the add-in libraries to the folder NUnit expects to find them in. First, if you are running any instances of the NUnit GUI, close them. Then, copy the SpiraTestNUnitAddIn.dll assembly from its location in the temporary folder to the NUnit Add-In folder (typically C:\\Program Files\\NUnit 2.5.5\\bin\\net-2.0\\addins).
Now you can restart the NUnit GUI application. To check that the add-in was loaded successfully, click on Tools > Addins... to bring up the list of loaded add-ins:
You should see an entry marked \"SpiraTest Addin\" listed with its detailed description and status \"Loaded\". If this does not happen, try closing and reopening NUnit.
"},{"location":"Unit-Testing-Integration/Integrating-with-NUnit/#using-nunit-2x-with-spiratest","title":"Using NUnit 2.x with SpiraTest","text":"The typical code structure for an NUnit test fixture coded in C# is as follows:
using System;\nusing NUnit.Framework;\n\nnamespace Inflectra.SpiraTest.AddOns.SpiraTestNUnitAddIn.SampleTestSuite\n{\n/// <summary>\n/// Sample test fixture that tests the NUnit SpiraTest integration\n/// </summary>\n[TestFixture]\npublic class SampleTestFixture\n{\n[SetUp]\npublic void Init()\n{\n//Do Nothing\n}\n\n/// <summary>\n/// Sample test that asserts a failure\n/// </summary>\n[Test]\npublic void _01_SampleFailure()\n{\n//Failure Assertion\nAssert.AreEqual (1, 0);\n} /// <summary>\n/// Sample test that succeeds\n/// </summary>\n[Test]\npublic void _02_SamplePass()\n{\n//Successful assertion\nAssert.AreEqual (1, 1);\n} /// <summary>\n/// Sample test that fails\n/// </summary>\n[Test]\npublic void _03_SampleIgnore()\n{\n//Failure Assertion\nAssert.AreEqual (1, 0);\n} }\n}\nThe .NET class is marked as an NUnit test fixture by applying the [TestFixture] attribute to the class as a whole, and the [Test] attribute to each of the test assertion methods individually -- highlighted in yellow above. When you open up the class in NUnit and click the <Run> button it loads all the test classes marked with [TestFixture] and executes all the methods marked with [Test] in turn.
Each of the Assert statements is used to test the state of the application after executing some sample code that calls the functionality being tested. If the condition in the assertion is true, then execution of the test continues, if it is false, then a failure is logged and NUnit moves on to the next test method.
So, to use SpiraTest with NUnit, each of the test cases written for execution by NUnit needs to have a corresponding test case in SpiraTest. These can be either existing test cases that have manual test steps or they can be new test cases designed specifically for automated testing and therefore have no defined test steps. In either case, the changes that need to be made to the NUnit test fixture for SpiraTest to record the NUnit test run are illustrated below:
using System;\nusing NUnit.Framework;\nusing Inflectra.SpiraTest.AddOns.SpiraTestNUnitAddIn.SpiraTestFramework;\n\nnamespace Inflectra.SpiraTest.AddOns.SpiraTestNUnitAddIn.SampleTestSuite\n{\n/// <summary>\n/// Sample test fixture that tests the NUnit SpiraTest integration\n/// </summary>\n[\n TestFixture,\n SpiraTestConfiguration (\n \"http://<server name>/SpiraTest\",\n \"<username>\",\n \"<password>\",\n <project id>,\n <release id>,\n <test set id>,\n <runner name>\n)\n ]\npublic class SampleTestFixture\n{\n[SetUp]\npublic void Init()\n{\n//Do Nothing\n}\n\n/// <summary>\n/// Sample test that asserts a failure\n/// </summary>\n[\n Test,\n SpiraTestCase (<test case id>)\n ]\npublic void _01_SampleFailure()\n{\n//Failure Assertion\nAssert.AreEqual (1, 0);\n} /// <summary>\n/// Sample test that succeeds\n/// </summary>\n[\n Test,\n SpiraTestCase (<test case id>))\n ]\npublic void _02_SamplePass()\n{\n//Successful assertion\nAssert.AreEqual (1, 1);\n} /// <summary>\n/// Sample test that does not log to SpiraTest\n/// </summary>\n[\n Test\n ]\npublic void _03_SampleIgnore()\n{\n//Failure Assertion\nAssert.AreEqual (1, 0);\n} }\n}\nThe overall class is marked with a new [SpiraTestConfiguration] attribute that contains the following pieces of information needed to access the SpiraTest test repository:
In addition, each of the individual test methods needs to be mapped to a specific test case within SpiraTest. This is done by adding a [SpiraTestCase] attribute to the test method together with the ID of the corresponding test case in SpiraTest. The Test Case ID can be found on the test cases list page (click the \"Test Cases\" tab).
For these attributes to be available in your test fixture, you also need to add a reference to the SpiraTestFramework.dll assembly. This assembly can be found in the temporary folder that you extracting the add-in to. It is recommended that you move this file from the temporary folder into a permanent folder located within your .NET project.
Now all you need to do is compile your code, launch NUnit, run the test fixtures as you would normally do, and when you view the test cases in SpiraTest, you should see an NUnit automated test run displayed in the list of executed test runs:
Clicking on one of the NUnit test runs will bring up a screen that provides information regarding what NUnit test method failed, what the error was, together with the associated code stack-trace:
Congratulations... You are now able to run NUnit automated tests and have the results be recorded within SpiraTest. The sample test fixture SampleTestSuite.cs is provided with the installation.
"},{"location":"Unit-Testing-Integration/Integrating-with-PHPUnit/","title":"Integrating with PHPUnit","text":""},{"location":"Unit-Testing-Integration/Integrating-with-PHPUnit/#installing-the-phpunit-extension","title":"Installing the PHPUnit Extension","text":"This section outlines how to install the SpiraTest Extension for PHPUnit onto a workstation so that you can then run automated PHPUnit tests against a PHP application and have the results be recorded as test runs inside SpiraTest. It assumes that you already have a working installation of SpiraTest v3 or later, and a working PHP development environment. If you have an earlier version of SpiraTest you will need to upgrade to at least v3 before trying to use this extension.
To obtain the latest version of the SpiraTest PHPUnit extension you simply need to go to http://www.inflectra.com/SpiraTest/Downloads.aspx page and download the PHPUnit Extension compressed archive (.zip). This process is described in the SpiraTest Administration Guide in more detail.
The PHPUnit extension is provided as a set of PHP source files that can be imported into your existing unit tests to add the SpiraTest reporting functionality. Once you have downloaded the Zip archive, you simply need to uncompress it into a folder of your choice on your local system (e.g. C:\\Program Files\\SpiraTest\\PHPUnit Extension)
Now to use the extension within your test cases, you need to first make sure that the folder is added to the PHP include_path. The method for doing this is dependent on the platform you're using, so please refer to the documentation on php.org for details on the appropriate method for your platform. Alternatively you can copy the PHPUnit extension files to the root of the PHP installation and then just include the extension files using the root folder syntax.
Once you have completed these steps, you are now ready to begin using your PHPUnit test fixtures with SpiraTest.
"},{"location":"Unit-Testing-Integration/Integrating-with-PHPUnit/#using-phpunit-with-spiratest","title":"Using PHPUnit with SpiraTest","text":"The typical code structure for a PHPUnit test suite and test case coded in PHP is as follows:
a) Sample Test Suite
<?php\n/**\n * \n * @author Inflectra Corporation\n * @version 0\n *\n */\n\n require_once 'PHPUnit/Framework.php';\n require_once 'PHPUnit/TextUI/ResultPrinter.php';\n require_once './SimpleTest.php';\n\n // Create a test suite that contains the tests\n // from the ArrayTest class\n $suite = new PHPUnit_Framework_TestSuite('SimpleTest');\n\n // Create a test result and attach the default console text listener\n $result = new PHPUnit_Framework_TestResult;\n $textPrinter = new PHPUnit_TextUI_ResultPrinter;\n $result->addListener($textPrinter);\n\n // Run the tests and print the results\n $result = $suite->run($result);\n $textPrinter->printResult($result);\n\n ?>\n\nb) Sample Test Case\n<?php\nrequire_once 'PHPUnit/Framework/TestCase.php';\n\n/**\n * Some simple tests\n * \n * @author Inflectra Corporation\n * @version 0\n *\n */\n\nclass SimpleTest extends PHPUnit_Framework_TestCase\n{\n protected $fValue1;\n protected $fValue2;\n\n /**\n * Sets up the unit test\n */\n protected function setUp()\n {\n $this->fValue1= 2;\n $this->fValue2= 3;\n }\n\n /**\n * Tests the addition of the two values\n */\n public function testAdd()\n {\n $result = $this->fValue1 + $this->fValue2;\n\n // forced failure result == 5\n $this->assertTrue ($result == 6);\n }\n\n /**\n * Tests division by zero\n */\n /*\n public function testDivideByZero()\n {\n $zero = 0;\n $result = 8 / $zero;\n $result++; // avoid warning for not using result\n }\n\n /**\n * Tests two equal values\n */\n /*\npublic function testEquals()\n {\n $this->assertEquals(12, 12);\n $this->assertEquals(10, 10);\n $num1 = 12;\n $num2 = 12;\n $this->assertEquals($num1, $num2);\n\n $this->assertEquals(\"Size\", 12, 13);\n $this->assertEquals(\"Capacity\", 10, 199, 0);\n }\n\n /**\n * Tests success\n */\n /*\n public function testSuccess()\n {\n //Successful test\n $this->assertEquals(12, 12);\n }\n}\n?>\nThe PHP class is marked as a PHPUnit test case by inheriting from the PHPUnit_Framework_TestCase base class, and the individual test methods are identified by using the 'test' prefix, with special setUp() and tearDown() methods reserved for the respective purposes. When you open up the class in a PHPUnit runner or execute from the command line it loads all the test classes and executes all the methods marked with 'test...' in turn.
Each of the Assert statements is used to test the state of the application after executing some sample code that calls the functionality being tested. If the condition in the assertion is true, then execution of the test continues, if it is false, then a failure is logged and PHPUnit moves on to the next test method.
So, to use SpiraTest with PHPUnit, each of the test cases written for execution by PHPUnit needs to have a corresponding test case in SpiraTest. These can be either existing test cases that have manual test steps or they can be new test cases designed specifically for automated testing and therefore have no defined test steps. In either case, the changes that need to be made to the PHPUnit test case and test suite for SpiraTest to record the PHPUnit test run are illustrated below:
a) Sample Test Suite
<?php\n/**\n * Passes a list of tests to be executed to PHPUnit and adds the custom SpiraTest Listener\n * \n * @author Inflectra Corporation\n * @version 0\n *\n */\n\n require_once 'PHPUnit/Framework.php';\n require_once 'PHPUnit/TextUI/ResultPrinter.php';\n require_once './SimpleTest.php';\n require_once '../SpiraListener/Listener.php';\n\n // Create a test suite that contains the tests\n // from the ArrayTest class\n $suite = new PHPUnit_Framework_TestSuite('SimpleTest');\n\n //Set the timezone identifier to match that used by the SpiraTest server\n date_default_timezone_set (\"US/Eastern\");\n\n //Create a new SpiraTest listener instance and specify the connection info\n $spiraListener = new SpiraListener_Listener;\n $spiraListener->setBaseUrl ('http://localhost/SpiraTeam');\n $spiraListener->setUserName ('fredbloggs');\n $spiraListener->setPassword ('fredbloggs');\n $spiraListener->setProjectId (1);\n $spiraListener->setReleaseId (1);\n $spiraListener->setTestSetId (1);\n\n // Create a test result and attach the SpiraTest listener\n // object as an observer to it (as well as the default console text listener)\n $result = new PHPUnit_Framework_TestResult;\n $textPrinter = new PHPUnit_TextUI_ResultPrinter;\n $result->addListener($textPrinter);\n $result->addListener($spiraListener);\n\n // Run the tests and print the results\n $result = $suite->run($result);\n $textPrinter->printResult($result);\n\n ?>\nb) Sample Test Case
<?php\nrequire_once 'PHPUnit/Framework/TestCase.php';\n\n/**\n * Some simple tests using the ability to return results back to SpiraTest\n * \n * @author Inflectra Corporation\n * @version 0\n *\n */\n\nclass SimpleTest extends PHPUnit_Framework_TestCase\n{\n protected $fValue1;\n protected $fValue2;\n\n /**\n * Sets up the unit test\n */\n protected function setUp()\n {\n $this->fValue1= 2;\n $this->fValue2= 3;\n }\n\n /**\n * Tests the addition of the two values\n */\n public function testAdd__2()\n {\n $result = $this->fValue1 + $this->fValue2;\n\n // forced failure result == 5\n $this->assertTrue ($result == 6);\n }\n\n /**\n * Tests division by zero\n */\n /*\n public function testDivideByZero__3()\n {\n $zero = 0;\n $result = 8 / $zero;\n $result++; // avoid warning for not using result\n }\n\n /**\n * Tests two equal values\n */\n /*\npublic function testEquals__4()\n {\n $this->assertEquals(12, 12);\n $this->assertEquals(10, 10);\n $num1 = 12;\n $num2 = 12;\n $this->assertEquals($num1, $num2);\n\n $this->assertEquals(\"Size\", 12, 13);\n $this->assertEquals(\"Capacity\", 10, 199, 0);\n }\n\n /**\n * Tests success\n */\n /*\n public function testSuccess__5()\n {\n //Successful test\n $this->assertEquals(12, 12);\n }\n}\n?>\nFirstly, each of the individual test methods is appended with two underscores followed by the ID of the corresponding test case in SpiraTest. So for example testSuccess() is now testSuccess__5() as it maps to test case TC00005 inside SpiraTest.
Second, in the Test Suite class, the PHPUnit TestResult object is passed an additional PHPUnit listener (in addition to the default one). This special listener class intercepts the results from the test run during execution and uses it to generate the web-service messages that are sent to SpiraTest to communicate the test results.
The following attributes need to be set on the instance of the SpiraListener_Listener() object so that the extension can access the SpiraTest repository:
baseUrl -- The base URL used to access your instance of SpiraTest (e.g. http://myserver/SpiraTest). It should include the protocol (e.g. http/https), the server-name, the port number (if not 80/443) and the virtual directory (if there is one).
userName - A valid username for the instance of SpiraTest that has access to the project specified above
password - A valid password for the user specified above
projectId -- The ID of the project inside SpiraTest (this can be found on the project homepage in the \"Project Overview\" section)
releaseId - The ID of the SpiraTest release to associate the test run with. This can be found on the releases list page (click on the Planning > Releases tab). If you don't want to associate the test run with a specific release, just use the value -1 to indicate N/A.
testSetId - The ID of the SpiraTest test set to associate the test run with. This can be found on the test set list page (click on the Testing > Test Sets tab). If you don't want to associate the test run with a specific test set, just use the value -1 to indicate N/A.
The SpiraListener_Listener class can also be called with the parameters as the constructor arguments:
//Create a new SpiraTest listener instance and specify the connection info\n $spiraListener = new SpiraListener_Listener (\n'http://localhost/SpiraTeam',\n 'fredbloggs',\n 'fredbloggs',\n 1,\n 1,\n 1);\nYou can also attach the listener to the class declaratively by adding it to the phpunit.xml configuration file instead of adding through PHP code:
<phpunit>\n<listeners>\n<listener class=\"SpiraListener_Listener\" file=\"../SpiraListener/Listener.php\">\n<arguments>\n<!-- URL -->\n<string>http://localhost/SpiraTeam</string>\n<!-- User Name -->\n<string>fredbloggs</string>\n<!-- User Password -->\n<string>fredbloggs</string>\n<!-- Project ID -->\n<integer>1</integer>\n<!-- Release ID -->\n<integer>1</integer>\n<!-- Test Set ID -->\n<integer>1</integer>\n</arguments>\n</listener>\n</listeners>\n<testsuites>\n<testsuite name=\"Sample Suite\">\n<directory>.</directory>\n<file>./SampleSuite.php</file>\n</testsuite>\n</testsuites>\n</phpunit>\nNow all you need to do is save your code, launch PHPUnit, run the test suite as you would normally do, and when you view the test cases in SpiraTest, you should see a PHPUnit automated test run displayed in the list of executed test runs:
Clicking on one of the PHPUnit test runs will bring up a screen that provides information regarding what PHPUnit test method failed, what the error was, together with the associated code stack-trace:
Congratulations... You are now able to run PHPUnit automated tests and have the results be recorded within SpiraTest. The sample test suite SampleSuite.php and sample test case SampleTest.php are provided with the installation in the Samples subfolder.
"},{"location":"Unit-Testing-Integration/Integrating-with-Perl-TAP/","title":"Integrating with Perl TAP","text":""},{"location":"Unit-Testing-Integration/Integrating-with-Perl-TAP/#installing-the-perl-tap-extension","title":"Installing the Perl TAP Extension","text":"This section outlines how to install the SpiraTest extensions for Perl's Test Anything Protocol (TAP) so that you can then run automated Perl TAP unit tests against a Perl application and have the results be recorded as test runs inside SpiraTest. It assumes that you already have a working installation of SpiraTest v2.3 or later, and a working Perl development environment. If you have an earlier version of SpiraTest you will need to upgrade to at least v2.3 before trying to use this extension.
To obtain the latest version of the TAP extension you simply need to go to http://www.inflectra.com/SpiraTest/Downloads.aspx page and download the Perl TAP Extension compressed archive (.zip). This process is described in the SpiraTest Administration Guide in more detail.
The TAP extension is provided as a set of Perl library files (.pm) that can be imported into your existing TAP test harnesses to add the SpiraTest reporting functionality. Once you have downloaded the Zip archive, you simply need to uncompress it and copy the Inflectra folder (and subfolders) into the standard Perl library location (e.g. C:\\Perl\\lib on Windows). The sample files (the ones ending in .pl) that are not located in a folder can be put into a folder of your choice.
Once you have completed this step, you are now ready to begin running one of the provided samples or use your existing TAP unit tests with SpiraTest.
"},{"location":"Unit-Testing-Integration/Integrating-with-Perl-TAP/#using-perl-tap-extension-with-spiratest","title":"Using Perl TAP Extension with SpiraTest","text":"The typical code structure for a Perl TAP test harness is as follows:
a) The sample test harness - SampleHarness.pl
#this is a test case that tests addition operations
#!/usr/bin/perl -w
use TAP::Harness;
#instantiate the harness
my $harness = TAP::Harness ->new;
#define the list of tests to be executed
my @tests = (\"SampleTest1.pl\", \"SampleTest2.pl\");
$harness->runtests(@tests);
b) One of the sample test fixtures -- Sample1Test.pl
#!/usr/bin/perl -w
# Specify our plan, how many tests we're writing
use Test::More tests => 9;
# or alternately, if we don't know how many:
# use Test::More qw(no_plan);
# Check that our module compiles and can be \"use\"d.
BEGIN { use_ok( 'Inflectra::SpiraTest::Addons::Samples::TestMe' ); }
# Check our module can be required. Very similar test to that above.
require_ok( 'Inflectra::SpiraTest::Addons::Samples::TestMe' );
# There are a number of ways to generate the \"ok\" tests. These are:
# ok: first argument is true, second argument is name of test.
# is: first argument equals (eq) second argument, third argument is name of test.
# isnt: first argument does not equal (ne) the second, third is name of test
# like: first argument matches regexp in second, third is name of test
# unlike: first argument does not match regexp, third is name of test
# cmp_ok: compares first and third argument with comparison in second. Forth is test name.
# Here are some examples that should PASS
ok( add(1,1) == 2, \"Basic addition is working\");
is ( subtract(2,1), 1, \"Basic subtraction is working\");
isnt( multiply(2,2), 5, \"Basic multiplication doesn't fail\");
# Here are some examples that should FAIL
ok( add(1,1) == 3, \"Basic addition is working\");
is ( subtract(2,1), 0, \"Basic subtraction is working\");
isnt( multiply(2,2), 4, \"Basic multiplication doesn't fail\");
# Here is an example of a test that throws an ERROR
is($notdeclared, 1, \"Undeclared variable test\");
The TAP test cases in the sample code use the Test::More library which provides the necessary assertion methods for testing results from the code under test. The tests are themselves executed by adding their filenames to an array passed to the default TAP::Harness class. To run the test cases, you just need to execute the SampleHarness.pl file from the command line, and the test output will be echoed onto the screen.
Now, to use SpiraTest with TAR, each of the TAP test case files (e.g. SampleTest1.pl, SampleTest2.pl in our example) needs to have a corresponding test case in SpiraTest. These can be either existing test cases that have manual test steps or they can be new test cases designed specifically for automated testing and therefore have no defined test steps. In either case, no changes need to be made to the individual test cases, but the following changes need to be made to the test harness (illustrated in yellow below):
#this is a test case that tests addition operations
#!/usr/bin/perl -w
use Inflectra::SpiraTest::Addons::SpiraHarness::Harness;
#instantiate the harness
my $harness = Inflectra::SpiraTest::Addons::SpiraHarness::Harness->new;
#specify the spiratest custom harness properties
$spira_args = {};
$spira_args->{\"base_url\"} = \"http://localhost/SpiraTest\";
$spira_args->{\"user_name\"} = \"fredbloggs\";
$spira_args->{\"password\"} = \"fredbloggs\";
$spira_args->{\"project_id\"} = 1;
$spira_args->{\"release_id\"} = 1;
$spira_args->{\"test_set_id\"} = 1;
$harness->{\"spira_args\"} = $spira_args;
#define the list of tests and their SpiraTest Mapping
#Hash is of the format: TestFile => Test Case ID
my $tests = {};
$tests->{\"SampleTest1.pl\"} = 2;
$tests->{\"SampleTest2.pl\"} = 3;
harness-\\>runtests(tests);
Firstly you need to use the SpiraTest specific harness rather than the general TAP::Harness library. This new class is actually a subclass of the standard one, so it supports all the same methods, with the exception of the runtests command, which now accepts a Perl hashref rather than a simple array.
Also you need to create and pass a hashref of arguments to the test harness (the spira_args property on the instantiated harness class) so that it knows how to access the SpiraTest server during test execution:
base_url-- The base URL used to access your instance of SpiraTest (e.g. http://myserver/SpiraTest). It should include the protocol (e.g. http/https), the server-name, the port number (if not 80/443) and the virtual directory (if there is one).
user_name - A valid username for the instance of SpiraTest that has access to the project specified above
password - A valid password for the user specified above
project_id - The ID of the project inside SpiraTest (this can be found on the project homepage in the \"Project Overview\" section)
release_id - The ID of the SpiraTest release to associate the test run with. This can be found on the releases list page (click on the Planning > Releases tab). If you don't want to associate the test run with a specific release, just comment out the line.
test_set_id - The ID of the SpiraTest test set to associate the test run with. This can be found on the test set list page (click on the Testing > Test Sets tab). If you don't want to associate the test run with a specific test set, just comment out the line.
Finally instead of passing a simple array of the test case files to be executed, you instead need to create a Perl hashref and pass that to the runtests(...) method. The hashref needs to contain a list of the various test case files and their associated SpiraTest Test Case ID with the TC prefix removed (e.g. test case TC00005 would be just 5).
Now all you need to do is save your code, run the test fixtures as you would normally do (e.g. by executing from the command line), and when you view the test cases in SpiraTest, you should see a Perl::TAP automated test run displayed in the list of executed test runs:
Clicking on one of the Perl::TAP test runs will bring up a screen that provides information regarding what Perl::TAP test method failed, what the error was, together with the associated code stack-trace:
Congratulations... You are now able to run Perl TAP unit tests and have the results be recorded within SpiraTest. The sample test suite SampleHarness.pl together with its two test cases (SampleTest1.pl and SampleTest2.pl) is provided with the installation.
"},{"location":"Unit-Testing-Integration/Integrating-with-PyTest/","title":"Integrating with PyTest","text":"This section describes how to use SpiraTest/SpiraTeam/SpiraPlan (hereafter referred to as SpiraTest) in conjunction with python's pytest unit testing framework. The SpiraTest-pytest plugin enables the automated sending of unit test results from pytest to SpiraTest with a specified Test Case, and (optionally), a release and/or test set as well.
"},{"location":"Unit-Testing-Integration/Integrating-with-PyTest/#installing-the-pytest-plugin","title":"Installing the pytest plugin","text":"This section outlines how to install the SpiraTest plugin for pytest. It assumes that you already have a working installation of SpiraTest v2.3 or later. If you have an earlier version of SpiraTest you will need to upgrade to at least v2.3 before trying to use this plugin. You will also need to have Python (with pip) and pytest version 3.0 or later.
To obtain the latest version of the SpiraTest plugin, simply run the following command:
pip install pytest-spiratest
This command will install the latest version of the plugin straight from the Python Package Index (PyPI). Once the SpiraTest plugin is successfully installed, all you need to do is configure the extension, then you can begin testing!
"},{"location":"Unit-Testing-Integration/Integrating-with-PyTest/#configuring-the-pytest-plugin","title":"Configuring the pytest plugin","text":"This section outlines how to configure the SpiraTest plugin for pytest. It assumes that you are familiar with pytest, and already have some working tests configured.
Here is a sample test file:
import pytest\n\n# Function we are testing\ndef add(num1, num2):\n return num1 + num2\n\n# Successful test\ndef test_add_1():\n assert add(1, 1) == 2\n\n# Failed test\ndef test_add_2():\n assert add(2, 1) == 2\n\n# Failed test\ndef test_add_3():\n assert add(4, 1) == 6\nNote how test_add_2 is used in the configuration file discussed below.
In your test root folder (the folder you run the pytest command from), create a file named \"spira.cfg\" with the following:
[credentials]\n# Following are required\n\nurl = localhost/SpiraTest\nusername = fredbloggs\ntoken = {XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXXX}\nproject_id = 1\n\n# Following are optional:\nrelease_id = 5\ntest_set_id = 1\n\n[test_cases]\n# Assigned to the rest\ndefault = 20\n# Test case for a specific function\ntest_add_2 = 22\nFor the plugin to work, you must have both settings groups (credentials and test_cases) with the following in the credentials group:
url -- The base url to your SpiraTest installation, without a '/' at the end.
username -- The username you use to sign into SpiraTest.
token -- Your RSS Token. Found in your profile page as the \"RSS Token\" field, you must have RSS Feeds enabled for this to work.
project_id -- The ID of the project you would like the test runs to be sent to
release_id -- OPTIONAL -- Use if you would like to associate the test run with a release.
test_set_id -- OPTIONAL -- Use if you would like to associate the test run with a test set.
Under the test_cases group, put the following:
default -- The default test case ID for functions without an assigned test case
\\ - Used to override the default setting for a function's test case ID in SpiraTest. Only include the function name, without the parentheses.
NOTE: If your functions are in a class then add the class before the function name - for example MyClass.myFunction. The plugin is case insensitive.
Once you have filled out all of the configurations, you are all set to go!
Running the pytest (or py.test) command will run your unit tests, send the data to SpiraTest, and show the results to you. Here is an example of the test_add_3 function inside SpiraTest:
"},{"location":"Unit-Testing-Integration/Integrating-with-PyUnit/","title":"Integrating with PyUnit","text":""},{"location":"Unit-Testing-Integration/Integrating-with-PyUnit/#installing-the-pyunit-extension","title":"Installing the PyUnit Extension","text":"This section outlines how to install the SpiraTest Extension for PyUnit onto a workstation so that you can then run automated PyUnit tests against a Python application and have the results be recorded as test runs inside SpiraTest. It assumes that you already have a working installation of SpiraTest v2.3 or later, and a working Python development environment. If you have an earlier version of SpiraTest you will need to upgrade to at least v2.3 before trying to use this extension.
To obtain the version of the PyUnit extension that is compatible with your version of SpiraTest, you simply need to log-in as a project-level administrator to SpiraTest, go to the Administration home page and download the PyUnit Extension compressed archive (.zip). This process is described in the SpiraTest Administration Guide in more detail.
The PyUnit extension is provided as a set of Python source files that can be imported into your existing unit tests to add the SpiraTest reporting functionality. Once you have downloaded the Zip archive, you simply need to uncompress it into a folder of your choice on your local system (e.g. C:\\Program Files\\SpiraTest\\PyUnit Extension)
Now to use the extension within your test cases, you need to first make sure that the folder is added to the Python PYTHONPATH. The method for doing this is dependent on the platform you're using, so please refer to the documentation on python.org for details on the appropriate method for your platform. As an example, on a Windows platform, the folder would be added to the PYTHONPATH by typing the following:
set PYTHONPATH=%PYTHONPATH%; C:\\Program Files\\SpiraTest\\PyUnit Extension
Once you have completed this step, you are now ready to begin using your PyUnit test fixtures with SpiraTest.
"},{"location":"Unit-Testing-Integration/Integrating-with-PyUnit/#using-pyunit-with-spiratest","title":"Using PyUnit with SpiraTest","text":"The typical code structure for a PyUnit test fixture coded in Python is as follows:
import random\n\nimport unittest\n\n\\# sample PyUnit test case\n\nclass TestSequenceFunctions(unittest.TestCase):\n\ndef setUp(self):\n\nself.seq = range(10)\n\ndef testshuffle(self):\n\n\\# make sure the shuffled sequence does not lose any elements\n\nrandom.shuffle(self.seq)\n\nself.seq.sort()\n\nself.assertEqual(self.seq, range(10))\n\ndef testchoice(self):\n\nelement = random.choice(self.seq)\n\nself.assert\\_(element in self.seq)\n\ndef testfail(self):\n\nself.assertEqual(1, 2, \"1==2 Should fail\")\n\ndef testsample(self):\n\nself.assertRaises(ValueError, random.sample, self.seq, 20)\n\nfor element in random.sample(self.seq, 5):\n\nself.assert\\_(element in self.seq)\n\nsuite =\nunittest.TestLoader().loadTestsFromTestCase(TestSequenceFunctions)\n\ntestResult = unittest.TextTestRunner(verbosity=2).run(suite)\nThe Python class is marked as a PyUnit test fixture by inheriting from the unittest.TestCase base class, and the individual test methods are identified by using the 'test' prefix, with special setUp() and tearDown() methods reserved for the respective purposes. When you open up the class in a PyUnit runner or execute from the command line it loads all the test classes and executes all the methods marked with 'test...' in turn.
Each of the Assert statements is used to test the state of the application after executing some sample code that calls the functionality being tested. If the condition in the assertion is true, then execution of the test continues, if it is false, then a failure is logged and PyUnit moves on to the next test method.
So, to use SpiraTest with PyUnit, each of the test cases written for execution by PyUnit needs to have a corresponding test case in SpiraTest. These can be either existing test cases that have manual test steps or they can be new test cases designed specifically for automated testing and therefore have no defined test steps. In either case, the changes that need to be made to the PyUnit test fixture for SpiraTest to record the PyUnit test run are illustrated below:
import random\n\nimport unittest\n\nimport spiratestextension\n\n\\# sample PyUnit test case\n\nclass TestSequenceFunctions(unittest.TestCase):\n\ndef setUp(self):\n\nself.seq = range(10)\n\ndef testshuffle\\_\\_2(self):\n\n\\# make sure the shuffled sequence does not lose any elements\n\nrandom.shuffle(self.seq)\n\nself.seq.sort()\n\nself.assertEqual(self.seq, range(10))\n\ndef testchoice\\_\\_3(self):\n\nelement = random.choice(self.seq)\n\nself.assert\\_(element in self.seq)\n\ndef testfail\\_\\_4(self):\n\nself.assertEqual(1, 2, \"1==2 Should fail\")\n\ndef testsample\\_\\_5(self):\n\nself.assertRaises(ValueError, random.sample, self.seq, 20)\n\nfor element in random.sample(self.seq, 5):\n\nself.assert\\_(element in self.seq)\n\nsuite =\nunittest.TestLoader().loadTestsFromTestCase(TestSequenceFunctions)\n\ntestResult = unittest.TextTestRunner(verbosity=2).run(suite)\n\nreleaseId = 1\n\ntestSetId = 1\n\nspiraTestExtension = spiratestextension.SpiraTestExtension()\n\nspiraTestExtension.projectId = 1\n\nspiraTestExtension.server = \"localhost\"\n\nspiraTestExtension.port = 80\n\nspiraTestExtension.ssl = False\n\nspiraTestExtension.path = \"SpiraTest\"\n\nspiraTestExtension.userName = \"fredbloggs\"\n\nspiraTestExtension.password = \"PleaseChange\"\n\nspiraTestExtension.recordResults(TestSequenceFunctions, testResult,\nreleaseId, testSetId)\nFirstly, each of the individual test methods is appended with two underscores followed by the ID of the corresponding test case in SpiraTest. So for example testshuffle() is now testshuffle__2() as it maps to test case TC00002 inside SpiraTest.
Second, at the end of the test run, the testResults object generated by the test run is passed to a special SpiraTestExtension() class via the recordResults() method. This class takes the results from the test run and uses it to generate the web-service messages that are sent to SpiraTest to communicate the test results.
The following attributes need to be set on the instance of the SpiraTestExtension() object so that the extension can access the SpiraTest repository:
spiraTestExtension.projectId -- The ID of the project inside SpiraTest (this can be found on the project homepage in the \"Project Overview\" section)
spiraTestExtension.server - The name of the web server that SpiraTest is installed on
spiraTestExtension.port -- The port used to access SpiraTest over the network (typically 80 unless you have a custom port setup)
spiraTestExtension.ssl -- This should be set to False for HTTP and True for HTTPS
spiraTestExtension.path -- The path to SpiraTest on your webserver (typically just 'SpiraTest')
spiraTestExtension.userName - A valid username for the instance of SpiraTest that has access to the project specified above
spiraTestExtension.password - A valid password for the user specified above
In addition, when calling the recordResults() method, you should also pass the Release ID and the Test Set ID which is used to tell SpiraTest which release and/or test set to associate the test execution with.
The Release ID can be found on the releases list page (click on the Planning > Releases tab) -- just remove the RL prefix from the number as well as any leading zeros. Similarly, the Test Set ID can be found on the test set list page (click on the Testing > Test Sets tab) -- just remove the TX prefix from the number as well as any leading zeros. If you don't want to associate the test run with a specific release or test set, just use the special value -1 to indicate N/A.
Now all you need to do is save your code, launch PyUnit, run the test fixtures as you would normally do, and when you view the test cases in SpiraTest, you should see a PyUnit automated test run displayed in the list of executed test runs:
Clicking on one of the PyUnit test runs will bring up a screen that provides information regarding what PyUnit test method failed, what the error was, together with the associated code stack-trace:
Congratulations... You are now able to run PyUnit automated tests and have the results be recorded within SpiraTest. The sample test fixture testsequencefunctions.py is provided with the installation.
"},{"location":"Unit-Testing-Integration/Integrating-with-Ruby-TestUnit/","title":"Integrating with Ruby Test::Unit","text":""},{"location":"Unit-Testing-Integration/Integrating-with-Ruby-TestUnit/#installing-the-ruby-testunit-test-runner","title":"Installing the Ruby Test::Unit Test Runner","text":"This section outlines how to install the SpiraTest custom Test Runner for Test::Unit onto a workstation so that you can then run automated Test::Unit tests against a Ruby application and have the results be recorded as test runs inside SpiraTest. It assumes that you already have a working installation of SpiraTest v2.3 or later, and a working Ruby development environment. If you have an earlier version of SpiraTest you will need to upgrade to at least v2.3 before trying to use this extension.
To obtain the version of the Test::Unit test runner that is compatible with your version of SpiraTest, you simply need to log-in as a project-level administrator to SpiraTest, go to the Administration home page and download the Test::Unit test runner compressed archive (.zip). This process is described in the SpiraTest Administration Guide in more detail.
The Test::Unit test runner is provided as a set of Ruby source files that can be imported into your existing unit tests to add the SpiraTest reporting functionality. Once you have downloaded the Zip archive, you simply need to uncompress it into a folder of your choice on your local system (e.g. C:\\Program Files\\SpiraTest\\RubyTestUnitRunner)
Now to use the custom test runner within your test cases, you need to first make sure that the folder is added to the Ruby RUBYPATH (or just the system PATH). The method for doing this is dependent on the platform you're using, so please refer to the documentation on http://ruby-lang.org for details on the appropriate method for your platform. As an example, on a Windows platform, the folder would be added to the RUBYPATH by typing the following:
set RUBYPATH=%RUBYPATH%; C:\\Program Files\\SpiraTest\\RubyTestUnitRunner
Once you have completed this step, you are now ready to begin using your Test::Unit test fixtures with SpiraTest.
"},{"location":"Unit-Testing-Integration/Integrating-with-Ruby-TestUnit/#using-ruby-testunit-with-spiratest","title":"Using Ruby Test::Unit with SpiraTest","text":"The typical code structure for a Test::Unit test suite and test case coded in Ruby is as follows:
#this is a test case that tests addition operations
class TC_Adder < Test::Unit::TestCase
def setup
@adder = Adder.new(5)
end
def test_add
assert_equal(7, @adder.add(2), \"Should have added correctly\")
end
def test_addfail
assert_equal(7, @adder.add(3), \"Test failure\")
end
def teardown
@adder = nil
end
end
#this is a test suite that calls the test case
class TS_Examples
def self.suite
suite = Test::Unit::TestSuite.new
suite << TC_Adder.suite
return suite
end
end
Test::Unit::UI::Console::TestRunner.run(TS_Examples)
The Test::Unit test case is marked as a Test::Unit test case by inheriting from the Test::Unit::TestCase base class, and the individual test methods are identified by using the 'test' prefix, with special setup and teardown methods reserved for the respective purposes. When you open up the class in a Ruby Test::Unit runner or execute from the command line it loads all the test classes and executes all the methods marked with 'test...' in turn.
Each of the Assert statements is used to test the state of the application after executing some sample code that calls the functionality being tested. If the condition in the assertion is true, then execution of the test continues, if it is false, then a failure is logged and Test::Unit moves on to the next test method.
So, to use SpiraTest with Test::Unit, each of the test cases written for execution by Test::Unit needs to have a corresponding test case in SpiraTest. These can be either existing test cases that have manual test steps or they can be new test cases designed specifically for automated testing and therefore have no defined test steps. In either case, the changes that need to be made to the Test::Unit test case and test suite for SpiraTest to record the Test::Unit test run are illustrated below:
#this is a test case that tests addition operations
class TC_Adder < Test::Unit::TestCase
def setup
@adder = Adder.new(5)
end
def test_add__2
assert_equal(7, @adder.add(2), \"Should have added correctly\")
end
def test_addfail__3
assert_equal(7, @adder.add(3), \"Test failure\")
end
def teardown
@adder = nil
end
end
#this is a test suite that calls the test case
class TS_Examples
def self.suite
suite = Test::Unit::TestSuite.new
suite << TC_Adder.suite
return suite
end
end
projectId = 1
releaseId = 2
testSetId = -1
testRunner = Test::Unit::SpiraTest::TestRunner.new(TS_Examples, \"http://servername/SpiraTest\", \"fredbloggs\", \"fredbloggs\", projectId, releaseId, testSetId)
testRunner.start
Firstly, each of the individual test methods is appended with two underscores followed by the ID of the corresponding test case in SpiraTest. So for example test_add is now test_add__2 as it maps to test case TC00002 inside SpiraTest.
Second, at the end of the test suite, instead of just creating the standard Console Test Runner class and passing it a reference to the test suite (e.g. TS_Examples), we now create an instance of the special Test::Unit::SpiraTest::TestRunner class, passing it a reference to the test suite as well as specifying the SpiraTest connection information.
This class takes the results from the test suite being executed and uses it to generate the web-service messages that are sent to SpiraTest to communicate the test results.
The following parameters need to be passed during the instantiation of the Test::Unit::SpiraTest::TestRunner object so that the custom test runner can access the SpiraTest repository:
suite -- the reference to the Test::Unit test suite that contains the test cases being executed. In our example above, this is the TS_Examples class.
baseUrl-- The base URL used to access your instance of SpiraTest (e.g. http://myserver/SpiraTest). It should include the protocol (e.g. http/https), the server-name, the port number (if not 80/443) and the virtual directory (if there is one).
userName - A valid username for the instance of SpiraTest that has access to the project specified above
password - A valid password for the user specified above
projectId - The ID of the project inside SpiraTest (this can be found on the project homepage in the \"Project Overview\" section)
releaseId - The ID of the SpiraTest release to associate the test run with. This can be found on the releases list page (click on the Planning > Releases tab). If you don't want to associate the test run with a specific release, just use the value -1 to indicate N/A.
testSetId - The ID of the SpiraTest test set to associate the test run with. This can be found on the test set list page (click on the Testing > Test Sets tab). If you don't want to associate the test run with a specific test set, just use the value -1 to indicate N/A.
Now all you need to do is save your code, launch Test::Unit, run the test fixtures as you would normally do (e.g. by executing the TS_Examples ruby file from the command line), and when you view the test cases in SpiraTest, you should see a Ruby Test::Unit automated test run displayed in the list of executed test runs:
Clicking on one of the Ruby Test::Unit test runs will bring up a screen that provides information regarding what Ruby Test::Unit test method failed, what the error was, together with the associated code stack-trace:
Congratulations... You are now able to run Test::Unit automated tests and have the results be recorded within SpiraTest. The sample test suite ts_examples.rb together with two test cases (tc_adder and tc_subtracter) is provided with the installation.
"},{"location":"Unit-Testing-Integration/Integrating-with-Selenium/","title":"Integrating with Selenium","text":"Selenium WebDriver is a test tool that allows you to write automated web application user interface tests in any programming language against any HTTP website using any mainstream JavaScript-enabled browser. Selenium WebDriver comes in two parts.
An API or library for the web browser itself that is used to allow external applications to connect to the web browser and instruct it to perform certain operations.
Client libraries for various computer languages - these are referred to as 'language bindings.
Therefore to use SpiraTest with Selenium WebDriver (hereafter referred to as just Selenium), you need to decide which client driver you want to use, and then use the appropriate integration between SpiraTest and that driver's underlying platform/language. Any unit test framework listed in this guide can be used with Selenium (in addition to just running unit tests), we have some examples below for .NET, Java and Python.
"},{"location":"Unit-Testing-Integration/Integrating-with-Selenium/#using-the-net-driver","title":"Using the .NET Driver","text":"To use the .NET driver for Selenium with SpiraTest, you will need to run your Selenium tests within the context of an NUnit test fixture. Once you have configured NUnit for use with SpriaTest, there is one change that needs to be made to the SpiraTest NUnit configuration so that the Selenium tests report back to SpiraTest as 'Selenium' rather than \"NUnit' so you can distinguish between them.
Supplied with the SpiraTest NUnit add-in is a sample test for using Selenium with SpiraTest:
using System;\nusing NUnit.Framework;\nusing Inflectra.SpiraTest.AddOns.SpiraTestNUnitAddIn.SpiraTestFramework;\nusing Selenium;\n\nnamespace SeleniumSampleTest\n{\n/// <summary>\n/// Sample test fixture that tests the NUnit SpiraTest integration with the\n/// Selenium-RC .NET Driver\n/// </summary>\n[\n TestFixture,\n SpiraTestConfiguration(\"http://localhost/SpiraTest\", \"fredbloggs\", \"fredbloggs\", 1, 1, 2, SpiraTestConfigurationAttribute.RunnerName.Selenium)\n ]\npublic class GoogleTest\n{\nprivate static ISelenium selenium;\n\n[SetUp]\npublic void SetupTest()\n{\n//Instantiate the selenium .NET proxy\nselenium = new DefaultSelenium(\"localhost\", 4444, \"*iexplore\", \"http://www.google.com\");\nselenium.Start();\n}\n\n[TearDown]\npublic void TeardownTest()\n{\nselenium.Stop();\n}\n\n/// <summary>\n/// Sample test that searches on Google, passes correctly\n/// </summary>\n[\n Test,\n SpiraTestCase (5)\n ]\npublic void GoogleSearch()\n{\n//Opens up Google\nselenium.Open(\"http://www.google.com/webhp\");\n\n//Verifies that the title matches\nAssert.AreEqual(\"Google\", selenium.GetTitle());\nselenium.Type(\"q\", \"Selenium OpenQA\");\n\n//Verifies that it can find the Selenium website\nAssert.AreEqual(\"Selenium OpenQA\", selenium.GetValue(\"q\"));\nselenium.Click(\"btnG\");\nselenium.WaitForPageToLoad(\"5000\");\nAssert.IsTrue(selenium.IsTextPresent(\"www.openqa.org\"));\nAssert.AreEqual(\"Selenium OpenQA - Google Search\", selenium.GetTitle());\n} }\n}\nThe details of the sample itself are described in more detail on the Selenium website, and you can see that we have added the SpiraTest specific attributes onto the test case and test methods to indicate that they need to report back to SpiraTest.
However there is one change that has been made to the SpiraTestConfiguration attribute applied to the test fixture -- an extra SpiraTestConfigurationAttribute.RunnerName.Selenium parameter has been specified. This tells the SpiraTest NUnit add-in to report the results back as being generated by Selenium rather than NUnit.
"},{"location":"Unit-Testing-Integration/Integrating-with-Selenium/#using-the-java-driver","title":"Using the Java Driver","text":"To use the Java driver for Selenium with SpiraTest, you will need to run your Selenium tests within the context of a TestNG test fixture. Once you have configured TestNG for use with SpriaTest, there is one change that needs to be made to the SpiraTest TestNG configuration so that the Selenium tests report back to SpiraTest as 'Selenium' rather than \"TestNG' so you can distinguish between them.
Supplied with the SpiraTest TestNG listener is a sample test for using Selenium with SpiraTest:
The details of the sample itself are described in more detail on the Selenium website, and you can see that we have added the SpiraTest specific attributes onto the test case and test methods to indicate that they need to report back to SpiraTest.
package com.inflectra.spiratest.addons.testnglistener.samples;\n\nimport org.testng.annotations.*;\nimport static org.testng.AssertJUnit.*;\nimport com.thoughtworks.selenium.*;\n\nimport com.inflectra.spiratest.addons.testnglistener.*;\n\n/**\n * A sample Selenium test using the ability to return results back to SpiraTest\n * \n * @author Inflectra Corporation\n * @version 2.3.0\n *\n */\n@SpiraTestConfiguration(\nurl=\"http://localhost/SpiraTest\",\nlogin=\"fredbloggs\",\npassword=\"fredbloggs\",\nprojectId=1,\nreleaseId=1,\ntestSetId=-1\nrunner=RunnerName.Selenium\n)\n@Test(groups={\"seleniumtest\"})\npublic class SeleniumTest\n{\nprivate Selenium selenium;\n\n@BeforeClass\npublic void setUp()\n{\n//Instantiate the selenium Java proxy\nString url = \"http://www.google.com\";\nselenium = new DefaultSelenium(\"localhost\", 4444, \"*firefox\", url);\nselenium.start();\n}\n\n@AfterClass\nprotected void tearDown()\n{\nselenium.stop();\n}\n\n// Sample test that searches on Google, passes correctly\n@Test(groups={\"seleniumtest\"})\n@SpiraTestCase(testCaseId=5)\npublic void testGoogle()\n{\n//Opens up Google\nselenium.open(\"http://www.google.com/webhp?hl=en\");\n\n//Verifies that the title matches\nassertEquals(\"Google\", selenium.getTitle());\nselenium.type(\"q\", \"Selenium OpenQA\");\n\n//Verifies that it can find the Selenium website\nassertEquals(\"Selenium OpenQA\", selenium.getValue(\"q\"));\nselenium.click(\"btnG\");\nselenium.waitForPageToLoad(\"5000\");\nassertEquals(\"Selenium OpenQA - Google Search\", selenium.getTitle());\n}\n}\nHowever there is one change that has been made to the SpiraTestConfiguration attribute applied to the test fixture -- an extra runner=RunnerName.Selenium parameter has been specified. This tells the SpiraTest TestNG listener to report the results back as being generated by Selenium rather than TestNG.
"},{"location":"Unit-Testing-Integration/Integrating-with-Selenium/#using-the-python-driver","title":"Using the Python Driver","text":"To use the Python driver for Selenium with SpiraTest, you will need to run your Selenium tests within the context of a PyUnit unit-test fixture. Once you have configured PyUnit for use with SpriaTest, there is one change that needs to be made to the SpiraTest PyUnit configuration so that the Selenium tests report back to SpiraTest as 'Selenium' rather than \"PyUnit' so you can distinguish between them.
Supplied with the SpiraTest PyUnit extension is a sample test for using Selenium with SpiraTest:
from selenium import selenium\nimport unittest\nimport sys, time\nimport spiratestextension\n\n# A sample Selenium test using the ability to return results back to SpiraTest\n#\n# Author Inflectra Corporation\n# Version 2.3.0\n#\nclass TestSeleniumSample(unittest.TestCase):\n\n seleniumHost = 'localhost'\n seleniumPort = str(4444)\n browserStartCommand = \"*firefox\"\n browserURL = \"http://www.google.com\"\n\n def setUp(self):\n print \"Using selenium server at \" + self.seleniumHost + \":\" + self.seleniumPort\n self.selenium = selenium(self.seleniumHost, self.seleniumPort, self.browserStartCommand, self.browserURL)\n self.selenium.start()\n\n def testGoogle__4(self):\n selenium = self.selenium\n selenium.open(\"http://www.google.com/webhp?hl=en\")\n\n #Verifies that the title matches\n self.assertEqual (\"Google\", selenium.get_title())\n selenium.type(\"q\", \"Selenium OpenQA\")\n\n #Verifies that it can find the Selenium website\n self.assertEqual(\"Selenium OpenQA\", selenium.get_value(\"q\"))\n selenium.click(\"btnG\")\n selenium.wait_for_page_to_load(\"5000\")\n self.assertEqual(\"Selenium OpenQA - Google Search\", selenium.get_title())\n\n def tearDown(self):\n self.selenium.stop()\n\nsuite = unittest.TestLoader().loadTestsFromTestCase(TestSeleniumSample)\ntestResult = unittest.TextTestRunner(verbosity=2).run(suite)\nreleaseId = 1\ntestSetId = -1\nspiraTestExtension = spiratestextension.SpiraTestExtension()\nspiraTestExtension.projectId = 1\nspiraTestExtension.server = \"localhost\"\nspiraTestExtension.port = 80\nspiraTestExtension.path = \"SpiraTest\"\nspiraTestExtension.userName = \"fredbloggs\"\nspiraTestExtension.password = \"fredbloggs\"\nspiraTestExtension.recordResults(TestSeleniumSample, testResult, releaseId, testSetId, \"Selenium\")\nThe details of the sample itself are described in more detail on the Selenium website, and you can see that we have added the SpiraTest specific test case suffixes and reporting code into the test methods to indicate that they need to report back to SpiraTest.
However there is one change that has been made to the spiraTestExtension.recordResults method called at the end of the test case. An extra string parameter has been specified that contains \"Selenium\". This tells the SpiraTest PyUnit extension to report the results back as being generated by Selenium rather than PyUnit.
"},{"location":"Unit-Testing-Integration/Integrating-with-TestNG/","title":"Integrating with TestNG","text":""},{"location":"Unit-Testing-Integration/Integrating-with-TestNG/#installing-the-testng-listener","title":"Installing the TestNG Listener","text":"This section outlines how to install the SpiraTest Listener for TestNG onto a workstation so that you can then run automated TestNG unit tests against a Java application and have the results be recorded as test runs inside SpiraTest. It assumes that you already have a working installation of SpiraTest v3.0 or later. If you have an earlier version of SpiraTest you will need to upgrade to at least v3.0 before trying to use this listener. You will also need to have at least version 1.0 of TestNG running under JDK 1.5 or later, since earlier versions do not have support for annotations and custom listeners. If you are using an earlier version, please visit testng.org to obtain the latest version.
To obtain the latest version of the TestNG listener, you simply need to log-in as a project-level administrator to SpiraTest, go to the Administration home page and download the SpiraTest TestNG Listener compressed archive (.zip) from the section that lists downloads and add-ons. This process is described in the SpiraTest Administration Guide in more detail.
The TestNG listener is provided as a compressed zipfile that includes both the binaries (packaged as a JAR-file) and the source code (stored in a folder structure that mirrors the Java classpath). The JAR-file binary was compiled for use on a Windows x86 platform, other platforms (e.g. Linux) will require you to compile the Java source files into the appropriate Java classfiles before using the extension. The rest of this section will assume that you are using the pre-compiled JAR-file.
Once you have downloaded the Zip archive, you need to uncompress it into a folder of your choice on your local system. Assuming that you uncompressed it to the C:\\Program Files\\SpiraTestListener folder, you should have the following folder structure created:
C:\\Program Files\\SpiraTestListener
C:\\Program Files\\SpiraTestListener\\com
C:\\Program Files\\SpiraTestListener\\com\\inflectra
C:\\Program Files\\SpiraTestListener\\com\\inflectra\\spiratest
C:\\Program Files\\SpiraTestListener\\com\\inflectra\\spiratest\\addons
C:\\Program Files\\SpiraTestListener\\com\\inflectra\\spiratest\\addons\\testnglistener
C:\\Program Files\\SpiraTestListener\\Extension\\com\\inflectra\\spiratest\\addons\\testnglistener\\samples
The JAR-file is located in the root folder, the source-code for the extension can be found in the \"testnglistener\" subfolder, and the sample test fixture can be found in the \"samples\" subfolder.
Now to use the listener within your test cases, you need to first make sure that the JAR-file is added to the Java classpath. The method for doing this is dependent on the platform you're using, so please refer to FAQ on www.testngorg for details on the appropriate method for your platform. As an example, on a Windows platform, the JAR-file would be added to the classpath by typing the following:
set CLASSPATH=%CLASSPATH%; C:\\Program Files\\SpiraTestListener\\TestNGListener.jar
Once you have completed this step, you are now ready to begin using your TestNG test fixtures with SpiraTest.
"},{"location":"Unit-Testing-Integration/Integrating-with-TestNG/#using-testng-with-spiratest","title":"Using TestNG with SpiraTest","text":"The typical code structure for a TestNG test fixture coded in Java is as follows:
package com.inflectra.spiratest.addons.testnglistener.samples;\n\nimport org.testng.annotations.*;\nimport static org.testng.AssertJUnit.*;\n\nimport java.util.*;\n\n/**\n * Some simple tests using the ability to return results back to SpiraTest\n * \n * @author Inflectra Corporation\n * @version 2.3.0\n *\n */\n@Test(groups={\"unittest\"})\npublic class SimpleTest\n{\nprotected int fValue1;\nprotected int fValue2;\n\n/**\n * Sets up the unit test\n */\n@BeforeClass\npublic void setUp()\n{\nfValue1= 2;\nfValue2= 3;\n}\n\n/**\n * Tests the addition of the two values\n */\n@Test(groups={\"unittest\"})\npublic void testAdd()\n{\ndouble result = fValue1 + fValue2;\n\n// forced failure result == 5\nassertTrue (result == 6);\n}\n\n/**\n * Tests division by zero\n */\n@Test(groups={\"unittest\"})\npublic void testDivideByZero()\n{\nint zero = 0;\nint result = 8 / zero;\nresult++; // avoid warning for not using result\n}\n\n/**\n * Tests two equal values\n */\n@Test(groups={\"unittest\"})\npublic void testEquals()\n{\nassertEquals(12, 12);\nassertEquals(12L, 12L);\nassertEquals(new Long(12), new Long(12));\n\nassertEquals(\"Size\", 12, 13);\nassertEquals(\"Capacity\", 12.0, 11.99, 0.0);\n}\n\n/**\n * Tests success\n */\n@Test(groups={\"unittest\"})\npublic void testSuccess()\n{\n//Successful test\nassertEquals(12, 12);\n}\n}\nThe Java class is marked as a TestNG test fixture by applying the @Test attribute to the class definition, and the @Test attribute to each of the test assertion methods individually -- highlighted in yellow above. In addition, special setup methods are marked with annotations such as @BeforeClass. When you open up the class in a TestNG runner or execute from the command line it loads all the test classes and executes all the methods marked with @Test in turn.
Each of the Assert statements is used to test the state of the application after executing some sample code that calls the functionality being tested. If the condition in the assertion is true, then execution of the test continues, if it is false, then a failure is logged and TestNG moves on to the next test method.
So, to use SpiraTest with TestNG, each of the test cases written for execution by TestNG needs to have a corresponding test case in SpiraTest. These can be either existing test cases that have manual test steps or they can be new test cases designed specifically for automated testing and therefore have no defined test steps. In either case, the changes that need to be made to the TestNG test fixture for SpiraTest to record the TestNG test run are illustrated below:
package com.inflectra.spiratest.addons.testnglistener.samples;\n\nimport org.testng.annotations.*;\nimport static org.testng.AssertJUnit.*;\n\nimport com.inflectra.spiratest.addons.testnglistener.*;\n\nimport java.util.*;\n\n/**\n * Some simple tests using the ability to return results back to SpiraTest\n * \n * @author Inflectra Corporation\n * @version 2.3.0\n *\n */\n@SpiraTestConfiguration(\nurl=\"http://localhost/SpiraTest\",\nlogin=\"fredbloggs\",\napiKey=\"{00000000-0000-0000-0000-000000000000}\",\nprojectId=1,\nreleaseId=1,\ntestSetId=-1\n)\n@Test(groups={\"unittest\"})\npublic class SimpleTest\n{\nprotected int fValue1;\nprotected int fValue2;\n\n/**\n * Sets up the unit test\n */\n@BeforeClass\npublic void setUp()\n{\nfValue1= 2;\nfValue2= 3;\n}\n\n/**\n * Tests the addition of the two values\n */\n@Test(groups={\"unittest\"})\n@SpiraTestCase(testCaseId=5)\npublic void testAdd()\n{\ndouble result = fValue1 + fValue2;\n\n// forced failure result == 5\nassertTrue (result == 6);\n}\n\n/**\n * Tests division by zero\n */\n@Test(groups={\"unittest\"})\n@SpiraTestCase(testCaseId=5)\npublic void testDivideByZero()\n{\nint zero = 0;\nint result = 8 / zero;\nresult++; // avoid warning for not using result\n}\n\n/**\n * Tests two equal values\n */\n@Test(groups={\"unittest\"})\n@SpiraTestCase(testCaseId=6)\npublic void testEquals()\n{\nassertEquals(12, 12);\nassertEquals(12L, 12L);\nassertEquals(new Long(12), new Long(12));\n\nassertEquals(\"Size\", 12, 13);\nassertEquals(\"Capacity\", 12.0, 11.99, 0.0);\n}\n\n/**\n * Tests success\n */\n@Test(groups={\"unittest\"})\n@SpiraTestCase(testCaseId=6)\npublic void testSuccess()\n{\n//Successful test\nassertEquals(12, 12);\n}\n}\nThe overall class is marked with a new @SpiraTestConfiguration attribute that contains the following pieces of information needed to access the SpiraTest test repository:
URL - The URL to the instance of SpiraTest being accessed. This needs to start with http:// or https://
Login - A valid username for the instance of SpiraTest.
apiKey - A valid API Key / RSS Token for the instance of SpiraTest (for the user specified in Login).
Project Id - The ID of the project (this can be found on the project homepage in the \"Project Overview\" section)
Release Id (Optional) - The ID of the release to associate the test run with. This can be found on the releases list page (click on the Planning > Releases tab). If you don't want to specify a release, just use the value -1.
Test Set Id (Optional) -- The ID of the test set to associate the test run with. This can be found on the test set list page (click on the Testing > Test Sets tab). If you don't want to specify a test set, just use the value -1. If you choose a test set that is associated with a release, then you don't need to explicitly set a release id (i.e. just use -1). However if you do set a release value, it will override the value associated with the test set.
In addition, each of the individual test methods needs to be mapped to a specific test case within SpiraTest. This is done by adding a @SpiraTestCase attribute to the test method together with the ID of the corresponding test case in SpiraTest. The Test Case ID can be found on the test cases list page (click the \"Test Cases\" tab).
For these attributes to be available in your test fixture, you also need to add a reference to the com.inflectra.spiratest.addons.testnglistener package. This package is bundled within the supplied JAR-file library for Windows machines, and can be compiled from the provided source .java files on other platforms.
"},{"location":"Unit-Testing-Integration/Integrating-with-TestNG/#running-the-testng-tests-from-the-command-line","title":"Running the TestNG Tests from the Command-Line","text":"Now all you need to do is compile your code and then launch TestNG by executing the test fixture through the command line (or through your choice of IDE, e.g. Eclipse) with the SpiraTest listener option specified as a command argument. E.g. for our sample test, you would use the following command:
java -classpath \"C:\\Program Files\\SpiraTestListener\\TestNGListener.jar;C:\\Program Files\\TestNG-5.7\\testng-5.7\\testng-5.7-jdk15.jar\" org.testng.TestNG -listener com.inflectra.spiratest.addons.testnglistener.SpiraTestListener com\\inflectra\\spiratest\\addons\\testnglistener\\samples\\unittests.xml
Once the test has run, you can view the test cases in SpiraTest, you should see a TestNG automated test run displayed in the list of executed test runs:
Clicking on one of the TestNG test runs will bring up a screen that provides information regarding what TestNG test method failed, what the error was, together with the associated code stack-trace:
Congratulations... You are now able to run TestNG automated tests and have the results be recorded within SpiraTest. The sample test fixture SimpleText.java is provided with the installation.
"},{"location":"Unit-Testing-Integration/Using-Test-Runner-For-Excel/","title":"Spira Test Runner add-in for Excel 365","text":"This add-in lets you retrieve your assigned Test Cases and Test Sets for a specific product in SpiraTest\u00ae, SpiraTeam\u00ae, or SpiraPlan\u00ae application (hereafter referred to as SpiraPlan). You can run your tests straight away or later. When you are ready you can send your test executions back to SpiraPlan. This addin works with Microsoft Excel 2016+, Excel in the cloud (via a web browser), and Excel on iPad OS.
"},{"location":"Unit-Testing-Integration/Using-Test-Runner-For-Excel/#installation","title":"Installation","text":"To install the add-in:
Open the add-in from the ribbon and fill in the login form panel on the right of your Excel screen. If you are using Excel in the browser, make sure your SpiraPlan is accessible over the internet.
If there is a problem connecting to SpiraPlan you will be notified with an error message.
After you have logged in, click Logout to close your connection with SpiraPlan and take you back to the add-in's login page.
"},{"location":"Unit-Testing-Integration/Using-Test-Runner-For-Excel/#retrieving-tests-from-spiraplan","title":"Retrieving Tests from SpiraPlan","text":"After successfully logging in to the application, you need to get the most up to date list of Test Cases and/or Test Sets assigned to you from SpiraPlan. Select a product to retrieve all your assigned tests cases and sets from and click on 'Get from Spira'.
When you click the Get from Spira button you will see the Test Cases and their Test Steps be added the current sheet of the spreadsheet. The following tests are retrieved:
Resuming Testing
The add-in only communicates to SpiraPlan when you first get data from SpiraPlan and then at the end when you send the new data into SpiraPlan. You can therefore carry out your testing described below completely offline if you wish. You can also work on tests over multiple sessions.
When you return to the spreadsheet with your Test Cases after the first session you need to resume your testing. To do this you can use the spreadsheet without opening the add-in. You only need to login to the add-in when you want to send the Test Runs to SpiraPlan. That is what the \"Use Current Sheet button directly below the Get from Spira button is for.
"},{"location":"Unit-Testing-Integration/Using-Test-Runner-For-Excel/#running-tests","title":"Running Tests","text":"On retrieving your assigned tests from SpiraPlan the add-in populates the sheet with the information in a format to make it clear how to run your tests.
"},{"location":"Unit-Testing-Integration/Using-Test-Runner-For-Excel/#spreadsheet-structure","title":"Spreadsheet Structure","text":"The spreadsheet is generating using the following columns:
<b> for bold.The add-in uses different cell background colors to help you know what you can or should do in each cell:
Let's put the columns and the cell background colors together:
Column Test Case Rows Test Step Rows Send to Spira Log Gray (disabled) Gray (disabled) Test Case ID Gray (disabled) Gray (disabled) Test Set ID Gray (disabled) Gray (disabled) Test Step ID Gray (disabled) Gray (disabled) Test Case Name Gray (disabled) Gray (disabled) Release Green (populate) Gray (disabled) Set Case Unique ID Gray (disabled) Gray (disabled) Test Step Description Gray (disabled) White (optional) Test Step Expected Result Gray (disabled) White (optional) Test Step Sample Data Gray (disabled) White (optional) Execution Status Gray (disabled) Green (populate) Actual Result Gray (disabled) Green (populate) Incident Name Gray (disabled) White (optional)"},{"location":"Unit-Testing-Integration/Using-Test-Runner-For-Excel/#how-to-execute-tests","title":"How to Execute Tests","text":"To execute the Test Cases on the spreadsheet:
Let's say you have 5 Test Cases assigned to you but you plan to only execute 2 of them. How can you execute just these 2 and not the remaining 3? Delete all the rows for the 3 Test Cases you are not testing today. Make sure to delete the rows for the Test Case and all of each Test Case's Test Steps. If this is not done correctly you will not be able to log anything to SpiraPlan.
"},{"location":"Unit-Testing-Integration/Using-Test-Runner-For-Excel/#sending-test-runs-to-spiraplan","title":"Sending Test Runs to SpiraPlan","text":"Once you have finished executing all the tests and recorded the results of your test runs on the spreadsheet, it is time to send the data to Spira to get properly recorded. There are two ways of doing this, depending on how you executed your tests:
If you got your data from SpiraPlan using the add-in, and straight away executed your tests in a single seession, you can easily send the data back to SpiraPlan.
To do so click the button \"Send to Spira\" on the add-in and wait for the operation to complete.
"},{"location":"Unit-Testing-Integration/Using-Test-Runner-For-Excel/#multi-session-testing","title":"Multi Session Testing","text":"If you have first got your data from SpiraPlan and then executed your assigned tests over multiple sessions, you now need to send the data back to SpiraPlan, without wiping out your work. If you have been testing over multiple sessions in this way follow the steps below:
Once everything has been sent to SpiraPlan, results are recorded in the \"'Send to Spira' Log\" column of the spreadsheet. In this column you will see:
Below are common questions and answers related to common errors you may face when using the add-in.
1. After entering my SpiraPlan credentials and clicking 'Log in', I see the error message...
Error: Request has been terminated Possible causes: the network is offline, Origin is not allowed by Access-Control-Allow-Origin, the page is being unloaded, etc.
How to solve this issue: first, make sure your credentials are correct. You can re-generate your RSS / API Key by going to your user page in SpiraPlan. Always remember to click 'Save' after re-generating your RSS key. If the problem persists, ask your SpiraPlan administrator to check the SpiraPlan API CORS configuration (in SpiraPlan: Admin menu > System > Security Settings > Allowed Domains) to see if it is accepting connections from the add-in domain.
2. When importing data from a spreadsheet on my computer, I get error messages. How do I solve it?
Here is a list of possible error messages you may see when importing a spreadsheet into the add-in and how to solve them:
Error: The selected product does not match the Spreadsheet data.
Solution: You cannot run Tests from one product and record them in another product. In the add-in, select the same product of the saved spreadsheet and try again.
Error: Database sheet is missing.
Solution: Your spreadsheet is missing required data. You have to re-import (using the \"Get From Spira\" button) the data. Never delete/rename any worksheet from the spreadsheet.
Error: There are columns missing in the spreadsheet.
Solution: Your worksheet is missing required data. You have to re-import (using the \"Get From Spira\" button) the data. Never delete or rename any column from the worksheet.
Error: Invalid Test Case detected: missing Test Step(s).
Solution: Your worksheet is missing Test Case data. You have to re-import (using the \"Get From Spira\" button) the data. You can delete Test Cases from the worksheet, but make sure to not leave Test Sets with no Test Cases or Test Cases with no Test Steps.
3. After clicking on \"Send to Spira\", I see a red Test Case row and an error message saying...
Invalid Execution Statuses: This TestCase contains an invalid execution statuses combination.
How to solve this issue: only valid Test Runs can be recorded in SpiraPlan. A valid Test Run is one that meets the conditions below. Check to make sure your test case meets all of these. In particular, review any Test Steps that have an execution status of Not Run still.
4. After clicking on 'Send to Spira', I see a Test Step red row and an error message saying...
Missing Actual Result: This TestStep needs to have an Actual Result, since it failed.
How to solve this issue: all Test Steps that are run but not passed (steps marked as any of Failed, Blocked, Caution, or N/A) must have an Actual Result. Check your non-passed Test Steps and make sure they all have an actual result and try again.
5. After clicking on 'Get from Spira' or 'Send to Spira', nothing happens for a long time - the add-in is stuck
Make sure you are not editing any cell when clicking on any add-in button. Excel does not allow add-ins to modify the spreadsheet when in editing mode. To solve this, click on any blank cell or press the ESC key. If it still does not work, check your internet connection and try again.
"},{"location":"Version-Control-Integration/Integrating-with-CVS/","title":"Integrating with CVS","text":"The Concurrent Versions System (CVS) is a Software Configuration Management (SCM) system that enables users to work on code simultaneously while preserving previous versions by avoiding collisions in code edits. This plug-in will allow users of SpiraPlan or SpiraTeam (hereafter referred to as SpiraTeam) to be able to browse a CVS repository and view commits linked to SpiraTeam artifacts.
The plug-in will download a working-copy of the CVS repository onto the SpiraTeam server and use that for displaying the list of files/folders. The list of commits will be queries dynamically from the CVS repository on an as-needed basis. The rest of this section outlines how to install and use the plug-in with SpiraTeam.
Note: The plug-in will allow users to download and view different commits of files and view commit logs, but no changes to the repository are allowed through the plug-in.
"},{"location":"Version-Control-Integration/Integrating-with-CVS/#installing-the-cvs-plug-in","title":"Installing the CVS Plug-In","text":"To install the CVS Version Control plug-in, copy the following files from the plug-in zip-archive into the \"VersionControl\" sub-folder of the SpiraTeam installation: - CvsProvider.dll - DocsVision.Remoting.dll - ICSharpCode.SharpCvsLib.dll - ICSharpCode.SharpZipLib.dll - log4net.dll
"},{"location":"Version-Control-Integration/Integrating-with-CVS/#configuring-cvs-in-spiraplan","title":"Configuring CVS in SpiraPlan","text":"Before you can start using CVS in SpiraPlan you need to setup, at a system level, how CVS and SpiraPlan should work together:
Complete the form on this page as below:
sharpcvslib.cvs.sourceforge.net:/cvsroot/sharpcvslibCustom 01: This must contain the name of the connection protocol being used to access the CVS server. The following protocols are supported:
Custom 02: This must contain the name of the module you wish to access in the CVS repository.
When finished, click \"Insert\". You will be taken back to the Source Code list page, with CvsProvider listed as an available plug-in.
"},{"location":"Version-Control-Integration/Integrating-with-CVS/#use-cvs-for-your-product","title":"Use CVS for Your Product","text":"Once CVS has been configured at the system level, you are ready to use it for any products you need to.
Source code setup for your product is complete. Click on the \"Source Code\" or \"Commits\" menu items under the Developing tab to navigate and browse the source code repository.
You can read more about working with source code in SpiraPlan at the links below:
Since the integration with CVS requires that a working copy of the CVS repository be stored on the SpiraTeam server, you may decide at some point to unlink a disused CVS repository from SpiraTeam to save disk-space. However unlinking the repository through the SpiraTeam web interface will not remove the working copy of the repository from the server.
To permanently remove a repository from the SpiraTeam server, you need to locate the following path:
If you look inside this folder, you will see a subfolder called \"Inflectra\", and under that will be a subfolder called \"CvsProvider\". If you open up this subfolder, you will see a list of all the CVS modules that have been accessed through SpiraTeam. To purge a module, just select it and choose the Delete Folder option in Windows.
"},{"location":"Version-Control-Integration/Integrating-with-Git/","title":"Integrating with Git","text":""},{"location":"Version-Control-Integration/Integrating-with-Git/#introduction-to-git","title":"Introduction to Git","text":"Git is a Distributed Version Control System (DVCS) system that keeps track of software commits and allows many developers to work on a given project without necessarily being connected to a common network since it doesn't rely on a central repository. Instead Git distributes copies of relevant branches of the entire source code repository to each user's machine.
SpiraPlan's Git plug-in allows users of SpiraTeam or SpiraPlan (hereafter referred to as SpiraPlan) to browse a Git repository and view commits linked to SpiraPlan artifacts.
The plug-in will clone a read-only \"bare\" (i.e. no working folder) copy of the Git repository onto the SpiraPlan server. The plugin use that bare repository to parse data about the various branches, files, folders, and commits. The plug-in performs all necessary 'pull' requests from the remote repository to keep the local bare repository up to date. Note: the plugin does not make any changes to the repo at all.
The current version of the Git plugin is compatiblbe with SpiraPlan v4.2.0.2 or later.
"},{"location":"Version-Control-Integration/Integrating-with-Git/#installing-the-git-plug-in","title":"Installing the Git Plug-In","text":"Cloud hosted users and on-premise users on SpiraPlan 6+ can skip this section: all required files are included as part of the normal installation process.
To install the Git plug-in on your SpiraPlan service:
Copy the following files from the plug-in zip-archive into the \"VersionControl\" sub-folder of the SpiraPlan installation:
If your server operating system is 64-bit, copy \"git2.dll\" from the \"x64\" directory of the downloaded plug-in zip file into the \"VersionControl\" sub-folder of the SpiraPlan installation. Note: Do not create an x64 folder under VersionControl, make sure the file lives in the VersionControl folder itself.
Before you can start using Git in SpiraPlan you need to setup, at a system level, how Git and SpiraPlan should work together:
Complete the form on this page as below:
When finished, click \"Insert\". You will be taken back to the Source Code list page, with GitProvider listed as an available plug-in.
Github and Gitlab
When connecting to repositories on Github or Gitlab please use a Personal Access Token instead of your password in the password field. Your password may work for public repos, but you will always need to use the Personal Access Token for private repos.
Learn more about setting up these tokens for Github and Gitlab.
"},{"location":"Version-Control-Integration/Integrating-with-Git/#use-git-for-your-product","title":"Use Git for Your Product","text":"Once Git has been configured at the system level, you are ready to use it for any products you need to.
Source code setup for your product is complete. Click on the \"Source Code\" or \"Commits\" menu items under the Developing tab to navigate and browse the source code repository.
You can read more about working with source code in SpiraPlan at the links below:
Git integration needs a bare copy of the Git repository to be stored on the SpiraPlan server. If you decide to deactivate a SpiraPlan product from using a Git repository, the bare repository will still exist on the server.
To permanently remove a repository from the SpiraPlan server, you need to locate the following path: C:\\ProgramData\\Inflectra\\Spira\\GitProvider
In this folder, you will see a list of all the Git repositories that have been accessed through SpiraPlan. To purge a repository, select it and choose the Delete Folder option in Windows.
"},{"location":"Version-Control-Integration/Integrating-with-Mercurial/","title":"Integrating with Mercurial","text":"Mercurial is a Distributed Version Control System (DVCS) system that keeps track of software commits and allows many developers to work on a given project without necessarily being connected to a common network since it doesn't rely on a central repository, but instead distributes copies of the entire source code repository to each user's workstation.
The SpiraTeam plug-in for Mercurial allows users of SpiraPlan or SpiraTeam (hereafter referred to as SpiraTeam) to be able to browse a Mercurial repository and view commits linked to SpiraTeam artifacts.
The plug-in will download a read-only working-copy of the Mercurial repository onto the SpiraTeam server and use that for displaying the list of files/folders. The list of commits will be queried dynamically from this local repository on an as-needed basis. The plug-in also performs 'pull' requests from the specified remote repository to ensure that the local repository remains up to date.
The rest of this section outlines how to install and use the plug-in with SpiraTeam.
Note: The plug-in will allow users to download and view different commits of files and view commit logs, but no changes to the repository are allowed through the plug-in.
"},{"location":"Version-Control-Integration/Integrating-with-Mercurial/#installing-the-mercurial-plug-in-to-install-the-mercurial-version-control-plug-in-follow-these-steps","title":"Installing the Mercurial Plug-In To install the Mercurial Version Control plug-in, follow these steps:","text":"Copy the following files from the plug-in zip-archive into the \"VersionControl\" sub-folder of the SpiraTeam installation:
- MercurialProvider.dll\n- Mercurial.Net.dll\nBefore you can start using Mercurial in SpiraPlan you need to setup, at a system level, how Mercurial and SpiraPlan should work together:
Complete the form on this page as below:
<https://bitbucket.org/aragost/javahg> ssh://example.com/hg/When finished, click \"Insert\". You will be taken back to the Source Code list page, with MercurialProvider listed as an available plug-in.
"},{"location":"Version-Control-Integration/Integrating-with-Mercurial/#use-mercurial-for-your-product","title":"Use Mercurial for Your Product","text":"Once Mercurial has been configured at the system level, you are ready to use it for any products you need to.
Source code setup for your product is complete. Click on the \"Source Code\" or \"Commits\" menu items under the Developing tab to navigate and browse the source code repository.
You can read more about working with source code in SpiraPlan at the links below:
Since the integration with Mercurial requires that a working copy of the Mercurial repository be stored on the SpiraTeam server, you may decide at some point to unlink a disused Mercurial repository from SpiraTeam to save disk-space. However unlinking the repository through the SpiraTeam web interface will not remove the working copy of the repository from the server.
To permanently remove a repository from the SpiraTeam server, you need to locate the following path:
If you look inside this folder, you will see a subfolder called \"Inflectra\", and under that will be a subfolder called \"MercurialProvider\". If you open up this subfolder, you will see a list of all the Mercurial repositories that have been accessed through SpiraTeam. To purge a module, just select it and choose the Delete Folder option in Windows.
"},{"location":"Version-Control-Integration/Integrating-with-Perforce/","title":"Integrating with Perforce","text":""},{"location":"Version-Control-Integration/Integrating-with-Perforce/#installing-the-perforce-plug-in","title":"Installing the Perforce Plug-In","text":"To install the Perforce Version Control plug-in, copy the following files to the folder named \"VersionControl\" in the SpiraTeam installation folder:
- Inflectra.Global.dll\n- P4API.dll\n- P4DN.dll\n- PerforceProvider.dll\nBefore you can start using Perforce in SpiraPlan you need to setup, at a system level, how Perforce and SpiraPlan should work together:
Complete the form on this page as below:
When finished, click \"Insert\". You will be taken back to the Source Code list page, with PerforceProvider listed as an available plug-in.
"},{"location":"Version-Control-Integration/Integrating-with-Perforce/#use-perforce-for-your-product","title":"Use Perforce for Your Product","text":"Once Perforce has been configured at the system level, you are ready to use it for any products you need to.
Source code setup for your product is complete. Click on the \"Source Code\" or \"Commits\" menu items under the Developing tab to navigate and browse the source code repository.
You can read more about working with source code in SpiraPlan at the links below:
Subversion (also known as SVN) is a Software Configuration Management (SCM) system, that enables users to work on code simultaneously while preserving previous versions by avoiding collisions in code edits. While users working on the code will usually have a complete copy of the repository on their local systems, this plug-in will access the repository remotely by use of the \"svn://\" , \"http://\" and \"https://\" protocols. (Note that \"svn+ssh://\" may be supported on a server by server basis.)
Due to the methodologies in which IIS handles web requests and runs on the server, any SSH connection certificates that have trust issues will be automatically accepted. Therefore, we recommend using an IP address to connect to the server instead of a DNS name that could be redirected to an unsafe connection.
The current version of the Subversion plugin requires SpiraPlan or SpiraTeam v5.4.0.0 or later.
"},{"location":"Version-Control-Integration/Integrating-with-Subversion/#installing-the-subversion-plug-in","title":"Installing the Subversion Plug-In","text":"Cloud hosted users and on-premise users on SpiraPlan 6+ can skip this section: all required files are included as part of the normal installation process.
To install the Subversion Version Control plug-in, follow these steps:
Before you can start using Subversion in SpiraPlan you need to setup, at a system level, how Subversion and SpiraPlan should work together:
Complete the form on this page as below:
When finished, click the \"Insert\" button and you will be taken back to the Source Code list page, with SubversionProvider listed as an available plug-in.
"},{"location":"Version-Control-Integration/Integrating-with-Subversion/#use-subversion-for-your-product","title":"Use Subversion for Your Product","text":"Once Subversion has been configured at the system level, you are ready to use it for any products you need to.
Source code setup for your product is complete. Click on the \"Source Code\" or \"Commits\" menu items under the Developing tab to navigate and browse the source code repository.
You can read more about working with source code in SpiraPlan at the links below:
Microsoft Visual Studio Team System (VSTS) Team Foundation Server (TFS) from Microsoft\u00ae (hereafter referred to as TFS) is a Software Configuration Management (SCM) system that enables users to work on code simultaneously while preserving previous versions by avoiding collisions in code edits. This plug-in will allow users of SpiraPlan or SpiraTeam (hereafter referred to as SpiraTeam) to be able to browse a TFS repository and view commits linked to SpiraTeam artifacts. There are separate plug-ins for TFS 2005/2008, 2010 and 2012+. When connecting to a TFS 2010/2012+ repository, the connection URL will also need to be in a different format (see below).
While users working on the code will usually have a complete copy of the repository on their local systems, this plug-in will access the TFS repository remotely. The rest of this section outlines how to install and use the plug-in with SpiraTeam.
Note: The plug-in will allow users to download and view different commits of files and view commit logs, but no changes to the repository are allowed through the plug-in.
"},{"location":"Version-Control-Integration/Integrating-with-TFS/#installing-the-tfs-plug-in","title":"Installing the TFS Plug-In","text":"To install the TFS Version Control plug-in, follow these steps:
Copy the following files from the plug-in zip-archive into the \"VersionControl\" sub-folder of the SpiraTeam installation:
Before you can start using TFS in SpiraPlan you need to setup, at a system level, how TFS and SpiraPlan should work together:
Complete the form on this page as below:
Connection Info: This field points to the URL used for accessing the Team Foundation Server. Typically TFS runs on website port 8080, but you may need to check with your IT administrator to verify. The exact connection URL will depend on your version of TFS:
Login / Password: The user id and the password of the user to use while accessing and retrieving information from the TFS repository. If the repository doesn't require a username/password, just use \"anonymous\" as both the username and password.
When finished, click \"Insert\". You will be taken back to the Source Code list page, with TfsProvider listed as an available plug-in.
"},{"location":"Version-Control-Integration/Integrating-with-TFS/#use-tfs-for-your-product","title":"Use TFS for Your Product","text":"Once TFS has been configured at the system level, you are ready to use it for any products you need to.
Source code setup for your product is complete. Click on the \"Source Code\" or \"Commits\" menu items under the Developing tab to navigate and browse the source code repository.
You can read more about working with source code in SpiraPlan at the links below:
As described in Linking to artifacts in commit messages, you can easily associate check-ins of code in TFS with relevant SpiraTeam artifacts by adding the appropriate artifact identifier in the commit messages.
In order to enforce this process, one of our customers has written a custom Visual Studio 2008 and 2010/2012+ Team System check-in policy that will force users to enter at least one SpiraTeam artifact in each of the check-in comments. This policy will also check the IDs of the supplied artifacts to make sure they exist in the appropriate SpiraTeam installation.
To install the custom check-in policy, you should download the SpiraPolicySetup.msi (for 2008) or SpiraPolicy.vsix (for 2010+) installation package from the Add-Ons/Downloads section of the Inflectra website (http://www.inflectra.com/SpiraTeam/Downloads.aspx) and run the installation package on each workstation that has Visual Studio installed. Once this installation has been completed, you need to tell Visual Studio to add the custom check-in policy:
Click on the [Add...] button to add a new check-in policy:
Select the SpiraTeam/Plan TFS check-in Policy and click [OK]. This will bring up the SpiraTeam custom policy configuration dialog box:
Enter the URL for the SpiraTeam server (you only need the server name and virtual directory portion) as well as a valid login and password. Then click [Connect] to get the list of projects.
Tortoise is a family of Windows Explorer shell extensions that helps programmers manage different versions of the source code for their programs directly inside the standard Windows Explorer user interface.
There are different versions of Tortoise that are compatible with different version control systems.
"},{"location":"Version-Control-Integration/Integrating-with-Tortoise/#tortoisesvn","title":"TortoiseSVN","text":"TortoiseSVN is a Subversion client, implemented as a Microsoft Windows shell extension, that helps programmers manage different versions of the source code for their programs.
In Windows Explorer, besides showing context menu items for Subversion commands, TortoiseSVN provides icon overlay that indicates the status of Subversion working copies.
"},{"location":"Version-Control-Integration/Integrating-with-Tortoise/#tortoisegit","title":"TortoiseGit","text":"TortoiseGit is a Git commit control client, implemented as a Windows shell extension and based on TortoiseSVN.
In Windows Explorer, besides showing context menu items for Git commands, TortoiseGit provides icon overlays that indicate the status of Git working trees and files. It also comes with the TortoiseGitMerge utility to visually compare two files and resolve conflicts.
"},{"location":"Version-Control-Integration/Integrating-with-Tortoise/#tortoisecvs","title":"TortoiseCVS","text":"TortoiseCVS is a CVS client for Microsoft Windows. Unlike most CVS tools, it includes itself in Windows' shell by adding entries in the contextual menu of the file explorer, therefore it does not run in its own window. Moreover, it adds icons onto files and directories controlled by CVS, giving additional information to the user without having to run a full-scale stand-alone application.
"},{"location":"Version-Control-Integration/Integrating-with-Tortoise/#using-the-spira-plugin-for-tortoise","title":"Using the Spira Plugin for Tortoise","text":"The Spira issue-tracker plugin for Tortoise (called TurtleSpira) works with all variants of Tortoise, including TortoiseGit,TortoiseSVN, and TortoiseCVS, and lets you streamline your workflow for linking source code commits / commits to assigned artifacts in SpiraTeam, SpiraPlan, or SpiraTest.
The Tortoise plugin system lets you integrate different issue trackers. With such plugins it is possible to fetch information directly from the issue tracker, interact with the user and provide information back to Tortoise about open issues, verify log messages entered by the user and even run actions after a successful commit to e.g, close an issue.
"},{"location":"Version-Control-Integration/Integrating-with-Tortoise/#installing-the-turtlespira-plugin","title":"Installing the TurtleSpira Plugin","text":"You need to download the TurtleSpira windows installer package from the Inflectra website and run it on the same computer that already has Tortoise installed:
Once it has finished installing, you need to go to the Tortoise > Settings and bring up the Settings dialog box:
On the main Settings menu, click on the Hook Scripts > Issue Tracker Integration.
Click on the Add button to bring up the dialog box to configure the issue tracker integration:
You need to fill out the following fields in the dialog box:
Then Click on the Options button to bring up the Spira configuration dialog box:
You need to enter the URL, User Name, and Password to your Spira instance and click the Login button. Once it connects, then choose the appropriate Product from the dropdown list and then click Save.
You have now installed and configured the TurtleSpira plugin.
"},{"location":"Version-Control-Integration/Integrating-with-Tortoise/#committing-a-code-change-linked-to-spira-artifacts","title":"Committing a Code Change Linked to Spira Artifacts","text":"Now we want to commit a change we have made to some source code files and associate that change with artifacts in Spira that are assigned to me. For example, I might be fixing a bug, implementing a feature, or completing a task associated with a requirement.
When you choose the menu option in Tortoise to commit the change, it displays the following dialog box:
Click on the Choose Artifact button on the top-right of the dialog box:
This screen will list all of the Spira requirements, tasks, and incidents assigned to you. Simply select the checkboxes of the items you want to associate with this commit operation and click OK:
The plugin will automatically populate the list of requirements, tasks and incidents into the commit text. Now click the OK button to commit the change:
Check the box of any tasks that you want the plugin to automatically close for you in Spira. If the source code commit completed all the work on the task, you should check the box. If the commit was merely part of the task, you should leave it unchecked.
In addition, there is a checkbox which will tell the plugin to add the commit text as comments onto all the selected artifacts.
Once that has been done, you will see the following comments appear in Spira:
"},{"location":"Version-Control-Integration/Integrating-with-VSS/","title":"Integrating with VSS","text":"Visual SourceSafe\u00ae (VSS) from Microsoft\u00ae is a Software Configuration Management (SCM) system that enables users to work on code simultaneously while preserving previous versions by avoiding collisions in code edits. This plug-in will allow users of SpiraPlan or SpiraTeam (hereafter referred to as SpiraTeam) to be able to browse a VSS database and view commits linked to SpiraTeam artifacts.
While users working on the code will usually have a complete copy of the repository on their local systems, this plug-in will access the VSS database remotely.The rest of this section outlines how to install and use the plug-in with SpiraTeam.
Note: The plug-in will allow users to download and view different commits of files and view commit logs, but no changes to the repository are allowed through the plug-in.
"},{"location":"Version-Control-Integration/Integrating-with-VSS/#installing-the-vss-plug-in","title":"Installing the VSS Plug-In","text":"To install the VSS Version Control plug-in, follow these steps:
Copy the following files from the plug-in zip-archive into the \"VersionControl\" sub-folder of the SpiraTeam installation:
Before you can start using VSS in SpiraPlan you need to setup, at a system level, how VSS and SpiraPlan should work together:
Complete the form on this page as below:
C:\\VssDatabases\\Project1\\srcsafe.iniWhen finished, click \"Insert\". You will be taken back to the Source Code list page, with VssProvider listed as an available plug-in.
"},{"location":"Version-Control-Integration/Integrating-with-VSS/#use-vss-for-your-product","title":"Use VSS for Your Product","text":"Once VSS has been configured at the system level, you are ready to use it for any products you need to.
Source code setup for your product is complete. Click on the \"Source Code\" or \"Commits\" menu items under the Developing tab to navigate and browse the source code repository.
You can read more about working with source code in SpiraPlan at the links below:
Documentation version
This site was last updated for version 7.7.0.0 of SpiraTest, SpiraTeam, and SpiraPlan
Current available beta features
This documentation is for the entire Spira suite of products: SpiraTest, SpiraTeam, SpiraPlan, and all relevant addons and extensions.
Use the menu on the left to navigate to the different documentation pages. On each page the navigation on the right helps you move around the section of that specific page.
To search, use the text box at the top of the page. Already know the exact phrase you want to search for? Try putting the phrase in \"quotes\" to improve the results.
Please send comments and questions to:
Technical Publications Inflectra Corporation 8121 Georgia Ave, Suite 504 Silver Spring, MD 20910-4957 USA support@inflectra.com
"},{"location":"About/introduction-to-spira/","title":"Introduction to Spira","text":"The Spira\u2122 family of applications from Inflectra\u00ae are a powerful set of tools that help you manage your software lifecycle.
SpiraTest\u00ae is our powerful and easy to use requirements, test and defect management system, ideal for quality assurance teams.
SpiraTeam\u00ae is our integrated Application Lifecycle Management (ALM) system that manages your product's requirements, releases, test cases, issues and tasks in one unified environment.
SpiraPlan\u00ae expands on the features in SpiraTeam\u00ae to provide a complete Enterprise Agile Planning\u00ae solution that lets you manage risks, products, programs and the entire organization with ease.
"},{"location":"About/introduction-to-spira/#quality-assurance","title":"Quality Assurance","text":"Quality Assurance is a key component of the Software Development Life-Cycle (SDLC), which needs to be integrated into the planning and management of a program or product from its inception. Too often though, QA is implemented as Quality Control - whereby testing that the required functionality works as expected, is performed at the end, when it is most costly to make corrections and changes.
To manage QA across a product from day one, it is imperative that the original requirements are documented together with the use-cases that validate the desired functionality. These use-cases then form the basis of the test scripts that can be executed to validate that the functionality has been correctly built, and that the requirements have been satisfied. During the execution of these test scripts, failures may occur, which are recorded as incidents - either to be fixed or documented depending on the severity.
Typically, these activities require people to use at least three different types of software:
However, this stove-piped approach has many limitations and drawbacks, most importantly the fact that there is no traceability between the different artifacts. How can the product manager know that all the requirements have been tested? Conversely, how can the developer know which test script was responsible for a recorded bug -- needed to accurately reproduce the issue?
"},{"location":"About/introduction-to-spira/#product-management","title":"Product Management","text":"As described in the Agile Manifesto, traditional waterfall software methodologies and lifecycles have failed to deliver products on-time and on-budget. In addition, many systems built this way will fail to provide the expected business value as there is no ability to quickly refine the requirements as the product progresses.
Consequently, software development has been transformed with these new ideas and concepts, with new agile methodologies such as Scrum, and Kanban becoming common. However, the traditional tools of product management - requirements specifications, high level product plans, GANTT charts, white-board schedules and top-down task management - are too cumbersome and not well suited.
"},{"location":"About/legal-notices/","title":"Legal Notices","text":"This publication is provided as is without warranty of any kind, either express or implied, including, but not limited to, the implied warranties of merchantability, fitness for a particular purpose, or non-infringement.
This publication could include technical inaccuracies or typographical errors. Changes are periodically added to the information contained herein; these changes will be incorporated in new editions of the publication. Inflectra Corporation may make improvements and/or changes in the product(s) and/or program(s) and/or service(s) described in this publication at any time.
The sections in this guide that discuss internet web security are provided as suggestions and guidelines. Internet security is constantly evolving field, and our suggestions are no substitute for an up-to-date understanding of the vulnerabilities inherent in deploying internet or web applications, and Inflectra cannot be held liable for any losses due to breaches of security, compromise of data or other cyber-attacks that may result from following our recommendations.
The section of the manual that describes modifying the Windows System Registry (\"Registry\") should only be attempted by experienced Windows administrators who are familiar with its organization and contents. Inflectra\u00ae cannot be held liable for any losses due to damage to the system registry made by inexperienced personnel.
Spira\u2122, TaraVault\u00ae, SpiraPlan\u00ae, SpiraTeam\u00ae, SpiraTest\u00ae and Inflectra\u00ae are either trademarks or registered trademarks of Inflectra Corporation in the United States of America and other countries. Microsoft\u00ae, Windows\u00ae, Explorer\u00ae, Microsoft Project\u00ae and Visual SourceSafe\u00ae are registered trademarks of Microsoft Corporation. Subversion\u00ae is a registered trademark of Collabnet, Inc. iOS, iPod, iPad and iPhone are registered trademarks of Apple Corporation, Android\u00ae is a registered trademark of Google Corporation, and Kindle Fire\u00ae is a registered trademark of Amazon LLC. All other trademarks and product names are property of their respective holders.
"},{"location":"About/release-notes-addons-1/","title":"Release Notes for Spira Addons","text":"This page shows summary information about releases in Spira's addons, data syncs, integrations, and optional features.
"},{"location":"About/release-notes-addons-1/#may-2023","title":"May 2023","text":"Jira Cloud DataSync v5.4.2.0: this update includes a number of enhancements and bug fixes:
qTest: this update includes bug fixes and enhancements including:
ServiceNow DataSync v5.0.1.0: this update fixes bugs related to the new API standard introduced by the ServiceNow Tokyo 2022, expanding the compatibility of this dataSync plugin with the most recent SNOW version.
New features
New features
New features
New features
New features
New features
New features
New features
New features
New features
New features
Summary
Security and Performance improvements: enforced password expiration and restrictions, requirements management module now 400% faster
New artifact icons: more contemporary, visually striking, with a modular consistent design
New Features and FixesSummary
New Agile Task and Incident Boards
Program View of Releases & Incidents (SpiraPlan)
Graphing Enhancements and Custom Graphs
New featuresDocument Management
Program Management
Project Management
Reporting
Summary
Data-driven testing with test configurations
Exploratory testing: new testing mode to edit, move, and create test steps during exploratory testing sessions
Improved artifact details page: new designs, improved information flow, faster performance
New featuresSummary
Improved reporting: additional graphs and more dashboard layout choices
Planning board improvements
Testing improvements
New featuresSummary
Powerful new search
Improved program management tools
Seamless cross-product associations
New featuresSummary
Testing improvements: test case folders and test set folders
Electronic signature support
Workflows for releases
The app is 100% response across all sizes of device
New featuresWebhooks (inbound)
Navigation
Reporting
Other
Bug fixes and enhancements
Bug fix
Fix on-premise upgrades to installations that use SQL Authentication not completing successfully [IN:7076]
"},{"location":"About/release-notes-v6/#version-615-february-2022","title":"Version 6.15 (February 2022)","text":"Summary
Improves the welcome emails users receive on getting their brand new SpiraPlan user account. The emails are now more clear and easier to read.
Building on the overhaul we did to our rich text editor in 6.13, the editor is now more powerful and feature-packed than ever. The editor supports find and replace, has more formatting options for tables and images, and is more performant.
UI tweaks under the hood to improve the user experience, particularly for users with more limited product permissions.
New FeaturesRich text editor
tags) [IN:6887]\n
Testing
\nImprovements for those with limited permissions
\nOther
\nPatch Notes
\nSummary
\nView, edit, and add releases inline on the release mindmap, release Gantt chart, or task Gantt chart pages in a new popup View full details about each release without leaving the mindmap or Gantt chart, or edit and save changes right there. (SpiraTeam and SpiraPlan only)
\nView, edit, and add tasks inline on the task Gantt chart pages in a new popup View full details about each task without leaving the Gantt chart, or edit and save changes right there. (SpiraTeam and SpiraPlan only)
\nSupport for two new Single Sign On (SSO) providers: the popular OneLogin service and a generic OpenID provider. This makes it even easiser to integrate your external authentication system with Spira.
\nNew Features\nOAuth connectors are available for specific providers
\nProduct Release List Page Changes (SpiraTeam and SpiraPlan only)
\nProduct Task List Page Changes (SpiraTeam and SpiraPlan only)
\nOn-premise installer
\nFix text not wrapping when editing rich text fields of test steps on a test case details page (introduced in 6.13) [IN:6833]
\nFix the diagram tab for use case requirements with steps no longer rendering the diagram on the requirements details page (introduced in 6.13) [IN:6860]
\nFix details pages for artifacts that use workflows so that the comments settings in the workflow always control the comment box [IN:4917]
\nSummary
\nGive users increased flexibility when managing requirements with requirement types now always being user editable and controllable. Previously parent requirements (those with children) had a fixed type of \"Epic\" that users could never change. Now parent requirements can have any type at any time.
\nImprove the user experience and features of the built-in rich text editor. This lets users more easily add and view links, create checklists, highlight text, and strikethrough text
\nAdd support for more custom property types to let users customize even more how they use SpiraPlan. This release adds support for passwords (encrypted text), release, and automation host custom properties.
\nThe built-in diagram tools get even more powerful with additional shapes and option. You can now make diagrams that group individual shapes together to form kanban board diagrams and swim lane diagrams.
\nWe continue to round out our extensive API to let users automate more and more of their workflows in SpiraPlan. Each of our APIs (REST and SOAP) already had over 375 individual API calls. This release adds API calls to manage all template managed fields for specific artifacts.
\nImproved localization in the web application of fields that users are not able to customize (like requirement or test case statuses).
\nNew Features\nRequirements that have children (parent requirements) retain their type and are not forced to be \"Epics\" [RQ:3703]
\nAPIs
\nCustom Property Types
\nRich Text Editor
\nOther
\nSummary
\nNew installs come with improved sample data. On\u00a0first trying out SpiraPlan, users can select from a number of industry specific example products, programs, and portfolios to see how the tool can work for them.\u00a0
\nBug fixes and performance improvements
\nIndustry specific sample data installed with new installations
\nSummary
\nMulti-Factor Authentication (MFA) support for all users to improve security. Users can add a one-time password to Spira from within the application. Admins can enable/disable, monitor, and manage one-time passwords.
\nCreate and edit a wide array of diagrams live from within the application. This includes mindmaps, org charts, and general diagrams to meet all of your needs. Like all documents in the application, diagrams are versioned, have beautiful previews, can be downloaded, and can be controlled with robust workflows.
\nEdit requirements inline on the requirements mind-map page in a new popup. View full details about each requirement without leaving the mindmap, or edit and save changes right there. [IN:6570]
\nExcel365 addin support risks and test sets, and existing artifacts support even more fields. You can now update existing records using the tools. Advanced users can create new comments and test coverage and traceability links right from the spreadsheet.
\nNew Features\nFix the owner field not being set when owner data is sent on first creating a release (e.g. when cloning a release, or creating a release via the API) [IN:6619]
\nAPI
\nPatch Notes
\nSummary
\nPlanning Board enhancements (SpiraTeam and SpiraPlan): quality of life improvements, including: users can edit cards directly on the board in on-page popups (or view relevant information if you can't edit); improve tooltips, drag and drop; and more sensible defaults when creating items based on your view
\nWork faster and smarter with tasks (SpiraTeam and SpiraPlan): on the task list page you can now perform actions on a whole folders at once, not just specific tasks. This lets you quickly clone, export, or print tasks in folders.
\nNew Features\nPlanning Board
\nAPI
\nOther
\nSummary
\nImproved requirement document view (SpiraTeam and SpiraPlan): Users can now customize which fields to display; edit requirement names, descriptions, and other rich text fields; and display the requirement hierarchy position as an outline code (e.g. 1.2.11). Navigation and pagination have also been improved.
\nBaselining enhancements (SpiraTeam and SpiraPlan): There are now new views and existing views improved to make it easier to see what changed in a baseline.
\nAccess custom report data from external tools (SpiraPlan): First, we've added lots more reporting views to help build out even more queries (available in all editions of Spira). Next, SpiraPlan customers can use 3rd party tools like spreadsheets and database reporting packages to query and report against all custom report tables in the application via the ODATA standard (read our in-depth tutorial). This takes custom reports to a whole new level of integration and ease of use.
\nCustomize custom fields: Custom properties have been turned up to 100 (minus 1). You can now have 99 custom properties for each artifact in a template. Order your custom properties how you like, and add a useful tooltip description for users to read on details pages.
\nNOTE: Internet Explorer is no longer supported by SpiraTest, SpiraTeam, or SpiraPlan. You should use a modern and secure browser instead.
\nNew Features\nRequirements document view
\nCustom Properties
\nHistory and Baselining
\nReport Customization
\nOther
\nAdministration
\nEnhancements
\nBug fixes
\nSecurity fixes
\nSummary
\nBDD and Gherkin Support: Create and write BDD style requirements and test cases 100% in Spira using Gherkin syntax with automatic syntax highlighting. Managed through the documents repository, which includes workflow, checkout, and versioning support.
\nInline content editing: Write plain text, rich text, and markdown inside Spira and have all of the versioning and workflow capabilities at your disposal. Of course, you can link this content to your requirements, test cases, and other Spira artifacts.
\nNew Features\nTesting and test coverage
\nHome pages and reporting
\nAPI
\nOther
\nSummary
\nPull Requests (SpiraTeam and SpiraPlan): The Developing menu in the global navigation now includes Pull Requests, where you can create and manage pull requests. For each pull request you can see all of the relevant commits, their code changes, and discuss any code changes.
\nThe build details page has been overhauled to improve usability and bring the most important information to your fingertips. Key information is more clearly displayed at the top of the page and source code commits and artifact associations are more prominent.
\nSource code diff view (SpiraTeam and SpiraPlan): by default, source code files now collapse unchanged sections, making it easier to quickly review the changes in larger files. You can quickly toggle the page to view the entire file, if you need to.
\nRecording Product setting changes (SpiraTeam and SpiraPlan only): The application now automatically tracks when certain settings on a product change (turning baselining on and off, changing testing settings, or changing some planning options) and who made the change. This is our first step to better tracing admin level changes. Changes are shown on the product history page.
\nNew Features\nSource Code (SpiraTeam and SpiraPlan only)
\nEnhanced history tracking (SpiraTeam and SpiraPlan only)
\nSource Code / Development (SpiraTeam and SpiraPlan only)
\nOther
\nAPI
\nSummary
\nThis release focused on improving the experience and functionality for developers and development teams using SpiraTeam and SpiraPlan. On top of integrating with the top IDEs, your CI/CD processes, and unit test, this release brings massive improvements to our source code features.
\nWe have revamped the source code management module (SpiraTeam and SpiraPlan only), and for the first time, there is now a native code difference viewing capability in Spira. We have also improved views of branches, commits, files and given the source code system a huge performance boost. Note, source code is not included in SpiraTest.
\nView rendered markdown files directly in Spira with rich previews for documents and source code files. John Gruber's markdown format is an incredibly popular and easy way to write human readable plain text that renders as html with images, headings, lists, and more.
\nNew Features\nSource Code (SpiraTeam and SpiraPlan only)
\nOther
\nAPI
\nSummary
\nBaselining Enhancements (SpiraTeam and SpiraPlan only): with baselining enabled, you can now still revert recent changes in a product. Additionally, with baselining enabled, test coverage changes to requirements and releases are tracked and recorded. This release also includes a number of further bug fixes and enhancements.
\nNew features\nShow a warning about future deprecation (after March 31, 2021) on the login page if user is using Internet Explorer 11 [RQ:2987]
\nBaselining (SpiraTeam and SpiraPlan only)
\nSummary
\nPlanning Improvements (SpiraTeam and SpiraPlan only): Planning and kanban boards have some great new features like new display options and improved design. Set a product to estimate releases and requirements only with points (not hours). Use dynamic WIP limits on the planning board to help manage your kanban flow of requirements.
\nBaselines (SpiraTeam and SpiraPlan only): View all baselines created across all releases in a product, and drill down into a baseline to review every artifact that changed during that baselines period of activity.
\nPerformance Improvements: The most frequent power-hungry operations by users have been reworked from the ground up to maximize performance. Operations like updating test coverage is up to 300% faster.
\nNew features\nAdministering baselining within a product (SpiraTeam and SpiraPlan only)
\nProduct Planning (SpiraTeam and SpiraPlan only)
\nAgile and Planning (SpiraTeam and SpiraPlan only)
\nPerformance
\nTesting
\nOther
\nSummary
\nBaselining (SpiraTeam and SpiraPlan only): Enable baselining by product to add baselines to releases or sprints. Use baselines to create snapshots of the entire product at a specific point in time, for instance what it looked like at the start and then at the end of a sprint.
\nLearn: read our blog about this feature here, or read our documentation overview
\nTesting Settings: testing settings are now managed at the product, not system, level. Not only that but there are now lots more ways to tailor how testing behaves.
\nDevOps (SpiraTeam and SpiraPlan only): streamlined and improved traceability between source code commits, CI builds, DevOps pipelines, and SpiraPlan artifacts.
\nNew features\nUsers can create an Incident directly from a Task [RQ:2971]
\nCustom Reports
\nBaselining (SpiraTeam and SpiraPlan only)
\nSecurity Enhancements
\nImprove included sample templates
\nSource Code Management (SpiraTeam and SpiraPlan only)
\nTesting
\nHome pages
\nOther
\nSummary
\nImproved dashboard widgets: enhanced and new Recent Build widgets, let you get an easier handle on your CI/CD processes from program, portfolio, and enterprise home pages; a number of widgets on the program home page by default display data for active releases only to make their data more meaningful; a brand new product test summary table on the program home page provides important information at a glance.
\nNew features\nBaselining
\nEnterprise Dashboard (SpiraPlan only)
\nPorfolio Dashboard (SpiraPlan only)
\nProgram Dashboard
\nSample Data installed with new installations
\nBug fix
\nBug fix
\nSummary
\nPortfolio management (SpiraPlan only): Allow users to collect programs together into portfolios, which can then be collected into a single enterprise view. Key data (like percent complete) will flow from a product, all the way up to the enterprise view.
\nLearn: editing portfolios; letting users see portfolio and enterprise pages.
\nNew dashboard views to assess overall progress: Key data about percent complete for sprints, releases, products, programs, and portfolios will be displayed in a new widget on relevant dashboards. This will be based on the requirements that are part of each active sprint and release.
\nLearn: the portfolio dashboard; the enterprise dashboard.
\nNew release and task views to better manage workloads (SpiraTeam and SpiraPlan only): View all your relevant releases and tasks in new Gantt views. These let you see at a glance what is due when, and get an overview of the schedule of work and sprints.
\nLearn: release Gantt chart; release mind map; task Gantt chart.
\nNew features\nInstaller can upgrade successfully with required database additions [RQ:2850]
\nEnterprise Dashboard (SpiraPlan only)
\nPorfolio Dashboard (SpiraPlan only)
\nProgram Dashboard
\nProduct Dashboard
\nMy Page
\nRelease List Page Changes
\nProgram Release List Page (SpiraPlan only)
\nProduct Task List Page Changes
\nSample Data installed with new installations
\nCalculation Changes/Updates
\nPermissions to control access to portfolios and enterprise views (SpiraPlan only)
\nAdministration changes
\nBug fix
\nSummary
\nSingle Sign On (SSO) Support: Built in integration with a number of OAuth 2.0 providers to provide more seamless and secure sign-on to the application. Initial providers will include Azure AD, GitHub, GitLab, Google, Microsoft ADFS, and Okta.
\nImproved reporting: With a single release picker you can now update every graph (including custom graphs) on the main reporting page. Report formatting for Word has also been improved
\nNew features\nIntegration with OAuth2 Protocol
\nUsers will be able to register an account after signing into their OAuth account
\nAll OAuth providers will have their own library
\nSystem Administrators can managed Oauth providers and users connected using a provider
\nError States are managed
\nBusiness Code
\nOAuth connectors are available for specific providers
\nOther features
\nBug fixes and performance improvements
\nSummary
\nTaraVault unlimited for all SpiraTeam and SpiraPlan cloud users: To celebrate the start of a new decade, our cloud source code management solution, TaraVault, is now included at no extra charge, for all the users and repositories and branches you want.
\nImprovements to filters: Update your filters and shared filters easily. Create filters that also include information about which columns you have visible, their sort, order, and width. This is a great way for saving specific \u201cviews\u201d you and your teams need.
\nImproved navigation between folders and hierarchies: Each folder now has its own unique url, so you can share links to specific folders with your team. For requirements, releases, and all artifacts with folders new clickable breadcrumbs making it easy to go straight to an artifact\u2019s parent.
\nNew features\nSummary
\nSpiraTeam and SpiraPlan cloud users can use any source code provider: In addition to our source code provider, TaraVault, cloud customers can choose to use any Git or Subversion provider they wish.
\nBug fixes and UI improvements: The improvements include better access to the sidebars on all main pages, and improved search in dropdowns.
\nBug fixes and enhancements\nSummary
\nEnhanced product template management: Users can migrate a product from one template to another. This will help you consolidate your templates and streamline your administration more easily.
\nNew features\nBug fixes
\nTemporary fix to manage a bug introduced in the latest Chrome browser version
"},{"location":"About/release-notes-v6/#version-62-august-2019","title":"Version 6.2 (August 2019)","text":"Summary
\nAdditional Requirement List Views (SpiraTeam and SpiraPlan only): In addition to the current hierarchical list view of requirements, additional views will make it easier for users to work with requirements in ways that work for them at the time.
\nImproved Risk Associations (SpiraPlan only): Now you can add links between risks to and from other risks, as well as incidents, test cases, and requirements.
\nNew features\nBug fixes
\nSummary
\nDark Mode: The application follows the color scheme you use in your operating system, or you can set it manually. Dark mode makes every part of the application easier on the eyes and look more gorgeous than ever.
\nImprovements to Administration: With easier filtering and more intuitive controls for key pages like tables and managing workflow permissions, administration is now more user friendly than ever.
\nVersion 6 of our SOAP and REST APIs: Our existing APIs are as compatible as they can be with version 6 of SpiraPlan. The new API version will allow access to new features, such as those from templates.
\nNew features\nBug fixes
\nSummary
\nEnterprise Risk Management [SpiraPlan only]: Risks have their own types, statuses, workflows, and mitigations. New reports for risks, as well as charts and a risk cube have been added.
\nChanges to certain names in the system: Projects are now called Products; Project Groups are now Programs; and Iterations are now Sprints.
\nBetter manage your products (projects) with templates: Templates now control many aspects of a product (such as notifications, workflows, custom fields), and can control many products at once. Each existing product from 5.4 will have its own template. Every new product can have its own template or be managed by an existing template.
\nNew customizations at the template level: Requirement, Test Case, Document, and Task types are customizable. Documents can now be managed using workflows to allow you to control versioning and check-ins. Notifications now apply to products in a template and no longer the same system wide.
\nImprove navigation and new administration user interface: New login screens and a completely reworked navigation menu in the application make using SpiraPlan easier than ever. Navigation is more mobile friendly and intuitive. Administration menus are now only ever one click away.
\nNew features\nRisk Administration (Project Template)
\nRisks
\nProject Templates [RQ:1703]
\nSummary
As a developer I can use SOAP and REST APIs to manage system level custom properties and lists [RQ:4618]
As a program manager, I can plan out the necessary work of the program with **capabilities, linked to product requirements, and release management at the program level, so I can ensure the program objectives will be delivered**
As a program manager, I can monitor the progress of work in the program so I can analyze current performance and ensure the program is compliant with any reporting or audit standards
As a program manager, I can plan out the program delivery timetable with program milestones, so I can ensure we meet our program objectives on time
As a program manager, I want to monitor the progress of program milestones so I can analyze trends and ensure the program is compliant with any reporting or audit standards
As a new user, I can see relevant and meaningful sample data for program scaled agile, so I can easily understand how the tools works [RQ:4506]
Summary
This release includes a number of performance improvements and bug fixes to streamline user experience.
Bug fixes and enhancementsSummary
This release includes a number of performance improvements and bug fixes to streamline user experience.
Bug fixes and enhancementsPerformance improvements
Bug fixes
Summary
APIs
Cross-Cutting Functionality
Beta Planning Board
As a manager, I can use the new beta task board, so I can better oversee and track the work of my teams
Administration (SpiraPlan only)
Add an email option to never include the password in a new user confirmation email (when users are created by a system admin) [IN:7805]
APIs
Bug Fixes
Enhancements
Bug Fixes
Summary
Introducing our next generation planning board for SpiraTeam and SpiraPlan. Available as a beta alongside the existing planning board, the new board has a brand new look, big new features (including swimlanes), and simpler to use than ever.
SpiraPlan admins can create teams and assign members of a product to those teams (in beta). Currently teams are available exclusively on the beta planning board.
New FeaturesBeta Planning Board
There are useful main display modes that dictate how you use the boards
**The planning board makes it easy to customize how the board is organized to help you focus on the right information **
Planning board cards design updated with greater customization
Incident cards can be shown alongside requirement cards for certain views of the Planning Board
System Administration
Fix concurrency dates and concurrency checks to serialize using the Invariant Culture to avoid problems using certain cultural settings (for example, Thai) [IN:7499]
Logging in and out
On premise installer
Documentation and logging
Summary
Manage products in a whole new way (SpiraPlan only). New system level custom properties and custom lists let program users see and manage your products with custom data and through new dedicated pages and custom report options. You can use these new features for improved Project Portfolio Management, to implement product charts, and much more.
Along with existing support for creating and editing dynamic documents inside Spira (including diagrams and documents), the new spreadsheet editor lets you create simple spreadsheets to better organize your teams and track work. You can have multiple sheets, apply formatting to cells, use a wide number of functions, and even import from and export to Excel spreadsheets.
New FeaturesEmail all system administrators every time that the concurrent user limit is exceeded by a user trying to login but can't due to license issues [RQ:4361]
Improved Product Management and Customization
Summary
Cloud customers can now more easily and flexibly set up source code integration inside SpiraTeam and SpiraPlan. TaraVault is the default provider for Git or Subversion. Along with other quality of enhancements you can now, for each product, either user TaraVault or any other cloud based source code provider. This lets you pick the best provider for each product.
Our latest SpiraApp integrates SpiraPlan and OctoPerf seamlessly. Kick off load testing in OctoPerf directly from SpiraPlan and the results of the test get logged against each relevant test case.
New FeaturesSummary
SpiraApps bring a brand new of tailoring SpiraTest, SpiraTeam, and SpiraPlan to your needs. Dedicated SpiraApps will extend what is possible, each addressing a specific use case. This release introduces the first 7 SpiraApps and expect more to follow:
We have updated our data synchronization platform to improve ease of use and simplify setup for administrators, with tailored guidance and information right inside the app.
New FeaturesData synchronization
Testing
SpiraApps
SpiraApps Administration
SpiraApps Architecture
About
This roadmap outlines the functionality planned for future releases of the Spira platform (including SpiraTest, SpiraTeam, and SpiraPlan). Where not specified, a feature will be available in all Spira editions.
It is not set in stone. We are always listening to feedback from our customers and new ideas that will have the most impact to users.
It is not reflect all the work and changes we have planned. The roadmap focuses on large scale features. It does not include small scale features, enhancements, or bug fixes. We do not provide a public list of open bugs or enhancement requests at this time.
If you have any feedback or suggestions regarding this roadmap, please email us at support@inflectra.com.
"},{"location":"About/roadmap/#what-has-been-released","title":"What has been released","text":"Please take a look at our release notes to see a complete list of the changes (large and small) that we have recently delivered.
"},{"location":"About/roadmap/#q3-2023","title":"Q3 2023","text":"We will complete the new planning board rollout, and finish the first round of features for program level \"Scaled Agile\"
We will extend our \"Scaled Agile\" approach further with portfolio level features, like \"Portfolio Outcomes\" and \"Portfolio Milestones\", and deeper risk integration
"},{"location":"About/roadmap/#longer-term-thematic-ideas","title":"Longer term thematic ideas","text":"The list below are features that we are focused on delivering but not in the above timeline. We look for ways to deliver each (all or in part) with smaller enhancements in the short-term, or to integrate them into our timeline based on user feedback.
This section outlines how to use SpiraTest, SpiraPlan or SpiraTeam (hereafter referred to as SpiraTeam) in conjunction with the Atlassian's Bamboo continuous integration build servers. It assumes that you already have a working installation of SpiraTest, SpiraPlan or SpiraTeam v4.0 or later and a working installation of Bamboo v 5.0 or later. If you have an earlier version of SpiraTeam, you will need to upgrade to at least v4.0.
"},{"location":"Build-Server-Integration/Atlassian-Bamboo/#overview","title":"Overview","text":"Bamboo provides continuous integration services for software development, in any programming language using any build tool. It is a server-based system running that supports a variety of different version control systems. It supports SCM tools including CVS, Subversion, and Git, and can execute Apache Ant and Apache Maven based projects as well as arbitrary shell scripts and Tomcat.
When you use the SpiraTeam Add-on for Bamboo, it will allow you to associate each Bamboo project and plan with a corresponding project/release in SpiraTeam. Then, each time Bamboo creates a new build, a new build artifact will be created in SpiraTeam. Each build in SpiraTeam will be automatically linked to the incidents fixed, tasks implemented, requirements developed and source code commits committed.
"},{"location":"Build-Server-Integration/Atlassian-Bamboo/#installing-the-spirateam-add-on-for-bamboo","title":"Installing the SpiraTeam Add-on for Bamboo","text":"Go to the Inflectra website and open up the page that lists the various downloads available for SpiraTeam (http://www.inflectra.com/SpiraTeam/Downloads.aspx). Listed on this page will be the SpiraTeam Add-on for Bamboo. Right-click on this link and save the .zip file to your local computer.
Inside this .zip file will be a .jar file, extract the .jar file and save to a local folder on your system. After that, go to Bamboo Administration. You will need Bamboo administrator privileges to access this configuration page. Under Add-ons, click on the Manage Add-ons link and then on Upload Add-on on the left:
After that, click on Browse and select the .jar file extracted from the .zip archive downloaded from the Inflectra website. Then, click on Update.
After the installation of the SpiraTeam Add-on, you should see a welcome screen:
"},{"location":"Build-Server-Integration/Atlassian-Bamboo/#you-will-then-be-able-to-see-the-spirateam-add-on-in-the-user-installed-add-ons-list","title":"You will then be able to see the SpiraTeam Add-on in the User Installed Add-ons list :","text":""},{"location":"Build-Server-Integration/Atlassian-Bamboo/#_1","title":"Atlassian Bamboo","text":""},{"location":"Build-Server-Integration/Atlassian-Bamboo/#setting-up-the-spirateam-bamboo-add-on","title":"Setting-Up the SpiraTeam Bamboo Add-on","text":"Now that the add-on has been installed, you need to configure the settings for integration with SpiraTeam. To do this, go to the Project you want to communicate with SpiraTeam, and under the plan you want to receive notifications, click on Edit ( icon). In the Plan Configuration screen, go to the Notifications tab and click on Add Notification:
In the Add a new notification pop-up, select the appropriate event you want to receive notifications, and in the Recipient type box, select SpiraTeam:
After that, you will see some new fields to fill, they are:
URL - It is the URL you use to access your instance of SpiraTeam;
User Name: Your SpiraTeam user name;
Password: Your SpiraTeam password;
Project ID -- The numeric ID of the SpiraTeam Project that the Build belongs to. (e.g. for Project PR00001 just enter 1)
Release Version Number -- The version number of the SpiraTeam Release/Iteration that the Build belongs to. (e.g. for Release RL0004 with version number 1.0.0.0 you'd enter just 1.0.0.0)
After filling this boxes with appropriate information, click on Add button. Bamboo will then try to connect to the SpiraTeam Server, and check the Project/Release provided info. Once it validates your information, the connection settings will be saved. In case of error, follow the instructions on-screen and try again.
"},{"location":"Build-Server-Integration/Atlassian-Bamboo/#viewing-the-build-results-in-spirateam","title":"Viewing the Build Results in SpiraTeam","text":"Now that you have associated your Bamboo Project and Plan with a specific SpiraTeam project and release/iteration, you can use Bamboo to manage your software builds and have the results of the build be reported back into SpiraTeam. For example when the 'Plan1' build of TestProject 1 illustrated in the figure bellow is executed, it will report in Bamboo:
The corresponding build entry will also be created in SpiraTeam under the specified project and release/iteration:
If you have configured your Project Home to include the list of recent builds, the build information will also be displayed on the Project Home dashboard:
Clicking on either of the hyperlinks will allow you to navigate to the Build details page inside SpiraTeam:
This page will display the status (success / failure) and details of the build (imported from the Bamboo Console Output) together with a list of the associated incidents, test runs and source code commits. The following section will explain how to use your Source Code Management (SCM) system to take advantage of the SpiraTeam add-on and automatically link incidents and source code commits to the build information.
"},{"location":"Build-Server-Integration/Atlassian-Bamboo/#working-with-source-code-changesets","title":"Working with Source Code Changesets","text":"When your developers commit changes to your application's source into the SCM repository, they should make sure to link the commit to the appropriate artifacts in SpiraTeam. For example they may want to record that the commit fixes a specific incident or implements a specific feature (requirement).
Linking an artifact is very simple. All the developer needs to do is enter the artifact token in the following format:
[PREFIX:ID]
The first half, the Artifact Identifier, is a two-letter code that is used throughout SpiraTeam, and is visible on almost every page in the application. For example, a requirement's identifier is \"RQ\". Incidents are \"IN\", and tasks are \"TK\". The artifact ID is the number of the artifact. So by creating a commit message that reads:
SpiraTeam will automatically detect the tokens and will include links to them under the Associations tab for each commit detail in SpiraTeam.
Inside SpiraTeam, the system will use the same information to automatically link the list of associated commits to the build record:
If the commit message contains Incident tokens, the add-on will also automatically link those incidents to the appropriate build:
Similarly when you view the list of incidents inside SpiraTeam you will now be able to sort and filter the list by the associated build:
Congratulations! You are now able to use SpiraTeam and Bamboo to be able to manage your builds and have the build status integrated into your SpiraTeam project dashboard.
"},{"location":"Build-Server-Integration/Atlassian-Bamboo/#scheduling-test-sets-upon-successful-builds","title":"Scheduling Test Sets Upon Successful Builds","text":"One additional feature of the integration with SpiraTest and SpiraTeam (hereafter just SpiraTest) is the ability to have SpiraTest automatically schedule the execution of a test set whenever a build passes.
To do that, make sure the Test Set is associated with the SpiraTest release or iteration that is being built and then set the Schedule on Build field to \"Yes\" and optionally enter in the delay (after the build succeeds) that you want the test set to be scheduled for:
This means that you don't need to separately manage your build schedule in Bamboo and your test automation schedule in SpiraTest.
"},{"location":"Build-Server-Integration/CircleCI-Pipelines/","title":"CircleCI Pipelines","text":""},{"location":"Build-Server-Integration/CircleCI-Pipelines/#introduction","title":"Introduction","text":"SpiraTest, SpiraTeam, and SpiraPlan (from here on called SpiraPlan) integrated seamlessly with CircleCI in a number of ways. In this section we discuss SpiraPlan's CircleCI Pipelines reporting integration.
You can easily configure your CircleCI Pipelines to report against a release and create a new build in SpiraPlan each time they run. This let's you see the health of your CI/CD process within SpiraPlan.
CircleCI SpiraApp
You can also let end users start CircleCI Pipelines from within SpiraPlan itself. To do so you will need to enable and configure the CircleCI SpiraApp
The integration has two parts, which are discussed below:
Summary
{{base url}}/Services/Webhooks/BuildService.svc/CircleCI?username={{username}}&api-key={{api key}}The integration with CircleCI Pipelines works by having a dedicated custom field for CircleCI. This lets you link a release or sprint to a specific branch in a CircleCI repo. In SpiraPlan we need to specify the branch name. Then from CircleCI we configure our specific repo to talk to the correct SpiraPlan product.
The first step in SpiraPlan is to create a release custom property:
Next, we have to add the CircleCI project name into the SpiraPlan product description, so that the two are linked together.
Finally, in your SpiraPlan product itself (not administration):
In CircleCI we now need to setup our repo to talk to the SpiraPlan each time a Pipeline builds. To do this, you need to add a dedicated webhook. This means that when the CircleCI Pipeline(s) completes, CircleCI will send the results to SpiraPlan via that webhook. SpiraPlan processes that data and adds it as a build to the correct release, in the correct product.
The webhook URL
The webhook URL is made of different parts.
https://mysite.spiraservice.net. This is the start of every URL you use when using SpiraPlan/Services/Webhooks/BuildService.svc/CircleCI?username={{username}}&api-key={{api key}}The final URL will look like this: https://mysite.spiraservice.net/Services/Webhooks/BuildService.svc/CircleCI?username=circleci-pipelines&api-key={11111111-1111-1111-1111-111111111111}
When an Action on the CircleCI project next runs (either from CircleCI, or with the CircleCI SpiraApp) it will report its results to SpiraPlan. SpiraPlan finds the first product that has the project name in its description. SpiraPlan then looks the first release in that product that has the repo branch in the correct custom property that the CircleCI Pipeline was run against.
SpiraPlan creates a build against that release, with the key information, including the build status.
You can click on the build name/link to open its build details page. The build will also appear on any relevant widgets in SpiraPlan.
"},{"location":"Build-Server-Integration/GitHub-Actions/","title":"GitHub Actions","text":""},{"location":"Build-Server-Integration/GitHub-Actions/#introduction","title":"Introduction","text":"SpiraTest, SpiraTeam, and SpiraPlan (from here on called SpiraPlan) integrated seamlessly with GitHub in a number of ways. In this section we discuss SpiraPlan's GitHub Actions reporting integration.
You can easily configure your GitHub Actions to report against a release and create a new build in SpiraPlan each time they run. This let's you see the health of your CI/CD process within SpiraPlan.
GitHub SpiraApp
You can also let end users start GitHub Actions from within SpiraPlan itself. To do so you will need to enable and configure the GitHub SpiraApp
The integration has two parts, which are discussed below:
Summary
{{base url}}/Services/Webhooks/BuildService.svc/GitHub?username={{username}}&api-key={{api key}}The integration with GitHub actions works by having a dedicated custom field for GitHub. This lets you link a release or sprint to a specific branch in a GitHub repo. In SpiraPlan we need to specify the branch name only. Then from GitHub we configure our specific repo to talk to the correct SpiraPlan product.
The first step in SpiraPlan is to create a release custom property:
Next, in your SpiraPlan product:
In GitHub we now need to setup our repo to talk to the correct SpiraPlan product. Your GitHub repo/project will need to use Actions for the integration to work. You can add or edit Actions at any time - this will not impact the integration.
First, we have to add information to link up the GitHub repo and SpiraPlan, by adding the SpiraPlan product reference into the repo. To do this:
[PR:{{product id}}]. For example, \"[PR:1]\". You can have other text in the description, as long as the token is in there somewhere.Second, you need to add a dedicated webhook. This means that when the GitHub Action(s) completes, GitHub will send the results, along with the project description (and that SpiraPlan product token) to SpiraPlan via that webhook. SpiraPlan processes that data and adds it as a build.
The webhook URL
The webhook URL is made of different parts.
https://mysite.spiraservice.net. This is the start of every URL you use when using SpiraPlan/Services/Webhooks/BuildService.svc/GitHub?username={{username}}&api-key={{api key}}The final URL will look like this: https://mysite.spiraservice.net/Services/Webhooks/BuildService.svc/GitHub?username=github-actions&api-key={11111111-1111-1111-1111-111111111111}
When an Action on the GitHub project next runs (either from GitHub, or with the GitHub SpiraApp) it will report its results to SpiraPlan. SpiraPlan reads the product token to know what product the Action is for. SpiraPlan then looks the first release in that product that has the repo branch in the correct custom property that the GitHub Action was run against.
SpiraPlan creates a build against that release, with the key information, including the build status.
You can click on the build name/link to open its build details page. The build will also appear on any relevant widgets in SpiraPlan.
"},{"location":"Build-Server-Integration/GitLab-Pipelines/","title":"GitLab Pipelines","text":""},{"location":"Build-Server-Integration/GitLab-Pipelines/#introduction","title":"Introduction","text":"SpiraTest, SpiraTeam, and SpiraPlan (from here on called SpiraPlan) integrated seamlessly with GitLab in a number of ways. In this section we discuss SpiraPlan's GitLab Pipelines reporting integration.
You can easily configure your GitLab Pipelines to report against a release and create a new build in SpiraPlan each time they run. This let's you see the health of your CI/CD process within SpiraPlan.
GitLab SpiraApp
You can also let end users start GitLab Pipelines from within SpiraPlan itself. To do so you will need to enable and configure the GitLab SpiraApp
The integration has two parts, which are discussed below:
Summary
{{base url}}/Services/Webhooks/BuildService.svc/GitLab?username={{username}}&api-key={{api key}}The integration with GitLab Pipelines works by having a dedicated custom field for GitLab. This lets you link a release or sprint to a specific branch in a GitLab repo. In SpiraPlan we need to specify the branch name only. Then from GitLab we configure our specific repo to talk to the correct SpiraPlan product.
The first step in SpiraPlan is to create a release custom property:
Next, in your SpiraPlan product:
In GitLab we now need to setup our repo to talk to the correct SpiraPlan product. Your GitLab repo/project will need to use Pipelines for the integration to work. You can add or edit Actions at any time - this will not impact the integration.
First, we have to add information to link up the GitLab repo and SpiraPlan, by adding the SpiraPlan product reference into the repo. To do this:
[PR:{{product id}}]. For example, \"[PR:1]\". You can have other text in the description, as long as the token is in there somewhere.Second, you need to add a dedicated webhook. This means that when the GitLab Pipeline(s) completes, GitLab will send the results, along with the project description (and that SpiraPlan product token) to SpiraPlan via that webhook. SpiraPlan processes that data and adds it as a build.
The webhook URL
The webhook URL is made of different parts.
https://mysite.spiraservice.net. This is the start of every URL you use when using SpiraPlan/Services/Webhooks/BuildService.svc/GitLab?username={{username}}&api-key={{api key}}The final URL will look like this: https://mysite.spiraservice.net/Services/Webhooks/BuildService.svc/GitLab?username=gitlab-pipelines&api-key={11111111-1111-1111-1111-111111111111}
When an Action on the GitLab project next runs (either from GitLab, or with the GitLab SpiraApp)it will report its results to SpiraPlan. SpiraPlan reads the product token to know what product the Action is for. SpiraPlan then looks the first release in that product that has the repo branch in the correct custom property that the GitLab Pipeline was run against.
SpiraPlan creates a build against that release, with the key information, including the build status.
You can click on the build name/link to open its build details page. The build will also appear on any relevant widgets in SpiraPlan.
"},{"location":"Build-Server-Integration/Jenkins--Hudson/","title":"Jenkins / Hudson","text":"This section outlines how to use SpiraTest, SpiraTeam or SpiraPlan (hereafter referred to as SpiraPlan in conjunction with either the Jenkins or Hudson (hereafter referred to as Jenkins) continuous integration build servers. It assumes that you already have a working installation of SpiraTest, SpiraTeam or SpiraPlan v3.2 or later and a working installation of Jenkins/Hudson v2.7.3 or later. If you have an earlier version of SpiraPlan, you will need to upgrade to at least v3.2, and if you have any earlier version of Jenkins you will also need to upgrade it too.
Note: this integration is only available for Jenkins Freestyle Project items
"},{"location":"Build-Server-Integration/Jenkins--Hudson/#overview","title":"Overview","text":"Jenkins provides continuous integration services for software development, primarily in the Java programming language. It is a server-based system running in a servlet container such as Apache Tomcat. It supports SCM tools including CVS, Subversion, Git, Mercurial, Perforce and Clearcase, and can execute Apache Ant and Apache Maven based projects as well as arbitrary shell scripts and Windows batch commands.
When you use the SpiraPlan plugin for Jenkins, it will allow you to associate each Jenkins project with a corresponding project and release in SpiraPlan. Then, each time Jenkins creates a new build, a new build artifact will be created in SpiraPlan. Each build in SpiraPlan will be automatically linked to the incidents fixed, source code commits committed, and any SpiraPlan tokens in the Jenkins changelog will be parsed and turned into SpiraPlan artifact hyperlinks.
"},{"location":"Build-Server-Integration/Jenkins--Hudson/#installing-the-spiraplan-plug-in-for-jenkins","title":"Installing the SpiraPlan Plug-in for Jenkins","text":"The plug-in for SpiraPlan is available through the Jenkins Plugin Manager under the Available tab. Use the filter on the right of the screen to narrow down the plugins listed by typing spira. Check off Spira Importer and use the install that is best for your environment.
The Installing Plugins screen will show you the progress of the install.
After Jenkins has restarted, connect to your Jenkins server.
"},{"location":"Build-Server-Integration/Jenkins--Hudson/#setting-up-the-spiraplan-jenkins-plug-in","title":"Setting-Up the SpiraPlan Jenkins Plug-in","text":"Now that the plugin has been installed, you need to go back to the Jenkins homepage and click on the \"Manage Jenkins\" hyperlink followed by the \"Configure System\" hyperlink. This will bring up the main Jenkins configuration page. Scroll down to find the \"Spira Integeration\" section:
Enter in the URL you use to access your instance of SpiraPlan, together with a valid username and RSS key. You can find or generate the RSS Key from your user profile page inside Spira - read how to do so here. Make sure to include the curly braces - {ExampleRSS} - Once you have entered the values, click on the [Test Connection] button to verify that Jenkins can connect to SpiraPlan successfully. Once it has connected successfully, click the [Save] button at the bottom of the screen to save your connection settings.
"},{"location":"Build-Server-Integration/Jenkins--Hudson/#configuring-a-jenkins-job","title":"Configuring a Jenkins Job","text":"Now that you have setup the global SpiraPlan settings in Jenkins, next you need make a new item in Jenkins to associate each of your Jenkins Jobs with their corresponding SpiraPlan Product and Release/Sprint. To do this, go to the Jenkins Home Page and click in the upper left on New Item.
In the new Item page enter a meaningful name for the job and select Freestyle project. At the bottom left of the page click the OK button.
Scroll down in the Build Triggers page to the Build Environment Section. Under the section \"Build Environment\" select the checkbox marked \"Enable Spira Integration\". That will display the SpiraPlan configuration panel for this job:
Now you need to enter the following values:
Product ID -- The numeric ID of the SpiraPlan Product that the Build belongs to. (e.g. for Product PR1 enter \"1\")
Release Version Number -- The active version number of the SpiraPlan Release/Sprint that the Build belongs to. (e.g. for Release RL4 with version number 1.0.0.0 you'd enter \"1.0.0.0\")
Once you have entered in the Product ID and Release version number, click the [Verify Release] button and the plugin will connect to SpiraPlan and verify that the product exists, that the release/sprint is currently active, that the specified release/sprint exists in the product, and that the current user can connect to that product.
Once it has verified successfully, click the [Save] button at the bottom of the screen to save your Job configuration settings. You are now ready to use Jenkins with SpiraPlan.
"},{"location":"Build-Server-Integration/Jenkins--Hudson/#viewing-the-build-results-in-spiraplan","title":"Viewing the Build Results in SpiraPlan","text":"Now that you have associated your Jenkins job with a specific SpiraPlan product and active release/sprint, you can now use Jenkins to manage your software builds and have the results of the build be reported back into SpiraPlan. For example when the 'Build JUnit' job illustrated in the previous section is executed, it will report back the following result in Jenkins:
The corresponding build entry will also be created in SpiraPlan under the specified product and release/sprint:
If you have configured your Product Home to include the list of recent builds, the build information will also be displayed on the Project Home dashboard:
Clicking on either of the hyperlinks will allow you to navigate to the Build details page inside SpiraPlan:
This page will display the status (success / failure) and details of the build (from the Jenkins Console Output) together with a list of the associated incidents, test runs and source code commits. The following section will explain how to use your Source Code Management (SCM) system to take advantage of the Spira Importer plugin and automatically link incidents and source code commits to the build information.
"},{"location":"Build-Server-Integration/Jenkins--Hudson/#working-with-source-code-changesets","title":"Working with Source Code Changesets","text":"When your developers commit changes to your application's source into the SCM repository, they should make sure to link the commit to the appropriate artifacts in SpiraPlan. For example they may want to record that the commit fixes a specific incident or implements a specific feature (requirement).
Linking an artifact is very simple. All the developer needs to do is enter the artifact token in the following format:
[PREFIX:ID]
The first half, the Artifact Identifier, is a two-letter code that is used throughout SpiraPlan, and is visible on almost every page in the application. For example, a requirement's identifier is \"RQ\". Incidents are \"IN\", and tasks are \"TK\". The artifact ID is the number of the artifact. So by creating a commit message that reads:
SpiraPlan will automatically detect the tokens and will include links to them under the Associations tab for each commit detail in SpiraPlan.
In addition, when Jenkins creates the next build (that includes this commit), the plugin will automatically parse the commit message and convert the tokens into hyperlinks to the corresponding SpiraPlan artifact. That way, when developers view the build changelog in Jenkins, it will automatically include links to the SpiraPlan items:
Meanwhile, inside SpiraPlan, the system will use the same information to automatically link the list of associated commits to the build record:
If the commit message contains Incident tokens, the plugin will also automatically link those incidents to the appropriate build:
Similarly when you view the list of incidents inside SpiraPlan you will now be able to sort and filter the list by the associated build:
Congratulations! You are now able to use SpiraPlan and Jenkins to be able to manage your builds and have the build status integrated into your SpiraPlan project dashboard.
"},{"location":"Build-Server-Integration/Jenkins--Hudson/#scheduling-test-sets-upon-successful-builds","title":"Scheduling Test Sets Upon Successful Builds","text":"One additional feature of the integration with SpiraTest, SpiaTeam, and SpiraPlan (hereafter just SpiraPlan) is the ability to have SpiraPlan automatically schedule the execution of a test set whenever a build passes.
To do that, make sure the Test Set is associated with the SpiraPlan release or sprint that is being built and then set the Schedule on Build field to \"Yes\" and optionally enter in the delay (after the build succeeds) that you want the test set to be scheduled for:
This means that you don't need to separately manage your build schedule in Jenkins and your test automation schedule in SpiraTest.
"},{"location":"Build-Server-Integration/JetBrains-TeamCity/","title":"JetBrains TeamCity","text":"This section outlines how to use SpiraTest, SpiraPlan or SpiraTeam (hereafter referred to as SpiraTeam) in conjunction with the JetBrains' TeamCity continuous integration build servers. It assumes that you already have a working installation of SpiraTest, SpiraPlan or SpiraTeam v6.0 or later and a working installation of TeamCity v9.0.4 or later. If you have an earlier version of SpiraTeam, you will need to upgrade to at least v6.0.
"},{"location":"Build-Server-Integration/JetBrains-TeamCity/#overview","title":"Overview","text":"TeamCity provides continuous integration services for software development, primarily in the Java programming language. It is a server-based system running that supports a variety of different version control systems and build runners. It supports SCM tools including CVS, Subversion, Git, Mercurial, Perforce and Borland StarTeam, and can execute Apache Ant and Apache Maven based projects as well as arbitrary shell scripts and Windows batch commands.
When you use the SpiraTeam Plug-In for TeamCity, it will allow you to associate each TeamCity project with a corresponding project and release in SpiraTeam. Then, each time TeamCity creates a new build, a new build artifact will be created in SpiraTeam. Each build in SpiraTeam will be automatically linked to the incidents fixed, tasks implemented, requirements developed and source code commits committed.
"},{"location":"Build-Server-Integration/JetBrains-TeamCity/#installing-the-spirateam-plug-in-for-teamcity","title":"Installing the SpiraTeam Plug-in for TeamCity","text":"Go to the Inflectra website and open up the page that lists the various downloads available for SpiraTeam (http://www.inflectra.com/SpiraTeam/Downloads.aspx). Listed on this page will be the SpiraTeam Plug-In for TeamCity. Right-click on this link and save the Zip compressed folder to the TeamCity's Plug-In directory ($TEAMCITY_USER_HOME/plugins). After that, restart TeamCity for the plugin to take effect. It's also possible to install the Plug-In through the user interface of TeamCity via Administration > Plugins List > Upload Plugin Zip, choosing the zip-file from your file-system:
Do not forget to restart TeamCity for the plugin to take effect.
Once TeamCity has restarted, you can see the SpiraTeam Plug-In listed as one of the installed plugins:
"},{"location":"Build-Server-Integration/JetBrains-TeamCity/#setting-up-the-spirateam-teamcity-plug-in","title":"Setting-Up the SpiraTeam TeamCity Plug-in","text":"Now that the plugin has been installed, you need to configure the Global Settings for integration with SpiraTeam. To do this, go to Administration > Spira Global Settings:
You will need TeamCity administrator privileges to access this configuration page. Once in the Spira Global Settings page, enter in the URL you use to access your instance of SpiraTeam, together with a valid username and API Key. Once you have entered the values, click on the [Save] button. TeamCity will then verify if it can connect to SpiraTeam successfully.
Once it has connected successfully, your connection settings will be saved. In case of error, follow the instructions on-screen and try again.
After setting the global configurations appropriately, you will need to enable the notifications in TeamCity. To do this, go to My Settings & Tools, that can be accessed through clicking your TeamCity username (top right). Once there, click on the Notification Rules section, find the Spira Notifier for TeamCity section, and click its hyperlink:
Once in the page, click in Add new Rule. Then, inside the Send notification when section, select the events you want TeamCity notify SpiraTeam:
After selecting your preferences, click in the Save button.
"},{"location":"Build-Server-Integration/JetBrains-TeamCity/#configuring-a-teamcity-project","title":"Configuring a TeamCity Project","text":"Now that you have setup the Global SpiraTeam and Notifications settings in TeamCity, next you need to associate each of your TeamCity Projects with their corresponding SpiraTeam Project and Release/Iteration. To do this, click on the name of a project and then click on the \"Spira Project Configuration\" tab for that Project:
In this page you can check the URL of the SpiraTeam Server. If it is wrong, you can change it in the Spira Global Settings menu. It is also possible to check the Project ID associated with the project in TeamCity. This information can be useful for debugging/checking reasons.
To associate a TeamCity Project with a SpiraTeam Project, enter the following values:
Project ID -- The numeric ID of the SpiraTeam Project that the Build belongs to. (e.g. for Project PR00001 just enter 1)
Release Version Number -- The version number of the SpiraTeam Release/Iteration that the Build belongs to. (e.g. for Release RL0004 with version number 1.0.0.0 you'd enter just 1.0.0.0)
Once you have entered in the Project ID and Release version number, click the [Save] button and the plugin will connect to SpiraTeam and verify that the project exists, that the current user can connect to that project, and that the specified release/iteration exists in the project. Once it has verified successfully, it will save your Project configuration settings. In case of error, follow the instructions on-screen and try again. You are now ready to use TeamCity with SpiraTeam.
"},{"location":"Build-Server-Integration/JetBrains-TeamCity/#viewing-the-build-results-in-spirateam","title":"Viewing the Build Results in SpiraTeam","text":"Now that you have associated your TeamCity Project with a specific SpiraTeam project and release/ iteration, you can now use TeamCity to manage your software builds and have the results of the build be reported back into SpiraTeam. For example when the 'BuildConfigTest' build of Project 1 illustrated in the figure bellow is executed, it will report in TeamCity:
The corresponding build entry will also be created in SpiraTeam under the specified project and release/iteration:
If you have configured your Project Home to include the list of recent builds, the build information will also be displayed on the Project Home dashboard:
Clicking on either of the hyperlinks will allow you to navigate to the Build details page inside SpiraTeam:
This page will display the status (success / failure) and details of the build (imported from the TeamCity Console Output) together with a list of the associated incidents, test runs and source code commits. The following section will explain how to use your Source Code Management (SCM) system to take advantage of the SpiraTeam plugin and automatically link incidents and source code commits to the build information.
"},{"location":"Build-Server-Integration/JetBrains-TeamCity/#working-with-source-code-changesets","title":"Working with Source Code Changesets","text":"When your developers commit changes to your application's source into the SCM repository, they should make sure to link the commit to the appropriate artifacts in SpiraTeam. For example they may want to record that the commit fixes a specific incident or implements a specific feature (requirement).
Linking an artifact is very simple. All the developer needs to do is enter the artifact token in the following format:
[PREFIX:ID]
The first half, the Artifact Identifier, is a two-letter code that is used throughout SpiraTeam, and is visible on almost every page in the application. For example, a requirement's identifier is \"RQ\". Incidents are \"IN\", and tasks are \"TK\". The artifact ID is the number of the artifact. So by creating a commit message that reads:
SpiraTeam will automatically detect the tokens and will include links to them under the Associations tab for each commit detail in SpiraTeam.
Inside SpiraTeam, the system will use the same information to automatically link the list of associated commits to the build record:
If the commit message contains Incident tokens, the plugin will also automatically link those incidents to the appropriate build:
Similarly when you view the list of incidents inside SpiraTeam you will now be able to sort and filter the list by the associated build:
Congratulations! You are now able to use SpiraTeam and TeamCity to be able to manage your builds and have the build status integrated into your SpiraTeam project dashboard.
"},{"location":"Build-Server-Integration/JetBrains-TeamCity/#scheduling-test-sets-upon-successful-builds","title":"Scheduling Test Sets Upon Successful Builds","text":"One additional feature of the integration with SpiraTest and SpiraTeam (hereafter just SpiraTest) is the ability to have SpiraTest automatically schedule the execution of a test set whenever a build passes.
To do that, make sure the Test Set is associated with the SpiraTest release or iteration that is being built and then set the Schedule on Build field to \"Yes\" and optionally enter in the delay (after the build succeeds) that you want the test set to be scheduled for:
This means that you don't need to separately manage your build schedule in Jenkins and your test automation schedule in TeamCity.
"},{"location":"Build-Server-Integration/Microsoft-Azure-DevOps-Pipelines/","title":"Microsoft Azure DevOps Pipelines","text":"This section outlines how to use SpiraTest, SpiraPlan or SpiraTeam (hereafter referred to as SpiraPlan) in conjunction with Microsoft's Azure DevOps continuous integration platform called Azure DevOps Pipelines. It assumes that you already have a working installation of SpiraPlan v5.0 or later and have already setup Microsoft Azure DevOps Pipelines. If you have an earlier version of SpiraTeam, you will need to upgrade to at least v5.0.
"},{"location":"Build-Server-Integration/Microsoft-Azure-DevOps-Pipelines/#overview","title":"Overview","text":"Microsoft Azure DevOps provides tools for managing the entire application lifecycle, including source code management, reporting, automated builds, testing and release capabilities, for example. It supports version control using either its native TFS source code management system or Git. SpiraTeam has version control plugins for both TFS native and TFS with Git source code management options.
When you use the Spira Build Server Extension for Azure DevOps, it will allow you to associate different Azure DevOps projects with a corresponding project and release in SpiraPlan. Then, each time a DevOps pipeline creates a new build, a new build artifact will be created in SpiraPlan. Each build in SpiraTeam will be automatically linked to the incidents fixed, tasks implemented, requirements developed and source code commits committed.
"},{"location":"Build-Server-Integration/Microsoft-Azure-DevOps-Pipelines/#installing-the-spirateam-build-plug-in-for-azure-devops","title":"Installing the SpiraTeam Build Plug-in for Azure DevOps","text":"Go to the Inflectra website and open up the page that lists the various downloads available for SpiraTeam (http://www.inflectra.com/SpiraTeam/Downloads.aspx). Listed on this page will be the Azure DevOps Pipeline Plug-In. When you click on the link on this page, it will take you to the Azure DevOps Marketplace, where you can install the Spira extension into your DevOps instance:
After that, the plugin will be available in your instance of Azure DevOps.
"},{"location":"Build-Server-Integration/Microsoft-Azure-DevOps-Pipelines/#authenticating-with-spira","title":"Authenticating with Spira","text":"In DevOps, open the project you would like to have builds sync with Spira. Go to Project Settings > Pipelines > Service Connections
Under Service connections, click the \"New service connection\" button and click \"SpiraPlan Configuration.\" Under connection name, put something helpful like SpiraPlan Fred Bloggs
For SpiraPlan URL put the 'root' directory of your Spira instance, not including the end slash. For username, put the username you use to sign-in to Spira. For RSS Token, go to your user profile page in Spira, enable RSS Feeds and copy the token into DevOps. Now verify the connection by clicking \"Verify connection,\" if you entered everything correctly, you're good to go!
"},{"location":"Build-Server-Integration/Microsoft-Azure-DevOps-Pipelines/#adding-the-spira-build-task","title":"Adding the Spira Build Task","text":"Now in the pipeline you would like to add Spira support to, open the pipeline's YAML file and in the assistant to the right, search \"Spira\" and select \"Export data to Spira\" Select the service connection name you put in earlier, enter the ID of the project in Spira you would like your results sent to, the ID of the release you would like the builds to be associated with, and the base url of your DevOps instance (like https://dev.azure.com/fabrikam or https://fabrikam.visualstudio.com)
The other fields are used internally by the plugin and should be left as-is - DO NOT CHANGE THEM. Click \"Add\" and add the condition: succeededOrFailed() above inputs in the YAML snippet. This makes sure that the Spira task can access the current build status.
Now move the spira-build-task YAML Snippet to the end of the file so that it's executed last. This will make sure that the final result of the build gets recorded in Spira.
Here is an example YAML file:
trigger:\n- master\n\npool:\nvmImage: 'ubuntu-latest'\n\nsteps:\n- task: NodeTool@0\ninputs:\nversionSpec: '10.x'\ndisplayName: 'Install Node.js'\n- script: |\nnpm install\nnpm test\ndisplayName: 'npm install and test'\n- task: PublishTestResults@2\ncondition: succeededOrFailed()\ninputs:\ntestRunner: JUnit\ntestResultsFiles: '**/junitresults-*.xml'\n- task: spira-build-task@0\ncondition: succeededOrFailed()\ninputs:\nconnectedService: 'SpiraPlan Fred Bloggs'\nproject: '2'\nreleaseId: '20'\nbaseUrl: 'https://dev.azure.com/inflectra'\nbuildNumber: '$(Build.BuildNumber)'\nbuildStatus: '$(Agent.JobStatus)'\nbuildId: '$(Build.BuildId)'\nsourceVersion: '$(Build.SourceVersion)'\nprojectName: '$(System.TeamProject)'\nIf everything had been configured correctly a new build in DevOps will create a new build in Spira!
"},{"location":"Build-Server-Integration/Microsoft-Azure-DevOps-Pipelines/#viewing-the-build-results-in-spirateam","title":"Viewing the Build Results in SpiraTeam","text":"Now that you have associated your Azure DevOps pipeline with a specific SpiraTeam project and release/ iteration, you can now use Azure DevOps to manage your software builds and have the results of the build be reported back into SpiraPlan. For example, when a DevOps Pipeline runs, it will report in Azure DevOps something like the following:
The corresponding build entry will also be created in SpiraPlan under the specified project and release/iteration:
If you have configured your Project Home to include the list of recent builds, the build information will also be displayed on the Project Home dashboard:
Clicking on either of the hyperlinks will allow you to navigate to the Build details page inside SpiraTeam:
This page will display the status (success / failure) and details of the build.
Congratulations! You are now able to use SpiraPlan and Azure DevOps to be able to manage your builds and have the build status integrated into your SpiraPlan project dashboard.
"},{"location":"Build-Server-Integration/Microsoft-Azure-DevOps-Pipelines/#scheduling-test-sets-upon-successful-builds","title":"Scheduling Test Sets Upon Successful Builds","text":"One additional feature of the integration with SpiraPlan is the ability to have SpiraPlan automatically schedule the execution of a test set whenever a build passes.
To do that, make sure the Test Set is associated with the SpiraPlan release or iteration that is being built and then set the Schedule on Build field to \"Yes\" and optionally enter in the delay (after the build succeeds) that you want the test set to be scheduled for:
This means that you don't need to separately manage your build schedule in Azure DevOps and your test automation schedule in SpiraPlan.
"},{"location":"Email-Integration/Configuring-the-Email-Integration-Service/","title":"Configuring the Email Integration Service","text":"Once you have completed the installation, you can configure the email integration service by going to Start > Program Files > Inflectra SpiraTeam > Tools > Email Integration which will bring up the management interface.
"},{"location":"Email-Integration/Configuring-the-Email-Integration-Service/#connecting-to-the-spirateam-server","title":"Connecting to the SpiraTeam Server","text":"The first tab lets you specify the SpiraTeam instances that the email integration service will connect to. To add a new SpiraTeam server, click on the green Add (+) icon to switch the screen to allow you to enter a new server:
You need to enter the following information:
Click the \"Test\" button to verify the connection. Once it has passed, click the Save icon to save the new SpiraTeam server information.
To modify an existing SpiraTeam server instance, just click on its name in the server list. To delete a server, select its name in the server list and click the Delete icon (X).
Once you have entered all the SpiraTeam instances that you will be connecting to, click the \"Next\" button to move to the next tab and configure the mail server integration.
"},{"location":"Email-Integration/Configuring-the-Email-Integration-Service/#connecting-to-the-pop3-mail-server","title":"Connecting to the POP3 Mail Server","text":"The \"POP3 Accounts\" tab displays a list of all the configured mail servers:
Initially it will be empty, so just click the Add (+) icon to add a new mail server:
You need to enter the following information:
Using Gmail
If you use Google Workspace (gmail) make sure to take the following two steps. Note that personal gmail accounts are not supported.
To enable POP switch to an administrator account. This will open the Google Admin console. Follow https://support.google.com/a/answer/105694?hl=en to Google instructions to proceed.
To allow less secure app access - starting from May 30, 2022, \u200b\u200bGoogle no longer supports the use of third-party apps or devices which ask you to sign in to your Google Account using only your user name and password. This deadline does not apply to Google Workspace or Google Cloud Identity customers. For more information please refer to the Google Help: https://support.google.com/accounts/answer/6010255?hl=en#zippy=%2Cuse-more-secure-apps%2Cuse-an-app-password
"},{"location":"Email-Integration/Configuring-the-Email-Integration-Service/#configuring-the-advanced-settings","title":"Configuring the Advanced Settings","text":"Once you have finished configuring the SpiraTeam server instances and POP3 mail accounts, you can click on the \"Advanced Settings\" tab to setup special rules that prevent emails from specific accounts being processed as well as allow the email integration service to look for special mail headers and subject tokens that might indicate bulk / spam messages that should be ignored.
You can configure the following settings:
In addition, there are two other sub-tabs to the Advanced Settings tab that provide configuration options:
The \"Ignore Headers\" section allows you to specify any email message headers that if present in an email message will be ignored by the email integration service.
Note: Right now, the importer will only check the presence of a header, not its contents. As long as the header exists, even if it's value is null, the message will not be imported.
The \"Ignore Keywords\" section allows you to specify any keywords/phrases that if present in the subject-line or body of an email message will be ignored by the email integration service. Some mail servers that have built-in SPAM detection systems will automatically add SPAM-HIGH, SPAM-MEDIUM, SPAM-LOW to the subject line (for example).
The \"SpamAssasin\" section allows you to enable SpamAssasin utility, if you have a server that is running SpamAssasin. If this is enabled, messages marked as spam will not be imported, and be left on the mail server. You can use SpamAssasin's own level, or override the value. For information and support on SpamAssasin, see their website http://spamassasin.appache.org
"},{"location":"Email-Integration/Installing-the-Email-Integration-Service/","title":"Installing the Email Integration Service","text":"This section outlines how to install the SpiraTeam email integration service onto your environment. Depending on your environment you can install the email integration service on:
Your SpiraTeam application server
Your corporate mail server
A separate workstation that can connect to both SpiraTeam and your mail server
If your SpiraTeam installation is installed on-premise, then you can use options (1), (2) or (3), if your SpiraTeam installation is hosted by Inflectra as a Software as a Service (SaaS) subscription then you'd need to use either option (2) or (3).
Once you have downloaded the SpiraTeam email integration installation package (InflectraEmailIntegration.msi) from the Inflectra website you should download it onto the appropriate computer and double-click on it to run the Windows installer package:
You should click on the \"Next\" button, read the End User License Agreement, check the box that you agree with its terms and then click the \"Next\" button. This brings up the installation location page:
You should choose the appropriate place to install the email integration service and then click \"Next\". On the next screen click the \"Install\" button and it will complete the software installation.
Once the installation has completed, you will see the following new service listed in the Control Panel > Administrative Tools > Windows Services section:
The service should be listed to run in Automatic mode and should already be started.
Note: This email integration service is able to integrate with both KronoDesk and SpiraTeam from Inflectra, however the focus of this guide is the integration with SpiraTest, SpiraPlan and SpiraTeam (hereafter SpiraTeam) only.
"},{"location":"Email-Integration/Using-the-Email-Integration-Service-with-SpiraTeam/","title":"Using the Email Integration Service with SpiraTeam","text":"Once you have the email integration service configured, we recommend that you initially clear the Windows Application Log on the machine. This will allow you to quickly see any errors that occur due to misconfiguration. The event viewer can be found in Control Panel > Administrative Tools > Event Viewer.
Once you have the email integration enabled and running, any users that email in a support ticket to one of the \"watched\" email addresses will experience the following process:
The user emails incident.logger@mycompany.com with an incident to create.
The contents (including attachments) of the email will be parsed by the email integration service.
The application will look for tokens to decide if it should be inserted in the default project or another user-specified project.
The sender's email address will be queried to make sure that the user has access to create incident in the selected project. (If not, the system will then check the user's permissions for the default project.)
If the user has permission, the new incident is created.
The user will receive an automated email from the system letting them know that the incident was created:
SpiraTeam Incident \"Need New Security Settings updated in Documentation\" in project \"Project1\" has been changed.
Please log into SpiraTeam to view this Incident's details.
https://localhost/spirateam/6/Incident/2196.aspx
The user will not be subscribed to the ticket unless the user falls under normal Workflow Notification or Event Notification settings.
Any time the user gets a notification email from the server, they can reply to the email -- leaving the token in the subject line unaltered -- and their reply will be put into the ticket as a new comment. It's important that -- if enabled in the SpiraTeam application -- the separator line is not altered, and the reply is kept above the line. Any test under that line will not be imported. (If the separator line is altered, or the option is disabled in the SpiraTeam administration, then the entire email, including quotes and reply text, will be inserted.)
This section outlines the general data synchronization configuration to use any of the supported bug trackers with SpiraTest, SpiraPlan or SpiraTeam (hereafter referred to as Spira).
\u25ba Please read this section first, before performing the configuration steps specific to your bug-tracker.
The built-in data-synchronization service that comes with Spira, allows the quality assurance team to manage their requirements and test cases in Spira, execute their test runs, and then have the new defects/bugs generated during the run be automatically loaded into an external bug-tracker. Once the incidents are loaded into the external bug-tracker, the development team can then manage the lifecycle of these defects/bugs in their chosen tool, and have the status changes be reflected back in Spira.
In addition, any issues logged directly into the external bug-tracker will get imported into Spira as either new incidents or new requirements (depending on their type) so that they can be used as part of the planning and testing lifecycle.
There are three possible deployment options for the Spira data synchronization:
We shall provide the configuration steps for each option:
"},{"location":"External-Bug-Tracking-Integration/Setting-up-Data-Synchronization/#spira-external-tool-cloud-hosted","title":"Spira & External Tool Cloud Hosted","text":"Using the Customer Area to Manage the Spira DataSync
The \"Spira DataSync\" is a cloud based data synchronization tool that can be used to synchronize your cloud Spira to a number of cloud hosted external tools. Configuration is minimal and is managed from the Customer Area of your Inflectra account.
The Customer Area is your organization's dedicated portal on the Inflectra website for managing your account and subscriptions with us. It is used for:
Access to the Customer Area is restricted to only a couple of people in each organization. This is to ensure that only select authorized people are able to manage and make payments on their account.
If you do not have access to your organization's customer area, and you wish to edit or manage the \"Spira DataSync\" you will need to contact the owner of the Inflectra account in your organization. They will be able to assist you in configuring any settings as required.
When you sign up for Spira for a cloud-hosted trial, you can add on the Spira DataSync service to the trial for free. NOTE: the DataSync service is only free during the free trial period - there is a nominal charge for the service once you start your subscription.
Make sure to include the 'Spira DataSync' add-on with your trial.
If you did not include the Spira DataSync with your trial, you can add one at any time once your subscription starts. Go to the customer area; find the \"My Cloud Subscriptions\" section and click \"Customize\" next to the subscription you want to add the Spira DataSync to:
Once your trial (or subscription) is provisioned, you will be able to configure the connection to Spira by going to your secure Customer Area on our website. Click on the 'Configure' button associated with the Spira-DataSync addon row:
Enter a login and password that can connect to your Spira instance. This user, for all of the product(s) that will be synchronize with the external bug-tracker, needs to:
Click on the 'Test' button to verify the credentials, and once they validate, make sure the 'Active' flag is checked and then click 'Save'. You have now configured the synchronization.
Now navigate to your Spira instance. Go to System Administration > Integration > Data Sychronization to see a list of the plugins currently configured (as in the example below):
If you click on any of the 'Manage' buttons you will be taken to your Spira instance where you can complete the plugin configuration:
The steps for configuring each plugin are specific to each external bug-tracking tool. Please refer to the appropriate section in this document for the tool you are using.
"},{"location":"External-Bug-Tracking-Integration/Setting-up-Data-Synchronization/#spira-installed-on-premise","title":"Spira Installed On-Premise","text":"With Spira installed on-premise, there is a built-in Windows\u00ae service that is installed with Spira that is not running by default, but is available for data-synchronization.
The steps that need to be performed to configure integration are as follows:
Go to the Inflectra website and open up the page that lists the various downloads available for Spira (http://www.inflectra.com/SpiraTeam/Downloads.aspx). Listed on this page will be the data-synchronization plug-In for your desired bug-tracking tool. Right-click on this link and save the Zip compressed folder to the hard-drive of the server where Spira is installed.
Open up the compressed folder and extract the DLL assembly files and place them in the C:\\\\Program Files (x86)\\\\SpiraTeam\\\\DataSync folder (it may be SpiraTest or SpiraPlan depending on which product you're running). This folder should already contain the DataSyncService.exe and DataSyncService.exe.config files that are the primary files used for managing the data synchronization between Spira and other systems.
To configure the integration service, please open up the DataSyncService.exe.config file located in C:\\\\Program Files (x86)\\\\SpiraTeam\\\\DataSync with a text editor such as Notepad. Once open, it should look like:
<?xml version=\"1.0\" encoding=\"utf-8\"?>\n<configuration>\n<configSections>\n<sectionGroup name=\"applicationSettings\" type=\"System.Configuration.ApplicationSettingsGroup, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089\" >\n<section name=\"Inflectra.SpiraTest.DataSyncService.Properties.Settings\" type=\"System.Configuration.ClientSettingsSection, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089\" requirePermission=\"false\" />\n</sectionGroup>\n</configSections>\n<applicationSettings>\n<Inflectra.SpiraTest.DataSyncService.Properties.Settings>\n<setting name=\"PollingInterval\" serializeAs=\"String\">\n<value>600000</value>\n</setting>\n<setting name=\"WebServiceUrl\" serializeAs=\"String\">\n<value>http://localhost/SpiraTeam</value>\n</setting>\n<setting name=\"Login\" serializeAs=\"String\">\n<value>fredbloggs</value>\n</setting>\n<setting name=\"Password\" serializeAs=\"String\">\n<value>fredbloggs</value>\n</setting>\n<setting name=\"EventLogSource\" serializeAs=\"String\">\n<value>SpiraTeam Data Sync Service</value>\n</setting>\n<setting name=\"TraceLogging\" serializeAs=\"String\">\n<value>False</value>\n</setting>\n</Inflectra.SpiraTest.DataSyncService.Properties.Settings>\n</applicationSettings>\n</configuration>\nThe sections that need to be verified and possibly changed are the values for the following 4 setting XML tags above.
For each of these, check the following information:
The polling interval allows you to specify how frequently the data-synchronization service will ask Spira and the external system for new data updates. The value is specified in milliseconds and we recommend a value around 2-5 minutes (i.e. 120,000 - 300,000ms). The larger the number, the longer it will take for data to be synchronized, but the lower the network and server overhead. When you are using a bidirectional synchronization plugin, a shorter value with avoid conflicting changes being made in the system systems.
The base URL to your instance Spira. It is typically of the form http://<server name>/SpiraTeam. Make sure that when you enter this URL on a browser on the server itself, the application login page appears.
A valid login name and password to your instance of Spira. This user, for all of the product(s) that will be synchronize with the external bug-tracker, needs to:
Once you have made these changes, please refer to the section in this document that covers the specific bug-tracking tool you will be integrating with.
Note: If you are using the MS-TFS plugin on premise, you will also need to switch over your IIS application pool running Spira to \"Enable 32-bit Applications. You will also need to download the recompiled 32-bit version of the DataSyncService.exe application from our support knowledge base - KB14 - Using SpiraTeam Data Synchronization with TFS on a 64-bit system.
"},{"location":"External-Bug-Tracking-Integration/Setting-up-Data-Synchronization/#starting-the-data-synchronization-service","title":"Starting the Data-Synchronization Service","text":"When Spira is installed, a Windows Service -- SpiraTeam Data Sync Service -- is installed along with the web application. However to avoid wasting system resources, this service is initially set to run manually. To ensure continued synchronization of SpiraTeam with the external tool, we recommend starting the service and setting its startup-type to Automatic.
To make these changes, open up the Windows Control Panel, click on the \"Administrative Tools\" link, and then choose the Services option. This will bring up the Windows Service control panel:
Click on the 'SpiraTeam Data Sync Service' entry and click on the link to start the service. Then right-click the service entry and choose the option to set the startup type to 'Automatic'. This will ensure that synchronization continues after a reboot of the server.
"},{"location":"External-Bug-Tracking-Integration/Setting-up-Data-Synchronization/#spira-cloud-hosted-external-tool-on-premise","title":"Spira Cloud Hosted, External Tool On-Premise","text":"The Desktop Data Synchronization utility (hereafter referred to as the \"Desktop DataSync\") is a standalone utility than can be used to run the various Data Synchronization PlugIns without a server installation of Spira.
This is useful where you have your SpiraTeam instance cloud hosted, but the external tool is locally installed behind your firewall.
"},{"location":"External-Bug-Tracking-Integration/Setting-up-Data-Synchronization/#installation","title":"Installation","text":"To obtain the Desktop DataSync, go to the Inflectra website and under the \"Downloads and Add-Ons\" section you will find a Windows Installation (MSI) package that will install the Desktop DataSync onto your computer. The installer will install both a 64-bit version of the Desktop Data Sync and a 32-bit version. You should use the 64-bit version for all plugins except the Microsoft TFS plugin which will require the 32-bit version.
Next you need to download the appropriate plug-in(s) for the various bug-trackers (as described in the appropriate section of this document) and place the assemblies (DLL files) into the same folder that contains the DesktopDataSync.exe application:
"},{"location":"External-Bug-Tracking-Integration/Setting-up-Data-Synchronization/#usage","title":"Usage","text":"Once you have downloaded and installed the application and appropriate plug-ins, go to Start > Programs > Inflectra > Desktop DataSync to launch the application.
This will bring up the main options window of the application:
You should then enter the URL, login and password to your Spira installation and click [Test]. Assuming that this information is correct, you will see a confirmation message:
Now you should complete the configuation by setting the Polling Interval (how often the utility will synchronize data between Spira and the external system) and whether Trace Logging is enabled (useful when verifying your data mapping, but will fill up the application log, so leave unchecked for production use). Then click the [Update] button to save your settings or [Start] to save your settings and start synchronization immediately.
Once the Options window closes, the application will remain active in the system tray of your computer:
You can then use the right-click context menu to start synchronization, stop synchronization, view the status (if synchronization is running) or exit the application altogether.
During synchronization, any errors will be logged to the Windows Application Event Log and you can use those logs to diagnose any issues connecting to the external bug-tracker or any data mapping configuration changes that need to be made.
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-Asana/","title":"Using Spira with Asana","text":"This section outlines how to use SpiraTest, SpiraTeam or SpiraPlan (hereafter referred to as Spira) in conjunction with the Asana task tracking system.
Set up data synchronization
STOP! Please make sure you have first read the instructions to set up the data sync before proceeding!
Asana is a simple yet powerful cloud-based task management system used to track tasks. The built-in integration between Spira and Asana lets you create incidents and tasks in Spira and have them synchronize over to Asana as tasks.
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-Asana/#configuring-the-integration-service","title":"Configuring the Integration Service","text":"This section outlines how to set up the integration service between Asana and Spira. It assumes that you already have a working installation of Spira and a valid Asana account, workspace and project to integrate with. To setup the service, you must be logged into Spira as a user with System-Administrator level account.
Inside Spira, go to the Administration page and navigate to the Integration > Data Synchronization webpage. Check that you don't already have a Plug-In called \"AsanaDataSync\", as shown below:
If you already have a plug-in called AsanaDataSync, please click on its edit button, otherwise please click the Add button to create a new plug-in.
Now fill out this configuration page as follows:
You need to fill out the following fields for the Asana Data Sync plugin to work properly:
Name -- This needs to be set to AsanaDataSync
Caption -- This is the display name of the plug-in, generally something generic like \"Asana\" would work, but you should change it if you will be syncing with multiple Asana workspaces.
Description -- The description of what you're using the plug-in for. This field is entirely optional and is not used by the system in any way.
Connection Info -- The name of your Asana workspace, this is the name of your workspace or organization, not project.
Login -- Your Asana username / login
Password -- An Asana personal access token. For more information on personal access tokens, please refer to: https://asana.com/guide/help/api/api
Time Offset -- This should be set to 0, but if you find that changes are not being synced, try increasing the value to tell the plugin to offset timestamps
Custom 01-05 -- These fields are not used for Asana and can be left blank.
Once all those fields have been filled out, click the Add or Save button to save your changes.
For this step, please ensure that you are in the Spira project you would like to sync with Asana. For this example, the project is called \"Sample Empty Product 1\".
Click on the \"View Project Mappings\" button for Asana Data Sync. You need to fill out the following fields to sync correctly:
External Key -- The name of your Asana project. In our example, the project is called \"Sample Project\".
Active -- Set this to yes so that the Data Sync plug-in knows to synchronize with this project.
The project looks like this in Asana:
The Asana plugin will synchronize incidents and tasks, so you will need to setup the status mappings for incidents and tasks. We shall discuss each in turn.
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-Asana/#configuring-the-incident-status-mapping","title":"Configuring the Incident Status Mapping","text":"Now click the \"Status\" button within the \"Incident\" section to map the incident statuses together. The purpose of this is so that the Asana Data Sync plug-in knows what the equivalent status is in Asana for an incident status in Spira.
You must map every status in the system. Descriptions of the field are below:
External Key -- Either incomplete or completed, which are the only two statuses in Asana
Primary -- You must have exactly one primary key for incomplete and one for completed. This is what status the plug-in should set the incident in Spira to when the status in Asana changes.
Now click the \"Status\" button within the \"Task\" section to map the task statuses together. The purpose of this is so that the Asana Data Sync plug-in knows what the equivalent status is in Asana for an task status in Spira.
You must map every status in the system. Descriptions of the field are below:
External Key -- Either incomplete or completed, which are the only two statuses in Asana
Primary -- You must have exactly one primary key for incomplete and one for completed. This is what status the plug-in should set the task in Spira to when the status in Asana changes.
To configure the mapping of users in the two systems, you need to go to Administration > Users > View Edit Users, which will bring up the list of users in the system. Then click on the \"Edit\" button for a particular user that will be editing tasks in Asana:
Click on the 'Data Mapping' tab to list all the configured data-synchronization plug-ins for this user. In the text box next to the Asana Data-Sync plug-in you need to enter the login for this username in Asana. This will allow the data-synchronization plug-in to know which user in Spira match which equivalent user in Asana. Click Save once you've entered the appropriate login name. You should now repeat for the other users who will be active in both systems.
If you have set the \"Auto-Map Users\" option in the Asana plugin, you can skip this section completely.
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-Asana/#using-the-data-synchronization","title":"Using the Data Synchronization","text":"Assuming everything was done correctly, the plug-in should start working. If you are using Spira on-premise, start your Data Sync service and you can now start synchronizing incidents and tasks
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-Asana/#synchronizing-spira-incidents","title":"Synchronizing Spira Incidents","text":"When you log a new incident in Spira, for example:
It will appear in Asana as a new task:
Any of the following changes made in Asana will update back into Spira:
In addition, the Spira incident will automatically include a hyperlink to the corresponding item in Asana:
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-Asana/#synchronizing-spira-tasks","title":"Synchronizing Spira Tasks","text":"When you log a new task in Spira, for example:
It will appear in Asana as a new task:
Any of the following changes made in Asana will update back into Spira:
In addition, the Spira task will automatically include a hyperlink to the corresponding item in Asana:
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-Asana/#summary","title":"Summary","text":"Congratulations, you have just integrated your Spira instance with the Asana task tracking system.
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-Axosoft-14%2B/","title":"Using Spira with Axosoft 14+","text":"This section outlines how to use SpiraTest, SpiraPlan or SpiraTeam (hereafter referred to as SpiraTeam) in conjunction with the Axosoft defect tracking system (formerly known as OnTime). The built-in integration service allows the quality assurance team to manage their requirements and test cases in SpiraTeam, execute test runs in SpiraTest, and then have the new incidents generated during the run be automatically loaded into Axosoft.
Once the incidents are loaded into Axosoft as defects, the development team can then manage the lifecycle of these defects in Axosoft, and have the status changes in Axosoft be reflected back in SpiraTeam.
Set up data synchronization
STOP! Please make sure you have first read the instructions to set up the data sync before proceeding!
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-Axosoft-14%2B/#configuring-the-plug-in","title":"Configuring the Plug-In","text":"This section outlines how to configure the integration service to export incidents into Axosoft and pick up subsequent status changes in Axosoft and have them update SpiraTeam. It assumes that you already have a working installation of SpiraTest, SpiraPlan or SpiraTeam v4.0 or later and a working installation of Axosoft 14 or later (either hosted in the cloud or on-premise). If you have an earlier version of SpiraTeam, you will need to upgrade to at least v4.0 before trying to integrate with Axosoft.
The steps that need to be performed to configure integration with Axosoft are as follows:
Enable the REST API in Axosoft
Setup the plug-in in SpiraTeam to point to the correct instance of Axosoft
Configure the data field mappings between SpiraTeam and Axosoft
Start synchronization and verify data transfer
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-Axosoft-14%2B/#enable-the-rest-api-in-axosoft","title":"Enable the REST API in Axosoft","text":"First you will need to login to your instance of Axosoft and click on Tools > System Options. Then click on the 'Axosoft API Settings' section:
Check the box to 'Enable API' and then click on the [Manage API Keys] button:
On this screen you will need to enter the name of the application you are creating an API key for (e.g. \"Spira\") and then record the following two pieces of information:
Client ID
Client Secret
You will need these later on. Then click Save.
The Axosoft Client Secret is a long hash that will be of the form:
ykk8WD3eYfMJ6WbV1HtkutJv_w9jS2ah1tSbwqs-408Gp0_cPh5wTnjwfqPLN3-_oCSHPVG5tpFkETHBgxUBKbXaTzzVqYtKC9_S
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-Axosoft-14%2B/#configuring-the-plug-in_1","title":"Configuring the Plug-In","text":"The next step is to configure the plug-in within SpiraTeam so that the system knows how to access the Axosoft server. To start the configuration, please open up SpiraTeam in a web browser, log in using a valid account that has System-Administration level privileges and click on the System > Data Synchronization administration option from the left-hand navigation:
This screen lists all the plug-ins already configured in the system. Depending on whether you chose the option to include sample data in your installation or not, you will see either an empty screen or a list of sample data-synchronization plug-ins.
If you already see an entry for AxosoftDataSync you should click on its \"Edit\" link. If you don't see such an entry in the list, please click on the [Add] button instead. In either case you will be taken to the following screen where you can enter or modify the Axosoft Data-Synchronization plug-in:
You need to fill out the following fields for the Axosoft Plug-in to operate correctly:
Name -- this needs to be set to AxosoftDataSync. This needs to match the name of the plug-in DLL assembly that was copied into the C:\\Program Files\\SpiraTeam\\Bin folder (minus the .dll file extension). If you renamed the AxosoftDataSync.dll file for any reason, then you need to change the name here to match.
Description -- this should be set to a description of the plug-in. This is an optional field that is used for documentation purposes and is not actually used by the system.
Connection Info -- this should the full URL to Axosoft. This is typically something like: https://mysite.axosoft.com.
Login -- this should be set to the login that you use to access Axosoft through its web interface
Password -- this should be set to the password that you use to access Axosoft through its web interface
Time Offset -- normally this should be set to zero, but if you find that defects being changed in Axosoft are not being updated in SpiraTeam, try increasing the value as this will tell the data-synchronization plug-in to add on the time offset (in hours) when comparing date-time stamps.
Auto-Map Users -- This changes the way that the plugin maps users in SpiraTeam to those in Axosoft:
**Auto-Map = True **With this setting, all users in SpiraTeam need to have the same username as those in Axosoft. If this is the case then you do not need to perform the user-mapping task outlined in Configuring the User Mapping. This is a big time-saver if you can guarantee that all usernames are the same in both systems.
**Auto-Map = False **With this setting, users in SpiraTeam and Axosoft are free to have different usernames because you specify the corresponding Axosoft login for each user as outlined in Configuring the User Mapping.
Custom 01 -- This should contain the Client ID value from the Axosoft API Key screen
Custom 02 -- This should contain the Axosoft Client Secret that you obtained from the Axosoft API Key Screen.
Custom 03-05 -- these are not currently used by the Axosoft data-sync plug-in and can be left blank.
Next, you need to configure the data mapping between SpiraTeam and Axosoft. This allows the various projects, users, releases, incident statuses, priorities, severities and custom property values used in the two applications to be related to each other. This is important, as without a correct mapping, there is no way for the integration service to know that an \"Open\" incident in SpiraTeam is the same as an \"Open\" defect in Axosoft (for example).
The following mapping information needs to be setup in SpiraTeam:
The mapping of the project identifiers for the projects that need to be synchronized
The mapping of users in the system
The mapping of releases in the system
The mapping of the various standard fields in the system
The mapping of the various custom properties in the system
Each of these is explained in turn below:
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-Axosoft-14%2B/#configuring-the-project-mapping","title":"Configuring the Project Mapping","text":"From the data synchronization administration page, you need to click on the \"View Project Mappings\" hyperlink next to the Axosoft plug-in name. This will take you to the data-mapping home page for the currently selected project:
If the project name does not match the name of the project you want to configure the data-mapping for, click on the \"(Change Project)\" hyperlink to change the current project.
To enable this project for data-synchronization with Axosoft, you need to enter:
External Key -- This should be set to the name of the project token in Axosoft:
If you have a sub-project, you need to include both the parent and sub-project names separated by a forward slash (/), e.g. MyProject/SubProject1.
Active Flag -- Set this to 'Yes' so that SpiraTeam knows that you want to synchronize data for this project. Once the project has been completed, setting the value to \"No\" will stop data synchronization, reducing network utilization.
Click [Update] to confirm these settings. Once you have enabled the project for data-synchronization, you can now enter the other data mapping values outlined below.
Note: Once you have successfully configured the project, when creating a new project, you should choose the option to \"Create Project from Existing Project\" rather than \"Use Default Template\" so that all the project mappings get copied across to the new project.
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-Axosoft-14%2B/#configuring-the-user-mapping","title":"Configuring the User Mapping","text":"(This section can be skipped if you enabled the 'AutoMap Users' option earlier).
To configure the mapping of users in the two systems, you need to go to Administration > Users > View Edit Users, which will bring up the list of users in the system. Then click on the \"Edit\" button for a particular user that will be editing defects in Axosoft:
You will notice that in the Data Mapping tab for the user is a list of all the configured data-synchronization plug-ins. In the text box next to the Axosoft Data-Sync plug-in you need to enter the Login Name for this username in Axosoft. This will allow the data-synchronization plug-in to know which user in SpiraTeam match which equivalent user in Axosoft. Click [Update] once you've entered the appropriate login name. You should now repeat for the other users who will be active in both systems.
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-Axosoft-14%2B/#configuring-the-release-mapping","title":"Configuring the Release Mapping","text":"When the data-synchronization service runs, when it comes across a release/iteration in SpiraTeam that it has not seen before, it will create a corresponding Release in Axosoft. Similarly if it comes across a new Release in Axosoft that it has not seen before, it will create a new Release in SpiraTeam. Therefore when using both systems together, it is recommended that you only enter new Releases in one system and let the data-synchronization service add them to the other system.
To see this mapping, inside SpiraTeam, navigate to Planning > Releases and click on the Release/Iteration in question. Make sure you have the 'Overview' tab visible and expand the \"Details\" section of the release/iteration:
In addition to the standard fields and custom properties configured for Releases, you will see an additional text property called \"AxosoftDataSync ID\" that is used to store the mapped external identifier for the equivalent Version in Axosoft.
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-Axosoft-14%2B/#configuring-the-standard-field-mapping","title":"Configuring the Standard Field Mapping","text":"Now that the projects, user and releases have been mapped correctly, we need to configure the standard incident fields. To do this, go to Administration > System > Data Synchronization and click on the \"View Project Mappings\" for the AxosoftDataSync plug-in entry:
From this screen, you need to click on Priority, Severity and Status in turn to configure their values (Axosoft doesn't support different defect types):
a) Incident Status
Click on the \"Status\" hyperlink under Incident Standard Fields to bring up the Incident status mapping configuration screen:
The table lists each of the incident statuses available in SpiraTeam and provides you with the ability to enter the matching Axosoft defect status names for each one. You can map multiple SpiraTeam fields to the same Axosoft fields (e.g. New and Open in SpiraTeam are both equivalent to Open in Axosoft), in which case only one of the two values can be listed as Primary = Yes as that's the value that's used on the reverse synchronization (from Axosoft > SpiraTeam).
We recommend that you always point the New and Open statuses inside SpiraTeam to point to the \"Open\" status inside Axosoft and make Open in SpiraTeam the Primary status of the two. This is recommended so that as new incidents in SpiraTeam get synched over to Axosoft, they will get switched to the Open status in Axosoft which will then be synched back to \"Open\" in SpiraTeam. That way you'll be able to see at a glance which incidents have been synched with Axosoft and those that haven't.
Note: The Axosoft external key needs to exactly match the display name of the status inside Axosoft. If you change the name of a status in Axosoft, you'll need to update the value in the data-mapping configuration as well.
b) Incident Priority
Click on the \"Priority\" hyperlink under Incident Standard Fields to bring up the Incident Priority mapping configuration screen:
The table lists each of the incident priorities available in SpiraTeam and provides you with the ability to enter the matching Axosoft priority name for each one. You can map multiple SpiraTeam fields to the same Axosoft fields, in which case only one of the two values can be listed as Primary = Yes as that's the value that's used on the reverse synchronization (from Axosoft > SpiraTeam).
Note: The Axosoft external key needs to exactly match the display name of the priority inside Axosoft. If you change the name of a priority in Axosoft, you'll need to update the value in the data-mapping configuration as well.
c) Incident Severity
Click on the \"Severity\" hyperlink under Incident Standard Fields to bring up the Incident severity mapping configuration screen:
The table lists each of the incident severities available in SpiraTeam and provides you with the ability to enter the matching Axosoft severity name for each one. You can map multiple SpiraTeam fields to the same Axosoft fields, in which case only one of the two values can be listed as Primary = Yes as that's the value that's used on the reverse synchronization (from Axosoft > SpiraTeam).
Note: The Axosoft external key needs to exactly match the display name of the severity inside Axosoft. If you change the name of a severity in Axosoft, you'll need to update the value in the data-mapping configuration as well.
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-Axosoft-14%2B/#configuring-the-custom-property-mapping","title":"Configuring the Custom Property Mapping","text":"Now that the various SpiraTeam standard fields have been mapped correctly, we need to configure the custom property mappings. This is used for both custom properties in SpiraTeam that map to custom fields in Axosoft and also for custom properties in SpiraTeam that are used to map to standard fields in Axosoft (currently only Replication Procedures) that don't exist in SpiraTeam.
From the View/Edit Project Data Mapping screen, you need to click on the name of the Incident Custom Property that you want to add data-mapping information for. We will consider the three different types of mapping that you might want to enter:
a) Scalar Custom Properties
This refers to custom properties that have a simple user-entered value and don't need to have their specific options mapped between SpiraTeam and Axosoft. All of the custom property types except List and Multi-List fall into this category (e.g. Text, Date, User, Boolean, Decimal, Integer, etc.)
Click on the hyperlink of the text custom property under Incident Custom Properties to bring up the custom property mapping configuration screen. For text custom properties there will be no values listed in the lower half of the screen.
You need to lookup the display name of the custom field in Axosoft that matches this custom property in SpiraTeam. Once you have entered the id of the custom field, click [Update].
b) List Custom Properties
Click on the hyperlink of the list custom property under Incident Custom Properties to bring up the custom property mapping configuration screen. For list custom properties there will be a textbox for both the custom field itself and a mapping table for each of the custom property values that need to be mapped:
First you need to lookup the display name of the custom field in Axosoft that matches this custom property in SpiraTeam. This should be entered in the 'External Key' field below the name of the custom property.
Next for each of the Property Values in the table (in the lower half of the page) you need to enter the full name of the custom field value as specified in Axosoft.
Once you have updated the various mapping sections, you are now ready to use the service.
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-Axosoft-14%2B/#using-spirateam-with-axosoft","title":"Using SpiraTeam with Axosoft","text":"Now that the integration service has been configured and the service started, initially any incidents created in SpiraTeam for the specified projects will be imported into Axosoft and vice versa.
At this point we recommend opening the Windows Event Viewer and choosing the Application Log. In this log any error messages raised by the SpiraTeam Data Sync Service will be displayed. If you see any error messages at this point, we recommend immediately stopping the SpiraTeam service and checking the various mapping entries. If you cannot see any defects with the mapping information, we recommend sending a copy of the event log message(s) to Inflectra customer services (support@inflectra.com) who will help you troubleshoot the problem.
To use SpiraTeam with Axosoft on an ongoing basis, we recommend the following general processes be followed:
When running tests in SpiraTeam, defects found should be logged through the 'Add Incident' option as normal.
Developers can log new defects into either SpiraTeam or Axosoft. In either case they will get loaded into the other system.
Once created in one of the systems and successfully replicated to the other system, the incident should not be modified again inside SpiraTeam
At this point, the incident should not be acted upon inside SpiraTeam, and all data changes to the defect should be made inside Axosoft. To enforce this, you can modify the workflows set up in SpiraTeam so that the various fields are marked as inactive for all the incident statuses other than the \"New\" status. This will allow someone to submit an incident in SpiraTeam, but will prevent them making changes in conflict with Axosoft after that point.
As the defect progresses through the Axosoft workflow, changes to the status, priority, severity, and resolution will be updated automatically in SpiraTeam. In essence, SpiraTeam acts as a read-only viewer of these incidents.
You are now able to perform test coverage and incident reporting inside SpiraTeam using the test cases managed by SpiraTeam and the incidents managed on behalf of SpiraTeam inside Axosoft.
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-ClickUp/","title":"Using Spira with ClickUp","text":"ClickUp is a cloud based project management system that can be synced with SpiraTest, SpiraTeam or SpiraPlan (Spira from here on). This data sync lets you:
Details of how to set this up and things to watch out for are explained below.
Set up data synchronization
STOP! Please make sure you have first read the instructions to set up the data sync before proceeding!
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-ClickUp/#system-setup","title":"System Setup","text":"This section outlines how to set up the integration between ClickUp and Spira. It assumes you already have a working installation of Spira (Version 7.3+) as well as a workspace in ClickUp. To setup the service, you must be logged into a Spira user with System-Administrator level privileges.
Inside SpiraPlan, open the system admin menu and open the Integration > Data Synchronization page. Check if you see a plug-in called ClickUpDataSync, as shown below:
What do if the plug-in is not there
If you don't see the plug-in in the list, click the \"\"Add\" button at the top of the page. This opens the generic Data Sync plug-in details page. This is not yet customized to help you more easily set up the data sync. We recommend, adding just enough information now to create the plug-in. Then edit the plug-in after its made to complete the process.
To start, fill in the following fields:
Now click \"Add\" to save the plug-in and return you to the list of plug-ins. Then follow the instructions below.
With the plug-in place, click on its \"edit\" button to open its detailed settings page.
You need to fill out the following fields for the ClickUp Data Sync plugin to work properly:
login) here, and enter the actual token in the password field below)Custom 01 (Data Sync Directionality): This should contain one of these 3 options and determines how the data sync will function.
clickup_to_spira: sync new and updated information from ClickUp to Spiraspira_to_clickup: sync new information from Spira to ClickUp (see the box below for more information about how syncing from Spira to ClickUp works)bidirectional: sync both of the above options at onceCustom 02 (Artifact Sync Options): The types of information you want to sync, with the names in a comma separated list. requirements, tasks, incidents, releases, files, and associations are the choices. You may also put \"all\" to select all of these options. For example, you could enter: all, requirements, tasks, incidents, releases, files, associations, or requirements, incidents, releases. Note that not all of these artifacts sync in both directions (see the box below for more information)
Click the \"Save\" button.
How syncing from Spira to ClickUp works
Please note the following ways that the data sync from Spira to ClickUp works. These also apply when syncing from Spira to ClickUp with the sync direction set to bidirectional:
For this step, from the Data Synchronization page:
From the product's data mapping page for ClickUp, enter a value for the external key, set \"Active\" to \"Yes\", and click \"Save\".
How to configure external key: The external key contains the names of a Space to sync with this product, and also the name of the Workspace that space is in. This must be in the format of \"Workspace Name || Space Name\" (notice the double pipe | characters) and should match the capitalization of the names in ClickUp. Here is an example of what this looks like, and how it relates to ClickUp's UI:
Incompatible description formatting between platforms
Please note that text formatting in descriptions from either service cannot be mapped to the other, as their formats are not compatible. Complex structures such as tables may produce unintended results that are confusing in the opposite service when synced. The data sync does its best to turn both formats into plain text to keep the descriptions readable.
Click the \"Status\" button within the incident, task, or requirement section (You should do this for each artifact you intend to sync). From here, map each status in ClickUp to a status in Spira.
Note: If 1 mapped status in ClickUp is mapped to multiple statuses in Spira, you must choose which is the primary mapping. The primary mapping will be used when syncing from ClickUp to Spira.
Here is an example using ClickUp's \"Normal\" Status Template:
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-ClickUp/#configuring-priority-mappings","title":"Configuring priority mappings","text":"Priority mappings are very similar to status, except the values from ClickUp's priority field are not customizable.
Here is an example of how this would look using default Spira priorities with ClickUp's priorities:
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-ClickUp/#configuring-custom-property-mappings","title":"Configuring custom property mappings","text":"This section assumes the custom properties in Spira and ClickUp are of compatible types. Custom property syncing will not work and may cause the sync to fail if this is not adhered to. Below is a list of custom property types in Spira and which custom properties in ClickUp can map to them. Any custom property types besides the ones outlined here will not be attempted to be mapped into Spira. Fields marked with ** will only be synced from ClickUp to Spira due to formatting constraints.
Spira custom property type Matching ClickUp custom property type Text (not rich text) TextText AreaEmailUrlPhone Decimal Number DateDate & Time Date Boolean Checkbox List Dropdown Multiselect List Labels"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-ClickUp/#non-list-custom-properties","title":"Non-List Custom Properties","text":"To configure a non-list custom property in ClickUp to a custom property in Spira, set the external key to the name of the property in ClickUp (case sensitive). As an example, if there is a text field in ClickUp named \"Custom Text\", you would configure the mapping like this:
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-ClickUp/#list-custom-properties","title":"List Custom Properties","text":"To configure a list or multiselect list custom property, first follow the steps for a non-list property. After that, configure the options. It is important that these options match the exact capitalization in ClickUp. As an example, here is a multiselect list in Spira mapped to a labels custom property in ClickUp named \"Labels In ClickUp\" with the options \"Label 1\", \"Label 2\", \"Label 3\", and \"Label 4\":
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-ClickUp/#configuring-user-mappings","title":"Configuring User mappings","text":"Users must be configured manually for this data sync in order for the owner and creator fields to be assigned to that user during syncing.
To configure the mapping of users in the two systems, go to Administration > Users > View / Edit Users to see the list of users in the Spira system. Click the \"Edit\" button for a particular user that edits tasks in ClickUp:
Click on the \"Data mapping\" tab to list all the configured data-synchronization plug-ins for this user. In the text box labeled \"ClickUp ID\", enter the full name of the user in ClickUp. Click \"Save\" and the user will be mapped so long as the configuration was done correctly. Repeat this for each user who will be active in both systems.
NOTE: avoid having duplicate names for multiple users. If this is the case, you will need to change the name somehow in ClickUp to make them unique (for example, by adding any middle initial).
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-ClickUp/#using-the-data-synchronization","title":"Using the Data Synchronization","text":"Once the steps above have been carried out, the data sync will start working once you mark the \"Active\" option for the data sync at the system level and in all relevant products.
Congratulations, you have just integrated your Spira instance with the ClickUp project managing system.
Wait for the \"Status\" on the data sync to update to see if it was successful. If it failed, look at the event logs for error messages which may contain insights into what part of the configuration you need to fix.
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-GitHub/","title":"Using Spira with GitHub","text":"GitHub's issue tracker is a simple and lightweight tool used to track problems with an associated git repository.
You can use this integration to sync new incidents, new comments, statuses, pull requests, and releases (milestones) with SpiraTest, SpiraTeam or SpiraPlan (SpiraPlan from here on).
Set up data synchronization
STOP! Please make sure you have first read the instructions to set up the data sync before proceeding!
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-GitHub/#configuring-the-integration-service","title":"Configuring the Integration Service","text":"This section outlines how to set up the integration service between GitHub and SpiraPlan. It assumes that you already have a working installation of SpiraPlan and a GitHub repository with an issue tracker. To setup the service, you must be logged into SpiraPlan as a user with System-Administrator level privileges.
Inside SpiraPlan, go to the Administration page and navigate to Integration > Data Synchronization. Check if you see a plug-in called GitHubDataSync, as shown below:
What do if the plug-in is not there
If you don't see the plug-in in the list, click the \"\"Add\" button at the top of the page. This opens the generic Data Sync plug-in details page. This is not yet customized to help you more easily set up the data sync. We recommend, adding just enough information now to create the plug-in. Then edit the plug-in after its made to complete the process.
To start, fill in the following fields:
Now click \"Add\" to save the plug-in and return you to the list of plug-ins. Now follow the instructions below.
With the plug-in place, click on its \"edit\" button to open its detailed settings page.
You need to fill out the following fields for the GitHub Data Sync plugin to work properly:
issues, pullrequests, and milestones (Typed as shown here). If this is left blank, issues and milestones are synced. Milestones cannot be synced alone - they must be paired with issues and/or pull requests. Click the \"Save\" button.
NOTE: Leave any field called \"(Not Used)\" blank.
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-GitHub/#manually-setting-up-user-mappings","title":"Manually Setting Up User Mappings","text":"If the display names of users on GitHub do not match the format of their names in SpiraPlan, then the auto-mapping feature will not work, and user mappings will need to be configured manually. If there is not a user mapping for a given GitHub account, the SpiraPlan account used by the data sync will be assigned as the creator of pull requests and the owner field will be left blank where relevant.
To configure the mapping of users in the two systems, go to Administration > Users > View / Edit Users to see the list of users in the SpiraPlansystem. Click the \"Edit\" button for a particular user that has an equivalent user in GitHub:
Click on the \"Data mapping\" tab to list all the configured data-synchronization plug-ins for this user. In the text box labeled \"GitHub ID\", enter the GitHub username of the user. Click \"Save\" and the user in SpiraPlan will be mapped to that GitHub user. Repeat this for each user who will be active or used in both systems.
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-GitHub/#configuring-product-mappings","title":"Configuring Product Mappings","text":"For this step, please ensure that you are in the SpiraPlan product you would like to sync with GitHub. For this example, the product is called \"Library Information System\".
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-GitHub/#configuring-repository-mappings","title":"Configuring Repository Mappings","text":"Click on the \"View product Mappings\" button for GitHub Data Sync. You need to fill out the following fields to sync correctly:
External Key -- The name of your GitHub repository. In the example above, where the URL in GitLab was https://github.com/octocat/Hello-World, you would simply enter \"Hello-World\" for this setting.
Active -- Set this to yes so that the Data Sync plug-in knows to synchronize with this product.
Now click the \"Status\" button within the \"Incident\" section to map the Incident statuses together. The purpose of this is so that the GitHub Data Sync plug-in knows what the equivalent status is in GitHub for an incident status in SpiraPlan.
You must map every status in the system. Descriptions of the field are below:
External Key -- Either open or closed, which are the only two statuses in GitHub
Primary -- You must have exactly one primary key for open and one for closed. This is what status the plug-in should set the incident in SpiraPlan to when the status in GitHub changes.
Click \"Save\" and assuming everything was done correctly, the plug-in should work. Start your Data Sync service and verify that issues in GitHub appear inside SpiraPlan. Note that the Data Sync service is not running constantly, so it may take some time for changes to materialize.
Congratulations, you have just integrated your SpiraPlaninstance with GitHub's integrated issue tracker!
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-GitHub/#syncing-pull-requests","title":"Syncing Pull Requests","text":"Set Up GitHub As A Source Code Provider
If you do not set up GitHub as a source code provider pull request syncing will not work. Once the source code integration is set up, pull request syncing will work after the cache in SpiraPlan has been.
To sync pull requests, the GitHub repository that is being synced must be connected to the same product both as an issue tracker (as outlined in this guide) and as a source code provider. Pull requests are synced from GitHub into SpiraPlan only.
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-GitHub/#additional-product-and-template-configuration","title":"Additional Product and Template Configuration","text":"Syncing pull requests has additional requirements in terms of product mappings and product template configuration for this feature to work. If you are not syncing Pull requests, you do not need to do this additional setup.
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-GitHub/#task-types","title":"Task Types","text":"To properly sync pull requests, there must be at least one task type with \"Pull Request?\" set to Yes in the template for the product(s) you are syncing. If there are multiple, the type which is the nearest to the top of the list will be selected by the data sync.
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-GitHub/#task-status-mappings","title":"Task Status Mappings","text":"In task status mappings, there are 4 possible statuses from GitHub that need to be accounted for. The possible statuses are \"open\", \"started\", \"closed\", and \"merged\". These are case sensitive.
These external keys mean the following:
GitLab's issue tracker is a simple and lightweight tool used to track problems with an associated git repository.
You can use this integration to sync new incidents, new comments, statuses, and releases (milestones) bidirectionally with SpiraTest, SpiraTeam or SpiraPlan (SpiraPlan from here on).
Set up data synchronization
STOP! Please make sure you have first read the instructions to set up the data sync before proceeding!
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-GitLab/#configuring-the-integration-service","title":"Configuring the Integration Service","text":"This section outlines how to set up the integration service between GitLab and SpiraPlan. It assumes that you already have a working installation of SpiraPlan and a GitLab repository with an issue tracker. To setup the service, you must be logged into SpiraPlan as a user with System-Administrator level privileges.
Inside SpiraPlan, go to the Administration page and navigate to Integration > Data Synchronization. Check if you see a plug-in called GitLabDataSync as shown below:
What do if the plug-in is not there
If you don't see the plug-in in the list, click the \"\"Add\" button at the top of the page. This opens the generic Data Sync plug-in details page. This is not yet customized to help you more easily set up the data sync. We recommend, adding just enough information now to create the plug-in. Then edit the plug-in after its made to complete the process.
To start, fill in the following fields:
Now click \"Add\" to save the plug-in and return you to the list of plug-ins. Now follow the instructions below.
With the plug-in place, click on its \"edit\" button to open its detailed settings page.
You need to fill out the following fields for the GitLab Data Sync plugin to work properly:
Click the \"Save\" button.
NOTE: Leave any field called \"(Not Used)\" blank.
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-GitLab/#configuring-project-mappings","title":"Configuring Project Mappings","text":"For this step, please ensure that you are in the SpiraPlan project you would like to sync with GitLab. For this example, the project is called \"GitLab Data Sync.\"
Click on the \"View Project Mappings\" button for GitLab Data Sync. You need to fill out the following fields to sync correctly:
External Key -- The name of your GitLab repository. In the example above, where the URL in GitLab was https://gitlab.com/gitlab-examples/velociraptor, you would simply enter \"velociraptor\" for this setting.
Active -- Set this to yes so that the Data Sync plug-in knows to synchronize with this project.
Now click the \"Status\" button within the \"Incident\" section to map the Incident statuses together. The purpose of this is so that the GitLab Data Sync plug-in knows what the equivalent status is in GitLab for an incident status in SpiraPlan.
You must map every status in the system. Descriptions of the field are below:
External Key -- Either opened or closed, which are the only two statuses in GitLab
Primary -- You must have exactly one primary key for opened and one for closed. This is what status the plug-in should set the incident in SpiraPlan to when the status in GitLab changes.
To configure the mapping of users in the two systems, you need to go to Administration > Users > View Edit Users, which will bring up the list of users in the system. Then click on the \"Edit\" button for a particular user that will be editing issues in GitLab:
Click on the 'Data Mapping' tab to list all the configured data-synchronization plug-ins for this user. In the text box next to the GitLab Data-Sync plug-in you need to enter the login for this username in GitLab. This will allow the data-synchronization plug-in to know which user in SpiraTeam match which equivalent user in GitLab. Click [Save] once you've entered the appropriate login name. You should now repeat for the other users who will be active in both systems.
If you have set the \"Auto-Map Users\" option in the GitLab plugin, you can skip this section completely.
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-GitLab/#configuring-the-release-mapping","title":"Configuring the Release Mapping","text":"When the data-synchronization service runs, when it comes across a release/iteration in SpiraTeam that it has not seen before, it will create a corresponding \"Milesone\" in GitLab. Similarly, if it comes across a new Milestone in GitLab that it has not seen before, it will create a new Release in SpiraTeam. Therefore, when using both systems together, it is recommended that you only enter new Releases/Milestones in one system and let the data-synchronization service add them to the other system.
However, you may start out with the situation where you already have pre-existing Releases / Milestones in both systems that you need to associate in the data-mapping. If you don't do this, you may find that duplicates get created when you first enable the data-synchronization service. Therefore, for any Releases/Iterations that already exist in BOTH systems please navigate to Planning > Releases and click on the Release/Iteration in question. Make sure you have the 'Overview' tab visible and expand the \"Details\" section of the release/iteration:
In addition to the standard fields and custom properties, you will see an additional text property called \"GitLab ID\" that is used to store the mapped external identifier for the equivalent Milestone in GitLab. You need to locate the ID of the equivalent version in GitLab, enter it into this text-box and click [Save]. You should now repeat for all the other pre-existing releases.
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-GitLab/#using-the-data-synchronization","title":"Using the Data Synchronization","text":"Assuming everything was done correctly, the plug-in should start working. Start your Data Sync service and verify that issues in GitLab appear inside SpiraPlan. Note that the Data Sync service is not running constantly, so it may take some time for changes to materialize.
Congratulations, you have just integrated your Spira instance with GitLab's integrated issue tracker!
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-Monday/","title":"Using Spira with monday.com","text":"The monday.com products are cloud-based platforms that allows users to create their own applications and work management software with more than 50 integrations with other applications.
This page outlines how to use SpiraTest, SpiraTeam, or SpiraPlan (called Spira from here on) with monday.com products. This data sync engine lets you add new monday.com items to Spira as Tasks and Incidents (and vice versa). The data sync also lets you update artifacts and items in both systems/directions.
Set up data synchronization
STOP! Please make sure you have first read the instructions to set up the data sync before proceeding!
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-Monday/#configuring-the-plug-in","title":"Configuring the Plug-In","text":"Now that the data synchronization service / application itself is set up, we are ready to move to the next step. You need to tell Spira how to access your monday.com app. Inside Spira, go to the Administration page (as a system admin) and navigate to Integration > Data Synchronization. Check if you see a plug-in called MondayDataSync.
What do if the plug-in is not there
If you don't see the plug-in in the list, click the \"\"Add\" button at the top of the page. This opens the generic Data Sync plug-in details page. This is not yet customized to help you more easily set up the data sync. We recommend, adding just enough information now to create the plug-in. Then edit the plug-in after its made to complete the process.
To start, fill in the following field:
Now click \"Add\" to save the plug-in and return you to the list of plug-ins. Now follow the instructions below.
With the plug-in place, click on its \"edit\" button to open its detailed settings page. Now fill out this configuration page as follows:
You need to fill out the following fields for the monday.com Data Sync plug-in:
Sync Mode: This option allows choosing between unidirectional or bidirectional syncing of items and/or artifacts between the systems. The valid values are shown below. Please enter the sync mode you want exactly as written. If this field is left blank, the sync will be bidirectional:
monday_to_spira - new and updated items in monday.com are sent to Spira. No data or updates go from Spira to monday.comspira_to_monday - new and updated tasks and incidents in Spira are sent to monday.com. No data or updates go from monday.com to Spirabidirectional - new and updated items/artifacts go from monday.com to Spira, and from Spira to monday.comArtifact\u00a0Sync Mode: Use this field to set which artifacts and items get synced between the two systems. The valid values are shown below. By choosing \"tasks_only\", for example, you can limit the sync to just Tasks. If this field is blank, the data sync will look for changes in both artifacts.
Sync subitems?: Ignore this setting if you are using the spira_to_monday sync mode. Otherwise, if you want the monday.com subitems to be synced to Spira, please enter yes to this field. If you want the datasync to skip monday.com subitems, enter no. You can learn more about this below.
Once all those fields have been filled out, click the \"Save\" button to save your changes.
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-Monday/#configuring-project-mappings","title":"Configuring Project Mappings","text":"For this step, please ensure that you are in the Spira project you would like to sync with monday.com. For this example, the project is called \"Monday.com DS Team Management\".
Click on the \"View Project Mappings\" button for monday.com Data Sync. You need to fill out the following fields to sync correctly:
Workspace||Task Board,,Incident Board. Please enter your monday.com Workspace name followed by two pipe characters (||), then the monday.com board name you want to sync with Tasks in Spira followed by two commas (,,), and finally the monday.com board name you want to sync with Incidents in Spira. Please note that all the pipes and commas are always required. If you don't want to sync Incidents for example, your external key should be something such as myWorkspace||,,MyIncidentBoard. Make sure to enter the exact name of the workspace and board(s) on the product external key, otherwise the data may be synced to the wrong workspace and board(s).Use this as a reference to find the necessary names in monday.com:
The monday.com plugin can synchronize Incidents and Tasks, so you will need to set up the status mappings for these artifacts, accordingly to the Artifact Sync Mode you chose. We shall discuss each in turn.
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-Monday/#incident-status-mapping","title":"Incident Status Mapping","text":"Now click the \"Status\" button within the \"Incident\" section to map the incident statuses together. The purpose of this is so that the monday.com Data Sync plug-in knows what the equivalent status is in monday.com for an incident status in Spira. Please make sure this is called Status in monday.com.
You must map every status in the system. Descriptions of the field are below:
Select the \"Priority\" button within the \"Incident\" section to map the incident priorities together. The purpose of this is so that the monday.com Data Sync plug-in knows what the equivalent priority is in monday.com for an incident priority in Spira. Please make sure this is called Priority in monday.com.
You must map every priority in the system. Descriptions of the field are below:
Select the \"Type\" button within the \"Incident\" section to map the incident types together. The purpose of this is so that the monday.com Data Sync plug-in knows what the equivalent type is in monday.com for an incident type in Spira. Please make sure this is called Type in monday.com.
You must map every Type in the system. Descriptions of the field are below:
Now click the \"Severity\" button within the \"Incident\" section to map the incident severities together. Use the same logic as described in the Incident Priority Mapping section.
Click the \"Status\" button within the \"Task\" section to map the task statuses together. Use the same logic as described in the Incident Status Mapping section.
Click the \"Priority\" button within the \"Task\" section to map the task priorities together. Use the same logic as described in the Incident Priority Mapping section.
Click the \"Type\" button within the \"Task\" section to map the task types together. Use the same logic as described in the Incident Type Mapping section.
If you have set the \"Auto-Map Users\" option in the *monday.com plugin, you can skip this section completely.*
To configure the mapping of users in the two systems, you need to go to Administration > Users > View Edit Users, which will bring up the list of users in the system. Then click on the \"Edit\" button for a particular user that will be editing items in monday.com:
Click on the 'Data Mapping' tab to list all the configured data-synchronization plug-ins for this user. In the text box next to the Monday.com Data-Sync plug-in you need to enter the display name for this user in monday.com. This will allow the data-synchronization plug-in to know which user in Spira match which equivalent user in monday.com. Click Save once you've entered the appropriate login name. You should now repeat for the other users who will be active in both systems.
The flexibility of monday.com means some assumptions were made in the design of this data sync. Specific column names are mapped to their counterparts in SpiraPlan based on the list below. If a field is not present in monday.com, it will not be synced.
Spira Field monday.com Field Name monday.com Field Type Incident Description Description Text Incident Priority Priority Single Dropdown (Status) Incident Severity Severity Single Dropdown (Status) Incident Type Type Single Dropdown (Status) Incident Status Status Single Dropdown (Status) Incident Start Date Start Date Date Incident End Date End Date Date Incident Detected By Creator People Incident Owner Owner People Task Description Description Text Task Priority Priority Single Dropdown (Status) Task Type Type Single Dropdown (Status) Task Status Status Single Dropdown (Status) Task Start Date Start Date Date Task End Date End Date Date Task Creator Creator People Task Owner Owner PeopleIt's also possible to sync the monday.com item Group to a Spira custom property for Incidents and/or Tasks. To do that, in Spira:
Additionally, please make sure that the board(s)/workspace names provided as an External Key for a Spira Product are unique in the monday.com workspace/system, otherwise, the data may be synced to/from the wrong board/workspace.
Due to the nature of text fields in monday.com (only plain text is supported), descriptions will only be synced from Monday to Spira on creation and from Spira to Monday all the time.
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-Monday/#mondaycom-sub-items","title":"monday.com sub-items","text":"monday.com allows users to create sub-items for any item in the boards. By default, the data sync will sync these subitems in Spira. They will have their parent linked under the 'Associations' tab in Spira. To turn off the subitems sync feature, change the Sync subitems? property of the data sync to no. It's not possible to create subitems in monday.com from Spira.
Once everything has been setup correctly the plug-in should start working. If you are using Spira on-premise, start your Data Sync service and you can now start synchronizing incidents and/or tasks.
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-Monday/#synchronizing-spira-incidents","title":"Synchronizing Spira Incidents","text":"If you selected both or incidents_only as your Artifact\u00a0Sync Mode, and spira_to_monday or bidirectional as the Sync Mode, when you log a new incident in Spira, it will appear in monday.com as a new item of your Incidents Board:
If you selected monday_to_spira or bidirectional as the Sync Mode, when you add a new item in your monday.com Incidents Board, it will appear in Spira as a new Incident.
If you selected both or tasks_only as your Artifact\u00a0Sync Mode, and spira_to_monday or bidirectional as the Sync Mode, when you create a new task in Spira, it will appear in monday.com as a new item of your Tasks Board:
If you selected monday_to_spira or bidirectional as the Sync Mode, when you add a new item in your monday.com Tasks Board, it will appear in Spira as a new Task.
Congratulations, you have just integrated your Spira instance with the monday.com project managing system.
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-OnTime-11/","title":"Using Spira with OnTime 11","text":"This section outlines how to use SpiraTest, SpiraPlan or SpiraTeam (hereafter referred to as SpiraTeam) in conjunction with the OnTime 11+ defect tracking system from AxoSoft. The built-in integration service allows the quality assurance team to manage their requirements and test cases in SpiraTeam, execute test runs in SpiraTest, and then have the new incidents generated during the run be automatically loaded into OnTime.
Once the incidents are loaded into OnTime as defects, the development team can then manage the lifecycle of these defects in OnTime, and have the status changes in OnTime be reflected back in SpiraTeam.
Note: This section refers to integrating with the older SOAP API that was available in AxoSoft OnTime 11 (2010). This API was removed from AxoSoft OnTime in 2012 and we recommend you use the AxoSoft OnTime 14 Plugin instead that is described in section 10 above if you are using OnTime 14 or later.
\u25ba Note: The OnTime11 Plug-In is Not Available on the Inflectra Cloud-Based DataSync Service.
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-OnTime-11/#configuring-the-integration-service","title":"Configuring the Integration Service","text":"This section outlines how to configure the integration service to export incidents into OnTime and pick up subsequent status changes in OnTime and have them update SpiraTeam. It assumes that you already have a working installation of SpiraTest, SpiraPlan or SpiraTeam v2.3 or later and a working installation of OnTime 2010 or later. If you have an earlier version of SpiraTeam, you will need to upgrade to at least v2.3 before trying to integrate with OnTime.
The steps that need to be performed to configure integration with OnTime are as follows:
Install and configure the OnTime SDK if you have not already done so
Download the OnTime11 Data-Sync plug-in for SpiraTeam from our website
Setup the plug-in in SpiraTeam to point to the correct instance of OnTime
Configure the data field mappings between SpiraTeam and OnTime
Start the service and verify data transfer
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-OnTime-11/#install-and-configure-the-ontime-sdk","title":"Install and Configure the OnTime SDK","text":"The API for accessing OnTime remotely is a separate download from the main OnTime application, and should be downloaded and installed from AxoSoft's website onto your OnTime server. It typically adds a separate IIS virtual directory (e.g. http://servername/OnTimeSdk) to the existing OnTime virtual directory (e.g. http://servername/OnTime). Please make sure you have both virtual directories listed in IIS before continuing.
Once you have installed the OnTime SDK, you need to navigate to the location that it was installed (typically C:\\inetpub\\wwwroot\\OnTimeSdk) and open up the Web.Config file in Notepad and locate the \"appSettings\" part of the file:
<appSettings> <add key=\"ConnectionString\" value=\"server=SERVER;database=OnTime;uid=USER;pwd=PASSWORD;\"/>\n<add key=\"SecurityToken\" value=\"{66ACD352-16C0-4485-8498-8C461BE7CE44}\"/> <add key=\"WebServicesUser\" value=\"1\"/> <add key=\"EnableDataCache\" value=\"False\"/> </appSettings>\nYou need to make sure that you fill out the ConnectionString that points to the Microsoft SQL Server database that OnTime is connecting to. Also for the SecurityToken field you need to generate a new GUID and add it to the file. This security token will be used by SpiraTeam when it connects to the OnTime API. Once you have made the necessary changes, save the file.
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-OnTime-11/#download-the-ontime-plug-in","title":"Download the OnTime Plug-In","text":"Go to the Inflectra website and open up the page that lists the various downloads available for SpiraTeam (http://www.inflectra.com/SpiraTeam/Downloads.aspx). Listed on this page will be the OnTime11 Plug-In for SpiraTeam. Right-click on this link and save the Zip compressed folder to the hard-drive of the server where SpiraTeam is installed.
Open up the compressed folder and extract the OnTimeDataSync.dll file and place it in the C:\\Program Files\\SpiraTeam\\Bin folder (it may be SpiraTest or SpiraPlan depending on which product you're running). This folder should already contain the DataSyncService.exe and DataSyncService.exe.config files that are the primary files used for managing the data synchronization between SpiraTeam and other systems.
If you do not have an on-premise installation of SpiraTeam, but instead are using a hosted subscription provided by Inflectra (or a third party company) you will not have access to the DataSyncService background service. In such situations, you should use the Desktop DataSync application instead. This application is described in Appendix 1 and can be used instead of the server-based DataSyncService.
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-OnTime-11/#configuring-the-service","title":"Configuring the Service","text":"To configure the integration service, please open up the DataSyncService.exe.config file located in C:\\Program Files\\SpiraTeam\\Bin with a text editor such as Notepad. Once open, it should look like:
<configuration>\n<configSections>\n<sectionGroup name=\"applicationSettings\" type=\"System.Configuration.ApplicationSettingsGroup, System,\nVersion=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089\">\n<section name=\"Inflectra.SpiraTest.DataSyncService.Properties.Settings\" type=\"System.Configuration.ClientSettingsSection, System,\nVersion=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089\" requirePermission=\"false\" />\n</sectionGroup>\n</configSections>\n<applicationSettings>\n<Inflectra.SpiraTest.DataSyncService.Properties.Settings>\n<setting name=\"PollingInterval\" serializeAs=\"String\">\n<value>600000</value>\n</setting>\n<setting name=\"WebServiceUrl\" serializeAs=\"String\">\n<value>http://localhost/SpiraTeam</value>\n</setting>\n<setting name=\"Login\" serializeAs=\"String\">\n<value>fredbloggs</value>\n</setting>\n<setting name=\"Password\" serializeAs=\"String\">\n<value>fredbloggs</value>\n</setting>\n<setting name=\"EventLogSource\" serializeAs=\"String\">\n<value>SpiraTeam Data Sync Service</value>\n</setting>\n<setting name=\"TraceLogging\" serializeAs=\"String\">\n<value>False</value>\n</setting>\n</Inflectra.SpiraTest.DataSyncService.Properties.Settings>\n</applicationSettings>\n</configuration>\nThe sections that need to be verified and possibly changed are marked in yellow above. You need to check the following information:
The polling interval allows you to specify how frequently the data-synchronization service will ask SpiraTeam and the external system for new data updates. The value is specified in milliseconds and we recommend a value no smaller than 5 minutes (i.e. 300,000ms). The larger the number, the longer it will take for data to be synchronized, but the lower the network and server overhead.
The base URL to your instance SpiraTeam. It is typically of the form http://<server name>/SpiraTeam. Make sure that when you enter this URL on a browser on the server itself, the application login page appears.
A valid login name and password to your instance of SpiraTeam. This user needs to be a member of the project(s) that will be synchronized with OnTime and needs to have at least Incident create/modify/view permissions and Release create/modify/view permissions in these projects.
Once you have made these changes, save the file and proceed to the next stage.
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-OnTime-11/#configuring-the-plug-in","title":"Configuring the Plug-In","text":"The next step is to configure the plug-in within SpiraTeam so that the system knows how to access the OnTime server. To start the configuration, please open up SpiraTeam in a web browser, log in using a valid account that has System-Administration level privileges and click on the System > Data Synchronization administration option from the left-hand navigation:
This screen lists all the plug-ins already configured in the system. Depending on whether you chose the option to include sample data in your installation or not, you will see either an empty screen or a list of sample data-synchronization plug-ins.
If you already see an entry for OnTimeDataSync you should click on its \"Edit\" link. If you don't see such an entry in the list, please click on the [Add] button instead. In either case you will be taken to the following screen where you can enter or modify the OnTime Data-Synchronization plug-in:
You need to fill out the following fields for the OnTime Plug-in to operate correctly:
Name -- this needs to be set to OnTimeDataSync. This needs to match the name of the plug-in DLL assembly that was copied into the C:\\Program Files\\SpiraTeam\\Bin folder (minus the .dll file extension). If you renamed the OnTimeDataSync.dll file for any reason, then you need to change the name here to match.
Description -- this should be set to a description of the plug-in. This is an optional field that is used for documentation purposes and is not actually used by the system.
Connection Info -- this should the full URL to the OnTime SDK. This is typically something like: http://<OnTime server name>/OnTimeSdk. You may need to check in the IIS Management Console of the OnTime server to verify the virtual directory name.
Login -- this should be set to the GUID that you specified in the Web.Config file in step 13.1.1 above.
Password -- this should be left blank as it's not used by the OnTime data-sync plug-in.
Time Offset -- normally this should be set to zero, but if you find that defects being changed in OnTime are not being updated in SpiraTeam, try increasing the value as this will tell the data-synchronization plug-in to add on the time offset (in hours) when comparing date-time stamps. Also if your OnTime installation is running on a server set to a different time-zone, then you should add in the number of hours difference between the servers' time-zones here.
Auto-Map Users -- this is not currently used by the OnTime data-sync plug-in and can be ignored.
Custom 01 -- 05 -- these are not currently used by the OnTime data-sync plug-in and can be left blank.
Next, you need to configure the data mapping between SpiraTeam and OnTime. This allows the various projects, users, releases, incident statuses, priorities, severities and custom property values used in the two applications to be related to each other. This is important, as without a correct mapping, there is no way for the integration service to know that an \"Open\" incident in SpiraTeam is the same as an \"Open\" defect in OnTime (for example).
The following mapping information needs to be setup in SpiraTeam:
The mapping of the project identifiers for the projects that need to be synchronized
The mapping of users in the system
The mapping of releases in the system
The mapping of the various standard fields in the system
The mapping of the various custom properties in the system
Each of these is explained in turn below:
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-OnTime-11/#configuring-the-project-mapping","title":"Configuring the Project Mapping","text":"From the data synchronization administration page, you need to click on the \"View Project Mappings\" hyperlink next to the OnTime plug-in name. This will take you to the data-mapping home page for the currently selected project:
If the project name does not match the name of the project you want to configure the data-mapping for, click on the \"(Change Project)\" hyperlink to change the current project.
To enable this project for data-synchronization with OnTime, you need to enter:
External Key -- This should be set to the numeric ID of the project token in OnTime. You can find this in OnTime by selecting the project in the project explorer inside OnTime and then clicking the Edit icon. This brings up the project details screen:
The ID of the project is the value listed in the browser URL directly after the \"ProjectId=\" text. In the example above, the project ID would be 3.
Active Flag -- Set this to 'Yes' so that SpiraTeam knows that you want to synchronize data for this project. Once the project has been completed, setting the value to \"No\" will stop data synchronization, reducing network utilization.
Click [Update] to confirm these settings. Once you have enabled the project for data-synchronization, you can now enter the other data mapping values outlined below.
Note: Once you have successfully configured the project, when creating a new project, you should choose the option to \"Create Project from Existing Project\" rather than \"Use Default Template\" so that all the project mappings get copied across to the new project.
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-OnTime-11/#configuring-the-user-mapping","title":"Configuring the User Mapping","text":"To configure the mapping of users in the two systems, you need to go to Administration > Users > View Edit Users, which will bring up the list of users in the system. Then click on the \"Edit\" button for a particular user that will be editing defects in OnTime:
You will notice that below the Active flag for the user is a list of all the configured data-synchronization plug-ins. In the text box next to the OnTime Data-Sync plug-in you need to enter the Login ID for this username in OnTime. This will allow the data-synchronization plug-in to know which user in SpiraTeam match which equivalent user in OnTime. Click [Update] once you've entered the appropriate login name. You should now repeat for the other users who will be active in both systems.
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-OnTime-11/#configuring-the-release-mapping","title":"Configuring the Release Mapping","text":"When the data-synchronization service runs, when it comes across a release/iteration in SpiraTeam that it has not seen before, it will create a corresponding Release in OnTime. Similarly if it comes across a new Release in OnTime that it has not seen before, it will create a new Release in SpiraTeam. Therefore when using both systems together, it is recommended that you only enter new Releases in one system and let the data-synchronization service add them to the other system.
However you may start out with the situation where you already have pre-existing Releases in both systems that you need to associate in the data-mapping. If you don't do this, you may find that duplicates get created when you first enable the data-synchronization service. Therefore for any Releases/Iterations that already exist in BOTH systems please navigate to Planning > Releases and click on the Release/Iteration in question. Make sure you have the 'Overview' tab visible and expand the \"Details\" section of the release/iteration:
In addition to the standard fields and custom properties configured for Releases, you will see an additional text property called \"OnTimeDataSync ID\" that is used to store the mapped external identifier for the equivalent Version in OnTime. You need to locate the ID of the equivalent version in OnTime, enter it into this text-box and click [Save]. You should now repeat for all the other pre-existing releases.
Note: The OnTime ID can be found by looking at the URL inside OnTime when choosing to Edit the release in question. The URL will include the section: ReleaseId=X where X is the numeric ID of the version inside OnTime:
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-OnTime-11/#configuring-the-standard-field-mapping","title":"Configuring the Standard Field Mapping","text":"Now that the projects, user and releases have been mapped correctly, we need to configure the standard incident fields. To do this, go to Administration > System > Data Synchronization and click on the \"View Project Mappings\" for the OnTimeDataSync plug-in entry:
From this screen, you need to click on Priority, Severity and Status in turn to configure their values (OnTime doesn't support different defect types):
a) Incident Status
Click on the \"Status\" hyperlink under Incident Standard Fields to bring up the Incident status mapping configuration screen:
The table lists each of the incident statuses available in SpiraTeam and provides you with the ability to enter the matching OnTime defect status names for each one. You can map multiple SpiraTeam fields to the same OnTime fields (e.g. New and Open in SpiraTeam are both equivalent to Open in OnTime), in which case only one of the two values can be listed as Primary = Yes as that's the value that's used on the reverse synchronization (from OnTime > SpiraTeam).
We recommend that you always point the New and Open statuses inside SpiraTeam to point to the \"Open\" status inside OnTime and make Open in SpiraTeam the Primary status of the two. This is recommended so that as new incidents in SpiraTeam get synched over to OnTime, they will get switched to the Open status in OnTime which will then be synched back to \"Open\" in SpiraTeam. That way you'll be able to see at a glance which incidents have been synched with OnTime and those that haven't.
Note: The OnTime external key needs to exactly match the display name of the status inside OnTime. If you change the name of a status in OnTime, you'll need to update the value in the data-mapping configuration as well.
b) Incident Priority
Click on the \"Priority\" hyperlink under Incident Standard Fields to bring up the Incident Priority mapping configuration screen:
The table lists each of the incident priorities available in SpiraTeam and provides you with the ability to enter the matching OnTime priority name for each one. You can map multiple SpiraTeam fields to the same OnTime fields, in which case only one of the two values can be listed as Primary = Yes as that's the value that's used on the reverse synchronization (from OnTime > SpiraTeam).
Note: The OnTime external key needs to exactly match the display name of the priority inside OnTime. If you change the name of a priority in OnTime, you'll need to update the value in the data-mapping configuration as well.
c) Incident Severity
Click on the \"Severity\" hyperlink under Incident Standard Fields to bring up the Incident severity mapping configuration screen:
The table lists each of the incident severities available in SpiraTeam and provides you with the ability to enter the matching OnTime severity name for each one. You can map multiple SpiraTeam fields to the same OnTime fields, in which case only one of the two values can be listed as Primary = Yes as that's the value that's used on the reverse synchronization (from OnTime > SpiraTeam).
Note: The OnTime external key needs to exactly match the display name of the severity inside OnTime. If you change the name of a severity in OnTime, you'll need to update the value in the data-mapping configuration as well.
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-OnTime-11/#configuring-the-custom-property-mapping","title":"Configuring the Custom Property Mapping","text":"Now that the various SpiraTeam standard fields have been mapped correctly, we need to configure the custom property mappings. This is used for both custom properties in SpiraTeam that map to custom fields in OnTime and also for custom properties in SpiraTeam that are used to map to standard fields in OnTime (currently only Replication Procedures) that don't exist in SpiraTeam.
From the View/Edit Project Data Mapping screen, you need to click on the name of the Incident Custom Property that you want to add data-mapping information for. We will consider the three different types of mapping that you might want to enter:
a) Text Custom Properties
Click on the hyperlink of the text custom property under Incident Custom Properties to bring up the custom property mapping configuration screen. For text custom properties there will be no values listed in the lower half of the screen.
You need to lookup the display name of the custom field in OnTime that matches this custom property in SpiraTeam. Once you have entered the id of the custom field, click [Update].
b) List Custom Properties
Click on the hyperlink of the list custom property under Incident Custom Properties to bring up the custom property mapping configuration screen. For list custom properties there will be a textbox for both the custom field itself and a mapping table for each of the custom property values that need to be mapped:
First you need to lookup the display name of the custom field in OnTime that matches this custom property in SpiraTeam. This should be entered in the 'External Key' field below the name of the custom property.
Next for each of the Property Values in the table (in the lower half of the page) you need to enter the full name of the custom field value as specified in OnTime.
c) OnTime's Replication Procedures Field
If you want new defects in OnTime to be loaded with the \"replication prodcedures\" standard text field populated, then you will need to fill out this section. You first need to create an incident custom property in SpiraTeam of type 'TEXT' that will be used to store the environment description within SpiraTeam.
Then click on the hyperlink of this new list custom property under Incident Custom Properties to bring up the custom property mapping configuration screen:
All you need to do on this screen is enter the word \"ReplicationProcedures\" in the External Key textbox and the data-sync plug-in will know that this custom property is mapped to the built-in Replication Procedures field in OnTime. Note that there is no space between the words Replication and Procedures!!
Once you have updated the various mapping sections, you are now ready to start the service.
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-OnTime-11/#enabling-the-data-synchronization","title":"Enabling the Data-Synchronization","text":""},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-OnTime-11/#starting-the-service","title":"Starting the Service","text":"When SpiraTeam is installed, a Windows Service -- SpiraTeam Data Sync Service -- is installed along with the web application. However to avoid wasting system resources, this service is initially set to run manually. To ensure continued synchronization of SpiraTeam with OnTime, we recommend starting the service and setting its startup-type to Automatic.
To make these changes, open up the Windows Control Panel, click on the \"Administrative Tools\" link, and then choose the Services option. This will bring up the Windows Service control panel:
Click on the 'SpiraTeam Data Sync Service' entry and click on the link to start the service. Then right-click the service entry and choose the option to set the startup type to 'Automatic'. This will ensure that synchronization continues between SpiraTeam and OnTime after a reboot of the server.
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-OnTime-11/#using-spirateam-with-ontime","title":"Using SpiraTeam with OnTime","text":"Now that the integration service has been configured and the service started, initially any incidents created in SpiraTeam for the specified projects will be imported into OnTime.
At this point we recommend opening the Windows Event Viewer and choosing the Application Log. In this log any error messages raised by the SpiraTeam Data Sync Service will be displayed. If you see any error messages at this point, we recommend immediately stopping the SpiraTeam service and checking the various mapping entries. If you cannot see any defects with the mapping information, we recommend sending a copy of the event log message(s) to Inflectra customer services (support@inflectra.com) who will help you troubleshoot the problem.
To use SpiraTeam with OnTime on an ongoing basis, we recommend the following general processes be followed:
When running tests in SpiraTeam, defects found should be logged through the 'Add Incident' option as normal.
Once an incident has been created during the running of the test, it will now be populated across into OnTime as a defect. It will be populated with the information captured in SpiraTeam.
At this point, the incident should not be acted upon inside SpiraTeam, and all data changes to the defect should be made inside OnTime. To enforce this, you can modify the workflows set up in SpiraTeam so that the various fields are marked as inactive for all the incident statuses other than the \"New\" status. This will allow someone to submit an incident in SpiraTeam, but will prevent them making changes in conflict with OnTime after that point.
As the defect progresses through the OnTime workflow, changes to the status, priority, severity, and resolution will be updated automatically in SpiraTeam. In essence, SpiraTeam acts as a read-only viewer of these incidents.
You are now able to perform test coverage and incident reporting inside SpiraTeam using the test cases managed by SpiraTeam and the incidents managed on behalf of SpiraTeam inside OnTime.
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-Salesforce.com/","title":"Using Spira with Salesforce.com","text":"Salesforce objects are a highly customizable system that can be synced with SpiraTest, SpiraTeam or SpiraPlan (SpiraPlan from here on). This integration lets you carry out:
Set up data synchronization
STOP! Please make sure you have first read the instructions to set up the data sync before proceeding!
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-Salesforce.com/#configuring-salesforce","title":"Configuring Salesforce","text":"Before integrating with SpiraPlan, you need to properly configure Salesforce's Rest API service. To do this, create a dedicated \"Connected App\" in your Salesforce application, as described in these instructions.
Info
In the Salesforce Connected App, the property \u201cIP Relaxation\u201d MUST BE defined as \u201cRelax IP restrictions\u201d, otherwise there may be connection problems.
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-Salesforce.com/#configuring-the-integration-service","title":"Configuring the Integration Service","text":"This section outlines how to set up the integration service between Salesforce and SpiraPlan. It assumes you already have:
Inside SpiraPlan, go to the Administration page and navigate to Integration > Data Synchronization. Check if you see a plug-in called SalesforceDataSync as shown below:
What do if the plug-in is not there
If you don't see the plug-in in the list, click the \"\"Add\" button at the top of the page. This opens the generic Data Sync plug-in details page. This is not yet customized to help you more easily set up the data sync. We recommend, adding just enough information now to create the plug-in. Then edit the plug-in after its made to complete the process.
To start, fill in the following fields:
Now click \"Add\" to save the plug-in and return you to the list of plug-ins. Now follow the instructions below.
With the plug-in place, click on its \"edit\" button to open its detailed settings page.
Fill out this configuration page as follows:
The remaining two fields store information about the Salesforce objects to sync, and the field in each object that stores project information. These fields are used to sync only relevant items to the right Spira product. For instance, you have a field called \"Project\" and this can be set to either Project1 or Project2, depending on what specific Project that particular record is part of. In Spira you may sync records set to Project1 to ProductA and sync records set to Project2 to ProductB.
Enter the name of the object, then a comma, then the name of the project field of the object - if your object name or field name have spaces in them, you must replace them with a _. For example if you have the object \"My Requirement Object\", which uses a field called \"Project Name Field\" you must enter \"My_Requirement_Object,Project_Name_Field\". In other words:
Click the \"Save\" button.
NOTE: Leave any field called \"(Not Used)\" blank.
Important gotchas to be aware of
We assume you have not changed the default API names automatically generated by Salesforce to Objects and Fields. If you have customized these names, you must use these customized names instead. You can check the API names of objects and fields in Salesforce, by going to Setup > Object Manager > [Your Object] > Details and Fields & Relationships.
If your Project Field in Salesforce is a pick-up list that points to another Salesforce object (called \"Reference type\" or \"Lookup type\"), you must add a text field containing the name of the specific value from that object (i.e. the actual project name) you are pointing to. You must use this in Spira's \"Incidents Object\" / \"Requirements Object\" fields for the data sync to work.
Salesforce automatically adds the \"__c\" characters after a custom object/field name. You should not add that yourself to the end of the object/field names.
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-Salesforce.com/#configuring-project-mappings","title":"Configuring Project Mappings","text":"Now that you have configured how the Salesforce data-sync works at the system level, you now need to configure the plug-in for each specific SpiraPlan product.
Click on the \"View Project Mappings\" dropdown for the Salesforce Data Sync. Select your product, then click the arrow to the right. This takes you to the Product Admin Salesforce Data Sync screen. You need to fill out the following fields before the plug-in is ready:
A brief note about field syncing in Salesforce: The sheer customizability of Salesforce necessarily means we have had to make some assumptions. Specific field names of objects are mapped to their counterparts in SpiraPlan based on the exact names (case sensitive) in the list below. Fields with these exact names will be synced over to SpiraPlan. Other fields (unless linked to a custom field in SpiraPlan) will not be synced.
Warning
Note: Do not forget to map the standard fields Priority, Importance, Severity, Type and Status in the \"Standard Field Data Mapping\" menu of the Data Sync configuration. Otherwise, they won't be synced.
Note 2: In case your Salesforce instance does not allow creating/updating the \"Name\" field of the record, the add-on will try to update/create the field \"Title\" instead. For that, make sure you have this field configured in your instance.
Note 3: If you would like to see the Spira Incident ID in your Salesforce instance, just add the \"SpiraPlanID__c\" field in your corresponding object in Salesforce.
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-Salesforce.com/#configuring-the-incidentrequirement-status-mappings","title":"Configuring the Incident/Requirement Status Mappings","text":"If you don't have a status equivalent in your table, you can ignore this section.
Click the \"Status\" button within the \"Incident\" section to map the Incident statuses from SalesForce to SpiraPlan. This tells the Salesforce Data Sync plug-in what the equivalent status is in Salesforce for an incident status in SpiraPlan.
If you are syncing Requirements, repeat this exact process for Requirement statuses, by clicking the Requirement > Status button.
You must map every status in SpiraPlan to Salesforce. Descriptions of the field are below:
If you don't have a priority equivalent in your Salesforce object, you can ignore this section.
Click the Priority button within the Incident section to map incident priorities. This will tell the Salesforce Data Sync plug-in which priorities in Salesforce map to those in SpiraPlan. The process is identical for Requirement importance, so repeat these steps with Requirement > Importance instead if you are also/only syncing requirements.
You must map every priority/importance in SpiraPlan to Salesforce. Descriptions of the field are below:
This section assumes the custom properties in SpiraPlan and Salesforce are of the same type (integer -> integer, text -> text, etc.). Custom property syncing will not work otherwise. This applies to both requirement and incident custom properties.
Click on a custom property mapping for a property you would like to sync. For the \"External Key\" put the exact Salesforce field name.
If your custom property is a single-select list, for each custom value, put in the \"Label\" of the option in Salesforce (the text you see in the Salesforce main application). An example of mapping a single-select list is below:
If you have a multi-select list in SpiraPlan repeat the same steps as for a single-select, except instead of putting the Salesforce \"Label\" in the external key, put the Salesforce \"Value\" instead. You should have something like this:
If, in Salesforce, you have list dropdown that links to another Salesforce object then the value you enter in SpiraPlan must be the string for the ID of the object, not the name. For example, if your dropdown says \"Release 1\" in Salesforce, and it has an ID of \"6fghincx8dx\", in SpiraPlan enter \"6fghincx8dx\" into the appropriate field.
Warning
Make sure the values provided for \"External Key\" meet the conditions required by Salesforce. For instance, \"false/true\" for boolean values, matching values for lists, etc. If the artifact synchronization fails because of that, you will see an error in the System log like this:
Error when creating/updating artifact: [{\\\"message\\\":\\\"GXP: bad value for BOOL field...\nIf you have set the \"Auto-Map Users\" option set to yes in the Salesforce plugin, please skip this section.
To configure the mapping of users in the two systems, you need to go to Administration > Users > View Edit Users, which will bring up the list of users in the system. Click on the [Edit] button for a particular user that will be editing records in Salesforce:
Click on the 'Data Mapping' tab to list all the configured data-synchronization plug-ins for this user. In the text box labeled \"Salesforce Data Sync ID,\" enter the first and last name of the user as set in Salesforce. This will allow the data-synchronization plug-in to know which user in SpiraPlan matches an equivalent user in Salesforce. Click [Save] once you've entered the appropriate login name.
Repeat for other users who will be active in both systems.
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-Salesforce.com/#attachments-synchronization","title":"Attachments synchronization","text":"If an object in Salesforce has the \"Notes & Attachments\" section, the data sync will sync all files to SpiraPlan and any attachments on SpiraPlan Incidents will sync to Salesforce. If a new version of a pre-existing file is uploaded in Salesforce, this will be uploaded as a new version to the matching SpiraPlan attachment (new versions of attachments to SpiraPlan Incidents will be uploaded as new versions in Salesforce). Finally, if an attachment is deleted from a record in Salesforce, the file will be removed from the equivalent artifact in SpiraPlan.
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-Salesforce.com/#comments-synchronization","title":"Comments synchronization","text":"If an object in Salesforce has the \"Feed Post & Comments component\" configured, the comments posted on it will be synced to SpiraPlan and vice-versa.
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-Salesforce.com/#using-the-data-synchronization","title":"Using the Data Synchronization","text":"Once the above steps have been correctly carried out, the plug-in should start working. Start your Data Sync service and verify that records in Salesforce appear inside SpiraPlan as either incidents or requirements in the relevant product(s). Note that the Data Sync service is not running constantly, so it may take some time for changes to materialize.
Congratulations, you have just integrated your SpiraPlan instance with Salesforce!
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-ServiceNow/","title":"Using Spira with ServiceNow","text":"ServiceNow tables are a highly customizable system that can be synced with SpiraTest, SpiraTeam or SpiraPlan (SpiraPlan from here on). This integration service enables two-way syncing of new incidents and requirements with any table in ServiceNow and syncing of updates from ServiceNow into SpiraPlan. Attachments will only be synced with creation.
Set up data synchronization
STOP! Please make sure you have first read the instructions to set up the data sync before proceeding!
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-ServiceNow/#configuring-the-integration-service","title":"Configuring the Integration Service","text":"This section outlines how to set up the integration service between ServiceNow and SpiraPlan. It assumes that you already have a working installation of SpiraPlan and appropriate ServiceNow tables. To setup the service, you must be logged into SpiraPlan as a user with System-Administrator level privileges.
Inside SpiraPlan, go to the Administration page and navigate to Integration > Data Synchronization. Check if you see a plug-in called ServiceNowDataSync, as shown below:
What do if the plug-in is not there
If you don't see the plug-in in the list, click the \"\"Add\" button at the top of the page. This opens the generic Data Sync plug-in details page. This is not yet customized to help you more easily set up the data sync. We recommend, adding just enough information now to create the plug-in. Then edit the plug-in after its made to complete the process.
To start, fill in the following fields:
Now click \"Add\" to save the plug-in and return you to the list of plug-ins. Now follow the instructions below.
With the plug-in place, click on its \"edit\" button to open its detailed settings page.
You need to fill out the following fields for the ServiceNow Data Sync plugin to work properly:
Click the \"Save\" button.
NOTE: Leave any field called \"(Not Used)\" blank.
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-ServiceNow/#configuring-project-mappings","title":"Configuring Project Mappings","text":"For this step, please ensure that you are in a SpiraPlan project you would like to sync with ServiceNow. For this example, the project is called \"ServiceNowDataSync Test.\"
Click on the \"View Project Mappings\" button for the ServiceNow Data Sync. You need to fill out the following fields to sync correctly:
The spira_product example above is a 'choice' type with the choices shown below:
Type in the 'Label' field of the choice, not the 'Value.'
A brief note about field syncing in ServiceNow: The sheer configurability of ServiceNow meant some assumptions were made in the designing of this data sync. Specific column names are mapped to their counterparts in SpiraPlan based on the list below. If a field is not present in ServiceNow, it will simply not be synced.
SpiraPlan Field ServiceNow Column Name name / short_description (both will work) Description description Priority / Importance priority Author / Detected By opened_by Owner assigned_to Status state Incident Severity severity Type type"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-ServiceNow/#configuring-the-incidentrequirement-status-mappings","title":"Configuring the Incident/Requirement Status Mappings","text":"Now click the \"Status\" button within the \"Incident\" section to map the Incident statuses together. The purpose of this is so that the ServiceNow Data Sync plug-in knows what the equivalent status is in ServiceNow for an incident status in SpiraPlan. The process is identical for Requirement statuses, so repeat these steps with Requirement > Status instead if you are also/only syncing requirements.
If you don't have a status equivalent in your table, you can ignore this section.
You must map every status in SpiraPlan to ServiceNow. Descriptions of the field are below:
Here are the corresponding statuses in ServiceNow
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-ServiceNow/#configuring-the-incidentrequirement-type-mappings","title":"Configuring the Incident/Requirement Type Mappings","text":"Click the \"Type\" button for the relevant artifact to map the Incident or Requirent types between SpiraPlan and ServiceNow together. The process is identical to the mappings described previously, so repeat these steps with Incident and Requirement Types if you are syncing them.
You must map every type in SpiraPlan to ServiceNow. Descriptions of the field are below:
Now click the \"Priority\" button within the \"Incident\" section to map incident priorities. This will tell the ServiceNow Data Sync plug-in which priorities in ServiceNow map to those in SpiraPlan. The process is identical for Requirement importance, so repeat these steps with Requirement > Importance instead if you are also/only syncing requirements.
If you don't have a priority equivalent in your table, you can ignore this section.
You must map every priority/importance in SpiraPlan to ServiceNow. Descriptions of the field are below:
Here are the corresponding priorities in ServiceNow:
You can use the same logic to configure Incident Severity mappings.
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-ServiceNow/#cloning-servicenow-fields","title":"Cloning ServiceNow Fields","text":"Due to some of the assumptions made in the creation of this integration, it is often necessary to create a hidden compatibility layer between the fields you use in your ServiceNow table and those recognized by the SpiraPlan data sync. This section will lay out how to create 'hidden' fields that will be kept in sync with those in SpiraPlan.
A brief discussion about the requirements for this to work
These steps will show how to store description in complete notes when Spira creates an artifact in ServiceNow
Add a Filter Condition such that the field you're cloning with the Spira field is empty:
Under Actions, where it says \"---choose field --\" set it to the field you would like to be populated [\"Complete Notes\" in this example]
These steps will show you how to store complete notes in description when the user updates complete notes
These steps will show you how to store complete notes in description when the user creates a new artifact in ServiceNow
Add a Filter Condition such that the Spira field is empty:
Under Actions, where it says \"---choose field---\" set it to the Spira field you would like to be synced [\"Description\" in this example]
This section assumes the custom properties in SpiraPlan and ServiceNow are of the same type (integer -> integer, SingleSelect -> SingleSelect, etc.) Custom property syncing will not work otherwise. This applies to both requirement and incident custom properties.
Click on a custom property mapping for a property you would like to sync. For the \"External Key\" right below the \"Name\" field put the column name (not the column label), so for the Operating System field in ServiceNow, you would put in \"operating_system\" No extra work is required for user (sys_user references in ServiceNow), text, integer, or date fields.
If your custom property is a single-select list (choice in ServiceNow), for each custom value, put in the \"Label\" (not Value) of the choice in ServiceNow. So your single-select should look similar:
If you have a multi-select in SpiraPlan (List in ServiceNow), repeat the same steps as for a single-select, except instead putting \"Label\" in the external key, put \"Value\" instead. You should have something like this:
For these ServiceNow choices:
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-ServiceNow/#configuring-the-user-mapping","title":"Configuring the User Mapping","text":"If you have set the \"Auto-Map Users\" option set to yes in the ServiceNow plugin, you can skip this section completely.
To configure the mapping of users in the two systems, you need to go to Administration > Users > View Edit Users, which will bring up the list of users in the system. Then click on the \"Edit\" button for a particular user that will be editing issues in ServiceNow:
Click on the 'Data Mapping' tab to list all the configured data-synchronization plug-ins for this user. In the text box labeled \"ServiceNow Data Sync ID,\" you need to enter the first and last name of the user in ServiceNow. This will allow the data-synchronization plug-in to know which user in SpiraPlan matches with an equivalent user in ServiceNow. Click [Save] once you've entered the appropriate login name. You should now repeat for the other users who will be active in both systems.
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-ServiceNow/#using-the-data-synchronization","title":"Using the Data Synchronization","text":"Assuming everything was done correctly, the plug-in should start working. Start your Data Sync service and verify that issues in ServiceNow appear inside SpiraPlan. Note that the Data Sync service is not running constantly, so it may take some time for changes to materialize.
Congratulations, you have just integrated your SpiraPlan instance with ServiceNow!
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-VersionOne/","title":"Using Spira with VersionOne","text":"This section outlines how to use SpiraTest, SpiraPlan or SpiraTeam (hereafter referred to as SpiraTeam) in conjunction with the Version One (V1) project management system from Collabnet (hereafter called V1).
The built-in integration service allows the quality assurance team to manage their requirements and test cases in SpiraTeam, execute test runs in SpiraTeam, and then have the new incidents generated during the run be automatically loaded into V1 as new defects. In addition, user stories in V1 will be automatically added into SpiraTeam as new requirements that you can write test plans for.
Once the incidents are loaded into V1 as defects, the development team can then manage the lifecycle of these defects in V1, and have the status changes in V1 be reflected back in SpiraTeam.
Set up data synchronization
STOP! Please make sure you have first read the instructions to set up the data sync before proceeding!
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-VersionOne/#configuring-the-plug-in","title":"Configuring the Plug-In","text":"This section outlines how to configure the integration service to connect to V1. It assumes that you already have a working installation of SpiraTeam v5.0 or later and an existing provisioned instance of V1. If you have an earlier version of SpiraTeam, you will need to upgrade to at least v5.0 before trying to integrate with V1.
The steps that need to be performed to configure integration with V1 are as follows:
Setup the plug-in in SpiraTeam to point to the correct instance of V1
Configure the data field mappings between SpiraTeam and V1
Start synchronization and verify data transfer
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-VersionOne/#configuring-the-plug-in_1","title":"Configuring the Plug-In","text":"The next step is to configure the plug-in within SpiraTeam so that the system knows how to access the V1 instance. To start the configuration, please open up SpiraTeam in a web browser, log in using a valid account that has System-Administration level privileges and click on the System > Data Synchronization administration option from the left-hand navigation:
This screen lists all the plug-ins already configured in the system. Depending on whether you chose the option to include sample data in your installation or not, you will see either an empty screen or a list of sample data-synchronization plug-ins.
If you already see an entry for VersionOneDataSync you should click on its \"Edit\" link. If you don't see such an entry in the list, please click on the [Add] button instead. In either case you will be taken to the following screen where you can enter or modify the V1 Data-Synchronization plug-in:
You need to fill out the following fields for the V1 Plug-in to operate correctly:
Name -- this needs to be set to VersionOneDataSync. This needs to match the name of the plug-in DLL assembly that was copied into the C:\\Program Files (x86)\\SpiraTeam\\Bin folder (minus the .dll file extension). If you renamed the OnTimeDataSync.dll file for any reason, then you need to change the name here to match.
Caption -- this is the display name of the V1 plugin and it can be meaningful name such as \"Version One\", \"V1\", or \"V1 Instance 1\".
Description -- this should be set to a description of the plug-in. This is an optional field that is used for documentation purposes and is not actually used by the system.
Connection Info -- this should the full URL to V1. This is typically something like: https://www1.v1host.com/CompanyName.
Login -- this should be set to the login that you use to access V1 through its web interface. If you are using a V1 Access Token instead of a login and password, please use \"accesstoken\" as the login instead.
Password -- this should be set to the password that you use to access V1 through its web interface or the API access token. If the latter, please make sure to use the login name \"accesstoken\".
Time Offset -- normally this should be set to zero, but if you find that defects being changed in V1 are not being updated in SpiraTeam, try increasing the value as this will tell the data-synchronization plug-in to add on the time offset (in hours) when comparing date-time stamps.
Auto-Map Users -- This changes the way that the plugin maps users in SpiraTeam to those in V1:
**Auto-Map = True **With this setting, all users in SpiraTeam need to have the same username as those in V1. If this is the case then you do not need to perform the user-mapping task outlined in section 12.2.2. This is a big time-saver if you can guarantee that all usernames are the same in both systems.
**Auto-Map = False **With this setting, users in SpiraTeam and V1are free to have different usernames because you specify the corresponding V1login for each user as outlined in Configuring the User Mapping.
Custom 01 -- this should be set to \"True\" if you want the plugin to log warnings about missing user mappings
Custom 02-05 -- these are not currently used by the V1 data-sync plug-in and can be left blank.
Next, you need to configure the data mapping between SpiraTeam and V1. This allows the various projects, users, releases, incident statuses, priorities, severities and custom property values used in the two applications to be related to each other. This is important, as without a correct mapping, there is no way for the integration service to know that an \"Open\" incident in SpiraTeam is the same as an \"Open\" defect in V1 (for example).
The following mapping information needs to be setup in SpiraTeam:
The mapping of the project identifiers for the projects that need to be synchronized
The mapping of users in the system
The mapping of releases in the system
The mapping of the various incident standard fields in the system
The mapping of the various requirement standard fields in the system
Each of these is explained in turn below:
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-VersionOne/#configuring-the-project-mapping","title":"Configuring the Project Mapping","text":"From the data synchronization administration page, you need to click on the \"View Project Mappings\" hyperlink next to the V1 plug-in name. This will take you to the data-mapping home page for the currently selected project:
If the project name does not match the name of the project you want to configure the data-mapping for, click on the \"(Change Project)\" hyperlink to change the current project.
To enable this project for data-synchronization with V1, you need to enter:
External Key -- This should be set to the name of the project in V1:
If you have sub-projects, you can map to one of those using the syntax: Project/SubProject
Active Flag -- Set this to 'Yes' so that SpiraTeam knows that you want to synchronize data for this project. Once the project has been completed, setting the value to \"No\" will stop data synchronization, reducing network utilization.
Click [Update] to confirm these settings. Once you have enabled the project for data-synchronization, you can now enter the other data mapping values outlined below.
Note: Once you have successfully configured the project, when creating a new project, you should choose the option to \"Create Project from Existing Project\" rather than \"Use Default Template\" so that all the project mappings get copied across to the new project.
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-VersionOne/#configuring-the-user-mapping","title":"Configuring the User Mapping","text":"(This section can be skipped if you enabled the 'AutoMap Users' option earlier).
To configure the mapping of users in the two systems, you need to go to Administration > Users > View Edit Users, which will bring up the list of users in the system. Then click on the \"Edit\" button for a particular user that will be editing defects in V1:
You will notice that in the Data Mapping tab for the user is a list of all the configured data-synchronization plug-ins. In the text box next to the V1 Data-Sync plug-in you need to enter the Login Name for this username in V1. This will allow the data-synchronization plug-in to know which user in SpiraTeam match which equivalent user in V1. Click [Update] once you've entered the appropriate login name. You should now repeat for the other users who will be active in both systems.
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-VersionOne/#configuring-the-releaseiteration-mapping","title":"Configuring the Release/Iteration Mapping","text":"When the data-synchronization service runs, when it comes across a new Release or Sprint/Timebox in V1 that it has not seen before, it will create a new Release or Iteration in SpiraTeam. Therefore, when using both systems together, it is recommended that you only enter new Releases in V1 and let the data-synchronization service add them to SpiraTeam.
To see this mapping, inside SpiraTeam, navigate to Planning > Releases and click on the Release/Iteration in question. Make sure you have the 'Overview' tab visible and expand the \"Details\" section of the release/iteration:
In addition to the standard fields and custom properties configured for Releases, you will see an additional text property called \"V1DataSync ID\" that is used to store the mapped external identifier for the equivalent Version in V1.
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-VersionOne/#configuring-the-incident-field-mapping","title":"Configuring the Incident Field Mapping","text":"Now that the projects, user and releases have been mapped correctly, we need to configure the standard incident fields. To do this, go to Administration > System > Data Synchronization and click on the \"View Project Mappings\" for the V1DataSync plug-in entry:
From this screen, you need to click on Status, Priority, Type in turn to configure their values (V1 doesn't support different defect severities):
a) Incident Status
Click on the \"Status\" hyperlink under Incident Standard Fields to bring up the Incident status mapping configuration screen:
The table lists each of the incident statuses available in SpiraTeam and provides you with the ability to enter the matching V1 defect status names for each one. You can map multiple SpiraTeam fields to the same V1 fields (e.g. New and Open in SpiraTeam are both equivalent to Future in V1), in which case only one of the two values can be listed as Primary = Yes as that's the value that's used on the reverse synchronization (from V1 > SpiraTeam).
We recommend that you always point the New and Open statuses inside SpiraTeam to point to the \"Future\" status inside V1 and make Open in SpiraTeam the Primary status of the two. This is recommended so that as new incidents in SpiraTeam get synched over to V1, they will get switched to the Future status in V1 which will then be synched back to \"Open\" in SpiraTeam. That way you'll be able to see at a glance which incidents have been synched with V1 and those that haven't.
Note: The V1 external key needs to exactly match the display name of the status inside V1. If you change the name of a status in V1, you'll need to update the value in the data-mapping configuration as well.
b) Incident Priority
Click on the \"Priority\" hyperlink under Incident Standard Fields to bring up the Incident Priority mapping configuration screen:
The table lists each of the incident priorities available in SpiraTeam and provides you with the ability to enter the matching V1 priority name for each one. You can map multiple SpiraTeam fields to the same V1 fields, in which case only one of the two values can be listed as Primary = Yes as that's the value that's used on the reverse synchronization (from V1 > SpiraTeam).
Note: The V1 external key needs to exactly match the display name of the priority inside V1. If you change the name of a priority in V1, you'll need to update the value in the data-mapping configuration as well.
c) Incident Type
Click on the \"Type\" hyperlink under Incident Standard Fields to bring up the Incident type mapping configuration screen:
The table lists each of the incident types available in SpiraTeam and provides you with the ability to enter the matching V1 defect type name for each one. You can map multiple SpiraTeam fields to the same V1 fields, in which case only one of the two values can be listed as Primary = Yes as that's the value that's used on the reverse synchronization (from V1 > SpiraTeam).
Note: The V1 external key needs to exactly match the display name of the defect type inside V1. If you change the name of a defect type in V1, you'll need to update the value in the data-mapping configuration as well.
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-VersionOne/#configuring-the-requirement-field-mapping","title":"Configuring the Requirement Field Mapping","text":"Next, we need to configure the standard requirement fields. To do this, go to Administration > System > Data Synchronization and click on the \"View Project Mappings\" for the V1DataSync plug-in entry:
From this screen, you need to click on Priority, Severity and Status in turn to configure their values (V1 doesn't support different defect types):
a) Requirement Status
Click on the \"Status\" hyperlink under Requirement Standard Fields to bring up the Requirement status mapping configuration screen:
The table lists each of the requirement statuses available in SpiraTeam and provides you with the ability to enter the matching V1 user story status names for each one. You can map multiple SpiraTeam fields to the same V1 fields (e.g. Requested and Planned in SpiraTeam are both equivalent to Future in V1), in which case only one of the two values can be listed as Primary = Yes as that's the value that's used on the reverse synchronization (from V1 > SpiraTeam).
Note: The V1 external key needs to exactly match the display name of the status inside V1. If you change the name of a status in V1, you'll need to update the value in the data-mapping configuration as well.
b) Requirement Importance
Click on the \"Importance\" hyperlink under Requirement Standard Fields to bring up the Requirement Importance mapping configuration screen:
The table lists each of the requirement importances available in SpiraTeam and provides you with the ability to enter the matching V1 user story priority name for each one. You can map multiple SpiraTeam fields to the same V1 fields, in which case only one of the two values can be listed as Primary = Yes as that's the value that's used on the reverse synchronization (from V1 > SpiraTeam).
Note: The V1 external key needs to exactly match the display name of the priority inside V1. If you change the name of a priority in V1, you'll need to update the value in the data-mapping configuration as well.
c) Requirement Type
Click on the \"Type\" hyperlink under Requirement Standard Fields to bring up the requirement type mapping configuration screen:
The table lists each of the requirement types available in SpiraTeam and provides you with the ability to enter the matching V1 user story type name for each one. You can map multiple SpiraTeam fields to the same V1 fields, in which case only one of the two values can be listed as Primary = Yes as that's the value that's used on the reverse synchronization (from V1 > SpiraTeam).
Note: The V1 external key needs to exactly match the display name of the user story type inside V1. If you change the name of a user story type in V1, you'll need to update the value in the data-mapping configuration as well.
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-VersionOne/#mapping-a-custom-property-to-the-v1-display-id","title":"Mapping a Custom Property to the V1 Display ID","text":"Version One has two unique IDs for all artifacts, a display ID (e.g. D-23232) and a physical ID (Defect:11291). Now the built in Data Sync ID in SpiraTeam will contain the physical ID of the V1 artifact.
However, if you also want to see the V1 display IDs in SpiraTeam, you can map a custom property to the special V1DisplayId external key. This can be done for requirements:
And for incidents:
Once you have updated the various mapping sections, you are now ready to use the service.
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-VersionOne/#using-spirateam-with-v1","title":"Using SpiraTeam with V1","text":"Now that the integration service has been configured and the service started, initially any incidents created in SpiraTeam for the specified projects will be imported into V1 and vice versa. In addition, any existing user stories in V1 will get added to SpiraTeam as requirements.
At this point we recommend opening the Windows Event Viewer and choosing the Application Log. In this log any error messages raised by the SpiraTeam Data Sync Service will be displayed. If you see any error messages at this point, we recommend immediately stopping the SpiraTeam service and checking the various mapping entries. If you cannot see any defects with the mapping information, we recommend sending a copy of the event log message(s) to Inflectra customer services (support@inflectra.com) who will help you troubleshoot the problem.
To use SpiraTeam with V1 on an ongoing basis, we recommend the following general processes be followed:
When running tests in SpiraTeam, defects found should be logged through the 'Add Incident' option as normal.
Developers can log new defects into either SpiraTeam or V1. In either case they will get loaded into the other system.
Once created in one of the systems and successfully replicated to the other system, the incident should not be modified again inside SpiraTeam
User stories created in V1 will get added to SpiraTeam as requirements. You can now write test cases and associate them in SpiraTeam with these requirements.
As the defect progresses through the V1 workflow, changes to the status, priority, severity, and resolution will be updated automatically in SpiraTeam. In essence, SpiraTeam acts as a read-only viewer of these incidents.
You are now able to perform test coverage and incident reporting inside SpiraTeam using the requirements and test cases managed by SpiraTeam and the incidents managed on behalf of SpiraTeam inside V1.
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-YouTrack/","title":"Using Spira with JetBrains' YouTrack","text":"This section outlines how to use SpiraTest, SpiraTeam, or SpiraPlan (hereafter referred to as SpiraPlan) with JetBrains' YouTrack (YouTrack).
YouTrack issues can now be synchronized with SpiraPlan. This integration service enables two-way syncing of SpiraPlan incidents and, if specified, tasks with YouTrack issues. Once set up, by default, all issues in a YouTrack project will sync to Incidents in SpiraPlan. You can specify certain types of issues to sync as Tasks in SpiraPlan instead if you want.
Set up data synchronization
STOP! Please make sure you have first read the instructions to set up the data sync before proceeding!
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-YouTrack/#configuring-youtrack","title":"Configuring YouTrack","text":"Before integrating with SpiraPlan, you need to configure YouTrack to allow Rest API connections. There are a few different ways to do this. However, we recommend using a permanent token for authentication requests. You can generate your own permanent tokens in your YouTrack user profile. For instructions, please refer to the YouTrack documentation.
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-YouTrack/#configuring-the-integration-service","title":"Configuring the Integration Service","text":"This section outlines how to set up the integration service between YouTrack and SpiraPlan. It assumes you already have:
To configure the integration, login to your SpiraPlan application as a system administrator. Go to System Administration > Integrations > Data Synchronization (from the admin menu). This shows a list of all available data sync plug-ins.
If you already have a plug-in called \"YouTrackDataSync\", click on its \"edit\" button, otherwise click the \"Add\" button to create a new plug-in:
Fill out this configuration page as follows:
YouTrackDataSyncYouTrack Privileges
Please make sure that the provided YouTrack userName/userToken has privileges to access projects and report, assign, modify, open and close YouTrack issues. Otherwise, the datasync is not going to work as expected.
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-YouTrack/#configuring-project-mappings","title":"Configuring Project Mappings","text":"Now that you have configured how the YouTrack data-sync works at the system level, you now need to configure the plug-in for each specific SpiraPlan product.
Click on the \"View Project Mappings\" dropdown for the YouTrack Data Sync. Select your product, then click the arrow to the right. This takes you to the Product Admin YouTrack Data Sync screen. You need to fill out the following fields before the plug-in is ready:
In the YouTrackDataSync Product Data Mapping of your SpiraPlan project, you can map the SpiraPlan standard fields for incidents and tasks to a specific field value in YouTrack. To do that, click on the stardard property under the artifact type menu you want to map:
For example, clicking on Task > Priority allows you to map each YouTrack issue priority to an equivalent in SpiraPlan:
For SpiraPlan Incidents and Tasks, you can map Priority, Status and Types.
Syncing Tasks
If you configured the data sync to import some YouTrack issues as Tasks in SpiraPlan, please make sure you match the Custom 02 fields with the Task types as described in this section.
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-YouTrack/#configuring-custom-properties","title":"Configuring Custom Properties","text":"If you have custom properties in your SpiraPlan project, you will need to map them to YouTrack. To do that, click on a custom property mapping for a property you would like to sync. For the \"External Key\" put the exact YouTrack field name. An example is provided below:
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-YouTrack/#attachments-synchronization","title":"Attachments synchronization","text":"The datasync will save as Tasks/Incidents attachments in SpiraPlan the files associated with an issue in YouTrack, as well as their files in comments.
"},{"location":"External-Bug-Tracking-Integration/Using-Spira-with-YouTrack/#using-the-data-synchronization","title":"Using the Data Synchronization","text":"Once the above steps have been correctly carried out, the plug-in should start working. Start your Data Sync service and verify that records in YouTrack appear inside SpiraPlan as either incidents or tasks (optional) in the relevant product(s). Note that the Data Sync service is not running constantly, so it may take some time for changes to materialize.
Congratulations, you have just integrated your SpiraPlan instance with YouTrack!
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-ClearQuest/","title":"Using SpiraTeam with ClearQuest","text":"This section outlines how to use SpiraTest, SpiraPlan or SpiraTeam (hereafter referred to as SpiraTeam) in conjunction with the ClearQuest defect tracking system. The built-in integration service allows the quality assurance team to manage their requirements and test cases in SpiraTeam, execute test runs in SpiraTest, and then have the new incidents generated during the run be automatically loaded into ClearQuest. Once the incidents are loaded into ClearQuest as defects, the development team can then manage the lifecycle of these defects in ClearQuest, and have the status changes in ClearQuest be reflected back in SpiraTeam. In addition, any issues logged directly into ClearQuest will get imported into SpiraTeam so that they can be linked to test cases and requirements.
\u25ba Note: The ClearQuest Plug-In is Not Available on the Inflectra Cloud-Based DataSync Service.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-ClearQuest/#configuring-the-integration-service","title":"Configuring the Integration Service","text":"This section outlines how to configure the integration service to export incidents into ClearQuest and pick up subsequent status changes in ClearQuest and have them be updated in SpiraTeam. It assumes that you already have a working installation of SpiraTest, SpiraPlan or SpiraTeam (v3.0 or higher) and a working installation of IBM Rational ClearQuest 7.0 or higher.
If you have an earlier version of SpiraTeam, you will need to upgrade to at least v3.0 before trying to integrate with ClearQuest.
The steps that need to be performed to configure integration with ClearQuest are as follows:
Download the latest ClearQuest Data-Sync plug-in for SpiraTeam from our website
Setup the plug-in in SpiraTeam to point to the correct instance of ClearQuest
Configure the data field mappings between SpiraTeam and ClearQuest
Start the service and verify data transfer
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-ClearQuest/#download-the-clearquest-plug-in","title":"Download the ClearQuest Plug-In","text":"Go to the Inflectra website and open up the page that lists the various downloads available for SpiraTeam (http://www.inflectra.com/SpiraTeam/Downloads.aspx). Listed on this page will be the ClearQuest Plug-In for SpiraTeam. Right-click on this link and save the Zip compressed folder to the hard-drive of the server where SpiraTeam is installed.
Open up the compressed folder and extract the ClearQuestDataSync.dll file and place it in the C:\\Program Files\\SpiraTeam\\Bin folder (it may be SpiraTest or SpiraPlan depending on which product you're running). This folder should already contain the DataSyncService.exe and DataSyncService.exe.config files that are the primary files used for managing the data synchronization between SpiraTeam and other systems.
You will then need to install the ClearQuest client application itself onto the SpiraTeam server. This is needed because the ClearQuest plugin communicates with the ClearQuest API which is part of the ClearQuest client installation. The SpiraTeam plugin will use a single ClearQuest user license when it connects to ClearQuest.
If you do not have an on-premise installation of SpiraTeam, but instead are using a hosted subscription provided by Inflectra (or a third party company) you will not have access to the DataSyncService background service. In such situations, you should use the Desktop DataSync application instead. This application is described in Appendix 1 and can be used instead of the server-based DataSyncService.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-ClearQuest/#configuring-the-service","title":"Configuring the Service","text":"To configure the integration service, please open up the DataSyncService.exe.config file located in C:\\Program Files\\SpiraTeam\\Bin with a text editor such as Notepad. Once open, it should look like:
<?xml version=\"1.0\" encoding=\"utf-8\"?>\n<configuration>\n<configSections>\n<sectionGroup name=\"applicationSettings\" type=\"System.Configuration.ApplicationSettingsGroup, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089\" >\n<section name=\"Inflectra.SpiraTest.DataSyncService.Properties.Settings\" type=\"System.Configuration.ClientSettingsSection, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089\" requirePermission=\"false\" />\n</sectionGroup>\n</configSections>\n<applicationSettings>\n<Inflectra.SpiraTest.DataSyncService.Properties.Settings>\n<setting name=\"PollingInterval\" serializeAs=\"String\">\n<value>600000</value>\n</setting>\n<setting name=\"WebServiceUrl\" serializeAs=\"String\">\n<value>http://localhost/SpiraTeam</value>\n</setting>\n<setting name=\"Login\" serializeAs=\"String\">\n<value>fredbloggs</value>\n</setting>\n<setting name=\"Password\" serializeAs=\"String\">\n<value>fredbloggs</value>\n</setting>\n<setting name=\"EventLogSource\" serializeAs=\"String\">\n<value>SpiraTeam Data Sync Service</value>\n</setting>\n<setting name=\"TraceLogging\" serializeAs=\"String\">\n<value>False</value>\n</setting>\n</Inflectra.SpiraTest.DataSyncService.Properties.Settings>\n</applicationSettings>\n</configuration>\nThe sections that need to be verified and possibly changed are marked in yellow above. You need to check the following information:
The polling interval allows you to specify how frequently the data-synchronization service will ask SpiraTeam and the external system for new data updates. The value is specified in milliseconds and we recommend a value no smaller than 5 minutes (i.e. 300,000ms). The larger the number, the longer it will take for data to be synchronized, but the lower the network and server overhead.
The base URL to your instance SpiraTeam. It is typically of the form http://<server name>/SpiraTeam. Make sure that when you enter this URL on a browser on the server itself, the application login page appears.
A valid login name and password to your instance of SpiraTeam. This user needs to be a member of the project(s) that will be synchronized with ClearQuest and needs to have at least Incident create/modify/view permissions and Release create/modify/view permissions in these projects.
Once you have made these changes, save the file and proceed to the next stage.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-ClearQuest/#configuring-the-plug-in","title":"Configuring the Plug-In","text":"The next step is to configure the plug-in within SpiraTeam so that the system knows how to access the ClearQuest server. To start the configuration, please open up SpiraTeam in a web browser, log in using a valid account that has System-Administration level privileges and click on the System > Data Synchronization administration option from the left-hand navigation:
This screen lists all the plug-ins already configured in the system. Depending on whether you chose the option to include sample data in your installation or not, you will see either an empty screen or a list of sample data-synchronization plug-ins.
If you already see an entry for ClearQuestDataSync you should click on its \"Edit\" link. If you don't see such an entry in the list, please click on the [Add] button instead. In either case you will be taken to the following screen where you can enter or modify the ClearQuest Data-Synchronization plug-in:
You need to fill out the following fields for the ClearQuest Plug-in to operate correctly:
Name -- this needs to be set to ClearQuestDataSync. This needs to match the name of the plug-in DLL assembly that was copied into the C:\\Program Files\\SpiraTeam\\Bin folder (minus the .dll file extension). If you renamed the ClearQuestDataSync.dll file for any reason, then you need to change the name here to match.
Description -- this should be set to a description of the plug-in. This is an optional field that is used for documentation purposes and is not actually used by the system.
Connection Info -- this should the name of the ClearQuest master database. In most installations this is simply called \"MASTR\".
Login -- this should be set to a valid login for your ClearQuest installation. The login needs to have permissions to create and view defects within ClearQuest.
Password -- this should be set to the password of the login specified above.
Time Offset -- normally this should be set to zero, but if you find that issues being changed in ClearQuest are not being updated in SpiraTeam, try increasing the value as this will tell the data-synchronization plug-in to add on the time offset (in hours) when comparing date-time stamps. Also if your ClearQuest installation is running on a server set to a different time-zone, then you should add in the number of hours difference between the servers' time-zones here.
Auto-Map Users -- this is not currently used and can be ignored.
Custom 01 -- This should be set to the word \"True\" if you want to have the plugin restrict synchronization to only loading new incidents from SpiraTeam > ClearQuest and updating existing items. This is useful if you want to prevent existing issues in ClearQuest from being loaded into SpiraTeam. Leave blank if you want the plugin to synchronize normally.
Custom 02 -- Sometimes you don't want all the incidents in SpiraTeam to be added to ClearQuest. You can optionally enter a filter definition in this box to restrict the incidents that get synchronized. The filter uses the following syntax:
[Property]=[Value|*]:[Property]=[Value|*]\\
For example, to limit the incidents to only have those where List01 = 5 and Text08 = \"Hello\" and Text05 is not blank you would use:
List01=5:Text08=Hello:Text05=*
Custom 03 -- ClearQuest doesn't have a built-in Detected in Release field. If you would like to map a custom ClearQuest field to the SpiraTeam Detected in Release, simply enter in the name of the ClearQuest field here.
Custom 04 -- ClearQuest doesn't have a built-in Resolved in Release field. If you would like to map a custom ClearQuest field to the SpiraTeam Resolved in Release, simply enter in the name of the ClearQuest field here.
Custom 05 -- This is the optional \"DBset\" value, when you have installations with more than one database set. If you have a single database set you can just leave this blank.
If you enter a field name in either Custom 03 or Custom 04, you will need to also map the various releases in SpiraTeam to their corresponding equivalent field value in ClearQuest. To do that, click on Planning > Releases and choose a specific release. Then in the \"ClearQuest DataSync ID\" field under the \"Custom Properties\" tab you need to enter the name of the equivalent ClearQuest release.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-ClearQuest/#configuring-the-data-mapping","title":"Configuring the Data Mapping","text":"Next, you need to configure the data mapping between SpiraTeam and ClearQuest. This allows the various projects, users, incident statuses, priorities, severities and custom property values used in the two applications to be related to each other. This is important, as without a correct mapping, there is no way for the integration service to know that a \"New\" item in SpiraTeam is equivalent to a \"Submitted\" item in ClearQuest (for example).
The following mapping information needs to be setup in SpiraTeam:
The mapping of the project identifiers for the projects that need to be synchronized
The mapping of users in the system
The mapping of the various standard fields in the system
The mapping of the various custom properties in the system
Each of these is explained in turn below:
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-ClearQuest/#configuring-the-project-mapping","title":"Configuring the Project Mapping","text":"From the data synchronization administration page, you need to click on the \"View Project Mappings\" hyperlink next to the ClearQuest plug-in name. This will take you to the data-mapping home page for the currently selected project:
If the project name does not match the name of the project you want to configure the data-mapping for, click on the \"(Change Project)\" hyperlink to change the current project.
To enable this project for data-synchronization with ClearQuest, you need to enter:
External Key -- This should be set to the name of the project database in ClearQuest that will be mapped to the specific SpiraTeam project.
Active Flag -- Set this to 'Yes' so that SpiraTeam knows that you want to synchronize data for this project. Once the project has been completed, setting the value to \"No\" will stop data synchronization, reducing network utilization.
Click [Update] to confirm these settings. Once you have enabled the project for data-synchronization, you can now enter the other data mapping values outlined below.
Note: Once you have successfully configured the project, when creating a new project, you should choose the option to \"Create Project from Existing Project\" rather than \"Use Default Template\" so that all the project mappings get copied across to the new project.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-ClearQuest/#configuring-the-user-mapping","title":"Configuring the User Mapping","text":"To configure the mapping of users in the two systems, you need to go to Administration > Users > View Edit Users, which will bring up the list of users in the system. Then click on the \"Edit\" button for a particular user that will be editing issues in ClearQuest:
You will notice that in the Data Mapping tab for the user, there is a list of all the configured data-synchronization plug-ins. In the text box next to the ClearQuest Data-Sync plug-in you need to enter the login for this username in ClearQuest. This will allow the data-synchronization plug-in to know which user in SpiraTeam match which equivalent user in ClearQuest. Click [Update] once you've entered the appropriate login name. You should now repeat for the other users who will be active in both systems.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-ClearQuest/#configuring-the-standard-field-mapping","title":"Configuring the Standard Field Mapping","text":"Now that the projects, user and releases have been mapped correctly, we need to configure the standard incident fields. To do this, go to Administration > System > Data Synchronization and click on the \"View Project Mappings\" for the ClearQuestDataSync plug-in entry:
From this screen, you need to click on Priority, Severity and Status in turn to configure their values:
a) Incident Status
Click on the \"Status\" hyperlink under Incident Standard Fields to bring up the Incident status mapping configuration screen:
The table lists each of the incident statuses available in SpiraTeam and provides you with the ability to enter the matching ClearQuest issue status name for each one. You can map multiple SpiraTeam fields to the same ClearQuest fields (e.g. Open and Reopen in SpiraTeam are both equivalent to Opened in ClearQuest), in which case only one of the two values can be listed as Primary = Yes as that's the value that's used on the reverse synchronization (from ClearQuest > SpiraTeam).
b) Incident Priority
Click on the \"Priority\" hyperlink under Incident Standard Fields to bring up the Incident Priority mapping configuration screen:
The table lists each of the incident priorities available in SpiraTeam and provides you with the ability to enter the matching ClearQuest priority name for each one. You can map multiple SpiraTeam fields to the same ClearQuest fields, in which case only one of the two values can be listed as Primary = Yes as that's the value that's used on the reverse synchronization (from ClearQuest > SpiraTeam).
c) Incident Severity
Click on the \"Severity\" hyperlink under Incident Standard Fields to bring up the Incident severity mapping configuration screen:
The table lists each of the incident severities available in SpiraTeam and provides you with the ability to enter the matching ClearQuest severity name for each one. You can map multiple SpiraTeam fields to the same ClearQuest fields, in which case only one of the two values can be listed as Primary = Yes as that's the value that's used on the reverse synchronization (from ClearQuest > SpiraTeam).
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-ClearQuest/#configuring-the-custom-property-mapping","title":"Configuring the Custom Property Mapping","text":"Now that the various SpiraTeam standard fields have been mapped correctly, we need to configure the custom property mappings. This is used for both custom properties in SpiraTeam that map to custom fields in ClearQuest and also for custom properties in SpiraTeam that are used to map to standard fields in ClearQuest (e.g. Project, Resolution) that don't exist in SpiraTeam.
From the View/Edit Project Data Mapping screen, you need to click on the name of the Incident Custom Property that you want to add data-mapping information for. We will consider the two different types of mapping that you might want to enter:
a) Text Custom Properties
Click on the hyperlink of the text custom property under Incident Custom Properties to bring up the custom property mapping configuration screen. For text custom properties there will be no values listed in the lower half of the screen.
You need to lookup the ID of the custom field in ClearQuest that matches this custom property in SpiraTeam. Once you have entered the id of the custom field, click [Update].
Note: The ID can be found by looking at the URL inside ClearQuest when choosing to View/Edit the Custom Field. The URL will include the section: id=X where X is the numeric ID of the Custom Field inside ClearQuest.
b) List Custom Properties
Click on the hyperlink of the list custom property under Incident Custom Properties to bring up the custom property mapping configuration screen. For list custom properties there will be a textbox for both the custom field itself and a mapping table for each of the custom property values that need to be mapped:
First you need to lookup the name of the field in ClearQuest that matches this custom property in SpiraTeam. This should be entered in the 'External Key' field below the name of the custom property. The easiest way to determine this is to use the ClearQuest Designer which lets you see all the fields associated with a ClearQuest defect:
Next for each of the Property Values in the table (in the lower half of the page) you need to enter the full name of the possible field values as displayed in the ClearQuest client application.
Once you have updated the various mapping sections, you are now ready to start the service.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-ClearQuest/#enabling-the-data-synchronization","title":"Enabling the Data-Synchronization","text":""},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-ClearQuest/#starting-the-service","title":"Starting the Service","text":"When SpiraTeam is installed, a Windows Service -- SpiraTeam Data Sync Service -- is installed along with the web application. However to avoid wasting system resources, this service is initially set to run manually. To ensure continued synchronization of SpiraTeam with ClearQuest, we recommend starting the service and setting its startup-type to Automatic.
To make these changes, open up the Windows Control Panel, click on the \"Administrative Tools\" link, and then choose the Services option. This will bring up the Windows Service control panel:
Click on the 'SpiraTeam Data Sync Service' entry and click on the link to start the service. Then right-click the service entry and choose the option to set the startup type to 'Automatic'. This will ensure that synchronization continues between SpiraTeam and ClearQuest after a reboot of the server.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-ClearQuest/#using-spirateam-with-clearquest_1","title":"Using SpiraTeam with ClearQuest","text":"Now that the integration service has been configured and the service started, initially any incidents created in SpiraTeam for the specified projects will be imported into ClearQuest and any existing defects in ClearQuest will get loaded into SpiraTeam
At this point we recommend opening the Windows Event Viewer and choosing the Application Log. In this log any error messages raised by the SpiraTeam Data Sync Service will be displayed. If you see any error messages at this point, we recommend immediately stopping the SpiraTeam service and checking the various mapping entries. If you cannot see any issues with the mapping information, we recommend sending a copy of the event log message(s) to Inflectra customer services (support@inflectra.com) who will help you troubleshoot the problem.
To use SpiraTeam with ClearQuest on an ongoing basis, we recommend the following general processes be followed:
When running tests in SpiraTest or SpiraTeam, defects found should be logged through the Test Execution Wizard as normal.
Developers using ClearQuest can log new defects into either SpiraTeam or ClearQuest. In either case they will get loaded into the other system.
Once created in one of the systems and successfully replicated to the other system, the incident should not be modified again inside SpiraTeam
At this point, the incident should not be acted upon inside SpiraTeam and all data changes to the issue should be made inside ClearQuest. To enforce this, you should modify the workflows set up in SpiraTeam so that the various fields are marked as inactive for all the incident statuses other than the \"New\" status. This will allow someone to submit an incident in SpiraTeam, but will prevent them making changes in conflict with ClearQuest after that point.
As the issue progresses through the customized ClearQuest workflow, changes to the type of issue, changes to its status, priority, description and resolution will be updated automatically in SpiraTeam. In essence, SpiraTeam acts as a read-only viewer of these incidents.
You are now able to perform test coverage and incident reporting inside SpiraTest/SpiraTeam using the test cases managed by SpiraTest/SpiraTeam and the incidents managed on behalf of SpiraTest/SpiraTeam inside ClearQuest.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-IBM-RTC/","title":"Using SpiraTeam with IBM RTC","text":"This section outlines how to use SpiraTest, SpiraPlan or SpiraTeam (hereafter referred to as SpiraTeam) in conjunction with the IBM Rational Team Concert (hereafter referred to as RTC) work item tracking system. The built-in integration service allows the quality assurance team to manage their requirements and test cases in SpiraTeam, execute test runs in SpiraTest, and then have the new incidents generated during the run be automatically loaded into RTC.
Once the incidents are loaded into RTC as work items, the development team can then manage the lifecycle of these work items in RTC, and have the status changes in RTC be reflected back in SpiraTeam. In addition, any issues logged directly into RTC will get imported into SpiraTeam so that they can be linked to test cases and requirements.
Set up data synchronization
STOP! Please make sure you have first read the instructions to set up the data sync before proceeding!
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-IBM-RTC/#configuring-the-plug-in","title":"Configuring the Plug-In","text":"The next step is to configure the plug-in within SpiraTeam so that the system knows how to access the RTC server. To start the configuration, please open up SpiraTeam in a web browser, log in using a valid account that has System-Administration level privileges and click on the System > Data Synchronization administration option from the left-hand navigation:
This screen lists all the plug-ins already configured in the system. Depending on whether you chose the option to include sample data in your installation or not, you will see either an empty screen or a list of sample data-synchronization plug-ins.
If you already see an entry for RtcDataSync you should click on its \"Edit\" link. If you don't see such an entry in the list, please click on the [Add] button instead. In either case you will be taken to the following screen where you can enter or modify the RTC Data-Synchronization plug-in:
You need to fill out the following fields for the RTC Plug-in to operate correctly:
Name -- this needs to be set to RtcDataSync. This needs to match the name of the plug-in DLL assembly that was copied into the C:\\Program Files\\SpiraTeam\\Bin folder (minus the .dll file extension). If you renamed the RtcDataSync.dll file for any reason, then you need to change the name here to match.
Description -- this should be set to a description of the plug-in. This is an optional field that is used for documentation purposes and is not actually used by the system.
Connection Info -- this should be the base URL for connecting to your instance of RTC (for example https://servername:9443/ccm).
Login -- this should be set to a valid login for your RTC installation. The login needs to have permissions to create and view work items within RTC.
Password -- this should be set to the password of the login specified above.
Time Offset -- normally this should be set to zero, but if you find that issues being changed in RTC are not being updated in SpiraTeam, try increasing the value as this will tell the data-synchronization plug-in to add on the time offset (in hours) when comparing date-time stamps. Also if your RTC installation is running on a server set to a different time-zone, then you should add in the number of hours difference between the servers' time-zones here.
Auto-Map Users -- this is not currently used and can be ignored.
Custom 01 -- this is not currently used and can be ignored
Custom 02 -- this is not currently used and can be ignored
Custom 03 -- this is not currently used and can be ignored
Custom 04 -- this is not currently used and can be ignored
Custom 05 -- this is not currently used and can be ignored
Next, you need to configure the data mapping between SpiraTeam and RTC. This allows the various projects, users, incident statuses, priorities, severities and custom property values used in the two applications to be related to each other. This is important, as without a correct mapping, there is no way for the integration service to know that a \"New\" item in SpiraTeam is equivalent to a \"New\" item in RTC (for example).
The following mapping information needs to be setup in SpiraTeam:
The mapping of the project identifiers for the projects that need to be synchronized
The mapping of the various standard fields in the system
The mapping of the various custom properties in the system
Each of these is explained in turn below:
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-IBM-RTC/#configuring-the-project-mapping","title":"Configuring the Project Mapping","text":"From the data synchronization administration page, you need to click on the \"View Project Mappings\" hyperlink next to the RTC plug-in name. This will take you to the data-mapping home page for the currently selected project:
If the project name does not match the name of the project you want to configure the data-mapping for, click on the \"(Change Project)\" hyperlink to change the current project.
To enable this project for data-synchronization with RTC, you need to enter:
External Key -- This should be set to the display name of the project in RTC that will be mapped to the specific SpiraTeam project.
Active Flag -- Set this to 'Yes' so that SpiraTeam knows that you want to synchronize data for this project. Once the project has been completed, setting the value to \"No\" will stop data synchronization, reducing network utilization.
Click [Update] to confirm these settings. Once you have enabled the project for data-synchronization, you can now enter the other data mapping values outlined below.
Note: Once you have successfully configured the project, when creating a new project, you should choose the option to \"Create Project from Existing Project\" rather than \"Use Default Template\" so that all the project mappings get copied across to the new project.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-IBM-RTC/#configuring-the-standard-field-mapping","title":"Configuring the Standard Field Mapping","text":"Now that the projects, user and releases have been mapped correctly, we need to configure the standard incident fields. To do this, go to Administration > System > Data Synchronization and click on the \"View Project Mappings\" for the RtcDataSync plug-in entry:
From this screen, you need to click on Status and Type in turn to configure their values:
a) Incident Status
Click on the \"Status\" hyperlink under Incident Standard Fields to bring up the Incident status mapping configuration screen:
The table lists each of the incident statuses available in SpiraTeam and provides you with the ability to enter the matching RTC work item status name for each one. You can map multiple SpiraTeam fields to the same RTC fields (e.g. Closed and Resolved in SpiraTeam are both equivalent to Complete in RTC), in which case only one of the two values can be listed as Primary = Yes as that's the value that's used on the reverse synchronization (from RTC > SpiraTeam).
b) Incident Type
Click on the \"Type\" hyperlink under Incident Standard Fields to bring up the Incident type mapping configuration screen:
The table lists each of the incident types available in SpiraTeam and provides you with the ability to enter the matching RTC work item type name for each one. You can map multiple SpiraTeam fields to the same RTC fields, in which case only one of the two values can be listed as Primary = Yes as that's the value that's used on the reverse synchronization (from RTC > SpiraTeam).
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-IBM-RTC/#configuring-the-custom-property-mapping","title":"Configuring the Custom Property Mapping","text":"Now that the various SpiraTeam standard fields have been mapped correctly, we need to configure the custom property mappings. This is used to associate custom properties in SpiraTeam that map to custom fields in RTC. From the View/Edit Project Data Mapping screen, you need to click on the name of the Incident Custom Property that you want to add data-mapping information for.
We will consider the two different types of mapping that you might want to enter:
a) Text Custom Properties
Click on the hyperlink of the text custom property under Incident Custom Properties to bring up the custom property mapping configuration screen. For text custom properties there will be no values listed in the lower half of the screen.
You need to obtain the fully qualified XML name of the custom field in RTC that matches this custom property in SpiraTeam from the RTC documentation. Once you have entered the name of the custom field, click [Update].
b) List Custom Properties
Click on the hyperlink of the list custom property under Incident Custom Properties to bring up the custom property mapping configuration screen. For list custom properties there will be a textbox for both the custom field itself and a mapping table for each of the custom property values that need to be mapped:
First you need to obtain the fully qualified XML name of the field in RTC that matches this custom property in SpiraTeam. This should be entered in the 'External Key' field below the name of the custom property. Then you need enter the possible values in RTC for the custom property, mapping each one to the corresponding SpiraTeam custom property value.
**Once you have updated the various mapping sections, you are now ready to use the service. **
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-IBM-RTC/#using-spirateam-with-rtc","title":"Using SpiraTeam with RTC","text":"Now that the integration service has been configured and the service started, initially any incidents created in SpiraTeam for the specified projects will be imported into RTC and any existing work items in RTC will get loaded into SpiraTeam
At this point we recommend opening the Windows Event Viewer and choosing the Application Log. In this log any error messages raised by the SpiraTeam Data Sync Service will be displayed. If you see any error messages at this point, we recommend immediately stopping the SpiraTeam service and checking the various mapping entries. If you cannot see any issues with the mapping information, we recommend sending a copy of the event log message(s) to Inflectra customer services (http://www.inflectra.com/Support) who will help you troubleshoot the problem.
To use SpiraTeam with RTC on an ongoing basis, we recommend the following general processes be followed:
When running tests in SpiraTest or SpiraTeam, defects found should be logged through the Test Execution Wizard as normal.
Developers using RTC can log new work items into either SpiraTeam or RTC. In either case they will get loaded into the other system.
Once created in one of the systems and successfully replicated to the other system, the incident should not be modified again inside SpiraTeam
At this point, the incident should not be acted upon inside SpiraTeam and all data changes to the issue should be made inside RTC. To enforce this, you should modify the workflows set up in SpiraTeam so that the various fields are marked as inactive for all the incident statuses other than the \"New\" status. This will allow someone to submit an incident in SpiraTeam, but will prevent them making changes in conflict with RTC after that point.
As the issue progresses through the customized RTC workflow, changes to the type of work item, changes to its status, description and custom fields will be updated automatically in SpiraTeam. In essence, SpiraTeam acts as a read-only viewer of these incidents.
You are now able to perform test coverage and incident reporting inside SpiraTest/SpiraTeam using the test cases managed by SpiraTest/SpiraTeam and the incidents managed on behalf of SpiraTest/SpiraTeam inside RTC.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-JIRA-3--4/","title":"Using SpiraTeam with JIRA 3 / 4","text":"This section outlines how to use SpiraTest, SpiraPlan or SpiraTeam (hereafter referred to as SpiraTeam) in conjunction with the JIRA issue/bug tracking system versions 3.0 -- 4.0. The built-in integration service allows the quality assurance team to manage their requirements and test cases in SpiraTeam, execute test runs in SpiraTest, and then have the new incidents generated during the run be automatically loaded into JIRA. Once the incidents are loaded into JIRA as issues, the development team can then manage the lifecycle of these issues in JIRA, and have the status changes in JIRA be reflected back in SpiraTeam.
In addition, if you are using JIRA 4.x or higher, any issues logged directly into JIRA will get imported into SpiraTeam so that they can be linked to test cases and requirements.
Set up data synchronization
STOP! Please make sure you have first read the instructions to set up the data sync before proceeding!
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-JIRA-3--4/#configuring-the-plug-in","title":"Configuring the Plug-In","text":"The next step is to configure the plug-in within SpiraTeam so that the system knows how to access the JIRA server. To start the configuration, please open up SpiraTeam in a web browser, log in using a valid account that has System-Administration level privileges and click on the System > Data Synchronization administration option from the left-hand navigation:
This screen lists all the plug-ins already configured in the system. Depending on whether you chose the option to include sample data in your installation or not, you will see either an empty screen or a list of sample data-synchronization plug-ins.
If you already see an entry for JiraDataSync you should click on its \"Edit\" link. If you don't see such an entry in the list, please click on the [Add] button instead. In either case you will be taken to the following screen where you can enter or modify the JIRA Data-Synchronization plug-in:
You need to fill out the following fields for the JIRA Plug-in to operate correctly:
Name -- this needs to be set to JiraDataSync. This needs to match the name of the plug-in DLL assembly that was copied into the C:\\Program Files\\SpiraTeam\\Bin folder (minus the .dll file extension). If you renamed the JiraDataSync.dll file for any reason, then you need to change the name here to match.
Description -- this should be set to a description of the plug-in. This is an optional field that is used for documentation purposes and is not actually used by the system.
Connection Info -- this should the full URL to the JIRA installation's web-service API. This is typically http://<jira server name>/rpc/soap/jirasoapservice-v2.
Login -- this should be set to a valid login to the JIRA installation. The login needs to have permissions to create and view issues and versions within JIRA.
Password -- this should be set to the password of the login specified above.
Time Offset -- normally this should be set to zero, but if you find that issues being changed in JIRA are not being updated in SpiraTeam, try increasing the value as this will tell the data-synchronization plug-in to add on the time offset (in hours) when comparing date-time stamps. Also if your JIRA installation is running on a server set to a different time-zone, then you should add in the number of hours difference between the servers' time-zones here.
The remaining fields work differently depending on which version of the plugin you are using (JIRA 3.x or JIRA 4.x):
a) JIRA 3.x Plugin
Please fill out the fields as follows:
Auto-Map Users -- this is not currently used and can be ignored.
Custom 01 -- This is used to specify a JIRA custom property that should be mapped to the built-in SpiraTeam Incident Severity field (which does not exist in JIRA). This can be left empty for now and will be discussed below in Configuring the Data Mapping.
Custom 02 -- 05 -- these are not currently used by the plug-in and should be left blank.
b) JIRA 4.x Plugin
Please fill out the fields as follows:
Auto-Map Users -- This changes the way that the plugin maps users in SpiraTeam to those in JIRA:
**Auto-Map = True **With this setting, all users in SpiraTeam need to have the same username as those in JIRA. If this is the case then you do not need to perform the user-mapping task. This is a big time-saver if you can guarantee that all usernames are the same in both systems.
Auto-Map = False **With this setting, users in SpiraTeam and JIRA are free to have different usernames because you specify the corresponding JIRA name for each user as outlined in Configuring the User Mapping. **
Custom 01 -- This is used to specify a JIRA custom property that should be mapped to the built-in SpiraTeam Incident Severity field (which does not exist in JIRA). This can be left empty for now and will be discussed below in Configuring the Data Mapping.
Custom 02 -- This should be set to the word \"True\" if you want to have the new issues submitted to JIRA be submitted using a specified SecurityLevel. If you're not using the security level feature of JIRA, leave the field blank.
Custom 03 -- This should be set to the word \"True\" if you want to have the plugin restrict synchronization to only loading new incidents from SpiraTeam to JIRA and updating existing items. This is useful if you want to prevent existing issues in JIRA from being loaded into SpiraTeam. Leave blank if you want the plugin to synchronize normally.
Custom 04 -- This should be set to the word \"True\" if you want to have the plugin copy file attachments from SpiraTeam to JIRA. This can use additional system resources and may fail if the files are too large for JIRA's API to handle. Leave the field blank if you want the default behavior -- which is to not synchronize attachments.
Custom 05 - When you click \"Force Resync\" inside SpiraTeam it will attempt to resynchronize all incidents/issues from 1/1/1900. Sometimes that causes the JIRA API to timeout or exceed the maximum allowed number of results if there are a large number of existing issues in JIRA.
You can set this field to a specific year (e.g. 1995) or year and month (e.g. 2010-11) to restrict how far back the system will look for existing issues. If you leave this field blank it will use the default value of \"1900-01\".
Note: For most users, we recommend leaving Custom 01 -- Custom 05 blank.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-JIRA-3--4/#configuring-the-data-mapping","title":"Configuring the Data Mapping","text":"Next, you need to configure the data mapping between SpiraTeam and JIRA. This allows the various projects, users, releases, incident types, statuses, priorities and custom property values used in the two applications to be related to each other. This is important, as without a correct mapping, there is no way for the integration service to know that an \"Enhancement\" in SpiraTeam is the same as a \"New Feature\" in JIRA (for example).
The following mapping information needs to be setup in SpiraTeam:
Each of these is explained in turn below:
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-JIRA-3--4/#configuring-the-project-mapping","title":"Configuring the Project Mapping","text":"From the data synchronization administration page, you need to click on the \"View Project Mappings\" hyperlink next to the JIRA plug-in name. This will take you to the data-mapping home page for the currently selected project:
If the project name does not match the name of the project you want to configure the data-mapping for, click on the \"(Change Project)\" hyperlink to change the current project.
To enable this project for data-synchronization with JIRA, you need to enter:
External Key -- This should be set to the name of the project token in JIRA. Typically this is a three-letter acronym for the project.
Active Flag -- Set this to 'Yes' so that SpiraTeam knows that you want to synchronize data for this project. Once the project has been completed, setting the value to \"No\" will stop data synchronization, reducing network utilization.
Click [Update] to confirm these settings. Once you have enabled the project for data-synchronization, you can now enter the other data mapping values outlined below.
Note: Once you have successfully configured the project, when creating a new project, you should choose the option to \"Create Project from Existing Project\" rather than \"Use Default Template\" so that all the project mappings get copied across to the new project.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-JIRA-3--4/#configuring-the-user-mapping","title":"Configuring the User Mapping","text":"To configure the mapping of users in the two systems, you need to go to Administration > Users > View Edit Users, which will bring up the list of users in the system. Then click on the \"Edit\" button for a particular user that will be editing issues in JIRA:
You will notice that below the Active flag for the user is a list of all the configured data-synchronization plug-ins. In the text box next to the JIRA Data-Sync plug-in you need to enter the login for this username in JIRA. This will allow the data-synchronization plug-in to know which user in SpiraTeam match which equivalent user in JIRA. Click [Update] once you've entered the appropriate login name. You should now repeat for the other users who will be active in both systems.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-JIRA-3--4/#configuring-the-release-mapping","title":"Configuring the Release Mapping","text":"When the data-synchronization service runs, when it comes across a release/iteration in SpiraTeam that it has not seen before, it will create a corresponding \"Version\" in JIRA. Similarly if it comes across a new Version in JIRA that it has not seen before, it will create a new Release in SpiraTeam. Therefore when using both systems together, it is recommended that you only enter new Releases/Versions in one system and let the data-synchronization service add them to the other system.
However you may start out with the situation where you already have pre-existing Releases/Version in both systems that you need to associate in the data-mapping. If you don't do this, you may find that duplicates get created when you first enable the data-synchronization service. Therefore for any Releases/Iterations that already exist in BOTH systems please navigate to Planning > Releases and click on the Release/Iteration in question. Make sure you have the 'Overview' tab visible and expand the \"Details\" section of the release/iteration:
In addition to the standard fields custom properties configured for Releases, you will see an additional text property called \"JiraDataSync ID\" that is used to store the mapped external identifier for the equivalent Version in JIRA. You need to locate the ID of the equivalent version in JIRA, enter it into this text-box and click [Save]. You should now repeat for all the other pre-existing releases.
Note: The JIRA ID can be found by looking at the URL inside JIRA when choosing to View/Edit the version name/description. The URL will include the section: id=X where X is the numeric ID of the version inside JIRA.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-JIRA-3--4/#configuring-the-standard-field-mapping","title":"Configuring the Standard Field Mapping","text":"Now that the projects, user and releases have been mapped correctly, we need to configure the standard incident fields. To do this, go to Administration > System > Data Synchronization and click on the \"View Project Mappings\" for the JiraDataSync plug-in entry:
From this screen, you need to click on Priority, Severity, Status and Type in turn to configure their values:
a) Incident Type
Click on the \"Type\" hyperlink under Incident Standard Fields to bring up the Incident type mapping configuration screen:
The table lists each of the incident types available in SpiraTeam and provides you with the ability to enter the matching JIRA issue type ID for each one. You can map multiple SpiraTeam fields to the same JIRA fields (e.g. Bug and Incident in SpiraTeam are both equivalent to Bug in JIRA), in which case only one of the two values can be listed as Primary = Yes as that's the value that's used on the reverse synchronization (from JIRA to SpiraTeam).
Note: The JIRA ID can be found by looking at the URL inside JIRA when choosing to View/Edit the Issue Type. The URL will include the section: id=X where X is the numeric ID of the Issue Type inside JIRA.
b) Incident Status
Click on the \"Status\" hyperlink under Incident Standard Fields to bring up the Incident status mapping configuration screen:
The table lists each of the incident statuses available in SpiraTeam and provides you with the ability to enter the matching JIRA issue status ID for each one. You can map multiple SpiraTeam fields to the same JIRA fields (e.g. New and Open in SpiraTeam are both equivalent to Open in JIRA), in which case only one of the two values can be listed as Primary = Yes as that's the value that's used on the reverse synchronization (from JIRA to SpiraTeam).
We recommend that you always point the New and Open statuses inside SpiraTeam to point to the ID for \"Open\" inside JIRA and make Open in SpiraTeam the Primary status of the two. This is recommended so that as new incidents in SpiraTeam get synched over to JIRA, they will get switched to the Open status in JIRA which will then be synched back to \"Open\" in SpiraTeam. That way you'll be able to see at a glance which incidents have been synched with JIRA and those that haven't.
Note: The JIRA ID can be found by looking at the URL inside JIRA when choosing to View/Edit the Issue Status. The URL will include the section: id=X where X is the numeric ID of the Issue Status inside JIRA.
c) Incident Priority
Click on the \"Priority\" hyperlink under Incident Standard Fields to bring up the Incident Priority mapping configuration screen:
The table lists each of the incident priorities available in SpiraTeam and provides you with the ability to enter the matching JIRA priority ID for each one. You can map multiple SpiraTeam fields to the same JIRA fields, in which case only one of the two values can be listed as Primary = Yes as that's the value that's used on the reverse synchronization (from JIRA to SpiraTeam).
Note: The JIRA ID can be found by looking at the URL inside JIRA when choosing to View/Edit the Priority. The URL will include the section: id=X where X is the numeric ID of the Priority inside JIRA.
d) Incident Severity (Optional)
Click on the \"Severity\" hyperlink under Incident Standard Fields to bring up the Incident severity mapping configuration screen:
Unlike the other incident standard fields, JIRA doesn't actually have a built-in field for storing the severity of an issue, so if you want to be able to see the SpiraTeam incident severity in JIRA, you'll need to create a JIRA custom list field to store the different severity values. If you don't want to synchronize severity values with JIRA, you can skip the rest of this section.
Once you have created a custom field in JIRA to contain the list of severity values, you need to now populate the above table with the name (Not the ID) of the severity custom property values inside JIRA and click Update. Secondly you need to go to the Plug-in configuration screen:
On this screen you need to enter the ID of the custom field that you're using to store severities in JIRA and populate the Custom 01 property with this value (see above). Note: The ID can be found by looking at the URL inside JIRA when choosing to View/Edit the Custom Field. The URL will include the section: id=X where X is the numeric ID of the Custom Field inside JIRA.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-JIRA-3--4/#configuring-the-custom-property-mapping","title":"Configuring the Custom Property Mapping","text":"Now that the various SpiraTeam standard fields have been mapped correctly, we need to configure the custom property mappings. This is used for both custom properties in SpiraTeam that map to custom fields in JIRA and also for custom properties in SpiraTeam that are used to map to standard fields in JIRA (Component, Environment, Resolution and SecurityLevel) that don't exist in SpiraTeam.
From the View/Edit Project Data Mapping screen, you need to click on the name of the Incident Custom Property that you want to add data-mapping information for. We will consider the four different types of mapping that you might want to enter:
a) Text Custom Properties
Click on the hyperlink of the text custom property under Incident Custom Properties to bring up the custom property mapping configuration screen. For text custom properties there will be no values listed in the lower half of the screen.
You need to lookup the ID of the custom field in JIRA that matches this custom property in SpiraTeam. Once you have entered the id of the custom field, click [Update].
Note: The ID can be found by looking at the URL inside JIRA when choosing to View/Edit the Custom Field. The URL will include the section: id=X where X is the numeric ID of the Custom Field inside JIRA.
b) List Custom Properties
Click on the hyperlink of the list custom property under Incident Custom Properties to bring up the custom property mapping configuration screen. For list custom properties there will be a textbox for both the custom field itself and a mapping table for each of the custom property values that need to be mapped:
First you need to lookup the ID of the custom field in JIRA that matches this custom property in SpiraTeam. This should be entered in the 'External Key' field below the name of the custom property. Note: The ID can be found by looking at the URL inside JIRA when choosing to View/Edit the Custom Field. The URL will include the section: id=X where X is the numeric ID of the Custom Field inside JIRA.
Next for each of the Property Values in the table (in the lower half of the page) you need to enter the full name (not the id this time) of the custom field value as specified in JIRA.
c) JIRA's Component Field
If your instance of JIRA requires that all new issues are submitted with a 'Component' then you will need to fill out this section. You first need to create an incident custom property in SpiraTeam of type 'LIST' that contains the various component names that exist inside JIRA.
Then click on the hyperlink of this new list custom property under Incident Custom Properties to bring up the custom property mapping configuration screen:
First you need to enter the word \"Component\" as the External Key of the custom property. This tells the data-sync plug-in that the custom property in SpiraTeam should be mapped to built-in Component field in JIRA.
Next for each of the Property Values in the table (in the lower half of the page) you need to enter the JIRA ID of the various Components that are configured in JIRA. The external ID can be found by looking at the URL inside JIRA which choosing to View/Edit the component name/description.
d) JIRA's Resolution Field
If you would like the values of the JIRA 'Resolution' field to be synchronized back to SpiraTeam, then you will need to fill out this section. You first need to create an incident custom property in SpiraTeam of type 'LIST' that contains the various resolution names that exist inside JIRA.
Then click on the hyperlink of this new list custom property under Incident Custom Properties to bring up the custom property mapping configuration screen:
First you need to enter the word \"Resolution\" as the External Key of the custom property. This tells the data-sync plug-in that the custom property in SpiraTeam should be mapped to built-in Resolution field in JIRA.
Next for each of the Property Values in the table (in the lower half of the page) you need to enter the JIRA ID of the various Resolutions that are configured in JIRA. The external ID can be found by looking at the URL inside JIRA which choosing to View/Edit the resolution name/description.
e) JIRA's Environment Field
If your instance of JIRA requires that all new issues are submitted with an 'Environment' description specified, then you will need to fill out this section. You first need to create an incident custom property in SpiraTeam of type 'TEXT' that will be used to store the environment description within SpiraTeam.
Then click on the hyperlink of this new list custom property under Incident Custom Properties to bring up the custom property mapping configuration screen:
All you need to do on this screen is enter the word \"Environment\" in the External Key textbox and the data-sync plug-in will know that this custom property is mapped to the built-in Environment field in JIRA.
f) JIRA's Security Level Field (JIRA 4.x Plug-In Only)
If your instance of JIRA requires that all new issues are submitted with a 'Security Level' then you will need to fill out this section. You first need to create an incident custom property in SpiraTeam of type 'LIST' that contains the various security levels that exist inside JIRA.
Then click on the hyperlink of this new list custom property under Incident Custom Properties to bring up the custom property mapping configuration screen.
First you need to enter the word \"SecurityLevel\" as the External Key of the custom property. This tells the data-sync plug-in that the custom property in SpiraTeam should be mapped to built-in Security Level field in JIRA.
Next for each of the Property Values in the table (in the lower half of the page) you need to enter the JIRA ID of the various Security Levels that are configured in JIRA. The external ID can be found by looking at the URL inside JIRA which choosing to View/Edit the security level name/description.
g) JIRA's Issue Key Field (JIRA 4.x Plug-In Only)
It can be convenient to create a SpiraTeam custom property to store the JIRA Issue Key (the ID used to identify an issue in JIRA). This allows you to display a list of incients in SpiraTest and see the corresponding JIRA ID in the same list. You first need to create an incident custom property in SpiraTeam of type 'TEXT' that will be used to store the JIRA issue key within SpiraTeam.
Then click on the hyperlink of this new list custom property under Incident Custom Properties to bring up the custom property mapping configuration screen:
All you need to do on this screen is enter the word \"JiraIssueKey\" in the External Key textbox and the data-sync plug-in will know that this custom property is mapped to the built-in Issue Key field in JIRA.
Once you have updated the various mapping sections, you are now ready to start using the system.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-JIRA-3--4/#using-spirateam-with-jira","title":"Using SpiraTeam with JIRA","text":"Now that the integration service has been configured and the service started, initially any incidents created in SpiraTeam for the specified projects will be imported into JIRA and if using JIRA 4.x, any existing issues in JIRA will get loaded into SpiraTeam
At this point we recommend opening the Windows Event Viewer and choosing the Application Log. In this log any error messages raised by the SpiraTeam Data Sync Service will be displayed. If you see any error messages at this point, we recommend immediately stopping the SpiraTeam service and checking the various mapping entries. If you cannot see any issues with the mapping information, we recommend sending a copy of the event log message(s) to Inflectra customer services (support@inflectra.com) who will help you troubleshoot the problem.
To use SpiraTeam with JIRA on an ongoing basis, we recommend the following general processes be followed:
When running tests in SpiraTest or SpiraTeam, defects found should be logged through the Test Execution Wizard as normal.
Developers using JIRA 4.x can log new defects into either SpiraTeam or JIRA. In either case they will get loaded into the other system.
Once created in one of the systems and successfully replicated to the other system, the incident should not be modified again inside SpiraTeam
At this point, the incident should not be acted upon inside SpiraTeam and all data changes to the issue should be made inside JIRA. To enforce this, you should modify the workflows set up in SpiraTeam so that the various fields are marked as inactive for all the incident statuses other than the \"New\" status. This will allow someone to submit an incident in SpiraTeam, but will prevent them making changes in conflict with JIRA after that point.
As the issue progresses through the customized JIRA workflow, changes to the type of issue, changes to its status, priority, description and resolution will be updated automatically in SpiraTeam. In essence, SpiraTeam acts as a read-only viewer of these incidents.
You are now able to perform test coverage and incident reporting inside SpiraTest/SpiraTeam using the test cases managed by SpiraTest/SpiraTeam and the incidents managed on behalf of SpiraTest/SpiraTeam inside JIRA.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-JIRA-5%2B/","title":"Using SpiraTeam with Jira Server (or DataCenter)","text":""},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-JIRA-5%2B/#introduction","title":"Introduction","text":"By integrating SpiraTest, SpiraTeam or SpiraPlan (called SpiraPlan from here on out) and Jira Server or Jira DataCenter (hereafter just Jira Server or Jira) your teams can work seamlessly across both applications.
For example, the quality assurance team can manage their requirements and test cases in SpiraPlan, and execute test runs in SpiraPlan. Incident generated during testing wil be automatically loaded into Jira Server as new issues. The development team, working in Jira, can then manage the lifecycle of these issues in Jira. When they change the issue status or add comments, these changes are quickly updated to match back in SpiraPlan. You can choose which sort of Jira issues are made into incidents in SpiraPlan, and which get created as requirements (based on the issue type). This can be used as part of the planning and testing lifecycle.
With this integration you can, for each project/product you want to sync up:
Set up data synchronization
STOP! Please make sure you have first read the instructions to set up the data sync before proceeding!
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-JIRA-5%2B/#configuring-the-plug-in","title":"Configuring the Plug-In","text":"This section outlines how to configure the integration service to export incidents into JIRA, import new issues from JIRA and pick up subsequent status changes in JIRA and have them update SpiraTeam. It assumes that you already have a working installation of SpiraTest, SpiraPlan or SpiraTeam and a working installation of JIRA.
The following versions of SpiraTeam and Jira Server are supported:
The JIRA 5.x plugin supports Jira 5.0 or later and SpiraTeam v5.0 or later
The JIRA 4.x plugin supports Jira 4.0 or later and SpiraTeam v3.0 or later (see Using SpiraTeam with JIRA 3 / 4)
The JIRA 3.x plugin supports Jira 3.0 or later and SpiraTeam v2.3 or later (see Using SpiraTeam with JIRA 3 / 4)
If you are using the Cloud version of Jira, please refer to the Jira Cloud Documentation instead.
If you have an earlier version of SpiraTeam, you will need to upgrade to at least v2.3 before trying to integrate with Jira Server.
The next step is to configure the plug-in within SpiraTeam so that the system knows how to access the Jira server. Inside SpiraPlan, go to the Administration page and navigate to Integration > Data Synchronization. Check if you see a plug-in called JiraServerDataSync, as shown below:
What do if the plug-in is not there
If you don't see the plug-in in the list, click the \"\"Add\" button at the top of the page. This opens the generic Data Sync plug-in details page. This is not yet customized to help you more easily set up the data sync. We recommend, adding just enough information now to create the plug-in. Then edit the plug-in after its made to complete the process.
To start, fill in the following fields:
Now click \"Add\" to save the plug-in and return you to the list of plug-ins. Now follow the instructions below.
With the plug-in place, click on its \"edit\" button to open its detailed settings page.
You need to fill out the following fields for the JIRA Plug-in to operate correctly:
Auto-Map Users: This changes the way that the plugin maps users in SpiraTeam to those in JIRA:
Severity Field: This is used to specify a JIRA custom property that should be mapped to the built-in SpiraTeam Incident Severity field (which does not exist in JIRA). This can be left empty for now and will be discussed below in Configuring the Data Mapping.
Sync Direction: This determines how the synchronization of incidents works:
Requirement Types: This should be set to a comma-separated list of IDs of any JIRA issue types that you want to be synchronized with SpiraTeam requirements instead of incidents. If you leave this blank, all JIRA issue types will be synchronized with incidents.
Note: For most users, we recommend leaving Severity Field, Task Types, Sync Direction, and Requirement Types fields blank.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-JIRA-5%2B/#configuring-the-data-mapping","title":"Configuring the Data Mapping","text":"Next, you need to configure the data mapping between SpiraTeam and JIRA. This allows the various projects, users, releases, incident types, statuses, priorities and custom property values used in the two applications to be related to each other. This is important, as without a correct mapping, there is no way for the integration service to know that an \"Enhancement\" in SpiraTeam is the same as a \"New Feature\" in JIRA (for example).
The following mapping information needs to be setup in SpiraTeam:
Each of these is explained in turn below. However, to make the data mapping process easier, we have a helpful utility that will help you connect to your JIRA instance (both cloud or server) and determine the matching IDs for the various fields in JIRA:
You can download it from this URL: https://www.inflectra.com/Downloads/JiraConfigurationHelper.zip
Once you have downloaded and unzipped the program, run the JiraConfigurationHelper.exe and the following screen will be displayed:
Enter in the URL, login and password/API Key for your JIRA instance and click Connect:
Choose the project in JIRA that you will be connecting to SpiraTest and then the list of issue types, issue statuses, issue priorities, components, versions and custom fields will be displayed. We will be using this tool later on when you want to get some of the ID values to populate in SpiraTest.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-JIRA-5%2B/#configuring-the-project-mapping","title":"Configuring the Project Mapping","text":"From the data synchronization administration page, you need to click on the \"View Project Mappings\" hyperlink next to the JIRA plug-in name. This will take you to the data-mapping home page for the currently selected project:
If the project name does not match the name of the project you want to configure the data-mapping for, click on the \"(Change Project)\" hyperlink to change the current project.
To enable this project for data-synchronization with JIRA, you need to enter:
External Key -- This should be set to the name of the project Key in JIRA. Typically, this is a short acronym for the project:
Active Flag -- Set this to 'Yes' so that SpiraTeam knows that you want to synchronize data for this project. Once the project has been completed, setting the value to \"No\" will stop data synchronization, reducing network utilization.
Click [Update] to confirm these settings. Once you have enabled the project for data-synchronization, you can now enter the other data mapping values outlined below.
Note: Once you have successfully configured the project, when creating a new project, you should choose the option to \"Create Project from Existing Project\" rather than \"Use Default Template\" so that all the project mappings get copied across to the new project.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-JIRA-5%2B/#configuring-the-user-mapping","title":"Configuring the User Mapping","text":"To configure the mapping of users in the two systems, you need to go to Administration > Users > View Edit Users, which will bring up the list of users in the system. Then click on the \"Edit\" button for a particular user that will be editing issues in JIRA:
Click on the 'Data Mapping' tab to list all the configured data-synchronization plug-ins for this user. In the text box next to the JIRA Data-Sync plug-in you need to enter the login for this username in JIRA. This will allow the data-synchronization plug-in to know which user in SpiraTeam match which equivalent user in JIRA. Click [Save] once you've entered the appropriate login name. You should now repeat for the other users who will be active in both systems.
If you have set the \"Auto-Map Users\" option in the JIRA plugin, you can skip this section completely.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-JIRA-5%2B/#configuring-the-release-mapping","title":"Configuring the Release Mapping","text":"When the data-synchronization service runs, when it comes across a release/iteration in SpiraTeam that it has not seen before, it will create a corresponding \"Version\" in JIRA. Similarly, if it comes across a new Version in JIRA that it has not seen before, it will create a new Release in SpiraTeam. Therefore, when using both systems together, it is recommended that you only enter new Releases/Versions in one system and let the data-synchronization service add them to the other system.
However, you may start out with the situation where you already have pre-existing Releases/Version in both systems that you need to associate in the data-mapping. If you don't do this, you may find that duplicates get created when you first enable the data-synchronization service. Therefore, for any Releases/Iterations that already exist in BOTH systems please navigate to Planning > Releases and click on the Release/Iteration in question. Make sure you have the 'Overview' tab visible and expand the \"Details\" section of the release/iteration:
In addition to the standard fields and custom properties, you will see an additional text property called \"Jira ID\" that is used to store the mapped external identifier for the equivalent Version in JIRA. You need to locate the ID of the equivalent version in JIRA, enter it into this text-box and click [Save]. You should now repeat for all the other pre-existing releases.
The JIRA ID can be found using the Jira Configuration Helper using the Versions tab:
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-JIRA-5%2B/#configuring-the-standard-field-mapping","title":"Configuring the Standard Field Mapping","text":"Now that the projects, user and releases have been mapped correctly, we need to configure the standard incident and requirement fields. To do this, go to Administration > System > Data Synchronization and click on the \"View Project Mappings\" for the JiraDataSync plug-in entry:
From this screen, you need to click on Priority, Severity, Component, Status and Type in turn to configure the incident field mappings. If you're using the option to have JIRA also synchronize some issue types as requirements, then you'll need to also configure the Requirement Importance, Type, Component and Status fields.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-JIRA-5%2B/#a-incident-type","title":"a) Incident Type","text":"Click on the \"Type\" hyperlink under Incident Standard Fields to bring up the Incident type mapping configuration screen:
The table lists each of the incident types available in SpiraTeam and provides you with the ability to enter the matching JIRA issue type ID for each one. You can map multiple SpiraTeam fields to the same JIRA fields (e.g. Bug and Incident in SpiraTeam are both equivalent to Bug in JIRA), in which case only one of the two values can be listed as Primary = Yes as that's the value that's used on the reverse synchronization (from JIRA to SpiraTeam).
The JIRA ID can be found by using the Issue Types tab of the Jira configuration helper:
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-JIRA-5%2B/#b-incident-status","title":"b) Incident Status","text":"Click on the \"Status\" hyperlink under Incident Standard Fields to bring up the Incident status mapping configuration screen:
The table lists each of the incident statuses available in SpiraTeam and provides you with the ability to enter the matching JIRA issue status ID for each one. You can map multiple SpiraTeam fields to the same JIRA fields (e.g. New and Open in SpiraTeam are both equivalent to Open in JIRA), in which case only one of the two values can be listed as Primary = Yes as that's the value that's used on the reverse synchronization (from JIRA to SpiraTeam).
We recommend that you always point the New and Open statuses inside SpiraTeam to point to the ID for \"Open\" inside JIRA and make Open in SpiraTeam the Primary status of the two. This is recommended so that as new incidents in SpiraTeam get synched over to JIRA, they will get switched to the Open status in JIRA which will then be synched back to \"Open\" in SpiraTeam. That way you'll be able to see at a glance which incidents have been synched with JIRA and those that haven't.
The JIRA ID can be found by using the Issue Statuses tab of the Jira configuration helper:
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-JIRA-5%2B/#c-incident-priority","title":"c) Incident Priority","text":"Click on the \"Priority\" hyperlink under Incident Standard Fields to bring up the Incident Priority mapping configuration screen:
The table lists each of the incident priorities available in SpiraTeam and provides you with the ability to enter the matching JIRA priority ID for each one. You can map multiple SpiraTeam fields to the same JIRA fields, in which case only one of the two values can be listed as Primary = Yes as that's the value that's used on the reverse synchronization (from JIRA to SpiraTeam).
The JIRA ID can be found by using the Issue Priorities tab of the Jira configuration helper:
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-JIRA-5%2B/#d-incident-component-optional","title":"d) Incident Component (Optional)","text":"Click on the \"Component\" hyperlink under Incident Standard Fields to bring up the Incident component mapping configuration screen:
The table lists each of the components available in SpiraTeam and provides you with the ability to enter the matching JIRA component ID for each one. You can map multiple SpiraTeam fields to the same JIRA fields, in which case only one of the two values can be listed as Primary = Yes as that's the value that's used on the reverse synchronization (from JIRA to SpiraTeam).
The JIRA ID can be found by using the Components tab of the Jira configuration helper:
:
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-JIRA-5%2B/#e-incident-severity-optional","title":"e) Incident Severity (Optional)","text":"Click on the \"Severity\" hyperlink under Incident Standard Fields to bring up the Incident severity mapping configuration screen:
Unlike the other incident standard fields, JIRA doesn't actually have a built-in field for storing the severity of an issue, so if you want to be able to see the SpiraTeam incident severity in JIRA, you'll need to create a JIRA custom list field to store the different severity values. If you don't want to synchronize severity values with JIRA, you can skip the rest of this section.
Once you have created a custom field in JIRA to contain the list of severity values, you need to now populate the above table with the name (Not the ID) of the severity custom property values inside JIRA and click Update. Secondly you need to go to the Plug-in configuration screen:
On this screen you need to enter the ID of the custom field that you're using to store severities in JIRA and populate the Severity Field property with this value (see above). The ID can be found by using the Custom Fields tab of the Jira Configuration Helper:
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-JIRA-5%2B/#f-requirement-status-optional","title":"f) Requirement Status (Optional)","text":"Click on the \"Status\" hyperlink under Requirement Standard Fields to bring up the Requirement status mapping configuration screen:
The table lists each of the requirement statuses available in SpiraTeam and provides you with the ability to enter the matching JIRA issue status ID for each one. You can map multiple SpiraTeam fields to the same JIRA fields, in which case only one of the two values can be listed as Primary = Yes as that's the value that's used on the reverse synchronization (from JIRA to SpiraTeam).
The JIRA ID can be found by using the Issue Statuses tab of the Jira configuration helper:
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-JIRA-5%2B/#g-requirement-importance-optional","title":"g) Requirement Importance (Optional)","text":"Click on the \"Importance\" hyperlink under Requirement Standard Fields to bring up the Requirement Importance mapping configuration screen:
The table lists each of the requirement importances available in SpiraTeam and provides you with the ability to enter the matching JIRA priority ID for each one. You can map multiple SpiraTeam fields to the same JIRA fields, in which case only one of the two values can be listed as Primary = Yes as that's the value that's used on the reverse synchronization (from JIRA to SpiraTeam).
The JIRA ID can be found by using the Issue Priorities tab of the Jira configuration helper:
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-JIRA-5%2B/#h-requirement-type-optional","title":"h) Requirement Type (Optional)","text":"Click on the \"Type\" hyperlink under Requirement Standard Fields to bring up the Requirement type mapping configuration screen:
The table lists each of the requirement types available in SpiraTeam and provides you with the ability to enter the matching JIRA issue type ID for each one. You can map multiple SpiraTeam fields to the same JIRA fields (e.g. Use Case and User Story in SpiraTeam are both equivalent to User Story in JIRA), in which case only one of the two values can be listed as Primary = Yes as that's the value that's used on the reverse synchronization (from JIRA to SpiraTeam).
The JIRA ID can be found by using the Issue Types tab of the Jira configuration helper:
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-JIRA-5%2B/#i-requirement-component-optional","title":"i) Requirement Component (Optional)","text":"Click on the \"Component\" hyperlink under Requirement Standard Fields to bring up the Requirement component mapping configuration screen:
The table lists each of the components available in SpiraTeam and provides you with the ability to enter the matching JIRA component ID for each one. You can map multiple SpiraTeam fields to the same JIRA fields, in which case only one of the two values can be listed as Primary = Yes as that's the value that's used on the reverse synchronization (from JIRA to SpiraTeam).
The JIRA ID can be found by using the Components tab of the Jira configuration helper:
:
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-JIRA-5%2B/#j-task-status-optional","title":"j) Task Status (Optional)","text":"Click on the \"Status\" hyperlink under Task Standard Fields to bring up the Task status mapping configuration screen:
The table lists each of the task statuses available in SpiraPlan and provides you with the ability to enter the matching JIRA issue status ID for each one. You can map multiple SpiraPlan fields to the same JIRA fields, in which case only one of the two values can be listed as Primary = Yes as that's the value that's used on the reverse synchronization (from JIRA to SpiraPlan).
The JIRA ID can be found by using the Issue Statuses tab of the Jira configuration helper. Please note, in Jira there are 5 default levels of Issue Priority, and only 4 (by default - this can be changed) in SpiraPlan.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-JIRA-5%2B/#k-task-priority-optional","title":"k) Task Priority (Optional)","text":"Click on the \"Priority\" hyperlink under Task Standard Fields to bring up the Task Priority mapping configuration screen:
The table lists each of the task priorities available in SpiraPlan and provides you with the ability to enter the matching JIRA priority ID for each one. You can map multiple SpiraPlan fields to the same JIRA fields, in which case only one of the two values can be listed as Primary = Yes as that's the value that's used on the reverse synchronization (from JIRA to SpiraPlan).
The JIRA ID can be found by using the Issue Priorities tab of the Jira configuration helper:
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-JIRA-5%2B/#l-task-type-optional","title":"l) Task Type (Optional)","text":"Click on the \"Type\" hyperlink under Task Standard Fields to bring up the Task type mapping configuration screen:
The table lists each of the task types available in SpiraPlan and provides you with the ability to enter the matching JIRA issue type ID for each one. You can map multiple SpiraPlan fields to the same JIRA fields (e.g. Management and Other in SpiraPlan are both equivalent to Task in JIRA), in which case only one of the two values can be listed as Primary = Yes as that's the value that's used on the reverse synchronization (from JIRA to SpiraPlan).
The JIRA ID can be found by using the Issue Types tab of the Jira configuration helper:
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-JIRA-5%2B/#configuring-the-custom-property-mapping","title":"Configuring the Custom Property Mapping","text":"Now that the various SpiraTeam standard fields have been mapped correctly, we need to configure the custom property mappings. This is used for both custom properties in SpiraTeam that map to custom fields in JIRA and also for custom properties in SpiraTeam that are used to map to standard fields in JIRA (Environment, Resolution and SecurityLevel) that don't exist in SpiraTeam.
From the View/Edit Project Data Mapping screen, you need to click on the name of the Incident or Requirement Custom Property that you want to add data-mapping information for. We will consider the four different types of mapping that you might want to enter:
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-JIRA-5%2B/#a-scalar-custom-properties","title":"a) Scalar Custom Properties","text":"This refers to custom properties that have a simple user-entered value and don't need to have their specific options mapped between SpiraTeam and JIRA. All of the custom property types except List and Multi-List fall into this category (e.g. Text, Date, User, Boolean, Decimal, Integer, etc.)
Click on the hyperlink of the scalar custom property under Incident/Requirement Custom Properties to bring up the custom property mapping configuration screen. For scalar custom properties, there will be no values listed in the lower half of the screen.
You need to lookup the ID of the custom field in JIRA that matches this custom property in SpiraTeam. Once you have entered the id of the custom field, click [Update].
The ID can be found by using the Custom Fields tab of the Jira Configuration Helper:
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-JIRA-5%2B/#b-list-custom-properties","title":"b) List Custom Properties","text":"This refers to custom properties that are either of type List or Multi-List. Click on the hyperlink of the list custom property under Incident/Requirement Custom Properties to bring up the custom property mapping configuration screen. For list custom properties there will be a textbox for both the custom field itself and a mapping table for each of the custom property values that need to be mapped:
First you need to lookup the ID of the custom field in JIRA that matches this custom property in SpiraTeam. This should be entered in the 'External Key' field below the name of the custom property. The ID can be found by using the Custom Fields tab of the Jira Configuration Helper:
Next for each of the Property Values in the table (in the lower half of the page) you need to enter the full name (not the id this time) of the custom field value as specified in JIRA:
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-JIRA-5%2B/#c-jiras-resolution-field","title":"c) JIRA's Resolution Field","text":"If you would like the values of the JIRA 'Resolution' field to be synchronized back to SpiraTeam, then you will need to fill out this section. You first need to create an incident custom property in SpiraTeam of type 'LIST' that contains the various resolution names that exist inside JIRA.
Then click on the hyperlink of this new list custom property under Incident Custom Properties to bring up the custom property mapping configuration screen:
First you need to enter the word \"Resolution\" as the External Key of the custom property. This tells the data-sync plug-in that the custom property in SpiraTeam should be mapped to built-in Resolution field in JIRA.
Next for each of the Property Values in the table (in the lower half of the page) you need to enter the JIRA ID of the various Resolutions that are configured in JIRA. The external ID can be found by looking at the URL inside JIRA which choosing to View/Edit the resolution name/description.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-JIRA-5%2B/#d-jiras-environment-field","title":"d) JIRA's Environment Field","text":"If your instance of JIRA requires that all new issues are submitted with an 'Environment' description specified, then you will need to fill out this section. You first need to create an incident custom property in SpiraTeam of type 'TEXT' that will be used to store the environment description within SpiraTeam.
Then click on the hyperlink of this new list custom property under Incident Custom Properties to bring up the custom property mapping configuration screen:
All you need to do on this screen is enter the word \"Environment\" in the External Key textbox and the data-sync plug-in will know that this custom property is mapped to the built-in Environment field in JIRA.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-JIRA-5%2B/#e-jiras-security-level-field","title":"e) JIRA's Security Level Field","text":"If your instance of JIRA requires that all new issues are submitted with a 'Security Level' then you will need to fill out this section. You first need to create an incident custom property in SpiraTeam of type 'LIST' that contains the various security levels that exist inside JIRA.
Then click on the hyperlink of this new list custom property under Incident Custom Properties to bring up the custom property mapping configuration screen.
First you need to enter the word \"SecurityLevel\" as the External Key of the custom property. This tells the data-sync plug-in that the custom property in SpiraTeam should be mapped to built-in Security Level field in JIRA.
Next for each of the Property Values in the table (in the lower half of the page) you need to enter the JIRA ID of the various Security Levels that are configured in JIRA. The external ID can be found by looking at the URL inside JIRA which choosing to View/Edit the security level name/description.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-JIRA-5%2B/#f-jiras-issue-key-field","title":"f) JIRA's Issue Key Field","text":"It can be convenient to create a SpiraTeam custom property to store the JIRA Issue Key (the ID used to identify an issue in JIRA). This allows you to display a list of incients in SpiraTest and see the corresponding JIRA ID in the same list. You first need to create an incident custom property in SpiraTeam of type 'TEXT' that will be used to store the JIRA issue key within SpiraTeam.
Then click on the hyperlink of this new list custom property under Incident Custom Properties to bring up the custom property mapping configuration screen:
All you need to do on this screen is enter the word \"JiraIssueKey\" in the External Key textbox and the data-sync plug-in will know that this custom property is mapped to the built-in Issue Key field in JIRA.
Once you have updated the various mapping sections, you are now ready to use the integration.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-JIRA-5%2B/#using-spirateam-with-jira","title":"Using SpiraTeam with JIRA","text":"Now that the integration service has been configured and the service started, initially any incidents created in SpiraTeam for the specified projects will be imported into JIRA and any existing issues in JIRA will get loaded into SpiraTeam as either incidents or requirements (depending on your configuration).
At this point we recommend opening the Windows Event Viewer and choosing the Application Log. In this log any error messages raised by the SpiraTeam Data Sync Service will be displayed. If you see any error messages at this point, we recommend immediately stopping the SpiraTeam service and checking the various mapping entries. If you cannot see any issues with the mapping information, we recommend sending a copy of the event log message(s) to Inflectra customer services (support@inflectra.com) who will help you troubleshoot the problem.
To use SpiraTeam with JIRA on an ongoing basis, we recommend the following general processes be followed:
When running tests in SpiraTest or SpiraTeam, defects found should be logged through the Test Execution Wizard as normal.
Developers can log new defects into either SpiraTeam or JIRA. In either case they will get loaded into the other system.
Once created in one of the systems and successfully replicated to the other system, the incident should not be modified again inside SpiraTeam
At this point, the incident should not be acted upon inside SpiraTeam and all data changes to the issue should be made inside JIRA. To enforce this, you should modify the workflows set up in SpiraTeam so that the various fields are marked as inactive for all the incident statuses other than the \"New\" status. This will allow someone to submit an incident in SpiraTeam, but will prevent them making changes in conflict with JIRA after that point.
As the issue progresses through the customized JIRA workflow, changes to the type of issue, changes to its status, priority, description and resolution will be updated automatically in SpiraTeam. In essence, SpiraTeam acts as a read-only viewer of these incidents.
You are now able to perform test coverage and incident reporting inside SpiraTest/SpiraTeam using the test cases managed by SpiraTest/SpiraTeam and the incidents managed on behalf of SpiraTest/SpiraTeam inside JIRA.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-Jira-Cloud/","title":"Using SpiraPlan with Jira Cloud","text":""},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-Jira-Cloud/#introduction","title":"Introduction","text":"By integrating SpiraTest, SpiraTeam or SpiraPlan (SpiraPlan from here on) and Jira Cloud your teams can work seamlessly across both applications.
For example, the quality assurance team can manage their requirements and test cases in SpiraPlan, and execute test runs in SpiraPlan. Incident generated during testing wil be automatically loaded into JIRA as new issues. The development team, working in Jira, can then manage the lifecycle of these issues in JIRA. When they change the issue status or add comments, these changes are quickly updated to match back in SpiraPlan. You can choose which sort of Jira issues are made into incidents in SpiraPlan, and which get created as requirements (based on the issue type). This can be used as part of the planning and testing lifecycle.
With this integration you can, for each project/product you want to sync up:
Prerequisites: The Jira Cloud plugin supports SpiraPlan v5.0 or later and the most recent version of Jira cloud hosted by Atlassian. For Jira Server, we have an alternate Jira Server plugin available.
DO THIS FIRST
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-Jira-Cloud/#set-up-the-data-synchronization","title":"Set up the data synchronization","text":"STOP! Please make sure you have first read the instructions to set up the data sync before proceeding!
Once you have completed the above you are ready to start configuring the plug-in.
You must also have a working installation of SpiraPlan and a cloud subscription to Jira.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-Jira-Cloud/#configuring-the-plug-in","title":"Configuring the Plug-In","text":"Now that the data synchronization service / application itself is set up, we are ready to move to the next step.
Now you need to configure the Jira integration to let you:
To do this, you need to tell SpiraPlan how to access your JIRA instance. Inside SpiraPlan, go to the Administration page and navigate to Integration > Data Synchronization. Check if you see a plug-in called JiraDataSync, as shown below:
What do if the plug-in is not there
If you don't see the plug-in in the list, click the \"\"Add\" button at the top of the page. This opens the generic Data Sync plug-in details page. This is not yet customized to help you more easily set up the data sync. We recommend, adding just enough information now to create the plug-in. Then edit the plug-in after its made to complete the process.
To start, fill in the following fields:
Now click \"Add\" to save the plug-in and return you to the list of plug-ins. Now follow the instructions below.
With the plug-in place, click on its \"edit\" button to open its detailed settings page.
You need to fill out the following fields for the JIRA Plug-in to operate correctly:
Auto-Map Users: This changes the way that the plugin maps users in SpiraPlan to those in JIRA:
Severity/Est. Points Field: This is used to specify the value(s) for Spira Incident Severity and/or Requirement Estimate Points based on JIRA custom properties . Please enter the Jira custom property IDs separated by a comma. Both fields are optional, but if you want to skip one, please enter it as 0. This can be left empty for now and will be discussed below in Configuring the Data Mapping.
Sync Direction: This determines how the synchronization of incidents works:
Requirement Types: This should be set to a comma-separated list of IDs of any JIRA issue types that you want to be synchronized with SpiraPlan requirements instead of incidents. If you leave this blank, all JIRA issue types will be synchronized with incidents (user stories/epics will not be synced at all).
Info
For most users, we recommend leaving these fields blank: \"Severity/Est. Points Field\"; \"Task Types\"; and \"Sync Direction\". Leave \"Requirement Types\" blank if you do not want sync user stories/requirements.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-Jira-Cloud/#configuring-the-data-mapping","title":"Configuring the Data Mapping","text":"Next, you need to configure the data mapping between SpiraPlan and JIRA. This allows the various products, users, releases, incident types, statuses, priorities and custom property values used in the two applications to be related to each other. This is important, as without a correct mapping, there is no way for the integration service to know that an \"Enhancement\" in SpiraPlan is the same as a \"New Feature\" in JIRA (for example).
The following mapping information needs to be setup in SpiraPlan:
Each of these is explained in turn below. However, to make the data mapping process easier, we have a helpful utility that will help you connect to your JIRA instance (both cloud or server) and determine the matching IDs for the various fields in JIRA:
You can download it from this URL: https://www.inflectra.com/Downloads/JiraConfigurationHelper.zip
Once you have downloaded and unzipped the program, run the JiraConfigurationHelper.exe and the following screen will be displayed:
Enter in the URL, login and password/API Key for your JIRA instance and click Connect:
Choose the project in JIRA that you will be connecting to SpiraPlan and then the list of issue types, issue statuses, issue priorities, components, versions and custom fields will be displayed. We will be using this tool later on when you want to get some of the ID values to populate in SpiraPlan .
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-Jira-Cloud/#configuring-the-project-mapping","title":"Configuring the Project Mapping","text":"From the data synchronization administration page, you need to click on the \"View Product Mappings\" hyperlink next to the JIRA plug-in name. This will take you to the data-mapping home page for the currently selected product:
If the project name does not match the name of the project you want to configure the data-mapping for, click on the \"(Change Project)\" hyperlink to change the current product.
To enable this project for data-synchronization with JIRA, you need to enter:
Click \"Update\" to confirm these settings. Once you have enabled the product for data-synchronization, you can now enter the other data mapping values outlined below.
Info
One SpiraPlan product can only be mapped to one Jira project, in other words it is a one-to-one mapping.
Once you have successfully configured the product, when creating a new product, you should choose the option to \"Create product from Existing product\" rather than \"Use Default Template\" so that all the product mappings get copied across to the new product.***
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-Jira-Cloud/#configuring-the-user-mapping","title":"Configuring the User Mapping","text":"If you have set the \"Auto-Map Users\" option in the JIRA plugin, you can skip this section completely.
To configure the mapping of users in the two systems, you need to go to Administration > Users > View Edit Users, which will bring up the list of users in the system. Then click on the \"Edit\" button for a particular user that will be editing issues in JIRA:
Click on the 'Data Mapping' tab to list all the configured data-synchronization plug-ins for this user.
In the text box next to the JIRA Data-Sync plug-in entry, you need to enter one of the following Jira user identifiers to allow the data-synchronization plug-in to know which user in SpiraPlan match which equivalent user in Jira:
Email Address
You can enter in the email address of the user in Jira. This will only work if the user has set their user profile to be public.
This requires that the profile has its email address visibility set to Anyone inside Jira
Atlassian AccountID
You can enter in the corresponding Atlassian AccountID value into this field. This will work regardless of whether the user's profile is public or private.
Click Save once you've entered the appropriate user identifier name.
Repeat the above steps for each user who is active in both systems.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-Jira-Cloud/#configuring-the-release-mapping","title":"Configuring the Release Mapping","text":"When the data-synchronization service runs, when it comes across a release/iteration in SpiraPlan that it has not seen before, it will create a corresponding \"Version\" in JIRA. Similarly, if it comes across a new Version in JIRA that it has not seen before, it will create a new Release in SpiraPlan. Therefore, when using both systems together, it is recommended that you only enter new Releases/Versions in one system and let the data-synchronization service add them to the other system.
However, you may start out with the situation where you already have pre-existing Releases/Version in both systems that you need to associate in the data-mapping. If you don't do this, you may find that duplicates get created when you first enable the data-synchronization service. Therefore, for any Releases/Iterations that already exist in BOTH systems please navigate to Planning > Releases and click on the Release/Iteration in question. Make sure you have the 'Overview' tab visible and expand the \"Details\" section of the release/iteration:
In addition to the standard fields and custom properties, you will see an additional text property called \"Jira ID\" that is used to store the mapped external identifier for the equivalent Version in JIRA. You need to locate the ID of the equivalent version in JIRA, enter it into this text-box and click [Save]. You should now repeat for all the other pre-existing releases.
The JIRA ID can be found using the Jira Configuration Helper using the Versions tab:
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-Jira-Cloud/#configuring-the-standard-field-mapping","title":"Configuring the Standard Field Mapping","text":"Now that the products, users and releases have been mapped correctly, we need to configure the standard incident and requirement fields. To do this, go to Administration > System > Data Synchronization and click on the \"View Product Mappings\" for the JiraDataSync plug-in entry:
From this screen, you need to click on Priority, Severity, Component, Status and Type in turn to configure the incident field mappings. If you're using the option to have JIRA also synchronize some issue types as requirements, then you'll need to also configure the Requirement Importance, Type, Component and Status fields.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-Jira-Cloud/#a-incident-type","title":"a) Incident Type","text":"Click on the \"Type\" hyperlink under Incident Standard Fields to bring up the Incident type mapping configuration screen:
The table lists each of the incident types available in SpiraPlan and provides you with the ability to enter the matching JIRA issue type ID for each one. You can map multiple SpiraPlan fields to the same JIRA fields (e.g. Bug and Incident in SpiraPlan are both equivalent to Bug in JIRA), in which case only one of the two values can be listed as Primary = Yes as that's the value that's used on the reverse synchronization (from JIRA to SpiraPlan).
The JIRA ID can be found by using the Issue Types tab of the Jira configuration helper:
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-Jira-Cloud/#b-incident-status","title":"b) Incident Status","text":"Click on the \"Status\" hyperlink under Incident Standard Fields to bring up the Incident status mapping configuration screen:
The table lists each of the incident statuses available in SpiraPlan and provides you with the ability to enter the matching JIRA issue status ID for each one. You can map multiple SpiraPlan fields to the same JIRA fields (e.g. New and Open in SpiraPlan are both equivalent to Open in JIRA), in which case only one of the two values can be listed as Primary = Yes as that's the value that's used on the reverse synchronization (from JIRA to SpiraPlan).
We recommend that you always point the New and Open statuses inside SpiraPlan to point to the ID for \"Open\" inside JIRA and make Open in SpiraPlan the Primary status of the two. This is recommended so that as new incidents in SpiraPlan get synched over to JIRA, they will get switched to the Open status in JIRA which will then be synched back to \"Open\" in SpiraPlan. That way you'll be able to see at a glance which incidents have been synched with JIRA and those that haven't.
The JIRA ID can be found by using the Issue Statuses tab of the Jira configuration helper:
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-Jira-Cloud/#c-incident-priority","title":"c) Incident Priority","text":"Click on the \"Priority\" hyperlink under Incident Standard Fields to bring up the Incident Priority mapping configuration screen:
The table lists each of the incident priorities available in SpiraPlan and provides you with the ability to enter the matching JIRA priority ID for each one. You can map multiple SpiraPlan fields to the same JIRA fields, in which case only one of the two values can be listed as Primary = Yes as that's the value that's used on the reverse synchronization (from JIRA to SpiraPlan).
The JIRA ID can be found by using the Issue Priorities tab of the Jira configuration helper:
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-Jira-Cloud/#d-incident-component-optional","title":"d) Incident Component (Optional)","text":"Click on the \"Component\" hyperlink under Incident Standard Fields to bring up the Incident component mapping configuration screen:
The table lists each of the components available in SpiraPlan and provides you with the ability to enter the matching JIRA component ID for each one. You can map multiple SpiraPlan fields to the same JIRA fields, in which case only one of the two values can be listed as Primary = Yes as that's the value that's used on the reverse synchronization (from JIRA to SpiraPlan).
The JIRA ID can be found by using the Components tab of the Jira configuration helper:
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-Jira-Cloud/#e-incident-severity-optional","title":"e) Incident Severity (Optional)","text":"Click on the \"Severity\" hyperlink under Incident Standard Fields to bring up the Incident severity mapping configuration screen:
Unlike the other incident standard fields, JIRA doesn't actually have a built-in field for storing the severity of an issue, so if you want to be able to see the SpiraPlan incident severity in JIRA, you'll need to create a JIRA custom list field to store the different severity values. If you don't want to synchronize severity values with JIRA, you can skip the rest of this section.
Once you have created a custom field in JIRA to contain the list of severity values, you need to now populate the above table with the name (Not the ID) of the severity custom property values inside JIRA and click Update. Secondly you need to go to the Plug-in configuration screen:
On this screen you need to enter the ID of the custom field that you're using to store severities in JIRA and populate the \"Severity/Est. Points\" property with this value (see above). The ID can be found by using the Custom Fields tab of the Jira Configuration Helper:
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-Jira-Cloud/#f-requirement-status-optional","title":"f) Requirement Status (Optional)","text":"Click on the \"Status\" hyperlink under Requirement Standard Fields to bring up the Requirement status mapping configuration screen:
The table lists each of the requirement statuses available in SpiraPlan and provides you with the ability to enter the matching JIRA issue status ID for each one. You can map multiple SpiraPlan fields to the same JIRA fields, in which case only one of the two values can be listed as Primary = Yes as that's the value that's used on the reverse synchronization (from JIRA to SpiraPlan).
The JIRA ID can be found by using the Issue Statuses tab of the Jira configuration helper. Please note, in Jira there are 5 default levels of Issue Priority, and only 4 (by default - this can be changed) in SpiraPlan.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-Jira-Cloud/#g-requirement-importance-optional","title":"g) Requirement Importance (Optional)","text":"Click on the \"Importance\" hyperlink under Requirement Standard Fields to bring up the Requirement Importance mapping configuration screen:
The table lists each of the requirement importances available in SpiraPlan and provides you with the ability to enter the matching JIRA priority ID for each one. You can map multiple SpiraPlan fields to the same JIRA fields, in which case only one of the two values can be listed as Primary = Yes as that's the value that's used on the reverse synchronization (from JIRA to SpiraPlan).
The JIRA ID can be found by using the Issue Priorities tab of the Jira configuration helper:
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-Jira-Cloud/#h-requirement-type-optional","title":"h) Requirement Type (Optional)","text":"Click on the \"Type\" hyperlink under Requirement Standard Fields to bring up the Requirement type mapping configuration screen:
The table lists each of the requirement types available in SpiraPlan and provides you with the ability to enter the matching JIRA issue type ID for each one. You can map multiple SpiraPlan fields to the same JIRA fields (e.g. Use Case and User Story in SpiraPlan are both equivalent to User Story in JIRA), in which case only one of the two values can be listed as Primary = Yes as that's the value that's used on the reverse synchronization (from JIRA to SpiraPlan).
The JIRA ID can be found by using the Issue Types tab of the Jira configuration helper:
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-Jira-Cloud/#i-requirement-component-optional","title":"i) Requirement Component (Optional)","text":"Click on the \"Component\" hyperlink under Requirement Standard Fields to bring up the Requirement component mapping configuration screen:
The table lists each of the components available in SpiraPlan and provides you with the ability to enter the matching JIRA component ID for each one. You can map multiple SpiraPlan fields to the same JIRA fields, in which case only one of the two values can be listed as Primary = Yes as that's the value that's used on the reverse synchronization (from JIRA to SpiraPlan).
The JIRA ID can be found by using the Components tab of the Jira configuration helper:
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-Jira-Cloud/#j-requirement-estimate-points-optional","title":"j) Requirement Estimate Points (Optional):","text":"To sync Estimate Points for Requirements in Spira, make sure you added Estimates to your Jira issues as Story points or have a numeric custom property in Jira to map against. Use the Configuration Helper tool to find its ID (under the 'Custom Fields' tab). Enter this ID in Spira, as the second attribute (after a comma ',') of the \"Severity/Est. Points Field\" on the DataSync configuration page. For example: '10001,10033' where 10001 is the Incident Severity property ID in Jira and 10033 is the field we are configuring, the Estimate Points property ID in Jira. Make sure this field was created as a numeric field in Jira, otherwise the sync won't happen.
Click on the \"Status\" hyperlink under Task Standard Fields to bring up the Task status mapping configuration screen:
The table lists each of the task statuses available in SpiraPlan and provides you with the ability to enter the matching JIRA issue status ID for each one. You can map multiple SpiraPlan fields to the same JIRA fields, in which case only one of the two values can be listed as Primary = Yes as that's the value that's used on the reverse synchronization (from JIRA to SpiraPlan).
The JIRA ID can be found by using the Issue Statuses tab of the Jira configuration helper. Please note, in Jira there are 5 default levels of Issue Priority, and only 4 (by default - this can be changed) in SpiraPlan.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-Jira-Cloud/#l-task-priority-optional","title":"l) Task Priority (Optional)","text":"Click on the \"Priority\" hyperlink under Task Standard Fields to bring up the Task Priority mapping configuration screen:
The table lists each of the task priorities available in SpiraPlan and provides you with the ability to enter the matching JIRA priority ID for each one. You can map multiple SpiraPlan fields to the same JIRA fields, in which case only one of the two values can be listed as Primary = Yes as that's the value that's used on the reverse synchronization (from JIRA to SpiraPlan).
The JIRA ID can be found by using the Issue Priorities tab of the Jira configuration helper:
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-Jira-Cloud/#m-task-type-optional","title":"m) Task Type (Optional)","text":"Click on the \"Type\" hyperlink under Task Standard Fields to bring up the Task type mapping configuration screen:
The table lists each of the task types available in SpiraPlan and provides you with the ability to enter the matching JIRA issue type ID for each one. You can map multiple SpiraPlan fields to the same JIRA fields (e.g. Management and Other in SpiraPlan are both equivalent to Task in JIRA), in which case only one of the two values can be listed as Primary = Yes as that's the value that's used on the reverse synchronization (from JIRA to SpiraPlan).
The JIRA ID can be found by using the Issue Types tab of the Jira configuration helper:
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-Jira-Cloud/#configuring-the-custom-property-mapping","title":"Configuring the Custom Property Mapping","text":"Now that the various SpiraPlan standard fields have been mapped correctly, we need to configure the custom property mappings. This is used for both custom properties in SpiraPlan that map to custom fields in JIRA and also for custom properties in SpiraPlan that are used to map to standard fields in JIRA (Environment, Resolution and SecurityLevel) that don't exist in SpiraPlan.
From the View/Edit Product Data Mapping screen, you need to click on the name of the Incident or Requirement Custom Property that you want to add data-mapping information for. We will consider the four different types of mapping that you might want to enter:
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-Jira-Cloud/#a-scalar-custom-properties","title":"a) Scalar Custom Properties","text":"This refers to custom properties that have a simple user-entered value and don't need to have their specific options mapped between SpiraPlan and JIRA. All of the custom property types except List and Multi-List fall into this category (e.g. Text, Date, User, Boolean, Decimal, Integer, etc.)
Click on the hyperlink of the scalar custom property under Incident/Requirement Custom Properties to bring up the custom property mapping configuration screen. For scalar custom properties, there will be no values listed in the lower half of the screen.
You need to lookup the ID of the custom field in JIRA that matches this custom property in SpiraPlan. Once you have entered the id of the custom field, click [Update].
The ID can be found by using the Custom Fields tab of the Jira Configuration Helper:
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-Jira-Cloud/#b-list-custom-properties","title":"b) List Custom Properties","text":"This refers to custom properties that are either of type List or Multi-List (in Jira called cascading, multiple choice or single choice).
Click on the hyperlink of the list custom property under Incident/Requirement Custom Properties to bring up the custom property mapping configuration screen. For list custom properties there will be a textbox for both the custom field itself and a mapping table for each of the custom property values that need to be mapped:
First you need to lookup the ID of the custom field in JIRA that matches this custom property in SpiraPlan. This should be entered in the 'External Key' field below the name of the custom property. The ID can be found by using the Custom Fields tab of the Jira Configuration Helper:
Next for each of the Property Values in the table (in the lower half of the page) you need to enter the full name (not the id this time) of the custom field value as specified in JIRA:
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-Jira-Cloud/#c-jiras-resolution-field","title":"c) JIRA's Resolution Field","text":"If you would like the values of the JIRA 'Resolution' field to be synchronized back to SpiraPlan, then you will need to fill out this section. You first need to create an incident custom property in SpiraPlan of type 'LIST' that contains the various resolution names that exist inside JIRA.
Then click on the hyperlink of this new list custom property under Incident Custom Properties to bring up the custom property mapping configuration screen:
First you need to enter the word \"Resolution\" as the External Key of the custom property. This tells the data-sync plug-in that the custom property in SpiraPlan should be mapped to built-in Resolution field in JIRA.
Next for each of the Property Values in the table (in the lower half of the page) you need to enter the JIRA ID of the various Resolutions that are configured in JIRA. The external ID can be found by looking at the URL inside JIRA which choosing to View/Edit the resolution name/description.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-Jira-Cloud/#d-jiras-environment-field","title":"d) JIRA's Environment Field","text":"If your instance of JIRA requires that all new issues are submitted with an 'Environment' description specified, then you will need to fill out this section. You first need to create an incident custom property in SpiraPlan of type 'TEXT' that will be used to store the environment description within SpiraPlan.
Then click on the hyperlink of this new list custom property under Incident Custom Properties to bring up the custom property mapping configuration screen:
All you need to do on this screen is enter the word \"Environment\" in the External Key textbox and the data-sync plug-in will know that this custom property is mapped to the built-in Environment field in JIRA.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-Jira-Cloud/#e-jiras-security-level-field","title":"e) JIRA's Security Level Field","text":"If your instance of JIRA requires that all new issues are submitted with a 'Security Level' then you will need to fill out this section. You first need to create an incident custom property in SpiraPlan of type 'LIST' that contains the various security levels that exist inside JIRA.
Then click on the hyperlink of this new list custom property under Incident Custom Properties to bring up the custom property mapping configuration screen.
First you need to enter the word \"SecurityLevel\" as the External Key of the custom property. This tells the data-sync plug-in that the custom property in SpiraPlan should be mapped to built-in Security Level field in JIRA.
Next for each of the Property Values in the table (in the lower half of the page) you need to enter the JIRA ID of the various Security Levels that are configured in JIRA. The external ID can be found by looking at the URL inside JIRA which choosing to View/Edit the security level name/description.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-Jira-Cloud/#f-jiras-issue-key-field","title":"f) JIRA's Issue Key Field","text":"To see the Jira ID on the Incident list page you need to create a SpiraPlan custom property to store the JIRA Issue Key (the ID used to identify an issue in JIRA). The Jira DataSync id field will always show up on the details page, but not the list page. So if you wish to see the Jira ID on the list page follow these steps:
Now that all the mappings are done, you are now ready to use the integration.
Once the data sync service starts, at first any incidents created in SpiraPlan for the specified products will be imported into JIRA and any existing issues in JIRA get loaded into SpiraPlan as either incidents or requirements (depending on your configuration). Please note that links between Jira issues will be imported as Requirements associations.
Checking the logs
At this point we recommend checking the event log for any errors or useful messages.
If you see any error messages, we recommend immediately stopping data-sync and checking the various mapping entries. If you cannot see any issues with the mapping information, we recommend sending a full copy of the event log message(s) to Inflectra customer services who will help you troubleshoot the problem.
To use SpiraPlan with JIRA on an ongoing basis, we recommend:
You are now able to perform test coverage and incident reporting inside SpiraPlan /SpiraPlan using the test cases managed by SpiraPlan /SpiraPlan and the incidents managed on behalf of SpiraPlan /SpiraPlan inside JIRA.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-Jira-Cloud/#jiras-issue-key-field","title":"JIRA's Issue Key Field","text":"SpiraPlan automatically stores the unique id for each Jira issue that syncs with a SpiraPlan artifact. This field is visible on the artifact details page, in the \"Properties\" section. The field in SpiraPlan will be named based off plugin name in System Admin > Data Synchronization. The unique key in this field matches the one you will see in Jira for an issue:
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-Jira-Cloud/#using-the-jira-cloud-connector","title":"Using the Jira Cloud Connector","text":"Once you have the data-synchronization established between SpiraPlan and Jira Cloud, we have an additional Atlassian marketplace connector that you can use (see https://marketplace.atlassian.com/apps/1218742/spiratest-app-for-jira):
You can install the connector by following these instructions:
Please enter the following information:
You can get the SpiraPlan API Key from within the User Profile screen of SpiraPlan :
What to do if you cannot connect
If you get a message in the connector on a user story saying that it can't connect, please try the following:
SaveThis section outlines how to use SpiraTest, SpiraPlan or SpiraTeam (hereafter referred to as SpiraTeam) in conjunction with the Mantis issue tracking system. The built-in integration service allows the quality assurance team to manage their requirements and test cases in SpiraTeam, execute test runs in SpiraTest, and then have the new incidents generated during the run be automatically loaded into Mantis.
Once the incidents are synchronized into Mantis, the development team can then manage the issues in Mantis and have the status changes and additional notes entered in Mantis be reflected back in SpiraTeam. In addition, any new issues logged into mantis will get imported into SpiraTeam so that they can be linked to test cases and requirements.
Set up data synchronization
STOP! Please make sure you have first read the instructions to set up the data sync before proceeding!
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-Mantis/#configuring-the-plug-in","title":"Configuring the Plug-In","text":"The next step is to configure the plug-in within SpiraTeam so that the system knows how to access the Mantis server. To start the configuration, open up SpiraTeam in a web browser, log in using a valid account that has System-Administration level privileges and click on the System > Data Synchronization administration option from the left-hand navigation:
This screen lists all the plug-ins already configured in the system. Depending on whether you chose the option to include sample data in your installation or not, you will see either an empty screen or a list of sample data-synchronization plug-ins.
If you already see an entry for MantisDataSync you should click on its \"Edit\" link. If you don't see such an entry in the list, please click on the [Add] button instead. In either case you will be taken to the following screen where you can enter or modify the Mantis Data-Synchronization plug-in:
You need to fill out the following fields for the Mantis Plug-in to operate correctly:
Name -- this needs to be set to MantisDataSync. This needs to match the name of the plug-in DLL assembly that was copied into the C:\\Program Files\\SpiraTeam\\Bin folder (minus the .dll file extension). If you renamed the MantisDataSync.dll file for any reason, then you need to change the name here to match.
Description -- this should be set to a description of the plug-in. This is an optional field that is used for documentation purposes and is not actually used by the system.
Connection Info -- this should the URL that you use to access your instance of Mantis (e.g. https://www.mycompany.com/bugs)
Login -- this should be set to a valid login to the Mantis installation. The login needs to have permissions to create and view issues and versions within Mantis for the projects that you will be syncing to SpiraTeam.
Password -- this should be set to the password of the login specified above.
Time Offset -- The time offset between the two servers, if the Mantis server is on a different server than SpiraTeam. For example, if the Mantis server's clock is set to Pacific Standard Time (PST) and the SpiraTeam server is set to Eastern Standard Time (EST), the Mantis server would be three hours behind SpiraTeam, so you would need to put -3 into this field.
Auto-Map Users -- If enabled and a mapped user is not found between the two systems, a search will be made comparing logins between SpiraTeam and Mantis for matching UserIDs. If one is found, than that user will be used. If not enabled and a match is not found, then the UserID used will be the connecting user for the Data Sync. (The SpiraTeam User for issues coming into SpiraTeam, and the Mantis Login for issues imported into Mantis.)
Custom 01 -- This field specifies whether or not a Resolution item in SpiraTeam, or a Note item in Mantis will be created when an issue is created in either system for a new issue. Valid values are True or False. Default (or blank) is True.
Custom 02 -- This field indicates whether or not to convert Carriage Returns and spaces in Mantis issues when synchronizing them into SpiraTeam. If enabled, then carriage returns will be converted to HTML breaks, and multiple spaces will be converted to non-breaking spaces to preserve formatting when importing into SpiraTeam. If disabled, then carriage returns and spaces will be left as-is. Valid values are True or False. Default (or blank) is True.
Custom 03 -- This field is only used when 'Auto-Map Users' is enabled and for Incidents synchronized from SpiraTeam into Mantis. If enabled, and the Auto-Map User did not find a user with a matching Login ID, then the Login ID will be set to the User in Spira, even if that user may not exist in Mantis. Depending on Mantis configuration, the user may be accepted, or it may default back to the Mantis UserID that the Data Sync runs under. Valid values are True or False. Default (or blank) is False.
Custom 04 -- If enabled, this option specifies whether or not to append the \"Additional Information\" and \"Steps To Reproduce\" fields to the end of the Description field in Spira. During transfer of new issues from Mantis to SpiraTeam, the Description field in SpiraTeam will consist of the Description field in Mantis appended by the Additional Information field in Mantis, and finally the Steps To Reproduce field in Mantis. If this option is disabled, only the Description will be transferred over. Valid values are True or False. Default (or blank) is False.
Custom 05 -- This is not currently used by the MantisDataSync, and can be left blank.
Next, you need to configure the data mapping between SpiraTeam and Mantis. This allows the various projects, users, releases, incident types, statuses, priorities and custom property values used in the two applications to be related to each other. This is important, as without a correct mapping, there is no way for the integration service to know that an \"Enhancement\" in SpiraTeam is the same as a \"Feature\" in Mantis (for example).
The following mapping information needs to be setup in SpiraTeam:
The linking between the project in SpiraTeam and the project in Mantis.
The linking of users between the two systems.
The linking of releases between the two systems.
The linking of standard SpiraTeam fields to Mantis fields.
The linking of custom SpiraTeam fields to Mantis custom fields.
Each of these is explained in turn below:
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-Mantis/#configuring-the-project-mapping","title":"Configuring the Project Mapping","text":"While working in the project you want to map, from the data synchronization administration page you need to click on the \"View Project Mappings\" hyperlink next to the Mantis plug-in name. This will take you to the data-mapping overview page:
If the project name does not match the name of the project you want to configure the data-mapping for, click on the \"(Change Project)\" hyperlink to change the current project.
To enable this project for data-synchronization with Mantis, you need to enter:
External Key -- This should be set to the ID of the project in Mantis. To get the ID of the Project in Mantis, log in as an administrator and go to Manage -> Manage Projects:
Then hover the mouse over the project name. The project ID will be displayed in the URL line as project_id=X where X is the numeric ID of the project.
Active Flag -- Set this to 'Yes' so that SpiraTeam knows that you want to synchronize data for this project. Once the project has been completed, setting the value to \"No\" will stop data synchronization, reducing network utilization.
Click [Update] to confirm these settings. Once you have enabled the project for data-synchronization, you can now enter the other data mapping values outlined below.
Note: Once you have successfully configured the project, when creating a new project, you should choose the option to \"Create Project from Existing Project\" rather than \"Use Default Template\" so that all the project mappings get copied across to the new project, if you are going to want to Sync the new project up to Mantis.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-Mantis/#configuring-the-user-mapping","title":"Configuring the User Mapping","text":"To configure the mapping of users in the two systems, you need to go to Administration > Users > View Edit Users, which will bring up the list of users in the system. Then click on the \"Edit\" button for a particular user that will be editing issues in Mantis:
You will notice that below the Active flag for the user is a list of all the configured data-synchronization plug-ins. In the text box next to the MantisDataSync ID you need to enter the Login ID of this user in Mantis. If you have the \"Automap Users\" checkbox enabled in the MantisDataSync plugin, then if no link is created, the system will scan for a matching Login ID from both systems and use a match. (If you then do not have Custom3 set to \"False\", then for data going into Mantis the User ID will be forced to that of the User ID in SpiraTeam.)
Once you have entered the Mantis Login ID in, click [Update]. You should now repeat for the other users who will be active in both systems.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-Mantis/#configuring-the-release-mapping","title":"Configuring the Release Mapping","text":"When the data-synchronization service runs and it comes across a release in SpiraTeam (or a Version in Mantis) that it has not linked before, it will create a corresponding entry in the other system. When starting out a new project, it is recommended that you let the MantisDataSync handle creation of the releases/versions in either system, and then edit the information once the link is made.
In cases where you are syncing up two existing projects in both systems, it is advised that you link any existing releases that exist in both systems manually, and then only create new releases in one system. To link a release in SpiraTeam up to a version in Mantis, please navigate to Planning > Releases and click on the Release/Iteration in question. Make sure you have the 'Overview' tab visible and expand the \"Details\" section of the release/iteration:
In addition to the standard fields and custom properties configured for Releases, you will see an additional text property called \"MantisDataSync ID\" that is used to store the mapped external identifier for the equivalent Release in Mantis. The Mantis ID of a version is the string that is in the
The Mantis Release ID can be found by going to Manage -> Manage Projects -> Versions and viewing a release's details:
The Mantis Release ID is the highlighted text field. Copy and paste this into the field in SpiraTeam. Depending on your regional settings in both applications, this field will likely be case-sensitive.
For versions imported into Mantis from SpiraTeam, the Version will have an \"(S)\" appended to the name, and for versions in SpiraTeam imported from Mantis the version field of the Release will have \"(M)\" appended to the name.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-Mantis/#configuring-the-standard-field-mapping","title":"Configuring the Standard Field Mapping","text":"Now that the projects, user and releases have been mapped correctly, we need to configure the standard incident fields. To do this, go to Administration > System > Data Synchronization and click on the \"View Project Mappings\" for the MantisDataSync plug-in entry:
From this screen, you need to set up the Priority, Severity, Status, and Type fields:
a) Incident Type
The Incident Type field is optional and can be linked to the Mantis Category selection.
If you do not link values, then all issues being imported into SpiraTeam from Mantis will be set to the Default Type (as specified in the \"View/Edit Types\" screen), and issues going from SpiraTeam into Mantis will be assigned to the first Category in the list. (Usually Mantis orders them alphabetically, but this may change depending on your installation. If you do not have any Categories set-up, then issues will not transfer over and error messages will be logged.) For existing issues, updates to this field will not be transferred.
The table lists each of the incident types available in SpiraTeam and provides you with the ability to enter the matching Mantis Category for each one. The value to put in External ID is the Category text:
The Mantis Release ID is the highlighted text field. Copy and paste this into the field in SpiraTeam. Depending on your regional settings in both applications, this field will likely be case-sensitive.
You can map multiple SpiraTeam fields to the same Mantis fields (e.g. Bug and Incident in SpiraTeam are both equivalent to category \"development\" in Mantis). In a situation like this, enter in the Mantis category in both Big and Incident external keys, and decide which one will be primary. For issues coming from Mantis into SpiraTeam, the one marked Primary will be used, and for issues being created in Mantis, the same category will be used to create the issue.
b) Incident Status
The Incident Status is an optional field to be linked to the Mantis field by the same name.
If you do not link values, then defaults will be used. For issues coming from Mantis into SpiraTeam, incidents will be marked as 'New' (as defined by the \"View/Edit Status\" in Administration), and for issues being transferred to Mantis, the default is 'new'. Note that if an issue has an Owner in SpiraTeam, then the default for the new issue in Mantis is 'assigned'. For existing issues, updates to the field will not be transferred over.
The table lists each of the incident types available in SpiraTeam and provides you with the ability to enter the matching Mantis Category for each one. The values to put in External Key is any one of the Status values in Mantis. By default in Mantis, the available statuses are:
The Mantis values are in the highlighted text field. Type these into the External Key field in SpiraTeam. Depending on your regional settings in both applications, this field will likely be case-sensitive.
You can map multiple SpiraTeam fields to the same Mantis fields, just like the Incident Type above.
c) Incident Priority & Severity
The Incident Priority and Severity are optional fields that are linked to Mantis fields by the same name.
If you do not link values, then defaults will be used. For issues coming from Mantis into SpiraTeam, incidents will leave those fields undefined (unset). For issues coming from SpiraTeam into Mantis, the default priority of 'normal' and severity of 'minor' is used. For existing issues, updates to the field will not be transferred over.
The table lists each of the priorities available in SpiraTeam and provides you with the ability to enter the matching Mantis priority for each one. (The table for Severities has the same functionality.) The values to put in External Key are any one of the Priority (or Severity) values in Mantis. By default in Mantis, the available values are:
The Mantis values are in the highlighted fields above. Type these into the External Key field in SpiraTeam. Depending on your regional settings in both applications, this field will likely be case-sensitive.
You can map multiple SpiraTeam fields to the same Mantis fields, just like described in Incident Type above.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-Mantis/#configuring-the-custom-property-mapping","title":"Configuring the Custom Property Mapping","text":"Now that the various SpiraTeam standard fields have been mapped correctly, we need to configure the custom property mappings. At the moment, only custom fields in Mantis can be linked to custom fields in SpiraTeam.
From the View/Edit Project Data Mapping screen, you need to click on the name of the Incident Custom Property that you want to add data-mapping information for. Both field types in SpiraTeam can be linked up to any of the supported field types in Mantis. Linking between the two systems is done in text values only -- that means that if you have a SpiraTeam custom list, then the values that will be put into Mantis will be the strings of the list. The same works for moving fields back from Mantis. Rules for linking different field types up are as follows:
SpiraTeam 'List' to Mantis 'Enum', 'List', or 'Multiselection': For linking these types of fields together, the available values must match. For example, if you have \"Windows\" as an item in your list in SpiraTeam, then in the associated field in Mantis, \"Windows\" must be an available item as well. In instances where there is no match, then the default will be used in either system. On a Multiselection-type field, for importing back into SpiraTeam, only the first (top) selected value will be stored.
SpiraTeam 'List' to Mantis 'Numeric', 'Float', 'Date', 'Text', or 'Email': In this case, the text value of the SpiraTeam list will be assigned to the Mantis field, and values must be exact. For example, if you linked a SpiraTeam List to a Mantis Date field, the value for the List must be a valid date, like \"1/1/2010\". If any value fails the Mantis validation, the value will be ignored and the custom field will be set blank or to default. When transferring a value back from Mantis into SpiraTeam, the text must equal an available item in the custom list, or the field will be left blank.
SpiraTeam 'Text' to Mantis 'Numeric', 'Float', 'Date', 'Text', or 'Email': In this case, text will be copied over as-is. Note that in some special cases, like the number, date, and e-mail fields, Mantis may apply formatting or verification on values transferred over.
SpiraTeam 'Text' to Mantis 'Enum', 'List', or 'Multiselection': When pulling data from Mantis, the SpiraTeam custom field will be translated as the field in Mantis displays. However, when transferring data to Mantis, if the text in the SpiraTeam field does not match an available item in the lists, then Mantis may leave the field blank or set it to the default value.
a) Mapping custom fields
For a SpiraTeam test field, all you need to do is link the custom field to the custom field in Mantis. To do this, click on the name of the custom field under the \"Custom Properties\" header in the MantisDataSync Project Mappings, and you will see a screen allowing you to enter the External Key:
insert screenshot of custom map text prop screen with mapping for belowIn the External Key field, put the name of your custom field in Mantis:
Once you have updated the various mapping sections, you are now ready to use the service.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-Mantis/#using-spirateam-with-mantis_1","title":"Using SpiraTeam with Mantis","text":"Now that the integration service has been configured and the service started, initially any incidents created in SpiraTeam for the specified projects will be imported into Mantis and any existing issues in Mantis will get loaded into SpiraTeam. After the first sync, we recommend opening the Windows Event Viewer and viewing the Application Log. Any errors (unable to connect messages, invalid required field mappings) and warnings (incomplete field mappings) will be displayed. If on Server 2008/Vista or later, you can filter by the Application name \"MantisDataSync\". If you see any error messages (or warning messages that you want to correct before continuing) at this point, we recommend immediately stopping the SpiraTeam service and checking the various mapping entries. If you cannot see any issues with the mapping information, we recommend sending a copy of the event log message(s) to Inflectra customer services (support@inflectra.com) who will help you troubleshoot the problem.
To use SpiraTeam with Mantis on an ongoing basis, we recommend the following general processes be followed:
When running tests in SpiraTest or SpiraTeam, defects found should be logged through the Test Execution Wizard as normal.
Developers using Mantis can log new defects into either SpiraTeam or Mantis. In either case they will get loaded into the other system.
Once created in one of the systems and successfully replicated to the other system, the incident should not be modified again inside SpiraTeam. Since Mantis is considered the master system for incidents/issues, all data changes to the issue should be made inside Mantis. To enforce this, you should modify the workflows set up in SpiraTeam so that the various fields are marked as inactive for all the incident statuses other than the \"New\" status. This will allow someone to submit an incident in SpiraTeam, but will prevent them from making changes in conflict with Mantis after that point.
As the issue progresses in Mantis, changes to the type of issue, changes to its status, priority, description and resolution will be updated automatically in SpiraTeam. In essence, SpiraTeam acts as a read-only viewer of these incidents.
You are now able to perform test coverage and incident reporting inside SpiraTeam using the test cases managed by SpiraTeam and the incidents managed on behalf of SpiraTeam inside Mantis.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-Redmine/","title":"Using SpiraTeam with Redmine","text":"This section outlines how to use SpiraTeam in conjunction with the open-source Redmine bug-tracking and project management system. The built-in integration service allows the quality assurance team to manage their requirements and test cases in SpiraTeam, execute test runs in SpiraTeam, and then have the new incidents generated during the run be automatically loaded into Redmine. Once the incidents are loaded into Redmine as issues, the development team can then manage the lifecycle of these issues in Redmine, and have the status changes in Redmine be reflected back in SpiraTeam.
In addition, any issues logged directly into Redmine will get imported into SpiraTeam so that they can be linked to test cases and requirements.
Set up data synchronization
STOP! Please make sure you have first read the instructions to set up the data sync before proceeding!
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-Redmine/#configuring-the-plug-in","title":"Configuring the Plug-In","text":"The next step is to configure the plug-in within SpiraTeam so that the system knows how to access the Redmine server. To start the configuration, please open up SpiraTeam in a web browser, log in using a valid account that has System-Administration level privileges and click on the System > Data Synchronization administration option from the left-hand navigation:
This screen lists all the plug-ins already configured in the system. Depending on whether you chose the option to include sample data in your installation or not, you will see either an empty screen or a list of sample data-synchronization plug-ins.
If you already see an entry for RedmineDataSync you should click on its \"Edit\" link. If you don't see such an entry in the list, please click on the [Add] button instead. In either case you will be taken to the following screen where you can enter or modify the Redmine Data-Synchronization plug-in:
You need to fill out the following fields for the Redmine Plug-in to operate correctly:
Name -- this needs to be set to RedmineDataSync. This needs to match the name of the plug-in DLL assembly that was copied into the C:\\Program Files\\SpiraTeam\\Bin folder (minus the .dll file extension). If you renamed the RedmineDataSync.dll file for any reason, then you need to change the name here to match.
Description -- this should be set to a description of the plug-in. This is an optional field that is used for documentation purposes and is not actually used by the system.
Connection Info -- this should be the base URL of the Redmine installation. As an example, for the public demo installation of Redmine, it would be: http://demo.redmine.org
Login -- this should be set to a valid login to the Redmine installation -- the login needs to have permissions to create and view bugs and versions within Redmine.
Password -- this should be set to the password of the login specified above.
Time Offset -- normally this should be set to zero, but if you find that issues being changed in Redmine are not being updated in SpiraTeam, try increasing the value as this will tell the data-synchronization plug-in to add on the time offset (in hours) when comparing date-time stamps. Also if your Redmine installation is running on a server set to a different time-zone, then you should add in the number of hours difference between the servers' time-zones here.
Auto-Map Users -- This changes the way that the plugin maps users in SpiraTeam to those in Redmine:
**Auto-Map = True **With this setting, all users in SpiraTeam need to have the same username as those in Redmine. If this is the case then you do not need to perform the user-mapping task. This is a big time-saver if you can guarantee that all usernames are the same in both systems.
**Auto-Map = False **With this setting, users in SpiraTeam and Redmine are free to have different usernames because you specify the corresponding Redmine name for each user as outlined in Configuring the User Mapping.
Custom 01 -- This should be set to the word \"false\" if you want to have the plugin restrict synchronization to not create any new incidents in Spira.
Custom 02 -- This should be set to the word \"false\" if you want to have the plugin restrict synchronization to not create any new issues in Redmine.
Custom 03 -- 05 -- these are not currently used by the Redmine data-sync plug-in and can be left blank.
Next, you need to configure the data mapping between SpiraTeam and Redmine. This allows the various projects, users, releases, incident types, statuses, priorities and custom property values used in the two applications to be related to each other. This is important, as without a correct mapping, there is no way for the integration service to know that an \"Duplicate\" incident in SpiraTeam is the same as a \"Rejected\" bug in Redmine (for example).
The following mapping information needs to be setup in SpiraTeam:
The mapping of the project identifiers for the projects that need to be synchronized
The mapping of users in the system
The mapping of releases (equivalent to Redmine versions) in the system
The mapping of the various standard fields in the system
The mapping of the various custom properties in the system
Each of these is explained in turn below:
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-Redmine/#configuring-the-project-mapping","title":"Configuring the Project Mapping","text":"From the data synchronization administration page, you need to click on the \"View Project Mappings\" hyperlink next to the Redmine plug-in name. This will take you to the data-mapping home page for the currently selected project:
If the project name does not match the name of the project you want to configure the data-mapping for, click on the \"(Change Project)\" hyperlink to change the current project.
To enable this project for data-synchronization with Redmine, you need to enter:
External Key -- This should be set to the name of the equivalent project in Redmine.
Active Flag -- Set this to 'Yes' so that SpiraTeam knows that you want to synchronize data for this project. Once the project has been completed, setting the value to \"No\" will stop data synchronization, reducing network utilization.
Click [Update] to confirm these settings. Once you have enabled the project for data-synchronization, you can now enter the other data mapping values outlined below.
Note: Once you have successfully configured the project, when creating a new project, you should choose the option to \"Create Project from Existing Project\" rather than \"Use Default Template\" so that all the project mappings get copied across to the new project.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-Redmine/#configuring-the-user-mapping","title":"Configuring the User Mapping","text":"To configure the mapping of users in the two systems, you need to go to Administration > Users > View Edit Users, which will bring up the list of users in the system. Then click on the \"Edit\" button for a particular user that will be editing issues in Redmine:
You will notice that in the special Data Mapping tab for the user is a list of all the configured data-synchronization plug-ins. In the text box next to the Redmine Data-Sync plug-in you need to enter the numeric ID for this user in Redmine. This will allow the data-synchronization plug-in to know which user in Redmine matches this SpiraTeam user. Click [Update] once you've entered the appropriate ID value. You should now repeat for the other users who will be active in both systems.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-Redmine/#configuring-the-release-mapping","title":"Configuring the Release Mapping","text":"Now that the projects and users have been mapped correctly, we need to configure the mapping between Releases/Iterations in SpiraTeam and Versions in Redmine. To do this, please navigate to Planning > Releases and click on the Release/Iteration in question. Make sure you have the 'Overview' tab visible and expand the \"Details\" section of the release/iteration:
In addition to the standard fields and custom properties configured for Releases, you will see an additional text property called \"RedmineDataSync ID\" that is used to store the mapped external identifier for the equivalent Version in Redmine. You need to enter the numeric ID of the equivalent version in Redmine, enter it into this text-box and click [Save]. You should now repeat for all the other releases and iterations in the project.
In addition, any Versions that have already been created in Redmine will be automatically imported into SpiraTeam if they do not already exist in SpiraTeam and they have not already been mapped.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-Redmine/#configuring-the-standard-field-mapping","title":"Configuring the Standard Field Mapping","text":"Now that the projects, user and releases have been mapped correctly, we need to configure the standard incident fields. To do this, go to Administration > System > Data Synchronization and click on the \"View Project Mappings\" for the RedmineDataSync plug-in entry:
From this screen, you need to click on Priority, Type and Status in turn to configure their values:
a) Incident Status
Click on the \"Status\" hyperlink under Incident Standard Fields to bring up the Incident status mapping configuration screen:
The table lists each of the incident statuses available in SpiraTeam and provides you with the ability to enter the matching Redmine bug status ID for each one. You can map multiple SpiraTeam fields to the same Redmine fields (e.g. Open and Assigned in SpiraTeam are both equivalent to \"In Progress\" (ID=2) in Redmine), in which case only one of the two values can be listed as Primary = Yes as that's the value that's used on the reverse synchronization (from Redmine > SpiraTeam).
b) Incident Priority
Click on the \"Priority\" hyperlink under Incident Standard Fields to bring up the Incident Priority mapping configuration screen:
The table lists each of the incident priorities available in SpiraTeam and provides you with the ability to enter the matching Redmine priority ID for each one. You can map multiple SpiraTeam fields to the same Redmine fields, in which case only one of the two values can be listed as Primary = Yes as that's the value that's used on the reverse synchronization (from Redmine > SpiraTeam).
c) Incident Type
Incident types in SpiraTeam are equivalent to Trackers in Redmine. Click on the \"Type\" hyperlink under Incident Standard Fields to bring up the Incident type mapping configuration screen:
The table lists each of the incident types available in SpiraTeam and provides you with the ability to enter the matching Redmine Tracker ID for each one. You can map multiple SpiraTeam fields to the same Redmine tracker values, in which case only one of the two values can be listed as Primary = Yes as that's the value that's used on the reverse synchronization (from Redmine > SpiraTeam).
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-Redmine/#configuring-the-custom-property-mapping","title":"Configuring the Custom Property Mapping","text":"Now that the various SpiraTeam standard fields have been mapped correctly, we need to configure the custom property mappings. This is used for custom properties in SpiraTeam that map to custom fields in Redmine. You will need to first make sure that the custom properties and associated custom lists have been created in both systems:
From the View/Edit Project Data Mapping screen, you need to click on the name of the Incident Custom Property that you want to add data-mapping information for:
We will consider the two different types of mapping that you might want to enter.
a) Scalar Custom Properties
This refers to custom properties that have a simple user-entered value and don't need to have their specific options mapped between SpiraTeam and Redmine. All of the custom property types except List and Multi-List fall into this category (e.g. Text, Date, Boolean, Decimal, Integer, etc.)
Click on the hyperlink of the scalar custom property under Incident Custom Properties to bring up the custom property mapping configuration screen. For scalar custom properties there will be no values listed in the lower half of the screen.
You need to enter the ID of the custom field in Redmine that matches this custom property in SpiraTeam. Once you have entered the id of the custom field, click [Update].
b) List Custom Properties
This refers to custom properties that are either of type List or Multi-List. Click on the hyperlink of the list custom property under Incident Custom Properties to bring up the custom property mapping configuration screen. For list custom properties there will be a textbox for both the custom field itself and a mapping table for each of the custom property values that need to be mapped:
First you need to find the ID of the custom field in Redmine that matches this custom property in SpiraTeam. This should be entered in the 'External Key' field below the name of the custom property.
Next for each of the Property Values in the table (in the lower half of the page) you need to enter the full name (not the id this time) of the custom field value as specified in Redmine.
Once you have updated the various mapping sections, you are now ready to use the service.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTeam-with-Redmine/#using-spiratest-with-redmine","title":"Using SpiraTest with Redmine","text":"Now that the integration service has been configured and the service started, initially any incidents created in SpiraTeam for the specified projects will be imported into Redmine. At this point we recommend opening the Windows Event Viewer and choosing the Application Log. In this log any error messages raised by the Data Synchronization service will be displayed. If you see any error messages at this point, we recommend immediately stopping the service and checking the various mapping entries. If you cannot see any issues with the mapping information, we recommend sending a copy of the event log message(s) to Inflectra customer services (support@inflectra.com) who will help you troubleshoot the problem.
To use SpiraTeam with Redmine on an ongoing basis, we recommend the following general processes be followed:
When running tests in SpiraTeam, defects found should be logged through the Test Execution Wizard as normal.
Developers can log new defects into either SpiraTeam or Redmine. In either case they will get loaded into the other system.
Once created in one of the systems and successfully replicated to the other system, the incident should not be modified again inside SpiraTeam
All data changes to the issue should be made inside Redmine.
To enforce this, you can modify the workflows set up in SpiraTeam so that the various fields are marked as inactive for all the incident statuses other than the \"New\" status.
This will allow someone to submit an incident in SpiraTeam, but will prevent them making changes in conflict with Redmine after that point.
As the issue progresses through the Redmine workflow, changes to the status, priority, tracker, and target version will be updated automatically in SpiraTeam, and any notes added will be added to SpiraTeam as new comments. In essence, SpiraTeam acts as a read-only viewer of these incidents.
You are now able to perform test coverage and incident reporting inside SpiraTeam using the test cases managed by SpiraTeam and the incidents managed on behalf of SpiraTeam inside Redmine.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTest-with-Bugzilla/","title":"Using SpiraTest with Bugzilla","text":"This section outlines how to use SpiraTest in conjunction with the open-source Bugzilla bug tracking system. The built-in integration service allows the quality assurance team to manage their requirements and test cases in SpiraTest, execute test runs in SpiraTest, and then have the new incidents generated during the run be automatically loaded into Bugzilla. Once the incidents are loaded into Bugzilla as bugs, the development team can then manage the lifecycle of these bugs in Bugzilla, and have the status changes in Bugzilla be reflected back in SpiraTest.
In addition, if you are using Bugzilla 4.x or higher, any issues logged directly into Bugzilla will get imported into SpiraTeam so that they can be linked to test cases and requirements.
Set up data synchronization
STOP! Please make sure you have first read the instructions to set up the data sync before proceeding!
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTest-with-Bugzilla/#configuring-the-plug-in","title":"Configuring the Plug-In","text":"The next step is to configure the plug-in within SpiraTeam so that the system knows how to access the Bugzilla server. To start the configuration, please open up SpiraTeam in a web browser, log in using a valid account that has System-Administration level privileges and click on the System > Data Synchronization administration option from the left-hand navigation:
This screen lists all the plug-ins already configured in the system. Depending on whether you chose the option to include sample data in your installation or not, you will see either an empty screen or a list of sample data-synchronization plug-ins.
If you already see an entry for BugzillaDataSync you should click on its \"Edit\" link. If you don't see such an entry in the list, please click on the [Add] button instead. In either case you will be taken to the following screen where you can enter or modify the Bugzilla Data-Synchronization plug-in:
You need to fill out the following fields for the Bugzilla Plug-in to operate correctly:
Name -- this needs to be set to BugzillaDataSync. This needs to match the name of the plug-in DLL assembly that was copied into the C:\\Program Files\\SpiraTeam\\Bin folder (minus the .dll file extension). If you renamed the BugzillaDataSync.dll file for any reason, then you need to change the name here to match.
Description -- this should be set to a description of the plug-in. This is an optional field that is used for documentation purposes and is not actually used by the system.
Connection Info -- this should the full URL to the Bugzilla installation's web-service API. This is typically http://<Bugzilla server name>/xmlrpc.cgi
Login -- this should be set to a valid login to the Bugzilla installation -- typically an email address. The login needs to have permissions to create and view bugs within Bugzilla.
Password -- this should be set to the password of the login specified above.
Time Offset -- normally this should be set to zero, but if you find that issues being changed in Bugzilla are not being updated in SpiraTeam, try increasing the value as this will tell the data-synchronization plug-in to add on the time offset (in hours) when comparing date-time stamps. Also if your Bugzilla installation is running on a server set to a different time-zone, then you should add in the number of hours difference between the servers' time-zones here.
Auto-Map Users -- this is not currently used by the Bugzilla data-sync plug-in and can be ignored.
Custom 01 -- When connecting to Bugzilla, sometimes the connection gets dropped by the server without notifying the plug-in. This happens when using HTTP 1.1 Keep-Alive connections. If you set this property to \"False\", it will tell the plug-in to not-use HTTP keep-alives when connecting to Bugzilla, otherwise set it to \"True\".
Custom 02 -- When connecting to a Bugzilla instance that is running under HTTPS (SSL) this custom property can be set to determine if the plug-in should verify that the SSL certificate is a trusted root certificate. Set to \"True\" if you are using an SSL certificate that was issued by a trusted Certification Authority, and set to \"False\" if you are using a self-signed certificate.
Custom 03 -- 05 -- these are not currently used by the Bugzilla data-sync plug-in and can be left blank.
Next, you need to configure the data mapping between SpiraTeam and Bugzilla. This allows the various projects, users, releases, incident types, statuses, priorities and custom property values used in the two applications to be related to each other. This is important, as without a correct mapping, there is no way for the integration service to know that an \"Duplicate\" incident in SpiraTeam is the same as an \"UNCONFIRMED\" bug in Bugzilla (for example).
The following mapping information needs to be setup in SpiraTeam:
The mapping of the project identifiers for the projects that need to be synchronized
The mapping of users in the system
The mapping of releases (equivalent to Bugzilla versions) in the system
The mapping of the various standard fields in the system
The mapping of the various custom properties in the system
Each of these is explained in turn below:
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTest-with-Bugzilla/#configuring-the-project-mapping","title":"Configuring the Project Mapping","text":"From the data synchronization administration page, you need to click on the \"View Project Mappings\" hyperlink next to the Bugzilla plug-in name. This will take you to the data-mapping home page for the currently selected project:
If the project name does not match the name of the project you want to configure the data-mapping for, click on the \"(Change Project)\" hyperlink to change the current project.
To enable this project for data-synchronization with Bugzilla, you need to enter:
External Key -- This should be set to the name of the equivalent Product in Bugzilla.
Active Flag -- Set this to 'Yes' so that SpiraTeam knows that you want to synchronize data for this project. Once the project has been completed, setting the value to \"No\" will stop data synchronization, reducing network utilization.
Click [Update] to confirm these settings. Once you have enabled the project for data-synchronization, you can now enter the other data mapping values outlined below.
Note: Once you have successfully configured the project, when creating a new project, you should choose the option to \"Create Project from Existing Project\" rather than \"Use Default Template\" so that all the project mappings get copied across to the new project.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTest-with-Bugzilla/#configuring-the-user-mapping","title":"Configuring the User Mapping","text":"To configure the mapping of users in the two systems, you need to go to Administration > Users > View Edit Users, which will bring up the list of users in the system. Then click on the \"Edit\" button for a particular user that will be editing issues in Bugzilla:
You will notice that below the Active flag for the user is a list of all the configured data-synchronization plug-ins. In the text box next to the Bugzilla Data-Sync plug-in you need to enter the login for this username in Bugzilla. This will allow the data-synchronization plug-in to know which user in SpiraTeam match which equivalent user in Bugzilla. Click [Update] once you've entered the appropriate login name. You should now repeat for the other users who will be active in both systems.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTest-with-Bugzilla/#configuring-the-release-mapping","title":"Configuring the Release Mapping","text":"Now that the projects and users have been mapped correctly, we need to configure the mapping between Releases/Iterations in SpiraTeam and Versions in Bugzilla. To do this, please navigate to Planning > Releases and click on the Release/Iteration in question. Make sure you have the 'Overview' tab visible and expand the \"Details\" section of the release/iteration:
In addition to the standard fields and custom properties configured for Releases, you will see an additional text property called \"BugzillaDataSync ID\" that is used to store the mapped external identifier for the equivalent Version in Bugzilla. You need to enter the name of the equivalent version in Bugzilla, enter it into this text-box and click [Save]. You should now repeat for all the other releases and iterations in the project.
If you are using the plugin for Bugzilla 4.x then any Versions that have already been created in Bugzilla will be automatically imported into SpiraTeam if they do not already exist in SpiraTeam and they have not already been mapped.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTest-with-Bugzilla/#configuring-the-standard-field-mapping","title":"Configuring the Standard Field Mapping","text":"Now that the projects, user and releases have been mapped correctly, we need to configure the standard incident fields. To do this, go to Administration > System > Data Synchronization and click on the \"View Project Mappings\" for the BugzillaDataSync plug-in entry:
From this screen, you need to click on Priority, Severity and Status in turn to configure their values:
a) Incident Status
Click on the \"Status\" hyperlink under Incident Standard Fields to bring up the Incident status mapping configuration screen:
The table lists each of the incident statuses available in SpiraTeam and provides you with the ability to enter the matching Bugzilla bug status for each one. You can map multiple SpiraTeam fields to the same Bugzilla fields (e.g. New and Open in SpiraTeam are both equivalent to NEW in Bugzilla), in which case only one of the two values can be listed as Primary = Yes as that's the value that's used on the reverse synchronization (from Bugzilla > SpiraTeam).
We recommend that you always point the New and Open statuses inside SpiraTeam to point to the NEW status inside Bugzilla and make Open in SpiraTeam the Primary status of the two. This is recommended so that as new incidents in SpiraTeam get synched over to Bugzilla, they will get switched to the NEW status in Bugzilla which will then be synched back to \"Open\" in SpiraTeam. That way you'll be able to see at a glance which incidents have been synched with Bugzilla and those that haven't.
b) Incident Priority
Click on the \"Priority\" hyperlink under Incident Standard Fields to bring up the Incident Priority mapping configuration screen:
The table lists each of the incident priorities available in SpiraTeam and provides you with the ability to enter the matching Bugzilla priority for each one. You can map multiple SpiraTeam fields to the same Bugzilla fields, in which case only one of the two values can be listed as Primary = Yes as that's the value that's used on the reverse synchronization (from Bugzilla > SpiraTeam).
c) Incident Severity
Click on the \"Severity\" hyperlink under Incident Standard Fields to bring up the Incident severity mapping configuration screen:
The table lists each of the incident severities available in SpiraTeam and provides you with the ability to enter the matching Bugzilla severity for each one. You can map multiple SpiraTeam fields to the same Bugzilla fields, in which case only one of the two values can be listed as Primary = Yes as that's the value that's used on the reverse synchronization (from Bugzilla > SpiraTeam).
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTest-with-Bugzilla/#configuring-the-custom-property-mapping","title":"Configuring the Custom Property Mapping","text":"Now that the various SpiraTeam standard fields have been mapped correctly, we need to configure the custom property mappings. This is used for custom properties in SpiraTeam that are used to map to standard fields in Bugzilla (Component, Hardware, Operating System and Resolution) that don't exist in SpiraTeam. You need to make sure that you have first added custom lists in SpiraTeam that contain the list of Components, Hardware platforms and Operating Systems used in Bugzilla and that you have setup those lists as Custom Properties on the Incident artifact type.
Once that's done, from the View/Edit Project Data Mapping screen, you need to click on the name of the Incident Custom Property that you want to add data-mapping information for. We will consider the four different types of mapping that you might want to enter in turn:
a) Bugzilla's Component Field
If your instance of Bugzilla requires that all new bugs are submitted with a 'Component' then you will need to fill out this section. You first need to create an incident custom property in SpiraTeam of type 'LIST' that contains the various component names that exist inside Bugzilla.
Then click on the hyperlink of this new list custom property under Incident Custom Properties to bring up the custom property mapping configuration screen:
First you need to enter the word \"Component\" as the External Key of the custom property. This tells the data-sync plug-in that the custom property in SpiraTeam should be mapped to built-in Component field in Bugzilla.
Next for each of the Property Values in the table (in the lower half of the page) you need to enter the Bugzilla name of the various Components that are configured in Bugzilla.
b) Bugzilla's Operating System Field
If your instance of Bugzilla requires that all new issues are submitted with an 'Operating System' then you will need to fill out this section. You first need to create an incident custom property in SpiraTeam of type 'LIST' that contains the various operating system names that exist inside Bugzilla.
Then click on the hyperlink of this new list custom property under Incident Custom Properties to bring up the custom property mapping configuration screen:
First you need to enter the word \"OperatingSystem\" as the External Key of the custom property. This tells the data-sync plug-in that the custom property in SpiraTeam should be mapped to built-in Operating System field in Bugzilla.
Next for each of the Property Values in the table (in the lower half of the page) you need to enter the Bugzilla name of the various Operating System values that are configured in Bugzilla.
c) Bugzilla's Hardware Field
If your instance of Bugzilla requires that all new issues are submitted with a 'Hardware' value then you will need to fill out this section. You first need to create an incident custom property in SpiraTeam of type 'LIST' that contains the various hardware platform names that exist inside Bugzilla.
Then click on the hyperlink of this new list custom property under Incident Custom Properties to bring up the custom property mapping configuration screen:
First you need to enter the word \"Hardware\" as the External Key of the custom property. This tells the data-sync plug-in that the custom property in SpiraTeam should be mapped to built-in Hardware field in Bugzilla.
Next for each of the Property Values in the table (in the lower half of the page) you need to enter the Bugzilla name of the various Hardware platforms that are configured in Bugzilla.
d) Bugzilla's Resolution Field (Optional)
When incidents in SpiraTeam are updated with changes made in Bugzilla, the value of the Bugzilla resolution field (FIXED, INVALID, WONTFIX, LATER, REMIND, DUPLICATE, WORKSFORME, MOVED, DEPLOY) is used to populate the Resolution/Comments text box within SpiraTeam.
However the Resolution/Comments field in SpiraTeam cannot be displayed in the incident list page as it's a long text-field, so if you would like to be able to see the list of Bugzilla Resolution codes displayed in a list, it is necessary to add a TEXT custom property to Incidents that can be used to store this returned value and then be filtered in the list. The rest of this section describes how to map this text custom property so that it picks up the Resolution field values from Bugzilla.
To configure the mapping, click on the hyperlink of this new text custom property under Incident Custom Properties to bring up the custom property mapping configuration screen:
All you need to do on this screen is enter the word \"Resolution\" in the External Key textbox and the data-sync plug-in will know that this custom property is mapped to the built-in Resolution field in Bugzilla.
Once you have updated the various mapping sections, you are now ready to use the synchronization.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTest-with-Bugzilla/#using-spiratest-with-bugzilla_1","title":"Using SpiraTest with Bugzilla","text":"Now that the integration service has been configured and the service started, initially any incidents created in SpiraTeam for the specified projects will be imported into Bugzilla. At this point we recommend opening the Windows Event Viewer and choosing the Application Log. In this log any error messages raised by the Data Synchronization service will be displayed. If you see any error messages at this point, we recommend immediately stopping the service and checking the various mapping entries. If you cannot see any issues with the mapping information, we recommend sending a copy of the event log message(s) to Inflectra customer services (support@inflectra.com) who will help you troubleshoot the problem.
To use SpiraTeam with Bugzilla on an ongoing basis, we recommend the following general processes be followed:
When running tests in SpiraTeam, defects found should be logged through the 'Add Incident' option as normal.
Once an incident has been created during the running of the test, it will now be populated across into Bugzilla as a bug. It will be populated with the information captured in SpiraTeam.
At this point, the incident should not be acted upon inside SpiraTeam, and all data changes to the issue should be made inside Bugzilla. To enforce this, you can modify the workflows set up in SpiraTeam so that the various fields are marked as inactive for all the incident statuses other than the \"New\" status. This will allow someone to submit an incident in SpiraTeam, but will prevent them making changes in conflict with Bugzilla after that point.
As the issue progresses through the Bugzilla workflow, changes to the status, priority, severity, and resolution will be updated automatically in SpiraTeam. In essence, SpiraTeam acts as a read-only viewer of these incidents.
If you are using the plugin for Bugzilla 4.x, changes to the hardware, operating system and component will also be synchronized back into SpiraTeam. In addition, any comments added to the bug in Bugzilla 4.x will get added to the corresponding incident in SpiraTeam
You are now able to perform test coverage and incident reporting inside SpiraTeam using the test cases managed by SpiraTeam and the incidents managed on behalf of SpiraTeam inside Bugzilla.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTest-with-FogBugz/","title":"Using SpiraTest with FogBugz","text":"This section outlines how to use SpiraTest, SpiraPlan or SpiraTeam (hereafter referred to as SpiraTeam) in conjunction with the FogBugz issue/bug tracking system. The built-in integration service allows the quality assurance team to manage their requirements and test cases in SpiraTeam, execute test runs in SpiraTest, and then have the new incidents generated during the run be automatically loaded into FogBugz.
Once the incidents are loaded into FogBugz as cases, the development team can then manage the lifecycle of these cases in FogBugz, and have the status changes in FogBugz be reflected back in SpiraTeam. In addition, any cases logged into FogBugz will get imported into SpiraTeam so that they can be linked to test cases and requirements.
Set up data synchronization
STOP! Please make sure you have first read the instructions to set up the data sync before proceeding!
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTest-with-FogBugz/#configuring-the-plug-in","title":"Configuring the Plug-In","text":"The next step is to configure the plug-in within SpiraTeam so that the system knows how to access the FogBugz server. To start the configuration, please open up SpiraTeam in a web browser, log in using a valid account that has System-Administration level privileges and click on the System > Data Synchronization administration option from the left-hand navigation:
This screen lists all the plug-ins already configured in the system. Depending on whether you chose the option to include sample data in your installation or not, you will see either an empty screen or a list of sample data-synchronization plug-ins.
If you already see an entry for FogBugzDataSync you should click on its \"Edit\" link. If you don't see such an entry in the list, please click on the [Add] button instead. In either case you will be taken to the following screen where you can enter or modify the FogBugz Data-Synchronization plug-in:
You need to fill out the following fields for the FogBugz Plug-in to operate correctly:
Name -- this needs to be set to FogBugzDataSync. This needs to match the name of the plug-in DLL assembly that was copied into the C:\\Program Files\\SpiraTeam\\Bin folder (minus the .dll file extension). If you renamed the FogBugzDataSync.dll file for any reason, then you need to change the name here to match.
Caption -- this is the display name of the plugin, typically just \"FogBugz\". If you have multiple instances of FogBugz, they could have different captions.
Description -- this should be set to a description of the plug-in. This is an optional field that is used for documentation purposes and is not actually used by the system.
Connection Info -- this should the URL that you use to access your instance of FogBugz (e.g. https://mycompany.fogbugz.com)
Login -- this should be set to a valid login to the FogBugz installation. The login needs to have permissions to create and view cases and versions within FogBugz.
Password -- this should be set to the password of the login specified above.
Time Offset -- normally this should be set to zero, but if you find that cases being changed in FogBugz are not being updated in SpiraTeam, try increasing the value as this will tell the data-synchronization plug-in to add on the time offset (in hours) when comparing date-time stamps. Also if your FogBugz installation is running on a server set to a different time-zone, then you should add in the number of hours difference between the servers' time-zones here.
Auto-Map Users -- this is not currently used by the FogBugz data-sync plug-in and can be ignored.
Custom 01 -- When connecting to FogBugz, sometimes the connection gets dropped by the server without notifying the plug-in. This happens when using HTTP 1.1 Keep-Alive connections. If you set this property to \"False\", it will tell the plug-in to not-use HTTP keep-alives when connecting to FogBugz, otherwise set it to \"True\".
Custom 02 -- When connecting to a FogBugz instance that is running under HTTPS (SSL) this custom property can be set to determine if the plug-in should verify that the SSL certificate is a trusted root certificate. Set to \"True\" if you are using an SSL certificate that was issued by a trusted Certification Authority, and set to \"False\" if you are using a self-signed certificate.
Custom 03 -- Normally all rich text (HTML) descriptions in SpiraTeam are converted into plain text when added to FogBugz. However, more recent version of FogBugz can now support rich text. So if you have rich-text enabled in your instance of FogBugz, you should enter the world \"True\" in Custom 03 to enable rich text description transfer.
Custom 04 -- Normally you can leave this blank. However if you want to prevent the plugin from getting new cases from FogBugz (that did not originate in SpiraTest), set it to \"False\".
Custom 05 -- this is not currently used by the FogBugz data-sync plug-in and can be left blank.
Next, you need to configure the data mapping between SpiraTeam and FogBugz. This allows the various projects, users, releases, incident types, statuses, priorities and custom property values used in the two applications to be related to each other. This is important, as without a correct mapping, there is no way for the integration service to know that an \"Enhancement\" in SpiraTeam is the same as a \"Feature\" in FogBugz (for example).
The following mapping information needs to be setup in SpiraTeam:
The mapping of the project identifiers for the projects that need to be synchronized
The mapping of users in the system
The mapping of releases (equivalent to FogBugz releases/fix-fors) in the system
The mapping of the various standard fields in the system
The mapping of the various custom properties in the system
Each of these is explained in turn below:
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTest-with-FogBugz/#configuring-the-project-mapping","title":"Configuring the Project Mapping","text":"From the data synchronization administration page, you need to click on the \"View Project Mappings\" hyperlink next to the FogBugz plug-in name. This will take you to the data-mapping home page for the currently selected project:
If the project name does not match the name of the project you want to configure the data-mapping for, click on the \"(Change Project)\" hyperlink to change the current project.
To enable this project for data-synchronization with FogBugz, you need to enter:
External Key -- This should be set to the ID of the project in FogBugz. This can be found by navigating to Settings > Projects in FogBugz:
Then hover the mouse over the project name. The project ID will be displayed in the URL line as ixProject-X where X is the numeric ID of the project.
Active Flag -- Set this to 'Yes' so that SpiraTeam knows that you want to synchronize data for this project. Once the project has been completed, setting the value to \"No\" will stop data synchronization, reducing network utilization.
Click [Update] to confirm these settings. Once you have enabled the project for data-synchronization, you can now enter the other data mapping values outlined below.
Note: Once you have successfully configured the project, when creating a new project, you should choose the option to \"Create Project from Existing Project\" rather than \"Use Default Template\" so that all the project mappings get copied across to the new project.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTest-with-FogBugz/#configuring-the-user-mapping","title":"Configuring the User Mapping","text":"To configure the mapping of users in the two systems, you need to go to Administration > Users > View Edit Users, which will bring up the list of users in the system. Then click on the \"Edit\" button for a particular user that will be editing cases in FogBugz:
You will notice that below the Active flag for the user is a list of all the configured data-synchronization plug-ins. In the text box next to the FogBugz Data-Sync plug-in you need to enter the ID of this user in FogBugz. This will allow the data-synchronization plug-in to know which user in SpiraTeam match which equivalent user in FogBugz. The ID can be found in FogBugz by going to Settings > Users:
Then hover the mouse over the user's name. The user ID will be displayed in the URL line as ixPerson-X where X is the numeric ID of the user.
Back in SpiraTeam, click [Update] once you've entered the appropriate user ID in the mapping box. You should now repeat for the other users who will be active in both systems.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTest-with-FogBugz/#configuring-the-release-mapping","title":"Configuring the Release Mapping","text":"When the data-synchronization service runs, when it comes across a release/iteration in SpiraTeam that it has not seen before, it will create a corresponding Release/Fix-For in FogBugz. Similarly if it comes across a new Release/Fix-For in FogBugz that it has not seen before, it will create a new Release in SpiraTeam. Therefore when using both systems together, it is recommended that you only enter new Releases/Versions in one system and let the data-synchronization service add them to the other system.
However you may start out with the situation where you already have pre-existing Releases/Versions in both systems that you need to associate in the data-mapping. If you don't do this, you may find that duplicates get created when you first enable the data-synchronization service. Therefore for any Releases/Iterations that already exist in BOTH systems please navigate to Planning > Releases and click on the Release/Iteration in question. Make sure you have the 'Overview' tab visible and expand the \"Details\" section of the release/iteration:
In addition to the standard fields and custom properties configured for Releases, you will see an additional text property called \"FogBugzDataSync ID\" that is used to store the mapped external identifier for the equivalent Release in FogBugz. You need to locate the ID of the equivalent Release in FogBugz, enter it into this text-box and click [Save]. You should now repeat for all the other pre-existing releases.
The FogBugz Release ID can be found by going to Settings > Projects and viewing the releases:
Then hover the mouse over the release name. The release ID will be displayed in the URL line as ixFixFor-X where X is the numeric ID of the release.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTest-with-FogBugz/#configuring-the-standard-field-mapping","title":"Configuring the Standard Field Mapping","text":"Now that the projects, user and releases have been mapped correctly, we need to configure the standard incident fields. To do this, go to Administration > System > Data Synchronization and click on the \"View Project Mappings\" for the FogBugzDataSync plug-in entry:
From this screen, you need to click on Priority, Status and Type in turn to configure their values:
a) Incident Type
Click on the \"Type\" hyperlink under Incident Standard Fields to bring up the Incident type mapping configuration screen:
The table lists each of the incident types available in SpiraTeam and provides you with the ability to enter the matching FogBugz case category ID for each one. You can map multiple SpiraTeam fields to the same FogBugz fields (e.g. Bug and Incident in SpiraTeam are both equivalent to Bug in FogBugz), in which case only one of the two values can be listed as Primary - Yes as that's the value that's used on the reverse synchronization (from FogBugz > SpiraTeam).
The values for the category ID are fixed for FogBugz and should be:
Category Name Category ID Bug > 1 Feature > 2 Inquiry > 3So, depending on which types have been configured in SpiraTeam, you'll need to adjust the mapping so that the appropriate SpiraTeam types correspond to the equivalent FogBugz category.
b) Incident Status
Click on the \"Status\" hyperlink under Incident Standard Fields to bring up the Incident status mapping configuration screen:
The table lists each of the incident statuses available in SpiraTeam and provides you with the ability to enter the matching FogBugz case status ID for each one. You can map multiple SpiraTeam fields to the same FogBugz fields (e.g. New, Open, Assigned, and Reopen in SpiraTeam are all equivalent to Active in FogBugz), in which case only one of the four values can be listed as Primary - Yes as that's the value that's used on the reverse synchronization (from FogBugz > SpiraTeam).
We recommend that you always point the New, Open, Assigned and Reopen statuses inside SpiraTeam to point to the ID for \"Assigned\" inside FogBugz and make Assigned in SpiraTeam the Primary status of the four. This is recommended so that as new incidents in SpiraTeam get synched over to FogBugz, they will get switched to the Active status in FogBugz which will then be synched back to \"Assigned\" in SpiraTeam. That way you'll be able to see at a glance which incidents have been synched with FogBugz and those that haven't.
You also might want to consider changing the statuses in SpiraTeam to match the 16 discrete statuses in FogBugz to make things easier for your users. In which case you'll need to create the new statuses and configure the workflow (as described in the SpiraTeam Administration Guide).
The status IDs in FogBugz are fixed and should be:
Status ID Status Name > 1 Active > 2 Resolved (Fixed) > 3 Resolved (Not Reproducible) > 4 Resolved (Duplicate) > 5 Resolved (Postponed) > 6 Resolved (Won't Fix) > 7 Resolved (By Design) > 8 Resolved (Implemented) > 9 Resolved (Won't Implement) > 10 Resolved (Already Exists) > 11 Resolved (Responded) > 12 Resolved (Won't Respond) > 13 Resolved (SPAM) > 14 Resolved (Waiting For Info) > 15 Resolved (Completed) > 16 Resolved (Canceled)In addition to these statuses, FogBugz also has the concept of a 'Closed' case which is one where the case has been assigned to the special Closed user (user id 1). If you want to map a SpiraTeam status to this special closed status, for the external key just enter 'Closed' instead of a numeric ID and that will tell the plug-in to associate that SpiraTest status with the special condition of a FogBugz case that is assigned to the 'closed' user.
c) Incident Priority
Click on the \"Priority\" hyperlink under Incident Standard Fields to bring up the Incident Priority mapping configuration screen:
The table lists each of the incident priorities available in SpiraTeam and provides you with the ability to enter the matching FogBugz priority ID for each one. You can map multiple SpiraTeam fields to the same FogBugz fields, in which case only one of the two values can be listed as Primary - Yes as that's the value that's used on the reverse synchronization (from FogBugz > SpiraTeam).
Since both applications allow you to customize the priority list, we recommend that you modify the list in both systems to be the same and then map them one to one as this will be easier for users to understand. In the example above, we have switched over SpiraTeam to match the priorities in FogBugz, but you could do it the other way around as well.
The FogBugz Priority IDs can be found by going to Settings > Priorities and viewing the priorities:
The priority ID is the \"priority number\" value displayed in the left hand column.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTest-with-FogBugz/#configuring-the-custom-property-mapping","title":"Configuring the Custom Property Mapping","text":"Now that the various SpiraTeam standard fields have been mapped correctly, we need to configure the custom property mappings. This is used for custom properties in SpiraTeam that are used to map to standard fields in FogBugz (Computer, Version and Area) that don't exist in SpiraTeam.
From the View/Edit Project Data Mapping screen, you need to click on the name of the Incident Custom Property that you want to add data-mapping information for. We will consider the three different types of mapping that you typically will want to enter:
a) FogBugz's Computer Field
You first need to create an incident custom property in SpiraTeam of type 'TEXT' that will be used to store the Computer description within SpiraTeam.
Then click on the hyperlink of this new text custom property under Incident Custom Properties to bring up the custom property mapping configuration screen:
All you need to do on this screen is enter the word \"Computer\" in the External Key textbox and the data-sync plug-in will know that this custom property is mapped to the built-in Computer field in FogBugz.
b) FogBugz's Version Field
You first need to create an incident custom property in SpiraTeam of type 'TEXT' that will be used to store the Version description within SpiraTeam.
Then click on the hyperlink of this new text custom property under Incident Custom Properties to bring up the custom property mapping configuration screen:
All you need to do on this screen is enter the word \"Version\" in the External Key textbox and the data-sync plug-in will know that this custom property is mapped to the built-in Version field in FogBugz.
c) FogBugz's Area Field
You first need to create an incident custom property in SpiraTeam of type 'LIST' that will be used to store the list of project areas within SpiraTeam. You will need to create a new custom list to store the different possible values of area and then use that list when creating the new custom property.
Then back on the Data Mapping page, click on the hyperlink of this new list custom property under Incident Custom Properties to bring up the custom property mapping configuration screen:
First you need to enter the word \"Area\" as the External Key of the custom property. This tells the data-sync plug-in that the custom property in SpiraTeam should be mapped to built-in Area field in FogBugz.
Next for each of the Property Values in the table (in the lower half of the page) you need to enter the FogBugz ID of the various Areas that are configured in FogBugz. The FogBugz Area ID can be found by going to Settings > Projects and viewing the areas in the project:
Then hover the mouse over the area name. The area ID will be displayed in the URL line as ixArea-X where X is the numeric ID of the area.
d) FogBugz's Parent Case Field
FogBugz lets you link a new case with an existing 'parent' case. You can make this possible from within SpiraTeam by simply creating a new custom text property and mapping to the special External Key - Parent:
Users will then enter the FogBugz ID of an existing case when they a log a new SpiraTeam incidents and the data-synchronization system will know how to associate the two cases.
Once you have updated the various mapping sections, you are now ready to use the synchronization.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTest-with-FogBugz/#using-spirateam-with-fogbugz","title":"Using SpiraTeam with FogBugz","text":"Now that the integration service has been configured and the service started, initially any incidents created in SpiraTeam for the specified projects will be imported into FogBugz and any existing cases in FogBugz will get loaded into SpiraTeam. At this point we recommend opening the Windows Event Viewer and choosing the Application Log. In this log any error messages raised by the SpiraTeam Data Sync Service will be displayed. If you see any error messages at this point, we recommend immediately stopping the SpiraTeam service and checking the various mapping entries. If you cannot see any cases with the mapping information, we recommend sending a copy of the event log message(s) to Inflectra customer services (support@inflectra.com) who will help you troubleshoot the problem.
To use SpiraTeam with FogBugz on an ongoing basis, we recommend the following general processes be followed:
When running tests in SpiraTest or SpiraTeam, defects found should be logged through the Test Execution Wizard as normal.
Developers using FogBugz can log new defects into either SpiraTeam or FogBugz. In either case they will get loaded into the other system.
Once created in one of the systems and successfully replicated to the other system, the incident should not be modified again inside SpiraTeam. Since FogBugz is considered the master system for incidents/cases, all data changes to the case should be made inside FogBugz. To enforce this, you should modify the workflows set up in SpiraTeam so that the various fields are marked as inactive for all the incident statuses other than the \"New\" status. This will allow someone to submit an incident in SpiraTeam, but will prevent them making changes in conflict with FogBugz after that point.
As the case progresses through the FogBugz workflow, changes to the type of case, changes to its status, priority, description and resolution will be updated automatically in SpiraTeam. In essence, SpiraTeam acts as a read-only viewer of these incidents.
You are now able to perform test coverage and incident reporting inside SpiraTest/SpiraTeam using the test cases managed by SpiraTest/SpiraTeam and the incidents managed on behalf of SpiraTest/SpiraTeam inside FogBugz.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTest-with-MS-TFS/","title":"Using SpiraTest with Microsoft Azure DevOps (TFS)","text":"This section outlines how to use SpiraTest, SpiraPlan or SpiraTeam (hereafter referred to as SpiraTeam) in conjunction with the work item tracking functionality of Microsoft Azure DevOps, also known as Microsoft Team Foundation Server (TFS) hereafter referred to as TFS for brevity.
The built-in integration service allows the quality assurance team to manage their requirements and test cases in SpiraTeam, execute test runs in SpiraTest, and then have the new incidents generated during the run be automatically loaded into TFS. Once the incidents are loaded into TFS as work items, the development team can then manage the lifecycle of these work items in TFS, and have the status changes in TFS be reflected back in SpiraTeam.
Similarly, as the requirements are decomposed into discrete project tasks in SpiraTeam, the integration service will automatically load these new tasks into TFS as task work items where the development team can manage their lifecycle, with schedule and progress changes in TFS being reflected back in SpiraTeam.
Set up data synchronization
STOP! Please make sure you have first read the instructions to set up the data sync before proceeding!
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTest-with-MS-TFS/#configuring-the-plug-in","title":"Configuring the Plug-In","text":"The next step is to configure the plug-in within SpiraTeam so that the system knows how to access the TFS server. Inside SpiraPlan, go to the Administration page and navigate to Integration > Data Synchronization. Check if you see a plug-in called MsTfsDataSync, as shown below:
What do if the plug-in is not there
If you don't see the plug-in in the list, click the \"\"Add\" button at the top of the page. This opens the generic Data Sync plug-in details page. This is not yet customized to help you more easily set up the data sync. We recommend, adding just enough information now to create the plug-in. Then edit the plug-in after its made to complete the process.
To start, fill in the following fields:
Now click \"Add\" to save the plug-in and return you to the list of plug-ins. Now follow the instructions below.
With the plug-in place, click on its \"edit\" button to open its detailed settings page.
You need to fill out the following fields for the TFS Plug-in to operate correctly:
Auto-Map Users: This changes the way the plugin maps users in SpiraTeam to those in TFS:
Windows Domain: This is used to specify the Windows Active Directory Domain that the Windows user specified above is a member of. For Azure DevOps in the cloud, you should leave this field blank.
If you are using Microsoft Azure DevOps Online instead of a local TFS instance, you will need to use a Personal Access Token (PAT) to connect to the instance of Azure DevOps from SpiraTeam.
To get a PAT, login to Azure DevOps and access your user profile:
In the popup menu, Click on the Personal access tokens option. This will display the list of already issued/active personal access tokens:
Click on the + New Token button to create a new personal access token:
You can give it a logical name (e.g. \"Spira\") and give it permissions to:
Azure Devops will then create a personal access token that you should copy to the clipboard and store somewhere secure (e.g. a password manager):
You will now use this personal access token as the \"password\" that SpiraTeam will use to connect to Azure DevOps. For the username, you can just use your standard Azure DevOps login (in fact you can use anything, it will only be checking the PAT).
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTest-with-MS-TFS/#configuring-the-data-mapping","title":"Configuring the Data Mapping","text":"Next, you need to configure the data mapping between SpiraTeam and TFS. This allows the various projects, users, releases, incident types, statuses, priorities and custom property values used in the two applications to be related to each other. This is important, as without a correct mapping, there is no way for the integration service to know that a \"Not Reproducible\" incident in SpiraTeam is the same as a \"Closed + Cannot Reproduce\" bug work item in TFS (for example).
The following mapping information needs to be setup in SpiraTeam:
Note: If using SpiraTest, you do not need to setup the last two sets of mappings as Tasks are not available in SpiraTest.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTest-with-MS-TFS/#configuring-the-project-mapping","title":"Configuring the Project Mapping","text":"From the data synchronization administration page, you need to click on the \"View Project Mappings\" hyperlink next to the TFS plug-in name. This will take you to the data-mapping home page for the currently selected project:
If the project name does not match the name of the project you want to configure the data-mapping for, click on the \"(Change Project)\" hyperlink to change the current project.
To enable this project for data-synchronization with TFS, you need to enter:
External Key -- This should be set to the name of the project in TFS as visible from the Visual Studio Team Explorer or web interface:
OR
Active Flag -- Set this to 'Yes' so that SpiraTeam knows that you want to synchronize data for this project. Once the project has been completed, setting the value to \"No\" will stop data synchronization, reducing network utilization.
Click [Update] to confirm these settings. Once you have enabled the project for data-synchronization, you can now enter the other data mapping values outlined below.
Note: Once you have successfully configured the project, when creating a new project, you should choose the option to \"Create Project from Existing Project\" rather than \"Use Default Template\" so that all the project mappings get copied across to the new project.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTest-with-MS-TFS/#configuring-the-user-mapping","title":"Configuring the User Mapping","text":"To configure the mapping of users in the two systems, you need to go to Administration > Users > View Edit Users, which will bring up the list of users in the system. Then click on the \"Edit\" button for a particular user that will be editing work items in TFS:
You will notice that in the special Data Mapping tab, there is a list of all the configured data-synchronization plug-ins. In the text box next to the TFS Data-Sync plug-in you need to enter the full name of this Windows User (not the login). This is the name of the user as they appear inside work items within TFS:
This will allow the data-synchronization plug-in to know which user in SpiraTeam match which equivalent user in TFS. Click [Update] once you've entered the appropriate login name. You should now repeat for the other users who will be active in both systems.
If you have set the \"Auto-Map Users\" option in the TFS 2012 plugin, you can skip this section completely.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTest-with-MS-TFS/#configuring-the-release-mapping","title":"Configuring the Release Mapping","text":"When the data-synchronization service runs, when it comes across a release/iteration in SpiraTeam that it has not seen before, it will create a corresponding \"Iteration\" in TFS. Similarly if it comes across a new Iteration in TFS that it has not seen before, it will create a new Release/Iteration in SpiraTeam. Therefore when using both systems together, it is recommended that you only enter new Releases/Iterations in one system and let the data-synchronization service add them to the other system.
However you may start out with the situation where you already have pre-existing Releases/Iterations in both systems that you need to associate in the data-mapping. If you don't do this, you may find that duplicates get created when you first enable the data-synchronization service. Therefore for any Releases/Iterations that already exist in BOTH systems please navigate to Planning > Releases and click on the Release/Iteration in question. Make sure you have the 'Overview' tab visible and expand the \"Properties\" section of the release/iteration:
In addition to the standard fields and custom properties configured for Releases, you will see an additional text property called \"MsTfsDataSync ID\" that is used to store the mapped external identifier for the equivalent Version in TFS. You need to locate the ID of the equivalent Iteration in TFS, enter it into this text-box and click [Save]. You should now repeat for all the other pre-existing releases.
The TFS Iteration ID is not visible in the TFS user interface, but can instead be located by opening up the SQL Server that it's installed on, opening the 'TfsWorkItemTracking' database (in TFS 2010 it will named after your project collection instead) and locating the 'TreeNodes' table:
Once you have found the matching Iteration (by name), the numeric value stored in the ID column (the one on the left) is the value that needs to get added as the MsTfsDataSync ID inside SpiraTeam.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTest-with-MS-TFS/#configuring-the-standard-incident-field-mapping","title":"Configuring the Standard Incident Field Mapping","text":"Now that the projects, user and releases have been mapped correctly, we need to configure the standard incident fields. To do this, go to Administration > System > Data Synchronization and click on the \"View Project Mappings\" for the MsTfsDataSync plug-in entry:
From this screen, you need to click on Priority, Severity, Status and Type in turn to configure their values:
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTest-with-MS-TFS/#a-incident-type","title":"a) Incident Type","text":"Click on the \"Type\" hyperlink under Incident Standard Fields to bring up the Incident type mapping configuration screen:
The table lists each of the incident types available in SpiraTeam and provides you with the ability to enter the matching TFS work item type name for each one. To make this easier, we recommend that inside the Administration > Edit Incident Statuses screen you first make all incident types inactive except Risk, Issue and Bug since only those types make sense to synchronize with TFS.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTest-with-MS-TFS/#b-incident-status","title":"b) Incident Status","text":"Click on the \"Status\" hyperlink under Incident Standard Fields to bring up the Incident status mapping configuration screen:
The table lists each of the incident statuses available in SpiraTeam and provides you with the ability to enter the matching TFS work item State + Reason or State for each one.
TFS uses separate State (Active, Resolved, Closed) and Reason (Fixed, Duplicate, Not Fixed, etc.) code unlike SpiraTeam which uses a single status code. For maximum flexibility, the integration can work with either a mapped State or a mapped State+Reason.
If you want to have SpiraTeam statuses point to a specific TFS work item State and a specific Reason associated with that State, you need to concatenate the TFS State and Reason together with a 'plus' (+) sign so that the system knows that the incident status in SpiraTeam corresponds to that specific combination.
If you want to have SpiraTeam statuses simply point to a specific TFS work item State and let TFS assign the default Reason for that State, you simply map the SpiraTeam statuses to the State:
You can map multiple SpiraTeam fields to the same TFS fields (e.g. New and Open in SpiraTeam are both equivalent to 'Active+New' in TFS), in which case only one of the two values can be listed as Primary = Yes as that's the value that's used on the reverse synchronization (from TFS > SpiraTeam).
We recommend that you always point the New and Open statuses inside SpiraTeam to point to the \"Active+New\" TFS state+reason, and make Open in SpiraTeam the Primary status of the two. This is recommended so that as new incidents in SpiraTeam get synched over to TFS, they will get switched to the \"Active+New\" status in TFS which will then be synched back to \"Open\" in SpiraTeam. That way you'll be able to see at a glance which incidents have been synched with TFS and those that haven't.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTest-with-MS-TFS/#c-incident-priority","title":"c) Incident Priority","text":"Click on the \"Priority\" hyperlink under Incident Standard Fields to bring up the Incident Priority mapping configuration screen:
The table lists each of the incident priorities available in SpiraTeam and provides you with the ability to enter the matching TFS priority value for each one. To make this easier, we recommend that inside the Administration > Edit Incident Priorities screen you first make any statuses not used in TFS inactive in SpiraTeam.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTest-with-MS-TFS/#d-incident-severity","title":"d) Incident Severity","text":"Click on the \"Severity\" hyperlink under Incident Standard Fields to bring up the Incident Severity mapping configuration screen:
The table lists each of the incident severities available in SpiraTeam and provides you with the ability to enter the matching TFS severity value for each one. To make this easier, we recommend that inside the Administration > Edit Incident Severities screen you first make any statuses not used in TFS inactive in SpiraTeam.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTest-with-MS-TFS/#configuring-the-incident-custom-property-mapping","title":"Configuring the Incident Custom Property Mapping","text":"Now that the various SpiraTeam standard incident fields have been mapped correctly, we need to configure the custom property mappings. This is used for both custom properties in SpiraTeam that map to custom fields in TFS and also for custom properties in SpiraTeam that are used to map to standard fields in TFS (e.g. Area) that don't exist in SpiraTeam.
From the View/Edit Project Data Mapping screen, you need to click on the name of the Incident Custom Property that you want to add data-mapping information for:
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTest-with-MS-TFS/#a-tfss-area-field","title":"a) TFS's Area Field","text":"First you need to go to Administration > Edit Custom Lists and create a new custom list that contains all the different Areas that are being used in TFS.
Then you need to go to Administration > Edit Custom Properties and add a new list custom property onto the Incident artifact type called 'Area' and link it to the Area custom list you created in the previous step. This will now be available for mapping.
Now, back in the data-mapping page, click on the 'Area' hyperlink under Incident Custom Properties to bring up the custom property mapping configuration screen:
First you need to enter the word \"Area\" as the External Key of the custom property. This tells the data-sync plug-in that the custom property in SpiraTeam should be mapped to built-in Area field in TFS.
Next for each of the Property Values in the table (in the lower half of the page) you need to enter either the Area ID or the Area Path of the various Areas that are configured in TFS. The TFS Area ID is not visible in the TFS user interface, but can instead be located by opening up the SQL Server that it's installed on, opening the 'TfsWorkItemTracking' database (in TFS 2010 and later it will named after your project collection instead) and locating the 'TreeNodes' table:
Once you have found the matching Area (by name), the numeric value stored in the ID column (the one on the left) is the value that needs to get added as the External Key inside SpiraTeam.
For Azure DevOps in the cloud, it is usually easier to just map the areas to the appropriate paths instead (since the IDs are not easily found):
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTest-with-MS-TFS/#b-tfs-custom-fields","title":"b) TFS Custom Fields","text":"If the custom field in TFS is a list field, first you need to go to Administration > Edit Custom Lists in SpiraTeam and create a new custom list that contains all the different values that are being used in TFS.
Then for both list-fields and value-fields you need to go to Administration > Edit Custom Properties and add a new custom property onto the Incident artifact type with the name of the appropriate TFS field (e.g. Triage, Rank, etc.) and if a list-field, link it to the custom list you created in the previous step. The custom property will now be available for data-mapping.
Now, back in the data-synchronization data-mapping page, click on the hyperlink under Incident Custom Properties that corresponds to the custom property to bring up the custom property mapping configuration screen:
First you need to enter the full Reference Name of the TFS field as the External Key of the custom property. This tells the data-sync plug-in that the custom property in SpiraTeam should be mapped to this specific field in TFS. To see a list of fields and their reference names, you can run the following SQL query against your TFS database:
SELECT Name, ReferenceName FROM Fields ORDER BY Name
We have included a list of fields in the Agile process template in TFS Field Reference as a helpful reference.
Next for each of the Property Values in the table (in the lower half of the page) you need to enter the name of the field values as they appear in TFS as the External Key.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTest-with-MS-TFS/#configuring-the-standard-task-field-mapping","title":"Configuring the Standard Task Field Mapping","text":"Now that the projects, user, releases and incident fields have been mapped correctly, we need to configure the standard task fields. To do this, go to Administration > System > Data Synchronization and click on the \"View Project Mappings\" for the MsTfsDataSync plug-in entry:
From this screen, you need to click on Priority and Status in turn to configure their values:
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTest-with-MS-TFS/#a-task-status","title":"a) Task Status","text":"Click on the \"Status\" hyperlink under Task Standard Fields to bring up the Task status mapping configuration screen:
The table lists each of the task statuses available in SpiraTeam and provides you with the ability to enter the matching TFS work item State for each one. Unlike the mapping for incidents (see above) SpiraTeam does not track the reason codes associated with the tasks in MS TFS, so you only need to map the State names from TFS with the task status names.
You can map multiple SpiraTeam fields to the same TFS fields (e.g. Blocked, Completed and Deferred in SpiraTeam are all equivalent to State = Closed in TFS), in which case only one of the values can be listed as Primary = Yes as that's the value that's used on the reverse synchronization (from TFS > SpiraTeam).
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTest-with-MS-TFS/#b-task-priority","title":"b) Task Priority","text":"Click on the \"Priority\" hyperlink under Task Standard Fields to bring up the Task Priority mapping configuration screen:
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTest-with-MS-TFS/#c-task-type","title":"c) Task Type","text":"Click on the \"Type\" hyperlink under Task Standard Fields to bring up the Task Type mapping configuration screen:
The table lists each of the task type values available in SpiraTeam and provides you with the ability to enter the matching TFS work item type value for each one.
The table lists each of the task priorities available in SpiraTeam and provides you with the ability to enter the matching TFS priority value for each one.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTest-with-MS-TFS/#configuring-the-task-custom-property-mapping","title":"Configuring the Task Custom Property Mapping","text":"Now that the various SpiraTeam standard task fields have been mapped correctly, we need to configure the custom property mappings. This is used for both custom properties in SpiraTeam that map to custom fields in TFS and also for custom properties in SpiraTeam that are used to map to standard fields in TFS (e.g. Area) that don't exist in SpiraTeam.
From the View/Edit Project Data Mapping screen, you need to click on the name of the Task Custom Property that you want to add data-mapping information for:
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTest-with-MS-TFS/#a-tfss-area-field_1","title":"a) TFS's Area Field","text":"First you need to go to Administration > Edit Custom Lists and create a new custom list that contains all the different Areas that are being used in TFS.
Then you need to go to Administration > Edit Custom Properties and add a new list custom property onto the Task artifact type called 'Area' and link it to the Area custom list you created in the previous step. This will now be available for mapping.
Now, back in the data-mapping page, click on the 'Area' hyperlink under Task Custom Properties to bring up the custom property mapping configuration screen:
First you need to enter the word \"Area\" as the External Key of the custom property. This tells the data-sync plug-in that the custom property in SpiraTeam should be mapped to built-in Area field in TFS.
Next for each of the Property Values in the table (in the lower half of the page) you need to enter the ID or Path of the various Areas that are configured in TFS. The TFS Area ID is not visible in the TFS user interface, but can instead be located by opening up the SQL Server that it's installed on, opening the 'TfsWorkItemTracking' database (in TFS 2010 and later it will named after your project collection instead) and locating the 'TreeNodes' table:
Once you have found the matching Area (by name), the numeric value stored in the ID column (the one on the left) is the value that needs to get added as the External Key inside SpiraTeam.
For Azure DevOps in the cloud, it is usually easier to just map the areas to the appropriate paths instead (since the IDs are not easily found):
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTest-with-MS-TFS/#b-tfs-custom-fields_1","title":"b) TFS Custom Fields","text":"If the custom field in TFS is a list field, first you need to go to Administration > Edit Custom Lists in SpiraTeam and create a new custom list that contains all the different values that are being used in TFS.
Then for both list-fields and value-fields you need to go to Administration > Edit Custom Properties and add a new custom property onto the Task artifact type with the name of the appropriate TFS field (e.g. Discipline, Stack Rank, etc.) and if a list-field, link it to the custom list you created in the previous step. The custom property will now be available for data-mapping.
Now, back in the data-synchronization data-mapping page, click on the hyperlink under Task Custom Properties that corresponds to the custom property to bring up the custom property mapping configuration screen:
First you need to enter the full Reference Name of the TFS field as the External Key of the custom property. This tells the data-sync plug-in that the custom property in SpiraTeam should be mapped to this specific field in TFS. To see a list of fields and their reference names, you can run the following SQL query against your TFS database:
SELECT Name, ReferenceName FROM Fields ORDER BY Name
We have included a list of fields in the Agile process template in TFS Field Reference as a helpful reference.
Next for each of the Property Values in the table (in the lower half of the page) you need to enter the name of the field values as they appear in TFS as the External Key.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTest-with-MS-TFS/#configuring-the-standard-requirement-field-mapping-2012-plugin-only","title":"Configuring the Standard Requirement Field Mapping (2012 Plugin Only)","text":"Now that the projects, user, releases, incident and task fields have been mapped correctly, we need to configure the standard requirement fields. To do this, go to Administration > System > Data Synchronization and click on the \"View Project Mappings\" for the MsTfsDataSync plug-in entry:
From this screen, you need to click on Importance and Status in turn to configure their values:
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTest-with-MS-TFS/#a-requirement-status","title":"a) Requirement Status","text":"Click on the \"Status\" hyperlink under Requirement Standard Fields to bring up the Requirement status mapping configuration screen:
The table lists each of the requirement statuses available in SpiraTeam and provides you with the ability to enter the matching TFS work item State for each one. Unlike the mapping for incidents (see above) SpiraTeam does not track the reason codes associated with the requirements in MS TFS, so you only need to map the State names from TFS with the requirement status names.
You can map multiple SpiraTeam fields to the same TFS fields, in which case only one of the values can be listed as Primary = Yes as that's the value that's used on the reverse synchronization (from TFS > SpiraTeam).
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTest-with-MS-TFS/#b-requirement-importance","title":"b) Requirement Importance","text":"Click on the \"Importance\" hyperlink under Requirement Standard Fields to bring up the Requirement Importance mapping configuration screen:
The table lists each of the requirement importance values available in SpiraTeam and provides you with the ability to enter the matching TFS work item priority value for each one.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTest-with-MS-TFS/#c-requirement-type","title":"c) Requirement Type","text":"Click on the \"Type\" hyperlink under Requirement Standard Fields to bring up the Requirement Type mapping configuration screen:
The table lists each of the requirement type values available in SpiraTeam and provides you with the ability to enter the matching TFS work item type value for each one.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTest-with-MS-TFS/#configuring-the-requirement-custom-property-mapping","title":"Configuring the Requirement Custom Property Mapping","text":"Now that the various SpiraTeam standard requirement fields have been mapped correctly, we need to configure the custom property mappings. This is used for both custom properties in SpiraTeam that map to custom fields in TFS and also for custom properties in SpiraTeam that are used to map to standard fields in TFS (e.g. Area) that don't exist in SpiraTeam.
From the View/Edit Project Data Mapping screen, you need to click on the name of the Requirement Custom Property that you want to add data-mapping information for:
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTest-with-MS-TFS/#a-tfss-area-field_2","title":"a) TFS's Area Field","text":"First you need to go to Administration > Edit Custom Lists and create a new custom list that contains all the different Areas that are being used in TFS.
Then you need to go to Administration > Edit Custom Properties and add a new list custom property onto the Requirement artifact type called 'Area' and link it to the Area custom list you created in the previous step. This will now be available for mapping.
Now, back in the data-mapping page, click on the 'Area' hyperlink under Requirement Custom Properties to bring up the custom property mapping configuration screen:
First you need to enter the word \"Area\" as the External Key of the custom property. This tells the data-sync plug-in that the custom property in SpiraTeam should be mapped to built-in Area field in TFS.
Next for each of the Property Values in the table (in the lower half of the page) you need to enter the ID or Path of the various Areas that are configured in TFS. The TFS Area ID is not visible in the TFS user interface, but can instead be located by opening up the SQL Server that it's installed on, opening the 'TfsWorkItemTracking' database (in TFS 2010 and later it will named after your project collection instead) and locating the 'TreeNodes' table:
Once you have found the matching Area (by name), the numeric value stored in the ID column (the one on the left) is the value that needs to get added as the External Key inside SpiraTeam.
For Azure DevOps in the cloud, it is usually easier to just map the areas to the appropriate paths instead (since the IDs are not easily found):
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTest-with-MS-TFS/#b-tfs-custom-fields_2","title":"b) TFS Custom Fields","text":"If the custom field in TFS is a list field, first you need to go to Administration > Edit Custom Lists in SpiraTeam and create a new custom list that contains all the different values that are being used in TFS.
Then for both list-fields and value-fields you need to go to Administration > Edit Custom Properties and add a new custom property onto the Requirement artifact type with the name of the appropriate TFS field (e.g. Risk, Stack Rank, etc.) and if a list-field, link it to the custom list you created in the previous step. The custom property will now be available for data-mapping.
Now, back in the data-synchronization data-mapping page, click on the hyperlink under Requirement Custom Properties that corresponds to the custom property to bring up the custom property mapping configuration screen:
First you need to enter the full Reference Name of the TFS field as the External Key of the custom property. This tells the data-sync plug-in that the custom property in SpiraTeam should be mapped to this specific field in TFS. To see a list of fields and their reference names, you can run the following SQL query against your TFS database:
SELECT Name, ReferenceName FROM Fields ORDER BY Name
We have included a list of fields in the Agile process template in TFS Field Reference as a helpful reference.
Next for each of the Property Values in the table (in the lower half of the page) you need to enter the name of the field values as they appear in TFS as the External Key.
Once you have updated the various mapping sections, you are now ready to start the service.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTest-with-MS-TFS/#using-spirateam-with-tfs","title":"Using SpiraTeam with TFS","text":"Now that the integration service has been configured and the service started, initially any incidents already created in SpiraTeam for the specified projects will be imported into TFS and any requirements, tasks or bugs already created in TFS will be imported into SpiraTeam. At this point we recommend opening the Windows Event Viewer and choosing the Application Log. In this log any error messages raised by the SpiraTeam Data Sync Service will be displayed. If you see any error messages at this point, we recommend immediately stopping the SpiraTeam service and checking the various mapping entries. If you cannot see any work items with the mapping information, we recommend sending a copy of the event log message(s) to Inflectra customer services (support@inflectra.com) who will help you troubleshoot the problem.
To use SpiraTeam with TFS on an ongoing basis, we recommend the following general processes be followed:
When running tests in SpiraTest or SpiraTeam, defects found should be logged through the Test Execution Wizard as normal.
Once an incident has been created during the running of the test, it will now be populated across into TFS as a work item of type corresponding to the types setup in the incident type mappings.
At this point, the incident can be worked on in either system, with changes being synchronized to the other system. However in general we recommend that the QA/Testing team use SpiraTeam and the development team use TFS. E.g. the developers will mark the bugs as resolved in MSTS once they have completed fixing them and the QA team will either reopen or close then in SpiraTeam once they have had a change to verify the resolution.
You are now able to perform test coverage and incident reporting inside SpiraTest/SpiraTeam using the test cases managed by SpiraTest/SpiraTeam and the incidents managed collaboratively between SpiraTest/SpiraTeam and TFS.
You can create project requirements and associated tasks in either SpiraTeam or TFS, however the synchronization service is only unidirectional for requirements and tasks, so when you create or update a requirement or task in TFS, the change will be reflected in SpiraTeam, but not the other way around.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTest-with-MS-TFS/#description-handling","title":"Description Handling","text":"Whereas Spira has a single artifact Description field, ADO/TFS has three possible \"Description\" fields depending on the templates setup by an administrator:
Microsoft.VSTS.TCM.ReproSteps (rich text)Microsoft.VSTS.Common.DescriptionHtml (rich text)System.Description (plain text)The plugin checks for each of them in the order above. It will sync the Description in Spira with whichever one of these it finds first. So if you have both ReproSteps and Description (for example) then it will use ReproSteps.
If you need both fields in Spira, then we recommend making two separate rich text custom properties and map each of those to the ones in ADO/TFS.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTest-with-MS-TFS/#troubleshooting","title":"Troubleshooting","text":"In most cases once you have started the service, once it's up and running you will not see any error or warning messages from the Data-Sync service. However, if you have new users created in SpiraTeam that have not been mapped to users in TFS, when you assign incidents, requirements or tasks to those items, you may see warning messages in the Event Viewer letting you know which users needs to be mapped.
"},{"location":"External-Bug-Tracking-Integration/Using-SpiraTest-with-MS-TFS/#tfs-field-reference","title":"TFS Field Reference","text":"The following fields are available in TFS for data-mapping when using the TFS agile process template:
Display Name Reference Name Accepted By Microsoft.VSTS.CodeReview.AcceptedBy Accepted Date Microsoft.VSTS.CodeReview.AcceptedDate Activated By Microsoft.VSTS.Common.ActivatedBy Activated Date Microsoft.VSTS.Common.ActivatedDate Activity Microsoft.VSTS.Common.Activity Application Launch Instructions Microsoft.VSTS.Feedback.ApplicationLaunchInstructions Application Start Information Microsoft.VSTS.Feedback.ApplicationStartInformation Application Type Microsoft.VSTS.Feedback.ApplicationType Area ID System.AreaId Area Level 1 System.AreaLevel1 Area Level 2 System.AreaLevel2 Area Level 3 System.AreaLevel3 Area Level 4 System.AreaLevel4 Area Level 5 System.AreaLevel5 Area Level 6 System.AreaLevel6 Area Level 7 System.AreaLevel7 Area Path System.AreaPath Assigned To System.AssignedTo Associated Context Microsoft.VSTS.CodeReview.Context Associated Context Code Microsoft.VSTS.CodeReview.ContextCode Associated Context Owner Microsoft.VSTS.CodeReview.ContextOwner Associated Context Type Microsoft.VSTS.CodeReview.ContextType Attached File Count System.AttachedFileCount Attached Files System.AttachedFiles Authorized As System.AuthorizedAs Authorized Date System.AuthorizedDate Automated Test Id Microsoft.VSTS.TCM.AutomatedTestId Automated Test Name Microsoft.VSTS.TCM.AutomatedTestName Automated Test Storage Microsoft.VSTS.TCM.AutomatedTestStorage Automated Test Type Microsoft.VSTS.TCM.AutomatedTestType Automation status Microsoft.VSTS.TCM.AutomationStatus BIS Links System.BISLinks Changed By System.ChangedBy Changed Date System.ChangedDate Changed Set System.ChangedSet Closed By Microsoft.VSTS.Common.ClosedBy Closed Date Microsoft.VSTS.Common.ClosedDate Closed Status Microsoft.VSTS.CodeReview.ClosedStatus Closed Status Code Microsoft.VSTS.CodeReview.ClosedStatusCode Closing Comment Microsoft.VSTS.CodeReview.ClosingComment Completed Work Microsoft.VSTS.Scheduling.CompletedWork Created By System.CreatedBy Created Date System.CreatedDate Description System.Description Due Date Microsoft.VSTS.Scheduling.DueDate External Link Count System.ExternalLinkCount Finish Date Microsoft.VSTS.Scheduling.FinishDate Found In Microsoft.VSTS.Build.FoundIn History System.History Hyperlink Count System.HyperLinkCount ID System.Id InAdminOnlyTreeFlag System.InAdminOnlyTreeFlag InDeletedTreeFlag System.InDeletedTreeFlag Integration Build Microsoft.VSTS.Build.IntegrationBuild Issue Microsoft.VSTS.Common.Issue Iteration ID System.IterationId Iteration Level 1 System.IterationLevel1 Iteration Level 2 System.IterationLevel2 Iteration Level 3 System.IterationLevel3 Iteration Level 4 System.IterationLevel4 Iteration Level 5 System.IterationLevel5 Iteration Level 6 System.IterationLevel6 Iteration Level 7 System.IterationLevel7 Iteration Path System.IterationPath Link Type System.Links.LinkType Linked Files System.LinkedFiles Local Data Source Microsoft.VSTS.TCM.LocalDataSource Node Name System.NodeName Node Type System.NodeType Not a field System.NotAField Original Estimate Microsoft.VSTS.Scheduling.OriginalEstimate Parameters Microsoft.VSTS.TCM.Parameters PersonID System.PersonId Priority Microsoft.VSTS.Common.Priority ProjectID System.ProjectId Rating Microsoft.VSTS.Common.Rating Reason System.Reason Related Link Count System.RelatedLinkCount Related Links System.RelatedLinks Remaining Work Microsoft.VSTS.Scheduling.RemainingWork Repro Steps Microsoft.VSTS.TCM.ReproSteps Resolved By Microsoft.VSTS.Common.ResolvedBy Resolved Date Microsoft.VSTS.Common.ResolvedDate Resolved Reason Microsoft.VSTS.Common.ResolvedReason Rev System.Rev Reviewed By Microsoft.VSTS.Common.ReviewedBy Revised Date System.RevisedDate Risk Microsoft.VSTS.Common.Risk Severity Microsoft.VSTS.Common.Severity Stack Rank Microsoft.VSTS.Common.StackRank Start Date Microsoft.VSTS.Scheduling.StartDate State System.State State Change Date Microsoft.VSTS.Common.StateChangeDate State Code Microsoft.VSTS.Common.StateCode Steps Microsoft.VSTS.TCM.Steps Story Points Microsoft.VSTS.Scheduling.StoryPoints System Info Microsoft.VSTS.TCM.SystemInfo Tags System.Tags Team Project System.TeamProject TF Server System.TFServer Title System.Title Tree System.Tree Watermark System.Watermark _Extension Marker System.ExtensionMarker _Kanban Column _Kanban.Column Work Item Form System.WorkItemForm Work Item FormID System.WorkItemFormId Work Item Type System.WorkItemType WorkItem System.WorkItem WorkItemLink System.WorkItemLink WorkItemTypeExtension System.WorkItemTypeExtensionFor a full list of the available TFS fields in the different process templates, please refer to: http://msdn.microsoft.com/en-us/library/vstudio/dd997792.aspx
"},{"location":"Help-Desk-Integration/KronoDesk/","title":"KronoDesk","text":"This section outlines how to integrate KronoDesk\u00ae into SpiraPlan\u00ae. This will enable KronoDesk agents to log incidents emerging from a ticket directly from the KronoDesk interface into SpiraPlan. They will also be able to see and review any SpiraPlan incidents already linked to existing KronoDesk tickets.
The integration is built-in to KronoDesk out of the box, with no add-ons necessary.
"},{"location":"Help-Desk-Integration/KronoDesk/#configuring-spiraplan","title":"Configuring SpiraPlan","text":"In order for KronoDesk to successfully connect to SpiraPlan to create incidents, you need to first enable the security permissions for REST API access. To do this, open up SpiraPlan and go to the Administration > System > Security Settings. Enter the URL domain of your KronoDesk into the \"Allowed Domains\" box. This tells SpiraPlan that REST API requests from this domain is authorized.
For non-production environments, you can set the value to \"*\" to allow all requests. We do not recommend this setting for production.
Each agent who wants to integrate KronoDesk with SpiraPlan needs to enter a SpiraPlan username and RSS Token into their user profile. In SpiraPlan, go to your User Profile page (if it's your user) or the Administration > Edit Users page, if you want to connect as a different user:
Make sure that Enable RSS Feeds is set to Active = Yes, and that there is an RSS Token. This is used as the REST API Key too. Make sure you have the following:
This is what you will use to connect from KronoDesk.
"},{"location":"Help-Desk-Integration/KronoDesk/#configuring-kronodesk","title":"Configuring KronoDesk","text":"Inside KronoDesk as an administrator, go to: Administration > Help Desk Settings > Spira Integration:
Enter the following information for your SpiraPlan instance:
When you click \"Test\", you should see the following:
If you see an authentication error, please check the login and RSS Token / API Key and try again.
Next, each user support agent in KronoDesk needs to connect their SpiraPlan user to their KronoDesk profile (using the information collected above). Each user needs to go to their User Profile in KronoDesk:
They should enter the Spira login and RSS Token and click Test:
Then click Save Changes to update the profile with this information.
"},{"location":"Help-Desk-Integration/KronoDesk/#using-kronodesk-with-spiraplan","title":"Using KronoDesk with SpiraPlan","text":"When you view a ticket in KronoDesk (and you have configured the connection to SpiraPlan), you will see a little toggle icon to show or hide incidents (the highlighted bug icon in the image below).
This means you are connected to SpiraPlan and can view any incidents logged against this help desk ticket.
To log a new incident in SpiraPlan based on the current help desk ticket, click on downward facing arrow on the right hand side of the ticket header (the \"more actions\" button). To \"Add New Incident\" make sure a SpiraPlan project is selected from the dropdown list (if the name of the product for the ticket matches the name of any SpiraPlan project, that project will be automatically selected for you):
This will display a dialog that lets you add a new incident to the linked instance of SpiraPlan. The system will prepopulate the description of the incident with the ticket description. You can edit this text or clear it completely and enter in custom content:
Once you click Add, the new incident is logged in SpiraPlan and linked to the current ticket:
If you click on the incident hyperlink, you will see that the incident is available in SpiraPlan:
In addition, in the Attachments tab of the Incident in Spiraplan, there is a hyperlink for the developers to see the original help desk ticket:
"},{"location":"Help-Desk-Integration/Zendesk/","title":"Zendesk","text":"This section outlines how to integrate Zendesk into SpiraTeam\u00ae. This will enable Zendesk agents to log incidents emerging from a ticket directly from the Zendesk interface into SpiraTeam\u00ae. They will also be able to see and review any SpiraTeam\u00ae incidents already linked to existing Zendesk tickets. The integration is in the form of a Zendesk app, available for free, from the Zendesk marketplace.
"},{"location":"Help-Desk-Integration/Zendesk/#overview-to-get-up-and-running","title":"Overview to Get Up and Running","text":"This section outlines the steps required to ensure that the links between Zendesk and Spirateam will work correctly.
"},{"location":"Help-Desk-Integration/Zendesk/#summary-of-requirements","title":"Summary of requirements","text":"There are a number of elements needed for both applications to successfully communicate:
Zendesk and SpiraTeam need to communicate and post data to one another cross domain. To ensure effective security SpiraTeam therefore needs to be accessible via HTTPS (i.e. using a certificate). If this is not already in place, contact your network administration for support.
Note: all SpiraTeam hosted accounts are already accessible via HTTPS (only).
Zendesk and SpiraTeam communicate through a security protocol called CORs to ensure that each application only receives data from trusted domains. The subdomain of your Zendesk account is required by SpiraTeam to validate any calls it receives.
Log in as a project-level administrator to SpiraTeam, go to the Administration home page and scroll to System > Security Settings.
At the bottom of the Security Settings page, enter the Zendesk subdomain in the \"Allowed Domains\" text box, making sure to include the full url (i.e including https:// before the domain address). Click <Update> for the changes to take effect. The url should be in the format of: \"https://yoursubdomain.zendesk.com\"
Important: if this field is left blank, NO domains will be allowed to interact with SpiraTeam via CORs. If an asterisk (*) is entered, ALL domains will be able to do so (not recommended).
The Zendesk app uses the details of a SpiraTeam user to authenticate with SpiraTeam. This needs to be, for the initial setup, a user with administrator privileges. We recommend creating a specific user account (such as \"Zendesk\"), so that the only incidents created by that account can be traced back to Zendesk.
Note: all tickets logged with Zendesk will be marked as originating from this user. This means that the Zendesk team do not need to have individual SpiraTeam logins.
Go to the Administration home page and scroll to Users > View / Edit Users.
Click the <Add User> button on the bottom right of the page.
Fill in the required fields (see below), and make sure that:
Click <Insert> to add the new user.
"},{"location":"Help-Desk-Integration/Zendesk/#install-and-configure-the-spirateam-app-in-zendesk","title":"Install and Configure the SpiraTeam App in Zendesk","text":"
First, find an install the free SpiraTeam App from within Zendesk. Only administrators on Zendesk can install apps. Navigate to the Admin panel, and select Marketplace from the Apps menu. Search for \"SpiraTeam\" in the search field on the right, or browse by \"Issues Tracking\".
You can also browse the Zendesk app website.
Once the application is installed, enter required information in the settings page of the app. Go to Admin > Apps > Manage in Zendesk to see the list of installed applications.
Make sure the application is enabled. Right click on the app's gear icon to change settings
In the settings screen, make sure all input boxes are correctly filled in. Enter the username and API key that you created inside SpiraTeam above, as well as the address of SpiraTeam. Make sure that the API key is an alphanumeric string contained within curly braces -- { }. Click <Update>.
"},{"location":"Help-Desk-Integration/Zendesk/#connecting-zendesk-to-spirateam","title":"Connecting Zendesk to SpiraTeam","text":"
Zendesk should now be able to communicate fully with SpiraTeam. In order for SpiraTeam to be informed that you are using the Zendesk app, simply navigate to any ticket, click on the app sidebar (on the right of the Zendesk window) and locate the SpiraTeam app. You should see a screen like that below, giving you a welcome message on the successful connection of Zendesk to SpiraTeam.
If you instead see a message like that below (note that you will also see a Zendesk service notification), please check your network settings, and double check through the steps outline above.
"},{"location":"Help-Desk-Integration/Zendesk/#connecting-spirateam-to-zendesk","title":"Connecting SpiraTeam to Zendesk","text":"
Zendesk can now retrieve information form SpiraTeam. For Zendesk to be able to write all the information it needs to SpiraTeam, you need to grant Zendesk access in each relevant project (i.e. any project that a Zendesk agent may need to submit an incident about).
If you wish, at this time you can change the account of the dedicated \"Zendesk\" user to no longer be an administrator. Make sure proper permissions are set so that the user has full access to incidents in all relevant projects.
In SpiraTeam, navigate to a project Zendesk will need access to. Go to the SpiraTeam administration panel and then Integration > Data Synchronization.
This will show you the list of current external tools that can synchronize custom data directly with SpiraTeam. Zendesk should appear as the last \"Plug-In\" in the table.
Click on <View Project Mappings>. Set Active to \"Yes\". Type in any value for External Key (this is a required field but because SpiraTeam does not write to Zendesk it is never used by the app). Click <Update>.
NOTES:
Repeat the above steps for every project Zendesk will need access to.
"},{"location":"Help-Desk-Integration/Zendesk/#creating-an-incident-in-spirateam","title":"Creating an Incident in SpiraTeam","text":"Zendesk agents are able to create an incident from within Zendesk that is logged directly into SpiraTeam. The app should not be visible to the public.
When an agent has a ticket, which raises an issue to pass to a development team, they open the app sidebar on the right hand side of Zendesk. They will see the following screen.
In order to log an incident, the agent must decide which project the issue relates to. SpiraTeam will list all active projects in the drop down list. If an agent is unsure which project to select, we recommend that they discuss the issue with the development team first. Select a project and click <Go>.
Zendesk will load fields specific to that project, including any custom properties or components. By default, as a minimum, the app collects Incident Type, Priority, Release, and Owner lists, all of which are required to be filled in, along with a subject field and a note.
By default, the subject field will be the same as the ticket's current subject, but the agent can change this to make as clear as possible to the developer -- changing the subject in the SpiraTeam app will NOT change the subject of the ticket itself.
The Notes to Developers is initially left blank, so that the agent can provide meaningful information. If the agent wants to include the comment history of the ticket after their own notes, click <Add comment history to description>. NOTE: clicking this repeatedly will paste in the comment history multiple times.
When a project has additional fields (such as components or custom properties), these are also displayed. The app provides a split view of the fields -- those that are required and those that are optional. The tab at the top of the app lets agents switch between both.
If the agent wishes to cancel logging the incident, or has chosen the wrong project, click the <Back> button.
Once the form has been filled in, click <Log Incident>. If any of the fields have been left blank a notification will display and the form will not be processed. Once everything has been entered correctly, Zendesk attempts to send the form to SpiraTeam, along with links to any attachments stored with the ticket.
If Zendesk is not successful, a warning notification will be displayed (see below), and the agent is asked to attempt again.
"},{"location":"Help-Desk-Integration/Zendesk/#reviewing-the-incident-in-spirateam","title":"Reviewing the Incident in SpiraTeam","text":"
Back in SpiraTeam the new incident should be visible within the main incident log. Details about the incident can be altered as needed, without risk of breaking the connection with Zendesk.
NOTE: On the incidents screen, you should notice a new field on the Overview page, called \"Zendesk ID\". This is the ID of the specific Zendesk ticket. Editing this field will break the connection and is not advised.
"},{"location":"Help-Desk-Integration/Zendesk/#reviewing-spirateam-incidents-linked-to-a-zendesk-ticket","title":"Reviewing SpiraTeam Incidents Linked to a Zendesk Ticket","text":"As soon as the incident has been successfully logged to SpiraTeam, the app in Zendesk will return to the screen showing lists of projects, in case another incident needs to be logged.
In addition, information about any incidents linked to the ticket are clearly shown, including the most up to date status from SpiraTeam so that the agent can clearly see whether an issue is resolved or not.
Hovering over a particular incident gives the agent quick access to the additional information directly in Spira.
"},{"location":"HowTo-Guides/Admins-orientation/","title":"Getting to Know Spira Administration","text":""},{"location":"HowTo-Guides/Admins-orientation/#how-to-know-what-if-anything-you-are-an-admin-of","title":"How to know what, if anything, you are an admin of","text":"You can read about the different types of administration here.
"},{"location":"HowTo-Guides/Admins-orientation/#admin-home-pages","title":"Admin home pages","text":"Users can only delete artifacts if their product role has the delete permission enable for that specific artifact. The exception to this is folders: users who have \"Bulk Edit\" permissions for the relevant artifact can also add, edit, and delete those artifacts folders.
Folder deletion: Documents, Tasks, Test Cases, and Test Sets have folders. Deleting folders is permanent and cannot be undone
Artifact deletion:
Read about the template workspace here.
"},{"location":"HowTo-Guides/Admins-templates/#how-to-create-a-new-template","title":"How to create a new template","text":"You cannot create a template by itself. You can only create a new template when creating a new product.
Administration > System > Workspace > View/Edit ProductsAdd to add a new productTemplate field. From here you can select an existing template or Create New Template.Create New Template optionInsertTo clone a template, you need to clone a product that uses the template you wish to clone
Administration > System > Workspace > View/Edit ProductsClone button on that product's rowClone templateCloneFor more information about changing a product's template see here.
Administration > System > Workspace > View/Edit ProductsEditChange TemplateNextIf you have 2+ products using the same template, but decide 1 products needs slightly different template settings, you need to branch its template off into a brand new template. This is possible, but requires a few different steps to make it work smoothly.
We have dedicated guides explaining this in detail for: Jira Cloud and Jira Server. Below is a very high level summary with further links
For cloud-hosted Spira instances you can use Inflectra's cloud data sync to simplify how you sync with third party providers like Jira. To configure a cloud data sync:
Configure the username to use for the dataSync
For more information about using login providers see the admin guide
Please Note
We have tried to give up to date and accurate information, but many providers do not themselves have correct information on their site. Hopefully they do not change things too much, but if they do and you cannot figure out what to do please contact our support team.
"},{"location":"HowTo-Guides/Login-providers/#azure-ad","title":"Azure AD","text":"To set up an Azure AD provider app with Spira you will need an Azure account with Azure AD set up with users as needed. For the steps below we have assumed Azure AD is set up in relatively standard way.
First, you need to set up the app registration, this app will give your users a specific connection to Spira. When creating an app registration you should:
SettingsDeveloper SettingsOauth Appssettings from the dropdownApplications in the lefthand sidebarThis guide assumes you already have an accessible ADFS (2016+) server, configured with users as required.
First, create the application group
Now, you need to get the specific URLs so Spira knows how to connect to your ADFS. You will need your server's base URL, to which you add the specific endpoints\u00a0
By default your urls will look like:
{server base URL}/adfs/oauth2/authorize{server base URL}/adfs/oauth2/token{server base URL}/adfs/userinfoFirst you need to create the application in Okta
Next, you need to get the necessary urls for connecting to Spira. You will need several urls specific to your Okta domain.
The authServerId will need to be configured based on your Okta setup. You can find more information about testing the server here:\u00a0https://developer.okta.com/docs/guides/customize-authz-server/test-authz-server/
Broadly, the urls may take the following shape (discuss with Okta if you run into any issues with these)
The Redirect URI (or return URL) can be found at the bottom of the Okta administration page in Spira.
"},{"location":"HowTo-Guides/Login-providers/#onelogin","title":"OneLogin","text":"First create the application in OneLogin
Fill in the basic information about the new app:
Add existing users to the application to allow them to login to SpiraPlan using OneLogin via the \"Users\" tab
Next, you need to get the necessary information for connecting to Spira. You will need several urls specific to your OneLogin domain.
Use the \"Issuer URL\" (which will end in something like \"onelogin.com/oidc/2\") as the base url in SpiraPlan as below:
The generic OpenId providers accepts any standard compliant OAuth Provider. The required configuration will vary based on how each provider works. However, make sure that, as with other providers, that the return URI entered into the OpenId provider matches that inside SpiraPlan.
"},{"location":"HowTo-Guides/Permissions-Workflows/","title":"Permissions and Workflows","text":""},{"location":"HowTo-Guides/Permissions-Workflows/#how-do-spiras-permissions-and-workflows-work","title":"How do Spira's permissions and workflows work","text":"You give users specific roles to give them specific permissions. These permissions are mostly about what that role can do with each artifact in general. Users with a role that lets them view incidents can view every single incident in the product.
A workflow controls what a specific artifact will look like and how it can be edited. For example Bug1 may have lots of fields hidden, while Bug2 has every field visible. Bug1 and Bug2 look different because their display is controlled by different parts of a workflow system. One workflow step applies to Bug1 and a different workflow step applies to Bug2.
So roles let admins control who can see what in general. Workflow let admins control, if you can see something (say a bug), exactly how that bug (for example) should behave based the bug's state at the time. When you change an item's state (by changing this bug's status, for instance) you can change how it will look or behave.
How do you change an item's state? The most common way is changing the item's status. This is called a transition. Transitions are special because they let users make this big changes to something - for instance hiding or showing information. Because transitions can be so powerful, they can also be protected. An admin can control who can carry out each and every transition (including based on product roles).
Taken together, this system of roles and workflows, with their combination of permissions, statuses, and transitions, give admins a lot of power to customize how things should work. They are powerful, but also they can be fiddly. It can be confusing to a user or an admin why things work one way for one user, but differently for another.
The tips and tricks below should help work through the most common problems and stumbling blocks.
"},{"location":"HowTo-Guides/Permissions-Workflows/#what-does-a-workflow-do-and-control","title":"What does a workflow do and control","text":"Workflows are a way to control a number of things about your artifacts. A workflow is based on a series of steps (statuses) that you move the artifact through.
At each step you can control:
Transition are how you move from one step (status) to another. At each workflow step you can make as many transitions as you want. Each transition will move the workflow to a new step. For each transition you can control:
When you add a user to a product, you have to set the specific product role they should have. This grants them specific permissions to view certain data, edit other data, maybe the ability to delete some data too.
Each user has to be actively given a particular role for each product. In other words, you cannot make a user a member of a product without giving them a specific role. Likewise, you cannot make a user a \"Tester\" for any products they are or will be a member of.
"},{"location":"HowTo-Guides/Permissions-Workflows/#permissions","title":"Permissions","text":"The application ships with some built-in product roles but you can edit these roles or add new ones too. Each role defines if users with that role:
For example:
Your product role is used to control if you:
Product Role permissions control if users with that product role can or cannot delete a specific artifact. To stop users being able to delete artifacts, edit the product role. Make sure that the \"Delete\" checkboxes are NOT checked for all relevant artifacts.
"},{"location":"HowTo-Guides/Permissions-Workflows/#why-is-a-field-disabled-or-hidden-or-required","title":"Why is a field disabled or hidden or required","text":"Each field can be controlled by the relevant workflow to show, hide, disable, or be required. If you thought a field should be visible, but in reality it is hidden, this is the workflow at work.
The workflow controlling that specific artifact has a step that matches the current status of the specific artifact. That step sets whether each field is visible, disabled, hidden, or required. You need to work through how this is happening.
"},{"location":"HowTo-Guides/Permissions-Workflows/#how-to-make-a-field-required-or-hidden-or-disabled","title":"How to make a field required or hidden or disabled","text":"There are two ways that a field can be required. The best way to control this is through the workflow. This controls what fields are required, not required, disabled/read only, or hidden.
"},{"location":"HowTo-Guides/Permissions-Workflows/#workflow","title":"Workflow","text":"The below works for any artifact that has a workflow. Below we are changing the Incident workflow
Steps next to the workflowSaveCustom properties have a special option that says whether a blank value is allowed or not. If a blank value is allowed, then the field will onyl be required if the workflow step/status says so. If a blank value is not allowed then anytime you try to save an artifact with that field and the value is blank it will prompt you for a value.
To change if a blank value is allowed or not for a custom property: 1. Find the template that your product is using 2. As a template administrator go to Template Administration, find the artifact section you need, and click its \"Custom Properties\" link 4. Find the custom property you want to change 5. Click Edit Defintion 6. Go to the Options tab in the popup 7. Set the \"Allow Empty\" dropdown to Yes or No as desired 8. Hit Save
If you are looking at an artifact and the status has no button next to it, then you cannot change its status. The button (if there) shows which transitions you can do to move the artifact to a new status.
Why is this button missing? Either because:
Read more about these issues below
"},{"location":"HowTo-Guides/Permissions-Workflows/#why-does-a-user-not-see-the-right-transitions","title":"Why does a user not see the right transitions","text":"When a user goes to look at the detail of an artifact they may be able to change the status by transitioning from one status to another. This is called a transition. What transitions show up when for what users is controlled by a number of things.
To troubleshoot the issue you need to be a template administrator. The summary steps to review are below. Please refer to the admin guide for more information.
Save to commit any changesNote: the following does NOT apply to releases.
When you are looking at a specific artifact on its full details page, the fields you see or not and which transitions are available are determined by the workflow. However, you can have more than one actie workflow for each artifact. How can this be?
Because you can match a workflow to a specific type. This means that one type (say incidents of type bug) will use one workflow, but a different type (say incidents of type enhancement) will use a second workflow.
If you do not know why you are seeing what you are seeing for a workflow, it could be because a different workflow is actually controlling the artifact. You can check this by:
You can change the default workflow step for artifacts that let you edit their statuses.
On the relevant product template administration status page for an artifact (if present) one of the options is to pick a single default status. Changing the status will change the default status for every workflow of that artifact for that product template.
Artifacts that support editing of statuses, and picking a default workflow step are:
Other artifacts do not support editing of their statuses (Test Cases, Test Sets, Requirements, Releases, and Tasks)
"},{"location":"HowTo-Guides/Requirements/","title":"Requirements","text":""},{"location":"HowTo-Guides/Requirements/#how-to-fix-the-requirement-hierarchy","title":"How to fix the requirement hierarchy","text":"Sometimes the requirement list will not look as you expect (on the main list view or in the sidebar when looking at a single requirement). Some nodes may be hidden that should be visible, or vice versa. This can happen due to the combination of expanding/collapsing different nodes / parent requirements, and filtering requirements by different fields. You can get this back to normal by doing the following:
Clear Filter button above the table of requirements)Sometimes you may change the status of a requirement, then when you look at it again the status was the old status, not the new one you tried to change it to. What causes this?
When you run a test case or a test set it creates a \"Pending Test Run\". This is a test run that is in progress. You can see pending test runs in 2 places. From there you can also, if allowed, delete the pending test run. This will permanently delete the pending test run from everywhere for all users.
Pending test runs are works in progress and can be deleted (see above). Once a test has been finalized it becomes a Test Run. This is designed to be an immutable record of what happened during testing. Therefore we strongly discourage every deleting a test run. Instead we recommend running the test case or test set again. That is why, by default, no roles have permission to delete test runs.
If you really need to delete a test run then these are the steps to take:
Delete button that lets them to delete test runs.Refersh Test Status CacheNOTE: because we do not consider the above a usual workflow in SpiraPlan currently we do not maintain a history of test run deletions and modifications.
"},{"location":"HowTo-Guides/Testing/#how-to-change-a-test-result-after-the-test-has-been-run","title":"How to change a test result after the test has been run","text":"What do you do if a tester marked a step as passed or failed by accident? How can this be corrected? BEFORE the test is finished the tester can edit the results on the test execution screen.
Once the test run has been formally completed, the only way to update an execution status or an actual result is to rerun the test case or test set. For a test case: find the test case and hit Execute. For a test set you have a few options:
Let's say that you ran a test set with ten test cases in it. One of the test cases failed and now is ready for retest. Do you need to rerun the whole test set of ten test cases? Or is there a quicker way?
To update part of a test set result you can optionally selectively execute just part of it. There are two ways to do this:
Execute button just above the list of test cases (or from the context menu on the test case table). This will only execute those test cases.Test cases contain test steps. These steps can be edited in a number of ways: each step has properties that you can edit; you can add and remove steps; and you can change the order of the steps.
You may want to control who can edit test steps, and when they can edit them.
Control who can edit test steps: set your product roles so that only users with certain roles can modify test steps.
Control when anyone can edit test steps: using the test case workflow, you can control what fields of the test case are editable, disabled, hidden, or required. For each workflow step, make sure to review the \"Test Steps?\" row.
Together, controlling who, and when, give you a lot of flexibility in managing your test steps (and other artifacts too).
"},{"location":"HowTo-Guides/Testing/#setting-up-scheduled-test-automation","title":"Setting up scheduled test automation","text":"SpiraPlan gives users powerful ways to execute tests, integrate with external testing tools, and schedule automate testing right from inside the web application.
Executing scheduled automated test cases in SpiraPlan needs the following setup:
Automation Engine Itself: make sure you have an automation engine (application) installed and setup on a machine. For example, if using RemoteLaunch:
Automation Host: each product needs dedicated Automation Hosts. Setup one for each computer that is going to run an automated test case. Make sure that the token field is meaningful and unique (for example, that it is the same as the matching field in RemoteLaunch).
Test Set (with its test cases): create a test set to be the wrapper for your automated test (automated test cases can only be executed within a test set). Make sure to set the following fields on the test set:
Wait: when your planned dates go by, the automation engine will query for any tests that are now ready for its specific automation host and will then execute the test, reporting the results back to SpiraPlan.
From left to right, it has links and dropdowns for the following:
What is an artifact list page?
Clicking on a specific artifact from its page or elsewhere will open the artifact details page. What is an artifact details page?
This section outlines how to use SpiraTest, SpiraPlan or SpiraTeam (hereafter referred to as SpiraTeam) in conjunction with the Eclipse integrated development environment (IDE) for implementing Requirements, completing Tasks and fixing Incidents. Rather than develop a new user-interface from scratch, the SpiraTeam plug-in uses the generic Mylyn task-based interface that allows Eclipse users to manage their local tasks and tasks from any compatible repository in a single interface.
"},{"location":"IDE-Integration/Eclipse--Mylyn/#installing-the-eclipse-plug-in","title":"Installing the Eclipse Plug-In","text":"This section outlines how to install the SpiraTeam plug-in for Eclipse. It assumes that you already have a working installation of SpiraTest, SpiraPlan or SpiraTeam v6.0 or later and a working installation of Eclipse v4.6 (Neon) or later with the Mylyn plug-in installed.
If you have an earlier version of SpiraTeam, you will need to upgrade to at least v6.0 before trying to integrate with Eclipse.
To obtain the Eclipse plug-in, open up the Eclipse application and click on Help > Eclipse Marketplace. Enter \"SpiraTeam\" in the 'Find' text box. Once you hit enter, you should see the following result:
Click the Install button, accept the terms of the license and click \"Finish\". Eclipse will advise you that our software contains unsigned content, press \"OK\" to continue the installation. After you restart Eclipse, you can start to use our plug-in.
Alternatively, you can click Help > Install New Software. This will display the Eclipse installation wizard:
Enter https://www.inflectra.com/Downloads/Eclipse as the download site in the \"Work with:\" text box and uncheck the \"Group items by category\" checkbox. Once you hit enter, the wizard should display \"SpiraTeam\". Select the Feature's checkbox and click \"Next\" or \"Finish\" to tell Eclipse to download and install the feature and dependent plug-ins. During this process you may be asked to agree to our software license and to allow the installation of unsigned software. Once you have completed these steps, you should now have our SpiraTeam plug-in installed and ready to use.
To check that the individual plugins have been installed, you can go to Help > About Eclipse and then click on the [Installation Details] button. On the page that appears, click on the Plugins tab and you will see the two Inflectra plugins listed (Core and UI).
Now that you have the plug-ins installed, the next steps are:
Connect to the appropriate SpiraTeam repository
Download your assigned SpiraTeam artifacts (Requirements, Tasks and Incidents)
Work on the downloaded SpiraTeam artifacts
To connect to a SpiraTeam repository, you need to first display the appropriate Eclipse views. To do this, go to Window > Show View > \"Other...\" and then under the Tasks section, display both the Task Repositories view and the Task List view:
Once you have chosen to select the Task Repositories, the following tab will be displayed:
Where any existing repositories will listed along with the built-in \"Local\" repository that is used to manage tasks created natively within Eclipse/Mylyn.
To connect to a new SpiraTeam repository, right-click on the window and choose \"Add Task Repository...\" which will bring up the following selection box:
Choose the \"Spira\" repository entry and click [Next]. This will bring up the repository configuration dialog box:
On this screen, you need to fill out the information used to connect to your SpiraTeam server:
Server -- This should be the URL to the SpiraTeam instance that you are accessing.
Label -- This is a \"friendly\" name for that server that will be used inside Eclipse.
User ID -- This needs to be a valid username that has access to SpiraTeam.
Password -- This needs to be the correct API Key for the username specified. Although the Eclipse label says Password, you need to use the Spira username and API Key NOT password.
Once you have entered the information, click [Finish] to complete the \"Add Repository\" wizard. Once this has been done, Eclipse will ask you if you would like to add a new query for this repository. You can choose either Yes or No. The process for adding a new query to the SpiraTeam repository is described in the next section.
Once you have added the SpiraTeam repository, the repository list view should now look something like:
You can now add a new query by right-clicking on the SpiraTeam repository instance and choosing \"New Query...\". This will bring up the new query wizard:
Currently the SpiraTeam Eclipse/Mylyn plugin only supports the three predefined queries listed above. You can choose to add a list of Requirements, Incidents or Tasks that are assigned to you. Once you have added the appropriate queries (depending on which types of artifact get assigned to you), the list of Requirements, Incidents and or Tasks will be downloaded from the server and added to your Task List in Eclipse:
When you hover the mouse over any of the items in the list of Requirements, Incidents or Tasks, you will see a popup tooltip that provides additional information:
Artifacts in the list have various states, based on your interaction with them. Unread artifacts are those with new changes, which you haven't seen yet. These artifacts are denoted as having \"incoming changes\" (coming from repository). When you open and edit the artifact, it will have local modifications which haven't been sent to SpiraTeam repository yet (outgoing changes).
The following UI Legend explains meaning of various icons which are displayed in the Eclipse/Mylyn Task List:
As you can see, the different SpiraTeam artifacts are represented by different graphic overlays that let you know if the Eclipse/Mylyn task is really a SpiraTeam Requirement, Incident or Task.
To refresh the list of tasks in Eclipse, you can either right-click on the appropriate query folder and choose \"Synchronize\" or just press the F5 key on the keyboard.
Each of the different artifacts (Requirements, Incidents and Tasks) works slightly differently, so please refer to the appropriate section for details on how to view and edit.
"},{"location":"IDE-Integration/Eclipse--Mylyn/#viewing-and-editing-requirements-in-eclipse","title":"Viewing and Editing Requirements in Eclipse","text":"When you view the list of Requirements in the Eclipse task list, it will have the following general form:
Each Requirement is listed by name and number, together with its importance indicated by the equivalent Eclipse/Mylyn priority icon. To view the details of a specific Requirement, you should double-click on the Requirement, and the Requirements editor will be opened:
The Requirements editor screen is divided up into several sections:
Header -- this displays the name and ID of the Requirement, together with a graphical indication of its priority, its status, creation date and last-update date.
Attributes -- this displays the various SpiraTeam-specific attributes of the Requirement, including status, importance, scheduled release, component ID and planned effort. Any custom properties defined for the requirement will also be displayed.
Attachments -- this displays the list of documents, web-links and screenshots attached to the Requirement. You can also upload new files and screenshots to the Requirement from within Eclipse.
Description -- this displays the detailed description of the Requirement.
Comments -- this displays a threaded list of all the comments that have been added to the Requirement in SpiraTeam.
New Comment -- this allows you to add a new comment to the Requirement. The new comments will be sent to the SpiraTeam server when [Submit] is clicked.
People -- this displays the name and email address of the person who wrote the Requirement (author) and the person who it's currently assigned-to (owner).
Operations -- this contains the list of operations that can be performed on the Requirement. More information on operations can be found below.
You can make changes to the Requirement by simply changing the values in the appropriate dropdown list or editing the information in any of the text boxes. Once you have happy with the changes, you can update the version on the SpiraTeam server by clicking the [Submit] button. If there are any data validation errors, they will be displayed. Once you have corrected them, the Requirement changes will be accepted by the system.
In addition to making updates, you can perform the following actions on the Requirement:
Workflow Transitions -- these are the blue hyperlinks displayed directly above the [Submit] button in the actions tab. These allow you to change the status of the Requirement and when clicked, the fields in the Attributes section will change based on the new status. Note: changing the Type of the Requirement will disable the workflow transition hyperlinks until [Submit] is clicked.
Refresh the Requirement from the version on the server. This will update the local copy of the Requirement with the latest changes made on the SpiraTeam server.
Browse the version of the Requirement on the server. Clicking the \"globe\" icon will open up a browser and display the Requirement directly in SpiraTeam.
"},{"location":"IDE-Integration/Eclipse--Mylyn/#viewing-and-editing-tasks-in-eclipse","title":"Viewing and Editing Tasks in Eclipse","text":"When you view the list of Tasks in the Eclipse task list, it will have the following general form:
Each Task is listed by name and number, together with its priority indicated by the equivalent Eclipse/Mylyn priority icon. To view the details of a specific Task, you should double-click on the Task, and the Tasks editor will be opened:
The Tasks editor screen is divided up into several sections:
Header -- this displays the name and ID of the Task, together with a graphical indication of its priority, its status, creation date and last-update date.
Attributes -- this displays the various SpiraTeam-specific attributes of the Task, including status, scheduled release, priority, start-date, end-date, % complete, estimated effort, actual effort, the name/id of the Requirement it belongs to and its component. Any custom properties defined for the task will also be displayed.
Attachments -- this displays the list of documents, web-links and screenshots attached to the Task. You can also upload new files and screenshots to the Task from within Eclipse.
Description -- this displays the detailed description of the Task.
Comments -- this displays a threaded list of all the comments that have been added to the Task in SpiraTeam.
New Comment -- this allows you to add a new comment to the Task. The new comments will be sent to the SpiraTeam server when [Submit] is clicked.
People -- this displays the name and email address of the person who created the Task (creator) and the person who it's currently assigned-to (owner).
Operations -- this contains the list of operations that can be performed on the Task. More information on operations can be found below.
You can make changes to the task by simply changing the values in the appropriate dropdown list or editing the information in any of the text boxes. Once you have happy with the changes, you can update the version on the SpiraTeam server by clicking the [Submit] button. If there are any data validation errors (e.g. you have to enter a start-date to make the Task In-Progress), they will be displayed. Once you have corrected them, the Task changes will be accepted by the system.
In addition to making updates, you can perform the following actions on the Task:
Workflow Transitions -- these are the blue hyperlinks displayed directly above the [Submit] button in the actions tab. These allow you to change the status of the Task and when clicked, the fields in the Attributes section will change based on the new status. Note: changing the Type of the Task will disable the workflow transition hyperlinks until [Submit] is clicked.
Refresh the Task from the version on the server. This will update the local copy of the Task with the latest changes made on the SpiraTeam server.
Browse the version of the Task on the server. Clicking the \"globe\" icon will open up a browser and display the Task directly in SpiraTeam.
"},{"location":"IDE-Integration/Eclipse--Mylyn/#viewing-and-editing-incidents-in-eclipse","title":"Viewing and Editing Incidents in Eclipse","text":"When you view the list of Incidents in the Eclipse task list, it will have the following general form:
Each Incident is listed by name and number, together with its priority indicated by the equivalent Eclipse/Mylyn priority icon. To view the details of a specific Incident, you should double-click on the Incident, and the Incidents editor will be opened:
The Incidents editor screen is divided up into several sections:
Header -- this displays the name and ID of the Incident, together with a graphical indication of its priority, its status, creation date and last-update date.
Attributes -- this displays the various SpiraTeam-specific attributes of the Incident, including priority, severity, status, type, detected release, resolved release, verified release, start-date, closed-date, % complete, estimated effort, actual effort and component Id's. Any custom properties defined for the incident will also be displayed.
Attachments -- this displays the list of documents, web-links and screenshots attached to the Incident. You can also upload new files and screenshots to the Task from within Eclipse.
Description -- this displays the detailed description of the Incident.
Comments -- this displays a threaded list of all the comments that have been added to the Incident in SpiraTeam.
New Comment -- this allows you to add a new comment to the Incident. The new comments will be sent to the SpiraTeam server when [Submit] is clicked.
People -- this displays the name and email address of the person who found the Incident (detector) and the person who it's currently assigned-to (owner).
Operations -- this contains the list of operations that can be performed on the Incident. See below for more information on how to use this section.
You can make changes to the Incident by simply changing the values in the appropriate dropdown list or editing the information in any of the text boxes. Once you have happy with the changes, you can update the version on the SpiraTeam server by clicking the [Submit] button. If there are any data validation errors (e.g. you have to enter a start-date to make the Incident In-Progress), they will be displayed. Once you have corrected them, the Incident changes will be accepted by the system.
In addition to making simple updates, you can perform the following actions on the Incident:
Submit -- clicking the submit button will commit the changes made on the Incident to the SpiraTeam Server.
Workflow Transitions -- these are the blue hyperlinks displayed directly above the [Submit] button in the actions tab. These allow you to change the status of the Incident and when clicked, the fields in the Attributes section will change based on the new status. Note: changing the Type of the Incident will disable the workflow transition hyperlinks until [Submit] is clicked.
Refresh the Incident from the version on the server. This will update the local copy of the Incident with the latest changes made on the SpiraTeam server.
Browse the version of the Incident on the server. Clicking the \"globe\" icon will open up a browser and display the Incident directly in SpiraTeam.
"},{"location":"IDE-Integration/Jetbrains-IDEs/","title":"Jetbrains IDEs","text":"This section outlines how to use SpiraTest, SpiraPlan or SpiraTeam (hereafter referred to as SpiraTeam) in conjunction with any Jetbrains integrated development environment (IDE) for viewing Requirements, Tasks and Incidents. Rather than develop a new user-interface from scratch, the SpiraTeam plug-in uses the robust tool window functionality in Jetbrains IDEs which allows users to customize their experience.
"},{"location":"IDE-Integration/Jetbrains-IDEs/#installing-the-jetbrains-plug-in","title":"Installing the Jetbrains Plug-In","text":"This section outlines how to install the SpiraTeam plug-in for Jetbrains. It assumes that you already have a working installation of SpiraTest, SpiraPlan or SpiraTeam v5.0 or later and an up-to-date version of your Jetbrains IDE. For this tutorial we will be installing the plug-in in IntelliJ, Jetbrains' Java IDE.
If you have an earlier version of SpiraTeam, you will need to upgrade to at least v5.0 before trying to integrate with Jetbrains.
To obtain the Jetbrains plug-in, open up the Jetbrains settings dialog at File > Settings. This will open the settings dialog. Click on the \"Plugins\" section on the left. Your screen should look something like this:
Click on the \"Browse repositories\" button on the bottom of the screen, and enter \"SpiraTeam\" into the search bar. You should see the following result:
Click the Install button. After it has installed you will be asked to restart your IDE.
After your IDE has restarted, go to View > Tool Windows > SpiraTeam to open up the SpiraTeam Tool Window.
Click on the \"View Credentials\" button and put in your log-in credentials. Please note that you can obtain the RSS Token by going to your user profile inside SpiraTeam. If the RSS Token is blank, make sure to enable RSS, and click Save.
NOTE: this plugin lets users create artifacts in Spira, so please make sure that the user has create permissions for incidents and tasks to make full use of it.
Once you press the OK button, wait for the window to close. If your log-in information is correct, you should see the following screen in the SpiraTeam Tool Window:
"},{"location":"IDE-Integration/Jetbrains-IDEs/#viewing-requirements-tasks-and-incidents-in-jetbrains","title":"Viewing Requirements, Tasks and Incidents in Jetbrains","text":"Clicking on Requirements, Tasks or Incidents will expand a list of their respective item's that are open and are assigned to you. If, for instance, you have no open requirements assigned to you, you will not see the \"Requirements\" title in the SpiraTeam window. Here is an example of all three expanded:
Clicking on any requirement, task or incident will open up additional information in the bottom of the tool window. Clicking the title in this additional information panel will open the relevant item in SpiraTeam in your default browser.
"},{"location":"IDE-Integration/Jetbrains-IDEs/#creating-new-requirements-tasks-and-incidents-in-jetbrains","title":"Creating new Requirements, Tasks, and Incidents in Jetbrains","text":"Clicking the \"New\" button at the top of the SpiraTeam window or navigating to Tools > SpiraTeam > New Item will bring up the new item popup.
After you select your project and item type, the type, priority and owner fields will populate appropriately. If you do not wish to select a priority or owner, simply select \"---None --\" for either of them, and the field will not be populated in SpiraTeam.
Once you press OK, your artifact will be created and you will get a notification in the SpiraTeam Tool Window like this one:
Clicking on the notification label will dismiss it.
"},{"location":"IDE-Integration/Jetbrains-IDEs/#miscellaneous-functions","title":"Miscellaneous Functions","text":"If you want to change the user you are signed in as, you simply need to click on your username on the right of the \"Signed in as\" label.
Clicking the \"Refresh\" button will refresh your assigned items from the server, while the \"Home\" button will take you to your My Page in your default browser. Navigating to Tools > SpiraTeam will bring up another way of interacting with SpiraTeam
"},{"location":"IDE-Integration/Visual-Studio-2005---2008/","title":"Visual Studio 2005 - 2008","text":"This section outlines how to use SpiraTest, SpiraPlan or SpiraTeam (hereafter referred to as SpiraTeam) in conjunction with the Visual Studio (VS) integrated development environment (IDE) for viewing Requirements, completing Tasks and fixing Incidents.
The Add-In will operate in Visual Studio 2005 and 2008 but does require that the .NET framework version 3.5 SP1 is installed. It is normally installed with Visual Studio 2008 SP1 and Visual Studio 2010, but can be separately installed on a system with Visual Studio 2005 by downloading the installation file from Microsoft: http://www.microsoft.com/downloads/details.aspx?FamilyID=ab99342f-5d1a-413d-8319-81da479ab0d7
Visual Studio Express versions cannot support Add-Ins, you must at least have the standard version of the IDE for the Add-In to appear in the menu bar.
"},{"location":"IDE-Integration/Visual-Studio-2005---2008/#installing-the-visual-studio-add-in","title":"Installing the Visual Studio Add-In","text":"Download and execute the Add-In installation file from the Inflectra website. The add-in will be automatically added to VS's menu bar.
"},{"location":"IDE-Integration/Visual-Studio-2005---2008/#adding-and-assigning-spirateam-projects","title":"Adding and Assigning SpiraTeam Projects","text":"To view the Project Explorer, select \"SpiraTeam Project Explorer\" from the View menu. The tool window will open, and can be docked with any existing tool windows. When a solution is loaded that hasn't had any SpiraTeam projects assigned to it -- or if no solution is open -- the dialog will report so. If you have already assigned SpiraTeam projects to the open solution, they will each be loaded in a tree format in the tool window.
Visual Studio will remember the docking and location of the window, so that if you close it you can re-open it by selecting the menu option a second time. The window will re-open in the last position before it was closed.
Once the Project Explorer is open, click the \"Configuration\" button () in the Project Explorer's toolbar to open the SpiraTeam project dialog. Note that if you have no solution open, you can add, remove, and edit SpiraTeam projects, but you can only assign them to a solution when that solution is open:
Click the New button (
) to link to a new SpiraTeam project. The \"new SpiraTeam Project\" dialog will open. In the fields, enter in the following:
Server URL: The root address of your SpiraTeam installation. For example:
https://server1/SpiraTeam/ Do not put \"login.aspx\" or any other page address in this field.
User ID: Your user ID you use to log into the SpiraTeam application.
Password: Your password you use to log into the SpiraTeam application.
Once entered, click the \"Get Projects\" button. The add-in will connect to the server and get a list of projects that you are assigned to. Select the SpiraTeam project that you want to add, and click the \"Save\" button. Your project will appear in the dialog in the format of \"Project Name [Server]\". With a project selected in the left box, you can also Edit () and Delete ( ) the project.
With a solution loaded, you can select any number of SpiraTeam projects and assign them to the open Solution, by highlighting them, and clicking the \"Add >\" button. All projects assigned to the open solution will appear in the right side.
Clicking \"Save\" will return you to the IDE, and if you made any changes in the configuration, the Project Explorer will refresh and update its display.
"},{"location":"IDE-Integration/Visual-Studio-2005---2008/#viewing-spirateam-project-artifacts","title":"Viewing SpiraTeam Project Artifacts","text":"Once a solution is opened and there is a SpiraTeam project assigned, you can view the project's contents. At this time, the add-in will display the following items:
Incidents: Assigned to you, unassigned.
Tasks: Assigned to you, unassigned.
Requirements: Assigned to you.
By default, the Project Explorer will not show closed and completed items. However, by clicking the 'View Closed' () button in the toolbar, the Project Explorer will be updated to show closed and completed items as well.
Double-clicking on a node (or clicking on the item's arrow) will open that item up and show all the sub-items.
Clicking the Refresh () button on the toolbar will refresh the SpiraTeam projects in the Project Explorer. Double-clicking an artifact will open its details in the main tabbed document area for viewing and editing.
"},{"location":"IDE-Integration/Visual-Studio-2005---2008/#viewing-artifact-details","title":"Viewing Artifact Details","text":"By double-clicking an artifact in the Project Explorer, you can open the details for the item in the main tabbed-document view. All the details screens are very similar, here is the Incident Details view for reference:
The top of the window has the \"Save\" button, and any informational or warning messages will appear to the right of the Save button. The rest of the window has detail fields relating to the item, and depending on the current workflow, some fields may be required or disabled. (Note that at this time, Requirements are read-only.)
Once you make changes to the artifact, changes are saved to the server when the \"Save\" button is clicked.
Note that due to platform architecture differences, the HTML description may not appear and save exactly as entered, and there is no 'Source HTML' view. If visual integrity/layout is important, then we recommend editing the description and resolution fields in SpiraTeam's Web user interface instead.
"},{"location":"IDE-Integration/Visual-Studio-2005---2008/#data-concurrency-warnings","title":"Data Concurrency Warnings","text":"When trying to save an artifact, you may get a warning at the top of the window stating that the item was modified by another user. This error is telling you that changes were made to the item after the data on your screen was pulled from the server.
When this happens, you may see some fields highlighted in yellow or red. The colors represent data collisions:
Yellow -- Any field highlighted yellow is a field that you tried to change that wasn't changed by the other user.
Red -- Any field highlighted in red is a field that both you and the other user tried to change.
No Highlight -- Fields without a highlight were possibly changed by the other user, but you did not make any changes to those fields.
When a concurrency issue occurs, the new data is loaded from the server, losing your changes due to possible workflow collisions. Simply review the changed data and make your changes accordingly.
"},{"location":"IDE-Integration/Visual-Studio-2005---2008/#troubleshooting","title":"Troubleshooting","text":"The add-in is designed to capture all errors so that when something unexpected happens, work isn't lost. In most situations where an error occurs, a notification will be displayed of the error. In the Project Explorer, hover the mouse over the error node to get a full description of the error. Errors will also be logged to the desktop's Application Event Log.
A common symptom of an internal error is a blank or empty Details screen -- if this occurs when opening an artifact, save all your open work and restart Visual Studio. Contact support with the Application Event Log and inform them of the issue.
"},{"location":"IDE-Integration/Visual-Studio-2010/","title":"Visual Studio 2010","text":"This section outlines how to use SpiraTest, SpiraPlan or SpiraTeam (hereafter referred to as SpiraTeam) in conjunction with the Visual Studio (VS) integrated development environment (IDE) for viewing Requirements, completing Tasks and fixing Incidents.
This add-in is meant for use with Visual Studio 2010 or later and SpiraTest, SpiraPlan or SpiraTeam (hereafter referred to as SpiraTeam) version v4.0 or later. It does require that .NET v4.0 is installed; however this is required by Visual Studio 2010 by default.
"},{"location":"IDE-Integration/Visual-Studio-2010/#installing-the-visual-studio-add-in","title":"Installing the Visual Studio Add-In","text":"The Visual Studio 2010 version can be downloaded from the Inflectra SpiraTeam add-ons webpage:
Please do not use the version in the Visual Studio gallery, that is the newer Visual Studio 2012 extension which is not compatible with Visual Studio 2010.
"},{"location":"IDE-Integration/Visual-Studio-2010/#adding-and-assigning-spirateam-projects","title":"Adding and Assigning SpiraTeam Projects","text":"After installing, a new menu item will appear under the \"View\" menu.
To view the Project Explorer, select \"SpiraTeam Project Explorer\" from the View menu. The tool window will open, and may be docked like any other tool window. When a solution is loaded that hasn't had any SpiraTeam projects assigned to it -- or if no solution is open -- the tool window will give a message saying so. Once a project is loaded that contains linked SpiraTeam projects, or a SpiraTeam project is added to the current open solution, then the tool window will load in the SpiraTeam projects and display them.
To add, remove, and assign a SpiraTeam project to the open solution, click the Configuration Button in the Tool Window (), which will open the configuration dialog:
Click the New button () to link to a new SpiraTeam project. The \"new SpiraTeam Project\" dialog will open. In the fields, enter in the following:
Server URL: The root address of your SpiraTeam installation. For
example: https://server1/SpiraTeam/ Do not put \"login.aspx\" or any other page address in this field.
User ID: Your user ID you use to log into the SpiraTeam application.
Password: Your password you use to log into the SpiraTeam application.
Once entered, click the \"Get Projects\" button. The add-in will connect to the server and get a list of projects that you are assigned to. Select the SpiraTeam project that you want to add, and click the \"Save\" button. Your project will appear in the dialog in the format of \"Project Name [Server]\". With a project selected in the left box, you can also Edit () and Delete () the project.
With a solution loaded, you can select any number of SpiraTeam projects and assign them to the open Solution, by highlighting them, and clicking the \"Add >\" button. All projects assigned to the open solution will appear in the right side.
Clicking \"Save\" will return you to the IDE, and if you made any changes in the configuration, the Project Explorer will refresh and update its display.
"},{"location":"IDE-Integration/Visual-Studio-2010/#viewing-spirateam-project-artifacts","title":"Viewing SpiraTeam Project Artifacts","text":"Once a solution is opened and there is a SpiraTeam project assigned, you can view the project's contents. At this time, the add-in will display the following items:
Incidents: Assigned to you and unassigned.
Tasks: Assigned to you and unassigned.
Requirements: Assigned to you and unassigned.
By default, the Project Explorer will not show closed and completed items. However, by clicking the 'View Closed' () button in the toolbar, the Project Explorer will be updated to show closed and completed items as well.
Double-clicking on a node (or clicking on the item's arrow) will open that item up and show all the sub-items:
Clicking the Refresh () button on the toolbar will refresh the highlighted item in the tree, and all sub-items contained within it. SpiraTeam projects in the Project Explorer.
All items have a right-click menu, and the options available for items are as follows:
View Details: Opens the details of the item in a tool window inside the IDE.
View in Browser: Opens the details of the item in a browser.
Start/Stop Timer: For Tasks and Incidents only. Starts or Stops a work timer for that item.
Refresh List: For folders and project only. Refreshes the folder or project's contents.
Copy to Clipboard: Copies the artifact's token into the clipboard, for easy pasting into Version Control commits or descriptions.
By double-clicking an artifact in the Project Explorer, you can open the details for the item in the main tabbed-document view. All the details screens are very similar.
All of the fields closely match the fields as they appear in SpiraTeam's interface. The toolbar at top lets you Save the item, Refresh the details, and view the item in the browser if you so wish. Tasks and Incidents also have a Work Timer button on the toolbar, which lets a developer mark an item as being worked on, and when the developer stops working, it will update the fields with any time worked. Incident screens also have the Workflow steps up in the toolbar under the \"Change Status\" dropdown.
Once you make changes to the artifact, changes are saved to the server when the \"Save\" button is clicked.
Note: Due to platform architecture differences, the HTML description may not appear and save exactly as entered, and there is no 'Source HTML' view. If visual integrity/layout is important, then we recommend editing the description and resolution fields in SpiraTeam's Web user interface instead.
"},{"location":"IDE-Integration/Visual-Studio-2010/#data-concurrency-and-errors-while-saving","title":"Data Concurrency and Errors while Saving","text":"In the case an item was changed by someone else while the details screen was open, you will get an error indicating that the item was changed. There are two possible options at this point:
If the data that was changed locally does not conflict with any changes made by the other user, then you will be given the option to Merge or Reload the data.
If a field was changed locally that was also changed by another user, the only option that will be given will be to reload the data.
If you opt to merge, then changes taken from the other user will be merged with your changes, and the item will be saved to the server. However, if you choose to reload, then your changes will be lost and you will need to make your changes again.
For incidents, some fields may be marked as being required by the current workflow. In this case, the labels will be highlighted in bold. If you try to save an item without all required fields, an error will be displayed, and the field in error will be highlighted in red.
"},{"location":"IDE-Integration/Visual-Studio-2010/#troubleshooting","title":"Troubleshooting","text":"The add-in is designed to capture all errors so that when something unexpected happens, work isn't lost. In most situations where an error occurs, a notification will be displayed of the error. In the Project Explorer, hover the mouse over the error node to get a full description of the error. Errors will also be logged to the desktop's Application Event Log or a text file in case there was a problem connecting to the Event Log on the local computer.
A common symptom of an internal error is a blank or empty Details screen -- if this occurs when opening an artifact, save all your open work and restart Visual Studio. Contact support with the Application Event Log and inform them of the issue.
"},{"location":"IDE-Integration/Visual-Studio-Code/","title":"Visual Studio Code","text":"This plugin creates a new custom view which allows you to seamlessly view your assigned Spira Tasks, Requirements, and Incidents as well as create brand new Tasks right from Visual Studio Code.
"},{"location":"IDE-Integration/Visual-Studio-Code/#guide-basics","title":"Guide Basics","text":"Unfortunately, this plugin only works with version 5.3 and above of the Spira ALM suite. If you have an older version, you need to update to use this plugin.
This guide assumes you are familiar with Visual Studio Code and have already installed our plugin from the store.
"},{"location":"IDE-Integration/Visual-Studio-Code/#logging-in","title":"Logging in","text":"Open the command palette and type in 'credentials' as shown:
Hit return to begin the Spira authentication process. You should see an input box that asks you to type the base URL of your Spira service. This should access the 'root' directory of your Spira, not including the ending slash. An example is provided below:
Hit return when you typed in your URL to move on to the next step. You will be prompted to enter your Spira username, which you use when signing into your Spira subscription. See the example below for assistance.
After you entered your username, hit return to move onto your final step. You will be prompted to enter your RSS Token, which must be enabled in your user profile to work.
Here is the location of the RSS Token in your profile:
Here is a sample image of a (fake) RSS Token:
"},{"location":"IDE-Integration/Visual-Studio-Code/#viewing-your-assigned-requirements-tasks-and-incidents","title":"Viewing your Assigned Requirements, Tasks, and Incidents","text":"You should see a new icon on the left menu where the explorer, search bar, version control, etc are expanded from. Alternatively, you can expand the view by pressing alt+s Here is an image of the Spira icon:
Click on the new icon to open the Spira panel where you can see all of the Tasks, Requirements, and Incidents that are assigned to you. You can expand/collapse any of the different types of items. You should now see a view similar to this:
Clicking on one of the different items, 'Cannot log into the application' for instance will bring up a view similar to this:
Ctrl clicking on the url for the artifact will open the selected item in your default browser.
"},{"location":"IDE-Integration/Visual-Studio-Code/#refreshing-your-assigned-items-from-spira","title":"Refreshing your Assigned Items from Spira","text":""},{"location":"IDE-Integration/Visual-Studio-Code/#refreshing-automatically","title":"Refreshing Automatically","text":"By default, your assigned items are refreshed every 60 seconds. If you would like to change this, see Changing Auto-Refresh Time
Changing the setting will affect how often the server is pinged to refresh the list. If you put in 0 or below, the list will never automatically refresh, and a value between 1 and 5 will default to 5 seconds. If you changed the setting from 0 or below to above 0, please refresh manually as shown below:
"},{"location":"IDE-Integration/Visual-Studio-Code/#refreshing-manually","title":"Refreshing Manually","text":"Running 'Spira - Refresh' in the command palette or hitting alt+s, alt+r by default on windows will refresh manually.
"},{"location":"IDE-Integration/Visual-Studio-Code/#creating-a-new-task","title":"Creating a new Task","text":"You can easily create a new task in VS Code by running 'Spira - Create New Task' in the command palette or by hitting alt+s, alt+t on windows. This will take any highlighted text and dump it into the name prompt. Feel free to change the name if you like.
Hit return and select a project from the dropdown as shown below:
Hit return and you should see it in the Spira panel on the left and get a popup in the bottom right telling you it was a success!
"},{"location":"IDE-Integration/Visual-Studio-Code/#settings","title":"Settings","text":""},{"location":"IDE-Integration/Visual-Studio-Code/#changing-auto-refresh-time","title":"Changing Auto-Refresh Time","text":"By default, the panel will refresh every 60 seconds, but this can easily be changed or disabled altogether through settings. To change this, open up your settings and search for 'spira' as shown below:
"},{"location":"IDE-Integration/Visual-Studio-Code/#disabling-an-item-type","title":"Disabling an Item Type","text":"If you like, you can prevent displaying a particular item type. This can be particularly useful if you only want to view your assigned tasks, which should also decrease load times. To accomplish this, simply search 'spira' in settings and switch any of the 'showType' settings to false. See the image below for an example:
"},{"location":"IDE-Integration/Visual-Studio/","title":"Visual Studio","text":"This section outlines how to use SpiraTest, SpiraPlan or SpiraTeam (hereafter referred to as SpiraTeam) in conjunction with the Visual Studio (VS) integrated development environment (IDE) for viewing Requirements, completing Tasks and fixing Incidents.
This add-in is meant for use with Visual Studio 2012 or later and SpiraTest, SpiraPlan or SpiraTeam (hereafter referred to as SpiraTeam) version v5.0 or later. It does require that .NET v4.5 be installed; however this is required by Visual Studio 2012 by default.
"},{"location":"IDE-Integration/Visual-Studio/#installing-the-visual-studio-add-in","title":"Installing the Visual Studio Add-In","text":"The addin is downloadable from Microsoft's Visual Studio Gallery, or from within Visual Studio by going to Tools -> Extension Manager and searching for \"SpiraTeam\". If downloaded from within Visual Studio, after installation the IDE will need to be restarted. If downloaded from the browser, double-click on the VSIP file and it will walk you through the installation process.
"},{"location":"IDE-Integration/Visual-Studio/#adding-and-assigning-spirateam-projects","title":"Adding and Assigning SpiraTeam Projects","text":"After installing, a new menu item will appear under the \"View\" menu:
To view the Project Explorer, select \"SpiraTeam Project Explorer\" from the View menu. The tool window will open, and may be docked like any other tool window. When a solution is loaded that hasn't a SpiraTeam project assigned to it -- or if no solution is open -- the tool window will give a message saying so:
Once a project is loaded that contains linked SpiraTeam projects, or a SpiraTeam project is added to the current open solution, then the tool window will load in the SpiraTeam projects and display them.
To add, remove, and assign a SpiraTeam project to the open solution, click the SpiraTeam Configuration Button in the Tool Window (looks like a cog), which will open the configuration dialog:
In the fields, enter in the following:
Server URL: The root address of your SpiraTeam installation. For
example: https://server1/SpiraTeam/ Do not put \"login.aspx\" or any other page address in this field.
User ID: Your user ID you use to log into the SpiraTeam application.
Password: Your password you use to log into the SpiraTeam application.
Once entered, click the \"Get Projects\" button. The add-in will connect to the server and get a list of projects that you are assigned to.
Select the SpiraTeam project that you want to add, and click the \"Save\" button.
Clicking \"Save\" will return you to the IDE, and if you made any changes in the configuration, the Project Explorer will refresh and update its display.
"},{"location":"IDE-Integration/Visual-Studio/#viewing-spirateam-project-artifacts","title":"Viewing SpiraTeam Project Artifacts","text":"Once a solution is opened and there is a SpiraTeam project assigned, you can view the project's contents. At this time, the add-in will display the following items:
Users: Users in your Spira contacts list
Incidents: Assigned to you and open.
Tasks: Assigned to you and not completed.
Requirements: Assigned to you and not developed yet.
Double-clicking on a node (or clicking on the item's arrow) will open that item up and show all the sub-items:
Clicking the Refresh button on the toolbar will refresh the highlighted item in the tree, and all sub-items contained within it. SpiraTeam projects in the Project Explorer.
All items have a right-click menu, and the options available for items are as follows:
View in Browser: Opens the details of the item in your current web browser.
Refresh List: For folders and project only. Refreshes the folder or project's contents.
Copy to Clipboard: Copies the artifact's token into the clipboard, for easy pasting into Version Control commits or descriptions.
By double-clicking an artifact in the Project Explorer (or choosing View in Browser), you can open the details for the item in the current tab of your web browser:
In addition, when you select one of the items in the add-in treeview, the add-in will display the properties for that item in the standard Visual Studio properties window:
This lets you decide whether you want to open the item in SpiraTeam before actually doing so. In a similar vein, there is a helpful tooltip displayed for all items in the tree:
"},{"location":"IDE-Integration/Visual-Studio/#creating-a-task","title":"Creating a Task","text":"If you click on the (+) icon in the extension toolbar you will be able to quickly log a new task in SpiraTeam or SpiraPlan, making it easier to track new developer tasks and have them sync across machines:
Just enter the name of the new task and it will be created in SpiraTeam, then displayed in the task list:
"},{"location":"IDE-Integration/Visual-Studio/#troubleshooting","title":"Troubleshooting","text":"The add-in is designed to capture all errors so that when something unexpected happens, work isn't lost. In most situations where an error occurs, a notification will be displayed of the error. In the Project Explorer, hover the mouse over the error node to get a full description of the error.
Errors will also be logged to the desktop's Application Event Log or a text file in case there was a problem connecting to the Event Log on the local computer. Contact support with the Application Event Log and inform them of the issue.
"},{"location":"Migration-and-Integration/Importing-from-Google-Sheets/","title":"Importing from Google Sheets","text":"The web-based interface of SpiraTeam\u00ae is ideal for creating and managing all aspects of your projects. However when migrating requirements, release, tasks, incidents, and test cases with test steps for an existing project from another system, it is useful to be able to retrieve and load in a batch of artifacts, rather than having to manually enter them one at a time.
To simplify this task we've created a Google sheets add-on for SpiraTeam\u00ae that can import requirements, releases, tasks, and test cases with test steps from a generated spreadsheet into SpiraTeam\u00ae.
*This guide assumes you have a Google account with access to Google Drive and persistent access to the internet. It also assumes your instance of SpiraTeam (or SpiraTest, or SpiraPlan) is accessible over the internet so that Google Sheets can send data to it.
"},{"location":"Migration-and-Integration/Importing-from-Google-Sheets/#installing-the-spirateam-google-sheets-integration-add-on","title":"Installing the SpiraTeam\u00ae Google Sheets Integration Add-on","text":"Like most Google services installation is very simple and straightforward as long as you have a Google account.
Before connecting to SpiraTeam\u00ae with the add-on make sure that you're working on the first tab in the spreadsheet.
When the add-on fully loads you will be able to enter your SpiraTeam\u00ae log in credentials.
Spira URL : Please enter the web address that you use to access SpiraTeam\u00ae in your browser. This is usually of the form http://<hostname>/SpiraTeam. Make sure that you remove any suffixes from the address (e.g. Default.aspx).
RSS Token : Please enter your RSS token including the curly braces i.e {ExampleRSS}.
To activate your RSS Token:
Click on the User Profile menu in the application header
Click on \"My Profile\"
The string of numbers including the brackets listed in the RSS Token text box is your token.
If you don't see an RSS Token in that box, then click on 'Enable RSS Feeds' so that it is checked.
Click the button 'Generate New' to get a new RSS token.
Click [Update] to save your changes
Once you have successfully connected to SpiraTeam, you should now choose the appropriate Project and Artifact in the system to which you will be importing into SpiraTeam. As you make your selections more buttons will be enabled.
After the project and artifact have been selected both buttons below these dropdowns should now be clickable. One let's you start entering data to send to SpiraPlan, the other gets data from SpiraPlan.
"},{"location":"Migration-and-Integration/Importing-from-Google-Sheets/#preparing-your-template","title":"Preparing your Template","text":"The SpiraTeam Google Sheets Integration add-on dynamically generates a template for each artifact with the click of a button. After a valid project and artifact have been selected the [ Prepare Template ] button will be enabled. Click this button to generate the required template on the currently selected sheet.
Warning: make sure no data on this sheet is needed as the entire sheet will be wiped
"},{"location":"Migration-and-Integration/Importing-from-Google-Sheets/#filling-in-the-template","title":"Filling in The Template","text":"The above template is for requirements. Fields which have list of values to select from have dropdowns to make choosing the right values easy.
For an artifact to be created successfully in SpiraPlan it has to have certain fields filled in. These required fields are highlighted in bold black text. For example, the above screenshot is for requirements, where both the Name and Type field are required.
Different artifacts have different factors to take account of when entering the data:
Requirements: SpiraPlan allows a hierarchy of requirements (where each requirement can have children, who can, in turn, have child requirements of their own). To designate the hierarchy level of requirements, use the \">\" character. For example:
\"Parent Requirement\"
\"> Child of Parent\"
\"> Another child of parent\"
\">> Child of \"Another Child\"\"
\"A second parent requirement\"
Releases: are also hierarchical, and this is set on the sheet in the same way as requirements
Incidents and Tasks: neither of these artifacts have any special factors to take into account
Test Cases with Test Steps: The screenshot below shows the basic template for Test Cases. Please note the following points:
A test step must have a test case parent to be linked to and all test steps below a test case will become the steps for that test case.
There is no need to number the test steps -- SpiraPlan adds this information automatically
Because each row can either be a case or a step, there are columns for both -- some are only for test cases, others are only for tests steps
The lighter orange column names are ONLY for test step creation
Fields with black text are required: darker orange ones are needed for a test case, lighter orange ones for a test step
If a row has a mix of required fields in for both test cases and test steps, the addon won't know if it is a test case or a test step, so it will flag this an error
Below is a partially filled in test case with test steps template -- it is visually easy to see which rows are steps to which case.
"},{"location":"Migration-and-Integration/Importing-from-Google-Sheets/#import-into-spiraplan","title":"Import Into SpiraPlan","text":"Before importing new artifacts, make sure that you're on the correct tab and the dropdowns in the sidebar show the correct project and artifact type.
After the correct/required fields have been entered, click the [ Send to SpiraPlan] button to send your data to SpiraPlan\u00ae. You will see a popup showing overall progress.
When the artifact has been successfully created an ID number will be placed in the ID column. This is the ID straight from SpiraPlan.
If there are any errors for a particular row (eg if required fields have not all been filled in, or if there was some other problem with the data or on the SpiraPlan server) that row will be highlighted with a comment in column A explain the problem.
For hierarchical artifacts (ones with parents and children), the import process will stop as soon as any error is found, to ensure SpiraPlan does not create an incorrect hierarchy
"},{"location":"Migration-and-Integration/Importing-from-Google-Sheets/#get-data-from-spiraplan","title":"Get data From SpiraPlan","text":"To get all the data for the specified project and artifact from SpiraPlan, instead of going through the steps outlined in Preparing your Template to Import Into SpiraPlan above, click the [ Get From SpiraPlan ] button. This will first load up the template on the current sheet then automatically retrieve all data from SpiraPlan and add it to the sheet.
"},{"location":"Migration-and-Integration/Importing-from-Microsoft-Excel-%28Office365%29/","title":"Importing from Microsoft Excel (Office 2016+, iOS, web)","text":"This add-in works with Microsoft Excel 2016+, Excel in the cloud (via a web browser), and Excel on iPad OS. The add-in lets you import or export data to and from any product in your SpiraTest, SpiraTeam, or SpiraPlan application.
The add-in works for:
In legacy versions of this add-in, you needed to download a static excel template to help make sure you enter data into it in the correct way. However, this new add-in dynamically creates the sheet headers and cell validation based on the artifact and product you select.
"},{"location":"Migration-and-Integration/Importing-from-Microsoft-Excel-%28Office365%29/#installation","title":"Installation","text":"To install the add-in:
You can use this add-in with SpiraTest\u00ae, SpiraTeam\u00ae, or SpiraPlan\u00ae.
If you are using Excel in the browser, make sure your SpiraPlan is accessible over the internet.
If there is a problem connecting to Spira you will be notified with an error message.
After you have logged in click Logout to close your connection with Spira and take you back to the add-in's login page.
On-premise customers
If you have an on-premise Spira installation and you are not able to login to the add-in with valid credentials, please ask your local IT team to issue a self-signed certificate for your Spira instance, as some Excel versions require it.
"},{"location":"Migration-and-Integration/Importing-from-Microsoft-Excel-%28Office365%29/#2-choose-which-mode-to-use","title":"2. Choose which mode to use","text":"The add-in has three main modes: getting data from Spira, Sending data to Spira, and Administrator Functions. Please choose a mode to proceed. Only Spira administrator users can see the third button.
Once you have successfully connected the Excel add-in to your Spira app, you need to decide what you want to use this add-in for. You can go back and change your mind at any time.
"},{"location":"Migration-and-Integration/Importing-from-Microsoft-Excel-%28Office365%29/#get-data-from-spira-exporting","title":"Get data from Spira (exporting)","text":"This button will prompt you to pick a product and artifact to get from Spira and load into the spreadsheet (on the current active sheet). Getting data from Spira can be helpful to share with colleagues who are not using Spira. You can get up to 2,000 artifacts at a time. If there are more than 2,000 artifacts, use the \"Page\" option to get subsequent pages / batches of 2,000 artifacts (for example, selecting page 3, will retrieve artifacts 4001 to 6000). The pagination feature may not be available for all the artifacts.
Updating Data in Spira
Once you have the data from Spira loaded into Excel you can freely edit it. You can then, optionally, update the data in Spira by clicking the \"Update Spira\" button. This will send every artifact on the sheet back to Spira, updating each and every one. Each row will be sent in full to Spira - if you blank out a cell, that value will be blanked out in Spira.
If there are any errors during the update process you will see relevant explanations, with the specific cells (as relevant) that are causing the problem highlighted in red.
If you only wish to update a single artifact, we recommend deleting all the other rows of data to keep things clean.
You can only update artifacts that already exist in Spira. You cannot create new artifacts at the same time as updating.
"},{"location":"Migration-and-Integration/Importing-from-Microsoft-Excel-%28Office365%29/#send-data-to-spira-importing","title":"Send data to Spira (importing)","text":"This button will prompt you to pick a product and artifact to send new data to Spira (from the currently active sheet). Before you can enter data to send, the add-in creates a dynamic template for that specific product and artifact to make it easier for you to enter data correctly. Therefore if you have data already in your sheet, make sure to create a new worksheet for Excel to wipe and prepare for you.
Click \"Prepare Sheet\" to create this template for your chosen product and artifact. Do not alter the worksheet structure in any way after the template has been created (for example do not merge cells, change formatting or delete columns).
Once the template is ready you can start entering your new data2. Once you have entered in all required data, click the \"Send\" button to add the data to Spira. Note: cells highlighted in grey are not editable.
If there are any errors during the sending process you will see relevant explanations, with the specific cells (as relevant) that are causing the problem highlighted in red.
Show Advanced Fields (optional): When you enable this, you have more options when sending data to or updating data in Spira that are normally not available. This lets you create new comments and add associations between specific artifacts. Check the box 'Show Advanced Fields' to activate it for the two previous modes of operation.
"},{"location":"Migration-and-Integration/Importing-from-Microsoft-Excel-%28Office365%29/#administrator-functions","title":"Administrator Functions","text":"This mode is only available for Spira system administrators. When you login to the add-in with administrator credentials, you will see the \"Product Template and System Admin\" section, at the bottom of the second screen. Clicking the \"Get or Send data\" button in this section will let you:
Select this under \"Operations\" and click \"Prepare Data Template Sheet\" to load the template.
Populate the sheet with at least the required (bold) fields and hit \"Send Data\". The just-created new users will already be approved in Spira. If you try to make a new user with a username that already exists, no data will be created or updated in Spira. Instead, the username's ID will be shown in the first column.
"},{"location":"Migration-and-Integration/Importing-from-Microsoft-Excel-%28Office365%29/#add-new-artifact-folders-to-spira","title":"Add new Artifact Folders to Spira","text":"Select this option under \"Operations\", then select an Artifact type and a Product to create the folders. Then, click on \"Prepare Data Template\" to load the template spreadsheet. Enter the new folder data in the spreadsheet. Finally, hit \"Send Data\" and wait until the data is sent to Spira. To create subfolders, use a \"> \" character at the start of the \"Name\" field to mark the hierarchy. This is illustrated in the example below
Folder 1 (root level)\n> Folder 2 (subfolder of Folder 1)\n> Folder 3 (subfolder of Folder 1)\n> > Folder 4 (subfolder of Folder 3)\n> > > Folder 5 (subfolder of Folder 4)\n> Folder 6 (subfolder of Folder 1)\nFolder 7 (root level)\nSelect this under \"Operations\" and then select the product template you want to add the new list(s) and value(s). Then, click on \"Prepare Data Template Sheet\" to load the template. Populate the sheet with at least the required (bold) fields. Please note that you must reserve one row for a list and one or more for its values. Finally, hit \"Send Data\" and wait until the data is sent to Spira.
"},{"location":"Migration-and-Integration/Importing-from-Microsoft-Excel-%28Office365%29/#edit-existing-custom-lists-and-values","title":"Edit Existing Custom Lists and Values","text":"Select this under \"Operations\" and select the product template to edit the lists in, and then from the dropdown select either:
Now click on \"Get Data from Spira\" to load the template. Edit the sheet values freely. Remember to keep/provide new required (bold) fields. Additionally, you can add new values to existing lists, and also add brand new lists (with their values).
When ready, hit \"Send Updated Data\" and wait until the data is sent to Spira.
"},{"location":"Migration-and-Integration/Importing-from-Microsoft-Excel-%28Office365%29/#3-prepare-for-the-data-transfer","title":"3. Prepare for the data transfer","text":"This section is valid for the non-admin modes only (getting data and creating new data).
After you have chosen which mode to use, select the product and artifact from the dropdown menus.
For a given artifact, the required fields are:
Allow Empty at the custom property definition is toggled to NoWhen \"Show Advanced Fields\" is enabled you will see a column called \"New Comments\". This lets you create new comments in Spira when sending the relevant items to Spira
To add a new comment, enter the comment in the column \"New Comment\". When you send data to or update Spira, this will be saved as a new comment in the artifact.
Please note that you can only create new comments. You cannot get existing comments from Spira.
"},{"location":"Migration-and-Integration/Importing-from-Microsoft-Excel-%28Office365%29/#advanced-fields-associations","title":"Advanced Fields: associations","text":"When \"Show Advanced Fields\" is enabled you will may see columns that let you create associations between artifacts. This is an advanced feature because you need to know the exact IDs and type them in manually. For a more user friendly experience associating artifacts please use the main application.
To create an association between artifacts: - find the column of the artifact type you want to associate to (e.g.: \"New Linked Requirement(s)\") - enter the ID(s) of the artifact(s) to associate with. - associate multiple artifacts at a time using a comma-separated list of IDs, e.g.: 335,336,337.
Using the add-in, it's possible to associate:
Please note that you can only create new associations. You cannot get existing associations from Spira
"},{"location":"Migration-and-Integration/Importing-from-Microsoft-Excel-%28Office365%29/#entering-or-updating-data-for-different-artifacts","title":"Entering or Updating Data for different artifacts","text":""},{"location":"Migration-and-Integration/Importing-from-Microsoft-Excel-%28Office365%29/#requirements","title":"Requirements","text":"Indenting items: SpiraPlan lets you create a hierarchy of requirements (where each requirement can have children, who can, in turn, have child of their own). Use a \"> \" at the start of the \"Name\" field to mark a requirement a child of the row above it. This is illustrated in the example below
Indenting Example:\nItem 1\n> Item 2 child of item 1\n> Item 3 child of item 1\n> > Item 4 child of item 3\nStatus: when adding new Requirements, the status you see in Spira may not match the one you selected in the add-in. This is because the status is often calculated by the system itself. E.g.: the 'Requested' status is automatically updated to 'Planned' in Spira if the requirement is assigned to a Release. You can always get the data from Spira to see the most updated fields in the spreadsheet.
Estimate Points for Epics: will get replaced by the child requirement in Spira, even if you selected a different value in the add-in.
Changing the hierarchy by updating: you cannot change where a requirement is in the hierarchy when updating. Do not attempt to change any requirement's relative row or indentation - it will be ignored by the add-in.
"},{"location":"Migration-and-Integration/Importing-from-Microsoft-Excel-%28Office365%29/#releases","title":"Releases","text":"Indenting items: SpiraPlan lets you create a hierarchy of releases (where each release can have children, who can, in turn, have child of their own). Use a \"> \" at the start of the \"Name\" field to mark a release a child of the row above it. This is illustrated in the example below
Indenting Example:\nItem 1\n> Item 2 child of item 1\n> Item 3 child of item 1\n> > Item 4 child of item 3\nChanging the hierarchy by updating: you cannot change where a release is in the hierarchy when updating. Do not attempt to change any release's relative row or indentation - it will be ignored by the add-in.
"},{"location":"Migration-and-Integration/Importing-from-Microsoft-Excel-%28Office365%29/#test-cases-and-test-steps","title":"Test Cases and Test Steps","text":"Don't get confused between test cases and test steps
Test steps are an integral part of test cases so we let you view and add test cases and their steps together in the same table. This combination of two different artifacts can be confusing because they have different fields and requirements. Because each row can either be a case or a step, there are columns for both -- some are only for test cases, others are only for tests steps.
To create a test case with a step, fill in the test case fields in the first row. Then fill in the test step fields for the second row. Add more steps as needed in new rows. To add a second test case, start a new row and fill in the test case fields again.
Make sure: each row only fills in either the required test case or test step columns. If the system cannot tell whether an entry is a test case or step it is skipped over when sending to Spira.
Following is an example of how to add Test Cases and Test Steps to Spira:
"},{"location":"Migration-and-Integration/Importing-from-Microsoft-Excel-%28Office365%29/#incidents","title":"Incidents","text":"Remaining Effort: the add-in populates 'Remaining Effort' in Spira equally to the spreadsheet's entry for 'Estimated Effort'
"},{"location":"Migration-and-Integration/Importing-from-Microsoft-Excel-%28Office365%29/#tasks","title":"Tasks","text":"This artifact does not have any special factors to take into account.
"},{"location":"Migration-and-Integration/Importing-from-Microsoft-Excel-%28Office365%29/#test-sets","title":"Test Sets","text":"This artifact does not have any special factors to take into account.
"},{"location":"Migration-and-Integration/Importing-from-Microsoft-Excel-%28Office365%29/#risks","title":"Risks","text":"This artifact does not have any special factors to take into account.
"},{"location":"Migration-and-Integration/Importing-from-Microsoft-Excel-%28Office365%29/#components","title":"Components","text":"Only system administrators will see this entry in the dropdown for getting and sending data from/to Spira.
"},{"location":"Migration-and-Integration/Importing-from-Microsoft-Excel-%28Office365%29/#folders","title":"Folders","text":"Only system administrators will see this entry in the dropdown for sending data to Spira. You can create folder for different artifact types at the same time. Just select them under the Artifact column in the worksheet.
Only system administrators can Add/Edit Custom Lists and Values going to the second/third option of the \"Product Template/System Admin. Operation\"` menu. Please note that:
Only system administrators can create new users going to the first option of the \"Product Template/System Admin Operations\" menu.
"},{"location":"Migration-and-Integration/Importing-from-Microsoft-Excel-%28Office365%29/#other-actions-you-can-do-on-after-you-have-logged-in-to-the-add-in","title":"Other actions you can do on after you have logged in to the add-in","text":"What can the Excel365 add-in do that the Classic Excel add-in cannot?
What can the Excel Classic add-in do that the Excel365 add-in cannot?
NOTE The classic version of our Excel importer can create test runs. Please refer to the SpiraPlan TestRunner for Excel 365 add-in to use these functionalities in our new generation of add-ins.
Requires system administrator credentials\u00a0\u21a9\u21a9\u21a9\u21a9
Please note that you can currently only send a maximum of 10,000 rows of data to Spira at a a time.\u00a0\u21a9
Not compatible with Excel Professional 2016 and 2019 versions \u21a9
Danger
If you are using recent versions of Excel and Spira, then do not use this Add-In. This is legacy addon only.
Please use our Excel365 importer instead.
The web-based interface of SpiraTeam\u00ae is ideal for creating and managing requirements, test cases and incidents for a new project. However when migrating requirements, test cases, test steps and incidents for an existing project from another system or Microsoft Office document (e.g. Excel), it is useful to be able to load in a batch of artifacts, rather than having to manually enter them one at a time.
To simplify this task, SpiraTeam\u00ae comes with a Microsoft Excel Add-In that can export requirements, test cases, test steps and incidents from a populated Excel sheet into SpiraTeam\u00ae. In addition, the Add-In allows you to import those same artifacts back into the Excel sheet to make batch updates which can then be used to update the master copies on the server.
Note that this guide refers to SpiraTeam\u00ae, but the Excel Add-In can be used with SpiraTest\u00ae and SpiraPlan\u00ae as well. The only difference is that some of the artifact types may not be available in SpiraPlan/Test.
"},{"location":"Migration-and-Integration/Importing-from-Microsoft-Excel/#installing-the-microsoft-excel-add-in","title":"Installing the Microsoft Excel Add-In","text":"The first thing you need to do is to go to the \"Add-Ons and Downloads\" page of the Inflectra Website (it can be found in the SpiraTest, SpiraPlan or SpiraTeam sections), and download the MS-Office Add-Ins installation package. There are separate packages for the following versions of MS Office:
MS-Office 2003 Add-Ins -- these are compatible with Microsoft Office 2003 and 2007. They can connect to SpiraTeam v2.3 or later. They also require Microsoft .NET 3.5.
MS-Office 2007 Add-Ins -- these are compatible with Microsoft Office 2007 and 2010. They can connect to SpiraTeam v3.0 or later. They also require Microsoft .NET 4.0.
MS-Office 2010 Add-Ins -- these are compatible with Microsoft Office 2010 and later. They can connect to SpiraTeam v5.0 or later. They also require Microsoft .NET 4.0.
This installation package will install the add-ins for Microsoft Excel, Word and Project at the same time. If you don't have the correct version of Microsoft .NET installed or some of the necessary prerequisites, you will be given the opportunity to install them when you first run the installation package.
Once you have the Excel Add-In installed, the second thing you'll need to download is the SpiraImportTemplate Excel Sheet. This spreadsheet contains the necessary pre-formatted columns that are needed for the Add-In to easily recognize the data and know how to handle it. There are three versions of the template available - SpiraImportTemplate.xls for the Excel 2003 Add-In, SpiraImportTemplate.xlsx for the Excel 2007 Add-In and SpiraImportTemplate2010.xslx for the Excel 2010 Add-In.
Once you have downloaded the template, please double-click on it to open it up in MS-Excel. You will notice that there is an additional toolbar displayed in Excel which is used for importing/exporting data to/from SpiraTeam:
If you are using the MS-Excel 2007 or 2010 Add-In, you will see a modified version of the toolbar that makes use of the MS-Office Ribbon:
This toolbar allows you to connect to SpiraTeam, and perform the import/export. The process for using this toolbar is described below:
"},{"location":"Migration-and-Integration/Importing-from-Microsoft-Excel/#connecting-to-spirateam","title":"Connecting to SpiraTeam\u00ae","text":"The first thing you need to do is to click on the [Connect] button to specify the information used to connect to your instance of SpiraTeam:
Please enter the following information into the dialog box:
Spira URL: Please enter the web address that you use to access SpiraTeam\u00ae in your browser. This is usually of the form http://<hostname>/SpiraTeam. Make sure that you remove any suffixes from the address (e.g. Default.aspx).
User Name: Please enter the username that you use for logging in to SpiraTeam
Password: Please enter the password that you use for logging in to SpiraTeam
Remember Password: If you are using this Add-In on a private computer, you can check this option to have the system remember your credentials locally. Please do not use this option on a public computer and it will compromise the security of your SpiraTeam installation.
Once you have entered the necessary information, please click [Connect] to authenticate with the server. If the login information is invalid, you will see an error message appear, otherwise you will be connected and the list of projects and artifacts will be populated. If you want to end your session, you should just click the [Disconnect] button and the Add-In will close your connection.
"},{"location":"Migration-and-Integration/Importing-from-Microsoft-Excel/#choosing-the-project-and-artifact","title":"Choosing the Project and Artifact","text":"Once you have successfully connected to SpiraTeam, you should now choose the appropriate Project and Artifact in the system that you will be importing / exporting:
Or
The artifact choice will match the name of the Excel sheet in the template, so if you are going to be importing/exporting Requirements, you should choose \"Requirements\" from the dropdown list and then click on the \"Requirements\" tab inside the Excel import template.
Once you have selected the project and artifact, there are three buttons that you can now use:
Import: Clicking this button will retrieve the data from the SpiraTeam server and use that to populate the spreadsheet.
Export: Clicking this button will take the data in the spreadsheet and use it to add/update items in SpiraTeam.
Clear: This button allows you to quickly clear the data in the import template while leaving all the necessary headings and other information that the Add-In needs to be able to import/export data.
Options: (Only in MS-Excel 2007/2010 Add-Inx). This button allows you to change some of the import/export options.
The Excel Add-In is capable of either importing data from SpiraTeam into the Excel template or exporting data from the Excel template to SpiraTeam. However it is important to understand how the system knows whether to add new items to SpiraTeam or whether to update existing items:
If you start with a blank import spreadsheet and enter items into it, they will not have a value set on their ID column in the spreadsheet (this is always the first column in each sheet). When you perform an Export, it will add these as new items in SpiraTeam
If you start with a blank import spreadsheet and choose to Import data from SpiraTeam, those rows will include the ID of the item in the first column of the spreadsheet. You can either update those rows or add new rows in between. Any rows that have the ID column populated will be updated in SpiraTeam when you choose Export, whereas any newly added rows will be inserted in SpiraTeam.
To import/export releases, first you need to click on the \"Releases\" tab in the Excel sheet:
Next if you want to import the list of existing Releases from SpiraTeam, you should click on the [Clear] icon to first remove the sample information from the spreadsheet, then click [Import] to load the list of existing releases into the sheet. These items will all have the \"Rel #\" column populated so that the system knows to update them rather than insert them when you subsequently click [Export].
If you want to simply export a list of releases from a spreadsheet, then you need to either enter the releases into this specially formatted spreadsheet or cut and paste them in from another existing Excel sheet that you've been using to manage releases previously. Then click [Export] and the new items will be added to your instance of SpiraTeam.
The various columns that can be imported, and the rules for entering data are listed below:
Field name Description Rel # Stores the ID of the release. Should be left blank for new items being added to SpiraTeam Release Name The name of the release. This field supports indentation, so you need to use Excel's ability to Indent text fields to indicate how the items in the release hierarchy are organized Release Description The long description of the release. If you want it formatted, you need to add HTML tags such as <b> for bold Version Number The version number for the release; acts as the short name Active Whether this release is active or not. Should be set to either Y/N Iteration Whether this release is an Iteration or not. Should be set to either Y/N Creator The user that should listed as the release's creator. Needs to be the ID of the user (e.g. user US00005 would be entered as just 5) Start Date The date that work on the release is scheduled to start End Date The date that work on the release is scheduled to end # Resources The number of people / resources that are scheduled to work on the release. Non-Wk Days The number of non-working days that should be subtracted from the # available hours for work performed on the release. MS-Excel 2003/2007 Add-In Specific Fields TEXT-01 -- TEXT-10 The ten (10) custom text properties available in the project LIST-01 -- LIST-10 The ten (10) drop-down list properties available in the project. You need to enter the ID value of the custom property not the display name. E.g. if you have a custom property with ID - PV00005 you would enter just 5 in these boxes. MS-Excel 2010 Add-In Specific Fields Status The status of the release. It needs to be one of the values from the dropdown list Type The type of the release (major, minor, iteration or phase). It needs to be one of the values from the dropdown list CUS-01 -- CUS-30 The thirty (30) custom fields defined in the project. The value entered depends on the type of custom property: - List -- provide the numeric ID of the custom list value (e.g. PV00005 would be entered as just \"5\") - MultiList -- provide a comma-separated list of the numeric IDs of the custom list values (e.g. PV00005 and PV00003 would be entered as just \"5,3\") - Text -- enter the text, include HTML tags if rich-text - Decimal -- enter the number (e.g. 1.0) - Integer -- enter the number (e.g. 2) - Date -- enter the number in the current local time format (e.g. m/d/yyyy for the US, d/m/yyyy for Europe) - User -- enter the ID of the user - Boolean -- Enter either \"True\" or \"False\" Comment The description of a comment that should be appended to the item. If you want it formatted, you need to add HTML tags such as <b> for bold. Note that this field always appends, so if you want to add two comments, just enter the first value and click [Export], then replace it with the second value and click [Export]Note: the columns that are required are listed in bold type.
"},{"location":"Migration-and-Integration/Importing-from-Microsoft-Excel/#importingexporting-requirements","title":"Importing/Exporting Requirements","text":"To import/export requirements, first you need to click on the \"Requirements\" tab in the Excel sheet:
Next if you want to import the list of existing Requirements from SpiraTeam, you should click on the [Clear] icon to first remove the sample information from the spreadsheet, then click [Import] to load the list of existing requirements into the sheet. These items will all have the \"Req #\" column populated so that the system knows to update them rather than insert them when you subsequently click [Export].
If you want to simply export a list of requirements from a spreadsheet, then you need to either enter the requirements into this specially formatted spreadsheet or cut and paste them in from another existing Excel sheet that you've been using to manage requirements previously. Then click [Export] and the new items will be added to your instance of SpiraTeam.
The various columns that can be imported, and the rules for entering data are listed below:
Field name Description Req # Stores the ID of the requirement. Should be left blank for new items being added to SpiraTeam Requirement Name The name of the requirement. This field supports indentation, so you need to use Excel's ability to Indent text fields to indicate how the items in the requirement hierarchy are organized Requirement Description The long description of the requirement. If you want it formatted, you need to add HTML tags such as <b> for bold Importance The importance / priority of the requirement. It needs to be one of the values from the dropdown list. Status The status of the requirement. It needs to be one of the values from the dropdown list. If this is not specified, the requirement will default to the \"Requested\" status. Author The user that should listed as the requirement's author. Needs to be the ID of the user (e.g. user US00005 would be entered as just 5) Owner The user that should listed as the requirement's owner. Needs to be the ID of the user (e.g. user US00005 would be entered as just 5) MS-Excel 2003/2007 Add-In Specific Fields Release # The release that this requirement is scheduled for. Needs to be the ID of the release (e.g. release RL00005 would be entered as just 5) TEXT-01 -- TEXT-10 The ten (10) custom text properties available in the project LIST-01 -- LIST-10 The ten (10) drop-down list properties available in the project. You need to enter the ID value of the custom property not the display name. E.g. if you have a custom property with ID - PV00005 you would enter just 5 in these boxes. MS-Excel 2010 Add-In Specific Fields Release Version The release/iteration that this requirement is scheduled for. Needs to be the version number of the release (e.g. 1.0.1.1) Type The type of the requirement. It needs to be one of the values from the dropdown list. Estimate The estimate (in points) of the requirement. It should be a decimal number with one decimal place (e.g. 1.0, 2.5, etc.) Component This should be the Name of the Component the requirement is assigned-to. E.g. \"Component 1\" Linked Requirements Comma-separated list of requirement IDs (without the RQ prefix) that this requirement should be linked to (e.g. 204, 891) Note: This field only Exports to Spira and not the other way around CUS-01 -- CUS-30 The thirty (30) custom fields defined in the project. The value entered depends on the type of custom property: - List -- provide the numeric ID of the custom list value (e.g. PV00005 would be entered as just \"5\") - MultiList -- provide a comma-separated list of the numeric IDs of the custom list values (e.g. PV00005 and PV00003 would be entered as just \"5,3\") - Text -- enter the text, include HTML tags if rich-text - Decimal -- enter the number (e.g. 1.0) - Integer -- enter the number (e.g. 2) - Date -- enter the number in the current local time format (e.g. m/d/yyyy for the US, d/m/yyyy for Europe) - User -- enter the ID of the user - Boolean -- Enter either \"True\" or \"False\" Comment The description of a comment that should be appended to the item. If you want it formatted, you need to add HTML tags such as <b> for bold. Note that this field always appends, so if you want to add two comments, just enter the first value and click [Export], then replace it with the second value and click [Export]Note: the columns that are required are listed in bold type.
"},{"location":"Migration-and-Integration/Importing-from-Microsoft-Excel/#importingexporting-test-sets","title":"Importing/Exporting Test Sets","text":"To import/export test sets, first you need to click on the \"Test Sets\" tab in the Excel sheet:
Next if you want to import the list of existing Test Sets from SpiraTeam, you should click on the [Clear] icon to first remove the sample information from the spreadsheet, then click [Import] to load the list of existing test sets into the sheet. These items will all have the \"TX #\" column populated so that the system knows to update them rather than insert them when you subsequently click [Export].
If you want to simply export a list of test sets from a spreadsheet, then you need to either enter the test sets into this specially formatted spreadsheet or cut and paste them in from another existing Excel sheet that you've been using to manage test sets previously. Then click [Export] and the new items will be added to your instance of SpiraTeam.
The various columns that can be imported, and the rules for entering data are listed below:
Field name Description TX # Stores the ID of the test set. Should be left blank for new items being added to SpiraTeam Test Set Name The name of the test set. This field supports indentation, so you need to use Excel's ability to Indent text fields to indicate how the items in the test set hierarchy are organized Test Set Description The long description of the test set. If you want it formatted, you need to add HTML tags such as <b> for bold Folder Whether this item is a folder or not. Should be set to either Y/N Status The status of the test set. It needs to be one of the values from the dropdown list. Creator The user that should listed as the test set's creator. Needs to be the ID of the user (e.g. user US00005 would be entered as just 5) Owner The user that should listed as the test set's owner. Needs to be the ID of the user (e.g. user US00005 would be entered as just 5) Planned Date The date that the test set needs to be completed by. MS-Excel 2003/2007 Add-In Specific Fields Release # The release that this test set is scheduled for. Needs to be the ID of the release (e.g. release RL00005 would be entered as just 5) TEXT-01 -- TEXT-10 The ten (10) custom text properties available in the project LIST-01 -- LIST-10 The ten (10) drop-down list properties available in the project. You need to enter the ID value of the custom property not the display name. E.g. if you have a custom property with ID - PV00005 you would enter just 5 in these boxes. MS-Excel 2010 Add-In Specific Fields Release Version The release/iteration that this test set is scheduled for. Needs to be the version number of the release (e.g. 1.0.1.1) CUS-01 -- CUS-30 The thirty (30) custom fields defined in the project. The value entered depends on the type of custom property: - List -- provide the numeric ID of the custom list value (e.g. PV00005 would be entered as just \"5\") - MultiList -- provide a comma-separated list of the numeric IDs of the custom list values (e.g. PV00005 and PV00003 would be entered as just \"5,3\") - Text -- enter the text, include HTML tags if rich-text - Decimal -- enter the number (e.g. 1.0) - Integer -- enter the number (e.g. 2) - Date -- enter the number in the current local time format (e.g. m/d/yyyy for the US, d/m/yyyy for Europe) - User -- enter the ID of the user - Boolean -- Enter either \"True\" or \"False\" Comment The description of a comment that should be appended to the item. If you want it formatted, you need to add HTML tags such as <b> for bold. Note that this field always appends, so if you want to add two comments, just enter the first value and click [Export], then replace it with the second value and click [Export]Note: the columns that are required are listed in bold type.
"},{"location":"Migration-and-Integration/Importing-from-Microsoft-Excel/#importingexporting-test-cases","title":"Importing/Exporting Test Cases","text":"To import/export test cases, first you need to click on the \"Test Cases\" tab in the Excel sheet:
Next if you want to import the list of existing Test Cases from SpiraTeam, you should click on the [Clear] icon to first remove the sample information from the spreadsheet, then click [Import] to load the list of existing test cases into the sheet. These items will all have the \"Test #\" and \"Step #\" columns populated so that the system knows to update them rather than insert them when you subsequently click [Export].
If you want to simply export a list of test cases from a spreadsheet, then you need to either enter the test cases (including any test steps) into this specially formatted spreadsheet or cut and paste them in from another existing Excel sheet that you've been using to manage test cases previously. Then click [Export] and the new items will be added to your instance of SpiraTeam.
The various columns that can be imported, and the rules for entering data are listed below:
Field name Description Test # Stores the ID of the test case. Should be left blank for new items being added to SpiraTeam Test Case Name The name of the test case. This field supports indentation, so you need to use Excel's ability to Indent text fields to indicate how the items in the test case hierarchy are organized Test Case Description The long description of the test case. If you want it formatted, you need to add HTML tags such as <b> for bold Priority The priority of the test case. It needs to be one of the values from the dropdown list. Owner The user that should listed as the test case's owner. Needs to be the ID of the user (e.g. user US00005 would be entered as just 5) Row Type This is used to tell the Add-In what type of row this is. You should enter \"FOLDER\" if this row is a test folder, \"TestCase\" if it is a test case and \">TestStep\" if it is a test step belonging to a test case. These values should be selected from the dropdown list. Note: You should make sure that test step rows are located directly underneath the test case they are a part of. Step # Stores the ID of the test step. Should be left blank for new test steps being added to a test case Test Step Description The description of the test step. This should contain the description of the actions that the tester needs to take. If you want it formatted, you need to add HTML tags such as <b> for bold Expected Result The expected result of the test step. This should contain the description of what the tester should see if the step succeeds. If you want it formatted, you need to add HTML tags such as <b> for bold Sample Data The sample date for the test step. This should contain any sample data that the tester can use when testing the step. If you want it formatted, you need to add HTML tags such as <b> for bold MS-Excel 2003/2007 Add-In Specific Fields** Requirement The requirement that this test case should be mapped to. Needs to be the ID of the requirement (e.g. requirement RQ00005 would be entered as just 5). *Note that this field always appends, so if you want to add a test case to two requirements, run the export twice, once for each requirement. *Note: This field only Exports to Spira and not the other way around Release The release that this test case should be mapped to. Needs to be the ID of the release (e.g. release RL00005 would be entered as just 5). *Note that this field always appends, so if you want to add a test case to two releases, run the export twice, once for each release. *Note: This field only Exports to Spira and not the other way around Test Set The test set that this test case should be added to. Needs to be the ID of the test set (e.g. test set TX00005 would be entered as just 5). *Note that this field always appends, so if you want to add a test case to two test sets, run the export twice, once for each test set. *Note: This field only Exports to Spira and not the other way around TEXT-01 -- TEXT-10 The ten (10) custom text properties available in the project LIST-01 -- LIST-10 The ten (10) drop-down list properties available in the project. You need to enter the ID value of the custom property not the display name. E.g. if you have a custom property with ID - PV00005 you would enter just 5 in these boxes. MS-Excel 2010 Add-In Specific Fields Type The type of the test case. It needs to be one of the values from the dropdown list. Status The status of the test case. It needs to be one of the values from the dropdown list. Requirement The requirement(s) that this test case should be mapped to. Needs to be a comma-separated list of requirement IDs (e.g. requirements RQ00005 and RQ00008 would be entered as just \"5,8\"). Note: This field only Exports to Spira and not the other way around Release The release(s) that this test case should be mapped to. Needs to be a comma-separated list of release version numbers (e.g. releases 1.1.0.0 and 1.2.0.0 would be entered as \"1.1.0.0,1.2.0.0\"). Note: This field only Exports to Spira and not the other way around Test Set The test set(s) that this test case should be added to. Needs to be a comma-separated list of test set IDs (e.g. test sets TX00005 and TX00008 would be entered as just \"5,8\"). Note: This field only Exports to Spira and not the other way around Components This should be a comma-separated list of the Name of the Components the test case is assigned-to. E.g. Component 1, Component 2 CUS-01 -- CUS-30 The thirty (30) custom fields defined in the project. The value entered depends on the type of custom property: - List -- provide the numeric ID of the custom list value (e.g. PV00005 would be entered as just \"5\") - MultiList -- provide a comma-separated list of the numeric IDs of the custom list values (e.g. PV00005 and PV00003 would be entered as just \"5,3\") - Text -- enter the text, include HTML tags if rich-text - Decimal -- enter the number (e.g. 1.0) - Integer -- enter the number (e.g. 2) - Date -- enter the number in the current local time format (e.g. m/d/yyyy for the US, d/m/yyyy for Europe) - User -- enter the ID of the user - Boolean -- Enter either \"True\" or \"False\"Note: the columns that are required are listed in bold type.
"},{"location":"Migration-and-Integration/Importing-from-Microsoft-Excel/#importingexporting-incidents","title":"Importing/Exporting Incidents","text":"To import/export incidents, first you need to click on the \"Incidents\" tab in the Excel sheet:
Next if you want to import the list of existing Incidents from SpiraTeam, you should click on the [Clear] icon to first remove the sample information from the spreadsheet, then click [Import] to load the list of existing incidents into the sheet. These items will all have the \"Inc #\" column populated so that the system knows to update them rather than insert them when you subsequently click [Export].
If you want to simply export a list of incidents from a spreadsheet, then you need to either enter the incidents into this specially formatted spreadsheet or cut and paste them in from another existing Excel sheet that you've been using to manage incidents previously. Then click [Export] and the new items will be added to your instance of SpiraTeam.
The various columns that can be imported/exported, and the rules for entering data are listed below:
Field name Description Inc # Stores the ID of the incident. Should be left blank for new items being added to SpiraTeam Incident Name The name of the incident. Incident Description The long description of the incident. If you want it formatted, you need to add HTML tags such as <b> for bold Type The type of the incident. It needs to be one of the values from the dropdown list. Status The status of the incident. It needs to be one of the values from the dropdown list. Priority The priority of the incident. It needs to be one of the values from the dropdown list. Severity The severity of the incident. It needs to be one of the values from the dropdown list. Detector The user that found the incident. Needs to be the ID of the user (e.g. user US00005 would be entered as just 5). If left blank, it will default to the user logged in through the Add-In. Owner The user that the incident should be assigned to Needs to be the ID of the user (e.g. user US00005 would be entered as just 5) Detected Date The date that the incident was found. If this field is not populated, the current date is used instead Closed Date The date that the incident was closed. Do not enter a value in this field if the incident is not in a closed status. MS-Excel 2003 Add-In Specific Fields % Complete The completion percentage of the incident Detected Release The release that this incident was found in. Needs to be the ID of the release (e.g. release RL00005 would be entered as just 5) Resolved Release The release that this incident is scheduled to be fixed in. Needs to be the ID of the release (e.g. release RL00005 would be entered as just 5) TEXT-01 -- TEXT-10 The ten (10) custom text properties available in the project LIST-01 -- LIST-10 The ten (10) drop-down list properties available in the project. You need to enter the ID value of the custom property not the display name. E.g. if you have a custom property with ID - PV00005 you would enter just 5 in these boxes. Resolution The description of a resolution/comment that should be appended to the incident. If you want it formatted, you need to add HTML tags such as <b> for bold. Note that this field always appends, so if you want to add two comments, just enter the first value and click [Export], then replace it with the second value and click [Export] MS-Excel 2007 Add-In Specific Fields Detected Release The release that this incident was found in. Needs to be the ID of the release (e.g. release RL00005 would be entered as just 5) Resolved Release The release that this incident is scheduled to be fixed in. Needs to be the ID of the release (e.g. release RL00005 would be entered as just 5) Est. Effort The estimated effort associated with the task (entered as a whole number of minutes) Act. Effort The actual effort associated with number of minutes) Rem. Effort The remaining effort associated with the task (entered as a whole number of minutes) TEXT-01 -- TEXT-10 The ten (10) custom text properties available in the project LIST-01 -- LIST-10 The ten (10) drop-down list properties available in the project. You need to enter the ID value of the custom property not the display name. E.g. if you have a custom property with ID - PV00005 you would enter just 5 in these boxes. Resolution The description of a resolution/comment that should be appended to the incident. If you want it formatted, you need to add HTML tags such as <b> for bold. Note that this field always appends, so if you want to add two comments, just enter the first value and click [Export], then replace it with the second value and click [Export] MS-Excel 2010 Add-In Specific Fields Detected Release The release/iteration that this incident was found in. Needs to be the version number of the release (e.g. 1.0.1.1) Resolved Release The release/iteration that this is planned to be fixed in. Needs to be the version number of the release (e.g. 1.0.1.1) Components This should be a comma-separated list of the Name of the Components the incident is assigned-to. E.g. Component 1, Component 2 Est. Effort The estimated effort associated with the task (entered as a whole number of minutes) Act. Effort The actual effort associated with the task (entered as a whole number of minutes) Rem. Effort The remaining effort associated with the task (entered as a whole number of minutes) CUS-01 -- CUS-30 The thirty (30) custom fields defined in the project. The value entered depends on the type of custom property: - List -- provide the numeric ID of the custom list value (e.g. PV00005 would be entered as just \"5\") - MultiList -- provide a comma-separated list of the numeric IDs of the custom list values (e.g. PV00005 and PV00003 would be entered as just \"5,3\") - Text -- enter the text, include HTML tags if rich-text - Decimal -- enter the number (e.g. 1.0) - Integer -- enter the number (e.g. 2) - Date -- enter the number in the current local time format (e.g. m/d/yyyy for the US, d/m/yyyy for Europe) - User -- enter the ID of the user - Boolean -- Enter either \"True\" or \"False\" Comment The description of a comment that should be appended to the incident. If you want it formatted, you need to add HTML tags such as <b> for bold. Note that this field always appends, so if you want to add two comments, just enter the first value and click [Export], then replace it with the second value and click [Export]Note: the columns that are required are listed in bold type.
"},{"location":"Migration-and-Integration/Importing-from-Microsoft-Excel/#importingexporting-tasks","title":"Importing/Exporting Tasks","text":"To import/export tasks, first you need to click on the \"Tasks\" tab in the Excel sheet:
Next if you want to import the list of existing Tasks from SpiraTeam, you should click on the [Clear] icon to first remove the sample information from the spreadsheet, then click [Import] to load the list of existing tasks into the sheet. These items will all have the \"Inc #\" column populated so that the system knows to update them rather than insert them when you subsequently click [Export].
If you want to simply export a list of tasks from a spreadsheet, then you need to either enter the tasks into this specially formatted spreadsheet or cut and paste them in from another existing Excel sheet that you've been using to manage tasks previously. Then click [Export] and the new items will be added to your instance of SpiraTeam.
The various columns that can be imported, and the rules for entering data are listed below:
Field name Description Task # Stores the ID of the task. Should be left blank for new items being added to SpiraTeam Task Name The name of the task. Task Description The long description of the task. If you want it formatted, you need to add HTML tags such as <b> for bold Status The status of the task. It needs to be one of the values from the dropdown list. Priority The priority of the task. It needs to be one of the values from the dropdown list. Requirement The requirement that this task should be associated with. Needs to be the ID of the requirement (e.g. requirement RQ00005 would be entered as just 5). Owner The user that the task should be assigned to Needs to be the ID of the user (e.g. user US00005 would be entered as just 5) Start Date The date that work on the task is scheduled to start End Date The date that work on the task is scheduled to end Est. Effort The estimated effort associated with the task (entered as a whole number of minutes) Act. Effort The actual effort associated with the task (entered as a whole number of minutes) MS-Excel 2003 Add-In Specific Fields % Complete The completion percentage of the task Release # The release/iteration that this task is scheduled for. Needs to be the ID of the release/iteration (e.g. release RL00005 would be entered as just 5). TEXT-01 -- TEXT-10 The ten (10) custom text properties available in the project LIST-01 -- LIST-10 The ten (10) drop-down list properties available in the project. You need to enter the ID value of the custom property not the display name. E.g. if you have a custom property with ID - PV00005 you would enter just 5 in these boxes. **MS-Excel 2007 Add-In Specific Fields** Rem. Effort The remaining effort associated with the task (entered as a whole number of minutes) Release # The release/iteration that this task is scheduled for. Needs to be the ID of the release/iteration (e.g. release RL00005 would be entered as just 5). TEXT-01 -- TEXT-10 The ten (10) custom text properties available in the project LIST-01 -- LIST-10 The ten (10) drop-down list properties available in the project. You need to enter the ID value of the custom property not the display name. E.g. if you have a custom property with ID - PV00005 you would enter just 5 in these boxes. MS-Excel 2010 Add-In Specific Fields Type The type of the task. It needs to be one of the values from the dropdown list. Rem. Effort The remaining effort associated with the task (entered as a whole number of minutes) Release Version The release/iteration that this task is scheduled for. Needs to be the version number of the release (e.g. 1.0.1.1) CUS-01 -- CUS-30 The thirty (30) custom fields defined in the project. The value entered depends on the type of custom property: - List -- provide the numeric ID of the custom list value (e.g. PV00005 would be entered as just \"5\") - MultiList -- provide a comma-separated list of the numeric IDs of the custom list values (e.g. PV00005 and PV00003 would be entered as just \"5,3\") - Text -- enter the text, include HTML tags if rich-text - Decimal -- enter the number (e.g. 1.0) - Integer -- enter the number (e.g. 2) - Date -- enter the number in the current local time format (e.g. m/d/yyyy for the US, d/m/yyyy for Europe) - User -- enter the ID of the user - Boolean -- Enter either \"True\" or \"False\" Comment The description of a comment that should be appended to the task. If you want it formatted, you need to add HTML tags such as <b> for bold. Note that this field always appends, so if you want to add two comments, just enter the first value and click [Export], then replace it with the second value and click [Export]Note: the columns that are required are listed in bold type.
"},{"location":"Migration-and-Integration/Importing-from-Microsoft-Excel/#execute-test-cases-offline","title":"Execute Test Cases Offline","text":"As well as being able to import/export data, you can also use the import spreadsheet to execute test cases while disconnected from your network and then upload the results to SpiraTeam as a single batch.
To do this, when connected to the network, connect to the server using the Add-In [Connect] icon, select the project and \"Test Runs\", then click on the \"Test Runs\" in the spreadsheet:
Now you should click on the [Import] button, and the Add-In will load the list of Test Cases (and in the case of the MS-Office 2007/2010 Add-Ins, any Test Sets as well) that are currently assigned to you together with open cells (marked in green) that you can use to record the actual results of testing:
You can now disconnect from the network and perform the testing activities offline. Enter the following entries into the spreadsheet:
Status The execution status of that test step. It should be selected drop the dropdown list. The allowed values are: Failed / Passed / Blocked / Caution. Actual Result The long description of the actual result experienced during testing. If you want it formatted, you need to add HTML tags such as <b> for bold Incident Name If you want to log an incident associated with the test failure, enter the name of the incident here. The description of the incident will be pre-populated with the Test Step Description, Expected Result, and Actual Result.
Once you have finished testing and are connected back on the network, just click on the [Connect] icon to have the Add-In connect with the SpiraTeam server, choose the project name and \"Test Runs\" and then click [Export]. The test results will now be uploaded to the server.
Note: If you are using the MS-Excel 2007/2010 Add-Ins, you will also see the Test Set ID, Release ID and TX TC ID (Test-Set, Test Case unique ID). You can manually set a Release ID on test cases that were not part of a test set.
"},{"location":"Migration-and-Integration/Importing-from-Microsoft-Excel/#importing-custom-property-list-values","title":"Importing Custom Property List Values","text":"To import/export custom property values (for list custom properties), first you need to click on the \"Custom Values\" tab in the Excel sheet:
Next if you want to import the list of existing custom list values from SpiraTeam, you should click on the [Clear] icon to first remove the sample information from the spreadsheet, then click [Import] to load the list of existing custom list values into the sheet. These items will all have the \"Value #\" column populated so that the system knows to update them rather than insert them when you subsequently click [Export].
If you want to export a list of custom list values from a spreadsheet you first need to make sure that a list exists in the right template in Spira. You can only edit a list that already exists in Spira. Then you need to either enter the custom list ID and value name into this specially formatted spreadsheet or cut and paste them in from another existing Excel sheet that you've been using to manage the values previously. Then click [Export] and the new items will be added to your instance of SpiraTeam. NOTE: These values are initially added as inactive on the list. You will need to log into Spira to make the list values required active.
The various columns that can be imported, and the rules for entering data are listed below:
Field name Description Value # Stores the ID of the custom list value. Should be left blank for new items being added to SpiraTeam Custom List # The ID of the custom list that the value is being added to (with the CL prefix removed). For example custom list CL00005 would be entered as just \"5\" Custom Value Name The name of the custom value that you are inserting/updating in SpiraTeam
Note: the columns that are required are listed in bold type.
"},{"location":"Migration-and-Integration/Importing-from-Microsoft-Excel/#changing-the-importexport-options","title":"Changing the Import/Export Options","text":"In the MS-Excel 2007 and 2010 Add-Ins, you can change how the import/export works by clicking on the Options icon. This brings up the Options dialog box:
"},{"location":"Migration-and-Integration/Importing-from-Microsoft-Excel/#rich-text-setting","title":"Rich Text Setting","text":"When you import artifacts from SpiraTeam into MS-Excel, if they have a formatted description, by default all the HTML tags that are used to describe the formatting will be loaded into the Excel cell. This is useful if you plan on making changes and then updating SpiraTeam (since it will preserve the formatting).
However if you want to be able to more easily read the descriptions in Excel and do not plan on updating SpiraTeam, you can select the option to Remove the Formatting, which will convert the descriptions to plain-text before loading them into Excel.
"},{"location":"Migration-and-Integration/Importing-from-Microsoft-Excel/#test-run-date-setting","title":"Test Run Date Setting","text":"If you set a date for the 'Test Run Date', the importer will use that date to be the date the test runs were executed on, rather than the current date/time, which is used by default.
"},{"location":"Migration-and-Integration/Importing-from-Microsoft-Excel/#functionality-differences-from-microsoft-excel-365-plugin","title":"Functionality Differences from Microsoft Excel 365 plugin","text":"Excel Classic can (and the Excel 365 plugin cannot):
Excel 365 can (and the classic plugin cannot):
NOTE Excel Classic can create test runs. This functionality is in the SpiraPlan TestRunner Excel 365 addin, and not the Excel 365 import/export addin.
For more information about how the Excel Classic plugin works with version 6+ of SpiraPlan see this blog post.
"},{"location":"Migration-and-Integration/Importing-from-Microsoft-Project/","title":"Importing from Microsoft Project","text":"The web-based interface of SpiraTeam\u00ae is ideal for creating and managing requirements, releases/iterations and tasks for a new project. However when migrating requirements and tasks from an existing project, it is useful to be able to load in an existing project plan in batch and have SpiraTeam be able to interpret the data.
To simplify this task, SpiraTeam\u00ae comes with a Microsoft Project Add-In that can export requirements, releases and tasks from a populated MS-Project plan into SpiraTeam\u00ae. In addition, the Add-In allows you to import those same artifacts back into the MS-Project plan to make batch updates which can then be used to update the master copies on the server.
Note that this guide refers to SpiraTeam\u00ae, but the MS-Project Add-In can be used with SpiraPlan\u00ae as well.
"},{"location":"Migration-and-Integration/Importing-from-Microsoft-Project/#installing-the-microsoft-project-add-in","title":"Installing the Microsoft Project Add-In","text":"The first thing you need to do is to go to the \"Add-Ons and Downloads\" page of the Inflectra Website (it can be found in the SpiraPlan or SpiraTeam sections), and download the MS-Office Add-Ins installation package. There are separate packages for the following versions of MS Office:
MS-Office 2003 Add-Ins -- these are compatible with Microsoft Office 2003 and 2007. They can connect to SpiraTeam v2.3 or later. They also require Microsoft .NET 3.5.
MS-Office 2007 Add-Ins -- these are compatible with Microsoft Office 2007 and 2010. They can connect to SpiraTeam v3.0 or later. They also require Microsoft .NET 4.0.
MS-Office 2010 Add-Ins -- these are compatible with Microsoft Office 2010 and all later versions. They can connect to SpiraTeam v5.0 or later. They also require Microsoft .NET 4.0.
This installation package will install the add-ins for Microsoft Excel, Word and Project at the same time. If you don't have the correct version of Microsoft .NET installed or some of the necessary prerequisites, you will be given the opportunity to install them when you first run the installation package.
Once you have the MS-Project Add-In installed, the second thing you may want to download is the SampleProjectFile.mpp MS-Project plan. This project file contains a fully-populated project plan and is a good sample to test the import/export before using a real project plan.
Once you have downloaded the project file, please double-click on it to open it up in MS-Project. You will notice that there is an additional toolbar displayed in MS-Project which is used for importing/exporting data to/from SpiraTeam:
If you are using the MS-Project 2010 Add-In, you will see a modified version of the toolbar that makes use of the MS-Office Ribbon:
This toolbar allows you to connect to SpiraTeam, and perform the import/export. The process for using this toolbar is described below:
"},{"location":"Migration-and-Integration/Importing-from-Microsoft-Project/#connecting-to-spirateam","title":"Connecting to SpiraTeam\u00ae","text":"The first thing you need to do is to click on the [Connect] button to specify the information used to connect to your instance of SpiraTeam:
Please enter the following information into the dialog box:
Spira URL: Please enter the web address that you use to access SpiraTeam\u00ae in your browser. This is usually of the form http://<hostname>/SpiraTeam. Make sure that you remove any suffixes from the address (e.g. Default.aspx).
User Name: Please enter the username that you use for logging in to SpiraTeam
Password: Please enter the password that you use for logging in to SpiraTeam
Remember Password: If you are using this Add-In on a private computer, you can check this option to have the system remember your credentials locally. Please do not use this option on a public computer and it will compromise the security of your SpiraTeam installation.
Once you have entered the necessary information, please click [Connect] to authenticate with the server. If the login information is invalid, you will see an error message appear, otherwise you will be connected and the list of projects and artifacts will be populated. If you want to end your session, you should just click the [Disconnect] button and the Add-In will close your connection.
"},{"location":"Migration-and-Integration/Importing-from-Microsoft-Project/#choosing-the-project","title":"Choosing the Project","text":"Once you have successfully connected to SpiraTeam, you should now choose the appropriate Project in the system that you will be importing / exporting to / from:
Or
Once you have selected the project, there are three buttons that you can now use:
Import: Clicking this button will retrieve the data from the SpiraTeam server and use that to populate the MS-Project file.
Export: Clicking this button will take the data in the currently opened MS-Project file and use it to add/update items in SpiraTeam.
Clear: This button allows you to quickly clear the data in the current Project file so that you can import a clean version from the server.
The MS-Project Add-In is capable of either importing data from SpiraTeam into the project file or exporting data from the project file to SpiraTeam. However it is important to understand how the system knows whether to add new items to SpiraTeam or whether to update existing items:
If you start with a blank MS-Project file and enter tasks into it, they will not have a value set on their Text1 custom field. When you perform an Export, it will add these as new items in SpiraTeam
If you start with a blank import MS-Project file and choose to Import data from SpiraTeam, those tasks imported will include the ID of the item in SpiraTeam as their Text1 custom field. You can either update those tasks or add new tasks in between. Any tasks that have the Text1 custom property populated will be updated in SpiraTeam when you choose Export, whereas any newly added tasks will be inserted in SpiraTeam.
The Add-In will import the tasks from SpiraTeam into the MS-Project file based on the following rules:
Any Releases/Iterations in SpiraTeam will be added as zero-effort (milestone) tasks in the MS-Project plan.
Any Requirements in SpiraTeam that have at least one task under them, will be added as summary tasks in the MS-Project plan. Their indentation in the project plan will match the requirements' indentation in SpiraTeam
Any Tasks in SpiraTeam will be added as tasks in the MS-Project plan. The tasks will be nested directly under their parent requirement's equivalent task in MS-Project.
Any Requirements in SpiraTeam that have no tasks under them, will be added as zero-effort (milestone) tasks in the MS-Project plan. Their indentation in the project plan will match the requirements' indentation in SpiraTeam
The Add-In will export the tasks in the MS-Project file into SpiraTeam based on the following rules:
Any summary tasks or top-level tasks in the MS-Project file will be treated as Requirements when being exported to SpiraTeam.
Any non-summary tasks that have zero-effort (milestones) that are not originally Releases/Iterations will be treated as Requirements when being exported to SpiraTeam.
Any non-summary tasks that are NOT at the top-level will be treated as Tasks when being exported to SpiraTeam. They will be attached to the requirement that is their parent task in MS-Project.
The export function does not update any of the Release/Iteration items. They need to be updated in SpiraTeam.
If you want to prevent an MS-Project Task from being imported into SpiraTeam simply set the value of its Text1 column to the text \"IGNORE\" (without the quotes).
Be careful when you indent/outdent a task in MS-Project. If you take a non-summary item (which would be represented by a Task in SpiraTeam) and make it a summary item by adding child tasks, when you next run Export, it will get added as a new Requirement in SpiraTeam, with the child tasks added as Tasks. The old task will still remain in SpiraTeam and will need to be manually removed.
"},{"location":"Migration-and-Integration/Importing-from-Microsoft-Word-%28Office365%29/","title":"Importing from Microsoft Word (Office 2019+, iOS, Web)","text":"This add-in lets you import a list of requirements or test cases (with folders and test steps) into any product in your SpiraTest, SpiraTeam, or SpiraPlan application. It lets you specify how your document is organized using its styles and headings so the data added to SpiraPlan will be hierarchically structured in the same way. It supports importing rich text, tables, lists, and images.
This add-in requires:
a support version of Microsoft Word
SpiraTest\u00ae, SpiraTeam\u00ae, or SpiraPlan\u00ae application (called SpiraPlan from here on) version 6.3.0.1+
To install the add-in:
The add-in works with modern Word (docx) documents. The add-in has a number of settings to work flexibly with your existing Word files so that they can be imported into SpiraPlan without any changes. Please note that some preparation of the document may be required in some circumstances if the styles configuration does not fully meet your needs.
"},{"location":"Migration-and-Integration/Importing-from-Microsoft-Word-%28Office365%29/#connect-to-spiraplan","title":"Connect to SpiraPlan","text":"You can use this add-in with SpiraTest\u00ae, SpiraTeam\u00ae, or SpiraPlan\u00ae. If you are using Word in the browser, make sure SpiraPlan is accessible over the internet.
When you first open the add-in you will see the connection screen. Fill in the details and click \"Log In\" to connect the add-in to your SpiraPlan.
If there is a problem connecting to Spira you will be notified with an error message.
After you have logged in click Log-out to close your connection with SpiraPlan and return to the add-in's login page.
"},{"location":"Migration-and-Integration/Importing-from-Microsoft-Word-%28Office365%29/#select-a-product","title":"Select a Product","text":"After logging in, first you need to choose the product to import into. The dropdown shows all products you are a member of.
Once you have selected a product, you need to select to either import Requirements or Test Cases. This selection can be changed at any time.
"},{"location":"Migration-and-Integration/Importing-from-Microsoft-Word-%28Office365%29/#configure-the-styles","title":"Configure the styles","text":"Select the styles used in the document which represent either the hierarchy of requirements, or the test case folder names, test case names, and table configuration for test steps. These styles must be selected to match those used in the current document. Your style selections are saved as metadata within the document itself, so next time you open the document, the styles will be pre-populated for you.
"},{"location":"Migration-and-Integration/Importing-from-Microsoft-Word-%28Office365%29/#requirements","title":"Requirements","text":"You can select up to 5 indent levels to represent the hierarchical relationship of your requirements in your document. This hierarchy will be replicated when importing into SpiraPlan. Choose the relevant styles that match each indent level. These styles are used as headings for your requirements and will become the requirement names in SpiraPlan
Your requirements document must only increase the indent level once per requirement (your document can't have an Indent Level 1 requirement immediately followed by an Indent Level 3 requirement). If the requirements to import do not meet this condition, the add-in will display a relevant error.
"},{"location":"Migration-and-Integration/Importing-from-Microsoft-Word-%28Office365%29/#test-cases","title":"Test Cases","text":"It is common to organize test cases into groups or headings in your document. The add-in support 1 level of groupings and these will get converted into root level test case folders in SpiraPlan. Test case folder descriptions (text immediately below the folder heading in Word) will also be added to SpiraPlan
Select the style that matches your heading used to organize test cases into folders. Then select the style that matches the heading used for your test case names. Any test cases after that heading will be added into that folder. If there is already a folder with that name in SpiraPlan at the root level (case sensitive), relevant test cases will be added to that existing test case folder (in other words, a duplicate test case folder will not be created).
Test cases and their descriptions will be imported into SpiraPlan. Test step information will also be imported if present.
Test steps need to be in a table inside the relevant test case with rows for each test step. If the test case description has more than one table in it, the last table is assumed to be the one that contains the test steps. The other tables will not be imported into SpiraPlan at all.
The add-in supports tables with or without header rows. Use the \"Using header rows\" option to toggle between removing the first row (because it has table headers) or sending the first row as a test step. Select which columns match with each test step field.
Test step table rows with an empty description will get a default description added, and empty rows are ignored. If the table cannot be properly parsed to import into SpiraPlan an error will be shown. This can happen, for example, if a table does not have a description column at all, or the description column is completely blank, or the whole table is empty.
"},{"location":"Migration-and-Integration/Importing-from-Microsoft-Word-%28Office365%29/#validate-styles","title":"Validate Styles","text":"Once the configuration / selection of the styles is complete, click the \"Validate Styles\" button. This will check the document against your selections to make sure that there are no obvious problems. If there are you will see a popup with an explanation.
Once the validation is complete you will be able to start the import process.
"},{"location":"Migration-and-Integration/Importing-from-Microsoft-Word-%28Office365%29/#importing-into-spiraplan","title":"Importing into SpiraPlan","text":"By default, the add-in imports your entire document into SpiraPlan, based on your setup as described above.
If you want, you can also choose exactly what to import by selecting just part of the document (discussed more below).
Once you have decided what to import, click the \"Send to Spira\" button. During the import process you will see a popup showing its progress. Note that closing this pop-up will not stop the import process - to do that you will need to press the cancel button, or close or refresh the add-in (note that this will not un-do any already sent artifacts).
Selecting part of a document
To send only part of a document:
Make sure no lists within the selection contain styles which are set to any style selector - for instance if Heading 1 is your indent level 1 selection, lists may not contain any Heading 1 text - parsing will throw an error or even crash the add-in depending on the specific instance.
"},{"location":"Migration-and-Integration/Importing-from-Microsoft-Word-%28Office365%29/#troubleshooting","title":"Troubleshooting","text":"Documents are often, rich, complex, very long, and have been used for a number of years. Sometimes this means the add-in may struggle to correctly import all relevant artifacts. This can be for a variety of reasons:
How to work with legacy Word documents
Older Word documents (Created or edited in a version of Word 2016 or earlier) may not get imported correctly
Older versions of Word saved documents in a slightly different format than newer versions. Microsoft add-ins are not able to fully see all parts of these older document formats. Unfortunately, it is hard to know whether your document is in the newer or older format.
Practically, this means that when working with these older Word documents, the add-in:
Currently, the only automatic workaround we can recommend that fixes both of the above issues, is to:
There is no way, within Word itself, to update a document to the latest version automatically. If you are not able to use the above method, you may need to manually update all images and lists in your document:
images: there are two options here
Quicker for lots of images but complex. By default, Word will paste images with the setting \"Keep source formatting\", but this is not what we want, so we have to tell Word to not do this.
What can the Word365 add-in do that the Classic Word add-in cannot?
What can the Classic Word add-in do that the Word365 add-in cannot?
The web-based interface of SpiraTeam\u00ae is ideal for creating and managing requirements, test cases and incidents for a new project. However often an organization will often have existing requirements documentation and test case templates in Microsoft Word format that need to get easily migrated into SpiraTeam.
To simplify this task, SpiraTeam\u00ae comes with a Microsoft Word Add-In that can export requirements and test cases from a populated Word document into SpiraTeam\u00ae. Note that this guide refers to SpiraTeam\u00ae, but the Word Add-In can be used with SpiraTest\u00ae and SpiraPlan\u00ae as well. The only difference is that the Test Case import functionality will not be applicable for SpiraPlan\u00ae users.
"},{"location":"Migration-and-Integration/Importing-from-Microsoft-Word/#installing-the-microsoft-word-add-in","title":"Installing the Microsoft Word Add-In","text":"The first thing you need to do is to go to the \"Add-Ons and Downloads\" page of the Inflectra Website (it can be found in the SpiraTest, SpiraPlan or SpiraTeam sections), and download the MS-Office Add-Ins installation package. There are separate packages for the following versions of MS Office:
MS-Office 2003 Add-Ins -- these are compatible with Microsoft Office 2003 and 2007. They can connect to SpiraTeam v2.3 or later. They also require Microsoft .NET 3.5.
MS-Office 2007 Add-Ins -- these are compatible with Microsoft Office 2007 and 2010. They can connect to SpiraTeam v3.0 or later. They also require Microsoft .NET 4.0.
MS-Office 2010 Add-Ins -- these are compatible with Microsoft Office 2010 and later. They can connect to SpiraTeam v5.0 or later. They also require Microsoft .NET 4.0.
This installation package will install the add-ins for Microsoft Excel, Word and Project at the same time. If you don't have the correct version of Microsoft .NET installed or some of the necessary prerequisites, you will be given the opportunity to install them when you first run the installation package.
Once you have the Word Add-In installed, the second thing you'll need to download is the SampleWordDocument document. This sample document contains some example requirements and test cases that be exported into SpiraTeam. Also the documents make good templates if you're looking for a way to standardize the import of requirements and test cases. There are two versions of the document available - SampleWordDocument.doc for Word 2003 and SampleWordDocument.docx for Word 2007 and later.
Once you have downloaded the template, please double-click on it to open it up in MS-Word. You will notice that there is an additional toolbar displayed in Word which is used for exporting requirements and test cases to SpiraTeam:
If you are using the MS-Word 2007 or 2010 Add-In, you will see a modified version of the toolbar that makes use of the MS-Office Ribbon:
This toolbar allows you to connect to SpiraTeam, and perform the export. The process for using this toolbar is described below:
"},{"location":"Migration-and-Integration/Importing-from-Microsoft-Word/#connecting-to-spirateam","title":"Connecting to SpiraTeam\u00ae","text":"The first thing you need to do is to click on the [Connect] button to specify the information used to connect to your instance of SpiraTeam:
Please enter the following information into the dialog box:
Spira URL: Please enter the web address that you use to access SpiraTeam\u00ae in your browser. This is usually of the form http://<hostname>/SpiraTeam. Make sure that you remove any suffixes from the address (e.g. Default.aspx).
User Name: Please enter the username that you use for logging in to SpiraTeam
Password: Please enter the password that you use for logging in to SpiraTeam
Remember Password: If you are using this Add-In on a private computer, you can check this option to have the system remember your credentials locally. Please do not use this option on a public computer and it will compromise the security of your SpiraTeam installation.
Once you have entered the necessary information, please click [Connect] to authenticate with the server. If the login information is invalid, you will see an error message appear, otherwise you will be connected and the list of projects and artifacts will be populated. If you want to end your session, you should just click the [Disconnect] button and the Add-In will close your connection.
"},{"location":"Migration-and-Integration/Importing-from-Microsoft-Word/#choosing-the-project-and-artifact","title":"Choosing the Project and Artifact","text":"Once you have successfully connected to SpiraTeam, you should now choose the appropriate Project and Artifact in the system that you will be importing / exporting:
Or
Once you have selected the project and artifact, there are two buttons that you can now use:
Export: Clicking this button will take the currently selected data in the document and use it to add new items in SpiraTeam.
Style Mappings: This button allows you to change the parameters used by the Add-In when scanning the Word document to know where each requirement, test case and test step beings and ends.
The parameters selection varies by the type of information being exported, and will be discussed in the relevant artifact section below:
"},{"location":"Migration-and-Integration/Importing-from-Microsoft-Word/#exporting-requirements-into-spirateam","title":"Exporting Requirements into SpiraTeam","text":"To export requirements, first you need to open up the MS-Word document that contains the requirements to be exported. Then you need to click on the \"Style Mappings\" icon to display the style mapping configuration dialog box:
This dialog box allows you to tell the Add-In which styles are being used in the document to describe each level of Requirements in the hierarchy. When you run the Export, the Add-In will examine each paragraph in the document, and any item that matches one of these styles will be considered the start of a new requirement, and its indentation level will be based on the appropriate style.
Once you have verified that the styles match those used in your document, highlight the areas of the document that you wish to import and click the [Import] button. Once you have done this, the Add-In will scan the selected portions of the document and export the requirements into the system. During the export, the Add-In uses the following rules for dealing with the content:
The text that matches the selected style will be loaded as the Name field of the requirement
Any text located between the selected styles will be loaded into the Description field of the requirement. The Add-In will attempt to match the formatted used in the Word document. However because of some differences between MS-Word and HTML, it may not be exact.
Any embedded images will be added to the requirement as a file Attachment, with an embedded image tag added to Description field
To export test cases (and their test steps), first you need to open up the MS-Word document that contains the test cases to be exported. Then you need to click on the \"Style Mappings\" icon to display the style mapping configuration dialog box:
This dialog box allows you to tell the Add-In which styles are being used in the document to denote the name of the Test Folder and the name of the Test Case. For the test steps, the Add-In currently requires that they be organized in tables, with each column in the table being used consistently to describe one of the three Test Step fields. For the import to work correct, your tables need to have at least three (3) columns so that it can map them correctly. You can use the same column multiple times (e.g. the contents of column 2 would be imported into both the expected result and sample data).
Once you have verified that the styles and table columns match those used in your document, highlight the areas of the document that you wish to import and click the [Import] button. Once you have done this, the Add-In will scan the selected portions of the document and export the test cases and test steps into the system. During the export, the Add-In uses the following rules for dealing with the content:
The text that matches the selected style will be loaded as the Name field of the Test Folder or Test Case
Any text located between the selected styles will be loaded into the Description field of the Test Case. The Add-In will attempt to match the formatted used in the Word document. However because of some differences between MS-Word and HTML, it may not be exact.
Any embedded images will be added to the Test Case as a file Attachment, with an embedded image tag added to Description field
Any tables located between the selected styles will be treated as the Test Steps belonging to the previous test case. The fields for the Test Steps will be populated based on the index of the column.
Any text located in the table cells into the appropriate field of the Test Step. The Add-In will attempt to match the formatted used in the Word document. However because of some differences between MS-Word and HTML, it may not be exact.
The first row of the table is assumed to be a header row, so if you are seeing the first step of your document being omitted, it means that you need to add a header rows.
If there is an error during the import of either requirements or test cases, the error message will be stored in a text file called Spira_WordImport.log that can be found on the desktop of the user running the import:
"},{"location":"Migration-and-Integration/Importing-from-Microsoft-Word/#functionality-differences-to-the-microsoft-word365-plugin","title":"Functionality Differences to the Microsoft Word365 plugin","text":"What can the Word365 add-in do that the Classic Word add-in cannot?
What can the Classic Word add-in do that the Word365 add-in cannot?
This page outlines how to use the HP ALM Migration Tool to import projects from HP ALM (formerly known as HP Quality Center) into Spira.
What can be imported from HP ALM?
The migration tool will import the following artifacts:
To get started, you will need to install the migration tool onto a workstation that can access both your HP ALM server, and your Spira application.
You must already have a working installation of Spira v4.0 or later and a working version of HP ALM 11.5 or later. If you are using HP QualityCenter 10.0 or older, please refer to the migration tool and documentation here.
The Windows installation package can be downloaded from the \"Add-Ons & Downloads\" section of the Inflectra website. Once you have obtained the Windows Installer package, simply double-click on the package to begin the installation wizard which should display the following welcome page:
Click the <Next> button, accept the software license, then click <Next> again to choose the folder to install the migration tool to:
Choose the folder to install to, and then decide whether the application should be accessible by all users on the workstation or just the current user. Then click the <Install> button to start the installation process. It will confirm if you want to proceed, click <Next> then wait for it to finish.
"},{"location":"Migration-and-Integration/Migrating-from-HP-ALM/#using-the-hp-alm-migration-tool","title":"Using the HP ALM Migration Tool","text":""},{"location":"Migration-and-Integration/Migrating-from-HP-ALM/#connecting-to-hp-alm-and-choosing-artifacts","title":"Connecting to HP ALM and choosing artifacts","text":"Now that you have installed the migration tool, you can launch it at any time by going to Start > Programs > Inflectra > SpiraTest > Tools > HP ALM Importer. This will launch the migration tool application itself:
The first thing you need to do is to enter the URL for the instance of HP ALM that you want to import the information from (typically of the form http://<server name>/qcbin) together with a valid username and password.
Once you have entered this information, click the <Authenticate> button and the list of possible domains and projects will be populated. Select the HP ALM domain and project that you want to import from and click the <Login> button. If the user has permission to access this project, you will be see a message that the login was successful.
Assuming this is a new import session, i.e. you are not restoring a previous session, choose the types of artifact you want to import and then click the <Next> button to move to the next page in the import wizard:
"},{"location":"Migration-and-Integration/Migrating-from-HP-ALM/#connecting-to-spira-and-choosing-options","title":"Connecting to Spira and choosing options","text":"This page allows you to enter the URL, user name and password that you want to use to access the instance of Spira that you want to import to and click <Login>. Typically the URL is of the form (http://<server name>/SpiraTest). The version of the importer being used must be compatible with the version of Spira you're importing into; if not you will receive an error message.
You start the import process from the Spira login screen. There is an \"Import Options\" box. Here, you can check 'Verbose Logging' to add more log entries to the session log, which will be saved on the computer's Desktop. You can also choose to 'Resume Previous Import Session'. This option is explained below.
Click the <Start Import> button to begin the process of importing the various artifacts from HP ALM into Spira. Note that the importer will automatically create a new project in Spira to hold all the artifacts with the same name as that used in HP ALM.
"},{"location":"Migration-and-Integration/Migrating-from-HP-ALM/#import-progress","title":"Import progress","text":"During the import process, the importer shows the current session identifier (which is part of the session log name), as well as the progress and estimated remaining time for every artifact. The Event History at the bottom logs important events of the session. As each of the types of artifact are imported, the progress display will change (as shown above). Once the import has finished, you will receive a message to that effect and the <Done> button will be enabled. Clicking this button closes the importer. You can cancel the importing session at any time by clicking on 'Cancel and Close'. You should now log into Spira using the same username and password that was used for the import to view the imported project.
Note: Once you have migrated a project into Spira you will have the definitions of incident priorities and statuses from both Spira and HP ALM (this is because HP ALM doesn't use the same codes as Spira, so they will be imported).
You should go back in to the Administration screen and make all the standard Spira statuses and priorities inactive, and then create a new incident workflow using the imported HP ALM statuses.
"},{"location":"Migration-and-Integration/Migrating-from-HP-ALM/#restoring-a-failed-or-canceled-session","title":"Restoring a failed or canceled Session","text":"If you can cancel a session part way through, or the session fails for any reason, you can easily resume importing artifacts from that session. To do this:
ApplicationData]\\Spira_ALM_QC_Importer_Sessions). You should see then the identification of the session, followed by the artifacts previously selected for it:
At this point, you can add or remove artifacts from the session. Please note that artifacts that already started importing can not now be deselected. In our example, only Test Runs, Users, and Attachments are not disabled. Since we didn't select Attachments originally, if you check off that box, it will include attachments for new artifacts - changes will not be made to artifact attachments already imported to Spira. Press 'Start Import' and wait a few seconds until the program loads the previous session data and continues from the point it stopped previously:
Wait until the import session successfully ends. Congratulations, you have just imported your data from HP ALM to Spira!
"},{"location":"Migration-and-Integration/Migrating-from-HP-QualityCenter/","title":"Migrating from HP QualityCenter","text":"This is for Legacy HP QualityCenter installs only
You should only use this guide if you are using HP QualityCenter 10.0 or older.
If your HP QC/ALM installation is 11.5 or newer please follow the instructions here.
This section outlines how to use the included Migration Tool for importing Requirements, Test Cases, Test Runs and Incidents from HP QualityCenter (formerly known as Mercury TestDirector).
"},{"location":"Migration-and-Integration/Migrating-from-HP-QualityCenter/#installing-the-qualitycenter-migration-tool","title":"Installing the QualityCenter Migration Tool","text":"This section outlines how to install the migration tool for QualityCenter onto a workstation so that you can then migrate whole projects from QualityCenter to SpiraTest. It assumes that you already have a working installation of SpiraTest v3.0 or later. If you have an earlier version of SpiraTest you will need to upgrade to at least v3.0 before trying to migrate projects.
The Windows installation package can be downloaded from the 'Add-Ons & Downloads\" section of the Inflectra website. Once you have obtained the Windows Installer package, simply double-click on the package to begin the installation wizard which should display the following welcome page:
Click the <Next> button, accept the software license, then click <Next> again to choose the folder to install the migration tool to:
Choose the folder to install to, and then decide whether the application should be accessible by all users on the workstation or just the current user. Then click the <Install> button to start the installation process. It will confirm if you want to proceed, click <Next> then wait for it to finish.
"},{"location":"Migration-and-Integration/Migrating-from-HP-QualityCenter/#using-the-hp-qualitycenter-migration-tool","title":"Using the HP QualityCenter Migration Tool","text":"Now that you have installed the migration tool, you can launch it at any time by going to Start > Programs > SpiraTest > Tools > QualityCenter Importer. This will launch the migration tool application itself:
The first thing you need to do is to enter the URL for the instance of HP QualityCenter that you want to import the information from (typically of the form http://<server name>/qcbin) together with a valid username and password.
Note that the importer has only been tested against version 9.0 of Quality Center or later. It may not work correctly against previous versions. Once you have entered this information, click the <Authenticate> button and the list of possible domains and projects will be populated.
Select the QualityCenter domain and project that you want to import from and click the <Login> button:
Assuming that the user name selected has permission to access this project, you will be prompted with a message box indicating that the login was successful. Now choose the types of artifact you want to import and then click the <Next> button to move to the next page in the import wizard:
This page allows you to enter the URL, user name and password that you want to use to access the instance of SpiraTest that you want to import to and click <Login>. Typically the URL is of the form (http://<server name>/SpiraTest). The version of the importer being used must be compatible with the version of SpiraTest you're importing into; if not you will receive an error message.
Assuming that the login was successful, click the <Start Import> button to actually begin the process of importing the various artifacts from QualityCenter into SpiraTest. Note that the importer will automatically create a new project in SpiraTest to hold all the artifacts with the same name as that used in QualityCenter.
During the import process, as each of the types of artifact are imported, the progress display will change (as illustrated above). Once the import has finished, you will receive a message to that effect and the <Done> button will be enabled. Clicking this button closed the importer. You should now log into SpiraTest using the same user name and password that was used for the import to view the imported project.
The migration tool will import the following artifacts:
Note: Once you have migrated a project into SpiraTest you will have the definitions of incident priorities and statuses from both SpiraTest and QualityCenter (this is because QualityCenter doesn't use the same codes as SpiraTest, so they will be imported). You should go back in to the Administration screen and make all the SpiraTest statuses and priorities inactive.
"},{"location":"Migration-and-Integration/Migrating-from-IBM-Rational-Quality-Manager/","title":"Migrating from IBM Rational Quality Manager (RQM)","text":"This section outlines how to use the free Migration Tool for importing test plans, test cases, test suites, test scripts and test executions from IBM Rational Quality Manager (RQM) into Spira (SpiraTest, SpiraTeam or SpiraPlan).
"},{"location":"Migration-and-Integration/Migrating-from-IBM-Rational-Quality-Manager/#installing-the-rqm-migration-tool","title":"Installing the RQM Migration Tool","text":"This section outlines how to install the migration tool for RQM onto a workstation so that you can then migrate whole projects from RQM to Spira. It assumes that you already have a working installation of Spira v6.0 or later and a live instance of RQM to migrate from. If you have an earlier version of Spira you will need to upgrade to at least v6.0 before trying to migrate projects.
The Windows installation package can be downloaded from the 'Add-Ons & Downloads\" section of the Inflectra website. Once you have obtained the Windows Installer package, simply double-click on the package to begin the installation wizard which should display the following welcome page:
Click the <Next> button, accept the software license, then click <Next> again to choose the folder to install the migration tool to:
Choose the folder to install to, and then decide whether the application should be accessible by all users on the workstation or just the current user. Then click the <Install> button to start the installation process. It will confirm if you want to proceed, click <Next> then wait for it to finish.
"},{"location":"Migration-and-Integration/Migrating-from-IBM-Rational-Quality-Manager/#using-the-rqm-migration-tool","title":"Using the RQM Migration Tool","text":"Now that you have installed the migration tool, you can launch it at any time by going to Start > Programs > Inflectra > SpiraTest > Tools > IBM RQM Importer. This will launch the migration tool application itself:
The first thing you need to do is to enter the URL for the instance of RQM that you want to import the information from (typically of the form https://jazz.net/mycompany) together with a valid username and password.
Once you have entered this information, click the <Authenticate> button and the list of projects will be populated. Select the RQM project that you want to import from You can also choose to not import certain artifacts from RQM (e.g. test executions, etc.) then click the <Next> button to move to the next page in the import wizard:
This page allows you to enter the URL, user name and password that you want to use to access the instance of Spira that you want to import to and click <Login>. Typically, the URL is of the form (https://xxxx.spiraservice.net). The version of the importer being used must be compatible with the version of Spira you're importing into; if not you will receive an error message.
Assuming that the login was successful, click the <Start Import> button to actually begin the process of importing the various artifacts from RQM into Spira. Note that the importer will automatically create a new project in Spira to hold all the artifacts with the same name as that used in RQM.
During the import process, as each of the types of artifact are imported, the progress display will change (as illustrated above). Once the import has finished, you will receive a message to that effect and the <Done> button will be enabled. Clicking this button closed the importer. You should now log into SpiraTest using the same user name and password that was used for the import to view the imported project.
The migration tool will import the following artifacts from RQM:
Should the import fail for any reason, there will be a log file created on the Desktop of the person doing the import. The filename is usually: Spira_RQM_Import.log.
When you migrate an RQM project to Spira, the data will migrate as described below.
"},{"location":"Migration-and-Integration/Migrating-from-IBM-Rational-Quality-Manager/#test-plans-and-test-cases","title":"Test Plans and Test Cases","text":"The test plans and associated test cases from RQM will migrate into Spira test case folders and test cases:
becomes:
"},{"location":"Migration-and-Integration/Migrating-from-IBM-Rational-Quality-Manager/#test-scripts-and-test-steps","title":"Test Scripts and Test Steps","text":"The test scripts and associated manual test steps from RQM will migrate into Spira template test cases and test steps:
becomes:
In RQM, the test cases don't contain test steps themselves. Instead, the test case contain references to the test scripts, which contain the test steps.
Therefore when we migrate over the test cases from RQM to Spira, we create linked test cases from the test plan test cases to the test script test cases to maintain these relationships:
"},{"location":"Migration-and-Integration/Migrating-from-IBM-Rational-Quality-Manager/#test-runs-and-test-run-steps","title":"Test Runs and Test Run Steps","text":"The test executions from RQM contain test steps:
These are migrated over into Spira and test runs and test run steps:
"},{"location":"Migration-and-Integration/Migrating-from-Jira/","title":"Migrating from Atlassian Jira","text":"This section outlines how to use the included Migration Tool for importing projects, versions, requirements, issues, tasks and associated attachments from Atlassian Jira to SpiraTeam.
Note: This migration tool works with Jira Cloud, Server and Data Center editions.
"},{"location":"Migration-and-Integration/Migrating-from-Jira/#installing-the-jira-migration-tool","title":"Installing the Jira Migration Tool","text":"This section outlines how to install the migration tool for Jira onto a workstation so that you can then migrate whole projects from Jira to either SpiraTeam or SpiraPlan (hereafter referred to as SpiraTeam). It assumes that you already have a working installation of SpiraTeam v6.0 or later and a working version of Jira Cloud, Server or Data Center.
Minimum Version of Spira
You must be on at least SpiraTeam 6.13 to use this tool. If you have an earlier version of SpiraTeam you will need to upgrade to at least v6.13 before trying to migrate projects.
The Windows installation package can be downloaded from the 'Add-Ons & Downloads\" section of the Inflectra website. Once you have obtained the Windows Installer package, simply double-click on the package to begin the installation wizard which should display the following welcome page:
Click the <Next> button, accept the software license, then click <Next> again to choose the folder to install the migration tool to:
Choose the folder to install to, and then decide whether the application should be accessible by all users on the workstation or just the current user. Then click the <Install> button to start the installation process. It will confirm if you want to proceed, click <Next> then wait for it to finish.
"},{"location":"Migration-and-Integration/Migrating-from-Jira/#using-the-jira-migration-tool","title":"Using the Jira Migration Tool","text":"Now that you have installed the migration tool, you can launch it at any time by going to Start > Programs > Inflectra > SpiraTeam > Tools > Jira Importer. This will launch the migration tool application itself:
"},{"location":"Migration-and-Integration/Migrating-from-Jira/#connecting-to-jira","title":"Connecting to Jira","text":"The first thing you need to do is to enter the URL for the instance of Jira that you want to import the information from (typically of the form http://servername/jira for on-premise and https://myinstance.atlassian.net for cloud) together with a valid username and password (or API Key if using Jira Cloud).
Once you have entered this information, click the Login button and the list of possible Jira projects will be populated.
Select the Jira project that you want to import from, choose which artifacts (requirements, tasks incidents, users, attachments, etc.) you want to import, then click the Next button to move to the next page in the import wizard.
"},{"location":"Migration-and-Integration/Migrating-from-Jira/#connecting-to-spirateam","title":"Connecting to SpiraTeam","text":"This page allows you to enter the URL, user name and password (or Api Key if using SSO) that you want to use to access the instance of SpiraTeam that you want to import to and click Login. (Typically the URL is of the form http://servername/SpiraTeam for on-premise and https://myinstance.spiraservice.net for cloud). The version of the importer being used must be compatible with the version of SpiraTeam you're importing into; if not you will receive an error message.
Assuming that the login was successful, next choose the product template that you want the imported project to use. You can also select the option to '--- Create New Template ---' instead, which will instruct the importer to create a brand new product template for the import. We recommend this option for test imports to avoid affecting any production templates
Once you have chosen the template, click the Next button to move to the next page in the wizard:
"},{"location":"Migration-and-Integration/Migrating-from-Jira/#mapping-jira-issues-types-to-spirateam-artifacts","title":"Mapping Jira Issues Types to SpiraTeam Artifacts","text":"On this page you will map the different SpiraTeam artifacts to the different issue types in Jira. Currently, the following artifact types in SpiraTeam can be mapped to Jira issues: - Requirements (used for user stories, features, epics, etc.) - Tasks (used for tasks and sub-tasks) - Incidents (used for all other issue types such as bugs, defects, issues)
Once you have mapped the artfiacts, click the Start Import button to actually begin the process of importing the various artifacts from Jira into SpiraTeam.
"},{"location":"Migration-and-Integration/Migrating-from-Jira/#importer-progress","title":"Importer Progress","text":"Note that the importer will automatically create a new project in SpiraTeam to hold all the artifacts with the same name as that used in Jira.
During the import process, as each of the types of artifact are imported, the progress display will change (as illustrated above). Once the import has finished, you will receive a message to that effect and the Done button will be enabled. Clicking this button will close the importer. You should now log into SpiraTeam using the same user name and password that was used for the import to view the imported project.
"},{"location":"Migration-and-Integration/Migrating-from-Jira/#what-is-imported","title":"What is Imported?","text":"The migration tool will import the following artifacts:
Any of the Jira issue types that are mapped to requirements in SpiraTeam:
Will be imported into SpiraTeam as types of requirement:
"},{"location":"Migration-and-Integration/Migrating-from-Jira/#tasks","title":"Tasks","text":"Any of the Jira issue types that are mapped to tasks in SpiraTeam:
Will be imported into SpiraTeam as types of task:
"},{"location":"Migration-and-Integration/Migrating-from-Jira/#incidents","title":"Incidents","text":"Any of the Jira issue types that are mapped to incidents in SpiraTeam:
Will be imported into SpiraTeam as types of incident:
"},{"location":"Migration-and-Integration/Migrating-from-MS-Azure-DevOps/","title":"Migrating from MS Azure DevOps / TFS","text":"This section outlines how to use the free Migration Tool for importing users, releases, requirements, test plans, test suites, test cases, test runs, tasks and defects from Microsoft Azure DevOps (ADO) also known as Microsoft Team Foundation Server (TFS) into Spira.
"},{"location":"Migration-and-Integration/Migrating-from-MS-Azure-DevOps/#installing-the-ado-migration-tool","title":"Installing the ADO Migration Tool","text":"This section outlines how to install the migration tool for ADO onto a workstation so that you can then migrate whole projects from ADO into Spira (SpiraTest, SpiraTeam or SpiraPlan). It assumes that you already have a working installation of Spira v7.0 or later. If you have an earlier version of Spira you will need to upgrade to at least v7.0 before trying to migrate projects.
The Windows installation package can be downloaded from the 'Add-Ons & Downloads\" section of the Inflectra website. Once you have obtained the Windows Installer package, simply double-click on the package to begin the installation wizard which should display the following welcome page:
Click the Next button, accept the software license, then click Next again to choose the folder to install the migration tool to:
Choose the folder to install to, and then decide whether the application should be accessible by all users on the workstation or just the current user. Then click the Install button to start the installation process. It will confirm if you want to proceed, click Next then wait for it to finish.
Now that you have installed the migration tool, you can launch it at any time by going to Start > Programs > Spira > Tools > ADO/TFS Importer. This will launch the migration tool application itself:
The first thing you need to do is to enter the URL for the instance of ADO that you want to import.
For cloud ADO instances, the URL will normally be the https://dev.azure.com/account, where 'account' is the name of the ADO organization. You will also need to enter a valid username and Personal Access Token (PAT).
For on-premise TFS installations, the URL should include the project collection that you want to import the information from (typically of the form http://server:8080/tfs) together with a valid username, Windows\u00ae domain and password.
Once you have entered this information, click the Authenticate button and the list of possible projects will be populated in the Project dropdown list. Select the ADO project that you want to import from and either keep the Test Plan dropdown set to 'All Test Plans' or pick a specific test plan to import.
You can also at this point choose which optional items will be imported from ADO - users, requirements, tasks, bugs, test cases, test runs, attachments or test sets. Once you have chosen the project and/or test plan, click the Next button to go to the Spira configuration screen.
This page allows you to enter the URL, user name and password that you want to use to access the instance of Spira that you want to import to and click Login.
Typically the URL is of the form http://server-name/Spira for on-premise installations and https://mycompany.spiraservice.net for cloud instances. The version of the importer being used must be compatible with the version of Spira you're importing into; if not you will receive an error message.
Assuming that the login was successful, click the Next button to go to the next screen where you will map the different types of work item to Spira artifacts:
On this page you will map the different Spira artifacts to the different work item types in ADO. Currently, the following artifact types in Spira can be mapped to ADO work items: - Requirements (used for user stories, features, epics, etc.) - Tasks (used for tasks) - Incidents (used for all other issue types such as bugs, defects, issues)
Note that you don't need to explicitly map test cases as they are automatically handled.
Once you have mapped the work item types you will be importing, click the Start Import button to actually begin the process of importing the various artifacts from ADO into Spira. Note that the importer will automatically create a new project in Spira to hold all the artifacts with the same name as that used in ADO.
During the import process, as each of the types of artifact are imported, the progress display will change (as illustrated above). Once the import has finished, you will receive a message to that effect and the Done button will be enabled. Clicking this button closed the importer. You should now log into Spira using the same user name and password that was used for the import to view the imported project.
The migration tool will import the following artifacts:
Once the import has completed, please open up the the import log file Spira_ADOTFSImport.log that will be saved to the Windows Desktop of the user running the import. In this log file you will see what was imported, with any items that failed to import also listed.
This section outlines how to use the free Migration Tool for importing users, releases, requirements, test plans, test suites, test cases, test runs and defects from Microsoft Test Manager (MTM).
"},{"location":"Migration-and-Integration/Migrating-from-MS-Test-Manager/#installing-the-mtm-migration-tool","title":"Installing the MTM Migration Tool","text":"This section outlines how to install the migration tool for MTM onto a workstation so that you can then migrate whole projects from MTM into SpiraTest (or SpiraTeam). It assumes that you already have a working installation of SpiraTest v4.0 or later. If you have an earlier version of SpiraTest you will need to upgrade to at least v4.0 before trying to migrate projects.
The Windows installation package can be downloaded from the 'Add-Ons & Downloads\" section of the Inflectra website. Once you have obtained the Windows Installer package, simply double-click on the package to begin the installation wizard which should display the following welcome page:
Click the <Next> button, accept the software license, then click <Next> again to choose the folder to install the migration tool to:
Choose the folder to install to, and then decide whether the application should be accessible by all users on the workstation or just the current user. Then click the <Install> button to start the installation process. It will confirm if you want to proceed, click <Next> then wait for it to finish.
"},{"location":"Migration-and-Integration/Migrating-from-MS-Test-Manager/#using-the-mtm-migration-tool","title":"Using the MTM Migration Tool","text":"Now that you have installed the migration tool, you can launch it at any time by going to Start > Programs > SpiraTest > Tools > MTM Importer. This will launch the migration tool application itself:
The first thing you need to do is to enter the URL for the instance of Microsoft Team Foundation Server (TFS) that MTM is running on. The URL should include the project collection that you want to import the information from (typically of the form http://server:8080/tfs) together with a valid username, Windows\u00ae domain and password.
Once you have entered this information, click the <Authenticate> button and the list of possible projects will be populated in the Project dropdown list. Select the MTM project that you want to import from and either keep the Test Plan dropdown set to 'All Test Plans' or pick a specific test plan to import.
You can also at this point choose which optional items will be imported from MTM (users, test runs, attachments or test sets) -- test cases are always imported. Once you have chosen the project and/or test plan, click the <Next> button to go to the SpiraTest configuration screen.
This page allows you to enter the URL, user name and password that you want to use to access the instance of SpiraTest that you want to import to and click <Login>. Typically the URL is of the form (http://<server name>/SpiraTest). The version of the importer being used must be compatible with the version of SpiraTest you're importing into; if not you will receive an error message.
Assuming that the login was successful, click the <Start Import> button to actually begin the process of importing the various artifacts from MTM into SpiraTest. Note that the importer will automatically create a new project in SpiraTest to hold all the artifacts with the same name as that used in MTM.
During the import process, as each of the types of artifact are imported, the progress display will change (as illustrated above). Once the import has finished, you will receive a message to that effect and the <Done> button will be enabled. Clicking this button closed the importer. You should now log into SpiraTest using the same user name and password that was used for the import to view the imported project.
The migration tool will import the following artifacts:
This section outlines how to use the free Migration Tool for importing Users, Test Cases, Test Sets, Test Runs, Issues, Requirements and Attachments from PractiTest into SpiraPlan.
"},{"location":"Migration-and-Integration/Migrating-from-PractiTest/#installing-the-practitest-migration-tool","title":"Installing the PractiTest Migration Tool","text":"This section outlines how to install the migration tool for PractiTest onto a workstation so that you can then migrate whole projects from PractiTest to SpiraTest/SpiraTeam/SpiraPlan (SpiraPlan). It assumes that you already have a working installation of SpiraPlan v5.0 or later and a live instance of PractiTest to migrate from. If you have an earlier version of SpiraPlan you will need to upgrade to at least v5.0 before trying to migrate projects.
The Windows installation package can be downloaded from the \"Add-Ons & Downloads\" section of the Inflectra website. Double-click the package to begin the installation wizard. The wizard should display the following welcome page:
Click the Next button to choose the folder to install the migration tool to:
Choose the folder to install to, and then decide whether the application should be accessible by all users on the workstation or just the current user. Then, click Next. It will confirm if you want to proceed, click Next then wait for it to finish.
Now that you have installed the migration tool, you can launch it at any time by going to Start > Programs > Inflectra > SpiraPlan > Tools > PractiTest Importer. This will launch the migration tool application itself:
The first thing you need to do is to enter the user email for the instance of PractiTest that you want to import the information from, together with a valid API Token (provided under Account Settings on Practitest).
Once you have entered this information, click Authenticate and the list of projects will be populated. Select the PractiTest project you want to import from. You can also choose to not import certain artifacts from PractiTest (e.g. Issues, etc.) then click the Next button to move to the next page in the import wizard:
This page allows you to enter the URL, user name and password to access SpiraPlan that you want to import to. Enter the information and click Login. Typically, the URL is of the form (https://xxxx.spiraservice.net). The version of the importer being used must be compatible with the version of SpiraPlan you're importing into; if not you will receive an error message.
Assuming that the login was successful, click the Start Import button to actually begin the process of importing the various artifacts from PractiTest into SpiraPlan. Note that the importer will automatically create a new product in SpiraPlan to hold all the artifacts with the same name as that used in PractiTest. Note: if you run the importer on the same PractiTest project multiple times, it will create a new product in SpiraPlan each time.
During the import process, as each of the types of artifact are imported, the progress display will change (as illustrated above). Once the import has finished, you will receive a message to that effect and the Done button will be enabled. Click this button to close the importer. You can now log into SpiraPlan to view the imported project.
The migration tool will import the following artifacts from PractiTest:
If the Import Fails
In case the import fail for any reason, there will be a log file created on the Desktop of the computer doing the import. The filename is usually: Spira_PractiTest_Import.log . Please send this file to our support team if help is needed.
Importing Attachments
Because of a limitation in PractiTest, attachments can only be migrated from PractiTest after a delay of a certain number of seconds. So if you have 10 attachments, the migration tool will have to wait 5 seconds, for example, before importing each attachment. There is a user configurable delay in seconds that you can set for attachments. If the import fails because of attachments, try increasing this delay.
Due to a PractiTest limitation, if importing attachments, expect the process to take a few extra seconds per attachment. Note that this process may still result in an error because of limitations in the PractiTest API.\u00a0\u21a9
This feature is not currently available because of missing API calls in PractiTest. Hopefully it will be available in a future PractiTest update\u00a0\u21a9
This section outlines how to use the free Migration Tool for importing Projects, Test Suites, Test Cases, and Test Steps from the open source TestLink application into SpiraTest.
"},{"location":"Migration-and-Integration/Migrating-from-TestLink/#installing-the-testlink-migration-tool","title":"Installing the TestLink Migration Tool","text":"This section outlines how to install the migration tool for TestLink onto a workstation so that you can then migrate whole projects from TestLink to either SpiraTest, SpiraTeam or SpiraPlan (hereafter referred to as SpiraTest). It assumes that you already have a working installation of SpiraTest v5.0 or later and a live instance of TestLink to migrate from. If you have an earlier version of SpiraTest you will need to upgrade to at least v5.0 before trying to migrate projects.
The Windows installation package can be downloaded from the 'Add-Ons & Downloads\" section of the Inflectra website. Once you have obtained the Windows Installer package, simply double-click on the package to begin the installation wizard which should display the following welcome page:
Click the <Next> button, accept the software license, then click <Next> again to choose the folder to install the migration tool to:
Choose the folder to install to, and then decide whether the application should be accessible by all users on the workstation or just the current user. Then click the <Install> button to start the installation process. It will confirm if you want to proceed, click <Next> then wait for it to finish.
"},{"location":"Migration-and-Integration/Migrating-from-TestLink/#using-the-testlink-migration-tool","title":"Using the TestLink Migration Tool","text":"Now that you have installed the migration tool, you can launch it at any time by going to Start > Programs > Inflectra > SpiraTest > Tools > TestLink Importer. This will launch the migration tool application itself:
The first thing you need to do is to enter the URL for the instance of TestLink that you want to import the information from (typically of the form http://myserver/testlink) together with a valid API Key. If you don't have an API Key, you need to first login to TestLink using your normal username and password, then generate an API on the user profile page:
Once you have entered this information, click the <Authenticate> button and the list of projects will be populated. Select TestLink project that you want to import from then click the <Next> button to move to the next page in the import wizard:
This page allows you to enter the URL, user name and password that you want to use to access the instance of SpiraTest that you want to import to and click <Login>. Typically, the URL is of the form (https://xxxx.spiraservice.net). The version of the importer being used must be compatible with the version of SpiraTest you're importing into; if not you will receive an error message.
Assuming that the login was successful, click the <Start Import> button to actually begin the process of importing the various artifacts from TestLink into SpiraTest. Note that the importer will automatically create a new project in SpiraTest to hold all the artifacts with the same name as that used in TestLink.
During the import process, as each of the types of artifact are imported, the progress display will change (as illustrated above). Once the import has finished, you will receive a message to that effect and the <Done> button will be enabled. Clicking this button closed the importer. You should now log into SpiraTest using the same user name and password that was used for the import to view the imported project.
The migration tool will import the following artifacts from TestLink:
For example, the following TestLink project:
Now looks like this in SpiraTest (v5.4):
Should the import fail for any reason, there will be a log file created on the Desktop of the person doing the import. The filename is usually: Spira_TestLink_Import.log.
"},{"location":"Migration-and-Integration/Migrating-from-TestRail/","title":"Migrating from TestRail","text":"This section outlines how to use the free Migration Tool for importing Milestones, Test Cases, Test Suites, Test Plans, Test Runs, and Test Results from Gurock TestRail into SpiraTest.
"},{"location":"Migration-and-Integration/Migrating-from-TestRail/#installing-the-testrail-migration-tool","title":"Installing the TestRail Migration Tool","text":"This section outlines how to install the migration tool for TestRail onto a workstation so that you can then migrate whole projects from TestRail to either SpiraTest or SpiraTeam (hereafter referred to as SpiraTest). It assumes that you already have a working installation of SpiraTest v5.0 or later and a live instance of TestRail to migrate from. If you have an earlier version of SpiraTest you will need to upgrade to at least v5.0 before trying to migrate projects.
The Windows installation package can be downloaded from the 'Add-Ons & Downloads\" section of the Inflectra website. Once you have obtained the Windows Installer package, simply double-click on the package to begin the installation wizard which should display the following welcome page:
Click the <Next> button, accept the software license, then click <Next> again to choose the folder to install the migration tool to:
Choose the folder to install to, and then decide whether the application should be accessible by all users on the workstation or just the current user. Then click the <Install> button to start the installation process. It will confirm if you want to proceed, click <Next> then wait for it to finish.
"},{"location":"Migration-and-Integration/Migrating-from-TestRail/#using-the-testrail-migration-tool","title":"Using the TestRail Migration Tool","text":"Now that you have installed the migration tool, you can launch it at any time by going to Start > Programs > Inflectra > SpiraTest > Tools > TestRail Importer. This will launch the migration tool application itself:
The first thing you need to do is to enter the URL for the instance of TestRail that you want to import the information from (typically of the form https://xxxxx.testrail.net) together with a valid username and password.
Once you have entered this information, click the <Authenticate> button and the list of projects will be populated. Select TestRail project that you want to import from You can also choose to not import certain artifacts from TestRail (e.g. Milestones, etc.) then click the <Next> button to move to the next page in the import wizard:
This page allows you to enter the URL, user name and password that you want to use to access the instance of SpiraTest that you want to import to and click <Login>. Typically, the URL is of the form (https://xxxx.spiraservice.net). The version of the importer being used must be compatible with the version of SpiraTest you're importing into; if not you will receive an error message.
Assuming that the login was successful, click the <Start Import> button to actually begin the process of importing the various artifacts from TestRail into SpiraTest. Note that the importer will automatically create a new project in SpiraTest to hold all the artifacts with the same name as that used in TestRail.
During the import process, as each of the types of artifact are imported, the progress display will change (as illustrated above). Once the import has finished, you will receive a message to that effect and the <Done> button will be enabled. Clicking this button closed the importer. You should now log into SpiraTest using the same user name and password that was used for the import to view the imported project.
The migration tool will import the following artifacts from TestRail:
Should the import fail for any reason, there will be a log file created on the Desktop of the person doing the import. The filename is usually: Spira_TestRail_Import.log.
"},{"location":"Migration-and-Integration/Migrating-from-qTest/","title":"Migrating from qTest","text":"This section outlines how to use the free Migration Tool for importing Users, Test Cases, Test Sets, Test Runs, Defects, Releases, Requirements and Attachments from qTest into SpiraTest (or SpiraTeam, or SpiraPlan).
"},{"location":"Migration-and-Integration/Migrating-from-qTest/#installing-the-qtest-migration-tool","title":"Installing the qTest Migration Tool","text":"For the migration tool to work you need a working installation of SpiraTest/SpiraTeam/SpiraPlan v5.0 or later and a live instance of qTest to migrate from. You will also need a Windows machine to install the migration tool onto, that can access both SpiraPlan and qTest.
First, download the Windows installation package from the \"Add-Ons & Downloads\" section of the Inflectra website. Double-click the msi file to start the installation wizard. The first screen of this wizard will look like this:
Click the Next button to choose the folder to install the migration tool to:
Choose the folder to install to and then click Next. It will confirm if you want to proceed, click Next then wait for it to finish.
Now that you have installed the migration tool, you can launch it at any time by going to Start > Programs > Inflectra > SpiraTest > Tools > qTest Importer. This will launch the migration tool application itself:
First, enter the qTest information below and click Authenticate to verify your details (this will also retrieve the list of projects in qTest):
Next, select the qTest project that you want to import from. Now choose which artifacts you want to import from qTest (e.g. Defects, Requirements). NOTE: to import test cases, test sets, or test runs, the wizard needs to also import releases.
Click Next to move to the Connect to SpiraTest part of the import wizard:
On the Connect to SpiraTest page you have to enter your SpiraTest login information and click Login:
Once the wizard has verified its connection with SpiraTest and you are logged in, click the now enabled Start Import button. This begins the import process from qTest into SpiraPlan. The importer will automatically create a new product in SpiraPlan with the same name as that used in qTest. Note: if you run the importer on the same qTest project multiple times, it will create a new product in SpiraTest each time.
During the import process, as each artifact is imported, the progress display will change (as illustrated above). Once the import finishes the Done button will be enabled. Click this button to close the importer. You can now log into SpiraPlan to view the imported project.
The migration tool can import the following artifacts from qTest:
If the import fails
If the import fails for any reason, you will find a log file on the Desktop of the computer where the migration tool is installed. The filename will normally be \"Spira_qTest_Import.log\". Please send this file to our support team if help is needed.
"},{"location":"Migration-and-Integration/Project-Backup-and-Migration/","title":"Project Backup and Migration","text":"This application allows an entire project to be exported to a backup file, for archiving and offline storage of SpiraTeam projects. The base minimum SpiraTeam version required is 3.2 (014), and there is some data that is not backed up. Also there are separate versions of the backup and migration tool for SpiraTeam v3.2, v4.x and v5.x, and you need to use the appropriate version that matches your installations.
The migration tool does not support upgrading versions, i.e. you need to have the same version of SpiraTeam for both the import and export phase. If you have two different versions of SpiraTeam, you must first upgrade the older installation to the same version as the newer one.
"},{"location":"Migration-and-Integration/Project-Backup-and-Migration/#main-screen","title":"Main Screen","text":"When running the application, you will see the main screen, which gives you three main options: Export, Import, and Transfer:
"},{"location":"Migration-and-Integration/Project-Backup-and-Migration/#project-export","title":"Project Export","text":"Clicking the Export button will start the Export wizard, allowing you to save the project to a file.
On the first screen, enter in the SpiraTeam server URL, and the administrator account password. The administrator account must be used, so make sure that it is an active account (Active: Yes) in the application. When clicking the 'Next' button, it will verify the server and login information.
The second screen gives you the selection of the project to export. Select the project, and then click the 'Next' button.
On the third screen, select the location and name of the file you wish to export the project to. If the file already exists, it will be overwritten.
The next screen is the verification screen -- make sure you wish to start the export, and then click the 'Next' button. Once started, you cannot cancel or change any options. To change an option, click the 'Back' button at any time before starting the process to go back a screen.
Once finished, your output file will be created. You can store and backup the file as you need.
"},{"location":"Migration-and-Integration/Project-Backup-and-Migration/#project-import","title":"Project Import","text":"To import a project file into a new project in SpiraTeam, select the Import button on the main screen. This will start the Import wizard:
On the first screen, enter in the SpiraTeam server URL, and the administrator account password. The administrator account must be used, so make sure that it is an active account (Active: Yes) in the application. When clicking the 'Next' button, it will verify the server and login information.
The second screen allows you to enter in a name for the project created. You can enter in the name of an existing project, but a new project by that name will be created -- it will not import the project into an existing project.
The third screen is only present on the SpiraTeam v4.0 version of the migration tool. This is because the SpiraTeam 4.0 API requires that new user's be created with passwords of specific strength. Any user in the project file that is not present in the destination system will be created with the password that you specify:
You should enter a password, click the 'Test' button to make sure it will be accepted by SpiraTeam, and then click the 'Next' button. This will then display the fourth screen:
The fourth screen will let you select the PRJ Project file. Select the file by clicking on the folder button, and the application will verify the integrity of the file before performing the import:
The last screen will let you verify your settings before starting the import. If any changes need to be made, click the Back button. Once ready to import the project, click the 'Finish button to start the import.
If any error occurs during import, it's not recommended to use the project created in the application, although you can log in and view the data that was imported.
"},{"location":"Migration-and-Integration/Project-Backup-and-Migration/#project-transfer","title":"Project Transfer","text":"Selecting the 'Transfer' button will start the transfer wizard, which contains screens from both the Import and Export wizards, above.
The first two screens will let you select the SpiraTeam application to pull the project from, following the same information as the first two screens in the Export wizard.
The next three screens will ask for the new SpiraTeam application to create the project in and the default password for any new users that need to be created. These three screens follow the first three screens of the Import wizard, above. Note that the application will try to determine if you're trying to re-import the project into the same server, and advise that copying the project in the SpiraTeam UI is a better choice.
The final screen will provide a summary of the chosen settings. Once you click 'Next', the transfer process will start:
Once transfer starts, the entire project will be unloaded into a temporary directory on the computer running the application, and then the project will be imported into the new system.
"},{"location":"Migration-and-Integration/Project-Backup-and-Migration/#data-transferred","title":"Data Transferred","text":"SpiraTeam v3.2 Exported Imported Incidents \u2713 \u2713 Requirements \u2713 \u2713 Tasks \u2713 \u2713 Releases \u2713 \u2713 Test Cases \u2713 \u2713 Test Sets \u2713 \u2713 Test Runs \u2713 \u2713 Custom Properties \u2713 \u2713 Custom Lists \u2713 \u2713 Document Files \u2713 \u2713 Document Folders \u2713 \u2713 Document Types \u2713 Comments / Resolutions \u2713 \u2713 Datasync Mappings \u2713 Automation Hosts \u2713 \u2713 Automation Engines \u2713 \u2713 Project Roles \u2713 Project Users \u2713 \u27131The table on the left shows what data is backed up and restored. Future versions of the Migration tool and SpiraTeam may support exporting and importing more data.
The exported project file may be large, since the binary data of all the attachments are downloaded and contained within the file.
Once an export is completed, the migration tool will not delete the project from the system -- you must still do that through the UI. Any changes in the project will not automatically be updated in the export file; you must re-run the export.
Notes:
1Users imported back into v3.2 will be marked Active, even if they were originally inactive.
"},{"location":"RemoteLaunch-User-Guide/BadBoy/","title":"BadBoy","text":"Badboy is an automated website functional test automation system that lets you record website operations in Internet Explorer and generate test automation scripts that can be used to playback the test script against the website.
This section describes how you can use SpiraTest / SpiraTeam (hereafter SpiraTeam) together with RemoteLaunch to schedule and remotely launch instances of Badboy on different computers and have the testing results be transmitted back to SpiraTeam. This allows you to extend your SpiraTeam's test management capabilities to include automated Badboy tests.
Note: This integration requires at least version 3.0 of SpiraTest/Team and version 2.1 of Badboy.
"},{"location":"RemoteLaunch-User-Guide/BadBoy/#installing-the-badboy-engine","title":"Installing the Badboy Engine","text":"This section assumes that you already have a working installation of SpiraTest or SpiraTeam and have installed RemoteLaunch on the various test automation hosts following the instructions in RemoteLaunch Guide. Once those prerequisites are in place, please follow these steps:
Download and extract the BadboyAutomationEngine.zip file from the Inflectra website and locate the appropriate BadboyX.dll for the version of Badboy that you are using.
If you don't see the version listed, just use the nearest version that is lower than your current version.
Copy the file \"*Badboy*X.dll\" (where X is the appropriate version) into the \"extensions\" sub-folder of the RemoteLaunch installation.
Log in to SpiraTeam as a system administrator and go into SpiraTeam main Administration page and click on the \"Test Automation\" link under Integration.
Click the \"Add\" button to enter the new test automation engine details page. The fields required are as follows:
Name: This is the short display name of the automation engine. It can be anything that is meaningful to your users.
Description: This is the long description of the automation engine. It can be anything that is meaningful to your users. (Optional)
Active: If checked, the engine is active and able to be used for any project.
Token: This needs to be the assigned unique token for the automation engine and is used to tell RemoteLaunch which engine to actually use for a given test case. For Badboy this should be BadboyX where 'X' is the version number of the DLL file that you are using.
Once you have finished, click the \"Insert & Close\" button and you will be taken back to the Test Automation list page, with Badboy listed as an available automation engine.
You can modify the Badboy configuration for each of the specific automation hosts, by right-clicking on the RemoteLaunch icon in the system tray and choosing \"Configuration\". That will bring up the RemoteLaunch configuration page.
The Badboy 2.x engine adds its own tab to this page which allows you to configure how Badboy operates:
The following fields can be specified on this screen:
Trace Logging -- When selected, this will log additional trace and debugging information to the Windows Event Log. This should not be selected in a production environment.
"},{"location":"RemoteLaunch-User-Guide/BadBoy/#setting-up-the-automated-test-cases","title":"Setting up the Automated Test Cases","text":"This section describes the process for setting up a test case in SpiraTeam for automation and linking it to an automated Badboy test script.
First you need to display the list of test cases in SpiraTeam (by clicking Testing > Test Cases) and then add a new test case. Once you have added the new test case, click on it and select the \"Automation\" tab:
You need to enter the following fields:
Automation Engine - Choose the Badboy Automation Engine that you created in the previous section from the drop-down list.
Script Type -- This should be set to Linked as the integration with Badboy only supports referencing Badboy test script files and not physically uploading the test scripts into SpiraTeam.
Filename -- This needs to be the full path to the Badboy test script. To make this easier across different machines, you can use several constants for standard Windows locations (see example in screenshot):
[MyDocuments] -- The user's \"My Documents\" folder. The user indicated is the user that ran RemoteLaunch.
[CommonDocuments] -- The Public Document's folder.
[DesktopDirectory] -- The user's Desktop folder. The user indicated is the user that ran RemoteLaunch.
[ProgramFiles] -- Translated to the Program Files directory. For 64-bit machines, it's the 64-bit directory.
[ProgramFilesX86] -- Translated to the 32-bit Program Files directory.
Document Type -- This allows you to choose which document type the automated test script will be categorized under.
Document Folder --This allows you to choose which document folder the automated test script will be stored in.
Version -- The version of the test script (1.0 is used if no value specified)
Test Script -- This is not used with the Badboy Engine since it only supports linked test scripts.
Once you are happy with the values, click [Save] to update the test case. Now you are ready to schedule the automated test case for execution.
"},{"location":"RemoteLaunch-User-Guide/BadBoy/#using-parameterized-test-cases","title":"Using Parameterized Test Cases","text":"There is an advanced feature of SpiraTest/Team and RemoteLaunch that lets you pass parameters from SpiraTeam to your Badboy automated test script. This is very useful if you have a data-driven Badboy test script that defines input variables from an external data source.
To setup the automated test case for parameters, click on the \"Test Steps\" tab and click on \"Edit Parameters\":
The name of the parameter ${login} needs to match the name of the variable defined within the Badboy script in its variables configuration.
"},{"location":"RemoteLaunch-User-Guide/BadBoy/#executing-the-badboy-test-sets-from-spirateam","title":"Executing the Badboy Test Sets from SpiraTeam","text":"There are two ways to execute automated test cases in SpiraTeam:
Schedule the test cases to be executed on a specific computer (local or remote) at a date/time in the future
Execute the test cases right now on the local computer.
We shall outline both of these two scenarios in this section. However first we need to setup the appropriate automation hosts and test sets in SpiraTeam:
"},{"location":"RemoteLaunch-User-Guide/BadBoy/#configuring-the-automation-hosts-and-test-sets","title":"Configuring the Automation Hosts and Test Sets","text":"Go to Testing > Automation Hosts in SpiraTeam to display the list of automation hosts:
Make sure that you have created an Automation Host for each computer that is going to run an automated test case. The name and description can be set to anything meaningful, but the Token field must be set to the same token that is specified in the RemoteLaunch application on that specific machine.
Once you have at least one Automation Host configured, go to Testing > Test Sets to create the test sets that will contain the automated test case:
Note: Unlike manual test cases, automated test cases must be executed within a test set -- they cannot be executed directly from the test case.
Create a new Test Set to hold the Badboy automated test cases and click on its hyperlink to display the test set details page:
You need to add at least one automated test case to the test set and then configure the following fields:
Automation Host -- This needs to be set to the name of the automation host that will be running the automated test set.
Planned Date -- The date and time that you want the scenario to begin. (Note that multiple test sets scheduled at the exact same time will be scheduled by Test Set ID order.)
Status -- This needs to be set to \"Not Started\" for RemoteLaunch to pick up the scheduled test set. When you change the Planned Date, the status automatically switches back to \"Not Started\"
Type -- This needs to be set to \"Automated\" for automated testing
If you have parameterized test cases inside the automated test set you can set their values in three different ways:
Test Set Parameter Values -- this lets you set the same value of a parameter for all the test cases in the test set:
Test Case Parameter Values -- this lets you set a specific value for a parameter for a particular test case in the test set:
You set these values, by right-clicking on a row and choosing \"Edit Parameters\":
Once you have set the various test set fields (as described above), the Remote Launch instances will periodically poll SpiraTeam for new test sets. Once they retrieve the new test set, they will add it to their list of test sets to execute. Once execution begins they will change the status of the test set to \"In Progress\", and once test execution is done, the status of the test set will change to either \"Completed\" -- the automation engine could be launched and the test has completed -- or \"Blocked\" -- RemoteLaunch was not able to start the automation engine.
If you want to immediately execute the test case on your local computer, instead of setting the \"Automation Host\", \"Status\" and \"Planned Date\" fields, you can instead click the [Execute] icon on the test set itself. This will cause RemoteLaunch on the local computer to immediately start executing the current test set.
In either case, once all the test cases in the test set have been completed, the status of the test set will switch to \"Completed\" and the individual test cases in the set will display a status based on the results of the Badboy test:
Passed -- The Badboy automated test ran successfully and all the test steps in the test script passed and no assertions were thrown.
Failed -- The Badboy automated test ran successfully, but at least one test step failed or at least one assertion failed.
Caution -- The Badboy automated test run successfully, but at least one warning was logged in one of the test steps.
Blocked -- The Badboy automated test did not run successfully or at least one timeout error was recorded.
If you receive the \"Blocked\" status for either the test set or the test cases you should open up the Windows Application Event Log on the computer running RemoteLaunch and look in the event log for error messages.
Note: While the tests are executing you will see browser windows launch as Badboy executes the appropriate tests.
Once the tests have completed, you can log back into SpiraTeam and see the execution status of your test cases. If you click on a Test Run that was generated by Badboy, you will see the following information:
This screen indicates the status of the test run that was reported back from Badboy together with any messages or other information. The Test Name indicates the name of the test inside Badboy and the execution status corresponds the matching status inside Badboy as illustrated below:
Badboy Status SpiraTeam Status Succeeded Passed Failure Failed Warning Caution Assertion Failed Timeout BlockedIn addition, the detailed test report from Badboy is below. It will contain messages such as:
Suite: Test Suite 1
==============================================
Test: Test 3
---------------------------------- ------------
12 played, 12 succeeded, 0 failures, 0 assertions, 0 warnings, 0 timeouts ---------------------------------- ------------
Step: Step 2
---------------------------------- ------------
12 played, 12 succeeded, 0 failures, 0 assertions, 0 warnings, 0 timeouts ---------------------------------- ------------
Congratulations... You are now able to run Badboy automated functional tests and have the results be recorded within SpiraTest / SpiraTeam.
"},{"location":"RemoteLaunch-User-Guide/Command-Line/","title":"Command-Line","text":"In addition to the various pre-built plug-ins for different test automation engines, there is a generic command-line engine available that lets RemoteLaunch execute an arbitrary command-line program, capture the console output and send the output back to SpiraTeam as the test results. This is useful when you want to be able to use SpiraTeam to manage the scheduling and execution of automated testing using an in-house tool or a third-party tool that Inflectra has not yet built a plug-in for.
This section describes how you can use SpiraTest / SpiraTeam (hereafter SpiraTeam) together with RemoteLaunch to schedule and remotely launch instances of a command-line application on different computers and have the \"testing\" results be transmitted back to SpiraTeam. This allows you to extend your SpiraTeam's test management capabilities to include automation
Note: This integration requires at least version 4.0 of SpiraTest/Team and RemoteLaunch.
"},{"location":"RemoteLaunch-User-Guide/Command-Line/#installing-the-command-line-engine","title":"Installing the Command-Line Engine","text":"This section assumes that you already have a working installation of SpiraTest or SpiraTeam and have installed RemoteLaunch on the various test automation hosts following the instructions in RemoteLaunch Guide. Once those prerequisites are in place, please follow these steps:
Download and extract the CommandLineAutomationEngine.zip file from the Inflectra website and locate the CommandLine.dll
Copy the file \"CommandLine.dll\" into the \"extensions\" sub-folder of the RemoteLaunch installation.
Log in to SpiraTeam as a system administrator and go into SpiraTeam main Administration page and click on the \"Test Automation\" link under Integration.
Click the \"Add\" button to enter the new test automation engine details page. The fields required are as follows:
Name: This is the short display name of the automation engine. It can be anything that is meaningful to your users.
Description: This is the long description of the automation engine. It can be anything that is meaningful to your users. (Optional)
Active: If checked, the engine is active and able to be used for any project.
Token: This needs to be the assigned unique token for the automation engine and is used to tell RemoteLaunch which engine to actually use for a given test case. For Command-Line this should be simply \"CommandLine\".
Once you have finished, click the \"Insert & Close\" button and you will be taken back to the Test Automation list page, with Command-Line listed as an available automation engine.
You may need to modify the Command-Line configuration for some of the specific automation hosts, by right-clicking on the RemoteLaunch icon in the system tray and choosing \"Configuration\". That will bring up the RemoteLaunch configuration page. The Command-Line engine adds its own tab to this page which allows you to configure how the Command-Line engine operates:
The following fields can be specified on this screen:
RunAs Administrator -- This normally should not be checked. However if your automation tool requires Windows UAC elevation to operate, you will need to select this option. We recommend initially trying your tool with the value unchecked. Then, if you get an error message \"requires elevation\" in the test results you will need to select the option.
Log Results -- Normally the command-line engine will capture the output results from the command-line and send the results back to SpiraTeam as the test result. When you are executing a tool that directly integrates with SpiraTeam (e.g. a NUnit test suite that is already integrated with SpiraTeam) you don't want two different results to be sent back. In such a scenario, deselecting this option will prevent the command-line engine from sending back its own test result.
Default Status -- This specifies the execution status that will be returned to SpiraTeam in the event that none of the regular expressions (Regex) specified match the results returned from the test application. By default, the system will return \"Passed\" if none of the other regular expressions match correctly.
Pass Regex -- This is the regular expression that is used to match a passed test result. By default the system will search for the phrase \"Pass\" in the test output and return a Passed status if the match is successful.
Fail Regex -- This is the regular expression that is used to match a failed test result. By default the system will search for the phrases \"Fail\", \"Error\" and \"Fatal\" in the test output and return a Fail status if any of the matches are successful.
Caution Regex -- This is the regular expression that is used to match a caution test result. By default the system will search for the phrases \"Warning\" and \"Caution\" in the test output and return a Caution status if any of the matches are successful.
Blocked Regex -- This is the regular expression that is used to match a blocked test result. By default the system will search for the phrase \"Blocked\" in the test output and return a Blocked status if the match is successful.
Test Regular Expressions -- This text box lets you enter in some sample text and see how the Command-Line extension would interpret it. Once you have entered in the text, click \"Test Regular Expression...\" and the system will display a popup message box letting you know what the outcome of such a test would be interpreted as:
This section describes the process for setting up a test case in SpiraTeam for automation and either linking it to an existing test script file or entering a test script directly into SpiraTeam.
"},{"location":"RemoteLaunch-User-Guide/Command-Line/#attaching-a-command-line-test-script","title":"Attaching a Command-Line Test Script","text":"First you need to display the list of test cases in SpiraTeam (by clicking Testing > Test Cases) and then add a new test case. Once you have added the new test case, click on it and select the \"Automation\" tab:
You need to enter the following fields:
Automation Engine - Choose the Command-Line Automation Engine that you created in the previous section from the drop-down list.
Script Type -- This should be set to Attached for this case
Filename -- This needs to consist of the following sections separated by a pipe (|) character:
The full path to the command-line tool. To make this easier across different machines, you can use several constants for standard Windows locations:
[MyDocuments] -- The user's \"My Documents\" folder. The user indicated is the user that ran RemoteLaunch.
[CommonDocuments] -- The Public Document's folder.
[DesktopDirectory] -- The user's Desktop folder. The user indicated is the user that ran RemoteLaunch.
[ProgramFiles] -- Translated to the Program Files directory. For 64-bit machines, it's the 64-bit directory.
[ProgramFilesX86] -- Translated to the 32-bit Program Files directory.
Any arguments for the command-line tool, with the filename specified as {filename}. This special token will be replaced by the actual filename of the test script when RemoteLaunch downloads it from SpiraTeam. In addition, you can use the following additional tokens for some of the special SpiraTeam ID values:
[TestCaseId] -- the ID of the test case
[TestSetId] -- the ID of the test set
[ReleaseId] -- the ID of the release (if specified)
[ProjectId] -- the ID of the project
An example filename would be: C:\\Temp\\TestApp.exe|-arg1 -arg2 \"-arg3={filename}\"|
Document Type -- If using SpiraTeam (not SpiraTest) you can choose which document type the automated test script will be categorized under.
Document Folder -- If using SpiraTeam (not SpiraTest) you can choose which document folder the automated test script will be stored in.
Version -- The version of the test script (1.0 is used if no value specified)
Test Script -- This needs to contain the complete test script in whatever language and syntax is being expected by the command-line application
If you would like to have SpiraTeam pass any parameter values to this test script (this will be discussed in more detail later) you can specify them by using the syntax ${parameterName} inside the test script.
Once you are happy with the values, click [Save] to update the test case. Now you are ready to schedule the automated test case for execution.
"},{"location":"RemoteLaunch-User-Guide/Command-Line/#linking-a-command-line-test-script","title":"Linking a Command-Line Test Script","text":"First you need to display the list of test cases in SpiraTeam (by clicking Testing > Test Cases) and then add a new test case. Once you have added the new test case, click on it and select the \"Automation\" tab:
You need to enter the following fields:
Automation Engine - Choose the Command-Line Automation Engine that you created in the previous section from the drop-down list.
Script Type -- This should be set to Linked for this case
Filename -- This needs to consist of the following sections separated by a pipe (|) character:
The full path to the command-line tool. To make this easier across different machines, you can use several constants for standard Windows locations:
[MyDocuments] -- The user's \"My Documents\" folder. The user indicated is the user that ran RemoteLaunch.
[CommonDocuments] -- The Public Document's folder.
[DesktopDirectory] -- The user's Desktop folder. The user indicated is the user that ran RemoteLaunch.
[ProgramFiles] -- Translated to the Program Files directory. For 64-bit machines, it's the 64-bit directory.
[ProgramFilesX86] -- Translated to the 32-bit Program Files directory.
Any arguments for the command-line tool, including the filepath of the test script file that the command-line tool will be executing. In addition, you can use the following additional tokens for some of the special SpiraTeam ID values:
[TestCaseId] -- the ID of the test case
[TestSetId] -- the ID of the test set
[ReleaseId] -- the ID of the release (if specified)
[ProjectId] -- the ID of the project
The mask for converting any parameter values from SpiraTeam into valid command line arguments. If parameters are not accepted by the command-line tool, you can leave this section out.
The mask can include any symbols together with \"name\" to refer to the parameter name and \"value\" to refer to the parameter value.
Example 1: If you want parameters to provided in the form: -param1=value1 --param2=value2 you would use the following mask: -name=value
Example 2: If you want parameters to provided in the form: /param1:value1 /param2:value2 you would use the following mask: /name:value
An example filename would be: C:\\Temp\\TestApp.exe|-arg1 -arg2|-name=value
Document Type -- If using SpiraTeam (not SpiraTest) you can choose which document type the automated test script will be categorized under.
Document Folder -- If using SpiraTeam (not SpiraTest) you can choose which document folder the automated test script will be stored in.
Version -- The version of the test script (1.0 is used if no value specified)
Test Script -- This is not used when you are using the linked test script option
Once you are happy with the values, click [Save] to update the test case. Now you are ready to schedule the automated test case for execution.
"},{"location":"RemoteLaunch-User-Guide/Command-Line/#using-parameterized-test-cases","title":"Using Parameterized Test Cases","text":"There is an advanced feature of SpiraTest/Team and RemoteLaunch that lets you pass parameters from SpiraTeam to your command-line automated testing tool. This is very useful if you want to have a data-driven test script that be executed multiple times with different parameter values.
To setup the automated test case for parameters, click on the \"Edit Parameters\" hyperlink above the \"Test Script\" box:
The name of the parameter ${login} needs to match the name of a parameter accepted by the command-line tool.
"},{"location":"RemoteLaunch-User-Guide/Command-Line/#executing-the-command-line-test-sets-from-spirateam","title":"Executing the Command-Line Test Sets from SpiraTeam","text":"There are two ways to execute automated test cases in SpiraTeam:
Schedule the test cases to be executed on a specific computer (local or remote) at a date/time in the future
Execute the test cases right now on the local computer.
We shall outline both of these two scenarios in this section. However first we need to setup the appropriate automation hosts and test sets in SpiraTeam:
"},{"location":"RemoteLaunch-User-Guide/Command-Line/#configuring-the-automation-hosts-and-test-sets","title":"Configuring the Automation Hosts and Test Sets","text":"Go to Testing > Automation Hosts in SpiraTeam to display the list of automation hosts:
Make sure that you have created an Automation Host for each computer that is going to run an automated test case. The name and description can be set to anything meaningful, but the Token field must be set to the same token that is specified in the RemoteLaunch application on that specific machine.
Once you have at least one Automation Host configured, go to Testing > Test Sets to create the test sets that will contain the automated test case:
Note: Unlike manual test cases, automated test cases must be executed within a test set -- they cannot be executed directly from the test case.
Create a new Test Set to hold the Command-Line automated test cases and click on its hyperlink to display the test set details page:
You need to add at least one automated test case to the test set and then configure the following fields:
Automation Host -- This needs to be set to the name of the automation host that will be running the automated test set.
Planned Date -- The date and time that you want the scenario to begin. (Note that multiple test sets scheduled at the exact same time will be scheduled by Test Set ID order.)
Status -- This needs to be set to \"Not Started\" for RemoteLaunch to pick up the scheduled test set. When you change the Planned Date, the status automatically switches back to \"Not Started\"
Type -- This needs to be set to \"Automated\" for automated testing
If you have parameterized test cases inside the automated test set you can set their values in three different ways:
Test Set Parameter Values -- this lets you set the same value of a parameter for all the test cases in the test set:
Test Case Parameter Values -- this lets you set a specific value for a parameter for a particular test case in the test set:
You set these values, by right-clicking on a row and choosing \"Edit Parameters\":
Once you have set the various test set fields (as described above), the Remote Launch instances will periodically poll SpiraTeam for new test sets. Once they retrieve the new test set, they will add it to their list of test sets to execute. Once execution begins they will change the status of the test set to \"In Progress\", and once test execution is done, the status of the test set will change to either \"Completed\" -- the automation engine could be launched and the test has completed -- or \"Blocked\" -- RemoteLaunch was not able to start the automation engine.
If you want to immediately execute the test case on your local computer, instead of setting the \"Automation Host\", \"Status\" and \"Planned Date\" fields, you can instead click the [Execute] icon on the test set itself. This will cause RemoteLaunch on the local computer to immediately start executing the current test set.
In either case, once all the test cases in the test set have been completed, the status of the test set will switch to \"Completed\" and the individual test cases in the set will display a status based on the results of the command-line test:
Passed -- The automated test ran successfully and the results output to the console did not include any of the phrases -- FAIL, ERROR, FATAL, WARNING, CAUTION
Failed -- The automated test ran successfully, but one of the phrases -- FAIL, ERROR, FATAL -- was included in the console output
Caution -- The automated test ran successfully, but one of the phrases -- WARNING, CAUTION -- was included in the console output
Blocked -- The automated test did not run successfully
If you receive the \"Blocked\" status for either the test set or the test cases you should open up the Windows Application Event Log on the computer running RemoteLaunch and look in the event log for error messages.
Note: While the tests are executing you may see application windows launch as the command-line tool server executes the appropriate tests.
Once the tests have completed, you can log back into SpiraTeam and see the execution status of your test cases. If you click on a Test Run that was generated by the command-line tool, you will see the following information:
This screen indicates the status of the test run that was reported back from command-line tool together with any messages or other information. The execution status will be set according to the rules described above, the Message field will contain the first line of console output and the large details box will contain the full console output from the command-line tool.
Congratulations... You are now able to run a custom command-line run tests and have the results be recorded within SpiraTest / SpiraTeam.
"},{"location":"RemoteLaunch-User-Guide/Eggplant/","title":"Eggplant DAI","text":"Eggplant Digital Automation Intelligence (DAI) is a functional test automation system. Eggplant uses a command-line tool to allow users to more easily triggering automated tests remotely. RemoteLaunch's dedicated Eggplant engine uses this command-line tool to run automated tests in Eggplant, once triggered for a SpiraPlan test set. RemoteLaunch's Eggplant engine reports the results of the output from Eggplant back to SpiraPlan as test run results.
This page describes how you can use SpiraTest, SpiraTeam, or SpiraPlan (hereafter SpiraPlan) together with RemoteLaunch to schedule and remotely launch Eggplant DAI tests and have the results transmitted back to SpiraPlan. This allows you to extend your SpiraPlan's test management capabilities to include automation.
Note: This integration requires at least: SpiraTest/Team v4.0, RemoteLaunch, and Eggplant DAI v6.2.
"},{"location":"RemoteLaunch-User-Guide/Eggplant/#installing-the-eggplant-engine","title":"Installing the Eggplant Engine","text":"This section assumes that you already have a working installation of SpiraPlan and of RemoteLaunch as described here. Once these prerequisites are in place, please follow these steps:
Click the \"Add\" button to enter the new test automation engine details page. The fields required are as follows:
You can modify the Eggplant DAI configuration for each of the specific automation hosts, by right-clicking on the RemoteLaunch icon in the system tray and choosing \"Configuration\". That will bring up the RemoteLaunch configuration page.
The Eggplant DAI engine adds its own tab to this page which allows you to configure how it operates:
The following fields can be specified on this screen:
This section describes the process for setting up a test case in SpiraPlan for automation and either linking it to a command that triggers Eggplant DAI remote execution.
"},{"location":"RemoteLaunch-User-Guide/Eggplant/#attaching-a-command-line-test-script","title":"Attaching a Command-Line Test Script","text":"First, you need to display the list of test cases in SpiraPlan (by clicking Testing > Test Cases) and then add a new test case. Once you have added the new test case, click on it and select the \"Automation\" tab:
You need to enter the following fields:
Filename: This needs to consist of the following sections separated by a pipe (|) character:
The full path to the Eggplant command-line runner tool. To make this easier across different machines, you can use several constants for standard Windows locations:
The Eggplant Client Secret number and the Eggplant Client Id, separated by a comma (,)
The Eggplant Test Configuration ID number to associate with this Spira Test Case
An example of filename would be: C:\\Users\\eggplant-runner-Windows-6.1.2-1.exe|umthdbvwiuy76bXStxzL,32584136987|https://mycompany.dai.eggplant.cloud|15d0d5e8-c3frt-8541-v5t9-d423760925f2
Document Type: If using SpiraPlan (not SpiraTest) you can choose which document type the automated test script will be categorized under.
Once you are happy with the values, click [Save] to update the test case. Now you are ready to schedule the automated test case for execution.
"},{"location":"RemoteLaunch-User-Guide/Eggplant/#executing-the-test-sets-from-spiraplan","title":"Executing the Test Sets from SpiraPlan","text":"There are two ways to execute automated test cases in SpiraPlan:
We shall outline both of these two scenarios in this section. However, first we need to setup the appropriate automation hosts and test sets in SpiraPlan:
"},{"location":"RemoteLaunch-User-Guide/Eggplant/#configuring-the-automation-hosts-and-test-sets","title":"Configuring the Automation Hosts and Test Sets","text":"Go to Testing > Automation Hosts in SpiraPlan to display the list of automation hosts:
Make sure that you have created an Automation Host for each computer that is going to run an automated test case. The name and description can be set to anything meaningful, but the Token field must be set to the same token that is specified in the RemoteLaunch application on that specific machine.
Once you have at least one Automation Host configured, go to Testing > Test Sets to create the test sets that will contain the automated test case.
Note: Unlike manual test cases, automated test cases must be executed within a test set -- they cannot be executed directly from the test case.
Create a new Test Set to hold the Eggplant automated test cases and click on its hyperlink to display the test set details page:
You need to add at least one automated test case to the test set and then configure the following fields:
Once you have set the various test set fields (as described above), the RemoteLaunch instances will periodically poll SpiraPlan for new test sets. Once they retrieve the new test set, they will add it to their list of test sets to execute. Once execution begins they will change the status of the test set to \"In Progress\", and once test execution is done, the status of the test set will change to either \"Completed\" -- the automation engine could be launched and the test has completed -- or \"Blocked\" -- RemoteLaunch was not able to start the automation engine. If you want to immediately execute the test case on your local computer, instead of setting the \"Automation Host\", \"Status\" and \"Planned Date\" fields, you can instead click the [Execute] icon on the test set itself. This will cause RemoteLaunch on the local computer to immediately start executing the current test set.
In either case, once all the test cases in the test set have been completed, the status of the test set will switch to \"Completed\" and the individual test cases in the set will display a status based on the results of the Eggplant test:
If you receive the \"Blocked\" status for either the test set or the test cases you should open up the Windows Application Event Log on the computer running RemoteLaunch and look in the event log for error messages.
Note: While the tests are executing you may see application windows launch as the command-line tool server executes the appropriate tests. Please do not close them.
Once the tests have been completed, you can log back into SpiraPlan and see the execution status of your test cases. If you click on a Test Run that was generated by the command-line tool, you will see the following information:
This screen indicates the status of the test run that was reported back from the engine together with any messages or other information. The execution status will be set according to the rules described above, the Message field will contain a weblink for the detailed online results at Eggplant and the large details box will contain the full console output from the Eggplant command-line tool.
Congratulations! You are now able to run the Eggplant automated tests and have the results recorded within SpiraTest / SpiraPlan.
"},{"location":"RemoteLaunch-User-Guide/FitNesse/","title":"FitNesse","text":"FitNesse is a lightweight, open-source automated software testing framework that uses web-based Wikis to define the inputs and expected results from different combinations of input values and then compare the results with what is actually generated during testing. For more details on FitNesse, please refer to the FitNesse website: http://fitnesse.org
This section describes how you can use SpiraTest / SpiraTeam (hereafter SpiraTeam) together with RemoteLaunch to schedule and remotely launch instances of FitNesse on different computers and have the testing results be transmitted back to SpiraTeam. This allows you to extend your SpiraTeam's test management capabilities to include automated FitNesse acceptance tests.
Note: This integration requires at least version 4.0 of SpiraTest/Team and RemoteLaunch.
"},{"location":"RemoteLaunch-User-Guide/FitNesse/#installing-the-fitnesse-engine","title":"Installing the FitNesse Engine","text":"This section assumes that you already have a working installation of SpiraTest or SpiraTeam and have installed RemoteLaunch on the various test automation hosts following the instructions in RemoteLaunch Guide. Once those prerequisites are in place, please follow these steps:
Download and extract the FitNesseEngine.zip file from the Inflectra website and c*opy the file \"FitNesseEngine.dll\" into the \"extensions\" sub-folder of the RemoteLaunch installation.*
You may also need to verify that you have the full Microsoft .NET Framework 4.0 installed since that is needed by the FitNesse engine. RemoteLaunch itself only needs the .NET 4.0 Client Profile, so make sure you have the .NET 4.0 Framework Extended entry listed in the Program & Features section of the Windows Control Panel.
Log in to SpiraTeam as a system administrator and go into SpiraTeam main Administration page and click on the \"Test Automation\" link under Integration.
Click the \"Add\" button to enter the new test automation engine details page. The fields required are as follows:
Name: This is the short display name of the automation engine. It can be anything that is meaningful to your users.
Description: This is the long description of the automation engine. It can be anything that is meaningful to your users. (Optional)
Active: If checked, the engine is active and able to be used for any project.
Token: This needs to be the assigned unique token for the automation engine and is used to tell RemoteLaunch which engine to actually use for a given test case. For FitNesse this should be simply FitNesse.
Once you have finished, click the \"Insert & Close\" button and you will be taken back to the Test Automation list page, with FitNesse listed as an available automation engine.
You can modify the FitNesse configuration for each of the specific automation hosts, by right-clicking on the RemoteLaunch icon in the system tray and choosing \"Configuration\". That will bring up the RemoteLaunch configuration page. The FitNesse engine adds its own tab to this page which allows you to configure how FitNesse operates:
The following fields can be specified on this screen:
Server Host -- This should be the base URL for accessing the installation of FitNesse. Each of the FitNesse test cases will be a URL relative to this base URL.
Server Port -- This should be set to the TCP port that the FitNesse web server uses for displaying the FitNesse wiki web pages.
FitNesse Timeout -- This allows you to extend the timeout for executing FitNesse tests. This is useful if you find that the FitNesse tests take a long time to execute and RemoteLaunch is aborting the execution before they are finished.
"},{"location":"RemoteLaunch-User-Guide/FitNesse/#setting-up-the-automated-test-cases","title":"Setting up the Automated Test Cases","text":"This section describes the process for setting up a test case in SpiraTeam for automation and linking it to an existing FitNesse test case wiki page. Note: The FitNesse automation engine only supports Linked test scripts in SpiraTeam (not Attached).
First you need to display the list of test cases in SpiraTeam (by clicking Testing > Test Cases) and then add a new test case. Once you have added the new test case, click on it and go to the \"Automation\" section located in the \"Overview\" tab:
You need to enter the following fields:
Automation Engine - Choose the FitNesse Automation Engine that you created in the previous section from the drop-down list.
Script Type -- This should be set to Linked for FitNesse tests.
Filename -- This needs to be the relative URL of the FitNesse test case. I.e. if the FitNesse URL is http://myserver/FitNesse.UserGuide.TwoMinuteExample and the base URL setup in RemoteLaunch is http://myserver then the \"filename\" would be just FitNesse.UserGuide.TwoMinuteExample.
Document Type -- You can choose which document type the automated test script will be categorized under.
Document Folder -- You can choose which document folder the automated test script will be stored in.
Version -- The version of the test script (1.0 is used if no value specified)
Test Script -- This is not used when you are using the linked test script option
Once you are happy with the values, click [Save] to update the test case. Now you are ready to schedule the automated test case for execution.
"},{"location":"RemoteLaunch-User-Guide/FitNesse/#using-parameterized-test-cases","title":"Using Parameterized Test Cases","text":"The FitNesse automation engine does not currently support the passing of parameter values from SpiraTeam to the FitNesse test.
"},{"location":"RemoteLaunch-User-Guide/FitNesse/#executing-the-fitnesse-test-sets-from-spirateam","title":"Executing the FitNesse Test Sets from SpiraTeam","text":"There are three ways to execute automated test cases in SpiraTeam:
Schedule the test cases to be executed on a specific computer (local or remote) at a date/time in the future
Execute the test cases right now on the local computer.
Execute the test cases from the command-line or a build script
We shall outline each of these three scenarios in this section. However first we need to setup the appropriate automation hosts and test sets in SpiraTeam:
"},{"location":"RemoteLaunch-User-Guide/FitNesse/#configuring-the-automation-hosts-and-test-sets","title":"Configuring the Automation Hosts and Test Sets","text":"Go to Testing > Automation Hosts in SpiraTeam to display the list of automation hosts:
Make sure that you have created an Automation Host for each computer that is going to run an automated test case. The name and description can be set to anything meaningful, but the Token field must be set to the same token that is specified in the RemoteLaunch application on that specific machine.
Once you have at least one Automation Host configured, go to Testing > Test Sets to create the test sets that will contain the automated test case:
Note: Unlike manual test cases, automated test cases must be executed within a test set -- they cannot be executed directly from the test case.
Create a new Test Set to hold the FitNesse automated test cases and click on its hyperlink to display the test set details page:
You need to add at least one automated test case to the test set and then configure the following fields:
Automation Host -- This needs to be set to the name of the automation host that will be running the automated test set.
Planned Date -- The date and time that you want the scenario to begin. (Note that multiple test sets scheduled at the exact same time will be scheduled by Test Set ID order.)
Status -- This needs to be set to \"Not Started\" for RemoteLaunch to pick up the scheduled test set. When you change the Planned Date, the status automatically switches back to \"Not Started\"
Type -- This needs to be set to \"Automated\" for automated testing
Once you have set the various test set fields (as described above), the Remote Launch instances will periodically poll SpiraTeam for new test sets. Once they retrieve the new test set, they will add it to their list of test sets to be executed. Once execution begins they will change the status of the test set to \"In Progress\", and once test execution is done, the status of the test set will change to either \"Completed\" -- the automation engine could be launched and the test has completed -- or \"Blocked\" -- RemoteLaunch was not able to start the automation engine.
If you want to immediately execute the test case on your local computer, instead of setting the \"Automation Host\", \"Status\" and \"Planned Date\" fields, you can instead click the [Execute] icon on the test set itself. This will cause RemoteLaunch on the local computer to immediately start executing the current test set.
In either case, once all the test cases in the test set have been completed, the status of the test set will switch to \"Completed\" and the individual test cases in the set will display a status based on the results of the FitNesse test:
Passed -- The FitNesse automated test ran successfully and all the test conditions in the test script passed
Failed -- The FitNesse automated test ran successfully, but at least one test condition in the test script failed.
Blocked -- The FitNesse automated test did not run successfully
If you receive the \"Blocked\" status for either the test set or the test cases you should open up the Windows Application Event Log on the computer running RemoteLaunch and look in the event log for error messages.
Note: While the tests are executing you may see command windows appear as the FitNesse server executes the appropriate tests.
Once the tests have completed, you can log back into SpiraTeam and see the execution status of your test cases. If you click on a Test Run that was generated by FitNesse, you will see the following information:
This screen indicates the status of the test run that was reported back from FitNesse together with any messages or other information. The execution status will be set to PASSED if all the FitNesse rows report back OK and all the tests passed. If any of the rows failed or the tests don't pass, the overall execution status will be listed as FAILED.
You can see a step-by-step record of what happened by scrolling down to the \"Test Steps\" section:
In addition, you can scroll down to the \"Console Output\" section to get the FitNesse specific information:
The Message field will contain a summary of the number of tests executed and the number of wrong results and exceptions. The large details box contains the full command execution log as reported back from FitNesse:
Congratulations... You are now able to run FitNesse automated acceptance tests and have the results be recorded within SpiraTest / SpiraTeam.
"},{"location":"RemoteLaunch-User-Guide/HP-UFT--QTP/","title":"HP UFT / QTP","text":"HP\u00ae QuickTest Professional\u00ae (hereafter QTP) is an automated functional test automation system that lets you record application operations and generate VBA test automation scripts that can be used to playback the test script against the test application.
HP\u00ae Unified Functional Testing\u00ae (hereafter UFT) is an updated version of QTP that also includes functionality for web service testing.
This section describes how you can use SpiraTest / SpiraTeam (hereafter SpiraTeam) together with RemoteLaunch to schedule and remotely launch instances of QTP and UFT on different computers and have the testing results be transmitted back to SpiraTeam. This allows you to extend your SpiraTeam's test management capabilities to include automated QTP and UFT tests.
Note: This integration requires at least version 3.0 of SpiraTest/Team and version 9.0 of Quick Test Professional. For accessing UFT, you'd need at least version 4.0 of SpiraTest/Team and version 11.0 of UFT.
"},{"location":"RemoteLaunch-User-Guide/HP-UFT--QTP/#installing-the-uftqtp-engine","title":"Installing the UFT/QTP Engine","text":"This section assumes that you already have a working installation of SpiraTest or SpiraTeam and have installed RemoteLaunch on the various test automation hosts following the instructions in RemoteLaunch Guide. Once those prerequisites are in place, please follow these steps:
Download and extract the QuickTestProAutomationEngine.zip file from the Inflectra website and locate the appropriate QuickTestProX.dll or UftX.dll for the version of QTP or UFT that you are using.
If you don't see the version listed, just use the nearest version that is lower than your current version.
Copy the file \"QuickTestProX.dll\" or \"UftX.dll\" (where X is the appropriate version) into the \"extensions\" sub-folder of the RemoteLaunch installation.
Log in to SpiraTeam as a system administrator and go into SpiraTeam main Administration page and click on the \"Test Automation\" link under Integration.
Click the \"Add\" button to enter the new test automation engine details page. The fields required are as follows:
This section describes the process for setting up a test case in SpiraTeam for automation and linking it to an automated QTP or UFT test script.
First you need to display the list of test cases in SpiraTeam (by clicking Testing > Test Cases) and then add a new test case. Once you have added the new test case, click on it and select the \"Overview\" tab and scroll down to the 'Automation' section:
You need to enter the following fields:
Automation Engine - Choose the QTP/UFT Automation Engine that you created in the previous section from the drop-down list.
Script Type -- This should be set to Linked as the integration with QTP/UFT only supports referencing QTP/UFT test script folder paths and not physically uploading the test scripts into SpiraTeam.
Filename -- This needs to be the full path to the QTP/UFT test script folder (i.e. the folder that you open in QTP/UFT to run the test). To make this easier across different machines, you can use several constants for standard Windows locations (see example in screenshot):
[MyDocuments] -- The user's \"My Documents\" folder. The user indicated is the user that ran RemoteLaunch.
[CommonDocuments] -- The Public Document's folder.
[DesktopDirectory] -- The user's Desktop folder. The user indicated is the user that ran RemoteLaunch.
[ProgramFiles] -- Translated to the Program Files directory. For 64-bit machines, it's the 64-bit directory.
[ProgramFilesX86] -- Translated to the 32-bit Program Files directory.
Document Type -- If using SpiraTeam (not SpiraTest) you can choose which document type the automated test script will be categorized under.
Document Folder -- If using SpiraTeam (not SpiraTest) you can choose which document folder the automated test script will be stored in.
Version -- The version of the test script (1.0 is used if no value specified)
Test Script -- This is not used with the QTP/UFT Engine since it only supports linked test scripts.
Once you are happy with the values, click [Save] to update the test case. Now you are ready to schedule the automated test case for execution.
"},{"location":"RemoteLaunch-User-Guide/HP-UFT--QTP/#using-parameterized-test-cases","title":"Using Parameterized Test Cases","text":"There is an advanced feature of SpiraTest/Team and RemoteLaunch that lets you pass parameters from SpiraTeam to your QTP/UFT automated test script. This is very useful if you have a data-driven QTP/UFT test script that accepts input parameters from an external data source.
To setup the automated test case for parameters, click on the \"Test Steps\" tab and click on \"Edit Parameters\":
The name of the parameter ${login} needs to match the name of the input parameter defined within the QTP/UFT script in its input parameters configuration.
"},{"location":"RemoteLaunch-User-Guide/HP-UFT--QTP/#executing-the-qtpuft-test-sets-from-spirateam","title":"Executing the QTP/UFT Test Sets from SpiraTeam","text":"There are two ways to execute automated test cases in SpiraTeam:
Schedule the test cases to be executed on a specific computer (local or remote) at a date/time in the future
Execute the test cases right now on the local computer.
We shall outline both of these two scenarios in this section. However first we need to setup the appropriate automation hosts and test sets in SpiraTeam:
"},{"location":"RemoteLaunch-User-Guide/HP-UFT--QTP/#configuring-the-automation-hosts-and-test-sets","title":"Configuring the Automation Hosts and Test Sets","text":"Go to Testing > Automation Hosts in SpiraTeam to display the list of automation hosts:
Make sure that you have created an Automation Host for each computer that is going to run an automated test case. The name and description can be set to anything meaningful, but the Token field must be set to the same token that is specified in the RemoteLaunch application on that specific machine.
Once you have at least one Automation Host configured, go to Testing > Test Sets to create the test sets that will contain the automated test case:
Note: Unlike manual test cases, automated test cases must be executed within a test set -- they cannot be executed directly from the test case.
Create a new Test Set to hold the QTP/UFT automated test cases and click on its hyperlink to display the test set details page.
You need to add at least one automated test case to the test set:
Then configure the following fields:
Automation Host -- This needs to be set to the name of the automation host that will be running the automated test set.
Planned Date -- The date and time that you want the scenario to begin. (Note that multiple test sets scheduled at the exact same time will be scheduled by Test Set ID order.)
Status -- This needs to be set to \"Not Started\" for RemoteLaunch to pick up the scheduled test set. When you change the Planned Date, the status automatically switches back to \"Not Started\"
Type -- This needs to be set to \"Automated\" for automated testing
If you have parameterized test cases inside the automated test set you can set their values in three different ways:
Test Set Parameter Values -- this lets you set the same value of a parameter for all the test cases in the test set:
Test Case Parameter Values -- this lets you set a specific value for a parameter for a particular test case in the test set:
You set these values, by right-clicking on a row and choosing \"Edit Parameters\":
Once you have set the various test set fields (as described above), the Remote Launch instances will periodically poll SpiraTeam for new test sets. Once they retrieve the new test set, they will add it to their list of test sets to execute. Once execution begins they will change the status of the test set to \"In Progress\", and once test execution is done, the status of the test set will change to either \"Completed\" -- the automation engine could be launched and the test has completed -- or \"Blocked\" -- RemoteLaunch was not able to start the automation engine.
If you want to immediately execute the test case on your local computer, instead of setting the \"Automation Host\", \"Status\" and \"Planned Date\" fields, you can instead click the [Execute] icon on the test set itself. This will cause RemoteLaunch on the local computer to immediately start executing the current test set.
In either case, once all the test cases in the test set have been completed, the status of the test set will switch to \"Completed\" and the individual test cases in the set will display a status based on the results of the QTP/UFT test:
Passed -- The QTP/UFT automated test ran successfully and all the test conditions in the test script passed
Failed -- The QTP/UFT automated test ran successfully, but at least one test condition in the test script failed.
Blocked -- The QTP/UFT automated test did not run successfully
If you receive the \"Blocked\" status for either the test set or the test cases you should open up the Windows Application Event Log on the computer running RemoteLaunch and look in the event log for error messages.
Note: While the tests are executing you may see browser or application windows launch as QuickTest Pro (QTP) or Unified Functional Testing (UFT) executes the appropriate tests.
Once the tests have completed, you can log back into SpiraTeam and see the execution status of your test cases. If you click on a Test Run that was generated by QTP/UFT, you will see the following information:
This screen indicates the status of the test run that was reported back from QTP/UFT together with any messages or other information. The Test Name indicates the name of the test inside QTP/UFT, and the execution status corresponds the matching status inside QTP/UFT as illustrated below:
QTP/UFT Status SpiraTeam Status Passed Passed Failed Failed Warning Caution Stopped Blocked Not Applicable N/A (Any other status) Not RunIn addition, the detailed test report from QTP/UFT is below. It will contain messages such as:
QuickTest Professional
Test: Test1
Results Name: Res21
Run Started: 10/22/2010 - 11:49:06
Run Ended: 10/22/2010 - 11:49:10
Summary Results
======= =======
Passed: 0
Failed: 0
Warnings: 0
Detailed Results
======= =======
Iteration: 1
=============
Action: Log In To Flight
=============
Step: Login: Dialog
Step: Agent Name:.SetText: \"Bobba Fett\"
Step: Agent Name:.Type: \"<__MicTab>\"
Step: Password:.SetSecureText: \"4cc08e88683135b35bb8a7dab8442c69b8441f3e\"
Step: OK.Click:
Step: Flight Reservations: Dialog
Step: OK.Click:
Congratulations... You are now able to run QTP/UFT automated functional tests and have the results be recorded within SpiraTest / SpiraTeam.
"},{"location":"RemoteLaunch-User-Guide/JMeter/","title":"JMeter","text":"Apache JMeter is a free, open source Java desktop application designed to load test functional behavior and measure performance. It was originally designed for testing Web Applications but has since expanded to other test functions.
This section describes how you can use SpiraTest / SpiraTeam (hereafter SpiraTeam) together with RemoteLaunch to schedule and remotely launch instances of JMeter on different computers and have the testing results be transmitted back to SpiraTeam. This allows you to extend your SpiraTeam's test management capabilities to include automated JMeter performance tests.
Note: This integration requires at least version 3.0 of Spira (SpiraTest, SpiraTeam or SpiraPlan) and version 2.5 of JMeter.
"},{"location":"RemoteLaunch-User-Guide/JMeter/#installing-the-jmeter-engine","title":"Installing the JMeter Engine","text":"This section assumes that you already have a working installation of SpiraTest or SpiraTeam and have installed RemoteLaunch on the various test automation hosts following the instructions in RemoteLaunch Guide. Once those prerequisites are in place, please follow these steps:
Download and extract the JMeterEngine.zip file from the Inflectra website and locate the JMeter2.dll.
Copy the file JMeter2.dll into the extensions sub-folder of your RemoteLaunch installation.
Log in to SpiraTeam as a system administrator and go into SpiraTeam main Administration page and click on the \"Test Automation\" link under Integration.
Click the \"Add\" button to enter the new test automation engine details page. The fields required are as follows:
Name: This is the short display name of the automation engine. It can be anything that is meaningful to your users.
Description: This is the long description of the automation engine. It can be anything that is meaningful to your users. (Optional)
Active: If checked, the engine is active and able to be used for any project.
Token: This needs to be the assigned unique token for the automation engine and is used to tell RemoteLaunch which engine to actually use for a given test case. For JMeter this should be JMeter2 as illustrated in the image.
Once you have finished, click the Save button and you will be taken back to the Test Automation list page, with JMeter listed as an available automation engine.
Next, you will need to modify the JMeter configuration for each of the specific automation hosts, by right-clicking on the RemoteLaunch icon in the system tray and choosing \"Configuration\". That will bring up the RemoteLaunch configuration page.
The JMeter 2.x engine adds its own tab to this page which allows you to configure how JMeter operates:
The following fields can be specified on this screen:
JMeter Location -- This should point to the location on the host computer where JMeter is installed. You can click on the browse button and navigate to the location of the JMeter.bat file.
Trace Logging -- When selected, this will log additional trace and debugging information to the Windows Event Log. This should not be selected in a production environment.
"},{"location":"RemoteLaunch-User-Guide/JMeter/#ensuring-jmeter-is-logging-in-xml","title":"Ensuring JMeter is logging in XML","text":"By default, JMeter will log its output in CSV format. This format is not readable by RemoteLaunch, so you will need to update JMeter to log in XML format.
To make this change, locate the following file - jmeter.properties:
Open up this file and locate the following line:
# legitimate values: xml, csv, db. Only xml and csv are currently supported.\n # jmeter.save.saveservice.output_format=csv\nChange this to be:
# legitimate values: xml, csv, db. Only xml and csv are currently supported.\n jmeter.save.saveservice.output_format=xml\nThen save the jmeter.properties file.
"},{"location":"RemoteLaunch-User-Guide/JMeter/#setting-up-the-automated-test-cases","title":"Setting up the Automated Test Cases","text":"This section describes the process for setting up a test case in SpiraTeam for automation and linking it to an automated JMeter test script.
First you need to display the list of test cases in SpiraTeam (by clicking Testing > Test Cases) and then add a new test case. Once you have added the new test case, click on it and select the \"Automation\" tab:
You need to enter the following fields:
Automation Engine - Choose the JMeter Automation Engine that you created in the previous section from the drop-down list.
Script Type -- This should be set to Linked as the integration with JMeter only supports referencing JMeter test script files and not physically uploading the test scripts into SpiraTeam.
Filename -- This consists of the following elements:
The full path to the JMeter test script. To make this easier across different machines, you can use several constants for standard Windows locations (see example in screenshot):
[MyDocuments] -- The user's \"My Documents\" folder. The user indicated is the user that ran RemoteLaunch.
[CommonDocuments] -- The Public Document's folder.
[DesktopDirectory] -- The user's Desktop folder. The user indicated is the user that ran RemoteLaunch.
[ProgramFiles] -- Translated to the Program Files directory. For 64-bit machines, it's the 64-bit directory.
[ProgramFilesX86] -- Translated to the 32-bit Program Files directory.
Optionally you can include JMeter command-line arguments by separating them with a pipe (|) character.
Examples of Filenames you can enter in SpiraTeam include:
[MyDocuments]JMeter\\JMeter-SampleScript.jmx
[MyDocuments]JMeter\\JMeter-SampleScript.jmx|-P 81
[MyDocuments]JMeter\\JMeter-SampleScript.jmx|-P 81 -H 192.168.117.25
Document Type -- This allows you to choose which document type the automated test script will be categorized under.
Document Folder --This allows you to choose which document folder the automated test script will be stored in.
Version -- The version of the test script (1.0 is used if no value specified)
Test Script -- This is not used with the JMeter Engine since it only supports linked test scripts.
Once you are happy with the values, click [Save] to update the test case. Now you are ready to schedule the automated test case for execution.
"},{"location":"RemoteLaunch-User-Guide/JMeter/#using-parameterized-test-cases","title":"Using Parameterized Test Cases","text":"There is an advanced feature of SpiraTest/Team and RemoteLaunch that lets you pass parameters from SpiraTeam to your JMeter automated test script. This is very useful if you have a data-driven JMeter test script that expects specific JMeter properties to be passed to the test script.
To setup the automated test case for parameters, click on the \"Test Steps\" tab and click on \"Edit Parameters\":
The name of the parameter ${login} needs to match the name of the property defined within the JMeter script.
"},{"location":"RemoteLaunch-User-Guide/JMeter/#executing-the-jmeter-test-sets-from-spirateam","title":"Executing the JMeter Test Sets from SpiraTeam","text":"There are two ways to execute automated test cases in SpiraTeam:
Schedule the test cases to be executed on a specific computer (local or remote) at a date/time in the future
Execute the test cases right now on the local computer.
We shall outline both of these two scenarios in this section. However first we need to setup the appropriate automation hosts and test sets in SpiraTeam:
"},{"location":"RemoteLaunch-User-Guide/JMeter/#configuring-the-automation-hosts-and-test-sets","title":"Configuring the Automation Hosts and Test Sets","text":"Go to Testing > Automation Hosts in SpiraTeam to display the list of automation hosts:
Make sure that you have created an Automation Host for each computer that is going to run an automated test case. The name and description can be set to anything meaningful, but the Token field must be set to the same token that is specified in the RemoteLaunch application on that specific machine.
Once you have at least one Automation Host configured, go to Testing > Test Sets to create the test sets that will contain the automated test case:
Note: Unlike manual test cases, automated test cases must be executed within a test set -- they cannot be executed directly from the test case.
Create a new Test Set to hold the JMeter automated test cases and click on its hyperlink to display the test set details page:
You need to add at least one automated test case to the test set and then configure the following fields:
Automation Host -- This needs to be set to the name of the automation host that will be running the automated test set.
Planned Date -- The date and time that you want the scenario to begin. (Note that multiple test sets scheduled at the exact same time will be scheduled by Test Set ID order.)
Status -- This needs to be set to \"Not Started\" for RemoteLaunch to pick up the scheduled test set. When you change the Planned Date, the status automatically switches back to \"Not Started\"
Type -- This needs to be set to \"Automated\" for automated testing
If you have parameterized test cases inside the automated test set you can set their values in three different ways:
Test Set Parameter Values -- this lets you set the same value of a parameter for all the test cases in the test set:
Test Case Parameter Values -- this lets you set a specific value for a parameter for a particular test case in the test set:
You set these values, by right-clicking on a row and choosing \"Edit Parameters\":
Once you have set the various test set fields (as described above), the Remote Launch instances will periodically poll SpiraTeam for new test sets. Once they retrieve the new test set, they will add it to their list of test sets to be executed. Once execution begins they will change the status of the test set to \"In Progress\", and once test execution is done, the status of the test set will change to either \"Completed\" -- the automation engine could be launched and the test has completed -- or \"Blocked\" -- RemoteLaunch was not able to start the automation engine.
If you want to immediately execute the test case on your local computer, instead of setting the \"Automation Host\", \"Status\" and \"Planned Date\" fields, you can instead click the [Execute] icon on the test set itself. This will cause RemoteLaunch on the local computer to immediately start executing the current test set.
In either case, once all the test cases in the test set have been completed, the status of the test set will switch to \"Completed\" and the individual test cases in the set will display a status based on the results of the JMeter test:
Passed -- The JMeter automated test ran successfully and no failures or errors were logged.
Failed -- The JMeter automated test ran successfully, but at least one error or failure was logged.
Blocked -- The JMeter automated test did not run successfully.
If you receive the \"Blocked\" status for either the test set or the test cases you should open up the Windows Application Event Log on the computer running RemoteLaunch and look in the event log for error messages.
Note: While the tests are executing you will see a Windows command prompt open as JMeter executes the appropriate tests.
Once the tests have completed, you can log back into SpiraTeam and see the execution status of your test cases. If you click on a Test Run that was generated by JMeter, you will see the following information:
This screen indicates the status of the test run that was reported back from JMeter together with any messages or other information. The Test Name indicates the name of the test inside JMeter and the execution status corresponds the rules described above.
In addition, the detailed test report from JMeter is below. It will contain messages such as:
Response Assertion (http://www.inflectra.com/): failure=true, error=false, message='Test failed: text expected to contain /(?i)Purchase Our Products Online/' Response Assertion (http://www.inflectra.com/SpiraTest/Default.aspx): failure=true, error=false, message='Test failed: text expected to contain /(?i)Purchase Our Products Online/' Response Assertion (http://www.inflectra.com/Purchase/Default.aspx): failure=false, error=false, message='' Response Assertion (https://www.inflectra.com/Purchase/Default.aspx): failure=false, error=false, message=''
Congratulations... You are now able to run JMeter automated functional tests and have the results be recorded within SpiraTest, SpiraTeam, and SpiraPlan.
"},{"location":"RemoteLaunch-User-Guide/LoadRunner/","title":"LoadRunner","text":"HP\u00ae LoadRunner is a load testing system that lets you record application performance by a number of 'virtual users'.
This section covers installing and using the Engine to report back statistics of run scenarios.
Note: This integration requires at least version 3.0 of SpiraTest/Team and version 11 of LoadRunner. The extension has not been tested on previous versions of LoadRunner due to lack of availability of previous released versions.
"},{"location":"RemoteLaunch-User-Guide/LoadRunner/#installing-the-loadrunner11-engine","title":"Installing the LoadRunner11 Engine","text":"This section assumes that you already have a working installation of SpiraTest or SpiraTeam and have installed RemoteLaunch on the various test automation hosts following the instructions in RemoteLaunch Guide. Once those prerequisites are in place, please follow these steps:
Download and extract the LoadRunner11Engine.zip file from the Inflectra website.
Copy the files in the ZIP file into the \"extensions\" sub-folder of the RemoteLaunch installation.
Log in to SpiraTeam as a system administrator and go into SpiraTeam main Administration page and click on the \"Test Automation\" link under Integration.
Click the \"Add\" button to enter the new test automation engine details page. The fields required are as follows:
Name: This is the short display name of the automation engine. It can be anything that is meaningful to your users, and will be displayed in the dropdown when the user selects the Tester.
Description: This is the long description of the automation engine. It can be anything that is meaningful to your users. (Optional)
Active: If checked, the engine is active and able to be used for any project.
Token: This needs to be the assigned unique token for the automation engine and is used to tell RemoteLaunch which engine to actually use for a given test case. For LoadRunner, it needs to be \"LoadRunner11\".
Once you have finished, click the \"Insert & Close\" button and you will be taken back to the Test Automation list page, with LoadRunner listed as an available automation engine.
This section describes the process for setting up a test case in SpiraTeam for automation and linking it to a Load Runner Scenario.
First you need to display the list of test cases in SpiraTeam (by clicking Testing > Test Cases) and then add a new test case. Once you have added the new test case, click on it and select the \"Automation\" tab:
You need to enter the following fields:
Automation Engine - Choose the LoadRunner Automation Engine that you created in the previous section from the drop-down list.
Script Type -- For LoadRunner, all scenarios must be stored on the local testing machine so 'Linked' must be selected. If you select 'Attached', when the scenario is attempted to be executed it will be marked as blocked and skipped.
Filename -- This needs to be the full path to the LoadRunner Scenario (*.lrs) file. Certain tokens are allowed to be able to specify common locations across different operating systems. Note that the tokens are case-sensitive, and there are no spaces in them. A list of tokens are:
[MyDocuments] -- The user's \"My Documents\" folder. The user indicated is the user that ran RemoteLaunch.
[CommonDocuments] -- The Public Document's folder.
[DesktopDirectory] -- The user's Desktop folder. The user indicated is the user that ran RemoteLaunch.
[ProgramFiles] -- Translated to the Program Files directory. For 64-bit machines, it's the 64-bit directory.
[ProgramFilesX86] -- Translated to the 32-bit Program Files directory.
Document Type -- If using SpiraTeam (not SpiraTest) you can choose which document type the automated scenario will be categorized under.
Document Folder -- If using SpiraTeam (not SpiraTest) you can choose which document folder the automated scenario will be stored in.
Version -- The version of the scenario (1.0 is used if no value specified)
Test Script -- Not used.
Once you are happy with the values, click [Save] to update the test case. Now you are ready to schedule the automated test case for execution.
"},{"location":"RemoteLaunch-User-Guide/LoadRunner/#using-parameterized-test-cases","title":"Using Parameterized Test Cases","text":"There is an advanced feature of SpiraTest/Team and RemoteLaunch that lets you pass parameters from SpiraTeam to your LoadRunner scenario. This is very useful if you have a data-driven LoadRunner scenario that has custom parameters used that you would like to change based on the test.
To setup the automated test case for parameters, click on the \"Test Steps\" tab and click on \"Edit Parameters\":
The name of the parameter ${login} needs to match the name of the custom parameter defined in the LoadRunner scenario. Invalid parameters will be silently ignored by the LoadRunner engine. Parameters must have a unique name.
"},{"location":"RemoteLaunch-User-Guide/LoadRunner/#executing-the-loadrunner-scenario-from-spirateam","title":"Executing the LoadRunner Scenario from SpiraTeam","text":"There are two ways to execute a scenario in SpiraTeam:
Schedule the test cases to be executed on a specific computer (local or remote) at a date/time in the future
Execute the test cases right now on the local computer.
We shall outline both of these two scenarios in this section. However first we need to setup the appropriate automation hosts and test sets in SpiraTeam:
"},{"location":"RemoteLaunch-User-Guide/LoadRunner/#configuring-the-automation-hosts-and-test-sets","title":"Configuring the Automation Hosts and Test Sets","text":"Go to Testing > Automation Hosts in SpiraTeam to display the list of automation hosts:
Make sure that you have created an Automation Host for each computer that is going to run an automated test case. The name and description can be set to anything meaningful, but the Token field must be set to the same token that is specified as the Host name in the RemoteLaunch application on that specific machine.
Once you have at least one Automation Host configured, go to Testing > Test Sets to create the test sets that will contain the automated test case:
Note: Unlike manual test cases, automated test cases must be executed within a test set -- they cannot be executed directly from the test case.
Create a new Test Set to hold the LoadRunner test cases and click on its hyperlink to display the test set details page:
You need to add at least one automated test case to the test set and then configure the following fields:
Automation Host -- This needs to be set to the name of the automation host that will be running the automated test set.
Planned Date -- The date and time that you want the scenario to begin. (Note that multiple test sets scheduled at the exact same time will be scheduled by Test Set ID order.)
Status -- This needs to be set to \"Not Started\" for RemoteLaunch to pick up the scheduled test set. When you change the Planned Date, the status automatically switches back to \"Not Started\"
Type -- This needs to be set to \"Automated\" for automated testing
If you have parameterized test cases inside the automated test set you can set their values in three different ways:
Test Set Parameter Values -- this lets you set the same value of a parameter for all the test cases in the test set:
Test Case Parameter Values -- this lets you set a specific value for a parameter for a particular test case in the test set:
You set these values, by right-clicking on a row and choosing \"Edit Parameters\":
Once you have set the various test set fields (as described above), the Remote Launch instances will periodically poll SpiraTeam for new test sets. Once they retrieve the new test set, they will add it to their list of test sets to be executed. Once execution begins they will change the status of the test set to \"In Progress\", and once test execution is done, the status of the test set will change to either \"Completed\" -- the automation engine could be launched and the test has completed -- or \"Blocked\" -- RemoteLaunch was not able to start the automation engine.
If you want to immediately execute the test case on your local computer, instead of setting the \"Automation Host\", \"Status\" and \"Planned Date\" fields, you can instead click the [Execute] icon on the test set itself. This will cause RemoteLaunch on the local computer to immediately start executing the current test set.
In either case, once all the test cases in the test set have been completed, the status of the test set will switch to \"Completed\" and the individual test cases in the set will display a status based on the results of the LoadRunner execution:
Passed -- The Scenario ran and reported no error messages. Warning, Debug, and Informational messages may have been logged, however.
Failed -- The Scenario ran and at least one error message was reported.
Blocked -- There was an error with the Test Set or LoadRunner application.
If you receive the \"Blocked\" status for either the test set or the test cases you should open up the Windows Application Event Log on the computer running RemoteLaunch and look in the event log for error messages.
Note: While the tests are executing you may see browser or application windows launch as LoadRunner runs the scenario and connects VUsers to their tasks.
Once the tests have completed, you can log back into SpiraTeam and see the execution status of your test cases. If you click on a Test Run that was generated by LoadRunner, you will see the following information:
This screen indicates the status of the scenario that was reported back from LoadRunner together with any messages or other information. Because LoadRunner only reports statistics on the scenarios that was run, the test set will always be marked as passed -- regardless of how long it took, unless there were errors reported. If any errors are reported, the test will be marked as Failed.
The Message of the test will report the duration the scenario took, along with the count of VUsers that reported an error, the number that reported a pass, and the hits per minute on the application.
A more detailed report will be included in the test run's details -- the information above, and then any added Execution Messages and messages logged by the script in time order.
Note: LoadRunner's engine is very basic at this stage. If you have issues with a scenario not reporting or executing properly, please let Inflectra's support team know.
"},{"location":"RemoteLaunch-User-Guide/NeoLoad/","title":"NeoLoad","text":"Neotys NeoLoad is a performance and load testing system that lets you record application performance by a number of 'virtual users' and measure the performance against specified Service Level Agreement (SLA) metrics for the application. When you use NeoLoad with SpiraTest you can report back pass/fail/caution by comparing the actual results against the specified SLA metrics.
This section covers installing and using the Engine to report back statistics of run scenarios as well as the results of the test compared to the required SLAs.
Note: This integration requires at least version 4.0 of SpiraTest/Team and has been tested against version 5.0 of NeoLoad.
"},{"location":"RemoteLaunch-User-Guide/NeoLoad/#installing-the-neoload-engine","title":"Installing the NeoLoad Engine","text":"This section assumes that you already have a working installation of SpiraTest or SpiraTeam and have installed RemoteLaunch on the various test automation hosts following the instructions in RemoteLaunch Guide. Once those prerequisites are in place, please follow these steps:
Download and extract the NeoLoadEngine.zip file from the Inflectra website.
Copy the files in the ZIP file into the \"extensions\" sub-folder of the RemoteLaunch installation.
Log in to SpiraTeam as a system administrator and go into SpiraTeam main Administration page and click on the \"Test Automation\" link under Integration.
Click the \"Add\" button to enter the new test automation engine details page. The fields required are as follows:
Name: This is the short display name of the automation engine. It can be anything that is meaningful to your users, and will be displayed in the dropdown when the user selects the Tester.
Description: This is the long description of the automation engine. It can be anything that is meaningful to your users. (Optional)
Active: If checked, the engine is active and able to be used for any project.
Token: This needs to be the assigned unique token for the automation engine and is used to tell RemoteLaunch which engine to actually use for a given test case. For NeoLoad, it needs to be simply \"NeoLoad\".
Once you have finished, click the \"Insert & Close\" button and you will be taken back to the Test Automation list page, with NeoLoad listed as an available automation engine.
"},{"location":"RemoteLaunch-User-Guide/NeoLoad/#neoload-remotelaunch-settings","title":"NeoLoad RemoteLaunch Settings","text":"You will need to modify the NeoLoad configuration for each of the specific automation hosts, by right-clicking on the RemoteLaunch icon in the system tray and choosing \"Configuration\". That will bring up the RemoteLaunch configuration page. The NeoLoad engine adds its own tab to this page which allows you to configure how NeoLoad operates:
The following fields can be specified on this screen:
NeoLoad Location -- This should be folder containing the \"NeoLoadCmd.exe\" executable that will be used to actually run the automated tests.
Attach PDF Report -- NeoLoad has a built-in report generator that can create detailed Acrobat (PDF) format reports. Enabling this option will attach these reports to the test runs recorded in SpiraTeam.
Run as Administrator -- Sometimes NeoLoad needs to be run as a Windows elevated process, in which case, choose the \"Run as Administrator\" option.
"},{"location":"RemoteLaunch-User-Guide/NeoLoad/#setting-up-the-automated-test-cases","title":"Setting up the Automated Test Cases","text":"This section describes the process for setting up a test case in SpiraTeam for automation and linking it to a NeoLoad project and scenario.
First you need to display the list of test cases in SpiraTeam (by clicking Testing > Test Cases) and then add a new test case. Once you have added the new test case, click on it and go to the \"Automation\" section in the main \"Overview\" tab:
You need to enter the following fields:
Automation Engine - Choose the NeoLoad Automation Engine that you created in the previous section from the drop-down list.
Script Type -- For NeoLoad, all scenarios must be stored on the local testing machine so 'Linked' must be selected. If you select 'Attached', when the scenario is attempted to be executed it will be marked as blocked and skipped.
Filename -- This needs to be the full path to the NeoLoad project file (*.nlp) file followed by the name of the NeoLoad scenario. The two components need to be separated by a pipe (|) character. Certain tokens are allowed to be able to specify common locations across different operating systems. Note that the tokens are case-sensitive, and there are no spaces in them. A list of tokens are:
[MyDocuments] -- The user's \"My Documents\" folder. The user indicated is the user that ran RemoteLaunch.
[CommonDocuments] -- The Public Document's folder.
[DesktopDirectory] -- The user's Desktop folder. The user indicated is the user that ran RemoteLaunch.
[ProgramFiles] -- Translated to the Program Files directory. For 64-bit machines, it's the 64-bit directory.
[ProgramFilesX86] -- Translated to the 32-bit Program Files directory.
Document Type -- You can choose which document type the automated scenario will be categorized under.
Document Folder -- You can choose which document folder the automated scenario will be stored in.
Version -- The version of the scenario (1.0 is used if no value specified)
Test Script -- Not used.
Once you are happy with the values, click [Save] to update the test case. Now you are ready to schedule the automated test case for execution.
"},{"location":"RemoteLaunch-User-Guide/NeoLoad/#using-parameterized-test-cases","title":"Using Parameterized Test Cases","text":"Currently the NeoLoad automation engine does not support the passing of parameter values from SpiraTeam to NeoLoad.
"},{"location":"RemoteLaunch-User-Guide/NeoLoad/#executing-the-neoload-scenario-from-spirateam","title":"Executing the NeoLoad Scenario from SpiraTeam","text":"There are three ways to execute automated test cases in SpiraTeam:
Schedule the test cases to be executed on a specific computer (local or remote) at a date/time in the future
Execute the test cases right now on the local computer.
Execute the test cases from the command-line or a build script
We shall outline each of these three scenarios in this section. However first we need to setup the appropriate automation hosts and test sets in SpiraTeam:
"},{"location":"RemoteLaunch-User-Guide/NeoLoad/#configuring-the-automation-hosts-and-test-sets","title":"Configuring the Automation Hosts and Test Sets","text":"Go to Testing > Automation Hosts in SpiraTeam to display the list of automation hosts:
Make sure that you have created an Automation Host for each computer that is going to run an automated test case. The name and description can be set to anything meaningful, but the Token field must be set to the same token that is specified as the Host name in the RemoteLaunch application on that specific machine.
Once you have at least one Automation Host configured, go to Testing > Test Sets to create the test sets that will contain the automated test case:
Note: Unlike manual test cases, automated test cases must be executed within a test set -- they cannot be executed directly from the test case.
Create a new Test Set to hold the NeoLoad test cases and click on its hyperlink to display the test set details page:
You need to add at least one automated test case to the test set and then configure the following fields:
Automation Host -- This needs to be set to the name of the automation host that will be running the automated test set.
Planned Date -- The date and time that you want the scenario to begin. (Note that multiple test sets scheduled at the exact same time will be scheduled by Test Set ID order.)
Status -- This needs to be set to \"Not Started\" for RemoteLaunch to pick up the scheduled test set. When you change the Planned Date, the status automatically switches back to \"Not Started\"
Type -- This needs to be set to \"Automated\" for automated testing
Once you have set the various test set fields (as described above), the Remote Launch instances will periodically poll SpiraTeam for new test sets. Once they retrieve the new test set, they will add it to their list of test sets to be executed. Once execution begins they will change the status of the test set to \"In Progress\", and once test execution is done, the status of the test set will change to either \"Completed\" -- the automation engine could be launched and the test has completed -- or \"Blocked\" -- RemoteLaunch was not able to start the automation engine.
If you want to immediately execute the test case on your local computer, instead of setting the \"Automation Host\", \"Status\" and \"Planned Date\" fields, you can instead click the [Execute] icon on the test set itself. This will cause RemoteLaunch on the local computer to immediately start executing the current test set.
In either case, once all the test cases in the test set have been completed, the status of the test set will switch to \"Completed\" and the individual test cases in the set will display a status based on the results of the NeoLoad execution:
Passed -- The scenario ran and reported no error messages and all SLAs were passed.
Caution -- The scenario ran and at least one SLA reported back as acceptable
Failed -- The scenario ran and at least one error message was reported or at least one SLA was reported back as failed.
Blocked -- There was an error with the Test Set or NeoLoad application.
If you receive the \"Blocked\" status for either the test set or the test cases you should open up the Windows Application Event Log on the computer running RemoteLaunch and look in the event log for error messages.
Note: While the tests are executing you may see browser or application windows launch as NeoLoad runs the scenario and connects VUsers to their tasks.
Once the tests have completed, you can log back into SpiraTeam and see the execution status of your test cases. If you click on a Test Run that was generated by NeoLoad, you will see the following test run summary information:
This section of the screen indicates how long the test took to execute, the overall status, which release was being executed, which test set it was a part of and each of the key summary statistics, together with information on how they compared to the defined SLA:
N/A -- There was no SLA defined for this metric
Passed -- There is an SLA defined for this metric and it was passed.
Caution -- There is an SLA defined for this metric and it was considered less than a pass, but still acceptable.
Failed -- There is an SLA defined for this metric and it was not met successfully.
In addition, if you scroll down, in the \"Console Output\" section of the report there is more detailed information:
The Message of the test will report the number of total pages, number of total hits, number of total users, number of errors as well as the total count of virtual users.
In addition, more detailed information is displayed in the test run details:
Top 5 errors by page
Top 5 alerts by page
Top 5 average response times by page
Top 5 maximum response times by page
Finally, if you have chosen the option to attach the NeoLoad PDF report, in the Attachments section of the Test Run, that will be listed:
Congratulations... You are now able to run automated NeoLoad performance scenarios and have the results be recorded within SpiraTest / SpiraTeam.
"},{"location":"RemoteLaunch-User-Guide/Ranorex/","title":"Ranorex","text":"Ranorex is an automated functional test automation system that lets you record application operations and generate .NET language (C#, VB.NET) test automation scripts that can be used to playback the test script against the test application.
This section describes how you can use SpiraTest / SpiraTeam (hereafter SpiraTeam) together with RemoteLaunch to schedule and remotely launch instances of Ranorex on different computers and have the testing results be transmitted back to SpiraTeam. This allows you to extend your SpiraTeam's test management capabilities to include automated Ranorex tests.
This plugin was developed by one of our partners (step2IT GmbH) but has been formally tested by Inflectra and is fully supported by Inflectra.
Note: This integration requires at least version 3.0 of SpiraTest/Team and version 3.0 of Ranorex.
"},{"location":"RemoteLaunch-User-Guide/Ranorex/#installing-the-ranorex-engine","title":"Installing the Ranorex Engine","text":"This section assumes that you already have a working installation of SpiraTest or SpiraTeam and have installed RemoteLaunch on the various test automation hosts following the instructions in RemoteLaunch Guide. Once those prerequisites are in place, please follow these steps:
Download and extract the RanorexAutomationEngine.zip file from the Inflectra website and locate the appropriate RanorexAutomationEngine.dll for the version of Ranorex that you are using.
If you don't see the version listed, just use the nearest version that is lower than your current version.
Copy the file \"RanorexAutomationEngine.dll\" into the \"extensions\" sub-folder of the RemoteLaunch installation.
Log in to SpiraTeam as a system administrator and go into SpiraTeam main Administration page and click on the \"Test Automation\" link under Integration.
Click the \"Add\" button to enter the new test automation engine details page. The fields required are as follows:
Name: This is the short display name of the automation engine. It can be anything that is meaningful to your users.
Description: This is the long description of the automation engine. It can be anything that is meaningful to your users. (Optional)
Active: If checked, the engine is active and able to be used for any project.
Token: This needs to be the assigned unique token for the automation engine and is used to tell RemoteLaunch which engine to actually use for a given test case. For Ranorex this should always be RanorexEngine.
Once you have finished, click the \"Insert & Close\" button and you will be taken back to the Test Automation list page, with Ranorex listed as an available automation engine:
You can modify the Ranorex configuration for each of the specific automation hosts, by right-clicking on the RemoteLaunch icon in the system tray and choosing \"Configuration\". That will bring up the RemoteLaunch configuration page.
The Ranorex engine adds its own tab to this page which allows you to configure how Ranorex operates:
The following fields can be specified on this screen:
Result Path -- This is the folder where the results of Ranorex tests will be stored. The currently logged-in user needs to have Read/Write permissions over this folder.
Trace Logging -- When selected, this will log additional trace and debugging information to the Windows Event Log. This should not be selected in a production environment.
"},{"location":"RemoteLaunch-User-Guide/Ranorex/#setting-up-the-automated-test-cases","title":"Setting up the Automated Test Cases","text":"This section describes the process for setting up a test case in SpiraTeam for automation and linking it to an automated Ranorex test script.
First you need to display the list of test cases in SpiraTeam (by clicking Testing > Test Cases) and then add a new test case. Once you have added the new test case, click on it and select the \"Automation\" tab:
You need to enter the following fields:
Automation Engine - Choose the Ranorex Automation Engine that you created in the previous section from the drop-down list.
Script Type -- This should be set to Linked as the integration with Ranorex only supports referencing Ranorex test script files and not physically uploading the test scripts into SpiraTeam.
Filename -- This needs to be the full path to the Ranorex test suite.
To make this easier across different machines, you can use several constants for standard Windows locations (see example in screenshot):
[MyDocuments] -- The user's \"My Documents\" folder. The user indicated is the user that ran RemoteLaunch.
[CommonDocuments] -- The Public Document's folder.
[DesktopDirectory] -- The user's Desktop folder. The user indicated is the user that ran RemoteLaunch.
[ProgramFiles] -- Translated to the Program Files directory. For 64-bit machines, it's the 64-bit directory.
[ProgramFilesX86] -- Translated to the 32-bit Program Files directory.
If you'd like to pass parameters to Ranorex you can specify them by separating them from the filename with a pipe (\"|\") character. For example to run a specific Ranorex test case you can use the following \"filename\":
c:\\test\\mytestsuit.exe|/testcase:addDataTest
Document Type -- This allows you to choose which document type the automated test script will be categorized under.
Document Folder --This allows you to choose which document folder the automated test script will be stored in.
Version -- The version of the test script (1.0 is used if no value specified)
Test Script -- This is not used with the Ranorex Engine since it only supports linked test scripts.
Once you are happy with the values, click [Save] to update the test case. Now you are ready to schedule the automated test case for execution.
"},{"location":"RemoteLaunch-User-Guide/Ranorex/#using-parameterized-test-cases","title":"Using Parameterized Test Cases","text":"There is an advanced feature of SpiraTest/Team and RemoteLaunch that lets you pass parameters from SpiraTeam to your Ranorex automated test suite. This is very useful if you have a data-driven Ranorex test suite that defines input variables from an external data source.
To setup the automated test case for parameters, click on the \"Test Steps\" tab and click on \"Edit Parameters\":
The name of the parameter ${login} needs to match the name of the variable defined within the Ranorex script in its variables configuration.
"},{"location":"RemoteLaunch-User-Guide/Ranorex/#executing-the-ranorex-test-sets-from-spirateam","title":"Executing the Ranorex Test Sets from SpiraTeam","text":"There are two ways to execute automated test cases in SpiraTeam:
Schedule the test cases to be executed on a specific computer (local or remote) at a date/time in the future
Execute the test cases right now on the local computer.
We shall outline both of these two scenarios in this section. However first we need to setup the appropriate automation hosts and test sets in SpiraTeam:
"},{"location":"RemoteLaunch-User-Guide/Ranorex/#configuring-the-automation-hosts-and-test-sets","title":"Configuring the Automation Hosts and Test Sets","text":"Go to Testing > Automation Hosts in SpiraTeam to display the list of automation hosts:
Make sure that you have created an Automation Host for each computer that is going to run an automated test case. The name and description can be set to anything meaningful, but the Token field must be set to the same token that is specified in the RemoteLaunch application on that specific machine.
Once you have at least one Automation Host configured, go to Testing > Test Sets to create the test sets that will contain the automated test case:
Note: Unlike manual test cases, automated test cases must be executed within a test set -- they cannot be executed directly from the test case.
Create a new Test Set to hold the Ranorex automated test cases and click on its hyperlink to display the test set details page:
Lower down, the list of test cases in the test set are displayed:
You need to add at least one automated test case to the test set and then configure the following fields:
Automation Host -- This needs to be set to the name of the automation host that will be running the automated test set.
Planned Date -- The date and time that you want the scenario to begin. (Note that multiple test sets scheduled at the exact same time will be scheduled by Test Set ID order.)
Status -- This needs to be set to \"Not Started\" for RemoteLaunch to pick up the scheduled test set. When you change the Planned Date, the status automatically switches back to \"Not Started\"
Type -- This needs to be set to \"Automated\" for automated testing
If you have parameterized test cases inside the automated test set you can set their values in three different ways:
Test Set Parameter Values -- this lets you set the same value of a parameter for all the test cases in the test set:
Test Case Parameter Values -- this lets you set a specific value for a parameter for a particular test case in the test set:
You set these values, by right-clicking on a row and choosing \"Edit Parameters\":
Once you have set the various test set fields (as described above), the Remote Launch instances will periodically poll SpiraTeam for new test sets. Once they retrieve the new test set, they will add it to their list of test sets to execute. Once execution begins they will change the status of the test set to \"In Progress\", and once test execution is done, the status of the test set will change to either \"Completed\" -- the automation engine could be launched and the test has completed -- or \"Blocked\" -- RemoteLaunch was not able to start the automation engine.
If you want to immediately execute the test case on your local computer, instead of setting the \"Automation Host\", \"Status\" and \"Planned Date\" fields, you can instead click the [Execute] icon on the test set itself. This will cause RemoteLaunch on the local computer to immediately start executing the current test set.
In either case, once all the test cases in the test set have been completed, the status of the test set will switch to \"Completed\" and the individual test cases in the set will display a status based on the results of the Ranorex test:
Passed -- The Ranorex automated test ran successfully and all the test steps in the test script passed and no assertions were thrown.
Failed -- The Ranorex automated test ran successfully, but at least one test step failed or at least one assertion failed.
Caution -- The Ranorex automated test run successfully, but at least one warning was logged in one of the test steps.
Blocked -- The Ranorex automated test did not run successfully or at least one timeout error was recorded.
If you receive the \"Blocked\" status for either the test set or the test cases you should open up the Windows Application Event Log on the computer running RemoteLaunch and look in the event log for error messages.
Note: While the tests are executing you will see browser windows launch as Ranorex executes the appropriate tests.
Once the tests have completed, you can log back into SpiraTeam and see the execution status of your test cases. If you click on a Test Run that was generated by Ranorex, you will see the following information:
This screen indicates the status of the test run that was reported back from Ranorex together with any messages or other information. The Test Name indicates the name of the test inside Ranorex and the execution status corresponds the matching status inside Ranorex as illustrated below:
Ranorex Status SpiraTeam Status Success Passed Failed Failed
In addition, the detailed test report from Ranorex is available in the large text-box below. It will contain messages such as:
+-----------------------------------------------------------------------+ | [2011/10/14 14:08:32.795][Debug ][Logger]: Console logger | | starting. | | | | [2011/10/14 14:08:32.874][Info ][Test]: Test Suite 'WinForms | | Test' started. | | | | [2011/10/14 14:08:32.889][Info ][Test]: Test Case | | 'VS2005_Application_Test' started. | | | | [2011/10/14 14:08:33.467][Success][Test]: Test Module | | 'StartWinformsSample' completed with status 'Success'. | | | | [2011/10/14 14:08:33.467][Info ][Test]: Test Module | | 'CheckIfApplicationAlive' started. | | | | [2011/10/14 14:08:33.608][Info ][Validation]: Validating Exists | | on item 'WinFormsApp.ButtonTest_PushButton'. | | | | [2011/10/14 14:09:55.718][Failure][Test]: Test Case | | 'VS2005_Application_Test' completed with status 'Failed'. | | | | [2011/10/14 14:09:55.718][Failure][Test]: Test Suite 'WinForms | | Test' completed with status 'Failed'. | +-----------------------------------------------------------------------+
Congratulations... You are now able to run Ranorex automated functional tests and have the results be recorded within SpiraTest / SpiraTeam.
"},{"location":"RemoteLaunch-User-Guide/Rational-Functional-Tester/","title":"Rational Functional Tester","text":"IBM Rational Functional Tester (hereafter RFT) is software test automation tool used by quality assurance teams to perform automated regression testing. Testers create scripts by using a test recorder which captures a user's actions against their application under test. The recording mechanism creates a test script from the actions. The test script is produced as either a Java or Visual Basic.net application.
This section describes how you can use SpiraTest / SpiraTeam (hereafter SpiraTeam) together with RemoteLaunch to schedule and remotely launch instances of RFT on different computers and have the testing results be transmitted back to SpiraTeam. This allows you to extend your SpiraTeam's test management capabilities to include automated RFT tests.
Note: This integration requires at least version 3.0 of SpiraTest/Team.
"},{"location":"RemoteLaunch-User-Guide/Rational-Functional-Tester/#installing-the-rft-engine","title":"Installing the RFT Engine","text":"This section assumes that you already have a working installation of SpiraTest or SpiraTeam and have installed RemoteLaunch on the various test automation hosts following the instructions in RemoteLaunch Guide. Once those prerequisites are in place, please follow these steps:
Download and extract the RFTEngine.zip file from the Inflectra website and locate the appropriate RFTAutomationEngine.dll for the version of RFT that you are using.
If you don't see the version listed, just use the nearest version that is lower than your current version.
Copy the file \"RFTAutomationEngine.dll\" into the \"extensions\" sub-folder of the RemoteLaunch installation.
Log in to SpiraTeam as a system administrator and go into SpiraTeam main Administration page and click on the \"Test Automation\" link under Integration.
Click the \"Add\" button to enter the new test automation engine details page. The fields required are as follows:
Name: This is the short display name of the automation engine. It can be anything that is meaningful to your users.
Description: This is the long description of the automation engine. It can be anything that is meaningful to your users. (Optional)
Active: If checked, the engine is active and able to be used for any project.
Token: This needs to be the assigned unique token for the automation engine and is used to tell RemoteLaunch which engine to actually use for a given test case. For RFT this should always be RFTAutomationEngine.
Once you have finished, click the \"Insert & Close\" button and you will be taken back to the Test Automation list page, with RFT listed as an available automation engine.
You can modify the RFT configuration for each of the specific automation hosts, by right-clicking on the RemoteLaunch icon in the system tray and choosing \"Configuration\". That will bring up the RemoteLaunch configuration page.
The RFT engine adds its own tab to this page which allows you to configure how RFT operates:
The following fields can be specified on this screen:
RFT Location -- this is where the installation of RFT can be found. Typically it's C:\\Program Files\\IBM\\SDP\\FunctionalTester\\bin
Workspace Location -- This is the folder where the RFT test scripts and generated log files will be stored. The currently logged-in user needs to have Read/Write permissions over this folder. Typically it's:
C:\\Documents and Settings\\[User Name]\\IBM\\rationalsdp\\workspace on a Windows XP workstation or Windows 2003 server.
C:\\Users\\[User Name]\\IBM\\rationalsdp\\workspace on a Windows Vista, 7, 2008 or 2008 R2 computer.
Trace Logging -- When selected, this will log additional trace and debugging information to the Windows Event Log. This should not be selected in a production environment.
"},{"location":"RemoteLaunch-User-Guide/Rational-Functional-Tester/#setting-up-the-automated-test-cases","title":"Setting up the Automated Test Cases","text":"This section describes the process for setting up a test case in SpiraTeam for automation and linking it to an automated RFT test script.
First you need to display the list of test cases in SpiraTeam (by clicking Testing > Test Cases) and then add a new test case. Once you have added the new test case, click on it and select the \"Automation\" tab:
You need to enter the following fields:
Automation Engine - Choose the RFT Automation Engine that you created in the previous section from the drop-down list.
Script Type -- This should be set to Linked as the integration with RFT only supports referencing RFT test script files and not physically uploading the test scripts into SpiraTeam.
Filename -- This needs to consist of the following three components separated by a pipe (|) character (see the screenshot for an example):
The name of the RFT project that the test is mapped to
The name of the RFT script in the project that the test is mapped to
Either \"java\" or \"net\" depending on whether you have a Java or .NET test script
Document Type -- This allows you to choose which document type the automated test script will be categorized under.
Document Folder --This allows you to choose which document folder the automated test script will be stored in.
Version -- The version of the test script (1.0 is used if no value specified)
Test Script -- This is not used with the RFT Engine since it only supports linked test scripts.
Once you are happy with the values, click [Save] to update the test case. Now you are ready to schedule the automated test case for execution.
"},{"location":"RemoteLaunch-User-Guide/Rational-Functional-Tester/#using-parameterized-test-cases","title":"Using Parameterized Test Cases","text":"There is an advanced feature of SpiraTest/Team and RemoteLaunch that lets you pass parameters from SpiraTeam to your RFT automated test suite. This is very useful if you have a data-driven RFT test suite that defines input variables from an external data source.
To setup the automated test case for parameters, click on the \"Test Steps\" tab and click on \"Edit Parameters\":
The name of the parameter ${login} is actually not used when passing the data to RFT, only the values are passed. Therefore it's important that the parameters are stored in the order they are expected by your RFT test script.
"},{"location":"RemoteLaunch-User-Guide/Rational-Functional-Tester/#executing-the-rft-test-sets-from-spirateam","title":"Executing the RFT Test Sets from SpiraTeam","text":"There are two ways to execute automated test cases in SpiraTeam:
Schedule the test cases to be executed on a specific computer (local or remote) at a date/time in the future
Execute the test cases right now on the local computer.
We shall outline both of these two scenarios in this section. However first we need to setup the appropriate automation hosts and test sets in SpiraTeam:
"},{"location":"RemoteLaunch-User-Guide/Rational-Functional-Tester/#configuring-the-automation-hosts-and-test-sets","title":"Configuring the Automation Hosts and Test Sets","text":"Go to Testing > Automation Hosts in SpiraTeam to display the list of automation hosts:
Make sure that you have created an Automation Host for each computer that is going to run an automated test case. The name and description can be set to anything meaningful, but the Token field must be set to the same token that is specified in the RemoteLaunch application on that specific machine.
Once you have at least one Automation Host configured, go to Testing > Test Sets to create the test sets that will contain the automated test case:
Note: Unlike manual test cases, automated test cases must be executed within a test set -- they cannot be executed directly from the test case.
Create a new Test Set to hold the RFT automated test cases and click on its hyperlink to display the test set details page:
You need to add at least one automated test case to the test set and then configure the following fields:
Automation Host -- This needs to be set to the name of the automation host that will be running the automated test set.
Planned Date -- The date and time that you want the scenario to begin. (Note that multiple test sets scheduled at the exact same time will be scheduled by Test Set ID order.)
Status -- This needs to be set to \"Not Started\" for RemoteLaunch to pick up the scheduled test set. When you change the Planned Date, the status automatically switches back to \"Not Started\"
Type -- This needs to be set to \"Automated\" for automated testing
If you have parameterized test cases inside the automated test set you need to set their values by right-clicking on the test case and choosing \"Edit Parameters\":
Enter the parameter values and click \"Update\" to commit the change. This allows you to have the same test case in the test set multiple times with different data for each instance.
"},{"location":"RemoteLaunch-User-Guide/Rational-Functional-Tester/#executing-the-test-sets","title":"Executing the Test Sets","text":"Once you have set the various test set fields (as described above), the Remote Launch instances will periodically poll SpiraTeam for new test sets. Once they retrieve the new test set, they will add it to their list of test sets to execute. Once execution begins they will change the status of the test set to \"In Progress\", and once test execution is done, the status of the test set will change to either \"Completed\" -- the automation engine could be launched and the test has completed -- or \"Blocked\" -- RemoteLaunch was not able to start the automation engine.
If you want to immediately execute the test case on your local computer, instead of setting the \"Automation Host\", \"Status\" and \"Planned Date\" fields, you can instead click the [Execute] icon on the test set itself. This will cause RemoteLaunch on the local computer to immediately start executing the current test set.
In either case, once all the test cases in the test set have been completed, the status of the test set will switch to \"Completed\" and the individual test cases in the set will display a status based on the results of the RFT test:
Passed -- The RFT automated test ran successfully and all the test steps in the test script passed and no assertions were thrown.
Failed -- The RFT automated test ran successfully, but at least one test step failed or at least one assertion failed.
Caution -- The RFT automated test run successfully, but at least one warning was logged in one of the test steps.
Blocked -- The RFT automated test did not run successfully.
If you receive the \"Blocked\" status for either the test set or the test cases you should open up the Windows Application Event Log on the computer running RemoteLaunch and look in the event log for error messages.
Note: While the tests are executing you will see browser windows launch as RFT executes the appropriate tests.
Once the tests have completed, you can log back into SpiraTeam and see the execution status of your test cases. If you click on a Test Run that was generated by RFT, you will see the following information:
This screen indicates the status of the test run that was reported back from RFT together with any messages or other information. The Test Name indicates the name of the test inside RFT and the execution status corresponds the matching status inside RFT as illustrated below:
RFT Status SpiraTeam Status PASS Passed FAIL Failed WARNING CautionIn addition, the detailed test report from RFT is available in the large text-box below. It will contain messages such as:
07-Nov-2011 03:00:05.004 PM: Script Start - INFORMATION - Script start [Script1]
07-Nov-2011 03:00:05.035 PM: Simplified Script Group - INFORMATION - firefox.exe: self improvement - QuickStart Tutorials for Rational Functional Tester (RFT) - Stack Overflow - Mozilla Firefox
07-Nov-2011 03:00:05.035 PM: Timer Start - INFORMATION - Start timer: firefoxexeselfimprovementQuickSta_1
07-Nov-2011 03:00:25.535 PM: General - WARNING - Object Recognition is weak (above the warning threshold)
07-Nov-2011 03:00:49.488 PM: General - FAIL - Script1.testMain had an unhandled exception.
07-Nov-2011 03:00:49.488 PM: Script End - FAIL - Script end [Script1]
Exception occurred during playback of script [Script1] [CRFCN0019E: RationalTestScriptException on line 49 of script Script1 - com.rational.test.ft.ObjectNotFoundException: CRFCN0661W: The recognition score of the found object does not qualify the object as a match.
Looking for [GuiSubitemTestObject(Name: goToAWebSitetext, Map: GoToAWebSite)], best failing candidate score was [22500] with best failing description [{.class=.Text, .name=Go to a Web Site, .classIndex=0}].].
Congratulations... You are now able to run RFT automated functional tests and have the results be recorded within SpiraTest / SpiraTeam.
"},{"location":"RemoteLaunch-User-Guide/RemoteLaunch-Guide/","title":"RemoteLaunch Guide","text":"There are actually two separate versions of RemoteLaunch\u00ae that are available from Inflectra:
The first part of this section will describe how to use the Windows-only RemoteLaunch\u00ae GUI application and the second part will describe how to use the cross-platform RemoteLaunchX**\u2122** console application.
"},{"location":"RemoteLaunch-User-Guide/RemoteLaunch-Guide/#installing-remotelaunch","title":"Installing RemoteLaunch","text":"It is required that you install the program before copying or installing any test extensions for the program. Testing applications, like Selenium and QuickTest Pro can be installed with no regards to the client application -- if they are not installed by the time a test requiring them needs to be executed, the test extension will simply report an error or block for the specified test set.
There are no options to the installer except for installation path. If you do not use the default installation path (typically C:\\Program Files\\Inflectra\\Spira RemoteLaunch\\), then make a note of where the installation path is, because it will be needed to install test extensions later.
A test extension is a single or a set of DLLs that the program will read upon startup and provides a link in which testing applications (like TestComplete and Squish) to report test information and status back to SpiraTeam.
When you download a test extension, the ZIP file should contain at least one DLL file. Unless otherwise specified by a readme.txt file included in the compressed file, copy the DLL file to the \\extension directory located within Spira RemoteLaunch installation directory. (If no such folder exists, you must create it.)
If an extension is removed or added, the program must be restarted for the any changes to take effect. The program will only load up to the first number of extensions that the license allows. Additional extensions will not be loaded or used during testing.
RemoteLaunch runs in the background. To fully close RemoteLaunch you need to exit the application by right clicking on the icon in the task bar (usually in the lower right of your screen). This will cancel any currently running tests. Any scheduled tests, waiting to be executed will be paused until the program is restarted and polling resumed.
If, when you restart the application, the new engine tab does not show up in RemoteLaunch, Windows may have blocked the engine dll in the extensions folder. To resolve this block:
Spira RemoteLaunch has its own License key needed for using the program. You cannot use your existing SpiraTest/Plan/Team key in Spira RemoteLaunch. Upon the first launch of the program, you will be asked to update your license information:
Enter in your organization name and license key in the email that was sent when you purchased the license, or as listed on your customer information page at http://inflectra.com.
Trial licenses are good until the 28th day of the listed month. The next time the program is run after the 28th of the month, you will be prompted to re-enter a new permanent license key, or the program will be unusable.
The license key can be updated at any time by going to the Tray Menu and select Help -> About. Once the About screen opens up, click the Update button in the license details section to update or change license information.
"},{"location":"RemoteLaunch-User-Guide/RemoteLaunch-Guide/#using-remotelaunch","title":"Using RemoteLaunch","text":""},{"location":"RemoteLaunch-User-Guide/RemoteLaunch-Guide/#basic-unattended-operation","title":"Basic Unattended Operation","text":"When run, the program will start minimized to the system tray and will start its polling of the server. Polling will occur every 'x' minutes (60 by default) for any automated test sets that are scheduled to be run. When time comes for a test to be launched, it will start the test extension. The installed test extension will then perform the test and report results back to SpiraTeam. At the end of the test, the program will go back and resume scanning for tests that need to be executed.
No user input is ever needed from the application itself. However, testing applications may pop up dialogs needing user input. For existing Inflectra testing extensions, effort was put in to avoid as much user-interaction as possible, but in some cases it is unavoidable.
"},{"location":"RemoteLaunch-User-Guide/RemoteLaunch-Guide/#client-configuration","title":"Client Configuration","text":"By right clicking on the system tray icon and selecting \"Configuration\", the application's window will open to the configuration panel. The panel has the following options:
SpiraTeam Server Configuration:
Server Polling:
If an extension has custom configuration options, they will appear as separate tabs located after the Client Setup tab. The contents of each tab will vary depending on the extension. View the extension's documentation for options given in those extensions.
"},{"location":"RemoteLaunch-User-Guide/RemoteLaunch-Guide/#status-screen","title":"Status Screen","text":"The status screen is usually hidden, but can be brought up for display by double-clicking on the system tray icon. The top of the screen shows the current status, whether it's running a test or waiting to poll the server for an update. It will also show any errors present on the application, like a registration error or configuration issue. Under the status bar is a list of any pending or executing tests that are scheduled for this testing machine. The list will get cleared at every poll, so tests that have executed since the previous poll will still be on the list, and will show their execution status:
Green Arrow: A green arrow indicates that the test is still running, or RemoteLaunch is waiting for a reply from the testing engine / test application.
Blue Checkbox: A blue checkbox indicates that the test is completed, regardless of status of the individual test steps in the scheduled test set.
Red Error: A red error indicator indicates that the test extension or the testing application ran into an issue (outside of test results). In this case, any further tests that require the extension will be marked as blocked, as the issue needs to be corrected within the extension settings or testing application.
No Indication: No indication means that the test is currently awaiting for its scheduled date to start. Note that only one test will be launched at a time, so that if two tests are scheduled at the same time, the one with the lower TestSet ID will be executed first, then as soon as it's finished, the second scheduled test will be run.
By highlighting a test that has not been executed yet, you can click the Force Execute button. This will cause the selected test to have its scheduled date to the current time, causing it to be immediately executed (or, if another test is already running, next in line for execution).
At any time the Force Poll button can be clicked, causing RemoteLaunch to initiate an immediate poll of the SpiraTeam server to check for pending runs. The timers for the next server poll will be reset when the button is clicked.
"},{"location":"RemoteLaunch-User-Guide/RemoteLaunch-Guide/#tray-icon-menu","title":"Tray Icon Menu","text":"Instead of operating from the application window, all functions exist on the tray icon menu as well, as well as some additional commands:
Pause / Resume: The Pause/Resume option pauses or resumes the timers for polling and executing tests. If a test or server poll is already in progress, it will not cancel these. However, after they are finished, no further polls or tests will be run.
Poll Now: This will force a server poll for upcoming tests, and reset the poll timer.
Configuration: Opens the main window to the Configuration page.
Help -> About: Opens the About window, which displays the current license information and any loaded extensions.
Help -> View Help: Opens this PDF file in a browser.
Exit: Will completely exit the program. Doing this will cancel any tests currently running and shut down the program. Any tests that were waiting to be executed will not execute until the program is restarted and the polling is resumed.
You can double-click the try icon to bring up the main window on the Status page.
"},{"location":"RemoteLaunch-User-Guide/RemoteLaunch-Guide/#test-execution-and-reporting","title":"Test Execution and Reporting","text":"All test handling is performed by the extension that the automated tests are configured for. Test Sets that have multiple Test Cases, the Test Cases will all be executed in order, sequentially. (No parallel executing.)
At the start of execution for a Test Set, the test set will be updated in SpiraTeam as \"In Progress\". As tests are performed, the Test Cases will be updated with their status. The Test Set on the status screen will be marked with the executing icon.
Once the Test Set is completed, the status of the Test Set will be changed to \"Completed\", and will be marked on the status screen with a completed icon.
In case of an uncaught exception that is thrown by the testing extension, the Test Set will be marked \"Blocked\", and the Test Case will be recorded as Blocked. All other following tests will not be run and remain as Not Run. The Test Set must be reset to be executed again, and it is recommended to look into the cause of the error (recorded in the Blocked Test Case results) and correct it before rescheduling the test. This Test Set will be marked with and error icon.
The same results are applied in the case where a Test Set contains a Test Case that references a testing extension that is not installed. Install the extension and re-run the Test Set.
Executing , Completed , and Error Test Sets are marked with the icons next to their scheduled date in the Status screen. They will stay in the list until the next scheduled server poll. You cannot manually re-run them.
"},{"location":"RemoteLaunch-User-Guide/RemoteLaunch-Guide/#running-remotelaunch-from-a-build-script","title":"Running RemoteLaunch from a Build Script","text":"Normally you schedule tests in SpiraTeam using the Planned Date field of the test sets and let the various instances of RemoteLaunch poll SpiraTeam for upcoming tests. In addition (as described in the SpiraTeam User Manual) you can execute a test set on the local machine immediately by clicking the \"Execute\" button within SpiraTeam.
However there are situations where you want to be able to launch an automated test script using one of the supported engines from an external batch file or build script (e.g. as part of a continuous integration environment) and have those tests report their results back into SpiraTeam. You can achieve this by using the special command-line argument --testset which is passed to RemoteLaunch. For more details on this parameter see the next section.
"},{"location":"RemoteLaunch-User-Guide/RemoteLaunch-Guide/#command-line-arguments","title":"Command line arguments","text":"For debugging and additional options when running the program, the following command-line arguments are available:
-status Shows the Status screen upon startup. (Normal action is to run minimized to the system tray. -paused Starts the application with timers Paused instead of active. -poll Forces the program to do an initial poll upon startup. (Normal action is to wait the pending time before doing the initial poll.) -trace Enables tracelogging to the EventLog for debugging and watching tests execute. -logfile Forces events to be written to a text file instead of the Application EventLog. This option enables --trace as well. Files are located in the Local Application Data folder. (C:\\Users\\<user>\\AppData\\Local on Vista/Win7). -testset:[Test Set ID] Allows you to tell RemoteLaunch to execute a specific test set on the remote computer (e.g. -testset:45 runs test set TX00045) <filename> Must be the last item on the command line. This is a TST file downloaded from SpiraTeam to start immediate execution on."},{"location":"RemoteLaunch-User-Guide/RemoteLaunch-Guide/#using-remotelaunchx","title":"Using RemoteLaunchX","text":"When you need to run automated tests on a variety of different platforms (Windows, MacOS X, Linux, Unix, etc.) the RemoteLaunchX cross-platform automated testing agent is a better choice than the standard RemoteLaunch\u00ae GUI application.
To start using RemoteLaunchX, please go to the Customer Area of the Inflectra website and download the latest version of the RemoteLaunchX application. It will be packaged as a simple .zip compressed folder that you can extract onto the target computer:
The following four files are included:
RemoteLaunchX.jar -- this is the main application, packaged as a Java JAR file. This version of RemoteLaunch requires Java 1.8 SE or later to be installed.
config.properties -- this contains all the settings used by RemoteLaunchX. You will need to edit this file in a text editor to configure RemoteLaunchX for use.
RemoteLaunchX.bat -- this is a sample Windows\u00ae batch file that can be used to simplify running RemoteLaunchX on Windows\u00ae systems.
RemoteLaunchX.sh -- this is a sample UNIX/Linux/MacOS X shell script that can be used to run RemoteLaunchX on UNIX, Linux or Mac OS X.
In addition, there is a lib folder that also needs to be extracted. It contains various third-party libraries that RemoteLaunchX uses. Currently it only uses the Google json parser library (gson v2.8.6):
"},{"location":"RemoteLaunch-User-Guide/RemoteLaunch-Guide/#configuring-remotelaunchx","title":"Configuring RemoteLaunchX","text":"Once you have extracted the files listed above, open up the config.properties file in a text editor:
#This file contains the configuration data used by the RemoteLaunch-X application\n\n#Spira connection information\nserver-url = http://vm-win2012r2/SpiraTeam\nserver-login = fredbloggs\nserver-token = {XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}\n\n#The automation host token \nhost-token = MyHost1\n\n#The license key \nlicense-organization: TBD \nlicense-key: TBD\n\n#The regular expressions for each of the possible execution statuses\npass-regex = .*\nfail-regex = (?i).*(Error|Fail|Fatal).*\ncaution-regex = .*(Warning|Caution).*\nblocked-regex = .*(Blocked).*\n\n#Default status for output not matching any of the regular expressions above\ndefault-test-status = Not Run\nThe following changes need to be made to this configuration file:
server-url -- This is the URL of the SpiraTest or SpiraTeam installation (hereafter referred to as just SpiraTest). Be sure to not put /Login.aspx or any other page in the string, this should be just the root URL of the application's install.
server-login -- This is the SpiraTest login id of the user that you want the tests reported as. Note that while the application is polling and updating test results, if the user is logged into a web browser session, they will get kicked out.
server-token -- The RSS Token of the SpiraTest login listed above. Found in users profile page under the \"RSS Token\" field; you must have RSS Feeds enabled for this to work.
host-token -- This field is required, and uniquely identifies the local testing machine. Any scheduled tests assigned to the Automation Host on SpiraTest will get polled for this machine. Except in special circumstances, this ID should be unique among all testing machines. Important: This field must match the string that is entered into the Automation Host Details screen in the Token: field, or scheduled tests will not be recognized.
license-organization -- The name of the \"Organization\" that your RemoteLaunch license key was issued to. This is listed in the Customer Area of the Inflectra website alongside the license key. Note: RemoteLaunch and RemoteLaunchX use the same license keys, so you don't need to have a separate RemoteLaunchX one.
license-key -- The RemoteLaunch license key that is listed in the secure Customer Area of the Inflectra website
You should leave the four regex settings alone for now, they can be changed when you start executing tests and need to fine-tune how RemoteLaunchX interprets the results.
Now that you have configured the plugin, you can execute the RemoteLaunchX console application by either running the provided batch / shell command or just executing the JAR file directly:
Java --jar RemoteLaunchX.jar
When you run the application, the following should be output to the console:
Starting RemoteLaunch...
========================
Server URL: http://localhost/Spira
Server Login: fredbloggs
Automation Host: MyHost1
Checking License Key for: Inflectra Corporation
Production License Key in Use.
Testing connection to Spira...
Successfully connected to Spira.
WARNING: Unable to retrieve test runs for SpiraTest project PR2, so skipping this project - Automation Host with token 'MyHost1' doesn't exist in project PR2.
WARNING: Unable to retrieve test runs for SpiraTest project PR3, so skipping this project - Automation Host with token 'MyHost1' doesn't exist in project PR3.
Retrieved 0 test run(s) from SpiraTest.
Exiting RemoteLaunch...
========================
The system will report back zero Test Runs at this point because nothing has been scheduled in SpiraTest. In the next section we shall setup an automated test set that contains an automated test case.
"},{"location":"RemoteLaunch-User-Guide/RemoteLaunch-Guide/#setting-up-automated-tests-in-spiratest","title":"Setting up Automated Tests in SpiraTest","text":"This section assumes that you already have a working installation of SpiraTest or SpiraTeam and have installed RemoteLaunchX on the various test automation hosts following the instructions above. Once those prerequisites are in place, please follow these steps:
Log in to SpiraTeam as a system administrator and go into SpiraTeam main Administration page and click on the \"Test Automation\" link under Integration.
Click the \"Add\" button to enter the new test automation engine details page. The fields required are as follows:
Name: This is the short display name of the automation engine. It can be anything that is meaningful to your users.
Description: This is the long description of the automation engine. It can be anything that is meaningful to your users. (Optional)
Active: If checked, the engine is active and able to be used for any project.
Token: This needs to be the assigned unique token for the automation engine and is used to tell RemoteLaunch which engine to actually use for a given test case. For Command-Line this should be simply \"CommandLine\".
Once you have finished, click the \"Insert & Close\" button and you will be taken back to the Test Automation list page, with Command-Line listed as an available automation engine.
Next you need to display the list of test cases in SpiraTeam (by clicking Testing > Test Cases) and then add a new test case. Once you have added the new test case, click on it and select the \"Automation\" tab:
You need to enter the following fields:
Automation Engine - Choose the Command-Line Automation Engine that you created in the previous section from the drop-down list.
Script Type -- This can be set to Attached or Linked (see below for the difference).
Filename -- This needs to consist of the following three sections separated by a pipe (|) character:
2) Any arguments for the command-line tool. In addition, you can use the following additional tokens for some of the special RemoteLaunchX values:
3) The mask for converting any parameter values from SpiraTeam into valid command line arguments. If parameters are not accepted by the command-line tool, you can leave this section out.
The mask can include any symbols together with \"name\" to refer to the parameter name and \"value\" to refer to the parameter value.
Example 1: If you want parameters to be provided in the form: -param1=value1 --param2=value2 you would use the following mask: -name=value
Example 2: If you want parameters to be provided in the form: /param1:value1 /param2:value2 you would use the following mask: /name:value
Some example filenames would be: C:\\Temp\\TestApp.exe|-arg1 -arg2|-name=value C:\\Temp\\TestApp.exe|-arg1 -arg2 \"-arg3=[Filename]\"|
where the first one is for a Linked test and the second one is for an Attached test.
Document Type -- You can choose which document type the automated test script will be categorized under.
Document Folder -- You can choose which document folder the automated test script will be stored in.
Version -- The version of the test script (1.0 is used if no value specified)
Test Script -- For Attached test scripts, this needs to contain the complete test script in whatever language and syntax is being expected by the command-line application. For Linked test scripts, you should leave this blank.
If you would like to have SpiraTeam pass any parameter values to this test script you can specify them by using the syntax ${parameterName} inside the test script.
here is an advanced feature of SpiraTest/Team and RemoteLaunch that lets you pass parameters from SpiraTeam to your command-line automated testing tool. This is very useful if you want to have a data-driven test script that be executed multiple times with different parameter values.
To setup the automated test case for parameters, click on the \"Edit Parameters\" hyperlink above the \"Test Script\" box:
The name of the parameter ${login} needs to match the name of a parameter accepted by the command-line tool.
Once you are happy with the values, click [Save] to update the test case. Now you are ready to schedule the automated test case for execution.
Go to Testing > Automation Hosts in SpiraTeam to display the list of automation hosts:
Make sure that you have created an Automation Host for each computer that is going to run an automated test case. The name and description can be set to anything meaningful, but the Token field must be set to the same token that is specified in the RemoteLaunchX application on that specific machine.
Once you have at least one Automation Host configured, go to Testing > Test Sets to create the test sets that will contain the automated test case. Note: Unlike manual test cases, automated test cases must be executed within a test set -- they cannot be executed directly from the test case.
Create a new Test Set to hold the Command-Line automated test cases and click on its hyperlink to display the test set details page:
You need to add at least one automated test case to the test set and then configure the following fields:
Automation Host -- This needs to be set to the name of the automation host that will be running the automated test set.
Planned Date -- The date and time that you want the scenario to begin. (Note that multiple test sets scheduled at the exact same time will be scheduled by Test Set ID order.)
Status -- This needs to be set to \"Not Started\" for RemoteLaunch to pick up the scheduled test set. When you change the Planned Date, the status automatically switches back to \"Not Started\"
Type -- This needs to be set to \"Automated\" for automated testing
If you have parameterized test cases inside the automated test set you can set their values in three different ways:
Test Set Parameter Values -- this lets you set the same value of a parameter for all the test cases in the test set:
Test Case Parameter Values -- this lets you set a specific value for a parameter for a particular test case in the test set:
Test Configurations -- this lets you create a data grid of possible test parameters and execute the test set multiple times, once for each unique combination:
testset -- If you would like to force execution of a test set regardless of its status, you can use the -testset command-line option just as in RemoteLaunch. Simply add -testset:[ID] where [ID] is the ID of the test set you would like to execute. e.g. java -jar RemoteLaunchX.jar -testset:24 -testset:37
project -- If you would like to limit the projects scanned by RemoteLaunchX, you can use the -project command-line option. Simply add -project:[ID] where [ID] is the ID of the project. e.g. java -jar RemoteLaunchX.jar -project:1 project:6
Once you have set the various test set fields (as described above), you are now ready to execute RemoteLaunchX. You can execute the RemoteLaunchX console application by either running the provided batch / shell command or just executing the JAR file directly:
Java --jar RemoteLaunchX.jar
When you run the application, the following should be output to the console:
Starting RemoteLaunch...
========================
Server URL: http://localhost/Spira
Server Login: fredbloggs
Automation Host: MyHost1
Checking License Key for: Inflectra Corporation
Production License Key in Use.
Testing connection to Spira...
Successfully connected to Spira.
WARNING: Unable to retrieve test runs for SpiraTest project PR2, so skipping this project - Automation Host with token 'MyHost1' doesn't exist in projec PR2.
WARNING: Unable to retrieve test runs for SpiraTest project PR3, so skipping this project - Automation Host with token 'MyHost1' doesn't exist in projec PR3.
Retrieved 1 test run(s) from SpiraTest.
Executing test case TC18 with filename 'C:\\Windows\\System32\\ipconfig.exe|/all'
This is a Linked test script
Executing command 'C:\\Windows\\System32\\ipconfig.exe' with arguments '/all'
Execution Status = Passed
Exiting RemoteLaunch...
========================
This can be seen graphically below:
The console output will indicate which test sets are being executed and what the final result was. Inside SpiraTest, once execution begins the status of the test set will change from \"Not Started\" to \"In Progress\", and once test execution is done, the status of the test set will change to either \"Completed\" -- the automation engine could be launched and the test has completed (passed or failed) -- or \"Blocked\" -- RemoteLaunchX was not able to execute the test.
In addition, the individual test cases in the set will display a status based on the results of the command-line test that was executed:
Passed -- The automated test ran successfully and matched the PASS regular expression.
Failed -- The automated test ran successfully, and matched the FAIL regular expression.
Caution -- The automated test ran successfully, and matched the CAUTION regular expression.
Blocked -- The automated test did not run successfully or it matched the BLOCKED regular expression.
If you receive the \"Blocked\" status for either the test set or the test cases you should open up the Test Run that was recorded and the Console output section will contain the underlying error message(s).
Once the tests have completed, you can log back into SpiraTest and see the execution status of your test cases. If you click on a Test Run that was generated by the command-line tool, you will see the following information:
This screen indicates the status of the test run that was reported back from command-line tool together with any messages or other information. The execution status will be set according to the rules described above, the Message field will contain the first line of console output and the large details box will contain the full console output from the command-line tool.
Congratulations... You are now able to run a custom command-line test, and have the results be recorded within SpiraTest / SpiraTeam.
"},{"location":"RemoteLaunch-User-Guide/RemoteLaunch-Guide/#scheduling-remotelaunchx","title":"Scheduling RemoteLaunchX","text":"Unlike the main RemoteLaunch application, RemoteLaunchX does not have a built-in timer and so when executed it will run once, check for pending test sets and then exit. If you want to have it run on a periodic basis, you will need to schedule it externally. If you are using Microsoft Windows\u00ae you would use the Windows Task Scheduler and in other operating systems you would setup a CRON job. We recommend scheduling RemoteLaunchX to run every 5 minutes.
"},{"location":"RemoteLaunch-User-Guide/RemoteLaunch-Guide/#customizing-the-reporting","title":"Customizing the Reporting","text":"By default, RemoteLaunchX will use the following rules to determine if a test has passed, failed, blocked or passed with warnings (caution) Note that regular expressions are case sensitive by default. To make them case insensitive, simply add the (?i) flag to the beginning just as in the fail-regex below.
Passed -- The test completed and the console output didn't contain any of the error phrases listed in the other rules (below).
Failed -- The test completed and the console output contained the phrases \"Error\", \"Fail\" or \"Fatal\".
Caution -- The test completed and the console output contained the phrases \"Warning\", or \"Caution\".
Blocked -- The automated test did not run successfully or the console output contained the phrase \"Blocked\".
You can customize the reporting by changing the Regular Expressions (Regex) and the default test status stored in the config.properties files:
#The regular expressions for each of the possible execution statuses\n\npass-regex = .\\*\nfail-regex = (?i).\\*(Error\\|Fail\\|Fatal).\\*\ncaution-regex = .\\*(Warning\\|Caution).\\*\nblocked-regex = .\\*(Blocked).\\*\n\n#Default status for output not matching any of the regular expressions above\ndefault-test-status = Not Run\nSelenium Remote Control (RC) is a test tool that allows you to write automated web application user interface tests in any programming language against any HTTP website using any mainstream JavaScript-enabled browser. Selenium RC comes in two parts.
A server which can automatically launch and kill supported browsers, and acts as a HTTP proxy for web requests from those browsers.
Client applications that send commands to the Selenium-RC server in a special language (called Selenese) that tell it what operations to perform on the launched web browser.
This section describes how you can use SpiraTest / SpiraTeam (hereafter SpiraTeam) together with RemoteLaunch to schedule and remotely launch instances of Selenium-RC (hereafter just referred to as Selenium) on different computers and have the testing results be transmitted back to SpiraTeam. This allows you to extend your SpiraTeam's test management capabilities to include automated Selenium web tests.
Note: This integration requires at least version 3.0 of SpiraTest/Team and version 1.0 of Selenium-Remote Control.
"},{"location":"RemoteLaunch-User-Guide/Selenium/#installing-the-selenium-engine","title":"Installing the Selenium Engine","text":"This section assumes that you already have a working installation of SpiraTest or SpiraTeam and have installed RemoteLaunch on the various test automation hosts following the instructions in RemoteLaunch Guide. Once those prerequisites are in place, please follow these steps:
Click the \"Add\" button to enter the new test automation engine details page. The fields required are as follows:
Name: This is the short display name of the automation engine. It can be anything that is meaningful to your users.
Description: This is the long description of the automation engine. It can be anything that is meaningful to your users. (Optional)
Active: If checked, the engine is active and able to be used for any project.
Token: This needs to be the assigned unique token for the automation engine and is used to tell RemoteLaunch which engine to actually use for a given test case. For Selenium this should be SeleniumX where 'X' is the version number of the DLL file that you are using.
Once you have finished, click the \"Insert & Close\" button and you will be taken back to the Test Automation list page, with Selenium listed as an available automation engine.
You can modify the Selenium configuration for each of the specific automation hosts, by right-clicking on the RemoteLaunch icon in the system tray and choosing \"Configuration\". That will bring up the RemoteLaunch configuration page.
a) Selenium-RC 1.0
The Selenium 1.0 engine adds its own tab to this page which allows you to configure how Selenium operates:
The following fields can be specified on this screen:
Server Host -- This should be the name / IP address of the Selenium server. Typically this will be localhost because RemoteLaunch is usually installed on the Selenium server itself.
Server Port -- This should be set to the custom port that the Selenium server uses as a proxy when intercepting requests to the browser. The default value is 4444.
Browser String -- This needs to be the name of the browser that the Selenium server will launch. Common values include:
*firefox -- This will launch the Firefox web browser
*iexplore -- This will launch the Microsoft Internet Explorer web browser
*safari -- This will launch the Apple Safari web browser
Browser URL -- This needs to be the initial URL that you want the browser to open to
a) Selenium WebDriver 2.x
The Selenium 2.x engine adds its own tab to this page which allows you to configure how Selenium operates:
The following fields can be specified on this screen:
Browser Type -- This needs to be set to the type of browser that the Selenium webdriver will launch.
Browser URL -- This needs to be the initial URL that you want the browser to open to
"},{"location":"RemoteLaunch-User-Guide/Selenium/#setting-up-the-automated-test-cases","title":"Setting up the Automated Test Cases","text":"This section describes the process for setting up a test case in SpiraTeam for automation and either linking it to an existing Selenium test script file or entering a Selenium test script directly into SpiraTeam.
"},{"location":"RemoteLaunch-User-Guide/Selenium/#attaching-a-selenium-test-script","title":"Attaching a Selenium Test Script","text":"First you need to display the list of test cases in SpiraTeam (by clicking Testing > Test Cases) and then add a new test case. Once you have added the new test case, click on it and select the \"Automation\" tab:
You need to enter the following fields:
Automation Engine - Choose the Selenium Automation Engine that you created in the previous section from the drop-down list.
Script Type -- This should be set to Attached for this case
Filename -- Since the test script is going to be entered directly into SpiraTeam you can enter any name you like for the filename as long as it's logical and memorable.
Document Type -- you can choose which document type the automated test script will be categorized under.
Document Folder -- you can choose which document folder the automated test script will be stored in.
Version -- The version of the test script (1.0 is used if no value specified)
Test Script -- This needs to contain the complete Selenium test script written in Selenium IDE Selenese. Selenium IDE test scripts consist of three parts:
The command
The target of the command
The data to be used
You should enter the three components on each line separated by the Pipe (|) character. If you need to use a pipe character inside any of the components you can escape it with a backslash (\\|).
An example command would be type|q|hello
If the command doesn't need all three components, you can simply leave it out (for example open||http://www.inflectra.com)
If you would like to have SpiraTeam pass any parameter values to this test script (this will be discussed in more detail later) you can specify them by using the syntax ${parameterName}.
A complete sample script is illustrated below:
open||http://www.google.com/webhp
assertTitle||Google
type|q|${query}
click|btnG
waitForPageToLoad||5000
isTextPresent||${matchtext}
Once you are happy with the values, click [Save] to update the test case. Now you are ready to schedule the automated test case for execution.
"},{"location":"RemoteLaunch-User-Guide/Selenium/#linking-a-selenium-test-script","title":"Linking a Selenium Test Script","text":"First you need to display the list of test cases in SpiraTeam (by clicking Testing > Test Cases) and then add a new test case. Once you have added the new test case, click on it and select the \"Automation\" tab:
You need to enter the following fields:
Automation Engine - Choose the Selenium Automation Engine that you created in the previous section from the drop-down list.
Script Type -- This should be set to Linked for this case
Filename -- This needs to be the full path to the Selenium IDE test script file. To make this easier across different machines, you can use several constants for standard Windows locations:
[MyDocuments] -- The user's \"My Documents\" folder. The user indicated is the user that ran RemoteLaunch.
[CommonDocuments] -- The Public Document's folder.
[DesktopDirectory] -- The user's Desktop folder. The user indicated is the user that ran RemoteLaunch.
[ProgramFiles] -- Translated to the Program Files directory. For 64-bit machines, it's the 64-bit directory.
[ProgramFilesX86] -- Translated to the 32-bit Program Files directory.
Document Type -- If using SpiraTeam (not SpiraTest) you can choose which document type the automated test script will be categorized under.
Document Folder -- If using SpiraTeam (not SpiraTest) you can choose which document folder the automated test script will be stored in.
Version -- The version of the test script (1.0 is used if no value specified)
Test Script -- This is not used when you are using the linked test script option
The linked test script needs to be an HTML document that contains a table with three columns. Each row corresponds to a single Selenium action. Each of the columns in the row corresponds to the three Selenium command components:
The command
The target of the command
The data to be used
An example Selenium test script is illustrated below:
<html>\n <body>\n <table>\n <tr>\n <td>\n open\n </td>\n <td> \n </td>\n <td>\n http://www.google.com/webhp\n </td>\n </tr>\n <tr>\n <td>\n assertTitle</td>\n <td> \n </td>\n <td>\n Google</td>\n </tr>\n <tr>\n <td>\n type</td>\n <td> \n q</td>\n <td>\n ${query}</td>\n </tr>\n <tr>\n <td>\n click</td>\n <td> \n btnG</td>\n <td>\n </td>\n </tr>\n <tr>\n <td>\n waitForPageToLoad</td>\n <td> \n </td>\n <td>\n 5000</td>\n </tr>\n <tr>\n <td>\n isTextPresent</td>\n <td> \n </td>\n <td>\n ${matchtext}</td>\n </tr>\n </table>\n </body>\n</html>\nWhen opened in an HTML editing tool it looks like:
open http://www.google.com/webhp assertTitle Google type q ${query} click btnG waitForPageToLoad 5000 isTextPresent ${matchtext}If you would like to have SpiraTeam pass any parameter values to this test script (this will be discussed in more detail later) you can specify them by using the syntax ${parameterName}.
An example parameterized command is displayed in the third and sixth rows of the table above (${query} and ${matchtext}).
Once you are happy with the values, click [Save] to update the test case. Now you are ready to schedule the automated test case for execution.
"},{"location":"RemoteLaunch-User-Guide/Selenium/#using-parameterized-test-cases","title":"Using Parameterized Test Cases","text":"There is an advanced feature of SpiraTest/Team and RemoteLaunch that lets you pass parameters from SpiraTeam to your Selenium automated test script. This is very useful if you want to have a data-driven Selenium test script that be executed multiple times with different parameter values.
To setup the automated test case for parameters, click on the \"Test Steps\" tab and click on \"Edit Parameters\":
The name of the parameter ${login} needs to match the name of the input parameter defined within the Selenium script.
"},{"location":"RemoteLaunch-User-Guide/Selenium/#executing-the-selenium-test-sets-from-spirateam","title":"Executing the Selenium Test Sets from SpiraTeam","text":"There are two ways to execute automated test cases in SpiraTeam:
Schedule the test cases to be executed on a specific computer (local or remote) at a date/time in the future
Execute the test cases right now on the local computer.
We shall outline both of these two scenarios in this section. However first we need to setup the appropriate automation hosts and test sets in SpiraTeam:
"},{"location":"RemoteLaunch-User-Guide/Selenium/#configuring-the-automation-hosts-and-test-sets","title":"Configuring the Automation Hosts and Test Sets","text":"Go to Testing > Automation Hosts in SpiraTeam to display the list of automation hosts:
Make sure that you have created an Automation Host for each computer that is going to run an automated test case. The name and description can be set to anything meaningful, but the Token field must be set to the same token that is specified in the RemoteLaunch application on that specific machine.
Once you have at least one Automation Host configured, go to Testing > Test Sets to create the test sets that will contain the automated test case:
Note: Unlike manual test cases, automated test cases must be executed within a test set -- they cannot be executed directly from the test case.
Create a new Test Set to hold the Selenium automated test cases and click on its hyperlink to display the test set details page:
You need to add at least one automated test case to the test set and then configure the following fields:
Automation Host -- This needs to be set to the name of the automation host that will be running the automated test set.
Planned Date -- The date and time that you want the scenario to begin. (Note that multiple test sets scheduled at the exact same time will be scheduled by Test Set ID order.)
Status -- This needs to be set to \"Not Started\" for RemoteLaunch to pick up the scheduled test set. When you change the Planned Date, the status automatically switches back to \"Not Started\"
Type -- This needs to be set to \"Automated\" for automated testing
If you have parameterized test cases inside the automated test set you can set their values in three different ways:
Test Set Parameter Values -- this lets you set the same value of a parameter for all the test cases in the test set:
Test Case Parameter Values -- this lets you set a specific value for a parameter for a particular test case in the test set:
You set these values, by right-clicking on a row and choosing \"Edit Parameters\":
Once you have set the various test set fields (as described above), the Remote Launch instances will periodically poll SpiraTeam for new test sets. Once they retrieve the new test set, they will add it to their list of test sets to execute. Once execution begins they will change the status of the test set to \"In Progress\", and once test execution is done, the status of the test set will change to either \"Completed\" -- the automation engine could be launched and the test has completed -- or \"Blocked\" -- RemoteLaunch was not able to start the automation engine.
If you want to immediately execute the test case on your local computer, instead of setting the \"Automation Host\", \"Status\" and \"Planned Date\" fields, you can instead click the [Execute] icon on the test set itself. This will cause RemoteLaunch on the local computer to immediately start executing the current test set.
In either case, once all the test cases in the test set have been completed, the status of the test set will switch to \"Completed\" and the individual test cases in the set will display a status based on the results of the Selenium test:
Passed -- The Selenium automated test ran successfully and all the test conditions in the test script passed
Failed -- The Selenium automated test ran successfully, but at least one test condition in the test script failed.
Blocked -- The Selenium automated test did not run successfully
If you receive the \"Blocked\" status for either the test set or the test cases you should open up the Windows Application Event Log on the computer running RemoteLaunch and look in the event log for error messages.
Note: While the tests are executing you may see browser windows launch as the Selenium server executes the appropriate tests.
Once the tests have completed, you can log back into SpiraTeam and see the execution status of your test cases. If you click on a Test Run that was generated by Selenium, you will see the following information:
This screen indicates the status of the test run that was reported back from Selenium together with any messages or other information. The execution status will be set to PASSED if all the Selenium commands report back OK and all the tests passed. If any of the commands failed or the tests don't pass, the overall execution status will be listed as FAILED.
The Message field will contain a summary of the number of commands executed and the number of failed commands, with the large details box containing the full command execution log as reported back from Selenium:
open (, http://www.google.com/webhp) - OK
assertTitle (, Google) - OK
type (q, Philomene Long) - OK
click (btnG, ) - OK
waitForPageToLoad (, 5000) - OK
isTextPresent (, Philomene Long) - OK,true
Congratulations... You are now able to run Selenium automated web tests and have the results be recorded within SpiraTest / SpiraTeam.
"},{"location":"RemoteLaunch-User-Guide/SmarteScript/","title":"SmarteScript","text":"SmarteSoft\u2122 SmarteScript\u2122 (hereafter SmarteScript) is a Graphic User Interface (GUI) script-free functional test automation system that lets you record application operations by capturing the various testable objects of the application and then playback the operations to automatically test the application.
This section describes how you can use SpiraTest / SpiraTeam (hereafter SpiraTeam) together with RemoteLaunch to schedule and remotely launch instances of SmarteScript on different computers and have the testing results be transmitted back to SpiraTeam. This allows you to extend your SpiraTeam's test management capabilities to include automated SmarteScript tests.
Note: This integration requires at least version 3.0 of SpiraTest/Team and version 5.0 of SmarteScript.
"},{"location":"RemoteLaunch-User-Guide/SmarteScript/#installing-the-smartescript-engine","title":"Installing the SmarteScript Engine","text":"This section assumes that you already have a working installation of SpiraTest or SpiraTeam and have installed RemoteLaunch on the various test automation hosts following the instructions in RemoteLaunch Guide. Once those prerequisites are in place, please follow these steps:
Download and extract the SmarteScriptAutomationEngine.zip file from the Inflectra website and locate the appropriate SmarteScriptX.dll for the version of SmarteScript that you are using.
If you don't see the version listed, just use the nearest version that is lower than your current version.
Copy the file \"SmarteScriptX.dll\" (where X is the appropriate version) into the \"extensions\" sub-folder of the RemoteLaunch installation.
Log in to SpiraTeam as a system administrator and go into SpiraTeam main Administration page and click on the \"Test Automation\" link under Integration.
Click the \"Add\" button to enter the new test automation engine details page. The fields required are as follows:
Name: This is the short display name of the automation engine. It can be anything that is meaningful to your users.
Description: This is the long description of the automation engine. It can be anything that is meaningful to your users. (Optional)
Active: If checked, the engine is active and able to be used for any project.
Token: This needs to be the assigned unique token for the automation engine and is used to tell RemoteLaunch which engine to actually use for a given test case. For SmarteScript this should be SmarteScriptX where 'X' is the version number of the DLL file that you are using.
Once you have finished, click the \"Insert & Close\" button and you will be taken back to the Test Automation list page, with SmarteScript listed as an available automation engine.
This section describes the process for setting up a test case in SpiraTeam for automation and linking it to an automated SmarteScript test script.
First you need to display the list of test cases in SpiraTeam (by clicking Testing > Test Cases) and then add a new test case. Once you have added the new test case, click on it and select the \"Automation\" tab:
You need to enter the following fields:
Automation Engine - Choose the SmarteScript Automation Engine that you created in the previous section from the drop-down list.
Script Type -- This should be set to Linked as the integration with SmarteScript only supports referencing SmarteScript test script file (.ses) and not physically uploading the test scripts into SpiraTeam.
Filename -- This needs to be the full path to the SmarteScript test script (i.e. the .ses file that you open in SmarteScript to run the test). To make this easier across different machines, you can use several constants for standard Windows locations (see example in screenshot):
[MyDocuments] -- The user's \"My Documents\" folder. The user indicated is the user that ran RemoteLaunch.
[CommonDocuments] -- The Public Document's folder.
[DesktopDirectory] -- The user's Desktop folder. The user indicated is the user that ran RemoteLaunch.
[ProgramFiles] -- Translated to the Program Files directory. For 64-bit machines, it's the 64-bit directory.
[ProgramFilesX86] -- Translated to the 32-bit Program Files directory.
Document Type -- If using SpiraTeam (not SpiraTest) you can choose which document type the automated test script will be categorized under.
Document Folder -- If using SpiraTeam (not SpiraTest) you can choose which document folder the automated test script will be stored in.
Version -- The version of the test script (1.0 is used if no value specified)
Test Script -- This is not used with the SmarteScript Engine since it only supports linked test scripts.
Once you are happy with the values, click [Save] to update the test case. Now you are ready to schedule the automated test case for execution.
"},{"location":"RemoteLaunch-User-Guide/SmarteScript/#using-parameterized-test-cases","title":"Using Parameterized Test Cases","text":"SmarteScript does not support the passing of input test parameters so the SmarteScript automation engine does not support this feature of SpiraTeam or RemoteLaunch.
"},{"location":"RemoteLaunch-User-Guide/SmarteScript/#executing-the-smartescript-test-sets-from-spirateam","title":"Executing the SmarteScript Test Sets from SpiraTeam","text":"There are two ways to execute automated test cases in SpiraTeam:
Schedule the test cases to be executed on a specific computer (local or remote) at a date/time in the future
Execute the test cases right now on the local computer.
We shall outline both of these two scenarios in this section. However first we need to setup the appropriate automation hosts and test sets in SpiraTeam:
"},{"location":"RemoteLaunch-User-Guide/SmarteScript/#configuring-the-automation-hosts-and-test-sets","title":"Configuring the Automation Hosts and Test Sets","text":"Go to Testing > Automation Hosts in SpiraTeam to display the list of automation hosts:
Make sure that you have created an Automation Host for each computer that is going to run an automated test case. The name and description can be set to anything meaningful, but the Token field must be set to the same token that is specified in the RemoteLaunch application on that specific machine.
Once you have at least one Automation Host configured, go to Testing > Test Sets to create the test sets that will contain the automated test case:
Note: Unlike manual test cases, automated test cases must be executed within a test set -- they cannot be executed directly from the test case.
Create a new Test Set to hold the SmarteScript automated test cases and click on its hyperlink to display the test set details page:
You need to add at least one automated test case to the test set and then configure the following fields:
Automation Host -- This needs to be set to the name of the automation host that will be running the automated test set.
Planned Date -- The date and time that you want the scenario to begin. (Note that multiple test sets scheduled at the exact same time will be scheduled by Test Set ID order.)
Status -- This needs to be set to \"Not Started\" for RemoteLaunch to pick up the scheduled test set. When you change the Planned Date, the status automatically switches back to \"Not Started\"
Type -- This needs to be set to \"Automated\" for automated testing
Once you have set the various test set fields (as described above), the Remote Launch instances will periodically poll SpiraTeam for new test sets. Once they retrieve the new test set, they will add it to their list of test sets to execute. Once execution begins they will change the status of the test set to \"In Progress\", and once test execution is done, the status of the test set will change to either \"Completed\" -- the automation engine could be launched and the test has completed -- or \"Blocked\" -- RemoteLaunch was not able to start the automation engine.
If you want to immediately execute the test case on your local computer, instead of setting the \"Automation Host\", \"Status\" and \"Planned Date\" fields, you can instead click the [Execute] icon on the test set itself. This will cause RemoteLaunch on the local computer to immediately start executing the current test set.
In either case, once all the test cases in the test set have been completed, the status of the test set will switch to \"Completed\" and the individual test cases in the set will display a status based on the results of the SmarteScript test:
Passed -- The SmarteScript automated test ran successfully and all the test conditions in the test script passed
Failed -- The SmarteScript automated test ran successfully, but at least one test condition in the test script failed.
Blocked -- The SmarteScript automated test did not run successfully
If you receive the \"Blocked\" status for either the test set or the test cases you should open up the Windows Application Event Log on the computer running RemoteLaunch and look in the event log for error messages.
Note: While the tests are executing you may see browser or application windows launch as SmarteScript executes the appropriate tests.
Once the tests have completed, you can log back into SpiraTeam and see the execution status of your test cases. If you click on a Test Run that was generated by SmarteScript, you will see the following information:
This screen indicates the status of the test run that was reported back from SmarteScript together with any messages or other information. The Test Name indicates the name of the test inside SmarteScript, and the execution status corresponds the matching status inside SmarteScript.
Congratulations... You are now able to run SmarteScript automated functional tests and have the results be recorded within SpiraTest / SpiraTeam.
"},{"location":"RemoteLaunch-User-Guide/SoapUI/","title":"SoapUI (ReadyAPI)","text":"SmartBear SoapUI / ReadyAPI (hereafter SoapUI) is an open source Web Service testing tool for Service Oriented Architectures (SOAs). There is also a Pro version (Now known as ReadyAPI) that is released as a commercial product. Its functionality mainly covers Web Service Inspection, Invoking, Development, Simulation and Mocking, Functional testing, Load and Compliance testing. Productivity enhancement features can be found in ReadyAPI (previously known as SoapUI Pro).
This section describes how you can use SpiraPlan / SpiraTest / SpiraTeam (hereafter SpiraTeam) together with RemoteLaunch to schedule and remotely launch instances of soapUI on different computers and have the testing results be transmitted back to SpiraTeam. This allows you to extend your SpiraTeam's test management capabilities to include automated web service testing.
Note: This integration requires at least version 4.0 of SpiraPlan/Team/Test and an instance of SoapUI, SoapUI Pro, or ReadyAPI running on a Windows\u00ae platform.
"},{"location":"RemoteLaunch-User-Guide/SoapUI/#installing-the-soapui-engine","title":"Installing the SoapUI Engine","text":"This section assumes that you already have a working installation of SpiraTest or SpiraTeam and have installed RemoteLaunch on the various test automation hosts following the instructions in RemoteLaunch Guide. Once those prerequisites are in place, please follow these steps:
Download and extract the SoapUIEngine.zip file from the Inflectra website.
Extract the file \"soapUIEngine.dll\" from the compressed archive into the \"extensions\" sub-folder of the RemoteLaunch installation.
Log in to SpiraTeam as a system administrator and go into SpiraTeam main Administration page and click on the \"Test Automation\" link under Integration.
Click the \"Add\" button to enter the new test automation engine details page. The fields required are as follows:
Name: This is the short display name of the automation engine. It can be anything that is meaningful to your users. Description: This is the long description of the automation engine. It can be anything that is meaningful to your users. (Optional)
Active: If checked, the engine is active and able to be used for any project.
Token: This needs to be the assigned unique token for the automation engine and is used to tell RemoteLaunch which engine to actually use for a given test case. For soapUI this should be SoapUI.
Once you have finished, click the \"Insert & Close\" button and you will be taken back to the Test Automation list page, with SoapUI listed as an available automation engine.
You will need to modify the SoapUI configuration for each of the specific automation hosts, by right-clicking on the RemoteLaunch icon in the system tray and choosing \"Configuration\". That will bring up the RemoteLaunch configuration page. The SoapUI engine adds its own tab to this page which allows you to configure how SoapUI operates:
The following fields can be specified on this screen:
SOAP-UI Location -- This should be SOAP-UI Bin folder that contains the \"TestRunner.bat\" batch file that will be used to actually run the automated tests.
Installation Type -- This allows you to take advantage of the enhanced reporting available in the commercial \"Pro\" edition of SoapUI. Check the \"SOAP-UI Pro Installation\" box only if you are using the commercial version of SoapUI (known as SoapUI Pro).
Execution Type -- If this is a LoadUI performance test rather than a standard SoapUI functional test, check the box and RemoteLaunch will know to parse the load-test report format.
Trace Logging -- Normally this can be left unchecked unless you are diagnosing configuration issues and need additional logging.
"},{"location":"RemoteLaunch-User-Guide/SoapUI/#setting-up-the-automated-test-cases","title":"Setting up the Automated Test Cases","text":"This section describes the process for setting up a test case in SpiraTeam for automation and linking it to an existing SoapUI test suite and test case.
"},{"location":"RemoteLaunch-User-Guide/SoapUI/#linking-a-soapui-test-script","title":"Linking a SoapUI Test Script","text":"First you need to display the list of test cases in SpiraTeam (by clicking Testing > Test Cases) and then add a new test case. Once you have added the new test case, click on it and expand the \"Automation\" section of the Test Case Overview tab:
You need to enter the following fields:
Automation Engine - Choose the SoapUI Automation Engine that you created in the previous section from the drop-down list.
Script Type -- This should be set to Linked for this case
Filename -- This needs to be the full path to the SoapUi test project XML file or composite folder together with the test suite name and test case name separated by the pipe (|) symbol. You can also pass custom command line switches as an optional final segment
For standard tests, you use the format:
Project XML File|Test Suite Name|Test Case Name|Switches
For composite folder tests, you use the format:
Test Folder|Test Suite Name|Test Case Name|Switches
For example if the test suite was named \"Requirements Testing\" and the test case was named \"Get Requirements\" you'd use:
[MyDocuments]\\SpiraTest-4-0-Web-Service-soapui-project.xml|Requirements Testing|Get Requirements
To make this easier across different machines, you can use several constants for standard Windows locations:
[MyDocuments] -- The user's \"My Documents\" folder. The user indicated is the user that ran RemoteLaunch.
[CommonDocuments] -- The Public Document's folder.
[DesktopDirectory] -- The user's Desktop folder. The user indicated is the user that ran RemoteLaunch.
[ProgramFiles] -- Translated to the Program Files directory. For 64-bit machines, it's the 64-bit directory.
[ProgramFilesX86] -- Translated to the 32-bit Program Files directory.
Document Type -- You can choose which document type the automated test script will be categorized under.
Document Folder -- You can choose which document folder the automated test script will be stored in.
Version -- The version of the test script (1.0 is used if no value specified)
Test Script -- This is not used when you are using the linked test script option
Note: The example filename shown above was taken from a test project in SoapUI that has the following structure:
Once you are happy with the values, click [Save] to update the test case. Now you are ready to schedule the automated test case for execution.
"},{"location":"RemoteLaunch-User-Guide/SoapUI/#using-parameterized-test-cases","title":"Using Parameterized Test Cases","text":"There is an advanced feature of SpiraTest/Team and RemoteLaunch that lets you pass parameters from SpiraTeam to your SoapUI automated test. This is very useful if you have a data-driven SoapUI test that has custom project properties used that you would like to change based on the test.
To setup the automated test case for parameters, click on the \"Test Steps\" tab and click on \"Edit Parameters\":
The name of the parameter ${login} needs to match the name of the custom parameter defined in the SoapUI project properties. Invalid parameters will be silently ignored by the SoapUI engine. Parameters must have a unique name. Note that the plugin currently only supports \"Project Properties\" and not Global or System Properties.
"},{"location":"RemoteLaunch-User-Guide/SoapUI/#executing-the-soapui-test-sets-from-spirateam","title":"Executing the SoapUI Test Sets from SpiraTeam","text":"There are three ways to execute automated test cases in SpiraTeam:
Schedule the test cases to be executed on a specific computer (local or remote) at a date/time in the future
Execute the test cases right now on the local computer.
Execute the test cases from the command-line or a build script
We shall outline each of these three scenarios in this section. However first we need to setup the appropriate automation hosts and test sets in SpiraTeam:
"},{"location":"RemoteLaunch-User-Guide/SoapUI/#configuring-the-automation-hosts-and-test-sets","title":"Configuring the Automation Hosts and Test Sets","text":"Go to Testing > Automation Hosts in SpiraTeam to display the list of automation hosts:
Make sure that you have created an Automation Host for each computer that is going to run an automated test case. The name and description can be set to anything meaningful, but the Token field must be set to the same token that is specified in the RemoteLaunch application on that specific machine.
Once you have at least one Automation Host configured, go to Testing > Test Sets to create the test sets that will contain the automated test case:
Note: Unlike manual test cases, automated test cases must be executed within a test set -- they cannot be executed directly from the test case.
Create a new Test Set to hold the SoapUI automated test cases and click on its hyperlink to display the test set details page:
You need to add at least one automated test case to the test set and then configure the following fields:
Automation Host -- This needs to be set to the name of the automation host that will be running the automated test set.
Planned Date -- The date and time that you want the scenario to begin. (Note that multiple test sets scheduled at the exact same time will be scheduled by Test Set ID order.)
Status -- This needs to be set to \"Not Started\" for RemoteLaunch to pick up the scheduled test set. When you change the Planned Date, the status automatically switches back to \"Not Started\"
Type -- This needs to be set to \"Automated\" for automated testing
If you have parameterized test cases inside the automated test set you can set their values in three different ways:
Test Set Parameter Values -- this lets you set the same value of a parameter for all the test cases in the test set:
Test Case Parameter Values -- this lets you set a specific value for a parameter for a particular test case in the test set:
You set these values, by right-clicking on a row and choosing \"Edit Parameters\":
Once you have set the various test set fields (as described above), the Remote Launch instances will periodically poll SpiraTeam for new test sets. Once they retrieve the new test set, they will add it to their list of test sets to execute. Once execution begins they will change the status of the test set to \"In Progress\", and once test execution is done, the status of the test set will change to either \"Completed\" -- the automation engine could be launched and the test has completed -- or \"Blocked\" -- RemoteLaunch was not able to start the automation engine.
If you want to immediately execute the test case on your local computer, instead of setting the \"Automation Host\", \"Status\" and \"Planned Date\" fields, you can instead click the [Execute] icon on the test set itself. This will cause RemoteLaunch on the local computer to immediately start executing the current test set.
If you want to run the tests as part of a build script, just call RemoteLaunch.exe with the appropriate test set id passed into the command-line:
RemoteLaunch.exe --testset:18
In all cases, once all the test cases in the test set have been completed, the status of the test set will switch to \"Completed\" and the individual test cases in the set will display a status based on the results of the SoapUI test:
Passed -- The SoapUI automated test ran successfully and all the assertions in the test script passed
Failed -- The SoapUI automated test ran successfully, but at least one assertion in the test script failed.
Blocked -- The SoapUI automated test did not run successfully
If you receive the \"Blocked\" status for either the test set or the test cases you should open up the Windows Application Event Log on the computer running RemoteLaunch and look in the event log for error messages.
Note: While the tests are executing you may see application or browser windows launch as the SoapUI server executes the appropriate tests.
Once the tests have completed, you can log back into SpiraTeam and see the execution status of your test cases. If you click on a Test Run that was generated by SoapUI, you will see the following information:
This screen indicates the status of the test run that was reported back from SoapUI together with any messages or other information. The execution status will be set according to the worst-case assessment reported back from SoapUI. If you have zero(0) failures, then the status will display as Passed, otherwise it will display as Failed.
Under Console Output section you will see more detailed logging information (in both SoapUI and SoapUI Pro):
The Message field will contain a summary of the number of test steps completed, the number of assertions and the number of failed assertions. The Details field will contain the detailed trace of what happened, captured from the summary output log that is generated by SoapUI.
SoapUI Pro
If you have the commercial SoapUI Pro product and have configured RemoteLaunch so that it knows to use SoapUI Pro, in addition, the Test Steps section of the test run will contain more detailed reporting:
Where each test step corresponds to a step recorded in the SoapUI Pro results file.
Congratulations... You are now able to run SoapUI automated web-service tests and have the results be recorded within SpiraTest / SpiraTeam.
"},{"location":"RemoteLaunch-User-Guide/Squish/","title":"Squish","text":"Froglogic\u00ae Squish\u00ae (hereafter Squish) is a functional test automation system that lets you record application operations and generate test automation scripts in a variety of different scripting languages (JavaScript, Tcl, Python) that can be used to playback the test script against the test application.
This section describes how you can use SpiraTest / SpiraTeam (hereafter SpiraTeam) together with RemoteLaunch to schedule and remotely launch instances of Squish on different computers and have the testing results be transmitted back to SpiraTeam. This allows you to extend your SpiraTeam's test management capabilities to include automated Squish tests.
Note: This integration requires at least version 3.0 of SpiraTest/Team and version 4.0 of Squish running on a Windows\u00ae platform.
"},{"location":"RemoteLaunch-User-Guide/Squish/#installing-the-squish-engine","title":"Installing the Squish Engine","text":"This section assumes that you already have a working installation of SpiraTest or SpiraTeam and have installed RemoteLaunch on the various test automation hosts following the instructions in RemoteLaunch Guide. Once those prerequisites are in place, please follow these steps:
Download and extract the SquishAutomationEngine.zip file from the Inflectra website and locate the appropriate SquishX.dll for the version of Squish that you are using.
Copy the file \"SquishX.dll\" (where X is the appropriate version) into the \"extensions\" sub-folder of the RemoteLaunch installation.
Log in to SpiraTeam as a system administrator and go into SpiraTeam main Administration page and click on the \"Test Automation\" link under Integration.
Click the \"Add\" button to enter the new test automation engine details page. The fields required are as follows:
Name: This is the short display name of the automation engine. It can be anything that is meaningful to your users.
Description: This is the long description of the automation engine. It can be anything that is meaningful to your users. (Optional)
Active: If checked, the engine is active and able to be used for any project.
Token: This needs to be the assigned unique token for the automation engine and is used to tell RemoteLaunch which engine to actually use for a given test case. For Squish this should be SquishX where 'X' is the version number of the DLL file that you are using.
Once you have finished, click the \"Insert & Close\" button and you will be taken back to the Test Automation list page, with Squish listed as an available automation engine.
You will need to modify the Squish configuration for each of the specific automation hosts, by right-clicking on the RemoteLaunch icon in the system tray and choosing \"Configuration\". That will bring up the RemoteLaunch configuration page. The Squish engine adds its own tab to this page which allows you to configure how Squish operates:
The following fields can be specified on this screen:
Squish Location -- This should be folder containing the \"SquishRunner\" executable that will be used to actually run the automated tests.
Server Host -- This field can be set to the name of a remote Squish server if you did not install RemoteLaunch on the machine running the Squish server (optional).
Server Port -- This field can be set to the port being used by a remote Squish server if you did not install RemoteLaunch on the machine running the Squish server (optional).
Trace Logging -- This checkbox can be selected if you need to provide debugging information to Inflectra support personnel. Normally this should remain unchecked
Note: In most cases, the second and third fields can be left empty.
"},{"location":"RemoteLaunch-User-Guide/Squish/#setting-up-the-automated-test-cases","title":"Setting up the Automated Test Cases","text":"This section describes the process for setting up a test case in SpiraTeam for automation and either linking it to an existing Squish test suite, test case or entering a Squish test script directly into SpiraTeam.
Note: that the Squish engine only supports passing parameters to an attached test script and not to a linked test script.
"},{"location":"RemoteLaunch-User-Guide/Squish/#attaching-a-squish-test-script","title":"Attaching a Squish Test Script","text":"First you need to display the list of test cases in SpiraTeam (by clicking Testing > Test Cases) and then add a new test case. Once you have added the new test case, click on it and select the \"Automation\" tab:
You need to enter the following fields:
Automation Engine - Choose the Squish Automation Engine that you created in the previous section from the drop-down list.
Script Type -- This should be set to Attached for this case
Filename -- Since the test script is going to be entered directly into SpiraTeam you can enter any filename you like as long as the file extension matches the scripting language that you're using. After that you need to add any command-line parameters after the filename, separated by a pipe (|) symbol.
For example, to launch a web test using Javascript, you'd use: address_test.js|--wrapper Web
For example, to launch an application test using Python, you'd use: address_test.py|--aut <application>
Document Type -- If using SpiraTeam (not SpiraTest) you can choose which document type the automated test script will be categorized under.
Document Folder -- If using SpiraTeam (not SpiraTest) you can choose which document folder the automated test script will be stored in.
Version -- The version of the test script (1.0 is used if no value specified)
Test Script -- This needs to contain the complete Squish test script. Squish test scripts can be written in JavaScript, Python or TCL.
A complete sample script (illustrating the use of parameters) is illustrated below:
function main()\n{\n// open URL\nloadUrl(\":http://address.icefaces.org/address/\");\n\n// wait for the first entry object to be available\nwaitForObject(\":_id0:title_select-one\");\n\n// check that the submit button is disabled\ntest.compare(findObject(\":_id0:Submit_image\").disabled, true);\n\n// enter data\nselectOption(\":_id0:title_select-one\", \"${title}\");\nsetText(\":_id0:firstName_text\", \"${firstname}\");\nsetText(\":_id0:lastName_text\", \"${lastname}\");\nsetText(\":_id0:city_text\", \"${city}\");\n\n// check that after entering city, the state is automatically chosen correctly\nvar state = \"${state}\";\nsetFocus(\":_id0:state_text\");\nif (!test.verify(waitFor(\"findObject(':_id0:state_text').value == state\", 10000)))\n{\nclickButton(\":_id0:Reset_image\");\ncontinue;\n}\n\n// input ZIP\nselectOption(\":_id0:zipSelect_select-one\", \"${zip}\");\n\n// check that submit button is enabled now\nsetFocus(\":_id0:lastName_text\");\nif (!test.verify(waitFor(\"findObject(':_id0:Submit_image').disabled == false\", 10000)))\n{\nclickButton(\":_id0:Reset_image\");\n}\n\n// submit\nclickButton(\":_id0:Submit_image\");\n\n// wait for results page\nwaitForContextExists(\":response.iface\");\nwaitForObject(\":_id1:_id3_SPAN\");\n\n// verify that data is stored and displayed correctly\ntest.compare(findObject(\":_id1:_id3_SPAN\").innerText, firstName);\ntest.compare(findObject(\":_id1:_id6_SPAN\").innerText, state);\n\n// close browser\ncloseWindow(\":[Window]\");\n}\nOnce you are happy with the values, click [Save] to update the test case. Now you are ready to schedule the automated test case for execution.
"},{"location":"RemoteLaunch-User-Guide/Squish/#linking-a-squish-test-script","title":"Linking a Squish Test Script","text":"First you need to display the list of test cases in SpiraTeam (by clicking Testing > Test Cases) and then add a new test case. Once you have added the new test case, click on it and select the \"Automation\" tab:
You need to enter the following fields:
Automation Engine - Choose the Squish Automation Engine that you created in the previous section from the drop-down list.
Script Type -- This should be set to Linked for this case
Filename -- This needs to be the full path to the Squish test case or test suite folder.
If specifying a test case folder, you need to also provide the configuration command-line parameters after the filename, separated by a pipe (|) symbol. These are not needed if executing a test suite, since they are contained in the suite.conf file instead.
For example, to launch a web test case you'd use: [ProgramFiles]\\Froglogic\\squish-4.0.1-web-win32\\examples\\web\\suite_examples\\tst_icefaces_addressbook_datadriven|--wrapper Web
For example, to launch a web test suite you'd simply use: [ProgramFiles]\\Froglogic\\squish-4.0.1-web-win32\\examples\\web\\suite_examples
For example, to launch a web test case within a test suite you'd use the path of the test suite, followed by the pipe (|) symbol, followed by the test case name: [ProgramFiles]\\Froglogic\\squish-4.0.1-web-win32\\examples\\web\\suite_examples|tst_icefaces
To make this easier across different machines, you can use several constants for standard Windows locations:
[MyDocuments] -- The user's \"My Documents\" folder. The user indicated is the user that ran RemoteLaunch.
[CommonDocuments] -- The Public Document's folder.
[DesktopDirectory] -- The user's Desktop folder. The user indicated is the user that ran RemoteLaunch.
[ProgramFiles] -- Translated to the Program Files directory. For 64-bit machines, it's the 64-bit directory.
[ProgramFilesX86] -- Translated to the 32-bit Program Files directory.
Document Type -- If using SpiraTeam (not SpiraTest) you can choose which document type the automated test script will be categorized under.
Document Folder -- If using SpiraTeam (not SpiraTest) you can choose which document folder the automated test script will be stored in.
Version -- The version of the test script (1.0 is used if no value specified)
Test Script -- This is not used when you are using the linked test script option
Once you are happy with the values, click [Save] to update the test case. Now you are ready to schedule the automated test case for execution.
"},{"location":"RemoteLaunch-User-Guide/Squish/#using-parameterized-test-cases","title":"Using Parameterized Test Cases","text":"There is an advanced feature of SpiraTest/Team and RemoteLaunch that lets you pass parameters from SpiraTeam to your attached (not linked) Squish automated test script. This is very useful if you want to have a data-driven Squish test script that be executed multiple times with different parameter values.
To setup the automated test case for parameters, click on the \"Test Steps\" tab and click on \"Edit Parameters\":
The name of the parameter ${city} needs to match the name of the parameter defined within the attached Squish script.
"},{"location":"RemoteLaunch-User-Guide/Squish/#executing-the-squish-test-sets-from-spirateam","title":"Executing the Squish Test Sets from SpiraTeam","text":"There are two ways to execute automated test cases in SpiraTeam:
Schedule the test cases to be executed on a specific computer (local or remote) at a date/time in the future
Execute the test cases right now on the local computer.
We shall outline both of these two scenarios in this section. However first we need to setup the appropriate automation hosts and test sets in SpiraTeam:
"},{"location":"RemoteLaunch-User-Guide/Squish/#configuring-the-automation-hosts-and-test-sets","title":"Configuring the Automation Hosts and Test Sets","text":"Go to Testing > Automation Hosts in SpiraTeam to display the list of automation hosts:
Make sure that you have created an Automation Host for each computer that is going to run an automated test case. The name and description can be set to anything meaningful, but the Token field must be set to the same token that is specified in the RemoteLaunch application on that specific machine.
Once you have at least one Automation Host configured, go to Testing > Test Sets to create the test sets that will contain the automated test case:
Note: Unlike manual test cases, automated test cases must be executed within a test set -- they cannot be executed directly from the test case.
Create a new Test Set to hold the Squish automated test cases and click on its hyperlink to display the test set details page:
You need to add at least one automated test case to the test set and then configure the following fields:
Automation Host -- This needs to be set to the name of the automation host that will be running the automated test set.
Planned Date -- The date and time that you want the scenario to begin. (Note that multiple test sets scheduled at the exact same time will be scheduled by Test Set ID order.)
Status -- This needs to be set to \"Not Started\" for RemoteLaunch to pick up the scheduled test set. When you change the Planned Date, the status automatically switches back to \"Not Started\"
Type -- This needs to be set to \"Automated\" for automated testing
If you have parameterized test cases inside the automated test set you can set their values in three different ways:
Test Set Parameter Values -- this lets you set the same value of a parameter for all the test cases in the test set:
Test Case Parameter Values -- this lets you set a specific value for a parameter for a particular test case in the test set:
You set these values, by right-clicking on a row and choosing \"Edit Parameters\":
Once you have set the various test set fields (as described above), the Remote Launch instances will periodically poll SpiraTeam for new test sets. Once they retrieve the new test set, they will add it to their list of test sets to execute. Once execution begins they will change the status of the test set to \"In Progress\", and once test execution is done, the status of the test set will change to either \"Completed\" -- the automation engine could be launched and the test has completed -- or \"Blocked\" -- RemoteLaunch was not able to start the automation engine.
If you want to immediately execute the test case on your local computer, instead of setting the \"Automation Host\", \"Status\" and \"Planned Date\" fields, you can instead click the [Execute] icon on the test set itself. This will cause RemoteLaunch on the local computer to immediately start executing the current test set.
In either case, once all the test cases in the test set have been completed, the status of the test set will switch to \"Completed\" and the individual test cases in the set will display a status based on the results of the Squish test:
Passed -- The Squish automated test ran successfully and all the test conditions in the test script passed
Failed -- The Squish automated test ran successfully, but at least one test condition in the test script failed.
Blocked -- The Squish automated test did not run successfully
If you receive the \"Blocked\" status for either the test set or the test cases you should open up the Windows Application Event Log on the computer running RemoteLaunch and look in the event log for error messages.
Note: While the tests are executing you may see application or browser windows launch as the Squish server executes the appropriate tests.
Once the tests have completed, you can log back into SpiraTeam and see the execution status of your test cases. If you click on a Test Run that was generated by Squish, you will see the following information:
This screen indicates the status of the test run that was reported back from Squish together with any messages or other information. The execution status will be set according to the worst-case assessment reported back from Squish. The various Squish statuses are mapped to their nearest equivalent SpiraTeam statuses as illustrated below:
Squish Status SpiraTeam Status PASS Passed FAIL Failed WARNING Caution FATAL Blocked ERROR Failed
In addition, the Message field will contain a summary of the number of tests completed and the number of tests that reported an error, fatal, fail, pass or warning status.
2010-11-02T16:50:01-04:00 START_TEST suite_examples
2010-11-02T16:50:01-04:00 START_TEST tst_icefaces_addressbook_datadriven
2010-11-02T16:50:05-04:00 PASS Comparison 'true' and 'true' are equal
2010-11-02T16:50:25-04:00 PASS Verified True expression
2010-11-02T16:50:30-04:00 PASS Verified True expression
2010-11-02T16:50:32-04:00 PASS Comparison 'Reginald' and 'Reginald' are equal
2010-11-02T16:50:33-04:00 PASS Comparison 'CA' and 'CA' are equal
2010-11-02T16:50:40-04:00 PASS Comparison 'true' and 'true' are equal
2010-11-02T16:50:59-04:00 PASS Verified True expression
2010-11-02T16:51:09-04:00 PASS Verified True expression
2010-11-02T16:51:12-04:00 PASS Comparison 'Tanja' and 'Tanja' are equal
2010-11-02T16:51:12-04:00 PASS Comparison 'NY' and 'NY' are equal
Congratulations... You are now able to run Squish automated web tests and have the results be recorded within SpiraTest / SpiraTeam.
"},{"location":"RemoteLaunch-User-Guide/TestComplete/","title":"TestComplete","text":"SmarteBear\u2122 TestComplete\u2122 (hereafter TestComplete) is an automated functional test automation system that lets you record application operations and generate test automation scripts in a variety of languages (JavaScript, C#, VBScript). These test scripts can then be used to playback the test script against the test application and verify that it works correctly.
This section describes how you can use SpiraTest / SpiraTeam (hereafter SpiraTeam) together with RemoteLaunch to schedule and remotely launch instances of TestComplete on different computers and have the testing results be transmitted back to SpiraTeam. This allows you to extend your SpiraTeam's test management capabilities to include automated TestComplete tests.
Note: This integration requires at least version 3.0 of SpiraTest/Team and version 8.0 of TestComplete.
"},{"location":"RemoteLaunch-User-Guide/TestComplete/#installing-the-testcomplete-engine","title":"Installing the TestComplete Engine","text":"This section assumes that you already have a working installation of SpiraTest or SpiraTeam and have installed RemoteLaunch on the various test automation hosts following the instructions in RemoteLaunch Guide. Once those prerequisites are in place, please follow these steps:
Download and extract the TestCompleteAutomationEngine.zip file from the Inflectra website and locate the appropriate TestCompleteX.dll or TestExecuteX.dll for the version of TestComplete or TestExecute that you are using.
If you don't see the version listed, just use the nearest version that is lower than your current version.
Copy the file \"TestCompleteX.dll\" or \"TestExecuteX.dll\" (where X is the appropriate version) into the \"extensions\" sub-folder of the RemoteLaunch installation.
Log in to SpiraTeam as a system administrator and go into SpiraTeam main Administration page and click on the \"Test Automation\" link under Integration.
Click the \"Add\" button to enter the new test automation engine details page. The fields required are as follows:
Name: This is the short display name of the automation engine. It can be anything that is meaningful to your users.
Description: This is the long description of the automation engine. It can be anything that is meaningful to your users. (Optional)
Active: If checked, the engine is active and able to be used for any project.
Token: This needs to be the assigned unique token for the automation engine and is used to tell RemoteLaunch which engine to actually use for a given test case. For TestComplete this should be TestCompleteX where 'X' is the version number of the DLL file that you are using. For TestExecute this should be TestExecuteX where 'X' is the version number of the DLL file that you are using.
Note: We only use the major version numbers for the token name. So the DLLs TestComplete9.0.dll and TestComplete9.1.dll would both use Token = \"TestComplete9\".
You can modify the TestComplete configuration for each of the specific automation hosts, by right-clicking on the RemoteLaunch icon in the system tray and choosing \"Configuration\". That will bring up the RemoteLaunch configuration page.
The TestComplete engine adds its own tab to this page which allows you to configure how TestComplete operates:
The following fields can be specified on this screen:
Wait Time -- This should be set to the amount of time TestComplete needs on this workstation to close the currently open test. The default value is 10000ms (10 seconds). If you get error messages that TestComplete is still open, you need to increase this value.
Application Visible -- This allows you to configure whether the TestComplete application is displayed during test execution or is kept hidden. The default is for it to be hidden.
Close TC After Each Test -- When this is selected, the plugin will close the TestComplete application after each test executes. We generally recommend leaving this disabled as the startup and closedown of TestComplete can sometimes interfere with the tests being executed.
"},{"location":"RemoteLaunch-User-Guide/TestComplete/#setting-up-the-automated-test-cases","title":"Setting up the Automated Test Cases","text":"This section describes the process for setting up a test case in SpiraTeam for automation and linking it to an automated TestComplete test script.
First you need to display the list of test cases in SpiraTeam (by clicking Testing > Test Cases) and then add a new test case. Once you have added the new test case, click on it and select the \"Automation\" tab:
You need to enter the following fields:
Automation Engine - Choose the TestComplete Automation Engine that you created in the previous section from the drop-down list.
Script Type -- This should be set to Linked as the integration with TestComplete only supports referencing TestComplete test project/suite file paths and not physically uploading the test scripts into SpiraTeam.
Filename -- This is actually a compound of several different components that need to be entered, separated by the pipe (|) symbol. The syntax depends on whether we want to associate the SpiraTeam test case with a specific project item or with a specific test routine. If you want to use parameterized test cases, you need to link it with a specific routine (see below for more details on parameters).
If you want to execute a specific project item, the filename should consist of
Suite Filename|Project Name|Project Item Name
(e.g. [CommonDocuments]\\TestComplete 7 Samples\\Open Apps\\OrdersDemo\\C#\\TCProject\\Orders.pjs|Orders_C#_C#Script|ProjectTestItem1)
If you want to execute a specific test routine, the filename should consist of
Suite Filename|Project Name|Unit Name|Routine Name
(e.g. [CommonDocuments]\\TestComplete 7 Samples\\Scripts\\Hello\\Hello.pjs|Hello_C#Script|hello_cs|Hello)
In the case of executing a specific test routine, the last component (the routine name) is actually the name of the function in the test script itself.
As illustrated in the examples, for the Test Suite filename, you can use several constants for standard Windows locations to make things easier:
[MyDocuments] -- The user's \"My Documents\" folder. The user indicated is the user that ran RemoteLaunch.
[CommonDocuments] -- The Public Document's folder.
[DesktopDirectory] -- The user's Desktop folder. The user indicated is the user that ran RemoteLaunch.
[ProgramFiles] -- Translated to the Program Files directory. For 64-bit machines, it's the 64-bit directory.
[ProgramFilesX86] -- Translated to the 32-bit Program Files directory.
Document Type -- If using SpiraTeam (not SpiraTest) you can choose which document type the automated test script will be categorized under.
Document Folder -- If using SpiraTeam (not SpiraTest) you can choose which document folder the automated test script will be stored in.
Version -- The version of the test script (1.0 is used if no value specified)
Test Script -- This is not used with the TestComplete Engine since it only supports linked test scripts.
Once you are happy with the values, click [Save] to update the test case. Now you are ready to schedule the automated test case for execution.
"},{"location":"RemoteLaunch-User-Guide/TestComplete/#using-parameterized-test-cases","title":"Using Parameterized Test Cases","text":"There is an advanced feature of SpiraTest/Team and RemoteLaunch that lets you pass parameters from SpiraTeam to your TestComplete automated test script. This is very useful if you have a data-driven TestComplete test script that accepts input parameters. To use this feature you need to use the option described above to link the SpiraTest test case to an explicit test routine inside TestComplete. If you choose the option to link to a Project Item, any parameters passed will be ignored.
To setup the automated test case for parameters, click on the \"Test Steps\" tab and click on \"Edit Parameters\":
Since the parameters in SpiraTeam map to the function arguments inside a TestComplete test script the parameter names need to match the order of the arguments inside TestComplete (i.e. they are matched by position/order not by name).
Therefore we recommend using numbers for the parameter names so that it's easy to see which parameter value will be passed to which argument in the test script function.
"},{"location":"RemoteLaunch-User-Guide/TestComplete/#executing-the-testcomplete-test-sets-from-spirateam","title":"Executing the TestComplete Test Sets from SpiraTeam","text":"There are two ways to execute automated test cases in SpiraTeam:
Schedule the test cases to be executed on a specific computer (local or remote) at a date/time in the future
Execute the test cases right now on the local computer.
We shall outline both of these two scenarios in this section. However first we need to setup the appropriate automation hosts and test sets in SpiraTeam:
"},{"location":"RemoteLaunch-User-Guide/TestComplete/#configuring-the-automation-hosts-and-test-sets","title":"Configuring the Automation Hosts and Test Sets","text":"Go to Testing > Automation Hosts in SpiraTeam to display the list of automation hosts:
Make sure that you have created an Automation Host for each computer that is going to run an automated test case. The name and description can be set to anything meaningful, but the Token field must be set to the same token that is specified in the RemoteLaunch application on that specific machine.
Once you have at least one Automation Host configured, go to Testing > Test Sets to create the test sets that will contain the automated test case:
Note: Unlike manual test cases, automated test cases must be executed within a test set -- they cannot be executed directly from the test case.
Create a new Test Set to hold the TestComplete automated test cases and click on its hyperlink to display the test set details page:
You need to add at least one automated test case to the test set and then configure the following fields:
Automation Host -- This needs to be set to the name of the automation host that will be running the automated test set.
Planned Date -- The date and time that you want the scenario to begin. (Note that multiple test sets scheduled at the exact same time will be scheduled by Test Set ID order.)
Status -- This needs to be set to \"Not Started\" for RemoteLaunch to pick up the scheduled test set. When you change the Planned Date, the status automatically switches back to \"Not Started\"
Type -- This needs to be set to \"Automated\" for automated testing
If you have parameterized test cases inside the automated test set you can set their values in three different ways:
Test Set Parameter Values -- this lets you set the same value of a parameter for all the test cases in the test set:
Test Case Parameter Values -- this lets you set a specific value for a parameter for a particular test case in the test set:
You set these values, by right-clicking on a row and choosing \"Edit Parameters\":
Once you have set the various test set fields (as described above), the Remote Launch instances will periodically poll SpiraTeam for new test sets. Once they retrieve the new test set, they will add it to their list of test sets to execute. Once execution begins they will change the status of the test set to \"In Progress\", and once test execution is done, the status of the test set will change to either \"Completed\" -- the automation engine could be launched and the test has completed -- or \"Blocked\" -- RemoteLaunch was not able to start the automation engine.
If you want to immediately execute the test case on your local computer, instead of setting the \"Automation Host\", \"Status\" and \"Planned Date\" fields, you can instead click the [Execute] icon on the test set itself. This will cause RemoteLaunch on the local computer to immediately start executing the current test set.
In either case, once all the test cases in the test set have been completed, the status of the test set will switch to \"Completed\" and the individual test cases in the set will display a status based on the results of the TestComplete test:
Passed -- The TestComplete automated test ran successfully and all the test conditions in the test script passed
Failed -- The TestComplete automated test ran successfully, but at least one test condition in the test script failed.
Blocked -- The TestComplete automated test did not run successfully
If you receive the \"Blocked\" status for either the test set or the test cases you should open up the Windows Application Event Log on the computer running RemoteLaunch and look in the event log for error messages.
Note: While the tests are executing you may see browser or application windows launch as TestComplete executes the appropriate tests.
Once the tests have completed, you can log back into SpiraTeam and see the execution status of your test cases. If you click on a Test Run that was generated by TestComplete, you will see the following information:
This screen indicates the status of the test run that was reported back from TestComplete together with any messages or other information. The Test Name indicates the name of the test inside TestComplete, and the execution status corresponds to the matching status inside TestComplete as illustrated below:
TestComplete Status SpiraTest Status Passed Passed Failed Failed Warning Caution
In addition, the detailed test report from TestComplete is available in the \"Console Output\" text-box below. It will contain messages such as:
For the most detail, the \"Test Steps\" section will contain a step-by-step breakdown of each action taken in the automated test:
"},{"location":"RemoteLaunch-User-Guide/TestComplete/#screenshot-capture","title":"Screenshot Capture","text":"During the execution of the test, TestComplete will capture screenshots of the application being tested. These screenshots are uploaded to SpiraTest so that you have a complete record of the testing activities:
Congratulations... You are now able to run TestComplete automated functional tests and have the results be recorded within SpiraTest / SpiraTeam.
"},{"location":"RemoteLaunch-User-Guide/TestPartner/","title":"TestPartner","text":"Micro Focus\u2122 TestPartner\u2122 (hereafter TestPartner) is a Graphic User Interface (GUI) functional test automation system that lets you record application operations by capturing the various testable objects of the application and then playback the operations to automatically test the application.
This section describes how you can use SpiraTest / SpiraTeam (hereafter SpiraTeam) together with RemoteLaunch to schedule and remotely launch instances of TestPartner on different computers and have the testing results be transmitted back to SpiraTeam. This allows you to extend your SpiraTeam's test management capabilities to include automated TestPartner tests.
Note: This integration requires at least version 3.0 of SpiraTest/Team and version 6.0 of TestPartner*.*
"},{"location":"RemoteLaunch-User-Guide/TestPartner/#installing-the-testpartner-engine","title":"Installing the TestPartner Engine","text":"This section assumes that you already have a working installation of SpiraTest or SpiraTeam and have installed RemoteLaunch on the various test automation hosts following the instructions in RemoteLaunch Guide. Once those prerequisites are in place, please follow these steps:
Download and extract the TestPartnerAutomationEngine.zip file from the Inflectra website and locate the TestPartner.dll inside the zip archive.
Copy the file \"TestPartner.dll\" into the \"extensions\" sub-folder of the RemoteLaunch installation.
Log in to SpiraTeam as a system administrator and go into SpiraTeam main Administration page and click on the \"Test Automation\" link under Integration.
Click the \"Add\" button to enter the new test automation engine details page. The fields required are as follows:
Name: This is the short display name of the automation engine. It can be anything that is meaningful to your users.
Description: This is the long description of the automation engine. It can be anything that is meaningful to your users. (Optional)
Active: If checked, the engine is active and able to be used for any project.
Token: This needs to be the assigned unique token for the automation engine and is used to tell RemoteLaunch which engine to actually use for a given test case. For TestPartner this should just be TestPartner.
Once you have finished, click the \"Insert & Close\" button and you will be taken back to the Test Automation list page, with TestPartner listed as an available automation engine.
This section describes the process for setting up a test case in SpiraTeam for automation and linking it to an automated TestPartner test script.
First you need to display the list of test cases in SpiraTeam (by clicking Testing > Test Cases) and then add a new test case. Once you have added the new test case, click on it and select the \"Automation\" tab:
You need to enter the following fields:
Automation Engine - Choose the TestPartner Automation Engine that you created in the previous section from the drop-down list.
Script Type -- This should be set to Linked as the integration with TestPartner only supports referencing TestPartner test scripts (stored in the internal database) and not physically uploading the test scripts into SpiraTeam.
Filename -- This needs contain the project and test name from TestPartner with the appropriate parameter name describing which is the project name and which is the test name. The test name can be either a test script of a visual test. The syntax is:
-visualtest <test name> -project <project name> or
-testscript <script name> -project <project name>
Document Type -- If using SpiraTeam (not SpiraTest) you can choose which document type the automated test script will be categorized under.
Document Folder -- If using SpiraTeam (not SpiraTest) you can choose which document folder the automated test script will be stored in.
Version -- The version of the test script (1.0 is used if no value specified)
Test Script -- This is not used with the TestPartner Engine since it only supports linked test scripts.
Once you are happy with the values, click [Save] to update the test case. Now you are ready to schedule the automated test case for execution.
"},{"location":"RemoteLaunch-User-Guide/TestPartner/#using-parameterized-test-cases","title":"Using Parameterized Test Cases","text":"TestPartner does not support the passing of input test parameters so the TestPartner automation engine does not support this feature of SpiraTeam or RemoteLaunch.
"},{"location":"RemoteLaunch-User-Guide/TestPartner/#executing-the-testpartner-test-sets-from-spirateam","title":"Executing the TestPartner Test Sets from SpiraTeam","text":"There are three ways to execute automated test cases in SpiraTeam:
Schedule the test cases to be executed on a specific computer (local or remote) at a date/time in the future
Execute the test cases right now on the local computer.
Execute the test cases from the command-line or a build script
We shall outline each of these three scenarios in this section. However first we need to setup the appropriate automation hosts and test sets in SpiraTeam:
"},{"location":"RemoteLaunch-User-Guide/TestPartner/#configuring-the-automation-hosts-and-test-sets","title":"Configuring the Automation Hosts and Test Sets","text":"Go to Testing > Automation Hosts in SpiraTeam to display the list of automation hosts:
Make sure that you have created an Automation Host for each computer that is going to run an automated test case. The name and description can be set to anything meaningful, but the Token field must be set to the same token that is specified in the RemoteLaunch application on that specific machine.
Once you have at least one Automation Host configured, go to Testing > Test Sets to create the test sets that will contain the automated test case:
Note: Unlike manual test cases, automated test cases must be executed within a test set -- they cannot be executed directly from the test case.
Create a new Test Set to hold the TestPartner automated test cases and click on its hyperlink to display the test set details page:
You need to add at least one automated test case to the test set and then configure the following fields:
Automation Host -- This needs to be set to the name of the automation host that will be running the automated test set.
Planned Date -- The date and time that you want the scenario to begin. (Note that multiple test sets scheduled at the exact same time will be scheduled by Test Set ID order.)
Status -- This needs to be set to \"Not Started\" for RemoteLaunch to pick up the scheduled test set. When you change the Planned Date, the status automatically switches back to \"Not Started\"
Type -- This needs to be set to \"Automated\" for automated testing
Once you have set the various test set fields (as described above), the Remote Launch instances will periodically poll SpiraTeam for new test sets. Once they retrieve the new test set, they will add it to their list of test sets to execute. Once execution begins they will change the status of the test set to \"In Progress\", and once test execution is done, the status of the test set will change to either \"Completed\" -- the automation engine could be launched and the test has completed -- or \"Blocked\" -- RemoteLaunch was not able to start the automation engine.
If you want to immediately execute the test case on your local computer, instead of setting the \"Automation Host\", \"Status\" and \"Planned Date\" fields, you can instead click the [Execute] icon on the test set itself. This will cause RemoteLaunch on the local computer to immediately start executing the current test set.
In either case, once all the test cases in the test set have been completed, the status of the test set will switch to \"Completed\" and the individual test cases in the set will display a status based on the results of the TestPartner test:
Passed -- The TestPartner automated test ran successfully and all the test conditions in the test script passed
Failed -- The TestPartner automated test ran successfully, but at least one test condition in the test script failed.
Blocked -- The TestPartner automated test did not run successfully
If you receive the \"Blocked\" status for either the test set or the test cases you should open up the Windows Application Event Log on the computer running RemoteLaunch and look in the event log for error messages.
Note: While the tests are executing you may see browser or application windows launch as TestPartner executes the appropriate tests.
Once the tests have completed, you can log back into SpiraTeam and see the execution status of your test cases. If you click on a Test Run that was generated by TestPartner, you will see the following information:
This screen indicates the status of the test run that was reported back from TestPartner together with any messages or other information. The Test Name indicates the name of the test inside TestPartner, and the execution status corresponds the matching status inside TestPartner.
Congratulations... You are now able to run TestPartner automated functional tests and have the results be recorded within SpiraTest / SpiraTeam.
"},{"location":"RemoteLaunch-User-Guide/TestingAnywhere/","title":"TestingAnywhere","text":"TestingAnywhere is a powerful and easy to use automated software testing tool that allows users to automate any type of testing. Powerful GUI based recording capabilities and a no-programming required user interface allows testers to quickly set up even complex test cases. A built-in editor allows users to build tests that can be easily edited to allow for changes in the test cases.
This section describes how you can use SpiraTest / SpiraTeam (hereafter SpiraTeam) together with RemoteLaunch to schedule and remotely launch instances of TestingAnywhere on different computers and have the testing results be transmitted back to SpiraTeam. This allows you to extend your SpiraTeam's test management capabilities to include automated TestingAnywhere tests.
Note: This integration requires at least version 4.0 of SpiraTest/Team and RemoteLaunch.
"},{"location":"RemoteLaunch-User-Guide/TestingAnywhere/#installing-the-testinganywhere-engine","title":"Installing the TestingAnywhere Engine","text":"This section assumes that you already have a working installation of SpiraTest or SpiraTeam and have installed RemoteLaunch on the various test automation hosts following the instructions in RemoteLaunch Guide. Once those prerequisites are in place, please follow these steps:
Download and extract the TestingAnywhereEngine.zip file from the Inflectra website and locate the TestingAnywhereAutomationEngine.dll file contained within.
Copy the file \"TestingAnywhereAutomationEngine.dll\" into the \"extensions\" sub-folder of the RemoteLaunch installation.
Log in to SpiraTeam as a system administrator and go into SpiraTeam main Administration page and click on the \"Test Automation\" link under Integration.
Click the \"Add\" button to enter the new test automation engine details page. The fields required are as follows:
Name: This is the short display name of the automation engine. It can be anything that is meaningful to your users.
Description: This is the long description of the automation engine. It can be anything that is meaningful to your users. (Optional)
Active: If checked, the engine is active and able to be used for any project.
Token: This needs to be the assigned unique token for the automation engine and is used to tell RemoteLaunch which engine to actually use for a given test case. For TestingAnywhere this should simply be TestingAnywhere.
Once you have finished, click the \"Insert & Close\" button and you will be taken back to the Test Automation list page, with TestingAnywhere listed as an available automation engine.
You can modify the TestingAnywhere configuration for each of the specific automation hosts, by right-clicking on the RemoteLaunch icon in the system tray and choosing \"Configuration\". That will bring up the RemoteLaunch configuration page.
The TestingAnywhere engine adds its own tab to this page which allows you to configure how TestingAnywhere operates:
The following fields can be specified on this screen:
Player Location -- this is the folder where the TestingAnywhere player (TAPlayer.exe) can be found. Typically it's C:\\Program Files (x86)\\Testing Anywhere 9.0\\Testing Anywhere
Files Location -- This is the folder where the TestingAnywhere test scripts and generated log files will be stored. The currently logged-in user needs to have Read/Write permissions over this folder. Typically it's:
C:\\Documents And Settings\\[UserName]\\My Documents\\Testing Anywhere Files on a Windows XP workstation or Windows 2003 server.
C:\\Users\\[UserName]\\Documents\\Testing Anywhere Files on a Windows Vista, 7, 2008 or 2008 R2 computer.
Trace Logging -- When selected, this will log additional trace and debugging information to the Windows Event Log. This should not be selected in a production environment.
"},{"location":"RemoteLaunch-User-Guide/TestingAnywhere/#setting-up-the-automated-test-cases","title":"Setting up the Automated Test Cases","text":"This section describes the process for setting up a test case in SpiraTeam for automation and linking it to an automated TestingAnywhere test script.
First you need to display the list of test cases in SpiraTeam (by clicking Testing > Test Cases) and then add a new test case. Once you have added the new test case, click on it and select the \"Overview\" tab, and scroll down to the \"Automation\" section:
You need to enter the following fields:
Automation Engine - Choose the TestingAnywhere Automation Engine that you created in the previous section from the drop-down list.
Script Type -- This should be set to Linked as the integration with TestingAnywhere only supports referencing TestingAnywhere test script files and not physically uploading the test scripts into SpiraTeam.
Filename -- This needs to consist of the relative location of the TestingAnywhere test script to the test script root folder.
Document Type -- This allows you to choose which document type the automated test script will be categorized under.
Document Folder --This allows you to choose which document folder the automated test script will be stored in.
Version -- The version of the test script (1.0 is used if no value specified)
Test Script -- This is not used with the TestingAnywhere Engine since it only supports linked test scripts.
Once you are happy with the values, click [Save] to update the test case. Now you are ready to schedule the automated test case for execution.
"},{"location":"RemoteLaunch-User-Guide/TestingAnywhere/#executing-the-testinganywhere-test-sets-from-spirateam","title":"Executing the TestingAnywhere Test Sets from SpiraTeam","text":"There are two ways to execute automated test cases in SpiraTeam:
Schedule the test cases to be executed on a specific computer (local or remote) at a date/time in the future
Execute the test cases right now on the local computer.
We shall outline both of these two scenarios in this section. However first we need to setup the appropriate automation hosts and test sets in SpiraTeam:
"},{"location":"RemoteLaunch-User-Guide/TestingAnywhere/#configuring-the-automation-hosts-and-test-sets","title":"Configuring the Automation Hosts and Test Sets","text":"Go to Testing > Automation Hosts in SpiraTeam to display the list of automation hosts:
Make sure that you have created an Automation Host for each computer that is going to run an automated test case. The name and description can be set to anything meaningful, but the Token field must be set to the same token that is specified in the RemoteLaunch application on that specific machine.
Once you have at least one Automation Host configured, go to Testing > Test Sets to create the test sets that will contain the automated test case:
Note: Unlike manual test cases, automated test cases must be executed within a test set -- they cannot be executed directly from the test case.
Create a new Test Set to hold the TestingAnywhere automated test cases and click on its hyperlink to display the test set details page:
You need to add at least one automated test case to the test set and then configure the following fields:
Automation Host -- This needs to be set to the name of the automation host that will be running the automated test set.
Planned Date -- The date and time that you want the scenario to begin. (Note that multiple test sets scheduled at the exact same time will be scheduled by Test Set ID order.)
Status -- This needs to be set to \"Not Started\" for RemoteLaunch to pick up the scheduled test set. When you change the Planned Date, the status automatically switches back to \"Not Started\"
Type -- This needs to be set to \"Automated\" for automated testing
Once you have set the various test set fields (as described above), the Remote Launch instances will periodically poll SpiraTeam for new test sets. Once they retrieve the new test set, they will add it to their list of test sets to be executed. Once execution begins they will change the status of the test set to \"In Progress\", and once test execution is done, the status of the test set will change to either \"Completed\" -- the automation engine could be launched and the test has completed -- or \"Blocked\" -- RemoteLaunch was not able to start the automation engine.
If you want to immediately execute the test case on your local computer, instead of setting the \"Automation Host\", \"Status\" and \"Planned Date\" fields, you can instead click the [Execute] icon on the test set itself. This will cause RemoteLaunch on the local computer to immediately start executing the current test set.
In either case, once all the test cases in the test set have been completed, the status of the test set will switch to \"Completed\" and the individual test cases in the set will display a status based on the results of the TestingAnywhere test:
Passed -- The TestingAnywhere automated test ran successfully and all the test steps in the test script passed and no assertions were thrown.
Failed -- The TestingAnywhere automated test ran successfully, but at least one test step failed or at least one assertion failed.
Caution -- The TestingAnywhere automated test run successfully, but at least one warning was logged in one of the test steps.
Blocked -- The TestingAnywhere automated test did not run successfully.
If you receive the \"Blocked\" status for either the test set or the test cases you should open up the Windows Application Event Log on the computer running RemoteLaunch and look in the event log for error messages.
Note: While the tests are executing you will see browser windows launch as TestingAnywhere executes the appropriate tests.
Once the tests have completed, you can log back into SpiraTeam and see the execution status of your test cases. If you click on a Test Run that was generated by TestingAnywhere, you will see the following high-level test information:
This screen indicates the status of the test run that was reported back from TestingAnywhere together with the execution date/time.
If you scroll down to the 'Console Output' section, you will see:
Finally, to see the detailed test steps, look under the 'Test Steps' section:
Congratulations... You are now able to run TestingAnywhere automated functional tests and have the results be recorded within SpiraTest / SpiraTeam.
"},{"location":"RemoteLaunch-User-Guide/Tosca/","title":"Tricentis Tosca","text":"Tricentis Tosca is a software testing tool that is used to automate end-to-end testing for software applications. It is developed by Tricentis. Tricentis Tosca combines multiple aspects of software testing to test GUIs and APIs from a business perspective.
You can use SpiraTest together with RemoteLaunch to schedule and remotely launch instances of Tricentis Tosca on different computers and have the testing results be transmitted back to SpiraTest. This allows you to extend your SpiraTest\u2019s test management capabilities to include automated Tosca tests.
This page describes the steps for using SpiraTest with Tosca. The plugin works with all three editions of the Inflectra Spira platform, including SpiraTest, SpiraTeam and SpiraPlan. We will be referring to the product as 'SpiraTest' for brevity.
"},{"location":"RemoteLaunch-User-Guide/Tosca/#installing-the-tosca-engine","title":"Installing the Tosca Engine","text":"This section assumes that you already have a working installation of SpiraTest and have installed RemoteLaunch on the various test automation hosts following the instructions in RemoteLaunch Guide. Once those prerequisites are in place, please follow these steps:
ToscaEngine.dll from inside the zipfile. You may need to right-click on the DLL and choose Unblock in Windows to confirm that you want to use the downloaded file.ToscaEngine.dll into the \"extensions\" sub-folder of the RemoteLaunch installation.Tosca.Next you need to configure the Tosca configuration for each of the specific automation hosts, by right-clicking on the RemoteLaunch icon in the system tray and choosing \"Configuration\". That will bring up the RemoteLaunch configuration page.
The Tosca engine adds its own tab to this page which allows you to configure how Tosca operates:
The following fields can be specified on this screen:
C:\\Program Files (x86)\\TRICENTIS\\Tosca Testsuite\\ToscaCommander\\ToscaCI\\Client\\http://server:8080/DistributionServerService/ManagerService.svcOnce you have configured the plugin, click Save to save your changes.
"},{"location":"RemoteLaunch-User-Guide/Tosca/#setting-up-the-automated-test-cases","title":"Setting up the Automated Test Cases","text":"This section describes the process for setting up a test case in SpiraTest for automation and linking it to an automated Tosca test script.
Due to the way that Tosca executes tests and reports results, we need to actually create two kinds of test case in SpiraTest:
Note: If you only have the first kind of test cases, you will be able to run automated Tosca test suites, but the reporting will be limited to a simple pass/fail for the entire test suite rather than more granular test case level reporting.
"},{"location":"RemoteLaunch-User-Guide/Tosca/#creating-a-test-case-for-launching-a-tosca-suite","title":"Creating a Test Case for Launching a Tosca Suite","text":"Next, display the list of test cases in SpiraTest (by clicking Testing > Test Cases) and then click on the button to add a new test case. In this example, we have called it Tricentis Insurance Website (Test Event) and stored it in the Tosca Suites folder:
Once you have added the new test case, click on it and scroll down to view the \"Automation\" tab:
You need to enter the following fields:
TestEvents=, so that in our example we have the sample test event: TestEvents=Tricentis Insurance WebsiteOnce you are happy with the values, click [Save] to update the test case.
"},{"location":"RemoteLaunch-User-Guide/Tosca/#creating-additional-test-case-for-parsing-the-tosca-results","title":"Creating additional Test Case for Parsing the Tosca Results","text":"We recommend that you create additional test cases to map to specific test cases in the Tosca test suite. This is an optional feature, but if you don't map these test cases, you will not be able to get detailed reporting and test coverage metrics.
To get this additional level of reporting, create one SpiraTest test case for each of the different Tosca test cases in the Tosca suite, for example we created the following:
Each of these SpiraTest test cases will have a different format for the Automation section:
<Test Suite>|<Test Case>, so that in our example we have the following combination: Auto Insurance Website|Create a quote for Audi Automobile. The other test cases will have the same test suite name, but different test case names.Now you are ready to schedule the automated test case for execution in SpiraTest
"},{"location":"RemoteLaunch-User-Guide/Tosca/#executing-the-tosca-test-sets-from-spiratest","title":"Executing the Tosca Test Sets from SpiraTest","text":"There are two ways to execute automated test cases in SpiraTest:
We shall outline both of these two scenarios in this section. However first we need to setup the appropriate automation hosts and test sets in SpiraTest:
"},{"location":"RemoteLaunch-User-Guide/Tosca/#configuring-the-automation-hosts-and-test-sets","title":"Configuring the Automation Hosts and Test Sets","text":"Go to Testing > Automation Hosts in SpiraTest to display the list of automation hosts:
Make sure that you have created an Automation Host for each computer that is going to run an automated test case. The name and description can be set to anything meaningful, but the Token field must be set to the same token that is specified in the RemoteLaunch application on that specific machine.
Once you have at least one Automation Host configured, go to Testing > Test Sets to create the test set that will contain the automated test cases:
Note: Unlike manual test cases, automated test cases must be executed within a test set -- they cannot be executed directly from the test case. Create a new Test Set (for example Tricentis Insurance Website Suite), and click on its hyperlink to display the test set details page:
Lower down, the list of test cases in the test set are displayed:
You need to add at least one automated test case to the test set, but to get the best reporting, we recommend having the first test case in the test set be the Tosca Test Event that launches the test suite, and the subsequent test cases be the individual test cases that parse the test suite and extract the results specific to the individual test case.
For example, our first test case in the screenshot will launch the entire insurance website test suite that tries to use the sample website with three different car brands (BMW, Audi and Honda). Each individual car brand will create a unique test case result that we'd want to map to different requirements in SpiraTest.
Once you have added the appropriate test cases to the test set, the final step is to configure the main test set fields:
Once you have set the various test set fields (as described above), the Remote Launch instances will periodically poll SpiraTest for new test sets. Once they retrieve the new test set, they will add it to their list of test sets to execute. Once execution begins they will change the status of the test set to \"In Progress\", and once test execution is done, the status of the test set will change to either \"Completed\" -- the automation engine could be launched and the test has completed -- or \"Blocked\" -- RemoteLaunch was not able to start the automation engine.
If you want to immediately execute the test case on your local computer, instead of setting the \"Automation Host\", \"Status\" and \"Planned Date\" fields, you can instead click the [Execute] icon on the test set itself. This will cause RemoteLaunch on the local computer to immediately start executing the current test set.
In either case, once all the test cases in the test set have been completed, the status of the test set will switch to \"Completed\" and the individual test cases in the set will display a status based on the results of the Tosca test:
If you receive the \"Blocked\" status for either the test set or the test cases you should open up the Windows Application Event Log on the computer running RemoteLaunch and look in the event log for error messages.
Note: While the tests are executing you may see browser windows launch as Tosca executes the appropriate tests.
"},{"location":"RemoteLaunch-User-Guide/Tosca/#viewing-the-tosca-test-results","title":"Viewing the Tosca Test Results","text":"Once the tests have completed, you can log back into SpiraTest and see the execution status of your test cases. If you click on a Test Run that was generated by Tosca, you will see the following information:
This screen indicates the status of the test run that was reported back from Tosca together with any messages or other information. The Test Name indicates the name of the test inside Tosca and the execution status corresponds the matching status inside Tosca as described above.
Underneath this high-level test result, you will see the detailed Tosca test results that show each entry in the test script step by step:
Finally, there is the Console Output section which reports back the raw output from the Tosca test result XML file:
Congratulations... You are now able to run Tosca automated functional tests and have the results be recorded within SpiraTest, with the ability to have those test cases update the requirements test coverage and other enterprise quality metrics in the system.
"},{"location":"RemoteLaunch-User-Guide/WebLOAD/","title":"WebLOAD","text":"RadView WebLoad is a WebLOAD is a performance, scalability, and reliability testing solution for internet applications. WebLOAD is easy to use and delivers maximum testing performance and value. WebLOAD verifies the scalability and integrity of internet applications by generating a load composed of Virtual Clients that simulate real-world traffic. Probing Clients let you refine the testing process by acting as a single user that measures the performance of targeted activities, and provides individual performance statistics of the internet application under load.
This section covers installing and using the Engine to report back the success of a WebLoad protocol test scripts/agendas for the WebLOAD environment.
Info
This integration requires at least version 4.0 of SpiraTest/Plan and has been tested against version WebLOAD-Professional-12.2.0.087 of WebLoad.
"},{"location":"RemoteLaunch-User-Guide/WebLOAD/#installing-the-webload-engine","title":"Installing the WebLOAD Engine","text":"This section assumes that you already have a working installation of SpiraTest or SpiraPplan and have installed RemoteLaunch on the various test automation hosts following the instructions in RemoteLaunch Guide. Once those prerequisites are in place, please follow these steps:
Name: This is the short display name of the automation engine. It can be anything that is meaningful to your users, and will be displayed in the Automation Host dropdown when the user selects it in the test set.
Description: This is the long description of the automation engine. It can be anything that is meaningful to your users. (Optional)
Active: If checked, the engine is active and able to be used for any project.
Token: This needs to be the assigned unique token for the automation engine and is used to tell RemoteLaunch which engine, in this case WebLoad.dll, to actually use for a given test case. For WebLOAD, it needs to be simply \"WebLoad\". This is case sensitive, and if it does not match an error will be written to a Blocked test run that will be phrased using what was entered as the token. For example, if the token is misspelled, WebLpsd, the error message will say \u201cExtension 'WebLpsd' was not loaded or was in error condition. Could not run TC:73 in TX:29\u201d
Once you have finished, click the Insert & Close button and you will be taken back to the Test Automation list page, with WebLOAD listed as an available automation engine.
You will need to modify the WebLOAD configuration for each of the specific automation hosts, by right-clicking on the RemoteLaunch icon in the system tray and choosing \"Configuration\". That will bring up the RemoteLaunch configuration page. The WebLOAD engine adds its own tab to this page which allows you to configure how WebLOAD operates:
The following fields can be specified on this screen (make sure to hit Save after making any changes):
Tokens for Specifying File Locations
The full path to the WebLOAD Location and the Output Directory can be shortened via keywords for better visibility, and to make this easier across different machines, you can use several constants for standard Windows locations (see example in screenshot):
This section describes the process for setting up a test case in SpiraPlan for automation and linking it to an automated WebLOAD test script.
First you need to display the list of test cases in SpiraPlan (by clicking Testing > Test Cases) and then add a new test case. Once you have added the new test case, click on it and select the \"Overview\" tab and scroll down to the Automation section:
You need to enter the following fields:
Once you are happy with the values, click Save to update the test case. Now you are ready to schedule the automated test case for execution.
Currently the WebLOAD automation engine does not support the passing of parameter values from SpiraPlan to WebLOAD. Only the file path to the WebLOAD project file (*.tpl) file can be passed. Other parameters must be set in RemoteLaunch as illustrated earlier.
"},{"location":"RemoteLaunch-User-Guide/WebLOAD/#executing-webload-test-sets-from-spiraplan","title":"Executing WebLOAD Test Sets from SpiraPlan","text":"Before we can executed tests we need to setup the appropriate automation hosts and test sets in SpiraPlan. Once this is done, there are two ways to execute automated test cases in SpiraPlan:
Go to Testing > Automation Hosts from the main navbar in SpiraPlan to display the list of automation hosts.
Make sure you have created an Automation Host for each computer that is going to run an automated test case. The name and description can be set to anything meaningful, but the Token field must be set to the same token that is specified in the RemoteLaunch application on that specific machine.
Once you have at least one Automation Host configured, go to Testing > Test Sets to create the test sets that will contain the automated test case.
Info
Unlike manual test cases, automated test cases must be executed within a test set -- they cannot be executed directly from the test case.
Create a new Test Set to hold the WebLOAD automated test cases and click on its hyperlink to display the test set details page.
You need to add at least one automated test case to the test set and then configure the following fields:
Once you have set the various test set fields (as described above), the Remote Launch instances will periodically poll SpiraPlan for new test sets. Once they retrieve the new test set, they will add it to their list of test sets to be executed. Once execution begins they will change the status of the test set to \"In Progress\", and once test execution is done, the status of the test set will change to either:
If you want to immediately execute the test case on your local computer, instead of setting the \"Automation Host\", \"Status\" and \"Planned Date\" fields, you can instead click the [Execute] icon on the test set itself. This will cause RemoteLaunch on the local computer to immediately start executing the current test set.
In either case, once all the test cases in the test set have been completed, the status of the test set will switch to \"Completed\" and the individual test cases in the set will display a status based on the results of the WebLOAD test:
If you receive the \"Blocked\" status for either the test set or the test cases you should open up the Windows Application Event Log on the computer running RemoteLaunch and look in the event log for error messages.
Info
While the tests are executing you will see the WebLOAD application open as WebLOAD executes the appropriate tests.
Once the tests have completed, you can log back into SpiraPlan and see the execution status of your test cases. If you click on a Test Run that was generated by WebLOAD, you will see the following information:
This screen indicates the status of the test run that was reported back from WebLOAD together with any messages or other information. The Test Name indicates the name of the test inside WebLOAD and the execution status corresponds the rules described above.
In addition, the details in the test run from WebLOAD lists the input script and the parameters passed to the script so testers will know the file created that are correlated with tis test run in the output directory. Here is an example of a successful WebLOAD script run through SpiraPlan:
Results from results.xml: Passed Test \nFile Name: C:\\Users\\suzanne.bauer\\Documents\\WebLOAD\\Sessions\\input\\WebLOADFirstTest.tpl\nwith arguments: C:\\Users\\su.be\\Documents\\WebLOAD\\Sessions\\output\\WebLOADFirstTest20200228135424.ls /rc C:\\Users\\su.be\\Documents\\WebLOAD\\Sessions\\output\\results.xml /ar 300 \nCongratulations
You are now able to run WebLOAD automated functional tests and have the results be recorded within SpiraTest /SpiraTeam/ SpiraPlan.
"},{"location":"RemoteLaunch-User-Guide/Worksoft-Certify/","title":"Worksoft Certify","text":"Worksoft Certify is a test automation solution for enterprise applications including SAP, Workday, Salesforce.com, Oracle, and Web Apps. Built to test complex business processes that span multiple applications, Certify ensures that your software and business work exactly as planned.
This section describes how you can use SpiraTest, SpiraTeam, or SpiraPlan (hereafter SpiraTeam) together with RemoteLaunch to schedule and remotely launch instances of Worksoft Certify on different computers and have the testing results be transmitted back to SpiraTeam. This allows you to extend your SpiraTeam's test management capabilities to include automated Worksoft Certify tests.
Note: This integration requires at least version 5.0 of SpiraTeam and version 10.0 of Worksoft Certify.
"},{"location":"RemoteLaunch-User-Guide/Worksoft-Certify/#installing-the-worksoft-certify-engine","title":"Installing the Worksoft Certify Engine","text":"This section assumes that you already have a working installation of SpiraTeam and have installed RemoteLaunch on the various test automation hosts following the instructions in RemoteLaunch Guide. Once those prerequisites are in place, please follow these steps:
Download and extract the WorksoftCertifyEngine.zip file from the Inflectra website and locate the appropriate WorksoftCertifyEngine.dll for the version of Worksoft Certify that you are using.
Copy the file \"WorksoftCertifyEngine.dll\" into the \"extensions\" sub-folder of the RemoteLaunch installation.
Log in to SpiraTeam as a system administrator and go into SpiraTeam main Administration page and click on the \"Test Automation\" link under Integration.
Click the \"Add\" button to enter the new test automation engine details page. The fields required are as follows:
Name: This is the short display name of the automation engine. It can be anything that is meaningful to your users.
Description: This is the long description of the automation engine. It can be anything that is meaningful to your users. (Optional)
Active: If checked, the engine is active and able to be used for any project.
Token: This needs to be the assigned unique token for the automation engine and is used to tell RemoteLaunch which engine to actually use for a given test case. For Worksoft Certify this should always be WorksoftCertify.
Once you have finished, click the \"Insert & Close\" button and you will be taken back to the Test Automation list page, with Worksoft Certify listed as an available automation engine:
You can modify the Worksoft Certify configuration for each of the specific automation hosts, by right-clicking on the RemoteLaunch icon in the system tray and choosing \"Configuration\". That will bring up the RemoteLaunch configuration page.
The Worksoft Certify engine adds its own tab to this page which allows you to configure how Worksoft Certify operates:
The following fields can be specified on this screen:
Trace Logging -- When selected, this will log additional trace and debugging information to the Windows Event Log. This should not be selected in a production environment.
Certify User -- This should be populated with a valid username that can login to the Worksoft Certify database that you are using
Certify Password -- This should be populated with a valid password for the user specified in the previous field that can login to the Worksoft Certify database that you are using
Test Timeout -- This tells RemoteLaunch how long to let the Worksoft Certify tests run (in seconds) in the event one of the tests were to not finish property. Once the test report is generated, RemoteLaunch will stop execution, regardless of this setting.
Report Generation Time -- This is how long (in seconds) RemoteLaunch should wait after Worksoft Certify has finished before reading the test report (for sending to SpiraTeam). It ensures that Worksoft Certify has enough time to finish writing the report.
"},{"location":"RemoteLaunch-User-Guide/Worksoft-Certify/#setting-up-the-automated-test-cases","title":"Setting up the Automated Test Cases","text":"This section describes the process for setting up a test case in SpiraTeam for automation and linking it to an automated Worksoft Certify test script.
First you need to display the list of test cases in SpiraTeam (by clicking Testing > Test Cases) and then add a new test case. Once you have added the new test case, click on it and select the \"Automation\" section of the main \"Overview\" tab:
You need to enter the following fields:
Automation Engine - Choose the Worksoft Certify Automation Engine that you created in the previous section from the drop-down list.
Script Type -- This should be set to Linked as the integration with Worksoft Certify only supports referencing Worksoft Certify projects and not physically uploading the tests into SpiraTeam.
Filename -- This needs to contain the following elements at the very least:
/Process=\"xxxxx\" needs to specify the name of the Worksoft Certify process
/Project=\"xxxxx\" needs to specify the name of the Worksoft Certify project
You can also add other Worksoft Certify command line options - http://community.worksoft.com/Knowledge-Base/Worksoft-Products/Worksoft-Certify/certify-command-line-options.html
Document Type -- This allows you to choose which document type the automated test script will be categorized under.
Document Folder --This allows you to choose which document folder the automated test script will be stored in.
Version -- The version of the test script (1.0 is used if no value specified)
Test Script -- This is not used with the Worksoft Certify Engine since it only supports linked test scripts.
Once you are happy with the values, click [Save] to update the test case. Now you are ready to schedule the automated test case for execution.
"},{"location":"RemoteLaunch-User-Guide/Worksoft-Certify/#executing-the-worksoft-certify-test-sets-from-spirateam","title":"Executing the Worksoft Certify Test Sets from SpiraTeam","text":"There are two ways to execute automated test cases in SpiraTeam:
Schedule the test cases to be executed on a specific computer (local or remote) at a date/time in the future
Execute the test cases right now on the local computer.
We shall outline both of these two scenarios in this section. However first we need to setup the appropriate automation hosts and test sets in SpiraTeam:
"},{"location":"RemoteLaunch-User-Guide/Worksoft-Certify/#configuring-the-automation-hosts-and-test-sets","title":"Configuring the Automation Hosts and Test Sets","text":"Go to Testing > Automation Hosts in SpiraTeam to display the list of automation hosts:
Make sure that you have created an Automation Host for each computer that is going to run an automated test case. The name and description can be set to anything meaningful, but the Token field must be set to the same token that is specified in the RemoteLaunch application on that specific machine.
Once you have at least one Automation Host configured, go to Testing > Test Sets to create the test sets that will contain the automated test case:
Note: Unlike manual test cases, automated test cases must be executed within a test set -- they cannot be executed directly from the test case.
Create a new Test Set to hold the Worksoft Certify automated test cases and click on its hyperlink to display the test set details page:
Lower down, the list of test cases in the test set are displayed:
You need to add at least one automated test case to the test set and then configure the following fields:
Automation Host -- This needs to be set to the name of the automation host that will be running the automated test set.
Planned Date -- The date and time that you want the scenario to begin. (Note that multiple test sets scheduled at the exact same time will be scheduled by Test Set ID order.)
Status -- This needs to be set to \"Not Started\" for RemoteLaunch to pick up the scheduled test set. When you change the Planned Date, the status automatically switches back to \"Not Started\"
Type -- This needs to be set to \"Automated\" for automated testing
Once you have set the various test set fields (as described above), the Remote Launch instances will periodically poll SpiraTeam for new test sets. Once they retrieve the new test set, they will add it to their list of test sets to execute. Once execution begins they will change the status of the test set to \"In Progress\", and once test execution is done, the status of the test set will change to either \"Completed\" -- the automation engine could be launched and the test has completed -- or \"Blocked\" -- RemoteLaunch was not able to start the automation engine.
If you want to immediately execute the test case on your local computer, instead of setting the \"Automation Host\", \"Status\" and \"Planned Date\" fields, you can instead click the [Execute] icon on the test set itself. This will cause RemoteLaunch on the local computer to immediately start executing the current test set.
In either case, once all the test cases in the test set have been completed, the status of the test set will switch to \"Completed\" and the individual test cases in the set will display a status based on the results of the Worksoft Certify test:
Passed -- The Worksoft Certify automated test ran successfully and all the test steps in the test script passed and no assertions were thrown.
Failed -- The Worksoft Certify automated test ran successfully, but at least one test step failed or at least one assertion failed.
Blocked -- The Worksoft Certify automated test did not run successfully and reported back the aborted test status to RemoteLaunch.
If you receive the \"Blocked\" status for either the test set or the test cases you should open up the Windows Application Event Log on the computer running RemoteLaunch and look in the event log for error messages.
Note: While the tests are executing you will see browser windows launch as Worksoft Certify executes the appropriate tests.
Once the tests have completed, you can log back into SpiraTeam and see the execution status of your test cases. If you click on a Test Run that was generated by Worksoft Certify, you will see the following information:
This screen indicates the status of the test run that was reported back from Worksoft Certify together with any messages or other information. The Test Name indicates the name of the test inside Worksoft Certify and there will be detailed steps displayed that match the Worksoft Certify execution steps:
Each of the SpiraTeam execution status values corresponds the matching status inside Worksoft Certify as illustrated below:
Worksoft Certify Status SpiraTeam Status Passed Passed Failed Failed Aborted Blocked Skipped N/AIn addition, the detailed test report from Worksoft Certify is available in the large text-box below. It will contain messages such as:
Congratulations... You are now able to run Worksoft Certify automated functional tests and have the results be recorded within SpiraTest, SpiraTeam, or SpiraPlan.
"},{"location":"RemoteLaunch-User-Guide/ZAPTEST/","title":"ZAPTEST","text":"ZAPTEST is a cross-platform and cross-browser software testing solution. Using OCR and Image Based recognition, it's able to automate the testing process without any API, Framework or environment dependencies and work only with a Graphic User Interface
This section describes how you can use SpiraTest, SpiraTeam, or SpiraPlan (hereafter SpiraTeam) together with RemoteLaunch to schedule and remotely launch instances of ZAPTEST on different computers and have the testing results be transmitted back to SpiraTeam. This allows you to extend your SpiraTeam's test management capabilities to include automated ZAPTEST tests.
Note: This integration requires at least version 5.0 of SpiraTeam and version 11.0 of ZAPTEST.
"},{"location":"RemoteLaunch-User-Guide/ZAPTEST/#installing-the-zaptest-engine","title":"Installing the ZAPTEST Engine","text":"This section assumes that you already have a working installation of SpiraTeam and have installed RemoteLaunch on the various test automation hosts following the instructions in RemoteLaunch Guide. Once those prerequisites are in place, please follow these steps:
Download and extract the ZapTestEngine.zip file from the Inflectra website and locate the appropriate ZapTestEngine.dll for the version of ZAPTEST that you are using.
Copy the file \"ZapTestEngine.dll\" into the \"extensions\" sub-folder of the RemoteLaunch installation.
Log in to SpiraTeam as a system administrator and go into SpiraTeam main Administration page and click on the \"Test Automation\" link under Integration.
Click the \"Add\" button to enter the new test automation engine details page. The fields required are as follows:
Name: This is the short display name of the automation engine. It can be anything that is meaningful to your users.
Description: This is the long description of the automation engine. It can be anything that is meaningful to your users. (Optional)
Active: If checked, the engine is active and able to be used for any project.
Token: This needs to be the assigned unique token for the automation engine and is used to tell RemoteLaunch which engine to actually use for a given test case. For ZAPTEST this should always be ZapTest.
Once you have finished, click the \"Insert & Close\" button and you will be taken back to the Test Automation list page, with ZAPTEST listed as an available automation engine:
You can modify the ZAPTEST configuration for each of the specific automation hosts, by right-clicking on the RemoteLaunch icon in the system tray and choosing \"Configuration\". That will bring up the RemoteLaunch configuration page.
The ZAPTEST engine adds its own tab to this page which allows you to configure how ZAPTEST operates:
The following fields can be specified on this screen:
ZAPTEST Location -- You need to browse to the location of the Standalone ZAPTEST.EXE program (e.g. C:\\Program Files (x86)\\ZAP-fiX\\Standalone)
Trace Logging -- When selected, this will log additional trace and debugging information to the Windows Event Log. This should not be selected in a production environment.
Report Generation Time -- This is how long (in seconds) RemoteLaunch should wait after ZAPTEST has finished before reading the test report (for sending to SpiraTeam). It ensures that ZAPTEST has enough time to finish writing the report.
"},{"location":"RemoteLaunch-User-Guide/ZAPTEST/#setting-up-the-automated-test-cases","title":"Setting up the Automated Test Cases","text":"This section describes the process for setting up a test case in SpiraTeam for automation and linking it to an automated ZAPTEST test script.
First you need to display the list of test cases in SpiraTeam (by clicking Testing > Test Cases) and then add a new test case. Once you have added the new test case, click on it and select the \"Automation\" section of the main \"Overview\" tab:
You need to enter the following fields:
Automation Engine - Choose the ZapTest Automation Engine that you created in the previous section from the drop-down list.
Script Type -- This should be set to Linked as the integration with ZAPTEST only supports referencing ZAPTEST script files and not physically uploading the tests into SpiraTeam.
Filename -- This needs to contain the full path to a location on the computer running ZAPTEST where the test script can be found.
Document Type -- This allows you to choose which document type the automated test script will be categorized under.
Document Folder --This allows you to choose which document folder the automated test script will be stored in.
Version -- The version of the test script (1.0 is used if no value specified)
Test Script -- This is not used with the ZapTest Engine since it only supports linked test scripts.
Once you are happy with the values, click [Save] to update the test case. Now you are ready to schedule the automated test case for execution.
"},{"location":"RemoteLaunch-User-Guide/ZAPTEST/#executing-the-zaptest-test-sets-from-spirateam","title":"Executing the ZAPTEST Test Sets from SpiraTeam","text":"There are two ways to execute automated test cases in SpiraTeam:
Schedule the test cases to be executed on a specific computer (local or remote) at a date/time in the future
Execute the test cases right now on the local computer.
We shall outline both of these two scenarios in this section. However first we need to setup the appropriate automation hosts and test sets in SpiraTeam:
"},{"location":"RemoteLaunch-User-Guide/ZAPTEST/#configuring-the-automation-hosts-and-test-sets","title":"Configuring the Automation Hosts and Test Sets","text":"Go to Testing > Automation Hosts in SpiraTeam to display the list of automation hosts:
Make sure that you have created an Automation Host for each computer that is going to run an automated test case. The name and description can be set to anything meaningful, but the Token field must be set to the same token that is specified in the RemoteLaunch application on that specific machine.
Once you have at least one Automation Host configured, go to Testing > Test Sets to create the test sets that will contain the automated test case:
Note: Unlike manual test cases, automated test cases must be executed within a test set -- they cannot be executed directly from the test case.
Create a new Test Set to hold the ZAPTEST automated test cases and click on its hyperlink to display the test set details page:
Lower down, the list of test cases in the test set are displayed:
You need to add at least one automated test case to the test set and then configure the following fields:
Automation Host -- This needs to be set to the name of the automation host that will be running the automated test set.
Planned Date -- The date and time that you want the scenario to begin. (Note that multiple test sets scheduled at the exact same time will be scheduled by Test Set ID order.)
Status -- This needs to be set to \"Not Started\" for RemoteLaunch to pick up the scheduled test set. When you change the Planned Date, the status automatically switches back to \"Not Started\"
Type -- This needs to be set to \"Automated\" for automated testing
Once you have set the various test set fields (as described above), the Remote Launch instances will periodically poll SpiraTeam for new test sets. Once they retrieve the new test set, they will add it to their list of test sets to execute. Once execution begins they will change the status of the test set to \"In Progress\", and once test execution is done, the status of the test set will change to either \"Completed\" -- the automation engine could be launched and the test has completed -- or \"Blocked\" -- RemoteLaunch was not able to start the automation engine.
If you want to immediately execute the test case on your local computer, instead of setting the \"Automation Host\", \"Status\" and \"Planned Date\" fields, you can instead click the [Execute] icon on the test set itself. This will cause RemoteLaunch on the local computer to immediately start executing the current test set.
In either case, once all the test cases in the test set have been completed, the status of the test set will switch to \"Completed\" and the individual test cases in the set will display a status based on the results of the ZAPTEST:
Passed -- The ZAPTEST automated test ran completed execution and all the test steps in the test script passed and no failures or warnings were logged.
Failed -- The ZAPTEST automated test ran completed execution, but at least one test step failed.
Warning -- The ZAPTEST automated test ran completed execution, but at least one test step reported a warning, but no steps completely failed.
Blocked -- The ZAPTEST automated test failed to execute because of some configuration error.
If you receive the \"Blocked\" status for either the test set or the test cases you should open up the Windows Application Event Log on the computer running RemoteLaunch and look in the event log for error messages.
Note: While the tests are executing you will see browser windows launch as ZAPTEST executes the appropriate tests.
Once the tests have completed, you can log back into SpiraTeam and see the execution status of your test cases. If you click on a Test Run that was generated by ZAPTEST, you will see the following information:
This screen indicates the status of the test run that was reported back from ZAPTEST together with any messages or other information. The Test Name indicates the name of the test script that was executed and there will be detailed steps displayed that match the ZAPTEST execution steps:
Each of the SpiraTeam execution status values corresponds the matching status inside Worksoft Certify as illustrated below:
ZAPTEST Status SpiraTeam Status Passed Passed Failed Failed Warning Caution Information N/AIn addition, the detailed test report from ZAPTEST is available in the large text-box below. It will contain messages such as:
Congratulations... You are now able to run ZAPTEST automated functional tests and have the results be recorded within SpiraTest, SpiraTeam, or SpiraPlan.
"},{"location":"Reporting/Custom-Graph-Tutorial/","title":"Custom Graphs Tutorial and Introduction","text":""},{"location":"Reporting/Custom-Graph-Tutorial/#introduction","title":"Introduction","text":"One of the maxims I always tell developers is that regardless of what you build, customers will never be satisfied with the reports you offer or the integration that you provide. In fact, the two most underestimated tasks in software development are data feeds and reporting. So one of the nice features in our Spira platform is the ability to do custom graphing, so that you are not limited to just the graphs that ship with the system.
"},{"location":"Reporting/Custom-Graph-Tutorial/#creating-custom-graphs","title":"Creating Custom Graphs","text":"To create a custom report, go to: Administration > System Administration > Reporting > Edit Graphs:
When you click on the Edit Graphs link, you will be taken to the custom graph configuration page where you can add / modify custom graphs.
This page lets you create custom graphs and charts in the system that your users can run in the various products they have access to. Note that the graph definitions themselves are global to the system and therefore available in all products.
You can click the Edit button to modify an existing graph, or click Add New Custom Graph to create an new one. In either case, you will see the custom graph editing screen.
The graph list page has the following additional operations:
On the graph editing page, you can enter the following fields:
The Query box is where you can choose the Reportable Entity from the dropdown list and then use that base query to create your own custom query.
We recommend that you first choose the appropriate reportable entity from the dropdown list. In the example below, we have selected the \"Test Runs\" reportable entity:
This will automatically populate the following query in the Query editor:
select value R from SpiraTestEntities.R_TestRuns as R where R.PROJECT_ID = ${ProjectId}\nThis query tells Spira to select all of the rows in the R_TestRuns collection that are in the current product and include all of the columns in the final report. You cannot graph non-numeric columns, so usually we'd recommend clicking Display Data Grid to see all of the columns that you can use in the graph:
This will help you decide which columns are important for your graph. You can then adjust the query to only include those columns:
select R.EXECUTION_STATUS_NAME, COUNT (R.TEST_RUN_ID) as COUNT\nfrom SpiraTestEntities.R_TestRuns as R\nwhere R.PROJECT_ID = ${ProjectId}\ngroup by R.EXECUTION_STATUS_NAME\nIn this modified query, we have replaced the keyword value with the specific column names. We have also added an aggregation function called COUNT to count the number of test runs and group by the execution status name column. Spira uses a modified SQL language called Entity SQL created by Microsoft that we'll be discussing in more detail in later articles in this series.
You may have noticed that we had a special token in the query ${ProjectId}, this token will be evaluated during the generation of the graph and ensures that only items in the current product are included. If you want to include all the items in a specific Program, you should instead use the token ${ProjectGroupId}. If you don't use either token, the graph will include all the items in the entire system, across all products and programs.
There are some restrictions about the select clause of the query:
You can test out your modified query by clicking the Display Data Grid button again. For our example test runs query above the system will now display:
Then once you have verified the data makes sense, click on the three different Preview Graph buttons to see how the data will look as a donut, bar, or\u00a0 line graph.
Note
For donut graphs, only one data range is supported, for line/bar charts, you can have multiple ranges
"},{"location":"Reporting/Custom-Graph-Tutorial/#a-donut-chart","title":"a) Donut Chart","text":""},{"location":"Reporting/Custom-Graph-Tutorial/#b-bar-graph","title":"b) Bar Graph","text":""},{"location":"Reporting/Custom-Graph-Tutorial/#c-line-chart","title":"c) Line Chart","text":"Once you are happy with your graph design, make sure the Active flag is set to Yes and then click Save to publish the graph for your end users.
Warning
If you create a graph that doesn't have either ${ProjectId} or ${ProjectGroupId} in the WHERE clause you could end up displaying data to a user that shouldn't have permission to see that data.
"},{"location":"Reporting/Custom-Graph-Tutorial/#viewing-custom-graphs","title":"Viewing Custom Graphs","text":"Once published, the custom graphs can be displayed in the main Reports dashboard by your end users:
Once you have added an instance of the Custom Graphs to your dashboard, you can choose the specific graph, and the visualization type (donut, bar, and line currently):
You can display the data being used to generate the graph by clicking on the data-grid button in the bottom-left:
As with all of the graphs on the reporting dashboard, you can export the data-grid as a CSV / Excel sheet, and export the actual graph as an image (PNG, JPEG, and BMP formats supported).
"},{"location":"Reporting/Custom-Graph-Tutorial/#understanding-entity-sql-esql","title":"Understanding Entity SQL (ESQL)","text":"The language that we use for creating custom graphs and reports in Spira is called \"Entity SQL\" (abbreviated to ESQL). Please read our dedicated tutorial to learn how ESQL works and how it is similar and different to standard SQL. This includes an overview, Entity SQL Syntax Basics, and the differences Between ESQL and Traditional Database SQL.
"},{"location":"Reporting/Custom-Graph-Tutorial/#advanced-entity-sql-queries","title":"Advanced Entity SQL Queries","text":"Now that we have discussed the differences between traditional database SQL and Entity SQL, we will cover some more advanced queries and functions that customers typically will want to use when creating custom graphs with Spira.
At the top of this tutorial, we outlined a sample ESQL query to get the count of test runs by execution status:
select R.EXECUTION_STATUS_NAME, COUNT (R.TEST_RUN_ID) as COUNT\nfrom SpiraTestEntities.R_TestRuns as R\nwhere R.PROJECT_ID = ${ProjectId}\ngroup by R.EXECUTION_STATUS_NAME\nAs we discussed, when using ESQL queries to display custom graphs, there are some restrictions about the select clause of the query:
We will now be looking at some specific examples of graphs that users have asked us for help with, that we have some suggestions for...
"},{"location":"Reporting/Custom-Graph-Tutorial/#1-requirements-addedremoved-over-time","title":"1) Requirements Added/Removed Over Time","text":"For example, lets consider that you want to display a graph of requirements added and removed over time. To get a count of this we can query the SpiraTestEntities.R_HistoryChangeSets view to get a count of the changes, filter by additions and deletions, then use a combination of aggregation and the CAST operator to count the items added/removed:
select\nR.CHANGE_DATE as Timestamp,\ncount(CASE\nWHEN R.CHANGETYPE_NAME=\"Added\" THEN 1\nWHEN R.CHANGETYPE_NAME=\"Deleted\" THEN -1\nEND\n) AS Sum\nfrom SpiraTestEntities.R_HistoryChangeSets as R\nwhere\nR.ARTIFACT_TYPE_NAME = \"Requirement\"\ngroup by R.CHANGE_DATE\nThis will display the following data:
Timestamp Sum 2019-08-17T02:06:18 0 2019-08-23T02:51:18 0 2020-01-14T11:50:18 5 2020-01-14T11:50:18 7 2020-01-14T11:50:18 5 2020-01-14T11:50:18 9 2020-01-14T11:50:18 7 2020-01-14T11:50:18 6 2020-01-14T11:50:18 5 2020-01-14T11:50:18 7Which when displayed as a graph would look like:
However suppose you want to display this graph by day, not by unique timestamp (a reasonable request), you would use the TruncateTime canonical EntitySQL function and combine that with a different way of writing the GROUP BY clause:
select\nDatePart,\ncount(CASE\nWHEN R.CHANGETYPE_NAME=\"Added\" THEN 1\nWHEN R.CHANGETYPE_NAME=\"Deleted\" THEN -1\nEND\n) AS Sum\nfrom SpiraTestEntities.R_HistoryChangeSets as R\nwhere\nR.ARTIFACT_TYPE_NAME = \"Requirement\"\ngroup by TruncateTime(R.CHANGE_DATE) as DatePart\nThis would now give the following results instead:
<table class=\"table table-striped\">\n <tbody>\n <tr class=\"Header\">\n <th>DatePart</th>\n <th>Sum</th>\n </tr>\n <tr>\n <td>2019-08-17T00:00:00</td>\n <td>0</td>\n </tr>\n <tr>\n <td>2019-08-23T00:00:00</td>\n <td>0</td>\n </tr>\n <tr>\n <td>2020-01-14T00:00:00</td>\n <td>248</td>\n </tr>\n </tbody>\n</table>\nwhich could be graphed as follows:
"},{"location":"Reporting/Custom-Graph-Tutorial/#2-aggregating-data-over-time-periods","title":"2) Aggregating Data Over Time Periods","text":"A common need is the ability to aggregate data over multiple time periods. For example, in the query above, we had the list of requirements aggregated by day:
<table class=\"table table-striped\">\n <tbody>\n <tr class=\"Header\">\n <th>DatePart</th>\n <th>Sum</th>\n </tr>\n <tr>\n <td>2019-08-17T00:00:00</td>\n <td>0</td>\n </tr>\n <tr>\n <td>2019-08-23T00:00:00</td>\n <td>0</td>\n </tr>\n <tr>\n <td>2020-01-14T00:00:00</td>\n <td>248</td>\n </tr>\n </tbody>\n</table>\nSuppose we wanted to group the data over a 20 day time period. We would need to modify the query as follows:
select\nDatePart,\ncount(CASE\nWHEN R.CHANGETYPE_NAME=\"Added\" THEN 1\nWHEN R.CHANGETYPE_NAME=\"Deleted\" THEN -1\nEND\n) AS Sum\nfrom SpiraTestEntities.R_HistoryChangeSets as R\nwhere\nR.ARTIFACT_TYPE_NAME = \"Requirement\"\ngroup by AddDays(CreateDateTime(Year(R.CHANGE_DATE),1,1,0,0,0), (DayOfYear(R.CHANGE_DATE)/20)*20) as DatePart\nNow when you execute the query, the system is using the following functions to combines the dates down into 20 day ranges:
When executed, this will display:
<table class=\"table table-striped\">\n <tbody>\n <tr class=\"Header\">\n <th>DatePart</th>\n <th>Sum</th>\n </tr>\n <tr>\n <td>2019-08-09T00:00:00</td>\n <td>0</td>\n </tr>\n <tr>\n <td>2020-01-01T00:00:00</td>\n <td>248</td>\n </tr>\n </tbody>\n</table>\nor in graphical form:
"},{"location":"Reporting/Custom-Graph-Tutorial/#further-reading","title":"Further Reading","text":"How to use this page
SpiraPlan has a number of database views available for creating custom reports using ESQL queries. Below, each available table is listed with all of their exact field names.
"},{"location":"Reporting/Custom-Report-Tables/#artifact-associations","title":"Artifact Associations","text":"R_ArtifactAssociations ARTIFACT_LINK_TYPE_ID SOURCE_ARTIFACT_ID SOURCE_ARTIFACT_TYPE_ID DEST_ARTIFACT_ID DEST_ARTIFACT_TYPE_ID CREATOR_ID CREATION_DATE COMMENT SOURCE_ARTIFACT_TYPE_NAME DEST_ARTIFACT_TYPE_NAME CREATOR_NAME ARTIFACT_LINK_TYPE_NAME"},{"location":"Reporting/Custom-Report-Tables/#artifact-attachments","title":"Artifact Attachments","text":"R_ArtifactAttachments ARTIFACT_TYPE_ID ARTIFACT_ID ARTIFACT_TYPE_NAME ARTIFACT_NAME COMMENT CREATOR_ID CREATION_DATE CREATOR_NAME ATTACHMENT_ID PROJECT_ID ARTIFACT_STATUS_NAME"},{"location":"Reporting/Custom-Report-Tables/#artifact-types","title":"Artifact Types","text":"R_ArtifactTypes ARTIFACT_TYPE_ID NAME PREFIX"},{"location":"Reporting/Custom-Report-Tables/#attachments","title":"Attachments","text":"R_Attachments ATTACHMENT_ID ATTACHMENT_TYPE_ID AUTHOR_ID EDITOR_ID FILENAME DESCRIPTION UPLOAD_DATE EDITED_DATE SIZE CURRENT_VERSION PROJECT_ID PROJECT_ATTACHMENT_FOLDER_ID CONCURRENCY_DATE DOCUMENT_STATUS_ID DOCUMENT_TYPE_ID DOCUMENT_STATUS_NAME DOCUMENT_TYPE_NAME TAGS CUST_01... CUST_99 IS_KEY_DOCUMENT DOCUMENT_STATUS_IS_OPEN_STATUS PROJECT_IS_ACTIVE PROJECT_GROUP_ID PROJECT_NAME AUTHOR_NAME EDITOR_NAME ATTACHMENT_TYPE_NAME PROJECT_ATTACHMENT_FOLDER_NAME"},{"location":"Reporting/Custom-Report-Tables/#attachment-folders","title":"Attachment Folders","text":"R_AttachmentFolders PROJECT_ATTACHMENT_FOLDER_ID PROJECT_ID PARENT_PROJECT_ATTACHMENT_FOLDER_ID NAME PROJECT_NAME PROJECT_GROUP_ID"},{"location":"Reporting/Custom-Report-Tables/#attachment-versions","title":"Attachment Versions","text":"R_AttachmentVersions ATTACHMENT_VERSION_ID ATTACHMENT_ID AUTHOR_ID FILENAME DESCRIPTION UPLOAD_DATE SIZE VERSION_NUMBER IS_CURRENT CHANGESET_ID AUTHOR_NAME ATTACHMENT_TYPE_ID PROJECT_ID"},{"location":"Reporting/Custom-Report-Tables/#automation-hosts","title":"Automation Hosts","text":"R_AutomationHosts AUTOMATION_HOST_ID PROJECT_ID NAME DESCRIPTION TOKEN LAST_UPDATE_DATE IS_DELETED CUST_01... CUST_99 PROJECT_NAME PROJECT_GROUP_ID IS_ACTIVE IS_ATTACHMENTS CONCURRENCY_DATE LAST_CONTACT_DATE"},{"location":"Reporting/Custom-Report-Tables/#baselines","title":"Baselines","text":"See | this KB](https://www.inflectra.com/Support/KnowledgeBase/KB550.aspx) for some examples of using this custom report table |
R_Baselines BASELINE_ID PROJECT_ID CREATOR_USER_ID CHANGESET_ID RELEASE_ID NAME DESCRIPTION IS_ACTIVE IS_APPROVED IS_DELETED CREATION_DATE LAST_UPDATE_DATE CONCURRENCY_DATE BASELINE_CREATOR_LOGIN CHANGESET_CREATOR_ID CHANGESET_CREATOR_LOGIN ARTIFACT_TYPE_ID ARTIFACT_TYPE_NAME CHANGESET_DATE CHANGESET_TYPE_ID CHANGESET_TYPE_NAME"},{"location":"Reporting/Custom-Report-Tables/#builds","title":"Builds","text":"R_Builds BUILD_ID BUILD_STATUS_ID RELEASE_ID PROJECT_ID NAME DESCRIPTION"},{"location":"Reporting/Custom-Report-Tables/#capabilities","title":"Capabilities","text":"R_ProjectGroup_Capabilities CAPABILITY_ID PROJECT_GROUP_ID MILESTONE_ID STATUS_ID TYPE_ID PRIORITY_ID NAME DESCRIPTION IS_DELETED PERCENT_COMPLETE PROJECT_REQUIREMENT_COUNT INDENT_LEVEL CONCURRENCY_GUID CREATOR_ID OWNER_ID CREATION_DATE LAST_UPDATED_DATE IS_SUMMARY STATUS_NAME STATUS_IS_OPEN TYPE_NAME PRIORITY_NAME PRIORITY_COLOR PRIORITY_SCORE MILESTONE_NAME CREATOR_NAME OWNER_NAME PROJECT_GROUP_NAME CUST_01... CUST_30"},{"location":"Reporting/Custom-Report-Tables/#capability-priorities","title":"Capability Priorities","text":"R_ProjectGroup_Capability_Priorities PRIORITY_ID NAME COLOR IS_ACTIVE IS_DELETED SCORE"},{"location":"Reporting/Custom-Report-Tables/#capability-requirement-associations","title":"Capability Requirement Associations","text":"R_ProjectGroup_Capability_Project_Requirements CAPABILITY_ID REQUIREMENT_ID ARTIFACT_LINK_TYPE_ID CAPABILITY_NAME REQUIREMENT_NAME ARTIFACT_LINK_TYPE_NAME"},{"location":"Reporting/Custom-Report-Tables/#capability-statuses","title":"Capability Statuses","text":"R_ProjectGroup_Capability_Statuses STATUS_ID NAME POSITION IS_ACTIVE IS_DELETED IS_DEFAULT IS_OPEN ON_BOARD"},{"location":"Reporting/Custom-Report-Tables/#capability-types","title":"Capability Types","text":"R_ProjectGroup_Capability_Types TYPE_ID NAME IS_ACTIVE IS_DELETED IS_DEFAULT"},{"location":"Reporting/Custom-Report-Tables/#comments","title":"Comments","text":"R_Comments ARTIFACT_ID CREATOR_ID COMMENT_TEXT CREATION_DATE CREATOR_NAME ARTIFACT_TYPE_NAME"},{"location":"Reporting/Custom-Report-Tables/#components","title":"Components","text":"R_Components COMPONENT_ID PROJECT_ID NAME IS_DELETED IS_ACTIVE PROJECT_NAME PROJECT_GROUP_ID"},{"location":"Reporting/Custom-Report-Tables/#custom-lists","title":"Custom Lists","text":"R_CustomLists CUSTOM_PROPERTY_LIST_ID PROJECT_ID NAME IS_ACTIVE IS_SORTED_ON_VALUE PROJECT_NAME PROJECT_IS_ACTIVE PROJECT_TEMPLATE_ID"},{"location":"Reporting/Custom-Report-Tables/#custom-list-values","title":"Custom List Values","text":"R_CustomListValues CUSTOM_PROPERTY_VALUE_ID CUSTOM_PROPERTY_LIST_ID NAME PROJECT_ID CUSTOM_PROPERTY_LIST_NAME CUSTOM_PROPERTY_LIST_IS_ACTIVE PROJECT_NAME PROJECT_IS_ACTIVE IS_ACTIVE IS_DELETED DEPENDENT_CUSTOM_PROPERTY_LIST_ID PARENT_CUSTOM_PROPERTY_VALUE_ID"},{"location":"Reporting/Custom-Report-Tables/#custom-property-definitions","title":"Custom Property Definitions","text":"R_CustomPropertyDefinitions CUSTOM_PROPERTY_ID CUSTOM_PROPERTY_TYPE_ID PROJECT_ID ARTIFACT_TYPE_ID NAME PROPERTY_NUMBER IS_DELETED CUSTOM_PROPERTY_LIST_ID LEGACY_NAME PROJECT_NAME PROJECT_IS_ACTIVE ARTIFACT_TYPE_NAME CUSTOM_PROPERTY_TYPE_NAME CUSTOM_PROPERTY_LIST_NAME DEPENDENT_CUSTOM_PROPERTY_ID PROJECT_TEMPLATE_ID"},{"location":"Reporting/Custom-Report-Tables/#document-statuses","title":"Document Statuses","text":"R_DocumentStatuses DOCUMENT_STATUS_ID PROJECT_TEMPLATE_ID NAME POSITION IS_ACTIVE IS_OPEN_STATUS IS_DEFAULT PROJECT_TEMPLATE_NAME"},{"location":"Reporting/Custom-Report-Tables/#document-types","title":"Document Types","text":"R_DocumentTypes DOCUMENT_TYPE_ID PROJECT_TEMPLATE_ID DOCUMENT_WORKFLOW_ID NAME DESCRIPTION IS_ACTIVE IS_DEFAULT PROJECT_TEMPLATE_NAME"},{"location":"Reporting/Custom-Report-Tables/#events","title":"Events","text":"R_Events EVENT_TYPE_ID EVENT_TIME_UTC EVENT_TIME EVENT_CATEGORY EVENT_SEQUENCE EVENT_OCCURRENCE EVENT_CODE EVENT_DETAIL_CODE MESSAGE APPLICATION_PATH APPLICATION_VIRTUAL_PATH MACHINE_NAME REQUEST_URL EXCEPTION_TYPE DETAILS EVENT_TYPE_NAME"},{"location":"Reporting/Custom-Report-Tables/#global-system-custom-property-definitions","title":"Global / System Custom Property Definitions","text":"R_GlobalCustomPropertyDefinitions CUSTOM_PROPERTY_ID CUSTOM_PROPERTY_TYPE_ID CUSTOM_PROPERTY_TYPE_NAME WORKSPACE_TYPE_ID WORKSPACE_TYPE_NAME NAME PROPERTY_NUMBER IS_DELETED CUSTOM_PROPERTY_LIST_ID CUSTOM_PROPERTY_LIST_NAME POSITION DESCRIPTION"},{"location":"Reporting/Custom-Report-Tables/#global-system-custom-property-lists","title":"Global / System Custom Property Lists","text":"R_GlobalCustomLists CUSTOM_PROPERTY_LIST_ID NAME IS_ACTIVE IS_SORTED_ON_VALUE"},{"location":"Reporting/Custom-Report-Tables/#global-system-custom-property-list-values","title":"Global / System Custom Property List Values","text":"R_GlobalCustomListValues CUSTOM_PROPERTY_VALUE_ID NAME IS_ACTIVE IS_DELETED CUSTOM_PROPERTY_LIST_ID CUSTOM_PROPERTY_LIST_NAME CUSTOM_PROPERTY_LIST_IS_ACTIVE"},{"location":"Reporting/Custom-Report-Tables/#history-change-sets","title":"History Change-Sets","text":"R_HistoryChangeSets CHANGESET_ID USER_ID ARTIFACT_TYPE_ID ARTIFACT_ID CHANGE_DATE CHANGETYPE_ID PROJECT_ID REVERT_ID ARTIFACT_DESC CHANGETYPE_NAME USER_NAME ARTIFACT_TYPE_NAME SIGNATURE_HASH MEANING"},{"location":"Reporting/Custom-Report-Tables/#history-details","title":"History Details","text":"R_HistoryDetails FIELD_NAME OLD_VALUE FIELD_CAPTION NEW_VALUE OLD_VALUE_INT OLD_VALUE_DATE NEW_VALUE_INT NEW_VALUE_DATE CHANGESET_ID FIELD_ID CUSTOM_PROPERTY_ID ARTIFACT_ID USER_ID ARTIFACT_TYPE_ID CHANGE_DATE CHANGER_NAME CHANGE_NAME CHANGETYPE_ID"},{"location":"Reporting/Custom-Report-Tables/#incidents","title":"Incidents","text":"R_Incidents INCIDENT_ID PROJECT_ID PRIORITY_ID SEVERITY_ID INCIDENT_STATUS_ID INCIDENT_TYPE_ID OPENER_ID OWNER_ID DESCRIPTION CREATION_DATE CLOSED_DATE LAST_UPDATE_DATE DETECTED_RELEASE_ID RESOLVED_RELEASE_ID START_DATE COMPLETION_PERCENT ESTIMATED_EFFORT ACTUAL_EFFORT REMAINING_EFFORT PROJECTED_EFFORT IS_DELETED VERIFIED_RELEASE_ID PRIORITY_NAME PRIORITY_COLOR SEVERITY_NAME SEVERITY_COLOR INCIDENT_STATUS_NAME INCIDENT_TYPE_NAME OPENER_NAME OWNER_NAME DETECTED_RELEASE_VERSION_NUMBER RESOLVED_RELEASE_VERSION_NUMBER VERIFIED_RELEASE_VERSION_NUMBER PROJECT_GROUP_ID PROJECT_NAME CUST_01... CUST_99 NAME IS_ATTACHMENTS COMPONENT_IDS INCIDENT_STATUS_IS_OPEN_STATUS PROJECT_IS_ACTIVE INCIDENT_TYPE_IS_ISSUE INCIDENT_TYPE_IS_RISK CONCURRENCY_DATE RANK END_DATE DETECTED_BUILD_ID RESOLVED_BUILD_ID DETECTED_BUILD_NAME RESOLVED_BUILD_NAME"},{"location":"Reporting/Custom-Report-Tables/#incident-priorities","title":"Incident Priorities","text":"R_IncidentPriorities PRIORITY_ID PROJECT_TEMPLATE_ID NAME COLOR IS_ACTIVE SCORE PROJECT_TEMPLATE_NAME"},{"location":"Reporting/Custom-Report-Tables/#incident-severities","title":"Incident Severities","text":"R_IncidentSeverities SEVERITY_ID PROJECT_TEMPLATE_ID NAME COLOR IS_ACTIVE SCORE PROJECT_TEMPLATE_NAME"},{"location":"Reporting/Custom-Report-Tables/#incident-statuses","title":"Incident Statuses","text":"R_IncidentStatuses INCIDENT_STATUS_ID PROJECT_TEMPLATE_ID NAME IS_ACTIVE IS_OPEN_STATUS IS_DEFAULT PROJECT_TEMPLATE_NAME"},{"location":"Reporting/Custom-Report-Tables/#incident-types","title":"Incident Types","text":"R_IncidentTypes INCIDENT_TYPE_ID PROJECT_TEMPLATE_ID WORKFLOW_ID NAME IS_ACTIVE IS_ISSUE IS_DEFAULT PROJECT_TEMPLATE_NAME"},{"location":"Reporting/Custom-Report-Tables/#portfolios","title":"Portfolios","text":"R_Portfolios PORTFOLIO_ID NAME DESCRIPTION IS_ACTIVE START_DATE END_DATE PERCENT_COMPLETE REQUIREMENT_COUNT"},{"location":"Reporting/Custom-Report-Tables/#program-milestones","title":"Program Milestones","text":"R_ProjectGroup_Milestones PROJECT_GROUP_MILESTONE_ID PROJECT_GROUP_ID TYPE_ID STATUS_ID NAME DESCRIPTION IS_DELETED START_DATE END_DATE PERCENT_COMPLETE CHILDREN_START_DATE CHILDREN_END_DATE PROJECT_RELEASE_COUNT PROJECT_GROUP_REQUIREMENT_COUNT CONCURRENCY_GUID CREATOR_ID OWNER_ID CREATION_DATE LAST_UPDATED_DATE STATUS_NAME STATUS_IS_OPEN TYPE_NAME CREATOR_NAME OWNER_NAME PROJECT_GROUP_NAME CUST_01... CUST_30"},{"location":"Reporting/Custom-Report-Tables/#program-milestone-releases","title":"Program Milestone Releases","text":"R_ProjectGroup_Milestone_Project_Releases PROJECT_GROUP_MILESTONE_ID RELEASE_ID ARTIFACT_LINK_TYPE_ID PROJECT_GROUP_MILESTONE_NAME RELEASE_NAME ARTIFACT_LINK_TYPE_NAME"},{"location":"Reporting/Custom-Report-Tables/#program-milestone-statuses","title":"Program Milestone Statuses","text":"R_ProjectGroup_Milestone_Statuses STATUS_ID NAME IS_ACTIVE IS_DELETED IS_DEFAULT IS_OPEN"},{"location":"Reporting/Custom-Report-Tables/#program-milestone-types","title":"Program Milestone Types","text":"R_ProjectGroup_Milestone_Types TYPE_ID NAME IS_ACTIVE IS_DELETED IS_DEFAULT"},{"location":"Reporting/Custom-Report-Tables/#project-artifacts-sharing","title":"Project Artifacts Sharing","text":"Retrieves data about cross product associations
R_ProjectArtifactSharings SOURCE_PROJECT_ID DEST_PROJECT_ID ARTIFACT_TYPE_ID SOURCE_PROJECT_NAME DEST_PROJECT_NAME ARTIFACT_TYPE_NAME ARTIFACT_TYPE_PREFIX"},{"location":"Reporting/Custom-Report-Tables/#projects-products","title":"Projects (Products)","text":"R_Projects PROJECT_ID PROJECT_GROUP_ID NAME DESCRIPTION CREATION_DATE WEBSITE WORKING_HOURS WORKING_DAYS NON_WORKING_HOURS TASK_DEFAULT_EFFORT PROJECT_GROUP_NAME PROJECT_GROUP_DESCRIPTION IS_ACTIVE IS_TIME_TRACK_INCIDENTS IS_TIME_TRACK_TASKS IS_EFFORT_INCIDENTS IS_EFFORT_TASKS IS_TASKS_AUTO_CREATE REQ_DEFAULT_ESTIMATE REQ_POINT_EFFORT IS_REQ_STATUS_BY_TASKS IS_REQ_STATUS_BY_TEST_CASES IS_EFFORT_TEST_CASES IS_REQ_STATUS_AUTO_PLANNED PROJECT_TEMPLATE_ID START_DATE END_DATE PERCENT_COMPLETE REQUIREMENT_COUNT CUST_01... CUST_30"},{"location":"Reporting/Custom-Report-Tables/#project-groups-programs","title":"Project Groups (Programs)","text":"R_ProjectGroups PROJECT_GROUP_ID NAME DESCRIPTION WEBSITE PROJECT_TEMPLATE_ID IS_ACTIVE IS_DEFAULT PERCENT_COMPLETE START_DATE END_DATE PORTFOLIO_ID REQUIREMENT_COUNT"},{"location":"Reporting/Custom-Report-Tables/#project-product-membership","title":"Project (Product) Membership","text":"R_ProjectMembership PROJECT_ID USER_ID PROJECT_ROLE_ID PROJECT_NAME PROJECT_ROLE_NAME USER_NAME FIRST_NAME LAST_NAME DEPARTMENT IS_SYSTEM_ADMIN"},{"location":"Reporting/Custom-Report-Tables/#project-release-resources","title":"Project Release Resources","text":"R_ProjectReleaseResources PROJECT_ID USER_ID RELEASE_ID INCIDENT_EFFORT TASK_EFFORT"},{"location":"Reporting/Custom-Report-Tables/#releases","title":"Releases","text":"R_Releases RELEASE_ID PROJECT_ID CREATOR_ID NAME VERSION_NUMBER DESCRIPTION INDENT_LEVEL CREATION_DATE LAST_UPDATE_DATE START_DATE END_DATE RESOURCE_COUNT DAYS_NON_WORKING PLANNED_EFFORT AVAILABLE_EFFORT COUNT_BLOCKED COUNT_CAUTION COUNT_FAILED COUNT_NOT_APPLICABLE COUNT_NOT_RUN COUNT_PASSED TASK_COUNT TASK_PERCENT_ON_TIME TASK_PERCENT_LATE_FINISH TASK_PERCENT_NOT_START TASK_PERCENT_LATE_START TASK_ESTIMATED_EFFORT TASK_ACTUAL_EFFORT TASK_PROJECTED_EFFORT TASK_REMAINING_EFFORT IS_DELETED CREATOR_NAME FULL_NAME PROJECT_NAME PROJECT_GROUP_ID CUST_01... CUST_99 RELEASE_TYPE_ID RELEASE_STATUS_ID OWNER_ID IS_SUMMARY IS_ATTACHMENTS OWNER_NAME RELEASE_TYPE_NAME RELEASE_STATUS_NAME CONCURRENCY_DATE MILESTONE_ID PERCENT_COMPLETE PLANNED_POINTS REQUIREMENT_POINTS REQUIREMENT_COUNT"},{"location":"Reporting/Custom-Report-Tables/#release-test-case-mapping","title":"Release Test Case Mapping","text":"R_ReleaseTestCases RELEASE_ID TEST_CASE_ID RELEASE_NAME RELEASE_VERSION_NUMBER TEST_CASE_NAME PROJECT_ID PROJECT_NAME RELEASE_TYPE_ID RELEASE_TYPE_NAME EXECUTION_STATUS_ID EXECUTION_DATE ACTUAL_DURATION"},{"location":"Reporting/Custom-Report-Tables/#requirements","title":"Requirements","text":"R_Requirements REQUIREMENT_ID AUTHOR_ID OWNER_ID RELEASE_ID PROJECT_ID IMPORTANCE_ID NAME CREATION_DATE INDENT_LEVEL DESCRIPTION LAST_UPDATE_DATE COVERAGE_COUNT_TOTAL COVERAGE_COUNT_PASSED COVERAGE_COUNT_FAILED COVERAGE_COUNT_CAUTION COVERAGE_COUNT_BLOCKED TASK_COUNT TASK_ESTIMATED_EFFORT TASK_ACTUAL_EFFORT TASK_PROJECTED_EFFORT TASK_REMAINING_EFFORT TASK_PERCENT_ON_TIME TASK_PERCENT_LATE_FINISH TASK_PERCENT_NOT_START TASK_PERCENT_LATE_START IS_DELETED AUTHOR_NAME OWNER_NAME IMPORTANCE_NAME RELEASE_VERSION_NUMBER PROJECT_NAME PROJECT_GROUP_ID CUST_01... CUST_99 REQUIREMENT_TYPE_ID REQUIREMENT_STATUS_ID COMPONENT_ID IS_SUMMARY IS_ATTACHMENTS CONCURRENCY_DATE REQUIREMENT_STATUS_NAME REQUIREMENT_TYPE_NAME COMPONENT_NAME ESTIMATE_POINTS ESTIMATED_EFFORT RANK GOAL_ID START_DATE END_DATE PERCENT_COMPLETE"},{"location":"Reporting/Custom-Report-Tables/#requirement-incidents","title":"Requirement Incidents","text":"R_RequirementIncidents INCIDENT_ID DETECTED_RELEASE_ID IS_OPEN_STATUS"},{"location":"Reporting/Custom-Report-Tables/#requirement-steps","title":"Requirement Steps","text":"R_RequirementSteps REQUIREMENT_ID POSITION DESCRIPTION IS_DELETED CREATION_DATE LAST_UPDATE_DATE CONCURRENCY_DATE REQUIREMENT_NAME REQUIREMENT_LAST_UPDATE_DATE PROJECT_IS_ACTIVE PROJECT_PROJECT_GROUP_ID PROJECT_NAME"},{"location":"Reporting/Custom-Report-Tables/#requirement-test-case-coverage","title":"Requirement Test Case Coverage","text":"R_RequirementTestCases REQUIREMENT_ID TEST_CASE_ID REQUIREMENT_NAME TEST_CASE_NAME PROJECT_ID PROJECT_NAME"},{"location":"Reporting/Custom-Report-Tables/#requirement-test-step-coverage","title":"Requirement Test Step Coverage","text":"R_RequirementTestSteps TEST_STEP_ID REQUIREMENT_NAME POSITION STEP_DESCRIPTION EXPECTED_RESULT SAMPLE_DATA PROJECT_ID PROJECT_NAME"},{"location":"Reporting/Custom-Report-Tables/#requirement-types","title":"Requirement Types","text":"R_RequirementTypes REQUIREMENT_TYPE_ID REQUIREMENT_WORKFLOW_ID PROJECT_TEMPLATE_ID NAME ICON IS_ACTIVE IS_STEPS IS_DEFAULT IS_KEY_TYPE PROJECT_TEMPLATE_NAME"},{"location":"Reporting/Custom-Report-Tables/#risks","title":"Risks","text":"R_Risks RISK_ID RISK_IMPACT_ID RISK_STATUS_ID RISK_PROBABILITY_ID RISK_TYPE_ID PROJECT_ID CREATOR_ID OWNER_ID PROJECT_GROUP_ID RELEASE_ID COMPONENT_ID NAME DESCRIPTION IS_DELETED CREATION_DATE LAST_UPDATE_DATE CONCURRENCY_DATE REVIEW_DATE GOAL_ID CLOSED_DATE IS_ATTACHMENTS RISK_PROBABILITY_NAME RISK_PROBABILITY_COLOR RISK_PROBABILITY_SCORE RISK_IMPACT_NAME RISK_IMPACT_COLOR RISK_IMPACT_SCORE RISK_EXPOSURE RISK_STATUS_NAME RISK_STATUS_IS_OPEN RISK_TYPE_NAME CREATOR_NAME OWNER_NAME RELEASE_VERSION_NUMBER RELEASE_NAME COMPONENT_NAME GOAL_NAME PROJECT_IS_ACTIVE PROJECT_PROJECT_GROUP_ID PROJECT_NAME CUST_01... CUST_99"},{"location":"Reporting/Custom-Report-Tables/#risk-impacts","title":"Risk Impacts","text":"R_RiskImpacts RISK_IMPACT_ID PROJECT_TEMPLATE_ID NAME COLOR IS_ACTIVE POSITION SCORE PROJECT_TEMPLATE_NAME"},{"location":"Reporting/Custom-Report-Tables/#risk-mitigations","title":"Risk Mitigations","text":"R_RiskMitigations RISK_ID POSITION DESCRIPTION IS_DELETED CREATION_DATE LAST_UPDATE_DATE CONCURRENCY_DATE IS_ACTIVE REVIEW_DATE RISK_NAME RISK_REVIEW_DATE PROJECT_IS_ACTIVE PROJECT_PROJECT_GROUP_ID PROJECT_NAME"},{"location":"Reporting/Custom-Report-Tables/#risk-probabilities","title":"Risk Probabilities","text":"R_RiskProbabilities RISK_PROBABILITY_ID PROJECT_TEMPLATE_ID NAME COLOR IS_ACTIVE POSITION SCORE PROJECT_TEMPLATE_NAME"},{"location":"Reporting/Custom-Report-Tables/#risk-statuses","title":"Risk Statuses","text":"R_RiskStatuses RISK_STATUS_ID NAME IS_ACTIVE IS_DEFAULT IS_OPEN POSITION PROJECT_TEMPLATE_ID PROJECT_TEMPLATE_NAME"},{"location":"Reporting/Custom-Report-Tables/#risk-types","title":"Risk Types","text":"R_RiskTypes RISK_TYPE_ID NAME IS_ACTIVE IS_DEFAULT PROJECT_TEMPLATE_ID RISK_WORKFLOW_ID PROJECT_TEMPLATE_NAME"},{"location":"Reporting/Custom-Report-Tables/#source-code-associations","title":"Source Code Associations","text":"R_SourceCodeAssociations ARTIFACT_SOURCE_CODE_REVISION_ID ARTIFACT_TYPE_ID ARTIFACT_ID REVISION_KEY COMMENT CREATION_DATE ARTIFACT_TYPE_NAME ARTIFACT_TYPE_PREFIX"},{"location":"Reporting/Custom-Report-Tables/#source-code-commits","title":"Source Code Commits","text":"R_SourceCodeCommits VERSION_CONTROL_SYSTEM_ID PROJECT_ID REVISION_ID NAME REVISION_KEY AUTHOR_NAME MESSAGE UPDATE_DATE CONTENT_CHANGED PROPERTIES_CHANGED VERSION_CONTROL_SYSTEM_NAME VERSION_CONTROL_SYSTEM_DESCRIPTION VERSION_CONTROL_SYSTEM_IS_ACTIVE PROJECT_NAME BRANCH_NAME BRANCH_PATH BRANCH_IS_HEAD"},{"location":"Reporting/Custom-Report-Tables/#tasks","title":"Tasks","text":"R_Tasks TASK_ID TASK_STATUS_ID PROJECT_ID REQUIREMENT_ID RELEASE_ID CREATOR_ID OWNER_ID TASK_PRIORITY_ID NAME DESCRIPTION CREATION_DATE LAST_UPDATE_DATE START_DATE END_DATE COMPLETION_PERCENT ESTIMATED_EFFORT ACTUAL_EFFORT PROJECTED_EFFORT REMAINING_EFFORT IS_DELETED TASK_STATUS_NAME OWNER_NAME CREATOR_NAME TASK_PRIORITY_NAME PROJECT_NAME PROJECT_GROUP_ID RELEASE_VERSION_NUMBER CUST_01... CUST_99 TASK_TYPE_ID TASK_FOLDER_ID IS_ATTACHMENTS CONCURRENCY_DATE REQUIREMENT_NAME TASK_TYPE_NAME COMPONENT_ID COMPONENT_NAME RISK_ID"},{"location":"Reporting/Custom-Report-Tables/#task-priorities","title":"Task Priorities","text":"R_TaskPriorities TASK_PRIORITY_ID PROJECT_TEMPLATE_ID NAME IS_ACTIVE COLOR SCORE PROJECT_TEMPLATE_NAME"},{"location":"Reporting/Custom-Report-Tables/#task-types","title":"Task Types","text":"R_TaskTypes TASK_TYPE_ID PROJECT_TEMPLATE_ID TASK_WORKFLOW_ID NAME POSITION IS_ACTIVE IS_DEFAULT IS_PULL_REQUEST PROJECT_TEMPLATE_NAME"},{"location":"Reporting/Custom-Report-Tables/#test-cases","title":"Test Cases","text":"R_TestCases TEST_CASE_ID EXECUTION_STATUS_ID TEST_CASE_PRIORITY_ID PROJECT_ID AUTHOR_ID NAME OWNER_ID DESCRIPTION EXECUTION_DATE CREATION_DATE LAST_UPDATE_DATE AUTOMATION_ENGINE_ID AUTOMATION_ATTACHMENT_ID ESTIMATED_DURATION IS_DELETED EXECUTION_STATUS_NAME TEST_CASE_PRIORITY_NAME AUTHOR_NAME OWNER_NAME AUTOMATION_ENGINE_NAME PROJECT_NAME PROJECT_GROUP_ID CUST_01... CUST_99 CONCURRENCY_DATE TEST_CASE_STATUS_ID TEST_CASE_TYPE_ID TEST_CASE_FOLDER_ID IS_ATTACHMENTS IS_TEST_STEPS ACTUAL_DURATION TEST_CASE_STATUS_NAME TEST_CASE_TYPE_NAME COMPONENT_IDS IS_SUSPECT"},{"location":"Reporting/Custom-Report-Tables/#test-case-folders","title":"Test Case Folders","text":"R_TestCaseFolders TEST_CASE_FOLDER_ID PARENT_TEST_CASE_FOLDER_ID PROJECT_ID NAME DESCRIPTION EXECUTION_DATE LAST_UPDATE_DATE ESTIMATED_DURATION ACTUAL_DURATION COUNT_PASSED COUNT_FAILED COUNT_BLOCKED COUNT_CAUTION COUNT_NOT_RUN COUNT_NOT_APPLICABLE PROJECT_NAME PROJECT_GROUP_ID"},{"location":"Reporting/Custom-Report-Tables/#test-case-incidents","title":"Test Case Incidents","text":"R_TestCaseIncidents INCIDENT_ID DETECTED_RELEASE_ID RESOLVED_RELEASE_ID VERIFIED_RELEASE_ID IS_OPEN_STATUS"},{"location":"Reporting/Custom-Report-Tables/#test-case-types","title":"Test Case Types","text":"R_TestCaseTypes TEST_CASE_TYPE_ID PROJECT_TEMPLATE_ID TEST_CASE_WORKFLOW_ID NAME IS_ACTIVE POSITION IS_DEFAULT IS_EXPLORATORY IS_BDD PROJECT_TEMPLATE_NAME"},{"location":"Reporting/Custom-Report-Tables/#test-configuration-entries","title":"Test Configuration Entries","text":"R_TestConfigurationEntries TEST_CONFIGURATION_SET_ID POSITION TEST_CONFIGURATION_SET_NAME IS_TEST_CONFIGURATION_SET_ACTIVE CUSTOM_PROPERTY_VALUE_ID TEST_CASE_PARAMETER_NAME TEST_CASE_PARAMETER_VALUE PROJECT_NAME PROJECT_GROUP_ID"},{"location":"Reporting/Custom-Report-Tables/#test-configuration-sets","title":"Test Configuration Sets","text":"R_TestConfigurationSets TEST_CONFIGURATION_SET_ID PROJECT_ID NAME DESCRIPTION IS_ACTIVE IS_DELETED CREATION_DATE LAST_UPDATED_DATE CONCURRENCY_DATE PROJECT_NAME PROJECT_GROUP_ID"},{"location":"Reporting/Custom-Report-Tables/#test-runs","title":"Test Runs","text":"R_TestRuns TEST_RUN_ID TEST_CASE_ID NAME DESCRIPTION ESTIMATED_DURATION ACTUAL_DURATION TEST_RUN_TYPE_ID TESTER_ID EXECUTION_STATUS_ID START_DATE END_DATE RUNNER_NAME RUNNER_TEST_NAME RUNNER_ASSERT_COUNT RUNNER_MESSAGE RUNNER_STACK_TRACE EXECUTION_STATUS_NAME TESTER_NAME TEST_RUNS_PENDING_ID RELEASE_ID TEST_SET_ID TEST_SET_TEST_CASE_ID RELEASE_NAME RELEASE_VERSION_NUMBER TEST_SET_NAME TEST_RUN_TYPE_NAME AUTOMATION_HOST_ID AUTOMATION_HOST_NAME AUTOMATION_ENGINE_ID BUILD_ID BUILD_NAME TEST_RUN_FORMAT_ID PROJECT_NAME PROJECT_GROUP_ID CUST_01... CUST_99 IS_ATTACHMENTS IS_DELETED CONCURRENCY_DATE PROJECT_ID CHANGESET_ID TEST_CONFIGURATION_ID"},{"location":"Reporting/Custom-Report-Tables/#test-run-incidents","title":"Test Run Incidents","text":"R_TestRunIncidents TEST_RUN_ID INCIDENT_ID DETECTED_RELEASE_ID RESOLVED_RELEASE_ID VERIFIED_RELEASE_ID IS_OPEN_STATUS"},{"location":"Reporting/Custom-Report-Tables/#test-run-steps","title":"Test Run Steps","text":"R_TestRunSteps TEST_RUN_STEP_ID EXECUTION_STATUS_ID TEST_CASE_ID TEST_STEP_ID TEST_RUN_ID DESCRIPTION POSITION EXPECTED_RESULT SAMPLE_DATA ACTUAL_RESULT EXECUTION_STATUS_NAME TEST_CASE_NAME PROJECT_ID PROJECT_NAME PROJECT_GROUP_ID START_DATE END_DATE ACTUAL_DURATION"},{"location":"Reporting/Custom-Report-Tables/#test-sets","title":"Test Sets","text":"R_TestSets TEST_SET_ID PROJECT_ID RELEASE_ID TEST_SET_STATUS_ID CREATOR_ID OWNER_ID AUTOMATION_HOST_ID TEST_RUN_TYPE_ID RECURRENCE_ID NAME DESCRIPTION CREATION_DATE PLANNED_DATE LAST_UPDATE_DATE IS_DELETED CONCURRENCY_DATE RELEASE_VERSION_NUMBER PROJECT_NAME TEST_CASE_COUNT TEST_SET_STATUS_NAME CREATOR_NAME OWNER_NAME PROJECT_ACTIVE_YN AUTOMATION_HOST_NAME TEST_RUN_TYPE_NAME RECURRENCE_NAME PROJECT_GROUP_ID CUST_01... CUST_99 TEST_SET_FOLDER_ID IS_ATTACHMENTS BUILD_EXECUTE_TIME_INTERVAL ESTIMATED_DURATION ACTUAL_DURATION COUNT_PASSED COUNT_FAILED COUNT_CAUTION COUNT_BLOCKED COUNT_NOT_RUN COUNT_NOT_APPLICABLE EXECUTION_DATE IS_DYNAMIC DYNAMIC_QUERY IS_AUTO_SCHEDULED TEST_CONFIGURATION_SET_ID"},{"location":"Reporting/Custom-Report-Tables/#test-set-folders","title":"Test Set Folders","text":"R_TestSetFolders TEST_SET_FOLDER_ID PROJECT_ID PARENT_TEST_SET_FOLDER_ID NAME DESCRIPTION CREATION_DATE LAST_UPDATE_DATE EXECUTION_DATE ESTIMATED_DURATION ACTUAL_DURATION COUNT_PASSED COUNT_FAILED COUNT_CAUTION COUNT_BLOCKED COUNT_NOT_RUN COUNT_NOT_APPLICABLE PROJECT_NAME PROJECT_GROUP_ID"},{"location":"Reporting/Custom-Report-Tables/#test-set-incidents","title":"Test Set Incidents","text":"R_TestSetIncidents INCIDENT_ID DETECTED_RELEASE_ID RESOLVED_RELEASE_ID VERIFIED_RELEASE_ID IS_OPEN_STATUS"},{"location":"Reporting/Custom-Report-Tables/#test-set-test-cases","title":"Test Set Test Cases","text":"R_TestSetTestCases TEST_SET_TEST_CASE_ID TEST_SET_ID TEST_CASE_ID OWNER_ID POSITION TEST_SET_NAME TEST_CASE_NAME OWNER_NAME PROJECT_ID PROJECT_NAME PLANNED_DATE IS_SETUP_TEARDOWN"},{"location":"Reporting/Custom-Report-Tables/#test-steps","title":"Test Steps","text":"R_TestSteps TEST_STEP_ID TEST_CASE_ID EXECUTION_STATUS_ID DESCRIPTION LINKED_TEST_CASE_ID POSITION EXPECTED_RESULT SAMPLE_DATA LAST_UPDATE_DATE IS_DELETED EXECUTION_STATUS_NAME TEST_CASE_NAME PROJECT_ID PROJECT_NAME PROJECT_GROUP_ID CUST_01... CUST_99 IS_ATTACHMENTS CONCURRENCY_DATE PRECONDITION"},{"location":"Reporting/Custom-Report-Tables/#users","title":"Users","text":"R_Users USER_NAME EMAIL_ADDRESS IS_ACTIVE CREATION_DATE LDAP_DN FIRST_NAME LAST_NAME MIDDLE_INITIAL DEPARTMENT LAST_UPDATE_DATE TIMEZONE LAST_OPENED_PROJECT_ID IS_APPROVED LAST_LOGIN_DATE LAST_ACTIVITY_DATE"},{"location":"Reporting/Custom-Report-Tutorial/","title":"Custom Reports Tutorial and Introduction","text":""},{"location":"Reporting/Custom-Report-Tutorial/#introduction","title":"Introduction","text":"One of the maxims I always tell developers is that regardless of what you build, customers will never be satisfied with the reports you offer or the integration that you provide. In fact the two most underestimated tasks in software development are data feeds and reporting. A great feature of SpiraPlan (and SpiraTest and SpiraTeam) is the ability to do custom reporting, so that you are not limited to only the reports that ship with the system. This guide explains how to use these powerful custom reporting features.
How to get more info and gotchas
You need to be a Spira system administrator to create or modify reports because they have the potential to affect all products in the system. To get to reports go to: Administration > System Administration > Reporting > Edit Reports:
From here you can either make a copy of one of the existing Spira built-in reports or create completely new report from scratch. The decision of which choice to make will depend on whether:
Once you have created your custom report, click on the Edit button for the report to go to the report details page. This displays a list of formats, sections, and the header and footer of the report.
When you edit a report you will see the following different items that can be changed/edited:
There are two types of report section that you can use in your report:
A report you create can have a mixture of the two sections, for example you could start the report with the standard project name and description and follow that with a custom section that displays a table of custom data (e.g. a risk cube or other table of data).
"},{"location":"Reporting/Custom-Report-Tutorial/#how-to-create-and-edit-a-custom-report","title":"How to Create and Edit a Custom Report","text":"In this tutorial you will learn how to:
The first thing we need to do is make a copy of one of the standard reports s that we can change it. For your safety, Spira will not let you modify the original copy of the report. To create a copy:
Clone next to the report you want to clone. In this example, we are going to make a copy of the \"Test Case Summary Report\":When editing a report, you can change the following fields:
For this example, we will edit the second Standard Section of the \"Test Case Summary Report\" clone. This report is a table-based layout. We will:
Under the list of 'Standard Sections', click the Customize button next to the 'Test Case List' section. This will show the edit dialog box for this section of the report:
Here, you can edit the following parts of the report section:
Feel free to edit the\u00a0Header\u00a0and\u00a0Footer\u00a0to make your section more readable, for example include a section heading or some introductory text. You might want to add a horizontal line (\\) to the footer to mark the end the report section.
The full contents of the\u00a0Template\u00a0section looks like the example below:
<?xml version=\"1.0\" encoding=\"utf-8\"?>\n<xsl:stylesheet version=\"1.0\" xmlns:xsl=\"http://www.w3.org/1999/XSL/Transform\" xmlns:msxsl=\"urn:schemas-microsoft-com:xslt\" exclude-result-prefixes=\"msxsl\">\n<xsl:template match=\"/TestCaseData\">\n<table class=\"DataGrid\" style=\"width:100%\">\n<tr>\n<th>Test #</th>\n<th>Name</th>\n<th>Description</th>\n<th>Priority</th>\n<xsl:if test=\"TestCase/TestSteps\">\n<th>Test Step</th>\n<th>Test Step Description</th>\n<th>Test Step Expected Result</th>\n<th>Test Step Sample Data</th>\n</xsl:if>\n<th>Status</th>\n<th>Author</th>\n<th>Owner</th>\n<th>Automation Engine</th>\n<th>Est. Duration</th>\n<th>Created On</th>\n<th>Last Modified</th>\n<th>Last Executed</th>\n<xsl:for-each select=\"TestCase[1]/CustomProperties/CustomProperty\">\n<th>\n<xsl:value-of select=\"Alias\" />\n</th>\n</xsl:for-each>\n</tr>\n<xsl:for-each select=\"TestCase\">\n<tr>\n<td>\n<xsl:value-of select=\"TestCaseId\" />\n</td>\n<td>\n<xsl:attribute name=\"style\">\npadding-left: <xsl:value-of select=\"string-length(IndentLevel)*2\" />\npx;\n </xsl:attribute>\n<if test=\"FolderYn='Y'\">\n<b><xsl:value-of select=\"Name\" /></b>\n</if>\n<if test=\"FolderYn='N'\">\n<xsl:value-of select=\"Name\" />\n</if>\n</td>\n<td>\n<xsl:value-of select=\"Description\" disable-output-escaping=\"yes\" />\n</td>\n<td>\n<xsl:value-of select=\"TestCasePriorityName\" />\n</td>\n<if test=\"TestSteps\">\n<td></td>\n<td></td>\n<td></td>\n<td></td>\n</if>\n<td>\n<xsl:value-of select=\"ExecutionStatusName\" />\n</td>\n<td>\n<xsl:value-of select=\"AuthorName\" />\n</td>\n<td>\n<xsl:value-of select=\"OwnerName\" />\n</td>\n<td>\n<xsl:value-of select=\"AutomationEngineName\" />\n</td>\n<td class=\"Timespan\">\n<xsl:value-of select=\"EstimatedDuration\" />\n</td>\n<td class=\"Date\">\n<xsl:call-template name=\"format-date\">\n<xsl:with-param name=\"datetime\" select=\"CreationDate\" />\n<\\xsl:call-template>\n </td>\n<td class=\"Date\">\n<xsl:call-template name=\"format-date\">\n<xsl:with-param name=\"datetime\" select=\"LastUpdateDate\" />\n<\\xsl:call-template>\n </td>\n<td class=\"Date\">\n<xsl:call-template name=\"format-date\">\n<xsl:with-param name=\"datetime\" select=\"ExecutionDate\" />\n<\\xsl:call-template>\n </td>\n<xsl:for-each select=\"CustomProperties/CustomProperty\">\n<td>\n<xsl:value-of select=\"Value\" />\n</td>\n</xsl:for-each>\n</tr>\n<xsl:for-each select=\"TestSteps/TestStep\">\n<tr>\n<td></td>\n<td></td>\n<td></td>\n<td></td>\n<td>\n<xsl:value-of select=\"position()\" />\n</td>\n<td>\n<xsl:value-of select=\"Description\" disable-output-escaping=\"yes\" />\n<xsl:value-of select=\"' '\" />\n<xsl:value-of select=\"LinkedTestCaseName\" />\n</td>\n<td>\n<xsl:value-of select=\"ExpectedResult\" disable-output-escaping=\"yes\" />\n</td>\n<td>\n<xsl:value-of select=\"SampleData\" disable-output-escaping=\"yes\" />\n</td>\n<td>\n<xsl:value-of select=\"ExecutionStatusName\" />\n</td>\n<td></td>\n<td></td>\n<td></td>\n<td></td>\n<td></td>\n<td></td>\n</tr>\n</xsl:for-each>\n</xsl:for-each>\n</table>\n</xsl:template>\n<xsl:template name=\"format-date\">\n<xsl:param name=\"datetime\" />\n<xsl:variable name=\"date\" select=\"substring-before($datetime, 'T')\" />\n<xsl:variable name=\"year\" select=\"substring-before($date, '-')\" />\n<xsl:variable name=\"month\" select=\"substring-before(substring-after($date, '-'), '-')\" />\n<xsl:variable name=\"day\" select=\"substring-after(substring-after($date, '-'), '-')\" />\n<xsl:variable name=\"time\" select=\"substring-before(substring-after($datetime, 'T'), '.')\" />\n<xsl:variable name=\"monthname\">\n<xsl:choose>\n<xsl:when test=\"$month='01'\">\n<xsl:value-of select=\"'Jan'\" />\n</xsl:when>\n<xsl:when test=\"$month='02'\">\n<xsl:value-of select=\"'Feb'\" />\n</xsl:when>\n<xsl:when test=\"$month='03'\">\n<xsl:value-of select=\"'Mar'\" />\n</xsl:when>\n<xsl:when test=\"$month='04'\">\n<xsl:value-of select=\"'Apr'\" />\n</xsl:when>\n<xsl:when test=\"$month='05'\">\n<xsl:value-of select=\"'May'\" />\n</xsl:when>\n<xsl:when test=\"$month='06'\">\n<xsl:value-of select=\"'Jun'\" />\n</xsl:when>\n<xsl:when test=\"$month='07'\">\n<xsl:value-of select=\"'Jul'\" />\n</xsl:when>\n<xsl:when test=\"$month='08'\">\n<xsl:value-of select=\"'Aug'\" />\n</xsl:when>\n<xsl:when test=\"$month='09'\">\n<xsl:value-of select=\"'Sep'\" />\n</xsl:when>\n<xsl:when test=\"$month='10'\">\n<xsl:value-of select=\"'Oct'\" />\n</xsl:when>\n<xsl:when test=\"$month='11'\">\n<xsl:value-of select=\"'Nov'\" />\n</xsl:when>\n<xsl:when test=\"$month='12'\">\n<xsl:value-of select=\"'Dec'\" />\n</xsl:when>\n<xsl:otherwise>\n<xsl:value-of select=\"''\" />\n</xsl:otherwise>\n</xsl:choose>\n<xsl:variable>\n<xsl:value-of select=\"concat($day, '-' ,$monthname, '-', $year , ' ', $time)\" />\n</xsl:template>\n</xsl:stlyesheet>\nThis is the underlying template that reads the data in Spira and turns it into a simple HTML table containing all of the columns and rows to be reported on. As you can see, it includes the HTML elements for the table:
<table class=\"DataGrid\" style=\"width:100%\">\nThe template also includes XSLT selectors for looping through all of the test cases in the Spira product:
<xsl:for-each select=\"TestCase\">\nBefore we can successfully modify the report, we need to understand what data is being returned by Spira.
"},{"location":"Reporting/Custom-Report-Tutorial/#viewing-the-data-available-for-reporting","title":"Viewing the Data Available for Reporting","text":"To see the data that is available for reporting, you need to open up another browser tab and then go to the\u00a0Reports\u00a0section of Spira:
Now click on the 'Test Case Summary' report from the left-hand navigation. This displays the Report Configuration page:
Create Report\u00a0buttonSpira will generate the report in \"raw XML format\":
<Report>\n<Title>\nTest Case Summary Report\n </Title>\n<ProjectData>\n<Project>\n<ArtifactPrefix>PR</ArtifactPrefix>\n<ArtifactType>Project</ArtifactType>\n<ArtifactToken>PR-1</ArtifactToken>\n<ArtifactId>1</ArtifactId>\n<ProjectId>1</ProjectId>\n<ProjectGroupId>2</ProjectGroupId>\n<Name>Library Information System</Name>\n<Description>\nSample application that allows users to manage books, authors and lending records for a typical branch library\n </Description>\n<CreationDate>2005-11-30T19:00:00</CreationDate>\n<Website>www.libraryinformationsystem.org</Website>\n<IsActive>True</IsActive>\n</Project>\n</ProjectData>\n<TestCaseData>\n<TestCase>\n<TestCaseId>1</TestCaseId>\n<ProjectId>1</ProjectId>\n<ExecutionStatusId>4</ExecutionStatusId>\n<AuthorId>2</AuthorId>\n<OwnerId>2</OwnerId>\n<TestCasePriorityId />\n<AutomationEngineId />\n<AutomationAttachmentId />\n<Name>l Tests</Name>\n<Description />\n<IndentLevel>A</IndentLevel>\n<ExecutionDate>3-11-30T19:00:00</ExecutionDate>\n<CreationDate>3-11-30T19:00:00</CreationDate>\n<LastUpdateDate>3-11-30T19:00:00</LastUpdateDate>\n<ConcurrencyDate>3-11-30T19:00:00</ConcurrencyDate>\n<EstimatedDuration />\n<VisibleYn>Y</VisibleYn>\n<FolderYn>Y</FolderYn>\n<ExpandedYn>Y</ExpandedYn>\n<ActiveYn>Y</ActiveYn>\n<AttachmentsYn>N</AttachmentsYn>\n<TestStepsYn>N</TestStepsYn>\n<FolderCountPassed>1</FolderCountPassed>\n<FolderCountFailed>3</FolderCountFailed>\n<FolderCountCaution>1</FolderCountCaution>\n<FolderCountBlocked>1</FolderCountBlocked>\n<FolderCountNotRun>0</FolderCountNotRun>\n<FolderCountNotApplicable>0</FolderCountNotApplicable>\n<ExecutionStatusName>N/A</ExecutionStatusName>\n<AuthorName>Fred Bloggs</AuthorName>\n<OwnerName>Fred Bloggs</OwnerName>\n<ProjectName />\n<TestCasePriorityName />\n<AutomationEngineName />\n<Custom_01 />\n<Custom_02 />\n...\n <Custom_30 />\n<IsDeleted>False</IsDeleted>\n<CustomProperties>\n<CustomProperty>\n<Alias>URL</Alias>\n<Name>Custom_01</Name>\n<Type>Text</Type>\n</CustomProperty>\n<CustomProperty>\n<Alias>Test Type</Alias>\n<Name>Custom_02</Name>\n<Type>List</Type>\n</CustomProperty>\n</CustomProperties>\n<Discussions />\n</TestCase>\n...\n <TestCaseData>\n</TestCaseData>\n</TestCaseData>\n</Report>\nThis fragment of the report lets you see all of the data that is available for displaying in your report. You can navigate this hierarchy of information using the special XSLT selection language called XPATH. This lets you query the data returned from Spira to retrieve specific data elements that can be displayed in the report. Before we start modifying the report XSLT to use this data, we first need to get a basic understanding of XPATH itself.
"},{"location":"Reporting/Custom-Report-Tutorial/#understanding-xpath","title":"Understanding XPATH","text":"(this section includes material from the website: http://www.whoishostingthis.com/resources/xslt/)
XPath is used to navigate through elements and attributes in an XML document. XPath uses path expressions to select nodes or node-sets in an XML document. These path expressions look very much like the expressions you see when you work with a traditional computer file system.
In XPath, there are seven kinds of nodes:
XML documents are treated as trees of nodes. The topmost element of the tree is called the root element.
In the examples that follow we shall be using the following simple XML document:
<?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<bookstore>\n<book>\n<title lang=\"en\">Harry Potter</title>\n<author>J K. Rowling</author>\n<year>2005</year>\n<price>29.99</price>\n</book>\n</bookstore>\nThis document contains the following node types:
XPath uses path expressions to select nodes in an XML document. The node is selected by following a path or steps. The most useful path expressions are listed below:
Expression Description nodename Selects all nodes with the name \\\"nodename\\\" / Selects from the root node // Selects nodes in the document from the current node that match the selection no matter where they are . Selects the current node .. Selects the parent of the current node @ Selects attributesIn the table below we have listed some path expressions and the result of the expressions if used on our sample document:
Path Expression Result bookstore Selects all nodes with the name \\\"bookstore\\\" /bookstore Selects the root element bookstore Note:\u00a0If the path starts with a slash ( / ) it always represents an absolute path to an element! bookstore/book Selects all book elements that are children of bookstore //book Selects all book elements no matter where they are in the document bookstore//book Selects all book elements that are descendant of the bookstore element, no matter where they are under the bookstore element //\\@lang Selects all attributes that are named lang"},{"location":"Reporting/Custom-Report-Tutorial/#predicates","title":"Predicates","text":"Predicates are used to find a specific node or a node that contains a specific value. Predicates are always embedded in square brackets.
In the table below we have listed some path expressions with predicates and the result of the expressions:
Path Expression Result /bookstore/book[1] Selects the first book element that is the child of the bookstore element /bookstore/book[last()] Selects the last book element that is the child of the bookstore element /bookstore/book[last()-1] Selects the last but one book element that is the child of the bookstore element /bookstore/book[position()\\<3] Selects the first two book elements that are children of the bookstore element //title[\\@lang] Selects all the title elements that have an attribute named lang //title[\\@lang='en'] Selects all the title elements that have a \\\"lang\\\" attribute with a value of \\\"en\\\" /bookstore/book[price>35.00] Selects all the book elements of the bookstore element that have a price element with a value greater than 35.00 /bookstore/book[price>35.00]/title Selects all the title elements of the book elements of the bookstore element that have a price element with a value greater than 35.00"},{"location":"Reporting/Custom-Report-Tutorial/#selecting-unknown-nodes","title":"Selecting Unknown Nodes","text":"XPath wildcards can be used to select unknown XML nodes:
Wildcard Description * Matches any element node @* Matches any attribute node node() Matches any node of any kindIn the table below we have listed some path expressions and the result of the expressions:
Path Expression Result /bookstore/* Selects all the child element nodes of the bookstore element //* Selects all elements in the document //title[@*] Selects all title elements which have at least one attribute of any kind"},{"location":"Reporting/Custom-Report-Tutorial/#selecting-several-paths","title":"Selecting Several Paths","text":"By using the | operator in an XPath expression you can select several paths.
In the table below we have listed some path expressions and the result of the expressions:
Path Expression Result //book/title | //book/price Selects all the title AND price elements of all book elements //title | //price Selects all the title AND price elements in the document /bookstore/book/title | //price Selects all the title elements of the book element of the bookstore element AND all the price elements in the documentNow that we understand the basics of XPath we can use that knowledge to modify our XSLT template to change the data that is included in our report.
"},{"location":"Reporting/Custom-Report-Tutorial/#modifying-the-report-xml-template","title":"Modifying the Report XML Template","text":"In the standard report it will display a list of test cases with various standard fields plus all of the custom properties (it uses an XSLT for-each loop to dynamically add all of the custom properties). For our example, we want to do the following:
To remove the test steps, delete the following sections from the XSLT template:
<xsl:if test=\\\"TestCase/TestSteps\\\">\n<th>Test Step</th>\n<th>Test Step Description</th>\n<th>Test Step Expected Result</th>\n<th>Test Step Sample Data</th>\n</xsl:if>\n<xsl:if test=\"TestSteps\">\n<td><td>\n<td></td>\n<td></td>\n<td></td>\n</xsl:if>\nThis removes the four columns related to test steps.
"},{"location":"Reporting/Custom-Report-Tutorial/#removing-the-creation-date","title":"Removing the Creation Date","text":"To remove the creation date, delete the header cell and body cell:
<th>Created On</th>\nand
<td class=\"Date\">\\\n <xsl:call-template name=\"format-date\">\n<xsl:with-param name=\"datetime\" select=\"CreationDate\" />\n</xsl:call-template>\\\n</td>\nNow to add the cell headers, we just need to add two \\ tags to the header of the table. This is done by adding:
<th>% Passed</th>\n<th>% Failed</th>\nNow to actually get the data, we need to use the following XPATH queries:
Note: the mathematical operators for XPATH are: + (add), * (multiply), - (subtract), and div (division). The slash is not used for division because it is already used as a node path separator.
So the section we need to add to the table body in the report would be:
<td>\n<xsl:value-of select=\"FolderCountPassed div (FolderCountPassed + FolderCountFailed + FolderCountCaution + FolderCountNotRun + FolderCountBlocked) * 100\" />\n%\n</td>\n<td>\n<xsl:value-of select=\"FolderCountFailed div (FolderCountPassed + FolderCountFailed + FolderCountCaution + FolderCountNotRun + FolderCountBlocked) * 100\" />\n%\n</td>\nNow that have make the changes, the complete XSLT template will be:
<?xml version=\"1.0\" encoding=\"utf-8\"?>\n<xsl:stylesheet version=\"1.0\" xmlns:xsl=\"http://www.w3.org/1999/XSL/Transform\" xmlns:msxsl=\"urn:schemas-microsoft-com:xslt\" exclude-result-prefixes=\"msxsl\">\n<xsl:template match=\"/TestCaseData\">\n<table class=\"DataGrid\" style=\"width:100%\">\n<tr>\n<th>Test #</th>\n<th>Name</th>\n<th>Description</th>\n<th>Priority</th>\n<th>Status</th>\n<th>Author</th>\n<th>Owner</th>\n<th>Automation Engine</th>\n<th>Est. Duration</th>\n<th>% Passed</th>\n<th>% Failed</th>\n<th>Last Modified</th>\n<th>Last Executed</th>\n<xsl:for-each select=\"TestCase[1]/CustomProperties/CustomProperty\">\n<th>\n<xsl:value-of select=\"Alias\" />\n</th>\n</xsl:for-each>\n</tr>\n<xsl:for-each select=\"TestCase\">\n<tr>\n<td>\n<xsl:value-of select=\"TestCaseId\" />\n</td>\n<td>\n<xsl:attribute name=\"style\">\npadding-left: <xsl:value-of select=\"string-length(IndentLevel)*2\" />\npx;\n </xsl:attribute>\n<if test=\"FolderYn='Y'\">\n<b><xsl:value-of select=\"Name\" /></b>\n</if>\n<if test=\"FolderYn='N'\">\n<xsl:value-of select=\"Name\" />\n</if>\n</td>\n<td>\n<xsl:value-of select=\"Description\" disable-output-escaping=\"yes\" />\n</td>\n<td>\n<xsl:value-of select=\"TestCasePriorityName\" />\n</td>\n<td>\n<xsl:value-of select=\"ExecutionStatusName\" />\n</td>\n<td>\n<xsl:value-of select=\"AuthorName\" />\n</td>\n<td>\n<xsl:value-of select=\"OwnerName\" />\n</td>\n<td>\n<xsl:value-of select=\"AutomationEngineName\" />\n</td>\n<td class=\"Timespan\">\n<xsl:value-of select=\"EstimatedDuration\" />\n</td>\n<td>\n<xsl:value-of select=\"FolderCountPassed div (FolderCountPassed + FolderCountFailed + FolderCountCaution + FolderCountNotRun + FolderCountBlocked) * 100\" />\n%\n </td>\n<td>\n<xsl:value-of select=\"FolderCountFailed div (FolderCountPassed + FolderCountFailed + FolderCountCaution + FolderCountNotRun + FolderCountBlocked) * 100\" />\n%\n </td>\n<td class=\"Date\">\n<xsl:call-template name=\"format-date\">\n<xsl:with-param name=\"datetime\" select=\"LastUpdateDate\" />\n</xsl:call-template>\n</td>\n<td class=\"Date\">\n<xsl:call-template name=\"format-date\">\n<xsl:with-param name=\"datetime\" select=\"ExecutionDate\" />\n</xsl:call-template>\n</td>\n<xsl:for-each select=\"CustomProperties/CustomProperty\">\n<td>\n<xsl:value-of select=\"Value\" />\n</td>\n</xsl:for-each>\n</tr>\n<xsl:for-each select=\"TestSteps/TestStep\">\n<tr>\n<td></td>\n<td></td>\n<td></td>\n<td></td>\n<td>\n<xsl:value-of select=\"position()\" />\n</td>\n<td>\n<xsl:value-of select=\"Description\" disable-output-escaping=\"yes\" />\n<xsl:value-of select=\"' '\" />\n<xsl:value-of select=\"LinkedTestCaseName\" />\n</td>\n<td>\n<xsl:value-of select=\"ExpectedResult\" disable-output-escaping=\"yes\" />\n</td>\n<td>\n<xsl:value-of select=\"SampleData\" disable-output-escaping=\"yes\" />\n</td>\n<td>\n<xsl:value-of select=\"ExecutionStatusName\" />\n</td>\n<td></td>\n<td></td>\n<td></td>\n<td></td>\n<td></td>\n<td></td>\n</tr>\n</xsl:for-each>\n</xsl:for-each>\n</table>\n</xsl:template>\n<xsl:template name=\"format-date\">\n<param name=\"datetime\" />\n<xsl:variable name=\"date\" select=\"substring-before($datetime, 'T')\" />\n<xsl:variable name=\"year\" select=\"substring-before($date, '-')\" />\n<xsl:variable name=\"month\" select=\"substring-before(substring-after($date, '-'), '-')\" />\n<xsl:variable name=\"day\" select=\"substring-after(substring-after($date, '-'), '-')\" />\n<xsl:variable name=\"time\" select=\"substring-before(substring-after($datetime, 'T'), '.')\" />\n<xsl:variable name=\"monthname\">\n<xsl:choose>\n<xsl:when test=\"$month='01'\">\n<xsl:value-of select=\"'Jan'\" />\n</xsl:when>\n<xsl:when test=\"$month='02'\">\n<xsl:value-of select=\"'Feb'\" />\n</xsl:when>\n<xsl:when test=\"$month='03'\">\n<xsl:value-of select=\"'Mar'\" />\n</xsl:when>\n<xsl:when test=\"$month='04'\">\n<xsl:value-of select=\"'Apr'\" />\n</xsl:when>\n<xsl:when test=\"$month='05'\">\n<xsl:value-of select=\"'May'\" />\n</xsl:when>\n<xsl:when test=\"$month='06'\">\n<xsl:value-of select=\"'Jun'\" />\n</xsl:when>\n<xsl:when test=\"$month='07'\">\n<xsl:value-of select=\"'Jul'\" />\n</xsl:when>\n<xsl:when test=\"$month='08'\">\n<xsl:value-of select=\"'Aug'\" />\n</xsl:when>\n<xsl:when test=\"$month='09'\">\n<xsl:value-of select=\"'Sep'\" />\n</xsl:when>\n<xsl:when test=\"$month='10'\">\n<xsl:value-of select=\"'Oct'\" />\n</xsl:when>\n<xsl:when test=\"$month='11'\">\n<xsl:value-of select=\"'Nov'\" />\n</xsl:when>\n<xsl:when test=\"$month='12'\">\n<xsl:value-of select=\"'Dec'\" />\n</xsl:when>\n<xsl:otherwise>\n<xsl:value-of select=\"''\" />\n</xsl:otherwise>\n</xsl:choose>\n</xsl:variable>\n<xsl:value-of select=\"concat($day, '-' ,$monthname, '-', $year , ' ', $time)\" />\n</xsl:template>\n</xsl:stylesheet>\nClick on the\u00a0Save\u00a0button to save your section and then the main\u00a0Save\u00a0button to save the report. You can now run the report through the main reports center and get something like:
Now we have learned how to modify one of the standard reports and use XSLT, XPATH and a 'standard section' to reformat how the data appears. You can use your knowledge of XPATH and XSLT to make more sophisticated changes. For example you could delete the entire XSLT default template and create a new template that displays a simple list of test cases, or a table of just test case names and IDs.
"},{"location":"Reporting/Custom-Report-Tutorial/#how-to-make-custom-queries","title":"How to Make Custom Queries","text":"In this article we shall be creating a whole new custom report that has a custom header, footer and a custom section that displays data based on a custom ESQL (Entity SQL) query. This is useful in cases where you have some special metrics that you want to be able publish in a report.
"},{"location":"Reporting/Custom-Report-Tutorial/#create-the-new-report","title":"Create the New Report","text":"First, go to Administration > System Administration > Reporting > Edit Reports.
and click on the\u00a0Add New Report\u00a0option. This will bring up the create new report page:
Enter the Name and Description of your new report (the description is optional and is used to describe the purpose of the report, the text is not displayed in the report itself). For example, we will enter:
Now enter in some text for the header and footer of the report (these will be displayed at the top and bottom of the entire report):
For our report, we'll choose the following formats and category:
The format choice is up to you, however the\u00a0category is important\u00a0because:
Before you add a custom section, let's include the name of the project and its description into the top of the report, underneath the header. To do that, click on the\u00a0Add New Standard Section\u00a0button and that will display the Standard Section dialog box:
On this page, choose the 'Product Overview' section from the dropdown list and then click 'Create Default Template' to display the standard XSLT template used for this report. This will populate the\u00a0Template\u00a0field with the standard Project Overview XSLT template. As described above, you can modify this XSLT to adjust how the Project Overview is displayed.
Click on the\u00a0Save\u00a0button.
Now we need to add our new custom section that contains our ESQL query. Click on the\u00a0Add New Custom Section\u00a0button and the new custom section dialog is displayed:
In this dialog box, we need to enter the name of the new section, a description, header, footer and then our ESQL query that is used to retrieve the data we need. For this example we'll enter:
Now in the query section, choose\u00a0'Releases'\u00a0as the base query to use. This will insert the following query:
select value R from SpiraTestEntities.R_Releases as R where R.PROJECT_ID = ${ProjectId}
Click on the\u00a0Preview Results\u00a0button to display the table of all the release fields. From this we can see what we want to include in the query:
Now change the query to only include the data that we want:
select R.NAME, R.VERSION_NUMBER, R.COUNT_PASSED, R.COUNT_FAILED, R.COUNT_NOT_RUN, R.COUNT_BLOCKED, R.COUNT_CAUTION from SpiraTestEntities.R_Releases as R where R.PROJECT_ID = ${ProjectId}\nThis will display the release name, and the test case counts for the current project. It will also include the deleted releases, so we need to add on a clause to the\u00a0WHERE\u00a0part of the query to make sure they are excluded:
select R.NAME, R.VERSION_NUMBER, R.COUNT_PASSED, R.COUNT_FAILED, R.COUNT_NOT_RUN, R.COUNT_BLOCKED, R.COUNT_CAUTION from SpiraTestEntities.R_Releases as R where R.PROJECT_ID = ${ProjectId}\nand R.IS_DELETED = False\nClick on the\u00a0Preview Results\u00a0button again to display the data we want:
To change the names of the columns to look a bit nicer, we can change the generated template. To do this, first click\u00a0Create Default Template\u00a0to generate the standard XSLT template for this query:
<?xml version=\"1.0\" encoding=\"utf-8\"?>\n<xsl:stylesheet version=\"1.0\" xmlns:xsl=\"http://www.w3.org/1999/XSL/Transform\" xmlns:msxsl=\"urn:schemas-microsoft-com:xslt\" exclude-result-prefixes=\"msxsl\">\n<xsl:template match=\"/RESULTS\">\n<table class=\"DataGrid\">\n<tr>\n<th>NAME</th>\n<th>VERSION_NUMBER</th>\n<th>COUNT_PASSED</th>\n<th>COUNT_FAILED</th>\n<th>COUNT_NOT_RUN</th>\n<th>COUNT_BLOCKED</th>\n<th>COUNT_CAUTION</th>\n</tr>\n<xsl:for-each select=\"ROW\">\n<tr>\n<td><xsl:value-of select=\"NAME\"/></td>\n<td><xsl:value-of select=\"VERSION_NUMBER\"/></td>\n<td><xsl:value-of select=\"COUNT_PASSED\"/></td>\n<td><xsl:value-of select=\"COUNT_FAILED\"/></td>\n<td><xsl:value-of select=\"COUNT_NOT_RUN\"/></td>\n<td><xsl:value-of select=\"COUNT_BLOCKED\"/></td>\n<td><xsl:value-of select=\"COUNT_CAUTION\"/></td>\n</tr>\n</xsl:for-each>\n</table>\n</xsl:template>\n</xsl:stylesheet>\nTo change the column headings to make them look better, we can change the template to look like this:
<?xml version=\"1.0\" encoding=\"utf-8\"?>\n<xsl:stylesheet version=\"1.0\" xmlns:xsl=\"http://www.w3.org/1999/XSL/Transform\" xmlns:msxsl=\"urn:schemas-microsoft-com:xslt\" exclude-result-prefixes=\"msxsl\">\n<xsl:template match=\"/RESULTS\">\n<table class=\"DataGrid\">\n<tr>\n<th>Release</th>\n<th>Version</th>\n<th># Passed</th>\n<th># Failed</th>\n<th># Not Run</th>\n<th># Blocked</th>\n<th># Caution</th>\n</tr>\n<xsl:for-each select=\"ROW\">\n<tr>\n<td><xsl:value-of select=\"NAME\"/></td>\n<td><xsl:value-of select=\"VERSION_NUMBER\"/></td>\n<td><xsl:value-of select=\"COUNT_PASSED\"/></td>\n<td><xsl:value-of select=\"COUNT_FAILED\"/></td>\n<td><xsl:value-of select=\"COUNT_NOT_RUN\"/></td>\n<td><xsl:value-of select=\"COUNT_BLOCKED\"/></td>\n<td><xsl:value-of select=\"COUNT_CAUTION\"/></td>\n</tr>\n</xsl:for-each>\n</table>\n</xsl:template>\n</xsl:stylesheet>\nOnce you are happy with the result, click on the\u00a0Save\u00a0button on the custom section and then the\u00a0Save\u00a0button on the report editing screen itself.
You can now run the report through the main reports center and get something like:
Release Version # Passed # Failed # Not Run # Blocked # Caution Library System Release 1 1.0.0.0 0 2 4 0 1 Library System Release 1 SP1 1.0.1.0 3 0 3 1 0 Library System Release 1 SP2 1.0.2.0 2 0 5 0 0"},{"location":"Reporting/Custom-Report-Tutorial/#conclusion_1","title":"Conclusion","text":"Now we have learned how to create a custom report and a use a combination of standard sections and custom sections to product a report that includes data specific to your business. You can use your knowledge of SQL and XSLT to make more sophisticated changes. For example, you could join multiple tables and use SQL aggregation functions to generate summary reports from other parts of the system.
The language that we use for creating custom graphs and reports in Spira is called \"Entity SQL\" (abbreviated to ESQL). Please read our dedicated tutorial to learn how ESQL works and how it is similar and different to standard SQL.
"},{"location":"Reporting/Custom-Reporting-Tokens/","title":"Tokens for Custom Reporting","text":""},{"location":"Reporting/Custom-Reporting-Tokens/#introduction","title":"Introduction","text":"When creating custom reports or custom graphs, you can use special tokens in your query. These are evaluated during the generation of the report or graph to make sure that your report is dynamically limited to the specific context the user is in when they run the report. These are listed below.
You do not have to use these tokens. You can hard code a report to query only against a specific value that the token would return dynamically (eg set the ProjectId to 1 rather than to the current ProjectId of the product the user is in). You can also exclude that part of the query entirely, so that the report will include all the items in the entire system, with no restriction by a token / that field.
"},{"location":"Reporting/Custom-Reporting-Tokens/#available-tokens","title":"Available Tokens","text":"This token limits the data to the release selected in the release dropdown. For custom graphs this is the dropdown on the main reporting page. For custom reports, this dropdown is shown at the bottom of the report configuration page in a section called \"Custom Section Filters\".
If \"All Releases\" is selected, custom graphs/reports using this token display no data. If a specific release is selected, then the graph will display data for that release only.
Example query:
select R.EXECUTION_STATUS_NAME, COUNT (R.TEST_RUN_ID) as COUNT\nfrom SpiraTestEntities.R_TestRuns as R\nwhere R.PROJECT_ID = ${ProjectId} and R.RELEASE_ID = ${ReleaseId}\ngroup by R.EXECUTION_STATUS_NAME\nThis token limits the data to the selected release and to data from that release's children.
If \"All Releases\" is selected data against all active releases in the current product will be returned. For example, if your custom graph shows requirements by release, with \"All Releases\" selected, the graph will show any requirement with an active release set on the release field (which matches the list of releases in the release dropdown). In other words, requirements with no release set will not be included.
If a specific release is selected that does not have any active children data for that release only will be returned.
If a release with active children is selected data for that release and all of its active children (ie any children shown in the release dropdown at the top of the page) will be returned.
Please note: an \"active\" release is one with a status of Planned, In Progress, or Completed.
Example query (note the use of \"in\" before the token):
select R.EXECUTION_STATUS_NAME, COUNT (R.TEST_RUN_ID) as COUNT\nfrom SpiraTestEntities.R_TestRuns as R\nwhere R.PROJECT_ID = ${ProjectId} and R.RELEASE_ID in {${ReleaseAndChildIds}}\ngroup by R.EXECUTION_STATUS_NAME\nOData is an open protocol that lets you easily query data, over the web. Exclusive to SpiraPlan (6.9+), with OData you can directly query the raw data in your database in a secure and safe way. Whenever you use OData in SpiraPlan you are communicating through a secure intermediary (the application itself) to get data from read-only reporting views. Tools like Excel, PowerBI, Tableau support OData and can therefore communicate with SpiraPlan to access this data with just a few clicks.
With OData you don't need to be a SQL expert to generate rich and dynamic insights into your data. If you can fiddle with a spreadsheet, you can stich tables of data from SpiraPlan (\"joins\" in database language) to get just the data you need. What sort of insights can you get with OData and SpiraPlan reporting views? Here are some examples:
In this tutorial series we will be using Excel and its built-in Power Query to communicate with SpiraPlan. Over this series we will build up to creating the final example listed above: a list of the most reopened bugs. This is not meant as a tutorial of Power Query itself, there are lots of those online. But if you don't know how to use Power Query don't worry, you will still be able to follow along
"},{"location":"Reporting/OData-Tutorial/#connecting-excel-and-spiraplan-using-odata","title":"Connecting Excel and SpiraPlan using OData","text":"In the first tutorial you will learn how to:
Not all SpiraPlan users can connect to OData to see live data. Access to OData lets you see all data across all products in your entire system - it is not restricted by product membership or product role permissions. Therefore you need to think carefully about who can and should have this read-only access.
Two types of users can use OData:
Each user can be one, both, or neither of these. Admins can turn these settings on or off in the admin user profile screens.
Before carrying on with this tutorial make sure you are either a system or report admin, are using SpiraPlan, and are on at least version 6.9.0.0.
"},{"location":"Reporting/OData-Tutorial/#connect-excel-and-spiraplan","title":"Connect Excel and SpiraPlan","text":"Open Excel and find the Get Data > From OData Feed button. This should be in the Data ribbon, under Get Data > From Other Sources.
Once you click this button you will see a popup. Stick with \"Basic\" and enter the special OData url for your SpiraPlan. This is the \"base url\" for your application with \"api/odata\" added at the end. If your site is at https://mycompany.spiraservice.net/ then your OData url will be https://mycompany.spiraservice.net/api/odata. Click OK.
Once Excel connects to SpiraPlan you see a popup \"Navigator\" where you can see all the different data views you can access (\"query\"). There is a lot here and a lot to explore. You can access pretty much all the information in your application, across all its products and templates, from these views. But if you click on now to take a look you will not be able to see anything. That's because you have not authenticated yet with Spira. You have to authenticate to view this data for obvious security reasons.
To authenticate you need to pieces of information:
You can find both of these on your Profile page in the application.
In Excel, the easiest way to add your authentication information is to click on one of the view names. It will fail, then show you a dialog box like this:
Click on \"Basic\" on the left, then fill it in as below and click Connect.
You should now see a preview of the table you clicked on. Here we are looking at incidents. You can see a few rows of data, not everything.
To see all the data you have two options:
We will finish this first tutorial by clicking \"Load\". Your new sheet with Incident data in should look something like this...
You can now: connect Excel and Spira together using OData and view data from Spira live in Excel. In the next tutorial we will build a simple query to filter the data to just those parts we are interested in
"},{"location":"Reporting/OData-Tutorial/#writing-your-first-query","title":"Writing your first query","text":"In this tutorial you will learn how to use Excel's Power Query to filter down all the Incidents in your SpiraPlan application. You will end up with a list of incidents in a single product, sorted by priority. You do not need any coding or SQL skills - everything you do will feel very similar to how you normal use Excel itself.
To get started:
The Power Query interface looks very similar to Excel
The Power Query Editor window is made up of:
To make the data easier to look at and filter, the first thing to do is get rid of columns we don't need. Ther are well over 100 columns (because of all the custom fields we include) and that is way too many.
Click on the \"Choose Columns\" button from the Home ribbon. Only select the following columns (make sure the rest are unchecked), and then click OK
You should now see a table of data like the one below. We are showing all the records still, but only 5 columns. The query settings sidebar has an extra line at the end that says \"Removed Other Columns.\" This is what we just did. You can undo the action by deleting it from the sidebar, or change which columns to show by double clicking on it.
"},{"location":"Reporting/OData-Tutorial/#filtering-data","title":"Filtering data","text":"Just like when filtering data on a sheet, the column names have dropdown arrows to open the filtering popup.
You have filtered your data! That's all there is to it. It is really easy. What is cool, is that we are not hiding rows of our table like we do in Excel normally. We are actually changing the query we are sending to SpiraPlan so that SpiraPlan is only sending us the information we have asked for.
Let's filter again. This time filter on the INCIDENT_TYPE_NAME column. Below we are filtering to show Bugs and Enhancements. So we are now seeing only certain types of incidents in a single product. You can see below we have a new entry in the list of Applied Steps in the right hand sidebar - for our Filtering Rows work.
"},{"location":"Reporting/OData-Tutorial/#sorting-data","title":"Sorting data","text":"Sorting data is just as easy as filtering data. Click on the dropdown arrow for the column you want to sort by and click \"Sort Ascending\" or \"Sort Descending\". That's all there is to it. You can, if you want, sort by multiple columns at once. In the example below, we are sorting ascending by the NAME column. Again, there is a new entry in the list of Applied Steps in the right hand sidebar - for our Sorting Rows.
Hopefully, this feels very straightforward, because it is. In the background Excel is creating the right OData query to send to SpiraPlan, which is then writing a secure query to the database to get just the data you need. But you don't need to think about any of that.
In the next tutorial we are going to try another query with incidents and make things more complicated by combining data across two tables at once.
"},{"location":"Reporting/OData-Tutorial/#combining-two-lots-of-data","title":"Combining two lots of data","text":"In this tutorial we will start to see the real power of reporting using OData. Until now we have been filtering and sorting a single list of incidents. Now we are going to do the same filtering and sorting but now across two tables joined together. Combining (joining) data in this way let's us do things with SpiraPlan's data like:
We are going to focus on the final example above in this tutorial, and add to it in the next tutorial
"},{"location":"Reporting/OData-Tutorial/#preparing-our-incident-data","title":"Preparing our incident data","text":"From the end of our last tutorial we had a list of bugs and enhancements in a single product. We can see names for things like the product (project in database terms), status, and type. This is what we see in SpiraPlan itself.
Behind each status name is a unique number identified (ID). This lets us change, for example, the status name, but still make sure the incidents with that status show with that updated name.
To properly match data across different tables of data we should match on this ID fields. Do this:
Excel has asked SpiraPlan for this extra data and is now showing it to us. But notice that you are now seeing all incidents again, and \"Removed Other Columns\" is highlighted in the list of Applied Steps. Click on the bottom step \"Sorted Rows\". This will apply all the steps that follow our now updated \"Removed Other Columns.\" This is a great feature - we can, within limits, edit previous steps we have made to our query, then go back to our most current step in the process. We now have the same list of incidents we ended the last tutorial with, but showing this extra column.
"},{"location":"Reporting/OData-Tutorial/#joining-queries-together","title":"Joining queries together","text":"The process for joining data across two tables (queries as Power Query calls them) is:
Right now we are only showing Incident data. To join it up with Incident Status data we need to add that table as a new query. To do that, carry out the following steps:
We now have two different queries that are completely independent from each other. We want to connect them together. For each incident we want to get extra information about its status. The main query is Incidents, and the secondary query is IncidentStatuses. So click on the Incidents query in the Queries sidebar to make sure we are viewing our Incident query again. Now, carry out the following steps:
We now see the output of our merge query. Our query looks very similar - it has the same number of rows, but has gained an extra column \"IncidentStatuses\" at the right. The Applied Steps list has a new entry too: \"Merged Queries.\" We know that merge has worked, but we can't see any extra data yet. That's because Project data is collapsed: in each cell in the IncidentStatuses column we see the word Table, which tells us that there is a whole set of data hiding inside that cell, waiting for us to look at it.
This is the 3rd and final step of the merge - choosing which columns to show from our extra data we have merged in. To the right of the IncidentStatuses column name you will see the little button looks different. It is not a dropdown arrow but a weird double arrow. Click this to choose how to expand the data from the IncidentStatuses data into new columns. You will see the familiar column picker. Only select the IS_OPEN_STATUS field and click OK.
The table is updated with an extra column called \"IncidentStatuses.IS_OPEN_STATUS\" and the Applied Steps list has a new entry \"Expanded IncidentStatuses.\"
In this simple example we have added extra information to each incident row about the incident status that applies to that incident.
The same principles can be used for combining data from many other tables together. The critical thing for this to work is that there are columns that match between the two tables you want to join. Imagine, for instance, if we match INCIDENT_ID from Incidents with INCIDENT_STATUS_ID from IncidentStatuses. The data may look interesting but it would be nonsense and not useable. It should almost always be obvious by the column name how it will match up with other columns in different tables.
As a final step in this tutorial, let's do something with this extra data we have. We now know which incidents are open or closed but that IS_OPEN_STATUS flag (TRUE = open, FALSE = closed). Filter on the \"IncidentStatuses.IS_OPEN_STATUS\" column the same as any other column, and select only the open incidents (TRUE). This added a new Applied Step \"Filtered Rows1.\"
This query is really easy to do on the list of Incidents using SpiraPlan itself. We have replicated that functionality using OData to talk between Excel and SpiraPlan. In this way you can easily compare SpiraPlan and your query to see if the results match. As you can see the image above and the one below show the same exact incidents in the same order (because have applied the same filter and sorting in both places).
In the final tutorial we are going to build on the query we have built but rapidly extend it with a number of other joins and semi-advanced filtering.
"},{"location":"Reporting/OData-Tutorial/#building-complex-queries","title":"Building complex queries","text":"In this tutorial we start with the output from the previous tutorial: a list of open bugs and enhancements for one product. By the end of this tutorial we will have a spreadsheet of data that shows, for a portfolio, the number of open bugs and enhancements each user is assigned. That's quite a transformation so let's get started.
Your data should look a little like that below. You can see here that we have incidents across different products, assigned to a handful of different users, who together work in two different departments (QA and Software Engineering).
Now we have three more merges and expanding columns to do:
Projects
ProjectGroups
Portfolios
The query should now have a total of 14 columns. It combines data across 6 different tables from SpiraPlan to show us details about the user assigned to each incident and the program, and portfolio each incident is in. Your data should look something like that below (note the list of Applied Steps). If at anytime you have done something wrong, remember you can edit a step, or delete a step entirely and do it again.
We're ready for the final stage: grouping data. This will let us count up the number of incidents assigned to each user. Follow the steps below:
.
This results in a condensed query of data that has unique rows for each user in each portfolio. The right hand column is called Count and is the number of open bugs and enhancements that the user has in that portfolio.
.
Click \"Close and Load from the ribbon to load this data into Excel. From here you can do anything with the data you want. For instance, you can turn it into a pivot table to tell you how many open bugs and enhancements there are, in total, in each portfolio.
This brings us to the end of the OData tutorial series. Hopefully you can see the power of OData and the ease with which you can interrogate your data and draw out insights from it. You can create much more complex data that we have done here, or use more complex reporting tools to create live data dashboards that let you extend SpiraPlan with customized queries that make sense to your organization.
"},{"location":"Reporting/Understanding-Entity-SQL/","title":"Understanding Entity SQL","text":""},{"location":"Reporting/Understanding-Entity-SQL/#understanding-entity-sql-esql","title":"Understanding Entity SQL (ESQL)","text":"This guide explains how you can use Entity SQL to write queries to pull back the data you need when working with custom reports in SpiraPlan.
The language that we use for creating custom graphs and reports in Spira is called \"Entity SQL\" (abbreviated to ESQL) and is based on the standard database Structured Query Language (SQL) but modified by Microsoft to work against a conceptual object oriented data structure rather than a traditional relational database. According to the Microsoft Entity SQL website:
Entity SQL is a SQL-like language that enables you to query conceptual models in the Entity Framework. Conceptual models represent data as entities and relationships, and Entity SQL allows you to query those entities and relationships in a format that is familiar to those who have used SQL.
"},{"location":"Reporting/Understanding-Entity-SQL/#entity-sql-syntax-basics","title":"Entity SQL Syntax Basics","text":"Similar to database SQL, ESQL supports query that consists of the following parts:
select properties or object\nfrom entity collection as alias\njoin other entity collections on relationship\nwhere conditions\ngroup by properties\norder by properties\nWhen using ESQL with Spira's reporting system, the entity collections you can use are the ones generated from the 'Add New Query' dropdown discussed in the previous article. For example, you have:
The R_xxx prefix is used to distinguish the entities available for reporting from the core entities used by Spira internally for its data access. You will only ever be able query the R_ prefixed entities from within the Spira reporting system.
A simple query used to retrieve all of the requirements in project 1 sorted by hierarchical order then ID would be:
select value RQ\nfrom SpiraTestEntities.R_Requirements as RQ\nwhere RQ.PROJECT_ID = 1\norder by RQ.INDENT_LEVEL, RQ.REQUIREMENT_ID\nA more complex query that selects specific requirement properties (vs. the entire object), joins to other table (e.g. to get test case object properties as well) would be:
select RQ.REQUIREMENT_ID, RQ.NAME as REQUIREMENT_NAME, TC.TEST_CASE_ID, TC.NAME as TEST_CASE_NAME\nfrom SpiraTestEntities.R_Requirements as RQ\njoin SpiraTestEntities.R_RequirementTestCases as RT on RQ.REQUIREMENT_ID = RT.REQUIREMENT_ID\njoin SpiraTestEntities.R_TestCases as TC on RT.TEST_CASE_ID = TC.TEST_CASE_ID where RQ.PROJECT_ID = 1\norder by RQ.NAME, TC.NAME\nFinally, you can add on an aggregation function and group by to group by one property and aggregate the other properties against this. For example to get a count of the test cases associated with each requirement, instead of the test case names would be:
select RQ.REQUIREMENT_ID, RQ.NAME as REQUIREMENT_NAME, COUNT(TC.TEST_CASE_ID) as TEST_CASE_COUNT\nfrom SpiraTestEntities.R_Requirements as RQ\njoin SpiraTestEntities.R_RequirementTestCases as RT on RQ.REQUIREMENT_ID = RT.REQUIREMENT_ID\njoin SpiraTestEntities.R_TestCases as TC on RT.TEST_CASE_ID = TC.TEST_CASE_ID\nwhere RQ.PROJECT_ID = 1\ngroup by RQ.REQUIREMENT_ID, RQ.NAME\norder by TEST_CASE_COUNT desc, RQ.REQUIREMENT_ID\nIn this last case, we're sorting the list of requirements by the count of associated test cases (in descending order).
So now that we have seen some example queries, let's examine each of the parts of the query in turn:
"},{"location":"Reporting/Understanding-Entity-SQL/#the-select-clause","title":"The SELECT Clause","text":"The select clause of an ESQL query can consist of either:
So for example we could have:
select value RQ\nthat selects all of the properties in the requirements table (i.e. all the columns).
Alternatively you could select specific properties (columns) from one or more object:
select RQ.REQUIREMENT_ID, RQ.NAME as REQUIREMENT_NAME, TC.TEST_CASE_ID, TC.NAME as TEST_CASE_NAME\nIn this case, we omit the value prefix since it's not evaluating all of the properties of an object. Since two of the properties have the same name (\"NAME\") we are using the as operator to give the property returned a unique name. This is important. If you try and return back two properties with the same name, Spira will give the following error message:
You get this error message because the Entity framework will try and create a name like (NAME #1) that is not allowed by the Spira reporting system. So make sure you used actual named aliases when the same property name is used more than once.
Finally you can use the following aggregations in the SELECT clause to aggregate data from properties that are not being grouped (see later for information on the group by clause):
A full list of Entity SQL aggregate functions can be found on the Microsoft ESQL reference website.
For example, we can count how many times one property appears relative to another column:
select RQ.REQUIREMENT_ID, RQ.NAME as REQUIREMENT_NAME, COUNT(TC.TEST_CASE_ID) as TEST_CASE_COUNT\nNote that in this case we recommend you always specify an alias for the result of the aggregation function using the as operator. If you forget, you'll get the same error message as before:
"},{"location":"Reporting/Understanding-Entity-SQL/#the-from-clause","title":"The FROM Clause","text":"The from clause in ESQL is relatively simple, it contains the primary object collection being queried and an alias that will be used to reference its properties in the other parts of the query:
from SpiraTestEntities.R_Requirements as RQ\nIf you are only going to need to work with the properties from a single object collection then you don't need to have any join clauses in your query. However if you are going to need data from multiple object collections, then you will need to use the join clause to add in those other collections. A simple join clause looks like:
join SpiraTestEntities.R_RequirementTestCases as RT on RQ.REQUIREMENT_ID = RT.REQUIREMENT_ID\nwhere you add the name of the entity collection being joined, the alias to refer to it with, and the comparison operator (in this case an equality) used to make the join.
Entity SQL supports the following types of join:
The where clause in ESQL lets you filter the results by one or more condition. In addition to the standard ESQL syntax, you can use the special Spira tokens to filter by dynamic data in the system:
The where clause consists of a set of conditions that are joined by a boolean operator:
Generally and operators have higher precedence than or operators, so you will need to use parenthesis when you want to have or operators that are higher precedence than an and.
For example:
where (RQ.PROJECT_ID = 1 or RQ.PROJECT_ID = 2) and RQ.IS_DELETED = 0\nmeans that you will retrieve any un-deleted requirement that is in project 1 or project 2, whereas this would mean something completely different:
where RQ.PROJECT_ID = 1 or RQ.PROJECT_ID = 2 and RQ.IS_DELETED = 0\nthis would retrieve all (including deleted) requirements in project 1, and any un-deleted ones from project 2.
The type of operator you can use in the various conditions include:
Greater than
= Greater than or equals
For example you might have a compound conditional clause such as:
where RQ.PROJECT_ID >= 1 and RQ.PROJECT_ID <= 4 and RQ.IS_DELETED = 0 and (RQ.TASK_ACTUAL_EFFORT + RQ.TASK_REMAINING_EFFORT) > 0\nIn the discussion of the select clause we mentioned that you can use aggregation functions such as count, sum, min, max, etc. If you use these in the select clause, then any object properties that are not being aggregated need to be included in the group by clause:
group by RQ.REQUIREMENT_ID, RQ.NAME\nIf you don't have any aggregation functions, you can still use a group by clause to simply group similar rows, but generally speaking you omit the group by clause if there are no aggregation functions in the select list.
"},{"location":"Reporting/Understanding-Entity-SQL/#sorting-and-order-by","title":"Sorting and ORDER BY","text":"Finally, you typically want to sort the data by one or more of the object properties, this is done by having an order by clause at the end of the query:
order by TEST_CASE_COUNT desc, RQ.REQUIREMENT_ID asc\nThe syntax of the order by clause is:
If you sort by a property (e.g. requirement name) that could be held by multiple rows, it is recommended to always add a final sort clause by a guaranteed unique ID such as the primary key REQUIREMENT_ID since that will ensure the results are consistent each time. This is known as 'stable sorting'
"},{"location":"Reporting/Understanding-Entity-SQL/#differences-between-esql-and-traditional-database-sql","title":"Differences Between ESQL and Traditional Database SQL","text":"Now that we have covered the basics of writing an Entity SQL (ESQL) query, we'll discuss some of the differences and limitations between ESQL and traditional database SQL.
"},{"location":"Reporting/Understanding-Entity-SQL/#no-support-for","title":"No Support for *","text":"Database SQL supports the unqualified * syntax as an alias for the entire row, and the qualified * syntax (t.*) as a shortcut for the fields of that table. In addition, database SQL allows for a special count(*) aggregate, which includes nulls.
Entity SQL does not support the * construct. Database SQL queries of the form:
select * from T\nand
select T1.* from T1, T2...\ncan be expressed in Entity SQL as
select value t from T as t\nand
select value t1 from T1 as t1, T2 as t2...\nrespectively.
Additionally, these constructs handle inheritance (value substitutability), while the select * variants are restricted to top-level properties of the declared type. Entity SQL does not support the count(*) aggregate. Use count(0) instead.
Entity SQL supports aliasing of group by keys. Expressions in the select clause and having clause must refer to the group by keys via these aliases. For example, this Entity SQL syntax:
SELECT k1, count(t.a), sum(t.a)\nFROM T AS t\nGROUP BY t.b + t.c AS k1\n...is equivalent to the following database SQL:
"},{"location":"Reporting/Understanding-Entity-SQL/#sql","title":"SQL","text":"SELECT b + c, count(*), sum(a)\nFROM T\nGROUP BY b + c\nEntity SQL supports two kinds of aggregates.
Collection-based aggregates operate on collections and produce the aggregated result. These can appear anywhere in the query, and do not require a group by clause. For example:
SELECT t.a AS a, count({1,2,3}) AS b FROM T AS t\nEntity SQL also supports SQL-style aggregates. For example:
SELECT a, sum(t.b) FROM T AS t GROUP BY t.a AS a\nDatabase SQL allows ORDER BY clauses to be specified only in the topmost SELECT .. FROM .. WHERE block. In Entity SQL you can use a nested ORDER BY expression and it can be placed anywhere in the query, but ordering in a nested query is not preserved.
-- The following query will order the results by the last name \nSELECT C1.FirstName, C1.LastName FROM AdventureWorks.Contact AS C1\nORDER BY C1.LastName -- In the following query ordering of the nested query is ignored. \nSELECT C2.FirstName, C2.LastName FROM (SELECT C1.FirstName, C1.LastName FROM AdventureWorks.Contact as C1 ORDER BY C1.LastName) as C2 In database SQL, identifier comparison is based on the settings of the current database and the database platform being used (SQL Server, Oracle, MySQL, etc.). In Entity SQL, identifiers are always case insensitive and accent sensitive (that is, Entity SQL distinguishes between accented and unaccented characters; for example, 'a' is not equal to '\u1ea5'). Entity SQL treats versions of letters that appear the same but are from different code pages as different characters.
"},{"location":"Reporting/Understanding-Entity-SQL/#group-by-clause-differences","title":"Group By Clause Differences","text":"Entity SQL also imposes additional restrictions on queries involving group by clauses. Expressions in the select clause and having clause of such queries may only refer to the group by keys via their aliases. The following construct is valid in most database SQL variants but are not in Entity SQL:
SELECT t.x + t.y FROM T AS t group BY t.x + t.y\nTo do this in Entity SQL:
SELECT k FROM T AS t GROUP BY (t.x + t.y) AS k\nAll column references in Entity SQL must be qualified with the table alias. The following construct (assuming that a is a valid column of table T) is valid in database SQL but not in Entity SQL.
SQL:
SELECT a FROM T\nThe Entity SQL form is
SELECT t.a AS A FROM T AS t\nThe table aliases are optional in the from clause. The name of the table is used as the implicit alias. Entity SQL allows the following form as well:
SELECT Tab.a FROM Tab\nDatabase SQL uses the \".\" notation for referencing columns of (a row of) a table. Entity SQL extends this notation (borrowed from programming languages) to support navigation through properties of an object.
For example, if p is an expression of type Person, the following is the Entity SQL syntax for referencing the city of the address of this person.
p.Address.City In database SQL, if you want to refer to a collection of possible values, you would use an IN clause together with a set of values contained within parenthesis:
SQL
SELECT t.a FROM T as t WHERE t.b IN (1,2,3)\nIn Entity SQL, the syntax for a collection of values is based on braces / curly brackets instead:
ESQL
select t.a from T as t where t.b in { 1,2,3 }\nThere are some differences between how literal values and types are represented in Entity SQL vs. Database SQL:
DATETIME '2006-12-25 01:01:00.000'\nN'hello'.(cast(null as Int16))\nThe following database SQL functionality is not available in Entity SQL.
This section outlines how to use the included Importer for importing folders, projects, modules and requirements from an IBM Rational DOORS database into a project in SpiraTest\u00ae, SpiraPlan\u00ae or SpiraTeam\u00ae (hereafter referred to as SpiraTeam).
"},{"location":"Requirements-Management-Integration/Importing-From-DOORS/#installing-the-importer","title":"Installing the Importer","text":"This section outlines how to install the importer onto a workstation so that you can then import requirements from DOORS into SpiraTeam. It assumes that you already have a working installation of SpiraTeam v3.0 or later and a working installation of DOORS 9.0 or later.
You can download the Importer from the Inflectra's website under \"Downloads and Add-Ons\". When downloaded, double-click the MSI file. Follow the instructions in the MSI file to install the importer.
"},{"location":"Requirements-Management-Integration/Importing-From-DOORS/#importing-from-a-doors-database","title":"Importing from a DOORS Database","text":"Now that you have installed the integration adapter, you can launch it at any time by going to Start > Programs > SpiraTest > Tools > IBM Rational DOORS Adapter. This will launch the import application itself. You will be shown an introduction screen. Click 'Next' to get to the second screen:
You need to click on the [Launch DOORS] button to connect to the locally installed DOORS client. Then you can enter in your DOORS login/password to access the system:
Once you have successfully authenticated with DOORS, you have the option of importing ALL the requirements in the DOORS database into a SpiraTeam project or selecting just a specific item (folder, project or module) in the DOORS hierarchy. To select a specific item, click on the \"Populate Item List\" button and choose the item from the dropdown list.
Then click Next to continue to the screen where you enter your SpiraTeam server and project information:
On this screen, you need to enter the SpiraTeam Server URL, the username and password you use to log onto the system, then click the Get Projects button. The program will connect to the server and get a list of all available projects. Select the project you want to import into under the Project & Requirement section.
The Root Requirement box is for specifying a base requirement to load all the DOORS elements into. If left blank, then the importer will create a single placeholder requirement that all of the DOORS folders, projects, modules and requirements will be nested under.
If you have a requirement already in SpiraTeam, and want the DOORS items to appear inside it, then you need to enter the requirement number into the Root Requirement text box. For example, if you have a requirement named \"DOORS Requirements\" with a number of RQ1920, then put 1920 into the Root Requirement field and run the import. When import is finished, the SpiraTeam requirements will be nested underneath.
Note: At this time, Link Modules are not imported from DOORS databases.
Once the fields have been populated, click Next to get to the summary screen.
The summary screen tells you what will actions will be performed, and once you have verified the information, click the Import button to start the import:
Anything flagged with a red
failed, green
means that they succeeded. Once finished, click Finish to get to the last page of the wizard:
If the Minimize to System Tray option is selected, when you click Finish or exit the from the application, it will minimize to the system tray. Once in the system tray, you can right-click on the icon and the it will give you the option to either re-import from the same project or select another project for a fresh import. If the option is not selected, the program will exit, and you can re-launch the importer to import from the same or another DOORS database.
"},{"location":"Requirements-Management-Integration/Importing-From-DOORS/#using-the-system-tray-shortcut-menu","title":"Using the System Tray Shortcut Menu","text":"When the application is minimized to the system tray, there are several shortcuts available:
Double-Clicking the icon will bring the importer back to the first screen, allowing you to import another DOORS database.
Right-clicking will give a shortcut menu with the following options:
Exit -- Close the program entirely.
Rerun Import -- Will provide you the screen to re-launch the last import you just ran.
Show Window -- Same as double-clicking on the icon, will bring the wizard back to the first screen, allowing new input options to be set.
At this time, only formal modules are imported into SpiraTeam from DOORS. The folders, projects and modules in DOORS become summary requirements in SpiraTeam and the actual requirements in each module are simply nested as child requirements in SpiraTeam. In addition, the following fields are brought over into SpiraTeam from DOORS according to the following mapping table:
DOORS Field SpiraTeam Field Heading Name Short Text Description Long Text Description Number Name DOORS Object ID Custom Text Property TEXT_01
Using this adapter, you can manage the appropriate artifacts in IBM Rational DOORS and then periodically re-run the import application to update SpiraTeam. The application will remember that the project was already used for an initial load and will simply update the requirements as appropriate as well as add any additional ones added.
Note that any changes to the requirement hierarchy are not reflected. This allows you to change the organization of the artifacts in SpiraTeam to make them easier to use without the changes being overwritten on the next import cycle.
Finally, should you want to start again and re-import a project from scratch that has already been imported once before, you may do so by re-running the Importer, and entering in -1 as the Root Requirement. This will not delete requirements from SpiraTeam, only remove mappings, so the next time you run the importer on this file, all new requirements will be created.
Note: This option is irreversible and should be performed with care.
"},{"location":"Requirements-Management-Integration/Importing-From-EnterpriseArchitect/","title":"Importing From EnterpriseArchitect","text":"This section outlines how to use the included Importer for importing Requirements, Features, and Screens from a Sparx Enterprise Architect (EA) project file into SpiraTeam.
"},{"location":"Requirements-Management-Integration/Importing-From-EnterpriseArchitect/#installing-the-importer","title":"Installing the Importer","text":"This section outlines how to install the importer onto a desktop so that you can then import requirements and use cases from EA into SpiraTest. It assumes that you already have a working installation of SpiraTest v3.0 or later and a working installation of Enterprise Architect.
Important: You must install the integration adapter on the same desktop that has the installed copy of Enterprise Architect.
You can download the Importer from the Inflectra's website under \"Downloads and Add-Ons\". When downloaded, double-click the MSI file. Follow the instructions in the MSI file to install the importer.
"},{"location":"Requirements-Management-Integration/Importing-From-EnterpriseArchitect/#importing-from-an-ea-project-file","title":"Importing from an EA Project File","text":"Now that you have installed the integration adapter, you can launch it at any time by going to Start > Programs > SpiraTeam > Tools > Enterprise Architect Importer. This will launch the import application itself. You will be shown an introduction screen. Click 'Next' to get to the second screen:
Click the folder button () to open the file open dialog. In this dialog, select the Enterprise Architect Project file (*.EAP) that you want to use for importing. If the file has access credentials required, enter the username and password needed to access the file.
Once the file is selected, click Next to continue to the screen where you enter your SpiraTeam project information:
If the file you selected in the previous step was already lined to a SpiraTeam project, that information will be automatically populated in the fields, and you can click Next to proceed.
Otherwise, enter in the SpiraTeam Server URL, your username and password used to log onto the system with and click the Get Projects button. The program will connect to the server and get a list of all available projects. Select the project you want to import into under the Project & Requirement section.
The Root Requirement box is for specifying a base requirement to load all the EA elements into. If left blank, then the root folders in the EAP's model will be root requirement folders in the SpiraTeam Project.
For example, if your EAP file has a tree that looks like:
Then the requirements imported into SpiraTeam will appear like:
Note that the folder \"Non-Functional Requirements\" does not appear in the list. Folders that have no importable elements will not get imported into SpiraTeam. At this time, only \"Requirement\", \"Feature\", and \"Screen\" elements are imported.
If you had a requirement already in SpiraTeam, and wanted the \"Requirements Model\" to appear in it, then enter the requirement number into the Root Requirement text box. For example, if I have a requirement named \"EA Requirements\" with a number of RQ1920, then put 1920 into the Root Requirement field and run the import. When import is finished, the SpiraTeam requirement tree will look like:
Once the fields are entered, click Next to get to the summary screen. The summary screen tells you what will be done, and once it's reviewed, click the Import button to start importing:
Anything flagged with a red
failed, green
means that they succeeded. Once finished, click Finish to get to the last page of the wizard:
If the Minimize to System Tray option is selected, when you click Finish or exit the form, the application will minmiize to the system tray and give you some quick actions to re-import from the same file or select another file. Otherwise the program will exit, and you can re-launch the importer to import from the same or another EAP file.
"},{"location":"Requirements-Management-Integration/Importing-From-EnterpriseArchitect/#using-the-system-tray-shortcut-menu","title":"Using the System Tray Shortcut Menu","text":"When the application is minimized to the system tray, there are several shortcuts available:
Double-Clicking the icon will bring the importer back to the first screen, allowing you to import another EAP file.
Right-clicking will give a shortcut menu with the following options:
Exit -- Close the program entirely.
Rerun Import -- Will provide you the screen to re-launch the last import you just ran.
Show Window -- Same as double-clicking on the icon, this will cause the wizard to appear back on the first screen, allowing new input options to be set.
At this time, only elements that are Requirements, Features, or Screens are imported. All three types are imported into Requirements within SpiraTeam, and most fields are brought over into SpiraTeam from EA. Mapping for fields are as follows:
Enterprise Architect Field SpiraTeam Field Short Description / Name Name Notes Description (with HTML) Priority Importance: EA Value : SpiraTeam Value High : High Medium : Medium Low : Low Status Status: EA Value : SpiraTeam Value Approved : Accepted Implemented: In Progress Validated : Completed Mandatory : Requested Proposed : Requested (None) : Requested Author (not transferred, always set to user who ran the import last) Release (not transferred) Owner (not transferred) Planned Effort (not transferred) Alias Custom Text Property #1 Element Type ('Requirement', 'Feature', 'Screen', etc) Custom Text Property #2 Phase Custom Text Property #3 Version Custom Text Property #4 Difficulty Custom Text Property #5When a mapping is made, a Tagged Value is saved into the EAP file with the name of SPIRA::Mapping. The number of the value is the requirement number within SpiraTeam. If the requirement is deleted from SpiraTeam, and the mapping value in the EA project still exists, the item will not be re-imported into SpiraTeam. Similarly, folders are also given a SPIRA::Mapping value, and if a new Requirement element is created within a folder that was deleted in SpiraTeam, it will not be added. If you need to remove all mappings from the EAP file, you may do so by re-running the Importer, and entering in -1 as the Root Requirement. Note that this will not delete requirements from SpiraTeam, only remove mappings, so the next time you run the importer on this file, all new requirements will be created.
"},{"location":"Requirements-Management-Integration/Importing-From-Jama-Contour/","title":"Importing From Jama Contour","text":"This section outlines how to use the included Importer for importing Requirements, Features, and Use Cases from projects residing in Jama Contour\u2122 projects into equivalent projects in SpiraTest\u00ae, SpiraPlan\u00ae or SpiraTeam\u00ae (hereafter referred to as SpiraTeam).
"},{"location":"Requirements-Management-Integration/Importing-From-Jama-Contour/#installing-the-importer","title":"Installing the Importer","text":"This section outlines how to install the importer onto a workstation so that you can then import requirements and use cases from Contour into SpiraTeam. It assumes that you already have a working installation of SpiraTeam v3.0 or later and a working installation of Jama Contour.
You can download the Importer from the Inflectra's website under \"Downloads and Add-Ons\". When downloaded, double-click the MSI file. Follow the instructions in the MSI file to install the importer.
"},{"location":"Requirements-Management-Integration/Importing-From-Jama-Contour/#importing-from-a-contour-project","title":"Importing from a Contour Project","text":"Now that you have installed the integration adapter, you can launch it at any time by going to Start > Programs > SpiraTest > Tools > Jama Contour Adapter. This will launch the import application itself. You will be shown an introduction screen. Click 'Next' to get to the second screen:
You need to enter the Contour Server URL (including the port number if appropriate), the username and password you use to log onto the system, then click the Get Projects button. The program will connect to the server and get a list of all available projects. Select the project you want to import into under the Project section. Once the project is selected, click Next to continue to the screen where you enter your SpiraTeam server and project information:
On this screen, you need to enter the SpiraTeam Server URL, the username and password you use to log onto the system, then click the Get Projects button. The program will connect to the server and get a list of all available projects. Select the project you want to import into under the Project & Requirement section.
The Root Requirement box is for specifying a base requirement to load all the Contour elements into. If left blank, then the root folders in the Contour's explorer will be root requirement folders in the SpiraTeam Project.
For example, if your Jama Contour project has a tree that looks like:
Then the requirements imported into SpiraTeam will appear like:
Note: At this time, change request and defect items are not imported from Contour projects.
If you have a requirement already in SpiraTeam, and want the Contour requirements to appear inside it, then you need to enter the requirement number into the Root Requirement text box. For example, if you have a requirement named \"Contour Requirements\" with a number of RQ1920, then put 1920 into the Root Requirement field and run the import. When import is finished, the SpiraTeam requirement tree will look like:
Once the fields have been populated, click Next to get to the summary screen.
The summary screen tells you what will actions will be performed, and once you have verified the information, click the Import button to start the import:
Anything flagged with a red
failed, green
means that they succeeded. Once finished, click Finish to get to the last page of the wizard:
If the Minimize to System Tray option is selected, when you click Finish or exit the from the application, it will minimize to the system tray. Once in the system tray, you can right-click on the icon and the it will give you the option to either re-import from the same project or select another project for a fresh import. If the option is not selected, the program will exit, and you can re-launch the importer to import from the same or another Contour project.
"},{"location":"Requirements-Management-Integration/Importing-From-Jama-Contour/#using-the-system-tray-shortcut-menu","title":"Using the System Tray Shortcut Menu","text":"When the application is minimized to the system tray, there are several shortcuts available:
Double-Clicking the icon will bring the importer back to the first screen, allowing you to import another Contour project.
Right-clicking will give a shortcut menu with the following options:
Exit -- Close the program entirely.
Rerun Import -- Will provide you the screen to re-launch the last import you just ran.
Show Window -- Same as double-clicking on the icon, will bring the wizard back to the first screen, allowing new input options to be set.
At this time, only requirements are imported into SpiraTeam from Contour. All the various types in Contour are imported as Requirements into SpiraTeam. In addition, the following fields are brought over into SpiraTeam from Contour according to the following mapping table:
Jama Contour Field SpiraTeam Field Name Name Description Description (with HTML) Priority Importance: Contour Value : SpiraTeam Value High : High Medium : Medium Low : Low Status Status: Contour Value : SpiraTeam Value Draft : Requested Approved : Accepted Completed : Completed Rejected : Rejected (None) : Requested Author (not transferred, always set to user who ran the import last) Release Release / Iteration Owner (not transferred) Planned Effort (not transferred) Item Type Custom Text Property #1 Document Key Custom Text Property #2 Item Type Category Custom Text Property #3"},{"location":"Requirements-Management-Integration/Importing-From-Jama-Contour/#keeping-jama-and-spira-in-sync","title":"Keeping Jama and Spira in Sync","text":"Using this adapter, you can manage the appropriate artifacts in Contour and then periodically re-run the import application to update Spira. The application will remember that the project was already used for an initial load and will simply update the requirements as appropriate as well as add any additional ones added. If you are using SpiraTeam v3.1 or later, the update process will also delete any artifacts removed in Contour.
Note that any changes to the requirement hierarchy in Contour are not reflected. This allows you to change the organization of the artifacts in SpiraTeam to make them easier to use without the changes being overwritten on the next import cycle.
Finally, should you want to start again and re-import a project from scratch that has already been imported once before, you may do so by re-running the Importer, and entering in -1 as the Root Requirement. This will not delete requirements from SpiraTeam, only remove mappings, so the next time you run the importer on this file, all new requirements will be created. Note: This option is irreversible and should be performed with care.
"},{"location":"Requirements-Management-Integration/Importing-From-ReqIF-Files/","title":"Importing From Requirements Interchange Format (ReqIF) Files","text":"The SpiraTeam ReqIF Importer imports requirements, specifications, custom properties, relationships and other information from Requirements Interchange Format (ReqIF) files into SpiraTeam.
"},{"location":"Requirements-Management-Integration/Importing-From-ReqIF-Files/#installing-the-importer","title":"Installing the Importer","text":"This section outlines how to install the importer onto a desktop so that you can then import requirements from ReqIF files into SpiraTeam. It assumes that you already have a working installation of SpiraTest, SpiraTeam, or SpiraPlan (hereafter SpiraTeam) v6.0 or later.
You can download the Importer from the Inflectra's website under \"Downloads and Add-Ons\". When downloaded, double-click the MSI file. Follow the instructions in the MSI file to install the importer.
"},{"location":"Requirements-Management-Integration/Importing-From-ReqIF-Files/#importing-from-a-reqif-requirements-file","title":"Importing from a ReqIF Requirements File","text":"Now that you have installed the integration adapter, you can launch it at any time by going to Start > Programs > SpiraTeam > Tools > ReqIF Importer. This will launch the import application itself. You will be shown an introduction screen.
Click 'Next' to get to the second screen:
Click the folder button () to open the file open dialog. In this dialog, select the Requirements Interchange Format (*.reqif) file that you want to use for importing.
Choose the requirements attributes you want from the .ReqIF file model to map to the Name and Description fields in SpiraTeam. Any other fields will be imported as custom properties.
Once the file is selected, and the name/description attributes mapped, click Next to continue to the screen where you enter your SpiraTeam project information:
If the file you selected in the previous step was already lined to a SpiraTeam project, that information will be automatically populated in the fields, and you can click Next to proceed.
Otherwise, enter in the SpiraTeam Server URL, your username and password used to log onto the system with and click the Get Projects button. The program will connect to the server and get a list of all available projects. Select the project you want to import into under the Project & Requirement section.
The Root Requirement box is for specifying the name of the parent requirement in SpiraTeam, that all the imported requirements will be nested under. The system will default this to the name of the ReqIF file unless you choose something else.
Once the fields are entered, click Next to get to the summary screen. The summary screen tells you what will be done, and once it's reviewed, click the Import button to start importing:
Anything flagged with a: - red failed - green means that they succeeded
Once finished, click Finish to get to the last page of the wizard:
If anything failed, you can view the details import log at the following location:
\nC:\\ProgramData\\SpiraTeamReqIFImporter.log\n"},{"location":"Requirements-Management-Integration/Importing-From-ReqIF-Files/#reqif-spirateam-importing-notes","title":"ReqIF & SpiraTeam Importing Notes","text":"
For example, if you import the sample Sample-Model.reqif file that is supplied with the importer, you will see the following requirements in SpiraTeam:
In addition, the importer will create the necessary custom properties as needed automatically:
If you run the same import twice, the importer will create a new requirements hierarchy each time, but it will reuse the existing custom properties if they are already defined in the SpiraTeam product.
"},{"location":"Requirements-Management-Integration/Importing-From-RequisitePro/","title":"Importing From RequisitePro","text":"This section outlines how to use the included Integration Adapter for importing Requirements, and Use Cases from IBM Rational\u00ae RequisitePro\u00ae into SpiraTest\u00ae.
"},{"location":"Requirements-Management-Integration/Importing-From-RequisitePro/#installing-the-integration-adapter","title":"Installing the Integration Adapter","text":"This section outlines how to install the integration adapter for RequisitePro onto a workstation so that you can then import requirements and use cases from RequisitePro into SpiraTest. It assumes that you already have a working installation of SpiraTest v2.2 or later and a working installation of RequisitePro v7.0 or later. If you have an earlier version of SpiraTest or RequisitePro, you will need to upgrade to at least v2.2 and v7.0 respectively before trying to import data.
To obtain the version of the migration tool that is compatible with your version of SpiraTest, you simply need to log-in as a project-level administrator to SpiraTest, go to the Administration home page and download the Integration Adapter Windows Installer package (.msi). This process is described in the SpiraTest Administration Guide in more detail.
Important: You must install the integration adapter on the same workstation that has the installed copy of RequisitePro. Once you have obtained the Windows Installer package, simply double-click on the package to begin the installation wizard which should display the following welcome page:
Click the <Next> button to choose the folder to install the integration adapter to:
Choose the folder to install to, and then decide whether the application should be accessible by all users on the workstation or just the current user. Then click the <Next> button to start the installation process. It will confirm if you want to proceed, click <Next> then wait for it to finish.
"},{"location":"Requirements-Management-Integration/Importing-From-RequisitePro/#importing-from-requisitepro_1","title":"Importing From RequisitePro","text":"Now that you have installed the integration adapter, you can launch it at any time by going to Start > Programs > SpiraTest > Tools > RequisitePro Adapter. This will launch the import application itself:
The first thing you need to do is to click the <Browse> button and select the Rational RequisitePro project file (.rqs) that you want to import from. You also need to select a valid username and password for that project. Once you have done this, click the <Login> button to verify that the project file can be opened.
The button marked <Clear Project Cache> will be explained later on.
Assuming that the user name selected has permission to access this project, you will be prompted with a message box indicating that the login was successful. Now click the <Next> button to move to the next page in the import wizard:
This page allows you to enter the URL, user name and password that you want to use to access the instance of SpiraTest that you want to import to and click <Login>. Typically the URL is of the form (http://<server name>/SpiraTest). The version of the importer being used must be compatible with the version of SpiraTest you're importing into; if not you will receive an error message.
Assuming that the login was successful, click the <Start Import> button to actually begin the process of importing the various artifacts from RequisitePro into SpiraTest. Note that the first time the importer sees a particular project file, it will create a new project in SpiraTest to hold all the artifacts with the same name as that used in RequisitePro.
During the import process, as each of the types of artifact are imported, the progress display will change (as illustrated above). Once the import has finished, you will receive a message to that effect and the <Done> button will be enabled. Clicking this button closed the importer. You should now log into SpiraTest using the same user name and password that was used for the import to view the imported project.
"},{"location":"Requirements-Management-Integration/Importing-From-RequisitePro/#using-requisitepro-with-spiratest","title":"Using RequisitePro with SpiraTest","text":"Once you have completed this initial import, you will now have two systems that can be used together to manage your project's lifecycle. How they should be used together depends on which methodology you have been using in your RequisitePro project:
Traditional Mode -- In this mode, RequisitePro only contains product requirements and software requirements. These are both loaded into SpiraTest's requirements matrix and can be used as a starting point for developing the necessary test case coverage. In this mode, requirements are managed in RequisitePro and all other artifacts are managed in SpiraTest.
Use Cases Mode -- In this mode, RequisitePro contains features, supplementary requirements and use cases. The features and supplementary requirements are loaded into SpiraTest's requirements matrix, and the use cases are loaded into SpiraTest's test case list. Note that these use cases do not contain any test steps. In this mode, requirements and test cases are managed in RequisitePro, and test steps, test runs and incidents are managed in SpiraTest.
Regardless of the mode employed, you can manage the appropriate artifacts in RequisitePro and then periodically re-run the import application to update SpiraTest. The application will remember that the project was already used for an initial load and will simply update the requirements and/or test cases as appropriate as well as add any additional ones added.
Note that this update process does not delete any artifacts removed in RequisitePro and any changes to the requirement or use case hierarchies are not reflected. This allows you to change the organization of the artifacts in SpiraTest to make them easier to use without the changes being overwritten on the next import cycle.
Finally, should you want to start again and re-import a project from scratch that has already been imported once before, you should choose the <Clear Project Cache> button on the first screen which will remove all the stored history of all previously loaded projects. This option is irreversible and should be performed with care.
"},{"location":"Requirements-Management-Integration/Importing-From-VersionOne/","title":"Importing From VersionOne","text":"This section outlines how to use the included Importer for importing Iterations/Sprints, Epics and Stories/Backlog Items from projects residing in VersionOne projects into equivalent projects in SpiraTest\u00ae, SpiraPlan\u00ae or SpiraTeam\u00ae (hereafter referred to as SpiraTeam).
"},{"location":"Requirements-Management-Integration/Importing-From-VersionOne/#installing-the-importer","title":"Installing the Importer","text":"This section outlines how to install the importer onto a workstation so that you can then import requirements and use cases from VersionOne into SpiraTeam. It assumes that you already have a working installation of SpiraTeam v3.0 or later and a working installation of VersionOne 8.0 or later.
You can download the Importer from the Inflectra's website under \"Downloads and Add-Ons\". When downloaded, double-click the MSI file. Follow the instructions in the MSI file to install the importer.
"},{"location":"Requirements-Management-Integration/Importing-From-VersionOne/#importing-from-a-versionone-project","title":"Importing from a VersionOne Project","text":"Now that you have installed the integration adapter, you can launch it at any time by going to Start > Programs > SpiraTest > Tools > VersionOne Adapter. This will launch the import application itself. You will be shown an introduction screen. Click 'Next' to get to the second screen:
You need to enter the VersionOne Server URL (including the port number if appropriate), the username and password you use to log onto the system, then click the Get Projects button. If you choose 'Use Windows Authentication' it will use the credentials of the currently logged-in user and disable the username/password text boxes.
The program will connect to the server and get a list of all available projects. Select the project you want to import into under the Project section. Once the project is selected, click Next to continue to the screen where you enter your SpiraTeam server and project information:
On this screen, you need to enter the SpiraTeam Server URL, the username and password you use to log onto the system, then click the Get Projects button. The program will connect to the server and get a list of all available projects. Select the project you want to import into under the Project & Requirement section.
The Root Requirement box is for specifying a base requirement to load all the VersionOne elements into. If left blank, then the importer will create a single placeholder requirement that all of the VersionOne epics and backlog items will be nested under.
If you have a requirement already in SpiraTeam, and want the VersionOne items to appear inside it, then you need to enter the requirement number into the Root Requirement text box. For example, if you have a requirement named \"VersionOne Requirements\" with a number of RQ1920, then put 1920 into the Root Requirement field and run the import. When import is finished, the SpiraTeam requirements will be nested underneath.
Note: At this time, change request and defect items are not imported from VersionOne projects.
Once the fields have been populated, click Next to get to the summary screen.
The summary screen tells you what will actions will be performed, and once you have verified the information, click the Import button to start the import:
Anything flagged with a red
failed, green
means that they succeeded. Once finished, click Finish to get to the last page of the wizard:
If the Minimize to System Tray option is selected, when you click Finish or exit the from the application, it will minimize to the system tray. Once in the system tray, you can right-click on the icon and the it will give you the option to either re-import from the same project or select another project for a fresh import. If the option is not selected, the program will exit, and you can re-launch the importer to import from the same or another VersionOne project.
"},{"location":"Requirements-Management-Integration/Importing-From-VersionOne/#using-the-system-tray-shortcut-menu","title":"Using the System Tray Shortcut Menu","text":"When the application is minimized to the system tray, there are several shortcuts available:
Double-Clicking the icon will bring the importer back to the first screen, allowing you to import another VersionOne project.
Right-clicking will give a shortcut menu with the following options:
Exit -- Close the program entirely.
Rerun Import -- Will provide you the screen to re-launch the last import you just ran.
Show Window -- Same as double-clicking on the icon, will bring the wizard back to the first screen, allowing new input options to be set.
At this time, only requirements and iterations/sprints are imported into SpiraTeam from VersionOne. The epics in VersionOne become summary requirements in SpiraTeam and the backlog items / stories become child requirements in SpiraTeam. In addition, the following fields are brought over into SpiraTeam from VersionOne according to the following mapping table:
VersionOne Field SpiraTeam Field Name Name Description Description (with HTML) Priority Importance: VersionOne Value : SpiraTeam Value High : High Medium : Medium Low : Low Status Status: VersionOne Value : SpiraTeam Value Future : Requested Accepted : Accepted Done : Completed In Progress : In Progress Author (not transferred, always set to user who ran the import last) Iteration/Sprint Release / Iteration Owner (not transferred) Estimate Planned Effort (not transferred) VersionOne ID Custom Text Property TEXT_01 VersionOne Display ID Custom Text Property TEXT_02Using this adapter, you can manage the appropriate artifacts in VersionOne and then periodically re-run the import application to update SpiraTeam. The application will remember that the project was already used for an initial load and will simply update the requirements as appropriate as well as add any additional ones added. If you are using SpiraTeam v3.1 or later, the update process will also delete any artifacts removed in VersionOne.
Note that any changes to the requirement hierarchy are not reflected. This allows you to change the organization of the artifacts in SpiraTeam to make them easier to use without the changes being overwritten on the next import cycle.
Finally, should you want to start again and re-import a project from scratch that has already been imported once before, you may do so by re-running the Importer, and entering in -1 as the Root Requirement. This will not delete requirements from SpiraTeam, only remove mappings, so the next time you run the importer on this file, all new requirements will be created.
Note: This option is irreversible and should be performed with care.
"},{"location":"Spira-Administration-Guide/","title":"Welcome to the SpiraPlan Administration Guide","text":"How to use this guide
This documentation is designed for all administrators of SpiraTest, SpiraTeam, or SpiraPlan.
To find the section you need, open the \"Admin Guide\" section from the site navigation to see all available chapters.
If you are installing Spira on your own servers, please read the \"Installing Spira\" chapter carefully. This is not required if you are hosted in the cloud by Inflectra.
We recommend that all new administrators read the section \"System Administration\" to get an overview of the administration functions in the application.
"},{"location":"Spira-Administration-Guide/Installing-SpiraPlan/","title":"Installing SpiraPlan\u00ae","text":"This section outlines how to:
The minimum hardware and software requirements for running the SpiraPlan\u00ae system are:
Server Requirements Requirement Minimum Specification Processor: Intel\u00ae or AMD\u00ae x86 or x64 compatible processor Memory: 4 GB, 8 GB recommended Operating System: Windows Server 2016+ (recommended) Windows Server 2012 R1 & R2 Windows 10 (for demoing) Database: Microsoft SQL Server 2016+ Microsoft SQL Server 2016+ Express Edition* Web Server: Internet Information Services (IIS) 7.0 or higher ASP.NET Web Extensions 4.7.2 or higherNote: Please consider there are some limitations for FREE SQL Express [That may significantly affect performance thus we don't recommend it to be used on production/handling large amounts of data).
Client Requirements Web Browser: Microsoft Edge Mozilla Firefox Google Chrome (Desktop and Android) Apple Safari (Desktop and iOS) Opera Other Components: Microsoft Excel 2010+ (optional) Microsoft Word 2010+ (optional) Microsoft Project 2010+ (optional)*Note that SpiraPlan\u00ae can be loaded onto either Windows Server or workstation editions, provided that the IIS web-server is installed and that SQL Server is available as a database engine. However, Windows workstation editions can only support a maximum of 5 concurrent user web sessions. In general, unless there are only going to be a couple of client machines hitting the server, we recommend using Windows Server.
"},{"location":"Spira-Administration-Guide/Installing-SpiraPlan/#system-prerequisites","title":"System Prerequisites","text":"Assuming that you have already installed the appropriate version of Microsoft Windows onto your computer (or that has been pre-installed for you), make sure that the various prerequisites have been correctly added to your installation before trying to install SpiraPlan\u00ae. The SpiraPlan\u00ae installer will check to ensure that the various prerequisites are in place, and will abort the installation if any are missing, indicating to you what action needs to be taken.
We recommend that you install / configure the prerequisites in the following order:
On most modern Windows 11 and Windows Server 2022+ installations, Microsoft .NET Framework v4.7.2 is usually already installed. On earlier operating systems, you may need to manually add the .NET 4.7.2 components to the factory configuration.
To see which version of the Microsoft .NET framework installed please follow the below steps:
You can find the version under \u201cProduct version\u201d property. See the below screenshot:
To install the .NET Framework, launch your browser and enter the URL: https://www.inflectra.com/CustomerArea. Once you have logged-in to the customer area, under the \"My Downloads\" section there will be hyperlinks to download and install the appropriate version of the .NET Framework (version 4.7.2 at time of writing). Click on the option to download and install the .NET Framework, and follow the instructions provided. Once you have completed the install, verify that the installation was successful by looking in the \"Administrative Tools\" folder as illustrated above. You also need to make sure that .NET 4.7.2 has been installed if necessary.
"},{"location":"Spira-Administration-Guide/Installing-SpiraPlan/#install-sql-server-version-2016-or-higher","title":"Install SQL Server version 2016 (or higher)","text":"If you do not have a SQL Server instance ready, you can install the appropriate version of the database software, following the instructions provided with the installation. For basic or trial use, we recommend SQL Server Express Edition. This free version of SQL Server will offer sufficient performance where performance and storage are not important (such as during a trial). SQL Express can be downloaded from either the customer area of our website (http://www.inflectra.com/CustomerArea) or directly from Microsoft's website.
You must setup the built-in SA (SysAdmin) account on SQL Server. Make sure SQL Server setup allows mixed-mode authentication so it allows both SQL Server and Windows logins:
SA user is required during the installation/upgrade to create the Database and required Logins, and this can be done using a SysAdmin user only.
Ensure you have enabled the Full-Text Indexing feature enabled prior running installer of Spira application.
"},{"location":"Spira-Administration-Guide/Installing-SpiraPlan/#ensure-that-iis-is-installed","title":"Ensure that IIS is installed","text":"On Windows Server OS installations, IIS is usually installed as part of the factory configuration, whereas on Windows workstation OS installations, you typically need to manually add the components to the factory configuration. The steps that you need to take to verify its installation are listed below:
On Windows 8 or 8.1, to install IIS, you need to click Start > Control Panel > Programs and Features or type appwiz.cpl in Run, then choose the option to \"Turn Windows features on or off\". This will bring up the list of features and roles that can be configured on the server:
"},{"location":"Spira-Administration-Guide/Installing-SpiraPlan/#windows-10","title":"Windows 10","text":"On Windows 10 and Windows 11, to install IIS, you need to click Start > Control Panel > Programs and Features or type appwiz.cpl in Run, then choose the option to \"Turn Windows features on or off\". This will bring up the list of features and roles that can be configured on the server:
Make sure that the following features are enabled within the 'Internet Information Services' folder:
Web Management Tools
IIS 6 Management Compatibility
World Wide Web Services
Application Development Features
Common HTTP Features
In the same panel ('Turn Windows Features on or off') you also need to check that the following features are enabled in the '.NET Framework 4.6 Advanced Services' folder:
.NET Framework 4.6 Advanced Services
WCF Services
To verify that this IIS is now installed, type \"http://localhost\" into the browser's address bar. You should see a screen displaying the initial IIS startup page:
"},{"location":"Spira-Administration-Guide/Installing-SpiraPlan/#windows-server-2012-2016-2019","title":"Windows Server 2012, 2016, 2019","text":"On Windows Server 2012, 2016, 2019, you need to click on Server Manager, then under the \"Roles\" heading, choose the option to \"Add Role\" (Add Roles and Features in Windows Server 2019+) followed by selecting the new role \"Web Server (IIS)\" or using a PowerShell command Install-WindowsFeature -name Web-Server -IncludeManagementTools
Then click \"Next\" to bring up the role configuration screen:
Make sure that the following features are enabled:
Web Server (IIS)
Application Development
Management Tools
WCF Services
Once IIS and .NET are both installed, make sure the Active Server Pages (ASP.NET) components that allow IIS to access the .NET framework are correctly configured. If you installed .NET after IIS, then ASP.NET is typically configured for you. But if you installed IIS afterwards, then further manual steps may be necessary.
To verify that ASP.NET has been correctly configured, click on Start > Control Panel > Administrative Tools > Internet Information Services (IIS) Manager to launch the IIS administrative console:
You should see a section called \"ASP.NET\" occupying the top third of the IIS screen. If not, then you need to go back to Ensure that ASP.NET is installed and make sure that you chose the option to install ASP.NET when installing IIS.
"},{"location":"Spira-Administration-Guide/Installing-SpiraPlan/#installing-the-software","title":"Installing the Software","text":"Once all of the prerequisites are correctly installed, you are now ready to install SpiraPlan\u00ae. To start and successfully finish the installation you will need the items listed below (all of which are available in the customer area of the Inflectra\u00ae website):
To start the installation, double-click on the SpiraPlan\u00ae installation package (it will have a filename in the form of SpiraPlan-vX.X.X.exe). The Installer will display the following dialog box:
"},{"location":"Spira-Administration-Guide/Installing-SpiraPlan/#select-an-installation-type","title":"Select an Installation Type","text":"Click the \"Next\" button to start the installation wizard. The wizard will gather information about what you want to do and how you want to do it. Before any changes are made to your system (installing web-server files and database components) you will get a chance to review everything again.
"},{"location":"Spira-Administration-Guide/Installing-SpiraPlan/#review-the-license-agreement-and-prerequisites","title":"Review the License Agreement and Prerequisites","text":"If installing a fresh installation or upgrading, after making your selection the next screen provides a copy of the SpiraPlan\u00ae End User License Agreement (EULA). Please read this carefully as it describes the legal contract between you -- the user of the software -- and Inflectra\u00ae Corporation, the developer and publisher. Once you have read the agreement and understood your rights and obligations, select the radio button marked \"I accept the terms in the License Agreement\" and click the \"Next\" button.
The next page of the wizard will display a list of the required pre-requisites. The installer does not attempt to verify if these pre-requisites have been met or not. The information is displayed for information purposes only. If a pre-requisite is missing the application may display incorrectly.
"},{"location":"Spira-Administration-Guide/Installing-SpiraPlan/#license-information","title":"License Information","text":"The next stage of the wizard (for installing and upgrading) is to enter license information:
You need to enter:
The installer will verify the license information as you enter it. If the details entered are valid then the information will be displayed beneath the entry fields. This allows you to check that the correct application and license will be installed. On clicking Next, the installer will warn you of any discrepancies, and will not allow you to proceed until valid information has been provided.
If for any reason you are unable to get the provided license key to work, please contact Inflectra\u00ae customer support for help resolving the issue.
"},{"location":"Spira-Administration-Guide/Installing-SpiraPlan/#choose-an-installation-location-advanced-mode-only","title":"Choose an Installation Location (advanced mode only)","text":"If you checked \"advanced\" at the start of the installation process, you will have the option to choose where the application is installed. You can choose an existing folder or make a new one and select that. By default it is C:\\Program Files (x86)\\[Application Name]).
"},{"location":"Spira-Administration-Guide/Installing-SpiraPlan/#web-server-configuration","title":"Web Server Configuration","text":"Choose which web site to install SpiraPlan\u00ae into using the available dropdown, which should list all available web sites in IIS on this machine. The Default Web Site will be preselected and is the best option in most circumstances.
Virtual Directory (advanced mode only)
If installing in advanced mode, then on this screen you will able to change the name of the web-site URL that will be used to access the system. By default, users would need to type into their browsers: http://\"server name\"/[product name]. Should you want to have a different name change the name in the Virtual Directory box, otherwise simply accept the default name and click \"Next\".
Note: The installer will check to make sure that the name you have chosen is not already in use, and will warn you if it is.
"},{"location":"Spira-Administration-Guide/Installing-SpiraPlan/#connect-to-the-database","title":"Connect to the Database","text":"SpiraPlan\u00ae has an application (installed into a default folder on your system), a website (configured above), and a database. The next screen tells the installer how to connect to the database server on your system.
a) Windows Authentication
This is the easiest option when the application and database will be residing on the same server. It is the only option available for authentication during a standard installation. In this case, choose the \"Windows Authentication\" option and the Login/Password boxes will be disabled. In this case, the installer will connect to the database using your current Windows login to create the application database objects, and SpiraPlan\u00ae will connect to the database during normal operation using either the ASPNET or NETWORK SERVICE Windows accounts (it depends on the version of the operating system).
b) SQL Server Authentication (advanced mode only)
This is the easiest option when the application and databases will be residing on different servers across the network. In this case, choose \"SQL Server Authentication\" under \"Connection Information\" section and provide SQL Server Login that has full sysadmin permissions -- e.g. the built in System Administrator (SA) account. The installer will use this SysAdmin account to create the database objects. The password for SA account is set in SQL Server itself and should be saved carefully.
Note that using this account for the 'Connection Info' fields is not a security risk as the installer does not remember this login and after the database is created. The credentials are used once and discarded.
With SQL Server authentication, the IIS application pool will run as a low-credentialed system user, typically the 'NETWORK SERVICE' account. This lets the application pool access the local system resources only:
Inside SQL Server SpiraPlan will use a dedicated login (called \"SpiraPlan\" by default, created automatically) for normal application operations. The username should not be changed as it is required by the application for it to operate.
Setting the Correct Server Instance
In the \"Server\" box, you need to enter the name of the Microsoft SQL Server instance that is running on your system; the installer will default it to the hostname of the server (which in many cases will be correct). The easiest way to find out the database server name is to:
For SQL Server Express edition installations, the Server name is usually the name of your computer followed by \"\\SQLEXPRESS\", so for example, if your computer is called MyComputer, the server name would be MyComputer\\SQLEXPRESS or simply use .\\SQLEXPRESS (Omitting the second part (called the instance name) would lead to a \"host not found\" error):
You can also choose whether to install the sample products or not - typically we recommend installing the sample products for evaluation installations and excluding them for production installs.
"},{"location":"Spira-Administration-Guide/Installing-SpiraPlan/#complete-the-installation","title":"Complete the Installation","text":"Once you have entered the various pieces of information, click \"Next\". The installer will attempt to connect to the database using the provided information, and it will display an error message if any of the information is incorrect. Assuming the information is correct, the following screen will be displayed:
Once you have confirmed that everything is correct, click the \"Install\" button to actually begin the process of installing SpiraPlan\u00ae onto your system. The installer will then display a progress bar as the installation proceeds. Once the installation is complete, the installer will provide confirmation, or display information about any problems it encountered.
Click the \"Finish\" button to complete the installation.
Congratulations! You have successfully installed SpiraPlan\u00ae onto your system. If you type http://localhost/SpiraPlan into your browser you should see the SpiraPlan\u00ae login page. If for any reason you don't see the login page, please contact Inflectra\u00ae support team.
"},{"location":"Spira-Administration-Guide/Installing-SpiraPlan/#upgrading","title":"Upgrading","text":"You can upgrade any SpiraPlan version that is 5.4.0.4 or newer using the latest installer (for instance you can upgrade from 5.4 to 7.7, or from 6.9.0.1 to 7.7 using the exact same installer exe). To upgrade from versions older than 5.4.0.4 you first need to upgrade to 5.4.0.4 and then upgrade to the latest version.
For example, to upgrade from SpiraTest v2.3.1 to v5.4, you would first upgrade from SpiraTest v2.3.1 > v3.2, then upgrade from SpiraTest v3.2 > v4.2, next step is to upgrade from v4.2 > 5.4
To upgrade an existing installation:
The next screen provides a copy of the SpiraPlan\u00ae End User License Agreement (EULA). Please read this carefully as it describes the legal contract between you -- the user of the software -- and Inflectra\u00ae Corporation, the developer and publisher. Once you have read the agreement and understood your rights and obligations, select the radio button marked \"I accept the terms in the License Agreement\" and click the \"Next\" button.
The next page of the wizard will display a list of the required pre-requisites and whether the installer could find them or not. The checks here are not fool-proof (in particular where a question mark is shown) so it is recommended to manually check the prerequisites in full as described above. The system will not require all prerequisites to be met before allowing the installation, but the application may display incorrectly if any are missing.
"},{"location":"Spira-Administration-Guide/Installing-SpiraPlan/#license-information_1","title":"License Information","text":"The next stage of the wizard is to enter license information:
You need to enter:
The installer will verify the license information as you enter it. If the details entered are valid then the information will be displayed beneath the entry fields. This allows you to check that the correct application and license will be installed. On clicking Next, the installer will warn you of any discrepancies, and will not allow you to proceed until valid information has been provided.
If for any reason you are unable to get the provided license key to work, please contact Inflectra\u00ae customer support for help resolving the issue.
"},{"location":"Spira-Administration-Guide/Installing-SpiraPlan/#upgrade-location","title":"Upgrade location","text":"The installer points the upgrade to the default installation location for the licensed version. If this is not correct, click the folder icon to select the proper installation location.
After verifying the location, the installer will display the screen that shows the summary of actions to be performed. Confirm to proceed with the upgrade.
In case of problems, a backup of the existing database is made when upgrading. The backup can be manually selected to ensure safety of the current database. The location is given on the summary screen, and is usually the default backup directory for SQL Server.
To recover your system, restore the backup over top of the existing corrupted database. You can then try the upgrade again.
If problems persist, please contact the Inflectra support team, and they will explain how to retrieve the logs for remediation.
"},{"location":"Spira-Administration-Guide/Installing-SpiraPlan/#advanced-install-scenarios","title":"Advanced Install Scenarios","text":"There may be a few cases where you need to customize the installation or upgrade of SpiraPlan\u00ae. To enable the installer's advanced mode, make sure to check the \"Advanced\" checkbox at the relevant screen of the wizard.
Including the options listed above with \"(advanced mode only)\" next to them, Advanced mode lets you:
Without a UserId/password listed in your connection string, Windows Authentication is used (the default). When asked for the username/password under \"Connection Info\", that user needs to be a SQL Account that is a sys admin, since the database and logins are going to be created. The database user is listed under 'Database settings', and should be left as their defaults as the installer sets and creates those automatically.
The 'sa' account is a built-in SQL account ('system admin'), and the password is usually set in SQL Server itself. Note that you can use this under the 'Connection Info' part of the installer. Please note that the installer does not remember this login after the database is created.
Leave 'Database Settings' section unchanged, as filled by default (make sure the Database name is the actual database you'd like to upgrade).
"},{"location":"Spira-Administration-Guide/Installing-SpiraPlan/#adding-an-application-server","title":"Adding An Application Server","text":"Use this option when you already have another application server and database server configured and operational. Installation is very similar to a standard installation normally. However, when the page about the SQL Server and Database is displayed, it requires you to point to the existing SQL Server and Database.
All other actions during this install matches those in a standard installation.
"},{"location":"Spira-Administration-Guide/Installing-SpiraPlan/#upgrading-an-existing-database","title":"Upgrading an existing Database","text":"Use this option in two rare cases:
These steps in this option are the same as if you were upgrading the application normally. You will be asked for the SQL Server and Database information for your database.
Once the installer connects and verifies the version of the database to be installed, you will be prompted with an additional Options screen with two options:
The Microsoft Internet Information Services (IIS) web-server and SQL Server database are powerful tools to managing web-based applications. However it is important to make sure that they are correctly secured to prevent unauthorized access to applications being hosted on them. This is a fast-changing field and beyond the scope of this guide to address, however we recommend reading the following article for details on how to secure IIS:
http://www.iis.net/learn/manage/configuring-security
In addition to the steps outlined in this article, it is important to note that by default, all web pages served by IIS using the HTTP protocol are unencrypted, and as such, the usernames and passwords used by SpiraPlan\u00ae to log into the application can be read by network sniffing tools. If you are using SpiraPlan\u00ae purely within an intranet environment, this may not be an issue. However, if you are externally hosting SpiraPlan\u00ae onto a publicly accessible website, we recommend installing a Secure Sockets Layer (SSL) encryption certificate, and restricting all web-traffic to the secure HTTPS protocol instead.
"},{"location":"Spira-Administration-Guide/Installing-SpiraPlan/#troubleshooting","title":"Troubleshooting","text":"Every time the installer attempts an operation (like an install or upgrade), it stores a log file. This is located at \"c:\\ProgramData\\Inflectra\\SpiraPlan\". Each log file is labelled with the date and time of the operation. Please share the relevant files with the Inflectra support team if you need help troubleshooting the required operation.
"},{"location":"Spira-Administration-Guide/Product-Changing-Template/","title":"Product: Changing the Template a Product Uses","text":""},{"location":"Spira-Administration-Guide/Product-Changing-Template/#introduction","title":"Introduction","text":"Each product in Spira has a template that controls the bulk of how that product is configured and will work for end users. Each product is controlled by one template, though each template can control many products at once. A template affects a product\u2019s fields, custom properties, workflows, and more.
If you change a product\u2019s template, you are not changing the core data inside the product. But you are changing how that product will work. This is not something to do lightly. There is a deep connection between a product and its template. When you change templates, you are changing the workflows, and also all the links in the product from the old template to the new template.
It\u2019s like trying to change out the engine in a car by replacing it with parts from another engine. If that new engine has different pistons and gears then the car will look the same, with the same seats, the same windows, and the same doors. It will just run a little differently. Below, we explain in gory detail:
As mentioned above, only those standard fields controlled by templates can change when changing templates for a product. Let\u2019s call these fields \u201cdynamic fields\u201d No other standard fields (i.e. non custom fields) in the product will change in any way. The dynamic fields in SpiraPlan are below (not all of these are available in SpiraTeam or SpiraTest):
For each of the dynamic fields above the system will:
As mentioned above, only custom fields of type list or multilist are affected by changing templates. No other custom field changes in any way and custom lists are also completely unchanged.
Matching custom fields between templates is more complicated than for standard fields. Before the system can match values of custom list/multilist fields, it checks that the custom field in the old template has a matching field in the new template.
A custom list/multilist field has a match between the templates if:
If all the above conditions are met, the system will:
When you look at the history for artifacts after the template has been changed, you won\u2019t see any difference. Behind the scenes, references to dynamic fields and custom list/multilist fields, are updated to the new template.
This so that, where possible, when you try and revert a history change, the reverted data updates the artifact to the new template - not the old one. If there was no match found when changing templates, then reverting history will not revert that particular field.
"},{"location":"Spira-Administration-Guide/Product-Changing-Template/#what-about-test-configurations","title":"What about test configurations?","text":"Test configurations use the template\u2019s custom lists. So when you change templates to a new template with different custom lists, what will happen? The system will:
As you will see above, the process of changing templates is not without risks. We flag many of these risks to you during the process itself to guide you. Below are five steps to help you prepare for changing to a product's template.
This page displays a list of changes made to items within the selected product. By default, items are shown in chronological order - with the most recent at the top.
The following artifact changes are recorded:
If baselining is enabled for this product, changes to assocations, test coverage, and positions of test steps, use case steps, and mitigations are recorded. Certain changes to artifacts are not recorded, such as location changes (indenting, outdenting) and comment additions.
Additionally, certain product administration changes are recorded and displayed. These include turning baselining on and off for a product, all testing settings, and some planning options (for example Work In Progress Limits).
There are a handful of change types recorded and displayed here:
Note: When upgrading from a version before v3.1, each individual field changed will be considered a unique change, due to how previous versions recorded history. However, as soon as the application is upgraded, simultaneous changes will be grouped together based on their last-update date.
This screen allows the administrator several options (below). NOTE: if baselining is enabled for this product you will not be able to purge all, and you will only be able to revert recent changes (those made since the last baseline for this product was created).
The history details screen displays information on the selected change set:
The History Details screen will show basic information as well as fields that were changed in this change set. Shown here is the Change ID, the date and time that the change was made, the user that made the change, the change type, the artifact affected, and the set of fields affected.
If a set of fields were affected (Standard or Custom), then the list of fields will be listed below. In the example above, the change was a Modification, and 5 fields were changed. In other change types, no fields will be displayed.
If the artifact is still available in the system, you can click the Artifact or click the 'View Item' button in the toolbar to view the item as it is currently. However, if the item has been deleted, a warning label will be displayed (as above in the example screenshot), the View Item links will be disabled, and a new option, \"Purge\" will appear on the toolbar.
If baselining is turned on
If baselining is enabled for this product, you will only be able to revert or purge recent history items (those made since the last baseline for this product was created).
"},{"location":"Spira-Administration-Guide/Product-General-Settings/#purging-items","title":"Purging Items","text":"Items that have been deleted by any user still remain in the database, but do not affect statistics or reports, and do not show up in reports and cannot be viewed. The artifacts are still in the database, however, and can be restored by clicking on the Restore button in the toolbar.
Purging an individual item can only be done while viewing one of its history detail screens. Once an item is purged, you will be taken back to the history list screen. All the previous history items for the artifact will be removed, and replaced with a single \"Purged\" history item.
Items that are purged cannot be restored into the database, as unique identifiers will be wiped from the database, so be sure that you are sure you want to purge an item before doing so.
You can purge all items in the product at once by clicking the \"Purge All\" button located on the History List page. This will take some time depending on how many deleted items are in your database, and it is recommended that the database files be compressed in SQL Management Studio afterwards to free up space and compress clustered indexes.
"},{"location":"Spira-Administration-Guide/Product-General-Settings/#reverting-items","title":"Reverting Items","text":"Reverting an artifact will attempt to reset all fields back to the selected change set, reverting all changes made after the selected change set as well. In certain cases, the artifact will not be able to be reverted -- cases like this could be caused by other items having been deleted or purged. (For example, if Requirement #1 was linked to Release #4, and that Release does not exist anymore.) In cases like this, no fields will be reverted and the artifact will remain unchanged.
Reverting an item will cause it to be undeleted if it has been deleted.
You can revert multiple items from the History List page -- however, the only items that can be reverted back are Deletes and Modifications. All other types will be ignored. When selecting multiple items, you can select more than a single change set for a specific artifact, the artifact will be rolled back to the earliest change set selected.
"},{"location":"Spira-Administration-Guide/Product-General-Settings/#product-associations","title":"Product Associations","text":"By default, all products in SpiraPlan are completely self-contained. Artifacts in one product can only be linked or associated with artifacts in the same product. However, for some customers, they need a way to share artifacts between products. This administration screen lets the product admin specify which other products can access artifacts in the current product:
Permissions when sharing artifacts across products
When you share artifacts from the current product to another product, the permissions and membership in the other product determine who can see what items. You therefore need to think about the impact of this before enabling cross product associations.
For example: Marie is a member of Product A and can see its requirements. She is not a member of Product B and cannot see anything in Product B at all. If Product B shares its requirements with Product A, anyone who can see Product A's requirements (like Marie can) will now be able to see (not edit - only see) all of Product B's requirements too.
"},{"location":"Spira-Administration-Guide/Product-General-Settings/#what-artifacts-can-be-shared-across-products","title":"What artifacts can be shared across products","text":"You can share the following artifacts from one product to another:
When you share the above artifacts from the sharing product to another product, members of that product can now see (read only) all artifacts of that type from the sharing product. Users can see these artifacts in a number of places in the other product (the one being shared with). For example:
To share artifacts with another product, click on the 'Add' button in the toolbar:
Select the name of the product you want to share with and choose which artifact(s) you want to share with this product:
When you click the 'Add' button, SpiraPlan will add the new product association to the list.
You can change the product association (for example to change which artifacts are shared) by clicking on the 'Edit' button to the right. This updates the association list.
To remove an association, simply select its checkbox and click 'Remove'.
"},{"location":"Spira-Administration-Guide/Product-General-Settings/#data-synchronization","title":"Data Synchronization","text":"This pages shows a list of all active integration plug-ins that the product is actively synchronizing with. Available plugins are set system wide.
In the above example, only TFS is active for this particular product. Clicking on \"View Product Mappings\" will display a detailed page for configuring this product to work with this plug-in. Here you can set the external key to use in the external application and map all relevant fields between Spira and this application. To read about how to configure this page, refer to the guide for your particular external bug tracking tool.
"},{"location":"Spira-Administration-Guide/Product-General-Settings/#product-data-tools","title":"Product Data Tools","text":"This page contains several different data management tools that can be used to identify certain data issues in the system and correct them. There are two main sections to this page -- Data Caching and Indentation Hierarchy:
Database Indexes: In order to improve the performance of SpiraPlan\u00ae, it can be beneficial to refresh the database indexes. Clicking the \"Refresh\" button illustrated above will refresh all relevant database indexes across all SpiraPlan products. If for any reason performance seems to be slower than usual after a large import of data (for instance from Excel, or using the product migration tool) or after a recent database upgrade, you should consider refreshing the indexes. Depending on the size of the database, this could take some time. Please keep the web page open throughout the process to ensure it can complete successfully.
Data Caching: In order to improve the performance of SpiraPlan\u00ae, certain types of product data are cached. Very occassionally, the cache can get behind the data in the actual database. In such cases, refreshing the cache will make sure the cache is fully up to date and correct data is therefore displayed in the application. If users report this kind of problem in one of the cache areas, click the relevant Refresh Cache button.
Indentation Hierarchy: The Requirement and Releases pages use an \"Indent\" system for managing the hierarchy of information. This allows requirements and test cases to be nested under parent items and be rapidly searched and filtered on. Sometimes if a move/copy operation is interrupted (due to a network outage, etc.) the hierarchy may get corrupted. If you suspect a problem with either of these artifacts, click the \"Check\" button. Once the check has run, if you see a red Error message instead of the Green OK that means problems were found. If that happens, click the \"Correct\" button and the system will correct the indent levels.
Clicking on the Source Code link in the administration menu will, if a source code provider has been set up by a system administrator, show a screen like the one below.
The first thing you need to do (regardless of whether you'll be overriding any of the settings) is to make the provider active for the current product. To do this, change the toggle to \"Yes\" and click [Save]:
Now you can decide whether you want to override any of the default settings for this product. Any field left blank will automatically get its settings from the default values entered at the system level. In the example above, we have specified a product-specific repository path, login and password. Once you have correctly configured the product, click [Save] to commit the changes.
To improve performance, SpiraPlan will cache some of the data it receives from the source code provider. Normally SpiraPlan will know when to update the cached data based on changes made in the source code system automatically. However, sometimes you may wish to force the cache to refresh right now. To do so, click the \"Refresh Cache\" button. If you ever want to wipe the cache completely and have it rebuild from scratch, click \"Clear Cache\".
You are now ready to use SpiraPlan\u00ae in conjunction with the source code tool you selected. For details on how to use the Source Code integration features of SpiraPlan, please see here.
"},{"location":"Spira-Administration-Guide/Product-General-Settings/#baselines","title":"Baselines","text":"NOTE: read about how baselining works and how to get started with it here
This page displays a list of all baselines in the product. You can only access this page in products where baselining has been turned on.
The table of baselines has the following columns:
Name: baseline name
Name (this links to the baseline details page)
To filter and sort the list of baselines, use the filter and sort controls at the top of the table.
"},{"location":"Spira-Administration-Guide/Product-General-Settings/#baseline-details","title":"Baseline Details","text":"This page displays detailed information about a single baseline. You cannot edit information about the baseline on this page. That can only be done from the release details page.
Information about the baseline is divided into 4 sections:
Why do we show the previous baseline?
A baseline is created against a point in time (more precisely, against a specific change event in this product). This is the end of the baseline. To know what happened during a baseline you need to know when a baseline starts. The start of a baseline is immediately after the end of the last baseline. If this is the first baseline in a product, then the baseline starts at the start of the product.
For example, let's say we start a new product. A few days later we create baseline 1. A week later we add baseline 2. Baseline 1 runs from the moment we created the product until the moment we created the baseline. More precisely, baseline 1 runs from the first change ID of the product, to the change ID that the baseline is linked to. Baseline 2 meanwhile runs from the moment baseline 1 was created through to the moment baseline 2 was created.
"},{"location":"Spira-Administration-Guide/Product-General-Settings/#artifacts-changed-in-a-baseline","title":"Artifacts changed in a baseline","text":"To filter and sort the list of artifacts shown in the table, use the filter and sort controls at the top of the table.
This table of artifacts only shows artifacts that changed in the baseline (between when this baseline was created and the previous baseline). Each artifact is only shown once, even if it changed multiple times. The changes that happened to the artifact are combined into a single description so you can easily see a summary of what happened to the artifact during the baseline (for example, was it only modified, or added then modified, or modified then deleted).
This table shows the following information:
This page displays detailed information about the changes made to a specific artifact for a specific baseline. This is a great way to see what happened to an artifact in the baseline.
Information about the artifact at this baseline is divided into 3 sections:
The table of changes is very similar to what you see on the history tab when looking at an artifact. The key difference is that here only a subset of the history is displayed: only those changes that fall within the baseline. All other changes to the artifact are not shown.
This table shows the following columns. You can apply a filter using any of the fields except for Change ID (because this is already filtered to show the key range for the baseline).
The SpiraApps page shows product administrators every SpiraApp currently active in the system, sorted alphabetically1.
For each SpiraApp in the list you see:
Available operations
The SpiraApp Settings page shows any product level settings available for the particular SpiraApp. For more detailed information about each SpiraApp, what they do, and how to work with them refer to the dedicated SpiraApp documentation
If the SpiraApp has no product settings you can still access the page but there will be no settings to edit.
If the SpiraApp has products settings you will see:
Within each group a list of available settings:
Click the \"Save\" button to commit any edits.
SpiraApps are shown even if they will not fully function in your application. For instance, the FMEA SpiraApp is only compatible with SpiraPlan but will still show in the list if you are using SpiraTest or SpiraTeam.\u00a0\u21a9
The Product Administration Home page is accessible to users whose product role includes product admin permission. There are multiple ways to navigate to it:
It provides Product Owners with quick access to important information.
As with other dashboards, you can edit these widgets, their position, and what is shown, using the two buttons in the top right (the cog and the plus).
"},{"location":"Spira-Administration-Guide/Product-Home/#product-overview","title":"Product Overview","text":"This widget displays general information about the product. To edit this information, click \u201cView Details\u201d.
"},{"location":"Spira-Administration-Guide/Product-Home/#product-history-changes","title":"Product History Changes","text":"This widget shows the latest history changes in the product. By default, 5 items are shown, but this number can be changed. To view the complete Product History list, click View All.
"},{"location":"Spira-Administration-Guide/Product-Home/#product-membership","title":"Product Membership","text":"This widget shows a list of product members. By default, 10 users are shown, but this number can be changed. To view the complete Product Membership list and edit it, click View All.
"},{"location":"Spira-Administration-Guide/Product-Home/#components","title":"Components","text":"This widget shows the active components for the product. By default, 5 components are shown, but this number can be changed. To view or edit the complete list of components, click View All.
"},{"location":"Spira-Administration-Guide/Product-Home/#source-code","title":"Source Code","text":"If a source code provider has been set up by a system administrator and is active for the current product, it will be displayed here. Click View Details to configure it.
"},{"location":"Spira-Administration-Guide/Product-Home/#spiraapps","title":"SpiraApps","text":"This widget shows a list of all active SpiraApps at the system level. It shows the SpiraApp icon and name, its system active status (which will always be Yes), and whether or not it is enabled for the product.
"},{"location":"Spira-Administration-Guide/Product-Home/#data-synchronization","title":"Data Synchronization","text":"If any Data Sync plug-ins have been set up by a system administrator, they will be displayed here. Click View Details to see more details and to configure them for the current product.
"},{"location":"Spira-Administration-Guide/Product-Planning/","title":"Product: Planning","text":""},{"location":"Spira-Administration-Guide/Product-Planning/#planning-options","title":"Planning Options","text":"The Planning Options page lets you configure the schedule and calendar options for the various product estimation and planning modules. The settings are specific to each product. The page is divided into a number of collapsible sections.
"},{"location":"Spira-Administration-Guide/Product-Planning/#general","title":"General","text":"Work In Progress (WIP) limits set the maximum number of requirements that the product team can efficiently manage at each stage of their Kanban process. Using WIP limits can be a useful way for teams to manage their work, allowing them to get through their work faster. This is done by focusing only tasks that can be done now (in other words, the work that can in-progress at any one time).
This feature, not available in SpiraTest, is an optional way of using the Planning Board. To not use the feature at all, leave the fields in each of the columns in the table blank.
To make use of WIP limits you need to:
The multipliers and percentages for releases and sprints are independent of one another.
Example WIP Limit
Clicking on the \"Testing Settings\" link brings up a list of options that the administrator can configure regarding testing. Select from the options displayed (as illustrated below) and click \"Save\" to commit the changes.
You can enable or disable the following settings:
Test Case Execution: the following settings affect the test execution rules / experience of all testers in the products
Auto Unassign Tests:
Execute Only From Test Sets: (default = no) when turned on testers will not be able to execute Test Cases. They will only be able to execute Test Sets.
SpiraPlan lets you define a list of Components for each product. These components represent the main functional areas of the system and artifacts can be associated with each of the defined components.
This page lets you display the list of components based on three predefined filters:
From this page you can click on the 'Add Component' option to add a new component in the list:
After entering the name of the new component and choosing its Active status, click on 'Save' to commit the new item. To edit an existing component, edit its name and Active status and click 'Save'. To delete a component, click the 'Delete' option next to its name. Once deleted, an item can be undeleted by changing the display to 'All' and then clicking 'Undelete'.
"},{"location":"Spira-Administration-Guide/Product-Users/","title":"Product: Users","text":""},{"location":"Spira-Administration-Guide/Product-Users/#product-membership","title":"Product Membership","text":"The following page is displayed when you choose the \"Product Membership\" link from the Administration menu:
This page displays the name of the current product together with a list of all the users who are currently members of the product along with their currently assigned product role. If you want to modify the membership for a different product, click the \"Change Product\" button to be taken back to View/Edit Products screen where you can select a different product.
To modify the role of a user assigned to the product, change the role for that user's entry in the drop-down menu and click the \"Save\" button.
To remove a user from the product, check the box to the left of the user's name and click the \"Delete\" button. Note that this only removes them from the product, not the entire system. See the product roles documentation for more information.
To add a user to the product, so that they can access its information, click the \"Add\" button and you will be taken to the following screen that lists all the users in the system that are not currently members of the product:
You now should narrow down the list of users by entering filter criteria and clicking [Filter]; you can also sort the results to make viewing easier. Once you have located the appropriate user(s), just select a product role for them from the drop-down list and click [Add] to add them to the product in the specified role.
"},{"location":"Spira-Administration-Guide/Product-Users/#team-membership","title":"Team Membership","text":"In beta, available in SpiraPlan only
System admins can enable beta functionality across the application for their users from the System Admin > General Settings page.
SpiraPlan lets product admins take teams that have been created at the system level, and assign product members to any active team on a product by product basis. You can use these teams in different ways in different products, but the most common way is to group people together based on your organizational or functional structure.
This page displays the name of the current product and a list of all the users who are currently members of the product (sorted alphabetically by full name). For each product member you can see their:
To change a user's current team, change the selected value in the dropdown. Once all changes to teams are made click \"Save\" to commit the changes.
Only currently active teams are shown. If a user is not in any team (for this product), or in an inactive or deleted team, their team will show as \"-- None --\".
"},{"location":"Spira-Administration-Guide/Program-Capabilities/","title":"Program Capabilities","text":"These features are only available in SpiraPlan
"},{"location":"Spira-Administration-Guide/Program-Capabilities/#statuses","title":"Statuses","text":"The following screen is displayed when you choose the \"Statuses\" link from the Capabilities section of the system administration menu:
The screen displays a list of all the defined statuses in the system. By default, it displays only the active statuses. Display all statuses (active and inactive) by selecting \"All\" from the \"Displaying\" dropdown.
To edit an existing status: change the name, open check-box, set a default status, a position, and/or change the active flag then click \"Save\". Note that:
The following screen is displayed when you choose the \"Types\" link from the Capabilities section of the system administration menu:
The screen displays a list of all the defined types in the system. By default, it displays only the active types. Display all types (active and inactive) by selecting \"All\" from the \"Displaying\" dropdown.
To edit an existing type: change the name, set a default type, and/or change the active flag then click \"Save\". Note that:
The following screen is displayed when you choose the \"Priority\" link from the Capabilities section of the system administration menu:
The screen displays a list of all the defined priorities in the system. By default, it displays only the active priorities. Display all priorities (active and inactive) by selecting \"All\" from the \"Displaying\" dropdown.
To edit an existing type: change the name, color, score, and active flag then click \"Save\". Note that:
Clicking this link from the Capabilities section of the system administration menu will open the system custom properties page for capabilities.
"},{"location":"Spira-Administration-Guide/Program-Milestones/","title":"Program Milestones","text":"These features are only available in SpiraPlan
"},{"location":"Spira-Administration-Guide/Program-Milestones/#statuses","title":"Statuses","text":"The following screen is displayed when you choose the \"Statuses\" link from the Program Milestones section of the system administration menu:
The screen displays a list of all the defined statuses in the system. By default, it displays only the active statuses. Display all statuses (active and inactive) by selecting \"All\" from the \"Displaying\" dropdown.
To edit an existing status: change the name, open check-box, set a default status, a position, and/or change the active flag then click \"Save\". Note that:
The following screen is displayed when you choose the \"Types\" link from the Program Milestones section of the system administration menu:
The screen displays a list of all the defined types in the system. By default, it displays only the active types. Display all types (active and inactive) by selecting \"All\" from the \"Displaying\" dropdown.
To edit an existing type: change the name, set a default type, and/or change the active flag then click \"Save\". Note that:
Clicking this link from the Program Milestones section of the system administration menu will open the system custom properties page for program milestones.
"},{"location":"Spira-Administration-Guide/System-Administration/","title":"System Administration","text":""},{"location":"Spira-Administration-Guide/System-Administration/#introduction","title":"Introduction","text":"Now that you have successfully installed SpiraPlan\u00ae, this section of the guide outlines how to perform the typical administrative tasks necessary for setting up products and programs in the system, managing users and verifying the license information.
"},{"location":"Spira-Administration-Guide/System-Administration/#types-of-administrator","title":"Types of administrator","text":"To perform these tasks, you need to login to the system with a user that has some level of \"administration\" permissions within the system. There are four different sections to administration, and each has its own permission. These sections and their permissions are:
System Administration: tasks like approving new users, creating new products, changing security settings, or viewing the logs all happen at the system-wide level of administration. There is a special \"System Administrator\" flag that can be assigned to any user (by an existing system admin only). Any user that has this flag can perform any system administrator task. Please note that a special \"administrator\" user is created by the installer. You should initially login to SpiraPlan\u00ae with the username administrator, and the password PleaseChange. Change this password as soon as possible to something that is secure yet memorable by clicking on the \"User Profile\" link.
Product Administration: a product admin can make changes specific to that product and that product only. For instance, they can add or remove users from a product. Once a user is made a product admin, they can perform all the actions in the product administration section. Each individual product has a defined set of users who are members of that product. Each member is assigned a specific role (many users can share the same role), and a role can be set to be a product admin. Please note, that when a system admin creates a product, they are automatically added as \"Product Owner\".
Program Administration: just like with products, some aspects of a program are managed in the program section of administration. Anyone who is assigned the role of \"Program Owner\" on a program can perform these administrative functions.
Template Administration: end users of the application will work with products and sometimes programs. However, behind the scenes of every product is a template. This template controls the bulk of how that product is configured and will work for the end users. Each product is controlled by one template, though each template can control many products at once. Making a change to a template in template administration will immediately affect all products controlled by that template. Such changes to a template include changing the name of incident types, changing the colors used to indicate requirement priorities, or changing custom properties. Please note that template admin permissions are managed by the same roles that manage product admin permissions and that apply to members of each product. You can read more about how template admin permissions work here.
Report Administration: a report admin can administer custom reports and graphs (create, edit, delete). They can also access custom report data in 3rd party tools via OData and the API. These functions are also available to system admins under System Administration. However report admins can only access the reporting functions and pages - they have no access to any other admin functions. There is a special \"Report Administrator\" flag that can be assigned to any user (by an existing system admin only). Any user that has this flag can perform any report administrator task.
Once you have logged in as an administrator, you can click the \"Administration\" link which can be found on the right-hand side of the global navigation at the top of any page:
This will display the context aware administration menu popup. This menu will show different sections depending on where you are in the application and your administrative privileges. For example, only system administrators see the \"System: Admin Home\" section shown at the bottom of the screenshot below.
In the screenshot below you can see that administration links are being shown for three different sections:
Library Information System -- which is a product
The template called Sample Template: Agile (this is the template the controls the above product)
System wide administration
This menu only shows the links to one product, one template, or one program at a time (and System Admin all the time to system administrators). Because this user is currently viewing a page in the product 'Library Information System', admin items for that product and its template are visible.
You can see that the \"Requirements\" sub section is highlighted. This is because the user is currently on a requirements page of the 'Library Information System' product (either in the main application or in template administration). The highlighting serves no function other than to guide the user to where they may wish to focus.
Below is an example of an administration menu where a user is a Program Owner but with no other access to administration. This menu is much barer than the one above, because the administrative options this user has are that much more limited. This user only has admin access to Sample Program One. If they navigate to a different program page or to a product page in the application, they would not see the admin menu at all.
If a user wants to see what, if any, parts of the system they have administrative access to, they can do so at any time. Clicking on the workspace dropdown on the global navigation will show them the list of workspaces they have access to. Below, you can see that products are grouped into programs, and there is a dedicated Templates section at the bottom. Any workspace the user has administrative access to has a superscript gray cog to the right of that workspace's name.
If this user wants to access the admin menu for \"Sample Barebones Product\", first that cog tells them they can do so. By clicking on that workspace's name, they will be switched to that workspace and then they can click on the admin button to get the right menu.
In the screenshot above at the top there is a \"System Administration\" workspace. This is visible because this user is a system administrator. Clicking this will take the user directly to the System Administration home page.
The Administration home page, like all admin pages, is divided into two areas:
the skinny left-hand bar. Clicking this will show the context-aware administration menu discussed above
the main pane that displays the available options for the selected page.
This home page shows a number of useful widgets with information about the system. You can edit these widgets, their position, and what is shown, using the two buttons in the top right (the cog and the plus).
Product and Template administration home pages also show useful data and links relevant to them. On most admin pages for products and templates the name of the current product or template is shown at the top of the page in a heading. These names are hyperlinks that will open the product or template administration home page.
When you first install the system, we suggest three main tasks to perform as the system administrator to get familiar with the basics and to help colleagues start to use the application:
These tasks typically need to be performed before any other users can use the system, since there will be no logins or products available other than the sample ones provided during the installation.
Below is the admin menu for a user who is a report administrator but has no other active admin roles. The only menu options available are for custom reports and graphs.
The rest of this guide explores each area of administration in order, grouped by administration section.
"},{"location":"Spira-Administration-Guide/System-Administration/#how-user-permissions-are-set","title":"How user permissions are set","text":"As described above there are 4 different types of administrator. There are also different permission models for accessing the application itself (ie not the administration pages). How do you set each of these permissions so that a user can only see / use what they are supposed to?
Product roles have two special flags. Changing these flags immediately affect anyone with that particular role:
Permissions for programs are more simple and managed on a per program basis:
Each user profile has two special flags about permissions, which affect the entire system, but only for one user at a time (they are completely separate to product and program permissions):
System administrators and product roles
Note: if a user is a System Administrator, it will force that user to always have the 'Product Owner' role on all their assigned products, regardless of the chosen role. If you disable this option, they will then revert back to their true role.*
"},{"location":"Spira-Administration-Guide/System-Custom-Properties/","title":"System Custom Properties","text":"These features are only available in SpiraPlan
Spira allows you to customize different workspaces or program-level artifacts. For each type (e.g. products, program capabilities, or program milestones) you can create up to 30 system custom properties. System custom properties are shared across every relevant workspace or program-level artifact in the system. For example, all products will share the same set of available custom properties; and all capabilities will share a different set of available custom properties. These system custom properties are visible in the following places:
You can create a variety of different types of custom properties. You can create as many custom lists as you need with each having as many values as you need. Custom lists are shared at the system level and available for any custom property to use. This page describes how to setup different custom lists and custom properties for relevant workspaces and artifacts.
"},{"location":"Spira-Administration-Guide/System-Custom-Properties/#edit-custom-properties","title":"Edit Custom Properties","text":"To access the custom properties definitions for a specific workspace or artifact, you must be a system administrator. Open the system admin menu and click the relevant link, either in the \"Custom Properties\" or relevant artifact sub-section of the menu. This opens the custom properties page for that workspace or artifact where you can quickly see the name, field number, type, and actions (edit and delete) for each custom property.
In the example below we see 7 custom properties defined for products. The custom properties page has rows for each available custom property.
To edit an existing custom property definition click the \"Edit Definition\" button for that specific property. To add a new definition click the \"Add Definition\" button. In either case the following dialog will be displayed:
For each custom property you set the following fields on the main definition tab:
Different types of custom properties supported:
Each custom property can have optional settings applied to it to further control the custom property. Note: not all settings are available for all property types. These settings are on the Options tab of the dialog:
When finished, click the Save button.
Renaming or Removing Custom Properties
When changing a custom property's type or removing a custom property, the data is not actually removed from the workspace or artifact. Therefore, if you change a custom property from a date type to a text custom property, the field may display the old date value until it is changed by the user.
"},{"location":"Spira-Administration-Guide/System-Custom-Properties/#edit-custom-lists","title":"Edit Custom Lists","text":"If you are planning on having any list-based custom properties at the system level, you need to create and populate the system custom lists that the user will be able to select from. These lists are stored separately from the individual custom property definitions so that you can have one set of values (e.g. list of operating systems under test) be reused by multiple custom properties.
The following screen is displayed when you choose the \"Custom Lists\" link from the Administration menu:
The screen displays all the system level custom lists currently defined, together with the number of values associated with each list. By default the screen will initially be empty so the first thing you need to do is click \"Add List\" to create a new custom list:
After changing the name of the list, and specifying whether the values will be ordered by their name or the order in which they were entered (called by ID), you can either click \"Save\" to commit the change, or click the \"Add Value\" option to add some list values:
This is the set of values that the user will select from the drop-down list when the custom property is displayed. You can change the display to include:
To add a new custom list value, click the \"Add Value\" button and a new row will be added to the list which you can now edit. To edit an existing custom list value, change the name in the textbox and click \"Save\". To delete a custom list value, click on the \"Delete\" hyperlink. If you want to remove an item from the list temporarily, you can set its Active dropdown list to 'No', if you want to remove an item permanently, just click the 'Delete' button.
To edit an existing custom list, click the \"Edit Values\" button to display the custom list name and list of associated values (which is the same screen as the one displayed for a new list). To remove a custom list from the template, just click on the \"Remove\" button next to the custom list and the list and all its associated values will be deleted from the template.
Recovering deleted list values
If you delete a custom list value, there is an option to undelete by changing the display selection to \"All\" and clicking the 'Undelete' button next to a deleted value.
"},{"location":"Spira-Administration-Guide/System-Home/","title":"System: Home Page","text":"The System Administration Home page is only accessible to users with the special \"System Administrator\" flag on their profile. There are multiple ways to navigate to it:
It provides system administrators with quick access to important information.
As with other dashboards, you can edit these widgets, their position, and what is shown, using the two buttons in the top right (the cog and the plus).
"},{"location":"Spira-Administration-Guide/System-Home/#system-information","title":"System Information","text":"The system information widget displays an overview of your Spira instance, including license information and the number of currently-active users, as well as links to detailed information.
"},{"location":"Spira-Administration-Guide/System-Home/#manage-sample-data","title":"Manage Sample Data","text":"On fresh installations that include the sample data that ships with the application there is a button on this widget to direct you to the admin page to set and manage sample data. This can be helpful if want to start with a clean slate following a trial and not have the sample data cluttering your system.
"},{"location":"Spira-Administration-Guide/System-Home/#event-log","title":"Event Log","text":"This widget shows the latest events from the system event log. By default, 5 events are shown, but this number can be changed. To view the complete event log, click View All.
"},{"location":"Spira-Administration-Guide/System-Home/#pending-user-requests","title":"Pending User Requests","text":"If you have enabled the ability for users to register for new SpiraPlan accounts themselves, any pending requests will be listed here. To accept or deny the requests, click View All. By default the list is limited to 5. This number can be adjusted.
"},{"location":"Spira-Administration-Guide/System-Home/#data-synchronization","title":"Data Synchronization","text":"This widget shows a list of active data-synchronization services, together with the status and date/time of the last synchronization.
"},{"location":"Spira-Administration-Guide/System-Integration/","title":"System: Integration","text":""},{"location":"Spira-Administration-Guide/System-Integration/#data-synchronization","title":"Data Synchronization","text":"SpiraPlan\u00ae is capable of synchronizing its data with a variety of other systems, including but not limited to requirements management systems and standalone bug-tracking tools. The various integration plug-ins for SpiraPlan\u00ae and the steps for configuring the data-synchronization settings are described in the SpiraTest External Bug-Tracking Integration Guide. Each individual tool has its own separate guide that builds on this setup guide.
If you are synchronizing data between SpiraPlan and one of these other systems, the 'Data Synchronization' administration page will show a list of available data-synchronizations services:
In the example above, we have six plug-ins available, with only Azure DevOps (ADO) active. For ADO, the data sync is active for a single product: Library Information System (Sample).
This table shows the following information about each data sync plug-in:
operations you can perform on each data sync.
Above the table you can add a new data sync or refresh the status of the page to ensure that you are seeing the most up to date information.
"},{"location":"Spira-Administration-Guide/System-Integration/#source-code-integration","title":"Source Code Integration","text":"This section refers to the functionality available to on-premise customers of SpiraPlan or those customers that have disabled TaraVault. If you are using the cloud / hosted version of SpiraPlan and have not disabled TaraVault, please refer to TaraVault Configuration instead.
SpiraPlan\u00ae is capable of integrating with a variety of source code / Software Configuration Management (SCM) tools such as Git, Subversion, CVS and TFS. This allows you to browse the source code repositories using the SpiraPlan web interface, and more importantly link commits in these tools to artifacts in SpiraPlan. This provides the end-to-end traceability from code commits/check-ins to the tasks, incidents and requirements that necessitated the code change.
The information on using the various source code providers for SpiraPlan\u00ae and the steps for configuring the provider-specific settings are described elsewhere - for example for Git.
To configure a source code provider, you need to click on the System Administration > Integration > Source Code link in the Administration navigation to bring up the list of configured source code providers:
By default the only provider listed will be the TestVersionControlProvider which is used for demonstration purposes only, and can be deleted from a production system by clicking on the \"Delete\" button to the right of it.
To edit the system wide settings for an existing source code provider, click on the \"Edit\" button on the far right of the row for that provider. You can edit the same settings that were shown above when you first created that provider.
If you want to change the settings for a particular product (including to turn that provider on or off for the product):
To add a new source code provider, click the \"Add\" button at the bottom to go to the Plug-in details page:
When finished, click the \"Insert\" button and you will be taken back to the Source Code integration list page, with new provider listed as an available plug-in:
"},{"location":"Spira-Administration-Guide/System-Integration/#test-automation","title":"Test Automation","text":"SpiraPlan\u00ae can be used to manage the development, scheduling and execution of automated unit, functional and load tests written using a variety of test automation engines (e.g. HP QuickTest Pro, SmarteScript, TestComplete, etc.). This section allows you to configure the different engines that are available in your environment so that the testers know which tools they can use to schedule tests with.
The information on using the various test automation engines for SpiraPlan\u00ae and the steps for configuring the engine-specific settings are described in the SpiraTest/Team RemoteLaunch Automated Testing Integration Guide.
To configure a test automation engine, you need to click on the Administration > Integration > Test Automation link in the Administration navigation to bring up the list of configured test automation engines:
To add a new test automation engine, click the \"Add\" button to enter the Automation Engine details page. The fields required are as follows:
Name: The name of the test automation engine that you're adding. This can be set to any name of your choice that would make sense to your users.
Description: The description is used for any comments or additional information that you need to use to describe the automation engine.
Active: If checked, the automation engine is active and able to be used in any product.
Token: This needs to match the name of the Automation Engine DLL file that you're using (see the SpiraTest/Team Automated Testing Integration Guide for more details on your specific tool) for the specific automation engine.
When finished, click the \"Insert\" button and you will be taken back to the test automation engine list page, with new automation engine listed.
To edit the settings for an existing test automation engine, just click on the \"Edit\" link next to the name of the engine and you will be able to edit the same settings that were shown above when you first created it.
Once you have made the appropriate changes, click the [Save] button to commit them.
You are now ready to use SpiraPlan\u00ae in conjunction with the test automation engine you added. For details on how to use the test automation features of SpiraPlan, please refer to the SpiraPlan\u00ae User Manual.
"},{"location":"Spira-Administration-Guide/System-Integration/#floating-licenses","title":"Floating Licenses","text":"Cloud users of SpiraPlan who have a floating license subscription addon to your SpiraPlan will see a \"Floating Licenses\" section in the Integrations section of the system administration menu. For example, if you have Rapise floating licenses, you will see this menu item and page.
Read more about how to purchase and use Rapise floating licenses.
When you go to the Floating Licenses page you will see how many floating licenses are available as well as how many are currently in use (initially the list will be empty):
Once you have floating licenses available, when you connect, for example, Rapise to Spira, Rapise automatically requests a floating license from Spira. The application will use that license until Rapise is closed or a SpiraPlan administrator clicks the End Session button in SpiraPlan.
The floating licenses page will show how many licenses are available and information about each currently active session. A system admin can end a session at any time by clicking the \"End Session\" button on a specific session.
"},{"location":"Spira-Administration-Guide/System-Reporting/","title":"System: Reporting","text":"SpiraPlan has a powerful set of reports and charts available out of the box that cover most product's needs. However, there is often a need to be able to generate custom reports and graphs that are specific to your organization. In this section, you can create custom graphs and reports for your users to use.
"},{"location":"Spira-Administration-Guide/System-Reporting/#edit-reports","title":"Edit Reports","text":"The \"Edit Reports\" administration page lets you create custom reports in the system that your users can run in the various products they have access to. Note that the report definitions themselves are global to the system and therefore available in all products.
The list of report definitions contains both the standard (default) reports that ship with the system and any custom reports that you have defined. However, any of the reports listed with the \"Default\" option checked will not be editable. So, if you want to modify one of the built-in reports to make it better suit your needs, you should instead click on the \"Clone\" button next to the report and make a copy of the report that you can then modify. You can view any of the default reports by clicking on the associated \"View\" button.
To edit an existing non-default report, click on the \"Edit\" button. To add a new report from scratch, click on the \"Add New Report\" option at the bottom of the list. Either of these will take you to the Report editing screen:
The top-half of this screen (illustrated above) lets you specify the name of the report, the long description (displayed in tooltips but not in the report itself) and a rich-text footer and header. The header and footer will be displayed at the top and bottom of the generated report.
In addition, you can specify whether the report is active (and therefore can be used in the SpiraPlan reports center) and which report category heading the report will appear in. This is also used to determine which role(s) are able to run the report (e.g. a user that has permissions to view requirements will be able to run all reports listed under the \"Requirement Reports\" category).
The lower-half of the screen displays the list of formats, standard sections and custom sections that make up the report:
The list of formats is fixed in the system, you can simply choose which formats this specific report will be available in. The reporting engine will take care of converting your report into the target format, you just need to specify which type(s) are applicable.
a) Standard Sections
The list of standard sections contains a list of the various pre-defined report sections that are to be included in the report. A standard section consists of a set of nested queries and embedded elements that will return back data. For example, the \"Requirements Details\" section consists of a list of all the requirements in a product, together with the associated test cases, tasks, custom properties, attachments, discussions, change history, source code commits, and other related items.
With a standard section, you cannot change the underlying data query, but you can change the header, footer and XSLT template used to format the results:
When you either click on \"Add New Standard Section\" or the \"Customize\" link next to an existing standard section, the popup dialog illustrated above will be displayed. On this page you can change the following fields:
Name -- Choose the name of the standard report section you want to use from the dropdown list. Changing the name of the section will automatically update the Description field below.
Description -- This is the description of the report section, it is not displayed in the final report.
Header -- This is the header that will be displayed before the dynamic data retrieved as part of the report section. You can enter in formatted rich text in this field.
Footer -- This is the footer that will be displayed after the dynamic data retrieved as part of the report section. You can enter in formatted rich text in this field.
Template -- This is the eXtensible Markup Language Stylesheet Transform (XSLT) used to transform the raw XML data from the report query into the final HTML display format. When you choose/change the name dropdown list, clicking on the \"Create Default Template\" will populate this field with the default template used to render the data.
When you first create a new standard report section, we recommend using the option to \"Create Default Template\". This will then allow you to run the report in the main reports center and have all the available data fields displayed in the standard format. If you would like to customize the content of the section, you have several options:
Customize Header/Footer -- if you want to keep the data and layout as-is, you can simply add a custom header and footer to add organization specific information into the report.
Customize the Data/Layout -- if you want to customize how the data is displayed and formatted, you will need to edit the XSLT Template. You can learn more about XSLT at W3Schools. However, the recommended approach is to first run the \"Raw XML\" format report from the main SpiraPlan reports center. An example XML report is partially shown below:
\u201c?xml version=\"1.0\" encoding=\"UTF-8\" standalone=\"yes\"?\u201d\n\u201cReport\u201d\n \u201cTitle\u201d\n Requirements Detailed Report\n \u201c/Title\u201d\n \u201cProductData\u201d\n \u201cProduct\u201d\n \u201cProjectId\u201d1\u201d/ProjectId\u201d\n \u201cProjectGroupId\u201d2\u201d/ProjectGroupId\u201d\n \u201cName\u201dLibrary Information System\u201d/Name\u201d\n \u201cDescription\u201dSample application that allows users to manage books, authors and lending records for a typical branch library\u201d/Description\u201d\n \u201cWebsite\u201dwww.libraryinformationsystem.org\u201d/Website\u201d\n \u201cCreationDate\u201d2005-11-30T19:00:00\u201d/CreationDate\u201d\n \u201cActiveYn\u201dY\u201d/ActiveYn\u201d\n \u201cWorkingHours\u201d8\u201d/WorkingHours\u201d\n \u201cWorkingDays\u201d5\u201d/WorkingDays\u201d\n \u201cNonWorkingHours\u201d0\u201d/NonWorkingHours\u201d\n \u201cTimeTrackIncidentsYn\u201dY\u201d/TimeTrackIncidentsYn\u201d\n \u201cTimeTrackTasksYn\u201dY\u201d/TimeTrackTasksYn\u201d\n \u201cEffortIncidentsYn\u201dY\u201d/EffortIncidentsYn\u201d\n \u201cEffortTasksYn\u201dY\u201d/EffortTasksYn\u201d\n \u201cTasksAutoCreateYn\u201dY\u201d/TasksAutoCreateYn\u201d\n \u201cReqDefaultEffort\u201d480\u201d/ReqDefaultEffort\u201d\n \u201cTaskDefaultEffort\u201d360\u201d/TaskDefaultEffort\u201d\n \u201cProductGroupName\u201dInternal Products\u201d/ProductGroupName\u201d\n \u201c/Product\u201d\n \u201c/ProductData\u201d\n \u201cRequirementData\u201d\n \u201cRequirement\u201d\n \u201cRequirementId\u201d1\u201d/RequirementId\u201d\n \u201cProjectId\u201d1\u201d/ProjectId\u201d\n \u201cScopeLevelId\u201d3\u201d/ScopeLevelId\u201d\n \u201cAuthorId\u201d2\u201d/AuthorId\u201d\n \u201cName\u201dFunctional System Requirements\u201d/Name\u201d\n \u201cCreationDate\u201d2003-11-30T19:00:00\u201d/CreationDate\u201d\n \u201cLastUpdateDate\u201d2003-11-30T19:00:00\u201d/LastUpdateDate\u201d\n \u201cIndentLevel\u201dAAA\u201d/IndentLevel\u201d\n \u201cExpandedYn\u201dY\u201d/ExpandedYn\u201d\n \u201cVisibleYn\u201dY\u201d/VisibleYn\u201d\n \u201cSummaryYn\u201dY\u201d/SummaryYn\u201d\n \u201cAttachmentsYn\u201dN\u201d/AttachmentsYn\u201d\n \u201cCoverageCountTotal\u201d21\u201d/CoverageCountTotal\u201d\n \u201cCoverageCountPassed\u201d10\u201d/CoverageCountPassed\u201d\n \u201cCoverageCountFailed\u201d3\u201d/CoverageCountFailed\u201d\n \u201cCoverageCountCaution\u201d1\u201d/CoverageCountCaution\u201d\n \u201cCoverageCountBlocked\u201d1\u201d/CoverageCountBlocked\u201d\n \u201cPlannedEffort\u201d8700\u201d/PlannedEffort\u201d\n \u201cTaskEstimatedEffort\u201d11400\u201d/TaskEstimatedEffort\u201d\n \u201cTaskActualEffort\u201d7570\u201d/TaskActualEffort\u201d\n \u201cTaskProjectedEffort\u201d3855\u201d/TaskProjectedEffort\u201d\n \u201cTaskRemainingEffort\u201d11485\u201d/TaskRemainingEffort\u201d\n \u201cTaskCount\u201d42\u201d/TaskCount\u201d\n \u201cTaskPercentOnTime\u201d59\u201d/TaskPercentOnTime\u201d\n \u201cTaskPercentLateFinish\u201d6\u201d/TaskPercentLateFinish\u201d\n \u201cTaskPercentNotStart\u201d7\u201d/TaskPercentNotStart\u201d\n \u201cTaskPercentLateStart\u201d28\u201d/TaskPercentLateStart\u201d\n \u201cScopeLevelName\u201dIn Progress\u201d/ScopeLevelName\u201d\n \u201cAuthorName\u201dFred Bloggs\u201d/AuthorName\u201d\n \u201cHasDiscussionChanged\u201dfalse\u201d/HasDiscussionChanged\u201d\n \u201cIsDeleted\u201dfalse\u201d/IsDeleted\u201d\n \u201cCustomProperties\u201d\n \u201cCustomProperty\u201d\n \u201cAlias\u201dURL\u201d/Alias\u201d\n \u201cName\u201dCustom_01\u201d/Name\u201d\n \u201cType\u201dText\u201d/Type\u201d\n \u201c/CustomProperty\u201d\n \u201cCustomProperty\u201d\n \u201cAlias\u201dDifficulty\u201d/Alias\u201d\n \u201cName\u201dCustom_02\u201d/Name\u201d\n \u201cType\u201dList\u201d/Type\u201d\n \u201c/CustomProperty\u201d\n \u201cCustomProperty\u201d\n \u201cAlias\u201dRequirement Type\u201d/Alias\u201d\n \u201cName\u201dCustom_03\u201d/Name\u201d\n \u201cType\u201dList\u201d/Type\u201d\n \u201c/CustomProperty\u201d\n \u201cCustomProperty\u201d\n \u201cAlias\u201dNotes\u201d/Alias\u201d\n \u201cName\u201dCustom_04\u201d/Name\u201d\n \u201cType\u201dText\u201d/Type\u201d\n \u201c/CustomProperty\u201d\n \u201cCustomProperty\u201d\n \u201cAlias\u201dReview Date\u201d/Alias\u201d\n \u201cName\u201dCustom_05\u201d/Name\u201d\n \u201cType\u201dDate\u201d/Type\u201d\n \u201c/CustomProperty\u201d\n \u201cCustomProperty\u201d\n \u201cAlias\u201dDecimal\u201d/Alias\u201d\n \u201cName\u201dCustom_06\u201d/Name\u201d\n \u201cType\u201dDecimal\u201d/Type\u201d\n \u201c/CustomProperty\u201d\n \u201c/CustomProperties\u201d\n \u201cDiscussions /\u201d\n \u201cTestCases /\u201d\n \u201cTasks /\u201d\n \u201cAttachments /\u201d\n \u201cHistory\u201d\n \u201cHistoryChangeSetType\u201d\n \u201cChangeTypeId\u201d1\u201d/ChangeTypeId\u201d\n \u201cChangeTypeName\u201dModified\u201d/ChangeTypeName\u201d\n \u201c/HistoryChangeSetType\u201d\n \u201cHistoryChangeSetType\u201d\n \u201cChangeTypeId\u201d2\u201d/ChangeTypeId\u201d\n \u201cChangeTypeName\u201dDeleted\u201d/ChangeTypeName\u201d\n \u201c/HistoryChangeSetType\u201d\n \u201cHistoryChangeSetType\u201d\n \u201cChangeTypeId\u201d3\u201d/ChangeTypeId\u201d\n \u201cChangeTypeName\u201dAdded\u201d/ChangeTypeName\u201d\n \u201c/HistoryChangeSetType\u201d\n \u201cHistoryChangeSetType\u201d\n \u201cChangeTypeId\u201d4\u201d/ChangeTypeId\u201d\n \u201cChangeTypeName\u201dPurged\u201d/ChangeTypeName\u201d\n \u201c/HistoryChangeSetType\u201d\n \u201cHistoryChangeSetType\u201d\n \u201cChangeTypeId\u201d5\u201d/ChangeTypeId\u201d\n \u201cChangeTypeName\u201dRollback\u201d/ChangeTypeName\u201d\n \u201c/HistoryChangeSetType\u201d\n \u201cHistoryChangeSetType\u201d\n \u201cChangeTypeId\u201d6\u201d/ChangeTypeId\u201d\n \u201cChangeTypeName\u201dUndelete\u201d/ChangeTypeName\u201d\n \u201c/HistoryChangeSetType\u201d\n \u201cHistoryChangeSetType\u201d\n \u201cChangeTypeId\u201d7\u201d/ChangeTypeId\u201d\n \u201cChangeTypeName\u201dImported\u201d/ChangeTypeName\u201d\n \u201c/HistoryChangeSetType\u201d\n \u201cHistoryChangeSetType\u201d\n \u201cChangeTypeId\u201d8\u201d/ChangeTypeId\u201d\n \u201cChangeTypeName\u201dExported\u201d/ChangeTypeName\u201d\n \u201c/HistoryChangeSetType\u201d\n \u201c/History\u201d\n \u201cRequirements /\u201d\n \u201cIncidents /\u201d\n \u201cSourceCodeRevisions /\u201d\n \u201c/Requirement\u201d\n \u201c/RequirementData\u201d\n\u201c/Report\u201d\nThis XML data is then converted by the XSLT template into HTML format so that it can be included into the final generated report. An example fragment of the XSLT template looks like:
\u201c?xml version=\"1.0\" encoding=\"utf-8\"?\u201d\n\u201cxsl:stylesheet version=\"1.0\" xmlns:xsl=\"http://www.w3.org/1999/XSL/Transform\" xmlns:msxsl=\"urn:schemas-microsoft-com:xslt\" exclude-result-prefixes=\"msxsl\"\u201c\n \u201cxsl:template match=\"/RequirementData\"\u201c\n \u201cxsl:for-each select=\"Requirement\"\u201c\n \u201cdiv\u201d\n \u201cxsl:attribute name=\"style\"\u201c\n padding-left: \u201cxsl:value-of select=\"string-length(IndentLevel)*2\"/\u201dpx;\n \u201c/xsl:attribute\u201d\n \u201cxsl:if test=\"SummaryYn='Y'\"\u201c\n \u201cdiv class=\"Title2\"\u201c\n RQ:\u201dxsl:value-of select=\"RequirementId\"/\u201d - \u201cxsl:value-of select=\"Name\"/\u201d\n \u201c/div\u201d\n \u201cdiv class=\"Description\"\u201c\n \u201cxsl:value-of select=\"Description\" disable-output-escaping=\"yes\"/\u201d\n \u201c/div\u201d\n \u201cbr /\u201d\n \u201c/xsl:if\u201d\n \u201cxsl:if test=\"SummaryYn='N'\"\u201c\n \u201cxsl:attribute name=\"style\"\u201c\n padding-left: \u201cxsl:value-of select=\"string-length(IndentLevel)*2\"/\u201dpx;\n \u201c/xsl:attribute\u201d\n \u201cdiv class=\"Title3\"\u201c\n RQ:\u201dxsl:value-of select=\"RequirementId\"/\u201d - \u201cxsl:value-of select=\"Name\"/\u201d\n \u201c/div\u201d\n \u201cp\u201d\n \u201cxsl:value-of select=\"Description\" disable-output-escaping=\"yes\"/\u201d\n \u201c/p\u201d\n \u201c/xsl:if\u201d\n \u201c/div\u201d\n \u201c/xsl:for-each\u201d\n \u201c/xsl:template\u201d\nSo using a combination of XSLT and the Raw XML report format, you can generate a customized view of the standard report section that will be included in the final report.
Sometimes, however you want to be able to create a completely custom report that includes customized data as well as a custom format. In which case you need to use a custom report section instead.
b) Custom Section
Back on the main report details page, if you click on \"Add New Custom Section\", the following dialog box will be displayed:
On this page you can enter / change the following fields:
Name -- Enter the name of the new custom report section that you will be adding to the report. This is not displayed in the final report
Description -- This is the description of the custom section, it is not displayed in the final report.
Header -- This is the header that will be displayed before the dynamic data retrieved as part of the report section. You can enter in formatted rich text in this field.
Footer -- This is the footer that will be displayed after the dynamic data retrieved as part of the report section. You can enter in formatted rich text in this field.
Active -- You should make sure this checkbox is checked if you want the custom section to appear in the final report.
Further down on the page you can actually enter the custom query and associated XSLT template:
On this page you need to first choose the appropriate reportable entity from the dropdown list. In the example illustrated above, we have selected the \"Requirements\" reportable entity. This will automatically populate the following query in the Query editor:
select value R from SpiraTestEntities.R_Requirements as R where R.PROJECT_ID = ${ProjectId}
This query tells SpiraPlan to select all of the rows in the R_Requirements collection that are in the current product and include all of the columns in the final report. This generally will result in more columns than is desirable, so you should click on the \"Preview Results\" option to view a list of the various columns and the sample data. That will help you decide which columns are important for your report. You can then adjust the query to only include those columns:
select R.REQUIREMENT_ID, R.NAME from SpiraTestEntities.R_Requirements as R where R.PROJECT_ID = ${ProjectId}
In this modified query, we have replaced the keyword value with the specific column names. When you use the \"Preview Results\" option on this query, you will only see the two desired columns:
Once you have verified that the data being returned matches your requirements, click on the \"Create Default Template\" option and SpiraPlan will automatically generate a new XSLT template that displays just these columns in a nice table format:
You can now click the [Save] button to save your changes to the report.
You may have noticed that we had a special token in the query {ProjectId}**, this token will be evaluated during the generation of the report and ensures that only items in the current product are included. If you want to include all the items in a specific Program, you should instead use the token **. If you don't use either token, the report will include all the items in the entire system, across all products and groups.
For example:
select value R from SpiraTestEntities.R_Requirements as R where R.PROJECT_ID = ${ProjectId} will display all the requirements in the specific product
select value R from SpiraTestEntities.R_Requirements as R where R.PROJECT_GROUP_ID = ${ProjectGroupId} will display all the requirements in the specific program
select value R from SpiraTestEntities.R_Requirements as R will display all the requirements in the entire system
For more information on creating custom report queries, please refer to the knowledge base articles on the Inflectra customer support website: http://www.inflectra.com/Support.
Warning: If you create a report that doesn't have either ${ProjectId} or ${ProjectGroupId} in the WHERE clause you could end up displaying data to a user that shouldn't have permission to see that data.
"},{"location":"Spira-Administration-Guide/System-Reporting/#edit-graphs","title":"Edit Graphs","text":"The \"Edit Graphs\" administration page lets you create custom graphs and charts in the system that your users can run in the various products they have access to. Note that the graph definitions themselves are global to the system and therefore available in all products.
When you click on the 'Edit Graphs' menu option, the system will display a list of any existing custom graphs that have been already defined (it will not list the standard graphs that come with the system):
To add a new graph, click on the 'Add New Custom Graph' option in the bottom of the table:
This is the same screen you will see if you click on the Edit button for an existing graph. In addition, the graph list page has the following additional operations:
Clone -- this will make a copy of the graph with '- Copy' appended to the name
Delete -- this will permanently delete the selected custom graph.
On the graph editing page, you can enter the following fields:
Name -- This is the short name of the graph that will be displayed to users when they choose to display a custom graph.
Description -- This is the longer description of the graph, and should be used to explain what the data in the graph shows, what the purpose of the graph is and how the data should be interpreted. This is what the user will see when they click on the help link on the graph.
Active -- If you set this to \"No\", the graph will not be accessible by end users
Position -- use this to specify the relative position of the graph in the list of custom graphs.
Query -- this is where you enter the actual query used to generate the graph data. We shall discuss this below.
Entering the Query
We recommend that you first choose the appropriate reportable entity from the dropdown list. In the example illustrated above, we have selected the \"Test Runs\" reportable entity.
This will automatically populate the following query in the Query editor:
select value R from SpiraTestEntities.R_TestRuns as R where R.PROJECT_ID = ${ProjectId}
This query tells SpiraPlan to select all of the rows in the R_TestRuns collection that are in the current product and include all of the columns in the final report. You cannot graph non-numeric columns, so usually we'd recommend clicking Display Data Grid to see all of the columns that you can use in the graph:
This will help you decide which columns are important for your graph. You can then adjust the query to only include those columns:
select R.EXECUTION_STATUS_NAME, COUNT (R.TEST_RUN_ID) as COUNT
from SpiraTestEntities.R_TestRuns as R
where R.PROJECT_ID = ${ProjectId}
group by R.EXECUTION_STATUS_NAME
In this modified query, we have replaced the keyword value with the specific column names. We have also added an aggregation function called COUNT to count the number of test runs and group by the execution status name column. SpiraPlan uses a modified SQL language called Entity SQL. For more information on creating custom graph queries, please refer to the knowledge base articles on the Inflectra customer support website: http://www.inflectra.com/Support.
When you click Display Data Grid, you will now see:
The graphing module requires that the first column be the list of categories to display on the x-axis of the graph. It can be any format (text, numeric, dates, etc.). The remaining columns have to be numeric and will be used to display the different data ranges. The column name will be used to display the data range. For donut graphs, only one data range is supported, for line/bar charts, you can have multiple ranges.
You can see how the graph looks in the three different styles (donuts, bar, line):
a) Donut Graph
b) Bar Graph
c) Line Graph
Once you are happy with your custom graph, click the Save button to commit the changes. If the Active flag is set to \"Yes\" then the graph will be available for end users to use.
Warning: If you create a graph that doesn't have either ${ProjectId} or ${ProjectGroupId} in the WHERE clause you could end up displaying data to a user that shouldn't have permission to see that data.
"},{"location":"Spira-Administration-Guide/System-Users/","title":"System: Users","text":""},{"location":"Spira-Administration-Guide/System-Users/#view-edit-users","title":"View / Edit Users","text":"The following screen is displayed when you choose the \"View/Edit Users\" link from the Administration menu:
This screen displays the list of all approved users in the system (by default it only shows active users, but you can use the dropdown at the top to view inactive or all users). It shows the following fields:
You can filter the list using the filter row above. When you click the \"Filter\" button, the list of users will be filtered by the criteria you entered. You can clear the filter selection by clicking the \"Clear Filters\" button. To sort the list of users, click on the appropriate arrow icon located in the header row of each field (one each for ascending / descending). In addition, the list of users is paginated into groups of fifteen (15). You can step through the different pages by clicking the page numbers at the bottom of the user list.
Why can't I find a user?
The user list shows all approved users. So if you are looking for a user that you think should exist but they are not in this list, then they are not approved. Check the list of pending user requests to see if the user is there waiting to be approved.
"},{"location":"Spira-Administration-Guide/System-Users/#add-a-new-user","title":"Add a new user","text":"To add a new user to the system, click the \"Add\" button at the bottom of the user list, and a new screen will be displayed that allows you to enter the new user information:
On this screen, you can:
System administrators and product roles
Note: if a user is a System Administrator, that user will always have the 'Product Owner' role on all their assigned products, regardless of the chosen role. If they stop being a system admin, they will then revert back to their true role.
When creating a new user, you can also set their role for products. A user can be assigned a role to multiple products at once, by checking the required checkboxes in the dropdown list of products. The same role will be applied across all products.
Notifying Newly Created Users
The new user created as above will get an email with the subject \"New Spira Account\". The email contains the new user's assigned username and password, along with the login URL.
"},{"location":"Spira-Administration-Guide/System-Users/#edit-an-existing-user","title":"Edit an existing user","text":"In a similar way, to edit the details of an existing user, click the \"Edit\" hyperlink in the user list box, and you will be taken to the following screen that allows you modify the user details:
On this screen you can edit key information and security about the user:
If your Spira accounts are managed by an external LDAP directory server, you can edit a user's LDAP information on this page. In LDAP-Managed mode you enter the fully Distinguished Name (DN) for that user in your corporate LDAP server and provide no password. SpiraPlan\u00ae will then query your corporate LDAP server for the password information, reducing the number of passwords that a user needs to remember. Please see the sections on Importing LDAP Users and LDAP Configuration for more details.
If a user's account uses an external provider for authentication (like LDAP or Okta) you can unlink the user from that authentication provider on this page. Click the Unlink Account button to display a popup that requires you to add the new security information for that user.
Once you have made the necessary changes, click the \"Save\" button to commit them. If you decide that you want to ignore the changes, click the \"Cancel\" button and the changes will be discarded.
At the top of the page you can also see information relating to the activity of the user on the system, such as when they last logged in.
In addition, there are three tabs that allow you to: - add/remove the user from products - update the data-mapping used when synchronizing artifacts that are assigned or created by the current user - where relevant, specify whether the user can access the linked TaraVault\u2122 source code management service
If you click on the \"Product Membership\" tab you will be shown a list of products that the user is currently a member of:
You can change the role that the user has on the various products, by choosing the appropriate role from the drop-down list and then clicking [Save]. To remove the user from a product, select its checkbox and then click [Delete]. To add a user to a new product, click on the [Add] button and then choose the product and associated role from the list of products on the screen that is displayed:
Then click [Add] to add the selected product(s) to the user's product membership.
To view/change the list of usernames that a user has in an external bug-tracking system, click on the \"Data Mapping\" tab. This section is used by the SpiraPlan data-synchronization service to map incidents from SpiraPlan to other bug-tracking systems
Please see the SpiraPlan External Bug-Tracking Integration Guide for more details on using the data-mapping tab.
If you click on the TaraVault membership tab, you can choose whether or not the user has access the linked TaraVault source code repository. This service is only available for hosted/cloud instances of SpiraPlan, and more details can be found in LDAP Configuration.
"},{"location":"Spira-Administration-Guide/System-Users/#importing-ldap-users","title":"Importing LDAP Users","text":"If your organization already has an LDAP compatible user management system in place (e.g. Windows Active Directory, Novell eDirectory, OpenLDAP, IBM Tivoli, etc.), then instead of having to manually enter users one by one into SpiraPlan\u00ae, you can simply import them from your LDAP Server. Before doing this however, you need to first setup the LDAP Configuration.
Once you have setup your LDAP server configuration in SpiraPlan\u00ae, clicking on the \"Import Users From and LDAP Server\" will bring up the following screen:
This screen lists all the users available in the LDAP server that have not been already imported into SpiraPlan\u00ae. The users are listed by name along with their login, email address and fully distinguished LDAP name (DN). You can narrow down the list by entering partial name matches in any of the fields displayed and clicking [Filter] and/or you can sort the results by clicking on the directional arrows in the field headings.
Select the checkbox of any users you want to import and click \"Import\" to complete the operation. These users can now login to SpiraPlan\u00ae and use their existing LDAP login and password information.
"},{"location":"Spira-Administration-Guide/System-Users/#login-providers","title":"Login Providers","text":"You can connect your organization's identity provider for Single Sign On (SSO) authentication with Spira. This works for both on premise and cloud versions of the application. We currently support integration with:
On the Provider List page you can see a list of all available providers, their status (active or inactive), and how many, if any, users are logging in to the application using that provider. To configure a particular provide, click the \"Edit\" button for that row.
On the provider details page you can set a provider to active or inactive. Different providers have different required fields. For your provider, make sure to fill in the required fields with the specific information that the provider generates for you. Every provider needs at least a client id and client secret. For users to be able to login using the provider make sure to set the provider to active and hit Save. This will make sure that the right button shows up on the login screen.
Note that you can only deactivate a provider that does not have any users linked to it.
Once you have setup a login provider, users will see a button for that provider on the Spira login page:
"},{"location":"Spira-Administration-Guide/System-Users/#how-to-set-up-a-provider-to-integrate-with-spira","title":"How to set up a provider to integrate with Spira","text":"Below is a general set of instructions about how to set up the provider and Spira to work together. However, the providers may have changed their process or documentation, so please consult the provider about configuring their system.
Create a new application / OAuth access with the provider
https://inflectra.spiraservice.netA guide to set up each provider, and the specific permissions they each need are available here:
Go back to Spira and enter the information for the required fields into the provider page and hit save.
Before rolling out the provider to your users be aware that the provider likely communicates to your Spira application over the internet so your users may not be able to log in to Spira if that provider service goes down. Because of this, the root admin is not able to connect to Spira using a provider in this way.
"},{"location":"Spira-Administration-Guide/System-Users/#active-sessions","title":"Active Sessions","text":"Sometimes a system administrator will want to know who is logged into the system right now, and how many total users are logged in. The 'Active User Sessions' page display a list of all the users who currently have active sessions in the system. Each user is displayed along with their user ID, whether they're connected through the application or via a third-party add-on, and the date they last logged-in.
Administrators can end a session that is in use to make it available for others. This is useful when you at your maximum number of concurrent sessions allowed by your license. This blocks anyone else from logging in - so if they really need to login, someone else has to logout. Clicking the \u2018End Session\u2019 button to the right of the user\u2019s name will end their session, making it available for another user.
Ending a session is not the same as logging out: ending a session does not fully logout the user - it only provides a window for someone to login. If no one logs in and that user keeps using the app, their session will be restarted.
If a user's session is replaced by another user: the first user will now be logged out. They will now be unable to access the system and any unsaved data will be lost.
"},{"location":"Spira-Administration-Guide/System-Users/#pending-requests","title":"Pending Requests","text":"If you have enabled the ability for users to register for new SpiraPlan accounts themselves, clicking on the \"Pending Requests\" administration option allows you to view a list of all the outstanding requests for new user accounts:
For each pending user request you can choose to either Approve or Deny the request:
Approve -- clicking this option will approve the user. They will get an email letting them know that they have been approved and can now log into the system.
Delete -- clicking this option will delete the pending user request from the system.
"},{"location":"Spira-Administration-Guide/System-Users/#view-edit-product-roles","title":"View / Edit Product Roles","text":"Read an overview of how permissions work across the application and all its workspaces.
"},{"location":"Spira-Administration-Guide/System-Users/#default-product-roles","title":"Default Product Roles","text":"There are six (6) default product roles that a user may be assigned to a product with:
The Special case of user administrator
The System Administrator (with a user id of 1) is automatically added to every product as a Product Owner, and can never be removed as Product Owner, made inactive or made a different role on the product.
"},{"location":"Spira-Administration-Guide/System-Users/#role-wide-customizations","title":"Role wide customizations","text":"You can make changes to the permissions associated with each of these default roles, and also create as many additional roles as you like. To customize the roles in your installation of SpiraPlan\u00ae, click on the \"View / Edit Roles\" link in the Administration menu:
The screen lists all of the roles currently configured in the system (both active and inactive) together with the name, description, and an active flag. You can create new roles by clicking the \"Add\" button which will create a new default role entry in the list. You can edit the name, description and associated permissions of a role by clicking on the appropriate \"Edit\" button. You can delete an existing role, by clicking the \"Delete\" button. Note that you cannot delete any of the default roles, but can instead make them inactive.
Clicking on the edit button will take you to the following screen:
On the top of the screen, you can edit the name, description, product admin, limited view and active flags:
Underneath the role wide customizations, you can specify the various artifact-specific permissions for the role:
These permission options allow you to specify if a user can view, create, delete, or modify (in three different ways) each type of artifact in the product:
Bulk Edit: lets users modify items outside of the scope of any workflow in a number of places. This means users can bypass workflow restrictions, allowing them to make status changes (including without electronic signatures) and not enter fields required by workflows. This permission should be applied carefully. Note that you can deny status changes in this with the \"Status bulk edit\" flag on the edit template page. Bulk edit works in the following places:
Note: The permission needed to execute a test case is the \"Create + Test Run\" permission since that initiates the creation of a new test run.
"},{"location":"Spira-Administration-Guide/System-Users/#cross-artifact-permissions","title":"Cross artifact permissions","text":"In addition, there are some permissions that can be specified for each role, that apply across all relevant artifacts:
This section lets you specify if the role allows users to add new documents to the product, edit existing documents, delete documents, edit the document folders, and view/edit source code commits.
"},{"location":"Spira-Administration-Guide/System-Users/#view-edit-teams","title":"View / Edit Teams","text":"In beta, available in SpiraPlan only
System admins can enable beta functionality across the application for their users from the System Admin > General Settings page.
SpiraPlan lets you define a list of Teams. These teams are created system wide, and product members can then be assigned any active team on a product by product basis. You can use these teams in different ways in different products, but the most common way is to group people together based on your organizational or functional structure.
This page lets you display the list of teams sorted alphabetically by name, based on three predefined filters:
Click the 'Add Team' button at the bottom of the list to add a new team:
After entering the name of the new team, optionally entering a description, and choosing its Active status (active by default), click 'Save' to commit the new item. To edit an existing team, change its name, description, or active status and click 'Save'. To delete a team, click the 'Delete' option for that row. Once deleted, an item can be undeleted by changing the display to 'All' and then clicking 'Undelete'.
Learn about how to manage team membership at the product level.
"},{"location":"Spira-Administration-Guide/System-Workspaces/","title":"System: Workspaces","text":"There are up to 3 levels of workspaces that you can use to organize all of your data within Spira. Products are where all your tests, requirements, and bugs live. These are grouped inside of Programs. In SpiraPlan you can group programs inside of Portfolios. Each of these workspaces is discussed below, as are Templates - a special type of workspace for controlling parts of how products and programs work.
All workspaces share certain ways of working: they all have a name and description, then can all be made active or inactive. An inactive workspace is completely inaccessible to any user.
The following screen is displayed when you choose the \"View/Edit Products\" link from the administration menu:
This screen displays the list of products in the system (both inactive and active) together with their program, template, date of creation, and active status. Clicking on either the \"View\" link in the right-hand column or the name of the product will change the currently selected product to one clicked.
By default the table shows you only the active products, but you can select a different option from the dropdown above the table. You can filter the list of products by either choosing an active status, program, or entering a portion of the name or date into the appropriate text box. When you click the \"Filter\" button, the list of products will be filtered by the criteria you entered. You can clear the filter selection by clicking the \"Clear Filters\" button. To sort the list of products, just click on the appropriate arrow icon located in the header row of each field (one each for ascending / descending) In addition, the list of products is paginated into groups of fifteen (15). You can step through the different pages by clicking the page numbers at the bottom of the product list.
To permanently delete a product, click the \"Delete\" button to the right of the product details. Doing so will show a popup where the admin will be required to correctly type the name of the selected product. Product deletion is irreversible and will delete all the artifacts associated with the product. If you want to temporarily delete a product, set its Active flag to 'No' instead. To make a copy of a product to reuse its test cases, releases, test sets and requirements, click the \"Copy\" link to the right of the product. NOTE: this will not make a copy of any historical information, test runs or incidents.
"},{"location":"Spira-Administration-Guide/System-Workspaces/#product-cloning","title":"Product cloning","text":"To clone a product, select a product and click the \"Clone\" button.
The popup dialog gives you the following options:
Whichever copy / clone option you choose, product settings (planning options and testing settings), components and product membership will all be copied over to the new product.
Full clone of the product: this option (the default) creates a new product that is effectively a clone of the original. The original product is not updated in any way. The new product will have copies of every artifact (including custom properties), along with all attachments, comments, and associations. This is very useful if you want to create an archived copy of a product, or want to split a product out into multiple products. Cloning creates the raw data but it does not also calculate test coverage or task progress for the new product. This final process can take a long time, and may not always be necessary. You can calculate this information at any time from the product admin Data Tools page, and after this coverage and traceability should look identical between the original and new product.
While we attempt to create as perfect a clone as possible using this method, there are some limitations to this process:
Reset copy of the product: this option creates a partial clone of the original product and then resets certain key fields. This provides a new product that can be used as a base for new work taking the original as a starting point.
All artifacts are cloned in the same way as the full clone option (e.g. comments and associations are copied) except for the following artifacts which are not copied over at all:
For those artifacts that are copied, the following fields are reset to be either blank or to their default value:
The same limitations listed above for a full clone also apply to this reset copy option.
Cloning the template: this will create a clone of the original product's template and make sure that the new cloned/copied product uses this cloned template. This can be really useful if you want to create a new independent product and template compared to the original.
"},{"location":"Spira-Administration-Guide/System-Workspaces/#add-a-new-product","title":"Add a new product","text":"To add a new product to the system, click the \"Add\" button at the bottom of the product list, and a new screen will be displayed that allows you to enter the new product information:
You need to:
Once you are satisfied with the information, click the \"Insert\" button to actually create the new product.
"},{"location":"Spira-Administration-Guide/System-Workspaces/#edit-a-product","title":"Edit a product","text":"In a similar way, to edit the details of an existing product, click the \"Edit\" button in the right hand column of the product list box, and you will be taken to the following screen that allows you modify the product details:
On this screen you can:
Once you have made the necessary changes, click the \"Save\" button to commit them. If you decide that you want to ignore the changes, click the \"Cancel\" button and the changes will be discarded.
What happens when you make a product inactive
If you set a product's active flag to \"No\" then it will be hidden from the global navigation for all users. This is the recommended alternative to deleting a product (because deletion is permanent).
"},{"location":"Spira-Administration-Guide/System-Workspaces/#viewedit-programs","title":"View/Edit Programs","text":"The following screen is displayed when you choose the \"View/Edit Programs\" link from the Administration menu:
This screen displays the list of programs in the system (both inactive and active) together with their portfolio (SpiraPlan only), template, web site URL, date of creation and active status. Programs are used to relate products that are in the same department/division/organization or are for a common customer, client, etc. When products are in the same program, a user that is a member of the program can see the special Program Dashboard that displays key metrics from all the products in the program combined. Also, such users will have observer-level access to the contained products without needing to be explicitly added to each product.
You can filter the list of programs by either choosing an active status, or entering a portion of the name, web-site or date into the appropriate text box. When you click the \"Filter\" button, the list of programs will be filtered by the criteria you entered. You can clear the filter selection by clicking the \"Clear Filters\" button. To sort the list of programs, just click on the appropriate arrow icon located in the header row of each field (one each for ascending / descending) In addition, the list of programs is paginated into groups of fifteen (15). You can step through the different pages by clicking the page numbers at the bottom of the list.
To permanently delete a program, you should click the \"Delete\" button to the right of the program details. Any products contained in the program will not be deleted, but instead just moved to the default program. There has to be at least one program in the system at all times, so the program designated as the 'default' one will not be available for deletion.
"},{"location":"Spira-Administration-Guide/System-Workspaces/#add-a-new-program","title":"Add a new program","text":"To add a new program to the system, click the \"Add\" button at the bottom of the program list, and a new screen will be displayed that allows you to enter the new program information:
You need to enter:
Once you are satisfied with the information, click the \"Insert\" button to actually create the new program.
"},{"location":"Spira-Administration-Guide/System-Workspaces/#edit-a-program","title":"Edit a program","text":"In a similar way, to edit the details of an existing program, click the \"Edit\" button in the right-hand column of the program list box, and you will be taken to the following screen that allows you modify the program details. Please note that this is the only administrative page in the program administration section.
On the top part of this screen you can edit the name, description, website URL, portfolio (SpiraPlan only), active flag and default flag. Once you have made the necessary changes, click the \"Save\" button to commit them. If you decide that you want to ignore the changes, click the \"Cancel\" button and the changes will be discarded.
What happens when you make a program inactive
If you set a programs's active flag to \"No\" then it will be hidden from the global navigation for all users. All products in that program will also be hidden from the global navigation for all users.
In addition, the lower part of the screen allows you to view/edit the users that are members of the program and also see which products are in the program:
"},{"location":"Spira-Administration-Guide/System-Workspaces/#program-user-membership","title":"Program User Membership","text":"This tab allows you to see which users are members of the program and which program role they have:
The two program roles are \"Executive\" and \"Program Owner\":
Executive -- This role allows the user to see this program's homepage, which contains all the key metrics for the contained products displayed in an aggregated manner. In addition, the user is automatically granted 'observer' permissions for all the products in the program.
Program Owner -- This role consists of all the permissions granted to the \"Executive\" role above, but in addition allows the user to make changes to the Program itself in the Administration section.
To change the role of an existing program member, just change the role in the drop-down list and click [Save]. To remove a member from the program, just select the appropriate checkboxes and click [Delete]. Finally, to add a new user to the program, click on the [Add] button:
You now should narrow down the list of users by entering filter criteria and clicking [Filter]. Once you have located the appropriate user(s), just select a program role for them from the drop-down list and click [Add] to add them to the program in the specified role.
"},{"location":"Spira-Administration-Guide/System-Workspaces/#program-product-list","title":"Program Product List","text":"This tab allows you to see the list of products that are contained within the current program. Clicking on the name of the product will take you to the details page for that product:
"},{"location":"Spira-Administration-Guide/System-Workspaces/#viewedit-portfolios","title":"View/Edit Portfolios","text":"Please note that portfolios are only available in SpiraPlan
The following screen is displayed when you choose the \"View/Edit Portfolios\" link from the Administration menu:
This screen displays the list of portfolios in the system (both inactive and active) together with their description, ID, and active status. Portfolios are used to relate programs together.
You can filter the list of portfolios by either choosing an active status, or entering a portion of the name. When you click the \"Filter\" button, the list of portfolios will be filtered by the criteria you entered. You can clear the filter selection by clicking the \"Clear Filters\" button. To sort the list of portfolios, click on the appropriate arrow icon located in the header row of each field (one each for ascending / descending) In addition, the list of portfolios is paginated into groups of fifteen (15). You can step through the different pages by clicking the page numbers at the bottom of the list.
To permanently delete a portfolio, click the \"Delete\" button to the right of the portfolio details. No programs (or their products) in the portfolio will be deleted - the programs' portfolios will instead be reset to \"none\".
"},{"location":"Spira-Administration-Guide/System-Workspaces/#add-a-new-portfolio","title":"Add a new portfolio","text":"To add a new portfolio to the system, click the \"Add\" button at the bottom of the portfolio list, and a new screen will be displayed that allows you to enter the new portfolio information:
You need to enter:
Once you are satisfied with the information, click the \"Insert\" button to actually create the new portfolio.
"},{"location":"Spira-Administration-Guide/System-Workspaces/#edit-a-portfolio","title":"Edit a portfolio","text":"In a similar way, to edit the details of an existing portfolio, click the \"Edit\" button in the right-hand column of the portfolio list box, and you will be taken to the following screen that allows you modify the portfolio details.
On the top part of this screen you can edit the name, description, and active flag. Once you have made the necessary changes, click the \"Save\" button to commit them. If you decide that you want to ignore the changes, click the \"Cancel\" button and the changes will be discarded.
At the bottom of the screen you can see all the programs that belong to this portfolio.
What happens when you make a portfolio inactive
If you set a portfolio's active flag to \"No\" then it will be hidden from the global navigation for all users. Any programs in the portfolio and all products in those programs will also be hidden from the global navigation for all users.
"},{"location":"Spira-Administration-Guide/System-Workspaces/#viewedit-templates","title":"View/Edit Templates","text":"The following screen is displayed when you choose the \"View/Edit Templates\" link from the administration menu:
This screen displays the list of templates in the system (both inactive and active) with their active status.
You can filter the list of products by either choosing an active status, ID, or entering a portion of the name into the appropriate text box. When you click the \"Filter\" button, the list of templates will be filtered by the criteria you entered. You can clear the filter selection by clicking the \"Clear Filter\" button. To sort the list of templates, click on the appropriate arrow icon located in the header row of each field (one each for ascending / descending).
To permanently delete a template, click the \"Delete\" button to the right of the template details. This is irreversible. If you want to temporarily delete a template, set its Active flag to 'No' instead. Neither of these actions will be possible if any product (active or inactive) is controlled by the template.
To add a new template to the system, you need to create a new template when creating a new product (as described in View/Edit Products). To edit the details of an existing template, click the \"Edit\" button in the right hand column of the template list box, and you will be taken to the following screen that allows you modify the template details:
On this screen you can edit the template's:
Once you have made the necessary changes, click the \"Save\" button to commit them. If you decide that you want to ignore the changes, click the \"Cancel\" button and the changes will be discarded.
"},{"location":"Spira-Administration-Guide/System-Workspaces/#included-templates","title":"Included Templates","text":"SpiraPlan ships with four different templates. Together these will cover most of your needs. You can easily clone and customize one of these templates to meet your exact needs. Or you can start from scratch. Below is a brief description of each of the includes templates:
Info
This page is accessible under the Workspace subsection of the system admin menu. It is visible when you first get a new application. But as soon as the application gets updated to a new version, the page is no longer accessible and you will not see the entry in the admin menu.
The application includes different types of sample data, some about specific industries, to help you understand how the application works. For example, how products fit inside a program, or how different artifacts work together. There are six sample data sets available in the application. A system administrator can change which of these are available at any one time. The admin can make all available, none available, or anywhere in between.
When you load this page the sample data sets currently active will have the checkbox next to them checked. By default the \"Basic Samples\" are the only ones enabled. To change which sample data sets are active, check the relevant checkboxes and click save.
Please note that for users to be able to see these samples they can either login with a user who is already a member of the data or they can be added as a member by a system admin. The users with username \"administrator\" and \"fredbloggs\" have access to all of the sample data by default.
"},{"location":"Spira-Administration-Guide/System-Workspaces/#delete-sample-data","title":"Delete Sample Data","text":"If you click the \"Delete\" button, a popup will show a warning. If you decide to proceed the system will attempt to delete all sample data, including users, products, artifact information, programs, and portfolios. This method will not delete:
Tip
If you do not want users to see the sample data but do not want to permanently delete that data:
These inactive items will still be visible on the relevant administration pages, but no one will see them in the main application.
"},{"location":"Spira-Administration-Guide/System/","title":"System","text":""},{"location":"Spira-Administration-Guide/System/#general-settings","title":"General Settings","text":"The general settings page allows you to configure SpiraPlan\u00ae to better match your environment and setup. In the current version, you can specify the default language, or configure the folder used to store document attachments:
The available settings include:
C:\\Program Files\\SpiraPlan\\Attachments folder located inside the main SpiraPlan\u00ae installation root. However you may want to have the documents stored on a remotely mounted drive or on a different hard disk partition. In which case you can simply change the folder pointed to in the text-box illustrated above and then click [Update] to commit the change.The below toggle is only available in cloud hosted versions of SpiraTeam and SpiraPlan.
Not exclusively using TaraVault
If you set/leave the \"Use TaraVault for source code\" toggle discussed above to Yes, then you will only have access to the TaraVault admin pages at both the system and product level administration.
If you set the \"Use TaraVault for source code\" toggle to No, the administration menu will work a little differently for you. The system admin menu will always show two links for source code management in the Integration sub-section. This allows to easily access and configure TaraVault and any third party providers at any time. Meanwhile, the product admin menu will adapt to how you have setup source code for that particular product:
The \"File Types List\" administration page allows you to view all the different filetypes that are recognized by SpiraPlan and add or edit the associated icon, name, description and MIME type:
If you click on the \"Edit\" button next to a filetype, or click on the \"Add\" button at the bottom of the screen, the system will display the page that lets you add or edit a filetype entry:
On this page you can enter/edit the file extension that's used to recognize the type of file uploaded, the description of the file type (displayed in popup tooltips), the MIME type (used to determine how the browser handles the file type) and the path to the icon image. Once you are satisfied with the values, you can click on the \"Save\" button to confirm the changes.
"},{"location":"Spira-Administration-Guide/System/#license-details","title":"License Details","text":"Info
This page is accessible under the System subsection of the sytem admin menu. It is only visible if you have Spira installed on premise.
The license details page displays the information about the installed license for the particular instance of SpiraPlan\u00ae being used. This will display less information for hosted customers. The information displayed for self-hosted customers includes: the product name (e.g. SpiraPlan), the license version (e.g. v6.0.0.0), type of license in effect (x-user fixed, x-user concurrent, demonstration, enterprise, etc.), the expiration date (if any) of the license, the organization that the license belongs to, and the number of users concurrently logged-in right now. This last piece of information is useful as it helps administrators track down how many licenses are currently in use.
A sample page is illustrated below:
To change the license key used by the system (for example, if to upgrade from Trial edition to Standard edition), you do not need to reinstall SpiraPlan\u00ae. All you need to do is change the organization and license key text-boxes to match the license key and organization name found in the customer area of our website (http://www.inflectra.com/CustomerArea) and click the \"Save\" button.
If there is an issue with the license key (e.g. a trial version that is passed its expiration date, or where the license key doesn't match the organization name) an error will be displayed describing the specific issue with the information you entered. If you are unable to get the system to work with the license key information, please contact Inflectra\u00ae customer support at: support@inflectra.com.
"},{"location":"Spira-Administration-Guide/System/#ldap-configuration","title":"LDAP Configuration","text":"As described previously, you can configure SpiraPlan\u00ae to use an external LDAP server for importing new user profiles into the system, and for authenticating users -- instead of having to store separate passwords inside SpiraPlan\u00ae. However, you need to first configure the LDAP server settings. To do this, click on the \"LDAP Configuration\" link the Administration navigation:
You need to fill out the various configuration settings for your LDAP server, each of which is explained in more detail below:
The \"Security Settings\" administration page lets you specify the various security settings within SpiraPlan to match your organization's policies and processes:
The following settings can be changed within the system, once you are satisfied, click the \"Save\" button to commit the changes:
2-Step Authentication tips
This section refers to the functionality available to hosted/cloud customers of SpiraPlan. If you are using the on-premise version of SpiraPlan, please refer to Version Control Integration instead.
TaraVault\u00ae is the hosted source code repository and software configuration management (SCM) system provided by Inflectra. When you signed-up or purchased a subscription to either SpiraPlan or SpiraTeam, it will have come with an entry-level subscription to TaraVault.
When you first click on the Administration > TaraVault administration page, you will see the following screen:
This lets you know that you have not yet activated your TaraVault account with Inflectra. When you click on the [Activate TaraVault] button you will see the following:
This will let you see how many TaraVault SCM users your subscription allows and also the name of the TaraVault instance that your SpiraPlan instance is associated with.
Each product in SpiraPlan has its own corresponding TaraVault product, and each TaraVault product can be configured to use one of the two different SCM providers:
Subversion (SVN) -- This is a simple, centralized version control system (VCS) that works best for teams that want to have a centralized SCM environment with only one central instance of the SCM repository. Subversion only allows a single branch to be managed and is generally easier to understand conceptually.
Git -- This is a more powerful, distributed version control system (DVCS) that works best for teams that want to have multiple distributed instances of their source code repository. Git offers superior merging and branching functionality to Subversion but is generally more complicated to understand conceptually.
For the current SpiraPlan product you can choose the type of provider you wish to use, enter the name of the TaraVault product and click Activate:
Since you cannot change the type or name of the TaraVault product once activated, please review your entries and click [OK] to confirm the new product activation.
Once the product activation has been completed, the screen will display the following:
The screen will display the name of the linked TaraVault product as well as the list of TaraVault SCM users that are configured to use this TaraVault product -- this list will not necessarily be all of the users in the SpiraPlan product, just those that need to connect to TaraVault to commit source code into the repository.
If you want to deactivate this TaraVault product, click the [Deactivate] button and the product will be removed from TaraVault.
To improve performance, SpiraPlan will cache some of the data it receives from TaraVault. Normally SpiraPlan will know when to update the cached data based on changes made in TaraVault automatically. However sometimes you may wish to flush the cached data completed, to do this, click on the [Clear Cache] button.
To add new SCM users to the TaraVault product, click on the 'Add Users' link to add new SCM users to the product.
"},{"location":"Spira-Administration-Guide/System/#event-log","title":"Event Log","text":"The \"System Event Log\" administration page lets you view all of the errors, warning and other diagnostic messages that have been logged in the system:
Each event entry is displayed along with the date-time it occurred, the type of event (error, warning, information, success audit, failure audit), category (application, source code provider, data-synchronization) and the short name. To view the full message, click on the \"View Item\" hyperlink:
The popup dialog box will display the full error message log and stack trace in a moveable dialog box. This information should be provided to Inflectra customer support if you log a help desk ticket.
"},{"location":"Spira-Administration-Guide/System/#email-configuration","title":"Email Configuration","text":"The Email Configuration page is split into two sections. The first section covers email notification details, and the second section configures how email from the application is sent.
To use the internal IIS's default virtual SMTP server, leave all fields blank. The virtual server must then be configured to use proper SMTP server and network configuration. If you want the application to contact an SMTP server directly, use the following fields:
Example settings for connecting to Gmail/Google Mail for sending notifications:
The SpiraApps page shows system administrators every SpiraApp currently installed, sorted alphabetically1.
For each SpiraApp in the list you see:
Available operations
The SpiraApp Settings page shows any system wide settings available for the particular SpiraApp. For more detailed information about each SpiraApp, what they do, and how to work with them refer to the dedicated SpiraApp documentation
If the SpiraApp has no settings you can still access the page but there will be no settings to edit.
If the SpiraApp has system level settings you will see:
Within each group a list of available settings:
Click the \"Save\" button to commit any edits.
"},{"location":"Spira-Administration-Guide/System/#system-history-changes","title":"System History Changes","text":"This page displays a list of relevant changes made to system level artifacts. Currently, only changes to product custom properties are recorded.
The system history list page shows system administrators all the currently recorded changes made at the system level. By default, items are shown in chronological order with the most recent at the top. The list can be filtered. Each history entry shows:
Change Type: what sort of change was made:
Workspace: the workspace type of that artifact (product, program, portfolio, or system)
The system history details screen will show basic information as well as fields that were changed in this change set.
The top part of the page shows relevant properties: change date, changed by, change type, workspace, artifact type, artifact (name).
Below this, the change actions are shown. This shows one row for each field that was changed in this change set. It shows:
SpiraApps are shown even if they will not fully function in your application. For instance, the FMEA SpiraApp is only compatible with SpiraPlan but will still show in the list if you are using SpiraTest or SpiraTeam.\u00a0\u21a9
SpiraPlan allows you to customize many of its artifacts1 by adding user-defined custom properties in addition to the built-in fields. Custom properties show in the application in the following places.
You can create a variety of different types of custom properties. You can create as many custom lists as you need with each having as many values as you need. Custom lists are not artifact specific, but can be used by any artifact. This section describes how to setup different custom lists and custom properties in your templates.
"},{"location":"Spira-Administration-Guide/Template-Custom-Properties/#edit-custom-properties","title":"Edit Custom Properties","text":"To access an artifact's custom properties, open the template admin menu and click the relevant link (artifacts with their own sub-sections in the menu list \"Custom Properties\" in that sub-section, all other artifacts are listed under the \"Custom Properties\" sub-section). This opens the custom property page for that artifact where you can quickly see the name, field number, type, legacy name, and actions (edit and delete) for each custom property.
In the example below we are looking at the requirements custom property page, which currently has 7 custom properties defined. The custom properties page has rows for available custom properties for that artifact type in the current template.
Artifacts in SpiraPlan can have up to 99 different custom properties per artifact-type, per template.
To edit an existing custom property definition click the \"Edit Definition\" button for that specific property. To add a new definition click the \"Add Definition\" button. In either case the following dialog will be displayed:
For each custom property you set the following fields on the main definition tab:
Different types of custom properties supported:
Each custom property can have optional settings applied to it to further control the custom property. Note: not all settings are available for all property types. These settings are on the Options tab of the dialog:
Note
Setting 'Allow Empty' to No will override any workflow step definitions, and will always require a value to be entered in, even if the workflow is configured to have the field disabled!
When finished, click the Save button.
Renaming or Removing Custom Properties
When changing a custom property's type or removing a custom property, the data is not actually removed from the artifact. Therefore, if you change a custom property from a date type to a text custom property, the field may display the old date value until it is changed by the user.
"},{"location":"Spira-Administration-Guide/Template-Custom-Properties/#edit-custom-lists","title":"Edit Custom Lists","text":"If you are planning on having any list based custom properties in your template, then you first need to create and populate the custom template lists that the user will be able to select from. These lists are stored separately from the individual artifact types so that you can have one set of values (e.g. list of operating systems under test) be reused by multiple artifact types.
The following screen is displayed when you choose the \"Custom Lists\" link from the Administration menu:
The screen displays all the custom lists currently defined within the template, together with the number of values associated with each list. By default the screen will initially be empty so the first thing you need to do is click \"Add List\" to create a new custom list:
After changing the name of the list, and specifying whether the values will be ordered by their name or the order in which they were entered (called by ID), you can either click \"Save\" to commit the change, or click the \"Add Value\" option to add some list values:
This is the set of values that the user will select from the drop-down list when the custom property is displayed. You can change the display to include:
To add a new custom list value, click the \"Add Value\" button and a new row will be added to the list which you can now edit. To edit an existing custom list value, change the name in the textbox and click \"Save\". To delete a custom list value, click on the \"Delete\" hyperlink. If you want to remove an item from the list temporarily, you can set its Active dropdown list to 'No', if you want to remove an item permanently, just click the 'Delete' button.
To edit an existing custom list, you just need to click on the \"Edit Values\" button to display the custom list name and list of associated values (which is the same screen as the one displayed for a new list). To remove a custom list from the template, just click on the \"Remove\" button next to the custom list and the list and all its associated values will be deleted from the template.
Recovering deleted list values
Even if you delete a custom list value, there is an option to undelete by simply changing the display selection to \"All\" and clicking the 'Undelete' hyperlink next to a deleted value.
the following artifacts support custom properties: requirements, releases, documents, test cases, test steps, test sets, test runs, automation hosts, incidents, tasks, risks.\u00a0\u21a9
SpiraPlan\u00ae includes a built-in web-based document management system that allows you to upload and share documents between product team members. These documents are stored in folders, categorized by a series of user-defined meta-tags and can also be associated with other artifacts in the system (e.g. requirements, incidents, etc.).
The set of administrative options located under the \"Documents\" heading allow the Template Owner to configure how the documents are organized in their particular template.
"},{"location":"Spira-Administration-Guide/Template-Documents/#document-types","title":"Document Types","text":"When users upload documents into a SpiraPlan product, they are required to specify the type of document that is being uploaded. The list of document types is configurable by the Template Owner for each individual template.
When you click on Documents \"Types\", you can edit the list of types available:
By default, each template will be created with a single document type called 'Default'. You can add additional document types and/or change the name of the ones already created. If you decide that you no longer want to use a specific document type, you can set its active flag to \"No\".
The only requirement is that each template needs to have at least one active document type available, and that there is one active type designated as the default type. The default type is the option that will be initially selected when a user uploads a file / URL to the template's product(s).
"},{"location":"Spira-Administration-Guide/Template-Documents/#document-statuses","title":"Document Statuses","text":"The following screen is displayed when you choose the \"Statuses\" link from the Documents section of the administration menu:
The screen displays a list of all the defined document statuses for the current template. By default, the screen will be populated with the standard SpiraPlan\u00ae document statuses. To edit an existing document status, change the name, open check-box, set it as the default status and/or change the active flag then click \"Save\".
You can't delete an existing document status, but to prevent it appearing in any drop-down-lists, change its active flag to \"No\" and click \"Save\". To add a new document status, click the \"Add\" button and a new row will be added to the list which you can now edit.
The open check-box allow you to specify if the document status should be considered open or not, which means it is would be eligible for display in the various sections of the user's home page and the product home page that list open document. The default radio button allows you to specify which document status should be the default for newly created documents. This is the status that a new document will be set to when first created, and acts as the first step in the document workflow. Note that you must have at least one active incident status, and you cannot set a document status as the default.
"},{"location":"Spira-Administration-Guide/Template-Documents/#document-workflows","title":"Document Workflows","text":"Clicking on the \"Workflows\" link in the Administration menu Documents section brings up the list of defined document workflows for the current template. A workflow is a predefined sequence of document statuses linked together by \"workflow transitions\" to enable a newly created document to be reviewed, prioritized, assigned, resolved and closed, as well as to checking documents in and out of the system. The workflow list screen for a sample template is illustrated below:
To modify the name, default status, notify and/or active flags, change the values in the appropriate text-box, radio-button, check-box or drop-down list and click the \"Save\" button. To add a new workflow, click the \"Add\" button and a new workflow will be created with the standard SpiraPlan\u00ae steps and transitions.
You can have as many document workflows as you like in a template, but only one can be marked as the default. Each document type is assigned to a workflow; this allows you to have different document types follow different paths from creation of closure. However, when a new document type is created, it will be initially associated with the template's default workflow.
Note: You can only assign an active workflow to a document type, and similarly you cannot make a workflow inactive that is currently linked to a document type. This is important as all document types need to be linked to an active workflow at all times.
"},{"location":"Spira-Administration-Guide/Template-Documents/#workflow-details","title":"Workflow Details","text":"Clicking on the \"Steps\" button of a workflow brings up the following screen that lists all the workflow steps and workflow transitions that comprise the workflow:
This page lists in the left-most column all the various document statuses defined for the template. The next column lists all the possible transitions that can occur from that status. In addition, to the right of each transition is the name of the resulting destination status that the transition leads to. E.g. from the Under Review status, depending on your role (see later) you can move the document to either Approved, Rejected or Draft depending on which transition the user takes.
Clicking on the name of a step or transition takes you to the appropriate details page (see below) where you can set the properties of the step or transition respectively. To delete an existing transition, click the \"x\" button after the transition name, and to add a new transition, click the \"Add Transition\" button in the Operations column.
"},{"location":"Spira-Administration-Guide/Template-Documents/#edit-workflow-transition","title":"Edit Workflow Transition","text":"When you click on the transition name link from the previous screen, you are taken to the workflow transition details screen:
The top part of the screen is the \"workflow browser\" which illustrates how the transition relates to the workflow as a whole. It displays the current transition in the middle, with the originating and destination steps listed to either side. Clicking on either document status name will take you to the appropriate workflow step details page. This allows you to click through the whole workflow from start to finish without having to return to the workflow details page.
If a digital signature from the user is required to authorize and record the transition, set the toggle to yes for \"Require Electronic Signature\".
Each transition has a series of conditions which need to be satisfied for a user to actually execute the transition (i.e. move the document from the originating status to the destination status).
"},{"location":"Spira-Administration-Guide/Template-Documents/#edit-workflow-step","title":"Edit Workflow Step","text":"When you click on the document status name link from either of the previous screens, you are taken to the workflow step details screen:
The top part of the screen is the \"workflow browser\" which illustrates how the step relates to the workflow as a whole. It displays the current document status in the middle, with the possible originating and destination transitions listed to either side. Clicking on either workflow transition name will take you to the appropriate workflow transition details page. This allows you to click through the whole workflow from start to finish without having to return to the workflow details page.
This page allows you to define the behavior of the various document fields (i.e. those that are a standard part of SpiraPlan\u00ae such as Type):
This page also allows you to define the behavior of the various document custom properties for this particular step in the workflow:
You can set each of the fields/custom properties as being:
After you have made the desired changes, click \"Save\".
Note that the \"Versions\" field has a special meaning. It related to the Versions tab on the Document details page. When hidden, users are not able to see any version information (the whole tab is hidden). When disabled, users cannot upload a new version. When required, a new version must have been recently uploaded by the current user for the document to be saved, and no changes made to the document between the version being uploaded and now.
"},{"location":"Spira-Administration-Guide/Template-Documents/#example-workflow","title":"Example Workflow","text":"Below is a diagram that shows an example workflow (the one used by the sample product \"Library Information System\") for documents.
"},{"location":"Spira-Administration-Guide/Template-Home/","title":"Template: Home Page","text":"The Template Administration Home page is accessible to users whose product role includes template admin permission. It provides template administrators with quick access to important information. There are multiple ways to navigate to it:
This widget shows a list of its owners. Click the Edit link to go to the template editing page. From here you can edit a number of properties about the template, including its name.
"},{"location":"Spira-Administration-Guide/Template-Home/#product-list","title":"Product List","text":"This widget shows a list of the products which use this template.
"},{"location":"Spira-Administration-Guide/Template-Home/#links","title":"Links","text":"This widget provides an alternate way to access the template-specific configuration pages.
"},{"location":"Spira-Administration-Guide/Template-Incidents/","title":"Template: Incidents","text":"In addition to being able to create custom properties and values for incidents (same as for all artifacts in SpiraPlan\u00ae), you can also change the values populated in many of the standard fields used in the incident tracker -- types, statuses, priorities and severities. The process for changing each of these is described below:
"},{"location":"Spira-Administration-Guide/Template-Incidents/#edit-types","title":"Edit Types","text":"The following screen is displayed when you choose the \"Types\" link from the Incidents section of the administration menu:
The screen displays a list of all the defined incident types for the current template. By default the screen will be populated with the standard SpiraPlan\u00ae incident types. To edit an existing incident type, change the name, associated workflow, issue check-box, risk check-box, set a default type and/or change the active flag then click \"Save\".
You can't delete an existing incident type, but to prevent it appearing in any drop-down-lists, all you need to do is change its active flag to \"No\" and click \"Save\". To add a new incident type, click the \"Add\" button and a new row will be added to the list which you can now edit.
The associated workflow drop-down list allows you to specify which workflow the incident type will follow. This is a very powerful feature since it allows you to configure different workflows for different incident types; i.e. a bug may follow a workflow geared to identification and resolution, whereas a risk may only need a much simpler set of steps and actions.
The issue check-boxes allow you to specify if the incident type is an issue, which means it would be eligible for display in the issue section of the product home page. The default radio button allows you to specify which incident type should be the default for newly created incidents. This is the type that a new incident will be set to unless changed by the creator of the incident. Note that you must have at least one active incident type, and you cannot set an inactive type as the default.
"},{"location":"Spira-Administration-Guide/Template-Incidents/#edit-statuses","title":"Edit Statuses","text":"The following screen is displayed when you choose the \"Statuses\" link from the Incidents section of the administration menu:
The screen displays a list of all the defined incident statuses for the current template. By default, the screen will be populated with the standard SpiraPlan\u00ae incident statuses. To edit an existing incident status, change the name, open check-box, set it as the default status and/or change the active flag then click \"Save\".
You can't delete an existing incident status, but to prevent it appearing in any drop-down-lists, all you need to do is change its active flag to \"No\" and click \"Save\". To add a new incident status, click the \"Add\" button and a new row will be added to the list which you can now edit.
The open check-box allow you to specify if the incident status should be considered open or not, which means it is would be eligible for display in the various sections of the user's home page and the product home page that list open incidents. The default radio button allows you to specify which incident status should be the default for newly created incidents. This is the status that a new incident will be set to when first created, and acts as the first step in the incident workflow. Note that you must have at least one active incident status, and you cannot set an inactive status as the default.
"},{"location":"Spira-Administration-Guide/Template-Incidents/#priorities","title":"Priorities","text":"The following screen is displayed when you choose the \"Priorities\" link from the Incidents section of the administration menu:
The screen displays a list of all the defined incident priorities for the current template. By default, the screen will be populated with the standard SpiraPlan\u00ae incident priorities. To edit an existing incident priority, change the name, color and/or change the active flag then click \"Save\". Note that you can either enter the hexadecimal RRGGBB code for the color or use the pop-up color picker.
You can't delete an existing incident priority, but to prevent it appearing in any drop-down-lists, all you need to do is change its active flag to \"No\" and click \"Save\". To add a new incident priority, click the \"Add\" button and a new row will be added to the list which you can now edit.
"},{"location":"Spira-Administration-Guide/Template-Incidents/#severities","title":"Severities","text":"The following screen is displayed when you choose the \"Severities\" link from the Incidents section of the administration menu:
The screen displays a list of all the defined incident severities for the current template. By default, the screen will be populated with the standard SpiraPlan\u00ae incident severities. To edit an existing incident severity, change the name, color and/or change the active flag then click \"Save\". Note that you can either enter the hexadecimal RRGGBB code for the color or use the pop-up color picker.
You can't delete an existing incident severity, but to prevent it appearing in any drop-down-lists, all you need to do is change its active flag to \"No\" and click \"Save\". To add a new incident severity, click the \"Add\" button and a new row will be added to the list which you can now edit.
"},{"location":"Spira-Administration-Guide/Template-Incidents/#incident-workflows","title":"Incident Workflows","text":"Clicking on the \"Workflows\" link in the Administration menu brings up the list of defined incident workflows for the current template. A workflow is a predefined sequence of incident statuses linked together by \"workflow transitions\" to enable a newly created incident to be reviewed, prioritized, assigned, resolved and closed, as well as to handle exception cases such as the case of a duplicate or non-reproducible incident. The workflow list screen for a sample template is illustrated below:
To modify the name, default status, notify and/or active flags, change the values in the appropriate text-box, radio-button, check-box or drop-down list and click the \"Save\" button. To add a new workflow, click the \"Add\" button and a new workflow will be created with the standard SpiraPlan\u00ae steps and transitions.
You can have as many workflows as you like in a template, but only one can be marked as the default. Each incident type is assigned to a workflow; this allows you to have different incident types follow different paths from creation of closure. However when a new incident type is created, it will be initially associated with the template's default workflow. The steps and transitions that make up the default workflow are illustrated in the diagram below:
flowchart LR\n A(open status)\n B(closed status)\n\n New --> Open;\n New --> Assigned;\n Assigned --> Duplicate;\n Assigned ---> Resolved;\n Assigned ---> NR[Not Reproducible];\n Resolved --> Closed;\n Open --> Assigned;\n Open --> Duplicate;\n Reopen --> Assigned;\n Reopen <--> Duplicate;\n Reopen <--> Resolved;\n Reopen <--> NR;\n Closed --> Reopen;\n\n style B fill:#f9f\n style Closed fill:#f9f\n style NR fill:#f9f\n style Duplicate fill:#f9f\n style Resolved fill:#f9fThe notify flag is used to tell SpiraPlan\u00ae whether that particular workflow should have email notifications turned on or off. You define what transitions and which recipients should receive the emails in the workflow transition editor (see below), but you can globally turn on/off notifications here as well. This is useful if you find that the notifications are becoming an annoyance, or if the email server is unavailable for a period of time.
Note: You can only assign an active workflow to an incident type, and similarly you cannot make a workflow inactive that is currently linked to an incident type. This is important as all incident types need to be linked to an active workflow at all times.
"},{"location":"Spira-Administration-Guide/Template-Incidents/#edit-workflow-details","title":"Edit Workflow Details","text":"Clicking on the \"Steps\" button of a workflow brings up the following screen that lists all the workflow steps and workflow transitions that comprise the workflow:
This page lists in the left-most column all the various incident statuses defined for the template. The next column lists all the possible transitions that can occur from that status. In addition, with each transition is listed the name of the resulting destination status that the transition leads to. E.g. from the assigned status, depending on your role (see later) you can move the incident to either duplicate, resolves or not-reproducible depending on which transition the user takes.
Clicking on the name of a step or transition takes you to the appropriate details page (see below) where you can set the properties of the step or transition respectively. To delete an existing transition, click the \"x\" button after the transition name, and to add a new transition, click the \"Add Transition\" button in the Operations column.
"},{"location":"Spira-Administration-Guide/Template-Incidents/#edit-workflow-transition","title":"Edit Workflow Transition","text":"When you click on the transition name link from the previous screen, you are taken to the workflow transition details screen:
The top part of the screen is the \"workflow browser\" which illustrates how the transition relates to the workflow as a whole. It displays the current transition in the middle, with the originating and destination steps listed to either side. Clicking on either incident status name will take you to the appropriate workflow step details page. This allows you to click through the whole workflow from start to finish without having to return to the workflow details page.
This part of the screen lets you change the name of the transition and specify the subject line of any email notifications sent as part of this transition. To view the list of special tokens that can be used in the email subject, click on the \"Display Email Subject Special Tokens\" hyperlink:
If a digital signature from the user is required to authorize and record the transition, set the toggle to yes for \"Require Electronic Signature\".
Each transition has a series of conditions which need to be satisfied for a user to actually execute the transition (i.e. move the incident from the originating status to the destination status):
Each transition also has a set of notification rules that allow you to specify who should get an email notification if the transition is executed.
Both the conditions and notifications allow you to set three types of user role:
The detector of the incident can be allowed to execute the transition, and/or be notified when the transition occurs. For example, when an incident is marked as Resolved, the detector should be the only one who's allowed to move it to Closed. Similarly when an incident is moved from Assigned to Resolved, the detector should probably be notified so that he knows to log in and verify that it has been resolved satisfactorily.
The owner of the incident can be allowed to execute the transition, and/or be notified when the transition occurs. For example, when an incident is marked as Assigned, the assigned owner should be the only one who's allowed to move it to Resolved. Similarly when an incident is moved from Open to Assigned, the owner should probably be notified so that he knows to log in and begin resolving the incident.
A user with a specified role can be allowed to execute the transition, and/or be notified when the transition occurs regardless of whether they are the detector or owner. For example a user with role \"Manager\" might want the power to close all incidents regardless of ownership status, and might also want to be notified when any incident is marked as Not-Reproducible.
You can set any of these conditions by changing the drop-down list > and/or check-boxes and clicking the appropriate \"Save\" button.
"},{"location":"Spira-Administration-Guide/Template-Incidents/#edit-workflow-step","title":"Edit Workflow Step","text":"When you click on the incident status name link from either of the previous screens, you are taken to the workflow step details screen:
The top part of the screen is the \"workflow browser\" which illustrates how the step relates to the workflow as a whole. It displays the current incident status in the middle, with the possible originating and destination transitions listed to either side. Clicking on either workflow transition name will take you to the appropriate workflow transition details page. This allows you to click through the whole workflow from start to finish without having to return to the workflow details page.
This page allows you to define the behavior of the various incident fields (i.e. those that are a standard part of SpiraPlan\u00ae such as Priority):
This page also allows you to define the behavior of the various incident custom properties for this particular step in the workflow:
You can set each of the fields/custom properties as being:
For example, when an incident is in the New status, you might make the owner field hidden (since a detector shouldn't need to know who will ultimately own it), when it gets to the Open status, you might make the field active, and when it gets to the Assigned status, you might make it active and required. This allows you to tailor the information gathered to the appropriate place in the workflow.
After you have made the desired changes, click \"Save\".
"},{"location":"Spira-Administration-Guide/Template-Incidents/#example-workflow","title":"Example Workflow","text":"Below is a diagram that shows an example workflow (the one used by the sample product \"Library Information System\") for incidents.
"},{"location":"Spira-Administration-Guide/Template-Notifications/","title":"Template: Notifications","text":"Each template has a separate notification system. This lets admins control what events trigger a notification being sent (via email), with what subject line, and who it should go to. You can create as many event triggers as you want, to give you fine grained control over when notifications are created. Each template has a single notification template (email body with tokens) per artifact. You can have, for example, 20 different requirement event triggers for a product template, each with their own rules and subjects; but they will all send the same email body, because they will all use the same requirement notification template.
To configure emails across the entire system see Email Configuration.
"},{"location":"Spira-Administration-Guide/Template-Notifications/#notification-templates","title":"Notification Templates","text":"Notification templates are used by notification events, and are defined for each supported artifact type1 in the template.
To edit a template, click the Edit button. To send a test email notification to yourself using the current template, click the Test button.
Clicking the Edit button will take you to a page similar to the following. Depending on the artifact type you selected, the list of available fields will vary.
On this screen you are presented with the same rich text editor available elsewhere in the application. Displayed in it is the current template (with template tags showing) for the artifact. Template tags start with a $ (dollar sign) and then a string name enclosed in {} parentheses. When email notifications are sent, tokens will be replaced with specific information from the artifact that the notification is being sent for. Invalid tokens will be stripped from the template text. Clicking the link \"(Display Email Template Field Tokens\" to see a list of available tokens to insert into the textbox for easy selecting and editing.
If HTML notifications are disabled, the template will be converted to plain text before sending.
When finished, click the update button to save your new template. The new template will take effect immediately.
"},{"location":"Spira-Administration-Guide/Template-Notifications/#notification-events","title":"Notification Events","text":"The Notification Events section is where template administrators can set up when and to whom notifications are sent out to users of the system. Clicking on the Notification Events link will present you with a list of all events defined for the current template:
Note: These events can handle all changes to any of the artifacts except changes handled by Status changes to Incidents. Incident status changes are handled through the Workflow configuration.
When clicking on the Edit or Add buttons, you will be presented with the event details screen:
The top section defines general configuration items for the event:
The Artifact Fields will let you configure which fields will cause this notification to send an email notification:
Selected fields are treated in an OR-based query, so that if you have two or more fields checked for an event, the event will send a notification if either of the two fields are changed. Depending on the artifact type configured above, the available fields will vary.
The last section is the configuration of whom to send the notifications to:
If a user belongs to more than one group or they have manually signed up to receive notifications to any changes in the artifact, they will only receive one notification for the artifact change.
Document, Incident, Release, Requirement, Risk, Task, Test Case, Test Set\u00a0\u21a9
Clicking on the \"Release Workflows\" link under the Planning heading, brings up the list of defined release workflows for the current template. A workflow is a predefined sequence of release statuses linked together by \"workflow transitions\" to enable a newly created release to be reviewed, prioritized, assigned, developed and tested, as well as to handle exception cases such as the case of a cancelled or deferred release. The workflow list screen for the sample template is illustrated below:
The screen displays a list of all the standard release types in the system. The associated workflow drop-down list allows you to specify which workflow the release type will follow. This is a very powerful feature since it allows you to configure different workflows for different release types; i.e. a Major release may follow a different process than an iteration.
You can have as many workflows as you like in a template, but only one can be marked as the default. Each release type must be assigned to a workflow. To modify the name, default flag, and/or active flag of an existing workflow, change the values in the appropriate text-box, radio-button, or drop-down list and click the \"Save\" button. To add a new workflow, click the 'Add Workflow' link and a new workflow will be created with the standard SpiraPlan\u00ae steps and transitions.
Note: You can only assign an active workflow to a release type, and similarly you cannot make a workflow inactive that is currently linked to a release type. This is important as all release types need to be linked to an active workflow at all times.
"},{"location":"Spira-Administration-Guide/Template-Releases/#edit-workflow-details","title":"Edit Workflow Details","text":"Clicking on the 'Steps' hyperlink of a workflow brings up the following screen that lists all the workflow steps and workflow transitions that comprise the workflow:
This page lists in the left-most column all the various release statuses defined in the system. The next column lists all the possible transitions that can occur from that status. In addition, with each transition is listed the name of the resulting destination status that the transition leads to. E.g. from the Planned status, depending on your role (see later) the user can move the release to either Cancelled, Deferred, or In Progress, depending on which transition the user takes.
Clicking on the name of a step or transition takes you to the appropriate details page (see below) where you can set the properties of the step or transition respectively. To delete an existing transition, click the 'x button after the transition name, and to add a new transition, click the 'Add Transition' button in the Operations column.
"},{"location":"Spira-Administration-Guide/Template-Releases/#edit-workflow-transition","title":"Edit Workflow Transition","text":"When you click on the transition name link from the previous screen, you are taken to the workflow transition details screen:
The top part of the screen is the \"workflow browser\" which illustrates how the transition relates to the workflow as a whole. It displays the current transition in the middle, with the originating and destination steps listed to either side. Clicking on either task status name will take you to the appropriate workflow step details page. This allows you to click through the whole workflow from start to finish without having to return to the workflow details page.
This part of the screen lets you change the name of the transition. If a digital signature from the user is required to authorize and record the transition, set the toggle to yes for \"Require Electronic Signature\".
In addition, each transition has a series of conditions which need to be satisfied for a user to actually execute the transition (i.e. move the release from the originating status to the destination status):
The conditions section allows you to set three types of user role:
The author of the release can be allowed to execute the transition. For example, when a release is marked as Completed, the author might be allowed to move it to In Progress if there is still work remaining.
The owner of the release can be allowed to execute the transition. For example, when a release is marked as In Progress, the assigned owner should be the only one who's allowed to move it to Competed.
A user with a specified role can be allowed to execute the transition regardless of whether they are the author or owner. For example a user with role \"Manager\" might want the power to defer all releases regardless of ownership status.
You can set any of these conditions by changing the drop-down list > and/or check-boxes and clicking the appropriate \"Save\" button.
"},{"location":"Spira-Administration-Guide/Template-Releases/#edit-workflow-step","title":"Edit Workflow Step","text":"When you click on the release status name link from either of the previous screens, you are taken to the workflow step details screen:
The top part of the screen is the \"workflow browser\" which illustrates how the step relates to the workflow as a whole. It displays the current release status in the middle, with the possible originating and destination transitions listed to either side. Clicking on either workflow transition name will take you to the appropriate workflow transition details page. This allows you to click through the whole workflow from start to finish without having to return to the workflow details page.
This page allows you to define the behavior of the various release fields (i.e. those that are a standard part of SpiraPlan\u00ae such as Priority):
This page also allows you to define the behavior of the various release custom properties for this particular step in the workflow:
You can set each of the fields/custom properties as being:
For example, when a release is in the Planned status, you might make the owner field hidden (since the author shouldn't need to know who will ultimately own it), when it gets to the In Progress status, you might make the field enabled and required, and when it gets to the Completed status, you might make it disabled. This allows you to tailor the information gathered to the appropriate place in the workflow.
Set the fields as desired and click \"Save\".
"},{"location":"Spira-Administration-Guide/Template-Releases/#example-workflow","title":"Example Workflow","text":"Below is a diagram that shows an example workflow (the one used by the sample product \"Library Information System\") for releases.
"},{"location":"Spira-Administration-Guide/Template-Requirements/","title":"Template: Requirements","text":"This section contains administrative options that are specific to the requirements functionality in the system.
"},{"location":"Spira-Administration-Guide/Template-Requirements/#importance","title":"Importance","text":"The following screen is displayed when you choose the \"Importance\" link from the Requirements section of the administration menu:
The screen displays a list of all the defined requirement importances for the current template. By default the screen will be populated with the standard SpiraPlan\u00ae requirement importances. To edit an existing requirement importance, change the name, color, score (this is used for ranking the different items -- the item with the lowest score will appear at the top of dropdown lists in the application), and/or change the active flag then click \"Save\".
Note that you can either enter the hexadecimal RRGGBB code for the color or use the pop-up color picker.
You can't delete an existing requirement importance, but to prevent it appearing in any drop-down-lists, change its active flag to \"No\" and click \"Save\". To add a new requirement importance, click the \"Add\" button and a new row will be added to the list which you can now edit.
"},{"location":"Spira-Administration-Guide/Template-Requirements/#statuses","title":"Statuses","text":"In beta, available in SpiraTeam and SpiraPlan only
System admins can enable beta functionality across the application for their users from the System Admin > General Settings page.
Requirement statuses are fixed. Admins cannot add or rename requirement statuses. The requirement status page lets template admins manage how these statuses are displayed to users on relevant planning boards (currently the beta planning board only).
This page shows every requirement status (in the same order you will see them on the requirement workflow pages). For each status you can:
By default, no statuses have a position or are toggled to show. In this state, the board will show all statuses that have a transition in and out (across all active workflows), in the default order.
If you turn on one or more statuses to show on boards, then those statuses will always show (whether or not they have transitions). Statuses that show and do not have a position are shown before those that do have a position. In the example below, the following statuses will show in the following order:
The following screen is displayed when you choose the \"Types\" link from the Requirements section of the administration menu:
The screen displays a list of all the defined requirement types for the current template. By default the screen will be populated with the standard SpiraPlan\u00ae requirement types. To edit an existing requirement type, change the name, associated workflow, issue check-box, risk check-box, set a default type and/or change the active flag then click \"Save\".
You can't delete an existing requirement type, but to prevent it appearing in any drop-down-lists, change its active flag to \"No\" and click \"Save\". To add a new requirement type, click the \"Add\" button and a new row will be added to the list which you can now edit.
The associated workflow drop-down list allows you to specify which workflow the requirement type will follow. This is a very powerful feature since it allows you to configure different workflows for different requirement types; i.e. a User Story may follow a simpler review process than a Feature or Use Case requirement.
The Has Steps check-box allows you to specify if the requirement type should be able to contain scenario steps (as is typical with use cases).
The default radio button allows you to specify which requirement type should be the default for newly created requirements. This is the type that a new requirement will be set to unless changed by the creator of the requirement. Note that you must have at least one active requirement type, and you cannot set an inactive type as the default.
"},{"location":"Spira-Administration-Guide/Template-Requirements/#workflows","title":"Workflows","text":"Clicking on the \"Workflow\" link under the Requirements heading, brings up the list of defined requirement workflows for the current template. A workflow is a predefined sequence of requirement statuses linked together by \"workflow transitions\" to enable a newly created requirement to be reviewed, prioritized, assigned, developed and tested, as well as to handle exception cases such as the case of a rejected or obsolete requirement. The workflow list screen for the sample template is illustrated below:
You can have as many workflows as you like in a template, but only one can be marked as the default. Each requirement type must be assigned to a workflow. To modify the name, default flag, and/or active flag of an existing workflow, change the values in the appropriate text-box, radio-button, or drop-down list and click the \"Save\" button. To add a new workflow, click the 'Add Workflow' link and a new workflow will be created with the standard SpiraPlan\u00ae steps and transitions.
Note: You cannot make a workflow inactive that is currently linked to a requirement type. This is important as all requirement types need to be linked to an active workflow at all times.
"},{"location":"Spira-Administration-Guide/Template-Requirements/#edit-workflow-details","title":"Edit Workflow Details","text":"Clicking on the 'Steps' button of a workflow brings up the following screen that lists all the workflow steps and workflow transitions that comprise the workflow:
This page lists in the left-most column all the various requirement statuses defined in the system. The next column lists all the possible transitions that can occur from that status. In addition, with each transition is listed the name of the resulting destination status that the transition leads to. E.g. from the Requested status, depending on your role (see later) the user can move the requirement to either Accepted or Under Review, depending on which transition the user takes.
Clicking on the name of a step or transition takes you to the appropriate details page (see below) where you can set the properties of the step or transition respectively. To delete an existing transition, click the 'x button after the transition name, and to add a new transition, click the 'Add Transition' button in the Operations column.
"},{"location":"Spira-Administration-Guide/Template-Requirements/#edit-workflow-transition","title":"Edit Workflow Transition","text":"When you click on the transition name link from the previous screen, you are taken to the workflow transition details screen:
The top part of the screen is the \"workflow browser\" which illustrates how the transition relates to the workflow as a whole. It displays the current transition in the middle, with the originating and destination steps listed to either side. Clicking on either requirement status name will take you to the appropriate workflow step details page. This allows you to click through the whole workflow from start to finish without having to return to the workflow details page.
This part of the screen lets you change the name of the transition. If a digital signature from the user is required to authorize and record the transition, set the toggle to yes for \"Require Electronic Signature\".
In addition, each transition has a series of conditions which need to be satisfied for a user to actually execute the transition (i.e. move the requirement from the originating status to the destination status):
The conditions section allows you to set three types of user role:
The author of the requirement can be allowed to execute the transition. For example, when a requirement is marked as Completed, the author might be allowed to move it to Obsolete when it's no longer applicable.
The owner of the requirement can be allowed to execute the transition. For example, when a requirement is marked as Under Review, the assigned owner should be the only one who's allowed to move it to Accepted.
A user with a specified role can be allowed to execute the transition regardless of whether they are the author or owner. For example a user with role \"Manager\" might want the power to close all requirements regardless of ownership status.
You can set any of these conditions by changing the drop-down list > and/or check-boxes and clicking the appropriate \"Save\" button.
"},{"location":"Spira-Administration-Guide/Template-Requirements/#edit-workflow-step","title":"Edit Workflow Step","text":"When you click on the requirement status name link from either of the previous screens, you are taken to the workflow step details screen:
The top part of the screen is the \"workflow browser\" which illustrates how the step relates to the workflow as a whole. It displays the current requirement status in the middle, with the possible originating and destination transitions listed to either side. Clicking on either workflow transition name will take you to the appropriate workflow transition details page. This allows you to click through the whole workflow from start to finish without having to return to the workflow details page.
This page allows you to define the behavior of the various requirement fields (i.e. those that are a standard part of SpiraPlan\u00ae such as Importance):
This page also allows you to define the behavior of the various requirement custom properties for this particular step in the workflow:
You can set each of the fields/custom properties as being:
For example, when a requirement is in the Requested status, you might make the owner field hidden (since the author shouldn't need to know who will ultimately own it), when it gets to the Accepted status, you might make the field enabled, and when it gets to the In Progress status, you might make it enabled and required. This allows you to tailor the information gathered to the appropriate place in the workflow.
After you have made the desired changes, click \"Save\".
"},{"location":"Spira-Administration-Guide/Template-Requirements/#example-workflow","title":"Example Workflow","text":"Below is a diagram that shows an example workflow (the one used by the sample product \"Library Information System\") for requirements.
"},{"location":"Spira-Administration-Guide/Template-Risks/","title":"Template: Risks","text":"This section contains administrative options that are specific to the risk functionality in the system.
"},{"location":"Spira-Administration-Guide/Template-Risks/#edit-types","title":"Edit Types","text":"The following screen is displayed when you choose the \"Types\" link from the Incidents section of the administration menu:
The screen displays a list of all the defined risk types for the current template. By default, the screen will be populated with the standard SpiraPlan\u00ae risk types. To edit an existing type, change the name, associated workflow, set a default type and/or change the active flag then click \"Save\".
You can't delete an existing risk type, but to prevent it appearing in any drop-down-lists, change its active flag to \"No\" and click \"Save\". To add a new type, click the \"Add\" button and a new row will be added to the list which you can now edit.
The associated workflow drop-down list allows you to specify which workflow the type will follow. This is a very powerful feature since it allows you to configure different workflows for different risk types.
The default radio button allows you to specify which type should be the default for newly created risks. This is the type that a new risk will be set to unless changed by the creator of the risk. Note that you must have at least one active risk type, and you cannot set an inactive type as the default.
"},{"location":"Spira-Administration-Guide/Template-Risks/#edit-statuses","title":"Edit Statuses","text":"The following screen is displayed when you choose the \"Statuses\" link from the Risks section of the administration menu:
The screen displays a list of all the defined risk statuses for the current template. By default, the screen will be populated with the standard SpiraPlan\u00ae risks statuses. To edit an existing status, change the name, open check-box, set it as the default status and/or change the active flag then click \"Save\".
You can't delete an existing risk status, but to prevent it appearing in any drop-down-lists, change its active flag to \"No\" and click \"Save\". To add a new risk status, click the \"Add\" button and a new row will be added to the list which you can now edit.
The open check-box allow you to specify if the risk status should be considered open or not, which means it is would be eligible for display in the various sections of the user's home page and the product home page that list open risks. The default radio button allows you to specify which risk status should be the default for newly created risks. This is the status that a new risk will be set to when first created, and acts as the first step in the risk workflow. Note that you must have at least one active status, and you cannot set an inactive status as the default.
"},{"location":"Spira-Administration-Guide/Template-Risks/#impact","title":"Impact","text":"The following screen is displayed when you choose the \"Impact\" link from the Risks section of the administration menu. The impact of a risk specifies how serious it will be if the risk happens.
The screen displays a list of all the defined risk impacts for the current template. By default, the screen will be populated with the standard SpiraPlan\u00ae risk impacts. To edit an existing impact: change the name, color, score (which is used, together with a risks probability to calculate its exposure), position, or change the active flag then click \"Save\". Note that you can either enter the hexadecimal RRGGBB code for the color or use the pop-up color picker.
You can't delete an existing impact, but to prevent it appearing in any drop-down-lists, change its active flag to \"No\" and click \"Save\". To add a new impact, click the \"Add\" button and a new row will be added to the list which you can now edit.
"},{"location":"Spira-Administration-Guide/Template-Risks/#probability","title":"Probability","text":"The following screen is displayed when you choose the \"Probability\" link from the Risks section of the administration menu:
The screen displays a list of all the defined risk probabilities for the current template. By default, the screen will be populated with the standard SpiraPlan\u00ae risk probabilities. To edit an existing probability: change the name, color, score (which is used, together with a risks impact to calculate its exposure), position, or change the active flag then click \"Save\". Note that you can either enter the hexadecimal RRGGBB code for the color or use the pop-up color picker.
You can't delete an existing risk probability, but to prevent it appearing in any drop-down-lists, change its active flag to \"No\" and click \"Save\". To add a new risk probability, click the \"Add\" button and a new row will be added to the list which you can now edit.
"},{"location":"Spira-Administration-Guide/Template-Risks/#risk-workflows","title":"Risk Workflows","text":"Clicking on the \"Workflows\" link in the Administration menu brings up the list of defined risk workflows for the current template. A workflow is a predefined sequence of risk statuses linked together by \"workflow transitions\" to enable a newly created risk to be reviewed, prioritized, assigned, resolved and closed. The workflow list screen for a sample template is illustrated below:
To modify the name, default status, notify and/or active flags, change the values in the appropriate text-box, radio-button, check-box or drop-down list and click the \"Save\" button. To add a new workflow, click the \"Add\" button and a new workflow will be created with the standard SpiraPlan\u00ae steps and transitions.
You can have as many workflows as you like in a template, but only one can be marked as the default. Each risk type is assigned to a workflow; this allows you to have different risk types follow different paths from creation of closure. However, when a new risk type is created, it will be initially associated with the template's default workflow.
Note: You can only assign an active workflow to a risk type, and similarly you cannot make a workflow inactive that is currently linked to a risk type. This is important as all risk types need to be linked to an active workflow at all times.
"},{"location":"Spira-Administration-Guide/Template-Risks/#edit-workflow-details","title":"Edit Workflow Details","text":"Clicking on the \"Steps\" button of a workflow brings up the following screen that lists all the workflow steps and workflow transitions that comprise the workflow:
This page lists in the left-most column all the various risk statuses defined for the template. The next column lists all the possible transitions that can occur from that status. In addition, with each transition is listed the name of the resulting destination status that the transition leads to. E.g. from the evaluated status, depending on your role (see elsewhere in this manual) you can move the risk to either rejected, or open depending on which transition the user takes.
Clicking on the name of a step or transition takes you to the appropriate details page (see below) where you can set the properties of the step or transition respectively. To delete an existing transition, click the \"x\" button after the transition name, and to add a new transition, click the \"Add Transition\" button in the Operations column.
"},{"location":"Spira-Administration-Guide/Template-Risks/#edit-workflow-transition","title":"Edit Workflow Transition","text":"When you click on the transition name link from the previous screen, you are taken to the workflow transition details screen:
The top part of the screen is the \"workflow browser\" which illustrates how the transition relates to the workflow as a whole. It displays the current transition in the middle, with the originating and destination steps listed to either side. Clicking on either risk status name will take you to the appropriate workflow step details page. This allows you to click through the whole workflow from start to finish without having to return to the workflow details page.
If a digital signature from the user is required to authorize and record the transition, set the toggle to yes for \"Require Electronic Signature\".
Each transition has a series of conditions which need to be satisfied for a user to actually execute the transition (i.e. move the incident from the originating status to the destination status).
"},{"location":"Spira-Administration-Guide/Template-Risks/#edit-workflow-step","title":"Edit Workflow Step","text":"When you click on the incident status name link from either of the previous screens, you are taken to the workflow step details screen:
The top part of the screen is the \"workflow browser\" which illustrates how the step relates to the workflow as a whole. It displays the current risk status in the middle, with the possible originating and destination transitions listed to either side. Clicking on either workflow transition name will take you to the appropriate workflow transition details page. This allows you to click through the whole workflow from start to finish without having to return to the workflow details page.
This page allows you to define the behavior of the various risk fields (i.e. those that are a standard part of SpiraPlan\u00ae such as probability):
This page also allows you to define the behavior of the various risk custom properties for this particular step in the workflow:
You can set each of the fields/custom properties as being:
After you have made the desired changes, click \"Save\".
"},{"location":"Spira-Administration-Guide/Template-Risks/#example-workflow","title":"Example Workflow","text":"Below is a diagram that shows an example workflow (the one used by the sample product \"Library Information System\") for risks.
"},{"location":"Spira-Administration-Guide/Template-Tasks/","title":"Template: Tasks","text":"This section contains administrative options that are specific to task functionality in the system.
"},{"location":"Spira-Administration-Guide/Template-Tasks/#priority","title":"Priority","text":"The following screen is displayed when you choose the \"Priority\" link from the Tasks section of the administration menu:
The screen displays a list of all the defined task priorities for the current template. By default, the screen will be populated with the standard SpiraPlan\u00ae task priorities. To edit an existing task priority, change the name, color, score (this is used for ranking the different items -- the item with the lowest score will appear at the top of dropdown lists in the application), and/or change the active flag then click \"Save\".
Note that you can either enter the hexadecimal RRGGBB code for the color or use the pop-up color picker.
You can't delete an existing task priority, but to prevent it appearing in any drop-down-lists, change its active flag to \"No\" and click \"Save\". To add a new task priority, click the \"Add\" button and a new row will be added to the list which you can now edit.
"},{"location":"Spira-Administration-Guide/Template-Tasks/#types","title":"Types","text":"When you choose the \"Types\" link from the Tasks section of the administration menu you will see the following page:
The page shows a list of all the defined task types for the current template. By default, the screen will be populated with the standard SpiraPlan\u00ae task types and only show the active types. To view inactive or all types, use the \"Displaying\" dropdown near the top.
You can change the following information about each type:
To add a new type, click the \"Add\" button and a new row will be added to the list for you to edit.
Once you have made any changes you need to make, click \"Save\".
"},{"location":"Spira-Administration-Guide/Template-Tasks/#task-workflows","title":"Task Workflows","text":"Clicking on the \"Task Workflows\" link under the Planning heading, brings up the list of defined task workflows for the current template. A workflow is a predefined sequence of task statuses linked together by \"workflow transitions\" to enable a newly created task to be reviewed, prioritized, assigned, developed and tested, as well as to handle exception cases such as the case of a blocked or deferred task. The workflow list screen for the sample template is illustrated below:
You can have as many workflows as you like in a template, but only one can be marked as the default. Each task type must be assigned to a workflow. To modify the name, default flag, and/or active flag of an existing workflow, change the values in the appropriate text-box, radio-button, or drop-down list and click the \"Save\" button. To add a new workflow, click the 'Add Workflow' link and a new workflow will be created with the standard SpiraPlan\u00ae steps and transitions.
Note: You can only assign an active workflow to a task type, and similarly you cannot make a workflow inactive that is currently linked to a task type. This is important as all task types need to be linked to an active workflow at all times.
"},{"location":"Spira-Administration-Guide/Template-Tasks/#edit-workflow-details","title":"Edit Workflow Details","text":"Clicking on the 'Steps' hyperlink of a workflow brings up the following screen that lists all the workflow steps and workflow transitions that comprise the workflow:
This page lists in the left-most column all the various task statuses defined in the system. The next column lists all the possible transitions that can occur from that status. In addition, with each transition is listed the name of the resulting destination status that the transition leads to. E.g. from the Not Started status, depending on your role (see later) the user can move the task to either Deferred or In Progress, depending on which transition the user takes.
Clicking on the name of a step or transition takes you to the appropriate details page (see below) where you can set the properties of the step or transition respectively. To delete an existing transition, click the 'x button after the transition name, and to add a new transition, click the 'Add Transition' button in the Operations column.
"},{"location":"Spira-Administration-Guide/Template-Tasks/#edit-workflow-transition","title":"Edit Workflow Transition","text":"When you click on the transition name link from the previous screen, you are taken to the workflow transition details screen:
The top part of the screen is the \"workflow browser\" which illustrates how the transition relates to the workflow as a whole. It displays the current transition in the middle, with the originating and destination steps listed to either side. Clicking on either task status name will take you to the appropriate workflow step details page. This allows you to click through the whole workflow from start to finish without having to return to the workflow details page.
This part of the screen lets you change the name of the transition. If a digital signature from the user is required to authorize and record the transition, set the toggle to yes for \"Require Electronic Signature\".
In addition, each transition has a series of conditions which need to be satisfied for a user to actually execute the transition (i.e. move the task from the originating status to the destination status):
The conditions section allows you to set three types of user role:
The author of the task can be allowed to execute the transition. For example, when a task is marked as Completed, the author might be allowed to move it to In Progress if there is still work remaining.
The owner of the task can be allowed to execute the transition. For example, when a task is marked as In Progress, the assigned owner should be the only one who's allowed to move it to Competed.
A user with a specified role can be allowed to execute the transition regardless of whether they are the author or owner. For example a user with role \"Manager\" might want the power to defer all tasks regardless of ownership status.
You can set any of these conditions by changing the drop-down list > and/or check-boxes and clicking the appropriate \"Save\" button.
"},{"location":"Spira-Administration-Guide/Template-Tasks/#edit-workflow-step","title":"Edit Workflow Step","text":"When you click on the task status name link from either of the previous screens, you are taken to the workflow step details screen:
The top part of the screen is the \"workflow browser\" which illustrates how the step relates to the workflow as a whole. It displays the current task status in the middle, with the possible originating and destination transitions listed to either side. Clicking on either workflow transition name will take you to the appropriate workflow transition details page. This allows you to click through the whole workflow from start to finish without having to return to the workflow details page.
This page allows you to define the behavior of the various task fields (i.e. those that are a standard part of SpiraPlan\u00ae such as Priority):
This page also allows you to define the behavior of the various task custom properties for this particular step in the workflow:
You can set each of the fields/custom properties as being:
For example, when a task is in the Not Started status, you might make the owner field hidden (since the author shouldn't need to know who will ultimately own it), when it gets to the In Progress status, you might make the field enabled and required, and when it gets to the Completed status, you might make it disabled. This allows you to tailor the information gathered to the appropriate place in the workflow.
After you have made the desired changes, click \"Save\".
"},{"location":"Spira-Administration-Guide/Template-Tasks/#example-workflow","title":"Example Workflow","text":"Below is a diagram that shows an example workflow (the one used by the sample product \"Library Information System\") for tasks.
"},{"location":"Spira-Administration-Guide/Template-Test-Cases/","title":"Template: Test Cases","text":"This section contains administrative options that are specific to the testing functionality in the system.
"},{"location":"Spira-Administration-Guide/Template-Test-Cases/#priority","title":"Priority","text":"The following screen is displayed when you choose the \"Priority\" link from the Test Cases section of the administration menu:
The screen displays a list of all the defined test case priorities for the current template. By default, the screen will be populated with the standard SpiraPlan\u00ae test case priorities. To edit an existing test case priority, change the name, color, score (this is used for ranking the different items -- the item with the lowest score will appear at the top of dropdown lists in the application), and/or change the active flag then click \"Save\".
Note that you can either enter the hexadecimal RRGGBB code for the color or use the pop-up color picker.
You can't delete an existing test case priority, but to prevent it appearing in any drop-down-lists, change its active flag to \"No\" and click \"Save\". To add a new test case priority, click the \"Add\" button and a new row will be added to the list which you can now edit.
"},{"location":"Spira-Administration-Guide/Template-Test-Cases/#types","title":"Types","text":"The following screen is displayed when you choose the \"Types\" link from the Test Cases section of the administration menu:
The screen displays a list of all the defined test case types for the current template. By default, the screen will be populated with the standard SpiraPlan\u00ae test case types. To edit an existing test case type, change the name, associated workflow, issue check-box, risk check-box, set a default type and/or change the active flag then click \"Save\".
You can't delete an existing test case type, but to prevent it appearing in any drop-down-lists, change its active flag to \"No\" and click \"Save\". To add a new test case type, click the \"Add\" button and a new row will be added to the list which you can now edit.
The associated workflow drop-down list allows you to specify which workflow the test case type will follow. This is a very powerful feature since it allows you to configure different workflows for different test case types; i.e. a User Story may follow a simpler review process than a Feature or Use Case test case.
The Is Exploratory check-box allows you to specify if the test case type should be able to be executed in exploratory mode (which allows more editing of the test case and its steps during execution). Note that this mode is only available to users with a certain permission level and when executing an individual test case.
The default radio button allows you to specify which test case type should be the default for newly created test cases. This is the type that a new test case will be set to unless changed by the creator of the test case. Note that you must have at least one active test case type, and you cannot set an inactive type as the default.
"},{"location":"Spira-Administration-Guide/Template-Test-Cases/#test-case-workflows","title":"Test Case Workflows","text":"Clicking on the \"Workflows\" link under the Test Cases section, brings up the list of defined test case workflows for the current template. A workflow is a predefined sequence of test cases statuses linked together by \"workflow transitions\" to enable a newly created test case to be reviewed, prioritized, assigned, and tested, as well as to handle exception cases such as the case of a rejected or obsolete test case. The workflow list screen for the sample template is illustrated below:
You can have as many workflows as you like in a template, but only one can be marked as the default. Each test case type must be assigned to a workflow. To modify the name, default flag, and/or active flag of an existing workflow, change the values in the appropriate text-box, radio-button, or drop-down list and click the \"Save\" button. To add a new workflow, click the 'Add Workflow' link and a new workflow will be created with the standard SpiraPlan\u00ae steps and transitions. The steps and transitions that make up the default workflow are illustrated in the diagram below:
flowchart LR\n Draft --> Rejected;\n Draft <--> Ready-for-Review;\n Ready-for-Review <--> Approved;\n Ready-for-Review <--> Rejected;\n Approved <--> Ready-for-Test;\n Ready-for-Test <--> Obsolete;Note: You can only assign an active workflow to a test case type, and similarly you cannot make a workflow inactive that is currently linked to a test case type. This is important as all test case types need to be linked to an active workflow at all times.
"},{"location":"Spira-Administration-Guide/Template-Test-Cases/#edit-workflow-details","title":"Edit Workflow Details","text":"Clicking on the 'Steps' button of a workflow brings up the following screen that lists all the workflow steps and workflow transitions that comprise the workflow:
This page lists in the left-most column all the various test case statuses defined in the system. The next column lists all the possible transitions that can occur from that status. In addition, with each transition is listed the name of the resulting destination status that the transition leads to. E.g. from the Draft status, depending on your role (see elsewhere in this manual) the user can move the test case to either Rejected, or Ready for Review, depending on which transition the user takes.
Clicking on the name of a step or transition takes you to the appropriate details page (see below) where you can set the properties of the step or transition respectively. To delete an existing transition, click the 'x button after the transition name, and to add a new transition, click the 'Add Transition' button in the Operations column.
"},{"location":"Spira-Administration-Guide/Template-Test-Cases/#edit-workflow-transition","title":"Edit Workflow Transition","text":"When you click on the transition name link from the previous screen, you are taken to the workflow transition details screen:
The top part of the screen is the \"workflow browser\" which illustrates how the transition relates to the workflow as a whole. It displays the current transition in the middle, with the originating and destination steps listed to either side. Clicking on either task status name will take you to the appropriate workflow step details page. This allows you to click through the whole workflow from start to finish without having to return to the workflow details page.
This part of the screen lets you change the name of the transition. If a digital signature from the user is required to authorize and record the transition, set the toggle to yes for \"Require Electronic Signature\".
In addition, each transition has a series of conditions which need to be satisfied for a user to actually execute the transition (i.e. move the test case ease from the originating status to the destination status):
The conditions section allows you to set three types of user role:
The author of the test case can be allowed to execute the transition. For example, when a test case is marked as Ready for Review, the author might be allowed to move it to Ready to Test.
The owner of the test case can be allowed to execute the transition. For example, when a test case is marked as Approved, the assigned owner should be the only one who's allowed to move it to Ready for Test.
A user with a specified role can be allowed to execute the transition regardless of whether they are the author or owner. For example a user with role \"Manager\" might want the power to approve all test cases regardless of ownership status.
You can set any of these conditions by changing the drop-down list > and/or check-boxes and clicking the appropriate \"Save\" button.
"},{"location":"Spira-Administration-Guide/Template-Test-Cases/#edit-workflow-step","title":"Edit Workflow Step","text":"When you click on the test case status name link from either of the previous screens, you are taken to the workflow step details screen:
The top part of the screen is the \"workflow browser\" which illustrates how the step relates to the workflow as a whole. It displays the current test case status in the middle, with the possible originating and destination transitions listed to either side. Clicking on either workflow transition name will take you to the appropriate workflow transition details page. This allows you to click through the whole workflow from start to finish without having to return to the workflow details page.
This page allows you to define the behavior of the various test case fields (i.e. those that are a standard part of SpiraPlan\u00ae such as Priority):
This page also allows you to define the behavior of the various test case custom properties for this particular step in the workflow:
You can set each of the fields/custom properties as being:
For example, when a test case is in the Draft status, you might make the owner field hidden (since the author shouldn't need to know who will ultimately own it), when it gets to the Ready for Review status, you might make the field enabled and required, and when it gets to the Approve status, you might make it disabled. This allows you to tailor the information gathered to the appropriate place in the workflow.
After you have made the desired changes, click \"Save\".
Note that two test case fields have special meanings:
Below is a diagram that shows an example workflow (the one used by the sample product \"Library Information System\") for test cases.
"},{"location":"Spira-Administration-Guide/Testing-Settings/","title":"Testing Settings","text":"In 6.5.2 this page moved here.
"},{"location":"Spira-User-Manual/","title":"Welcome to the SpiraPlan User Manual","text":"How to use this manual
This documentation is designed for all users of SpiraTest, SpiraTeam, or SpiraPlan.
It can be read 'cover to cover' or you can dip into a specific section for key information.
To find the section you need, open the \"User Manual\" section from the site navigation to see all available chapters.
This manual is built around a few core areas:
The Product section is by far the biggest part of this manual. This section is further divided up into 5 areas: planning, testing, developing, tracking, reporting. These areas mirror how you navigate around a product inside SpiraPlan itself.
"},{"location":"Spira-User-Manual/Appendix-1-Keyboard-Shortcuts/","title":"Appendix 1: Keyboard Shortcuts","text":"SpiraPlan\u00ae includes an array of keyboard shortcuts to speed up navigation and use of the application. All functionality can be performed using a mouse and clicking and therefore using a keyboard shortcut is never required. However, keyboard shortcuts can be an efficient way of performing common tasks. A list of the keyboard shortcuts and what they do is available throughout the application in two ways:
There are two main ways of using the shortcuts: either pressing a key or key(s) at the same time (indicated by a single key or \"a + b\"); or pressing a number of keys in succession as with normal typing (indicated by \"a ... b\"). The popup menu explaining the shortcuts is illustrated below (please note that the keyboard shortcuts displayed will vary depending on the current page:
"},{"location":"Spira-User-Manual/Application-Wide/","title":"Common Elements Across the Application","text":"There are lots of different artifacts in the application (described here). This means each artifact has its own settings, uses, and logical links to other artifacts, and reporting. Each artifact is different but they also share many similarities. These are explained below.
"},{"location":"Spira-User-Manual/Application-Wide/#artifact-list-pages","title":"Artifact List Pages","text":"When you first visit an artifact section in the app (by clicking on the relevant link in the global navigation bar), you will be taken to the artifact list page. This may look something like below (this image is of the requirements list page) with a grid of data - each row representing a single artifact, and often a sidebar on the left with charts or links:
"},{"location":"Spira-User-Manual/Application-Wide/#filtering","title":"Filtering","text":"You can easily filter artifact lists as you can see in the screen-shot below. Here, we are filtering Requirements by the status \"Requested\":
To filter the list:
Filter icon or press the ENTER key to apply the filtersNote that the NAME field is searched using a \"like\" comparison, so that searching for \"database\" would match \"Database is ready\", \"There is a database\", \"The data in the database is correct\", and so on. All other freetext fields need to be exact matches (e.g. dates or numbers).
To clear the current filter (whether it is saved or not), either click the Clear Filters button above the table (as you can see in the screenshot above), or go to Filter > Clear Filter from the operations toolbar.
You can do a number of things with filters. First let's talk about using the Filters button on the operations toolbar (at the top of the page just below the main navigation bar).
To reuse a filter, save it by going to Filter > Save Filter from the operations toolbar. Give your new filter a name and click Save.
By default, when you save a filter it will also save your column selection information. Uncheck the box next to \"Save the column selection with the filter\" if you do not want to save this information.
When you apply a saved filter with column selection information, the system will show the specific columns visible (including their relative ordering and width) to match those in the filter. This means that you can Show/Hide different columns, filter on them, and save the entire combination as a saved view. When you switch between saved views, the system will show/hide and reposition the columns associated with the view automatically.
To share the filter with other members of the product, in the Save Filter dialog, check the box next to \"Share with other members of the product\".
To update an existing filter, go to Filter > Save Filter and click on Update Existing. You will see a dropdown of all your saved filters. Pick one, and then click Save. This will update the filter itself, any sort applied, whether it is shared or not, or if it should save the column selection with the filter.
To see your saved filters for this artifact, go to Filter > Retrieve Filter. Apply the filter by selecting it.
From your \"My Page\" you can see all your save filters across all artifacts and products. You can also delete any filter from there. This is all through the My Saved Searches widget.
"},{"location":"Spira-User-Manual/Application-Wide/#quick-filter-side-panel","title":"Quick Filter Side Panel","text":"As a shortcut, the left hand panel on artifact list pages includes a set of Quick Filters. Click the name of the filter in this panel to apply it. This panel is NOT visible for list pages that do not have a side panel at all - i.e. Releases, Automation Hosts, Test Configurations, and Resources.
The quick filter panel shows a list of all saved filters created by you (with an icon of a person) or shared by others (with an icon of a group of people) for the current artifact.
For Requirements, Test Cases, Incidents, Risks, and Tasks the quick filter panel also shows a list of Components for the current product. Picking a component will filter the list to only show those associated with that component.
For Requirements and Test Runs the quick filter panel additionally shows a dropdown for Releases. Picking a release will filter the list to only show items that are set for that particular release.
"},{"location":"Spira-User-Manual/Application-Wide/#sorting","title":"Sorting","text":"Many artifact lists let you sort by a specific column (either ascending or descending). To change the column being sorted, click on the up or down arrow icon next to the title of that column. Click the other icon will reverse the sort order. The currently sorted column is indicated by the darker arrow. When you save a filter it will always save the selected sort.
"},{"location":"Spira-User-Manual/Application-Wide/#show-hide-columns","title":"Show / Hide Columns","text":"This drop-down list allows you to change the fields that are displayed in the artifact list as columns for the current product. To show a column that is not already displayed, simply select that column from the list of \"Show...\" column names and to hide an existing column, simply select that column from the list of \"Hide...\" column names. This is stored on a per-product basis, so you can have different display settings for each product that you are a member of. The fields can be any of the built-in fields or any of the custom properties set up by the product owner.
"},{"location":"Spira-User-Manual/Application-Wide/#right-click-context-menu","title":"Right-Click Context Menu","text":"SpiraPlan\u00ae provides a shortcut -- called the context menu - for accessing some of the most commonly used functions, so that you don't need to move your mouse up to the toolbar each time. To access the context menu, right-click on any of the rows in the artifacts list and the following menu will be displayed (the one below is specific to requirements - different artifacts have different options in the context menu):
"},{"location":"Spira-User-Manual/Application-Wide/#export-to-another-product","title":"Export to Another Product","text":"You can export the following artifacts from the current product to any other product that you have access to:
The artifacts will be exported from the current product to the destination product. Any file attachments will also be copied to the destination product. If the destination product uses the same product template then standard and custom fields will be copied over in full - but this will not necessarily be possible if the destination product uses a different product (the system will try and match up fields as best it can).
Note: when exporting a requirement that has children, the requirement itself and all of its children are exported to the destination product.
To export one or more of a particular artifact:
Tools > Export to Product from the toolbarExportTo view details about a specific artifact, you need to go to the artifact's detail page. Clicking on an item on the artifact list page will open the corresponding detail page.
Most of these details pages are made up of three areas;
the left pane with artifact list navigation options and information
the right pane's header, which displays: the operations toolbar; the editable name of the selected artifact; and the info bar (with a shaded background), which also contains the workflow status transitions
the right pane's tabbed interface with rich information related to the artifact
Please note that on smaller screen sizes the left navigation pane is not displayed. While the navigation pane has a link to take you back to the artifact list, on mobile devices a 'back' button is shown on the left of the operations toolbar.
The navigation pane can be collapsed by clicking on the \"-\" button, or expanded by clicking anywhere on the gray title area. On desktops the user can also control the exact width of the navigation pane by dragging and dropping a red handle that appears on hovering at the rightmost edge of the navigation pane.
The navigation pane often shows a list of the peer artifacts to the one selected. This list is useful as a navigation shortcut.
"},{"location":"Spira-User-Manual/Application-Wide/#breadcrumbs","title":"Breadcrumbs","text":"For folders and hierarchical / tree view artifacts at the top of the details page right hand side you will see the breadcrumb trail, where relevant.
If the artifact you are looking at is in a folder, above its name you will see a breadcrumb trail for the full folder path. It will be in the form of Grandparent Folder / Parent Folder. You can click on any part of this breadcrumb / path to navigate to that folder.
Artifacts that have folders are: documents, test cases, test sets, and tasks.
Requirements and releases exist in a hierarchy with other requirements and releases. For these you will also see a breadcrumb, but instead of showing folders it will show the hierarchy to the container requirements or releases. Clicking on the breadcrumb link will take you to the specific requirement or release clicked on.
Tip: when navigating to folders (for all artifacts that support them), the URL in your browser's address bar will change. Each folder has a unique, sharable URL that you can give to someone to display the list of artifacts with the appropriate folder selected. You can also open up multiple folders in different browser tabs and easily toggle between them from the same browser.
"},{"location":"Spira-User-Manual/Application-Wide/#workflows","title":"Workflows","text":"A number of artifacts can be controlled using workflows (these include requirements, releases, test cases, documents, risks, incidents, and tasks). Depending on the user's role and whether they are listed as the owner or author of the artifact, displayed in the info bar beneath the artifact name is the current workflow status and an Operations button. When you click this button you will see a set of allowed workflow operations - called transitions (below we are looking at that for a requirement):
These workflow transitions specify, given a starting status, which statuses you can move the artifact to. After changing the status of the artifact by clicking on a transition, the form on the overview tab may change. Different fields may be visible, enabled, or required.
For example, a requested requirement has its \"Release\" field hidden, but once the requirement is planned, that release field is visible and required. The types of change allowed and the fields that are enabled/visible/required will depend on how your product administrator has set up the workflow. Administrators should refer to the Administration Guide for details on configuring workflows.
Once you've made the changes to the appropriate artifact fields, you can either click \"Save\", \"Save and Close\", or \"Save and New\" to commit the changes or \"Refresh\" to discard the changes and reload the artifact from the database. In addition you can print the current artifact by clicking \"Print\", which will display a printable version of the page in a separate window.
Workflows are managed by the product's template. Read more about workflow administration for:
Any workflow transition (moving from one status to another) can be set to require an electronic signature. If enabled for a particular workflow operation an electronic signature is required to confirm the status change. Confirmation requires entering the users password, and a message explaining the meaning of this operation.
Workflow operations requiring a digital signature are marked with a padlock icon:
On attempting to save changes made after clicking a workflow operation that requires a digital signature you will be presented with a popup like the one below:
How to digitally sign if using OAuth
If you login to Spira using an OAuth / Single Sign On provider like Google or Okta, instead of entering your password use your RSS Key. This is visible on your My Profile page.
"},{"location":"Spira-User-Manual/Application-Wide/#emailing","title":"Emailing","text":"Using the \"Email\" button on the toolbar, you can send an email containing details of the artifact to an email address or another user on the system:
You can specify the subject line for the email, and either a list of email addresses, separated by semicolons, or an existing product user. The content of the email is specified in the product template's Notification Templates. Notification events can also be set up to automatically email users meeting specific conditions whenever a certain event happens (eg a particular field changes).
"},{"location":"Spira-User-Manual/Application-Wide/#followers","title":"Followers","text":"To be notified of any changes made to the current artifact via email, click the \"Subscribe\" button. If you already subscribed, the button will instead let you \"Unsubscribe\" to stop receiving emails about that particular artifact. Depending on your role, you may also see a dropdown arrow to the right of this button. This will let you subscribe others in the product to this artifact.
You can also quickly see who is following an artifact under the \"People\" section in the Overview tab.
To view information about the follower, or to unfollow them from the item, hover over their avatar to display a user profile card.
"},{"location":"Spira-User-Manual/Application-Wide/#overview","title":"Overview","text":"The Overview tab is divided into a number of different sections. Each of these can be collapsed or expanded by clicking on the title of that section. This tab displays information about all the main fields of the artifact, as well as descriptions, comments, and other information.
Many artifacts have a comments section that allows you to add and view discussions relating to the artifact:
Existing comments are displayed in order underneath the textbox in date order (either newest first or oldest first). To add a new comment, enter it into the textbox, and click the \"Add Comment\" button.
"},{"location":"Spira-User-Manual/Application-Wide/#comments","title":"Comments","text":"The Comments section of an artifact lets you add and view comments related to that artifact:
There are two parts to comments:
Viewing existing comments:
Adding a new comment:
Deleting comments: Users can delete comments that were made in error or that are no longer relevant. Who can delete what comments?
Note that certain system created comments \"permanent\" and cannot be deleted, even by system administrators. For example, comments are added when you create a test case from a use case and are marked as \"permanent\" behind the scenes.
"},{"location":"Spira-User-Manual/Application-Wide/#attachments","title":"Attachments","text":"The attachment tab displays the list of documents, screenshots or web-links (URLs) that have been \"attached\" to the artifact. The documents can be in any format, though SpiraPlan\u00ae will only display icons for certain known types.
The attachment list includes the filename/URL that was originally uploaded together with the file-size (in KB), name of the person who attached it and the date uploaded. In addition, if you position the pointer over the filename and hold it there for a few seconds, a detailed description is displayed as a tooltip.
To actually view the document, click on the filename hyperlink and a new web browser window will open. Depending on the type of file, this window will either display the document / web-page or prompt you for a place to save it on your local computer. To remove an existing attachment from an artifact, click the \"Remove\" button and the attachment will be removed from the list. Using the standard filter/sort options you can also sort and filter the list of attachments to make it more manageable.
If you are using SpiraPlan or SpiraTeam (but not SpiraTest) you can also choose to include file attachments stored in a linked version control system (e.g. Git, Subversion, CVS, Perforce, etc.) by selecting the \"Include Source Code Documents\" option.
To attach a new document to the artifact, you need to first click the \"Add New\" button to display the new attachment dialog box:
There are three different types of item that can be attached to an artifact:
To upload a file, choose \"File\" as the type and then click the Browse button and select the file from your local computer, optionally enter a detailed description then click the \"Upload\" button. The document will be copied from your computer and attached to the artifact.
To attach a web-link (URL) to the artifact, you need to choose \"URL\" as the type and then enter the fully qualified URL (e.g. http://mywebsite.com?Document=1), an optional description and then click the \"Upload\" button to attach the web-link.
To attach a screenshot to the artifact, you need to choose \"Screenshot\" as the type and then copy the image to your computer's clipboard (e.g. on Windows computers, the PRINT SCREEN button captures the current page and adds to the clipboard). Once the image is in the clipboard, paste it into the editor using CTRL+V (or the equivalent keystroke for your operating system) and the item will appear in the preview window. You can then fill in the other fields and click \"Upload\" to attach the image.
Note: If you are using a non-Windows\u00ae computer (e.g. Macintosh\u00ae) that doesn't put file extensions on filenames (e.g. .xls for an Excel sheet) automatically, then you will need to manually add the file extension to the filename before uploading if you want it to be displayed with the correct icon in the attachment list.
You can also associate an existing document (that's already stored in SpiraPlan) with the artifact. To do that, click on the \"Add Existing\" button to bring up the add file association dialog box:
You can then choose to either associate a document stored in the SpiraPlan Documents repository or (in the case of SpiraPlan/SpiraTeam but not SpiraTest) from the linked source code repository. In either case you first select the appropriate folder, and then pick the document(s) from the file list on the right. In the case of a source code file association you can also add a comment.
"},{"location":"Spira-User-Manual/Application-Wide/#history","title":"History","text":"This tab displays the list of changes that have been performed on the artifact since its creation. An example change history for a requirement is shown below:
The change history displays the date that each change was made, together with the fields that were changed, the old and new values and the person who made the change. This allows a complete audit trail to be maintained of all changes in the system. In addition, if you are logged in as a product administrator you can also click on the \"Admin View\" hyperlink to revert any unwanted changes.
"},{"location":"Spira-User-Manual/Application-Wide/#associations","title":"Associations","text":"You can associate artifacts to one another. For instance, you can associate (or link) one requirement to another requirement, or a test case to a risk. The following artifacts have association tabs:
From the associations tab you can see and manage the list of artifacts associated with the specific artifact you are looking at. You can even make links between artifacts across different products (if the admin has set this up). The image below shows the association tab for a requirement.
The requirements and risks in this list are those a user has decided are relevant to the current artifact. They therefore created a direct link between them.
Each association is for product level associations displayed with the:
In addition, when using SpiraPlan or SpiraTeam, the system automatically scans the source code repository for any commits, across all branches, that are linked to this artifact.
You can perform the following actions on the list of associations:
To create a new association, click the \"Add\" button to display the add association panel (below is an example from requirements):
If you know the ID of the artifact you want to associate, you can enter its ID prefixed by the appropriate token (eg \"RQ\" for requirement):
Otherwise choose the Artifact Type (and Product if making a cross-product association) from the dropdowns:
You can narrow down your search by entering a keyword:
Artifacts that have folders let you choose a folder to narrow your search. When attempting to add an association to a requirement, you can choose a parent requirement from the list to narrow down the results:
Once you have a list of artifacts, select the checkboxes of the items you want to associate with the current artifact and click the 'Save' button.
You can add a comment that explains the rationale for the association and choose the type of association being created:
What can you associate to what?
Assocation Tab Of Available artifacts Documents Requirements, Releases, Test Cases, Test Sets, Test Runs, Test Steps, Automation Hosts, Tasks, Incidents, Risks Incidents Requirements, Test Steps, Tasks, Incidents, Risks Releases Releases, Requirements Requirements Releases, Requirements, Incidents, Risks Risks Requirements, Incidents, Risks, Test Cases Source code commits Requirements, Releases, Test Cases, Test Sets, Test Runs, Test Steps, Automation Hosts, Tasks, Incidents, Risks Source code files Requirements, Releases, Test Cases, Test Sets, Test Runs, Test Steps, Automation Hosts, Tasks, Incidents, Risks Tasks Tasks, Incidents Test cases (in SpiraTeam and SpiraPlan only) Tasks, Risks Program Capabilities (SpiraPlan only) Requirements (the tab is called requirements, comments and association type not supported) Program Milestones (SpiraPlan only) Releases (the tab is called releases, comments and association type not supported)"},{"location":"Spira-User-Manual/Application-Wide/#rich-text-editor","title":"Rich Text Editor","text":"There are two ways to enter and edit text in SpiraPlan: plain text or rich text. Plain text is used for short and simple text - like artifact names, instant messages, or short notes in custom properties. When users need to enter more text and style it in a particular way, they use the built-in rich text editor. This is used for artifact descriptions and comments, as well dedicated rich text documents in the Documents Repository. Rich text fields can be as long as you need, and can replace traditional documents entirely.
SpiraPlan's rich text editor is responsive, fully featured, and intuitive to use. As such, it does not require special instruction. For information, below is a list of supported features in the rich text editor.
Formatting options:
Inserting content:
Images and screenshots
Tables using the powerful table editor. After table creation you can:
code blocks
seperator lines
Editing content: use the magnifying glass button on the toolbar to access find and replace functionality.
In many places the editor can also be made full screen to help editing of larger documents. To enter full screen mode, click on the computer monitor icon at the far right of the toolbar. Are you using dark mode? No problem - the editor works great in dark mode.
"},{"location":"Spira-User-Manual/Application-Wide/#beta-boards","title":"Beta Boards","text":"In beta, available in SpiraTeam and SpiraPlan
System admins can enable beta functionality across the application for their users from the System Admin > General Settings page.
To access the beta board, navigate to the relevant board as normal. This loads the standard planning or artifact board. Then click on the \"Try the Beta\" button the top-right to go to the new beta board.
You will now stay on the beta boards for the remainder of your session. To leave the beta, click on \"Exit the Beta\". This will return you to the old boards.
"},{"location":"Spira-User-Manual/Application-Wide/#page-structure","title":"Page Structure","text":"The beta boards are designed to provide a consistent user interface across its different views and:
The board pages are structured like this (in this example we are looking at the Planning Board but the high level features and layout is consistent across all boards):
Boards have the option to have multiple, separate boards displayed. This is used when you want to display a complete board for each item in a selection (for example each release). Inside each group, the rows and columns will show based on your selections. For example, when you are displaying the Release Backlog on the Planning Board, you may want to group by release. In the screenshot below of the Planning Board we have columns set to status, and rows to component
There are buttons in the header area of each group that let you:
Additionally, at the top of all the groups, there are buttons to expand/collapse all groups at once.
"},{"location":"Spira-User-Manual/Application-Wide/#board-columns","title":"Board Columns","text":"Inside each of the boards you can choose to organize the cards by column. Unlike groups and rows, this selection is required. For example, in the screenshot below we are displaying the Planning Board's product backlog with columns set to \"priority\".
There are no expand/collapse buttons for columns.
"},{"location":"Spira-User-Manual/Application-Wide/#board-rows","title":"Board Rows","text":"Inside each of the boards you can organize the cards into rows. This is optional. For example, in the screenshot below we are displaying the Planning Board' product backlog with rows set to \"parent\". In the example, the grouping is by component and the board is smart enough to know that it should only show you those parents in rows that are tagged with that component (so different component groups will show different parent requirements as their rows).
Note that when rows is set to parent / parent requirement, rows are also included for parents with no unplanned children.
There are buttons by the title of each row that let you expand/collapse that row.
"},{"location":"Spira-User-Manual/Application-Wide/#board-viewing-by-release-or-sprint","title":"Board Viewing by release or sprint","text":"When organizing by release or sprint there are a number of special features available in the header row (where you see the release/sprint name).
The group title will show additional information about the release or sprint on the right hand side of the group header. Hover on the group header to see this information in full. This shows:
When you move a card between releases or sprints, the fields described above may be recalculated. For effort fields, all child tasks of requirements in that release/sprint are used for calculations. For example, moving a requirement on a board into a sprint will increase the sprint's utilized effort by the hours of the relevant tasks in that requirement, and decrease the sprint's remaining effort by the same amount.
"},{"location":"Spira-User-Manual/Application-Wide/#board-viewing-by-person","title":"Board Viewing by Person","text":"When organizing by person there are a number of special features available in the header row (where you see the person's name).
Grouping by team and rows by person
When grouping by team, there is one group for every team. If rows is set to \"by person\", then within each team, all members of that team are shown. So if Amy is a member of the dev team, they will have a row in the dev team group and not in any other group.
"},{"location":"Spira-User-Manual/Application-Wide/#board-what-cards-show-when","title":"Board what cards show when","text":"What cards show on the board depends on how the viewing controls are set. In additional the following broad principles apply:
requirement cards:
Cards can be moved between any cell on the board a card is currently in. You can also move cards between groups, if you are grouping by a particular field. Moving a card updates all relevant fields about that item. For instance, moving a card to a different row and column will change that cards values for both fields at once.
You can also move cards within a cell to change their order. When you drop a card, it will be inserted between the relevant cards in the cell, or at the top or bottom of the list. Moving a card between cells and dropping the card within a list of cards will place the card in that exact position.
Click on a card to select it. Click on more cards to add them to your selection. Then click and drag on any selected to move them together.
Things to be aware of
Cards are disabled (cannot be moved) if any of the following are true:
Viewing cards: to view more information about the card you can click on the card's name to open a popup with much more detail; or ctrl/cmd+click on the card's name to open the full details page for that artifact. Information shown in the popup includes all standard and custom fields with fields being shown or hidden based on the workflow step that applies to that specific card. Users who cannot bulk edit the artifact but who can add comments can add comments when viewing the card.
Editing cards: users with bulk edit permissions can edit a planning board card at any time by clicking on the card's name (this includes letting you add a new comment). This opens a popup with full information about that card. At all times, which fields are shown, required, or hidden is based on the workflow step that applies to that specific card. To save any changes you must fill in all required fields. Please note: you cannot change the status in this edit mode, to do so open the artifact's detail page (you can do this from the popup by clicking the button next to the artifact's id at the top).
Add new cards: if you are able to create the primary artifact for a board (e.g. requirements on the Planning Board) then you will see plus (add) symbols at the top of each cell of the board. Clicking any of these will open a popup screen with all relevant fields available. Some of these fields may be pre-populated based on what cell you click the add button for. For instance, if your cell is for a specific status and release, both of those fields will preselected. The fields visible and required is driven based on what workflow step will apply to that new card.
"},{"location":"Spira-User-Manual/Automation-Host-Management/","title":"Automation Host Management","text":""},{"location":"Spira-User-Manual/Automation-Host-Management/#automation-host-list","title":"Automation Host List","text":"This section outlines how to use the Automation Host Management features of SpiraPlan\u00ae to manage the different host systems that will be running automated tests in your environment. Typically when scheduling automated tests you will want to execute the same tests on multiple computers running different environments.
SpiraPlan allows you to build a master list of automation hosts in each product, which can be used to schedule test sets containing automated test cases against.
When you click on the Testing > Automation Hosts global navigation link, you will open the automation host list page:
The automation host list screen displays all the automation hosts entered for the current product, in a filterable, sortable grid. The grid displays the automation host ID together with fields such as name, description, last updated date, token, and any custom properties. The choice of columns displayed is configurable per-user, per-product, giving extensive flexibility when it comes to viewing and searching automation hosts.
In addition, you can view a more detailed description of the automation host by positioning the mouse pointer over the host name hyperlink and waiting for the popup \"tooltip\" to appear. If you click on the host name hyperlink, you will be taken to the automation host details page. Clicking on any of the pagination links at the bottom of the page will advance you to the next set of hosts in the list according to the applied filter and sort-order. There is also a drop-down-list at the bottom of the page which allows you to specify how many rows should be displayed in each page, helping accommodate different user preferences.
One special column that is unique to automation hosts is the \"Token\" field. This needs to contain a short textual identifier that uniquely identifies each automation host in the product. This will be used by each host computer to identify itself to SpiraPlan.
"},{"location":"Spira-User-Manual/Automation-Host-Management/#filtering-sorting","title":"Filtering & Sorting","text":"Read about how to create and manage filters, and how to sort the artifact list.
"},{"location":"Spira-User-Manual/Automation-Host-Management/#new-host","title":"New Host","text":"Clicking on the \"New Host\" button adds a new automation host to the bottom of the automation host list with a default name and token.
"},{"location":"Spira-User-Manual/Automation-Host-Management/#delete","title":"Delete","text":"Clicking on the \"Delete\" button deletes the automation hosts whose check-boxes have been selected in the host list.
"},{"location":"Spira-User-Manual/Automation-Host-Management/#refresh","title":"Refresh","text":"Clicking on the \"Refresh\" button reloads the list of automation hosts; this is useful when new hosts are being added by other users, and you want to make sure you have the most up-to-date list displayed.
"},{"location":"Spira-User-Manual/Automation-Host-Management/#show-hide-columns","title":"Show / Hide Columns","text":"This drop-down list allows you to change the fields that are displayed in the host list as columns for the current product. To show a column that is not already displayed, simply select that column from the list of \"Show...\" column names and to hide an existing column, simply select that column from the list of \"Hide...\" column names. This is stored on a per-product basis, so you can have different display settings for each product that you are a member of. The fields can be any of the built-in fields or any of the custom properties set up by the product owner.
"},{"location":"Spira-User-Manual/Automation-Host-Management/#edit","title":"Edit","text":"Each automation host in the list has an \"Edit\" button in its right-most column. When you click this button or just double-click on any of the cells in the row, you change the item from \"View\" mode to \"Edit\" mode. The various columns are made editable, and \"Save\" buttons are displayed in the last column.
If you click \"Edit\" on more than one row, the \"Save\" buttons are only displayed on the first row, and you can make changes to all the editable rows and then update the changes by clicking the one \"Save\" button. Also, if you want to make the same change to multiple rows (e.g. to change five automation hosts from Active = No to Active = Yes), you can click on the \"fill\" icon to the right of the editable item, which will propagate the new value to all editable items in the same column.
If you want to edit lots of items, first select their checkboxes and then click the \"Edit\" button on the same row as the Filters and it will switch all the selected items into edit mode.
When you have made your updates, you can either click \"Save\"to commit the changes, or \"Cancel\" to revert back to the original information. Alternatively, pressing the <ENTER> key will commit the changes and pressing the <ESCAPE> key will cancel the changes.
"},{"location":"Spira-User-Manual/Automation-Host-Management/#automation-host-details","title":"Automation Host Details","text":"When you click on an automation host entry in the host list, you are taken to the automation host details page illustrated below:
This page is made up of three areas; the left pane is the navigation window, the upper part of the right pane contains the automation host name and ID, and the bottom part of the right pane displays different information associated with the automation host.
The navigation pane consists of a link that will take you back to the host list, as well as a list of the peer automation hosts to the one selected. This latter list is useful as a navigation shortcut; you can quickly view the peer hosts by clicking on the navigation links without having to first return to the host list page. The navigation list can be switched between two different modes:
The list of hosts matching the current filter
The list of all hosts, irrespective of the current filter
The top part of the right pane allows you to view and/or edit the details of the particular automation host. You can edit the various fields (name, description, token, etc.) and custom properties. Once you are satisfied with the changes, click either the \"Save\" button or the alternative options from the \"Save\" dropdown list. In addition you can delete the current automation host by clicking \"Delete\", or discard any changes made by clicking \"Refresh\".
"},{"location":"Spira-User-Manual/Automation-Host-Management/#overview","title":"Overview","text":"This tab shows the fields and description associated with the automation host. Standard and custom fields are grouped by type (eg all date and time fields are grouped together).
"},{"location":"Spira-User-Manual/Automation-Host-Management/#test-runs","title":"Test Runs","text":"This tab displays the list of all the test runs executed against the automation host. Each test run is listed together with the date of execution, the name of the test case, the name of the tester, the release/version of the system that the test was executed against, the name of the test set (if applicable), the overall execution status for the test case in that run and a link to the actual test run details. In addition, you can choose to display any of the custom properties associated with the test run.
The \"Show/hide columns\" drop-down list allows you to change the fields that are displayed in the test run list as columns. To show a column that is not already displayed, simply select that column from the list of \"Show...\" column names and to hide an existing column, simply select that column from the list of \"Hide...\" column names. The displayed columns can be any standard field or custom property.
You can also filter the results by choosing items from the filter options displayed in the sub-header row of each field and clicking the \"Filter\" button. In addition, you can quickly sort the list by clicking on one of the directional arrow icons displayed in the header row of the appropriate field.
"},{"location":"Spira-User-Manual/Automation-Host-Management/#attachments","title":"Attachments","text":"Read about how the attachments tab works
"},{"location":"Spira-User-Manual/Automation-Host-Management/#history","title":"History","text":"Read about how the history tab works
"},{"location":"Spira-User-Manual/Commits/","title":"Commits","text":"Go here to read about how to connect your source code to your SpiraPlan product.
"},{"location":"Spira-User-Manual/Commits/#linking-to-artifacts-in-commit-messages","title":"Linking To Artifacts In Commit Messages","text":"When developers are working on source code, it is often to fix a bug, create a feature described in a user story, or deal with a task. SpiraPlan lets you trace what commits (and therefore file changes) contributed to a bug fix. To do this SpiraPlan reads commit messages for special tokens that it turns into links between the commit and those artifacts. If SpiraPlan finds any links in the commit message it automatically creates the association between the commit and the artifact(s). You can view these associations from the commit details page, or from the associations tab of any artifact.
How does this work? The commit message has to contain one or more artifact token. For example [TK:123], or [IN:456], or [RQ:789]. These tokens are short and do not get in the way of the rest of the commit message. Artifact tokens are in the following format: [{artifact identifier}:{artifact id}]
The first half of the token is a two-letter code, used throughout SpiraPlan and visible on almost every page in the application. For example, a requirement's identifier is \"RQ\". Incidents are \"IN\", and test cases are \"TC\". The artifact ID is the number of the artifact. If you go to the details page for an artifact, you will always see this artifact token near the top of the page. Clicking on it copies it to your clipboard. Then you can paste it into your commit message.
Note: If you forget to add the association during the commit, go to the details page for that commit in SpiraPlan, and click 'Add Association' to add the association at any time.
"},{"location":"Spira-User-Manual/Commits/#commit-list","title":"Commit List","text":"When you click on Developing > Commits on the global navigation bar, you will be taken to the commits list screen. This shows you all commits in the current branch. You can change the branch, sort and filter this list, or browse the different pages of commits (up to 500 commits can be displayed on the page at any one time).
Above the list of commits is the action toolbar. This lets you perform the following functions:
For each commit you can see the following information (you can sort or filter on all of these):
When you click on a commit link (for example, from the commit list), you open the commit details page for that commit. This page shows you information about the commit, the files it includes, the branches it appears in, and other artifacts it is associated with.
The page is made up of two areas:
The detailed information available at the top of the page is the:
There are 3 tabs on this page that each show additional information about the commit. These are discussed below.
"},{"location":"Spira-User-Manual/Commits/#files","title":"Files","text":"This shows the list of files changed in this commit. You can sort or filter the list by any of its columns:
This shows the list of all branches that the commit appears in, listed in alphabetical order. Clicking on a branch changes your selected branch to that branch.
A commit exists in any branch that was made from the branch the commit was originally committed in, and that was made after this commit. There is no single \"original\" or \"main\" branch for a commit, because all the different git branches are considered equal. Deleted branches are not shown.
"},{"location":"Spira-User-Manual/Commits/#associations","title":"Associations","text":"This shows all current associations between this commit and any artifacts in SpiraPlan. This lets you to see which requirements, test cases, incidents, tasks, etc. are linked to the commit. Clicking on the artifact name will take you to the appropriate artifact page (assuming your user has permissions to access that information).
You can also add artifact associations to many other artifacts in the system from this panel. Read more about how to manage and add associations to this artifact.
"},{"location":"Spira-User-Manual/Commits/#commit-file-details","title":"Commit File Details","text":"Files are changed as source code develops. Each commit adds or changes or removes files. This pages allows you to see exactly how a file was changed between one commit and the next. For example, you could see that one function was added, and that another line of code was deleted. Or you can see how an image file looked before and after the commit.
SpiraPlan supports showing before and after previews of all file types that it can show previews for elsewhere in the application (for example, text files and images). For text files (things like code, markdown, and plain text), SpiraPlan will also show a line by line comparison of both file versions.
This page is made up of three areas:
the bottom of the left-hand pane shows the currently selected branch, and the other commits in this branch that changed the file currently being viewed (the icon represents the commit action for this file). Newer commits are at the top.
the right-hand pane shows detailed information about the file for the particular commit. This pane is discussed more below.
The detailed information available at the top of the page is:
There are 3 tabs on this page that each show additional information about the file at the specific commit. These are discussed below.
"},{"location":"Spira-User-Manual/Commits/#changes","title":"Changes","text":"This shows you, for support file types (text files), the line by line changes that were made to the file in this commit. Above the diff view you can see:
Each line that changed is highlighted based off the sort of edit that was made, and a symbol in the left hand gutter shows this too. Line numbers are also displayed. In the unified view (shown above) lines are either added or removed (shown in green or red; and with a \"+\" or \"-\" gutter symbol respectively).
In the split view (shown above) lines can be marked as added, deleted, or edited (shown in green, red, or blue; and with a \"+\", \"-\", or \"~\" gutter symbol respectively). In split, where a line was edited, we highlight the specific parts of the line that were changed.
"},{"location":"Spira-User-Manual/Commits/#previous-commit","title":"Previous Commit","text":"This shows you the preview of the complete file as it was at the previous commit (the commit name is shown in the tab label). Image files as well as text files are previewed. Markdown files are shown as rendered HTML.
"},{"location":"Spira-User-Manual/Commits/#current-commit","title":"Current Commit","text":"This shows you the preview of the complete file as it was at the commit currently being viewed (the commit name is shown in the tab label). Image files as well as text files are previewed. Markdown files are shown as rendered HTML.
Note: The first commit for a file adds the entire file. So when viewing the file at that first commit, you will only see this \"Current Commit\" tab, with a full preview of the file that was added in that commit.
Some older source code management systems (e.g. CVS, Visual SourceSafe) do not have the formal concept of branches, so the dropdown list will simply list the one main branch (usually called \"Trunk\").\u00a0\u21a9
This section outlines the document management features of SpiraPlan\u00ae that can be used to upload, manage, edit, and share documents between product members. This module includes support for:
Document management is fully integrated into the rest of the system: you can attach documents to other artifacts (e.g. requirements, test cases, etc.) and any ones you add on an artifact (including screenshots) are automatically connected to the product documentation repository.
"},{"location":"Spira-User-Manual/Document-Management/#document-list","title":"Document List","text":"When you choose the Documents artifact from the global navigation bar, you open the product documents list screen illustrated below:
This screen is made up of three sections:
The main toolbar has operations you can perform on the document list or selected documents. You can:
Read about how to create and manage filters, and how to sort the artifact list.
"},{"location":"Spira-User-Manual/Document-Management/#add-new-document","title":"Add New Document","text":"To create a new document, click the Add New button. This opens the \"Add New Document\" dialog box for uploading a single file (not multiple). Drag and drop a file onto the upload box, or click to browse for a file on your device. Each type of \"Add New Document\" dialog (see below) will let you:
The Add New button has a dropdown with more options - each option shows you a slightly different dialog box (the bottom part is the same but the top part differs).
Add New button itself): for uploading a fileNote: If you are using a non-Windows\u00ae computer (e.g. Macintosh\u00ae) that doesn't put file extensions on filenames (e.g. .xls for an Excel sheet) automatically, then you will need to manually add the file extension to the filename before uploading if you want it to be displayed with the correct icon in the attachment list.
"},{"location":"Spira-User-Manual/Document-Management/#add-new-inline-documents","title":"Add New Inline Documents","text":"The Add New dropdown has options for creating several files that are not uploaded at all. Instead you choose a file name (and enter description and tag and type information), then when you click \"Add\" you are taken straight to the blank document, so you can start editing it live inside SpiraPlan itself from the document details page.
When you hover the mouse pointer over any of the documents displayed in the document list, an information panel will be displayed that contains the name, description, version, document type and meta-tags of the document.
You can click on the document URL to actually open the document itself in a new window, click on the meta-tag links to find related documents that contain the same meta-tag, or click on \"View Details\" to see more information regarding the document, including an ability to edit its meta-information and see the different versions of the document.
"},{"location":"Spira-User-Manual/Document-Management/#edit-document-folders","title":"Edit Document Folders","text":"If you are a product administrator, you will see the \"Edit\" and \"Add\" buttons beneath the folder tree:
This lets you add, edit and delete task folders in the product. To add a new folder, click the \"Add\" button:
Choose the parent folder that you want to add the new folder under (or None if you are adding a new top-level folder) from the dropdown list and then enter the name of the new folder. Then click 'Add' save the new folder.
To edit or delete an existing folder, click the 'Edit' button to switch the folder tree to edit mode:
To edit or delete a specific folder, click on the 'Edit' button next to the folder:
You can change the parent folder and/or name of the folder and click \"Update\" to commit the change or click \"Delete\" to delete the folder entirely (including its contents).1
"},{"location":"Spira-User-Manual/Document-Management/#document-details","title":"Document Details","text":"When you click on an item in the document list described above, you are taken to the document details page illustrated below:
This page is made up of three areas;
Refresh.Please note that on smaller screen sizes the navigation pane is not displayed. While the navigation pane has a link to take you back to the documents list, on mobile devices a 'back' button is shown on the left of the operations toolbar.
The navigation pane can be collapsed by clicking on the \"-\" button, or expanded by clicking anywhere on the gray title area. On desktops the user can also control the exact width of the navigation pane by dragging and dropping a red handle that appears on hovering at the rightmost edge of the navigation pane.
The navigation pane consists of a link that will take you back to the product document list, as well as a list of other documents in the current folder. This latter list is useful as a navigation shortcut; you can quickly view the detailed information of all the peer documents by clicking on the navigation links without having to first return to the main document list page.
"},{"location":"Spira-User-Manual/Document-Management/#emailing","title":"Emailing","text":"Read about emailing a document to colleagues using Spira.
"},{"location":"Spira-User-Manual/Document-Management/#followers","title":"Followers","text":"Read about how to add and manage followers to an artifact.
"},{"location":"Spira-User-Manual/Document-Management/#workflows","title":"Workflows","text":"Read about using workflows to change the status of your document.
For documents, you can, depending on how the product administrator has set this up, use workflows to control who can add a new version to a document when. This can be useful for \"checking-out\" a document, during which time it is locked. When the document is checked back in the workflow can require that the person checking in the document upload a new version (make sure you upload the version before changing the status).
"},{"location":"Spira-User-Manual/Document-Management/#preview","title":"View","text":"This tab shows the currently active version of the document. You can view the document contents here for many different file types (notably plain text files, code files, feature/BDD files, rich text html documents, spreadsheets, diagrams (including mindmaps and org charts), and images).
If a format cannot be previewed (for example a PDF or Microsoft Word document), the following message is displayed:
When viewing diagrams, mindmaps, or orgcharts there is a button above the diagram that you let you directly download an SVG of the diagram (you can download the diagram from the Versions tab but this downloads the raw data, not a formatted diagram).
"},{"location":"Spira-User-Manual/Document-Management/#edit","title":"Edit","text":"When you create a new inline document the document opens to this tab, showing you the blank document. Make your changes by either:
Click Save to save the document and automatically create a new version (this version becomes the new active version). You can change the document from the Edit tab at any time (if allowed by the workflow and permissions).
You can only create inline documents from the list page for a few file formats, but there are many other file types that, once uploaded, can be edited inline. These include plain text file, including code files.
The Edit tab will show the text, but it is not fully formatted. Go to the view tab to see the formatted view with syntax highlighting applied.
"},{"location":"Spira-User-Manual/Document-Management/#editing-diagrams","title":"Editing Diagrams","text":"SpiraPlan supports three types of diagrams:
When editing any diagram, you will see a simple toolbar above the editing area. This toolbar lets:
The picker (diagrams only) shows all available objects available that you can add to your diagram. To add a new object, click on it from the picker, or drag it from the picker into the editor area. There are three types of object:
The editor area shows the diagram with all its nodes or shapes and connections. The diagram will be effectively identical to how it looks on the View tab. The main different being the dot grid background pattern in the editor area. The editor area lets you:
The formatting palette shows you all ways you can format a selected shape. The options available will vary based on which diagram type is being edited. In general you can edit a shape's:
When editing a diagram type you can also select a specific connector and edit its:
The SpiraPlan spreadsheet is a feature rich spreadsheet application that supports many common spreadsheet features. It is intuitive and easy to use, and should feel immediately familiar. It can work as a full spreadsheet replacement for a wide variety of use cases, with the benefit of all the data and versioning living directly inside Spira. Please note that the spreadsheet is not as powerful as desktop or dedicated web apps and will not be the best solution for handling things like very large data sets, or complex models.
Spreadsheet features:
Importing from and exporting to Excel: Go to
Formulas (including across sheets): work as in other spreadsheet applications. Here is a simple example to sum three cells: =sum(A1:A3). See our full guide to all supported functions below.
Formatting: use the menu to change
Rows and columns: add, remove, and resize
Locking cells: Right-click a cell/a range of cells you want to lock/unlock. Choose the Lock/Unlock cell option in the appeared context menu.
Data validation (to create a drop-down list):
Common keyboard shortcuts for things like undo, redo, copy, paste
This tab allows you to view and/or edit the document's details (thinks like the description, author, tags, any custom fields). Make any changes and then click Save to commit the changes.
Read about how the comments works
"},{"location":"Spira-User-Manual/Document-Management/#document-versions","title":"Document Versions","text":"This tab displays the list all the different versions that exist for the current document. When you first create a new document there will be only a single version (e.g. v1.0). As you change and update the document you do not need to create a whole new document. Instead, upload new versions or edit the document inline (if possible). This will create new versions of the file - you can have as many versions as you need and should give each a unique version number to help track them.
Each version in the list is displayed with its:
One version will have a checkmark in the Active column. This is the currently active version - this is the version users see when they open the document (including the preview on the view tab). All other versions will have two buttons in the Operations column: \"Delete\" (to completely remove that version) and \"Make Active\" (to switch the active version to this version).
To upload a new version click the 'Upload New Version' hyperlink:
In the popup dialog, you need to drag the file to be uploaded onto the upload icon (or click on the icon to browse to the file), enter a description of the changes made, a new version number and whether the new version should be made the active one, then click the Upload button to confirm the changes.
Note: This option is only available for files. You cannot add a new URL version or change the URL.
"},{"location":"Spira-User-Manual/Document-Management/#associations","title":"Associations","text":"You can associate a document to many other artifacts in the system from this tab. If you originally uploaded the document as an attachment to an artifact, then the initial association will be already listed. Read more about how to manage and add associations to this artifact
"},{"location":"Spira-User-Manual/Document-Management/#attachments","title":"Attachments","text":"Read about how the attachment tab works
"},{"location":"Spira-User-Manual/Document-Management/#history","title":"History","text":"Read about how the history tab works
"},{"location":"Spira-User-Manual/Document-Management/#annex-of-spreadsheet-functions","title":"Annex of Spreadsheet Functions","text":""},{"location":"Spira-User-Manual/Document-Management/#boolean-operators","title":"Boolean operators","text":"You can compare two values via using logical expressions that in any given case will only return either TRUE or FALSE.
Operator Example Description = =A1=B1 Returns TRUE if the value in cell A1 is equal to the value in cell B1; otherwise, FALSE. <> =A1<>B1 Returns TRUE if the value in cell A1 is not equal to the value in cell B1; otherwise, FALSE. > =A1>B1 Returns TRUE if the value in cell A1 is greater than the value in cell B1; otherwise, FALSE. < =A1<B1 Returns TRUE if the value in cell A1 is less than the value in cell B1; otherwise, FALSE. >= =A1>=B1 Returns TRUE if the value in cell A1 is greater than or equal to the value in cell B1; otherwise, FALSE. <= =A1<=B1 Returns TRUE if the value in cell A1 is less than or equal to the value in cell B1; otherwise, FALSE."},{"location":"Spira-User-Manual/Document-Management/#date-functions","title":"Date functions","text":"Function Formula Description DATE =DATE(year,month,day) Combines three separate values (year, month, and day) and returns a date. DATEDIF =DATEDIF(start_date,end_date,unit) Returns the number of days, months, or years between two dates. The unit argument is used to define which type of information you want returned. DATEVALUE =DATEVALUE(date_text) Converts a date that is stored as text to a serial number. DAY =DAY(date) Returns the day of the month as a number between 1 to 31 from a specified date. DAYS =DAYS(end_date, start_date) Returns the number of days between two dates. DAYS360 =DAYS360(start_date,end_date,[method]]) Returns the number of days between 2 dates, based on a 360-day year (twelve 30-days months). EDATE =EDATE(start_date, months) Returns the date on the same date of the month, n months in the past or future. EOMONTH =EOMONTH(start_date, months) Returns the date for the last day of the month, n months before or after the specified start date. ISOWEEKNUM =ISOWEEKNUM(date) Returns the number of the ISO week number of the year for the specified date. MONTH =MONTH(date) Returns the month of the year of the specified date. NETWORKDAYS =NETWORKDAYS(start_date, end_date, [holidays]) Returns the number of whole working days between two dates. Working days exclude weekends and any dates specified in holidays. NETWORKDAYSINTL =NETWORKDAYSINTL(start_date, end_date, [weekend], [holidays]) Returns the number of whole working days between two dates. The optional weekend parameter is used to specify which days of the week are considered weekends. Weekend days and holidays are not considered as workdays. NOW =NOW() Returns the current date. TIMEVALUE added in v4.3 =TIMEVALUE(time_text) Returns the decimal number of the time represented by a text string WEEKDAY =WEEKDAY(date,[return_type]) Returns the day of the week for the specified date. The return_type argument is used to define which day of the week is considered the first day. WEEKNUM =WEEKNUM(date,[return_type]) Returns the week number for the specified date. The return_type argument is used to define which day of the week is considered the first day. WORKDAY =WORKDAY(start_date, days, [holidays]) Returns the date of the nearest working day n days in the future or past. Working days exclude weekends and any dates specified in holidays. WORKDAYINTL =WORKDAYINTL(start_date, days, [weekend], [holidays]) Returns the date of the nearest working day n days in the future or past. The optional weekend parameter is used to specify which days of the week are considered weekends. Weekend days and holidays are not considered as workdays. YEAR =YEAR(date) Returns the year of the specified date. YEARFRAC =YEARFRAC(start_date, end_date, [basis]) Returns the year of the specified date. The optional basis argument is used to define the type of day count basis."},{"location":"Spira-User-Manual/Document-Management/#financial-functions","title":"Financial functions","text":"Function Formula Description ACCRINT =ACCRINT(issue, id, sd, rate, par, frequency, [basis], [calc_method]), where:* issue - the issue date of the security;* id - the security's first interest date;* sd - the security's settlement date;* rate - the security's annual coupon rate;* par - the security's par value, $1,000 by default;* frequency - the number of coupon payments per year (1 for annual payments);* basis - optional, the type of day count basis to use;* calc_method - optional, the way to calculate the total accrued interest when the date of settlement is later than the date of first interest (0 or 1(default)). Returns the accrued interest for a security that pays periodic interest. BINOM.DIST added in v4.3 =BINOM.DIST(number_s, trials, probability_s, cumulative), where:* number_s - the number of successes in trials;* trials - the number of independent trials;* probability_s - the probability of success on each trial;* cumulative - if TRUE, then BINOM.DIST returns the cumulative distribution function; if FALSE (use 0), it returns the probability mass function. Returns the individual term binomial distribution probability. BINOM.DIST.RANGE added in v4.3 =BINOM.DIST.RANGE(trials, probability_s, number_s, [number_s2]), where:* trials - the number of independent trials (must be \u2265 0);* probability_s - the probability of success in each trial (must be \u2265 0 and \u2264 1);* number_s - the number of successes in trials (must be \u2265 0 and \u2264 trials);* number_s2 - optional. If provided, returns the probability that the number of successful trials will fall between number_s and number_s2 ([number_s2] must be \u2265 number_s and \u2264 trials). Returns the probability of a trial result using a binomial distribution. BINOM.INV added in v4.3 =BINOM.INV(trials, probability_s, alpha), where:* trials - the number of Bernoulli trials;* probability_s - the probability of success in each trial (must be \u2265 0 and \u2264 1);* alpha - the criterion value (must be \u2265 0 and \u2264 1); Returns the smallest value for which the cumulative binomial distribution is greater than or equal to a criterion value. BITLSHIFT added in v4.3 =BITLSHIFT(number, shift_amount), where:* number - the number to be shifted (must be an integer greater than or equal to 0)* shift_amount - the amount of bits to shift, if negative, shifts bits to the right instead Returns a number shifted left by the specified number of bits. BITOR added in v4.3 =BITOR(number1, number2), where:* number1 - a decimal number (must be greater than or equal to 0 and no larger than 2^48 - 1);* number2 - a decimal number (must be greater than or equal to 0 and no larger than 2^48 - 1); Returns a decimal number representing the bitwise OR of two numbers. BITRSHIFT added in v4.3 =BITRSHIFT(number, shift_amount), where:* number - the number to be shifted (must be an integer greater than or equal to 0);* shift_amount - the amount of bits to shift, if negative shifts bits to the left instead; Returns a number shifted right by the specified number of bits. BITXOR added in v4.3 =BITXOR(number1, number2), where:* number1 - a decimal number (must be greater than or equal to 0 and no larger than 2^48 - 1);* number2 - a decimal number (must be greater than or equal to 0 and no larger than 2^48 - 1); Returns a decimal number representing the bitwise XOR of two numbers. COMPLEX added in v4.3 =COMPLEX(real_num, i_num, [suffix]), where:* real_num - the real coefficient of the complex number;* i_num - the imaginary coefficient of the complex number;* suffix - optional (\"i\" by default) - the suffix for the imaginary component of the complex number; (must be lowercase \"i\" or \"j\") . Converts real and imaginary coefficients into a complex number of the form x + yi or x + yj. CORREL added in v4.3 =CORREL(array1, array2), where:* array1 - a range of cell values;* array2 - a second range of cell values; Text, logical values, or empty cells are ignored. Cells with zero values are included. The arrays must have equal number of data points. Returns the correlation coefficient of two cell ranges. COVAR added in v4.3 =COVAR(array1, array2), where:* array1 - The first cell range of integers;* array2 - The second cell range of integers; Text, logical values, or empty cells are ignored. Cells with zero values are included. The arrays must have equal number of data points. Returns covariance, the average of the products of deviations for each data point pair in two data sets. COVARIANCE.P added in v4.3 =COVARIANCE.P(array1, array2), where:* array1 - The first cell range of integers;* array2 - The second cell range of integers; Text, logical values, or empty cells are ignored. Cells with zero values are included. The arrays must have equal number of data points. Returns population covariance, the average of the products of deviations for each data point pair in two data sets. COVARIANCE.S added in v4.3 =COVARIANCE.S(array1, array2), where:* array1 - The first cell range of integers;* array2 - The second cell range of integers; Text, logical values, or empty cells are ignored. Cells with zero values are included. The arrays must have equal number of data points. Returns the sample covariance, the average of the products of deviations for each data point pair in two data sets. DB =DB(cost, salvage, life, period, [month]), where:* cost - the initial cost of the asset;* salvage - the value of the asset at the end of the depreciation;* life - the number of periods over which the asset is being depreciated;* period - the period to calculate depreciation for;* month - optional, the number of months in the first year, 12 by default. Calculates the depreciation of an asset for a specified period using the fixed-declining balance method. DDB =DDB(cost, salvage, life, period, [factor]), where:* cost - the initial cost of the asset;* salvage - the value of the asset at the end of the depreciation;* life - the number of periods over which the asset is being depreciated;* period - the period to calculate depreciation for;* factor - optional, the rate at which the balance declines, 2 (the double-declining balance method) by default Calculates the depreciation of an asset for a specified period using the double-declining balance method or another method you specify. DEC2BIN added in v4.3 =DEC2BIN(number), where:* number - the decimal integer you want to convert (must be greater than -512 but less than 511); Converts a decimal number to binary. DEC2HEX added in v4.3 =DEC2HEX(number), where:* number - the decimal integer you want to convert (must be greater than -549755813888 but less than 549755813887); Converts a decimal number to hexadecimal. DEC2OCT added in v4.3 =DEC2OCT(number), where:* number - the decimal integer you want to convert (must be greater than -536870912 but less than 536870911); Converts a decimal number to octal. DELTA added in v4.3 =DELTA(number1, [number2]), where:* number1 - the first number;* number2 - optional, the second number. If omitted, number2 is assumed to be zero. Tests two numbers for equality. Returns 1 if number1 = number2; returns 0 otherwise. DEVSQ added in v4.3 =DEVSQ(number1, [number2], ...), where:* number1, number2,... - from 1 to 255 arguments for which you want to calculate the sum of squared deviations; Text, logical values, or empty cells are ignored. Cells with zero values are included. Returns the sum of squares of deviations of data points from their sample mean. DOLLARDE =DOLLARDE(fractional_dollar, fraction) Converts a dollar price specified as an integer part and a fraction part into a dollar price displayed as a decimal number. DOLLARFR =DOLLARFR(decimal_dollar, fraction) Converts a decimal number into fractional dollar number. EFFECT =EFFECT(nominal_rate, npery) nominal_rate must be >= 0, npery must be > 1. Returns the effective annual interest rate on the base of the nominal annual interest rate and the number of compounding periods per year you specify. Works with numeric values. ERF added in v4.3 =ERF(lower_limit, [upper_limit]), where:* lower_limit - the lower bound for integrating ERF;* upper_limit - the upper bound for integrating ERF. If omitted, ERF integrates between 0 and lower_limit. Returns the error function integrated between lower_limit and upper_limit. ERFC added in v4.3 =ERFC(x), where:* x - the lower bound for integrating ERFC Returns the complementary ERF function integrated between x and infinity. EXP added in v4.3 =EXP(number), where:* number - the power that e is raised to Returns the result of the constant e (which equals 2.71828182845904) raised to the power of a number. FISHER added in v4.3 =FISHER(x), where:* x - the value for which you want to calculate the transformation Calculates the Fisher transformation for a supplied value. FISHERINV added in v4.3 =FISHERINV(y), where:* y - the value for which you want to perform the inverse of the transformation Calculates the inverse of the Fisher transformation and returns a value between -1 and +1. FV =FV(rate, nper, pmt, [pv], [type]), where:* rate - the interest rate per period. For monthly payments, rate = rate/12;* nper - the total number of payment periods in an annuity. For monthly payments, nper=nper*12;* pmt - the payment made each period;* pv - optional, the present value, or the lump-sum amount that a series of future payments is worth right now, 0 by default;* type - optional, 0(default) - the payments are due at the end of the period, 1 - at the beginning of the period. Calculates the future value of an investment. FVSCHEDULE =FVSCHEDULE(principal, schedule), where:* principal - the present value;* schedule - an array of interest rates to apply. The values in the array can be numbers or blank cells; any other value produces the error value. Blank cells are taken as zeros. Returns the future value of an initial principal (=present value) after applying a series of compound interest rates. GAMMA added in v4.3 =GAMMA(number) If Number is a negative integer or 0, GAMMA returns the #Error value. Returns the gamma function value. GEOMEAN added in v4.3 =GEOMEAN(number1, [number2], ...) where:* number1, number2,... - from 1 to 255 arguments for which you want to calculate the mean; Text, logical values, or empty cells are ignored. Cells with zero values are included. Returns the geometric mean of an array or range of positive data. GESTEP added in v4.3 =GESTEP(number, [step]) where:* number - the value to test against step;* step - optional, the threshold value. If you omit a value for step, GESTEP uses zero; Returns 1 if number \u2265 step; returns 0 (zero) otherwise. HARMEAN added in v4.3 =HARMEAN(number1, [number2], ...) where:* number1, number2,... - from 1 to 255 arguments for which you want to calculate the mean; Text, logical values, or empty cells are ignored. Cells with zero values are included. Returns the harmonic mean of a data set. HEX2BIN added in v4.3 =HEX2BIN(number) where:* number - the hexadecimal number you want to convert. Number can't contain more than 10 characters; Converts a hexadecimal number to binary. HEX2DEC added in v4.3 =HEX2DEC(number) where:* number - the hexadecimal number you want to convert. Number can't contain more than 10 characters; Converts a hexadecimal number to decimal. HEX2OCT added in v4.3 =HEX2OCT(number) where:* number - the hexadecimal number you want to convert. Number can't contain more than 10 characters; Converts a hexadecimal number to octal. IMABS added in v4.3 =IMABS(inumber) where:* inumber - a complex number Returns the absolute value of a complex number in the format x + yi or x + yj. IMAGINARY added in v4.3 =IMAGINARY(inumber) where:* inumber - a complex number Returns the imaginary coefficient of a complex number given in the format x + yi or x + yj. IMCONJUGATE added in v4.3 =IMCONJUGATE(inumber) where:* inumber - a complex number Returns the complex conjugate of a complex number given in the format x + yi or x + yj. IMCOS added in v4.3 =IMCOS(inumber) where:* inumber - a complex number Returns the cosine of a complex number given in the format x + yi or x + yj. IMCOSH added in v4.3 =IMCOSH(inumber) where:* inumber - a complex number Returns the hyperbolic cosine of a complex number given in the format x + yi or x + yj. IMCOT added in v4.3 =IMCOT(inumber) where:* inumber - a complex number Returns the cotangent of a complex number given in the format x + yi or x + yj. IMCSC added in v4.3 =IMCSC(inumber) where:* inumber - a complex number Returns the cosecant of a complex number given in the format x + yi or x + yj. IMCSCH added in v4.3 =IMCSCH(inumber) where:* inumber - a complex number Returns the hyperbolic cosecant of a complex number given in the format x + yi or x + yj. IMDIV added in v4.3 =IMDIV(inumber1, inumber2) where:* inumber1 - the complex numerator or dividend* inumber2 - the complex denominator or divisor Returns the quotient of two complex numbers given in the format x + yi or x + yj. IMEXP added in v4.3 =IMEXP(inumber) where:* inumber - a complex number Returns the exponential of a complex number given in the format x + yi or x + yj. IMLN added in v4.3 =IMLN(inumber) where:* inumber - a complex number Returns the natural logarithm of a complex number given in the format x + yi or x + yj. IMPOWER added in v4.3 =IMPOWER(inumber, number) where:* inumber - a complex number* number - the power to which you want to raise the complex number Returns a complex number in x + yi or x + yj text format raised to a power. IMPRODUCT added in v4.3 =IMPRODUCT(inumber1, [inumber2], ...) where:* inumber1, inumber2,... - from 1 to 255 complex numbers to multiply Returns the product of 1 to 255 complex numbers given in the format x + yi or x + yj. IMREAL added in v4.3 =IMREAL(inumber) where:* inumber - a complex number Returns the real coefficient of a complex number given in the format x + yi or x + yj. IMSEC added in v4.3 =IMSEC(inumber) where:* inumber - a complex number Returns the secant of a complex number given in the format x + yi or x + yj. IMSECH added in v4.3 =IMSECH(inumber) where:* inumber - a complex number Returns the hyperbolic secant of a complex number given in the format x + yi or x + yj. IMSIN added in v4.3 =IMSIN(inumber) where:* inumber - a complex number Returns the sine of a complex number given in the format x + yi or x + yj. IMSINH added in v4.3 =IMSINH(inumber) where:* inumber - a complex number Returns the hyperbolic sine of a complex number given in the format x + yi or x + yj. IMSQRT added in v4.3 =IMSQRT(inumber) where:* inumber - a complex number Returns the square root of a complex number given in the format x + yi or x + yj. IMSUB added in v4.3 =IMSUB(inumber1, inumber2) where:* inumber1 - a complex number from which to subtract inumber2;* inumber2 - the complex number to subtract from inumber1 Returns the difference of two complex numbers given in the format x + yi or x + yj. IMSUM added in v4.3 =IMSUB(inumber1, [inumber2], ...) where:* inumber1, inumber2,... - from 1 to 255 complex numbers to add Returns the sum of two or more complex numbers given in the format x + yi or x + yj. IMTAN added in v4.3 =IMTAN(inumber) where:* inumber - a complex number Returns the tangent of a complex number given in the format x + yi or x + yj. IPMT =IPMT(rate, per, nper, pv, [fv], [type]), where:* rate - the interest rate per period. For monthly payments, rate = rate/12;* per - the period for which you want to find the interest and must be in the range between 1 and nper;* nper - the total number of payment periods in an annuity. For monthly payments, nper=nper*12;* pv - the present value, or the lump-sum amount that a series of future payments is worth right now;* fv - optional, the future value, 0 by default;* type - optional, 0(default) - the payments are due at the end of the period, 1 - at the beginning of the period. Returns the interest payment for a given period for an investment based on periodic, constant payments and a constant interest rate. IRR =IRR(values, [guess]), where:* values - an array or reference to cells that contain values. The array must contain at least one positive value and one negative value;* guess - optional, an estimate for expected IRR, .1 (=10%) by default. Returns the internal rate of return (IRR) for a series of cash flows that occur at regular intervals. ISPMT =ISPMT(rate, per, nper, pv), where:* rate - the interest rate for the investment. For monthly payments, rate = rate/12;* per - the period for which you want to find the interest and must be in the range between 1 and nper;* nper - the total number of payment periods for the investment. For monthly payments, nper=nper*12;* pv - the present value of the investment. For a loan, pv is the loan amount. Calculates the interest paid (or received) for the specified period of a loan (or investment) with even principal payments. LARGE added in v4.3 =LARGE(array, k), where:* array - the array or range of data for which you want to determine the k-th largest value;* k - the position (from the largest) in the array or cell range of data to return. Returns the k-th largest value in an array. MEDIAN added in v4.3 =MEDIAN(number1, [number2], ...), where:* number1, number2,... - from 1 to 255 numbers for which you want to calculate the median; Returns the median of the given numbers. NOMINAL =NOMINAL(effect_rate, npery), effect_rate must be >= 0, npery must be > 1. Returns the nominal annual interest rate on the base of the effective rate and the number of compounding periods per year you specify. NPER =NPER(rate,pmt,pv,[fv],[type]), where:* rate - the interest rate per period. For monthly payments, rate = rate/12;* pmt - the payment made each period;* pv - the present value, or the lump-sum amount that a series of future payments is worth right now;* fv - optional, the future value, 0 by default;* type - optional, 0(default) - the payments are due at the end of the period, 1 - at the beginning of the period. Returns the number of periods for an investment based on periodic, constant payments and a constant interest rate. NPV =NPV(rate,value1,[value2],...), where:* rate - the rate of discount over one year;* value1, value2,... - from 1 to 254 values representing cash flows (future payments and income). Empty cells, logical values, text, or error values are ignored. Calculates the net present value of an investment by using a discount rate and a series of future payments (negative values) and income (positive values). OCT2BIN added in v4.3 =OCT2BIN(number), where:* number - the octal number you want to convert. It can't contain more than 10 characters; Converts an octal number to binary. OCT2DEC added in v4.3 =OCT2DEC(number), where:* number - the octal number you want to convert. Number may not contain more than 10 octal characters (30 bits) Converts an octal number to decimal. OCT2HEX added in v4.3 =OCT2HEX(number), where:* number - the octal number you want to convert. Number may not contain more than 10 octal characters (30 bits) Converts an octal number to hexadecimal. PDURATION =PDURATION(rate, pv, fv), where:* rate - the interest rate per period. For monthly payments, rate = rate/12;* pv - the present value of the investment;* fv - the desired future value of the investment. All arguments must be positive values. Returns the number of periods required by an investment to reach a specified value. PERCENTILE added in v4.3 =PERCENTILE(array, k), where:* array - an array of data values;* k - the percentile value between 0 and 1, inclusive. Returns the k-th percentile of values in a range. PERCENTILE.EXC added in v4.3 =PERCENTILE.EXC(array, k), where:* array - an array of data values;* k - the percentile value between 0 and 1, exclusive. Returns the k-th percentile of values in a range. PERCENTILE.INC added in v4.3 =PERCENTILE.INC(array, k), where:* array - an array of data values;* k - the percentile value between 0 and 1, inclusive. Returns the k-th percentile of values in a range. PERMUT added in v4.3 =PERMUT(number, number_chosen), where:* number - the total number of items;* number_chosen - the number of items in each combination. Returns the number of permutations for a given number of items. PMT =PMT(rate, nper, pv, [fv], [type]), where:* rate - the interest rate for the loan. For monthly payments, rate = rate/12;* nper - the total number of months of payments for the loan. For monthly payments, nper=nper*12;* pv - the present value (or the current total amount of loan);* fv - optional, the future value, 0 by default;* type - optional, 0(default) - the payments are due at the end of the period, 1 - at the beginning of the period. Calculates the monthly payment for a loan based on constant payments and a constant interest rate. PPMT =PPMT(rate, per, nper, pv, [fv], [type]), where:* rate - the interest rate per period. For monthly payments, rate = rate/12;* per - the period for which you want to find the interest and must be in the range between 1 and nper;* nper - the total number of payment years in an annuity. For monthly payments, nper=nper*12;* pv - the present value - the total amount that a series of future payments is worth now;* fv - the desired future value or a cash balance.* type - optional, 0(default) - the payments are due at the end of the period, 1 - at the beginning of the period. Returns the payment on the principal for a specified period for an investment based on periodic, constant payments and a constant interest rate. PV =PV(rate, nper, pmt, [fv], [type]), where:* rate - the interest rate per period. For monthly payments, rate = rate/12;* nper - the total number of payment years in an annuity. For monthly payments, nper=nper*12;* pmt - the payment made each period. If pmt is omitted, you must include the fv argument;* fv - optional, the desired future value or a cash balance.* type - optional, 0(default) - the payments are due at the end of the period, 1 - at the beginning of the period. Returns the present value of a loan or an investment, based on a constant interest rate. QUARTILE added in v4.3 =QUARTILE(array, quart), where:* array - the array or cell range of numeric values;* quart - indicates which value to return (0-4). Returns the quartile of a data set. QUARTILE.EXC added in v4.3 =QUARTILE(array, quart), where:* array - the array or cell range of numeric values;* quart - indicates which value to return (1-3). Returns the quartile of the data set, based on percentile values from 0..1, exclusive. QUARTILE.INC added in v4.3 =QUARTILE.INC(array, quart), where:* array - the array or cell range of numeric values;* quart - indicates which value to return (0-4). Returns the quartile of a data set, based on percentile values from 0..1, inclusive. SIGN added in v4.3 =SIGN(number), where:* number - any real number Defines the sign of a number. Returns 1 if the number is positive, zero (0) if the number is 0, and -1 if the number is negative. SMALL added in v4.3 =SMALL(array, k), where:* array - an array or range of numeric values;* k - the position (from 1 - the smallest value) in the data set. Returns the k-th smallest value based on its position in the data set. STEYX added in v4.3 =STEYX(known_y's, known_x's), where:* known_y's - an array or range of dependent data points;* known_x's - an array or range of independent data points. Text, logical values, or empty cells are ignored. Zero values are included. Returns the standard error of the predicted y-value for each x in the regression. SYD added in v4.3 =SYD(cost, salvage, life, per), where:* cost - the initial cost of the asset;* salvage - the asset value at the end of the depreciation;* life - the number of periods over which the asset is depreciated;* per - the period and must use the same units as life. Returns the sum-of-years' digits depreciation of an asset for a specified period. TBILLPRICE added in v4.3 =TBILLPRICE(settlement, maturity, discount), where:* settlement - the settlement date of the Treasury bill;* maturity - the maturity date of the Treasury bill;* discount - the Treasury bill's percentage discount rate. Returns the price per $100 face value for a Treasury bill. TBILLYIELD added in v4.3 =TBILLYIELD(settlement, maturity, pr), where:* settlement - the settlement date of the Treasury bill;* maturity - the maturity date of the Treasury bill;* pr - the Treasury bill's price per $100 face value. Returns the yield for a Treasury bill. WEIBULL added in v4.3 =WEIBULL(x, alpha, beta, cumulative), where:* x - the value at which the function must be calculated (must be \u2265 0);* alpha - the alpha parameter to the distribution (must be > 0);* beta - the beta parameter to the distribution (must be > 0);* cumulative - the logical (true/false) argument which defines the type of distribution to be used. If True - Weibull cumulative distribution function, if False - Weibull probability density function Returns the Weibull distribution. WEIBULL.DIST added in v4.3 =WEIBULL(x, alpha, beta, cumulative), where:* x - the value at which the function must be calculated (must be \u2265 0);* alpha - the alpha parameter to the distribution (must be > 0);* beta - the beta parameter to the distribution (must be > 0);* cumulative - the logical (true/false) argument which defines the type of distribution to be used. If True - Weibull cumulative distribution function, if False - Weibull probability density function Returns the Weibull distribution."},{"location":"Spira-User-Manual/Document-Management/#information-functions","title":"Information functions","text":"Function Formula Description ISBINARY =ISBINARY(value) Returns TRUE if the value is binary; otherwise, returns FALSE. ISBLANK =ISBLANK(A1) Returns TRUE if a cell is empty; otherwise, returns FALSE. ISEVEN =ISEVEN(number) Returns TRUE if a number is even, or FALSE if number is odd. Works with integer numbers. ISNONTEXT =ISNONTEXT(value) Returns TRUE if a cell contains any value except text; otherwise, returns FALSE. ISNUMBER =ISNUMBER(value) Returns TRUE if a cell contains a number; otherwise, returns FALSE. ISODD =ISODD(number) Returns TRUE if a number is odd, or FALSE if number is even. Works with integer numbers. ISTEXT =ISTEXT(value) Returns TRUE if a value is text; otherwise, returns FALSE. N =N(value) Returns a value converted to a number."},{"location":"Spira-User-Manual/Document-Management/#lookup-functions","title":"Lookup functions","text":"Function Formula Description HLOOKUP added in v4.3 =HLOOKUP(lookup_value, table_array, row_index, [range_lookup]), where:* lookup_value - the value to search for;* table_array - the table from which to retrieve a value;* column_index_num - the row number in the table from which to retrieve a value;* range_lookup - optional (1 by default): 0 - exact match, 1 - approximate match Looks up a value in a horizontal table INDEX added in v4.3 =INDEX(array, row_num, [column_num]), where:* array - a range of cells or an array constant;* row_num - the row position in the reference or array;* column_num - optional, the column position in the reference or array. Returns the value at a given location in a range or array. LOOKUP added in v4.3 =LOOKUP(lookup_value, lookup_vector, [result_vector]), where:* lookup_value - the value to search for;* lookup_vector - the one-row, or one-column range to search;* result_vector - optional, the one-row, or one-column range of results. Looks up a value in a one-column or one-row range, and retrieves a value from the same position in another one-column or one-row range. MATCH added in v4.3 =MATCH(lookup_value, lookup_array, [match_type]), where:* lookup_value - the value that you want to match in lookup_array;* lookup_array - the range of cells;* match_type - optional (1 by default): 1- finds the largest value that is less than or equal to lookup_value 0 - finds the value that is exactly equal to lookup_value -1 - finds the smallest value that is greater than or equal to lookup_value Searches for a specified item in a range of cells, and then returns the relative position of that item in the range. VLOOKUP added in v4.3 =VLOOKUP(lookup_value, table_array, column_index_num, [range_lookup]), where:* lookup_value - the value to search for in the first column of a table;* table_array - the table from which to retrieve a value;* column_index_num - the column number in the table from which to retrieve a value;* range_lookup - optional (1 by default): 0 - exact match, 1 - approximate match Looks up a value in a vertical table by matching on the first column XLOOKUP added in v4.3 =XLOOKUP(lookup_value, lookup_array, return_array, [if_not_found], [match_mode]), where:* lookup_value - the value to search for;* lookup_array - the array or range to search;* return_array - the array or range to return;* if_not_found - optional, if a valid match is not found, returns the [if_not_found] text you supply;* match_mode - optional (0 by default): 0 - Exact match -1 - Exact match. If not found, returns the next smaller item 1 - Exact match. If not found, returns the next larger item Searches a range or an array, and then returns the item corresponding to the first match it finds. If no match exists, then XLOOKUP can return the closest (approximate) match. XMATCH added in v4.3 =XMATCH(lookup_value, lookup_array, [match_mode]), where:* lookup_value - the value that you want to match in lookup_array;* lookup_array - the range of cells;* match_mode - optional, 0 - exact match (default), -1 - exact match or next smallest, 1 - exact match or next larger Performs a lookup and returns a position in vertical or horizontal ranges."},{"location":"Spira-User-Manual/Document-Management/#math-functions","title":"Math functions","text":"Function Description ABS Returns the absolute value of a number. The absolute value of a number is always positive. ACOS Returns the arccosine, or inverse cosine, of a number. The arccosine is the angle whose cosine is number. The number must be from -1 to 1, inclusive. The returned angle is given in radians in the range 0 (zero) to pi. ACOSH Returns the inverse hyperbolic cosine of a number. The number must be greater than or equal to 1. ACOT Returns the principal value of the arc-cotangent, or inverse cotangent, of a number. The returned angle is given in radians in the range 0 (zero) to pi. ACOTH Returns the inverse hyperbolic cotangent of a number. The absolute value of the number must be greater than 1. ADD Returns the sum of two values. Empty cells, logical values like TRUE, or text are ignored. ARABIC Converts a Roman numeral to an Arabic numeral. ASIN Returns the arcsine, or inverse sine, of a number. The arcsine is the angle whose sine is number. The number must be from -1 to 1, inclusive. The returned angle is given in radians in the range -pi/2 to pi/2. ASINH Returns the inverse hyperbolic sine of a number. The inverse hyperbolic sine is the value whose hyperbolic sine is number. Works with real numbers. ATAN Returns the arctangent, or inverse tangent, of a number. The arctangent is the angle whose tangent is number. The returned angle is given in radians in the range -pi/2 to pi/2. Works with the tangent of the angle you want. ATAN2 Returns the arctangent of (x,y) coordinates. The arctangent is returned in radians between -pi and pi, excluding -pi. ATANH Returns the inverse hyperbolic tangent of a number. Number must be between -1 and 1 (excluding -1 and 1). Works with real numbers. AVEDEV added in v4.3 Returns the average of the absolute deviations of data points from their mean. Empty cells, logical values, text, or error values in the array or reference are ignored. Cells with the value 0 are included. AVERAGE Calculates the average (arithmetic mean) of a group of numbers. Logical values, empty cells and cells that contain text in the array or reference are ignored However, cells with the value zero are included. AVERAGEA added in v4.3 Calculates the average (arithmetic mean) of the values in the list of arguments. Arguments can be the following: numbers; names, arrays, or references that contain numbers; text representations of numbers; or logical values, such as TRUE and FALSE, in a reference. Empty cells and text values in the array or reference are ignored. BASE Converts a number into the supplied base (radix). The number should be an integer and greater than or equal to 0 and less than 2^53. The base radix is what we want to convert the number into. It must be an integer from 2 to 36, inclusive. BITAND added in v4.3 Returns a bitwise 'AND' of two numbers. The number must be an integer and greater than or equal to 0 and less than (2^48)-1. CEILING Returns a number rounded up to the nearest integer or to the nearest multiple of the specified significance. COMBIN Returns the number of combinations for two given integer numbers: the number of items (number) and the number of items in each combination (number_chosen):* number should be greater than or equal to zero; also, it should be greater than or equal to the number_chosen;* number_chosen must be greater than or equal to zero. COMBINA Returns the number of combinations for two given integer numbers and includes repetitions. The numbers are: the number of items (number) and the number of items in each combination (number_chosen):* number should be greater than or equal to zero; also, it should be greater than or equal to the number_chosen;* number_chosen must be greater than or equal to zero. COS Returns the cosine of an angle specified in radians. COSH Returns the hyperbolic cosine of a real number. CSC Returns the cosecant of an angle specified in radians. CSCH Return the hyperbolic cosecant of an angle specified in radians. COT Returns the cotangent of the an angle specified in radians. COTH Returns the hyperbolic cotangent of a hyperbolic angle. COUNT Counts the number of cells that contain numbers, and counts numbers within the list of arguments. Empty cells, logical values, text, or error values in the array or reference are not counted. COUNTA Counts the number of cells that contain numbers, text, logical values, error values, and empty text (\"\"); cells with zero values are excluded. The function does not count empty cells. COUNTBLANK Returns the number of empty cells from a specified range. Cells with zero values are not counted. DECIMAL Converts a text representation of a number in a given base (radix) into a decimal number. The base radix must be an integer from 2 to 36, inclusive. DEGREES Converts radians into degrees. DIVIDE Returns the result of dividing one number by another. EQ Returns TRUE if the first argument is equal to the second; otherwise FALSE. EVEN Returns a number rounded up to the nearest even integer. FACT Returns the factorial of a number. The number must be from 1 to n. If number is not an integer, it is truncated. FACTDOUBLE Returns the double factorial of a number. The number must be from 1 to n. If number is not an integer, it is truncated. FLOOR Rounds number down, toward zero, to the nearest multiple of the specified significance. The significant must be from 1 to n. If the sign of number is positive, a value is rounded down and adjusted toward zero. If the sign of number is negative, a value is rounded down and adjusted away from zero. GCD Returns the greatest common divisor of two or more integers. The function takes from 1 to 255 numeric values which are expected to be integers. If any value is not an integer, it is truncated. GT Returns TRUE if the first argument is greater than the second; otherwise FALSE. GTE Returns TRUE if the first argument is greater than or equal to the second; otherwise FALSE. INT Returns a number rounded down to the nearest integer. LN Returns the natural logarithm of a positive real number. LOG Returns the logarithm of a positive real number to the base you specify. If base is omitted, it is assumed to be 10. LOG10 Returns the base-10 logarithm of a positive real number. LT Returns TRUE if the first argument is less than the second; otherwise FALSE. LTE Returns TRUE if the first argument is less than or equal to the second; otherwise FALSE. MAX Returns the largest value in a set of values. The function ignores empty cells, the logical values TRUE and FALSE, and text values. If the arguments contain no numbers, MAX returns 0 (zero). MIN Returns the smallest number in a set of values. Empty cells, logical values, or text in the array or reference are ignored. If the arguments contain no numbers, MIN returns 0 (zero). MINUS Returns the difference of two numbers. MOD Returns the remainder after number is divided by divisor. The result has the same sign as divisor. MROUND Returns a number rounded to the nearest multiple of the specified significance. The values of number and multiple must have the same sign. MULTINOMIAL Returns the ratio of the factorial of a sum of values to the product of factorials. The function takes from 1 to 255 numeric values which must be greater than or equal to 0. MULTIPLY Returns the result of multiplying two numbers. NE Returns TRUE if the first argument is not equal to the second; otherwise FALSE. ODD Returns a number rounded up to the nearest odd integer. PI Returns the number 3.14159265358979 (the mathematical constant pi, accurate to 15 digits). POW Returns the result of a number raised to a given power. Works with real numbers. POWER Returns the result of a number raised to a given power. Works with real numbers. PRODUCT Multiplies all the numbers given as arguments and returns the product. Only numbers in the array or reference are multiplied. Empty cells, logical values, and text in the array or reference are ignored. QUOTIENT Returns the result of integer division without the remainder. Works with real numbers. RADIANS Converts degrees to radians. RAND Returns a random number that is greater than or equal to 0 and less than 1. Returns a new random number each time your spreadsheet recalculates. RANDBETWEEN Returns a random number between two specified numbers. Returns a new random number each time your spreadsheet recalculates. ROMAN Converts an arabic numeral to roman. ROUND Returns a number rounded to a specified number of digits. ROUNDDOWN Returns a number rounded down to a specified number of digits. ROUNDUP Returns a number rounded up to a specified number of digits. SEC Returns the secant of an angle specified in radians. Works with numeric values. SECH Returns the hyperbolic secant of an angle specified in radians. Works with numeric values. SIN Returns the sine of an angle specified in radians. SINH Returns the hyperbolic sine of a real number. SQRT Returns a positive square root of a number. SQRTPI Returns the square root of a number multiplied by pi. The number must be greater than or equal to 0. STDEV Calculates standard deviation based on data that represents a sample of population. The standard deviation is a measure of how widely values are dispersed from the average value (the mean). Empty cells, logical values, text, or error values in the array or reference are ignored. STDEVA Calculates standard deviation based on a sample. The standard deviation is a measure of how widely values are dispersed from the average value (the mean). Empty cells and text values in the array or reference are ignored. STDEVP Calculates standard deviation based on the entire population of numbers. The standard deviation is a measure of how widely values are dispersed from the average value (the mean). Empty cells, logical values, text, or error values in the array or reference are ignored. STDEVPA Calculates standard deviation based on the entire population given as arguments, including text (evaluate as 0) and logical values (evaluate as 1 for TRUE, and as 0 for FALSE). The standard deviation is a measure of how widely values are dispersed from the average value (the mean). If an argument is an array or reference, only values in that array or reference are used. Empty cells and text values in the array or reference are ignored. Error values cause errors. STDEV.S added in v4.3 Estimates standard deviation based on a sample (ignores logical values and text in the sample). The standard deviation is a measure of how widely values are dispersed from the average value (the mean). If an argument is an array or reference, only values in that array or reference are used. Empty cells, logical values, text, or error values in the array or reference are ignored. Error values cause errors. SUBTOTAL Returns a subtotal in a list or database. SUM Returns the sum of supplied values. Empty cells, logical values like TRUE, or text are ignored. SUMPRODUCT Multiplies range of cells or arrays and returns the sum of products. For valid products only numbers are multiplied. Empty cells, logical values, and text are ignored. Treats array entries that are not numeric as if they were zeros. SUMSQ Returns the sum of the squares of the arguments. Empty cells, logical values, text, or error values in the array or reference are ignored. SUMX2MY2 Returns the sum of the difference of squares of corresponding values in two arrays. The arguments should be either numbers or names, arrays, or references that contain numbers. Empty cells, logical values, text, or error values in the array or reference are ignored. Zero values are included. SUMX2PY2 Returns the sum of the sum of squares of corresponding values in two arrays. The arguments should be either numbers or names, arrays, or references that contain numbers. Empty cells, logical values, text, or error values in the array or reference are ignored. Zero values are included. SUMXMY2 Returns the sum of squares of differences of corresponding values in two arrays. The arguments should be either numbers or names, arrays, or references that contain numbers. Empty cells, logical values, text, or error values in the array or reference are ignored. Zero values are included. TAN Returns the tangent of an angle specified in radians. TANH Returns the hyperbolic tangent of a real number. TRUNC Truncates a number to an integer by removing the fractional part of the number. VAR Returns the variance based on a sample. Empty cells, logical values, text, or error values in the array or reference are ignored. VARA Returns the variance based on a sample of the population, including text (evaluate as 0) and logical values (evaluate as 1 for TRUE, and as 0 for FALSE). Empty cells and text values in the array or reference are ignored. VARP Returns the variance of a population based on an entire population of numbers. Empty cells, logical values, text, or error values in the array or reference are ignored. VARPA Returns the variance of a population based on an entire population, including text (evaluate as 0) and logical values (evaluate as 1 for TRUE, and as 0 for FALSE). Empty cells and text values in the array or reference are ignored. VAR.S added in v4.3 Returns the variance based on a sample (ignores logical values and text in the sample). Empty cells, logical values, text, or error values in the array or reference are ignored."},{"location":"Spira-User-Manual/Document-Management/#regex-functions","title":"Regex functions","text":"Function Formula Description REGEXREPLACE =REGEXREPLACE(text, regular_expression, replacement) Replaces a part of a text string with a different text string using regular expressions. REGEXMATCH =REGEXMATCH(text, regular_expression) Returns TRUE if a text string matches the pattern in the regular expression and FALSE if it doesn't. REGEXEXTRACT =REGEXEXTRACT(text, regular_expression) Returns the part of the string that matches the pattern in the regular expression."},{"location":"Spira-User-Manual/Document-Management/#string-functions","title":"String functions","text":"Function Formula Description ARRAYTOTEXT added in v4.3 =ARRAYTOTEXT(array, [format]) Returns an array of text values from any specified range, based on the format you specify (0 - concise (default) or 1 - strict format) CHAR =CHAR(number) Returns the character (from the character set used by your computer) specified by a number. Number must be between 1 and 255. CLEAN =CLEAN(text) Removes characters, which are not printed when you use the print option, from the text. CODE =CODE(text) Returns a numeric code for the first character in a text string. CONCATENATE =CONCATENATE(A1,\"\",B2:C3) Joins two or more text strings into one string. DOLLAR =DOLLAR(number, decimals) Converts a number to text using the currency format, based on the number of digits to the right/left of the decimal point you specify (by default, 2). EXACT =EXACT(text1, text2) Compares two strings and returns TRUE if they are exactly the same; otherwise, returns FALSE. FIND =FIND(find_text, within_text, [start_num]) Returns the position (as a number) of one text string inside another, starting at the position you specify (by default, 1). FIXED =FIXED(number, [decimals], [no_commas]) Rounds a number to the specified number of decimals, formats the number in decimal format using a period and commas, and converts the result to text. If no_commas is set to 1, the returned text won't include commas. JOIN =JOIN(separator, value1, value2,...) Concatenates values using a specified separator. LEFT =LEFT(text, count) Returns the first character or characters in a text string, based on the number of characters you specify. LEN =LEN(text) Returns the length of the specified string. LOWER =LOWER(text) Converts all letters in the specified string to lowercase. MID =MID(text, start, count) Returns a specific number of characters from a text string, starting at the position you specify, based on the number of characters you specify. NUMBERVALUE =NUMBERVALUE (text, [decimal_separator], [group_separator]) Converts a number in text format to numeric value, using specified decimal and group separators. PROPER =PROPER(text) Sets the first character in each word to uppercase and converts all other characters to lowercase. REPLACE added in v4.3 =REPLACE(old_text, start_num, num_chars, new_text), where:* old_text - the text in which you want to replace some characters;* start_num - the position of the character in old_text that you want to replace with new_text;* num_chars - the number of characters to be replaced in old_text;* new_text - the text that will replace characters in old_text. Replaces part of a text string, based on the number of characters you specify, with a different text string. REPT =REPT(text, number_times) Repeats text a specified number of times. RIGHT =RIGHT(text, count) Returns the last character or characters (rightmost) in a text string, based on the number of characters you specify. SEARCH =SEARCH(find_text, within_text, [start_num]) Returns the position (as a number) of the first character of find_text inside within_text, starting at the position you specify (by default, 1). SUBSTITUTE =SUBSTITUTE(text, old_text, new_text, [instance_num]) Replaces old text with new text in a text string. If you specify instance_num, only that instance of old_text is replaced; otherwise, all instances are replaced. T =T(value) returns text when given a text value and an empty string (\"\") for numbers, dates, and the logical TRUE/FALSE values. TRIM =TRIM(text) Removes all spaces from text except for single spaces between words. UPPER =UPPER(text) Converts text to uppercase."},{"location":"Spira-User-Manual/Document-Management/#other-functions","title":"Other functions","text":"Function Formula Description AND =AND(logical1, [logical2], ...) Returns either TRUE or FALSE depending on whether multiple conditions are met or not. CHOOSE =CHOOSE(index_num, value1, [value2], ...) Returns a value from the list of value arguments based on a position or index you specify. FALSE =FALSE() Returns the logical value FALSE. IF =IF(condition, [value_if_true], [value_if_false]) Returns one value if a condition is TRUE and another value if it's FALSE. NOT =NOT(logical) Returns the opposite of a given logical or Boolean value. OR =OR(logical1, [logical2], ...) Returns TRUE if at least one of the logical expressions is TRUE; otherwise, FALSE. TRUE =TRUE() Returns the logical value TRUE.when navigating to folders (for all artifacts that support them), the URL in your browser's address bar will change. Each folder has a unique, sharable URL that you can give to someone to display the list of artifacts with the appropriate folder selected. You can also open up multiple folders in different browser tabs and easily toggle between them from the same browser.\u00a0\u21a9
Who Can Access the Enterprise Homepage?
To access the enterprise homepage first, you need to be using SpiraPlan. Second, your user must be a Portfolio Viewer. System Administrators can control this setting on a user by user basis. If you are a Portfolio Viewer you will also be able to access the Enterprise Homepage.
If you are NOT a portfolio viewer, you can still see how your organization structures its portfolios, programs, and products from the workspace dropdown.
When you navigate to the Enterprise view from the global navigation bar you will be taken to the Enterprise homepage:
This page summarizes all of the information across the whole application (your whole enterprise) in a \"one-stop-shop\". You will see a small \"i\" in a circle at the top right of each widget. Hovering or clicking on this will show you information about that chart.
In a similar manner to other home pages in the application (like the 'My Page'), the Enterprise Home is loaded in 'view mode'. To switch the page to 'edit mode', click the button with the cog icon () on the right.
In 'edit mode', each widget can be:
Together, these editing options let you change the page to suit your needs. If you close a widget and then later want to open it again click the \"+ Add\" button at the top of the page (next to the 'edit mode' button). This brings up a list of all the widgets you can add onto the page (including a list of 'Closed Widgets'). You can choose where on the page each widget should go.
Please note
Any changes you make to this page (e.g. editing, moving, closing widgets) will only affect your user and on this particular home page. They do not affect any other user.
By default, the Enterprise home page shows the following widgets and are described in more details below:
This chart shows the proportion of all active requirements that have been completed across all active portfolios in your enterprise. When 100% of the requirements are completed, the color changes so that it is easy to tell what is in progress vs completed.
"},{"location":"Spira-User-Manual/Enterprise-Homepage/#top-open-risks","title":"Top Open Risks","text":"This widget lists the top risks logged against any of the active products in the application, ordered by exposure. Clicking on the risk name will open the risk details page for the risk in question. Note: you can configure the widget settings to control the maximum number of risks to show.
"},{"location":"Spira-User-Manual/Enterprise-Homepage/#portfolios-completion","title":"Portfolios: Completion","text":"This chart shows the progress of each portfolio in the enterprise. The left-hand chart shows progress from the start to end date of the portfolio. The bar's color indicates how on track the schedule is against requirement completion. The right-hand chart shows the proportion of requirements across active workspaces in the portfolio that have been completed.
Schedule Progress color definitions:
Example
A portfolio started a week ago and will finish in a week. Therefore its schedule is 50% of the way through (1 week down, 1 week to go).
The Schedule Progress bar will show as 50% (if you click \"Displaying\" button to \"As Numbers\" it will show 7 days).
This portfolio has a total of 20 requirements (summed up from all its program, their products, and their active releases). Let's say that 15 of these are completed. That's 75% complete. So the Requirements Complete bar will show 75% (if you click \"Displaying\" button to \"As Numbers\" it will show 15 completed).
So the schedule is half way through but we are three quarters done with the work (the requirements). So we are ahead of schedule (awesome!). The schedule bar will therefore have the \"Ahead of Schedule\" color.
What if, instead of finishing next week, we were supposed to finish last week? Well, the schedule bar would be flagged as \"Behind Schedule\". This is because we are only 75% complete on the work, but the end date is in the past.
Tip: You can hover over a bar to get more information.
"},{"location":"Spira-User-Manual/Enterprise-Homepage/#portfolios-relative-size","title":"Portfolios: Relative Size","text":"This chart shows the number of active requirements in each active portfolio. Hovering over a segment will show its percentage of all requirements (this is visually represented by the size of the donut wedge). Please note, portfolios with no active requirements are not shown.
"},{"location":"Spira-User-Manual/Enterprise-Homepage/#schedule","title":"Schedule","text":"This Gantt chart shows all active portfolios, programs, products, releases, and sprints in the enterprise. Each bar spans from the item's start date to end date. The darker shaded portion of each bar tells you how complete its requirements are.
"},{"location":"Spira-User-Manual/Enterprise-Homepage/#recent-builds","title":"Recent Builds","text":"This widget displays a list of the most recent builds for each active release (organized alphabetically by portfolio, program, and product; in each product the builds are listed by date). For each build it shows:
You can change the number of builds the widget should show in the widget's settings (the default is 15).*
"},{"location":"Spira-User-Manual/Functionality-Overview/","title":"Functionality Overview","text":"This section outlines the functionality provided by SpiraPlan\u00ae in the areas of requirements management, test case management, release planning, sprint planning, incident tracking, task management and product / user management.
Please note, that SpiraPlan\u00ae is designed for use on a very wide range of devices from desktops, to tablets, to smartphones. This guide is written using desktop conventions (e.g. using 'click' throughout where 'tap' would apply on mobile devices) but the functionality remains very similar throughout the application across all devices and platforms. See Mobile Access for more information.
"},{"location":"Spira-User-Manual/Functionality-Overview/#requirements-management","title":"Requirements Management","text":"SpiraPlan\u00ae provides the ability to create, edit and delete product scope / requirements in a hierarchical organization that resembles a typical scope matrix. Each requirement is associated with a particular importance level and a status identifier that designates where the requirement is in the development lifecycle (requested, planned, in-progress and completed). The requirements can be organized according to which part of the system they relate to (called the Component) as well as being organized into different types (features, qualities, use cases, etc.). Certain types (such as use cases) allow you to define the scenario steps that help describe that requirement.
In addition, each requirement can be mapped to one or more test cases that can be used to validate that the functionality works as expected. This mapping is called the \"Requirement Test Coverage\", since the test cases \"cover\" the requirement so that if all the tests can be executed successfully, then the requirement is validated.
At the same time, from a development perspective, the team begins initial estimation of the lowest-level requirements in the requirements matrix to determine the complexity and associated resourcing. Once the high-level release schedule has been determined, the requirements can then be prioritized and scheduled against the appropriate release according to their business priority.
Once the release is underway, the requirements are further decomposed into their constituent low-level product tasks that can be assigned to the product team. The system will track the progress and revised estimates for the tasks and display them against the requirements so that risks to the schedule can be quickly determined.
"},{"location":"Spira-User-Manual/Functionality-Overview/#test-case-management","title":"Test Case Management","text":"SpiraPlan\u00ae provides the ability to create, edit and delete product test cases that are stored in a hierarchical folder structure that resembles Windows Explorer \u00ae. Each test case consists of a set of test steps that represent the individual actions a user must take to complete the test. These test steps also contain a description of the expected result and any sample data elements that the tester should use when performing the action. When a user executes a test case, the results are stored in a test run that contains the success/failure status of each test step as well as the actual observed result that the tester experienced.
In addition each test case is mapped to one or more requirements that the test is effectively validating, providing the test coverage for the requirement. During the execution of the test case, each failure can be optionally used to record a new incident, which can then be managed in the incident tracking module (see below). This provides complete traceability from a recorded incident to the underlying requirement that was not satisfied.
To streamline the assignment and tracking of multiple test cases, SpiraPlan\u00ae allows users to select groups of test cases and arrange them into test sets. Each test set can contain test cases from a variety of different folders and can be associated with a specific release of the system being tested.
"},{"location":"Spira-User-Manual/Functionality-Overview/#test-automation","title":"Test Automation","text":"As well as being able to store and manage manual test cases, SpiraPlan\u00ae can be used to manage the scheduling and execution of automated test scripts for a variety of third-party test automation engines. This allows you to centrally plan your automated testing and monitor the results of automated unit, functional and load testing remotely. For example, you could schedule a set of automated functional tests to run on five different machines (each with a different browser/OS combination) at 2:00 AM and have the results be ready for the next morning.
"},{"location":"Spira-User-Manual/Functionality-Overview/#release-planning","title":"Release Planning","text":"SpiraPlan\u00ae provides the ability to track different versions / releases of the application being tested. Each product in the system can be decomposed into an unlimited number of specific product releases, denoted by name and version number. Requirements and Test Cases developed during the design phase can then be assigned to these different releases. When a tester executes a series of test cases, they are able to choose the version of the product being tested and the resulting test run information is then associated with that release.
From a product planning perspective, the releases are the major milestones in the product, which are further sub-divided into sprints which are separate mini-products with associated product scope and tasks. The product's requirements are scheduled at a high-level against the releases and the detailed tasks are scheduled against specific sprint within the release.
In addition, all incidents raised during the testing process are associated with this release, allowing the development team to easily determine which version of the product is affected. Finally as the incidents are resolved and verified during the testing phase, the appropriate release can be selected to indicate which release the incident was resolved and/or verified in.
"},{"location":"Spira-User-Manual/Functionality-Overview/#sprint-planning","title":"Sprint Planning","text":"As described in Release Planning, in addition to high-level product releases, SpiraPlan\u00ae can also track the individual sprints that comprise a release, giving the product manager the option to manage agile methodology products within the SpiraPlan\u00ae environment. Unlike the release planning stage, where high-level requirements are estimated and scheduled, the sprint planning phase involves assigning each of the requirements, incidents and tasks in the product backlog against a specific sprint until the available effort in the sprint has been completely allocated.
When you first create sprints, you specify the start and end-dates together with the notional number of product resources assigned to the sprint and any non-working days. SpiraPlan\u00ae uses this information to calculate the planned effort available to the sprint, from which it will subtract the estimated task and incident effort values to determine how much effort is available to schedule.
"},{"location":"Spira-User-Manual/Functionality-Overview/#incident-tracking","title":"Incident Tracking","text":"SpiraPlan\u00ae provides the ability to create, edit, assign, track, manage and close incidents that are raised during the testing of the software system under development. These incidents can be categorized into bugs, enhancements, issues, training items, limitations, change requests, and risks, and each type has its own specific workflow and business rules. Typically each incident is raised initially as a 'New' item of type 'Incident'. Following the review by the product manager and customer, they are changed to one of the other specific types, given a priority (critical, high, medium or low), and status changed to 'Open'. Once it is assigned to a developer for fixing, it is changed to status 'Assigned'.
The developer now works to correct the incident, after which time its status changes to 'Fixed' or 'Not Reproducible' depending on the actions taken (or not taken). Finally the product manager and customer verify that it has indeed been fixed, and the status is changed to 'Closed'. SpiraPlan\u00ae provides robust sorting and filtering of all the incidents in the system, as well as the ability to view the incidents associated with particular test cases and test runs, enabling drill-down from the requirements coverage display, right through to the open incidents that are affecting the requirement in question.
"},{"location":"Spira-User-Manual/Functionality-Overview/#task-management","title":"Task Management","text":"As described above, in addition to storing the requirements for a product, SpiraPlan\u00ae includes the capability of drilling each lowest-level requirement down further into a series of work items called 'Tasks'. These tasks are the discrete activities that each member of the development team would need to carry out for the requirement to be fulfilled. Each task can be assigned to an individual user as well as associated with a particular release or sprint. The system can then be used by the product manager to track the completion of the different tasks to determine if the product is on schedule.
The tasks can be organized into different folders as well as categorized by different types (development, testing, infrastructure, etc.), each of which can have its own workflow which defines the process by which the task changes status during the product lifecycle.
"},{"location":"Spira-User-Manual/Functionality-Overview/#products-and-users","title":"Products and Users","text":"SpiraPlan\u00ae supports the management of an unlimited number of users and products, which can be administered through the same web interface as the rest of the application. All artifacts (requirements, tests and incidents) are associated with a particular product, and each user of the system can be given a specific role for the particular product. So, a power user of one software product may be merely an observer of another. That way, a central set of users can be managed across the enterprise, whilst devolving product-level administration to the manager of the product. In addition to these administration functions, each user profile and product has its own personalized dashboard view of all the pertinent and relevant information. This feature reduces the information overload associated with managing such a rich source of product information, and allows a single user or product snapshot to be viewable at all times for rapid decision-making.
"},{"location":"Spira-User-Manual/Functionality-Overview/#document-management","title":"Document Management","text":"SpiraPlan\u00ae includes an integrated document management collaboration system that can be used to upload, manage and share documents between the different members of the product. This module includes support for uploading files and URLs, versioning of documents, the ability to organize into folders and categorize and search using meta-tags.
"},{"location":"Spira-User-Manual/Functionality-Overview/#risk-management","title":"Risk Management","text":"SpiraPlan\u00ae (not available in SpiraTest or SpiraTeam) enables a complete risk management workflow. This module aids in the analyzing and categorizing of risks based on their Probability and their impact, which produces a calculated risk exposure. The tool tracks both risks and their mitigations, and provides dynamic risk reporting tools.
"},{"location":"Spira-User-Manual/Functionality-Overview/#source-code-tracking","title":"Source Code Tracking","text":"SpiraTeam\u00ae and SpiraPlan\u00ae let you browse your source code from within the main web application. This is an excellent way to browse all a product's code files, commits, and how a file changed in a commit (the 'diff'). There is no need to install version control software on your own computer or to clone the source code to your machine. All users can link source code commits with any SpiraPlan\u00ae artifact. This gives you traceability from requirements, incidents, tasks, and more to right code changes. This let you easily see what code was edited to implement a feature, or fix a bug. If the bug is reopened later, you can quickly see the associated source code commits to check if the changes made actually did fix things properly.
"},{"location":"Spira-User-Manual/Functionality-Overview/#build-management","title":"Build Management","text":"SpiraPlan\u00ae integrates with a variety of continuous integration / automated build servers so that the results of automated builds can be displayed in SpiraPlan linked to the associated release or sprint. In addition, the results of automated tests and source code operations can be linked to the build events, providing traceability from a specific build to the bugs that were fixed, tests that were run, and source code files that were modified.
"},{"location":"Spira-User-Manual/Functionality-Overview/#instant-messenger","title":"Instant Messenger","text":"SpiraPlan\u00ae comes with a build-in integrated instant messaging capability. This lets users see which users are currently logged-into the system, maintain a list of contacts and where available, send short instant messages to other users. Any messages exchanged can then be posted to relevant artifacts in the system as permanent comments.
"},{"location":"Spira-User-Manual/Functionality-Overview/#miscellaneous","title":"Miscellaneous","text":""},{"location":"Spira-User-Manual/Functionality-Overview/#artifact-relationships","title":"Artifact Relationships","text":"The sections above have outlined the different features and functions available in the system, and have described the various artifacts managed in the system (e.g. products, users, requirements, tests, etc.). To aid in understanding how the information is related, the following diagrams illustrates the relationships between the different artifacts and entities:
Figure 1: The main entities that comprise a SpiraTest product.
Figure 2: The relationships between the various SpiraTest entities
With these overall concepts in mind, the rest of this help manual will outline the functionality in each of the SpiraPlan\u00ae screens, and provide specific information on how to manage each of the artifacts illustrated above. Note that this manual does not explain the Administration-level functionality of the system; for that, please refer to the SpiraPlan\u00ae Administration Guide.
"},{"location":"Spira-User-Manual/Functionality-Overview/#artifact-naming-conventions","title":"Artifact Naming Conventions","text":"On various screens in the system, you will see lists of artifacts (requirements, test cases, etc.) together with a unique identification number. In order to make it easier to recognize at a glance which type of artifact the identification number refers to, SpiraPlan\u00ae uses a system of two-letter prefixes which help identify the type of artifact being displayed. The current prefixes used by the system are:
Artifact Prefix Artifact Prefix Product PR Program PG User US Incident Type IT Requirement RQ Incident Priority IP Requirement Step RS Incident Severity IV Test Case TC Workflow WK Test Step TS Workflow Transition WT Test Run TR Custom Property Values PV Test Run Step RS Product Role RX Incident IN Task TK Incident Status IS Test Set TX Custom List CL Document DC Document Type DT Document Folder DF Automation Host AH Build BL Release/Sprint RL Component CP Risk RK Risk Mitigation RMIn addition, certain artifacts in the system are displayed with an icon that helps distinguish them from each other, and provides additional context on the state of the artifact:
Icon Artifact Description Program Product Summary Requirement Detailed Requirement Use Case Requirement Use Case Scenario Step Folder Test Case with Test Steps Test Case without Test Steps Test Set Test Run Test Step Linked Test Case Test Automation Host Test Configuration Release Iteration / Sprint Component Task Incident Risk Risk Mitigation Source Code Commit Product User Build Artifact has an Attachment"},{"location":"Spira-User-Manual/Incident-Tracking/","title":"Incident Tracking","text":"This section outlines how the incident/defect tracking features of SpiraPlan\u00ae can be used to manage key product artifacts during the software development lifecycle. In addition to managing the defects raised during the execution of test cases in the test management module, the Incident Tracker is also a powerful risk/issue/bug tracking system in its own right. When coupled with the product dashboard it is a powerful tool for representing all the key risks and issues associated with a product in a single, graphical format.
Unlike a standalone bug/issue tracking tool however, you can trace the incidents/defects back to the test case and the underlying requirement that generated them, giving the product manager unprecedented power in analyzing the \"in-process\" quality of a system during its lifecycle. This power is clearly illustrated in the \"Requirement Incident Count\" pane in the Product Home dashboard (see User/Product Management > Requirements Coverage).
"},{"location":"Spira-User-Manual/Incident-Tracking/#incident-list","title":"Incident List","text":"When you click on the Tracking > Incidents global navigation link, you will initially be taken to the incidents list screen illustrated below:
The incident list screen displays all the incidents entered for the current product, in a filterable, sortable grid. The grid displays the incident number together with fields such as incident type (bug, issue, risk, etc.), status (new, open, etc.), priority, name, assigned owner, detection date, detector, closed date, etc. The choice of columns displayed is configurable per-user, per-product, giving extensive flexibility when it comes to viewing and searching incidents.
The sidebar on the left gives you quick access to saved filters, along with some useful charts to get an at-a-glance view of incidents for this product. These charts are:
In addition, you can view a more detailed description of the incident (along with a resolution if any) by positioning the mouse pointer over the incident name hyperlink and waiting for the popup \"tooltip\" to appear. If you click on the incident name hyperlink, you will be taken to the incident details page described in Incident Tracking > Incident Details. Clicking on any of the pagination links at the bottom of the page will advance you to the next set of incidents in the list according to the applied filter and sort-order. There is also a drop-down-list at the bottom of the page which allows you to specify how many rows should be displayed in each page, helping accommodate different user preferences.
"},{"location":"Spira-User-Manual/Incident-Tracking/#filtering-sorting","title":"Filtering & Sorting","text":"Read about how to create and manage filters, and how to sort the artifact list.
Incidents can be filtered in special ways when filtering by incident status or incident type:
Clicking on the \"New Incident\" button takes you to the new incident screen. This is essentially the same screen as the incident details screen shown in Incident Details except, depending on how the workflow has been configured for this product, certain fields may be disabled.
"},{"location":"Spira-User-Manual/Incident-Tracking/#delete","title":"Delete","text":"Clicking on the \"Delete\" button deletes the incidents whose check-boxes have been selected in the incident list.
"},{"location":"Spira-User-Manual/Incident-Tracking/#refresh","title":"Refresh","text":"Clicking on the \"Refresh\" button simply reloads the list of incidents; this is useful when new incidents are being added by other users, and you want to make sure you have the most up-to-date list displayed.
"},{"location":"Spira-User-Manual/Incident-Tracking/#show-hide-columns","title":"Show / Hide Columns","text":"This drop-down list allows you to change the fields that are displayed in the incident list as columns for the current product. To show a column that is not already displayed, simply select that column from the list of \"Show...\" column names and to hide an existing column, simply select that column from the list of \"Hide...\" column names. This is stored on a per-product basis, so you can have different display settings for each product that you are a member of. The fields can be any of the built-in fields or any of the custom properties set up by the product owner.
"},{"location":"Spira-User-Manual/Incident-Tracking/#edit","title":"Edit","text":"Each incident in the list has an \"Edit\" button display in its right-most column. When you click this button or just double-click on any of the cells in the row, you change the item from \"View\" mode to \"Edit\" mode. The various columns are made editable, and \"Save\" buttons are displayed in the last column:
If you click \"Edit\" on more than one row, the \"Save\" buttons are only displayed on the first row, and you can make changes to all the editable rows and then update the changes by clicking the one \"Save\" button. Also, if you want to make the same change to multiple rows (e.g. to change five incidents from \"Resolved\" status to \"Closed\"), you can click on the \"fill\" icon to the right of the editable item, which will propagate the new value to all editable items in the same column.
If you want to edit lots of items, first select their checkboxes and then click the \"Edit\" button on the same row as the Filters and it will switch all the selected items into edit mode.
When you have made your updates, you can either click \"Save\" to commit the changes, or \"Cancel\" to revert back to the original information. Alternatively, pressing the <ENTER> key will commit the changes and pressing the <ESCAPE> key will cancel the changes.
"},{"location":"Spira-User-Manual/Incident-Tracking/#cloning-incidents","title":"Cloning Incidents","text":"To create a clone of an existing incident or set of incidents, simply select the check-boxes of the incidents you want to copy and then click \"Clone\" under the Edit menu (or click \"Clone\" from the \"New\" dropdown menu from the Incident's details page). This will make a copy of the current incident with its name prefixed 'Copy of ....' to distinguish itself from the original. Any file attachments will also be copied along with the incident itself.
When cloning Incidents please note that:
Read about how to export artifacts from one product to another.
"},{"location":"Spira-User-Manual/Incident-Tracking/#creating-requirement-from-incidents","title":"Creating Requirement from Incidents","text":"Sometimes you may have enhancements logged that now need to be converted into formal requirements. This may be useful for sprint planning or so test cases and tasks can be made from it. There is a shortcut to create new requirements from selected incidents (1 or more); and it automatically creates an association between each new requirement and the corresponding incident.1
To use this feature:
To quickly print a single incident or list of incidents you can select the items' checkboxes and then click Tools > Print Items. This will display a popup window containing a printable version of the selected items. You can also save the report in a variety of common formats from the same Tools menu.
"},{"location":"Spira-User-Manual/Incident-Tracking/#incident-details","title":"Incident Details","text":"When you click on an incident item in the incident list, or click the \"New Incident\" button (as described in Incident List), you are taken to the incident details page illustrated below:
This page is made up of three areas:
the left pane is the navigation window where you can quickly jump to other incidents;
the upper part of the right pane contains the incident name and key information about it (it's ID number, and what type of incident it is), as well as the current status (see below); and
the bottom part of the right pane displays different information associated with the incident across a number of tabs.
The navigation pane consists of a link that will take you back to the incidents list, as well as a list of the peer incidents to the one selected. This latter list is useful as a navigation shortcut; you can quickly view the peer incidents by clicking on the navigation links without having to first return to the incidents list page. The navigation list can be switched between four different modes:
In addition to the left hand navigation, you can enter a specific incident number in the text-box in the toolbar and click the \"Find\" button. In the same toolbar, there is also a shortcut for creating a copy of the current by clicking the \"Clone\" button.
"},{"location":"Spira-User-Manual/Incident-Tracking/#editing-an-existing-incident","title":"Editing an Existing Incident","text":"When editing an existing incident, the fields that are available and the fields that are required will depend on your stage in the incident workflow. Read about using workflows to change the status of your artifact, and how electronic signatures can further control how you progress an incident through the workflow.
You can print the current incident by clicking Tools > Print, which will display a printable version of the page in a separate window. Alternatively, you can export the incident to a number of formats by selecting the appropriate option from the Tools menu.
"},{"location":"Spira-User-Manual/Incident-Tracking/#inserting-a-new-incident","title":"Inserting a New Incident","text":"If you are creating a new incident, the fields that are available and the fields that are required will depend on how your product has been for configured. For example, some products may require that all incidents be started with Status=New and Type=Incident, others may allow you to specify the incident type. The types of change allowed will depend on how your product administrator has setup the system for you. Administrators should refer to the SpiraPlan Administration Guide for details on configuring the incident workflows to meet their needs.
Once you've filled out the appropriate incident fields, you can either click \"Save\" or one of the options from the \"Save\" dropdown list to commit the changes or click on \"Back to Incident List\" to discard the insertion and return back to the incident list.
"},{"location":"Spira-User-Manual/Incident-Tracking/#overview-comments","title":"Overview - Comments","text":"Read about how the comments works
"},{"location":"Spira-User-Manual/Incident-Tracking/#overview-dates-and-times","title":"Overview -- Dates and Times","text":"This section displays the general schedule and completion status of the specific incident. You can enter/edit:
Any custom date fields set up by the system administrator or product owner will also appear in this section (as shown below with the Review Date field).
Calculating Incident Progress
To help you better track incidents, there are three special calculated fields used for showing the progress of the incident:
Projected Effort is calculated by adding \"Actual Effort\" and \"Remaining Effort\" together.
Percent Complete is calculated as follows:
(Est. Effort - Remaining Effort) / Est. Effort * 100The Progress Indicator is a colorful progress bar of the percent completion:
Progress Indicator Color Incident Progress % Start Date Value Fully gray 0% None or in the future Fully yellow 0% In the past Partly green Between 0% and 100% Anything Fully green 100% AnythingExamples of the progress indicator are shown in the screenshots below:
Note, that unlike for tasks, the progress bar will never be red (because incidents do not have an end (due) date).
"},{"location":"Spira-User-Manual/Incident-Tracking/#attachments","title":"Attachments","text":"Read about how the attachments tab works
"},{"location":"Spira-User-Manual/Incident-Tracking/#associations","title":"Associations","text":"You can associate other incidents, requirements, test steps, tasks, and risks to an incident from this tab.
The incidents and tasks in this list are ones that a user has decided are relevant to the current one and has created a direct link between them. In the case of requirements and test cases, the association can be either due to the creator of an incident directly linking the incident to the requirement or test step, or it can be the result of a tester executing a test-run and creating an incident during the test run. In this latter case, the check-box to the left of the association will be unavailable as the link is not editable.
Read more about how to manage and add associations to this artifact
"},{"location":"Spira-User-Manual/Incident-Tracking/#history","title":"History","text":"Read about how the history tab works
"},{"location":"Spira-User-Manual/Incident-Tracking/#creating-a-requirement-from-an-incident","title":"Creating a Requirement from an Incident","text":"Sometimes you may have an enhancement logged that now needs to be converted into a formal requirement. This may be useful for sprint planning or so test cases and tasks can be made from it. There is a shortcut to create a new requirement from the current incident; and it automatically creates an association between the new requirement and the incident.1
To use this feature:
Add buttonCreate Requirement from this Incident button Read about emailing an incident to colleagues.
"},{"location":"Spira-User-Manual/Incident-Tracking/#incident-followers","title":"Incident Followers","text":"Read about how to add and manage followers to an artifact
"},{"location":"Spira-User-Manual/Incident-Tracking/#incident-board","title":"Incident Board","text":"The incident board is an alternative to the incident list page designed to let you view the incidents planned for the current product. You can access this feature by clicking on the Board icon in the top-right of the Incidents list page. You can switch back to the Incident list page by clicking on the Table view.
The incident board has the following different display modes:
All Releases
Release (select a specific release from the release dropdown - only incidents with a Planned Release matching this selection will be displayed)
Sprint (select a specific sprint from the release dropdown - only incidents with a Planned Release matching this selection will be displayed)
Each of these views is described below.
Planning Boards and Editing
Moving cards: Please note that the purpose of a planning board or Kanban board, is to make it straightforward for users to move cards around the interface to plan out their work. Therefore we do not enforce workflow restrictions on the planning board when moving cards. Therefore only users with permissions to bulk edit the relevant artifact can move cards. If the template admin has prevented status changes while bulk editing, then noone can change a card's status by moving its card on the planning.
Viewing cards: to view more information about the card you can: turn on Detailed View; hover on the card name to see a rich tooltip; click on the card's id to open a popup with much more detail; or ctrl/cmd+click on the card's id to open the full details page for that artifact. Information shown in the popup includes all standard and custom fields with fields being shown or hidden based on the workflow step that applies to that specific card.
Editing cards: users with bulk edit permissions can edit a planning board card at any time by click on the card's id (including adding a new comment). This opens a popup with full information about that card. At all times, which fields are shown, required, or hidden is based on the workflow step that applies to that specific card. To save any changes you must fill in all required fields. Please note: you cannot change the status in this edit mode, to do so open the artifact's detail page (you cand do this from the popup by clicking the button next to the artifact's id at the top).
Add new cards: if you are able to create the requirements then you will see plus (add) symbols in different locations on the board. Clicking any of these will open an popup screen with all relevant fields available. Some of these fields may be prepopulated based on what add button you clicked and how you are using the board. For instance, if you are viewing for a release, that release will be preselected. And if you are grouping by person and click on a particular person, that person will be set as the owner of the artifact. The fields visible and required is driven based on what workflow step will apply to that new card.
"},{"location":"Spira-User-Manual/Incident-Tracking/#incidents-by-priority","title":"Incidents -- By Priority","text":"This view is designed to let you see the list of planned incidents organized by priority. Each of the possible priority values is displayed on the left-hand side and the incidents displayed in the same row on the right:
The top section will contain the list of incidents that are not assigned a priority, with the other sections containing the incidents that have been assigned to the specific priority.
"},{"location":"Spira-User-Manual/Incident-Tracking/#incidents-by-status","title":"Incidents -- By Status","text":"This view is designed to let you see the incidents in the current product / release / sprint organized by their status. Each incident status (not started, in progress, completed, blocked, deferred) is displayed as a heading, with the incidents displayed in the same column underneath:
You can click on the expand/collapse icons to hide any statuses that are not relevant.
Depending on the view (all releases, release, or sprint), there may be sections with the release and sprint name. You can drag and drop the incidents between statuses or to/from the release/sprint backlog. Any incidents not assigned to a release/sprint will be listed in the (Unassigned Items) section at the top.
"},{"location":"Spira-User-Manual/Incident-Tracking/#incidents-by-person","title":"Incidents - By Person","text":"This view is designed to let you see the incidents in the current product / release / sprint organized by resource / person. Each of the users that is a member of the current product is displayed as a heading, with the incidents displayed in the same column underneath:
You can click on the expand/collapse icons to hide any people that are not relevant. The system will display a progress bar for each resource to illustrate the allocation for that resource. Any resource that has a progress bar that is completely green has been fully scheduled and should not have any additional incidents assigned. If the progress bar for that resource turns red, it means that they have been over-scheduled and you need to reassign some of the incidents.
Depending on the view (all releases, release, or sprint), there may be sections with the release and sprint name; they contain incidents that are scheduled for the current release or sprint but have not yet been assigned to a resource. You can drag and drop the incidents between resources or to/from the release/sprint backlog (as long as the item has a status that let's you set or edit its owner field). Any incidents not assigned to a resource and release/sprint will be listed in the (Unassigned Items) section at the top.
"},{"location":"Spira-User-Manual/Incident-Tracking/#incidents-by-release","title":"Incidents - By Release","text":"This view is only available when you are displaying the incident board for 'all releases'. Each of the active releases defined for the current product is displayed as a heading. Incidents are displayed in the release column that matches their Planned Release.
You can drag and drop the incidents between the different releases. Once the incident has been added to the release, the utilized effort for the release will increase, and the available effort will decrease by the same amount.
Note: The system will allow you to assign more incidents to a release than it is possible to complete, however this will result in a negative value for 'available effort'. If this happens, the \"Available Effort\" value will be displayed in red, and you need to rebalance the items, extend the release length or add product personnel resources to the release.
Clicking on the release hyperlinks in the headers will switch the incident board into the release view.
"},{"location":"Spira-User-Manual/Incident-Tracking/#incidents-by-sprint","title":"Incidents - By Sprint","text":"This view is only available when you are displaying the incident board for a specific release. Each of the sprints defined for the current release is displayed as a heading. Incidents are displayed in the sprint column that matches their Planned Release. This view is commonly used in Scrum products:
You can drag and drop the incidents between the different sprints. Once the incident has been added to the sprint, the utilized effort for the sprint will increase, and the available effort will decrease by the same amount.
Note: The system will allow you to assign more incidents to a sprint than it is possible to complete, however this will result in a negative value for 'available effort'. If this happens, the \"Available Effort\" value will be displayed in red, and you need to rebalance the items, extend the sprint length or add product personnel resources to the sprint.
Clicking on the sprint hyperlinks in the headers will switch the incident board into the sprint view.
To create a requirement from an incident, the user needs must have the permission to create requirements (which makes sense).
The creation process does not enforce the relevant requirement workflow to make sure that all required fields are filled in.
What gets copied over from the incident to the new requirement:
\u21a9\u21a9
This section describes the functionality available in SpiraPlan\u00ae when accessing the system from a mobile device such as an iOS\u00ae smartphone / tablet (iPod Touch\u00ae, iPhone\u00ae and iPad\u00ae) or an Android\u00ae smartphone / tablet (Galaxy, Nexus, Droid, Kindle Fire\u00ae, etc.).
The application has been designed to be fully \"responsive\", which means that it will dynamically rearrange the page based on the screen-sized used, to create an optimal experience on any device. As much as possible the application provides a consistent set of functions for any device. However, in order to make using the application on smaller devices as easy as possible, necessarily the experience on say, a smartphone, is less complete than on a desktop.
Whenever this user guide has referred to performing an action by 'clicking' if the same functionality is available, then 'tapping' on a mobile device will yield the same result. Due to the limitations of mobile devices, hovering over an element to display a \"tooltip\" is not possible.
Below, some illustrations of how the application looks at different screen sizes are provided.
"},{"location":"Spira-User-Manual/Mobile-Access/#my-page","title":"My Page","text":"Desktop (a tablet in landscape mode will appear largely identical)
Table in portrait mode
Smartphone in portrait mode
"},{"location":"Spira-User-Manual/Mobile-Access/#my-profile","title":"My Profile","text":"Desktop (a tablet in landscape mode will appear largely identical)
Tablet in portrait mode
Smartphone in portrait mode
"},{"location":"Spira-User-Manual/Mobile-Access/#example-list-page","title":"Example List Page","text":"Desktop (a tablet in landscape mode will appear largely identical)
Tablet in portrait mode
Smartphone in portrait mode
"},{"location":"Spira-User-Manual/Mobile-Access/#example-details-page","title":"Example Details Page","text":"Desktop (a tablet in landscape mode will appear largely identical)
Tablet in portrait mode
Smartphone in portrait mode
"},{"location":"Spira-User-Manual/Mobile-Access/#test-execution","title":"Test Execution","text":"Desktop (a tablet in landscape mode will appear largely identical)
Tablet in portrait mode
Smartphone in portrait mode
"},{"location":"Spira-User-Manual/Planning-Board/","title":"Planning Board","text":"The SpiraPlan planning board is a great way to visualize the backlog items (requirements, tasks, test cases and incidents) planned for your product. Based on the principles of agile methodologies such as Scrum and Kanban, the planning board is a great tool for planning agile products.
Planning Boards and Editing
Moving cards: Please note that the purpose of a planning board or Kanban board, is to make it straightforward for users to move cards around the interface to plan out their work. Therefore we do not enforce workflow restrictions on the planning board when moving cards. Therefore only users with permissions to bulk edit the relevant artifact can move cards. If the template admin has prevented status changes while bulk editing, then noone can change a card's status by moving its card on the planning.
Viewing cards: to view more information about the card you can: turn on Detailed View; hover on the card name to see a rich tooltip; click on the card's id to open a popup with much more detail; or ctrl/cmd+click on the card's id to open the full details page for that artifact. Information shown in the popup includes all standard and custom fields with fields being shown or hidden based on the workflow step that applies to that specific card. Users who cannot bulk edit the artifact but who can add comments can add comments when viewing the card.
Editing cards: users with bulk edit permissions can edit a planning board card at any time by clicking on the card's id (including adding a new comment). This opens a popup with full information about that card. At all times, which fields are shown, required, or hidden is based on the workflow step that applies to that specific card. To save any changes you must fill in all required fields. Please note: you cannot change the status in this edit mode, to do so open the artifact's detail page (you can do this from the popup by clicking the button next to the artifact's id at the top).
Add new cards: if you are able to create the requirements then you will see plus (add) symbols in different locations on the board. Clicking any of these will open an popup screen with all relevant fields available. Some of these fields may be prepopulated based on what add button you clicked and how you are using the board. For instance, if you are viewing for a release, that release will be preselected. And if you are grouping by person and click on a particular person, that person will be set as the owner of the artifact. The fields visible and required is driven based on what workflow step will apply to that new card.
To access the SpiraPlan product planning board, select a product and go to Artifacts > Planning Board and the following screen will be displayed:
By default, the system will display the product planning board in the product backlog view, with the backlog organized by component. You can change the view by click on the 'Planning' drop down list:
The 'Group By' dropdown list is used to change how the view is organized. This list of options available in the 'Group By' dropdown will depend on the view being displayed.
The planning board will include the following backlog items:
Requirements and Incidents -- these are displayed as 'story cards' and are the primary items that can be moved in the planning board.
Tasks and Test Cases -- these are secondary artifacts and are considered part of a requirement. So within the planning board they are displayed as being part of a specific requirement, and if you move a requirement, the associated tasks and test cases will move as well.
The backlog items themselves can be configured to display in different ways. The choice of display will depend on how many backlog items you have to display, how large your screen is and what information you need. The display is controlled by the four checkboxes at the top of the planning board:
Numerical rankings are also shown. The ranking numbers go from left to right and top to bottom. They indicate the relative ordering and priority of the various story cards and defects.
Regardless of the view, backlog items can be moved using \"drag and drop\" between the different parts of the planning board. To drag and drop multiple items, you should first select the items so that they are highlighted. Then you can drag and drop the entire selection:
You can add new requirement backlog items by clicking the \"+\" button. This will display the following dialog box:
On this screen you can enter the fields for a new requirement, click \"Add Requirement\" and the requirement will be added to the appropriate section of the planning board.
In some of the views of the planning board there will be more data that can be displayed on one screen, in which case you will be able to scroll the planning board left and right using the specially provided arrow buttons.
Each of the views is now described in more detail in the sections below.
What statuses show when grouping by status?
When you group by statuses, the statuses you see will change based on what you are looking at. Specifically, the statuses you see when on the product backlog view are different than those you see when looking at the \"All Releases\" view, or a single release or sprint.
The statuses shown are based on the template's workflows.
The product backlog view is designed to let you view the backlog items that have been created for the product and have not yet been assigned to a specific release or sprint. The backlog items can be requirements or incidents, and in the case of requirements, you can see the tasks and test cases associated with a specific requirement.
In this view you can drag and drop the backlog items from one section (e.g. component) to another and also rearrange the backlog items in their relative order. By default, the items are sorted according to their priority/importance value (the color of which is indicated in the left-hand side of the story card), but you can drag and drop them into a different order. This is particularly useful when you have several items of the same priority and you need to rank them. This process is typically called backlog grooming.
"},{"location":"Spira-User-Manual/Planning-Board/#product-backlog-by-component","title":"Product Backlog -- By Component","text":"This view is designed to let you see the product backlog organized by Component. Each of the components is displayed on the left-hand side and the backlog items displayed in the same row on the right. The backlog items can be requirements (with associated tasks and test cases) or incidents.
The top section will contain the list of items that are not assigned to a component, with the other sections containing the items that belong to the specific component.
"},{"location":"Spira-User-Manual/Planning-Board/#product-backlog-by-parent","title":"Product Backlog -- By Parent","text":"This view is designed to let you see the product backlog organized by parent requirements (those with at least one child requirement). Each of the parents is displayed on the left-hand side in a hierarchical structure, and the backlog items displayed in the same row on the right. The backlog items can be child requirements (with associated tasks and test cases) or incidents. In this view the incidents are the ones linked to the parent requirement through an association.
The top section will contain the list of items that are not assigned to a parent requirement, with the other sections containing the items that are children of the specific parent.
"},{"location":"Spira-User-Manual/Planning-Board/#product-backlog-by-priority","title":"Product Backlog -- By Priority","text":"This view is designed to let you see the product backlog organized by requirement importance. Each of the possible importance values is displayed on the left-hand side and the backlog items displayed in the same row on the right. The backlog items in this view will only be requirements (with associated tasks and test cases).
The top section will contain the list of items that are not assigned a priority, with the other sections containing the items that have been assigned to the specific priority.
"},{"location":"Spira-User-Manual/Planning-Board/#product-backlog-by-status","title":"Product Backlog -- By Status","text":"This view is designed to let you see the product backlog organized by requirement status. Each of the possible status values (for an unscheduled item) is displayed as a heading, with the backlog items displayed in the same column underneath. The backlog items in this view will only be requirements (with associated tasks and test cases). This view is commonly called a Kanban board:
Each of the vertical sections is one of the requirements' statuses, in order of the requirement lifecycle (Requested > Accepted). Once a requirement is assigned to a release or sprint it will come automatically 'Planned' and not appear in this view. You can drag and drop the requirements between the different statuses.
"},{"location":"Spira-User-Manual/Planning-Board/#release-planning","title":"Release Planning","text":"The 'All Releases' option lets you view all of the backlog items that have already been assigned to a release - and are therefore not in the product backlog. The backlog items can be requirements or incidents, and in the case of requirements, you can see the tasks and test cases associated with a specific requirement.
The lower section of the board allows you to view the items by either by release, priority, status, or person. Each section below will discuss each option in turn.
"},{"location":"Spira-User-Manual/Planning-Board/#release-planning-by-component","title":"Release Planning -- By Component","text":"This view is designed to let you see items across all releases organized by Component. Each of the components is displayed on the left-hand side and the backlog items displayed in the same row on the right. The backlog items can be requirements (with associated tasks and test cases) or incidents.
The top section will contain the list of items that are not assigned to a component, with the other sections containing the items that belong to the specific component.
"},{"location":"Spira-User-Manual/Planning-Board/#release-planning-by-parent","title":"Release Planning -- By Parent","text":"This view is designed to let you see items across all releases organized by parent requirement. Each of the parents is displayed on the left-hand side in a hierarchical structure, and the items are displayed in the same row on the right. The items can be child requirements (with associated tasks and test cases) or incidents. In this view the incidents are the ones linked to the parent requirement through an association.
The top section will contain the list of items that are not assigned to a parent requirement, with the other sections containing the items that are children of the specific parent.
"},{"location":"Spira-User-Manual/Planning-Board/#release-planning-by-priority","title":"Release Planning -- By Priority","text":"This view is designed to let you see the list of items across all releases, organized by requirement importance. Each of the possible importance values is displayed on the left-hand side and the items displayed in the same row on the right. The items in this view will only be requirements (with associated tasks and test cases).
The top section will contain the list of items that are not assigned a priority, with the other sections containing the items that have been assigned to the specific priority.
"},{"location":"Spira-User-Manual/Planning-Board/#release-planning-by-release","title":"Release Planning -- By Release","text":"This release planning view is designed to let you view the items across all releases that have been created for the product and associate them with different releases defined for the product
The 'Unassigned Items' section at the top allows you to see all the items not currently planned, and you can then drag and drop them into one of the lower sections that correspond to a specific release. Using the scroll arrows you can cycle through the releases and move any items from one release to another.
The header of each release section shows the overall progress and utilization of the release:
Clicking on the Release hyperlink will switch the planning board into the Release Backlog view described below.
"},{"location":"Spira-User-Manual/Planning-Board/#release-planning-by-status","title":"Release Planning -- By Status","text":"This view is designed to let you see the product planned items organized by requirement status. Each of the possible status values (for a planned item) is displayed as a heading, with the items displayed in the same column underneath. The items in this view will only be requirements (with associated tasks and test cases). This view is commonly called a Kanban board:
Each of the vertical sections is one of the requirements' statuses, in order of the requirement lifecycle (Planned > Completed). You can click on the expand/collapse icons to hide any statuses that are not used. You can drag and drop the requirements between the different statuses. If you have the planning options enabled to have requirements status' automatically update based on changes to the associated tasks and test cases, then items will automatically move between the statuses based on tasks being completed and test cases being executed.
"},{"location":"Spira-User-Manual/Planning-Board/#release-planning-by-person","title":"Release Planning -- By Person","text":"This view is designed to let you see the product planned items organized by resource / person. Each of the users that is a member of the current release is displayed as a heading, with the items displayed in the same column underneath. The items in this view can be either requirements (with associated tasks and test cases) or incidents.
You can click on the expand/collapse icons to hide any resources that are not relevant. Above the resource headings there is a section with the release name; that contains items that are scheduled for the current release but have not yet been assigned to a resource. You can drag and drop the items between resources (as long as the item has a status that let's you set or edit its owner field). Or you can move them to/from the release backlog. Any items not assigned to a resource and release will be listed in the (Unassigned Items) section at the top.
"},{"location":"Spira-User-Manual/Planning-Board/#release-backlog-planning","title":"Release Backlog Planning","text":"The release backlog view is designed to let you view the backlog items that have been assigned to the selected release. You can always see the items not currently assigned to any release by expanding the 'Unassigned Items' section and then drag those items into the current release.
The lower section of the board allows you to segment the items by either iteration/sprint (typically used in Scrum), by status (typically used in Kanban), or by person.
"},{"location":"Spira-User-Manual/Planning-Board/#release-backlog-by-component","title":"Release Backlog -- By Component","text":"This view is designed to let you see the release backlog organized by Component. Each of the components is displayed on the left-hand side and the backlog items displayed in the same row on the right. The backlog items can be requirements (with associated tasks and test cases) or incidents.
The top section will contain the list of items that are not assigned to a component, with the other sections containing the items that belong to the specific component.
"},{"location":"Spira-User-Manual/Planning-Board/#release-backlog-by-parent","title":"Release Backlog -- By Parent","text":"This view is designed to let you see the release backlog organized by parent requirement. Each of the parents is displayed on the left-hand side in a hierarchical structure, and the items are displayed in the same row on the right. The items can be child requirements (with associated tasks and test cases) or incidents. In this view the incidents are the ones linked to the parent requirement through an association.
The top section will contain the list of items that are not assigned to a parent requirement, with the other sections containing the items that are children of the specific parent.
"},{"location":"Spira-User-Manual/Planning-Board/#release-backlog-by-priority","title":"Release Backlog -- By Priority","text":"This view is designed to let you see the list of planned backlog items in the current release, organized by requirement importance. Each of the possible importance values is displayed on the left-hand side and the backlog items displayed in the same row on the right. The backlog items in this view will only be requirements (with associated tasks and test cases).
The top section will contain the list of items that are not assigned a priority, with the other sections containing the items that have been assigned to the specific priority.
"},{"location":"Spira-User-Manual/Planning-Board/#release-backlog-by-sprint","title":"Release Backlog -- By Sprint","text":"This view is designed to let you see the release backlog organized by iteration / sprint. Each of the sprints defined for the current release is displayed as a heading, with the backlog items displayed in the same column underneath. The backlog items in this view can be either requirements (with associated tasks and test cases) or incidents. This view is commonly called a Scrum board:
You can drag and drop the requirements between the different sprints. If you schedule a requirement for a specific sprint, all the child tasks that have not yet been started, will follow the parent requirement in being associated with the sprint. Once the backlog item has been added to the sprint, the utilized effort for the sprint will increase, and the remaining effort will decrease by the same amount.
Note: The system will allow you to assign more backlog items to an sprint than it is possible to complete, however this will result in a negative value for 'remaining effort'. If this happens, the \"Remaining\" value will be displayed in red - as will the sprint header area and the cards column. This alerts you that you need to rebalance the items, extend the sprint length, or add product personnel resources to the sprint.
Clicking on the Sprint hyperlinks in the headers will switch the planning board into the Sprint Backlog view described below.
"},{"location":"Spira-User-Manual/Planning-Board/#release-backlog-by-status","title":"Release Backlog -- By Status","text":"This view is designed to let you see the release backlog organized by requirement status. Each of the possible status values (for a planned item) is displayed as a heading, with the backlog items displayed in the same column underneath. The backlog items in this view will only be requirements (with associated tasks and test cases). This view is commonly called a Kanban board:
Each of the vertical sections is one of the requirements' statuses, in order of the requirement lifecycle (Planned > Completed). You can click on the expand/collapse icons to hide any statuses that are not used. You can drag and drop the requirements between the different statuses. If you have the planning options enabled to have requirements status' automatically update based on changes to the associated tasks and test cases, then items will automatically move between the statuses based on tasks being completed and test cases being executed.
"},{"location":"Spira-User-Manual/Planning-Board/#release-backlog-by-person","title":"Release Backlog -- By Person","text":"This view is designed to let you see the release backlog organized by resource / person. Each of the users that is a member of the current release is displayed as a heading, with the backlog items displayed in the same column underneath. The backlog items in this view can be either requirements (with associated tasks and test cases) or incidents.
You can click on the expand/collapse icons to hide any resources that are not relevant. The system will display a progress bar for each resource to illustrate the allocation for that resource. Any resource that has a progress bar that is completely green has been fully scheduled and should not have any additional items assigned. If the progress bar for that resource turns red, it means that they have been over-scheduled and you need to reassign some of the items.
Above the resource headings there is a section with the release name; that contains backlog items that are scheduled for the current release but have not yet been assigned to a resource (as long as the item has a status that let's you set or edit its owner field). You can drag and drop the backlog items between resources or to/from the release backlog. Any backlog items not assigned to a resource and release will be listed in the (Unassigned Items) section at the top.
"},{"location":"Spira-User-Manual/Planning-Board/#sprint-backlog-planning","title":"Sprint Backlog Planning","text":"The sprint backlog view is designed to let you view the backlog items that have been assigned to the selected iteration / sprint. You can always see the items not currently assigned to any release or sprint by expanding the 'Unassigned Items' section and then drag those items into the current release or sprint.
The lower section of the board allows you to segment the items by either status (typically used in Kanban), or by person. You can also view the Task artifacts by person or status for the current sprint.
"},{"location":"Spira-User-Manual/Planning-Board/#sprint-backlog-by-component","title":"Sprint Backlog -- By Component","text":"This view is designed to let you see the sprint backlog organized by Component. Each of the components is displayed on the left-hand side and the backlog items displayed in the same row on the right. The backlog items can be requirements (with associated tasks and test cases) or incidents.
The top section will contain the list of items that are not assigned to a component, with the other sections containing the items that belong to the specific component.
"},{"location":"Spira-User-Manual/Planning-Board/#sprint-backlog-by-parent","title":"Sprint Backlog -- By Parent","text":"This view is designed to let you see the sprint backlog organized by parent requirement. Each of the parents are displayed on the left-hand side in a hierarchical structure, and the items are displayed in the same row on the right. The items can be child requirements (with associated tasks and test cases) or incidents. In this view the incidents are the ones linked to the parent requirement through an association.
The top section will contain the list of items that are not assigned to a parent requirement, with the other sections containing the items that are children of the specific parent.
"},{"location":"Spira-User-Manual/Planning-Board/#sprint-backlog-by-priority","title":"Sprint Backlog -- By Priority","text":"This view is designed to let you see the list of planned backlog items in the current sprint, organized by requirement importance. Each of the possible importance values is displayed on the left-hand side and the backlog items displayed in the same row on the right. The backlog items in this view will only be requirements (with associated tasks and test cases).
The top section will contain the list of items that are not assigned a priority, with the other sections containing the items that have been assigned to the specific priority.
"},{"location":"Spira-User-Manual/Planning-Board/#sprint-backlog-by-status","title":"Sprint Backlog -- By Status","text":"This view is designed to let you see the sprint plan organized by requirement status. Each of the possible status values (for a planned item) is displayed as a heading, with the backlog items displayed in the same column underneath. The backlog items in this view will only be requirements (with associated tasks and test cases).
Each of the vertical sections is one of the requirements' statuses, in order of the requirement lifecycle (Planned > Completed). You can drag and drop the requirements between the different statuses. If you have the planning options enabled to have requirements status' automatically update based on changes to the associated tasks and test cases, then items will automatically move between the statuses based on tasks being completed and test cases being executed.
"},{"location":"Spira-User-Manual/Planning-Board/#sprint-backlog-by-person","title":"Sprint Backlog -- By Person","text":"This view is designed to let you see the sprint plan organized by resource / person. Each of the users that is a member of the current sprint is displayed as a heading, with the backlog items displayed in the same column underneath. The backlog items in this view can be either requirements (with associated tasks and test cases) or incidents.
You can click on the expand/collapse icons to hide any resources that are not relevant. The system will display a progress bar for each resource to illustrate the allocation for that resource. Any resource that has a progress bar that is completely green has been fully scheduled and should not have any additional items assigned. If the progress bar for that resource turns red, it means that they have been over-scheduled and you need to reassign some of the items.
Above the resource headings there are sections with the release and sprint name; they contain backlog items that are scheduled for the current release or sprint but have not yet been assigned to a resource. You can drag and drop the backlog items between resources or to/from the release/sprint backlog (as long as the item has a status that let's you set or edit its owner field). Any backlog items not assigned to a resource and release/sprint will be listed in the (Unassigned Items) section at the top.
"},{"location":"Spira-User-Manual/Planning-Board/#work-in-progress-limits","title":"Work In Progress Limits","text":"If the product is using Work in Progress (WIP) limits set, they will be shown in a little pill shaped badge on each relevant status, along with the number of requirement cards in that status for that release/sprint.
Read more about how to set up and use WIP limits.
"},{"location":"Spira-User-Manual/Planning-Board/#beta-planning-board","title":"Beta planning board","text":"In beta, available in SpiraTeam and SpiraPlan
System admins can enable beta functionality across the application for their users from the System Admin > General Settings page.
To learn more about how the planning board is structured or how to enter the beta please refer to our general information about the beta boards.
"},{"location":"Spira-User-Manual/Planning-Board/#views-summary","title":"Views summary","text":"Details about what combinations of views is possible and how each feature works is discussed in detail the sections below. For ease of reference, here is a summary of the different options available (you cannot select the same value for multiple view options at the same time):
View options Product Backlog Release Backlog Sprint Backlog Releases Not Available Open releases (excluding sprints) Open sprints Open parents Grouping Component Priority Component Priority Release Team Component Priority Sprint Team Columns Priority Status Priority Person Status Priority Person Status Rows Component Parent Requirement Component Person Parent Requirement Component Person Parent Requirement"},{"location":"Spira-User-Manual/Planning-Board/#view-controls-planning","title":"View controls - Planning","text":"The planning board has three different planning options. They impact what options are available in the other toolbar controls, and how the boards display:
Release backlog: lets managers review planned or in progress work items. This view displays all the planned items (based on status) so that the project manager can:
Sprint backlog: lets managers review work in a release and its sprint, or for a single sprint. This view displays all the planned items in a release and its sprints so that the product owner or manager can:
The release selector is only visible when the planning dropdown is set to either the release backlog or the sprint backlog.
When viewing the release backlog the dropdown will show:
When viewing the sprint backlog the dropdown will show:
Read about this here.
"},{"location":"Spira-User-Manual/Planning-Board/#columns","title":"Columns","text":"Read about this here.
What statuses show
What statuses shown on the board depends on how the template has been configured. In short:
Read about this here.
"},{"location":"Spira-User-Manual/Planning-Board/#customizing-the-cards","title":"Customizing the cards","text":"You can customize what information is shown on each card. For each artifact the following fields are always shown:
You can toggle whether to show each of the following features:
Note that the test coverage mini section shows the number of test cases covering the requirement in parentheses after its title. The task progress mini section shows the number of the requirement's child tasks in parentheses after its title.
Here's a typical card with all of the features described above turned off.
In the example below, is a card with all of the features described above turned on.
Finally, you can, based on your view, toggle other artifact cards to show. When this option is available you can toggle relevant artifact cards (eg Incidents) on or off. See below to learn what cards and card artifact show when.
"},{"location":"Spira-User-Manual/Planning-Board/#what-cards-show-when","title":"What cards show when","text":"Read about this here. In addition to the rules explained there, the following rules apply to how incident card display on the planning board:
Incidents have a priority field, which is different to the requirement importance field. These two fields are customized independently by template administrators.
However on the planning board, when organizing by priority, you may see both requirement cards and incident cards (if set to show). This is because the system automatically matches up incident priority and requirement importance. It does based on their names. If a requirement importance has an exactly matching incident priority (case sensitive), then any incidents with that priority will show in that \"priority\" column on the planning board. You can move incident cards between priorities and as long as there is match, the incident priority will be updated.
"},{"location":"Spira-User-Manual/Planning-Board/#what-cards-show-when-viewing-the-product-backlog","title":"What cards show when viewing the product backlog","text":"The following cards will show in this view (in combination with the relevant principles described above):
The following rules apply to what cards will show (note that more than one of these rules may apply at once):
View selected Requirements shown Incidents shown Release is all releases (Group by is not release) all requirements with a release set incidents with a planned release Release is a single release (Group by is not release) requirements with that release, or any of its child sprints incidents with that release as its planned release Group is release (Groups that are for a release) requirements with that release, or any of its child sprints incidents with that release as its planned release Group is release (in the \"unassigned\" group) requirements with no release incidents with no planned release"},{"location":"Spira-User-Manual/Planning-Board/#what-cards-show-when-viewing-the-sprint-backlog","title":"What cards show when viewing the sprint backlog","text":"The following rules apply to what cards will show (note that more than one of these rules may apply at once):
View selected Requirements shown Incidents shown Release is a single release (Group by is not release) requirements with that release, or any of its child sprints incidents with that release as its planned release Release is a single sprint (Group by is not release) requirements with that sprint incidents with that sprint as its planned release Group is sprint (Groups that are for a sprint or release) requirements with that specific sprint or release incidents with that sprint or release as its planned release Group is sprint (in the \"unassigned\" group) requirements with no release incidents with no planned release"},{"location":"Spira-User-Manual/Planning-Board/#moving-and-ordering-cards","title":"Moving and ordering cards","text":"Read about this here.
"},{"location":"Spira-User-Manual/Planning-Board/#viewing-by-release-or-sprint","title":"Viewing by release or sprint","text":"Read about this here.
"},{"location":"Spira-User-Manual/Planning-Board/#viewing-by-person","title":"Viewing by Person","text":"Read about this here.
"},{"location":"Spira-User-Manual/Planning-Board/#status-and-work-in-progress-limits","title":"Status and Work in Progress Limits","text":"When viewing by status and either grouping by releases/sprints or displaying for a release/sprint, extra information may show on each status column. If the product is using Work in Progress (WIP) limits set, the relevant limit for each status will show in a little pill shaped badge in the header for that status, along with the number of requirement cards in that status for that release/sprint. For example, if the limit is 3 and there are 2 cards then the pill will read \"\u2154\" - 2 of 3 requirements.
There are different colors to indicate the status of the WIP limit:
Read more about how to set up and use WIP limits.
"},{"location":"Spira-User-Manual/Planning-Board/#editing-and-viewing-cards","title":"Editing and viewing cards","text":"Read about this here.
"},{"location":"Spira-User-Manual/Planning-Board/#example-use-cases","title":"Example use cases","text":""},{"location":"Spira-User-Manual/Planning-Board/#scrum-projects","title":"Scrum Projects","text":"For Scrum projects, the boards support the most important agile ceremonies and planning activities. For example, you can show all the unplanned items in the product backlog for backlog grooming. In this example we are displaying user stories by parent (or epic) as rows, grouped by component and categorized into columns by priority.
Release planning: for a typical release planning section, you can use the following release backlog view. In this example, we are displaying all the releases, with the ability to take items from the product backlog (at the top) and assign them to a specific release.
Sprint planning: for a sprint planning session, the following view will let you assign work to each sprint from the release backlog:
Finally, you can drill down to look at an individual sprint and see the team's progress. This is useful for daily standup meetings:
"},{"location":"Spira-User-Manual/Planning-Board/#kanban-projects","title":"Kanban Projects","text":"For Kanban projects, in addition to the functionality described above, you have the ability to see the different releases by status, with the Work In Progress Limits clearly visible in each of the swim-lanes. In this example, we are showing the release backlog for a specific release, with the columns set to display by status and the planning options set to include WIP limits for the In-Progress and Developed columns.
"},{"location":"Spira-User-Manual/Portfolio-Homepage/","title":"Portfolio Homepage","text":""},{"location":"Spira-User-Manual/Portfolio-Homepage/#overview","title":"Overview","text":"Who Can Access the Portfolio Homepage?
To access the portfolio homepage first, you need to be using SpiraPlan. Second, your user must be a Portfolio Viewer. System Administrators can control this setting on a user by user basis. If you are a Portfolio Viewer you will also be able to access the Enterprise Homepage.
If you are NOT a portfolio viewer, you can still see how your organization structures its portfolios, programs, and products from the workspace dropdown.
When you navigate to a Portfolio from the global navigation bar or from any link to it in the application, you will be taken to the homepage of that portfolio:
This page summarizes all of the information about the portfolio in a \"one-stop-shop\". You will see a small \"i\" in a circle at the top right of each widget. Hovering or clicking on this will show you information about that chart.
In a similar manner to other home pages in the application (like the 'My Page'), the Portfolio Home is loaded in 'view mode'. To switch the page to 'edit mode', click the button with the cog icon () on the right.
In 'edit mode', each widget can be:
Together, these editing options let you change the page to suit your needs. If you close a widget and then later want to open it again click the \"+ Add\" button at the top of the page (next to the 'edit mode' button). This brings up a list of all the widgets you can add onto the page (including a list of 'Closed Widgets'). You can choose where on the page each widget should go.
Please note
Any changes you make to this page (e.g. editing, moving, closing widgets) will only affect your user and on this particular home page. They do not affect any other user.
By default, the Enterprise home page shows the following widgets and are described in more details below
This widget displays the description of the portfolio.
"},{"location":"Spira-User-Manual/Portfolio-Homepage/#requirement-completion","title":"Requirement Completion","text":"This chart shows the proportion of all active requirements that have been completed across all active programs in this portfolio. When 100% of the requirements are completed, the color changes so that it is easy to tell what is in progress vs completed.
"},{"location":"Spira-User-Manual/Portfolio-Homepage/#top-open-risks","title":"Top Open Risks","text":"This widget lists the top risks logged against any of the products in the portfolio, ordered by exposure. Clicking on the risk name will open the risk details page for the risk in question. Note: you can configure the widget settings to control the maximum number of risks to show.
"},{"location":"Spira-User-Manual/Portfolio-Homepage/#programs-completion","title":"Programs: Completion","text":"This chart shows the progress of each program in this portfolio. The left-hand shows progress from the start to end date of the program. The bar's color indicates how on track the schedule is against requirement completion. The right-hand chart shows the proportion of requirements across active workspaces in the program that have been completed.
Schedule Progress color definitions:
Example
A program started a week ago and will finish in a week. Therefore its schedule is 50% of the way through (1 week down, 1 week to go).
The Schedule Progress bar will show as 50% (if you click \"Displaying\" button to \"As Numbers\" it will show 7 days).
This program has a total of 20 requirements (summed up from all its products and their active releases). Let's say that 15 of these are completed. That's 75% complete. So the Requirements Complete bar will show 75% (if you click \"Displaying\" button to \"As Numbers\" it will show 15 completed).
So the schedule is half way through but we are three quarters done with the work (the requirements). So we are ahead of schedule (awesome!). The schedule bar will therefore have the \"Ahead of Schedule\" color.
What if, instead of finishing next week, we were supposed to finish last week? Well, the schedule bar would be flagged as \"Behind Schedule\". This is because we are only 75% complete on the work, but the end date is in the past.
Tip: You can hover over a bar to get more information.
"},{"location":"Spira-User-Manual/Portfolio-Homepage/#programs-relative-size","title":"Programs: Relative Size","text":"This chart shows the number of active requirements in each active program. Hovering over a segment will show its percentage of all requirements (this is visually represented by the size of the donut wedge). Please note, programs with no active requirements are not shown.
"},{"location":"Spira-User-Manual/Portfolio-Homepage/#schedule","title":"Schedule","text":"This Gantt chart shows all active programs, products, releases, and sprints in this portfolio. Each bar spans from the item's start date to end date. The darker shaded portion of each bar tells you how complete its requirements are.
"},{"location":"Spira-User-Manual/Portfolio-Homepage/#recent-builds","title":"Recent Builds","text":"This widget displays a list of the most recent builds for each active release (organized alphabetically by program and then product; in each product the builds are listed by date). For each build it shows:
You can change the number of builds the widget should show in the widget's settings (the default is 15).
"},{"location":"Spira-User-Manual/Product-Homepage/","title":"Product Homepage","text":""},{"location":"Spira-User-Manual/Product-Homepage/#overview","title":"Overview","text":"When you click on either the \"Product Home\" tab or the name of the product in the \"My Page\" product list, you will be taken to the homepage of the specific product in question:
This page summarizes all of the information regarding the product into a comprehensive, easily digestible form that provides a \"one-stop-shop\" for people interested in understanding the overall status of the product at a glance. It contains summary-level information for all types of artifact (requirements, test cases, incidents, etc.) that you can use to drill-down into the appropriate section of the application.
You will see a small \"i\" in a circle at the top right of every chart. Hovering or clicking on this will show you information about that chart.
In addition to viewing the product home page, you can choose to filter by a specific release, to get the homepage for just that release (and any child sprints).
Just like the 'My Page', the Product Home dashboard is initially loaded in 'view mode' with pre-configured set of widgets. The Product Home has 3 versions you can quickly switch between. While each of these can be customized as you want, by default they are designed to help different types of product member -- be they managers, testers, or developers.
To download an image of the entire dashboard click the 'picture' button beneath the currently selected view.
To switch the page to 'edit mode', you should click on the button with the cog icon () below the currently selected Product Home view.
Once in 'edit mode', each of the 'widgets' displayed on the product homepage can be minimized by clicking on the arrow icon () in the top-left of the window, or closed by clicking-on the cross icon () in the top-right of the window. In addition, the widgets allow you change their settings by clicking on the settings icon ().This allows you to customize your view of the product to reflect the types of information that are relevant to you. If you have closed a widget that you subsequently decide you want to reopen, you can rectify by clicking the \"Add Items\" button at the top of the page, and locating the closed item from the list of 'Closed Widgets'.
By default, the product home page shows the \"General\" view. The following table shows which widgets are displayed on the different views of the 'Product Home':
Widget Name General Development Testing Product Overview Y Y Y Activity Stream Y Y Shared Searches Y Schedule Y Requirement Completion Y Requirement Incident Count Y Y Y Requirements Coverage Y Y Requirements Graphs Y Y Requirements Regression Coverage Y Requirements Summary Y Y Y Release Task Progress Y Y Release Test Summary Y Y Releases/Sprints Completion Y Releases/Sprints Relative Size Y Recent Builds Y Tag Cloud Test Case Progress By Day Y Test Execution Status Y Y Test Set Status Y All Pending Test Runs Y Test Run Progress Y Incident Aging Y Incident Open Count Y Y Y Incident Test Coverage Incident Summary Y Y Y Top Open Issues Y Y Risk Summary Y Top Open Risks Y Late Finishing Tasks Y Y Late Starting Tasks Y Task Graphs Y Y Source Code Commits YPlease note that different widgets are shown by default for the \"Developer\" and for the \"Tester\" views.
If you click on the \"+ Add\" items button it will display the list of any additional widgets that are available for that view. Below is what this looks like for the 'General' view:
You can add the additional widgets by selecting the appropriate checkbox, choosing the destination location (left side vs. right side) and then click the \"Add\" button.
Each of the different widgets listed is described in more detail below:
"},{"location":"Spira-User-Manual/Product-Homepage/#product-overview","title":"Product Overview","text":"This section displays:
This section shows a list of the most recent changes made by any product member anywhere in the product. It only displays changes to artifacts that the current user is allowed to view (based on their product role). Here is an example activity item - you can see that it displays information about the user who made the change, what was changed, how it was changed, and when:
System Administrator modified Incident [IN:1] - Cannot log into the application | Tuesday, November 2, 2021 2:01:34 PM
You can configure how many recent changes to display.
Clicking the \"View All\" button at the top of this section will open the \"Activity List\" page. This page shows every change ever made in the product in a single, paginated list for artifacts that the current user is allowed to view (based on their product role).The list can be sorted on or filtered by any field. The list shows the following columns:
This section lists any filters/searches have been saved from the various artifact list screens throughout the application and marked as shared filters. This allows users to store specific combinations of searches that the product team needs to perform on a regular basis (e.g. display all newly logged incidents, display all requirements that are completed but have no test coverage).
The name of the saved search is displayed along with an icon that depicts which artifact it's for and the person who created it. Clicking on the name of the saved search will take you to the appropriate screen in the product and set the search parameters accordingly. If you are the creator of the saved search, clicking the \"Delete\" button next to the saved search will delete it. Clicking on the RSS icon will allow you to subscribe to the specific search so that it will be displayed in your RSS newsreader. This allows you to setup customized lists of information that can be displayed outside of SpiraPlan.
"},{"location":"Spira-User-Manual/Product-Homepage/#schedule","title":"Schedule","text":"This Gantt chart shows all active releases1 and sprints in this product. Each bar spans from the item's start date to end date. The darker shaded portion of each bar tells you how complete its requirements are.
"},{"location":"Spira-User-Manual/Product-Homepage/#requirement-completion","title":"Requirement Completion","text":"This chart shows the proportion of all active requirements that have been completed across all active releases in this product. When 100% of the requirements are completed, the color changes so that it is easy to tell what is in progress vs completed.
"},{"location":"Spira-User-Manual/Product-Homepage/#requirement-incident-count","title":"Requirement Incident Count","text":"This section displays a count of the total number of incidents, and the number of open incidents mapped against requirements in the system, sorted by the requirements that have the most open incidents first. This section is useful for determining the parts of the application that have the most instability, as you can look at the requirements that have yielded the greatest number of incidents. Clicking on any of the requirements hyperlinks will take you to the detail page for the requirement in question. You can configure in the settings whether to include requirements with no open incidents, and also how many rows of data to display.
"},{"location":"Spira-User-Manual/Product-Homepage/#requirements-coverage","title":"Requirements Coverage","text":"This section consists of a bar graph that displays the aggregated count of requirements test coverage for the product. The Passed, Failed, Blocked, Caution and Not-Run bars indicate the total count of requirements that have tests covering them, allocated across the execution status of the covering tests. For example, if a requirement is covered by four tests, two that have passed, one that has failed and one that has not yet been run, the counts would be passed = 0.5, failed = 0.25 and not-run 0.25. These fractional quantities are then summed across all the requirements to give the execution status breakdown of the covered requirements.
In addition to the five statuses for the covered requirements, the sixth (\"Not Covered\") bar depicts the total number of requirements that have no tests covering them, putting the five other bars into perspective. Typically a product is in good health if the \"Not Covered\" bar is zero, and the count of \"Passed\" requirements is greater than \"Failed\", \"Caution\" or \"Not Run\". The greatest risk lies with the \"Blocked\", \"Not Covered\" and \"Not Run\" status codes, since the severity/quantity of any bugs lurking within is not yet fully known.
If you position the mouse pointer over any of the four bars, the color of the bar changes slightly and the underlying raw data is displayed as a tooltip, together with the percentage equivalent. Clicking on the any of the bars in the chart will take you to the requirements list page with the corresponding filters set.
When you filter the product home by release/sprint, this widget will filter the requirements coverage graph to only include requirements that are specifically mapped to the selected release/sprint. This is useful when you want to determine the test coverage of new requirements that are being added to the specific release/sprint. If instead you want to determine the regression test coverage for a release, you should add the separate \"Requirements Regression Coverage\" widget to the page instead.
"},{"location":"Spira-User-Manual/Product-Homepage/#requirements-graphs","title":"Requirements Graphs","text":"This widget lets you quickly view four different graphs used when measuring the progress of requirements in an agile methodology. They are described in more detail in Reports.
Requirement Velocity -- this graph shows the actual velocity delivered in each product release and/or sprint compared to the product average and the rolling average.
Requirement Burnup -- this graph shows the cumulative number of story points outstanding for each release/sprint in the product with separate lines for the actual and ideal burnup overlaid on top of a bar-graph that shows the completed story points per release/sprint.
Requirement Burndown -- this graph shows the remaining number of story points that needs to be done for each release/sprint in the product with separate lines for the actual and ideal burndown overlaid on top of a bar-graph that shows the completed story points per release/sprint.
Requirements Coverage -- this graph shows the number of requirements that have test cases that are passed, failed, blocked, cautioned, not run as well those requirements that do not have any test cases (not covered). Unlike the main Requirements Coverage graph on the home page, this one is segmented by requirement importance.
For each of the three graphs you can click on the \"Display Data Grid\" link to display a grid of the underlying data that is represented in the graph and also there are options to save the graph in a variety of different image formats.
"},{"location":"Spira-User-Manual/Product-Homepage/#requirements-regression-coverage","title":"Requirements Regression Coverage","text":"This section consists of a bar graph that displays the aggregated count of requirements test coverage for the product in a similar fashion to the 'Requirements Coverage' widget:
However, unlike the 'Requirements Coverage' widget, when you filter the product home by release/sprint, this widget will filter the requirements coverage graph to include all requirements (regardless of release/sprint), but only considering covering test cases that are associated with the selected release/sprint. This is useful when you want to determine the regression requirements test coverage of a specific release (i.e. does running all the tests relevant to this release cover all the necessary requirements, not just new requirements).
"},{"location":"Spira-User-Manual/Product-Homepage/#requirements-summary","title":"Requirements Summary","text":"This section consists of a summary table that displays the aggregate count of requirements in the system broken-down by importance (on the x-axis) and status (on the y-axis). This allows the product manager to determine how many critical vs. low priority enhancements are waiting to be implemented, vs. actually being implemented. In addition, it makes a distinction between those requirements simply requested and those actually planned for implementation, so the product manager can see what the backlog is between the customer's demands, and the plan in place. Clicking on the \"View Details\" button at the top of the table takes you to the Requirement list page. Clicking on the individual values in the cells will display the requirements list with the filter set to match the importance and status of the value.
"},{"location":"Spira-User-Manual/Product-Homepage/#release-task-progress","title":"Release Task Progress","text":"This widget allows you to quickly ascertain the task progress of each of the active releases that make up the current product in one snapshot. Each release is displayed together with a graphical display that illustrates the completion percentage and status with different colored bars. In addition, if you hover the mouse over the graphical display it will display a tooltip that provides a more detailed description of the number of tasks in each status.
Each release will display the aggregate progress of any tasks directly assigned to itself, together with the task progress of any child sprints that are contained within the Release. Clicking on one of the releases will drill you down one level further and display the task progress for the parent release as well as each of the child sprints separately:
"},{"location":"Spira-User-Manual/Product-Homepage/#release-test-summary","title":"Release Test Summary","text":"This widget allows you to quickly ascertain the test execution status of each of the active releases that make up the current product in one snapshot. Each release is displayed together with a graphical display that illustrates the execution status with different colored bars. In addition, if you hover the mouse over the graphical display it will display a tooltip that provides a more detailed description of the number of tests in each status.
Each release will display the aggregate status of any test cases directly assigned to itself, together with the test status of any child sprints that are contained within the Release. Clicking on one of the releases will drill you down one level further and display the test execution status for the parent release as well as each of the child sprints separately:
"},{"location":"Spira-User-Manual/Product-Homepage/#releasessprints-completion","title":"Releases/Sprints Completion","text":"This chart shows the progress of each active release with requirements attached in this product. The left-hand chart shows progress from the start to end date of the release. The bar's color indicates how on track the schedule is against requirement completion. The right-hand chart shows the proportion of requirements in the release that have been completed.
Displaying for a Release
Normally this widget does not show sprints. However if you have set the dashboard to display information for a particular release, this widget will show any children of that release - including any sprints. The specific release you are displaying for is not shown in the widget.
Schedule Progress color definitions:
Example
A release started a week ago and will finish in a week. Therefore its schedule is 50% of the way through (1 week down, 1 week to go).
The Schedule Progress bar will show as 50% (if you click \"Displaying\" button to \"As Numbers\" it will show 7 days).
This release has a total of 20 requirements (summed up from all its active child releases and sprints, if any). Let's say that 15 of these are completed. That's 75% complete. So the Requirements Complete bar will show 75% (if you click \"Displaying\" button to \"As Numbers\" it will show 15 completed).
So the schedule is half way through but we are three quarters done with the work (the requirements). So we are ahead of schedule (awesome!). The schedule bar will therefore have the \"Ahead of Schedule\" color.
What if, instead of finishing next week, we were supposed to finish last week? Well, the schedule bar would be flagged as \"Behind Schedule\". This is because we are only 75% complete on the work, but the end date is in the past.
Tip: You can hover over a bar to get more information.
"},{"location":"Spira-User-Manual/Product-Homepage/#releasessprints-relatize-size","title":"Releases/Sprints Relatize Size","text":"This chart shows the number of active requirements in each active release. Hovering over a segment will show its percentage of all requirements (this is visually represented by the size of the donut wedge). Please note, releases with no active requirements are not shown.
Displaying for a Release
Normally this widget does not show sprints. However if you have set the dashboard to display information for a particular release, this widget will show any children of that release - including any sprints. The specific release you are displaying for is not shown in the widget. The widget will also show sprints if you ONLY have ative sprints in this product (i.e. if there are no active major or minor releases at all).
"},{"location":"Spira-User-Manual/Product-Homepage/#recent-builds","title":"Recent Builds","text":"This widget displays a list of the most recent builds that have been performed as part of the current release or sprint:
For each build it will display whether the build succeeded or failed, the date the build occurred and the name of the build together with a hyperlink to the build details. Note: If no release or sprint is selected then the widget will not display any data.
"},{"location":"Spira-User-Manual/Product-Homepage/#tag-cloud","title":"Tag Cloud","text":"This widget lets you see the list of document tags being used in the product:
The size of the tag name indicates the relative frequency of its usage in the product. Clicking on a document tag will open up the Document List page with the filter set to the tag you clicked on. This will display a list of related documents that have been tagged with the same tag name.
"},{"location":"Spira-User-Manual/Product-Homepage/#test-case-cumulative-progress","title":"Test Case Cumulative Progress","text":"This section consists of a chart that displays the last 30 days of test case executions cumulatively. That means it will display for each day, the total number of test cases executed plus the status from any previous days that have not been changed. Any test cases not executed up to that point will be considered \"not run\" and will appear in the \"not run\" category. For example, if you have 10 test cases created on day 1 you will see 10 test cases \"not run\" on day 1. On day 2, you execute 5 test cases and fail them all, you will now see 5 test cases failed and 5 not run. On day 3, you execute 3 of the previous 5 test cases and pass them. You will now see 3 test cases passed, 2 failed and 5 not run.
"},{"location":"Spira-User-Manual/Product-Homepage/#test-execution-status","title":"Test Execution Status","text":"This section consists of a bar graph that displays the aggregated count of test cases in each execution status for the product. Note that this graph does not consider past test-runs when calculating the totals in each status (Passed, Failed, Not Run, etc.), it simply looks at each test-case and uses the last-run status as the best health indicator. Thus if a test case that previously passed, has subsequently failed upon re-execution, it will be considered a failure only.
If you position the mouse pointer over any of the five bars, the color of the bar changes slightly and the underlying raw data is displayed as a tooltip, together with the percentage equivalent. Clicking on any of the bars will bring up the product test case list with the appropriate filter applied.
In addition to the bar-chart, there is also a display of the total number of test runs recorded for the product, and a list of the five most recent days of recorded test-runs, together with the daily count.
"},{"location":"Spira-User-Manual/Product-Homepage/#test-set-status","title":"Test Set Status","text":"This section consists of a bar graph that displays the aggregated count of test cases in each execution status for each test set in the product:
Therefore if you have the same test cases stored in multiple test sets, then this widget will display the total test case count for all combinations of test set. This is useful if you have the same test cases being executed in different environments -- represented by different test sets -- and you need to make sure that the tests passed successfully in all environments.
If you position the mouse pointer over any of the five bars, the color of the bar changes slightly and the underlying raw data is displayed as a tooltip, together with the percentage equivalent. Clicking on any of the bars brings up the product test set list page with the appropriate filter applied. In addition to the bar-chart, there is also a display of (up to) the five most overdue test sets in the product.
"},{"location":"Spira-User-Manual/Product-Homepage/#all-pending-test-runs","title":"All Pending Test Runs","text":"This section lists all the test runs that are currently being executed by testers in the product. Until a test case or test set is fully executed, a pending test run entry is stored in the system so that you can continue execution at a later date.
Any pending test run can be either deleted or reassigned to another member of the product. NOTE: only product administrators can delete or reassign test runs from this widget.
"},{"location":"Spira-User-Manual/Product-Homepage/#test-run-progress","title":"Test Run Progress","text":"This section consists of a chart that displays the last 30 days of test run activity, broken down, for each day, by the test run status. This is a useful chart to quickly track the testing activity of the product -- this is not the same as overall product status.
"},{"location":"Spira-User-Manual/Product-Homepage/#incident-aging","title":"Incident Aging","text":"This section displays the number of days incidents have been left open in the system. The chart is organized as a histogram, with the count of incidents on the y-axis and different age intervals on the x-axis.
"},{"location":"Spira-User-Manual/Product-Homepage/#incident-open-count","title":"Incident Open Count","text":"This section show a bar chart to visualize the breakdown of all open incidents in the product by priority. The chart's bar match the color assigned to that priority. Clicking on the \"View Details\" link at the top of the widget opens the Incident list page.
"},{"location":"Spira-User-Manual/Product-Homepage/#incident-summary","title":"Incident Summary","text":"This section consists of a summary table that displays the aggregate count of incidents in the system broken-down by priority (on the x-axis) and status (on the y-axis). This allow the product manager to determine how many critical vs. low priority incidents are waiting to be addressed, and how many new items need to be categorized and assigned. Clicking on the \"View Details\" link at the top of the table opens the Incident list page. Clicking on the individual values in the cells will display the incident list with the filter set to match the priority and status of the value.
By default this summary table displays the total count of all incidents -- regardless of type, however my changing the drop-down list to a specific incident type (e.g. bug, enhancement, issue, etc.), the product manager can filter the summary table to just items of that type. You can also configure in the settings whether to use Priority or Severity for the x-axis
"},{"location":"Spira-User-Manual/Product-Homepage/#incident-test-coverage","title":"Incident Test Coverage","text":"This section displays a bar-graph that illustrates the execution status of any test cases that previously failed and resulted in the generation of an incident that has subsequently been resolved. This is very useful when a test case was executed in Release 1.0 and an incident was logged. That incident has now been resolved in Release 1.1 (and is in a closed status) but we need to know that the test case that caused the failure has been successfully re-run. Any test cases listed as Blocked, Caution, Not-Run, Not Applicable, or Failed in this graph need to be executed to verify that all resolved bugs in the release have truly been fixed.
"},{"location":"Spira-User-Manual/Product-Homepage/#top-open-issues","title":"Top Open Issues","text":"Issues are a subset of Incidents. Admins can control which types of incident should be considered issues. All incidents that have a type marked in this way are considered \"issues.\"
This widget shows a breakdown of the top issues logged in the product, in order of decreasing priority. Issues that do not have a priority are listed at the top, since critical issues could be lurking in that list. Only open issues are shown. Clicking on the issue's hyperlink opens incident details page for that issue.
You can configure in the settings whether to use Priority or Severity for the display, and also how many rows of data to display.
"},{"location":"Spira-User-Manual/Product-Homepage/#risk-summary","title":"Risk Summary","text":"This section displays a two dimensional matrix of the open risks logged against the product of impact against probability. Combined these two dimensions are reflected in the risks exposure and each differently colored rectangle in the matrix represents one possible exposure. The number of risks that have a particular exposure are shown inside each rectangle as appropriate. Clicking on that number will take you to the risk list page filtered by the relevant exposure.
"},{"location":"Spira-User-Manual/Product-Homepage/#top-open-risks","title":"Top Open Risks","text":"This widget displays a breakdown of the top open risks in the product, in order of decreasing risk exposure. For each row you see:
You can edit the widget to: show/hide the risk owner column; show/hide the risk type column; and the number of rows to display (max of 50).
"},{"location":"Spira-User-Manual/Product-Homepage/#late-finishing-tasks","title":"Late Finishing Tasks","text":"This section displays the list of any product tasks that have not yet been completed, but whose scheduled end date has already elapsed. A graphical progress bar is included with each task in the grid, so that you can easily see which tasks are nearest completion.
"},{"location":"Spira-User-Manual/Product-Homepage/#late-starting-tasks","title":"Late Starting Tasks","text":"This section displays the list of any product tasks that have not yet started, but whose scheduled start date has already elapsed:
Each task is listed along with its owner, priority and due-date so that you quickly ascertain how many days late it will be starting, how important it is to the product, and who needs to be contacted to get more information.
"},{"location":"Spira-User-Manual/Product-Homepage/#task-graphs","title":"Task Graphs","text":"This widget lets you quickly view the three main graphs used when measuring the progress of tasks in an agile methodology:
This section consists of a chart that displays the last 3 months of code commits to the product (if you are using the source code functionality of the application). Commits are aggregated by week. The chart is color coded by bottom quartile, the middle 50%, and the top quartile of activity.
Above the chart is a branch selector. This shows you the current branch and lets you choose which branch in the source code repository to view. This is stored for your user across the whole product, which means that you will see information for this same branch in other relevant places - eg when viewing files, or when viewing commits.
Below the chart is a list of the five most recent commits, along with the date they were made (hovering over the commit name will show a tooltip with the commit message and exact time of the commit). Click the \"View All\" button to open the commit list page.
any release / sprint / phase with a status that is not \"Closed\", \"Deferred\", or \"Cancelled\".\u00a0\u21a9
These features are only available in SpiraPlan
Capabilities and Program Milestones give you powerful ways to manage delivery of features and releases across multiple products at once - in other words at a program level. Capabilities let you define cross-product, program-level features (requirements). You can customize capabilities with system-wide types, statuses, priorities, and fully customizable fields. You can link capabilities to product requirements to track their progress at a higher level, and tag them with a program milestone to manage their delivery timetable.
Use cases for capabilities
You can think of capabilities as program-level requirements. With deep customizations, you can use them in a variety of different ways. Here are a few to help guide you using them.
A capability's Progress is a special field that shows a mini chart. This chart represents the percentage completion of all relevant requirements associated directly to the capability.
The percentaged complete is calculated by dividing the number of \"completed requirements\" (described below) by the total number of requirements associated to the capability. A \"completed requirement\" is a requirement with a status of either \"Tested\", \"Completed\", or \"Released\". Hover over the mini chart to see more specific information.
Examples
To access capabilities, navigate to a program and then open the artifact dropdown. Select \"Capabilities\". This will open the capability list page. The capability list is a hierarchical collection of the capabilities. You can move the capabilities to a specific position in the hierarchy (above or below another specific capability), and you can indent capabilities to create parent and child capabilities. You can only have one level of indentation (in other words, you cannot have children that themselves also have children). At first, the list will be empty.
"},{"location":"Spira-User-Manual/Program-Capabilities/#list-page-toolbar-operations","title":"List page toolbar operations","text":"You can carry out a number of useful operations with the toolbar:
Insert this button has several features to add new capabilities (see below). When added the new capability is in \"Edit\" mode so you can set its name and other information.
Insert or New Capability from the button's dropdownChild Capability button from the dropdown Insert with nothing selected. Note that if the list goes over more than one page, the new capability will be at the bottom of the last pageDelete: deletes all currently selected capabilities. If any of them is a parent, their child capabilities are also deleted. If all the children are deleted from a parent, it changes back into a non-parent
Edit: this will switch any selected capabilities into Edit mode. You can achieve the same thing by clicking the \"Edit\" button at the top of the list itself. You can switch on edit mode for capabilities one at a time by clicking the \"Edit\" button for each specific row or by double clicking one of the cells in a row. When in edit mode, the row will show a \"Save\" button to commit the changes, and \"Cancel\" to discard them. The edit menu also has a dropdown of other options
Show / Hide Columns: By default the following columns are shown: ID, name, progress, type, status, and owner. The columns dropdown lets you change the columns shown (for standard and custom properties). Toggle a column's visibility by clicking on it from the dropdown. The shown columns is saved for each user and for each program.
Using the cut and paste buttons described above, you can move capabilities around the hierarchy. Alternatively, you can select the capabilities and drag and drop them into their new position.
"},{"location":"Spira-User-Manual/Program-Capabilities/#capability-details","title":"Capability Details","text":"When you click on a capability it will open its capability details page:
This page is made up of three areas;
Please note that on smaller screen sizes the navigation pane is not displayed. While the navigation pane has a link to take you back to the list page, on mobile devices a 'back' button is shown on the left of the operations toolbar.
The navigation pane can be collapsed by clicking on the \"-\" button, or expanded by clicking anywhere on the gray title area. On desktops the user can also control the exact width of the navigation pane by dragging and dropping a red handle that appears on hovering at the rightmost edge of the navigation pane.
The navigation pane shows a list of capabilities. This list is useful as a navigation shortcut - you can quickly view the peer capabilities by clicking on the navigation links, without having to first return to the list page. The navigation list can be switched between two different modes:
Save: to save the current item
Refresh: refreshes the name, info bar information, and overview tab for the item
New: adds a new item immediately below the current capability (and if the current capability is a child the new item is added as a child to the same parent)
Delete: deletes the current capability. If it is a parent, its child capabilities are also deleted
The info bar shows the following information for the capability: name, icon (different for parent and children), ID, type, status, and progress mini chart
"},{"location":"Spira-User-Manual/Program-Capabilities/#overview","title":"Overview","text":"The Overview tab is divided into a number of different sections. Each of these can be collapsed or expanded by clicking on the title of that section. Each section displays fields of a similar type. For instance, all fields regarding dates are grouped together in the \"Dates and Times\" area.
The bottom most section contains the long, formatted description, followed by any rich text custom fields. You can enter rich text or paste in from a word processing program or web page into these fields. Note that you are not able to paste screenshots into these description boxes
"},{"location":"Spira-User-Manual/Program-Capabilities/#requirement-associations","title":"Requirement Associations","text":"You can associate requirements from any product inside the current program to a capability from this tab. Any requirements linked to the capability feed into the progress calculation of the capability. The associated requirements show the following information: name, status, product name, owner, and ID.
Read more about how to manage and add associations to this artifact
"},{"location":"Spira-User-Manual/Program-Homepage/","title":"Program Homepage","text":""},{"location":"Spira-User-Manual/Program-Homepage/#overview","title":"Overview","text":"When you navigate to a Program from the global navigation bar or from any link to it in the application, you will be taken to the homepage of that program:
This page summarizes all of the information about the program in a \"one-stop-shop\". The Program Homepage has 3 versions you can quickly switch between. While each of these can be customized as you want, by default they are designed to help different types of user: managers, testers, and developers.
You will see a small \"i\" in a circle at the top right of each widget. Hovering or clicking on this will show you information about that chart.
In a similar manner to other home pages in the application (like the 'My Page'), the Program Home is loaded in 'view mode'. To switch the page to 'edit mode', click the button with the cog icon () on the right.
In 'edit mode', each widget can be:
Together, these editing options let you change the page to suit your needs. If you close a widget and then later want to open it again (or the widget is not visible on the page) click the \"+ Add\" button at the top of the page (next to the 'edit mode' button). This brings up a list of all the widgets you can add onto the page (including a list of 'Closed Widgets'). You can choose where on the page each widget should go.
Please note
Any changes you make to this page (e.g. editing, moving, closing widgets) will only affect your user and on this particular home page. They do not affect any other user.
By default, the program home page shows the \"General\" view. The following table shows which widgets are displayed on the different views of the 'Product Home':
Widget Name General Development Testing Program Overview Y Y Y Product List Y Y Y Products: Completion Y Products: Relative Size Y Schedule Y Requirement Completion Y Y Requirements Coverage Y Y Recent Builds Y Y Test Execution Status Y Y Incident Aging Y Y Top Open Issues Y Y Top Open Risks Y Task Progress Y"},{"location":"Spira-User-Manual/Program-Homepage/#program-overview","title":"Program Overview","text":"This section displays the name of the program, together with a brief description, the web-site that points to any additional information about the program, and the names of the owners of the program. In SpiraPlan, if the program is part of a portfolio, the portfolio name is also shown.
"},{"location":"Spira-User-Manual/Program-Homepage/#product-list","title":"Product List","text":"This section lists all the active products that make up the program, together with the name, description, program and date of creation. To view the description of the product, simply position the mouse pointer over the link, and a tooltip window will popup containing the description.
"},{"location":"Spira-User-Manual/Program-Homepage/#products-completion","title":"Products: Completion","text":"This chart shows the progress of each active release with requirements attached in this product. The left-hand chart shows progress from the start to end date of the release. The bar's color indicates how on track the schedule is against requirement completion. The right-hand chart shows the proportion of requirements in the release that have been completed.
Schedule Progress color definitions:
Example
A product started a week ago and will finish in a week. Therefore its schedule is 50% of the way through (1 week down, 1 week to go).
The Schedule Progress bar will show as 50% (if you click \"Displaying\" button to \"As Numbers\" it will show 7 days).
This product has a total of 20 requirements (summed up from all of its active releases). Let's say that 15 of these are completed. That's 75% complete. So the Requirements Complete bar will show 75% (if you click \"Displaying\" button to \"As Numbers\" it will show 15 completed).
So the schedule is half way through but we are three quarters done with the work (the requirements). So we are ahead of schedule (awesome!). The schedule bar will therefore have the \"Ahead of Schedule\" color.
What if, instead of finishing next week, we were supposed to finish last week? Well, the schedule bar would be flagged as \"Behind Schedule\". This is because we are only 75% complete on the work, but the end date is in the past.
Tip: You can hover over a bar to get more information.
"},{"location":"Spira-User-Manual/Program-Homepage/#products-relative-size","title":"Products: Relative Size","text":"This chart shows the number of active requirements in each active product. Hovering over a segment will show its percentage of all requirements (this is visually represented by the size of the donut wedge). Please note, products with no active requirements are not shown.
"},{"location":"Spira-User-Manual/Program-Homepage/#schedule","title":"Schedule","text":"This Gantt chart shows all active releases and sprints in this program. Each bar spans from the item's start date to end date. The darker shaded portion of each bar tells you how complete its requirements are.
"},{"location":"Spira-User-Manual/Program-Homepage/#requirement-completion","title":"Requirement Completion","text":"This chart shows the proportion of all active requirements that have been completed across all active products in this program. When 100% of the requirements are completed, the color changes so that it is easy to tell what is in progress vs completed.
"},{"location":"Spira-User-Manual/Program-Homepage/#requirements-coverage","title":"Requirements Coverage","text":"This section consists of a bar graph that displays the aggregated count of requirements test coverage for the entire program. The Passed, Failed, Blocked, Caution and Not-Run bars indicate the total count of requirements that have tests covering them, allocated across the execution status of the covering tests
Under the main bar graph is displayed a table containing each product in the program and a colored bar illustrating the specific requirements coverage distribution for that product. That way you can see both the aggregate coverage and also the relative coverage for the products. You can choose to show the aggregate bar graph, and/or the product-specific requirements coverage from the widget settings.
By default, this widget shows data for active releases only in each product in the program. You can choose to show data for all releases in all products of the program from the widget settings.
"},{"location":"Spira-User-Manual/Program-Homepage/#task-progress","title":"Task Progress","text":"This section consists of a bar graph that displays the aggregated count of tasks by progress category for the entire program. The 'On Schedule', 'Late Finish', 'Late Start' and 'Not Started' bars indicate the total count of tasks that are in that category for all the products in the program.
Under the main bar graph is displayed a table containing each product in the program and a colored bar illustrating the specific task progress for that product (using the same coloring convention as the main graph). That way you can see both the aggregate task progress and also the relative progress for each product. You can choose to show the aggregate bar graph, and/or the product-specific task progress from the widget settings.
By default, this widget shows data for active releases only in each product in the program. You can choose to show data for all releases in all products of the program from the widget settings.
"},{"location":"Spira-User-Manual/Program-Homepage/#test-execution-status","title":"Test Execution Status","text":"This section consists of a bar graph that displays the aggregated count of test cases by execution status for the entire program. The Passed, Failed, Blocked, Caution and Not-Run bars indicate the total count of test cases that are in that category for all the products in the program.
Under the main bar graph is displayed a table showing each product in the program with the following information:
By default, this widget shows data for active releases only in each product in the program.
In the widget settings you can choose to:
This section displays the number of days incidents have been left open in the system. The chart is organized as a histogram, with the count of incidents on the y-axis (for all products in the program) and different age intervals on the x-axis.
Under the main bar graph is displayed a table containing each product in the program and a colored bar illustrating the distribution of open incidents by priority for that product. That way you can see both the aggregate aging for the program and also the relative priority of open incidents for each product. You can configure in the widget settings whether you want to see the aggregate aging histogram, and/or the product-specific incident count by priority.
"},{"location":"Spira-User-Manual/Program-Homepage/#top-open-issues","title":"Top Open Issues","text":"This section displays a breakdown of the top issues logged against any of the products in the program, in order of decreasing priority. Note that items not given a priority are listed at the top, since critical issues could be lurking in that list, and the product manager will want to immediately review these to assign priorities. Clicking on the issue item hyperlink will take you to the incident details page for the issue in question (see Incident Tracking > Incident Details). You can configure in the settings whether to use Priority or Severity for the display, and also how many rows of data to display.
"},{"location":"Spira-User-Manual/Program-Homepage/#top-open-risks","title":"Top Open Risks","text":"This widget lists the top risks logged against any of the products in the portfolio, ordered by exposure. Clicking on the risk name will open the risk details page for the risk in question. Note: you can configure the widget settings to control the maximum number of risks to show.
"},{"location":"Spira-User-Manual/Program-Homepage/#recent-builds","title":"Recent Builds","text":"This widget displays a list of the most recent builds for each active release (organized alphabetically by product; in each product the builds are listed by date). For each build it shows:
You can change the number of builds the widget should show in the widget's settings (the default is 15).
"},{"location":"Spira-User-Manual/Program-Homepage/#product-test-summary","title":"Product Test Summary","text":"This table shows an information-dense, but easy to understand assessment of each product by a number of key metrics. It shows each product in the program, together with:
The program incident list is only available in SpiraPlan. If you are using SpiraPlan, to access the program incident list, you must be a member of the program (i.e. a program owner or executive).
The program incident list lets you see all of the incidents (bugs, enhancements, issues, risks, etc.) in the current program, displayed in an integrated table view showing incidents':
You can access this feature by clicking on the Incidents menu entry in the program navigation. You can filter and sort by specific product, or by the various fields displayed in the table.
"},{"location":"Spira-User-Manual/Program-Management/","title":"Program Management","text":""},{"location":"Spira-User-Manual/Program-Management/#redirects","title":"Redirects","text":"These features are only available in SpiraPlan
Program Milestones and Capabilities give you powerful ways to manage delivery of features and releases across multiple products at once - in other words at a program level. Program milestones let you define cross-product, program-level date goals / milestones (like releases or sprints). You can customize program milestones with system-wide types, statuses, and fully customizable fields. You can link program milestones to product releases to track their scheduling at a higher level. Program milestones also let you track capabilities' delivery.
Use cases for program milestones
You can think of program milestones as program-level releases. With deep customizations, you can use them in a variety of different ways. Here are a few to help guide you using them.
A program milestone's Progress is a special field that shows a mini chart. This chart represents the percentage completion of all relevant capabilities associated directly to the program milestone.
The percentaged complete is calculated by dividing the number of \"closed capabilities\" (based on their current status) by the total number of capabilities associated to the program milestone. Hover over the mini chart to see more specific information.
The mini chart shows different colors to help you quickly see if progress is on or off track:
Progress %age Start date End date Mini chart color 0 In the future Anything Gray 0 In the past Anything Yellow Above 0, Below 100 Anything In the future Green (remaining is gray) Above 0, Below 100 Anything In the past Red (remaining is gray) 100 Anything Anything GreenExamples
Program milestones have start and end dates. This lets you manually set the range when work for the program milestone starts and ends. In addition, each program milestone has a \"Child Start Date\" and a \"Child End Date\". These dates are set automatically based on all of the releases associated to the program milestone:
Examples
In this example, we have the following releases across a number of products
Release Start Date End Date Sprint 1 May 3rd May 20th Sprint 2 May 15th June 2nd Sprint 3 May 22nd June 5th Sprint 4 May 1st June 10thWhen we associate these to different program milestones the child start and end dates get automatically set as follows:
Program milestone Associated releases Child start date Child end date First Sprint 1, Sprint 2 May 3rd June 2nd Second Sprint 1, Sprint 4 May 1st June 10th Third Sprint 2, Sprint 3 May 15th June 5th"},{"location":"Spira-User-Manual/Program-Milestones/#milestone-list","title":"Milestone List","text":"To access program milestones, navigate to a program and then open the artifact dropdown. Select \"Program Milestones\". This will open the program milestone list page. The list is a flat, sortable collection of the program milestones.
"},{"location":"Spira-User-Manual/Program-Milestones/#list-page-toolbar-operations","title":"List page toolbar operations","text":"You can carry out a number of useful operations with the toolbar:
When you click on a program milestone it will open its program milestone details page:
This page is made up of three areas;
Please note that on smaller screen sizes the navigation pane is not displayed. While the navigation pane has a link to take you back to the list page, on mobile devices a 'back' button is shown on the left of the operations toolbar.
The navigation pane can be collapsed by clicking on the \"-\" button, or expanded by clicking anywhere on the gray title area. On desktops the user can also control the exact width of the navigation pane by dragging and dropping a red handle that appears on hovering at the rightmost edge of the navigation pane.
The navigation pane shows a list of program milestones. This list is useful as a navigation shortcut - you can quickly view the peer program milestones by clicking on the navigation links, without having to first return to the list page. The navigation list can be switched between two different modes:
Save: to save the current item
Refresh: refreshes the name, info bar information, and overview tab for the item
New: opens the new program milestone details page, where you can enter its information and hit save to actually create the item
Delete: deletes the current program milestone
The info bar shows the following information for the program milestone: name, icon, ID, type, status, and progress mini chart
"},{"location":"Spira-User-Manual/Program-Milestones/#overview","title":"Overview","text":"The Overview tab is divided into a number of different sections. Each of these can be collapsed or expanded by clicking on the title of that section. Each section displays fields of a similar type. For instance, all fields regarding dates are grouped together in the \"Dates and Times\" area.
The bottom most section contains the long, formatted description, followed by any rich text custom fields. You can enter rich text or paste in from a word processing program or web page into these fields. Note that you are not able to paste screenshots into these description boxes
"},{"location":"Spira-User-Manual/Program-Milestones/#release-associations","title":"Release Associations","text":"You can associate releases from any product inside the current program to a program milestone from this tab. Any releases linked to the program milestone feed into the child start and end dates of the program milestone. The associated releases show the following information: name, type, status, start date, end date, product name, owner, and ID.
Read more about how to manage and add associations to this artifact
"},{"location":"Spira-User-Manual/Program-Milestones/#capability-associations","title":"Capability Associations","text":"When you create or edit capabilities, you can optionally set their program milestone. On this tab you can see all capabilities currently linked to the program milestone. Any capability linked to the program milestone feed into the progress of the program milestone. The associated capabilities show the following information: name, type, status, owner, and ID.
You can refresh the list of capabilities, or filter the list.
"},{"location":"Spira-User-Manual/Program-Planning-Board/","title":"Planning Board","text":""},{"location":"Spira-User-Manual/Program-Planning-Board/#program-planning-board","title":"Program Planning Board","text":"The program planning board is only available in SpiraPlan. If you are using SpiraPlan, to access the program planning board, you must be a member of the program (i.e. a program owner or executive).
The program planning board is designed to let you view the backlog items that need to be planned for all of the products in a specific program as well as view all of the planned items in each of the individual products. It is designed to let you see a product-group wide view of all requirements and associated test cases and tasks. You can access this feature by clicking on the Planning menu entry in the program navigation.
The program planning board has the following views:
Each of these views is described below.
"},{"location":"Spira-User-Manual/Program-Planning-Board/#program-backlog-by-priority","title":"Program Backlog -- by Priority","text":"This view is designed to let you see the program backlog organized by requirement importance. Each of the possible importance values is displayed on the left-hand side and the backlog items displayed in the same row on the right. The backlog items in this view will only be requirements (with associated tasks and test cases).
The top section will contain the list of items that are not assigned a priority, with the other sections containing the items that have been assigned to the specific priority.
"},{"location":"Spira-User-Manual/Program-Planning-Board/#program-backlog-by-status","title":"Program Backlog -- by Status","text":"This view is designed to let you see the program backlog organized by requirement status. Each of the possible status values (for an unscheduled item) is displayed as a heading, with the backlog items displayed in the same column underneath. The backlog items in this view will only be requirements (with associated tasks and test cases). This view is commonly called a Kanban board:
Each of the vertical sections is one of the requirements' statuses, in order of the requirement lifecycle (Requested > Accepted). Once a requirement is assigned to a release or sprint it will come automatically 'Planned' and not appear in this view. You can drag and drop the requirements between the different statuses.
"},{"location":"Spira-User-Manual/Program-Planning-Board/#all-products-by-priority","title":"All Products -- by Priority","text":"This program planning view is designed to let you see all of the backlog items that have been scheduled for all of the products in the current program, organized by requirement importance/priority.
Each of the possible importance values is displayed on the left-hand side and the backlog items displayed in the same row on the right. The backlog items in this view will only be requirements (with associated tasks and test cases).
The top section will contain the list of items that are not assigned a priority, with the other sections containing the items that have been assigned to the specific priority.
"},{"location":"Spira-User-Manual/Program-Planning-Board/#all-products-by-product","title":"All Products -- by Product","text":"The program planning view is designed to let you view the open (not-completed) backlog items currently planned per product. The backlog items are themselves only requirements, however you can see the tasks and test cases associated with a specific requirement.
Clicking on the product hyperlink will switch the planning board into the Product Backlog view described below.
"},{"location":"Spira-User-Manual/Program-Planning-Board/#all-products-by-status","title":"All Products -- by Status","text":"This view is designed to let you see the scheduled backlog items for the entire program organized by requirement status. Each of the possible status values (for a planned item) is displayed as a heading, with the backlog items displayed in the same column underneath. The backlog items in this view will only be requirements (with associated tasks and test cases). This view is commonly called a Kanban board:
Each of the vertical sections is one of the requirements' statuses, in order of the requirement lifecycle (Planned > Completed). You can click on the expand/collapse icons to hide any statuses that are not used. You can drag and drop the requirements between the different statuses. If you have the planning options enabled to have requirements status' automatically update based on changes to the associated tasks and test cases, then items will automatically move between the statuses based on tasks being completed and test cases being executed.
"},{"location":"Spira-User-Manual/Program-Planning-Board/#all-products-by-person","title":"All Products -- by Person","text":"This view is designed to let you see the program backlog organized by resource / person. Each of the users that is a member of any of the products in the current program is displayed as a heading, with the backlog items displayed in the same column underneath.
You can click on the expand/collapse icons to hide any resources that are not relevant. Above the resource headings there is a section called 'Unassigned Items'; that contains backlog items that are scheduled but have not yet been assigned to a person.
"},{"location":"Spira-User-Manual/Program-Planning-Board/#product-by-priority","title":"Product -- by Priority","text":"This program planning view is designed to let you see all of the backlog items that have been scheduled for all of the products in the current program, organized by requirement importance/priority.
Each of the possible importance values is displayed on the left-hand side and the backlog items displayed in the same row on the right. The backlog items in this view will only be requirements (with associated tasks and test cases).
The top section will contain the list of items that are not assigned a priority, with the other sections containing the items that have been assigned to the specific priority.
"},{"location":"Spira-User-Manual/Program-Planning-Board/#product-by-status","title":"Product -- by Status","text":"This view is designed to let you see the product backlog organized by requirement status. Each of the possible status values (for a planned item) is displayed as a heading, with the backlog items displayed in the same column underneath. The backlog items in this view will only be requirements (with associated tasks and test cases). This view is commonly called a Kanban board:
Each of the vertical sections is one of the requirements' statuses, in order of the requirement lifecycle (Planned > Completed). You can click on the expand/collapse icons to hide any statuses that are not used. You can drag and drop the requirements between the different statuses. If you have the planning options enabled to have requirements status' automatically update based on changes to the associated tasks and test cases, then items will automatically move between the statuses based on tasks being completed and test cases being executed.
"},{"location":"Spira-User-Manual/Program-Planning-Board/#product-by-person","title":"Product -- by Person","text":"This view is designed to let you see the product backlog organized by resource / person. Each of the users that is a member of the current product is displayed as a heading, with the backlog items displayed in the same column underneath.
You can click on the expand/collapse icons to hide any resources that are not relevant. Above the resource headings there is a section with the product name; that contains backlog items that are scheduled for the current product but have not yet been assigned to a person.
"},{"location":"Spira-User-Manual/Program-Products/","title":"Program Products","text":"This page outlines how to access and use the program product pages. These pages are only available in SpiraPlan.
From the program product pages you can view information about each product in the program.
"},{"location":"Spira-User-Manual/Program-Products/#product-list","title":"Product List","text":"To access the program product list page, you must be a member of the program (i.e. a program owner or executive). From the program, open the \"artifact\" dropdown as shown below and click \"Products\"
.
The program product list shows all of the products in the current program, displayed in an integrated table view showing products':
The toolbar above the grid lets you:
You can sort the list by most columns (any with the ascending and descending arrows).
You can filter by entering (or selecting) a value in each required column to filter on. Read about how to create and manage filters (note that this page does not let you save and share named filters).
Clicking on a product name / link will open the program product details page.
"},{"location":"Spira-User-Manual/Program-Products/#product-details","title":"Product Details","text":"This page is made up of three areas:
The navigation pane has a link to take you back to the product list, as well as a list of products in the program. This list is useful as a navigation shortcut - click on any product to quickly view its details. The navigation list can be switched between two different modes:
The top part of the right pane has buttons to refresh the product information or save any changes made. The product logo beneath this (to the left of the product ID) can be clicked to open the product home page for that product.
If you have the required permissions for that product (see below) you can edit some of its fields. Many of the fields are always read only and can only be edited by system administrators from the System Admin Product Edit page. The fields that are editable on this page are:
Once you are satisfied with any changes you have made, click the \"Save\" button. To quickly discard any changes, click \"Refresh\".
"},{"location":"Spira-User-Manual/Program-Products/#editing-the-product-details","title":"Editing the product details","text":"To edit the product information for a particular product from the product details page you must meet at least one of the following conditions:
The program release plan is only available in SpiraPlan. If you are using SpiraPlan, to access the program release plan, you must be a member of the program (i.e. a program owner or executive).
The program release plan lets you see all of the products in the current program, together with their releases, sprints, and phases displayed in an integrated hierarchical view:
You can access this feature by clicking on the Releases menu entry in the program navigation.
This view lets you see all the releases, sprints, and phases with the following information (each column can be shown or hidden as needed):
You can expand and collapse the products and releases to display the appropriate level of detail as well as filter by the various fields in the grid.
"},{"location":"Spira-User-Manual/Program-Releases/#release-traceability-and-coverage","title":"Release Traceability and Coverage","text":"From the release list page you can see a number of columns that show calculated data for each release, based off:
This allows you to see at a glance the state of play about a number of key metrics for the release.
"},{"location":"Spira-User-Manual/Program-Releases/#requirements-completion","title":"Requirements Completion","text":"This column shows a mini chart that shows the percentage completion of all relevant requirements assigned to the release (or that are rolling up from the releases children).
The percentaged complete is worked out by dividing the number of \"completed requirements\" (described below) by the total number of requirements assigned to the release. A \"completed requirement\" is a requirement with a status of either \"Tested\", \"Completed\", or \"Released\".
"},{"location":"Spira-User-Manual/Program-Releases/#requirement-count-and-points","title":"Requirement Count and Points","text":"These columns (not shown by default) show you the sum of all requirements assigned to the release; and the sum of all the points scored to all those requirements respectively.
"},{"location":"Spira-User-Manual/Program-Releases/#test-coverage","title":"Test coverage","text":"This column shows a mini chart that shows the sum of each execution statuses against the release. It is calculated from the latest test run executed against that release for each test case that is assigned to that release. If you execute a test case against a release, and that test case is not by itself assigned to the release, the information for that test run will not be included.
If you hover the mouse over the mini chart it will display a tooltip that provides a more detailed description of the number of tests in each execution status.
Each release will display the aggregate status of any test cases directly assigned to itself, together with the test execution status of any child sprints that are contained within the release.
"},{"location":"Spira-User-Manual/Program-Releases/#task-progress","title":"Task Progress","text":"This columns shows a mini chart of the count of all active tasks1 assigned to the release, by progress category for the release. The 'On Schedule', 'Late Finish', 'Late Start' and 'Not Started' bars indicate the total count of tasks that are in that category.
If you hover the mouse over the mini chart it will display a tooltip that provides a more detailed description of the number of tasks in each category.
How are the different categories calculated?
any task with a status that is not one of the following: \"Rejected\", \"Obsolete\", \"Duplicate\".\u00a0\u21a9
Often, developers work on features or hotfixes in specific branches. Once development is complete, the code is ready to merged into the central branch (typically main, or development) ahead of release. Pull requests are a way to flag that the feature branch is ready for merging. A pull request lets the developer(s) of the feature ask colleagues to review the code, assess if changes are needed, and if everything looks good approve the pull request / merge into the main branch.
If your SpiraPlan product is connected to a source code repository, you will be able to use SpiraPlan's pull request functionality. This lets you create a pull request, select the branch you want reviewed, the branch the code will be pulled / merged into, and assign a team member to review the request. The reviewer can explore the code that was changed in the branch add comments or notes to the pull request, and move it through a workflow as needed. The requester can track any changes made to the pull request, so they can, as needed, make additional changes to their code.
SpiraPlan's pull request feature leverages the Task artifact. Tasks have different types. You can set any of these tasks types to be treated as a pull request task. Task types are managed via template administration. By default, templates have a task type called \"Pull Request\" which is flagged as being treated as a pull request. You can turn this off, or make other types also be treated as pull requests. If you have different workflows for different types of code (for instance a hotfix pull request may require a different workflow to a feature pull requests), it may make sense to have multiple task types being flagged as pull requests. You can then set each task type to use a different task workflow.
"},{"location":"Spira-User-Manual/Pull-Requests/#pull-request-list","title":"Pull Request List","text":"To view the list of pull requests in a product, the following three conditions need to be met:
Note: to carry out operations on pull requests (like create, delete, modify) you need those specific permissions for tasks.
"},{"location":"Spira-User-Manual/Pull-Requests/#view-pull-requests","title":"View Pull Requests","text":"When you click on Developing > Pull Requests on the global navigation bar, you will be taken to the pull requests list screen. This shows you all pull requests in the product. You can sort and filter this list, or browse the different pages of pull requests (up to 500 pull requests can be displayed on the page at any one time).
Above the list of pull requests is the action toolbar. This lets you perform the following functions:
The list of pull requests shows the following information about each pull request:
When you click the \"New Pull Request\" button you will see a popup dialog as below.
This dialog has the following fields to fill in:
Once the popup has been filled in click \"Create\" to add the pull request.
"},{"location":"Spira-User-Manual/Pull-Requests/#pull-requests-on-the-task-list","title":"Pull Requests on the Task List","text":"Pull requests are a special type of task. Only tasks with a pull request type are shown on the pull request list page. On the main task list page you can see all tasks, including pull requests. Pull requests have the special pull request icon next to the name. You can filter and order tasks and this will affect pull requests as if they are normal tasks. On the main task list page you cannot show special pull requests fields (like Merge From and Merge To). You can also view pull requests on the task board.
If you can create a new task from the task list you can create a pull request. However, you will not be able to set the Merge From or Merge To fields. That can only be done on the pull requests list page.
"},{"location":"Spira-User-Manual/Pull-Requests/#pull-request-details","title":"Pull Request Details","text":"Clicking on a pull request from anywhere in the application will open its details page. Here you can see and edit all information about the pull request, transition it through the workflow, add comments and more. This functionality is described in more detail on the task details page.
The pull request details page is different to the task details page in two specific ways:
From the pull request's commits tab, you can see a list of all commits that were made on the Merge From branch that are not in the Merge To branch. This lets you easily see all the changes that the pull request is asking to bring into the Merge To branch.
For each commit you can see the following information (you can sort or filter on all of these):
This section outlines how to use the Release Management features of SpiraPlan\u00ae to manage different versions of the system being tested in a particular product. This is an optional feature of the system, and you can manage the testing for a product successfully without tracking individual releases. Typically, when you develop a system, it is important to ensure that features introduced in successive versions do not impair existing functionality - this is known as regression testing.
In such situations, you will want to be able to execute the same set of test scripts against multiple versions of the system and be able to track failures by version. A feature that works correctly in version 1.0 may fail in version 1.1, and the maintenance team may be testing the existing lifecycle of v1.0 in parallel with the development team testing v1.1. Therefore, by developing a master set of releases/versions in the Release Management module, you can have the different testing teams correctly assign their testing actions to the appropriate version.
There are two types of release artifact in SpiraPlan\u00ae - product releases that are displayed with the release icon and represent major or minor versions of the system, and release Sprints that are displayed with the sprint icon. Note: Sprints can be contained within a Release, but not the other way round.
The main differences between releases and sprints are as follows:
From the release list page you can see a number of columns that show calculated data for each release, based off:
This allows you to see at a glance the state of play about a number of key metrics for the release.
"},{"location":"Spira-User-Manual/Release-Management/#requirements-completion","title":"Requirements Completion","text":"This column shows a mini chart that shows the percentage completion of all relevant requirements assigned to the release (or that are rolling up from the releases children).
The percentaged complete is worked out by dividing the number of \"completed requirements\" (described below) by the total number of requirements assigned to the release. A \"completed requirement\" is a requirement with a status of either \"Tested\", \"Completed\", or \"Released\".
"},{"location":"Spira-User-Manual/Release-Management/#requirement-count-and-points","title":"Requirement Count and Points","text":"These columns (not shown by default) show you the sum of all requirements assigned to the release; and the sum of all the points scored to all those requirements respectively.
"},{"location":"Spira-User-Manual/Release-Management/#test-coverage","title":"Test coverage","text":"This column shows a mini chart that shows the sum of each execution statuses against the release. It is calculated from the latest test run executed against that release for each test case that is assigned to that release. If you execute a test case against a release, and that test case is not by itself assigned to the release, the information for that test run will not be included.
If you hover the mouse over the mini chart it will display a tooltip that provides a more detailed description of the number of tests in each execution status.
Each release shows the overall execution status of test cases assigned to that release for that release. For each test case the execution status shown is the most recent result from when that test case was run against that particular release (if at all). Note: a major release will also show the results from test cases assigned to it directly that are also assigned to and run against its child sprints.
"},{"location":"Spira-User-Manual/Release-Management/#task-progress","title":"Task Progress","text":"This columns shows a mini chart of the count of all active tasks1 assigned to the release, by progress category for the release. The 'On Schedule', 'Late Finish', 'Late Start' and 'Not Started' bars indicate the total count of tasks that are in that category.
If you hover the mouse over the mini chart it will display a tooltip that provides a more detailed description of the number of tasks in each category.
How are the different categories calculated?
Rollup of effort from requirements associated to the release are summed together in the relevant release effort fields. Other artifacts's effort values can also be included in these calculations, controlled on the Planning Options page of product administration.
Task effort calculations are described in more detail here.
"},{"location":"Spira-User-Manual/Release-Management/#baselining","title":"Baselining","text":"NOTE: Baselining is only available in SpiraTeam and SpiraPlan.
What is baselining in SpiraPlan
Baselining allows you to take a snapshot of the entire product at a specific point in time. You can use this feature to see the state of every test case, requirement, and incident as they were the moment that baseline was created. You can see how an artifact changed between 2 baselines (or between the baseline and when the product was first created if you are looking at the earliest baseline).
In SpiraPlan, we attach baselines to a release, as well as to the state of the product changes. This is to help you more easily use baselines as part of your release planning and review: baselines are, in effect, tied to the progress of your releases and sprints. You may wish to create a baseline when your release starts, and then create another when it is released. You may create a baseline at the end of every sprint and then use your baselines to see what happened between those two sprints.
Once a product has baselines, product owners can explore each baseline to see what artifacts were added, changed, or deleted in a baseline.
Here is a step by step overview on getting started with baselines:
Below is more information below about how to create, edit, delete, and view your baselines against a specific release.
Product admins / product owners can use the dedicated admin list page to see all baselines across all releases in a product. They can also explore a baseline in detail, to see all the artifacts changed, added, or deleted in a baseline.
What is captured when baselining is turned on? Baselining leverages the change tracking tools built into SpiraPlan already. It does this by using the history stored against each artifact in the product to track what has changed between any two baselines. Some additional information is captured only when baselining is turned on (both for baselining use and general history tracking):
When you click on the Planning > Releases global navigation link, you will initially be taken to the release list screen illustrated below:
The release list will contain all the releases and sprints associated with current product. When you create a new product, this list will initially be empty, and you will have to use the \"Insert\" button to start adding releases and sprints to the product. The hierarchical organization of releases in the list is configurable, so you can organize the various releases in the way that makes most sense for a particular product. Typically you have the major releases as the top-level items, with sub-releases, builds and sprints as the lower-level items.
All of the releases in the list have a release-name, together with the assigned version number for that release, the start-date and end-date for the release, the number of estimated product personnel working on that release, the planned effort for the release, the total effort currently scheduled (as tasks), the available effort for new tasking, the release id, the type of each release, its status, and a set of custom properties defined by the product owner.
For those releases that have test cases mapped against them, the execution status of the various test cases associated with the release is displayed in aggregate for each item as a graphical bar diagram. If you position the mouse over the execution status indicator you will see the detailed execution information displayed as a tooltip.
For those releases that have at least one requirement task associated with them, they will display a block graph that illustrates the relative numbers of task that are on-schedule (green), late-starting (yellow), late-finishing (red) or just not-started (grey). These values are weighted by the effort of the task, so that larger, more complex tasks will be change the graph more than the smaller tasks. To determine the exact task progress information, position the mouse pointer over the bar-chart and the number of associated tasks, along with the details of how many are in each status will be displayed as a \"tooltip\".
Clicking on a release's hyperlink will take you to the release details page for the item in question.
"},{"location":"Spira-User-Manual/Release-Management/#filtering","title":"Filtering","text":"Read about how to create and manage filters.
"},{"location":"Spira-User-Manual/Release-Management/#insert","title":"Insert","text":"The \"Insert\" button has an attached dropdown menu that lets you:
If you insert a release or sprint (not as a child) the new item is inserted above the currently selected item -- i.e. at the same level in the hierarchy but visually above the release with the checked checkbox. If you insert an item with no release selected, the item is inserted at the bottom of the list (at the same level in the hierarchy as the item release or sprint that was previously at the bottom).
If you insert a child release or sprint, the new item is inserted below the currently selected item - i.e. nested insde the selected release as a child (a sprint cannot have child sprints or releases).
Once the new release has been inserted, the item is switched to \"Edit\" mode so you can change its name, version number or other information.
"},{"location":"Spira-User-Manual/Release-Management/#delete","title":"Delete","text":"Clicking on the \"Delete\" button deletes all the releases whose check-boxes have been selected. If any of the releases have child releases/sprint, then the child releases and sprints are also deleted.
"},{"location":"Spira-User-Manual/Release-Management/#indent","title":"Indent","text":"Clicking on the \"Indent\" button indents all the releases whose check-boxes have been selected. Note: you cannot indent a release or sprint if it is below a sprint, as sprints are not allowed to have child items.
"},{"location":"Spira-User-Manual/Release-Management/#outdent","title":"Outdent","text":"Clicking on the \"Outdent\" button de-indents all the releases whose check-boxes have been selected.
"},{"location":"Spira-User-Manual/Release-Management/#refresh","title":"Refresh","text":"Clicking on the \"Refresh\" button simply reloads the release list. This is useful as other people may be modifying the list of releases at the same time as you, and after stepping away from the computer for a short-time, you should click this button to make sure you are viewing the most current release list for the product.
"},{"location":"Spira-User-Manual/Release-Management/#edit","title":"Edit","text":"Each release/sprint in the list has an \"Edit\" button display in its right-most column. When you click this button or click on any of the cells in the row, you change the item from \"View\" mode to \"Edit\" mode. The various columns are made editable, and \"Save\" buttons are displayed in the last column:
If you click \"Edit\" on more than one row, the \"Save\" buttons are only displayed on the first row, and you can make changes to all the editable rows and then update the changes by clicking the one \"Save\" button. Also, if you want to make the same change to multiple rows (e.g. to change five releases from \"active\" to \"inactive\"), you can click on the \"fill\" icon to the right of the editable item, which will propagate the new value to all editable items in the same column.
If you want to edit lots of items, first select their checkboxes and then click the \"Edit\" button on the same row as the Filters and it will switch all the selected items into edit mode.
When you have made your updates, you can either click \"Save\" to commit the changes, or \"Cancel\" to revert back to the original information. Alternatively, pressing the <ENTER> key will commit the changes and pressing the <ESCAPE> key will cancel the changes.
"},{"location":"Spira-User-Manual/Release-Management/#show-level","title":"Show Level","text":"Choosing an indent level from the 'Show Level' drop down box allows you to quickly and easily view the entire release list at a specific indent level. For example you may want to see all releases drilled-down to the third level of detail. To do this you would simply choose 'Level 3' from the list, and the releases will be expanded / collapsed accordingly.
"},{"location":"Spira-User-Manual/Release-Management/#show-hide-columns","title":"Show / Hide Columns","text":"This drop-down list allows you to change the fields that are displayed in the release list as columns for the current product. To show a column that is not already displayed, simply select that column from the list of \"Show...\" column names and to hide an existing column, simply select that column from the list of \"Hide...\" column names. This is stored on a per-product basis, so you can have different display settings for each product that you are a member of. The fields can be any of the built-in fields or any of the custom properties set up by the product owner.
"},{"location":"Spira-User-Manual/Release-Management/#copying-releasessprints","title":"Copying Releases/Sprints","text":"To copy a release/sprint or set of releases/sprints, simply select the check-boxes of the release/sprint you want to copy and then select the Edit > Copy Items menu option. This will copy the current release/sprint selection to the clipboard. Then you should select the place where you want the releases/sprints to be inserted and choose the Edit > Paste Items option.
The releases/sprints will now be copied into the destination location you specified. The name of the copied releases/sprints will be prefixed with \"Copy of...\" to distinguish them from the originals. Note that copied releases/sprints will also include the test mapping information from the originals.
Copying parent and child releases together
If you want to copy a parent release and its children only select the parent release. You do not need to also select each of its child releases.
"},{"location":"Spira-User-Manual/Release-Management/#cloning-releasessprints","title":"Cloning Releases/Sprints","text":"To clone a release/sprint or set of releases/sprints, open particular release and select \"Clone\" from the New menu option. Please note that if you're cloning from the child release details page then only child release will be cloned. If you're cloning the parent release then all the children releases is getting cloned as well.
When cloning (or copying) a release note that:
To move a release/sprint in the hierarchy, there are two options:
Click on the release/sprint you want to move and drag the icon to the location you want it moved. An empty space will appear to show you where it will be inserted. Once you have the requirement positioned at the correct place that you want it inserted, just release the mouse button. To move multiple items simply select their checkboxes and then drag-and-drop one of the selected items
Alternatively you can simply select the check-boxes of the release/sprint you want to move and then select the Edit > Cut Items menu option. This will cut the current release/sprint selection to the clipboard. Then you should select the place where you want the release/sprint to be inserted and choose the Edit > Paste Items option. The release/sprint will now be moved into the destination location you specified.
Read about how to export artifacts from one product to another.
"},{"location":"Spira-User-Manual/Release-Management/#creating-test-sets-from-releases","title":"Creating Test Sets from Releases","text":"As a shortcut you can click the Tools > Create Test Set option to create a new test set for each of selected releases. The created test sets will include all of the test cases associated with a release. This is useful in regression testing when you have created a new release and want to be able to quickly assign a tester to ensure that all the functionality in the release works as expected.
"},{"location":"Spira-User-Manual/Release-Management/#printing-or-saving-items","title":"Printing or Saving Items","text":"To quickly print a single release/sprint or list of releases/sprints you can select the items' checkboxes and then click Tools > Print Items. This will display a popup window containing a printable version of the selected items. You can also save the report in a variety of common formats from the same Tools menu.
"},{"location":"Spira-User-Manual/Release-Management/#right-click-context-menu","title":"Right-Click Context Menu","text":"SpiraPlan\u00ae provides a shortcut -- called the context menu - for accessing some of the most commonly used functions, so that you don't need to move your mouse up to the toolbar each time. To access the context menu, right-click on any of the rows in the release list and the following menu will be displayed:
You can now choose any of these options as an alternative to using the icons in the toolbar
"},{"location":"Spira-User-Manual/Release-Management/#releases-additional-list-views","title":"Releases Additional List Views","text":"In SpiraTeam and SpiraPlan, there are two additional release list views. These views are:
You can pick between each of these views using the view selection button group at the top right of any requirement list page.
"},{"location":"Spira-User-Manual/Release-Management/#release-gantt-chart","title":"Release Gantt Chart","text":"This displays all active releases and sprints2 nested in the same hierarchy as on the main release list page. Any release that has active children has an expand / collapse toggle to the left of its name. To the right of the release names is the timeline bar, which graphically shows the length of each release between their start and end dates in individual horizontal bars.
Part of a release may be shaded darker than normal, from its left (see Library System Release 1.1 below). This represents the requirements completion percentage for that release. So if a release bar stretches for 3 months and 33% of its requirements are complete, the first month of the bar will be shaded darker.
The names of the releases on the left or in the horizontal bar are clickable and will open the specific release.
Above the Gantt chart is a toolbar that lets you:
Add button to add a new release (or open the dropdown to add a new sprint or phase). Once you click Add you will have a popup to fill in information about the new release and then click Add Release. Adding the release inserts it at the bottom of the release hierarchy at the same indent level as the previous last release in the hierarchy.To view more information about a release, click its name from the left hand sidebar or in the relevant Gantt bar. This will open popup with much more detail. If you ctrl/cmd+click on the release name it will open the full details page for that artifact. Information shown in the popup includes all standard and custom fields. These fields are visible or hidden based on the workflow step that applies to that specific release.
You can edit releases straight from the Gantt chart. Users with bulk edit permissions can edit a release (including adding a new comment) at any time by clicking on the release name. This opens a popup with full information about that release. At all times, which fields are shown, required, or hidden is based on the workflow step that applies to that specific release. To save any changes you must fill in all required fields. Please note: you cannot change the status in this edit mode, to do so open the artifact's detail page (you can do this from the popup by clicking the button next to the artifact's id at the top).
Note: only fields that users are able to edit are shown - fields that are always read only (like the creation date) are not shown in this view.
"},{"location":"Spira-User-Manual/Release-Management/#releases-mind-map","title":"Releases Mind Map","text":"The releases Mind Map / Pert chart displays the first 5,000 releases in the release hierarchy of the product as a connected tree view / mindmap. The root node shows the name of the product at the top. The top most level nodes are connected underneath this, with their successive children shown from top to bottom.
For each release the map displays the name and ID of the release, with a tooltip that additionally shows the release's version number. Each node is color coded by the release type: product is the darkest; major and minor releases are less dark; sprints and phases are the lightest.
Clicking on the node will take you to the details page for that release.
There are several other display options:
To view more information about a release, click its name. This will open popup with much more detail. If you ctrl/cmd+click on the release name it will open the full details page for that artifact. Information shown in the popup includes all standard and custom fields. These fields are visible or hidden based on the workflow step that applies to that specific release.
You can edit releases straight from the mindmap. Users with bulk edit permissions can edit a release (including adding a new comment) at any time by clicking on the release name. This opens a popup with full information about that release. At all times, which fields are shown, required, or hidden is based on the workflow step that applies to that specific release. To save any changes you must fill in all required fields. Please note: you cannot change the status in this edit mode, to do so open the artifact's detail page (you can do this from the popup by clicking the button next to the artifact's id at the top).
Note: only fields that users are able to edit are shown - fields that are always read only (like the creation date) are not shown in this view.
"},{"location":"Spira-User-Manual/Release-Management/#release-details","title":"Release Details","text":"When you click on release item in the release list, you are taken to the release details page illustrated below:
This page is made up of three areas;
Please note that on smaller screen sizes the navigation pane is not displayed. While the navigation pane has a link to take you back to the releases list, on mobile devices a 'back' button is shown on the left of the operations toolbar.
The navigation pane can be collapsed by clicking on the \"-\" button, or expanded by clicking anywhere on the gray title area. On desktops the user can also control the exact width of the navigation pane by dragging and dropping a red handle that appears on hovering at the rightmost edge of the navigation pane.
The navigation pane consists of a link that will take you back to the release list, as well as a list of the other releases in the current product. This latter list is useful as a navigation shortcut; you can quickly view the test run information of all the other releases by clicking on the navigation links without having to first return to the release list page. The navigation list can be switched between two different modes:
The top part of the right pane allows you to view and/or edit the details of the particular release. In addition you can delete the current artifact by choosing \"Delete\", discard any changes made by clicking \"Refresh\", or print or export it by clicking one of the options from the Tools dropdown menu.
The lower part of the right pane can be in one of seven possible modes that can be selected: \"Overview\", \"Incidents\", \"Reqs & Tasks\", \"Test Cases\", \"Test Runs\", \"Attachments\", and \"History\". Each of the different views is described separately below.
"},{"location":"Spira-User-Manual/Release-Management/#emailing","title":"Emailing","text":"Read about emailing an artifact to colleagues using Spira.
"},{"location":"Spira-User-Manual/Release-Management/#followers","title":"Followers","text":"Read about how to add and manage followers to an artifact.
"},{"location":"Spira-User-Manual/Release-Management/#workflows-and-statuses","title":"Workflows and Statuses","text":"Releases can have the following statuses: planned, in progress, completed, closed, deferred, and cancelled. Note that releases marked as closed, deferred, or cancelled cannot be associated with other artifacts -- for example an incident's planned release cannot be a cancelled release.
Read about using workflows to change the status of your artifact.
"},{"location":"Spira-User-Manual/Release-Management/#overview-details","title":"Overview -- Details","text":"The Overview tab is divided into a number of different sections. Each of these can be collapsed or expanded by clicking on the title of that section. It displays the description, fields and comments associated with the requirement.
The top part of this tab displays the various standard fields and custom properties associated with the requirement. Fields (both standard and custom) are grouped under the collapsible headings (marked by orange text and underline) in the screenshot below. For instance, all fields regarding dates are grouped together in the \"Dates and Times\" area.
When you make changes to the release/sprint's start-date, end-date, number of product personnel resources, or number of non-working person days, the system will automatically calculate how many hours of effort (planned effort) are available in the release/sprint for assigning tasks. As you begin assigning tasks -- either through the Tasks tab or the Sprint Planning screen -- the total estimated effort of the tasks is subtracted from this planned effort to give the \"available effort\".
"},{"location":"Spira-User-Manual/Release-Management/#overview-detailed-information","title":"Overview -- Detailed Information","text":"The Detailed Information section contains the long, formatted description of the requirement, as well as any rich text custom fields. You can enter rich text or paste in from a word processing program or web page into these fields. Clicking on the shaded areas of one of these detailed fields will display the rich text toolbar.
"},{"location":"Spira-User-Manual/Release-Management/#overview-comments","title":"Overview - Comments","text":"Read about how the comments works
"},{"location":"Spira-User-Manual/Release-Management/#overview-builds","title":"Overview - Builds","text":"This section displays the list of builds associated with the current release/sprint. Each build is listed together with its name, creation date, status (whether the build succeeded or failed), and last updated date. Clicking on the hyperlink for the build name will open up the Build Details page.
You can also filter the results by choosing items from the filter options displayed in the sub-header row of each field and clicking the \"Apply Filter\" button. In addition, you can quickly sort the list by clicking on one of the directional arrow icons displayed in the header row of the appropriate field.
"},{"location":"Spira-User-Manual/Release-Management/#incidents","title":"Incidents","text":"This tab displays the incidents associated with the selected release. The incident list can be one of three modes:
Detected in this Release -- this will display a list of all the incidents that were detected during the testing of the selected release. This is useful in determining if there are open incidents associated with a release that need to be dealt with.
Resolved in this Release -- This will display a list of all the incidents that have been reportedly resolved in this release. This is useful for double-checking that all the resolved incidents for a release have indeed been fixed.
Verified in this Release -- This will display a list of the incidents that have been verified as being fixed in this release. This is useful for generating release notes for a specific release indicating what changes and enhancements have been made in the release.
Regardless of the mode, each incident is listed together with the type, status, priority, name, owner, detector, detection date and a link to the actual incident details:
To change between the three modes outlined above, select the desired mode from the drop-down list contained within the header of the incident list table.
You can perform the following actions:
Refresh -- updates the list of incidents from the server, useful if other people are adding incidents to this release at the same time.
You can filter the results by choosing items from the filter options displayed in the sub-header row of each field and clicking the \"Filter\" button. In addition, you can quickly sort the list by clicking on one of the directional arrow icons displayed in the header row of the appropriate field.
Edit -- Clicking the \"Edit\" button to the right of the incident allows you to edit the incident inline directly on this screen. This functionality is limited to product owners.
Show/Hide Columns -- Allows you to choose which incident columns are visible
"},{"location":"Spira-User-Manual/Release-Management/#reqs-tasks","title":"Reqs & Tasks","text":"This tab displays the list of requirements (excluding parent requirements - in other words it displays 'user stories') and their associated child tasks that need to be completed for the release/sprint to be completed:
Each of the requirements and associated tasks is displayed together with its:
Clicking on a requirement will bring up the requirement details page. Clicking the triangle by a requirement will expand/collapse its list of tasks. Clicking on a task name will bring up the Task Details page which is described in more detail in Task Tracking > Task Details. This allows you to edit the details of an existing task.
You can perform the following actions on a task from this screen:
This tab shows the test coverage information for the release in question:
The tab displays a grid containing the test cases already mapped to this release. You can filter that list by the test case type, name, status, execution status, execution date, priority, product name and ID. You can remove an existing test case by selecting its check box and clicking the 'Delete' button. This doesn't delete the test case, just removes it from the release.
Hovering the mouse over the names of the test cases will display a \"tooltip\" consisting of the test case name, place in the folder structure and a detailed description.
To add a new test case to the release, simply click on the 'Add' button:
You can search for a test case by its ID if you know it (make sure to include the \"TC\" prefix):
Otherwise, you can search for the test cases by choosing a folder from the dropdown and/or entering a partial name match:
One you have found the desired test case(s), simply select their check boxes and click the 'Save' button to add them to the current release.
Finally, as a shortcut you can click the \"Create Test Set from This Release\" link to create a new test set from this release, that will include all of the test cases associated with this release. This is useful in regression testing when you have created a new release and want to be able to quickly assign a tester to ensure that all the functionality in the release works as expected.
"},{"location":"Spira-User-Manual/Release-Management/#test-runs","title":"Test Runs","text":"This view displays the list of all the test runs executed against the release. Each test run is listed together with the date of execution, the name of the test case, the name of the tester, the release/version of the system that the test was executed against, the name of the test set (if applicable), the overall execution status for the test case in that run and a link to the actual test run details. In addition, you can choose to display any of the custom properties associated with the test run.
The \"Show/hide columns\" drop-down list allows you to change the fields that are displayed in the test run list as columns. To show a column that is not already displayed, simply select that column from the list of \"Show...\" column names and to hide an existing column, simply select that column from the list of \"Hide...\" column names. The displayed columns can be any standard field or custom property.
You can also filter the results by choosing items from the filter options displayed in the sub-header row of each field and clicking the \"Filter\" link. In addition, you can quickly sort the list by clicking on one of the directional arrow icons displayed in the header row of the appropriate field.
"},{"location":"Spira-User-Manual/Release-Management/#attachments","title":"Attachments","text":"Read about how the attachments tab works
"},{"location":"Spira-User-Manual/Release-Management/#baselines","title":"Baselines","text":"NOTE: Baselining is only available in SpiraTeam and SpiraPlan and this tab will be only then be visible if baselining has been turned on for a product.
This view displays the list of all baselines created for this release. If you have permissions for releases to create/modify/delete then you can perform the same actions for baselines.
You can view the following information about a baseline here:
To add a new baseline, click the New Baseline button. This will be disabled if you are not able to create releases. This will open up a small form. The name field is required, but the description field is optional. Enter the information and hit Add. NOTE: a baseline's description is plain text only.
You can edit an existing baseline as long as you can edit the specific release the baseline belongs to. If you see Edit buttons on the table of baselines that means you can edit. You can edit a baselines name, its description, and whether it is active or not.
If you can delete releases you can delete any baseline on any release. To do so click select the baselines to delete (put a checkmark next to it) and click the Delete button.
To filter and sort the list of baselines, use the filter and sort controls at the top of the table.
"},{"location":"Spira-User-Manual/Release-Management/#history","title":"History","text":"Read about how the history tab works
"},{"location":"Spira-User-Manual/Release-Management/#build-details","title":"Build Details","text":"When you click on a build entry in the build list, you are taken to the build details page illustrated below:
This page is made up of three areas:
The navigation panel has:
The top part of the right panel shows:
Beneath the header bar are a number of collapsible sections, each of which show specific information about the build or links between the build and other parts of the system. This sections are: \"Commits\", \"Associations\", \"Test Runs\", \"Incidents\", and \"Full Log\". These are described below.
the details of the build including a detailed description of why it succeeded or failed. Since builds are populated from an external Continuous Integration server the build information will always be read-only inside the SpiraPlan user interface.
"},{"location":"Spira-User-Manual/Release-Management/#commits","title":"Commits","text":"This section shows all source code commits included in the current build. The grid can be sorted and filtered by using the appropriate controls.
"},{"location":"Spira-User-Manual/Release-Management/#associations","title":"Associations","text":"This section shows a list of SpiraPlan artifacts associated with the build. This is automatically populated by all artifacts listed as tokens in the commit messages of the commits included in the build.
"},{"location":"Spira-User-Manual/Release-Management/#incidents_1","title":"Incidents","text":"This section shows the list of incidents that have been fixed in the current build. The grid can be sorted and filtered by using the appropriate controls. Note: if the build has no incidents the section will be hidden.
"},{"location":"Spira-User-Manual/Release-Management/#test-runs_1","title":"Test Runs","text":"This section displays a list of all the tests that have been executed against the current build. The grid can be sorted and filtered by using the appropriate controls. Note: if the build has no test runs the section will be hidden.
"},{"location":"Spira-User-Manual/Release-Management/#full-log","title":"Full Log","text":"This section displays the full console log readout that was returned from SpiraPlan by the build tool. This lets you view any detailed messages or errors. Note: this displays a maximum of two million characters (more than enough under normal circumstances) - longer logs are collapsed to show the first and last one million characters.
any task with a status that is not one of the following: \"Rejected\", \"Obsolete\", \"Duplicate\".\u00a0\u21a9
any release / sprint / phase with a status that is not \"Closed\", \"Deferred\", or \"Cancelled\".\u00a0\u21a9\u21a9
This section describes the reporting features of SpiraPlan\u00ae, including an overview of each of the report types that are available. When you click on the \"Reports\" tab on the global navigation bar, you will initially be taken to the reports home page illustrated below:
"},{"location":"Spira-User-Manual/Reports-Center/#overview","title":"Overview","text":"This page consists of four main areas:
The right-hand pane is a dashboard that contains the set of graph widgets configured by the current user. By default the dashboard will display: the Incident Progress Rate, Test Run Progress Rate, Requirement Summary, Test Case Summary, Incident Aging and Task Burndown. When \"All Releases\" is selected from the dropdown release picker, some widgets show information for every single release and sprint, and others only for active releases/sprints1:
In addition to the graphs displayed by default, you can click on the \"Add Items\" buttons to add additional graphs to the reporting dashboard:
Each of the graphs is described in more detail in Summary Graphs to Date-Range Graphs.
"},{"location":"Spira-User-Manual/Reports-Center/#reports-configuration","title":"Reports Configuration","text":"The configuration page for each report differs slightly, but the general format is illustrated below (please note all sections are shown in orange text with a line beneath and are shown here in the collapsed state -- click the orange text to expand the section):
You can configure the reports in the following ways:
"},{"location":"Spira-User-Manual/Reports-Center/#report-format","title":"Report Format","text":"This allows you to specify the display format of the report. Depending on the specific report, they can be:
This allows you to determine which types of information to include in the report. This varies by report type, but includes the dependent items related to the artifact being reported on (attachments, test steps, coverage, history, etc.)
"},{"location":"Spira-User-Manual/Reports-Center/#filters","title":"Filters","text":"Standard Field Filters -- This allows you to constrain the range of data being reported on, based on the various fields associated with the artifact in question. These filters are typically selections from multi-valued-dropdown lists and date-ranges.
Custom Property Filters -- This allows you to constrain the range of data being reported on, based on the custom fields associated with the artifact by your product administrator. These filters can be either freetext or drop-down lists.
Sort Options - This option is only available for the non-hierarchical data reports (i.e. for test cases, test sets, test runs, incidents and tasks) and allows you to specify the sort order of the results returned in the report. For the hierarchical-data based reports the sort order is always the order of the hierarchy.
"},{"location":"Spira-User-Manual/Reports-Center/#saving-and-sharing","title":"Saving and Sharing","text":"Report Name -- If you would like to save the report configuration so that you can quickly re-run it at a later date, you just need to enter a name for the report and indicate (by selecting the checkbox or not) whether you want this report to be private or shared by all members of the product.
To save the generated report into the documents repository for the product, check the checkbox. This will load two extra inputs:
Once you have selected the format, elements and filters, clicking the \"Create Report\" button launches the report in a new window. If you saved the generated report to documents, you can view that report in the folder you selected at any time, as with any other document.
Each of the reports is described below:
"},{"location":"Spira-User-Manual/Reports-Center/#requirement-reports","title":"Requirement Reports","text":""},{"location":"Spira-User-Manual/Reports-Center/#requirements-summary-report","title":"Requirements Summary Report","text":"This report displays all of the requirements defined for the current product in the order they appear in the requirements list. The requirement's details and coverage status are displayed in a summary list form:
"},{"location":"Spira-User-Manual/Reports-Center/#requirements-detailed-report","title":"Requirements Detailed Report","text":"This printable report displays all of the requirements defined for the current product in the order they appear in the requirements list. For each individual requirement, the name, priority, author, status and coverage status are displayed, along with tables containing the list of covering test cases, these test cases' test runs, linked incidents/requirements, associated tasks, attached documents, and the change history:
"},{"location":"Spira-User-Manual/Reports-Center/#requirements-plan","title":"Requirements Plan","text":"This report displays a complete work breakdown structure of the product from a requirements perspective, including all requirements and tasks organized by schedule:
"},{"location":"Spira-User-Manual/Reports-Center/#requirements-traceability-matrix","title":"Requirements Traceability Matrix","text":"This report displays a matrix of the requirements in the system with their list of covering test cases and associated, mapped requirements:
"},{"location":"Spira-User-Manual/Reports-Center/#test-case-reports","title":"Test Case Reports","text":""},{"location":"Spira-User-Manual/Reports-Center/#test-case-summary-report","title":"Test Case Summary Report","text":"This report displays all of the test cases defined for the current product in the order they appear in the test case list. The test case's details and execution status are displayed in a summary grid form with the test steps optionally displayed:
"},{"location":"Spira-User-Manual/Reports-Center/#test-case-detailed-report","title":"Test Case Detailed Report","text":"This report displays all of the test cases defined for the current product in the order they appear in the test case list. The test case's details and execution status are displayed, along with sub-tables containing the list of test steps, test runs, attached documents, the change history, and a list of any associated open incidents:
"},{"location":"Spira-User-Manual/Reports-Center/#test-set-summary-report","title":"Test Set Summary Report","text":"This report displays all of the test sets defined for the current product in the order they appear in the test set list. The test set's details and execution status are displayed in a summary list form:
"},{"location":"Spira-User-Manual/Reports-Center/#test-set-detailed-report","title":"Test Set Detailed Report","text":"This report displays all of the test sets defined for the current product in the order they appear in the test set list. The test set's details and execution status are displayed, along with sub-tables containing the list of test cases, test runs, attached documents, and the change history:
"},{"location":"Spira-User-Manual/Reports-Center/#printable-test-scripts","title":"Printable Test Scripts","text":"This printable report is useful when you want to be able to conduct the testing activities offline on paper, or when testers need paper copies of the test script in addition to using the online test execution wizard.
In either case, this report simply displays all of the test cases defined for the current product in the order they appear in the test case list together with their detailed test steps and a list of any attached documents.
"},{"location":"Spira-User-Manual/Reports-Center/#test-run-summary-report","title":"Test Run Summary Report","text":"This report displays all of the test runs defined for the current product. The test run's details and execution status are displayed in a summary grid form:
"},{"location":"Spira-User-Manual/Reports-Center/#test-run-detailed-report","title":"Test Run Detailed Report","text":"This report displays all of the test runs defined for the current product in date order (most recent first). The test run's details and execution status are displayed, along with sub-tables containing the list of test run steps, and a list of any associated open incidents:
"},{"location":"Spira-User-Manual/Reports-Center/#test-case-traceability","title":"Test Case Traceability","text":"This report displays a matrix of the test cases in the system with the list of mapped releases, incidents and test sets:
"},{"location":"Spira-User-Manual/Reports-Center/#incident-reports","title":"Incident Reports","text":""},{"location":"Spira-User-Manual/Reports-Center/#incident-summary-report","title":"Incident Summary Report","text":"This report displays all of the incidents tracked for the current product. Incident information is displayed in a summary list/table form:
"},{"location":"Spira-User-Manual/Reports-Center/#incident-detailed-report","title":"Incident Detailed Report","text":"This printable report displays all of the incidents tracked for the current product sorted by incident number. For each individual incident, the name, type, priority, status, opener, owner and close date are displayed, along with tables containing the detailed description and resolutions as well as a tabular list of attached documents, linked requirements/incidents and the change history:
"},{"location":"Spira-User-Manual/Reports-Center/#task-reports","title":"Task Reports","text":""},{"location":"Spira-User-Manual/Reports-Center/#task-summary-report","title":"Task Summary Report","text":"This report displays all of the tasks tracked for the current product. The task's details are displayed in a summary list form:
"},{"location":"Spira-User-Manual/Reports-Center/#task-detailed-report","title":"Task Detailed Report","text":"This report displays all of the tasks tracked for the current product. The task's details are displayed, along with a tabular list of attached documents and the change history:
"},{"location":"Spira-User-Manual/Reports-Center/#release-reports","title":"Release Reports","text":""},{"location":"Spira-User-Manual/Reports-Center/#release-summary-report","title":"Release Summary Report","text":"This report displays all of the releases and sprints defined for the current product in the order they appear in the release/sprint hierarchy. The release's details are displayed in a summary list form:
"},{"location":"Spira-User-Manual/Reports-Center/#release-detailed-report","title":"Release Detailed Report","text":"This report displays all of the releases and sprints defined for the current product in the order they appear in the release/sprint hierarchy. The release's details are displayed, along with sub-tables containing the list of requirements added, mapped test cases, test runs executed, incidents resolved, attached documents, scheduled tasks and the change history:
"},{"location":"Spira-User-Manual/Reports-Center/#release-plan-report","title":"Release Plan Report","text":"This report displays a complete work breakdown structure of the product from a release perspective, including all releases, sprints, requirements, tasks and incidents organized by schedule:
"},{"location":"Spira-User-Manual/Reports-Center/#summary-graphs","title":"Summary Graphs","text":""},{"location":"Spira-User-Manual/Reports-Center/#requirements-summary-graph","title":"Requirements Summary Graph","text":"The requirements summary graph shows how many requirements are currently in a product. The number of requirements is displayed according to the criteria that you specify. You can specify the type of data displayed along the x-axis, and the requirement information which is used to group the data. When you first open the graph you will be asked to pick the field that you would like to display on the x-axis and the field that you would like to group the data by. Once you have chosen the appropriate fields the graph will be displayed:
In this version of the report, the x-axis represents the requirements' status, and the individual bars are grouped by requirement importance. Each data-value can be viewed by positioning the mouse pointer over the bar, and a \"tooltip\" will pop-up listing the actual data value.
If a specific release is currently selected for the whole page, then Release is selected from one of the graph dropdowns, the graph shows only data for the specific release and its child sprints, if any.
Clicking on the \"Display Data Grid\" button will display the underlying data that is being used to generate the graph:
Clicking on the \"Download Data as CSV\" button will export the datagrid into Comma Separated Values (CSV) format that can be opened in MS-Excel. Some browsers also support the ability to save the graph as an image file (JPEG, PNG and GIF formats).
"},{"location":"Spira-User-Manual/Reports-Center/#test-case-summary-graph","title":"Test Case Summary Graph","text":"The test case summary graph shows how many test cases are currently in a product. The number of test cases is displayed according to the criteria that you specify. You can specify the type of data displayed along the x-axis, and the test case information which is used to group the data. When you first open the graph you will be asked to pick the field that you would like to display on the x-axis and the field that you would like to group the data by. Once you have chosen the appropriate fields the graph will be displayed:
In this version of the report, the x-axis represents the test case execution status, and the individual bars are grouped by test case priority. Each data-value can be viewed by positioning the mouse pointer over the bar, and a \"tooltip\" will pop-up listing the actual data value. Clicking on the \"Display Data Grid\" button will display the underlying data that is being used to generate the graph. In addition, clicking on the \"Download Data as CSV\" button will export the datagrid into Comma Separated Values (CSV) format that can be opened in MS-Excel. Some browsers also support the ability to save the graph as an image file (JPEG, PNG and GIF formats).
"},{"location":"Spira-User-Manual/Reports-Center/#test-run-summary-graph","title":"Test Run Summary Graph","text":"The test run summary graph shows how many test runs are currently in a product. The number of test runs is displayed according to the criteria that you specify. You can specify the type of data displayed along the x-axis, and the test run information which is used to group the data. When you first open the graph you will be asked to pick the field that you would like to display on the x-axis and the field that you would like to group the data by. Once you have chosen the appropriate fields the graph will be displayed:
In this version of the report, the x-axis represents the test run execution status, and the individual bars are grouped by test run type. If a specific release is currently selected for the whole page, then Release is selected from one of the graph dropdowns, the graph shows only data for the specific release and its child sprints, if any.
Each data-value can be viewed by positioning the mouse pointer over the bar, and a \"tooltip\" will pop-up listing the actual data value. Clicking on the \"Display Data Grid\" button will display the underlying data that is being used to generate the graph. In addition, clicking on the \"Download Data as CSV\" button will export the datagrid into Comma Separated Values (CSV) format that can be opened in MS-Excel. Some browsers also support the ability to save the graph as an image file (JPEG, PNG and GIF formats).
"},{"location":"Spira-User-Manual/Reports-Center/#incident-summary-graph","title":"Incident Summary Graph","text":"The incident summary graph shows how many incidents are currently in a product. The number of incidents is displayed according to the criteria that you specify. You can specify the type of data displayed along the x-axis, and the incident information which is used to group the data. When you first open the graph you will be asked to pick the field that you would like to display on the x-axis and the field that you would like to group the data by. Once you have chosen the appropriate fields the graph will be displayed:
In this version of the report, the x-axis represents the incidents' status, and the individual bars are grouped by the type of incident. For incidents, the whole-page release selection applies to the incident Detected Release field.
Each data-value can be viewed by positioning the mouse pointer over the bar, and a \"tooltip\" will pop-up listing the actual data value. Clicking on the \"Display Data Grid\" button will display the underlying data that is being used to generate the graph. In addition, clicking on the \"Download Data as CSV\" button will export the datagrid into Comma Separated Values (CSV) format that can be opened in MS-Excel. Some browsers also support the ability to save the graph as an image file (JPEG, PNG and GIF formats).
"},{"location":"Spira-User-Manual/Reports-Center/#task-summary-graph","title":"Task Summary Graph","text":"The task summary graph shows how many tasks are currently in a product. The number of tasks is displayed according to the criteria that you specify. You can specify the type of data displayed along the x-axis, and the task information which is used to group the data. When you first open the graph you will be asked to pick the field that you would like to display on the x-axis and the field that you would like to group the data by. Once you have chosen the appropriate fields the graph will be displayed:
In this version of the report, the x-axis represents the tasks' priority, and the individual bars are grouped by the status of task. If a specific release is currently selected for the whole page, then Release is selected from one of the graph dropdowns, the graph shows only data for the specific release and its child sprints, if any.
Each data-value can be viewed by positioning the mouse pointer over the bar, and a \"tooltip\" will pop-up listing the actual data value. Clicking on the \"Display Data Grid\" button will display the underlying data that is being used to generate the graph. In addition, clicking on the \"Download Data as CSV\" button will export the datagrid into Comma Separated Values (CSV) format that can be opened in MS-Excel. Some browsers also support the ability to save the graph as an image file (JPEG, PNG and GIF formats).
"},{"location":"Spira-User-Manual/Reports-Center/#test-set-summary-graph","title":"Test Set Summary Graph","text":"The test set summary graph shows how many test set are currently in a product. The number of test sets is displayed according to the criteria that you specify. You can specify the type of data displayed along the x-axis, and the test set information which is used to group the data. When you first open the graph you will be asked to pick the field that you would like to display on the x-axis and the field that you would like to group the data by. Once you have chosen the appropriate fields the graph will be displayed:
In this version of the report, the x-axis represents the test set status, and the individual bars are grouped by the name of the tester (owner). If a specific release is currently selected for the whole page, then Release is selected from one of the graph dropdowns, the graph shows only data for the specific release and its child sprints, if any.
Each data-value can be viewed by positioning the mouse pointer over the bar, and a \"tooltip\" will pop-up listing the actual data value. Clicking on the \"Display Data Grid\" button will display the underlying data that is being used to generate the graph. In addition, clicking on the \"Download Data as CSV\" button will export the datagrid into Comma Separated Values (CSV) format that can be opened in MS-Excel. Some browsers also support the ability to save the graph as an image file (JPEG, PNG and GIF formats).
"},{"location":"Spira-User-Manual/Reports-Center/#snapshot-graphs","title":"Snapshot Graphs","text":""},{"location":"Spira-User-Manual/Reports-Center/#requirements-coverage-graph","title":"Requirements Coverage Graph","text":"The requirements coverage graph shows how many requirements are currently in a product, according to their test coverage status.
The x-axis of the report represents the various test execution statuses that a requirement can have as its coverage status (plus the Not-Covered status), and the individual bars are grouped by the requirements importance. Each data-value can be viewed by positioning the mouse pointer over the bar, and a \"tooltip\" will pop-up listing the actual data value.
Clicking on the \"Display Data Grid\" button will display the underlying data that is being used to generate the graph. In addition, clicking on the \"Download Data as CSV\" button will export the datagrid into Comma Separated Values (CSV) format that can be opened in MS-Excel. Some browsers also support the ability to save the graph as an image file (JPEG, PNG and GIF formats).
"},{"location":"Spira-User-Manual/Reports-Center/#requirements-burndown-graph","title":"Requirements Burndown Graph","text":"The Requirements Burndown graph shows the remaining number of story points that needs to be completed for each release/sprint in the product with separate lines for the estimated and ideal burndown. In addition, the graph includes bars for the completed number of story points in each time period on the x-axis:
The y-axis of the graph displays the total remaining number of story points that needs to be done (the actual burndown), with a blue line indicating the ideal burndown. In addition, there are bars displayed at each interval of the x-axis that shows the completed number of story points for that interval.
The x-axis display will change based on the selection of the dropdown release picker:
Clicking on the \"Display Data Grid\" button will display the underlying data that is being used to generate the graph. In addition, clicking on the \"Download Data as CSV\" button will export the datagrid into Comma Separated Values (CSV) format that can be opened in MS-Excel. Some browsers also support the ability to save the graph as an image file (JPEG, PNG and GIF formats).
"},{"location":"Spira-User-Manual/Reports-Center/#requirements-burnup-graph","title":"Requirements Burnup Graph","text":"The Requirements Burnup graph shows the cumulative number of story points outstanding for each release/sprint in the product with separate lines for the estimated and ideal burnup. In addition, the graph includes bars for the number of completed story points in each time period on the x-axis.
The y-axis of the graph displays the cumulative increase in number of story points for the product (the actual burnup), with a blue line indicating the ideal burnup. In addition, there are bars displayed at each interval of the x-axis that shows the number of completed story points for that interval.
The x-axis display will change based on the selection of the dropdown release picker:
Clicking on the \"Display Data Grid\" button will display the underlying data that is being used to generate the graph. In addition, clicking on the \"Download Data as CSV\" button will export the datagrid into Comma Separated Values (CSV) format that can be opened in MS-Excel. Some browsers also support the ability to save the graph as an image file (JPEG, PNG and GIF formats).
"},{"location":"Spira-User-Manual/Reports-Center/#requirements-velocity-graph","title":"Requirements Velocity Graph","text":"The Requirements Velocity graph shows the total number of story points that have been completed (or planned to be completed) in a particular release, sprint or time-period (called the velocity). The actual velocity is displayed along with the overall average velocity (in blue) and the rolling average velocity (in green):
The y-axis display will change based on the selection of the dropdown release picker:
Clicking on the \"Display Data Grid\" button will display the underlying data that is being used to generate the graph. In addition, clicking on the \"Download Data as CSV\" button will export the datagrid into Comma Separated Values (CSV) format that can be opened in MS-Excel. Some browsers also support the ability to save the graph as an image file (JPEG, PNG and GIF formats).
"},{"location":"Spira-User-Manual/Reports-Center/#incident-aging-graph","title":"Incident Aging Graph","text":"The incident aging graph displays the number of days incidents have been left open in the system with the count of incidents on the y-axis and different age intervals on the x-axis. Each bar-chart color represents a different incident priority, giving a product manager a snapshot view of the age of open incidents by priority and detected release. For this chart, \"open\" is defined as any incident with an empty \"Closed On\" date. The incident status is not used for this chart.
This report can be filtered by the type of incident, so for example you can see the aging of just bugs, or just issues for the product in question. Clicking on the \"Display Data Grid\" button will display the underlying data that is being used to generate the graph. In addition, clicking on the \"Download Data as CSV\" button will export the datagrid into Comma Separated Values (CSV) format that can be opened in MS-Excel. Some browsers also support the ability to save the graph as an image file (JPEG, PNG and GIF formats).
"},{"location":"Spira-User-Manual/Reports-Center/#incident-turnaround-time-graph","title":"Incident Turnaround Time Graph","text":"The incident turnaround time graph displays the number of days incidents have taken to be closed (from the time they were first raised) in the system with the count of incidents on the y-axis and different turnaround time intervals on the x-axis. Each bar-chart color represents a different incident priority, giving a product manager a snapshot view of the turnaround time of incidents by priority and detected release. For this chart, \"closed\" is defined as any incident with a \"Closed On\" date. The incident status is not used for this chart.
This report can be filtered by the type of incident, so for example you can see the turnaround time of just bugs, or just issues for the product in question. Clicking on \"Display Data Grid\" button will display the underlying data that is being used to generate the graph. In addition, clicking on the \"Download Data as CSV\" button will export the datagrid into Comma Separated Values (CSV) format that can be opened in MS-Excel. Some browsers also support the ability to save the graph as an image file (JPEG, PNG and GIF formats).
"},{"location":"Spira-User-Manual/Reports-Center/#task-velocity-chart","title":"Task Velocity Chart","text":"The Task Velocity graph shows the total estimated and actual effort (in number of hours) delivered in each product release and/or sprint:
The y-axis of the graph displays the total estimated and actual effort delivered (in hours). The x-axis display will change based on the selection of the dropdown release picker:
Clicking on the \"Display Data Grid\" button will display the underlying data that is being used to generate the graph. In addition, clicking on the \"Download Data as CSV\" button will export the datagrid into Comma Separated Values (CSV) format that can be opened in MS-Excel. Some browsers also support the ability to save the graph as an image file (JPEG, PNG and GIF formats).
"},{"location":"Spira-User-Manual/Reports-Center/#task-burnup-chart","title":"Task Burnup Chart","text":"The Task Burnup graph shows the cumulative amount of work outstanding for each release/sprint in the product with separate lines for the estimated and ideal burnup. In addition, the graph includes bars for the remaining and completed effort in each time period on the x-axis.
The y-axis of the graph displays the cumulative increase in work (in hours) for the product (the actual burnup), with a blue line indicating the ideal burnup. In addition, there are bars displayed at each interval of the x-axis that shows the remaining effort and completed effort for that interval.
The x-axis display will change based on the selection of the dropdown release picker:
Clicking on the \"Display Data Grid\" button will display the underlying data that is being used to generate the graph. In addition, clicking on the \"Download Data as CSV\" button will export the datagrid into Comma Separated Values (CSV) format that can be opened in MS-Excel. Some browsers also support the ability to save the graph as an image file (JPEG, PNG and GIF formats).
"},{"location":"Spira-User-Manual/Reports-Center/#task-burndown-chart","title":"Task Burndown Chart","text":"The Task Burndown graph shows the effort (in hours) on the y-axis. The x-axis shows releases/sprints - the releases/sprints shown changes as you change the release selector at the top of the page. To be useful tasks in the product have to have their effort fields populated (specifically Estimated Effort and Remaining Effort).
The blue line on the graphs indicates the ideal burndown. The other line shows the estimated actual burndown. The graph also shows bars for the remaining and completed effort for each relevant release/sprint.
The x-axis display will change based on the selection of the dropdown release picker:
Clicking on the \"Display Data Grid\" button shows the underlying data used to generate the graph. Clicking the Download Data as CSV exports the data into Comma Separated Values (CSV) file. Some browsers support saving the graph as an image (JPEG, PNG and GIF formats).
The Test Run Progress Rate Graph shows how many tests have been executed for the selected release/sprint for a specific date range, and what execution status was recorded. The graph can be displayed for all test case types or for a specific type.
In this version of the report, the y-axis represents the number of test runs executed in each 24 hour period, and the x-axis represents a specific week in the time-span. Each data-bar can be viewed by positioning the mouse pointer over the point, and a \"tooltip\" will pop-up listing the actual data value. You can filter the report by the release/sprint that the test run was executed against, and also change the date range. If you choose a smaller date-range, the x-axis will switch from weekly to daily and if you choose a larger date-range, the x-axis will switch to monthly.
Clicking on the \"Display Data Grid\" button will display the underlying data that is being used to generate the graph. In addition, clicking on the \"Download Data as CSV\" button will export the datagrid into Comma Separated Values (CSV) format that can be opened in MS-Excel. Some browsers also support the ability to save the graph as an image file (JPEG, PNG and GIF formats).
"},{"location":"Spira-User-Manual/Reports-Center/#test-case-progress-rate-graph","title":"Test Case Progress Rate Graph","text":"The Test Case Progress Rate Graph displays the number of test case executions for the specified date range, against the specified release/sprint, ignoring the status from any previous days. Any test cases not executed that day will be considered \"not run\" and will appear in the \"not run\" category.
For example, if you have 10 test cases created on day 1 you will see 10 test cases \"not run\" on day 1. On day 2, you execute 5 test cases and fail them all, you will now see 5 test cases failed and 5 not run. On day 3, you execute 3 of the previous 5 test cases and pass them. You will now see 3 test cases passed, 0 failed and 7 not run.
"},{"location":"Spira-User-Manual/Reports-Center/#test-case-cumulative-progress-graph","title":"Test Case Cumulative Progress Graph","text":"The Test Case Cumulative Progress Graph displays the number of test case executions cumulatively over the specified date range, against the specified release/sprint. That means it will display for each day, the total number of test cases executed plus the status from any previous days that have not been changed. Any test cases not executed up to that point will be considered \"not run\" and will appear in the \"not run\" category.
For example, if you have 10 test cases created on day 1 you will see 10 test cases \"not run\" on day 1. On day 2, you execute 5 test cases and fail them all, you will now see 5 test cases failed and 5 not run. On day 3, you execute 3 of the previous 5 test cases and pass them. You will now see 3 test cases passed, 2 failed and 5 not run.
"},{"location":"Spira-User-Manual/Reports-Center/#incident-progress-rate-graph","title":"Incident Progress Rate Graph","text":"The incident progress rate chart displays the total number of incidents created and closed over a particular date-range, either for all incident types or for a specific incident type:
In this version of the report, the y-axis represents the number of incidents (either created or closed in a 24 hour period), and the x-axis represents a specific day in the time-span. Each data-point can be viewed by positioning the mouse pointer over the point, and a \"tooltip\" will pop-up listing the actual data value. You can filter the report by the type of incident, and also change the date range (e.g. displaying only the bugs for the date range). If you choose a smaller date-range, the x-axis will switch from weekly to daily and if you choose a larger date-range, the x-axis will switch to monthly.
Clicking on the \"Display Data Grid\" button will display the underlying data that is being used to generate the graph. In addition, clicking on the \"Download Data as CSV\" button will export the datagrid into Comma Separated Values (CSV) format that can be opened in MS-Excel. Some browsers also support the ability to save the graph as an image file (JPEG, PNG and GIF formats).
"},{"location":"Spira-User-Manual/Reports-Center/#cumulative-incident-count-graph","title":"Cumulative Incident Count Graph","text":"The cumulative incident count chart displays the cumulative total number of incidents logged in the system for the current product over a particular date-range, either for all incident types or for a specific incident type. The report displays two data series, one illustrating the total count of all incidents, the other the total count of all open incidents (i.e. with status not set to fixed or closed):
In this version of the report, the y-axis represents the number of incidents, and the x-axis represents a specific week in the time-span. Each data-point can be viewed by positioning the mouse pointer over the point, and a \"tooltip\" will pop-up listing the actual data value. You can also filter the type of incident being reported, as well as change the date interval. If you choose a smaller date-range, the x-axis will switch from weekly to daily and if you choose a larger date-range, the x-axis will switch to monthly.
Clicking on the \"Display Data Grid\" button will display the underlying data that is being used to generate the graph. In addition, clicking on the \"Download Data as CSV\" button will export the datagrid into Comma Separated Values (CSV) format that can be opened in MS-Excel. Some browsers also support the ability to save the graph as an image file (JPEG, PNG and GIF formats).
"},{"location":"Spira-User-Manual/Reports-Center/#open-incident-count-graph","title":"Open Incident Count Graph","text":"The open incident count chart displays the net number of open incidents in the system for the current product over a particular date-range categorized by incident priority, either for all incident types or for a specific incident type. For this chart, \"open\" is defined as any incident with an empty \"Closed On\" date. The incident status is not used for this chart.
In this version of the report, the y-axis represents the number of incidents, and the x-axis represents a specific week in the time-span. The exact count of each bar in the stacked histogram can be viewed by positioning the mouse pointer over the bar, and a \"tooltip\" will pop-up listing the actual data value. You can also filter the type of incident being reported, as well as change the date interval. If you choose a smaller date-range, the x-axis will switch from weekly to daily and if you choose a larger date-range, the x-axis will switch to monthly.
Clicking on the \"Display Data Grid\" button will display the underlying data that is being used to generate the graph. In addition, clicking on the \"Download Data as CSV\" button will export the datagrid into Comma Separated Values (CSV) format that can be opened in MS-Excel. Some browsers also support the ability to save the graph as an image file (JPEG, PNG and GIF formats).
"},{"location":"Spira-User-Manual/Reports-Center/#incident-count-by-status-graph","title":"Incident Count by Status Graph","text":"The incident status count chart displays the number of open incidents in the system for the current product over a particular date-range categorized by incident status, either for all incident types or for a specific incident type. For this chart, \"open\" is defined as any incident with an empty \"Closed On\" date. The incident status is not used for this chart.
In this version of the report, the y-axis represents the number of incidents, and the x-axis represents a specific week in the time-span. The exact count of each bar in the stacked histogram can be viewed by positioning the mouse pointer over the bar, and a \"tooltip\" will pop-up listing the actual data value. You can also filter the type of incident being reported, as well as change the date interval. If you choose a smaller date-range, the x-axis will switch from weekly to daily and if you choose a larger date-range, the x-axis will switch to monthly.
Clicking on the \"Display Data Grid\" button will display the underlying data that is being used to generate the graph. In addition, clicking on the \"Download Data as CSV\" button will export the datagrid into Comma Separated Values (CSV) format that can be opened in MS-Excel. Some browsers also support the ability to save the graph as an image file (JPEG, PNG and GIF formats).
"},{"location":"Spira-User-Manual/Reports-Center/#custom-graphs","title":"Custom Graphs","text":"These are the graphs that a SpiraPlan administrator has created in the Administration section of the system and published for use by end users. They rely on specific ESQL data queries, so the data represented will depend on the query created by the administrator.
To add a custom graph to your reports dashboard, click on the Add Items icon and click on the \"Custom Graphs\" button to show available custom graphs:
Once you add the Custom Graphs widget to your dashboard, it will look just like any other graph:
You can view the graph description from the \"i\" (for information) button at the top right of the graph. You can change the graph display between the three display types: donut, bar, and line. The donut style of graph is only available for reports with a single data series:
Clicking on the \"Data Grid\" icon will display the underlying data that is being used to generate the graph.
In addition, clicking on the \"Download Data as CSV\" button will export the data grid into Comma Separated Values (CSV) format that can be opened in MS-Excel.
Some browsers also support the ability to save the graph as an image file (JPEG, PNG and GIF formats).
"},{"location":"Spira-User-Manual/Reports-Center/#risk-reports","title":"Risk Reports","text":""},{"location":"Spira-User-Manual/Reports-Center/#risk-summary-report","title":"Risk Summary Report","text":"This report displays all of the risks tracked for the current project. The risks are displayed, along with a tabular list of mitigations, tasks, comments, attached documents, and change history:
"},{"location":"Spira-User-Manual/Reports-Center/#risk-detailed-report","title":"Risk Detailed Report","text":"This report displays all of the risks tracked for the current project. The risks are displayed in a summary table form:
An active release or sprint is one that has a status of either: \"Planned\", \"In Progress\", or \"Completed\"\u00a0\u21a9
This section outlines how the requirements management features of SpiraPlan\u00ae can be used to develop a requirements / scope matrix for a product, and how you can map any existing test-cases to the requirements. Typically when starting a product, developing the requirements list is the first activity after the Administrator has set up the product in the system.
"},{"location":"Spira-User-Manual/Requirements-Management/#requirement-traceability-and-coverage","title":"Requirement Traceability and Coverage","text":"From the requirement list page you can see a number of columns that show calculated data for each requirement, based off:
This allows you to see at a glance the state of play about a number of key metrics for the requirement.
"},{"location":"Spira-User-Manual/Requirements-Management/#test-coverage","title":"Test coverage","text":"This column shows a mini chart for the sum of each execution status against the requirement. It is calculated from the current execution status of each test case assigned to that requirement. If a requirement has no test case coverage then the mini chart will be empty. All requirements with at least one test case mapped against them will show a mini chart. For example, if a requirement has 3 test cases assigned to it, then the mini chart will show the results for those 3 test cases. If 2 of those test cases have passed and one has still not been run, the mini chart will show a green bar (for pass) that is \u2154 the length of the chart, and a gray bar (for not run) that is \u2153 the length of the bar.
If you hover the mouse over the mini chart it will display a tooltip that provides a more detailed description of the number of tests in each execution status.
When you have a hierarchy of requirements, the total number of test cases included in the mini chart is the sum of all of the test cases assigned to each of its children, added to the number of test cases directly assigned to the parent requirement.
Example: How Test Coverage Rolls up to Parent RequirementsThe left-hand sidebar on the requirements list page shows an donut chart of aggregate requirement test coverage in the product. It shows segments for each test execution status. It calculates the number for each execution status segment as follows:
Requirements with at least one task associated with them will display a task progress mini chart in the Task Progress column. This is a mini chart of the count of all active tasks1 assigned to the requirement. Each part of the chart represents the relative size of that progress category for the requirement. The progress categories are 'On Schedule', 'Late Finish', 'Late Start' and 'Not Started'.
If you hover the mouse over the mini chart it will display a tooltip that provides a more detailed description of the number of tasks in each category.
How are the different categories calculated?
On Schedule (green) tasks:
Running Late (red) tasks:
Starting Late (yellow) tasks:
Not Started (gray) tasks:
For each requirement each effort column is calculated from the sum of effort from all tasks assigned to that requirement. These values are aggregated to any parent requirements:
Task effort calculations are described in more detail here.
"},{"location":"Spira-User-Manual/Requirements-Management/#standard-requirements-and-parent-requirements","title":"Standard Requirements and Parent Requirements","text":"Requirements come in two main flavors (Both can be mapped against test cases for test coverage):
Standard requirements are any requirements that are not parents (do not have children). These are shown in normal-type and with a normal icon (for either a requirement or a use case). Standard requirements, unlike parent requirements, can:
Parent requirements are any requirement that has at least one child inside it. Parents are shown in bold-type and have a special parent requirement icon. They are marked as \"Yes\" when viewing the \"Is Parent?\" column on the requirement list pages. Parent requirements get some information based on their children (and are therefore always read only):
status, which is based on the status of their children:
When you indent a requirement under an existing requirement, the normal requirement becomes a parent requirement. When you outdent a child item, its parent will return to a standard requirement immediately, if it has no other children.
In all other ways these two requirement flavors are the same. For example, both can have any requirement type, both can be assigned to a release, or to a specific owner, and both follow the relevant workflow for their current type.
"},{"location":"Spira-User-Manual/Requirements-Management/#requirements-list","title":"Requirements List","text":"When you click on the Planning > Requirements link on the global navigation bar, you will initially be taken to the requirements list screen illustrated below:
Each requirement is, by default, displayed along with its importance/priority (ranked from \"Critical\" to \"Low\"), its completion status (from \"Requested\" to \"Completed\"), the version of the software that the requirement is planned for, and graphical indicators that represents its test coverage status and its task progress.
The requirements list consists of a hierarchical arrangement of the various requirements and functionalities that need to be provided by the system in question. The structure is very similar to the Work Breakdown Structure (WBS) developed in Microsoft Product\u00ae, and users of that software package will find this very familiar to use. When you create a new product, this list will be empty.
"},{"location":"Spira-User-Manual/Requirements-Management/#insert","title":"Insert","text":"Click the Insert button to add requirements. This button let's you add requirements in different ways:
Once the new requirement has been inserted, the item is switched to \"Edit\" mode so that you can rename the default name and choose a priority, status and/or author.
"},{"location":"Spira-User-Manual/Requirements-Management/#delete","title":"Delete","text":"Clicking on the \"Delete\" button deletes all the requirements whose check-boxes have been selected. If any of the items are summary items, the child requirements are also deleted. If all the children are deleted from a summary item, it changes back into a non-summary item.
"},{"location":"Spira-User-Manual/Requirements-Management/#indent","title":"Indent","text":"Clicking on the \"Indent\" button indents all the requirements whose check-boxes have been selected. If any of the items are made children of a requirement that had no previous children, it will be changed from a detail item into a summary item.
"},{"location":"Spira-User-Manual/Requirements-Management/#outdent","title":"Outdent","text":"Clicking on the \"Outdent\" button de-indents all the requirements whose check-boxes have been selected. If any of the items were the only children of a summary requirement item, then that item will be changed back from a summary item to a detail item.
"},{"location":"Spira-User-Manual/Requirements-Management/#refresh","title":"Refresh","text":"Clicking on the \"Refresh\" button simply reloads the requirements list (not the entire page). This is useful as other people may be modifying the list of requirements at the same time as you, and after stepping away from the computer for a short-time, you should click this button to make sure you are viewing the most current requirements list for the product.
"},{"location":"Spira-User-Manual/Requirements-Management/#edit","title":"Edit","text":"Each requirement in the list has an \"Edit\" button display in its right-most column. When you click this button or just double-click on any of the cells in the row, you change the item from \"View\" mode to \"Edit\" mode. The various columns are made editable, and \"Update\" buttons are displayed in the last column:
If you click \"Edit\" on more than one row, the \"Update\" buttons are only displayed on the first row selected. You can make changes to all the editable rows and then update the changes by clicking the one \"Update\" button. Also, if you want to make the same change to multiple rows (e.g. to change five requirements from \"In Progress\" status to \"Completed\"), you can click on the \"fill\" icon to the right of the editable item, which will propagate the new value to all editable items in the same column.
If you want to edit lots of items, first select their checkboxes and then click the [Edit] button on the same row as the Filters and it will switch all the selected items into edit mode.
When you have made your updates, you can either click \"Save\" to commit the changes, or \"Cancel\" to revert back to the original information. Alternatively, pressing the <ENTER> key will commit the changes and pressing the <ESCAPE> key will cancel the changes.
"},{"location":"Spira-User-Manual/Requirements-Management/#show-level","title":"Show Level","text":"Choosing an indent level from the 'Show Level' drop down box allows you to quickly and easily view the entire requirements list at a specific indent level. For example you may want to see all requirements drilled-down to the third level of detail. To do this you would simply choose 'Level 3' from the list, and the requirements will be expanded / collapsed accordingly.
"},{"location":"Spira-User-Manual/Requirements-Management/#filtering","title":"Filtering","text":"Read about how to create and manage filters.
"},{"location":"Spira-User-Manual/Requirements-Management/#show-hide-columns","title":"Show / Hide Columns","text":"This drop-down list allows you to change the fields that are displayed in the requirement list as columns for the current product. To show a column that is not already displayed, simply select that column from the list of \"Show...\" column names and to hide an existing column, simply select that column from the list of \"Hide...\" column names. This is stored on a per-product basis, so you can have different display settings for each product that you are a member of. The fields can be any of the built-in fields or any of the custom properties set up by the product owner.
"},{"location":"Spira-User-Manual/Requirements-Management/#copying-requirements","title":"Copying Requirements","text":"To copy a requirement or set of requirements, simply select the check-boxes of the requirements you want to copy and then select the Edit > Copy Items menu option. This will copy the current requirements selection to the clipboard. Then you should select the place where you want the requirements to be inserted and choose the Edit > Paste Items option.
The requirements will now be copied into the destination location you specified. The name of the copied requirements will have \" - Copy\" at the end, to distinguish them from the originals. Note that copied requirements will also include the test coverage information from the originals.
"},{"location":"Spira-User-Manual/Requirements-Management/#moving-requirements","title":"Moving Requirements","text":"To move a requirement in the requirements hierarchy, there are two options:
Once you have the requirement positioned at the correct place that you want it inserted, just release the mouse button. To move multiple items simply select their checkboxes and then drag-and-drop one of the selected items.
Read about how to export artifacts from one product to another.
"},{"location":"Spira-User-Manual/Requirements-Management/#creating-test-cases-from-requirements","title":"Creating Test Cases from Requirements","text":"To quickly create test cases from a group of requirements, all you need to do is select the check-boxes of the appropriate requirements and then click Tools > Create Test Cases. This will then create new test cases based on the selected requirements.
"},{"location":"Spira-User-Manual/Requirements-Management/#creating-a-test-set-from-requirements","title":"Creating a Test Set from Requirements","text":"To quickly create a new test set from a group of requirements, all you need to do is select the check-boxes of the appropriate requirements and then click Tools > Create Test Set. This will then create new test set containing the test cases that are already mapped to the selected requirement(s).
"},{"location":"Spira-User-Manual/Requirements-Management/#printing-items","title":"Printing Items","text":"To quickly print a single requirement or list of requirements you can select the items' checkboxes and then click Tools > Print Items. This will open a new window containing a printable version of the selected items.
"},{"location":"Spira-User-Manual/Requirements-Management/#focus-on-branch","title":"Focus-On Branch","text":"Sometimes you will see a list of filtered requirements displayed and you would like to view all of the items that in the same branch of the requirements tree, even those that don't match the current filter. To view the branch, select the checkbox of the branch and then click Tools > Focus on, and the system will clear the current filters and then expand just the selected branch.
"},{"location":"Spira-User-Manual/Requirements-Management/#right-click-context-menu","title":"Right-Click Context Menu","text":"SpiraPlan\u00ae provides a shortcut -- called the context menu - for accessing some of the most commonly used functions, so that you don't need to move your mouse up to the toolbar each time. To access the context menu, right-click on any of the rows in the requirements list and the following menu will be displayed:
You can now choose any of these options as an alternative to using the icons in the toolbar.
"},{"location":"Spira-User-Manual/Requirements-Management/#viewing-requirements-from-shared-products","title":"Viewing Requirements from Shared Products","text":"If you are displaying the requirements list for a product has required shared from other products, you will see the option on the top-right to view the requirements from the shared product(s):
If you choose the option to show the requirement from 'All Products' and not just the current product, the shared products are displayed, grouped under the name of the product they are being shared from:
Note: Any requirements shared from other products will be read-only and won't display any of their custom properties. However you can expand/collapse these shared requirements and filter using the standard fields.
"},{"location":"Spira-User-Manual/Requirements-Management/#requirements-additional-list-views","title":"Requirements Additional List Views","text":"In SpiraTeam and SpiraPlan, there are four additional requirement list views. They are designed to better serve the needs of the Business Analyst community who often need different views of requirements than the project teams and project managers. These views are:
You can pick between each of these views using the view selection button group at the top right of any requirement list page.
Note: you can only view requirements from the current product in these four additional views, whether or not you are sharing requirements from other products with this product.
"},{"location":"Spira-User-Manual/Requirements-Management/#requirements-sorted-list","title":"Requirements Sorted List","text":"This view lets you view the requirements in a flat, sortable list that does not show the requirements hierarchy. You can still see the hierarchy of an item by hovering the mouse over its name to display the tooltip.
This view lets you sort or filter on any of the visible fields.
One major benefit of this view is that when you filter by a field, you only get the items that are a direct match, unlike in the hierarchical grid view, where you also get its parents displayed. It can be useful to displaying a list of only parent requirements.
"},{"location":"Spira-User-Manual/Requirements-Management/#toolbar","title":"Toolbar","text":"When cloning the requirements note that:
followers, comments, and history are not cloned
Tools: this dropdown allows to export requirements, create test cases or create test sets from requirements, or to print items.
To access the context menu, right-click on any of the rows in the requirements sorted list and the following menu will be displayed:
You can now choose any of these options as an alternative to using the icons in the toolbar.
"},{"location":"Spira-User-Manual/Requirements-Management/#requirements-agile-board","title":"Requirements Agile Board","text":"This view is similar to the existing Planning Board but only displays requirements, whereas the primary planning board will also include incidents / defects. This gives the requirements page consistency with the tasks and incidents pages that already have a Grid / Board view selector option.
"},{"location":"Spira-User-Manual/Requirements-Management/#requirements-document-view","title":"Requirements Document View","text":"This view shows the hierarchical organization of the requirements in a product. Instead of being displayed in a grid form, they are displayed in a document format that is designed to be readable from top to bottom, like a traditional requirements document. You can edit the name and description fields inline to update your document as you read through it, as well as change what fields are visible, to tailor the document to your needs.
"},{"location":"Spira-User-Manual/Requirements-Management/#requirements-document-navigation","title":"Requirements Document Navigation","text":"The sidebar shows all the parent requirements in the product2, in their hierarchy. Clicking on a parent requirement will load that parent with all its children2 into the document view (and save this view for the next time you are on this page for this product). There is a special link at the top of the list of parent requirements called \"Level 1 (root)\" and clicking on this will load all requirements at the root level (level 1)2. This is the default view you will see when you first visit the documents view. Looking at \"Level 1 (root)\" is particularly useful if you need to view or edit standalone requirements (requirements that do not have a parent or any children).
When you click a parent requirement (or \"Level 1 (root)\") from the sidebar, the documents view will show a page of the first 50 requirements. If there are more than 50 requirements you can quickly change pages by using the pagination options at the top right.
"},{"location":"Spira-User-Manual/Requirements-Management/#requirements-document-options","title":"Requirements Document Options","text":"For each requirement, the following fields are always displayed at the top of the requirement:
The following fields are displayed by default (but can be hidden) in a header bar, below the requirement name:
The following fields are always displayed, and below the header bar:
Additionally you can choose to show the following fields in the header bar:
To show or hide any of the optional fields, click the \"Show/Hide fields\" dropdown at the top of the screen and choose your action. When you change which fields are shown, the data will reload to reflect that choice (if you have unsaved changes you will be prompted to discard them or save your changes).
Next to the \"Show/Hide fields\" dropdown is a print button. Clicking this will allow you to print all the requirements in the current page. If you are on page 2 of 3 in the documents view, you will print all of page 2's requirements only.
"},{"location":"Spira-User-Manual/Requirements-Management/#editing-the-requirements-documents","title":"Editing the requirements documents","text":"To edit the requirements on the documents view your user must have Bulk Edit permissions for requirements in that product. If you have this permission, you will see an edit icon to the far right of each requirement name. Click this to edit that requirement. You can edit the following fields:
In the screenshot below we are editing RQ:1. You can see this because of the requirement name is highlighted, and there are two icons on the far right (save and cancel), instead of the edit icon. RQ:2 is not being edited: we can see the edit icon on the far left. Look at the very top of the documents view and you see in the screenshot a helpful message showing \"Editing 1 item(s), with 0 unsaved change(s).\"
In this next screenshot, we are editing RQ:1 still, but also now RQ:2. We are currently making changes to RQ:1 (its save icon is now bigger and orange telling us it can be saved). The header message clearly tells us that we have unsaved changes on this page. This is a helpful way of tracking requirements you need to save, because if you are editing several at a time, not all will be on screen at once.
To save your changes, click the save icon. To discard your changes, click the X icon / cancel. If there was a problem saving the requirement you will see an error message explaining the issue.
"},{"location":"Spira-User-Manual/Requirements-Management/#requirements-mindmap","title":"Requirements Mindmap","text":"This mindmap displays the first 5,000 requirements in a product as a connected tree view / mindmap. The root node shows the name of the product on the left hand side. The top most level nodes are connected to the left of this, with their successive children shown from left to right.
For each requirement the map displays the name and ID of the requirement, with a tooltip that shows the description and any comments. Each node is color coded by its priority / importance value.
As well as showing the primary hierarchy, there is an option to turn on the display of requirement associations. This will let you see all of the associations as dotted lines. For associations that denote dependencies there is an arrow and dotted line that shows the direction of the dependency. For simple relationship (relates to) associations, there is a dotted line without an arrow. The system will display either the comment or type of association, depending what was entered when the association was created.
There are several other display options:
To view more information about a requirement, click its name. This will open popup with much more detail. If you ctrl/cmd+click on the requirement name it will open the full details page for that artifact. Information shown in the popup includes all standard and custom fields with fields being shown or hidden based on the workflow step that applies to that specific requirement.
You can edit requirements straight from the mindmap. Users with bulk edit permissions can edit a requirement (including adding a new comment) at any time by clicking on the requirement name. This opens a popup with full information about that requirement. At all times, which fields are shown, required, or hidden is based on the workflow step that applies to that specific requirement. To save any changes you must fill in all required fields. Please note: you cannot change the status in this edit mode, to do so open the artifact's detail page (you can do this from the popup by clicking the button next to the artifact's id at the top).
Note: only fields that users are able to edit are shown - fields that are always read only (like the creation date) are not shown in this view.
"},{"location":"Spira-User-Manual/Requirements-Management/#requirement-details","title":"Requirement Details","text":"When you click on a requirement item in the requirements list described in Requirements Management > Requirements List, you are taken to the requirement details page illustrated below:
This page is made up of three areas;
Please note that on smaller screen sizes the navigation pane is not displayed. While the navigation pane has a link to take you back to the requirements list, on mobile devices a 'back' button is shown on the left of the operations toolbar.
The navigation pane can be collapsed by clicking on the \"-\" button, or expanded by clicking anywhere on the gray title area. On desktops the user can also control the exact width of the navigation pane by dragging and dropping a red handle that appears on hovering at the rightmost edge of the navigation pane.
The navigation pane shows a list of the peer requirements to the one selected. This list is useful as a navigation shortcut; you can quickly view the coverage information of all the peer requirements by clicking on the navigation links without having to first return to the requirements list page. The navigation list can be switched between three different modes:
The bottom part of the right pane can be switched between six views: \"Overview\", \"Test Coverage\", \"Tasks\", \"Attachments\", \"History\" and \"Associations\", each of which will be described in more detail below.
"},{"location":"Spira-User-Manual/Requirements-Management/#toolbar-operations","title":"Toolbar Operations","text":"Sometimes you may want to split a requirement into two: the original requirement, and a new requirement (based off the original one). The two requirements are associated together after this process. To do this click Tools > Split. This will bring up the requirement split dialog shown below.
In this dialog you are focusing on the new requirement you are creating from performing the split. Here you can:
To complete the split click the Split button.
Notes about how requirement splitting works
New estimate:
Status:
Tasks are not moved or cloned from the original requirement to the new requirement
The Overview tab is divided into a number of different sections. Each of these can be collapsed or expanded by clicking on the title of that section. It displays the description, fields and comments associated with the requirement.
The top part of this tab displays the various standard fields and custom properties associated with the requirement. Fields (both standard and custom) are grouped under the collapsible headings (marked by orange text and underline) in the screenshot below. For instance, all fields regarding dates are grouped together in the \"Dates and Times\" area.
"},{"location":"Spira-User-Manual/Requirements-Management/#overview-detailed-information","title":"Overview -- Detailed Information","text":"The Detailed Information section contains the long, formatted description of the requirement, as well as any rich text custom fields. You can enter rich text or paste in from a word processing program or web page into these fields. Clicking on the shaded areas of one of these detailed fields will display the rich text toolbar.
"},{"location":"Spira-User-Manual/Requirements-Management/#overview-comments","title":"Overview - Comments","text":"Read about how the comments works
"},{"location":"Spira-User-Manual/Requirements-Management/#overview-scenario","title":"Overview -- Scenario","text":"If you are editing a 'Use Case' type of requirement, there will be a special 'Scenario' section where you can enter in the scenario steps that define the use case:
This section displays the various steps that a user would perform when carrying out the defined use case. The list of use case steps displays the position number, and the description. If a test case is created from this use-case, the steps will be used to create the test steps.
Clicking on the \"Insert Step\" button inserts a new step before the currently selected (by means of the check-box) step. Clicking the \"Insert Step\" button without selecting an existing step will insert a new step at the end of the list. When a new step is inserted, the fields are displayed in \"Edit\" mode, so the description, field is editable, allowing you to enter the data:
To move the steps in the list, click on the step you want to move and drag it to the location you want it moved.
"},{"location":"Spira-User-Manual/Requirements-Management/#test-coverage_1","title":"Test Coverage","text":"This tab shows the test coverage information for the requirement in question:
The tab displays a grid containing the test cases already mapped to this requirement. You can filter that list by the test case type, name, status, execution status, execution date, priority, product name and ID. You can remove an existing test case by selecting its check box and clicking the 'Delete' button. This doesn't delete the test case, just removes it from the requirement.
Hovering the mouse over the names of the test cases will display a \"tooltip\" consisting of the test case name, place in the folder structure and a detailed description.
To add a new test case to the requirement, simply click on the 'Add' button:
You can search for a test case by its ID if you know it (make sure to include the \"TC\" prefix):
Otherwise, you can search for the test cases by choosing a folder from the dropdown and/or entering a partial name match:
One you have found the desired test case(s), select their check boxes and click the 'Save' button to add them to the current requirement:
Finally, as a shortcut you can click the \"Create Test Case from This Requirement\" button to create a new test case in the list of covered test cases that will be automatically linked to this requirement. This is useful when you have created a new requirement and want to generate an initial covering test to be fleshed-out later.
"},{"location":"Spira-User-Manual/Requirements-Management/#tasks","title":"Tasks","text":"This tab shows the list of product tasks that need to be completed for the requirement to be satisfied:
Each of the tasks is displayed together with, by default, its name, description (by hovering the mouse over the name), progress, priority, start-date, current owner, estimated effort, projected effort and numeric task identifier. Clicking on the task name will bring up the Task Details page. This allows you to edit the details of an existing task.
You can perform the following actions on a task from this screen:
The system has a series of shortcuts that simplify the editing of requirements and tasks (these can be changed as required in product administration):
Read about how the attachments tab works
"},{"location":"Spira-User-Manual/Requirements-Management/#history","title":"History","text":"Read about how the history tab works
"},{"location":"Spira-User-Manual/Requirements-Management/#associations","title":"Associations","text":"You can associate other requirements, incidents, or risks to a requirement from this tab.
The associated requirements and risks are those a user has decided are relevant to the current requirement and has created a direct link between them. In the case of incidents, the association can be either due to the creator of an incident directly linking the incident to the requirement, or it can be the result of a tester executing a test-run and creating an incident during the test run. In this latter case, the check-box to the left of the association will be unavailable as the link is not editable.
Read more about how to manage and add associations to this artifact
"},{"location":"Spira-User-Manual/Requirements-Management/#use-case-diagrams","title":"Use Case Diagrams","text":"Requirements with a list of defined steps displays an extra tab called \"Diagram\". This display the list of steps as a process flow diagram rather than as a simple list.
You still write the scenario in the main Overview tab as a list of steps, however that list of steps will render as a diagram on this tab. Every step is displayed in the diagram. To make the diagram easier to read, only the first part of the step description is rendered in the diagram.
any task with a status that is not one of the following: \"Rejected\", \"Obsolete\", \"Duplicate\".\u00a0\u21a9
limited to the first 5000 requirements\u00a0\u21a9\u21a9\u21a9
This section outlines how you can use the Resource Tracking features of SpiraPlan\u00ae and SpiraTeam\u00ae to view the total workload for each of the product personnel resources assigned to a specific product. This allows you to verify that the work is evenly distributed amongst the product members and that no individual resource is overloaded.
When you click Tracking > Resources on the global navigation bar, you will initially be taken to the product resources list screen illustrated below:
This screen lists all the personnel (product resources) that belong to the current product together with the total value of the projected effort of all the work assigned to them, the available effort based on the length of the current release/sprint, and the remaining effort (the difference between the previous two values). The effort is shown for tasks and incidents as well as a total of the two together.
Using the dropdown on the far right, you can display the workload:
You can also display the workload for the entire program by selecting the program from the product/program selector from the navigation bar
There is a colored progress bar column called \"Allocation\" that graphically illustrates the % of the person's available effort that has been scheduled. If a person is over-scheduled, this bar will turn red. In addition, if any product resources have been assigned more work that they have time to complete during the length of the release/sprint, the background color of the remaining effort value will be also be colored in red, indicating that you need to offload some of the work to other product resources.
Clicking on a resource name will take you to the Resource Details page.
"},{"location":"Spira-User-Manual/Resource-Tracking/#resource-details","title":"Resource Details","text":"The resource details page will show you what artifacts a resource has been assigned, and time values for the items. A small panel on the left will show current configured values for the product for # of hours per workday, # of days per week, and how many non-work hours per month there are.
There are two options related to the instant messenger beneath the user's avatar. When you click the \"Send Message\" button it will open up a new instant message window to start a conversation with the selected resource. If the resource is not a contact of the current user, clicking the \"Add Contact\" button adds the selected resource to the user's 'My Contacts' list on the 'My Page' dashboard. Similarly if the resource is already a contact of the current user, clicking 'Remove Contact' will remove the resource as a contact.
Tabs along the bottom will show assigned requirements and tasks, incidents, test cases, test sets and recent actions. The views for each item are a subset of available columns, to show progress and completion information for all items listed. Clicking on an artifact's name will take you to the artifact details page. The data in all of these tabs can be filtered by all releases, by a release and its children, or by a specific sprint.
"},{"location":"Spira-User-Manual/Resource-Tracking/#reqs-tasks","title":"Reqs & Tasks","text":"This tab displays the list of requirements and child tasks that are assigned to the current resource:
"},{"location":"Spira-User-Manual/Resource-Tracking/#incidents","title":"Incidents","text":"This tab displays the list of incidents that are assigned to the current resource:
"},{"location":"Spira-User-Manual/Resource-Tracking/#test-cases","title":"Test Cases","text":"This tab displays the list of test cases that are assigned to the current resource:
"},{"location":"Spira-User-Manual/Resource-Tracking/#test-sets","title":"Test Sets","text":"This tab displays the list of test sets that are assigned to the current resource:
"},{"location":"Spira-User-Manual/Resource-Tracking/#actions","title":"Actions","text":"This tab displays the list of recent actions make by the user in the product. It lets you quickly see all the changes they have made:
This can be useful when auditing the changes made by a specific user.
"},{"location":"Spira-User-Manual/Risks-Management/","title":"Risks Management","text":"This section outlines the risk management features of SpiraPlan\u00ae (not available in SpiraTest or SpiraTeam) and how they can be used to help understand, track, and mitigate risks across your products. The expected principle ways of managing risks is through assigning values to each risk's probability and impact. These two fields, multiplied together, represent the potential (negative) exposure from the risk: a highly likely risk that would have a large impact has a higher exposure (and should be managed with a higher priority) than an unlikely risk which will not have much real world impact.
"},{"location":"Spira-User-Manual/Risks-Management/#risks-list","title":"Risks List","text":"When you click on the Tracking > Risks global navigation link, you will initially be taken to the risks list screen illustrated below:
The risk list screen displays all the risks entered for the current product, in a filterable, sortable grid. The grid displays the risk number together with fields such as risk type (schedule, financial, etc.), status (open, evaluated, etc.), probability, impact, and exposure (calculated from the probability and impact). The choice of columns displayed is configurable per-user, per-product, giving extensive flexibility when it comes to viewing and searching risks.
The sidebar on the left gives you quick access to saved filters, along with useful charts to get an at-a-glance view of risks for this product.
In addition, you can view a more detailed description of the risk (along with any mitigations) by positioning the mouse pointer over the incident name hyperlink and waiting for the popup \"tooltip\" to appear. If you click on the risk name hyperlink, you will be taken to the risk details page. Clicking on any of the pagination links at the bottom of the page will advance you to the next set of risks in the list according to the applied filter and sort-order. There is also a drop-down-list at the bottom of the page which allows you to specify how many rows should be displayed in each page, helping accommodate different user preferences.
"},{"location":"Spira-User-Manual/Risks-Management/#filtering-sorting","title":"Filtering & Sorting","text":"Read about how to create and manage filters, and how to sort the artifact list.
"},{"location":"Spira-User-Manual/Risks-Management/#new-risk","title":"New Risk","text":"Clicking on the \"New Risk\" button takes you to the new risk screen. This is essentially the same screen as the risk details screen except, depending on how the workflow has been configured for your product, certain fields may be disabled. For more details on setting and up configuring workflow for your product, please refer to the SpiraTest Administration Guide.
"},{"location":"Spira-User-Manual/Risks-Management/#delete","title":"Delete","text":"Clicking on the \"Delete\" button deletes the risk(s) whose check-boxes have been selected in the risk list.
"},{"location":"Spira-User-Manual/Risks-Management/#refresh","title":"Refresh","text":"Clicking on the \"Refresh\" button simply reloads the list of risks; this is useful when new risks are being added by other users, and you want to make sure you have the most up-to-date list displayed.
"},{"location":"Spira-User-Manual/Risks-Management/#show-hide-columns","title":"Show / Hide Columns","text":"This drop-down list allows you to change the fields that are displayed in the risk list as columns for the current product. To show a column that is not already displayed, select that column from the list of \"Show...\" column names and to hide an existing column, select that column from the list of \"Hide...\" column names. This is stored on a per-product basis, so you can have different display settings for each product you are a member of. The fields can be any of the built-in fields or any of the custom properties set up by the product owner.
"},{"location":"Spira-User-Manual/Risks-Management/#edit","title":"Edit","text":"Each risk in the list has an \"Edit\" button display in its right-most column. When you click this button or double-click on any of the cells in the row, you change the item from \"View\" mode to \"Edit\" mode. The various columns are made editable, and \"Save\" buttons are displayed in the last column:
If you click \"Edit\" on more than one row, the \"Save\" buttons are only displayed on the first row, and you can make changes to all the editable rows and then update the changes by clicking the one \"Save\" button. Also, if you want to make the same change to multiple rows (e.g. to change five risks from \"Resolved\" status to \"Closed\"), you can click on the \"fill\" icon to the right of the editable item, which will propagate the new value to all editable items in the same column.
If you want to edit lots of items, first select their checkboxes and then click the \"Edit\" button on the same row as the Filters and it will switch all the selected items into edit mode.
When you have made your updates, you can either click \"Save\" to commit the changes, or \"Cancel\" to revert back to the original information. Alternatively, pressing the <ENTER> key will commit the changes and pressing the <ESCAPE> key will cancel the changes.
"},{"location":"Spira-User-Manual/Risks-Management/#cloning-risks","title":"Cloning Risks","text":"To create a clone of an existing risk or set of risks, select the check-boxes of the risks you want to copy and then click Edit then \"Clone\". You can also clone a rsiks from its detailed view (using the dropdown next to the \"New\" button). Cloning a risk makes a copy of the selected risk with '... - Copy' added at the end of its name. When cloning risks note that:
Read about how to export artifacts from one product to another.
"},{"location":"Spira-User-Manual/Risks-Management/#printing-items","title":"Printing Items","text":"To quickly print a single risk or list of risks you can select the items' checkboxes and then click Tools > Print Items. This will display a popup window containing a printable version of the selected items. You can also save the report in a variety of common formats from the same Tools menu.
"},{"location":"Spira-User-Manual/Risks-Management/#risk-details","title":"Risk Details","text":"When you click on a risk item in the risks list, you are taken to the risk details page illustrated below:
This page is made up of three areas;
Please note that on smaller screen sizes the navigation pane is not displayed. While the navigation pane has a link to take you back to the risks list, on mobile devices a 'back' button is shown on the left of the operations toolbar.
The navigation pane can be collapsed by clicking on the \"-\" button, or expanded by clicking anywhere on the gray title area. On desktops the user can also control the exact width of the navigation pane by dragging and dropping a red handle that appears on hovering at the rightmost edge of the navigation pane.
The navigation pane shows a list of the peer risks to the one selected. This list is useful as a navigation shortcut; you can quickly view the coverage information of all the peer risks by clicking on the navigation links without having to first return to the risks list page. The navigation list can be switched between three different modes:
The bottom part of the right pane can be switched between four views: \"Overview\", \"Tasks\", \"Attachments\", \"History\", each of which will be described in more detail below.
"},{"location":"Spira-User-Manual/Risks-Management/#emailing","title":"Emailing","text":"Read about emailing a document to colleagues using Spira.
"},{"location":"Spira-User-Manual/Risks-Management/#followers","title":"Followers","text":"Read about how to add and manage followers to an artifact.
"},{"location":"Spira-User-Manual/Risks-Management/#workflows","title":"Workflows","text":"Read about using workflows to change the status of your artifact.
"},{"location":"Spira-User-Manual/Risks-Management/#overview-details","title":"Overview - Details","text":"The Overview tab is divided into a number of different sections. Each of these can be collapsed or expanded by clicking on the title of that section. It displays the description, fields and comments associated with the risk.
The top part of this tab displays the various standard fields and custom properties associated with the risk. Fields (both standard and custom) are grouped under the collapsible headings (marked by orange text and underline) in the screenshot below. For instance, all fields regarding dates are grouped together in the \"Dates and Times\" area.
"},{"location":"Spira-User-Manual/Risks-Management/#overview-detailed-information","title":"Overview -- Detailed Information","text":"The Detailed Information section contains the long, formatted description of the risk, as well as any rich text custom fields. You can enter rich text or paste in from a word processing program or web page into these fields. Clicking on the shaded areas of one of these detailed fields will display the rich text toolbar.
"},{"location":"Spira-User-Manual/Risks-Management/#overview-mitigations","title":"Overview -- Mitigations","text":"The mitigations section is where you can enter information about any plans or ideas about how the risk in question can be mitigated, in other words how its impact or probability can and/or will be lowered. The list of mitigations displays the position number, and the description, and date fields.
Clicking on the \"Add\" button inserts a new mitigation before the currently selected (by means of the check-box) step. Clicking the \"Add\" button without selecting an existing step will insert a new mitigation at the end of the list. When a new mitigation is inserted, its fields are displayed in \"Edit\" mode, so the description and review date fields are editable, allowing you to enter the data:
To move the mitigations around in the list, click and hold on the mitigation you want to move and drag it to the location desired.
If at least one mitigation is selected (using the checkboxes on the left-hand side), then clicking \"Clone\" will clone those mitigations and add them to the bottom of the list.
"},{"location":"Spira-User-Manual/Risks-Management/#overview-comments","title":"Overview - Comments","text":"Read about how the comments works
"},{"location":"Spira-User-Manual/Risks-Management/#tasks","title":"Tasks","text":"This tab shows the list of product tasks that need to be completed for the risk to be properly managed/mitigated:
Each of the tasks is displayed together with, by default, its name, description (by hovering the mouse over the name), progress, priority, start-date, current owner, estimated effort, projected effort and numeric task identifier. Clicking on the task name will bring up the Task Details page. This allows you to edit the details of an existing task.
You can perform the following actions on a task from this screen:
Note that if you create a new task on the risks page, the component, release/sprint, and owner are automatically copied from the parent risk. You can change these suggested values before clicking \"Save\"
"},{"location":"Spira-User-Manual/Risks-Management/#attachments","title":"Attachments","text":"Read about how the attachments tab works
"},{"location":"Spira-User-Manual/Risks-Management/#associations","title":"Associations","text":"You can associate other risks, incidents, test cases, and requirements to a risk from this tab. Read more about how to manage and add associations to this artifact
Read about how the history tab works
"},{"location":"Spira-User-Manual/Source-Code/","title":"Source Code","text":""},{"location":"Spira-User-Manual/Source-Code/#introduction","title":"Introduction","text":"SpiraTeam\u00ae's and SpiraPlan\u00ae's source code integration features let you:
SpiraPlan integrates with many different source code / Software Configuration Management (SCM). You can connect SpiraPlan and your source code using Inflectra's cloud-hosted TaraVault or plugins for the different SCM's (including Git and Subversion). If you want to learn more about using a source code provider, read our intro guides to using Git and using Subversion.
This section outlines SpiraPlan's source code features, whatever type of source code provider you are using. The Commit section outlines viewing and working with commits and the changes made in them.
"},{"location":"Spira-User-Manual/Source-Code/#getting-started-with-source-code","title":"Getting Started With Source Code","text":"To use the source code features in SpiraPlan you need to do 3 things:
Once these steps are complete, the source code will be viewable within SpiraPlan. The rest of this section assumes these steps have all been taken.
"},{"location":"Spira-User-Manual/Source-Code/#troubleshooting-source-code-integration","title":"Troubleshooting Source Code Integration","text":"Integration with a source code provider can sometimes not work as you expect:
When you click on Developing > Source Code on the global navigation bar, you will be taken to the source code repository file list screen. This shows you all file in the current folder and the current branch. You can change the branch, sort and filter this list, or browse the different pages of files (up to 500 files can be displayed on the page at any one time).
Deleted Files
Once a file has been deleted you will no longer be able to view that file from the list of files, or view information about that file. There is a current limitation that means the commit where a file was deleted is not able to show this file deletion.
This screen consists of two sections:
Above the list of files is the action toolbar. This lets you perform the following functions:
For each file you can see the following information (you can sort or filter on all of these):
When you click on a file link (for example, from the source code file list), you open the file details page for that file. This page shows you information about the file, its commit history, and where relevant a file preview. It also shows you links to other relevant files, commits, or artifacts.
The page is made up of three areas:
The detailed information available at the top of the page is:
There are 3 tabs on this page that each show additional information about the file. These are discussed below.
"},{"location":"Spira-User-Manual/Source-Code/#preview","title":"Preview","text":"This shows, where possible, a preview of the file. Image files are previewed, as are text files (for example, code), and markdown files (as HTML rendered previews). For code, syntax highlighting is applied based on the code file type (using the file extension) and line numbers are also shown.
Note that if you save a file with an incorrect extension (e.g. using .txt for a JavaScript file) it may not display the correct color-coding.
"},{"location":"Spira-User-Manual/Source-Code/#history","title":"History","text":"This shows the full commit history for that file in the current branch. The list of commits is paginated and up to 500 rows of commits can be shown at one time. You can also filter this list of commits.
Each commit is displayed with:
This shows all current associations between this file and any artifacts in SpiraPlan. This lets you to see which requirements, test cases, incidents, tasks, etc. are linked to the file. Clicking on the artifact name will take you to the appropriate artifact page (assuming your user has permissions to access that information).
You can also add artifact associations to many other artifacts in the system from this panel. Read more about how to manage and add associations to this artifact.
"},{"location":"Spira-User-Manual/Source-Code/#source-code-revision-list","title":"Source Code Revision List","text":"Updated documentation is here.
"},{"location":"Spira-User-Manual/Source-Code/#source-code-revision-details","title":"Source Code Revision Details","text":"Updated documentation is here.
Some older source code management systems (e.g. CVS, Visual SourceSafe) do not have the formal concept of branches, so the dropdown list will simply list the one main branch (usually called \"Trunk\").\u00a0\u21a9
Task Tracking in SpiraPlan\u00ae and SpiraPlan\u00ae lets you view and manage tasks assigned to each person in the product. Each task can be assigned to an individual user and linked to a particular release or sprint. Product managers can track the the progress of tasks to see if the product is on schedule.
Tasks can be organized into different folders and categorized by different types (development, testing, infrastructure, etc.), each of which can have its own workflow which defines the way the task can change status during the product lifecycle.
Tasks can be used in a number of different parts of the system to manage and track work:
When you click on the Tracking > Tasks global navigation link, you will initially be taken to the tasks list screen illustrated below:
The task list screen displays all the tasks entered for the current product by folder, in a filterable, sortable grid. The grid displays the task number together with fields such as priority, name, assigned owner, start date, end date, scheduled release, etc. The choice of columns displayed is configurable per-user, per-product, giving extensive flexibility when it comes to viewing and searching tasks.
In addition, you can view a more detailed description of the task by positioning the mouse pointer over the task name hyperlink and waiting for the popup \"tooltip\" to appear. If you click on the task name hyperlink, you will be taken to the task details page Clicking on any of the pagination links at the bottom of the page will advance you to the next set of tasks in the list according to the applied filter and sort-order. There is also a drop-down-list at the bottom of the page which allows you to specify how many rows should be displayed in each page, helping accommodate different user preferences.
"},{"location":"Spira-User-Manual/Task-Tracking/#task-progress","title":"Task Progress","text":"One special column that is unique to tasks is the 'progress indicator'. This illustrates graphically both the percentage completion of the task and also if the task is either starting late or finishing late. The following table illustrates the different type of status that can be conveyed by the indicator:
Indicator Display Progress Description Task has not yet started, but the scheduled start date is still in the future. Task has not yet started, and the start date has elapsed. This is considered a 'Late Starting Task' Task has started, and is approximately 25% complete. The scheduled end date is still in the future. Task has started, and is approximately 50% complete. However the scheduled end date has elapsed already. This is a considered a 'Late Finishing Task'. Task has been 100% completed.Essentially, the gray section of the bar indicates the % of the task yet to be completed, and the green/red section of the bar indicates the % of the task that has already been completed. If the bar changes from green to red it means that the end date has been reached and the task is not yet complete, and if the background changes from gray to yellow it means that the task has not yet started, but the scheduled start date has passed.
"},{"location":"Spira-User-Manual/Task-Tracking/#task-folders","title":"Task Folders","text":"SpiraPlan lets you group product tasks into different folders to make organization easier. In the left-hand Quick Filters panel, the system displays the various task folders defined in the product:
If you are a product administrator, you will see the 'Edit' and 'Add' buttons beneath the folder tree, this lets you add, edit and delete task folders in the product. To add a new folder, click the 'Add' button:
Choose the parent folder that you want to add the new folder under (or None if you are adding a new top-level folder) from the dropdown list and then enter the name of the new folder. Then click 'Add' to save the new folder.
To edit or delete an existing folder, simply click the \"Edit\" button to switch the folder tree to edit mode. To edit or delete a specific folder, click on the \"Edit\" button next to the folder:
You can change the parent folder and/or name of the folder and click \"Update\" to commit the change or click \"Delete\" to delete the folder entirely.
To move a task / tasks between folders, click and drag the relevant task/tasks from the table on the right, and drag them over the desired folder in the tree view on the left. The destination folder will be highlighted to show where the task will be placed.1
"},{"location":"Spira-User-Manual/Task-Tracking/#actions","title":"Actions","text":"Cloning Tasks: To create a clone of a task, a set of tasks, or a folder of tasks, select the check-boxes of the tasks you want to clone and then click \"Clone\". This will make a clone of the current task in the current folder with its name changed to add \" - Copy\" added to the end, to distinguish itself from the original. When cloning a folder of tasks, only the folder name gets changed. When cloning tasks note that:
all standard fields (like status and owner) are cloned
{: #duplicating-tasks} - Exporting Tasks to Another Product: Read about how to export artifacts from one product to another. {: #exporting-tasks-to-another-product} - Printing and Saving Items: To quickly print a single task, a list of tasks, or a folder of tasks you can select the items' checkboxes and then click Tools > Print Items. This will display a popup window containing a printable version of the selected items. You can also save the report in a variety of common formats from the same Tools menu.
"},{"location":"Spira-User-Manual/Task-Tracking/#edit","title":"Edit","text":"Each task in the list has an \"Edit\" button display in its right-most column. When you click this button or just click on any of the cells in the row, you change the item from \"View\" mode to \"Edit\" mode. The various columns are made editable, and \"Save\" buttons are displayed in the last column:
If you click \"Edit\" on more than one row, the \"Save\" buttons are only displayed on the first row, and you can make changes to all the editable rows and then update the changes by clicking the one \"Save\" button. Also, if you want to make the same change to multiple rows (e.g. to change five tasks from \"Not Started\" status to \"In Progress\"), you can click on the \"fill\" icon to the right of the editable item, which will propagate the new value to all editable items in the same column.
If you want to edit lots of items, first select their checkboxes and then click the \"Edit\" button on the same row as the Filters and it will switch all the selected items into edit mode.
When you have made your updates, you can either click \"Save\" to commit the changes, or \"Cancel\" to revert back to the original information. Alternatively, pressing the <ENTER> key will commit the changes and pressing the <ESCAPE> key will cancel the changes.
"},{"location":"Spira-User-Manual/Task-Tracking/#task-additional-list-views","title":"Task Additional List Views","text":"There are two additional task list views. These views are:
You can pick between each of these views using the view selection button group at the top right of any requirement list page.
"},{"location":"Spira-User-Manual/Task-Tracking/#task-board","title":"Task Board","text":"The task board is an alternative to the task list page designed to let you view the tasks planned for the current product. You can access this feature by clicking on the Board icon in the top-right of the Tasks list page. You can switch back to the Task list page by clicking on the Table view.
The task board has the following different display modes:
All Releases
Release
Sprint
Each of these views is described below.
Planning Boards and Editing
Moving cards: Please note that the purpose of a planning board or Kanban board, is to make it straightforward for users to move cards around the interface to plan out their work. Therefore we do not enforce workflow restrictions on the planning board when moving cards. Therefore only users with permissions to bulk edit the relevant artifact can move cards. If the template admin has prevented status changes while bulk editing, then noone can change a card's status by moving its card on the planning.
Viewing cards: to view more information about the card you can: turn on Detailed View; hover on the card name to see a rich tooltip; click on the card's id to open a popup with much more detail; or ctrl/cmd+click on the card's id to open the full details page for that artifact. Information shown in the popup includes all standard and custom fields with fields being shown or hidden based on the workflow step that applies to that specific card.
Editing cards: users with bulk edit permissions can edit a planning board card at any time by click on the card's id (including adding a new comment). This opens a popup with full information about that card. At all times, which fields are shown, required, or hidden is based on the workflow step that applies to that specific card. To save any changes you must fill in all required fields. Please note: you cannot change the status in this edit mode, to do so open the artifact's detail page (you cand do this from the popup by clicking the button next to the artifact's id at the top).
Add new cards: if you are able to create the requirements then you will see plus (add) symbols in different locations on the board. Clicking any of these will open an popup screen with all relevant fields available. Some of these fields may be prepopulated based on what add button you clicked and how you are using the board. For instance, if you are viewing for a release, that release will be preselected. And if you are grouping by person and click on a particular person, that person will be set as the owner of the artifact. The fields visible and required is driven based on what workflow step will apply to that new card.
"},{"location":"Spira-User-Manual/Task-Tracking/#tasks-by-priority","title":"Tasks -- By Priority","text":"This view is designed to let you see the list of planned tasks organized by priority. Each of the possible priority values is displayed on the left-hand side and the tasks displayed in the same row on the right:
The top section will contain the list of tasks that are not assigned a priority, with the other sections containing the tasks that have been assigned to the specific priority.
"},{"location":"Spira-User-Manual/Task-Tracking/#tasks-by-status","title":"Tasks -- By Status","text":"This view is designed to let you see the tasks in the current product / release / sprint organized by their status. Each task status (not started, in progress, completed, blocked, deferred) is displayed as a heading, with the tasks displayed in the same column underneath:
You can click on the expand/collapse icons to hide any resources that are not relevant.
Depending on the view (all releases, release, or sprint), there may be sections with the release and sprint name. You can drag and drop the tasks between statuses or to/from the release/sprint backlog. Any tasks not assigned to a release/sprint will be listed in the (Unassigned Items) section at the top.
"},{"location":"Spira-User-Manual/Task-Tracking/#tasks-by-person","title":"Tasks - By Person","text":"This view is designed to let you see the tasks in the current product / release / sprint organized by resource / person. Each of the users that is a member of the current product is displayed as a heading, with the tasks displayed in the same column underneath. This view is often called the Task Board:
You can click on the expand/collapse icons to hide any resources that are not relevant. The system will display a progress bar for each resource to illustrate the allocation for that resource. Any resource that has a progress bar that is completely green has been fully scheduled and should not have any additional tasks assigned. If the progress bar for that resource turns red, it means that they have been over-scheduled and you need to reassign some of the tasks.
Depending on the view (all releases, release, or sprint), there may be sections with the release and sprint name; they contain tasks that are scheduled for the current release or sprint but have not yet been assigned to a resource. You can drag and drop the tasks between resources or to/from the release/sprint backlog (as long as the item has a status that let's you set or edit its owner field). Any tasks not assigned to a resource and release/sprint will be listed in the (Unassigned Items) section at the top.
"},{"location":"Spira-User-Manual/Task-Tracking/#tasks-by-release","title":"Tasks - By Release","text":"This view is only available when you are displaying the task board for 'all releases'. Each of the active releases defined for the current product is displayed as a heading, with the tasks displayed in the same column underneath
You can drag and drop the tasks between the different releases. Once the task has been added to the release, the utilized effort for the release will increase, and the available effort will decrease by the same amount.
Note: The system will allow you to assign more tasks to a release than it is possible to complete, however this will result in a negative value for 'available effort'. If this happens, the \"Available Effort\" value will be displayed in red, and you need to rebalance the items, extend the release length or add product personnel resources to the release.
Clicking on the release hyperlinks in the headers will switch the task board into the release view.
"},{"location":"Spira-User-Manual/Task-Tracking/#tasks-by-sprint","title":"Tasks - By Sprint","text":"This view is only available when you are displaying the task board for a specific release. Each of the sprints defined for the current release is displayed as a heading, with the tasks displayed in the same column underneath. This view is commonly used in Scrum products:
You can drag and drop the tasks between the different sprints. Once the task has been added to the sprint, the utilized effort for the sprint will increase, and the available effort will decrease by the same amount.
Note: The system will allow you to assign more tasks to a sprint than it is possible to complete, however this will result in a negative value for 'available effort'. If this happens, the \"Available Effort\" value will be displayed in red, and you need to rebalance the items, extend the sprint length or add product personnel resources to the sprint.
Clicking on the sprint hyperlinks in the headers will switch the task board into the sprint view.
"},{"location":"Spira-User-Manual/Task-Tracking/#tasks-by-requirement","title":"Tasks - By Requirement","text":"This option is only available when you are displaying the task board for a specific release or sprint.
In this case, the left hand side displays the requirements currently assigned to the current release / sprint, and the right hand column contains the tasks (in a card format) that are associated with that specific requirement, complete with color-coded progress bars. This view lets you quickly see all of the current user stories being worked, and the progress of completing the related tasks, in a single unified view.
"},{"location":"Spira-User-Manual/Task-Tracking/#beta-task-board","title":"Beta task board","text":"In beta, available in SpiraTeam and SpiraPlan
System admins can enable beta functionality across the application for their users from the System Admin > General Settings page.
To learn more about how the task board is structured or how to enter the beta please refer to our general information about the beta boards.
"},{"location":"Spira-User-Manual/Task-Tracking/#views-summary","title":"Views summary","text":"Details about what combinations of views is possible and how each feature works is discussed in detail the sections below. For ease of reference, here is a summary of the different options available (you cannot select the same value for multiple view options at the same time):
Releases can display \"all releases\" or a specific releases. The dropdown shows all open releases and sprints.
View options All releases A specific release or sprint Grouping Priority Release Status Type Person Team ... and Requirement Columns Priority Release Status Type Person ... and Requirement Rows Priority Release Status Type Person ... and Requirement"},{"location":"Spira-User-Manual/Task-Tracking/#view-controls","title":"View controls","text":"The release dropdown shows:
Read about how grouping works.
Read about how to use columns.
Read about how to use rows.
Read about what cards show when.
"},{"location":"Spira-User-Manual/Task-Tracking/#customizing-the-cards","title":"Customizing the cards","text":"You can customize what information is shown on each card. For each artifact the following fields are always shown:
You can toggle whether to show each of the following features:
Below is an example of a task card showing all available data
"},{"location":"Spira-User-Manual/Task-Tracking/#moving-and-ordering-cards","title":"Moving and ordering cards","text":"Read about this here.
"},{"location":"Spira-User-Manual/Task-Tracking/#editing-and-viewing-cards","title":"Editing and viewing cards","text":"Read about this here.
"},{"location":"Spira-User-Manual/Task-Tracking/#viewing-by-release-or-sprint","title":"Viewing by release or sprint","text":"Read about this here.
"},{"location":"Spira-User-Manual/Task-Tracking/#viewing-by-person","title":"Viewing by Person","text":"Read about this here.
"},{"location":"Spira-User-Manual/Task-Tracking/#task-gantt-chart","title":"Task Gantt Chart","text":"This displays all active releases and sprints2 nested in the same hierarchy as on the main release list page (releases or sprints without any tasks are also shown). It also displays any task that are assigned to one of these releases.
Any release that has active children or open tasks has an expand / collapse toggle to the left of its name. This will show the child releases and/or the assigned tasks
To the right of the names is the timeline bar, which graphically shows the length of each release (blue) and task (green) between their start and end dates in individual horizontal bars. The names of the releases and tasks on the left or in the horizontal bars are clickable and will open the specific release or task.
Part of a release or task may be shaded darker than normal, from its left - this is based on how complete the release or task is.
Above the Gantt chart is a toolbar that lets you:
Add button to add a new dispaly a popup to fill in information about the new task. The new task's release is filled in if you select a release on the Gantt chart, or otherwise by the release you are filtering the page on (see below). Click Add Task to add the task into the product.To view more information about a release or task, click its name from the left hand sidebar or in the relevant Gantt bar. This will open popup with much more detail. If you ctrl/cmd+click on the artifact's name it will open the full details page for that artifact. Information shown in the popup includes all standard and custom fields. These fields are visible or hidden based on the workflow step that applies to that specific release or to that specific task.
You can edit releases and tasks straight from the Gantt chart. Users with bulk edit permissions for releases or tasks can edit each respective artifact (including adding a new comment) at any time by clicking on the artifact name. This opens a popup with full information about that artifact. At all times, which fields are shown, required, or hidden is based on the workflow step that applies to that specific artifact. To save any changes you must fill in all required fields. Please note: you cannot change the status in this edit mode, to do so open the artifact's detail page (you can do this from the popup by clicking the button next to the artifact's id at the top).
Note: only fields that users are able to edit are shown - fields that are always read only (like the creation date) are not shown in this view.
"},{"location":"Spira-User-Manual/Task-Tracking/#task-details","title":"Task Details","text":"When you click on a task item in the lists displayed on either the main task list page or on the requirement / release details pages, you are taken to the task details page illustrated below:
This page is made up of three areas;
the left pane displays the tasks list navigation;
the right pane's header, which displays: the operations toolbar; the folder the task is in; the editable name of the selected task; and the info bar (with a shaded background), which also contains the workflow status transitions (see below); and
the right pane's tabbed interface with rich information related to the task.
Please note that on smaller screen sizes the navigation pane is not displayed. While the navigation pane has a link to take you back to the tasks list, on mobile devices a 'back' button is shown on the left of the operations toolbar.
The navigation pane can be collapsed by clicking on the \"-\" button, or expanded by clicking anywhere on the gray title area. On desktops the user can also control the exact width of the navigation pane by dragging and dropping a red handle that appears on hovering at the rightmost edge of the navigation pane.
The navigation pane consists of a link that will take you back to the task list, as well as a list of tasks, and another list of the other related tasks, nested under their parent task. This latter list is useful as a navigation shortcut; you can quickly view the peer tasks by clicking on the navigation links without having to first return to the tasks list pages. The navigation list can be switched between five different modes:
Current Filter - The list of tasks matching the current filter organized by task folder
All Items - The list of all tasks, irrespective of the current filter, organized by task folder
Assigned - The list of tasks assigned to the current user grouped by their parent requirement
For Release - The list of tasks assigned to the current release or sprint, grouped under that parent release/sprint.
For Requirement -- The list of tasks associated to the same requirement as the current task as well as other tasks at the same level in the requirement hierarchy.
The lower part of the right pane can be in one of four possible tabs that can be selected: \"Overview Properties\", \"Attachments\", \"History\" and \"Associations\". Each of the different views is described separately below.
"},{"location":"Spira-User-Manual/Task-Tracking/#toolbar-operations","title":"Toolbar Operations","text":"Sometimes you may want to split a task into two: the original task, and a new task (based off the original one). The two tasks are associated together after this process. To do this click Tools > Split. This will bring up the task split dialog shown below.
In this dialog you are focusing on the new task you are creating from performing the split. Here you can:
To complete the split click the Split button.
Notes about how the split works:
The Overview tab is divided into a number of different sections. Each of these can be collapsed or expanded by clicking on the title of that section. It displays the description, fields and comments associated with the task.
The top part of this tab displays the various standard fields and custom properties associated with the task. Fields (both standard and custom) are grouped under the collapsible headings (marked by orange text and underline) in the screenshot below. For instance, all fields regarding dates are grouped together in the \"Dates and Times\" area.
"},{"location":"Spira-User-Manual/Task-Tracking/#effort-fields","title":"Effort Fields","text":"You can enter/edit the start-date, end-date (i.e. the due-date), estimated, actual and remaining effort. From this the system will calculate the progress, percentage complete and projected final effort.
The different effort values mean the following:
Note: If the actual effort is not specified, the projected effort will be the same as the estimated effort.
Note: if the task is currently assigned to a release or sprint, the start-date and end-date of the task must lie within the date-range of the parent release/sprint. If your task looks like it will not be completed in the available timeframe, you will need to contact the product manager to get them to either extend the date-range of the task, or consider moving the task to the next sprint.
"},{"location":"Spira-User-Manual/Task-Tracking/#followers_1","title":"Followers","text":"Using the \"Subscribe\" button on the toolbar, you can quickly follow the item, and receive updates on certain changes to it. Depending on your role, you may also see a dropdown to this button, which let's you add another product member as a follower to this item.
You can also quickly see who is following an incident under the \"People\" section in the Overview tab.
To view information about the follower, or to unfollow them from the item, hover over their avatar to display a user profile card.
"},{"location":"Spira-User-Manual/Task-Tracking/#component","title":"Component","text":"For tasks, the component field works differently than it does normal as with other artifacts. The component field for a task is disabled and is derived from the component of any requirement that the task is associated with. If the task has no requirement associated with it, then the task's component field will be empty.
"},{"location":"Spira-User-Manual/Task-Tracking/#overview-comments","title":"Overview -- Comments","text":"Read about how the comments works
"},{"location":"Spira-User-Manual/Task-Tracking/#attachments","title":"Attachments","text":"Read about how the attachments tab works
"},{"location":"Spira-User-Manual/Task-Tracking/#associations","title":"Associations","text":"You can associate other tasks and to a task from this tab. Read more about how to manage and add associations to this artifact
"},{"location":"Spira-User-Manual/Task-Tracking/#commits","title":"Commits","text":"Tasks that are pull requests will show the commits tab. Read more about the commits tab.
"},{"location":"Spira-User-Manual/Task-Tracking/#history","title":"History","text":"Read about how the history tab works
"},{"location":"Spira-User-Manual/Task-Tracking/#creating-an-incident-from-a-task","title":"Creating an Incident from a Task","text":"Sometimes you may have a task logged to, say, fix something before release, that now needs to be converted into an Incident (because it won't be able to get fixed before release). This workflow is useful because Incidents usually are more public facing, and have more process around them than tasks. There is a shortcut to create a new incident from the current task; and it automatically creates an association between the new incident and the task (and if the task is linked to a requirement an association is added between that requirement and the new incident too).3
To use this feature:
Add buttonCreate Incident from this Task button when navigating to folders (for all artifacts that support them), the URL in your browser's address bar will change. Each folder has a unique, sharable URL that you can give to someone to display the list of artifacts with the appropriate folder selected. You can also open up multiple folders in different browser tabs and easily toggle between them from the same browser.\u00a0\u21a9
any release / sprint / phase with a status that is not \"Closed\", \"Deferred\", or \"Cancelled\".\u00a0\u21a9\u21a9
To create an incident from a task, the user needs must have the permission to create incidents (which makes sense).
The creation process does not enforce the relevant incident workflow to make sure that all required fields are filled in.
What gets copied over from the task to the new incident:
\u21a9
This section outlines how the use-case / test-case management features of SpiraPlan\u00ae can be used to develop the business use-cases for the system, which specify how the different pieces of functionality are expected to work in practice. In addition, these use/test-cases form the basis of the business specification of the system when associated with the underlying requirements matrix. Typically when starting a new product:
However when migrating existing products into SpiraPlan\u00ae, you may need to migrate the test-case list first, and then add the supporting requirements matrix afterwards.
"},{"location":"Spira-User-Manual/Test-Case-Management/#test-case-list","title":"Test Case List","text":"When you click on the Testing > Test Cases link on the global navigation bar, you will initially be taken to the test case list screen illustrated below:
The test case list consists of a hierarchical arrangement of the various test folders and test cases. The structure is very similar to the folder structure in Microsoft Windows\u00ae Explorer, and users will find this very familiar and intuitive to use. A folder tree is on the left hand side---with triangle icons to expand / collapse each folder. Contents of the selected folder (the one marked in bold on the folder tree) are shown on the right hand side.
When you create a new product, this list will initially be empty, and you will have to use the \"New Test Case\" button to start adding test cases to the system. A new product will also not have any test folders---only the base \"Root\" folder will be visible. To add a test folder, you click the \"Add' button at the bottom of the folder tree on the left.
The list shows all test folders (shown with a folder icon), and test cases (shown with a document icon) inside the currently selected folder. You can place test folders and test cases into test folders.2 All of the items in the list have a name, together with the most recent execution status (passed, failed or not-run), and owner, author, execution date, active flag and test case number. Clicking on a test case's hyperlink will take you to the test case details page for the item in question.
It is important to understand that only test cases are assigned a status themselves; the test folders instead display a test execution bar graph that illustrates the aggregate execution status of its child test-cases. Thus, if the test folder contains two test cases, one of which passed, and one of which wasn't run, the graph will display 50% green and 50% gray.
To determine the exact aggregate test folder execution status information, position the mouse pointer over the bar-chart, and the number of tests in each of the execution statuses (passed, failed, not-run, blocked, caution) will be displayed as a \"tooltip\". Note that if you change the owner of a test folder, then all the child test cases will be assigned the same owner. This allows you to more easily associate entire folders to test cases to be executed by a specific user.
"},{"location":"Spira-User-Manual/Test-Case-Management/#add-a-test-case","title":"Add a Test Case","text":"Click the \"New Test Case\" button will add a test case in the currently displayed folder (ie the one marked in bolder on the folder tree and also shown in the yellow information box). The new test case will be added at the bottom of the list.
Once the new test case has been inserted, the item is switched to \"Edit\" mode so that you can rename the default name and choose an owner and/or author. Note that all new test cases are initially set with an execution status of \"Not Run\".
"},{"location":"Spira-User-Manual/Test-Case-Management/#delete","title":"Delete","text":"Clicking on the \"Delete\" button deletes all the test cases and/or test folders whose check-boxes have been selected. If any of the items are test folders, then the entire contents of that folder will also be deleted (as you would expect in Microsoft Windows\u00ae Explorer or OS X Finder).
"},{"location":"Spira-User-Manual/Test-Case-Management/#execute","title":"Execute","text":"Clicking on the \"Execute Tests\" button (accessed from the \"Tools\" menu or context menu) executes all the test cases selected, together with all the test cases contained with any selected test folders. The test execution functionality of SpiraPlan\u00ae is explained in more detail in Test Step Details. NOTE: if the product does not allow you to execute test cases this button will not be available.
"},{"location":"Spira-User-Manual/Test-Case-Management/#refresh","title":"Refresh","text":"Clicking on the \"Refresh\" button simply reloads the test case list. This is useful as other people may be modifying the list of test cases at the same time as you, or executing specific test cases, and after stepping away from the computer for a short-time, you can click this button to make sure you are viewing the most current test case list for the product.
"},{"location":"Spira-User-Manual/Test-Case-Management/#editing-a-test-case","title":"Editing a Test Case","text":"Each test case in the list has an \"Edit\" button in its right-most column. When you click this button (or double-click on any of the cells in the row), you change the item from \"View\" mode to \"Edit\" mode. The various columns are made editable, and \"Update\" buttons are displayed in the last column:
If you click \"Edit\" on more than one row, the \"Update\" buttons are only displayed on the first row, and you can make changes to all the editable rows and then update the changes by clicking the one \"Update\" button. Also, if you want to make the same change to multiple rows (e.g. to change the owner of five test cases from \"Fred Bloggs\" to \"Joe Smith\"), you can click on the \"fill\" icon to the right of the editable item, which will propagate the new value to all editable items in the same column.
If you want to edit lots of items, first select their checkboxes and then click the \"Edit\" button on the same row as the Filters (ie the topmost edit button) and it will switch all the selected items into edit mode.
When you have made your updates, you can either click \"Update\" to commit the changes, or \"Cancel\" to revert back to the original information. Alternatively, pressing the <ENTER> key will commit the changes and pressing the <ESCAPE> key will cancel the changes.
"},{"location":"Spira-User-Manual/Test-Case-Management/#editing-a-test-folder","title":"Editing a Test Folder","text":"Test folders shown on the right hand list pane do not have an \"Edit\" button. To edit a test folder, first click the \"Edit\" button at the bottom of the left hand folder tree. This will place the whole folder tree into edit mode---each folder will get a small \"Edit\" button of its own.
Clicking on the \"Edit\" button of the folder you want to edit will display a pop up dialog. This allows you to: move the folder into a new or different parent folder; edit the name of the folder; or add a more detailed description. Click \"Update\" to commit the changes, \"Cancel\" to revert back to the original information, or \"Delete\" to delete the folder (and all of its contents). Note that on clicking \"Delete\" a warning box will appear to make sure you don't accidentally delete something.
"},{"location":"Spira-User-Manual/Test-Case-Management/#show-hide-columns","title":"Show / Hide Columns","text":"This drop-down list allows you to change the fields that are displayed in the test case list as columns for the current product. To show a column that is not already displayed, simply select that column from the list of \"Show...\" column names and to hide an existing column, simply select that column from the list of \"Hide...\" column names. This is stored on a per-product basis, so you can have different display settings for each product that you are a member of. The fields can be any of the built-in fields or any of the custom properties set up by the product owner.
Note: If you hide the 'execution status' column, the test case folders will no longer show the count of test cases contained within the folder.
"},{"location":"Spira-User-Manual/Test-Case-Management/#filtering-sorting","title":"Filtering & Sorting","text":"Read about how to create and manage filters, and how to sort the artifact list.
"},{"location":"Spira-User-Manual/Test-Case-Management/#viewing-the-test-status-for-a-release","title":"Viewing the Test Status for a Release","text":"By default, when you view the list of test cases, it will display an aggregate status for all releases of the product. I.e. the test list will include all the test cases in the system (regardless of which release they apply to) and the execution status will reflect the most recent test run -- regardless of which release it was for.
To change the test case list to just display test cases and execution status for a particular release, change the release selected in the drop-down list located in the top-right from \"All Releases\" to a specific release:
As illustrated in the example above, when the drop-down list is changed to select a specific release, the list of test cases is filtered to just those mapped to the release in question. In addition, the execution status for the test cases will only reflect test runs for that specific release (and any child sprints if applicable). As can be seen in our example, many test cases that have been run for other releases now show the \"Not Run\" status since they've not been run for this specific release.
As a shortcut, when you select a specific release for viewing, subsequent execution of any of the test cases via the Tools > Execute Tests menu option will default the test run to the selected release.
"},{"location":"Spira-User-Manual/Test-Case-Management/#copying-test-cases","title":"Copying Test Cases","text":"To copy one or more test cases, select the check-boxes of the test cases (or test case folder) you want to copy and then select Edit > Copy Items from the menu. This will copy the current test case / test case folder selection to the clipboard. Then select the place you want the test cases to be inserted and choose the Edit > Paste Items option.
The test cases will now be copied to the destination you specified. The name of the copied test cases will have \" - Copy\" added to the end to distinguish them from the originals. If you are copying test case folders, only the top level folders' name(s) will will have \" - Copy\" added to the end - the new copies of items in the folder will have the same names as the originals.
"},{"location":"Spira-User-Manual/Test-Case-Management/#blocking-and-unblocking-test-cases","title":"Blocking and Unblocking Test Cases","text":"To designate one or more test cases as blocked, select the check-boxes of the test cases and then select the Edit > Block Test Cases menu option. This temporarily blocks test cases so that testers know they are not available for testing. Unlike actually executing the test cases and recording an execution status, no test run is recorded and summary metrics (such as requirements test coverage and test set status) are not updated. Likewise, to unblock test cases, select their check-boxes and then select the Edit > Unblock Test Cases menu option. This changes their Execution Status from Blocked to Not Run. The Edit menu will be enabled if the current user has Test Case > Bulk Edit permission.
"},{"location":"Spira-User-Manual/Test-Case-Management/#moving-test-cases-or-folders","title":"Moving Test Cases or Folders","text":"There are two options for moving test cases or folders:
Once you have the test case/folder positioned at the correct place that you want it inserted, just release the mouse button. To move multiple items simply select their checkboxes and then drag-and-drop one of the selected items.
Read about how to export artifacts from one product to another.
"},{"location":"Spira-User-Manual/Test-Case-Management/#adding-test-cases-to-a-release-test-set-or-requirement","title":"Adding Test Cases to a Release, Test Set or Requirement","text":"To quickly add a series of test cases to a Release, Test Set or Requirement, select the check-boxes of the appropriate test cases and then click Tools > Add to Release / Test Set / Requirement. This will bring up a dialog box displaying either a list of available releases, test sets or requirements (depending on which option was chosen):
Once you have chosen the destination release / test set / requirement, clicking \"Add\" will add the selected test cases to that specific destination release / test set / requirement.
"},{"location":"Spira-User-Manual/Test-Case-Management/#printing-items","title":"Printing Items","text":"To quickly print a single test case, test folder or list of test cases you can select the items' checkboxes and then click Tools > Print Items. This will create a printable report of the selected items in a new window.
"},{"location":"Spira-User-Manual/Test-Case-Management/#right-click-context-menu","title":"Right-Click Context Menu","text":"SpiraPlan\u00ae provides a shortcut -- called the context menu - for accessing some of the most commonly used functions, so that you don't need to move your mouse up to the toolbar each time. To access the context menu, right-click on any of the rows in the test case list and the following menu will be displayed:
You can now choose any of these options as an alternative to using the icons in the toolbar.
"},{"location":"Spira-User-Manual/Test-Case-Management/#test-case-details","title":"Test Case Details","text":"When you click on a test case item in the test case list, you are taken to the test case details page illustrated below:
This page is made up of three areas;
The navigation pane consists of a link that will take you back to the test case list, as well as a list of the peer test cases to the one selected. This latter list is useful as a navigation shortcut: you can quickly view the detailed information of all the peer test cases by clicking on the navigation links without having to first return to the test cases list page. The navigation list can be switched between three different modes:
The operations toolbar lets you, amongst standard operations like save and delete:
RefreshTools dropdown menuExecute button will immediately prepare the current test case for execution and then take you to the test execution screen. NOTE: if the product does not allow you to execute test cases this button will not be available.When cloning test cases note that:
The lower part of the right pane can be switched between a number of different views by clicking the appropriate tab. Initially the pane will be in \"Overview\" mode, but it can be switched to \"Requirements Coverage\", \"Test Runs\", \"Releases\", \"Incidents\", \"Attachments\", \"History\", and \"Test Sets\" modes if so desired. Each of these views is described below.
"},{"location":"Spira-User-Manual/Test-Case-Management/#emailing","title":"Emailing","text":"Read about emailing an artifact to colleagues using Spira.
"},{"location":"Spira-User-Manual/Test-Case-Management/#followers","title":"Followers","text":"Read about how to add and manage followers to an artifact.
"},{"location":"Spira-User-Manual/Test-Case-Management/#workflows","title":"Workflows","text":"Read about using workflows to change the status of your artifact.
"},{"location":"Spira-User-Manual/Test-Case-Management/#overview-details","title":"Overview - Details","text":"The Overview tab is divided into a number of different sections. Each of these can be collapsed or expanded by clicking on the title of that section. This tab displays the fields, detailed information, and comments associated with the test case.
The top part of this tab displays the various standard fields and custom properties associated with the test case. Fields (both standard and custom) are grouped under the collapsible headings (marked by orange text and underline) in the screenshot below. For instance, all fields regarding dates are grouped together in the \"Dates and Times\" area.
The Detailed Information section contains the long, formatted description of the test case, as well as any rich text custom fields. You can enter rich text or paste in from a word processing program or web page. Clicking on the shaded areas of one of these detailed fields will display the rich text toolbar.
The Suspect flag is automatically set on an approved test case, when one of the requirements linking to it changes1. This lets you quickly find all the test cases impacted by a specific requirement change. For this to happen the requirement needs to be in an Accepted or later status (i.e. not Rejected, Rejected, Under Review, Obsolete) and the test case needs to be an approved status (i.e. not Draft, Obsolete, Rejected).
"},{"location":"Spira-User-Manual/Test-Case-Management/#overview-test-steps","title":"Overview - Test Steps","text":"This view displays the name of the test case together with all the defined test steps that a tester would need to perform to verify that the functionality works as expected. The list of test steps displays the position number, the description, the expected result, some suggested sample data and the most recent execution status of the individual test step:
Note: Test steps that are marked with a hyperlink and test case icon (e.g. \"Call Login to Application\" in the screen shot above) are in fact linked test cases. Linked test cases are a useful way of reusing existing test steps from other test cases. For example if you want to have a set of steps be in more than one test case (e.g. a login step) then you would create a separate test case just containing these steps, then have all the other test cases just link to it. This avoids the need to have duplicate test steps throughout the product.
If you click on the step number hyperlink (e.g. Step 2) you will be taken to the test step details page which allows you to perform additional editing of a specific test step as well as attach documents, associate pre-existing incidents and view the change history.
"},{"location":"Spira-User-Manual/Test-Case-Management/#insert-step","title":"Insert Step","text":"Clicking on the \"Insert Step\" button inserts a new test step before the currently selected (by means of the check-box) test step. Clicking the \"Insert Step\" button without selecting a test step will insert a new step at the end of the list. When a new step is inserted, the fields are displayed in \"Edit\" mode, so the description, expected result and sample data fields are editable, allowing you to enter the data:
Once you have entered the necessary information, you can click either \"Save and New\" to commit the changes. If you choose \"Save and New\" another new row will be inserted which is useful if you intend on entering lots of rows at once, whereas clicking \"Save\" will commit only the current row.
"},{"location":"Spira-User-Manual/Test-Case-Management/#insert-link","title":"Insert Link","text":"Clicking on the \"Insert Link\" button brings up the following dialog box that allows you to either choose an existing test case to be inserted or create a new test case and step with parameters:
When linking an existing test case, first select its parent folder from the dropdown. Then select the name of the test case you want to insert as a link from the list. If the test case has declared parameters you will see a list of parameters to fill out.
If it makes sense for your tests you can fill out the parameter values and then click \"Add\". The system will insert the test case as a link. These paramter values are passed down to the linked test at execution. These values override any default parameter values set on the test case. If a test step was already selected the link is inserted above that test step, otherwise the link is added at the end of the test step list.
If you want to create a test step with specific parameters and parameter values, you can do so by clicking the \"Create New Test Case\". This will change the dialog to one where you can assign a folder, name, and parameters to a new test case. On clicking the \"Add\" button: the new test case is created; a test step is created within that new test case; the parameters specified in the dialog are assigned to that test step, with the values set as the defaults for the step; and the new test case is added as a linked test case in the list of test steps.
"},{"location":"Spira-User-Manual/Test-Case-Management/#delete_1","title":"Delete","text":"Clicking on the \"Delete\" button deletes the currently selected test steps, and reorders the test step position numbers to close any gaps in numbering.
"},{"location":"Spira-User-Manual/Test-Case-Management/#clone","title":"Clone","text":"Clicking on the \"Clone\" button makes a duplicate of the current test step or linked test case and inserts the copied version directly above the original one.
When cloning the test step note that:
Click the \"Import\" button to import all the test steps of another test case. When you click the button a popup will let you choose a single test case to import steps from. Only users who can modify the current test case and who can create test steps can use this functionality.
"},{"location":"Spira-User-Manual/Test-Case-Management/#refresh_1","title":"Refresh","text":"Clicking on the \"Refresh\" button simply reloads the list of test steps. This is useful if other people are making changes to the test list and you want to make sure that you have the most current version.
"},{"location":"Spira-User-Manual/Test-Case-Management/#show-hide-columns_1","title":"Show / Hide Columns","text":"By default the test step list screen will display the Description, Expected Result and Sample Data fields. However the Expected Result and Sample Data fields are optional and can be hidden if necessary to make more space. If you have configured custom properties for test steps, you can use the Show/Hide features to display one or more of your custom properties instead. These fields will then be editable in this grid-view.
"},{"location":"Spira-User-Manual/Test-Case-Management/#editing-test-steps","title":"Editing Test Steps","text":"To modify an existing Test Step you simply need to click on the \"Edit\" button to the right of the step, or just double-click on the cells in the row. That will switch the selected row into Edit mode. The various columns are turned into editable text-boxes, and \"Save\" and \"Cancel\" buttons are displayed in the last column:
If you click \"Edit\" on more than one row, the \"Save\" buttons are only displayed on the first row, and you can make changes to all the editable rows and then save the changes by clicking the one \"Save\" button. Also, if you want to make the same change to multiple rows, you can click on the \"fill\" icon to the right of the editable item, which will propagate the new value to all editable items in the same column. When you have made your changes, you can either click \"Save\" to commit the changes, or \"Cancel\" to revert back to the original information.
"},{"location":"Spira-User-Manual/Test-Case-Management/#editing-test-links","title":"Editing Test Links","text":"To modify an existing Test Link you simply need to click on the \"Edit\" button to the right of the step, or double click on the cells in the row. This will open up the special dialog box used for editing the parameter values to pass into the specific linked test case:
This allows you to edit the parameters being passed from the current test step to the linked test case without having to recreate the test link from scratch. To commit the change click \"Save\" to close the dialog box, or click \"Cancel\" to revert back to the original information.
"},{"location":"Spira-User-Manual/Test-Case-Management/#moving-test-steps","title":"Moving Test Steps","text":"To move test steps in the list, click on the row you want to move and drag it where you want it moved to within the list of test steps. An empty space will appear to show you where it will be inserted.
"},{"location":"Spira-User-Manual/Test-Case-Management/#parameters","title":"Parameters","text":"Test cases can have parameters associated with them. This lets a single test case get called multiple times by another test case (as a link) and have different parameters passed in each case, making the operation different.
Parameter Example
You have a test case \"login to application\". This test case has 2 parameters: username; and password. It has default values for these parameters of \"user\" and \"correct-password\". We set the Sample Data field to read: \"Username = ${username}, and password = ${password}\". You can reuse this test case in other test cases by linking links.
Hopefully, the above example begins to show you the flexibility of parameters. You can add the same test case as a linked step multiple times and pass down / override different values each time - useful for testing different logins. You can link test cases together in more complex ways - with test cases nested inside each other.
With complex test case / link structures, you can still pass down parameter values. Building on the above example, let's add the test case \"Can login successfully\" to a new, third, test case called \"Can login and logout successfully\". We now have 3 test cases in a chain. When we add \"Can login successfully\" as a link we can only edit one of the original parameters: only \"password\". We are not able to edit \"username\". This is because when you override a parameter value in a link once, you cannot override from higher up in the chain.
In other words, during execution, parameter values are set by the linked step's defaults if no parent test case overrides them; and by the test case parent closest to the originating linked step that sets an overriding value for a parameter.
To view / change the parameters associated with the current test case, click on the \"Edit Parameters\" button in the toolbar to see and edit the list of current parameters for this test case:
Existing parameters are shown in a list. For each parameter you can:
insert the parameter token at the current cursor position. To do this:
To add a new parameter to the test case, use the form at the bottom of the popup dialog. Set the token name and (optionally) a default value then click \"Add\", and then \"Save\".
"},{"location":"Spira-User-Manual/Test-Case-Management/#overview-automation","title":"Overview - Automation","text":"The Automation section displays the automated test script associated with the test case. To activate this section, choose an Automation Engine from the dropdown in the section. Automation can only run if it has an engine that it will run on - the application / framework that will actually run the script (e.g. Rapise). You can set up automation engines in system administration.
There are three types of automated test:
The screenshot below illustrates a sample Rapise automated test script attached to a test case:
The automation screen includes the following fields that you should populate when using SpiraPlan\u00ae to store an automated test script:
Read about how the comments works
"},{"location":"Spira-User-Manual/Test-Case-Management/#requirements-coverage","title":"Requirements Coverage","text":"This tab displays the requirements coverage information for the test case in question:
The table shows the requirements, if any, mapped to this test case. Clicking on the hyperlinked names will jump you to the details screen for the item in question.
To map the test case to an additional requirement, click the \"Add\" button to display the add association panel. You can search by the ID (if known) prefixed with the appropriate token (e.g. \"RQ:4\" to search for requirement 4). You can also browse by parent requirement, or search by name. Select the requirements you want and then click the \"Save\" button\". This will add the selected requirement(s) only (and not their children if they are parent requirements). This will also add any releases assigned to the requirement(s) not already linked to the test case.
From the same add association panel there is a shortcut to \"Create Requirement from This Test Case\". This button will create a new requirement in the list of covered requirements that will be automatically linked to this test case. This is useful when you have created a new test case and want to generate an initial placeholder requirement to be fleshed-out later.
Finally, to remove coverage for this test case, select any of the added requirements (those in the bottom table) and click the \"Remove\" button. Note that this will remove the requirements and does not change the release coverage of the test case.
"},{"location":"Spira-User-Manual/Test-Case-Management/#test-runs","title":"Test Runs","text":"This view displays the name of the test case together with a list of the previous execution runs that the test case has been put through. Each test run is listed together with the date of execution, the name of the test case, the name of the test set (if applicable), the name of the tester, the release/version of the system that the test was executed against, the overall execution status for the test case in that run and a link to the actual test run details. In addition, you can choose to display any of the custom properties associated with the test run.
The \"show/hide columns\" drop-down list allows you to change the fields that are displayed in the test run list as columns. To show a column that is not already displayed, simply select that column from the list of \"Show...\" column names and to hide an existing column, simply select that column from the list of \"Hide...\" column names. The displayed columns can be any standard field or custom property.
You can also filter the results by choosing items from the filter options displayed in the sub-header row of each field and clicking the \"Filter\" button. In addition, you can quickly sort the list by clicking on one of the directional arrow icons displayed in the header row of the appropriate field.
"},{"location":"Spira-User-Manual/Test-Case-Management/#releases","title":"Releases","text":"This tab displays the name of the test case together with the release mapping information for the test case in question. It functions in a similar way to the Requirements Coverage tab described above: the table at the bottom of the panel shows the releases, if any, mapped to this test case. Clicking on the hyperlinked names will jump you to the details screen for the item in question. You can search for and add releases to this list using the \"Add\" button, or remove them using the \"Remove\" button. Adding the release(s) will only add the release(s) selected (and not their children, if any). However, when adding a sprint, the sprint's immediate parent release (if it has one) is also added.
"},{"location":"Spira-User-Manual/Test-Case-Management/#incidents","title":"Incidents","text":"This tab displays the list of incidents associated with the current test case. The incidents have either been created during an execution of the test case (and are thereby linked to one of the test runs and their steps) or manually linked to one of the test steps in the test case from the Incidents tab of the test step details page.
Each incident is listed together with (by default) the type, status, priority, name, owner, detector, detection date and a link to the actual incident details. On this tab you can perform the following actions:
In this tab, the main pane displays the list of documents that have been \"attached\" to the test case. The documents can be in any format, though SpiraPlan\u00ae will only display an icon for certain known types.
The attachment list includes the filename that was originally uploaded together with the file-size (in KB), name of the person who attached it and the date uploaded. In addition, if you position the pointer over the filename and hold it there for a few seconds, a detailed description is displayed as a tooltip.
To actually view the document, simply click on the filename hyperlink and a new web browser window will open. Depending on the type of file, this window will either display the document or prompt you for a place to save it on your local computer. To delete an existing attachment from a test case, simply click the \"Remove\" button and the attachment will be removed from the list.
To attach a new document to the test case, you need to first click the \"Add New\" link to display the new attachment dialog box:
There are three different types of item that can be attached to a test case:
To upload a file, choose \"File\" as the type and then click the Browse button and select the file from your local computer, optionally enter a detailed description then click the \"Upload\" button. The document will be copied from your computer and attached to the artifact.
To attach a web-link (URL) to the artifact, you need to choose \"URL\" as the type and then enter the fully qualified URL (e.g. http://mywebsite.com?Document=1), an optional description and then click the \"Upload\" button to attach the web-link.
To attach a screenshot to the artifact, you need to choose \"Screenshot\" as the type and then copy the image to your computer's clipboard (e.g. on Windows computers, the PRINT SCREEN button captures the current page and adds to the clipboard). Once the image is in the clipboard, paste it into the editor using CTRL+V (or the equivalent keystroke for your operating system) and the item will appear in the preview window. You can then fill in the other fields and click \"Upload\" to attach the image.
Note: If you are using a non-Windows\u00ae computer (e.g. Macintosh\u00ae) that doesn't put file extensions on filenames (e.g. .xls for an Excel sheet) automatically, then you will need to manually add the file extension to the filename before uploading if you want it to be displayed with the correct icon in the attachment list.
You can also associate an existing document (that's already stored in SpiraTeam) with the test case. To do that, click on the \"Add Existing\" button to bring up the add file association dialog box:
You can then choose to either associate a document stored in the SpiraPlan Documents repository or (in the case of SpiraPlan/SpiraTeam but not SpiraTest) from the linked source code repository. In either case you first select the appropriate folder, and then pick the document(s) from the file list on the right. In the case of a source code file association you can also add a comment.
"},{"location":"Spira-User-Manual/Test-Case-Management/#history","title":"History","text":"In this tab, the main pane displays the list of changes that have been performed on the test case artifact since its creation. An example test case change history is depicted below:
The change history displays the date that each change was made, together with the fields that were changed, the old and new values and the person who made the change. This allows a complete audit trail to be maintained of all changes in the system. In addition, if you are logged in as a product administrator you can also click on the \"Admin View\" button to navigate to where you can revert any unwanted changes.
"},{"location":"Spira-User-Manual/Test-Case-Management/#test-sets","title":"Test Sets","text":"In this tab, the main pane displays the test sets that contain the current test case. Each test set is listed together with its name, release, the date of last execution, the owner, the status, the execution status, and a link to the actual test set details. In addition, you can choose to display any of the custom properties associated with the test set.
The \"show/hide columns\" drop-down list allows you to change the fields that are displayed in the test set list as columns. To show a column that is not already displayed, simply select that column from the list of \"Show...\" column names and to hide an existing column, simply select that column from the list of \"Hide...\" column names. The displayed columns can be any standard field or custom property.
You can also filter the results by choosing items from the filter options displayed in the sub-header row of each field and clicking the \"Filter\" button. In addition, you can quickly sort the list by clicking on one of the directional arrow icons displayed in the header row of the appropriate field.
"},{"location":"Spira-User-Manual/Test-Case-Management/#associations","title":"Associations","text":"You can associate tasks and risks to a test case from this tab (which is only available to SpiraTeam and SpiraPlan users). Apart from creating links to an existing task from this tab, any tasks created during exploratory test execution will also be shown here.
Read more about how to manage and add associations to this artifact
"},{"location":"Spira-User-Manual/Test-Case-Management/#test-step-details","title":"Test Step Details","text":"When you click on one of the hyperlinks next to a test step in the test step list (see above), you will be taken to the test step details screen illustrated below:
This page is made up of three areas; the left pane is the navigation window, the upper part of the right pane contains the test step detailed information itself, and the bottom part of the right pane contains related information about the test step.
The navigation pane consists of a link that will take you back to the test step list, as well as a list of the peer test steps to the one selected. This latter list is useful as a navigation shortcut; you can quickly view the detailed information of all the peer test steps by clicking on the navigation links without having to first return to the test step list page. You can also switch between seeing the list of test steps with the current filter applier or simply unfiltered.
The top part of the right pane allows you to view and/or edit the details of the particular test step. You can edit the various fields (description, expected result and sample data) and custom properties. Once you are satisfied with them, click any \"Save\" button on the page to commit the changes.
If you can create test steps and want to add a new test step to the test case:
The lower part of the right pane can be switched between four different views by clicking the appropriate tab. Initially the pane will be on \"Incidents\" tab, but it can be switched to \"Attachments\", \"History\" or \"Requirements\" tabs if so desired. Each of the views is described separately below.
"},{"location":"Spira-User-Manual/Test-Case-Management/#incidents_1","title":"Incidents","text":"In this mode, the main pane displays a list of any incidents that are associated with this test step. They can either be linked indirectly due to being logged during a test run, or directly linked after the fact:
Each incident is listed together with the type, status, priority, name, owner, detector, detection date and a link to the actual incident details. You can customize the fields that are displayed using the \"Show/Hide Columns\" option. In addition, you can perform the following operations:
Refresh -- updates the list of incidents from the server, useful if other people are adding incidents to this release at the same time.
You can also filter the results by choosing items from the filter options displayed in the sub-header row of each field and clicking the \"Filter\" button. In addition, you can quickly sort the list by clicking on one of the directional arrow icons displayed in the header row of the appropriate field.
Edit -- Clicking the \"Edit\" button to the right of the incident allows you to edit the incident inline directly on this screen.
To create a new association between this test step and an existing incident, click the \"Link Incident\" button which will display the following panel:
You need to choose the specific incident(s) you want to link to, either by choosing the item from the scrolling selection box, or searching for them by name or ID. Before adding the chosen incidents you can add a comment that explains the rationale for the association.
"},{"location":"Spira-User-Manual/Test-Case-Management/#attachments_1","title":"Attachments","text":"Read about how the attachments tab works
"},{"location":"Spira-User-Manual/Test-Case-Management/#history_1","title":"History","text":"Read about how the history tab works
"},{"location":"Spira-User-Manual/Test-Case-Management/#requirements","title":"Requirements","text":"Normally within SpiraTest, you will link the test cases in a product with your requirements to describe which requirements are covered by each of the test cases. When all of the tests for a requirement pass, the requirement is considered fully tested.
However, in some industries (for example when developing Defense systems) there is an additional requirement to report on the traceability between the individual test steps and the requirements. For customers that have such a requirement, this tab lets you associate the current test step with specific requirements.
The tab displays a grid containing the requirements already mapped to this test step. You can filter that list by the requirement type, name, status, importance, product name and ID. You can remove an existing requirement by selecting its check box and clicking the 'Delete' button. This doesn't delete the requirement, just removes it from the test step.
Hovering the mouse over the names of the requirements will display a \"tooltip\" consisting of the requirement name, place in the hierarchy and a detailed description.
To add a new test case to the requirement, click the 'Add' button:
You can search for a requirement by its ID if you know it (make sure to include the \"RQ\" prefix):
Otherwise, you can search for the requirements by choosing a parent requirement from the dropdown and/or entering a partial name match:
One you have found the desired requirement(s), simply select their check boxes and click the 'Save' button to add them to the current test step:
"},{"location":"Spira-User-Manual/Test-Case-Management/#execute-test-cases","title":"Execute Test Case(s)","text":""},{"location":"Spira-User-Manual/Test-Case-Management/#test-run-list","title":"Test Run List","text":""},{"location":"Spira-User-Manual/Test-Case-Management/#test-run-details","title":"Test Run Details","text":""},{"location":"Spira-User-Manual/Test-Case-Management/#test-set-list","title":"Test Set List","text":""},{"location":"Spira-User-Manual/Test-Case-Management/#test-set-details","title":"Test Set Details","text":""},{"location":"Spira-User-Manual/Test-Case-Management/#automation-host-list","title":"Automation Host List","text":""},{"location":"Spira-User-Manual/Test-Case-Management/#automation-host-list_1","title":"Automation Host List","text":""},{"location":"Spira-User-Manual/Test-Case-Management/#test-configuration-list","title":"Test Configuration List","text":""},{"location":"Spira-User-Manual/Test-Case-Management/#test-configuration-details","title":"Test Configuration Details","text":"only certain changes to a requirement will trigger the suspect flag. These are any change to standard field only. Changes to comments, assocations, attachments, use case steps, and custom properties will not trigger the suspect flag.\u00a0\u21a9
when navigating to folders (for all artifacts that support them), the URL in your browser's address bar will change. Each folder has a unique, sharable URL that you can give to someone to display the list of artifacts with the appropriate folder selected. You can also open up multiple folders in different browser tabs and easily toggle between them from the same browser.\u00a0\u21a9
This section outlines how to use the Test Configuration features of SpiraPlan\u00ae to create and manage different configurations of parameters that tests (both manual and automated) can be run against. This offers tools to quickly create every combination of different parameters.
When you click on the Testing > Test Configuration global navigation link, you will initially be taken to the test configuration list screen illustrated below:
The test configuration list screen displays all the test configurations for the current product, in a filterable, sortable grid. The grid displays the name, creation date, last updated date, ID, and whether the test configuration is active.
In addition, you can view a more detailed description of the test configuration by positioning the mouse pointer over the host name hyperlink and waiting for the popup \"tooltip\" to appear. If you click on the host name hyperlink, you will be taken to the test configuration details page. Clicking on any of the pagination links at the bottom of the page will advance you to the next set of hosts in the list according to the applied filter and sort-order. There is also a drop-down-list at the bottom of the page which allows you to specify how many rows should be displayed in each page, helping accommodate different user preferences.
"},{"location":"Spira-User-Manual/Test-Configuration-Management/#filtering-sorting","title":"Filtering & Sorting","text":"Read about how to create and manage filters, and how to sort the artifact list.
"},{"location":"Spira-User-Manual/Test-Configuration-Management/#new-test-configuration","title":"New Test Configuration","text":"Clicking on the \"New Configuration\" button adds a new test configuration to the bottom of the list with a default name.
"},{"location":"Spira-User-Manual/Test-Configuration-Management/#delete","title":"Delete","text":"Clicking on the \"Delete\" button deletes the test configurations whose check-boxes have been selected in the host list.
"},{"location":"Spira-User-Manual/Test-Configuration-Management/#refresh","title":"Refresh","text":"Clicking on the \"Refresh\" button reloads the list of test configurations; this is useful when new configurations are being added by other users, and you want to make sure you have the most up-to-date list displayed.
"},{"location":"Spira-User-Manual/Test-Configuration-Management/#edit","title":"Edit","text":"Each test configuration in the list has an \"Edit\" button in its right-most column. When you click this button or just double-click on any of the cells in the row, you change the item from \"View\" mode to \"Edit\" mode. The various columns are made editable, and \"Save\" buttons are displayed in the last column.
If you click \"Edit\" on more than one row, the \"Save\" buttons are only displayed on the first row, and you can make changes to all the editable rows and then update the changes by clicking the one \"Save\" button. Also, if you want to make the same change to multiple rows (e.g. to change five test configurations from Active = No to Active = Yes), you can click on the \"fill\" icon to the right of the editable item, which will propagate the new value to all editable items in the same column.
If you want to edit lots of items, first select their checkboxes and then click the \"Edit\" button on the same row as the Filters and it will switch all the selected items into edit mode.
When you have made your updates, you can either click \"Save\"to commit the changes, or \"Cancel\" to revert back to the original information. Alternatively, pressing the <ENTER> key will commit the changes and pressing the <ESCAPE> key will cancel the changes.
"},{"location":"Spira-User-Manual/Test-Configuration-Management/#test-configuration-details","title":"Test Configuration Details","text":"When you click on a test configuration entry in the list, you are taken to the test configuration details page illustrated below:
This page is made up of three areas; the left pane is the navigation window, the upper part of the right pane contains the test configuration name and ID, and the bottom part of the right pane displays different information associated with the test configuration.
The navigation pane consists of a link that will take you back to the test configuration list, as well as a list of the peer test configurations to the one selected. This latter list is useful as a navigation shortcut; you can quickly view the peer configurations by clicking on the navigation links without having to first return to the list page. The navigation list can be switched between two different modes:
The list of configurations matching the current filter
The list of all configurations, irrespective of the current filter
The right pane allows you to view and/or edit the details of the particular test configuration. You can edit the various fields (name, description, etc.) and custom properties. Once you are satisfied with the changes, click either the \"Save\" button or the alternative options from the \"Save\" dropdown list. In addition you can delete the current automation host by clicking \"Delete\", or discard any changes made by clicking \"Refresh\".
"},{"location":"Spira-User-Manual/Test-Configuration-Management/#overview","title":"Overview","text":"This tab shows the fields and description associated with the test configuration. Standard and custom fields are grouped by type (eg all date and time fields are grouped together).
"},{"location":"Spira-User-Manual/Test-Configuration-Management/#overview-test-configuration-entries","title":"Overview -- Test Configuration Entries","text":"This section shows the list of all entries from this test configuration, and that would be used by a test set to populate parameters. Each row represents a single unique combination of the parameters (shown on the header row of the table).
Entries can be reordered by dragging and drop one row or more. Individual entries can also be removed by checking the checkbox for that entry and then clicking \"Remove\" button.
To create new entries, first click the \"Populate\" button. This will display the following panel:
You must select a parameter from the left dropdown (which contains a list of all parameters defined in test cases in the current product), and a custom list with which to populate the parameter. Then click the \"Add\" button. For instance, the screenshot below would create a configuration using every operating system defined by the custom list \"Operating System\" and assigning these to the parameter called \"operatingSystem.\"
Note: Custom lists are usually used in SpiraPlan for custom fields on various artifacts. However, you can create custom lists that are solely for the purpose of test configurations, should you so wish -- for instance, to contain a list of usernames.
Once you are happy with the lists and parameters selected, click the \"Populate\" button. This will overwrite all existing entries in this test configuration. It will create every combination based on the lists specified. So if you select two parameters, each with a list that has ten items, one hundred entries will be created in the test configuration.
"},{"location":"Spira-User-Manual/Test-Configuration-Management/#test-sets","title":"Test Sets","text":"This tab displays the list of all the test sets that are using the test configuration. Each test set is listed together with its name, release, the date of last execution, the owner, the status, the execution status, and a link to the actual test set details. In addition, you can choose to display any of the custom properties associated with the test set.
The \"Show/hide columns\" drop-down list allows you to change the fields that are displayed in the test set list as columns. To show a column that is not already displayed, simply select that column from the list of \"Show...\" column names and to hide an existing column, simply select that column from the list of \"Hide...\" column names. The displayed columns can be any standard field or custom property.
You can also filter the results by choosing items from the filter options displayed in the sub-header row of each field and clicking the \"Filter\" button. In addition, you can quickly sort the list by clicking on one of the directional arrow icons displayed in the header row of the appropriate field.
"},{"location":"Spira-User-Manual/Test-Execution/","title":"Execution of Test Case(s)","text":""},{"location":"Spira-User-Manual/Test-Execution/#introduction","title":"Introduction","text":"Customizing Test Execution
There are a number of ways that a product admin can tailor or customize test execution. Certain features can be disabled / enabled via the testing settings page. The below describes using test execution with default settings and flags the key places where customizing these settings can change testers' experiences.
This section describes how a tester can follow the steps defined for a series of test cases and record what actually happened in the process. In addition, recorded failures of test cases can be used to automatically generate new incidents that will be added to the incident tracking module and, optionally, to tasks.
You start test case execution in SpiraPlan by either:
If you execute a test set then the values of the selected release and custom list properties for the test run are automatically populated from the test set, whereas if you directly execute a test case itself, those values can be chosen by the tester.
If you attempt to execute a single test case that you are in the middle of testing (from either a test case, group of test cases, or a test set) a popup will ask if you want to resume one of those existing, not-yet-completed pending test runs, or start a new test run. The popup will show the five most recent relevant pending test runs with their dates and names.
Regardless of the route taken to launch the test execution module, the first screen that will be displayed will look like the following:
Before actually executing the test scripts, you need to select the release (if not already set) and optionally the specific build of the system that you will be testing against. You can also specify any test run custom properties that have been defined by the product owner. This ensures that the resulting test runs and incidents are associated with the correct release of the system, and that the test runs are mapped to the appropriate custom properties (e.g. operating system, platform, browser, etc.).
If you have not configured any releases for the product, then the release drop-down list will be disabled and the test runs/incidents will not be associated with any particular release. If the test run was launched from a test set, the release and any list custom properties will be pre-populated from the test set itself and will not be changeable on this screen (unless they weren't set by the test set).
Once you have chosen the appropriate release name and/or custom properties, click the \"Next\" button to begin executing test steps. By default you will see the default test execution module, shown below.
There is a second test execution view: the exploratory test execution module. This has much in common with standard test execution but differs in a number of important ways. You will automatically see this module if the following three conditions are met;
The screen is divided up into three main areas (each is explained in more detail in the sections below):
The header area at the top of the page, which displays the name (if any) of the test run, along with the selected release. This section also contains buttons to control how the \"test execution area\" looks and functions for the tester.
The Progress Bar, which shows a summary graphical view of the whole test run. The progress bar also has a number of navigation buttons to help you move around the test run, or to leave the test execution page. Between the buttons are indicator blocks. For test runs with relatively few test steps, each indicator block represents a single test step. A tall dotted line is used to indicate the end of one test case and the start of another. When there are many test steps to a test run, each indicator block represents a test case. Hovering over an indicator block will display a tooltip with information about the test step or case represented. The color of the indicator block matches the color of any assigned execution status for the test step or test case (see below).
The rest of the page contains the \"test execution area\". This has details about all of the steps in the test run. It can be used to both navigate between test cases and test steps, as well as to actions on any test case or test step (for instance assigning an execution status or logging an incident). This area can look markedly different depending on which display mode a user has selected. However, in every mode, a tester will be able to readily view the name and description of the test step (and at times the parent test case), along with the description of the test step, instructions for carrying out it, and any expected results. The test can then compare the results with those listed as expected. As described below, depending on how the actual system responds, you will use the buttons and fields on the page to record what actually happened.
Note: on first accessing this screen, the user will be given a guided tour of many of the features of this page. This can be accessed at any time via the options menu (discussed below)
"},{"location":"Spira-User-Manual/Test-Execution/#display-modes","title":"Display Modes","text":"The display mode toolbar is at the top right of the test execution screen. There are three different display modes. Each display mode has two sub-modes, using simple graphical images to indicate what they do (each pair of buttons to change sub-mode becomes visible on activating a particular display mode).
All of these modes affect how the test cases and test steps are displayed in the \"test execution area\". The different views have been designed to suit different ways of testing, depending on how your organization works; or the needs of a tester for a particular test.
There are three parts in the \"test execution area\", which are visible or hidden depending on the view.
There are three main display modes:
Split mode: shows a simplified list of test steps on the left (in the table) and full details about the currently selected test step on the right (in the inspector). The sub modes in the split view either show a narrow table and wide inspector, or a wide table and narrow inspector.
Table mode: in this mode the table takes up the full width of the \"test execution area\", with both the inspector and iframe completely hidden. The list of test cases and steps displays all the information about each---the same information as is shown in the inspector. This view makes it easy to quickly scan through a number of test steps and take quick actions on many steps in sequence. The sub-modes in this view either expand or collapse any fields with more than one line or text in them. This is helpful to give either a very detailed or summary view to the table. Note too that every field that takes up more than one line will have a little expand or collapse button to its left, allowing for control of individual fields as needed.
Mini mode: this mode fills the entire \"test execution area\" with the inspector, or a combination of the inspector and iframe. The table is completely hidden in this mode. The mini mode is designed to help you maximize space for the inspector or to allow you to test a website in the embedded mini browser (in the iframe) right next to a narrow inspector.
"},{"location":"Spira-User-Manual/Test-Execution/#navigating-around-a-test-run","title":"Navigating Around a Test Run","text":"There are several ways to move through the different cases and steps of a particular test run. In the default \"split\" mode you are guided through a test run in order, however at any time, in any display mode, you can easily and quickly move steps. Note that if you click on a test case, the first test step in that test case will be selected as well.
Using the progress bar buttons: the left-hand side of the progress bar has three buttons: backward, forward, and play/pause (the last of these is discussed in more detail below). Clicking on the backward or forward buttons will move to the previous or next progress bar indicator block (and the associated test step or test case).
Using the progress bar indicator blocks: clicking on any indicator block will immediately focus the test execution area on that test step or test case.
Using the table: when the table view is visible (in either split mode or table mode) clicking on any item will immediately focus the test execution area on that test step or test case.
Progressing through steps using the inspector: when the inspector is visible (in split or mini display mode), on properly setting a status for a test step (see Viewing and Recording Execution Details for further details), the next test step is automatically loaded into the inspector. If you were on step 3 of 5, you would be moved to step 4. If you were on the last step of a test case, you will be moved to the next test case, if one is available.
Pause/Play button: the time spent on every test step is recorded, by default, during test execution. This allows an accurate assessment of exactly how long a test run took to complete and these timing details are saved with the test run and its results. If you wish to pause the behind-the-scenes timer (for instance if taking a break) click the pause/play button. To resume the time click it again.
The currently selected progress bar indicator block will be outlined with a peach border. The currently selected test case and test step on the table view will be indicated with a peach bar along their left edge, and will also be highlighted in a light peach.
"},{"location":"Spira-User-Manual/Test-Execution/#viewing-and-recording-execution-details","title":"Viewing and Recording Execution Details","text":"There is a small icon to the left of each test step title and test case title. For test steps this is a circle, for test cases a square note. Once a status has been recorded for a test step (or once a test case has been assigned a status based on the statuses of its test steps) these icons will be filled with a visual indicator of its current status. The icons both become colored and are given a small symbol, based on the status. In the inspector view the associated button to that status has a gray bar beneath it.
The same colors and symbols used to show a status are used on the buttons to record a status. The colors and symbols used are: green / tick = \"Passed\"; yellow / stop sign = \"Blocked\"; orange / warning triangle = \"Caution\", red / cross = \"Failed\", gray / dash = \"Not Run\".
Depending on the display mode and device, the buttons may show the text name of the status along with the symbol (see examples below---the top button set is that on the inspector, the bottom from the table (when the display mode is set to table).
NOTE: by default all of the above buttons are visible during testing. However, a product admin can remove any or all of the \"Caution\", \"Blocked\", or \"N/A\" buttons on the testing settings page.
The various statuses when recorded against test steps will appear as below, respectively:
You will notice that softer shades are used above compared to the buttons. Similarly soft shades are also used on the progress bar indicator blocks, as shown below.
The status of a test case is determined by its test steps. If any of the steps are marked as \"Caution\", \"Blocked\", or \"Fail\" then the overall test case is marked with the most severe status of those statuses applied to any of the test steps from \"Caution\", to \"Blocked\", to \"Fail\" (e.g. if one is marked as \"Caution, the test case will be marked \"Caution\"; but if one is marked as \"Caution\", and another \"Blocked\", the case will be marked \"Blocked). If all the test steps passed, or if steps are marked either passed or \"N/A\", then the overall test case is marked as \"Passed\"; any other case results in the test case being marked as \"Not Run\".
If the expected results are indeed observed, then you simply need to click the \"Pass\" button to mark the test step as passed, and advance to the next test step, or if all the steps have passed, you can click \"Pass All\" to pass all the steps at once (this ability can be disabled by product admins in testing settings).
On the inspector, the \"Pass All\" button is visible via a dropdown to the right of the \"Pass\" button whenever the parent test case information is also displayed with the test step (typically only for the first step in a test case). This is illustrated in the screen shot below:
When in the table display mode, the \"Pass All\" button is shown on the right-hand side of the test case row, as illustrated below:
Below the main pane there are two optional sections. The first one allows you to log an incident in the system associated with the test step. For failures this will typically be used to log a bug relating to the failure. However even if you pass a step you can still log an incident, which may be useful for logging non-critical cosmetic items that are not serious enough for a failure to be recorded. This tab also displays any pre-existing incidents that were associated with the test step being viewed.
The second tab displays a list of attachments that are related to the current test case and/or test step. This list initially contains any documents that have been attached to either the test case in general or the test step in particular. However as you perform the testing, you can attach additional documents to this list that are relevant to the test results (e.g. screenshots of an error page); these attached documents will be associated with both the test run itself and any incidents that are created.
Once all the test steps have passed, you will be automatically be taken to the first step in the next test; if it is the last test case being executed, the <Finish> button will be displayed instead.
If the actual results differ from those expected, you need to enter a description of the actual result observed and click one of Fail, Caution, or Blocked buttons (if enabled). If you don't enter anything into the actual result description box, the system will display an error message and re-prompt you again for input. By default, you will not see this prompt for passing a step, however product admins can force testers to enter an actual result when passing a step on the testing settings page.
In the inspector, the actual results text box is shown in the first tab below the information provided to the tester for a test step, as illustrated below:
In the table display mode, previously entered actual results are always visible (below the information provided to the tester for a test step). On attempting to mark a step as anything other than \"Pass\" the actual results text box will automatically be displayed.
You can also choose to manually show the actual results text box by selecting \"Actual Result\" option from the \"+\" dropdown menu.
"},{"location":"Spira-User-Manual/Test-Execution/#saving-screenshots-to-a-test-step","title":"Saving Screenshots to a Test Step","text":"Often, testers will want to provide visual documentation of what they have found during the testing process. A screenshot of what they are testing is a great way to do this. To add a screenshot to the results of a test step, first copy your screenshot to the clipboard. Next, paste the screenshot into the actual results text box.
"},{"location":"Spira-User-Manual/Test-Execution/#recording-extra-information","title":"Recording Extra Information","text":""},{"location":"Spira-User-Manual/Test-Execution/#incidents","title":"Incidents","text":"In addition to logging the result of a test step, you can optionally choose to generate a new incident at the point of logging the execution status of a test step. When the incident form is visible (see below) enter a name, select a type and fill in any other required fields. The description for the new incident is automatically populated from the test step details. To add the new incident either click the Add button at the bottom of the incident form, or clicking an execution status button for that test step.
The newly created incident will also be linked to the test step, allowing traceability from within the incidents module. The functionality for managing incidents is described in more detail in Incident Tracking.
If the inspector is visible, go to the \"Incidents\" tab. This will show any already linked incidents, show a detailed form for creating a new incident.
You can instead link the test step to an existing incident (by clicking the \"Link Existing Incident\" button). The following popup will be displayed, where you can either enter an incident ID (if known), or choose one from the list.
When in the table display mode, open the \"+\" dropdown menu to show options to either add a new incident or link an existing incident. Click on the option required to display the appropriate popup. Note that on clicking Add the incident will be immediately linked to the selected test step.
NOTE: via testing settings the product admin can require every test step to have an incident linked to it. If this setting has been enabled and the test step does NOT have an incident already AND you are not passing the step, in order to move to the next step you will need to create a new incident or link to an existing one.
"},{"location":"Spira-User-Manual/Test-Execution/#attachments","title":"Attachments","text":"If you need to attach documents to the test run (in addition to any screenshots), you can either attach a new or link an existing document. From the inspector, go to the \"Attachments\" tab to see any documents already linked, or to add a document as needed. In the table display mode, select either \"Add New Attachment\" or \"Link Existing Attachment\" from the \"+\" dropdown menu. See Attachments for additional information about how to the different available options (e.g. either upload a document, url link, or screenshot, or to link a document or from source code).
"},{"location":"Spira-User-Manual/Test-Execution/#tasks","title":"Tasks","text":"By default you will not see a Task tab during test execution. But a \"Tasks\" tab will be visible if:
The task tab allows the tester to quickly create tasks based on the current test step. These tasks are attached to the test run as a whole, so any previously entered tasks will be visible even when changing steps. Creating a task is a light touch way of communicating with others about your findings and alerting them that some work is likely required to fix or clarify a feature. It is quicker to enter and manage than an incident.
When creating a task the following fields are available:
Tasks are shown as a list of cards with their left edge showing their priority by color. On creation a task's status will be gray -- showing that no priority has yet been set. The title of the task can be clicked to open the details page for that task.
"},{"location":"Spira-User-Manual/Test-Execution/#leaving-the-test-execution-page","title":"Leaving the Test Execution Page","text":"If you are not able complete the whole test run in a single session, click the \"Leave\" button on the right of the progress bar---shown with an eject symbol (see below). This will return you to the page where you began the execution from. You can resume testing at a later date by locating the test run on your 'My Page' under 'My Pending Test Runs' and choosing to resume testing. Note that the system will remember every result you have logged, along with the last test step you were working so you can pick up right where you left off.
Once either all steps in a test have an execution status recorded, or at least one step in each test case has been recorded with any status other than \"Pass\" the test run can be finished. An orange button at the far right of the progress bar with a stop symbol will appear (see below). Clicking this button will save and archive the entire test run (so it can no longer be amended) and the page will automatically exit the test execution page.
"},{"location":"Spira-User-Manual/Test-Execution/#extra-test-execution-options","title":"Extra Test Execution Options","text":"There are a number of ways that some users may wish to alter the test execution page, depending on how they work. Options to change this are available from the menu button to the right of the display buttons.
The following actions are available from this dropdown menu:
Refresh: this simply reloads the test run data. This is useful if other people are working on different test cases within the same test run and you want to make sure that you have the most current information about the statuses they have recorded.
Always show test case: by default, the inspector only shows the test case details when the first test step of a test case is displayed. Checking this item will mean that the test case details will be shown on every test step.
Show custom properties: by default, only a handful of system fields are shown for the test case and test step. If your organization places important and relevant information into custom fields as well, you can check this item to make them visible in the inspector for every case and step. Note that these fields will not be visible in the table display mode.
Show guided tour: if you missed or want to revisit the visual guided tour of the test execution page, click this button to run the tour again.
"},{"location":"Spira-User-Manual/Test-Execution/#exploratory-test-execution","title":"Exploratory Test Execution","text":"As mentioned above, there are a number of conditions that must be satisfied for a test to run in exploratory mode. Exploratory testing is designed for relatively experienced testers and rather than to record the results of a pre-determined set of steps, to instead adjust and create the testing sequence during the act of testing itself. During exploratory testing test steps can be added, removed, edited, moved freely, at any time.
Care must therefore be taken that this form of testing and of recording the results of a test are used appropriately. The conditions set by the system are one means of limiting its use.
When starting exploratory testing the main screen will resemble the one below. Note that it looks broadly similar to that for standard test execution and is made up of three different areas:
All fields in the right hand details area, or the top part of the page can often be edited. Their contents and associated label will be grayed out if they are read only fields (for instance if they are information from a custom property). To edit a field, click on it, change the text as required, then click out of the field. The information will be automatically saved. Note that any test steps that come from a link test case will be read only and as such their contents cannot be edited, nor can they be deleted.
Just like with normal test execution, you can navigate between steps using the list of steps on the left; and steps can be passed, or failed using the execution status toolbar on the right hand section of the page. The unique actions you can take on test steps (besides editing their fields) are below:
add a step: click on the plus button beneath the list of test steps on the left
clone an existing step: when you hover a test step in the list, you will see a button appear on its right. Click on this to show a mini menu with an option to clone the step. This will create a clone, at the bottom of the list of test steps, with a blank actual result
delete an existing step: if you have more than one test step, any editable test step can be deleted. Click on the button for that step (as explained above) and click delete from the mini menu.
move an existing step: to move an editable step click and drag it to the desired location in the test step list.
Below the main detailed section there are two or three tabs. SpiraTest users will only see two tabs -- incidents and attachements. SpiraPlan users may see the additional tasks tab (if enabled by the product admin).
The toolbar at the top right of the page has a number of buttons:
When you click on the Testing > Test Runs global navigation link, you will be taken to the test run list screen illustrated below:
The test run list screen displays all the individual test executions performed in the current product, in a filterable, sortable grid. The grid displays the test run number together with fields such as execution status, name, assigned tester, execution date, test set, specified release, etc. The choice of columns displayed is configurable per-user, per-product, giving extensive flexibility when it comes to viewing and searching test runs.
In addition, you can view a more detailed description of the test run by hovering over the test run name hyperlink to display a \"tooltip\". If you click on this test run hyperlink, you will be taken to the test run details page described in the next section. Clicking on any of the pagination links at the bottom of the page will advance you to the next set of test runs in the list according to the applied filter and sort-order. There is also a drop-down-list at the bottom of the page which allows you to specify how many rows should be displayed in each page, helping accommodate different user preferences.
The sidebar shows a chart of the last 30 days of test run activity, broken down, for each day, by the test run status. This is a useful chart to quickly track the testing activity of the product -- this is not the same as overall product status. (For info, this chart matches that on the Product Homepage's Test Run Progress widget)
"},{"location":"Spira-User-Manual/Test-Run-Management/#refresh","title":"Refresh","text":"Clicking on the \"Refresh\" button simply reloads the test run list. This is useful as other people may be completing test runs, and after stepping away from the computer for a short-time, you can click this button to make sure you are viewing the most current test run list for the product.
"},{"location":"Spira-User-Manual/Test-Run-Management/#show-hide-columns","title":"Show / Hide Columns","text":"This drop-down list allows you to change the fields that are displayed in the test run list as columns for the current product. To show a column that is not already displayed, simply select that column from the list of \"Show...\" column names and to hide an existing column, simply select that column from the list of \"Hide...\" column names. This is stored on a per-product basis, so you can have different display settings for each product that you are a member of. The fields can be any of the built-in fields or any of the custom properties set up by the product owner.
"},{"location":"Spira-User-Manual/Test-Run-Management/#filtering-sorting","title":"Filtering & Sorting","text":"Read about how to create and manage filters, and how to sort the artifact list.
"},{"location":"Spira-User-Manual/Test-Run-Management/#printing-items","title":"Printing Items","text":"To quickly print a single test run or list of test runs you can select the items' checkboxes and then click the Print icon. This will display a popup window containing a printable version of the selected items.
"},{"location":"Spira-User-Manual/Test-Run-Management/#test-run-details","title":"Test Run Details","text":"When you click on any of the individual test runs in the test run list, you are taken to the Test Run details page (not to be confused with the Test Case details page) shown below:
This page consists of three panes:
The left hand navigation pane displays a list of related test runs with a color indicator for their current execution status. The display dropdown will let you choose whether the list contains test runs that are for the same release, test case or test set, or are just a filtered/unfiltered list based on your last search in the main test run list page.
The top right area shows headline information about the test run details of the test run itself
The main pane on the right displays tabs for detailed information about the test run, and its associations. The overview tab is initially loaded and shows the name, description, release, test set, estimated and actual duration, tester name, test run type, automation host fields, along with others, including custom fields. Underneath this is shown the list of test run steps, and any console output from a test automation engine such as Rapise, NUnit, JUnit, QTP, or Selenium.
There is a button on the main test run toolbar called 'Re-Test\". If you click this button, SpiraPlan will launch the test execution wizard for this specific test case, with current release and/or test set already selected for you. This is a handy way of quickly re-running a failed test that has been addressed by the developers. NOTE: this button will not display if the product does not allow you to execute test cases (instead only letting you execute test sets).
"},{"location":"Spira-User-Manual/Test-Run-Management/#editing-a-test-run","title":"Editing a Test Run","text":"When reviewing the test run, you may find that you need to change the results of the test run (e.g. the user selected the wrong release or custom property value). Many of the fields are editable at a later date, and to make changes, just modify the appropriate fields and click any \"Save\" button.
"},{"location":"Spira-User-Manual/Test-Run-Management/#deleting-the-test-run","title":"Deleting the Test Run","text":"If you need to delete a test run that was erroneously captured, all you need to do is click on the link to access the invalid test run and then click the \"Delete\" button to remove it from the system. This will then force the system to update the status of the test case itself from the other logged test runs.
"},{"location":"Spira-User-Manual/Test-Run-Management/#test-run-steps","title":"Test Run Steps","text":"In the case of a manual test run, this section displays all the steps of the test case as they appeared during the test run in question. This means that if the test steps were changed after running the test, the list here will reflect the original information.
Each test run step is displayed along with the description, expected result, suggested sample data, a link back to the current version of the test step in question, the actual result and the execution status for this step in this particular test run. Where an actual result was recorded, an additional \"View Incidents\" button will be displayed. This allows you to view any incidents that are associated with this particular test run step:
Clicking on the link will open up a popup dialog box that displays a list of all the incidents associated with the selected test run step. Each of the incidents listed will reflect the most up-to-date information regarding that incident, including its type, status, priority, name, assigned owner, detection date and who first detected it. Clicking on the incident name will take you to the details page for that incident, which is described in Incident Tracking > Incident Details.
If you have modify all permissions for test runs you will be able to click the small link button at the right of the test run step. This is the \"link existing incident\" button. This will display a popup that lets you link an existing incident to the selected test run step.
"},{"location":"Spira-User-Manual/Test-Run-Management/#console-output","title":"Console Output","text":"In the case of an automated test run, this tab will display the details of the test run as reported from the test runner application. These details will vary depending on the type of automated tool being used, but typically they include the name of the automated test runner, the number of assertions raised, the name of the corresponding test case in the tool, the status of the test run and a detailed error message, and the stack-trace in the case of a failure. An example test run as reported from the NUnit automated test runner is illustrated below:
Details on how to use SpiraPlan\u00ae in conjunction with an automated testing tool are provided in the SpiraPlan\u00ae Automated Testing Integration Guide, which can be downloaded from the Inflectra\u00ae website.
"},{"location":"Spira-User-Manual/Test-Run-Management/#attachments","title":"Attachments","text":"Read about how the attachments tab works
"},{"location":"Spira-User-Manual/Test-Run-Management/#history","title":"History","text":"Read about how the history tab works
"},{"location":"Spira-User-Manual/Test-Run-Management/#incidents","title":"Incidents","text":"This tab displays the list of incidents associated with the current test run. The incidents have either been linked during test execution or can be linked to a test run step from the Overview tab of the test run details page.
Each incident is listed together with (by default) the type, status, priority, name, owner, detector, detection date and a link to the actual incident details. On this tab you can perform the following actions:
This tab is only visible to users of SpiraPlan. It shows the list of tasks associated with the current test run. Tasks can only be added to a test run created from an exploratory test case. These tasks will have been logged during the execution of the test.
"},{"location":"Spira-User-Manual/Test-Set-Management/","title":"Test Set Management","text":""},{"location":"Spira-User-Manual/Test-Set-Management/#test-set-list","title":"Test Set List","text":"As well as being able to organize test cases into folders, you can also create separate groupings of test cases called test sets which can then be assigned to testers as a package. To view the list of test sets for a product, click on Testing > Test Sets in the global navigation:
The test set list consists of hierarchical list of all the test sets in the current product organized into folders. The structure is very similar to the folder structure in Microsoft Windows\u00ae Explorer, and users will find this very familiar and intuitive to use. A folder tree is on the left hand side---with triangle icons to expand / collapse each folder. Contents of the selected folder (the one marked in bold on the folder tree) are shown on the right hand side.1
When you create a new product, this list will initially be empty, and you will have to use the \"New Test Set\" button to start adding test sets to the system.
Each test set is listed along with the number of test cases contained (in parenthesis), the aggregate execution status of the contained test cases (using a graphical bar-chart), the date that the test set has been scheduled to be executed (planned date), the date that it was last executed, the person currently assigned to execute the test set, the status and the test set id. Clicking on a test set's hyperlink will take you to the test set details page for the item in question.
Note: the test set status is separate from the execution status of the individual test cases and represents where the test set is in its lifecycle:
Clicking on the \"Delete\" button deletes the currently selected test sets. It will delete the association between the test set and its contained test cases, but it will not delete the test cases themselves.
"},{"location":"Spira-User-Manual/Test-Set-Management/#refresh","title":"Refresh","text":"Clicking on the \"Refresh\" button simply reloads the list of test sets. This is useful if other people are making changes to the test set list and you want to make sure that you have the most current version.
"},{"location":"Spira-User-Manual/Test-Set-Management/#focus-on","title":"Focus On","text":"The \"Focus On\" button is a useful when you have performed a filter on the list of test sets and then wish to quickly navigate to the folder of a particular test set shown in the list. After selecting a test set, clicking the button will move the left hand folder tree to the folder that contains the selected test set. It will also change the list view on the right to show all of the test sets within that folder (i.e. the selected test set and its siblings).
"},{"location":"Spira-User-Manual/Test-Set-Management/#edit","title":"Edit","text":"Each test set in the list has an \"Edit\" button in its right-most column. When you click this button, double-click on any of the cells in the row, or select a row and click the \"Edit\" button in the toolbar at the top of the page. This will change the item from \"View\" mode to \"Edit\" mode. The various columns are made editable, and \"Save\" and \"Cancel\" buttons are displayed in the last column:
If you click \"Edit\" on more than one row, the \"Save\" buttons are only displayed on the first row, and you can make changes to all the editable rows and then update the changes by clicking the one \"Save\" button. Also, if you want to make the same change to multiple rows (e.g. to change the owner of five test sets from \"Fred Bloggs\" to \"Joe Smith\"), you can click on the \"fill\" icon to the right of the editable item, which will propagate the new value to all editable items in the same column.
If you want to edit lots of items, first select their checkboxes and then click the \"Edit\" button on the same row as the Filters and it will switch all the selected items into edit mode.
When you have made your updates, you can either click \"Save\" to commit the changes, or \"Cancel\" to revert back to the original information. Alternatively, pressing the <ENTER> key will commit the changes and pressing the <ESCAPE> key will cancel the changes.
"},{"location":"Spira-User-Manual/Test-Set-Management/#show-hide-columns","title":"Show / Hide Columns","text":"This drop-down list allows you to change the fields that are displayed in the test set list as columns for the current product. To show a column that is not already displayed, simply select that column from the list of \"Show...\" column names and to hide an existing column, simply select that column from the list of \"Hide...\" column names. This is stored on a per-product basis, so you can have different display settings for each product that you are a member of. The fields can be any of the built-in fields or any of the custom properties set up by the product owner.
"},{"location":"Spira-User-Manual/Test-Set-Management/#filtering-sorting","title":"Filtering & Sorting","text":"Read about how to create and manage filters, and how to sort the artifact list.
"},{"location":"Spira-User-Manual/Test-Set-Management/#viewing-the-test-status-for-a-release","title":"Viewing the Test Status for a Release","text":"By default, when you view the list of test sets, it will display an aggregate status for all releases of the product. This means that the list shows:
If you change what release to display data for, by selecting a release from the dropdown in the top right, the list will show:
As a shortcut, when you select a specific release for viewing, subsequent execution of any of the test sets via the Tools > Execute Tests menu option will default the test run to the selected release.
"},{"location":"Spira-User-Manual/Test-Set-Management/#copying-test-sets","title":"Copying Test Sets","text":"To copy one or more test sets, select the check-boxes of the test sets (or test set folder) you want to copy and then select Edit > Copy Items from the menu. This will copy the current test set / test set folder selection to the clipboard. Then select the place you want the test sets to be inserted and choose the Edit > Paste Items option.
The test sets will now be copied to the destination you specified. The name of the copied test sets will have \" - Copy\" added to the end to distinguish them from the originals. If you are copying test set folders, only the top level folders' name(s) will will have \" - Copy\" added to the end - the new copies of items in the folder will have the same names as the originals.
"},{"location":"Spira-User-Manual/Test-Set-Management/#moving-test-sets","title":"Moving Test Sets","text":"There are two options for moving test sets or folders:
Once you have the test set/folder positioned at the correct place that you want it inserted, just release the mouse button. To move multiple items simply select their checkboxes and then drag-and-drop one of the selected items.
To quickly print a single test set, test set folder or list of test sets you can select the items' checkboxes and then click Tools > Print Items. This will display a popup window containing a printable version of the selected items.
Alternatively you can save the selected items into a number of formats, available via the Tools dropdown.
"},{"location":"Spira-User-Manual/Test-Set-Management/#right-click-context-menu","title":"Right-Click Context Menu","text":"SpiraPlan\u00ae provides a shortcut -- called the context menu - for accessing some of the most commonly used functions, so that you don't need to move your mouse up to the toolbar each time. To access the context menu, right-click on any of the rows in the test set list and the following menu will be displayed:
You can now choose any of these options as an alternative to using the icons in the toolbar.
"},{"location":"Spira-User-Manual/Test-Set-Management/#test-set-details","title":"Test Set Details","text":"When you click on a test set item in the test set list described in the previous section, you are taken to the test set details page illustrated below:
This page is made up of three areas:
The navigation pane consists of a link that will take you back to the test set list, as well as a list of the peer test sets to the one selected. This latter list is useful as a navigation shortcut; you can quickly view the detailed information of all the peer test sets by clicking on the navigation links without having to first return to the test sets list page. The navigation list can be switched between three different modes:
The operations toolbar lets you, amongst standard operations like save and delete:
create a duplicate of the current artifact by clicking Clone - note that:
export to a number of files formats or print it via one of the options in the Tools dropdown menu
Execute button will execute all the test cases in the set against the release specified in the test set and then take you to the test execution screenAt the top of the pane, you will see the test set's:
Initially the pane will be set to the \"Overview\" tab, but it can be switched to \"Test Runs\", \"Attachments\", \"Incidents\" and \"History\" tabs. Each of these is described separately below.
"},{"location":"Spira-User-Manual/Test-Set-Management/#overview-details","title":"Overview -- Details","text":"The top part of this tab displays the various standard fields and custom properties associated with the test set. Fields (both standard and custom) are grouped under the collapsible headings (marked by orange text and underline) in the screenshot below. For instance, all fields regarding releases are in the \"Releases\" group and dates are grouped together in the \"Dates and Times\" area.
The Display For field in the \"Releases\" section tells you what release execution status results are displaying for the test set. This field controls the results for the test set overall and also for its individual test cases. This field is read only. To change it, you must use the \"Display For\" dropdown on the list page.
The Detailed Information section contains the long, formatted description of the test case, as well as any rich text custom fields. You can enter rich text or paste in from a word processing program or web page. Clicking on the shaded areas of one of these detailed fields will display the rich text toolbar.
If you have test configuration sets defined in your product, you can assign them to a specific Test Set and use them for both manual and automated testing by setting the Configuration dropdown value. If you have a test configuration associated with the test set, when you execute the test set, SpiraPlan will generate a test run entry for each of the test configuration entries multiplied by each of the test cases in the set.
The Description section contains the long, formatted description of the test set. You can enter rich text or paste in from a word processing program or web page.
Manual or Automated Test Sets
Test Sets can be marked as either for \"Manual\" or \"Automated\" test runs (via the \"Type\" field).
How do you say when the test set should execute? You have two options.
Use the Planned Date field:
Use the Schedule on Build field:
Test cases can have parameters associated with them. This enables one test case to be called several times and have different parameters passed in each case, making the operation different. E.g. you could have a generic \"login to application\" test case that others call as an initial step, which could be provided with different login information depending on the calling test case. In addition these parameters may be used by certain test automation engines.
The Parameters section on the test set page lets you set a shared value for all of the parameters contained within the different test cases of the test set. The screenshot below shows that there are three parameters contained in the test cases that have been set at the test set level. In this example, every case that has a Parameter called 'browserName' will have its value set to 'Safari'. This is a quick way of setting values for many test cases at once. Test Set Values will override any default values of a Parameter (defined for each specific test case).
You can add any additional Parameters not already set by clicking on the \"Add Parameter Value\" button. In this example, you can see that one of the parameters not yet set is called 'url'.
You can also delete an existing Parameter specified for the whole test set by clicking the \"Delete\" button in the Operations column of the Parameter in question. Clicking the \"Edit\" button will let you alter the Test Set Value.
Note that the Default Value is derived from the test cases that use a specific Parameter. It is shown in this table for information only---to help testers know what value will be run in the absence of specifying a Test Set Value.
"},{"location":"Spira-User-Manual/Test-Set-Management/#overview-test-cases","title":"Overview - Test Cases","text":"This section displays the list of test cases currently contained within the test set. You can add, remove, reposition and remove test cases from the list. The execution status displayed next to each test case is the most recent execution status of the test case when run in the context of the current test set and, if specified, the release we are displaying data for.
To move the test cases, click the test case icon and drag it to the appropriate position in the list.
To modify an existing Test Case click the \"Edit\" button in the right-most column, or double-click on the cells in the row. That will switch the selected row into Edit mode. The Owner and Planned Date fields (if visible) can then be set at the test case level. Setting the owner field here is useful if you want the different test cases in the set to be executed by different testers (e.g. in integrated, scenario tests).
To add a new test case to the Test Set, click on the \"Add\" button to display the panel:
First, select the folder containing the test cases desired. You can then select the checkboxes of the individual test cases that you want to add to the test set (note: clicking the checkbox in the header row of the table will select ever test case in the currently selected folder). Once you have selected the desired items, click the \"Save\" button to add them to the test set.
As discussed above in Overview - Parameters, test cases can have parameters defined with specific values. These are created on the Test Case details page. If you need to specify different values for a parameter for different test cases in the test set, you can override both any default parameter values and any test set parameter values. To do so, click \"Edit Parameters\" for the required test case in this view. You can do this by either select the checkbox of a test set and click \"Edit Parameters\" at the top of the section, or right-click on the test case and choose \"Edit Parameters\":
You can then specify the values of the parameters that the test set will pass to this specific test case. Once you have entered / modified the values, click \"Save\" to commit the changes.
Matching execution status of test cases to the test set
The execution status shown for the test set at the top of the page is calculated from the most recent test run of the whole set for the release being displayed for (or most recent across all releases, if displaying for all releases). The execution status for the test cases in the test set is calculated in the same way.
As you change your test set over time, you may add and remove test cases. The list of test cases is always the currently included test cases. This means that if you are showing results for an old release, and since then you have REMOVED test cases from the test set, you will not see those test cases and their execution statuses in this list. The same happens if you have since ADDED test cases: they will show as Not Run, even if the test set's execution status has no Not Runs. When it was executed these new test cases weren't there to be run.
In this way, the overall test set execution status may not always match what you see in the test case list.
"},{"location":"Spira-User-Manual/Test-Set-Management/#overview-comments","title":"Overview - Comments","text":"Read about how the comments works
"},{"location":"Spira-User-Manual/Test-Set-Management/#test-runs","title":"Test Runs","text":"This tab displays the list of all the test runs executed against the test set. Each test run is listed together with the date of execution, the name of the test case, the name of the tester, the release/version of the system that the test was executed against, the overall execution status for the test case in that run and a link to the actual test run details. In addition, you can choose to display any of the custom properties associated with the test run.
The \"Show/hide columns\" drop-down list allows you to change the fields that are displayed in the test run list as columns. To show a column that is not already displayed, simply select that column from the list of \"Show...\" column names and to hide an existing column, simply select that column from the list of \"Hide...\" column names. The displayed columns can be any standard field or custom property.
You can also filter the results by choosing items from the filter options displayed in the sub-header row of each field and clicking the \"Filter\" button. In addition, you can quickly sort the list by clicking on one of the directional arrow icons displayed in the header row of the appropriate field.
"},{"location":"Spira-User-Manual/Test-Set-Management/#attachments","title":"Attachments","text":"Read about how the attachments tab works
"},{"location":"Spira-User-Manual/Test-Set-Management/#history","title":"History","text":"Read about how the history tab works
"},{"location":"Spira-User-Manual/Test-Set-Management/#incidents","title":"Incidents","text":"This tab displays the list of incidents associated with the current test set. Each incident will either have been: created during the execution of a test case in the test set (and are thereby linked to one of the test runs); or manually linked to one of the test steps in a test case of the set.
when navigating to folders (for all artifacts that support them), the URL in your browser's address bar will change. Each folder has a unique, sharable URL that you can give to someone to display the list of artifacts with the appropriate folder selected. You can also open up multiple folders in different browser tabs and easily toggle between them from the same browser.\u00a0\u21a9
This section outlines how you can log into SpiraPlan\u00ae, view your personalized home-page that lists the key tasks that you need to focus on, and drill-down into each of your assigned products in a single dashboard view. In addition to your personal homepage, each of your products has its own dashboard that depicts the overall product health and status in a single comprehensive view.
"},{"location":"Spira-User-Manual/User-Product-Management/#login-screen","title":"Login Screen","text":"Upon entering the SpiraPlan\u00ae URL provided by your system administrator into your browser, you will see the following login screen:
You need to enter your given user-name and password into the system in the appropriate boxes then click the Log In button to gain access to the application. Normally you only remain logged in to the application whilst in active use, and you will be asked to log-in again after either closing the browser or 20 minutes of inactivity. To prevent this, and to stay logged-in to SpiraPlan\u00ae regardless of browser window closing or inactivity, select the \"Keep me logged in\" check-box before clicking the Log In button. Note that this setting is specific to each individual computer you are logging-in from, and that it will be reset when you explicitly log-out with the log-out link.
If you have enabled 2-step authentication once you have entered your username and password correctly you will need to enter a valid one-time password.
If for any reason you are unable to login with the provided username/password combination, and error message will be displayed. If you cannot remember the correct log-in information, click on the \"Forgot your password\" link and your password will be emailed to the email address currently on file. The reset password screen is illustrated below:
If you don't have a SpiraPlan\u00ae account setup, clicking on the \"Register for an account?\" link will take you to a form that you need to fill-in, which will be forwarded to the system administrator, who will need to approve your account before it is active in the system. This screen is illustrated below:
In addition, the system will prevent you logging on to the system with the same username at the same time on multiple computers. This is to avoid the system getting confused by a user trying to make contradictory actions at the same time. If for any reason you do try and log in to the system when you already have an active session in progress, you will see the following screen:
You have two choices: you can either click the \"Log Out\" link and try logging in as a different user, or if you want to log-off any other active sessions (e.g. you closed the browser and the session is still listed as active), simply click the \"Sign Off The Other Locations\" link, and you will be logged in to the application.
Since SpiraPlan\u00ae is licensed to organizations for a specific number of concurrent users -- unless they have purchased an unlimited Enterprise license -- only a fixed number of users may be active at the same time. So, for example if an organization has a five (5) concurrent user license and a sixth user tries to log-in, they will be presented with the following screen:
This means that one of the other users who is already logged-in, needs to click the \"Log Out\" button so that one of the concurrent licenses is freed for your use. If the user has logged out by closing the browser, the system may not have detected the logout. In this case, the other user needs to log back in, and then click the \"Log Out\" link.
"},{"location":"Spira-User-Manual/User-Product-Management/#logging-in-using-an-external-provider","title":"Logging in Using An External Provider","text":"If your organisation uses a Single Sign On / OAuth provider like Okta or Google, underneath the standard username and password field you will see a button for each enabled provider.
To login using your account with this provider:
Login. You are now connected to this provider!Once you have a SpiraPlan user that authenticates with the provider, to log in to Spira click the provider button on the login page.
"},{"location":"Spira-User-Manual/User-Product-Management/#my-page","title":"My Page","text":"Once you have successfully logged in, you will initially be taken to your personalized home page called \"My Page\". Please note, that the very first time you log in you will be asked if you want to take a quick orientation tour of the application (which will look similar to the screenshot below).
Note that once you have successfully logged-in and chosen a product, SpiraPlan\u00ae remembers this selection, and on subsequent log-ins will automatically select that product, and highlight it for you in the \"My Products\" list.
Your homepage contains all the information relevant to you---consolidated onto a single page for you to take immediate action. By default the page lists the information for all products that you are a member of. However, you can choose to filter by the current product, to get a more focused list.
Next to some of the widgets is an RSS icon (
), this allows you to subscribe to the information as a Really Simple Syndication (RSS) newsfeed. This can be useful if you want to be notified about recently assigned items without having to setup email notifications or being logged into SpiraPlan continuously. If you don't see an RSS icon next to the widgets on your My Page it means that you have not enabled RSS newsfeeds in your profile. For more details on configuring your RSS preferences, please refer to My Profile.
Initially the page is loaded in 'view mode' which means that the various 'widgets' on the page are displayed with minimum visual clutter (no toolbars or control icons) that makes it easy to scan the items on the page and see what work has been assigned. To switch the page to 'edit mode', click on the button with the cog icon () on the right:
In this mode, each of the 'widgets' displayed on the page can be minimized by clicking on the arrow icon () in the top-left of the window, or closed by clicking-on the cross icon () in the top-right of the window. This allows you to customize your page to reflect the types of information that are relevant. If you have closed a widget that you subsequently decide you want to reopen, you can add them back to the page display by clicking the \"Add Items\" button at the top of the page. In addition, the various widgets have a \"settings\" icon () that allows you to customize how that widget appears. The settings are specific to each widget and in general allow you to specify how many rows of data are displayed and what columns are displayed.
You can move and reposition the various widgets on the dashboard by clicking the mouse on the title bar of the widget you want to move and dragging it to the desired location. This change will be remembered when you next login to the system. Once you have the dashboard configured the way you like it, you can click \"Return to Normal View\" to switch back to 'view mode'.
When you load your 'My Page' for the first time it will consists of the following main elements:
However these are not the only widgets available. If you click on the \"Add/Remove\" items hyperlink it will display the list of any additional widgets that are available:
You can add the additional widgets by selecting the appropriate checkbox, choosing the destination location (left side vs. right side) and then click the [Add] button. The additional widgets available in the My Page are:
This widgets shows the most recent products you have visited. Each time you visit a page for a different product the list of most recent products is updated. By default, it shows the five most recent products -- this can be edited in the widget edit controls to any number fifty or less.
For each recent product visited, the widget shows name for:
Each product name is a link to that product's home page. The program and portfolio names are links to the relevant home pages if you have access to view those home pages.
"},{"location":"Spira-User-Manual/User-Product-Management/#recent-artifacts","title":"Recent Artifacts","text":"This widgets shows the most recent artifacts you have visited. If you last looked at Requirement X in Product Y then Requirement X will show at the top of the list. The widget will show specific artifacts across all artifact types and all products. By default, it shows the five most recent artifacts -- this can be edited in the widget edit controls to any number fifty or less.
For each recent artifact, the widget shows:
If \"All Products\" is selected at the top of the My Page, the list shows the most recent artifact across all products.
If \"Current Product\" is selected at the top of the My Page, the list shows only the recent artifacts that are from the current product (if any).
"},{"location":"Spira-User-Manual/User-Product-Management/#my-saved-searches","title":"My Saved Searches","text":"This section lists any filters/searches you have saved from the various artifact list screens throughout the application. This allows you to store specific combinations of searches that you need to perform on a regular basis (e.g. display all newly logged incidents, display all requirements that are completed but have no test coverage).
The name of the saved search is displayed along with an icon that depicts which artifact it's for and the product it refers to. Clicking on the name of the saved search will take you to the appropriate screen in the product and set the search parameters accordingly. Clicking the \"Delete\" button next to the saved search will delete it. Clicking on the RSS icon will allow you to subscribe to the specific search so that it will be displayed in your RSS newsreader. This allows you to setup customized lists of information that can be displayed outside of SpiraPlan.
"},{"location":"Spira-User-Manual/User-Product-Management/#my-assigned-requirements","title":"My Assigned Requirements","text":"This section lists all the requirements you have been made owner of, across all the different products you are a member of. This typically means that the product manager has assigned you to be responsible for either developing the supporting test cases or decomposing the requirement into its detailed work breakdown structure of product tasks. The requirement name is displayed, along with its status (requested, accepted, in-progress, etc.) and its importance. Requirements are included based on their importance: the list is ordered by importance (highest at top) and requirements with the same importance are ordered by their IDs.
"},{"location":"Spira-User-Manual/User-Product-Management/#my-assigned-test-cases","title":"My Assigned Test Cases","text":"This section lists all the test cases you are the owner of, across all products you are a member of. This typically means that the product or test manager has assigned you to be responsible for executing these test scripts. Test cases are included based on their last execution status and date: the list is ordered by execution status (failed at the top), test cases with the same execution status are ordered by last execution date, and if those match, then by their IDs. For each test case in the list you can see:
If you edit the widget you can: change the number of rows to show; show or hide the last executed date; and show or hide and the workflow status.
"},{"location":"Spira-User-Manual/User-Product-Management/#my-assigned-test-sets","title":"My Assigned Test Sets","text":"This section lists all the test sets (groups of test cases) you are the owner of, across all products you are a member of. This typically means that the product or test manager has assigned you to be responsible for executing the test cases contained within the test set against a specified release of the system under test. Test sets are included based on their planned date: this list is ordered by planned date (oldest at top) and test sets with the same planned are ordered by their IDs. For each test set in the list you can see:
This section lists any test runs that you started executing in the test case module but haven't yet completed. Until a test case or test set is fully executed, a pending test run entry is stored in the system so that you can continue execution at a later date.
Any pending test run can be either deleted or resumed by clicking on the appropriate button. In addition, there is the option to reassign the test run to another user that is a member of the product.
"},{"location":"Spira-User-Manual/User-Product-Management/#my-assigned-tasks","title":"My Assigned Tasks","text":"This section lists all the product tasks that you have been made the owner of across all the different products you are a member of. This typically means that the manager of the product in question has assigned development tasks to you that need to be completed so that a release can be completed and/or a requirement can be fulfilled. The tasks are listed by priority: tasks with no priority at the top, and after that the highest priority tasks. In addition, each task is displayed with a progress indicator that graphically illustrates its completion against schedule. See Task Tracking -- task management for details of the different progress indicators.
Clicking on the task name hyperlink will take you to the task details page. This page will describe the task in more detail, illustrate which requirement and release it is associated with, and also allow you to view the change log of actions that have been performed on it.
"},{"location":"Spira-User-Manual/User-Product-Management/#my-assigned-incidents","title":"My Assigned Incidents","text":"This section lists all the open incidents you are the owner of, across all the different products you are a member of. This typically means that the product manager has assigned you to be responsible for resolving the incident. In the case of a bug, this can mean actually fixing the problem, whereas for other incident types (e.g. training item) it may mean simply documenting a workaround. In either event, this section highlights the open incidents you need to manage, ranked by priority (incidents with no priority are at the top) and categorized by type, with the open date displayed to give you a sense of the age of the incident.
Clicking on the incident name hyperlink takes you to the incident details page) that describes the incident in more detail, and allows you to add new information or change its status to indicate actions taken. In addition, if you position the mouse pointer over the name of the incident, a more detailed description is displayed as a \"tooltip\".
"},{"location":"Spira-User-Manual/User-Product-Management/#my-detected-incidents","title":"My Detected Incidents","text":"This section lists all the open incidents that you have detected, across all the different products you are a member of. These incidents are not necessarily ones that you need to take an active role in resolving, but since you were the originator -- either by executing a test case or just logging a standalone incident -- you can watch them to make sure that they are resolved in a timely manner. The incidents shown are ranked by last updated date (most recent at the top).
Clicking on the incident name hyperlink takes you to the incident details page) that describes the incident in more detail, and allows you to add new information or change its status to indicate actions taken. In addition, if you position the mouse pointer over the name of the incident, a more detailed description is displayed as a \"tooltip\".
"},{"location":"Spira-User-Manual/User-Product-Management/#quick-launch","title":"Quick Launch","text":"This widget allows users to quickly record a new incident in any of the products that they belong to. It's a shortcut that avoids having to first select a product, go to Tracking > Incidents and then click \"New Incident\". Instead you simply choose the product from the dropdown list and click the arrow icon to bring up the new incident creation screen.
"},{"location":"Spira-User-Manual/User-Product-Management/#my-contacts","title":"My Contacts","text":"This widget displays a list of any other users in the system that you have listed as a personal contact:
Each user is displayed along with their graphical avatar, department and a colored indicator that lets you know if they are online or not. If they are online you can then send them an instant message (which will be described later in Global Navigation. To remove an existing contact, just click on the 'Remove' button. To add a new user, simply locate them in the Tracking > Resources page and then use the <Add As Contact> button.
"},{"location":"Spira-User-Manual/User-Product-Management/#my-saved-reports","title":"My Saved Reports","text":"This section lists any reports you have saved from the reports center. This allows you to store specific combinations of report elements, format, filters and sorts (see the section on Reporting for more details on how to configure a report) for reports that you need to run on a regular basis.
"},{"location":"Spira-User-Manual/User-Product-Management/#my-subscribed-artifacts","title":"My Subscribed Artifacts","text":"This widget displays a list of all the artifacts in the system that you have subscribed to (by clicking on the Subscribe icon on the item). You can display the item by simply clicking on the hyperlink. In addition, if changes are made to any of the artifacts an email notification will be sent to you. You can click on the \"Unsubscribe\" button to remove the item from this list.
"},{"location":"Spira-User-Manual/User-Product-Management/#my-news-feeds","title":"My News Feeds","text":"This widget allows you to subscribe to an external newsfeed and have the results be displayed inside SpiraPlan. By default it will be set to the newsfeed from the Inflectra website that displays a list of recent company and product announcements. You can add multiple instances of the widget to the dashboard, allowing you to read multiple news sources at once. Typical uses for this widget are to add news from product management and testing news sites/blogs or to add information from other tools in your organization that can display their data in RSS format.
"},{"location":"Spira-User-Manual/User-Product-Management/#my-assigned-risks-spiraplan-only","title":"My Assigned Risks (SpiraPlan only)","text":"This section lists all the risks you are the owner of across all the different products you are a member of. Clicking on the risk name hyperlink will take you to the risk details page. This page will describe the risk in more detail. Risks are shown ranked by their exposure (the highest exposure at the top), risks with the same exposure are ordered by their IDs.
"},{"location":"Spira-User-Manual/User-Product-Management/#my-assigned-documents","title":"My Assigned Documents","text":"This section lists all the documents you are the owner of across all the different products you are a member of. Clicking on the risk name hyperlink will take you to the documents details page. This page will describe the documents in more detail. The list is ranked by last updated date.
"},{"location":"Spira-User-Manual/User-Product-Management/#global-navigation","title":"Global Navigation","text":"Regardless of the page you are on, SpiraPlan\u00ae will always display the global navigation bar, consisting of a number of different sections, depending on the user and where they are in the system.
Under some of the icons and headings are secondary menu options that display when you click on the section in question. The sections and menus available in the global navigation are show below:
Artifacts Selector: when visible, this shows the name of the current artifact for the current workspace. Clicking it will show all your available artifacts and clicking any of these will change you to that artifacts main page. For product workspaces these artifacts are grouped as follows:
Reporting
User Profile Icon
Administration Icon: This is visible if you are a system administrator, or if you are an owner/administrator of the current workspace or its template. Clicking the icon will display the relevant administration menu. This is described in the separate SpiraPlan Administration Guide.
SpiraPlan includes a global search that can be used to search across product and artifact type for items that include the entered keywords in either the name or description field. Clicking on the search icon in the global navigation will let you type in your search term. You will also see a popup below the search box that gives you quick access to recent artifacts you have looked at, and also to your most recent searches. After you search for something you see all matching results:
You can search for individual keywords by entering them in the search box and clicking the arrow button on the right. You can search for phrases by enclosing the words in double quotes. You can also search for a specific artifact by its unique two-letter prefix and ID number.
For example, searching on book name will find any artifacts that include either of the two words book and name in the name or description. Searching on \"book name\" will only return items that have that exact phrase in either the name or description. Searching on TC2 will display just the Test Case with ID=2:
When you get a list of search results, you can choose to order by relevance (the default) or by most recent. Searching by relevance finds the artifacts that have the greatest match with the keywords:
The search by date is useful when you want to find recent items that match the search keywords:
In addition, you can filter the results by artifact type and/or product to narrow down the search:
For example, if you filter by requirement, the list of results will be narrowed accordingy:
"},{"location":"Spira-User-Manual/User-Product-Management/#log-out","title":"Log Out","text":"Clicking on the \"Log Out\" link will immediately log you out of your current session and return you to the login page. If you had set the \"Keep Me Logged In\" option during your previous login, that setting will be reset; so if you want to avoid having to keep logging-in, you'll need to re-check that box during your next log-in.
"},{"location":"Spira-User-Manual/User-Product-Management/#documentation","title":"Documentation","text":"Clicking on this link on any page will bring up the online version of this manual shown below:
Clicking on any of the triangles expand links in the left hand table of contents will open up the detailed list of topics for each of the main areas of the system. In each area, clicking on one of the individual links will open the appropriate section in the help manual. By default, the reading-pane will open to the help item that is most closely related to the screen you happened to be on when you clicked the \"Help\" link.
You can search the index by using the \"Index\" tab.
If you want to share a specific help page with a colleague in your organization, send them the url from the address bar.
"},{"location":"Spira-User-Manual/User-Product-Management/#choosing-a-workspace","title":"Choosing a Workspace","text":"Workspaces in SpiraPlan set out the scope for the data you want to view and interact with. The most common workspace type is a product:
A product contains all the requirements, sprints, defects, and tests associated to it.
Programs are groups of products, where you can look across all the products in that program at once
Choosing, for example, a Product or Program from the list of your assigned workspaces in the drop-down-menu allows you to quickly and easily jump between workspace regardless of the page you happen to be on. When you choose a new workspace, you will be taken to the same page in the selected workspace (assuming that you have permissions to view that page). Any workspace with a little cog at the end is a workspace that you are an owner/admin of.
You can use CTRL+click to open the new product in a separate browser tab:
"},{"location":"Spira-User-Manual/User-Product-Management/#show-onboarding-tours","title":"Show Onboarding Tours","text":"When you first login to SpiraTeam, the system will show you a welcome page, together with a tour that walks you through the key features of the application. If you would like to see that again, you need to click on the \"Show Onboarding Tours\" option, under the user profile menu. SpiraPlan will then display the onboarding tour main dialog again:
You can click 'No Thanks to dismiss it, or 'Yes Please' to start the tour.
"},{"location":"Spira-User-Manual/User-Product-Management/#instant-messenger","title":"Instant Messenger","text":"The Spira instant messenger is available in both SpiraTeam\u00ae and SpiraPlan\u00ae and allows you to send short messages instantaneously to other users in the system. You can see the status of other users by looking for the small green circle next to the list of users in the 'My Contacts' widget as well as the various user fields in the system:
When a user is online and available to communicate with, the small circle will be filled-in green. If you click on the green circle, it will open up the instant messenger window for that user:
You can then enter in a message to the other user, which will then cause a conversation window to open inside their web browser with your message displayed. The other user can then enter in their responses, allowing the two users to have a real-time conversation:
To make it easier to see what's new, all unread messages are displayed in a message box with a darker shade. In addition, the user's avatar image is displayed at the start of each message group.
If the message window appears on a SpiraPlan\u00ae window that contains a specific artifact (e.g. a requirement, test case, task, etc.) there will be the option to 'Post as Comments'. If you click this option, any messages selected with a checkbox will be automatically posted to the current artifact as comments. This is useful if you have a conversation related to a specific item and you want to have the outcome permanently recorded as part of the audit trail. Otherwise, instant messages will be automatically purged from the system after 90 days.
"},{"location":"Spira-User-Manual/User-Product-Management/#my-profile","title":"My Profile","text":"When you click on the \"My Profile\" button (the top item in the user dropdown) in the global navigation, you will be taken to the page in the system that allows you to view and edit your personal profile:
You can change your user information including your first-name, last-name, middle-initial, avatar icon, department and your choice of start-page. Clicking the \"Save\" button will commit the changes, whereas clicking <Cancel> returns you back to either \"Product Home\" or \"My Page\" depending on whether you have a product currently selected or not.
If you want to be able to subscribe to RSS feeds of the information assigned to you in the \"My Page\", make sure that the \"Enable RSS Feeds\" switch is set to \"Yes\" and an RSS token has been generated underneath.
You can change your start page to be any of the following:
My Page -- When you first log-in, you will be taken to your \"My Page\" dashboard
Last Opened Product -- When you first login-in, you will be taken to the home page for the product you last had open
Last Opened Program - When you first login-in, you will be taken to the home page for the program you last had open
In addition to being able to update your user information, you can also change your password. To change your password, on the Account Security tab, fill in the three fields in the Change Password box with your current password, and new password repeated for verification. Click \"Save\". If the password fields were not correctly filled in, you will see a warning message at the top of the page.
You can also change the current password retrieval question and answer by entering in your current password (for security reasons) as well as the new password question and answer.
Note: If your SpiraPlan user profile is linked to an account stored in an external LDAP server, the change password option is disabled. This is because the system uses the password held in the external server. To change the password in this case, please contact your system administrator who will be able to help you change the password in your LDAP environment.
"},{"location":"Spira-User-Manual/User-Product-Management/#2-step-authentication","title":"2-Step Authentication","text":"2-Step Authentication lets you make sure on logging you have to enter your password and also a one-time password for added security. The 2-Step Authentication box on the Account Security tab:
Click on the link in the box to 2-Step Authentication Settings Page. If not yet enabled , the page will walk you through adding 2-step authentication. If already enabled, the page will let you remove the authentication or update it.
To add or update your one-time password you need to scan the QR code into a suitable 2-step authentication app. These are available across device types (desktops, smartphones, tablets). For example, apps like Google Authenticator and 1Password can readily scan the QR code.
Once scanned, enter in the six digit code in your authenticator app within its thirty second window onto the page and click \"Submit.\"
"},{"location":"Spira-User-Manual/User-Product-Management/#ldap-information","title":"LDAP Information","text":"If your account authenticates using LDAP, this tab will show you information about the configured LDAP options for your account. This is for reference only.
"},{"location":"Spira-User-Manual/User-Product-Management/#login-provider","title":"Login Provider","text":"If your account authenticates using an external provider (like Google or Okta), this tab will show you information about which provider you are using.
Click the Unlink Account button to stop using the external provider. The popup will make you enter new security information. You will use this, along with your username, to login to SpiraPlan, once the unlinking process is complete
Here you can configure the email address that the application will send notifications to, and whether or not you want to receive email notifications.
If the Enable Notifications cannot be changed, it means that the system is either not configured to send out notifications, or the administrator has disabled user's ability to opt out of notifications being sent.
"},{"location":"Spira-User-Manual/User-Product-Management/#regional-settings","title":"Regional Settings","text":"This tab will display the current culture and timezone associated with your profile:
By default all profiles will be set to use the application's default culture and timezone. This means that the language, number formats and timezone used in the application will be the ones decided by the person who installed the system. However there are cases where you want to use a different language, timezone or number format (for example, a German employee working in the German office of a French company might want to use the German culture instead of French). You can change the culture and/or timezone to any of the options listed in the dropdown list.
Note: The system will only be installed with a certain number of language packs, so in some cases a selected culture will only change the number formats and not the languages displayed.
"},{"location":"Spira-User-Manual/User-Product-Management/#actions","title":"Actions","text":"This tab displays the list of recent actions that you have performed in the system (across all products):
You can search and filter the grid to find changes by product, change date range, artifact type and type of change (added, deleted, or modified).
"},{"location":"Spira-User-Manual/User-Product-Management/#my-timecard","title":"My Timecard","text":"When you click on My Page > My Timecard the system will display a timecard that allows you to enter the effort worked on incidents and tasks currently assigned to you (across all your products):
The system will only include products that have time-tracking enabled for incidents and tasks, so if some of your assigned incidents or tasks are missing, please check with the product owner of the products affected to have them enable time-tracking.
Each task or incident will be displayed along with its priority, severity, start-date, end-date, product name effort remaining and effort expended to date. For each item you can then indicate the additional actual effort performed (which will be added to the \"actual effort\") and modify the amount of hours remaining. Once you are satisfied, click [Submit Timecard] to commit the changes.
"},{"location":"Spira-User-Manual/User-Product-Management/#redirects","title":"Redirects","text":"What are SpiraApps?
SpiraApps let you tailor SpiraTest, SpiraTeam, and SpiraPlan to your needs. Dedicated SpiraApps extend what is possible, each addressing a specific use case.
One of the key attributes of the Spira platform is that it is a complete, integrated turnkey solution for companies that need to develop, test and manage their software applications. However there are specific features that are needed by different industries and methodologies that are better served by a more extensible set of \u2018add-on\u2019 features to the core system. For example, working in healthcare you have to comply with 21 CFR Part 11, whereas in automotive you need to support ISO 26262. SpiraApps allow Inflectra and its customers and partners to easily, safely, and seamlessly provide niche features for different industries and needs.
Currently, Inflectra Corporation creates and manages all available SpiraApps, and they are distributed through installing or upgrading SpiraPlan itself.
Inside Spira, administrators can browse the list of available SpiraApps. From here they can activate, configure, and then enable for relevant products. SpiraApps functionality is limited to each product they are enabled for - in other words, they do not work in programs, portfolios, or system wide.
"},{"location":"SpiraApps/#getting-started-with-a-spiraapp","title":"Getting Started with a SpiraApp","text":"Here is a quick overview of how to start using a SpiraApp (we recommend also reading the documentation for the SpiraApp too):
System admins can see which SpiraApps are currently installed on the by going to the System Administration > System > SpiraApps page.
Meanwhile, product admins can see which SpiraApps are available to use in their product(s) by going to the Product Administration > General Settings > SpiraApps page. Only SpiraApps that a system has activated at the system level are available for use in products.
"},{"location":"SpiraApps/#setting-up-a-spiraapp","title":"Setting up a SpiraApp","text":"Some SpiraApps have system-wide settings that need to configured for the SpiraApp to work properly. For instance, if a SpiraApp integrates with a third party service, you may need to store login credentials (securely) in the SpiraApp's system settings.
Many SpiraApps have product-specific settings. For the SpiraApp to function correctly, you will need to fill in these settings. For example, if you want to use the SpiraApp to add default descriptions to all new tasks created on the task details page, you have to tell the SpiraApp what description to use.
Once system and product level settings have been configured, the SpiraApp will be ready to use. Depending on the SpiraApp, end users may need to prepare specific artifacts to work with the SpiraApp. They will do this by editing artifacts and their fields in exactly the same way as normal. For example, if a SpiraApp lets you integrate a third party CI/CD tool, you will use releases to start a build on that service: each release may link to a different build job or pipeline in that service, and you have to add that information to dedicated custom fields on the release.
"},{"location":"SpiraApps/#end-user-experience","title":"End User Experience","text":"End users likely will not know they are using a SpiraApp at all. They will interact with the SpiraApp functionality in the same way as any other part of the system.
"},{"location":"SpiraApps/#what-can-spiraapps-do","title":"What can SpiraApps do","text":"SpiraApps can work in the following places:
SpiraApps can do a range of different types of things:
Some SpiraApps may use only one of the features, others may use multiple. Some may be available in a single part of the application, others across multiple places and pages.
"},{"location":"SpiraApps/#available-spiraapps","title":"Available SpiraApps","text":"You can learn more about each of the currently available SpiraApps by accessing the other pages in this section of the documentation (see the menu on the left).
"},{"location":"SpiraApps/CircleCI/","title":"CircleCI SpiraApp","text":"This SpiraApp lets you integrate SpiraPlan and CircleCI so users can launch pipelines from Spira and see their results in Spira as builds.
About this SpiraApp
This SpiraApp has two independent parts (you do not need one for the other to work):
To record builds in SpiraPlan, you must setup the webhook integration with CircleCI.
To configure this SpiraApp that lets users manually kick off a new Pipeline, you must additionally do the following:
"},{"location":"SpiraApps/CircleCI/#system-settings","title":"System settings","text":"To find the slug:
circleci-branch-name for Releases in the product's template. Note: you may already have a custom property for this already if you setup the webhook integration - if you have, do not create a second one.To use the SpiraApp to start a new CircleCI Pipeline go to a release in that product.
You must make sure the custom property \"circleci-branch-name\" has the exact name of the branch in the relevant repo (for instance \"develop\") that you are building the release/sprint against. Note: this field is used by both the CircleCI SpiraApp and the CircleCI webhook integration.
Once the release has the branch name filled in, at any time you can click on the CircleCI button in the top toolbar. This opens the dropdown. Click \"Run Pipeline\" to start the pipeline on CircleCI. You will see an info message telling you the Pipeline has started.
Because a pipeline can take a while to run, do not expect to automatically see the build as soon as the info popup goes away. It may take a few minutes or more for the build to be recorded (if this part of the integration has been configured).
"},{"location":"SpiraApps/Default-Descriptions/","title":"Default Descriptions SpiraApp","text":"Some of this SpiraApp's functionality is not compatible with SpiraTest or SpiraTeam
This SpiraApp lets users to create artifacts from their details pages with pre-populated default descriptions. These descriptions are added automatically when creating new artifacts from the relevant details page. The following artifacts are supported: requirements, releases, test cases, incidents, tasks, and risks.
About this SpiraApp
Once the SpiraApp has been activated system wide, and enabled for a product you can edit its product settings to add/update the default descriptions for the relevant artifacts.
Enter the default description desired in each of the rich text boxes. If a rich text box is left blank, no default description will be added when making that artifact. You can use all available formatting options, except for pasting images.
"},{"location":"SpiraApps/Default-Descriptions/#using-the-spiraapp","title":"Using the SpiraApp","text":"Any default description set is automatically added as the description when any user creates a new artifact (not a clone of an existing artifact):
Once the new artifact has been created, the user can continue to edit the newly created artifact as normal, including editing the description. Once an artifact has been created there is no way to reset or reinsert the default description for that artifact.
Note when creating artifacts (like requirements) on the list page, the default description is not added. You must create the artifact from the standard details page.
"},{"location":"SpiraApps/FMEA/","title":"FMEA SpiraApp","text":"This SpiraApp is only compatible with SpiraPlan
This SpiraApp extends the built-in risk functionality by supporting FMEA with a dedicated FMEA SpiraApp that calculates the Risk Priority Number (RPN) by multiplying together values for the risk's probability, impact, and detectability. It also provides a replacement \"Top Open Risks\" widget for the product home page and reporting home page that is ranked by and shows the RPN.
About this SpiraApp
To effectively implement FMEA in your product, you have to set up the fields that will store the FMEA data (detectability and the RPN itself). You can also optionally configure how the \"Top Open Risks by Risk Priority Number\" widget will display.
"},{"location":"SpiraApps/FMEA/#product-template-setup","title":"Product Template Setup","text":"In the product template for each product that uses FMEA, you need to setup a few different fields:
1. Create a detectability list to store all the options available for detectability
2. Create a detectability property to set the detectability of each risk
3. Create a custom property to store the calculated RPN
4. Optionally, update workflows. This is not required, but we recommend making the following changes to all risk workflows in templates whose products will use FMEA:
Once the FMEA SpiraApp has been activated system wide, and enabled for a product, there are a number of settings:
Custom Properties: these must be filled in for the FMEA SpiraApp to work.
RPN Thresholds: these are optional fields to fill but we recommend filling them in if you intend for users to show the \"Top Open Risks by Risk Priority Number\" widget. The widget shows a list of risks by RPN score. The score can have three colors: red, yellow, or green. Fill in these threshold fields to determine what scores get which color. Unless both of these values are filled in, RPNs will not have any color on the widget.
Note that if your 3 values for RPN (probability, impact, and detectability) all range from 1 through 5, RPN scores will be in the range 1-125.
Other: you can optionally set the RPN Widget Number of Rows to set the maximum number of rows that every user will be able to see when using the widget. If blank every user will see up to 5 rows. You can enter any number here, but note that the widget will display a maximum of 50 rows (even if you enter a larger value).
"},{"location":"SpiraApps/FMEA/#using-the-spiraapp","title":"Using the SpiraApp","text":""},{"location":"SpiraApps/FMEA/#risk-details-page","title":"Risk Details Page","text":"The core functionality of the FMEA SpiraApp is to allow users to set detectability on a risk, and using that value and the risks probablity and impact, calculate a Risk Priority Number (RPN). Users do this on the risk details page.
While on the risk details page (either creating a new risk or editing an existing one) they will see, as per workflow, fields for probability, impact, and detectability. If all three of these fields have a value, then the RPN score for the risk is calculated and saved to the RPN field. Every time the underlying RPN fields are changed, while on this page, the RPN will be updated to reflect that.
The RPN is shown in the dedicated RPN custom property. The Risk Exposure is still calculated and shown at the top of the page, and is independent of the RPN.
On the risk list page: users can but should not edit the RPN; editing risk probability, impact, or detectability on the risk list page will not update the RPN
"},{"location":"SpiraApps/FMEA/#using-the-top-open-risks-by-risk-priority-number-widget","title":"Using the Top Open Risks by Risk Priority Number Widget","text":"This widget displays a breakdown of the top open risks in the product, in order of decreasing RPN score. The widget is available on any of the product home pages, and on the product reporting home page.
Risks in the widget are filtered by any release currently selected for the page. To add the widget to a page, edit the page and then open the \"SpiraApp Widgets\" section. Add the widget to the section of the page you want.
The number of rows shown matches that in the product settings for this SpiraApp. For each row you see:
Because the Detectability and RPN fields are custom properties, they can be viewed and queried in the same way as any other custom property. For example you can see this information on the:
This SpiraApp lets you integrate SpiraPlan and GitHub so users can launch Actions from Spira and see their results in Spira as builds.
About this SpiraApp
This SpiraApp has two independent parts (you do not need one for the other to work):
To record builds in SpiraPlan, you must setup the webhook integration with GitHub.
To configure this SpiraApp that lets users manually kick off a new Action, you must additionally do the following:
"},{"location":"SpiraApps/GitHub/#system-settings","title":"System settings","text":"github-branch-name for Releases in the product's template. Note: you may already have a custom property for this already if you setup the webhook integration - if you have, do not create a second one.github-workflow-id for Releases in the product's template.To use the SpiraApp to start a new GitHub Action go to a release in that product.
You must make sure:
Once the release has the branch name filled in, at any time you can click on the GitHub button in the top toolbar. This opens the dropdown. Click \"Run Action\" to start the Action on GitHub. You will see an info message telling you the Action has started.
Because a Action can take a while to run, do not expect to automatically see the build as soon as the info popup goes away. It may take a few minutes or more for the build to be recorded (if this part of the integration has been configured).
"},{"location":"SpiraApps/GitLab/","title":"GitLab SpiraApp","text":"This SpiraApp lets you integrate SpiraPlan and GitLab so users can launch pipelines from Spira and see their results in Spira as builds.
About this SpiraApp
This SpiraApp has two independent parts (you do not need one for the other to work):
To record builds in SpiraPlan, you must setup the webhook integration with GitLab.
To configure this SpiraApp that lets users manually kick off a new Pipeline, you must additionally do the following:
"},{"location":"SpiraApps/GitLab/#system-settings","title":"System settings","text":"gitlab-branch-name for Releases in the product's template. Note: you may already have a custom property for this already if you setup the webhook integration - if you have, do not create a second one.To use the SpiraApp to start a new GitLab Pipeline go to a release in that product.
You must make sure the custom property \"gitlab-branch-name\" has the exact name of the branch in the relevant repo (for instance \"develop\") that you are building the release/sprint against. Note: this field is used by both the GitLab SpiraApp and the GitLab webhook integration.
Once the release has the branch name filled in, at any time you can click on the GitLab button in the top toolbar. This opens the dropdown. Click \"Run Pipeline\" to start the pipeline on GitLab. You will see an info message telling you the Pipeline has started.
Because a pipeline can take a while to run, do not expect to automatically see the build as soon as the info popup goes away. It may take a few minutes or more for the build to be recorded (if this part of the integration has been configured).
"},{"location":"SpiraApps/OctoPerf/","title":"OctoPerf SpiraApp","text":"This SpiraApp lets you integrate SpiraPlan (and SpiraTest and SpiraTeam) and OctoPerf so users can launch Actions from Spira and see their results in Spira as builds.
About this SpiraApp
This SpiraApp has two interdependent parts that are both required for full functionality:
Note that only OctoPerf tests launched from SpiraPlan using this SpiraApp will create associated SpiraPlan test runs
"},{"location":"SpiraApps/OctoPerf/#system-settings","title":"System settings","text":"https://api.octoperf.com, while OctoPerf on-premise customers should enter their on premise URLoctoperf-scenario-id for Test Cases in the product's template.octoperf-benchresult-id for Test Cases in the product's template.This step is not required, but we strongly recommend updating your workflows to make the \"octoperf-benchresult-id\" custom property either hidden or disabled for all workflow steps. This is field is used to store data sent from OctoPerf so that Spira can match up the the results to the correct test case.
"},{"location":"SpiraApps/OctoPerf/#webhook-setup-in-octoperf","title":"Webhook Setup in OctoPerf","text":"To complete the next part of the setup, login to your OctoPerf Application.
Create a notification: go to the notifications page in OctoPerf and add a new notification with the specific settings below:
{{base url}}/Services/Webhooks/BuildService.svc/OctoPerf?username={{username}}&api-key={{api key}}. This is the url that OctoPerf uses to talk to SpiraPlan. See the example below.The webhook URL
The webhook URL is made of different parts.
https://mysite.spiraservice.net. This is the start of every URL you use when using SpiraPlan/Services/Webhooks/TestService.svc/OctoPerf?username={{username}}&api-key={{api key}}The final URL will look like this: https://mysite.spiraservice.net/Services/Webhooks/TestService.svc/OctoPerf?username=hobikdoc&api-key={11111111-1111-1111-1111-111111111111}
[PR:1]) appears in the name field. Note: you need to complete the above step for every OctoPerf scenario that you want to connect to SpiraPlan. Each scenario must have the product token in its name.
"},{"location":"SpiraApps/OctoPerf/#using-the-spiraapp","title":"Using the SpiraApp","text":"To use the SpiraApp to start a new OctoPerf Action go to a test case in that product.
You must make sure:
the custom property \"octoperf-scenario-id\" is correctly filled in. To find scenario id:
Once the test case has the scenario id filled in, at any time you can click on the OctoPerf button in the top toolbar. This opens the dropdown. Click \"Start Test Scenario\" to start the test scenario on OctoPerf. You will see an info message telling you the Action has started.
Because a test can take a while to run, do not expect to automatically see the test run and updated test execution status as soon as the info popup goes away. It may take a few minutes or more for the test run to be recorded. The test run created will have information about the test scenario in the Console Output, including a link to view the full report in OctoPerf itself.
The execution status is determined based on the test status passed from OctoPerf:
OctoPerf SpiraPlan Passed Passed Failed Failed Error Blocked"},{"location":"SpiraApps/Requirement-Multi-Approvers/","title":"Requirement Multi Approvers","text":"This SpiraApp functionality is limited to SpiraTeam and SpiraPlan
This SpiraApp lets you create groups of customizable tasks against requirements to ensure multiple named users must approve a requirement before it can progress through the workflow. Product admins can create groups of tasks with a consistent description and name style, but with specific assigned users and types. Requirement users can create these task groups that link to the relevant requirement. Widgets on the product home page and My Page help users manage these approval tasks. Note that Tasks are not available in SpiraTest.
About this SpiraApp
Once the SpiraApp has been activated system wide, the system admin can set the number of approval tasks that should be shown on the My Page widget. If this setting is left blank then five tasks will be shown. You can show up to a maximum of fifty approval tasks.
"},{"location":"SpiraApps/Requirement-Multi-Approvers/#product-template-setup","title":"Product Template Setup","text":"In the product template for each product that uses the requirement multi approvers, you need to setup a dedicated custom field. This powers the SpiraApp's widgets. Create a boolean task custom property called \"IsApprovalTask\" exactly.
"},{"location":"SpiraApps/Requirement-Multi-Approvers/#product-settings","title":"Product Settings","text":"Once the SpiraApp has been activated system wide, and enabled for a product you can edit its product settings.
First, pick the \"IsApprovalTask\" custom property from the dropdown for the IsApprovalTask Flag field. This will make sure that the product home page widget will work correctly.
To create a multi approval group, fill in Multi Approval Groups text box. Each group should be on its own line. For each group you specify:
Start each line with the group name, then a \"|\", then the task name prefix followed by \"|\", then the task type followed by \"|\", then a comma separated list of usernames. Your final line should be in this format: List name | Task name prefix | Task type name | username, username, username\u2026
Example multi approval groups
Business Review | Pending Approval: | Management | amycribbins, bernardtyler, fredbloggs
In this example we are creating a group:
QA Review | | | amycribbins, fredbloggs
In this example we are creating a group:
All approval tasks across all groups can share a default task description. Fill in the Task Description rich text field with any required text. This lets you provide standard instructions to all approvers.
Finally, you can set the number of approval tasks that should be shown on the product home page widget. If this setting is left blank then five tasks will be shown. You can show up to a maximum of fifty approval tasks.
"},{"location":"SpiraApps/Requirement-Multi-Approvers/#using-the-spiraapp","title":"Using the SpiraApp","text":""},{"location":"SpiraApps/Requirement-Multi-Approvers/#requirement-details-page","title":"Requirement Details Page","text":"When a user goes to the requirement details page, they will see an extra button in the toolbar. To add a group of multi approval tasks they should follow these steps:
A message will show at the top of the page stating that the tasks are being created. This message will disappear after all the approval tasks have been created. You can see the new tasks on the requirement's task tab. Below is an example.
Each of the multi approval tasks created has the following fields set:
This widget displays open multi approval tasks in the product (or for the release in that product if the page is set to display for a particular release). Approval tasks are shown in order of when they were created (oldest first). The widget is available on any of the product home pages. To add the widget to a page, edit the page and then open the \"SpiraApp Widgets\" section. Add the widget to the section of the page you want.
The number of rows shown matches that in the product settings for this SpiraApp (up to a maximum of 50). For each row you see:
Note that only approval tasks that have the IsApprovalTask custom property present and set to Yes will show on the widget.
This widget displays open multi approval tasks assigned to the current user. Approval tasks are shown in order of when they were created (oldest first). When the My Page is set to show content for \"All Products\" the widgets shows approval tasks system wide. When the My Page is set to show content for \"Current Product\" the widgets only shows approval tasks (if any) in the current product.
To add the widget to a page, edit the page and then open the \"SpiraApp Widgets\" section. Add the widget to the section of the page you want.
The number of rows shown matches that in the system settings for this SpiraApp (up to a maximum of 50). For each row you see:
Note that only approval tasks that have the IsApprovalTask custom property present and set to Yes will show on the widget.
"},{"location":"SpiraApps/Task-Test-Presets/","title":"Task and Test Presets SpiraApp","text":"Some of this SpiraApp's functionality is not compatible with SpiraTest
This SpiraApp lets users quickly create preset tasks or tests cases for a specific requirement or release. In this way, users can with a single click create, for example, 8 preset development tasks against a requirement, or generate a handful of approval tasks for another requirement. Note that Tasks are not available in SpiraTest.
About this SpiraApp
Once the SpiraApp has been activated system wide, and enabled for a product you can edit its product settings.
To create task or test case presets, fill in the relevant text boxes (tasks and test cases for requirements, and tasks and test cases for releases). Each preset should be on its own line.
Start each line with the preset name, then a colon, then a comma separated list of artifact names. To give the artifact a type add a | and the type name after the artifact name.
Example task preset
Development Checklist:Design Screen,Develop Screen,Write Test Cases|Testing,Update Documentation.
In this example we are creating a preset:
When a user goes to the requirement or release details page, they will see an extra button in the toolbar. To add a preset group of tasks or test cases they should follow these steps:
A message will show at the top of the page stating how many tasks or test cases are being created. This message will disappear after all the artifacts have been created. You can see the new items by going to the relevant tab. Below is an example task tab of a requirement where we have added some preset tasks.
"},{"location":"SpiraApps/Task-Test-Presets/#extra-details-to-be-aware-of","title":"Extra details to be aware of","text":"This SpiraApp lets you integrate SpiraPlan and the Worx desktop application.
About this SpiraApp
If the SpiraCapture icon doesn't appear at the top right of your screen, go to chrome://extensions to make sure the extension is enabled (check that the toggle in the bottom right of the extension card is lit up blue, if not click it to turn on the extension).
"},{"location":"SpiraCapture/User-Guide/#how-to-start-capturing","title":"How to start capturing","text":"To start capturing click the SpiraCapture icon in the toolbar, which should bring the SpiraCapture menu.
You should see a \"Start capturing\" button to capture the current tab. **Note: ** this will only capture the current tab you are on! If you would like to capture other tabs repeat this step. **Warning: ** if you have just enabled the extension, you need to refresh the tab before capturing will work.
You can tell if SpiraCapture is capturing the current tab, because the SpiraCapture icon in the toolbar will show in color. When it is not capturing a tab, the icon is shown in grayscale.
"},{"location":"SpiraCapture/User-Guide/#what-event-triggers-data-to-be-captured","title":"What event triggers data to be captured?","text":"A number of events trigger SpiraCapture to capture how the user is interacting with the current browser tab:
Additionally, there are a few ways that data can be captured manually by the tester, by interacting with the SpiraCapture menu. These give users flexibility in organizing the captured data to reflect their test.
Clicking the SpiraCapture icon from the browser toolbar will show the SpiraCapture menu. This gives you access to the main functionality of the extension.
When you click the \"View data\" link from the SpiraCapture menu the tab that opens shows all data collected. This page is divided into three parts:
Each of these areas is explained in more detail below.
"},{"location":"SpiraCapture/User-Guide/#the-event-list","title":"The event list","text":"The event list is shown on the left hand side of the page. Every event is shown in chronological order, broken down into testing steps (which can be manually created by the user and incremented automatically over time).
Each step has a heading which shows the name of the step and the time that particular step started. If the step contains any notes, a pin icon is shown in the step heading. This is designed to help you see which steps have notes in as these are likely the steps that you want to examine more closely. Clicking on the step heading will collapse or expand the events inside the step.
Each event shows certain standard information to make it easy to navigate and browse the data.
Each event also has a checkbox on its left. Checking the checkbox will mark that event as selected. Only selected events are sent through to Spira when logging new incidents.
"},{"location":"SpiraCapture/User-Guide/#the-preview-window","title":"The preview window","text":"Clicking on an event with a screenshot will display in the large preview window on the right hand side of the page. This is helpful if you want to see a screenshot in more detail.
"},{"location":"SpiraCapture/User-Guide/#the-action-bar","title":"The action bar","text":"The action bar has four buttons:
You can send all selected events to Spira as a single new incident. Once connected to Spira, as explained below, you choose a product, fill out the incident creation form and then create your incident. The selected events, including their screenshots, will be saved into the description field of the new incident.
"},{"location":"SpiraCapture/User-Guide/#connect-to-spira","title":"Connect to Spira","text":"First, make sure you have enabled API access to Spira. You do this from your Profile Page from within the Spira application. Make sure you enable rss and generate an RSS Token. This RSS token is the same token you use for API access, which is what SpiraCaptures uses.
Note This can be disabled be you or your administrator make sure you have it enabled if you would like to use this feature see warnings section below
Clicking the Send selected events to Spira button will show a popup. The first time you see this popup you will need to enter your connection credentials:
Once you are logged in to your Spira (and have your events selected) the popup will require at least 3 fields to be selected/filled in.
Once these have been filled in, click the \"Send data to Spira\" button to connect to your Spira application and upload the incident. Once the incident has been created you will see a link next to the send button that will open the incident in Spira for you.
"},{"location":"SpiraCapture/User-Guide/#potential-gotchas","title":"Potential Gotchas","text":"In this guide we will learn about the different parts of the application, how to use them, and how they fit together.
You don't need to know how to use the application already, and you don't need to be familiar with application management tools, or agile, or waterfall.
All you need to get started is the application itself.
You say SpiraTest, I say SpiraPlan
The SpiraPlan family of applications comes in 3 different editions:
Whatever flavor of Spira you have (we will say \"Spira\" from here on) you can use this Quick Start Guide. To learn more about the differences between the different Spira editions, take a look at our detailed comparison chart
"},{"location":"SpiraPlan-Quick-Start-Guide/#introduction","title":"Introduction","text":"Let's go on a journey together. In fact, let's go to Mars! For a vacation. We deserve it. In this Quick Start Guide we use SpiraPlan to help us plan and prepare for our Mars trip.
This Guide is split into different parts, the different stages of our preparation before the big launch.
We recommend doing things in order if you can. This will really let you see the power of how SpiraPlan helps you connect your work together. This in turn helps you better understand your progress and better meet your goals. That being said, this is your time and your time is precious. We have designed this guide so that you can dip into any part you want at ant time. However you approach it and whatever edition of Spira you have, there will be clear signposts and tips to guide you along the way.
Enough explaining, let's start doing...
"},{"location":"SpiraPlan-Quick-Start-Guide/#start-using-the-application","title":"Start using the application","text":"What you will learn
You have a brand new SpiraPlan application ready to go. This is either in the cloud or on-premise. First, go to the home page of the application in your browser to get to the login page:
Login using the default admin account:
You are now logged-in and will see the \"My Page\". The My Page looks pretty empty right now. This is normal.
The first time you log in you will see a popup that gives you a quick orientation of the application. Please follow this guide first.
Getting Help in the App
On every page of the application there is a link to go to the documentation for that specific page. Feel free to use that at any time.
To access it: click your icon / avatar in the upper right to open the user menu, then click on the link called \"Documentation\"
"},{"location":"SpiraPlan-Quick-Start-Guide/#products","title":"Products","text":"To start getting things done in the application you need to select a workspace to explore, manage, or work on. The most common and important workspace is the product. This is where you and your team will spend most of their time in SpiraPlan. Products are long running areas of work with tangible outputs or goals. This can be a software or hardware product that gets new regular new releases, patches, and features. A product can also be used like a project, where the focus may be a different kind of output or to manage a process.
For this tutorial we want to start with an empty product that has no data in it. By default, the system ships with a couple like this.
The \"Sample Program\" in this screenshot is a program. Programs are used to group products together. Programs can themselves get grouped together into portfolios. We are not going to get into that though.
"},{"location":"SpiraPlan-Quick-Start-Guide/#artifacts","title":"Artifacts","text":"Artifacts are the building blocks of a product in SpiraPlan. Artifacts contain all of the data in the product. Each artifact holds different data and is used in different ways. For instance, requirements are one artifact, and releases are another. They work differently, and are not interchangable. There are artifacts to help you test, plan, track bugs and tasks, and more.
Throughout this guide we will be moving between the different artifacts in our sample product. This will help us focus on one type of activity at a time. You will also see how all these different artifacts fit together like neat little puzzle pieces.
Let's Start
How to access legacy quick start guidesThe legacy version of the quick start guides are available for SpiraTest, SpiraTeam, and SpiraPlan. Click on the name of the product to access its legacy guide.
"},{"location":"SpiraPlan-Quick-Start-Guide/do-the-work/","title":"Doing the work","text":"The story so far (1)
We are going on a vacation to Mars (2). It's a long journey. Like you should do before any big trip, we started by planning out what we have to do. We made some reqirements, tasks, sprints, and even thought about the risks. Now its time to stop planning and start doing.
Workflows are a way of moving an artifact (like a task or requirement) through a series of steps. These steps take the artifact from its creation to its end point. Workflows give you control about the who, how, and what of moving an artifact through specific steps.
For example, a task going from not done to done. In SpiraPlan the task starts as \"Not Started\" and transitions through the workflow steps to \"Completed\". You can mark the task as \"In Progress\" when you have started work but not finished it yet. Maybe the task doesn't end up \"Completed\" - it may get blocked or become obsolete. All of these options are possible with workflows.
If you are starting the quick start guide here
This part of the guide only works if you have already made some requirements and (optionally) tasks for those requirements. If you haven't done this, please go back and do so now.
There are two different ways to \"do the work\" in this part of the guide - you only need to do one:
Using SpiraTest or did not follow all steps on the Plan page?
Skip ahead
We have 4 requirements. We made 4 tasks as well, but one of those tasks never got attached to a requirement. We never added a task to \"Prepare the spaceship\". So why do all 4 requirements show a filled in task progress bar? This is because of a feature called \"rollup\". The task progress from a requirement's children \"rollup\" to the parent. The task progress bar of \"Prepare the spaceship\" is a rolled up combination of the task progress of its two children.
Why are 3 of the task progress bars yellow? Because the tasks have start dates in the past and have not yet started. In SpiraPlan we consider these tasks to be \"starting late\". We never directly set their start dates, but the tasks got their start and end dates from the releases (sprints) they are linked to. The remaining task progress bar is gray because, although it too is still not started, its start date is in the future. Your task progress bars may look a little different if you choose different dates for your sprints.
We are not going to work on the requirements themselves, instead we do the work on the tasks we made.
Let's now complete another task. We will record this in a different way. On the list page, where we are now, you can make any changes to any task at any time. Workflows only let you do certain things at certain times. For the workflow to control what we can do we need to be on the details page for a task.
You may have missed it but as soon as the task status was at \"In Progress\" some names of the different fields went bold and got a star by them. This means they are now required. Most of these required fields are already filled in. But one, \"Owner\" is still blank.
We will now move the task through to completed
3 for 3 hours of work0Let's check our progress.
The task progress bars for 3 requirements are now green. This makes sense because it is the tasks linked to these requirements that we completed. The statuses have also changed. They all had statuses of \"Planned\" and now 3 have the status of \"Developed\". This happened automatically because all the tasks linked to these requirements are now complete. The system sees the requirement has tasks and judges that all the work for those requirements in stored in the tasks. So when the tasks are done, the requirement is done. For now done = \"Developed\": we have done the work but have not yet verified that work.
Why are statuses changing by themselves for requirements?
Requirements do not need to work like explained above. You can set your product up so that whatever you do with tasks, the requirements' statuses do not change. In this quick start guide, we are showing one way of using SpiraPlan, but you do not need to work this way.
Requirement Name Status Prepare the spaceship Developed > Pack my suitcase Developed > Take the right amount of rocket fuel Developed Get a cool spacesuit Planned"},{"location":"SpiraPlan-Quick-Start-Guide/do-the-work/#completing-standalone-requirements","title":"Completing Standalone Requirements","text":"Already completed tasks (above)?
Skip ahead
Let's now finish development on another requirement. We will record this in a different way. On the list page, where we are now, you can make any changes to any requirement at any time. Workflows only let you do certain things at certain times. For the workflow to control what we can do we need to be on the details page for a requirement.
You may have missed it but some fields names of the different fields are shown in bold and have a star by them. This means they are required. Most of these required fields are already filled in. But one, \"Importance\" is still blank.
We will now move the task through to completed
Let's check our progress.
We changed the statuses of 2 requirements, but 3 requirements now have different statuses. They all had statuses of \"Planned\" and now 3 have the status of \"Developed\". This happened automatically because when all of a parent requirement's children change their status, the parent status changes too.
Requirement Name Status Prepare the spaceship Developed > Pack my suitcase Developed > Take the right amount of rocket fuel Developed Get a cool spacesuit Planned"},{"location":"SpiraPlan-Quick-Start-Guide/do-the-work/#summary","title":"Summary","text":"You're doing great!
What's next? According to our requirements all our work to prepare the spaceship is developed, but we need to know for sure. In the next part, we will check our work, to make sure our tasks and requirements do what they are supposed to.
"},{"location":"SpiraPlan-Quick-Start-Guide/plan/","title":"Plan","text":"We will spend the first chunk of this guide planning things out. We start by outlining the big features and goals we need to deliver. Then we break those down into smaller tasks. Once we know the scope of the work we can plan out our time. This let's us plan out when we need to do each of our tasks and deliver on our goals. With that the planning is almost complete. Before we move onto the next section we should think about the risks that things could go wrong, or go off track.
The story so far (1)
We are going on a vacation to Mars (2). It's a long journey. So it's a good idea to plan it out first, instead of jumping into the first rocket for Mars you can find. We've logged into SpiraPlan and we are ready to go.
Requirements are also known as features, or user stories. Different frameworks and methodologies call them different things and use them in different ways. SpiraPlan is methodology agnostic so you can use requirements however you want.
Often, as you work with requirements or features you need to structure your requirements with some nested inside others. SpiraPlan gives you full support for hierarchically arranging your requirements.
We've decided on our vacation destination: Mars. Currently, we're on Earth, don't have a rocket, and have got a lot to do. We need to make a list of our big goals. SpiraPlan uses \"Requirements\" as the artifact (the item type in the application) for tracking these major goals.
Not all features are available in SpiraTest. SpiraTeam takes SpiraTest and adds some features, SpiraPlan adds even more. Below you can see the requirements page as it looks for SpiraTest. Only features that SpiraTest supports are available in the app. Compared to SpiraTeam or SpiraPlan it does not have the \"Task Progress\" column, because SpiraTest does not include tasks.
In the rest of this guide we normally show screenshots of SpiraPlan. If you are using SpiraTest or SpiraTeam you may see columns or tabs or widgets on certain screenshots that you do not have. This is expected.
Let's make some requirements. In SpiraPlan, there is almost always more than one way to do something, but let's start out simple.
Prepare the spaceshipGet a cool spacesuitWe've made a great start. We have two requirements. Let's add a couple more and see how easy it is to nest requirements inside others.
Pack my suitcaseTake the right amount of rocket fuelYou will see your 4 requirements and the top one has a different icon. This shows us that it is a parent requirement that has children nested inside it.
Requirement Name Position Prepare the spaceship Parent > Pack my suitcase Child > Take the right amount of rocket fuel Child Get a cool spacesuit By itself Other ways to add and position requirementsIf you have a list of requirements and want to make one a child of the requirement above it, select the requirement and click the \"Indent\" button on the toolbar. Use the \"Outdent\" button to move a child requirement out one level.
You can also right click on a requirement to indent or outdent them.
Click and drag requirements to move them around and change the order.
Select a requirement then click the \"Insert\" button. This adds a new requirement above the selected requirement.
Click the \"Insert\" button with no requirements selected. The new requirement is added at the end of the list of requirements as a sibling of the requirement above it.
"},{"location":"SpiraPlan-Quick-Start-Guide/plan/#make-tasks","title":"Make Tasks","text":"Skip this section if you are not using SpiraTeam or SpiraPlan
Skip ahead
Tasks are available in SpiraTeam and SpiraPlan. Tasks are used to define specific chunks of work to do.
They can be used in lots of different ways in SpiraPlan. A great way to use tasks is to link them to big pieces of work, to better manage and track what has to get done when. You can create tasks for requirements, that are then tied to sprints, so you can easily see your progress in finishing all relevant tasks.
"},{"location":"SpiraPlan-Quick-Start-Guide/plan/#tasks-from-requirements","title":"Tasks from Requirements","text":"Start here if you have created requirements
Otherwise skip ahead
We wrote out some top features we need for our Mars vacation to be a success. These requirements are very broad. It is a good idea to break them down into smaller chunks of work - tasks. Let's create some tasks for some of our requirements!
Congratulations! You have made one task. In real life you would make a few more so that the requirement has 2 or 3 or more tasks on it. For now, let's try making a task on a different requirement
We've made tasks directly from a requirement. These tasks are directly linked to the requirement. But we can also make tasks a different way, which we will try now.
"},{"location":"SpiraPlan-Quick-Start-Guide/plan/#standalone-tasks","title":"Standalone Tasks","text":"Book a spacesuit test fittingSet 'out of office' before launch dayWe now four tasks in total (two if you have only created standalone tasks). The task we made about our spacesuit fitting is actually part of our requirement (if you made it) to get a cool spacesuit. We made this task independently of that requirement, but we can still link them together.
Releases let you create a list of different releases or sprints for the product. They can be nested to create a hierarchy of releases.
Releases let you divide up your product or project into smaller blocks of time. If preparing for our vacation to Mars will take a year, you can use releases to plan what you will do every two weeks, or every month. Because releases are mostly time bound, their start and end dates are really important. You can have multiple releases on the go at the same time.
In SpiraPlan releases have lots of special properties. By themselves they are simple, but as you link up more and more things (using other artifacts) the more powerful releases become.
We're making good progress with our Mars vacation. We have worked out the top areas of work left to do and made some tasks for them. Next, we move from thinking about the what to thinking about the when. That's where releases come in.
The main list in the middle of the page is empty. Let's change that.
Build spaceship. Good news! We've already finished building the spaceship. Let's make this clear by marking this release as finishedLet's add two more releases - these won't be completed yet.
Prep for launch as the name of the new release2.0Lift off and a \"Version #\" of 3.0. Leave the \"Status\" as \"Planned\"The story so far
We have planned out the things we need to get done before we head to Mars. And we've created releases so we can track what we do and when we need to do it.
Currently, our what (things to do) are not linked up to our when (releases). Let's fix that.
If you have not made any requirements or tasks you can go back and do that now or skip this section.
"},{"location":"SpiraPlan-Quick-Start-Guide/plan/#set-releases-for-requirements","title":"Set Releases for Requirements","text":"First, we are going to set the release for our requirements.
Skip this section if you are not using SpiraTeam or SpiraPlan
Skip ahead
Let's hook our tasks up to releases.
Look at the release column of your tasks. Three of them already have a release set. This is because they are linked to requirements, and we just set the release for the requirements. That release information flows from the requirement to any of their linked tasks.
Why is the Task Progress bar yellow for some tasks?
Because the release these tasks are linked to has been started (its status is \"In Progress\") but the tasks have not started yet, we flag their progress as yellow
Our two tasks do not have a release yet, so let's change that.
Skip this section if you are not using SpiraPlan
Skip ahead
Risks let you set up a full risk management solution for your products. You can log and track risks at any time and link them up to releases as well as other artifacts.
Each risk can have a probability and an impact to help you analyze each risk's exposure. Add risk mitigations to track how you are treating the risk.
The more we think about this vacation to Mars, the more we realize it is kind of risky. These risks may make our trip of a lifetime kind of suck. Just thinking about all the ways things can go wrong is not very productive. Instead, we should write things down so we can manage the risks and not be scared of them.
Fly right on past Mars for the name (at the top of the page)Spaceship computer turns evil for the name (at the top of the page)Let's now add some ideas about how we can manage (or mitigate) this risk. We do so by creating mitigations, because we really, really need that computer to treat us well.
Be its friendKnow how to turn it off into the descriptionYou have created two mitigations on this risk and created two risks in total.
Risk Name (with mitigations) Release Fly right on past Mars 2.0 - Prep for launch Spaceship computer turns evil 3.0 - Lift off > Be its friend N/A > Know how to turn it off N/A"},{"location":"SpiraPlan-Quick-Start-Guide/plan/#summary","title":"Summary","text":"Congratulations we have now finished planning!
Our vacation to Mars is taking shape. But there is still lots more to do. In the next part of this quick start guide we will learn how to manage our work with SpiraPlan and get things done.
"},{"location":"SpiraPlan-Quick-Start-Guide/review/","title":"Review and Next Steps","text":"The story so far (1)
We are going on a vacation to Mars (2). We've been busy planning, preparing, and checking things for the long journey ahead. Are we ready to leave or not? What is left to do? That's what we are going to find out in this final core section of the SpiraPlan Quick Start Guide.
If you haven't followed the guide all the way through
We are going to see how the different artifacts link together. So, you really need to have done all the parts of the quick start guide to see this in action on your installation. If you haven't, you will be able to see how things could work, which will still be useful.
We left on the test case list page. We have two test cases and one of them has failed. Before going to Mars you want your tests to all pass, so you know that the trip will go as smoothly as possible.
We already have a hint with that failed test that our trip may need a little more work. Let's look around and find out.
The first 3 requirements are for release 2.0 (the one we are currently working on).
The statuses are also still at Developed. They haven't moved to \"Tested\" because our testing is not complete yet
Open the Artifact dropdown from the global navigation and click \"Releases\" under the Planning section
We have three releases. One was finished before we started this guide, one has not yet started, and the third (release 2.0) is the one we are working on. This is the one our requirements, and by extension, tasks and tests are linked to.
From a quick glance here, we can see that the \"Prep for launch\" release is not ready. We are not going to take action on this yet. Instead, let's take a look at one more place to review things. This time at the product wide level.
"},{"location":"SpiraPlan-Quick-Start-Guide/review/#reviewing-the-product","title":"Reviewing the Product","text":"There's a lot of information on the Product Home Page. The page is divided into widgets that each display different information. Together they give you a useful overview of the state of your product. You can customize how this page looks for you for every product. Below is the default view you will see when looking at the page for the first time.
What can we see from these widgets?
This quick start guide ends here. We've done a lot together, but the rest is up to you.
For this vacation to happen you need:
tasks done
tests to pass
bugs to be fixed
risks to be managed
requirements completed
releases to be ready
Even if we only focus on the \"Prep for launch\" release, apart from the tasks, you still have a lot to do. You can stop here, just like this guide. Or you can play around and and see if you can get this release 100% ready.
SPOILERS: Hints to finish the releaseWant some help about what you need to do, to get everything looking great? We've got you!
What success looks likeSpecific stepsRequirements:
Release 2:
Product Home Page: the screenshot below only displays data for the \"Prep for launch\" release (using the dropdown in the top left). The layout here is customized with specific widgets that show that our requirements, risks, and incidents are all looking good.
Collectively, these will move the three requirements in release 2.0 to the Tested Status. This in turn will make the requirement completion and test coverage for release 2.0 go 100% green.
"},{"location":"SpiraPlan-Quick-Start-Guide/review/#how-to-learn-more-or-get-more-help","title":"How to learn more or get more help","text":"We have lots more ways to help you get to know SpiraPlan better!
First, there is our online documentation that you are already reading. Here are some helpful links:
There is also the Inflectra support portal. Here you can read knowledge base articles, ask questions in the forum, or log a ticket with the support team.
"},{"location":"SpiraPlan-Quick-Start-Guide/test/","title":"Checking the Work","text":"The story so far (1)
We are going on a vacation to Mars (2). It's a long journey. We spent time planning the trip, and then doing the most important tasks. Before we blast off without a care in the world, let's check that we did everything right.
There's a lot to check before going on any trip. All the more so when traveling over 100 million miles. We need to stay focused. We made a few releases and work happens in each.
Let's focus on just one of those releases \"Prep for launch\". Three of our requirements should get delivered in this release / sprint. Because of our work in finishing tasks on these requirements, they all have a status of \"developed\". This is perfect, because it means the development (doing) work is done. The next step is to verify things. In SpiraPlan, we verify with the Test Case artifact.
"},{"location":"SpiraPlan-Quick-Start-Guide/test/#create-some-tests","title":"Create some Tests","text":"If you are starting the quick start guide here
Don't worry! You can create tests and execute them without doing the earlier steps in this guide. Some of the details may not apply to you, importantly linking our tests to requirements and releases. But don't let that stop you.
Test Cases are the main unit of testing in SpiraPlan. A Test Case defines a scenario or user flow that you want to verify. A Test Case is made up of Test Steps. These steps are the sequence the tester needs to go through and check. Each test step is an opportunity to verify functionality is working as it should, or recording where there are problems.
First you create your test cases, then you execute them. Test execution records the results of what you did or found. You can execute the same test many times and keep a list of records of what happened each time. These are called Test Runs. This system means you have test cases that you can reuse very efficiently. Each test run logs the execution status of that run (eg pass or fail). Together with requirements and releases, test cases help you have full traceability across your whole product.
Verify suitcase is well packedCheck if the spaceship computer seems niceDidn't make any requirements?
Skip Ahead
This is great. We have already created two test cases. We could start running these tests now, but first let's hook these tests up to requirements and releases.
These actions link each test case to the correct requirement. Because the requirements are already connected to a release, the test cases are automatically linked to the correct releases. So by adding a requirement to a test case we also added a release. Neat. You can link many requirements to a test case. And you can independently add many releases to a test case as well. Our setup for now looks like this:
Test Case Name Requirement Coverage Release Coverage Check if the spaceship computer seems nice Prepare the spaceship 2.0 - Prep for launch Verify suitcase is well packed Pack my suitcase 2.0 - Prep for launch"},{"location":"SpiraPlan-Quick-Start-Guide/test/#execute-a-test-case","title":"Execute a Test Case","text":"Test Execution in SpiraPlan has a dedicated module for running manual tests. This makes it easy for testers to see what they have to test each step of the way. They can quickly record results and log bugs. SpiraPlan also supports other types of tests, including automated tests and unit tests. These tests are not managed from the test execution module.
Now that we have a very simple test case, we can execute it to check if things are working as they should. Above, we said that test cases in SpiraPlan are made up of Test Steps, which are the steps the tester needs to go through and check. You can add as many steps as you want to a test case, and customize them to exactly your needs.
We didn't make any test steps on our test cases. Without steps there's nothing to actually verify! Don't worry, SpiraPlan automatically made a test step each time we made a test case. These test steps are emtpy, but they are enough for us to try out executing tests.
This will launch a popup showing you that the Test Run is being prepared for execution from the test case. Once it finishes, you will see the Test Execution Wizard. On this screen you can: pick a release to execute the test run against; and set any test run custom properties. You can see that the Release is currently set to \"1.0.0.0 - Build Spaceship\", because it is the first release in the list.
The test case is about our suitcase packing, which is part of our sprint to prepare for launch (release 2.0). So let's make sure to run the test against the correct release.
When you go to this page for the first time, you can go through a guided tour of how the page works
As a tester, you move through each of the test steps in the test run in order. Each test step needs a result: Pass, Fail, Blocked, Caution, or Not Applicable (N/A). If you enter any status other than Pass you need to enter a value for the \"Actual Result\". For a pass status, the Actual Result is optional.
We only have one test step. If we thought our packing was great, we could mark the step as Passed. That means the whole test run has passed, so we could finish the test run and officially log its results. That's no fun, so let's do something else.
Cannot close suitcase because of all the snacksBefore we finish testing, we have one more thing to do. We failed the test and now we should log this failure with an incident.
Why create an incident?
Creating an incident (or a bug) during testing is the perfect way to capture what is wrong so someone can fix it (like a developer, or here whoever has to pack the bags). The incident is linked to the exact test step that failed.
You can then track this bug outside of testing. Once the bug is fixed, the tester can rerun the test case and see if things are fixed.
There are too many snacks to fit in the suitcaseAfter clicking \"Add\" the incident is created and the Incident tab shows us that the incident is linked to this test step.
We are now ready to finish our test.
This will take you back to the Test Case list page. Here we see the two test cases, and we can see that \"Verify suitcase is well packed\" is marked as failed.
Test Case Name Execution Status Check if the spaceship computer seems nice Not Run (gray) Verify suitcase is well packed Failed (red)"},{"location":"SpiraPlan-Quick-Start-Guide/test/#summary","title":"Summary","text":"Almost there!
In the next and final part of this quick start guide we will review where things stand for our Mars vacation. How can SpiraPlan help us work out if we are ready to blast off, or if we are destined to stay stuck on Earth? Let's find out.
"},{"location":"SpiraPlan-Quick-Start-Guide-Legacy/","title":"SpiraPlan Quick Start Guide","text":"Want to access the new and improved Quick Start Guide?
This SpiraPlan quick start guide still works great, but we have a newer and greater quick start guide. Please feel free to check it out.
"},{"location":"SpiraPlan-Quick-Start-Guide-Legacy/#logging-in-and-selecting-a-product","title":"Logging In and Selecting a Product","text":"Once you have installed a self-hosted trial or signed up for a hosted trial of SpiraPlan, you should see the following login screen in your web browser:
Enter the following default details to start using the system:
Login: administrator
Password: PleaseChange
Once logged-in, you are shown your \"My Page\". The very first time you log in you will be able to take a quick orientation tour of the application (as shown in the screenshot below).
The My Page looks pretty empty right now. This is normal.
For this tutorial we want to start with an empty product that has no data in it, so click the hyperlink under 'My Products' for 'Sample Empty Product 2' / 'Sample Program'. That will select the empty product. Now to see the homepage for the product you just selected, click on the hexagon in the top left:
The product home page shows various widgets containing key product metrics. These are empty now, because the product has no data in it. In the rest of this guide we are going to fix that.
"},{"location":"SpiraPlan-Quick-Start-Guide-Legacy/#define-the-requirements","title":"Define the Requirements","text":"On the main Navigation bar, click Artifacts > Requirements to display the product's requirements list page:
The terminology in SpiraPlan is designed to be methodology agnostic. The table below shows how the terms used in SpiraPlan relate to some common methodologies:
SpiraPlan Extreme Programming Scrum AgileUP / DSDM Summary Requirement Epic Epic Feature Group Requirement User Story Backlog Item Requirement Task Task Task Task Release Release Release Release Sprint Iteration Sprint IterationAt first, the requirements list will be empty. Click the 'Insert' button in the toolbar to create your first requirement. Hit 'Save and New' (shown as buttons on the right of the new requirement in the list table) to add each new requirement after that except for the last requirement. After entering the last requirement, hit \"Save\" button. Below is the list of requirement names to add:
Functional Requirements
Module 1
System must allow entry of users
System must allow the modification of users
System must allow the deletion of users
Module 2
System should allow administrators to setup notifications
You should now have a simple, flat requirements list, like the one below:
Next, we are going to indent the requirements. This will give us a hierarchy, with some requirements being children of others.
To indent, select the checkboxes of all the requirements below 'Functional Requirements' and click 'Indent'. This makes 'Functional Requirements' the parent and all the other requirements its children.
Now, select the three requirements immediately below 'Module 1' and click 'Indent' again. This makes these three requirements children of 'Module 1' (and grandchildren of 'Functional Requirements').
Repeat for the requirement below 'Module 2' by right-clicking on this last requirement and choosing 'Indent' from the popup context menu.
You should now have a list that looks like:
We now have a nicely grouped set of requirements. Let's enter more information about them, starting with setting their types and priorities.
Save button.You now have a prioritized list of user story requirements:
The next thing we can do is assign estimates to each requirement. This is something that the developers or business analysts may do based on the complexity and scope of each. The 'Estimates' column is not visible yet, so first we need to show it. To do that, click on the 'Show/Hide Columns' dropdown list and select 'Show Estimate (points)':
By default, all the requirements will have been assigned a default estimate of 1.0 point. A point is not a defined number of hours, but an indication of the size of the requirement. The estimates should reflect how big each of the requirements are relative to each other.
To change the estimates:
Click the \"select all\" checkbox at the top of the list
Click on the top 'Edit' button in the right-hand column. The requirements should be in editable mode again.
Enter the following estimates for the requirements
Click Save
Your requirements should now look like this (with each parent's estimates automatically summing up the estimates of their children):
We have created a list of prioritized, estimated requirements, which is a great way to start our product. In the next section we are going to enter releases and sprints.
"},{"location":"SpiraPlan-Quick-Start-Guide-Legacy/#create-the-release-and-iteration-plan","title":"Create the Release and Iteration Plan","text":"On the main navigation bar, click out of 'Requirements' and select 'Releases' menu option to display the product's release list page:
The release list will be empty. Click the 'Insert' button in the toolbar to create your first release. Hit 'Save and New' (shown as buttons on the right of the new release in the list table) to add each new release after that. Below is the list of release names to add:
Release 1.0
Release 1.1
You should have a list of releases like this:
We need to add one additional level of detail to each release -- the list of sprints that will take place in each release.
Let's add some sample sprints for the first release:
Insert > Child ReleaseSave And NewSave on the final sprint's row. You should have three sprints added to the list, all children of Release 1.0.
Finally, let's specify the number of resources assigned to each sprint and release.
Edit button on the toolbarSaveWe have defined the high-level schedule for Release 1.0. The next stage is to have the developers take each of the requirements defined so far and define the various tasks needed to deliver them. Each task will have its own estimate associated with it. In addition, you can optionally specify date ranges and priorities to each of the individual tasks.
To start adding tasks, go to the main navigation bar and click out of Releases and hit Requirements to display the requirements list. Click on the hyperlink for the first requirement (\"System must allow entry of users\") and the requirement's details page will be displayed:
Notice that under 'Dates and Times' column on the right, the system displays an initial resource estimate of 1.5 points and 12 hours. This is based on an initial product setting of 8 hours per story point. Once you start adding tasks and getting metrics based on the actual team velocity (how many story points they can accomplish in a given time frame), the system can update that conversion metric.
Click on the 'Tasks' tab to display the list of tasks defined for this requirement. The list is empty, so let's change that:
New Task button (this adds a new task and associates it with this requirement)Save.The new task has now been added:
We have more tasks to add. The table below shows 12 tasks in total to add to 4 different requirements. This includes the one we just created for completeness.
Requirement / Task Est. Estimate System must allow entry of users Create user data tables 10.0h Develop user business object 10.0h Build user creation screens 20.0h System must allow the modification of users Extend user business object to handle updates 5.0h Add user list page 15.0h Add user details page 20.0h Add user permissions page 15.0h System must allow the deletion of users Extend user business object to handle deletes 5.0h Update user list page to add delete functionality 10.0h System should allow administrators to setup notifications Create user administration home 15.0h Add user settings for notifications to database 10.0h Create user notifications administration page 20.0hOn the main Navigation bar, click again on 'Requirements'. You should now have the following requirements list page. In this screenshot we have hidden the 'Author' field and shown the 'Task Effort' field to show the detailed task effort aggregated up to the requirements.
The total number of hours for these tasks divided by the total number of story points gives a number a lot more than the 8 hours that the system assumes. We can update the system to better estimate the number of hours to deliver each story point.
To update the metric, go to the three cogs dropdown menu on the rightmost corner of the main Navigation Bar, locate Planning and click Planning Options:
As you can see, the system lists 8.0 hours as the current number of hours required to deliver a single story point of functionality. Now that we have some actual tasks in the product, click on the 'Suggest 'button to have the system provide its suggestion of the new metric:
Click the 'Apply' button to update the planning metric, and then click the main Save button at the very bottom of the page to confirm the change.
Click on the Artifacts > Test Cases menu option to display the product's test case list page:
The test case list is empty and the only folder visible in the 'Folders' tree on the left-hand side is 'Root'.
Add button underneath the folder treeAddYou now have a new folder in the 'Folders' tree view. To show it, click 'Refresh'.
Save And NewRepeat the above steps to create 3 more test cases:
You should now have the following test case list:
Next, we need to enter detailed test steps to each test case, and link each test to the appropriate requirements.
In the 'Description' box under 'Detailed Information' section, enter a brief overview of the test case (something like \"this test case verifies that you can add new users to the system and that all of the fields get saved correctly.\").
Scrolling down to the 'Test Steps' section, you will see a single test step has been automatically created for you with some suggested text:
This test case needs 3 test steps.
Click 'Edit' on 'Step 1' and enter the first set of parameters below.
Click Save and then 'Insert Step' to add the second test step and enter its information from below
Click 'Save and New' to make the third step
Once you've entered its information click Save
You should now have the following test steps in the test case:
Next, we need to link this test case to the requirement(s) that it validates.
Choose the 'System must allow the entry of users' requirement
Click the Save button beneath the list of requirements to add the test case to this requirement
Let's repeat the process for the other test cases, adding a couple of test steps to each. Then link the test cases to the requirements according to this table just like you did above:
Test Case Requirement Test ability to add new users System must allow entry of users Test ability to edit existing users System must allow the modification of users Test ability to delete existing users System must allow the deletion of users Test ability to edit notifications System should allow administrators to setup notificationsWe have created test cases and set up their test coverage. Next, we need to specify which releases and sprints they can be tested in.
Select the checkbox of each test case in the 'Functional Tests' folder.
Click on 'Tools' drop-down menu on the toolbar
Click 'Add to Release'
Select 'Release 1.0
Click Add.
You have added all the tests to the overarching Release. Finally, we want to add the tests to the different sprints, based off the data in the table below.
Select the checkbox of each relevant test case in the 'Functional Tests' folder.
Click on 'Tools' drop-down menu on the toolbar
Click 'Add to Release'
Select the appropriate sprint
Click Add
You typically want to include previous functionality in each of the successive iterations to ensure regression coverage. That is what we have done here. This means that each sprint includes new test cases for the new requirements, as well as existing test cases for pre-existing functionality.
"},{"location":"SpiraPlan-Quick-Start-Guide-Legacy/#planning-the-sprint","title":"Planning the Sprint","text":"We have requirements that have tasks, and tests connected to them. What we haven't done yet is scope out which requirements go in which sprint.
Each backlog item (requirement or incident) is represented by a virtual \"story card\" in the iteration. The left-hand side of each item displays the priority color. The progress bar near the bottom of each item depicts the progress of the item. You can flip through each iteration to see the work planned by clicking the left/right arrow buttons at the sides of the screen.
Now drag the two highest priority requirements (the ones with Importance = 1 - Critical) to the first iteration:
In the screenshots above the cards are showing more information then you may see by default. Extra information can be shown by toggling the buttons at the top right of the planning board
To see more information about each requirement, enable the 'Detailed View' option
To see the individual tasks associated with each requirement, select the 'Tasks' option
To see the individual tests associated with each requirement, select the 'Test Cases' option
You can determine how much time has been scheduled in the first sprint and how much time is remaining. Although we have spare time available in Iteration 1, we will leave room left for fixing incidents, so next, drag and drop the remaining two requirements to Iteration 2:
"},{"location":"SpiraPlan-Quick-Start-Guide-Legacy/#assigning-the-requirements-tasks","title":"Assigning the Requirements & Tasks","text":"Now that we have planned which requirements (user stories) and tasks are planned for each sprint, we can assign tasks to the appropriate developer(s). The process you follow will depend on your methodology (e.g. in Scrum the developers pick the tasks, but in Extreme Programming the product manager usually assigns tasks).
To assign the tasks, go to the main Navigation Bar and click on Artifact > Tasks to display the main tasks list page:
Click on the 'Board' option on the top-right of the screen to change to the Kanban board view:
You can see at a glance which tasks are in each status (in this case, they are all marked as 'Not Started'). To see the distribution of tasks by person for a specific sprint, change the release selection to 'Release 1.0 Iteration 1', and the 'Group By' dropdown to 'By Person':
For our sample product, we have two product members listed (included ourselves). As an example, select the first four tasks (which are all priority = 1 - Critical) and drag them to your user's section:
Now you can clearly see the four tasks that have been assigned to your user. To simulate how this would appear to a developer, click on the main SpiraPlan icon (in the top-left) to display your user's \"My Page\" dashboard:
This page lists all the development tasks that have been assigned to your user. Click on the task \"Create user data tables\" to display the task details page:
This task has been estimated at 10.0 hours and is currently not started. The next step is to start working on the assigned task and report back progress. As an example:
Operations button and choose 'Start Task'Save at the top of the pageThe progress indicator will reflect the changes and the new comment will have been added.
Now click on the other three assigned tasks, start them, and specify the following:
Requirement / Task Est. Estimate Actual Effort Remaining Effort Create user data tables 10.0h 3.0h 5.0h Develop user business object 10.0h 2.0h 7.5h Build user creation screens 20.0h 3.0h 18.0h Extend user business object to handle updates 5.0h 0.5h 4.0hAfter updating the assigned tasks, the 'My Page' dashboard will show all these changes:
Similarly, for the product manager, click on Requirements from the artifact dropdown in the global Navigation Bar to display the requirements list. This will show the task progress as it impacts the various requirements:
"},{"location":"SpiraPlan-Quick-Start-Guide-Legacy/#scheduling-the-testing-activities","title":"Scheduling the Testing Activities","text":"Now that we have created our test plan for each release and sprint, we need to schedule the test cases for execution by our testers. As an example, we'll create a single test set (also known as a test suite) that contains a list of test cases to be executed by a specific tester.
On the main Navigation Bar, click on Artifacts >Test Sets menu option to display the product's test set list page:
At first, the test set list will be empty and the 'Folders' tree on the left will only show 'Root'.
Add button beneath the folder treeAdd button.SaveYou should now have the following test set list:
Click on the hyperlink for the test set to bring up the test set details page:
Let's add the appropriate test cases to this set. Click the Add button in the 'Test Cases' section halfway down the page to bring up the following panel:
Select the following test cases and click the Save button:
You should now have the following displayed:
Next, let's assign this test set to a specific release and to a particular tester. To do that, choose the following values for the following fields and click Save:
You have now scheduled this test set to be executed by your user by the end of today against the first iteration of release 1.0:
"},{"location":"SpiraPlan-Quick-Start-Guide-Legacy/#running-tests-and-logging-incidents","title":"Running Tests and Logging Incidents","text":"Now that you have scheduled the test set, if you go to the 'My Page' by clicking on the SpiraPlan logo in the top-left, you'll see your newly assigned test set down on the left:
Click the 'Execute' button (with the play icon) to the right of this new test set. That will start the test execution wizard:
On the first screen, the release dropdown list will have been automatically pre-selected to the release specified in the test set. Click 'Next' to move to the first test step in the first test case:
Note that when you first visit this page, you will be shown a quick guided tour of how the page works.
As a tester, you can progress through each of the test steps in each test case in the test set in turn. For each test step you can enter Pass, Fail, Blocked, Caution, or Not Applicable. If you enter any status other than Pass you need to enter a value for the 'Actual Result'. For a pass status, the Actual Result is optional.
Click the 'Pass' button to pass the first test step. As soon as you do, the test will automatically progress to the second test step:
Now for the second test step, enter in the actual result field \"Unable to enter the sample data as the fields were disabled\". Before clicking the Fail button, we also want to enter in the following fields in the Incident form (accessed by clicking the \"Incidents\" tab):
Name: Error displaying user fields
Type: Bug
Priority: 2 - High
Now click the 'Fail' button and you will have recorded a test failure and a new incident/defect:
Now that we have logged the test failure and the new incident/defect, click on a hexagon on the main navigation bar on the left of \"Sample Empty Product 2\" option.
You'll be taken to the product homepage with the requirements and test case metrics now visible in individual widgets (like the Test Execution Status widget shown below):
If you go to the Artifacts > Test Sets page, you also see the status of our test set:
If you go to the Artifacts > Requirements page, you'll see the different requirements' test coverage and the status of the tests associated with each requirement:
The next step in the process is to triage the logged defect and assign it to a developer to be fixed.
"},{"location":"SpiraPlan-Quick-Start-Guide-Legacy/#triaging-issues-and-defects","title":"Triaging Issues and Defects","text":"Now that a new incident has been logged, the next step in the process is to review the incident and assign it to a developer to be fixed. First, click on the Artifacts > Incidents menu item. This will display the incident list page for the product. You can also view the same list of incidents in a Kanban board view.
In either view, click on the hyperlink for the new incident \"Error displaying user fields\". This will display the incident details page:
Save button in the top toolbar.The incident will be assigned to your user for fixing.
To see what a developer would see in real life, go back to the \"My Page\" by clicking on the orange SpiraPlan icon in the top-left of the main Navigation Bar on the top of the screen:
You can see that you've been assigned an incident under the \"My Assigned Incidents\" widget (on the right-hand side). Now click on the hyperlink for the incident to bring up the incident details page:
The status is 'Assigned' and the comment from the product manager is clearly visible. To help you reproduce the issue, you can click on the \"Associations\" tab to display the test run and requirements associated with this incident:
If you click on the test run hyperlink \"Test ability to add new users\", you will see the detailed information about the test execution that resulted in the bug being logged:
This allows the developer to retrace the steps taken by the tester and attempt to reproduce the issue. We are going to assume we can reproduce and fix the issue so we can go right ahead and resolve the incident.
Operations drop-down menu and select 'Resolve Incident'.Fill in the following fields:
Click Save on the main toolbar.
The incident will now change from Assigned > Resolved and an email will be sent to the tester letting them know that they need to retest the test case and close the incident.
"},{"location":"SpiraPlan-Quick-Start-Guide-Legacy/#reviewing-your-product","title":"Reviewing Your Product","text":"You can check on the overall status of the product by clicking the hexagon on the main navigation bar. This will take you to the product home page. Below is what this home page looks like for a more complete product than we have been working through in this quick start guide.
Note how you can change between several views (the buttons on the right) to show different information based on your role or current needs, or only show data for a particular release (see the dropdown beneath the product name on the left).
"},{"location":"SpiraPlan-Quick-Start-Guide-Legacy/#reviewing-a-program","title":"Reviewing a Program","text":"In addition to having dashboards that let you monitor the performance of your product, SpiraPlan has several views available at the program level. These let you group products together into a common program and report on them as a whole.
To see this in action, click on the \"Sample Program One\" link in the main navigation bar.
You can click on the Artifacts > Planning Board tab to display the Program Planning Board (which is similar to the one we used previously for products, except that it is works across multiple products):
There are additional program views that let you see the Releases and Incidents at a program level. Click Artifacts > Releases:
Congratulations
Congratulations! You have now completed the software development and testing lifecycle using SpiraPlan. For more information about any of the features, please refer to the SpiraPlan User Manual.
"},{"location":"SpiraTeam-Quick-Start-Guide/","title":"SpiraTeam Quick Start Guide","text":"Want to access the new and improved Quick Start Guide?
This SpiraTeam quick start guide still works great, but we have a newer and greater quick start guide. Please feel free to check it out.
"},{"location":"SpiraTeam-Quick-Start-Guide/#logging-in-and-selecting-a-product","title":"Logging In and Selecting a Product","text":"Once you have installed a self-hosted trial or signed up for a hosted trial of SpiraTeam, you should see the following login screen in your web browser:
Enter the following default details to start using the system:
Login: administrator
Password: PleaseChange
Once logged-in, you are shown your \"My Page\". The very first time you log in you will be able to take a quick orientation tour of the application (as shown in the screenshot below).
The My Page looks pretty empty right now. This is normal.
For this tutorial we want to start with an empty product that has no data in it, so click the hyperlink under 'My Products' for 'Sample Empty Product 2' / 'Sample Program'. That will select the empty product. Now to see the homepage for the product you just selected click on the hexagon in the top left:
The product home page shows various widgets containing key product metrics. These are empty now, because the product has no data in it. In the rest of this guide we are going to fix that.
"},{"location":"SpiraTeam-Quick-Start-Guide/#define-the-requirements","title":"Define the Requirements","text":"On the main Navigation bar, click Artifacts > Requirements to display the product's requirements list page:
The terminology in SpiraTeam is designed to be methodology agnostic. The table below shows how the terms used in SpiraTeam relate to some common methodologies:
SpiraPlan Extreme Programming Scrum AgileUP / DSDM Summary Requirement Epic Epic Feature Group Requirement User Story Backlog Item Requirement Task Task Task Task Release Release Release Release Sprint Iteration Sprint IterationAt first, the requirements list will be empty. Click the 'Insert' button in the toolbar to create your first requirement. Hit 'Save and New' (shown as buttons on the right of the new requirement in the list table) to add each new requirement after that except for the last requirement. After entering the last requirement, hit \"Save\" button. Below is the list of requirement names to add:
Functional Requirements
Module 1
System must allow entry of users
System must allow the modification of users
System must allow the deletion of users
Module 2
System should allow administrators to setup notifications
You should now have a simple, flat requirements list, like the one below:
Next, we are going to indent the requirements. This will give us a hierarchy, with some requirements being children of others.
To indent, select the checkboxes of all the requirements below 'Functional Requirements' and click 'Indent'. This makes 'Functional Requirements' the parent and all the other requirements its children.
Now, select the three requirements immediately below 'Module 1' and click 'Indent' again. This makes these three requirements children of 'Module 1' (and grandchildren of 'Functional Requirements')
Repeat for the requirement below 'Module 2' by right-clicking on this last requirement and choosing 'Indent' from the popup context menu.
You should now have a list that looks like:
We now have a nicely group set of requirements. Let's enter more information about them, starting with setting their types and priorities.
Click the ''select all' checkbox at the top of the list (the checkbox just above the checkbox for 'Functional Requirements')
Click on the top 'Edit' button in the right-hand column of that same row. That will make all the requirement rows editable:
Change the 'Type' to 'User Story' for some of the requirements - in the example screenshot all requirements that are children (have a single diamond icon and a non bold name) are now user stories.
Choose whatever values you like for the 'Importance' field for each of the requirements.
Click the 'Save' button.
You now have a prioritized list of user story requirements:
The next thing we can do is assign estimates to each requirement. This is something that the developers or business analysts may do based on the complexity and scope of each. The 'Estimates' column is not visible yet, so first we need to show it. To do that, click on the 'Show/Hide Columns' dropdown list and select 'Show Estimate (points)'.:
By default, all the requirements will have been assigned a default estimate of 1.0 point. A point is not a defined number of hours, but an indication of the size of the requirement. The estimates should reflect how big each of the requirements are relative to each other.
To change the estimates:
Click the \"select all\" checkbox at the top of the list
Click on the top 'Edit' button in the right-hand column. The requirements should be in editable mode again.
Enter the following estimates for the requirements
Click 'Save'
Your requirements should now look like this (with each parent's estimates automatically summing up the estimates of their children):
We have created a list of prioritized, estimated requirements, which is a great way to start our product. In the next section we are going to enter releases and sprints.
"},{"location":"SpiraTeam-Quick-Start-Guide/#create-the-release-and-iteration-plan","title":"Create the Release and Iteration Plan","text":"On the main navigation bar, click out of 'Requirements' and select 'Releases' menu option to display the product's release list page:
The release list will be empty. Click the 'Insert' button in the toolbar to create your first release. Hit 'Save and New' (shown as buttons on the right of the new release in the list table) to add each new release after that. Below is the list of release names to add
Release 1.0 -- version number 1.0.0.0
Start Date: Today's Date
End Date: Today's Date + 2 months
Release 1.1 -- version number 1.1.0.0
Start Date: Today's Date + 2 months
End Date: Today's Date + 4 months
You should have a list of releases like this:
We need to add one additional level of detail to each release -- the list of sprints that will take place in each release.
Let's add some sample sprints for the first release.
Select the checkbox for Release 1.0 and, from the toolbar, click Insert > Child Release.
Choose a name for the new sprint
Make sure its 'Type' is set to 'sprint'
Specify its date-range. We recommend making each sprint last 2-weeks and have each one scheduled in series
click 'Save And New'.
Repeat steps 2-5 above, then steps 2-4 and then finally click 'Save' on the final sprint's row. You should have three sprints added to the list, all children of Release 1.0
Finally, let's specify the number of resources assigned to each sprint and release.
Click on the 'Show/Hide Columns' dropdown list and select 'Show # Resources' column
Select the three checkboxes for the sprints of \"Release 1.0\"
Click the 'Edit' button on the toolbar.
Adjust the # resources for the sprints to 2.
Click 'Save':
We have defined the high-level schedule for Release 1.0. The next stage is to have the developers take each of the requirements defined so far and define the various tasks needed to deliver them. Each task will have its own estimate associated with it. In addition, you can optionally specify date-ranges and priorities to each of the individual tasks.
To start adding tasks, go to the main navigation bar and click out of Releases and hit Requirements to display the requirements list. Click on the hyperlink for the first requirement (\"System must allow entry of users\") and the requirement's details page will be displayed:
Notice that under 'Dates and Times' column on the right, the system displays an initial resource estimate of 1.5 points and 12 hours. This is based on an initial product setting of 8 hours per story point. Once you start adding tasks and getting metrics based on the actual team velocity (how many story points they can accomplish in a given time frame), the system can update that conversion metric.
Click on the 'Tasks' tab to display the list of tasks defined for this requirement. The list is empty, so let's change that:
Because we want to enter the estimated effort for each task, before entering the tasks, first click on the 'Show/Hide Columns' dropdown list and hit the 'Show Est. Effort' column.
Click the 'New Task' button (this adds a new task and associated it with this requirement)
Set the task's name to \"Create user data tables\"
Choose a 'Priority' level
Set the 'Est. effort' to 10.0h.
Click 'Save'.
The new task has now been added:
We have more tasks to add. The table below shows 12 tasks in total to add to 4 different requirements. This includes the one we just created for completeness.
Requirement / Task Est. Estimate System must allow entry of users Create user data tables 10.0h Develop user business object 10.0h Build user creation screens 20.0h System must allow the modification of users Extend user business object to handle updates 5.0h Add user list page 15.0h Add user details page 20.0h Add user permissions page 15.0h System must allow the deletion of users Extend user business object to handle deletes 5.0h Update user list page to add delete functionality 10.0h System should allow administrators to setup notifications Create user administration home 15.0h Add user settings for notifications to database 10.0h Create user notifications administration page 20.0hOn the main Navigation bar, click again on 'Requirements'. You should now have the following requirements list page. In this screenshot we have hidden the 'Author' field and shown the 'Task Effort' field to show the detailed task effort aggregated up to the requirements.
The total number of hours for these tasks divided by the total number of story points, gives a number a lot more than the 8 hours that the system assumes. We can update the system to better estimate the number of hours to deliver each story point.
To update the metric, go to the three cogs dropdown menu on the rightmost corner of the main Navigation Bar, locate Planning and click Planning Options:
As you can see, the system lists 8.0 hours as the current number of hours required to deliver a single story point of functionality. Now that we have some actual tasks in the product, click on the 'Suggest' button to have the system provide its suggestion of the new metric:
Click the 'Apply' button to update the planning metric, and then click the main 'Save' button at the very bottom of the page to confirm the change.
"},{"location":"SpiraTeam-Quick-Start-Guide/#adding-the-test-cases","title":"Adding the Test Cases","text":"Click on the Artifacts > Test Cases menu option to display the product's test case list page:
The test case list is empty and the only folder visible in the 'Folders' tree on the left-hand side is 'Root'.
Click on the 'Add' button underneath the folder tree,
Enter the new folder name 'Functional Tests'.
Click 'Add'.
Click on this folder from the 'Folders' tree on the left
Click 'New Test Case' from the toolbar.
Enter \"Test ability to add new users\" for the name of this new test case
Click 'Save And New'
Repeat the above steps to create 3 more test cases:
Test ability to edit existing users
Test ability to delete existing users
Test ability to edit notifications
You should now have the following test case list:
Next, we need to enter detailed test steps to each test case, and link each test to the appropriate requirements.
In the 'Description' box under 'Detailed Information' section, enter a brief overview of the test case (something like \"this test case verifies that you can add new users to the system and that all of the fields get saved correctly.\").
Scrolling down to the 'Test Steps' section, you will see a single test step has been automatically created for you with some suggested text:
This test case needs 3 test steps.
Click 'Edit' on 'Step 1' and enter the first set of parameters below.
Click 'Save' and then 'Insert Step' to add the second test step and enter its information from below
Click 'Save and New' to make the third step
Once you've entered its information click 'Save'
You should now have the following test steps in the test case:
Next, we need to link this test case to the requirement(s) that it validates.
Choose the 'System must allow the entry of users' requirement
Click the 'Save' button beneath the list of requirements to add the test case to this requirement
Let's repeat the process for the other test cases, adding a couple of test steps to each. Then link the test cases to the requirements according to this table just like you did above:
Test Case Requirement Test ability to add new users System must allow entry of users Test ability to edit existing users System must allow the modification of users Test ability to delete existing users System must allow the deletion of users Test ability to edit notifications System should allow administrators to setup notificationsWe have created test cases and set up their test coverage. Next, we need to specify which releases and sprints they can be tested in.
Select the checkbox of each test case in the 'Functional Tests' folder.
Click on 'Tools' drop-down menu on the toolbar
Click 'Add to Release'
Select 'Release 1.0
Click 'Add'.
You have added all the tests to the overarching Release. Finally, we want to add the tests to the different sprints, based off the data in the table below.
Select the checkbox of each relevant test case in the 'Functional Tests' folder.
Click on 'Tools' drop-down menu on the toolbar
Click 'Add to Release'
Select the appropriate sprint
Click 'Add'
You typically want to include previous functionality in each of the successive iterations to ensure regression coverage. That is what we have done here. This means that each sprint includes new test cases for the new requirements, as well as existing test cases for pre-existing functionality.
"},{"location":"SpiraTeam-Quick-Start-Guide/#planning-the-sprint","title":"Planning the Sprint","text":"We have requirements that have tasks, and tests connected to them. What we haven't done yet is scope out which requirements go in which sprint.
On the main Navigation Bar, click on the Planning > Planning Board option on the main menu to display the product backlog planning board.
Make sure the 'Group By' dropdown on the left is set to \"By Priority\"
Make sure all requirements are visible by checking the left-most column and ensuring that all priority levels are shown in an expanded view (downward facing triangle signs)
To view the iteration plan for a specific release, select 'Release 1.0' on the 'Planning:' drop down menu on the top left.
Choose 'By Sprint' from the drop-down 'Group By' menu. That will display the sprint plan for the selected release (currently empty)
Each backlog item (requirement or incident) is represented by a virtual \"story card\" in the iteration. The left-hand side of each item displays the priority color. The progress bar near the bottom of each item depicts the progress of the item. You can flip through each iteration to see the work planned by clicking the left/right arrow buttons at the sides of the screen.
Now drag the two highest priority requirements (the ones with Importance = 1-Critical) to the first iteration:
In the screenshots above the cards are showing more information then you may see by default. Extra information can be shown by toggling the buttons at the top right of the planning board
To see more information about each requirement, enable the 'Detailed View' option
To see the individual tasks associated with each requirement, select the 'Tasks' option
To see the individual tests associated with each requirement, select the 'Test Cases' option
You can determine how much time has been scheduled in the first sprint and how much time is remaining. Although we have spare time available in Iteration 1, we will leave room left for fixing incidents, so next, drag and drop the remaining two requirements to Iteration 2:
"},{"location":"SpiraTeam-Quick-Start-Guide/#assigning-the-requirements-tasks","title":"Assigning the Requirements & Tasks","text":"Now that we have planned which requirements (user stories) and tasks are planned for each sprint, we can assign tasks to the appropriate developer(s). The process you follow will depend on your methodology (e.g. in Scrum the developers pick the tasks, but in Extreme Programming the product manager usually assigns tasks).
To assign the tasks, go to the main Navigation Bar and click on Artifact > Tasks to display the main tasks list page:
Click on the 'Board' option on the top-right of the screen to change to the Kanban board view:
You can see at a glance which tasks are in each status (in this case, they are all marked as 'Not Started'). To see the distribution of tasks by person for a specific sprint, change the release selection to 'Release 1.0 Iteration 1', and the 'Group By' dropdown to 'By Person':
For our sample product, we have two product members listed (included ourselves). As an example, select the first four tasks (which are all priority = 1 -- Critical) and drag them to your user's section:
Now you can clearly see the four tasks that have been assigned to your user. To simulate how this would appear to a developer, click on the main SpiraTeam icon (in the top-left) to display your user's \"My Page\" dashboard:
This page lists all the development tasks that have been assigned to your user. Click on the task \"Create user data tables\" to display the task details page:
This task has been estimated at 10.0 hours and is currently not started. The next step is to start working on the assigned task and report back progress. As an example:
click the workflow 'Operations' and chose 'Start Task'.
Then under 'Dates and Times' enter an 'Actual Effort' of 3.0 hours, and a 'Remaining Effort' of 5.0 hours.
In the 'Comments' section below, add a comment: \"Added initial set of data tables\",
Click 'Save' at the top of the page.
The progress indicator will reflect the changes and the new comment will have been added.
Now click on the other three assigned tasks, start them, and specify the following:
Requirement / Task Est. Estimate Actual Effort Remaining Effort Create user data tables 10.0h 3.0h 5.0h Develop user business object 10.0h 2.0h 7.5h Build user creation screens 20.0h 3.0h 18.0h Extend user business object to handle updates 5.0h 0.5h 4.0hAfter updating the assigned tasks, the 'My Page' dashboard will show all these changes:
Similarly, for the product manager, On the main Navigation Bar, clicking on Artifacts > Requirements to display the requirements list will show the task progress as it impacts the various requirements:
"},{"location":"SpiraTeam-Quick-Start-Guide/#scheduling-the-testing-activities","title":"Scheduling the Testing Activities","text":"Now that we have created our test plan for each release and sprint, we need to schedule the test cases for execution by our testers. As an example, we'll create a single test set (also known as a test suite) that contains a list of test cases to be executed by a specific tester.
On the main Navigation Bar, click on Artifacts >Test Sets menu option to display the product's test set list page:
At first, the test set list will be empty and the 'Folders' tree on the left will only show 'Root'.
Click the 'Add' button beneath the folder tree
Enter the new folder name 'Test Cycle #1'
Click the 'Add' button.
Click on the folder you just made
Click 'New Test Set' from the toolbar.
Enter the name of the new test set 'Testing new functionality'
Click 'Save'
You should now have the following test set list:
Click on the hyperlink for the test set to bring up the test set details page:
Let's add the appropriate test cases to this set.
Locate 'Root' drop down menu under 'Test Cases' section.
Choose the 'Functional Tests' folder and the test cases in that folder will be displayed:
Test ability to add new users
Test ability to edit existing users
You should now have the following displayed:
Next, let's assign this test set to a specific release and to a particular tester. To do that, choose the following values for the following fields and click 'Save':
Owner = System Administrator (your user)
Scheduled = Release 1.0 - Iteration 1
Planned Date = (Today's Date).
You have now scheduled this test set to be executed by your user by the end of today against the first iteration of release 1.0:
"},{"location":"SpiraTeam-Quick-Start-Guide/#running-tests-and-logging-incidents","title":"Running Tests and Logging Incidents","text":"Now that you have scheduled the test set, if you go to the 'My Page' by clicking on the SpiraTeam logo in the top-left, you'll see your newly assigned test set down on the left:
Click the 'Execute' button (with the play icon) to the right of this new test set. That will start the test execution wizard:
On the first screen, the release dropdown list will have been automatically pre-selected to the release specified in the test set. Click 'Next' to move to the first test step in the first test case:
Note that when you first visit this page, you will be shown a quick guided tour of how the page works.
As a tester, you can progress through each of the test steps in each test case in the test set in turn. For each test step you can enter Pass, Fail, Blocked, Caution, or Not Applicable. If you enter any status other than Pass you need to enter a value for the 'Actual Result'. For a pass status, the Actual Result is optional.
Click the 'Pass' button to pass the first test step. As soon as you do, the test will automatically progress to the second test step:
Now for the second test step, enter in the actual result field \"Unable to enter the sample data as the fields were disabled\". Before clicking the Fail button, we also want to enter in the following fields in the Incident form (accessed by clicking the \"Incidents\" tab):
Name = Error displaying user fields
Type = Bug
Priority = 2 -- High
Now click the 'Fail' button and you will have recorded a test failure and a new incident/defect:
Now that we have logged the test failure and the new incident/defect, click on a hexagon on the main navigation bar on the left of \"Sample Empty Product 2\" option.
You'll be taken to the product homepage with the requirements and test case metrics now visible in individual widgets (like the Test Execution Status widget shown below):
If you go to the Artifacts > Test Sets page, you also see the status of our test set:
If you go to the Artifacts > Requirements page, you'll see the different requirements' test coverage and the status of the tests associated with each requirement:
The next step in the process is to triage the logged defect and assign it to a developer to be fixed.
"},{"location":"SpiraTeam-Quick-Start-Guide/#triaging-issues-and-defects","title":"Triaging Issues and Defects","text":"Now that a new incident has been logged, the next step in the process is to review the incident and assign it to a developer to be fixed. First, click on the Artifacts > Incidents menu item. This will display the incident list page for the product. You can also view the same list of incidents in a Kanban board view.
In either view, click on the hyperlink for the new incident \"Error displaying user fields\". This will display the incident details page:
In the 'Operations' dropdown menu underneath the incident name on the top of the page, select 'Assign Incident' option. This will switch the status of the incident from New > Assigned.
Location the 'People' section and set the 'Owner' field to System Administrator (your user)
Add a new comment in the 'Comments' section at the bottom of the page. Type \"Assigning this to you to fix. Issue was found during testing.\"
Click the 'Save' button in the top toolbar.
The incident will be assigned to your user for fixing.
To see what a developer would see in real life, go back to the \"My Page\" by clicking on the orange SpiraTeam icon in the top-left of the main Navigation Bar on the top of the screen:
You can see that you've been assigned an incident under the \"My Assigned Incidents\" widget (on the right-hand side). Now click on the hyperlink for the incident to bring up the incident details page:
The status is 'Assigned' and the comment from the product manager is clearly visible. To help you reproduce the issue, you can click on the \"Associations\" tab to display the test run and requirements associated with this incident:
If you click on the test run hyperlink \"Test ability to add new users\", you will see the detailed information about the test execution that resulted in the bug being logged:
This allows the developer to retrace the steps taken by the tester and attempt to reproduce the issue. We are going to assume we can reproduce and fix the issue so we can go right ahead and resolve the incident.
Make your way back to the incident details screen: Artifacts> Incidents > Error displaying user fields' Hyperlink.
Click on the workflow 'Operations' drop-down menu and select 'Resolve Incident'.
Fill in the following fields
Click 'Save' on the main toolbar
The incident will now change from Assigned > Resolved and an email will be sent to the tester letting them know that they need to retest the test case and close the incident.
"},{"location":"SpiraTeam-Quick-Start-Guide/#reviewing-your-product","title":"Reviewing Your Product","text":"You can check on the overall status of the product by clicking the hexagon on the main navigation bar. This will take you to the product home page. Below is what this home page looks like for a more complete product than we have been working through in this quick start guide.
Note how you can change between several views (the buttons on the right) to show different information based on your role or current needs, or only show data for a particular release (see the dropdown beneath the product name on the left).
Congratulations! You have now completed the software development and testing lifecycle using SpiraTeam. For more information about any of the features, please refer to the SpiraTeam User Manual.
"},{"location":"SpiraTest-Quick-Start-Guide/","title":"SpiraTest Quick Start Guide","text":"Want to access the new and improved Quick Start Guide?
This SpiraTest quick start guide still works great, but we have a newer and greater quick start guide. Please feel free to check it out.
"},{"location":"SpiraTest-Quick-Start-Guide/#logging-in-and-selecting-a-product","title":"Logging in and Selecting a Product","text":"Once you have installed a self-hosted trial or signed up for a hosted trial of SpiraTest, you should see the following login screen in your web browser:
Enter the following default details to start using the system:
Login: administrator
Password: PleaseChange
Once logged-in, you are shown your \"My Page\". The very first time you log in you will be able to take a quick orientation tour of the application (as shown in the screenshot below).
The My Page looks pretty empty right now. This is normal.
For this tutorial we want to start with an empty product that has no data in it, so click the hyperlink under 'My Products' for 'Sample Empty Product 2' / 'Sample Program'. That will select the empty product. Now to see the homepage for the product you just selected click on the hexagon in the top left:
The product home page shows various widgets containing key product metrics. These are empty now, because the product has no data in it. In the rest of this guide we are going to fix that.
"},{"location":"SpiraTest-Quick-Start-Guide/#define-the-requirements","title":"Define the Requirements","text":"On the main Navigation bar, click Artifacts > Requirements to display the product's requirements list page:
The terminology in SpiraTest is designed to be methodology agnostic. The table below shows how the terms used in SpiraTest relate to some common methodologies:
SpiraPlan Extreme Programming Scrum AgileUP / DSDM Summary Requirement Epic Epic Feature Group Requirement User Story Backlog Item Requirement Task Task Task Task Release Release Release Release Sprint Iteration Sprint IterationAt first, the requirements list will be empty. Click the 'Insert' button in the toolbar to create your first requirement. Hit 'Save and New' (shown as buttons on the right of the new requirement in the list table) to add each new requirement after that except for the last requirement. After entering the last requirement, hit \"Save\" button. Below is the list of requirement names to add:
Functional Requirements
Module 1
System must allow entry of users
System must allow the modification of users
System must allow the deletion of users
Module 2
System should allow administrators to setup notifications
You should now have a simple, flat requirements list, like the one below:
Next, we are going to indent the requirements. This will give us a hierarchy, with some requirements being children of others.
To indent, select the checkboxes of all the requirements below 'Functional Requirements' and click 'Indent'. This makes 'Functional Requirements' the parent and all the other requirements its children.
Now, select the three requirements immediately below 'Module 1' and click 'Indent' again. This makes these three requirements children of 'Module 1' (and grandchildren of 'Functional Requirements')
Repeat for the requirement below 'Module 2' by right-clicking on this last requirement and choosing 'Indent' from the popup context menu.
You should now have a list that looks like:
We now have a nicely group set of requirements. Let's enter more information about them, starting with setting their types and priorities.
Click the ''select all' checkbox at the top of the list (the checkbox just above the checkbox for 'Functional Requirements')
Click on the top 'Edit' button in the right-hand column of that same row. That will make all the requirement rows editable:
Change the 'Type' to 'User Story' for some of the requirements - in the example screenshot all requirements that are children (have a single diamond icon and a non bold name) are now user stories.
Choose whatever values you like for the 'Importance' field for each of the requirements.
Click the 'Save' button.
You now have a prioritized list of user story requirements:
The next thing we can do is assign estimates to each requirement. This is something that the developers or business analysts may do based on the complexity and scope of each. The 'Estimates' column is not visible yet, so first we need to show it. To do that, click on the 'Show/Hide Columns' dropdown list and select 'Show Estimate (points)'.:
By default, all the requirements will have been assigned a default estimate of 1.0 point. A point is not a defined number of hours, but an indication of the size of the requirement. The estimates should reflect how big each of the requirements are relative to each other.
To change the estimates:
Click the \"select all\" checkbox at the top of the list
Click on the top 'Edit' button in the right-hand column. The requirements should be in editable mode again.
Enter the following estimates for the requirements
Click 'Save'
Your requirements should now look like this (with each parent's estimates automatically summing up the estimates of their children):
We have created a list of prioritized, estimated requirements, which is a great way to start our product. In the next section we are going to enter releases and sprints.
"},{"location":"SpiraTest-Quick-Start-Guide/#create-the-release-and-iteration-plan","title":"Create the Release and Iteration Plan","text":"On the main navigation bar, click out of 'Requirements' and select 'Releases' menu option to display the product's release list page:
The release list will be empty. Click the 'Insert' button in the toolbar to create your first release. Hit 'Save and New' (shown as buttons on the right of the new release in the list table) to add each new release after that. Below is the list of release names to add
Release 1.0 -- version number 1.0.0.0
Start Date: Today's Date
End Date: Today's Date + 2 months
Release 1.1 -- version number 1.1.0.0
Start Date: Today's Date + 2 months
End Date: Today's Date + 4 months
You should have a list of releases like this:
We need to add one additional level of detail to each release -- the list of sprints that will take place in each release.
Let's add some sample sprints for the first release.
Select the checkbox for Release 1.0 and, from the toolbar, click Insert > Child Release.
Choose a name for the new sprint
Make sure its 'Type' is set to 'sprint'
Specify its date-range. We recommend making each sprint last 2-weeks and have each one scheduled in series
click 'Save And New'.
Repeat steps 2-5 above, then steps 2-4 and then finally click 'Save' on the final sprint's row. You should have three sprints added to the list, all children of Release 1.0
Finally, let's specify the number of resources assigned to each sprint and release.
Click on the 'Show/Hide Columns' dropdown list and select 'Show # Resources' column
Select the three checkboxes for the sprints of \"Release 1.0\"
Click the 'Edit' button on the toolbar.
Adjust the # resources for the sprints to 2.
Click 'Save'
Now that we have the releases and sprints scheduled, we now need to assign our previously defined requirements to the different releases.
On the main navigation bar, click on Artifacts' drop-down menu and click Requirements to display the requirements list.
Click the 'select all' checkbox at the top of the list
Click the top 'Edit' button on the main tool bar. That will make all the cells editable.
Now choose the release/sprint for each of the lower-level requirements
Click 'Save'
Notice that all the requirements have automatically changed status from 'Requested' to 'Planned', this is because they have been assigned a specific release/iteration.
"},{"location":"SpiraTest-Quick-Start-Guide/#build-the-test-plan","title":"Build the Test Plan","text":"On the main Navigation bar, click on the Artifacts drop-down menu and select Test Cases menu option to display the product's test case list page:
The test case list is empty and the only folder visible in the 'Folders' tree on the left-hand side is 'Root'.
Click on the 'Add' button underneath the folder tree,
Enter the new folder name 'Functional Tests'.
Click 'Add'.
Click on this folder from the 'Folders' tree on the left
Click 'New Test Case' from the toolbar.
Enter \"Test ability to add new users\" for the name of this new test case
Click 'Save And New'
Repeat the above steps to create 3 more test cases:
Test ability to edit existing users
Test ability to delete existing users
Test ability to edit notifications
You should now have the following test case list:
Next, we need to enter detailed test steps to each test case, and link each test to the appropriate requirements.
In the 'Description' box under 'Detailed Information' section, enter a brief overview of the test case (something like \"this test case verifies that you can add new users to the system and that all of the fields get saved correctly.\").
Scrolling down to the 'Test Steps' section, you will see a single test step has been automatically created for you with some suggested text:
This test case needs 3 test steps.
Click 'Edit' on 'Step 1' and enter the first set of parameters below.
Click 'Save' and then 'Insert Step' to add the second test step and enter its information from below
Click 'Save and New' to make the third step
Once you've entered its information click 'Save'
You should now have the following test steps in the test case:
Next, we need to link this test case to the requirement(s) that it validates.
Choose the 'System must allow the entry of users' requirement
Click the 'Save' button beneath the list of requirements to add the test case to this requirement
Let's repeat the process for the other test cases, adding a couple of test steps to each. Then link the test cases to the requirements according to this table just like you did above:
Test Case Requirement Test ability to add new users System must allow entry of users Test ability to edit existing users System must allow the modification of users Test ability to delete existing users System must allow the deletion of users Test ability to edit notifications System should allow administrators to setup notificationsWe have created test cases and set up their test coverage. Next, we need to specify which releases and sprints they can be tested in.
Select the checkbox of each test case in the 'Functional Tests' folder.
Click on 'Tools' drop-down menu on the toolbar
Click 'Add to Release'
Select 'Release 1.0
Click 'Add'.
You have added all the tests to the overarching Release. Finally, we want to add the tests to the different sprints, based off the data in the table below.
Select the checkbox of each relevant test case in the 'Functional Tests' folder.
Click on 'Tools' drop-down menu on the toolbar
Click 'Add to Release'
Select the appropriate sprint
Click 'Add'
You typically want to include previous functionality in each of the successive iterations to ensure regression coverage. That is what we have done here. This means that each sprint includes new test cases for the new requirements, as well as existing test cases for pre-existing functionality.
"},{"location":"SpiraTest-Quick-Start-Guide/#scheduling-the-testing-activities","title":"Scheduling the Testing Activities","text":"Now that we have created our test plan for each release and sprint, we need to schedule the test cases for execution by our testers. As an example, we'll create a single test set (also known as a test suite) that contains a list of test cases to be executed by a specific tester.
On the main Navigation Bar, click on Artifacts >Test Sets menu option to display the product's test set list page:
At first, the test set list will be empty and the 'Folders' tree on the left will only show 'Root'.
Click the 'Add' button beneath the folder tree
Enter the new folder name 'Test Cycle #1'
Click the 'Add' button.
Click on the folder you just made
Click 'New Test Set' from the toolbar.
Enter the name of the new test set 'Testing new functionality'
Click 'Save'
You should now have the following test set list:
Click on the hyperlink for the test set to bring up the test set details page:
Let's add the appropriate test cases to this set.
Locate 'Root' drop down menu under 'Test Cases' section.
Choose the 'Functional Tests' folder and the test cases in that folder will be displayed:
Test ability to add new users
Test ability to edit existing users
You should now have the following displayed:
Next, let's assign this test set to a specific release and to a particular tester. To do that, choose the following values for the following fields and click 'Save':
Owner = System Administrator (your user)
Scheduled = Release 1.0 - Iteration 1
Planned Date = (Today's Date).
You have now scheduled this test set to be executed by your user by the end of today against the first iteration of release 1.0:
"},{"location":"SpiraTest-Quick-Start-Guide/#running-tests-and-logging-incidents","title":"Running Tests and Logging Incidents","text":"Now that you have scheduled the test set, if you go to the 'My Page' by clicking on the SpiraTest logo in the top-left, you'll see your newly assigned test set down on the left:
Click the 'Execute' button (with the play icon) to the right of this new test set. That will start the test execution wizard:
On the first screen, the release dropdown list will have been automatically pre-selected to the release specified in the test set. Click 'Next' to move to the first test step in the first test case:
Note that when you first visit this page, you will be shown a quick guided tour of how the page works.
As a tester, you can progress through each of the test steps in each test case in the test set in turn. For each test step you can enter Pass, Fail, Blocked, Caution, or Not Applicable. If you enter any status other than Pass you need to enter a value for the 'Actual Result'. For a pass status, the Actual Result is optional.
Click the 'Pass' button to pass the first test step. As soon as you do, the test will automatically progress to the second test step:
Now for the second test step, enter in the actual result field \"Unable to enter the sample data as the fields were disabled\". Before clicking the Fail button, we also want to enter in the following fields in the Incident form (accessed by clicking the \"Incidents\" tab):
Name = Error displaying user fields
Type = Bug
Priority = 2 -- High
Now click the 'Fail' button and you will have recorded a test failure and a new incident/defect:
Now that we have logged the test failure and the new incident/defect, click on a hexagon on the main navigation bar on the left of \"Sample Empty Product 2\" option.
You'll be taken to the product homepage with the requirements and test case metrics now visible in individual widgets (like the Test Execution Status widget shown below):
If you go to the Artifacts > Test Sets page, you also see the status of our test set:
If you go to the Artifacts > Requirements page, you'll see the different requirements' test coverage and the status of the tests associated with each requirement:
The next step in the process is to triage the logged defect and assign it to a developer to be fixed.
"},{"location":"SpiraTest-Quick-Start-Guide/#triaging-issues-and-defects","title":"Triaging Issues and Defects","text":"Now that a new incident has been logged, the next step in the process is to review the incident and assign it to a developer to be fixed. First, click on the Artifacts > Incidents menu item. This will display the incident list page for the product.
Click on the hyperlink for the new incident \"Error displaying user fields\". This will display the incident details page:
In the 'Operations' dropdown menu underneath the incident name on the top of the page, select 'Assign Incident' option. This will switch the status of the incident from New > Assigned.
Location the 'People' section and set the 'Owner' field to System Administrator (your user)
Add a new comment in the 'Comments' section at the bottom of the page. Type \"Assigning this to you to fix. Issue was found during testing.\"
Click the 'Save' button in the top toolbar.
The incident will be assigned to your user for fixing.
To see what a developer would see in real life, go back to the \"My Page\" by clicking on the orange SpiraTest icon in the top-left of the main Navigation Bar on the top of the screen:
You can see that you've been assigned an incident under the \"My Assigned Incidents\" widget (on the right-hand side). Now click on the hyperlink for the incident to bring up the incident details page:
The status is 'Assigned' and the comment from the product manager is clearly visible. To help you reproduce the issue, you can click on the \"Associations\" tab to display the test run and requirements associated with this incident:
If you click on the test run hyperlink \"Test ability to add new users\", you will see the detailed information about the test execution that resulted in the bug being logged:
This allows the developer to retrace the steps taken by the tester and attempt to reproduce the issue. We are going to assume we can reproduce and fix the issue so we can go right ahead and resolve the incident.
Make your way back to the incident details screen: Artifacts> Incidents > Error displaying user fields' Hyperlink.
Click on the workflow 'Operations' drop-down menu and select 'Resolve Incident'.
Fill in the following fields
Click 'Save' on the main toolbar
The incident will now change from Assigned > Resolved and an email will be sent to the tester letting them know that they need to retest the test case and close the incident.
"},{"location":"SpiraTest-Quick-Start-Guide/#reviewing-your-product","title":"Reviewing Your Product","text":"You can check on the overall status of the product by clicking the hexagon on the main navigation bar. This will take you to the product home page. Below is what this home page looks like for a more complete product than we have been working through in this quick start guide.
Note how you can change between several views (the buttons on the right) to show different information based on your role or current needs, or only show data for a particular release (see the dropdown beneath the product name on the left).
Congratulations, you have now completed the testing lifecycle using SpiraTest. For more information about any of the features, please refer to the SpiraTest User Manual.
"},{"location":"TaraVault-User-Manual/Activating-TaraVault/","title":"Activating TaraVault","text":""},{"location":"TaraVault-User-Manual/Activating-TaraVault/#introduction","title":"Introduction","text":"TaraVault\u00ae is the secure source code and file hosting service from Inflectra that allows you to host source code and other assets in our secure cloud, integrated with our SpiraPlan\u00ae application lifecycle management system.
This guide assumes that the reader is familiar with both SpiraPlan/SpiraTeam and the appropriate SCM platform (Git and/or Subversion). For information regarding how to use SpiraPlan/Team, please refer to the User Manual.
You can use either Git or Subversion with TaraVault. If you want to learn more about each of these and which is right for you, read our intro guides to using Git and using Subversion.
"},{"location":"TaraVault-User-Manual/Activating-TaraVault/#activation","title":"Activation","text":"To activate TaraVault:
NOTE: If you don't see the above link it will because you are: self-hosted, are using SpiraTest, or are not a system administrator. Please contact Inflectra customer services to upgrade to SpiraTeam or SpiraPlan, if needed.
If TaraVault is not yet activated, the TaraVault page displays a message explaining just that. This is normal. Click 'Activate TaraVault' to activate TaraVault. Once this succeeds, the page will change to look like the image below.
This shows you you the following information:
Now that TaraVault is active, you can:
Once you have activated TaraVault, you can begin to provision specific products to use source code with TaraVault and assign users to commit code or files into the TaraVault repositories. Note: All SpiraPlan users with roles that let them view source code, can view the code in the application, even if they are not a TaraVault user.
"},{"location":"TaraVault-User-Manual/Provisioning-Projects-%26-Users/#provisioning-products","title":"Provisioning Products","text":"When you provision a product with TaraVault you are setting up TaraVault's source code to be fully integrated into the SpiraPlan product. To do this:
This opens the TaraVault product administration page. In the screenshot below we have selected the 'Library Information System' sample product:
To provision this product with TaraVault:
Click 'Activate' to complete the TaraVault setu for this product.
In the screenshot below we have chosen 'libraryinformationsystem' as the product name and 'Git' as the type. The application will now:
Once TaraVault has been activated on a product, you can perform the following actions:
By default, the built-in system administrator account will be automatically enabled for TaraVault and will be added as a member of all TaraVault products. To enable other users to commit code/files to a TaraVault repository, go to Administration > Users > View/Edit Users menu item.
Click on the user you want to add to TaraVault. This will show their user details page. On this page, if TaraVault is active, you will see a TaraVault tab. From here you can enable a specific Spira user for TaraVault:
Now change the setting to \"YES\" and the following screen appears:
Enter a TaraVault password and click 'Save'. The user is now added to TaraVault and you can add them to specific TaraVault products.
To add a user to TaraVault products, make sure you are on their admin user details page. On the TaraVault tab click \"Add Products\".
You can now choose which TaraVault products to add the user to - select Yes for each active TaraVault product they should be added to. Then click Save.
The user will now be listed for those specific TaraVault products.
On the admin user details page, on the TaraVault tab:
And on the Product Admin > Source Code page:
You can see in the example above we have two users listed under the current product Library Information System. If you click on any of the 'Edit Users' you can make changes to the TaraVault user settings page.
From here you can:
Individual users can see their own TaraVault profile from the main Spira profile page. They need to click on the 'My Profile' link under their user's avatar on the main Spira navigation page:
This page displays the current user's TaraVault login and password (masked). They can update the password for connecting to TaraVault.
"},{"location":"TaraVault-User-Manual/Provisioning-Projects-%26-Users/#connecting-to-the-source-code-repository","title":"Connecting to the Source Code Repository","text":"Individual users can see the connection information they can use for connecting via. Git or Subversion by going to Developing > Source Code:
This dialog displays the connection string they should use to connect to the current product (the format will depend on whether the user is using Git or Subversion) along with the login and password.
They can click on the blurred password option to reveal their actual password. This is necessary since they will need to know the password to use when connecting to Subversion / Git using their desired SCM client (e.g. TortoiseSVN, TortoiseGit, etc.).
"},{"location":"TaraVault-User-Manual/Using-Git/","title":"Using Git","text":"Git is a Distributed Version Control System (DVCS) system that keeps track of software commits and allows many developers to work on a given project without necessarily being connected to a common network since it doesn't rely on a central repository, but instead distributes copies of the entire source code repository to each user's workstation.
"},{"location":"TaraVault-User-Manual/Using-Git/#git-basics","title":"Git Basics","text":"The major difference between Git and most other VCS (e.g. Subversion described in the previous section) is the way Git thinks about its data. Conceptually, most other systems store information as a list of file-based changes. These systems (CVS, Subversion, Perforce, Bazaar, and so on) think of the information they keep as a set of files and the changes made to each file over time.
Git doesn't think of or store its data this way. Instead, Git thinks of its data more like a set of snapshots of a miniature filesystem. Every time you commit, or save the state of your project in Git, it basically takes a picture of what all your files look like at that moment and stores a reference to that snapshot. To be efficient, if files have not changed, Git doesn't store the file again, just a link to the previous identical file it has already stored. Git thinks about its data more like a stream of snapshots:
This is an important distinction between Git and nearly all other VCSs. It makes Git reconsider almost every aspect of version control that most other systems copied from the previous generation. This makes Git more like a mini filesystem with some incredibly powerful tools built on top of it, rather than simply a VCS.
Another major difference between Git and Subversion is that Git has built-in support for 'branches' instead of relying on a specific folder structure. In Git, Branches are used to develop features isolated from each other. The master branch is the \"default\" branch when you create a repository. You can then use other branches for development and merge them back to the master branch upon completion.
"},{"location":"TaraVault-User-Manual/Using-Git/#working-with-remotes","title":"Working with Remotes","text":"To be able to work on any Git project, you need to know how to manage your remote repositories. Remote repositories the versions of your project that are hosted TaraVault itself. Collaborating with others involves managing these remote repositories and pushing and pulling data to and from them when you need to share work. Managing remote repositories includes knowing how to add remote repositories, remove remotes that are no longer valid, manage various remote branches and define them as being tracked or not, and more.
This is in stark contrast to Subversion where every commit and update is being performed directly on the central TaraVault remote repository. So when you make changes to your local repository, the will need to explicitly synchronized with TaraVault for other users to see them, and for them to appear in Spira:
"},{"location":"TaraVault-User-Manual/Using-Git/#getting-started-with-git","title":"Getting Started with Git","text":"This section assumes that you have already provisioned at least one Git project in TaraVault following the steps in Activating TaraVault and Provisioning Projects & Users. So you should now have a TaraVault user/password and a Git project with a connection URL:
The next step is to actually connect to this repository using a Git client and commit some source code. We recommend using a GUI tool such as TortoiseGit but you can use any standard Git client with TaraVault (command-line or GUI-based) just as well. In our examples we shall be using TortoiseGit.
The first thing we need to do is perform an initial 'clone' of our remote Git repository into a local repository. This will also do an implicit checkout from the local repository into the working directory.
Assuming that you have already installed TortoiseGit, you would now create a folder to hold all of your Git projects (in our example we shall use C:\\Temp\\Git) and right-click and choose \"Git Clone\":
The following dialog box will appear:
You need to enter the following:
URL-- needs to be the TaraVault Git connection string listed under 'My Profile' for the current project.
Directory -- needs to be the local name of the folder for the local repository. Typically it is best to make it the same as the name of the project in TaraVault (e.g. C:\\Temp\\Git\\libraryinformationsystem in this example)
When you click on the 'OK' button, the following authentication dialog box will appear:
Enter your TaraVault Git username, and then click 'OK'. Then the following will appear:
Enter your TaraVault password and then click 'OK' again. The success dialog will appear:
You will now get a folder C:\\Temp\\Git\\sampleapplicationone that is completely empty apart from a special .git folder that is used by Git internally.
Now that you have your Git local repository and working folder available, you are ready to start using Git.
"},{"location":"TaraVault-User-Manual/Using-Git/#adding-files-to-the-master-branch","title":"Adding Files to the Master Branch","text":"Now that you have your Git repository ready, we shall simulate working on a real project. You can now copy some code and folders into the empty working folder (which will be set to use the 'master' branch). In this example we shall add some sample Inflectra code:
Select all the files and folders and choose TortoiseGit > Add. That will display the following dialog box:
Select all the files and click OK.
Click on [OK] to commit the files to the local repository. Note that this does not send them to the remote TaraVault repository at this stage since this is a distributed version control system and all commits are done locally.
Enter in the appropriate commit message and then click [OK] to complete the local commit. The following screen will be displayed:
At this stage, we are not ready to 'Push' the repository to TaraVault so just click 'Close'.
Now, open up one of the files (we shall modify the SampleTestSuite\\AssemblyInfo.cs file in our example) and make a change to it. Then right-click on the top-level 'sampleapplicationone' folder and choose Git Commit -> \"master\" to commit the change. Make sure you add a comment:
Click OK and the change (known as a commit) will now be committed into the 'master' branch of the local repository.
"},{"location":"TaraVault-User-Manual/Using-Git/#working-with-branches","title":"Working with Branches","text":"Now that we have the primary development line in our master branch, we can work on a separate version of the code in a different branch, and then at a later date merge back in the changes to the 'master' branch. For example we might be working on an experimental new feature and we only want to merge it into the 'master' when it is internally stable and all the unit tests pass.
We shall create a new named branch in our local repository using TortoiseGit. To do that right-click on the top-level folder (sampleapplicationone) and then click Tortoise Git > Create Branch:
This will display the following dialog box:
Enter in the name of the new branch (we have chosen 'experimental' in the example shown) and click [OK] to create the new branch. Since we want to start working in this new branch, we should now using TortoiseGit > Switch/Checkout to switch to this new branch:
Click [OK] to confirm the switch. Now all your changes will be made on this branch.
Now, let's simulate making a code change on the 'experimental' branch we made. To do that, change one of the files in the folder structure and then right-click Git Commit -> \"experimental\":
That will display the commit dialog box:
Enter in a comment in the 'Message' text box that describes the purpose of the change. Then click [OK]. On the success dialog box that appears, click 'Close'.
Now unlike other VCS such as Subversion, we have made all of these changes in the local Git repository. Once you are ready to share your changes with your team, you need to 'Push' the local branches to the remote TaraVault repository.
To do this, right-click on the top-level folder (sampleapplicationone) and choose TortoiseGit > Push. The following dialog box will be displayed:
In this case we want to push all branches (master and experimental) to TaraVault, so select the checkbox 'Push all branches'. Then click 'OK' to push the changes:
Once they have been pushed, we are now ready to view the repository within Spira.
"},{"location":"TaraVault-User-Manual/Using-Git/#using-git-with-spiraplan","title":"Using Git with SpiraPlan","text":"Click on the \"Source Code\" or \"Commits\" menu items under the Developing tab to navigate and browse the source code repository.
You can read more about working with source code in SpiraPlan at the links below:
Subversion is a version control system (VCS) -- also known as a revision control system (RCS). That is, Subversion manages files and directories, and the changes made to them, over time. This allows you to recover older versions of your data or examine the history of how your data changed.
Some version control systems are also software configuration management (SCM) systems. These systems are specifically tailored to manage trees of source code and have many features that are specific to software development---such as natively understanding programming languages, or supplying tools for building software. Subversion, however, is not one of these systems. It is a general system that can be used to manage any collection of files, though it is often used for SCM, handling source code files
"},{"location":"TaraVault-User-Manual/Using-Subversion/#repository-layout","title":"Repository Layout","text":"Before we get started with using Subversion, we need to discuss the standard folder layout. For TaraVault to display its branches, folders, files and commits correctly in Spira you need to follow this layout for all your Subversion projects:
These three concepts are explained below:
Trunk is the main folder containing all the data. This is the main line of current development for the project.
A Branch contains copy of the trunk files and directories. These are used to denote older or non-primary versions of the Trunk. You may still commit changes into these branches. For example you may be still fixing bugs on an older version whilst primary development is occurring on the latest version.
Tags can also be referred as milestone. This is a check-point to indicate that your project has reached a certain point. You can use this to mark various releases. Unlike a branch, you cannot commit changes into a tag.
An example setup for such a project could look like:
The same folders and files are typically stored inside each of the Branches, Tags and the Trunk. We shall illustrate this more closely when we get started in the next section.
"},{"location":"TaraVault-User-Manual/Using-Subversion/#getting-started-with-subversion","title":"Getting Started with Subversion","text":"This section assumes that you have already provisioned at least one Subversion project in TaraVault following the steps in Activating TaraVault and Provisioning Projects & Users. So you should now have a TaraVault user/password and a Subversion project with a connection URL:
The next step is to actually connect to this repository using a Subversion client and commit some source code. We recommend using a GUI tool such as TortoiseSVN but you can use any standard Subversion client with TaraVault (command-line or GUI-based) just as well. In our examples we shall be using TortoiseSVN.
The first thing we need to do is perform an initial 'check-out' of our repository into a new working folder (that will initially be empty).
Assuming that you have already installed TortoiseSVN, you would now create a folder to hold all of your Subversion projects (in our example we shall use C:\\Temp\\Subversion) and right-click and choose TortoiseSVN > Check Out:
The following dialog box will appear:
You need to enter the following:
URL of repository -- needs to be the TaraVault connection string listed under 'My Profile' for the current project.
Checkout Directory -- needs to be the local name of the folder for this project. Typically it is best to make it the same as the name of the project in TaraVault (e.g. C:\\Temp\\Subversion\\libraryinformationsystem in this example)
When you click on the 'OK' button, the following authentication dialog box will appear:
Enter your TaraVault username/password, choose 'Save authentication' and then click 'OK'. You will now get a folder C:\\Temp\\Subversion\\libraryinformationsystem that is completely empty apart from a special _svn (or .svn) folder that is used by TortoiseSVN internally.
Now that you have your Subversion working folder downloaded, you should add the following three folders right now:
Trunk
Branches
Tags
Once you have added them to Windows Explorer, select them all and choose TortoiseSVN > Add:
This will display the following:
Once they are added, then choose TortoiseSVN > Commit to commit these folders to the TaraVault repository. That will display the following dialog box:
Typically you should add a message to describe what you did. Then click 'OK' and the three layout folders will now be added to your TaraVault subversion repository.
"},{"location":"TaraVault-User-Manual/Using-Subversion/#adding-files-to-the-trunk","title":"Adding Files to the Trunk","text":"Now that you have your Subversion repository layout setup, we shall simulate working on a real project. You can now copy some code and folders into the Trunk top-level folder for your project. In this example we shall add some sample Inflectra code:
Select all the files and folders and choose TortoiseSVN > Add, then after adding the files and folders, choose TortoiseSVN > Commit to add these files to the repository.
Now, open up one of the files (we shall modify the SampleTestSuite\\AssemblyInfo.cs file in our example) and make a change to it. Then right-click on Trunk and choose TortoiseSVN > Commit to commit the change. Make sure you add a comment:
Click OK and the change (known as a /commit) will now be committed into TaraVault.
"},{"location":"TaraVault-User-Manual/Using-Subversion/#branching-and-tagging","title":"Branching and Tagging","text":"Now that we have the primary development line in our Trunk, we can branch and tag a specific version of the code before we make other changes. For example we might be releasing a version and then making changes specific only to the next version.
We shall create both a branch and a tag from the current Trunk. Firstly, to create a Branch, right-click on Trunk and choose TortoiseSVN > Branch/Tag:
Change the 'To path' from /Trunk to /Branches/v2.0.0.0. You can either branch the latest commit (called the HEAD revision) or a specific commit:
We also recommend adding a 'Log message' to describe the purpose of making the branch. Once you are happy with your choice, click 'OK' to confirm the branch. Once that is done, a copy of the Trunk will now be available under the Branches/v2.0.0.0 folder. To see this, right-click on Branches and choose TortoiseSVN > Update:
Similarly, to make a Tag, right-click on Trunk and choose TortoiseSVN > Branch/Tag, and change the 'To path' from /Trunk to /Tags/v1.0.0.0:
Once that has been completed, right-click on the Tags folder and choose TortoiseSVN > Update:
The main difference between a Branch and a Tag is that you can continue to make changes on a Branch, whereas a Tag is a fixed snapshot of the Trunk and cannot be modified. To illustrate this, let's simulate making a bug fix on the v2.0 branch we made. To do that, change one of the files in the /Branches/v1.0.0.0 folder structure and then right-click TortoiseSVN > Commit:
Click 'OK' and we are now ready to view the repository within Spira.
"},{"location":"TaraVault-User-Manual/Using-Subversion/#using-subversion-with-spiraplan","title":"Using Subversion with SpiraPlan","text":"Click on the \"Source Code\" or \"Commits\" menu items under the Developing tab to navigate and browse the source code repository.
You can read more about working with source code in SpiraPlan at the links below:
UnitJS is an assertion library for JavaScript, running on Node.js or a web browser. It works with various test runner and unit testing frameworks, including Mocha, Karma, Protractor, and QUnit.
SpiraTest currently includes a pre-built extension for the MochaJS test runner and our sample code illustrates it working with UnitJS. However, we supply the source code to the extension, so you can easily adapt it for other runners such as Protractor.
"},{"location":"Unit-Testing-Integration/Integrating-UnitJS-%26-NodeJS/#using-the-spiratest-mochajs-reporter","title":"Using the SpiraTest MochaJS Reporter","text":"Mocha is a feature-rich JavaScript test framework running on Node.js and in the browser, making asynchronous testing simple and fun. Mocha tests run serially, allowing for flexible and accurate reporting, while mapping uncaught exceptions to the correct test cases.
An example UnitJS test running Mocha looks something like:
var test = require('unit.js');\n\ndescribe('Example Test', function(){\n\nit('sample pass', function(){\n\n// just for example of tested value\n\nvar example = 'hello world';\n\ntest\n\n.string(example)\n\n.startsWith('hello')\n\n.match(/\\[a-z\\]/)\n\n.given(example = 'you are welcome')\n\n.string(example)\n\n.endsWith('welcome')\n\n.contains('you')\n\n.when('\"example\" becomes an object', function(){\n\nexample = {\n\nmessage: 'hello world',\n\nname: 'Nico',\n\njob: 'developper',\n\nfrom: 'France'\n\n};\n\n})\n\n.then('test the \"example\" object', function(){\n\ntest\n\n.object(example)\n\n.hasValue('developper')\n\n.hasProperty('name')\n\n.hasProperty('from', 'France')\n\n.contains({message: 'hello world'})\n\n;\n\n})\n\n.if(example = 'bad value')\n\n.error(function(){\n\nexample.badMethod();\n\n})\n\n;\n\n});\n\nit('sample fail', function(){\n\n// just for example of tested value\n\nvar example = 'not hello world';\n\ntest\n\n.string(example)\n\n.startsWith('hello')\n\n.match(/\\[a-z\\]/)\n\n.given(example = 'you are welcome')\n\n.string(example)\n\n.endsWith('welcome')\n\n.contains('you')\n\n.when('\"example\" becomes an object', function(){\n\nexample = {\n\nmessage: 'hello world',\n\nname: 'Nico',\n\njob: 'developper',\n\nfrom: 'France'\n\n};\n\n})\n\n.then('test the \"example\" object', function(){\n\ntest\n\n.object(example)\n\n.hasValue('developper')\n\n.hasProperty('name')\n\n.hasProperty('from', 'France')\n\n.contains({message: 'hello world'})\n\n;\n\n})\n\n.if(example = 'bad value')\n\n.error(function(){\n\nexample.badMethod();\n\n})\n\n;\n\n});\n\n});\nIn this sample, we have one test suite \"Example Test\" that has two tests -- \"sample pass\" and \"sample fail\" inside it. When you run this test using Mocha using the command line:
node ./node_modules/mocha/bin/mocha .\\test\\example2.js
You get the following:
What we want is to have this test suite report back against a matching test case in SpiraTest.
To do that we need to download and unzip the UnitJS-MochaJS-Reporter.zip file from the Inflectra website and extract the contents to the same location as your test framework. The reporter subfolder contains two NodeJS modules:
SpiraReporter.js -- this contains the Mocha custom reporter used for sending the results to SpiraTest
SpiraClient.js -- this contains the JavaScript module that sends a test result back to SpiraTest. It is used by SpiraReporter.js but can also be used directly in your code if you want to report back results without using Mocha.
To use this custom reporter with your Mocha test framework, you simply need to do these two things:
Add the reporter name to the command line used to invoke Mocha
Add some configuration code to your UnitJS test suite to tell Mocha how to connect to your instance of SpiraTest.
The first part is very straightforward, just add the Reporter to your Mocha command line:
node ./node_modules/mocha/bin/mocha .\\test\\example2.js --reporter .\\reporter\\SpiraReporter
For the second part, you need to add the following code to your test suite at the top:
var SpiraReporter = require('../reporter/SpiraReporter.js');\n\n//set the SpiraTest options\n\nglobal.spiraOptions = {\n\nprojectId: 1,\n\ntestCaseId: 4,\n\nreleaseId: 1,\n\ntestSetId: null,\n\nlogin: 'fredbloggs',\n\napiKey: '{7A05FD06-83C3-4436-B37F-51BCF0060483}',\n\nprotocol: 'http',\n\nhost: '127.0.0.1',\n\nvdir: 'spira'\n\n};\nThe second line defines the connection and test case information used for reporting back to SpiraTest. Here's what you need to put in each of the required configuration options:
protocol -- this needs to be set to either \"http\" or \"https\" depending on how you connect to SpiraTest
host -- this needs to be the name or IP address of the host running SpiraTest. For cloud customers, it will be something like mycompany.spiraservice.net
port -- this is usually 80 for http and 443 for https unless you are running SpiraTest on a custom port
vdir -- this is the name of any path used after the hostname. For example, if your URL is https://demo.spiraservice.net/mysite then the vdir would be \"mysite\". If your URL is just https://mycompany.spiraservice.net then you can leave the vdir blank or just not set a value for it.
login -- this should be a login that has access to the project in SpiraTest with permissions to create test runs.
apiKey -- this should be the API Key (also known as the RSS Token) for the login specified
projectId -- this should be the numeric ID of the project that the test case belongs to (e.g. if the project is PR56 just use 56)
testCaseId -- this should be the numeric ID of the test case that you want this Mocha test suite to report against (e.g. if the test case in question is TC23 just use 23)
In addition, there are two optional configuration parameters you can use:
releaseId -- If you would like the recorded test run to be reported against a specific release, iteration or phase in SpiraTest, you need to specify the ID of the release in question (e.g. for release RL18 just use 18)
testSetId - If you would like the recorded test run to be reported against a specific test set in SpiraTest, you need to specify the ID of the test set in question (e.g. for test set TX35 just use 35)
With those values set, when you run the test suite using the command line:
node ./node_modules/mocha/bin/mocha .\\test\\example2.js --reporter .\\reporter\\SpiraReporter
The results of the test suite will be displayed inside the Mocha console:
When you login to SpiraTest and view the test case being executed, you will now see the automated test runs reported back from Mocha:
Clicking on one of the MochaJS Reporter test runs will bring up a screen that provides the detailed test run report from Mocha:
The Console Output section gives more detailed information:
Congratulations... You are now able to run UnitJS automated tests using Mocha and the SpiraTest custom reporter and have the results be recorded within SpiraTest. The sample test suites example.js and example2.js are provided with the installation.
"},{"location":"Unit-Testing-Integration/Integrating-with-Cypress/","title":"Cypress Reporter for Spira","text":"This is a sample cypress project that uploads Cypress test results automatically to Inflectra's SpiraTest, SpiraTeam or SpiraPlan (hereafter just Spira).
It is implemented as a custom reporter that you can easily add to your existing Cypress projects and have the benefit of the test results and screenshots automatically upload against the corresponding Spira test case.
"},{"location":"Unit-Testing-Integration/Integrating-with-Cypress/#installing-the-cypress-reporter","title":"Installing the Cypress Reporter","text":"To install the Spira custom reporter, simply download the Spira-Cypress-Reporter.zip zip file and extract the contents (consisting of the reporter folder) and place in your Cypress project at the same level as the cypress folder. For example:
To use the custom Spira reporter in your Cypress project, you just add it to the Cypress command line:
npx cypress run --browser edge --spec \"cypress\\e2e\\1-getting-started\\todo.cy.js\" --reporter \"reporter\\SpiraReporter\"\nor you modify the cypress.config.js to include the report. We recommend this method since it avoids need to add it to the command-line each time.
However before you can use the reporter, you will need to configure it to point to Spira, and map the Cypress spec files to specified Spira test cases.
"},{"location":"Unit-Testing-Integration/Integrating-with-Cypress/#configuring-the-cypress-reporter","title":"Configuring the Cypress Reporter","text":"Locate the cypress.config.js file from the root of your Cypress project. Open this up in your favorite text/code editor, for example Visual Studio Code. This file contain something similar to the following:
const { defineConfig } = require(\"cypress\");\n\nmodule.exports = defineConfig({\ne2e: {\nsetupNodeEvents(on, config) {\non('task', { log(message) {\nconsole.log(message)\nreturn null\n},\n})\n},\n}\n});\nDepending on how you have Cypress configured, you may have additional settings.
Now we need to modify it to enable the Spira custom reporter and configure its settings:
const { defineConfig } = require(\"cypress\");\n\nmodule.exports = defineConfig({\ne2e: {\nsetupNodeEvents(on, config) {\non('task', { log(message) {\nconsole.log(message)\nreturn null\n},\n})\n},\n},\nreporter: 'reporter/SpiraReporter',\nreporterOptions: {\nprojectId: 1,\nreleaseId: 1,\ntestSetId: null,\nlogin: 'fredbloggs',\napiKey: '{7A05FD06-83C3-4436-B37F-51BCF0060483}',\nprotocol: 'https',\nhost: 'demo-us.spiraservice.net',\nvdir: 'mysite',\nmapping: {\n\"with a checked task\": 4,\n\"with a checked task 2\": 5\n}\n}\n});\nNotice that we have added reporterOptions object that specifies how the Cypress reporter will communicate with Spira:
PR:5 would be just 5)RL:2 would be just 2)TX:3 would be just 3)http or httpsmysite) or just empty if you have a URL that is just the domain (e.g. https://mysite.spiraservice.net)The mapping section is where we map the name of each test suite in a spec file with a corresponding Spira test case. For example, if we have a spec file that has this context section:
context('with a checked task', () => {\nbeforeEach(() => {\ncy.contains('Pay electric bill')\n.parent()\n.find('input[type=checkbox]')\n.check()\n})\nThen the name of the test suite wiuld be with a checked task and then we map that to a test case in SpiraTest, for example TC:5. For our sample tests, we have the following example mapping:
mapping: {\n \"with a checked task\": 4,\n \"with a checked task 2\": 5\n}\nSo we are mapping: - with a checked task to Spira test case TC:4 - with a checked task 2 to Spira test case TC:5
We have now finished our configuration of the reporter, and can run the tests.
"},{"location":"Unit-Testing-Integration/Integrating-with-Cypress/#running-a-cypress-test","title":"Running a Cypress Test","text":"You can execute the tests using the Cypress command-line, launch-pad, CI tool or whatever method you currently use. For example, to execute one of the sample tests in this repository, you can use:
npx cypress run --browser edge --spec \"cypress\\e2e\\1-getting-started\\todo.cy.js\"\nto run the entire folder of tests, you can use:
npx cypress run --browser edge --spec \"cypress\\e2e\\1-getting-started\"\nThe system will then execute the test and let you know that it is reporting back to Spira:
"},{"location":"Unit-Testing-Integration/Integrating-with-Cypress/#viewing-the-results-in-spira","title":"Viewing the Results in Spira","text":"Once the Cypress tests have finished running, you can view the results in Spira:
If you click on one of the runs, you will see the details of that specific execution, including the pass/fail steps and the actions recorded:
In addition, if you choose one of the failed runs, you will see that any screenshots have been automatically uploaded as well:
If you click on the picture link, you can view the uploaded image/screenshot directly in Spira:
Congratulations! You have now run your first Cypress test and reported back the results to Spira!
"},{"location":"Unit-Testing-Integration/Integrating-with-Cypress/#where-can-i-obtain-spira","title":"Where Can I Obtain Spira?","text":"If you would like to learn more about the Inflectra Spira suite, please go to the following website: - SpiraTest, powerful requirements and test management - SpiraTeam, agile planning and test management for teams - SpiraPlan, enterprise planning and testing platform
"},{"location":"Unit-Testing-Integration/Integrating-with-JUnit/","title":"JUnit","text":"The directions for using JUnit 5 and JUnit 4 are in different sections below:
"},{"location":"Unit-Testing-Integration/Integrating-with-JUnit/#installing-the-junit-5-extension","title":"Installing the JUnit 5 Extension","text":"This section outlines how to install the SpiraTest Extension for JUnit 5 onto a workstation so that you can then run automated JUnit tests against a Java application and have the results be recorded as test runs inside SpiraTest. It assumes that you already have a working installation of SpiraTest v5.0 or later. If you have an earlier version of SpiraTest you will need to upgrade to at least v5.0 before trying to use this extension. You will also need to have at least version 5.0 of Junit. If you are using an earlier version, please visit www.junit.org to obtain the latest version.
To obtain the version of the JUnit extension that is compatible with your version of SpiraTest, you simply need to log-in as a project-level administrator to SpiraTest, go to the Administration home page and download the JUnit Extension compressed archive (.zip). This process is described in the SpiraTest Administration Guide in more detail.
The JUnit extension is provided as a compressed zipfile that includes both the binaries (packaged as a JAR-file) and the source code (stored in a folder structure that mirrors the Java classpath). The JAR-file binary was compiled for use on a Windows x86 platform, other platforms (e.g. Linux) will require you to compile the Java source files into the appropriate Java classfiles before using the extension. The rest of this section will assume that you are using the pre-compiled JAR-file.
Once you have downloaded the Zip archive, you need to uncompress it into a folder of your choice on your local system. Assuming that you uncompressed it to the C:\\Program Files\\JUnit Extension folder, you should have the following folder structure created:
C:\\Program Files\\JUnit Extension
C:\\Program Files\\JUnit Extension\\com
C:\\Program Files\\JUnit Extension\\com\\inflectra
C:\\Program Files\\JUnit Extension\\com\\inflectra\\spiratest
C:\\Program Files\\JUnit Extension\\com\\inflectra\\spiratest\\addons
C:\\Program Files\\JUnit Extension\\com\\inflectra\\spiratest\\addons\\junitextension
C:\\Program Files\\JUnit Extension\\com\\inflectra\\spiratest\\addons\\junitextension\\samples
The JAR-file is located in the root folder, the source-code for the extension can be found in the \"junitextension\" subfolder, and the sample test fixture can be found in the \"samples\" subfolder.
Now to use the extension within your test cases, you need to first make sure that the JAR-file is added to the Java classpath. The method for doing this is dependent on the platform you're using, so please refer to FAQ on www.junit.org for details on the appropriate method for your platform. As an example, on a Windows platform, the JAR-file would be added to the classpath by typing the following:
set CLASSPATH=%CLASSPATH%; C:\\\\Program Files\\\\JUnit Extension\\\\JUnitExtension.jar
Once you have completed this step, you are now ready to begin using your JUnit test fixtures with SpiraTest.
"},{"location":"Unit-Testing-Integration/Integrating-with-JUnit/#using-junit-5-with-spiratest","title":"Using JUnit 5 with SpiraTest","text":"The typical code structure for a JUnit test fixture coded in Java is as follows:
package com.inflectra.spiratest.addons.junitextension.samples;\n\nimport org.junit.jupiter.api.BeforeEach;\nimport org.junit.jupiter.api.Test;\nimport static org.junit.jupiter.api.Assertions.assertEquals;\nimport static org.junit.jupiter.api.Assertions.assertTrue;\n\n\n/**\n * Some simple tests using the ability to return results back to SpiraTest\n *\n * @author Inflectra Corporation\n * @version 4.0.0\n */\npublic class SimpleTest {\nprotected int fValue1;\nprotected int fValue2;\n\n/**\n * Sets up the unit test\n */\n@BeforeEach\npublic void setUp() {\nfValue1 = 2;\nfValue2 = 3;\n}\n\n/**\n * Tests the addition of the two values\n */\n@Test\npublic void testAdd() {\ndouble result = fValue1 + fValue2;\n\n// forced failure result == 5\nassertTrue(result == 6);\n}\n\n/**\n * Tests division by zero\n */\n@Test\npublic void testDivideByZero() {\nint zero = 0;\nint result = 8 / zero;\n}\n\n/**\n * Tests two equal values\n */\n@Test\npublic void testEquals() {\nassertEquals(12, 12);\nassertEquals(12L, 12L);\nassertEquals(new Long(12), new Long(12));\n\nassertEquals(12, 13, \"Size\");\nassertEquals(12.0, 11.99, 0.0, \"Capacity\");\n}\n\n/**\n * Tests success\n */\n@Test\npublic void testSuccess() {\n//Successful test\nassertEquals(12, 12);\n}\n}\nThe Java class is marked as a JUnit test fixture by applying the @BeforeEach attribute to the setup method, and the @Test attribute to each of the test assertion methods individually -- highlighted in yellow above. When you open up the class in a JUnit runner or execute from the command line it loads all the test classes and executes all the methods marked with @Test in turn.
Each of the Assert statements is used to test the state of the application after executing some sample code that calls the functionality being tested. If the condition in the assertion is true, then execution of the test continues, if it is false, then a failure is logged and JUnit moves on to the next test method.
So, to use SpiraTest with JUnit, each of the test cases written for execution by JUnit needs to have a corresponding test case in SpiraTest. These can be either existing test cases that have manual test steps or they can be new test cases designed specifically for automated testing and therefore have no defined test steps. In either case, the changes that need to be made to the JUnit test fixture for SpiraTest to record the JUnit test run are illustrated below:
package com.inflectra.spiratest.addons.junitextension.samples;\n\nimport com.inflectra.spiratest.addons.junitextension.*;\n\nimport org.junit.jupiter.api.BeforeEach;\nimport org.junit.jupiter.api.Test;\nimport static org.junit.jupiter.api.Assertions.assertEquals;\nimport static org.junit.jupiter.api.Assertions.assertTrue;\n\n\n/**\n * Some simple tests using the ability to return results back to SpiraTest\n *\n * @author Inflectra Corporation\n * @version 5.0.0\n */\n@SpiraTestConfiguration(\n//following are REQUIRED\nurl = \"https://demo-us.spiraservice.net/mysite\",\nlogin = \"fredbloggs\",\nrssToken = \"{XXXXXXXXXXXXXXXX}\", // make sure to use your API/RSS key and not your login password\nprojectId = 1,\n//following are OPTIONAL\nreleaseId = 7,\ntestSetId = 1\n)\n\npublic class SimpleTest {\nprotected int fValue1;\nprotected int fValue2;\n\n/**\n * Sets up the unit test\n */\n@BeforeEach\npublic void setUp() {\nfValue1 = 2;\nfValue2 = 3;\n}\n\n/**\n * Tests the addition of the two values\n */\n@Test\n@SpiraTestCase(testCaseId = 2)\npublic void testAdd() {\ndouble result = fValue1 + fValue2;\n\n// forced failure result == 5\nassertTrue(result == 6);\n}\n\n/**\n * Tests division by zero\n */\n@Test\n@SpiraTestCase(testCaseId = 3)\npublic void testDivideByZero() {\nint zero = 0;\nint result = 8 / zero;\n}\n\n/**\n * Tests two equal values\n */\n@Test\n@SpiraTestCase(testCaseId = 4)\npublic void testEquals() {\nassertEquals(12, 12);\nassertEquals(12L, 12L);\nassertEquals(new Long(12), new Long(12));\n\nassertEquals(12, 13, \"Size\");\nassertEquals(12.0, 11.99, 0.0, \"Capacity\");\n}\n\n/**\n * Tests success\n */\n@Test\n@SpiraTestCase(testCaseId = 5)\npublic void testSuccess() {\n//Successful test\nassertEquals(12, 12);\n}\n}\nThe overall class is marked with a new @SpiraTestConfiguration attribute that contains the following pieces of information needed to access the SpiraTest test repository:
URL - The URL to the instance of SpiraTest being accessed. This needs to start with http:// or https://.
Login - A valid username for the instance of SpiraTest.
In addition, each of the individual test methods needs to be mapped to a specific test case within SpiraTest. This is done by adding a @SpiraTestCase attribute to the test method together with the ID of the corresponding test case in SpiraTest. The Test Case ID can be found on the test cases list page (click the \"Test Cases\" tab).
-- The test methods must be marked as public or the test results will not appear in Spira --
For these attributes to be available in your test fixture, you also need to add a reference to the com.inflectra.spiratest.addons.junitextension package. This package is bundled within the supplied JAR-file library for Windows, and can be compiled from the provided source .java files on other platforms.
Now all you need to do is compile your code and then launch JUnit by executing the test fixture through the command line, or through your choice of IDE, e.g. Eclipse, IntelliJ). We shall show one example of each:
"},{"location":"Unit-Testing-Integration/Integrating-with-JUnit/#a-executing-junit-5-tests-using-command-line","title":"a) Executing JUnit 5 Tests using Command Line","text":"To execute JUnit 5 tests using the command line, you need to download the junit-platform-console-standalone.jar JUnit 5 package from Maven and use that to run the tests.
For our sample test, you would use the following command to launch the JUnit tests:
java -jar \"C:\\AutomatedTesting\\JUnitExtension\\junit-platform-console-standalone-1.8.0-M1.jar\"--classpath=\"C:\\AutomatedTesting\\JUnitExtension\\JUnit 5\\bin\" -classpath=\"C:\\AutomatedTesting\\JUnitExtension\\Jars\\JUnit_5_Extension_jar\\JUnit 5 Extension.jar\" --select-class=com.inflectra.spiratest.addons.junitextension.samples.SimpleTest
This includes both the SpiraTest extension JAR and the sample tests being executed on the classpath and the class name of the sample tests in the select argument.
When executed it will report back to the command line:
and the results will also appear in SpiraTest.
"},{"location":"Unit-Testing-Integration/Integrating-with-JUnit/#b-executing-junit-5-tests-using-eclipse","title":"b) Executing JUnit 5 Tests using Eclipse","text":"To execute the tests in Eclipse, simply open your automated test script in an Eclipse project, ensure you have the JUnit Eclipse plugin installed, and finally make sure you add a reference to the SpiraTest JUnit 5 Extension.jar JAR file:
Then when you choose the option to Run As a JUnit 5 it will execute the tests:
If for any reason you don't see the test results appear in SpiraTest, make sure you have the correct test IDs mapped. If you still don't see the results, check the Console tab inside Eclipse for any errors connecting to SpiraTest:
"},{"location":"Unit-Testing-Integration/Integrating-with-JUnit/#viewing-the-test-results-in-spiratest","title":"Viewing the Test Results in SpiraTest","text":"Once the test has run using one of the previous methods, you can view the test cases in SpiraTest, you should see a JUnit automated test run displayed in the list of executed test runs:
Clicking on one of the JUnit test runs will bring up a screen that provides information regarding what JUnit test method failed, what the error was, together with the associated code stack-trace:
Congratulations... You are now able to run JUnit 5 automated tests and have the results be recorded within SpiraTest. The sample test fixture SimpleText.java is provided with the installation.
"},{"location":"Unit-Testing-Integration/Integrating-with-JUnit/#installing-the-junit-4-extension","title":"Installing the JUnit 4 Extension","text":"This section outlines how to install the SpiraTest Extension for JUnit onto a workstation so that you can then run automated JUnit tests against a Java application and have the results be recorded as test runs inside SpiraTest. It assumes that you already have a working installation of SpiraTest v3.0 or later. If you have an earlier version of SpiraTest you will need to upgrade to at least v3.0 before trying to use this extension. You will also need to have version 4.0 of JUnit. To use version 5.0 of JUnit, please visit Installing the JUnit 5 Extension
To obtain the version of the JUnit extension that is compatible with your version of SpiraTest, you simply need to log-in as a project-level administrator to SpiraTest, go to the Administration home page and download the JUnit Extension compressed archive (.zip). This process is described in the SpiraTest Administration Guide in more detail.
The JUnit extension is provided as a compressed zipfile that includes both the binaries (packaged as a JAR-file) and the source code (stored in a folder structure that mirrors the Java classpath). The JAR-file binary was compiled for use on a Windows x86 platform, other platforms (e.g. Linux) will require you to compile the Java source files into the appropriate Java classfiles before using the extension. The rest of this section will assume that you are using the pre-compiled JAR-file.
Once you have downloaded the Zip archive, you need to uncompress it into a folder of your choice on your local system. Assuming that you uncompressed it to the C:\\Program Files\\JUnit Extension folder, you should have the following folder structure created:
C:\\Program Files\\JUnit Extension
C:\\Program Files\\JUnit Extension\\com
C:\\Program Files\\JUnit Extension\\com\\inflectra
C:\\Program Files\\JUnit Extension\\com\\inflectra\\spiratest
C:\\Program Files\\JUnit Extension\\com\\inflectra\\spiratest\\addons
C:\\Program Files\\JUnit Extension\\com\\inflectra\\spiratest\\addons\\junitextension
C:\\Program Files\\JUnit Extension\\com\\inflectra\\spiratest\\addons\\junitextension\\samples
The JAR-file is located in the root folder, the source-code for the extension can be found in the \"junitextension\" subfolder, and the sample test fixture can be found in the \"samples\" subfolder.
Now to use the extension within your test cases, you need to first make sure that the JAR-file is added to the Java classpath. The method for doing this is dependent on the platform you're using, so please refer to FAQ on www.junit.org for details on the appropriate method for your platform. As an example, on a Windows platform, the JAR-file would be added to the classpath by typing the following:
set CLASSPATH=%CLASSPATH%; C:\\Program Files\\JUnit Extension\\JUnitExtension.jar
Once you have completed this step, you are now ready to begin using your JUnit test fixtures with SpiraTest.
"},{"location":"Unit-Testing-Integration/Integrating-with-JUnit/#using-junit-4-with-spiratest","title":"Using JUnit 4 with SpiraTest","text":"The typical code structure for a JUnit test fixture coded in Java is as follows:
package com.inflectra.spiratest.addons.junitextension.samples;\n\nimport static org.junit.Assert.*;\nimport junit.framework.JUnit4TestAdapter;\nimport org.junit.Before;\nimport org.junit.Test;\nimport org.junit.runner.*;\nimport org.junit.runner.notification.*;\n\nimport java.util.*;\n\n/**\n * Some simple tests using JUnit 4\n * \n * @author Inflectra Corporation\n * @version 2.3.0\n *\n */\npublic class SimpleTest\n{\nprotected int fValue1;\nprotected int fValue2;\n\n/**\n * Sets up the unit test\n */\n@Before\npublic void setUp()\n{\nfValue1= 2;\nfValue2= 3;\n}\n\n/**\n * Tests the addition of the two values\n */\n@Test\npublic void testAdd()\n{\ndouble result = fValue1 + fValue2;\n\n// forced failure result == 5\nassertTrue (result == 6);\n}\n\n/**\n * Tests division by zero\n */\n@Test\npublic void testDivideByZero()\n{\nint zero = 0;\nint result = 8 / zero;\nresult++; // avoid warning for not using result\n}\n\n/**\n * Tests two equal values\n */\n@Test\n\npublic void testEquals()\n{\nassertEquals(12, 12);\nassertEquals(12L, 12L);\nassertEquals(new Long(12), new Long(12));\n\nassertEquals(\"Size\", 12, 13);\nassertEquals(\"Capacity\", 12.0, 11.99, 0.0);\n}\n\n/**\n * Tests success\n */\n@Test\npublic void testSuccess()\n{\n//Successful test\nassertEquals(12, 12);\n}\n\n/**\n * Entry point for command line execution\n * \n * @param args The command line arguments\n */\npublic static void main (String[] args)\n{\n//Instantiate the JUnit core\nJUnitCore core = new JUnitCore();\n\n//Finally run the test fixture\ncore.run (SimpleTest.class);\n}\n\n/**\n * Entry point for JUnit 4.x runners\n * \n * @return Handle to the test framework\n */\npublic static junit.framework.Test suite() {\nreturn new JUnit4TestAdapter(SimpleTest.class);\n}\n}\nThe Java class is marked as a JUnit test fixture by applying the @Before attribute to the setup method, and the @Test attribute to each of the test assertion methods individually -- highlighted in yellow above. When you open up the class in a JUnit runner or execute from the command line it loads all the test classes and executes all the methods marked with @Test in turn.
Each of the Assert statements is used to test the state of the application after executing some sample code that calls the functionality being tested. If the condition in the assertion is true, then execution of the test continues, if it is false, then a failure is logged and JUnit moves on to the next test method.
So, to use SpiraTest with JUnit, each of the test cases written for execution by JUnit needs to have a corresponding test case in SpiraTest. These can be either existing test cases that have manual test steps or they can be new test cases designed specifically for automated testing and therefore have no defined test steps. In either case, the changes that need to be made to the JUnit test fixture for SpiraTest to record the JUnit test run are illustrated below:
package com.inflectra.spiratest.addons.junitextension.samples;\n\nimport static org.junit.Assert.*;\nimport junit.framework.JUnit4TestAdapter;\nimport org.junit.Before;\nimport org.junit.Test;\nimport org.junit.runner.*;\nimport org.junit.runner.notification.*;\n\nimport com.inflectra.spiratest.addons.junitextension.*;\n\nimport java.util.*;\n\n/**\n * Some simple tests using the ability to return results back to SpiraTest\n * \n * @author Inflectra Corporation\n * @version 2.3.0\n *\n */\n@SpiraTestConfiguration(\nurl=\"http://sandman/SpiraTest\",\nlogin=\"fredbloggs\",\npassword=\"fredbloggs\",\nprojectId=1,\nreleaseId=1,\ntestSetId=1\n)\npublic class SimpleTest\n{\nprotected int fValue1;\nprotected int fValue2;\n\n/**\n * Sets up the unit test\n */\n@Before\npublic void setUp()\n{\nfValue1= 2;\nfValue2= 3;\n}\n\n/**\n * Tests the addition of the two values\n */\n@Test\n@SpiraTestCase(testCaseId=5)\npublic void testAdd()\n{\ndouble result = fValue1 + fValue2;\n\n// forced failure result == 5\nassertTrue (result == 6);\n}\n\n/**\n * Tests division by zero\n */\n@Test\n@SpiraTestCase(testCaseId=5)\npublic void testDivideByZero()\n{\nint zero = 0;\nint result = 8 / zero;\nresult++; // avoid warning for not using result\n}\n\n/**\n * Tests two equal values\n */\n@Test\n@SpiraTestCase(testCaseId=6)\npublic void testEquals()\n{\nassertEquals(12, 12);\nassertEquals(12L, 12L);\nassertEquals(new Long(12), new Long(12));\n\nassertEquals(\"Size\", 12, 13);\nassertEquals(\"Capacity\", 12.0, 11.99, 0.0);\n}\n\n/**\n * Tests success\n */\n@Test\n@SpiraTestCase(testCaseId=6)\npublic void testSuccess()\n{\n//Successful test\nassertEquals(12, 12);\n}\n\n/**\n * Entry point for command line execution\n * \n * @param args The command line arguments\n */\npublic static void main (String[] args)\n{\n//Instantiate the JUnit core\nJUnitCore core = new JUnitCore();\n\n//Add the custom SpiraTest listener\ncore.addListener(new SpiraTestListener());\n\n//Finally run the test fixture\ncore.run (SimpleTest.class);\n}\n\n/**\n * Entry point for JUnit 4.x runners\n * \n * @return Handle to the test framework\n */\npublic static junit.framework.Test suite() {\nreturn new JUnit4TestAdapter(SimpleTest.class);\n}\n}\nThe overall class is marked with a new @SpiraTestConfiguration attribute that contains the following pieces of information needed to access the SpiraTest test repository:
URL - The URL to the instance of SpiraTest being accessed. This needs to start with http:// or https://.
Login - A valid username for the instance of SpiraTest.
Password - A valid password for the instance of SpiraTest.
Project Id - The ID of the project (this can be found on the project homepage in the \"Project Overview\" section)
Release Id (Optional) - The ID of the release to associate the test run with. This can be found on the releases list page (click on the Planning > Releases tab). If you don't want to specify a release, just use the value -1.
Test Set Id (Optional) -- The ID of the test set to associate the test run with. This can be found on the test set list page (click on the Testing > Test Sets tab). If you don't want to specify a test set, just use the value -1. If you choose a test set that is associated with a release, then you don't need to explicitly set a release id (i.e. just use -1). However if you do set a release value, it will override the value associated with the test set.
In addition, each of the individual test methods needs to be mapped to a specific test case within SpiraTest. This is done by adding a @SpiraTestCase attribute to the test method together with the ID of the corresponding test case in SpiraTest. The Test Case ID can be found on the test cases list page (click the \"Test Cases\" tab).
For these attributes to be available in your test fixture, you also need to add a reference to the com.inflectra.spiratest.addons.junitextension package. This package is bundled within the supplied JAR-file library for Windows, and can be compiled from the provided source .java files on other platforms.
Now all you need to do is compile your code and then launch JUnit by executing the test fixture through the command line (or through your choice of IDE, e.g. Eclipse). E.g. for our sample test, you would use the following command:
java com.inflectra.spiratest.addons.junitextension.samples.SimpleTest
Once the test has run, you can view the test cases in SpiraTest, you should see a JUnit automated test run displayed in the list of executed test runs:
Clicking on one of the JUnit test runs will bring up a screen that provides information regarding what JUnit test method failed, what the error was, together with the associated code stack-trace:
Congratulations... You are now able to run JUnit automated tests and have the results be recorded within SpiraTest. The sample test fixture SimpleText.java is provided with the installation.
"},{"location":"Unit-Testing-Integration/Integrating-with-Jasmine/","title":"Integrating with Jasmine","text":"Jasmine is a behavior-driven development framework for testing JavaScript code. It does not depend on any other JavaScript frameworks. It does not require a DOM. And it has a clean, obvious syntax so that you can easily write tests.
Some key features of Jasmine are:
The Spira Reporter for Jasmine will integrate JasmineJS with Spira. It will create a test run in Spira for each test spec executed in Jasmine.
"},{"location":"Unit-Testing-Integration/Integrating-with-Jasmine/#setting-up-the-integration","title":"Setting up the integration","text":"Install the integration by running npm i jasmine-spiratest in the root directory of your tests. Inside each test spec file, import the SpiraReporter with var SpiraReporter = require('jasmine-spiratest') then put the line jasmine.getEnv().addReporter(new SpiraReporter(spiraCredentials)); where spiraCredentials is an object of the format below. You can see a full sample test spec at the bottom of this page.
{\n \"url\": \"https://doctor/SpiraPlan\",\n \"username\": \"fredbloggs\",\n \"token\": \"{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}\",\n \"projectId\": 1,\n \"releaseId\": 1,\n \"testSetId\": 1,\n \"testCases\": {\n \"default\": 20,\n \"should multiply correctly\": 21,\n \"should solve exponents and logarithms correctly\": 16\n }\n}\nFields are required unless otherwise noted.
Field Description url The root URL of your SpiraTest instance without a '/' at the end username The username you use to sign into SpiraTest token Your RSS Token. Found in your profile page as the RSS Token field. You must have RSS Feeds enabled for this to work projectId The ID of the product you would like the Test Runs to be filed under releaseId OPTIONAL - Use if you would like to associate created test runs with a release testSetId OPTIONAL - Use if you would like to associated created test runs with a test set testCases Must contain the default field within it and, optionally, specific test cases for a given test spec name default Inside the testCases field, this is the ID of the default test case mapped to a created test run OPTIONAL - Use as many times as you would like to map a the created test run for a spec to a particular test case in SpiraTest. Note that capitalization, special characters and spaces are ignored both in testCases and the spec itself Once you have added the SpiraReporter to the jasmine environment in each file as described above, you are all set!"},{"location":"Unit-Testing-Integration/Integrating-with-Jasmine/#using-the-spiratest-reporter","title":"Using the SpiraTest Reporter","text":"Run npm test or however you ran jasmine before and you should see test runs created in the product you specified.
describe(\"Test having two specs\", () => {\n var SpiraReporter = require('jasmine-spiratest');\n\n jasmine.getEnv().addReporter(new SpiraReporter({\n \"url\": \"https://doctor/SpiraPlan\",\n \"username\": \"fredbloggs\",\n \"token\": \"{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}\",\n \"projectId\": 1,\n \"releaseId\": 1,\n \"testSetId\": 1,\n \"testCases\": {\n \"default\": 20,\n \"equality works\": 21,\n \"addition works\": 16\n }\n }));\n\n describe(\"Test basic JavaScript\", () => {\n it(\"Equality works...\", () => {\n expect(2).toEqual(2);\n });\n it(\"Addition works\", () => {\n expect(3 + 2).toEqual(5);\n });\n it(\"Multiplication works\", () => {\n expect(4 * 5).toEqual(20);\n });\n });\n});\nThis reporter will integrate JestJS with Inflectra's ALM suite. It will create a test run in Spira for each test executed in Jest.
"},{"location":"Unit-Testing-Integration/Integrating-with-Jest/#guide-basics","title":"Guide Basics","text":"Unfortunately, this integration will work with SpiraTest/SpiraTeam/SpiraPlan (hereafter refered to as SpiraTest) version 5.0 and above and at least Jest 24.x. If you have an older version, you will need to update to use this reporter.
This guide assumes a basic familiarity with both SpiraTest and the Jest testing framework.
"},{"location":"Unit-Testing-Integration/Integrating-with-Jest/#setting-up-the-integration","title":"Setting up the integration","text":"Install the integration by running npm i jest-spiratest in the root directory of your tests. Inside your package.json file, add the jest field with the format as shown below. You can see a full sample package.json at the bottom of this README.
\"reporters\": [\n\"default\",\n[\n\"jest-spiratest\",\n{\n\"url\": \"https://doctor/SpiraPlan\",\n\"username\": \"fredbloggs\",\n\"token\": \"{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}\",\n\"projectId\": 1,\n\"releaseId\": 1,\n\"testSetId\": 1,\n\"testCases\": {\n\"default\": 20,\n\"storesCorrectly\": 21,\n\"javascriptWorks\": 16\n}\n}\n]\n]\nField | Description --- | --- | url | The root URL of your SpiraTest instance without a '/' at the end username | The username you use to sign into SpiraTest token | Your RSS Token. Foundin your profile page as the RSS Token field. You must have RSS Feeds enabled for this to work projectId | The ID of the project you would like the Test Runs to be filed under releaseId | OPTIONAL - Use if you would like to associate created test runs with a release testSetId | OPTIONAL - Use if you would like to associated created test runs with a test set testCases | Must contain the default field within it and, optionally, specific test cases for a given test spec name default | Inside the testCases field, this is the ID of the default test case mapped to a created test run <test_name> | OPTIONAL - Use as many times as you would like to map a the created test run to a particular test case in SpiraTest. Note that capitalization, special characters and spaces are ignored both in testCases and the test declaration
Once you have added the SpiraReporter to jest as described above, you are all set!
"},{"location":"Unit-Testing-Integration/Integrating-with-Jest/#using-the-spiratest-reporter","title":"Using the SpiraTest Reporter","text":"Actually, you don't do anything different! Just run npm test or however you ran jest before and you should see test runs created in the project you specified!
package.json with SpiraTest Integration","text":"{\n\"name\": \"sample\",\n\"scripts\": {\n\"test\": \"jest\"\n},\n\"jest\": {\n\"reporters\": [\n\"default\",\n[\n\"jest-spiratest\",\n{\n\"url\": \"https://doctor/SpiraPlan\",\n\"username\": \"fredbloggs\",\n\"token\": \"{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}\",\n\"projectId\": 1,\n\"releaseId\": 1,\n\"testSetId\": 1,\n\"testCases\": {\n\"default\": 20,\n\"storesCorrectly\": 21,\n\"javascriptWorks\": 16\n}\n}\n]\n]\n}\n}\nThis section describes how to use SpiraTest in conjunction with the unit testing features provided by Microsoft Visual Studio Team System (MS VSTS) Test -- commonly known as MS-Test.
"},{"location":"Unit-Testing-Integration/Integrating-with-MS-Test/#installing-the-ms-test-extension","title":"Installing the MS-Test Extension","text":"This section outlines how to install the SpiraTest extension for Microsoft Visual Studio Team System Test (MS-Test) onto a workstation so that you can then run automated MS-Test tests against a .NET application and have the results be recorded as test runs inside SpiraTest. It assumes that you already have a working installation of SpiraTest v2.3 or later. If you have an earlier version of SpiraTest you will need to upgrade to at least v2.3 before trying to use this add-in. You will also need to have either Visual Studio Team System 2005 or later or Visual Studio 2008 Professional or later, since earlier versions do not come with the test automation features.
To obtain the latest version of the SpiraTest extension, you can either access the administration section of SpiraTest, and click on the Add-Ins & Downloads link or simply visit the Inflectra corporate downloads webpage (http://www.inflectra.com/Products/Downloads.aspx) and then download the compressed archive (.zip) that contains the extension and associated sample files.
The MS-Test extension is provided as a compressed zipfile that includes both the binaries (packaged as a .NET dll assembly) and the source code (stored in a Visual Studio project folder structure). The rest of this section will assume that you are using the pre-compiled assembly.
Once you have downloaded the Zip archive, you need to uncompress it into a folder of your choice on your local system. Assuming that you uncompressed it to the C:\\Program Files\\SpiraTest\\MSTest Extension folder, you should have the following folder structure created:
C:\\Program Files\\SpiraTest\\MSTest Extension
C:\\Program Files\\SpiraTest\\MSTest Extension\\SampleMSTest
C:\\Program Files\\SpiraTest\\MSTest Extension\\SampleMSTest\\Properties
C:\\Program Files\\SpiraTest\\MSTest Extension\\SpiraTestMSExtension
C:\\Program Files\\SpiraTest\\MSTest Extension\\SpiraTestMSExtension\\Properties
C:\\Program Files\\SpiraTest\\MSTest Extension\\SpiraTestMSExtension\\Web References
The pre-built assembly SpiraTestMSTestExtension.dll is located in the root folder, the source-code for the extension can be found in the \"SpiraTestMSExtension\" subfolder, and the sample test fixture can be found in the \"SampleMSTest\" subfolder.
Now to use the extension within your test cases, you need to first make sure that the SpiraTestMSTestExtension.dll assembly is added to the project references. Once you have completed this step, you are now ready to begin using your MS-Test test fixtures with SpiraTest.
"},{"location":"Unit-Testing-Integration/Integrating-with-MS-Test/#using-ms-test-with-spiratest","title":"Using MS-Test with SpiraTest","text":"The typical code structure for a Visual Studio Team System Test (MS-Test) test fixture coded in C# is as follows:
using System;\nusing System.Threading;\nusing Microsoft.VisualStudio.TestTools.UnitTesting;\n\nnamespace Inflectra.SpiraTest.AddOns.SpiraTestMSTestExtension.SampleMSTest\n{\n/// <summary>\n/// Sample test fixture that tests the SpiraTest integration\n/// Written by Paul Tissue. Packed by Inflectra Corporation\n/// </summary>\n[\n TestClass\n ]\npublic class SpiraTestCaseAttributeTest\n{\n/// <summary>\n/// Test fixture state\n/// </summary>\nprotected static int testFixtureState = 1;\n\n/// <summary>\n/// Constructor method\n/// </summary>\npublic SpiraTestCaseAttributeTest()\n{\n//Delegates to base\n\n//Set the state to 2\ntestFixtureState = 2;\n}\n\n/// <summary>\n/// Sample test that asserts a failure and overrides the default configuration\n/// </summary>\n[\n TestMethod\n ]\npublic void SampleFail()\n{\n//Verify the state\nAssert.AreEqual(2, testFixtureState, \"*Real Error*: State not persisted\");\n\n//Failure Assertion\nAssert.AreEqual(1, 0, \"Failed as Expected\");\n}\n\n/// <summary>\n/// Sample test that succeeds - uses the default configuration\n/// </summary>\n[\n TestMethod\n ]\npublic void SamplePass()\n{\n//Verify the state\nAssert.AreEqual(2, testFixtureState, \"*Real Error*: State not persisted\");\n\n//Successful assertion\nAssert.AreEqual(1, 1, \"Passed as Expected\");\n}\n\n/// <summary>\n/// Sample test that does not log to SpiraTest\n/// </summary>\n[\n TestMethod,\n ExpectedException(typeof(AssertFailedException))\n ]\npublic void SampleIgnore()\n{\n//Verify the state\nAssert.AreEqual(2, testFixtureState, \"*Real Error*: State not persisted\");\n\n//Failure Assertion\nAssert.AreEqual(1, 0, \"Failed as Expected\");\n}\n}\n}\nThe .NET class is marked as a MS-Test unit test fixture by applying the [TestClass] attribute to the class as a whole, and the [TestMethod] attribute to each of the test assertion methods individually -- shown above. When you open up the class in Visual Studio and click Tests > Run > Run All Tests in Solution it loads all the test classes marked with [TestClass] and executes all the methods marked with [TestMethod] in turn.
Each of the Assert statements is used to test the state of the application after executing some sample code that calls the functionality being tested. If the condition in the assertion is true, then execution of the test continues, if it is false, then a failure is logged and MS-Test moves on to the next test method.
So, to use SpiraTest with MS-Test, each of the test cases written for execution by MS-Test needs to have a corresponding test case in SpiraTest. These can be either existing test cases that have manual test steps or they can be new test cases designed specifically for automated testing and therefore have no defined test steps. In either case, the changes that need to be made to the MS-Test test fixture for SpiraTest to record the MS-Test test run are illustrated below:
using System;\nusing System.Threading;\nusing Microsoft.VisualStudio.TestTools.UnitTesting;\n\nnamespace Inflectra.SpiraTest.AddOns.SpiraTestMSTestExtension.SampleMSTest\n{\n/// <summary>\n/// Sample test fixture that tests the SpiraTest integration\n/// Written by Paul Tissue. Packed by Inflectra Corporation\n/// </summary>\n[\n TestClass\n ]\npublic class SpiraTestCaseAttributeTest : MSTestExtensionsTestFixture\n{\n/// <summary>\n/// Test fixture state\n/// </summary>\nprotected static int testFixtureState = 1;\n\n/// <summary>\n/// Constructor method\n/// </summary>\npublic SpiraTestCaseAttributeTest()\n{\n//Delegates to base\n\n//Set the state to 2\ntestFixtureState = 2;\n}\n\n/// <summary>\n/// Sample test that asserts a failure and overrides the default configuration\n/// </summary>\n[\n TestMethod,\n SpiraTestCase(5),\n SpiraTestConfiguration(\"http://localhost/SpiraTest\", \"fredbloggs\", \"fredbloggs\", 1, 1, 2)\n ]\npublic void SampleFail()\n{\n//Verify the state\nAssert.AreEqual(2, testFixtureState, \"*Real Error*: State not persisted\");\n\n//Failure Assertion\nAssert.AreEqual(1, 0, \"Failed as Expected\");\n}\n\n/// <summary>\n/// Sample test that succeeds - uses the default configuration\n/// </summary>\n[\n TestMethod,\n SpiraTestCase(6)\n ]\npublic void SamplePass()\n{\n//Verify the state\nAssert.AreEqual(2, testFixtureState, \"*Real Error*: State not persisted\");\n\n//Successful assertion\nAssert.AreEqual(1, 1, \"Passed as Expected\");\n}\n\n/// <summary>\n/// Sample test that does not log to SpiraTest\n/// </summary>\n[\n TestMethod,\n ExpectedException(typeof(AssertFailedException))\n ]\npublic void SampleIgnore()\n{\n//Verify the state\nAssert.AreEqual(2, testFixtureState, \"*Real Error*: State not persisted\");\n\n//Failure Assertion\nAssert.AreEqual(1, 0, \"Failed as Expected\");\n}\n}\n}\nAnd the following settings need to be added to the .config file associated with the test fixture assembly:
<?xml version=\"1.0\"?>\n<configuration>\n<configSections>\n<sectionGroup name=\"applicationSettings\" type=\"System.Configuration.ApplicationSettingsGroup, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089\" >\n<section name=\"Inflectra.SpiraTest.AddOns.SpiraTestMSTestExtension.Properties.Settings\" type=\"System.Configuration.ClientSettingsSection, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089\" requirePermission=\"false\" />\n</sectionGroup>\n</configSections>\n<applicationSettings>\n<Inflectra.SpiraTest.AddOns.SpiraTestMSTestExtension.Properties.Settings>\n<setting name=\"Url\" serializeAs=\"String\">\n<value>http://localhost/SpiraTest</value>\n</setting>\n<setting name=\"Login\" serializeAs=\"String\">\n<value>fredbloggs</value>\n</setting>\n<setting name=\"Password\" serializeAs=\"String\">\n<value>fredbloggs</value>\n</setting>\n<setting name=\"ProjectId\" serializeAs=\"String\">\n<value>1</value>\n</setting>\n<setting name=\"ReleaseId\" serializeAs=\"String\">\n<value>1</value>\n</setting>\n<setting name=\"TestSetId\" serializeAs=\"String\">\n<value>1</value>\n</setting>\n<setting name=\"RecordTestRun\" serializeAs=\"String\">\n<value>True</value>\n</setting>\n</Inflectra.SpiraTest.AddOns.SpiraTestMSTestExtension.Properties.Settings>\n</applicationSettings>\nFirstly the settings in the .config file indicate the following information to the test fixture:
The URL to the instance of SpiraTest being accessed. This needs to start with http:// or https://.
A valid username and password for the instance of SpiraTest.
The ID of the project (this can be found on the project homepage in the \"Project Overview\" section)
(Optional) The ID of the release to associate the test-run with. This can be found on the releases list page (click on the Planning > Releases tab)
(Optional) The ID of the test set to associate the test-run with. This can be found on the test set list page (click on the Testing > Test Sets tab)
A flag that tells MS-Test whether or not to record the results in SpiraTest.
Next, the test fixture class needs to be derived from the MSTestExtensionsTestFixture base class so that the test runner knows that the test class will be reporting back to SpiraTest.
In addition, each of the individual test methods needs to be mapped to a specific test case within SpiraTest. This is done by adding a [SpiraTestCase] attribute to the test method together with the ID of the corresponding test case in SpiraTest. The Test Case ID can be found on the test cases list page (click the \"Test Cases\" tab).
In addition you can also override the default SpiraTest configuration settings from the .config file by adding the [SpiraTestConfiguration] attribute directly to the test method and specifying the SpiraTest URL, authentication information, project id, release id (optional) and test set id (optional). An example of this is shown above for the SampleFail() method.
Now all you need to do is compile your code, launch Visual Studio, run the test fixtures as you would normally do, and when you view the test cases in SpiraTest, you should see a MSTest automated test run displayed in the list of executed test runs:
Clicking on one of the MSTest test runs will bring up a screen that provides information regarding what MSTest test method failed, what the error was, together with the associated code stack-trace:
Congratulations. You are now able to run MSTest automated tests and have the results be recorded within SpiraTest. The sample test project SampleMSTest is provided with the installation.
"},{"location":"Unit-Testing-Integration/Integrating-with-NUnit/","title":"Integrating with NUnit","text":""},{"location":"Unit-Testing-Integration/Integrating-with-NUnit/#nunit-3","title":"NUnit 3","text":"SpiraTest/SpiraTeam/SpiraPlan (hereon called SpiraPlan) integrates seamlessly with NUnit 3, using our dedicated NUnit add-in. The add-in lets you run unit tests against a .NET application and get the results recorded in SpiraPlan as a test run against a specific test case. The add-in is designed to let you run your suite of unit tests against the application as part of your CI/CD pipeline. The add-in does not - and does not need to - integrate with your CI/CD engine.
To use the add-in you must have:
Please follow the steps below to download and install the add-in:
Once copied, open the NUnit addins file:
addins\\SpiraTestNUnitAddIn.dllSpiraTestNUnitAddIn.dllUsing NUnit and the console runner from NuGet
If integrating via NuGet, find the location of the the version of the NUnit Console Runner referenced by the PATH variable in your windows environment variables.
When installing the console runner via NuGet, this PATH variable will not be set for you. We recommended you do this manually. You should set this new PATH variable to a filepath which ends at the folder containing the nunit3-console.exe you wish to execute.
If you've followed all the steps correctly, the SpiraPlan NUnit add-in should now be properly installed. For reference your nunit.bundle.addins file may look something like this:
addins/nunit.v2.driver.dll\naddins/nunit-v2-result-writer.dll\naddins/nunit-project-loader.dll\naddins/vs-project-loader.dll\naddins/teamcity-event-listener.dll\naddins/SpiraTestNUnitAddIn.dll\nFor this example, we will be using the following sample test fixture:
using NUnit.Framework;\n\nnamespace SampleTestSuite\n{\n[TestFixture]\nclass SampleTest\n{\nint One, Two;\n[SetUp]\nprotected void SetUp()\n{\nOne = 1;\nTwo = 2;\n}\n[Test]\npublic void TestAdd()\n{\nint Result = One + Two;\n//will succeed\nAssert.AreEqual(Result, 3);\n}\n[Test]\npublic void TestMultiply()\n{\nint Result = One * Two;\n//will fail\nAssert.AreEqual(Result, 3);\n}\n[Test]\npublic void TestConcat()\n{\nstring Result = string.Concat(One, Two);\n//will fail\nAssert.AreEqual(Result, \"21\");\n} }\n}\nCreate a new file called (exactly) SpiraConfig.json. We recommend creating one of these files for your entire solution and saving it in a convenient location. This can be in the root folder of your unit tests, or the root folder of your whole solution.
{\n\"credentials\": {\n\"url\": \"localhost/SpiraPlan\",\n\"username\": \"fredbloggs\",\n\"token\": \"{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}\",\n\"project_id\": 1,\n\n\"release_id\": 5,\n\"test_set_id\": 1\n},\n\"test_cases\": {\n\"default\": 20,\n\"TestAdd\": 21,\n\"TestMultiply\": 22\n}\n}\nYou can also avoid setting specific test case IDs through the JSON file and instead place the TestCaseId's directly in the test suite's code. These 2 methods can be used together, with the test suite property for TestCaseId taking priority over the ID set in the JSON file. If using properties you still need the JSON file to store credentials and the \"default\" test case ID.
A minimum JSON file, if only using properties for test case ids is:
{\n\"credentials\": {\n\"url\": \"localhost/SpiraPlan\",\n\"username\": \"fredbloggs\",\n\"token\": \"{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}\",\n\"project_id\": 1,\n\n\"release_id\": 5,\n\"test_set_id\": 1\n},\n\"test_cases\": {\n\"default\": 20\n}\n}\nAn example of using properties inside C# is:
using NUnit.Framework;\n\nnamespace SampleTestSuite\n{\n[TestFixture]\nclass SampleTest\n{\nint One, Two;\n[SetUp]\nprotected void SetUp()\n{\nOne = 1;\nTwo = 2;\n}\n//testcaseid is not case sensitive - any capitalization scheme will work\n[Test, Property(\"testcaseid\", 234)]\npublic void TestAdd()\n{\nint Result = One + Two;\n//will succeed\nAssert.AreEqual(Result, 3);\n}\n[Test, Property(\"TestCaseId\", 235)]\npublic void TestMultiply()\n{\nint Result = One * Two;\n//will fail\nAssert.AreEqual(Result, 3);\n}\n[Test, Property(\"TESTCASEID\", 236)]\npublic void TestConcat()\n{\nstring Result = string.Concat(One, Two);\n//will fail\nAssert.AreEqual(Result, \"21\");\n} }\n}\nFor the plugin to work, you must have credentials, and an assigned test case ID for each test either through the JSON file or the test file. Any combination of the 2 test case ID assignment methods can be used, and will not block the other one from working. The TestCaseId property assigned in test code will take priority over TestCaseId's assigned through the JSON file. If a test case id cannot be found for a given method in either of these locations and there is no default, a warning will be logged above the NUnit test summary which says which method was not reported to Spira.
In the credentials group you must specify:
In the test_cases group, put the following:
Good practice tips
You can have multiple SpiraConfig.json files - one per subfolder in your projects's unit test folder, for example. This can help with maintenance of the json file.
However, when running the test cases it will likely be easier and less error prone to have a single SpiraConfig.json folder for every test in every fixture. If following this approach make sure that each unit test method name is globally unique.
"},{"location":"Unit-Testing-Integration/Integrating-with-NUnit/#running-the-tests-with-nunit","title":"Running the Tests with NUnit","text":"To execute the tests, you should use the NUnit console runner. To do this we need to do two things:
Example command line commands
In this example:
To correctly run the tests and record the results to SpiraPlan, run the following two commands:
cd C:\\TestProjectnunit3-console \"C:\\TestProject\\bin\\Release\\SampleTestSuite.dll\" (If you installed NUnit via NuGet and have not assigned the PATH variable for this console command, you will have to manually reference the NUnit3-console.exe file using a file path instead - This must be inside of quotes just like the second part of the command is)Once you run your tests with the NUnit Console Runner, you should see the results in SpiraPlan:
Clicking on one of the test runs will show you the results:
Congratulations... You are now able to run NUnit automated tests and have the results be recorded within SpiraPlan.
"},{"location":"Unit-Testing-Integration/Integrating-with-NUnit/#installing-the-nunit-2x-add-in","title":"Installing the NUnit 2.x Add-In","text":"This section outlines how to install the SpiraTest Add-In for NUnit onto a workstation so that you can then run automated NUnit tests against a .NET application and have the results be recorded as test runs inside SpiraTest. It assumes that you already have a working installation of SpiraTest v2.2 or later. If you have an earlier version of SpiraTest you will need to upgrade to at least v2.2 before trying to use this add-in. You will also need to have either version v2.5.5 or v2.6.3 of NUnit, since there are two versions of the add-in that have been compiled with the v2.5.5 and v2.6.3 NUnit APIs. If you are using a different version, please visit www.nunit.org to obtain the appropriate version (2.5.5 or 2.6.3).
To obtain the version of the add-in that is compatible with your version of SpiraTest, you simply need to go to http://www.inflectra.com/SpiraTest/Downloads.aspx or http://www.inflectra.com/SpiraTeam/Downloads.aspx and download the NUnit Add-In zipfile.
Once you have obtained the NUnit Zipfile from our website, you should extract all the files from zip archive into a temporary folder on your computer (e.g. C:\\Temp).
Next, you should copy the add-in libraries to the folder NUnit expects to find them in. First, if you are running any instances of the NUnit GUI, close them. Then, copy the SpiraTestNUnitAddIn.dll assembly from its location in the temporary folder to the NUnit Add-In folder (typically C:\\Program Files\\NUnit 2.5.5\\bin\\net-2.0\\addins).
Now you can restart the NUnit GUI application. To check that the add-in was loaded successfully, click on Tools > Addins... to bring up the list of loaded add-ins:
You should see an entry marked \"SpiraTest Addin\" listed with its detailed description and status \"Loaded\". If this does not happen, try closing and reopening NUnit.
"},{"location":"Unit-Testing-Integration/Integrating-with-NUnit/#using-nunit-2x-with-spiratest","title":"Using NUnit 2.x with SpiraTest","text":"The typical code structure for an NUnit test fixture coded in C# is as follows:
using System;\nusing NUnit.Framework;\n\nnamespace Inflectra.SpiraTest.AddOns.SpiraTestNUnitAddIn.SampleTestSuite\n{\n/// <summary>\n/// Sample test fixture that tests the NUnit SpiraTest integration\n/// </summary>\n[TestFixture]\npublic class SampleTestFixture\n{\n[SetUp]\npublic void Init()\n{\n//Do Nothing\n}\n\n/// <summary>\n/// Sample test that asserts a failure\n/// </summary>\n[Test]\npublic void _01_SampleFailure()\n{\n//Failure Assertion\nAssert.AreEqual (1, 0);\n} /// <summary>\n/// Sample test that succeeds\n/// </summary>\n[Test]\npublic void _02_SamplePass()\n{\n//Successful assertion\nAssert.AreEqual (1, 1);\n} /// <summary>\n/// Sample test that fails\n/// </summary>\n[Test]\npublic void _03_SampleIgnore()\n{\n//Failure Assertion\nAssert.AreEqual (1, 0);\n} }\n}\nThe .NET class is marked as an NUnit test fixture by applying the [TestFixture] attribute to the class as a whole, and the [Test] attribute to each of the test assertion methods individually -- highlighted in yellow above. When you open up the class in NUnit and click the <Run> button it loads all the test classes marked with [TestFixture] and executes all the methods marked with [Test] in turn.
Each of the Assert statements is used to test the state of the application after executing some sample code that calls the functionality being tested. If the condition in the assertion is true, then execution of the test continues, if it is false, then a failure is logged and NUnit moves on to the next test method.
So, to use SpiraTest with NUnit, each of the test cases written for execution by NUnit needs to have a corresponding test case in SpiraTest. These can be either existing test cases that have manual test steps or they can be new test cases designed specifically for automated testing and therefore have no defined test steps. In either case, the changes that need to be made to the NUnit test fixture for SpiraTest to record the NUnit test run are illustrated below:
using System;\nusing NUnit.Framework;\nusing Inflectra.SpiraTest.AddOns.SpiraTestNUnitAddIn.SpiraTestFramework;\n\nnamespace Inflectra.SpiraTest.AddOns.SpiraTestNUnitAddIn.SampleTestSuite\n{\n/// <summary>\n/// Sample test fixture that tests the NUnit SpiraTest integration\n/// </summary>\n[\n TestFixture,\n SpiraTestConfiguration (\n \"http://<server name>/SpiraTest\",\n \"<username>\",\n \"<password>\",\n <project id>,\n <release id>,\n <test set id>,\n <runner name>\n)\n ]\npublic class SampleTestFixture\n{\n[SetUp]\npublic void Init()\n{\n//Do Nothing\n}\n\n/// <summary>\n/// Sample test that asserts a failure\n/// </summary>\n[\n Test,\n SpiraTestCase (<test case id>)\n ]\npublic void _01_SampleFailure()\n{\n//Failure Assertion\nAssert.AreEqual (1, 0);\n} /// <summary>\n/// Sample test that succeeds\n/// </summary>\n[\n Test,\n SpiraTestCase (<test case id>))\n ]\npublic void _02_SamplePass()\n{\n//Successful assertion\nAssert.AreEqual (1, 1);\n} /// <summary>\n/// Sample test that does not log to SpiraTest\n/// </summary>\n[\n Test\n ]\npublic void _03_SampleIgnore()\n{\n//Failure Assertion\nAssert.AreEqual (1, 0);\n} }\n}\nThe overall class is marked with a new [SpiraTestConfiguration] attribute that contains the following pieces of information needed to access the SpiraTest test repository:
In addition, each of the individual test methods needs to be mapped to a specific test case within SpiraTest. This is done by adding a [SpiraTestCase] attribute to the test method together with the ID of the corresponding test case in SpiraTest. The Test Case ID can be found on the test cases list page (click the \"Test Cases\" tab).
For these attributes to be available in your test fixture, you also need to add a reference to the SpiraTestFramework.dll assembly. This assembly can be found in the temporary folder that you extracting the add-in to. It is recommended that you move this file from the temporary folder into a permanent folder located within your .NET project.
Now all you need to do is compile your code, launch NUnit, run the test fixtures as you would normally do, and when you view the test cases in SpiraTest, you should see an NUnit automated test run displayed in the list of executed test runs:
Clicking on one of the NUnit test runs will bring up a screen that provides information regarding what NUnit test method failed, what the error was, together with the associated code stack-trace:
Congratulations... You are now able to run NUnit automated tests and have the results be recorded within SpiraTest. The sample test fixture SampleTestSuite.cs is provided with the installation.
"},{"location":"Unit-Testing-Integration/Integrating-with-PHPUnit/","title":"Integrating with PHPUnit","text":""},{"location":"Unit-Testing-Integration/Integrating-with-PHPUnit/#installing-the-phpunit-extension","title":"Installing the PHPUnit Extension","text":"This section outlines how to install the SpiraTest Extension for PHPUnit onto a workstation so that you can then run automated PHPUnit tests against a PHP application and have the results be recorded as test runs inside SpiraTest. It assumes that you already have a working installation of SpiraTest v3 or later, and a working PHP development environment. If you have an earlier version of SpiraTest you will need to upgrade to at least v3 before trying to use this extension.
To obtain the latest version of the SpiraTest PHPUnit extension you simply need to go to http://www.inflectra.com/SpiraTest/Downloads.aspx page and download the PHPUnit Extension compressed archive (.zip). This process is described in the SpiraTest Administration Guide in more detail.
The PHPUnit extension is provided as a set of PHP source files that can be imported into your existing unit tests to add the SpiraTest reporting functionality. Once you have downloaded the Zip archive, you simply need to uncompress it into a folder of your choice on your local system (e.g. C:\\Program Files\\SpiraTest\\PHPUnit Extension)
Now to use the extension within your test cases, you need to first make sure that the folder is added to the PHP include_path. The method for doing this is dependent on the platform you're using, so please refer to the documentation on php.org for details on the appropriate method for your platform. Alternatively you can copy the PHPUnit extension files to the root of the PHP installation and then just include the extension files using the root folder syntax.
Once you have completed these steps, you are now ready to begin using your PHPUnit test fixtures with SpiraTest.
"},{"location":"Unit-Testing-Integration/Integrating-with-PHPUnit/#using-phpunit-with-spiratest","title":"Using PHPUnit with SpiraTest","text":"The typical code structure for a PHPUnit test suite and test case coded in PHP is as follows:
a) Sample Test Suite
<?php\n/**\n * \n * @author Inflectra Corporation\n * @version 0\n *\n */\n\n require_once 'PHPUnit/Framework.php';\n require_once 'PHPUnit/TextUI/ResultPrinter.php';\n require_once './SimpleTest.php';\n\n // Create a test suite that contains the tests\n // from the ArrayTest class\n $suite = new PHPUnit_Framework_TestSuite('SimpleTest');\n\n // Create a test result and attach the default console text listener\n $result = new PHPUnit_Framework_TestResult;\n $textPrinter = new PHPUnit_TextUI_ResultPrinter;\n $result->addListener($textPrinter);\n\n // Run the tests and print the results\n $result = $suite->run($result);\n $textPrinter->printResult($result);\n\n ?>\n\nb) Sample Test Case\n<?php\nrequire_once 'PHPUnit/Framework/TestCase.php';\n\n/**\n * Some simple tests\n * \n * @author Inflectra Corporation\n * @version 0\n *\n */\n\nclass SimpleTest extends PHPUnit_Framework_TestCase\n{\n protected $fValue1;\n protected $fValue2;\n\n /**\n * Sets up the unit test\n */\n protected function setUp()\n {\n $this->fValue1= 2;\n $this->fValue2= 3;\n }\n\n /**\n * Tests the addition of the two values\n */\n public function testAdd()\n {\n $result = $this->fValue1 + $this->fValue2;\n\n // forced failure result == 5\n $this->assertTrue ($result == 6);\n }\n\n /**\n * Tests division by zero\n */\n /*\n public function testDivideByZero()\n {\n $zero = 0;\n $result = 8 / $zero;\n $result++; // avoid warning for not using result\n }\n\n /**\n * Tests two equal values\n */\n /*\npublic function testEquals()\n {\n $this->assertEquals(12, 12);\n $this->assertEquals(10, 10);\n $num1 = 12;\n $num2 = 12;\n $this->assertEquals($num1, $num2);\n\n $this->assertEquals(\"Size\", 12, 13);\n $this->assertEquals(\"Capacity\", 10, 199, 0);\n }\n\n /**\n * Tests success\n */\n /*\n public function testSuccess()\n {\n //Successful test\n $this->assertEquals(12, 12);\n }\n}\n?>\nThe PHP class is marked as a PHPUnit test case by inheriting from the PHPUnit_Framework_TestCase base class, and the individual test methods are identified by using the 'test' prefix, with special setUp() and tearDown() methods reserved for the respective purposes. When you open up the class in a PHPUnit runner or execute from the command line it loads all the test classes and executes all the methods marked with 'test...' in turn.
Each of the Assert statements is used to test the state of the application after executing some sample code that calls the functionality being tested. If the condition in the assertion is true, then execution of the test continues, if it is false, then a failure is logged and PHPUnit moves on to the next test method.
So, to use SpiraTest with PHPUnit, each of the test cases written for execution by PHPUnit needs to have a corresponding test case in SpiraTest. These can be either existing test cases that have manual test steps or they can be new test cases designed specifically for automated testing and therefore have no defined test steps. In either case, the changes that need to be made to the PHPUnit test case and test suite for SpiraTest to record the PHPUnit test run are illustrated below:
a) Sample Test Suite
<?php\n/**\n * Passes a list of tests to be executed to PHPUnit and adds the custom SpiraTest Listener\n * \n * @author Inflectra Corporation\n * @version 0\n *\n */\n\n require_once 'PHPUnit/Framework.php';\n require_once 'PHPUnit/TextUI/ResultPrinter.php';\n require_once './SimpleTest.php';\n require_once '../SpiraListener/Listener.php';\n\n // Create a test suite that contains the tests\n // from the ArrayTest class\n $suite = new PHPUnit_Framework_TestSuite('SimpleTest');\n\n //Set the timezone identifier to match that used by the SpiraTest server\n date_default_timezone_set (\"US/Eastern\");\n\n //Create a new SpiraTest listener instance and specify the connection info\n $spiraListener = new SpiraListener_Listener;\n $spiraListener->setBaseUrl ('http://localhost/SpiraTeam');\n $spiraListener->setUserName ('fredbloggs');\n $spiraListener->setPassword ('fredbloggs');\n $spiraListener->setProjectId (1);\n $spiraListener->setReleaseId (1);\n $spiraListener->setTestSetId (1);\n\n // Create a test result and attach the SpiraTest listener\n // object as an observer to it (as well as the default console text listener)\n $result = new PHPUnit_Framework_TestResult;\n $textPrinter = new PHPUnit_TextUI_ResultPrinter;\n $result->addListener($textPrinter);\n $result->addListener($spiraListener);\n\n // Run the tests and print the results\n $result = $suite->run($result);\n $textPrinter->printResult($result);\n\n ?>\nb) Sample Test Case
<?php\nrequire_once 'PHPUnit/Framework/TestCase.php';\n\n/**\n * Some simple tests using the ability to return results back to SpiraTest\n * \n * @author Inflectra Corporation\n * @version 0\n *\n */\n\nclass SimpleTest extends PHPUnit_Framework_TestCase\n{\n protected $fValue1;\n protected $fValue2;\n\n /**\n * Sets up the unit test\n */\n protected function setUp()\n {\n $this->fValue1= 2;\n $this->fValue2= 3;\n }\n\n /**\n * Tests the addition of the two values\n */\n public function testAdd__2()\n {\n $result = $this->fValue1 + $this->fValue2;\n\n // forced failure result == 5\n $this->assertTrue ($result == 6);\n }\n\n /**\n * Tests division by zero\n */\n /*\n public function testDivideByZero__3()\n {\n $zero = 0;\n $result = 8 / $zero;\n $result++; // avoid warning for not using result\n }\n\n /**\n * Tests two equal values\n */\n /*\npublic function testEquals__4()\n {\n $this->assertEquals(12, 12);\n $this->assertEquals(10, 10);\n $num1 = 12;\n $num2 = 12;\n $this->assertEquals($num1, $num2);\n\n $this->assertEquals(\"Size\", 12, 13);\n $this->assertEquals(\"Capacity\", 10, 199, 0);\n }\n\n /**\n * Tests success\n */\n /*\n public function testSuccess__5()\n {\n //Successful test\n $this->assertEquals(12, 12);\n }\n}\n?>\nFirstly, each of the individual test methods is appended with two underscores followed by the ID of the corresponding test case in SpiraTest. So for example testSuccess() is now testSuccess__5() as it maps to test case TC00005 inside SpiraTest.
Second, in the Test Suite class, the PHPUnit TestResult object is passed an additional PHPUnit listener (in addition to the default one). This special listener class intercepts the results from the test run during execution and uses it to generate the web-service messages that are sent to SpiraTest to communicate the test results.
The following attributes need to be set on the instance of the SpiraListener_Listener() object so that the extension can access the SpiraTest repository:
baseUrl -- The base URL used to access your instance of SpiraTest (e.g. http://myserver/SpiraTest). It should include the protocol (e.g. http/https), the server-name, the port number (if not 80/443) and the virtual directory (if there is one).
userName - A valid username for the instance of SpiraTest that has access to the project specified above
password - A valid password for the user specified above
projectId -- The ID of the project inside SpiraTest (this can be found on the project homepage in the \"Project Overview\" section)
releaseId - The ID of the SpiraTest release to associate the test run with. This can be found on the releases list page (click on the Planning > Releases tab). If you don't want to associate the test run with a specific release, just use the value -1 to indicate N/A.
testSetId - The ID of the SpiraTest test set to associate the test run with. This can be found on the test set list page (click on the Testing > Test Sets tab). If you don't want to associate the test run with a specific test set, just use the value -1 to indicate N/A.
The SpiraListener_Listener class can also be called with the parameters as the constructor arguments:
//Create a new SpiraTest listener instance and specify the connection info\n $spiraListener = new SpiraListener_Listener (\n'http://localhost/SpiraTeam',\n 'fredbloggs',\n 'fredbloggs',\n 1,\n 1,\n 1);\nYou can also attach the listener to the class declaratively by adding it to the phpunit.xml configuration file instead of adding through PHP code:
<phpunit>\n<listeners>\n<listener class=\"SpiraListener_Listener\" file=\"../SpiraListener/Listener.php\">\n<arguments>\n<!-- URL -->\n<string>http://localhost/SpiraTeam</string>\n<!-- User Name -->\n<string>fredbloggs</string>\n<!-- User Password -->\n<string>fredbloggs</string>\n<!-- Project ID -->\n<integer>1</integer>\n<!-- Release ID -->\n<integer>1</integer>\n<!-- Test Set ID -->\n<integer>1</integer>\n</arguments>\n</listener>\n</listeners>\n<testsuites>\n<testsuite name=\"Sample Suite\">\n<directory>.</directory>\n<file>./SampleSuite.php</file>\n</testsuite>\n</testsuites>\n</phpunit>\nNow all you need to do is save your code, launch PHPUnit, run the test suite as you would normally do, and when you view the test cases in SpiraTest, you should see a PHPUnit automated test run displayed in the list of executed test runs:
Clicking on one of the PHPUnit test runs will bring up a screen that provides information regarding what PHPUnit test method failed, what the error was, together with the associated code stack-trace:
Congratulations... You are now able to run PHPUnit automated tests and have the results be recorded within SpiraTest. The sample test suite SampleSuite.php and sample test case SampleTest.php are provided with the installation in the Samples subfolder.
"},{"location":"Unit-Testing-Integration/Integrating-with-Perl-TAP/","title":"Integrating with Perl TAP","text":""},{"location":"Unit-Testing-Integration/Integrating-with-Perl-TAP/#installing-the-perl-tap-extension","title":"Installing the Perl TAP Extension","text":"This section outlines how to install the SpiraTest extensions for Perl's Test Anything Protocol (TAP) so that you can then run automated Perl TAP unit tests against a Perl application and have the results be recorded as test runs inside SpiraTest. It assumes that you already have a working installation of SpiraTest v2.3 or later, and a working Perl development environment. If you have an earlier version of SpiraTest you will need to upgrade to at least v2.3 before trying to use this extension.
To obtain the latest version of the TAP extension you simply need to go to http://www.inflectra.com/SpiraTest/Downloads.aspx page and download the Perl TAP Extension compressed archive (.zip). This process is described in the SpiraTest Administration Guide in more detail.
The TAP extension is provided as a set of Perl library files (.pm) that can be imported into your existing TAP test harnesses to add the SpiraTest reporting functionality. Once you have downloaded the Zip archive, you simply need to uncompress it and copy the Inflectra folder (and subfolders) into the standard Perl library location (e.g. C:\\Perl\\lib on Windows). The sample files (the ones ending in .pl) that are not located in a folder can be put into a folder of your choice.
Once you have completed this step, you are now ready to begin running one of the provided samples or use your existing TAP unit tests with SpiraTest.
"},{"location":"Unit-Testing-Integration/Integrating-with-Perl-TAP/#using-perl-tap-extension-with-spiratest","title":"Using Perl TAP Extension with SpiraTest","text":"The typical code structure for a Perl TAP test harness is as follows:
a) The sample test harness - SampleHarness.pl
#this is a test case that tests addition operations
#!/usr/bin/perl -w
use TAP::Harness;
#instantiate the harness
my $harness = TAP::Harness ->new;
#define the list of tests to be executed
my @tests = (\"SampleTest1.pl\", \"SampleTest2.pl\");
$harness->runtests(@tests);
b) One of the sample test fixtures -- Sample1Test.pl
#!/usr/bin/perl -w
# Specify our plan, how many tests we're writing
use Test::More tests => 9;
# or alternately, if we don't know how many:
# use Test::More qw(no_plan);
# Check that our module compiles and can be \"use\"d.
BEGIN { use_ok( 'Inflectra::SpiraTest::Addons::Samples::TestMe' ); }
# Check our module can be required. Very similar test to that above.
require_ok( 'Inflectra::SpiraTest::Addons::Samples::TestMe' );
# There are a number of ways to generate the \"ok\" tests. These are:
# ok: first argument is true, second argument is name of test.
# is: first argument equals (eq) second argument, third argument is name of test.
# isnt: first argument does not equal (ne) the second, third is name of test
# like: first argument matches regexp in second, third is name of test
# unlike: first argument does not match regexp, third is name of test
# cmp_ok: compares first and third argument with comparison in second. Forth is test name.
# Here are some examples that should PASS
ok( add(1,1) == 2, \"Basic addition is working\");
is ( subtract(2,1), 1, \"Basic subtraction is working\");
isnt( multiply(2,2), 5, \"Basic multiplication doesn't fail\");
# Here are some examples that should FAIL
ok( add(1,1) == 3, \"Basic addition is working\");
is ( subtract(2,1), 0, \"Basic subtraction is working\");
isnt( multiply(2,2), 4, \"Basic multiplication doesn't fail\");
# Here is an example of a test that throws an ERROR
is($notdeclared, 1, \"Undeclared variable test\");
The TAP test cases in the sample code use the Test::More library which provides the necessary assertion methods for testing results from the code under test. The tests are themselves executed by adding their filenames to an array passed to the default TAP::Harness class. To run the test cases, you just need to execute the SampleHarness.pl file from the command line, and the test output will be echoed onto the screen.
Now, to use SpiraTest with TAR, each of the TAP test case files (e.g. SampleTest1.pl, SampleTest2.pl in our example) needs to have a corresponding test case in SpiraTest. These can be either existing test cases that have manual test steps or they can be new test cases designed specifically for automated testing and therefore have no defined test steps. In either case, no changes need to be made to the individual test cases, but the following changes need to be made to the test harness (illustrated in yellow below):
#this is a test case that tests addition operations
#!/usr/bin/perl -w
use Inflectra::SpiraTest::Addons::SpiraHarness::Harness;
#instantiate the harness
my $harness = Inflectra::SpiraTest::Addons::SpiraHarness::Harness->new;
#specify the spiratest custom harness properties
$spira_args = {};
$spira_args->{\"base_url\"} = \"http://localhost/SpiraTest\";
$spira_args->{\"user_name\"} = \"fredbloggs\";
$spira_args->{\"password\"} = \"fredbloggs\";
$spira_args->{\"project_id\"} = 1;
$spira_args->{\"release_id\"} = 1;
$spira_args->{\"test_set_id\"} = 1;
$harness->{\"spira_args\"} = $spira_args;
#define the list of tests and their SpiraTest Mapping
#Hash is of the format: TestFile => Test Case ID
my $tests = {};
$tests->{\"SampleTest1.pl\"} = 2;
$tests->{\"SampleTest2.pl\"} = 3;
harness-\\>runtests(tests);
Firstly you need to use the SpiraTest specific harness rather than the general TAP::Harness library. This new class is actually a subclass of the standard one, so it supports all the same methods, with the exception of the runtests command, which now accepts a Perl hashref rather than a simple array.
Also you need to create and pass a hashref of arguments to the test harness (the spira_args property on the instantiated harness class) so that it knows how to access the SpiraTest server during test execution:
base_url-- The base URL used to access your instance of SpiraTest (e.g. http://myserver/SpiraTest). It should include the protocol (e.g. http/https), the server-name, the port number (if not 80/443) and the virtual directory (if there is one).
user_name - A valid username for the instance of SpiraTest that has access to the project specified above
password - A valid password for the user specified above
project_id - The ID of the project inside SpiraTest (this can be found on the project homepage in the \"Project Overview\" section)
release_id - The ID of the SpiraTest release to associate the test run with. This can be found on the releases list page (click on the Planning > Releases tab). If you don't want to associate the test run with a specific release, just comment out the line.
test_set_id - The ID of the SpiraTest test set to associate the test run with. This can be found on the test set list page (click on the Testing > Test Sets tab). If you don't want to associate the test run with a specific test set, just comment out the line.
Finally instead of passing a simple array of the test case files to be executed, you instead need to create a Perl hashref and pass that to the runtests(...) method. The hashref needs to contain a list of the various test case files and their associated SpiraTest Test Case ID with the TC prefix removed (e.g. test case TC00005 would be just 5).
Now all you need to do is save your code, run the test fixtures as you would normally do (e.g. by executing from the command line), and when you view the test cases in SpiraTest, you should see a Perl::TAP automated test run displayed in the list of executed test runs:
Clicking on one of the Perl::TAP test runs will bring up a screen that provides information regarding what Perl::TAP test method failed, what the error was, together with the associated code stack-trace:
Congratulations... You are now able to run Perl TAP unit tests and have the results be recorded within SpiraTest. The sample test suite SampleHarness.pl together with its two test cases (SampleTest1.pl and SampleTest2.pl) is provided with the installation.
"},{"location":"Unit-Testing-Integration/Integrating-with-PyTest/","title":"Integrating with PyTest","text":"This section describes how to use SpiraTest/SpiraTeam/SpiraPlan (hereafter referred to as SpiraTest) in conjunction with python's pytest unit testing framework. The SpiraTest-pytest plugin enables the automated sending of unit test results from pytest to SpiraTest with a specified Test Case, and (optionally), a release and/or test set as well.
"},{"location":"Unit-Testing-Integration/Integrating-with-PyTest/#installing-the-pytest-plugin","title":"Installing the pytest plugin","text":"This section outlines how to install the SpiraTest plugin for pytest. It assumes that you already have a working installation of SpiraTest v2.3 or later. If you have an earlier version of SpiraTest you will need to upgrade to at least v2.3 before trying to use this plugin. You will also need to have Python (with pip) and pytest version 3.0 or later.
To obtain the latest version of the SpiraTest plugin, simply run the following command:
pip install pytest-spiratest
This command will install the latest version of the plugin straight from the Python Package Index (PyPI). Once the SpiraTest plugin is successfully installed, all you need to do is configure the extension, then you can begin testing!
"},{"location":"Unit-Testing-Integration/Integrating-with-PyTest/#configuring-the-pytest-plugin","title":"Configuring the pytest plugin","text":"This section outlines how to configure the SpiraTest plugin for pytest. It assumes that you are familiar with pytest, and already have some working tests configured.
Here is a sample test file:
import pytest\n\n# Function we are testing\ndef add(num1, num2):\n return num1 + num2\n\n# Successful test\ndef test_add_1():\n assert add(1, 1) == 2\n\n# Failed test\ndef test_add_2():\n assert add(2, 1) == 2\n\n# Failed test\ndef test_add_3():\n assert add(4, 1) == 6\nNote how test_add_2 is used in the configuration file discussed below.
In your test root folder (the folder you run the pytest command from), create a file named \"spira.cfg\" with the following:
[credentials]\n# Following are required\n\nurl = localhost/SpiraTest\nusername = fredbloggs\ntoken = {XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXXX}\nproject_id = 1\n\n# Following are optional:\nrelease_id = 5\ntest_set_id = 1\n\n[test_cases]\n# Assigned to the rest\ndefault = 20\n# Test case for a specific function\ntest_add_2 = 22\nFor the plugin to work, you must have both settings groups (credentials and test_cases) with the following in the credentials group:
url -- The base url to your SpiraTest installation, without a '/' at the end.
username -- The username you use to sign into SpiraTest.
token -- Your RSS Token. Found in your profile page as the \"RSS Token\" field, you must have RSS Feeds enabled for this to work.
project_id -- The ID of the project you would like the test runs to be sent to
release_id -- OPTIONAL -- Use if you would like to associate the test run with a release.
test_set_id -- OPTIONAL -- Use if you would like to associate the test run with a test set.
Under the test_cases group, put the following:
default -- The default test case ID for functions without an assigned test case
\\ - Used to override the default setting for a function's test case ID in SpiraTest. Only include the function name, without the parentheses.
NOTE: If your functions are in a class then add the class before the function name - for example MyClass.myFunction. The plugin is case insensitive.
Once you have filled out all of the configurations, you are all set to go!
Running the pytest (or py.test) command will run your unit tests, send the data to SpiraTest, and show the results to you. Here is an example of the test_add_3 function inside SpiraTest:
"},{"location":"Unit-Testing-Integration/Integrating-with-PyUnit/","title":"Integrating with PyUnit","text":""},{"location":"Unit-Testing-Integration/Integrating-with-PyUnit/#installing-the-pyunit-extension","title":"Installing the PyUnit Extension","text":"This section outlines how to install the SpiraTest Extension for PyUnit onto a workstation so that you can then run automated PyUnit tests against a Python application and have the results be recorded as test runs inside SpiraTest. It assumes that you already have a working installation of SpiraTest v2.3 or later, and a working Python development environment. If you have an earlier version of SpiraTest you will need to upgrade to at least v2.3 before trying to use this extension.
To obtain the version of the PyUnit extension that is compatible with your version of SpiraTest, you simply need to log-in as a project-level administrator to SpiraTest, go to the Administration home page and download the PyUnit Extension compressed archive (.zip). This process is described in the SpiraTest Administration Guide in more detail.
The PyUnit extension is provided as a set of Python source files that can be imported into your existing unit tests to add the SpiraTest reporting functionality. Once you have downloaded the Zip archive, you simply need to uncompress it into a folder of your choice on your local system (e.g. C:\\Program Files\\SpiraTest\\PyUnit Extension)
Now to use the extension within your test cases, you need to first make sure that the folder is added to the Python PYTHONPATH. The method for doing this is dependent on the platform you're using, so please refer to the documentation on python.org for details on the appropriate method for your platform. As an example, on a Windows platform, the folder would be added to the PYTHONPATH by typing the following:
set PYTHONPATH=%PYTHONPATH%; C:\\Program Files\\SpiraTest\\PyUnit Extension
Once you have completed this step, you are now ready to begin using your PyUnit test fixtures with SpiraTest.
"},{"location":"Unit-Testing-Integration/Integrating-with-PyUnit/#using-pyunit-with-spiratest","title":"Using PyUnit with SpiraTest","text":"The typical code structure for a PyUnit test fixture coded in Python is as follows:
import random\n\nimport unittest\n\n\\# sample PyUnit test case\n\nclass TestSequenceFunctions(unittest.TestCase):\n\ndef setUp(self):\n\nself.seq = range(10)\n\ndef testshuffle(self):\n\n\\# make sure the shuffled sequence does not lose any elements\n\nrandom.shuffle(self.seq)\n\nself.seq.sort()\n\nself.assertEqual(self.seq, range(10))\n\ndef testchoice(self):\n\nelement = random.choice(self.seq)\n\nself.assert\\_(element in self.seq)\n\ndef testfail(self):\n\nself.assertEqual(1, 2, \"1==2 Should fail\")\n\ndef testsample(self):\n\nself.assertRaises(ValueError, random.sample, self.seq, 20)\n\nfor element in random.sample(self.seq, 5):\n\nself.assert\\_(element in self.seq)\n\nsuite =\nunittest.TestLoader().loadTestsFromTestCase(TestSequenceFunctions)\n\ntestResult = unittest.TextTestRunner(verbosity=2).run(suite)\nThe Python class is marked as a PyUnit test fixture by inheriting from the unittest.TestCase base class, and the individual test methods are identified by using the 'test' prefix, with special setUp() and tearDown() methods reserved for the respective purposes. When you open up the class in a PyUnit runner or execute from the command line it loads all the test classes and executes all the methods marked with 'test...' in turn.
Each of the Assert statements is used to test the state of the application after executing some sample code that calls the functionality being tested. If the condition in the assertion is true, then execution of the test continues, if it is false, then a failure is logged and PyUnit moves on to the next test method.
So, to use SpiraTest with PyUnit, each of the test cases written for execution by PyUnit needs to have a corresponding test case in SpiraTest. These can be either existing test cases that have manual test steps or they can be new test cases designed specifically for automated testing and therefore have no defined test steps. In either case, the changes that need to be made to the PyUnit test fixture for SpiraTest to record the PyUnit test run are illustrated below:
import random\n\nimport unittest\n\nimport spiratestextension\n\n\\# sample PyUnit test case\n\nclass TestSequenceFunctions(unittest.TestCase):\n\ndef setUp(self):\n\nself.seq = range(10)\n\ndef testshuffle\\_\\_2(self):\n\n\\# make sure the shuffled sequence does not lose any elements\n\nrandom.shuffle(self.seq)\n\nself.seq.sort()\n\nself.assertEqual(self.seq, range(10))\n\ndef testchoice\\_\\_3(self):\n\nelement = random.choice(self.seq)\n\nself.assert\\_(element in self.seq)\n\ndef testfail\\_\\_4(self):\n\nself.assertEqual(1, 2, \"1==2 Should fail\")\n\ndef testsample\\_\\_5(self):\n\nself.assertRaises(ValueError, random.sample, self.seq, 20)\n\nfor element in random.sample(self.seq, 5):\n\nself.assert\\_(element in self.seq)\n\nsuite =\nunittest.TestLoader().loadTestsFromTestCase(TestSequenceFunctions)\n\ntestResult = unittest.TextTestRunner(verbosity=2).run(suite)\n\nreleaseId = 1\n\ntestSetId = 1\n\nspiraTestExtension = spiratestextension.SpiraTestExtension()\n\nspiraTestExtension.projectId = 1\n\nspiraTestExtension.server = \"localhost\"\n\nspiraTestExtension.port = 80\n\nspiraTestExtension.ssl = False\n\nspiraTestExtension.path = \"SpiraTest\"\n\nspiraTestExtension.userName = \"fredbloggs\"\n\nspiraTestExtension.password = \"PleaseChange\"\n\nspiraTestExtension.recordResults(TestSequenceFunctions, testResult,\nreleaseId, testSetId)\nFirstly, each of the individual test methods is appended with two underscores followed by the ID of the corresponding test case in SpiraTest. So for example testshuffle() is now testshuffle__2() as it maps to test case TC00002 inside SpiraTest.
Second, at the end of the test run, the testResults object generated by the test run is passed to a special SpiraTestExtension() class via the recordResults() method. This class takes the results from the test run and uses it to generate the web-service messages that are sent to SpiraTest to communicate the test results.
The following attributes need to be set on the instance of the SpiraTestExtension() object so that the extension can access the SpiraTest repository:
spiraTestExtension.projectId -- The ID of the project inside SpiraTest (this can be found on the project homepage in the \"Project Overview\" section)
spiraTestExtension.server - The name of the web server that SpiraTest is installed on
spiraTestExtension.port -- The port used to access SpiraTest over the network (typically 80 unless you have a custom port setup)
spiraTestExtension.ssl -- This should be set to False for HTTP and True for HTTPS
spiraTestExtension.path -- The path to SpiraTest on your webserver (typically just 'SpiraTest')
spiraTestExtension.userName - A valid username for the instance of SpiraTest that has access to the project specified above
spiraTestExtension.password - A valid password for the user specified above
In addition, when calling the recordResults() method, you should also pass the Release ID and the Test Set ID which is used to tell SpiraTest which release and/or test set to associate the test execution with.
The Release ID can be found on the releases list page (click on the Planning > Releases tab) -- just remove the RL prefix from the number as well as any leading zeros. Similarly, the Test Set ID can be found on the test set list page (click on the Testing > Test Sets tab) -- just remove the TX prefix from the number as well as any leading zeros. If you don't want to associate the test run with a specific release or test set, just use the special value -1 to indicate N/A.
Now all you need to do is save your code, launch PyUnit, run the test fixtures as you would normally do, and when you view the test cases in SpiraTest, you should see a PyUnit automated test run displayed in the list of executed test runs:
Clicking on one of the PyUnit test runs will bring up a screen that provides information regarding what PyUnit test method failed, what the error was, together with the associated code stack-trace:
Congratulations... You are now able to run PyUnit automated tests and have the results be recorded within SpiraTest. The sample test fixture testsequencefunctions.py is provided with the installation.
"},{"location":"Unit-Testing-Integration/Integrating-with-Ruby-TestUnit/","title":"Integrating with Ruby Test::Unit","text":""},{"location":"Unit-Testing-Integration/Integrating-with-Ruby-TestUnit/#installing-the-ruby-testunit-test-runner","title":"Installing the Ruby Test::Unit Test Runner","text":"This section outlines how to install the SpiraTest custom Test Runner for Test::Unit onto a workstation so that you can then run automated Test::Unit tests against a Ruby application and have the results be recorded as test runs inside SpiraTest. It assumes that you already have a working installation of SpiraTest v2.3 or later, and a working Ruby development environment. If you have an earlier version of SpiraTest you will need to upgrade to at least v2.3 before trying to use this extension.
To obtain the version of the Test::Unit test runner that is compatible with your version of SpiraTest, you simply need to log-in as a project-level administrator to SpiraTest, go to the Administration home page and download the Test::Unit test runner compressed archive (.zip). This process is described in the SpiraTest Administration Guide in more detail.
The Test::Unit test runner is provided as a set of Ruby source files that can be imported into your existing unit tests to add the SpiraTest reporting functionality. Once you have downloaded the Zip archive, you simply need to uncompress it into a folder of your choice on your local system (e.g. C:\\Program Files\\SpiraTest\\RubyTestUnitRunner)
Now to use the custom test runner within your test cases, you need to first make sure that the folder is added to the Ruby RUBYPATH (or just the system PATH). The method for doing this is dependent on the platform you're using, so please refer to the documentation on http://ruby-lang.org for details on the appropriate method for your platform. As an example, on a Windows platform, the folder would be added to the RUBYPATH by typing the following:
set RUBYPATH=%RUBYPATH%; C:\\Program Files\\SpiraTest\\RubyTestUnitRunner
Once you have completed this step, you are now ready to begin using your Test::Unit test fixtures with SpiraTest.
"},{"location":"Unit-Testing-Integration/Integrating-with-Ruby-TestUnit/#using-ruby-testunit-with-spiratest","title":"Using Ruby Test::Unit with SpiraTest","text":"The typical code structure for a Test::Unit test suite and test case coded in Ruby is as follows:
#this is a test case that tests addition operations
class TC_Adder < Test::Unit::TestCase
def setup
@adder = Adder.new(5)
end
def test_add
assert_equal(7, @adder.add(2), \"Should have added correctly\")
end
def test_addfail
assert_equal(7, @adder.add(3), \"Test failure\")
end
def teardown
@adder = nil
end
end
#this is a test suite that calls the test case
class TS_Examples
def self.suite
suite = Test::Unit::TestSuite.new
suite << TC_Adder.suite
return suite
end
end
Test::Unit::UI::Console::TestRunner.run(TS_Examples)
The Test::Unit test case is marked as a Test::Unit test case by inheriting from the Test::Unit::TestCase base class, and the individual test methods are identified by using the 'test' prefix, with special setup and teardown methods reserved for the respective purposes. When you open up the class in a Ruby Test::Unit runner or execute from the command line it loads all the test classes and executes all the methods marked with 'test...' in turn.
Each of the Assert statements is used to test the state of the application after executing some sample code that calls the functionality being tested. If the condition in the assertion is true, then execution of the test continues, if it is false, then a failure is logged and Test::Unit moves on to the next test method.
So, to use SpiraTest with Test::Unit, each of the test cases written for execution by Test::Unit needs to have a corresponding test case in SpiraTest. These can be either existing test cases that have manual test steps or they can be new test cases designed specifically for automated testing and therefore have no defined test steps. In either case, the changes that need to be made to the Test::Unit test case and test suite for SpiraTest to record the Test::Unit test run are illustrated below:
#this is a test case that tests addition operations
class TC_Adder < Test::Unit::TestCase
def setup
@adder = Adder.new(5)
end
def test_add__2
assert_equal(7, @adder.add(2), \"Should have added correctly\")
end
def test_addfail__3
assert_equal(7, @adder.add(3), \"Test failure\")
end
def teardown
@adder = nil
end
end
#this is a test suite that calls the test case
class TS_Examples
def self.suite
suite = Test::Unit::TestSuite.new
suite << TC_Adder.suite
return suite
end
end
projectId = 1
releaseId = 2
testSetId = -1
testRunner = Test::Unit::SpiraTest::TestRunner.new(TS_Examples, \"http://servername/SpiraTest\", \"fredbloggs\", \"fredbloggs\", projectId, releaseId, testSetId)
testRunner.start
Firstly, each of the individual test methods is appended with two underscores followed by the ID of the corresponding test case in SpiraTest. So for example test_add is now test_add__2 as it maps to test case TC00002 inside SpiraTest.
Second, at the end of the test suite, instead of just creating the standard Console Test Runner class and passing it a reference to the test suite (e.g. TS_Examples), we now create an instance of the special Test::Unit::SpiraTest::TestRunner class, passing it a reference to the test suite as well as specifying the SpiraTest connection information.
This class takes the results from the test suite being executed and uses it to generate the web-service messages that are sent to SpiraTest to communicate the test results.
The following parameters need to be passed during the instantiation of the Test::Unit::SpiraTest::TestRunner object so that the custom test runner can access the SpiraTest repository:
suite -- the reference to the Test::Unit test suite that contains the test cases being executed. In our example above, this is the TS_Examples class.
baseUrl-- The base URL used to access your instance of SpiraTest (e.g. http://myserver/SpiraTest). It should include the protocol (e.g. http/https), the server-name, the port number (if not 80/443) and the virtual directory (if there is one).
userName - A valid username for the instance of SpiraTest that has access to the project specified above
password - A valid password for the user specified above
projectId - The ID of the project inside SpiraTest (this can be found on the project homepage in the \"Project Overview\" section)
releaseId - The ID of the SpiraTest release to associate the test run with. This can be found on the releases list page (click on the Planning > Releases tab). If you don't want to associate the test run with a specific release, just use the value -1 to indicate N/A.
testSetId - The ID of the SpiraTest test set to associate the test run with. This can be found on the test set list page (click on the Testing > Test Sets tab). If you don't want to associate the test run with a specific test set, just use the value -1 to indicate N/A.
Now all you need to do is save your code, launch Test::Unit, run the test fixtures as you would normally do (e.g. by executing the TS_Examples ruby file from the command line), and when you view the test cases in SpiraTest, you should see a Ruby Test::Unit automated test run displayed in the list of executed test runs:
Clicking on one of the Ruby Test::Unit test runs will bring up a screen that provides information regarding what Ruby Test::Unit test method failed, what the error was, together with the associated code stack-trace:
Congratulations... You are now able to run Test::Unit automated tests and have the results be recorded within SpiraTest. The sample test suite ts_examples.rb together with two test cases (tc_adder and tc_subtracter) is provided with the installation.
"},{"location":"Unit-Testing-Integration/Integrating-with-Selenium/","title":"Integrating with Selenium","text":"Selenium WebDriver is a test tool that allows you to write automated web application user interface tests in any programming language against any HTTP website using any mainstream JavaScript-enabled browser. Selenium WebDriver comes in two parts.
An API or library for the web browser itself that is used to allow external applications to connect to the web browser and instruct it to perform certain operations.
Client libraries for various computer languages - these are referred to as 'language bindings.
Therefore to use SpiraTest with Selenium WebDriver (hereafter referred to as just Selenium), you need to decide which client driver you want to use, and then use the appropriate integration between SpiraTest and that driver's underlying platform/language. Any unit test framework listed in this guide can be used with Selenium (in addition to just running unit tests), we have some examples below for .NET, Java and Python.
"},{"location":"Unit-Testing-Integration/Integrating-with-Selenium/#using-the-net-driver","title":"Using the .NET Driver","text":"To use the .NET driver for Selenium with SpiraTest, you will need to run your Selenium tests within the context of an NUnit test fixture. Once you have configured NUnit for use with SpriaTest, there is one change that needs to be made to the SpiraTest NUnit configuration so that the Selenium tests report back to SpiraTest as 'Selenium' rather than \"NUnit' so you can distinguish between them.
Supplied with the SpiraTest NUnit add-in is a sample test for using Selenium with SpiraTest:
using System;\nusing NUnit.Framework;\nusing Inflectra.SpiraTest.AddOns.SpiraTestNUnitAddIn.SpiraTestFramework;\nusing Selenium;\n\nnamespace SeleniumSampleTest\n{\n/// <summary>\n/// Sample test fixture that tests the NUnit SpiraTest integration with the\n/// Selenium-RC .NET Driver\n/// </summary>\n[\n TestFixture,\n SpiraTestConfiguration(\"http://localhost/SpiraTest\", \"fredbloggs\", \"fredbloggs\", 1, 1, 2, SpiraTestConfigurationAttribute.RunnerName.Selenium)\n ]\npublic class GoogleTest\n{\nprivate static ISelenium selenium;\n\n[SetUp]\npublic void SetupTest()\n{\n//Instantiate the selenium .NET proxy\nselenium = new DefaultSelenium(\"localhost\", 4444, \"*iexplore\", \"http://www.google.com\");\nselenium.Start();\n}\n\n[TearDown]\npublic void TeardownTest()\n{\nselenium.Stop();\n}\n\n/// <summary>\n/// Sample test that searches on Google, passes correctly\n/// </summary>\n[\n Test,\n SpiraTestCase (5)\n ]\npublic void GoogleSearch()\n{\n//Opens up Google\nselenium.Open(\"http://www.google.com/webhp\");\n\n//Verifies that the title matches\nAssert.AreEqual(\"Google\", selenium.GetTitle());\nselenium.Type(\"q\", \"Selenium OpenQA\");\n\n//Verifies that it can find the Selenium website\nAssert.AreEqual(\"Selenium OpenQA\", selenium.GetValue(\"q\"));\nselenium.Click(\"btnG\");\nselenium.WaitForPageToLoad(\"5000\");\nAssert.IsTrue(selenium.IsTextPresent(\"www.openqa.org\"));\nAssert.AreEqual(\"Selenium OpenQA - Google Search\", selenium.GetTitle());\n} }\n}\nThe details of the sample itself are described in more detail on the Selenium website, and you can see that we have added the SpiraTest specific attributes onto the test case and test methods to indicate that they need to report back to SpiraTest.
However there is one change that has been made to the SpiraTestConfiguration attribute applied to the test fixture -- an extra SpiraTestConfigurationAttribute.RunnerName.Selenium parameter has been specified. This tells the SpiraTest NUnit add-in to report the results back as being generated by Selenium rather than NUnit.
"},{"location":"Unit-Testing-Integration/Integrating-with-Selenium/#using-the-java-driver","title":"Using the Java Driver","text":"To use the Java driver for Selenium with SpiraTest, you will need to run your Selenium tests within the context of a TestNG test fixture. Once you have configured TestNG for use with SpriaTest, there is one change that needs to be made to the SpiraTest TestNG configuration so that the Selenium tests report back to SpiraTest as 'Selenium' rather than \"TestNG' so you can distinguish between them.
Supplied with the SpiraTest TestNG listener is a sample test for using Selenium with SpiraTest:
The details of the sample itself are described in more detail on the Selenium website, and you can see that we have added the SpiraTest specific attributes onto the test case and test methods to indicate that they need to report back to SpiraTest.
package com.inflectra.spiratest.addons.testnglistener.samples;\n\nimport org.testng.annotations.*;\nimport static org.testng.AssertJUnit.*;\nimport com.thoughtworks.selenium.*;\n\nimport com.inflectra.spiratest.addons.testnglistener.*;\n\n/**\n * A sample Selenium test using the ability to return results back to SpiraTest\n * \n * @author Inflectra Corporation\n * @version 2.3.0\n *\n */\n@SpiraTestConfiguration(\nurl=\"http://localhost/SpiraTest\",\nlogin=\"fredbloggs\",\npassword=\"fredbloggs\",\nprojectId=1,\nreleaseId=1,\ntestSetId=-1\nrunner=RunnerName.Selenium\n)\n@Test(groups={\"seleniumtest\"})\npublic class SeleniumTest\n{\nprivate Selenium selenium;\n\n@BeforeClass\npublic void setUp()\n{\n//Instantiate the selenium Java proxy\nString url = \"http://www.google.com\";\nselenium = new DefaultSelenium(\"localhost\", 4444, \"*firefox\", url);\nselenium.start();\n}\n\n@AfterClass\nprotected void tearDown()\n{\nselenium.stop();\n}\n\n// Sample test that searches on Google, passes correctly\n@Test(groups={\"seleniumtest\"})\n@SpiraTestCase(testCaseId=5)\npublic void testGoogle()\n{\n//Opens up Google\nselenium.open(\"http://www.google.com/webhp?hl=en\");\n\n//Verifies that the title matches\nassertEquals(\"Google\", selenium.getTitle());\nselenium.type(\"q\", \"Selenium OpenQA\");\n\n//Verifies that it can find the Selenium website\nassertEquals(\"Selenium OpenQA\", selenium.getValue(\"q\"));\nselenium.click(\"btnG\");\nselenium.waitForPageToLoad(\"5000\");\nassertEquals(\"Selenium OpenQA - Google Search\", selenium.getTitle());\n}\n}\nHowever there is one change that has been made to the SpiraTestConfiguration attribute applied to the test fixture -- an extra runner=RunnerName.Selenium parameter has been specified. This tells the SpiraTest TestNG listener to report the results back as being generated by Selenium rather than TestNG.
"},{"location":"Unit-Testing-Integration/Integrating-with-Selenium/#using-the-python-driver","title":"Using the Python Driver","text":"To use the Python driver for Selenium with SpiraTest, you will need to run your Selenium tests within the context of a PyUnit unit-test fixture. Once you have configured PyUnit for use with SpriaTest, there is one change that needs to be made to the SpiraTest PyUnit configuration so that the Selenium tests report back to SpiraTest as 'Selenium' rather than \"PyUnit' so you can distinguish between them.
Supplied with the SpiraTest PyUnit extension is a sample test for using Selenium with SpiraTest:
from selenium import selenium\nimport unittest\nimport sys, time\nimport spiratestextension\n\n# A sample Selenium test using the ability to return results back to SpiraTest\n#\n# Author Inflectra Corporation\n# Version 2.3.0\n#\nclass TestSeleniumSample(unittest.TestCase):\n\n seleniumHost = 'localhost'\n seleniumPort = str(4444)\n browserStartCommand = \"*firefox\"\n browserURL = \"http://www.google.com\"\n\n def setUp(self):\n print \"Using selenium server at \" + self.seleniumHost + \":\" + self.seleniumPort\n self.selenium = selenium(self.seleniumHost, self.seleniumPort, self.browserStartCommand, self.browserURL)\n self.selenium.start()\n\n def testGoogle__4(self):\n selenium = self.selenium\n selenium.open(\"http://www.google.com/webhp?hl=en\")\n\n #Verifies that the title matches\n self.assertEqual (\"Google\", selenium.get_title())\n selenium.type(\"q\", \"Selenium OpenQA\")\n\n #Verifies that it can find the Selenium website\n self.assertEqual(\"Selenium OpenQA\", selenium.get_value(\"q\"))\n selenium.click(\"btnG\")\n selenium.wait_for_page_to_load(\"5000\")\n self.assertEqual(\"Selenium OpenQA - Google Search\", selenium.get_title())\n\n def tearDown(self):\n self.selenium.stop()\n\nsuite = unittest.TestLoader().loadTestsFromTestCase(TestSeleniumSample)\ntestResult = unittest.TextTestRunner(verbosity=2).run(suite)\nreleaseId = 1\ntestSetId = -1\nspiraTestExtension = spiratestextension.SpiraTestExtension()\nspiraTestExtension.projectId = 1\nspiraTestExtension.server = \"localhost\"\nspiraTestExtension.port = 80\nspiraTestExtension.path = \"SpiraTest\"\nspiraTestExtension.userName = \"fredbloggs\"\nspiraTestExtension.password = \"fredbloggs\"\nspiraTestExtension.recordResults(TestSeleniumSample, testResult, releaseId, testSetId, \"Selenium\")\nThe details of the sample itself are described in more detail on the Selenium website, and you can see that we have added the SpiraTest specific test case suffixes and reporting code into the test methods to indicate that they need to report back to SpiraTest.
However there is one change that has been made to the spiraTestExtension.recordResults method called at the end of the test case. An extra string parameter has been specified that contains \"Selenium\". This tells the SpiraTest PyUnit extension to report the results back as being generated by Selenium rather than PyUnit.
"},{"location":"Unit-Testing-Integration/Integrating-with-TestNG/","title":"Integrating with TestNG","text":""},{"location":"Unit-Testing-Integration/Integrating-with-TestNG/#installing-the-testng-listener","title":"Installing the TestNG Listener","text":"This section outlines how to install the SpiraTest Listener for TestNG onto a workstation so that you can then run automated TestNG unit tests against a Java application and have the results be recorded as test runs inside SpiraTest. It assumes that you already have a working installation of SpiraTest v3.0 or later. If you have an earlier version of SpiraTest you will need to upgrade to at least v3.0 before trying to use this listener. You will also need to have at least version 1.0 of TestNG running under JDK 1.5 or later, since earlier versions do not have support for annotations and custom listeners. If you are using an earlier version, please visit testng.org to obtain the latest version.
To obtain the latest version of the TestNG listener, you simply need to log-in as a project-level administrator to SpiraTest, go to the Administration home page and download the SpiraTest TestNG Listener compressed archive (.zip) from the section that lists downloads and add-ons. This process is described in the SpiraTest Administration Guide in more detail.
The TestNG listener is provided as a compressed zipfile that includes both the binaries (packaged as a JAR-file) and the source code (stored in a folder structure that mirrors the Java classpath). The JAR-file binary was compiled for use on a Windows x86 platform, other platforms (e.g. Linux) will require you to compile the Java source files into the appropriate Java classfiles before using the extension. The rest of this section will assume that you are using the pre-compiled JAR-file.
Once you have downloaded the Zip archive, you need to uncompress it into a folder of your choice on your local system. Assuming that you uncompressed it to the C:\\Program Files\\SpiraTestListener folder, you should have the following folder structure created:
C:\\Program Files\\SpiraTestListener
C:\\Program Files\\SpiraTestListener\\com
C:\\Program Files\\SpiraTestListener\\com\\inflectra
C:\\Program Files\\SpiraTestListener\\com\\inflectra\\spiratest
C:\\Program Files\\SpiraTestListener\\com\\inflectra\\spiratest\\addons
C:\\Program Files\\SpiraTestListener\\com\\inflectra\\spiratest\\addons\\testnglistener
C:\\Program Files\\SpiraTestListener\\Extension\\com\\inflectra\\spiratest\\addons\\testnglistener\\samples
The JAR-file is located in the root folder, the source-code for the extension can be found in the \"testnglistener\" subfolder, and the sample test fixture can be found in the \"samples\" subfolder.
Now to use the listener within your test cases, you need to first make sure that the JAR-file is added to the Java classpath. The method for doing this is dependent on the platform you're using, so please refer to FAQ on www.testngorg for details on the appropriate method for your platform. As an example, on a Windows platform, the JAR-file would be added to the classpath by typing the following:
set CLASSPATH=%CLASSPATH%; C:\\Program Files\\SpiraTestListener\\TestNGListener.jar
Once you have completed this step, you are now ready to begin using your TestNG test fixtures with SpiraTest.
"},{"location":"Unit-Testing-Integration/Integrating-with-TestNG/#using-testng-with-spiratest","title":"Using TestNG with SpiraTest","text":"The typical code structure for a TestNG test fixture coded in Java is as follows:
package com.inflectra.spiratest.addons.testnglistener.samples;\n\nimport org.testng.annotations.*;\nimport static org.testng.AssertJUnit.*;\n\nimport java.util.*;\n\n/**\n * Some simple tests using the ability to return results back to SpiraTest\n * \n * @author Inflectra Corporation\n * @version 2.3.0\n *\n */\n@Test(groups={\"unittest\"})\npublic class SimpleTest\n{\nprotected int fValue1;\nprotected int fValue2;\n\n/**\n * Sets up the unit test\n */\n@BeforeClass\npublic void setUp()\n{\nfValue1= 2;\nfValue2= 3;\n}\n\n/**\n * Tests the addition of the two values\n */\n@Test(groups={\"unittest\"})\npublic void testAdd()\n{\ndouble result = fValue1 + fValue2;\n\n// forced failure result == 5\nassertTrue (result == 6);\n}\n\n/**\n * Tests division by zero\n */\n@Test(groups={\"unittest\"})\npublic void testDivideByZero()\n{\nint zero = 0;\nint result = 8 / zero;\nresult++; // avoid warning for not using result\n}\n\n/**\n * Tests two equal values\n */\n@Test(groups={\"unittest\"})\npublic void testEquals()\n{\nassertEquals(12, 12);\nassertEquals(12L, 12L);\nassertEquals(new Long(12), new Long(12));\n\nassertEquals(\"Size\", 12, 13);\nassertEquals(\"Capacity\", 12.0, 11.99, 0.0);\n}\n\n/**\n * Tests success\n */\n@Test(groups={\"unittest\"})\npublic void testSuccess()\n{\n//Successful test\nassertEquals(12, 12);\n}\n}\nThe Java class is marked as a TestNG test fixture by applying the @Test attribute to the class definition, and the @Test attribute to each of the test assertion methods individually -- highlighted in yellow above. In addition, special setup methods are marked with annotations such as @BeforeClass. When you open up the class in a TestNG runner or execute from the command line it loads all the test classes and executes all the methods marked with @Test in turn.
Each of the Assert statements is used to test the state of the application after executing some sample code that calls the functionality being tested. If the condition in the assertion is true, then execution of the test continues, if it is false, then a failure is logged and TestNG moves on to the next test method.
So, to use SpiraTest with TestNG, each of the test cases written for execution by TestNG needs to have a corresponding test case in SpiraTest. These can be either existing test cases that have manual test steps or they can be new test cases designed specifically for automated testing and therefore have no defined test steps. In either case, the changes that need to be made to the TestNG test fixture for SpiraTest to record the TestNG test run are illustrated below:
package com.inflectra.spiratest.addons.testnglistener.samples;\n\nimport org.testng.annotations.*;\nimport static org.testng.AssertJUnit.*;\n\nimport com.inflectra.spiratest.addons.testnglistener.*;\n\nimport java.util.*;\n\n/**\n * Some simple tests using the ability to return results back to SpiraTest\n * \n * @author Inflectra Corporation\n * @version 2.3.0\n *\n */\n@SpiraTestConfiguration(\nurl=\"http://localhost/SpiraTest\",\nlogin=\"fredbloggs\",\napiKey=\"{00000000-0000-0000-0000-000000000000}\",\nprojectId=1,\nreleaseId=1,\ntestSetId=-1\n)\n@Test(groups={\"unittest\"})\npublic class SimpleTest\n{\nprotected int fValue1;\nprotected int fValue2;\n\n/**\n * Sets up the unit test\n */\n@BeforeClass\npublic void setUp()\n{\nfValue1= 2;\nfValue2= 3;\n}\n\n/**\n * Tests the addition of the two values\n */\n@Test(groups={\"unittest\"})\n@SpiraTestCase(testCaseId=5)\npublic void testAdd()\n{\ndouble result = fValue1 + fValue2;\n\n// forced failure result == 5\nassertTrue (result == 6);\n}\n\n/**\n * Tests division by zero\n */\n@Test(groups={\"unittest\"})\n@SpiraTestCase(testCaseId=5)\npublic void testDivideByZero()\n{\nint zero = 0;\nint result = 8 / zero;\nresult++; // avoid warning for not using result\n}\n\n/**\n * Tests two equal values\n */\n@Test(groups={\"unittest\"})\n@SpiraTestCase(testCaseId=6)\npublic void testEquals()\n{\nassertEquals(12, 12);\nassertEquals(12L, 12L);\nassertEquals(new Long(12), new Long(12));\n\nassertEquals(\"Size\", 12, 13);\nassertEquals(\"Capacity\", 12.0, 11.99, 0.0);\n}\n\n/**\n * Tests success\n */\n@Test(groups={\"unittest\"})\n@SpiraTestCase(testCaseId=6)\npublic void testSuccess()\n{\n//Successful test\nassertEquals(12, 12);\n}\n}\nThe overall class is marked with a new @SpiraTestConfiguration attribute that contains the following pieces of information needed to access the SpiraTest test repository:
URL - The URL to the instance of SpiraTest being accessed. This needs to start with http:// or https://
Login - A valid username for the instance of SpiraTest.
apiKey - A valid API Key / RSS Token for the instance of SpiraTest (for the user specified in Login).
Project Id - The ID of the project (this can be found on the project homepage in the \"Project Overview\" section)
Release Id (Optional) - The ID of the release to associate the test run with. This can be found on the releases list page (click on the Planning > Releases tab). If you don't want to specify a release, just use the value -1.
Test Set Id (Optional) -- The ID of the test set to associate the test run with. This can be found on the test set list page (click on the Testing > Test Sets tab). If you don't want to specify a test set, just use the value -1. If you choose a test set that is associated with a release, then you don't need to explicitly set a release id (i.e. just use -1). However if you do set a release value, it will override the value associated with the test set.
In addition, each of the individual test methods needs to be mapped to a specific test case within SpiraTest. This is done by adding a @SpiraTestCase attribute to the test method together with the ID of the corresponding test case in SpiraTest. The Test Case ID can be found on the test cases list page (click the \"Test Cases\" tab).
For these attributes to be available in your test fixture, you also need to add a reference to the com.inflectra.spiratest.addons.testnglistener package. This package is bundled within the supplied JAR-file library for Windows machines, and can be compiled from the provided source .java files on other platforms.
"},{"location":"Unit-Testing-Integration/Integrating-with-TestNG/#running-the-testng-tests-from-the-command-line","title":"Running the TestNG Tests from the Command-Line","text":"Now all you need to do is compile your code and then launch TestNG by executing the test fixture through the command line (or through your choice of IDE, e.g. Eclipse) with the SpiraTest listener option specified as a command argument. E.g. for our sample test, you would use the following command:
java -classpath \"C:\\Program Files\\SpiraTestListener\\TestNGListener.jar;C:\\Program Files\\TestNG-5.7\\testng-5.7\\testng-5.7-jdk15.jar\" org.testng.TestNG -listener com.inflectra.spiratest.addons.testnglistener.SpiraTestListener com\\inflectra\\spiratest\\addons\\testnglistener\\samples\\unittests.xml
Once the test has run, you can view the test cases in SpiraTest, you should see a TestNG automated test run displayed in the list of executed test runs:
Clicking on one of the TestNG test runs will bring up a screen that provides information regarding what TestNG test method failed, what the error was, together with the associated code stack-trace:
Congratulations... You are now able to run TestNG automated tests and have the results be recorded within SpiraTest. The sample test fixture SimpleText.java is provided with the installation.
"},{"location":"Unit-Testing-Integration/Using-Test-Runner-For-Excel/","title":"Spira Test Runner add-in for Excel 365","text":"This add-in lets you retrieve your assigned Test Cases and Test Sets for a specific product in SpiraTest\u00ae, SpiraTeam\u00ae, or SpiraPlan\u00ae application (hereafter referred to as SpiraPlan). You can run your tests straight away or later. When you are ready you can send your test executions back to SpiraPlan. This addin works with Microsoft Excel 2016+, Excel in the cloud (via a web browser), and Excel on iPad OS.
"},{"location":"Unit-Testing-Integration/Using-Test-Runner-For-Excel/#installation","title":"Installation","text":"To install the add-in:
Open the add-in from the ribbon and fill in the login form panel on the right of your Excel screen. If you are using Excel in the browser, make sure your SpiraPlan is accessible over the internet.
If there is a problem connecting to SpiraPlan you will be notified with an error message.
After you have logged in, click Logout to close your connection with SpiraPlan and take you back to the add-in's login page.
"},{"location":"Unit-Testing-Integration/Using-Test-Runner-For-Excel/#retrieving-tests-from-spiraplan","title":"Retrieving Tests from SpiraPlan","text":"After successfully logging in to the application, you need to get the most up to date list of Test Cases and/or Test Sets assigned to you from SpiraPlan. Select a product to retrieve all your assigned tests cases and sets from and click on 'Get from Spira'.
When you click the Get from Spira button you will see the Test Cases and their Test Steps be added the current sheet of the spreadsheet. The following tests are retrieved:
Resuming Testing
The add-in only communicates to SpiraPlan when you first get data from SpiraPlan and then at the end when you send the new data into SpiraPlan. You can therefore carry out your testing described below completely offline if you wish. You can also work on tests over multiple sessions.
When you return to the spreadsheet with your Test Cases after the first session you need to resume your testing. To do this you can use the spreadsheet without opening the add-in. You only need to login to the add-in when you want to send the Test Runs to SpiraPlan. That is what the \"Use Current Sheet button directly below the Get from Spira button is for.
"},{"location":"Unit-Testing-Integration/Using-Test-Runner-For-Excel/#running-tests","title":"Running Tests","text":"On retrieving your assigned tests from SpiraPlan the add-in populates the sheet with the information in a format to make it clear how to run your tests.
"},{"location":"Unit-Testing-Integration/Using-Test-Runner-For-Excel/#spreadsheet-structure","title":"Spreadsheet Structure","text":"The spreadsheet is generating using the following columns:
<b> for bold.The add-in uses different cell background colors to help you know what you can or should do in each cell:
Let's put the columns and the cell background colors together:
Column Test Case Rows Test Step Rows Send to Spira Log Gray (disabled) Gray (disabled) Test Case ID Gray (disabled) Gray (disabled) Test Set ID Gray (disabled) Gray (disabled) Test Step ID Gray (disabled) Gray (disabled) Test Case Name Gray (disabled) Gray (disabled) Release Green (populate) Gray (disabled) Set Case Unique ID Gray (disabled) Gray (disabled) Test Step Description Gray (disabled) White (optional) Test Step Expected Result Gray (disabled) White (optional) Test Step Sample Data Gray (disabled) White (optional) Execution Status Gray (disabled) Green (populate) Actual Result Gray (disabled) Green (populate) Incident Name Gray (disabled) White (optional)"},{"location":"Unit-Testing-Integration/Using-Test-Runner-For-Excel/#how-to-execute-tests","title":"How to Execute Tests","text":"To execute the Test Cases on the spreadsheet:
Let's say you have 5 Test Cases assigned to you but you plan to only execute 2 of them. How can you execute just these 2 and not the remaining 3? Delete all the rows for the 3 Test Cases you are not testing today. Make sure to delete the rows for the Test Case and all of each Test Case's Test Steps. If this is not done correctly you will not be able to log anything to SpiraPlan.
"},{"location":"Unit-Testing-Integration/Using-Test-Runner-For-Excel/#sending-test-runs-to-spiraplan","title":"Sending Test Runs to SpiraPlan","text":"Once you have finished executing all the tests and recorded the results of your test runs on the spreadsheet, it is time to send the data to Spira to get properly recorded. There are two ways of doing this, depending on how you executed your tests:
If you got your data from SpiraPlan using the add-in, and straight away executed your tests in a single seession, you can easily send the data back to SpiraPlan.
To do so click the button \"Send to Spira\" on the add-in and wait for the operation to complete.
"},{"location":"Unit-Testing-Integration/Using-Test-Runner-For-Excel/#multi-session-testing","title":"Multi Session Testing","text":"If you have first got your data from SpiraPlan and then executed your assigned tests over multiple sessions, you now need to send the data back to SpiraPlan, without wiping out your work. If you have been testing over multiple sessions in this way follow the steps below:
Once everything has been sent to SpiraPlan, results are recorded in the \"'Send to Spira' Log\" column of the spreadsheet. In this column you will see:
Below are common questions and answers related to common errors you may face when using the add-in.
1. After entering my SpiraPlan credentials and clicking 'Log in', I see the error message...
Error: Request has been terminated Possible causes: the network is offline, Origin is not allowed by Access-Control-Allow-Origin, the page is being unloaded, etc.
How to solve this issue: first, make sure your credentials are correct. You can re-generate your RSS / API Key by going to your user page in SpiraPlan. Always remember to click 'Save' after re-generating your RSS key. If the problem persists, ask your SpiraPlan administrator to check the SpiraPlan API CORS configuration (in SpiraPlan: Admin menu > System > Security Settings > Allowed Domains) to see if it is accepting connections from the add-in domain.
2. When importing data from a spreadsheet on my computer, I get error messages. How do I solve it?
Here is a list of possible error messages you may see when importing a spreadsheet into the add-in and how to solve them:
Error: The selected product does not match the Spreadsheet data.
Solution: You cannot run Tests from one product and record them in another product. In the add-in, select the same product of the saved spreadsheet and try again.
Error: Database sheet is missing.
Solution: Your spreadsheet is missing required data. You have to re-import (using the \"Get From Spira\" button) the data. Never delete/rename any worksheet from the spreadsheet.
Error: There are columns missing in the spreadsheet.
Solution: Your worksheet is missing required data. You have to re-import (using the \"Get From Spira\" button) the data. Never delete or rename any column from the worksheet.
Error: Invalid Test Case detected: missing Test Step(s).
Solution: Your worksheet is missing Test Case data. You have to re-import (using the \"Get From Spira\" button) the data. You can delete Test Cases from the worksheet, but make sure to not leave Test Sets with no Test Cases or Test Cases with no Test Steps.
3. After clicking on \"Send to Spira\", I see a red Test Case row and an error message saying...
Invalid Execution Statuses: This TestCase contains an invalid execution statuses combination.
How to solve this issue: only valid Test Runs can be recorded in SpiraPlan. A valid Test Run is one that meets the conditions below. Check to make sure your test case meets all of these. In particular, review any Test Steps that have an execution status of Not Run still.
4. After clicking on 'Send to Spira', I see a Test Step red row and an error message saying...
Missing Actual Result: This TestStep needs to have an Actual Result, since it failed.
How to solve this issue: all Test Steps that are run but not passed (steps marked as any of Failed, Blocked, Caution, or N/A) must have an Actual Result. Check your non-passed Test Steps and make sure they all have an actual result and try again.
5. After clicking on 'Get from Spira' or 'Send to Spira', nothing happens for a long time - the add-in is stuck
Make sure you are not editing any cell when clicking on any add-in button. Excel does not allow add-ins to modify the spreadsheet when in editing mode. To solve this, click on any blank cell or press the ESC key. If it still does not work, check your internet connection and try again.
"},{"location":"Version-Control-Integration/Integrating-with-CVS/","title":"Integrating with CVS","text":"The Concurrent Versions System (CVS) is a Software Configuration Management (SCM) system that enables users to work on code simultaneously while preserving previous versions by avoiding collisions in code edits. This plug-in will allow users of SpiraPlan or SpiraTeam (hereafter referred to as SpiraTeam) to be able to browse a CVS repository and view commits linked to SpiraTeam artifacts.
The plug-in will download a working-copy of the CVS repository onto the SpiraTeam server and use that for displaying the list of files/folders. The list of commits will be queries dynamically from the CVS repository on an as-needed basis. The rest of this section outlines how to install and use the plug-in with SpiraTeam.
Note: The plug-in will allow users to download and view different commits of files and view commit logs, but no changes to the repository are allowed through the plug-in.
"},{"location":"Version-Control-Integration/Integrating-with-CVS/#installing-the-cvs-plug-in","title":"Installing the CVS Plug-In","text":"To install the CVS Version Control plug-in, copy the following files from the plug-in zip-archive into the \"VersionControl\" sub-folder of the SpiraTeam installation: - CvsProvider.dll - DocsVision.Remoting.dll - ICSharpCode.SharpCvsLib.dll - ICSharpCode.SharpZipLib.dll - log4net.dll
"},{"location":"Version-Control-Integration/Integrating-with-CVS/#configuring-cvs-in-spiraplan","title":"Configuring CVS in SpiraPlan","text":"Before you can start using CVS in SpiraPlan you need to setup, at a system level, how CVS and SpiraPlan should work together:
Complete the form on this page as below:
sharpcvslib.cvs.sourceforge.net:/cvsroot/sharpcvslibCustom 01: This must contain the name of the connection protocol being used to access the CVS server. The following protocols are supported:
Custom 02: This must contain the name of the module you wish to access in the CVS repository.
When finished, click \"Insert\". You will be taken back to the Source Code list page, with CvsProvider listed as an available plug-in.
"},{"location":"Version-Control-Integration/Integrating-with-CVS/#use-cvs-for-your-product","title":"Use CVS for Your Product","text":"Once CVS has been configured at the system level, you are ready to use it for any products you need to.
Source code setup for your product is complete. Click on the \"Source Code\" or \"Commits\" menu items under the Developing tab to navigate and browse the source code repository.
You can read more about working with source code in SpiraPlan at the links below:
Since the integration with CVS requires that a working copy of the CVS repository be stored on the SpiraTeam server, you may decide at some point to unlink a disused CVS repository from SpiraTeam to save disk-space. However unlinking the repository through the SpiraTeam web interface will not remove the working copy of the repository from the server.
To permanently remove a repository from the SpiraTeam server, you need to locate the following path:
If you look inside this folder, you will see a subfolder called \"Inflectra\", and under that will be a subfolder called \"CvsProvider\". If you open up this subfolder, you will see a list of all the CVS modules that have been accessed through SpiraTeam. To purge a module, just select it and choose the Delete Folder option in Windows.
"},{"location":"Version-Control-Integration/Integrating-with-Git/","title":"Integrating with Git","text":""},{"location":"Version-Control-Integration/Integrating-with-Git/#introduction-to-git","title":"Introduction to Git","text":"Git is a Distributed Version Control System (DVCS) system that keeps track of software commits and allows many developers to work on a given project without necessarily being connected to a common network since it doesn't rely on a central repository. Instead Git distributes copies of relevant branches of the entire source code repository to each user's machine.
SpiraPlan's Git plug-in allows users of SpiraTeam or SpiraPlan (hereafter referred to as SpiraPlan) to browse a Git repository and view commits linked to SpiraPlan artifacts.
The plug-in will clone a read-only \"bare\" (i.e. no working folder) copy of the Git repository onto the SpiraPlan server. The plugin use that bare repository to parse data about the various branches, files, folders, and commits. The plug-in performs all necessary 'pull' requests from the remote repository to keep the local bare repository up to date. Note: the plugin does not make any changes to the repo at all.
The current version of the Git plugin is compatiblbe with SpiraPlan v4.2.0.2 or later.
"},{"location":"Version-Control-Integration/Integrating-with-Git/#installing-the-git-plug-in","title":"Installing the Git Plug-In","text":"Cloud hosted users and on-premise users on SpiraPlan 6+ can skip this section: all required files are included as part of the normal installation process.
To install the Git plug-in on your SpiraPlan service:
Copy the following files from the plug-in zip-archive into the \"VersionControl\" sub-folder of the SpiraPlan installation:
If your server operating system is 64-bit, copy \"git2.dll\" from the \"x64\" directory of the downloaded plug-in zip file into the \"VersionControl\" sub-folder of the SpiraPlan installation. Note: Do not create an x64 folder under VersionControl, make sure the file lives in the VersionControl folder itself.
Before you can start using Git in SpiraPlan you need to setup, at a system level, how Git and SpiraPlan should work together:
Complete the form on this page as below:
When finished, click \"Insert\". You will be taken back to the Source Code list page, with GitProvider listed as an available plug-in.
Github and Gitlab
When connecting to repositories on Github or Gitlab please use a Personal Access Token instead of your password in the password field. Your password may work for public repos, but you will always need to use the Personal Access Token for private repos.
Learn more about setting up these tokens for Github and Gitlab.
"},{"location":"Version-Control-Integration/Integrating-with-Git/#use-git-for-your-product","title":"Use Git for Your Product","text":"Once Git has been configured at the system level, you are ready to use it for any products you need to.
Source code setup for your product is complete. Click on the \"Source Code\" or \"Commits\" menu items under the Developing tab to navigate and browse the source code repository.
You can read more about working with source code in SpiraPlan at the links below:
Git integration needs a bare copy of the Git repository to be stored on the SpiraPlan server. If you decide to deactivate a SpiraPlan product from using a Git repository, the bare repository will still exist on the server.
To permanently remove a repository from the SpiraPlan server, you need to locate the following path: C:\\ProgramData\\Inflectra\\Spira\\GitProvider
In this folder, you will see a list of all the Git repositories that have been accessed through SpiraPlan. To purge a repository, select it and choose the Delete Folder option in Windows.
"},{"location":"Version-Control-Integration/Integrating-with-Mercurial/","title":"Integrating with Mercurial","text":"Mercurial is a Distributed Version Control System (DVCS) system that keeps track of software commits and allows many developers to work on a given project without necessarily being connected to a common network since it doesn't rely on a central repository, but instead distributes copies of the entire source code repository to each user's workstation.
The SpiraTeam plug-in for Mercurial allows users of SpiraPlan or SpiraTeam (hereafter referred to as SpiraTeam) to be able to browse a Mercurial repository and view commits linked to SpiraTeam artifacts.
The plug-in will download a read-only working-copy of the Mercurial repository onto the SpiraTeam server and use that for displaying the list of files/folders. The list of commits will be queried dynamically from this local repository on an as-needed basis. The plug-in also performs 'pull' requests from the specified remote repository to ensure that the local repository remains up to date.
The rest of this section outlines how to install and use the plug-in with SpiraTeam.
Note: The plug-in will allow users to download and view different commits of files and view commit logs, but no changes to the repository are allowed through the plug-in.
"},{"location":"Version-Control-Integration/Integrating-with-Mercurial/#installing-the-mercurial-plug-in-to-install-the-mercurial-version-control-plug-in-follow-these-steps","title":"Installing the Mercurial Plug-In To install the Mercurial Version Control plug-in, follow these steps:","text":"Copy the following files from the plug-in zip-archive into the \"VersionControl\" sub-folder of the SpiraTeam installation:
- MercurialProvider.dll\n- Mercurial.Net.dll\nBefore you can start using Mercurial in SpiraPlan you need to setup, at a system level, how Mercurial and SpiraPlan should work together:
Complete the form on this page as below:
<https://bitbucket.org/aragost/javahg> ssh://example.com/hg/When finished, click \"Insert\". You will be taken back to the Source Code list page, with MercurialProvider listed as an available plug-in.
"},{"location":"Version-Control-Integration/Integrating-with-Mercurial/#use-mercurial-for-your-product","title":"Use Mercurial for Your Product","text":"Once Mercurial has been configured at the system level, you are ready to use it for any products you need to.
Source code setup for your product is complete. Click on the \"Source Code\" or \"Commits\" menu items under the Developing tab to navigate and browse the source code repository.
You can read more about working with source code in SpiraPlan at the links below:
Since the integration with Mercurial requires that a working copy of the Mercurial repository be stored on the SpiraTeam server, you may decide at some point to unlink a disused Mercurial repository from SpiraTeam to save disk-space. However unlinking the repository through the SpiraTeam web interface will not remove the working copy of the repository from the server.
To permanently remove a repository from the SpiraTeam server, you need to locate the following path:
If you look inside this folder, you will see a subfolder called \"Inflectra\", and under that will be a subfolder called \"MercurialProvider\". If you open up this subfolder, you will see a list of all the Mercurial repositories that have been accessed through SpiraTeam. To purge a module, just select it and choose the Delete Folder option in Windows.
"},{"location":"Version-Control-Integration/Integrating-with-Perforce/","title":"Integrating with Perforce","text":""},{"location":"Version-Control-Integration/Integrating-with-Perforce/#installing-the-perforce-plug-in","title":"Installing the Perforce Plug-In","text":"To install the Perforce Version Control plug-in, copy the following files to the folder named \"VersionControl\" in the SpiraTeam installation folder:
- Inflectra.Global.dll\n- P4API.dll\n- P4DN.dll\n- PerforceProvider.dll\nBefore you can start using Perforce in SpiraPlan you need to setup, at a system level, how Perforce and SpiraPlan should work together:
Complete the form on this page as below:
When finished, click \"Insert\". You will be taken back to the Source Code list page, with PerforceProvider listed as an available plug-in.
"},{"location":"Version-Control-Integration/Integrating-with-Perforce/#use-perforce-for-your-product","title":"Use Perforce for Your Product","text":"Once Perforce has been configured at the system level, you are ready to use it for any products you need to.
Source code setup for your product is complete. Click on the \"Source Code\" or \"Commits\" menu items under the Developing tab to navigate and browse the source code repository.
You can read more about working with source code in SpiraPlan at the links below:
Subversion (also known as SVN) is a Software Configuration Management (SCM) system, that enables users to work on code simultaneously while preserving previous versions by avoiding collisions in code edits. While users working on the code will usually have a complete copy of the repository on their local systems, this plug-in will access the repository remotely by use of the \"svn://\" , \"http://\" and \"https://\" protocols. (Note that \"svn+ssh://\" may be supported on a server by server basis.)
Due to the methodologies in which IIS handles web requests and runs on the server, any SSH connection certificates that have trust issues will be automatically accepted. Therefore, we recommend using an IP address to connect to the server instead of a DNS name that could be redirected to an unsafe connection.
The current version of the Subversion plugin requires SpiraPlan or SpiraTeam v5.4.0.0 or later.
"},{"location":"Version-Control-Integration/Integrating-with-Subversion/#installing-the-subversion-plug-in","title":"Installing the Subversion Plug-In","text":"Cloud hosted users and on-premise users on SpiraPlan 6+ can skip this section: all required files are included as part of the normal installation process.
To install the Subversion Version Control plug-in, follow these steps:
Before you can start using Subversion in SpiraPlan you need to setup, at a system level, how Subversion and SpiraPlan should work together:
Complete the form on this page as below:
When finished, click the \"Insert\" button and you will be taken back to the Source Code list page, with SubversionProvider listed as an available plug-in.
"},{"location":"Version-Control-Integration/Integrating-with-Subversion/#use-subversion-for-your-product","title":"Use Subversion for Your Product","text":"Once Subversion has been configured at the system level, you are ready to use it for any products you need to.
Source code setup for your product is complete. Click on the \"Source Code\" or \"Commits\" menu items under the Developing tab to navigate and browse the source code repository.
You can read more about working with source code in SpiraPlan at the links below:
Microsoft Visual Studio Team System (VSTS) Team Foundation Server (TFS) from Microsoft\u00ae (hereafter referred to as TFS) is a Software Configuration Management (SCM) system that enables users to work on code simultaneously while preserving previous versions by avoiding collisions in code edits. This plug-in will allow users of SpiraPlan or SpiraTeam (hereafter referred to as SpiraTeam) to be able to browse a TFS repository and view commits linked to SpiraTeam artifacts. There are separate plug-ins for TFS 2005/2008, 2010 and 2012+. When connecting to a TFS 2010/2012+ repository, the connection URL will also need to be in a different format (see below).
While users working on the code will usually have a complete copy of the repository on their local systems, this plug-in will access the TFS repository remotely. The rest of this section outlines how to install and use the plug-in with SpiraTeam.
Note: The plug-in will allow users to download and view different commits of files and view commit logs, but no changes to the repository are allowed through the plug-in.
"},{"location":"Version-Control-Integration/Integrating-with-TFS/#installing-the-tfs-plug-in","title":"Installing the TFS Plug-In","text":"To install the TFS Version Control plug-in, follow these steps:
Copy the following files from the plug-in zip-archive into the \"VersionControl\" sub-folder of the SpiraTeam installation:
Before you can start using TFS in SpiraPlan you need to setup, at a system level, how TFS and SpiraPlan should work together:
Complete the form on this page as below:
Connection Info: This field points to the URL used for accessing the Team Foundation Server. Typically TFS runs on website port 8080, but you may need to check with your IT administrator to verify. The exact connection URL will depend on your version of TFS:
Login / Password: The user id and the password of the user to use while accessing and retrieving information from the TFS repository. If the repository doesn't require a username/password, just use \"anonymous\" as both the username and password.
When finished, click \"Insert\". You will be taken back to the Source Code list page, with TfsProvider listed as an available plug-in.
"},{"location":"Version-Control-Integration/Integrating-with-TFS/#use-tfs-for-your-product","title":"Use TFS for Your Product","text":"Once TFS has been configured at the system level, you are ready to use it for any products you need to.
Source code setup for your product is complete. Click on the \"Source Code\" or \"Commits\" menu items under the Developing tab to navigate and browse the source code repository.
You can read more about working with source code in SpiraPlan at the links below:
As described in Linking to artifacts in commit messages, you can easily associate check-ins of code in TFS with relevant SpiraTeam artifacts by adding the appropriate artifact identifier in the commit messages.
In order to enforce this process, one of our customers has written a custom Visual Studio 2008 and 2010/2012+ Team System check-in policy that will force users to enter at least one SpiraTeam artifact in each of the check-in comments. This policy will also check the IDs of the supplied artifacts to make sure they exist in the appropriate SpiraTeam installation.
To install the custom check-in policy, you should download the SpiraPolicySetup.msi (for 2008) or SpiraPolicy.vsix (for 2010+) installation package from the Add-Ons/Downloads section of the Inflectra website (http://www.inflectra.com/SpiraTeam/Downloads.aspx) and run the installation package on each workstation that has Visual Studio installed. Once this installation has been completed, you need to tell Visual Studio to add the custom check-in policy:
Click on the [Add...] button to add a new check-in policy:
Select the SpiraTeam/Plan TFS check-in Policy and click [OK]. This will bring up the SpiraTeam custom policy configuration dialog box:
Enter the URL for the SpiraTeam server (you only need the server name and virtual directory portion) as well as a valid login and password. Then click [Connect] to get the list of projects.
Tortoise is a family of Windows Explorer shell extensions that helps programmers manage different versions of the source code for their programs directly inside the standard Windows Explorer user interface.
There are different versions of Tortoise that are compatible with different version control systems.
"},{"location":"Version-Control-Integration/Integrating-with-Tortoise/#tortoisesvn","title":"TortoiseSVN","text":"TortoiseSVN is a Subversion client, implemented as a Microsoft Windows shell extension, that helps programmers manage different versions of the source code for their programs.
In Windows Explorer, besides showing context menu items for Subversion commands, TortoiseSVN provides icon overlay that indicates the status of Subversion working copies.
"},{"location":"Version-Control-Integration/Integrating-with-Tortoise/#tortoisegit","title":"TortoiseGit","text":"TortoiseGit is a Git commit control client, implemented as a Windows shell extension and based on TortoiseSVN.
In Windows Explorer, besides showing context menu items for Git commands, TortoiseGit provides icon overlays that indicate the status of Git working trees and files. It also comes with the TortoiseGitMerge utility to visually compare two files and resolve conflicts.
"},{"location":"Version-Control-Integration/Integrating-with-Tortoise/#tortoisecvs","title":"TortoiseCVS","text":"TortoiseCVS is a CVS client for Microsoft Windows. Unlike most CVS tools, it includes itself in Windows' shell by adding entries in the contextual menu of the file explorer, therefore it does not run in its own window. Moreover, it adds icons onto files and directories controlled by CVS, giving additional information to the user without having to run a full-scale stand-alone application.
"},{"location":"Version-Control-Integration/Integrating-with-Tortoise/#using-the-spira-plugin-for-tortoise","title":"Using the Spira Plugin for Tortoise","text":"The Spira issue-tracker plugin for Tortoise (called TurtleSpira) works with all variants of Tortoise, including TortoiseGit,TortoiseSVN, and TortoiseCVS, and lets you streamline your workflow for linking source code commits / commits to assigned artifacts in SpiraTeam, SpiraPlan, or SpiraTest.
The Tortoise plugin system lets you integrate different issue trackers. With such plugins it is possible to fetch information directly from the issue tracker, interact with the user and provide information back to Tortoise about open issues, verify log messages entered by the user and even run actions after a successful commit to e.g, close an issue.
"},{"location":"Version-Control-Integration/Integrating-with-Tortoise/#installing-the-turtlespira-plugin","title":"Installing the TurtleSpira Plugin","text":"You need to download the TurtleSpira windows installer package from the Inflectra website and run it on the same computer that already has Tortoise installed:
Once it has finished installing, you need to go to the Tortoise > Settings and bring up the Settings dialog box:
On the main Settings menu, click on the Hook Scripts > Issue Tracker Integration.
Click on the Add button to bring up the dialog box to configure the issue tracker integration:
You need to fill out the following fields in the dialog box:
Then Click on the Options button to bring up the Spira configuration dialog box:
You need to enter the URL, User Name, and Password to your Spira instance and click the Login button. Once it connects, then choose the appropriate Product from the dropdown list and then click Save.
You have now installed and configured the TurtleSpira plugin.
"},{"location":"Version-Control-Integration/Integrating-with-Tortoise/#committing-a-code-change-linked-to-spira-artifacts","title":"Committing a Code Change Linked to Spira Artifacts","text":"Now we want to commit a change we have made to some source code files and associate that change with artifacts in Spira that are assigned to me. For example, I might be fixing a bug, implementing a feature, or completing a task associated with a requirement.
When you choose the menu option in Tortoise to commit the change, it displays the following dialog box:
Click on the Choose Artifact button on the top-right of the dialog box:
This screen will list all of the Spira requirements, tasks, and incidents assigned to you. Simply select the checkboxes of the items you want to associate with this commit operation and click OK:
The plugin will automatically populate the list of requirements, tasks and incidents into the commit text. Now click the OK button to commit the change:
Check the box of any tasks that you want the plugin to automatically close for you in Spira. If the source code commit completed all the work on the task, you should check the box. If the commit was merely part of the task, you should leave it unchecked.
In addition, there is a checkbox which will tell the plugin to add the commit text as comments onto all the selected artifacts.
Once that has been done, you will see the following comments appear in Spira:
"},{"location":"Version-Control-Integration/Integrating-with-VSS/","title":"Integrating with VSS","text":"Visual SourceSafe\u00ae (VSS) from Microsoft\u00ae is a Software Configuration Management (SCM) system that enables users to work on code simultaneously while preserving previous versions by avoiding collisions in code edits. This plug-in will allow users of SpiraPlan or SpiraTeam (hereafter referred to as SpiraTeam) to be able to browse a VSS database and view commits linked to SpiraTeam artifacts.
While users working on the code will usually have a complete copy of the repository on their local systems, this plug-in will access the VSS database remotely.The rest of this section outlines how to install and use the plug-in with SpiraTeam.
Note: The plug-in will allow users to download and view different commits of files and view commit logs, but no changes to the repository are allowed through the plug-in.
"},{"location":"Version-Control-Integration/Integrating-with-VSS/#installing-the-vss-plug-in","title":"Installing the VSS Plug-In","text":"To install the VSS Version Control plug-in, follow these steps:
Copy the following files from the plug-in zip-archive into the \"VersionControl\" sub-folder of the SpiraTeam installation:
Before you can start using VSS in SpiraPlan you need to setup, at a system level, how VSS and SpiraPlan should work together:
Complete the form on this page as below:
C:\\VssDatabases\\Project1\\srcsafe.iniWhen finished, click \"Insert\". You will be taken back to the Source Code list page, with VssProvider listed as an available plug-in.
"},{"location":"Version-Control-Integration/Integrating-with-VSS/#use-vss-for-your-product","title":"Use VSS for Your Product","text":"Once VSS has been configured at the system level, you are ready to use it for any products you need to.
Source code setup for your product is complete. Click on the \"Source Code\" or \"Commits\" menu items under the Developing tab to navigate and browse the source code repository.
You can read more about working with source code in SpiraPlan at the links below: