A customer asked is how they could run a report on a daily basis to see for how long a defect has been assigned to someone and the audit log of the assignment changes. That is best done by using the History table and the main Incident table together in a custom report
The latest version of SpiraTeam and SpiraPlan (v6.5.2) has support for creating and managing project baselines. In this initial release there are no standard reports built into the system for viewing baselines and the changes that have occurred. This article we provide some custom reports you can use until the next version is released.
A customer asked us how we could group the data in a report by a sub-heading. For example, suppose you want to display a list of all the Components, and under each component, show a table of associated requirements. Well your trusty friend XSLT 1.0 comes to the rescue.
When you run Rapise automated tests using RapiseLauncher the system will automatically embed the images from Rapise into the various test cases and test run reports. By default the report format has relatively small images so that they can fit easily into the tables of expected result and actual results. However some users have asked for ways to make the images bigger.
The standard PDF reports in Spira and KronoDesk uses a dynamic table layout, so all of the cells take a general width that is based on the number of columns and the width of the page. A customer wanted to be able to modify the widths to make certain columns larger or smaller (e.g. make the ID field smaller than the name). This article explains the process to do this.
In this article, we will create a custom report that displays a list of users in the system and the associated effort for tasks, incidents and test cases.
A customer asked us if we could provide a report of all the test cases and test results across all projects and programs. In the future we plan on having built in screens for quality managers to be able to see the test results and test metrics across all projects without needing to run a report. However this report will give you the information in the meantime.
A customer asked us if we could provide a report of all the activity by users across all projects and programs. In the future we plan on having built in screens for resource managers to be able to see user activity across all projects without needing to run a report. However this report will give you the information in the meantime.
Sometimes customers need to show a Graph with all the Test Runs by status for a specific Release in Spira. This article explains how to use the custom graphing engine to achieve this.
Sometimes customers need to show a Graph with all the Incidents by status for a specific Component in Spira. This article explains how to use the custom graphing engine to achieve this.
Of the unique needs of a requirements and test management system when working in the Defense industry, specifically when designing, building, and testing mission systems, is the ability to link individual test steps to the requirements. This article provides you with a custom report to use to display such a traceability matrix.
Sometimes you want to get a report of all the tests executed along with their test cases with the tests organized by the order in which they are displayed in SpiraTest. The custom reporting system in Spira allows you to create a custom report of all the test runs and test run steps sorted by test case order. This articles describes the process for creating such a report.
A customer asked us how you could create a custom report that shows the following information in a single table:
- A list of test sets containing:
- For each test step, the linked:
UI Automation is a default technology for testing desktop applications on Windows. If your application is not .NET or Java then Rapise will turn on UI Automation library during recording. If some elements in your application are not recognized or there are issues with playback of recorded steps then most likely your application is using custom UI controls. You may inspect those controls and send information to Rapise support team to get recommendations on how to proceed with testing.
A customer asked us if it was possible to create a version of the requirements traceability report that would display the following:
- Requirement (name and ID)
- Test Case (name and ID)
- Test Run (ID and execution status)
- Incident (ID)
This article is for those who test a desktop application via UI Automation library. Since desktop applications are frequently built using UI controls from different vendors and the number of such controls available on the market is pretty big (> 1k) - Rapise may not have out-of-the-box support for some controls in your application. For such cases Rapise offers a low level API to navigate UI Automation tree of elements inside an application and read/write element properties. In this tutorial we'll show how to use this API and quickly add minimal support for a custom control.
Sometimes you want a simple test execution report that includes the list of test cases, execution dates and raised defects, without all the ancillary information in the standard Spira reports. This article provides an example of such a report.
Every test has a User.js file and it is a place to put custom code and functions. This code must follow a few rules.
You can use the Spira Project Backup & Migration Tool to move projects between one instance of SpiraTest and another pretty easily. However there is a known issue that can sometimes occur if you have deleted custom properties.
Customers sometimes ask us for a way to generate a report that would be a human readable requirements document. The built-in requirements detailed report often has more information that is needed in such a report. This article describes how to create such a report.
One of the metrics that customers often find useful is the number of times that a specific incident has been reopened. We plan on adding some built-in dashboard widgets for this metric, but in the meantime, we have a custom report that you can use to report on this metric from Spira.
In Spira we have a nice incident aging graph that you can use to see the count of incidents per aging range. However sometimes customers are looking for more customizable reporting around incident aging data. This article provides some sample custom reports.
A customer asked us this question:
My team is using SpiraTeam 5.4 as a storage vault for all software documents. The documents are placed in a specific project "System" that has been created for this specific purpose.
The documents are placed into several subdirectories: Requirements, Risks, Design., General, etc
Can we generate a report that lists the name of the document, folder, author, and current version.
A customer of ours asked for a custom report / graph for displaying the count of incidents by project and by priority.
Sometimes when you try and run certain reports you may get an strange error message "The passed in report ID or report format ID does not exist". This message is unfortunately a red herring, and there is a different reason for this error.
If you have recently upgraded to Spira v5.x from an earlier version and get an error message saving artifacts that mentions 'XPKTST_ARTIFACT_CUSTOM_PROPERTY' then you may have some old artifact custom property records that are blocking the new item saving
A customer asked us if it was possible to create a version of the requirements traceability report that would not display each of the individual mapped test cases, but instead would give summary counts by priority.
We often get enquiries from customers looking to customize some of the reports in Spira. Although our support does not generally extend to writing such reports for customers (we have consultants and partners who would be happy to do it as a service), in this article we explain a common situation that we get asked about.
The custom reporting functionality in SpiraTest, SpiraPlan and SpiraTeam v5.4 (or later) includes the ability to write complex reports, joining various tables, using SQL aggregation (COUNT, SUM, etc.) functions and other advanced reporting features. A common needs is to display a list of artifacts (requirements, test cases, etc.) and join against the custom property definitions so that you get the custom fields displayed with the names of the value not just the IDs. This articles explains how to do this.
The custom reporting functionality in SpiraTest, SpiraPlan and SpiraTeam v4.1 (or later) includes the ability to write complex reports, joining various tables, using SQL aggregation (COUNT, SUM, etc.) functions and other advanced reporting features. A common needs is to display a list of artifacts (requirements, test cases, etc.) and join against the custom property definitions so that you get the custom fields displayed with the names of the value not just the IDs. This articles explains how to do this.
We had a potential customer that was looking to generate simplified test result reports from SpiraTeam that had more details for each of the executed test steps, with full size screenshots displayed, rather than the small table cells that are in the small reports. This article contains an example of such a report.
If you are trying to run a test case or test set and you receive the following error:
Database constraint violation occurred [APPLICATION.Business.EntityConstraintViolationException]
An error occurred while updating the entries. See the inner exception for details. [System.Data.UpdateException]
Violation of PRIMARY KEY constraint 'XPKTST_ARTIFACT_CUSTOM_PROPERTY'. Cannot insert duplicate key in object 'dbo.TST_ARTIFACT_CUSTOM_PROPERTY'.
The statement has been terminated. [System.Data.SqlClient.SqlException]
Then this article provides the solution for you.
Customers sometimes ask us for a simple Release Notes report that can be used to display the list of new features and enhancements / fixed bugs in a specific release. We use a report like that ourselves to generate the Release Notes for our products (Rapise, SpiraTest, SpiraTeam, etc.). This article describes how you can create a similar report yourself
Our Spira platform (SpiraPlan, SpiraTest, SpiraTeam) has powerful custom reporting capabilities that let you build custom reports using the Microsoft Entity SQL language. This article provides some pointers on writing such reports.
Example of adding support for Java UI control in Rapise.
In the standard reports that come with SpiraTeam, we have the 'Detailed' reports that are designed to include a primary artifact (e.g. requirements) and then include tables that display lists of related items (e.g. Tasks, Incidents, etc.). By default, we only show some of the fields in these tables. This article explains how to display the value of specific custom fields in the tables when you customize the standard reports.
Sometimes you want to create a new custom report with a list of fields from SpiraTest that includes the date that a test cases was executed or the date that a defect was logged, but you don't want to clutter the report with the time part. Alternatively you want to join two tables on a date-time field where only a date comparison is needed.
As part of the v5.0 update to SpiraTest, SpiraPlan and SpiraTeam, we made major changes to the database structure to improve performance and usability as well as lay the foundation for v5.1, v5.2 and v5.3 due out later this year. Customers using custom reports
that relied on the old v4.2 database structure will need to modify their custom reports.
Sometimes you want to get a report of all the test sets with their included test cases along with
their test steps with the tests organized by the order in which they are
displayed in SpiraTest. The custom reporting system in Spira allows you
to create a custom report of all the test cases (by test set) and test steps
sorted by test case order. This articles describes the process for
creating such a report.
(There are different versions of the ESQL query to use based on the version of Spira that you are using)
The new release of SpiraTest, SpiraPlan and SpiraTeam 4.1 includes the ability to write custom reports against various reportable entities. This article provides a list of the available entities:
The build in reports in SpiraTest / SpiraTeam are primarily geared to display the # passes, # fails, etc. from the perspective of test cases. It assumes that even a single fail / block / caution of any of the steps constitutes a failure of the entire test case. However some of our customers were looking for ways to display the execution information at the test step level. This articles describes how to create a simple custom report to display this.
This articles describes the steps to create a custom report that displays a table of test cases with the following fields:
- Test Case ID
- Test Case Name
- Last Execution Date
- Last Execution Status
- Number of Test Runs
A customer asked us the following question: "I run an automated test suite consisting of the same 250 tests every night. I'd like to be able to run a report in the morning that shows me the tests that failed, but had passed the previous night. How can I accomplish this using the reporting mechanism ??"
The web-based custom reporting system in Spira v4.1 (or later) is designed to let you easily change the layout and contents of the various reports (and to create your own reports). It works in a format-agnostic manner, so that the same templates and layouts can be used regardless of whether the final report will be in PDF, HTML, Excel or MS-Word format. However sometimes there is a need to modify the specific template used to generate a specific format (e.g. MS-Word). This article describes the process.
The new release of SpiraTest, SpiraPlan and SpiraTeam 4.0 includes the ability to write custom reports against various reportable entities. This articles provides a list of the available entities:
Using SpiraTest, SpiraPlan or SpiraTeam versions v2.3 - v3.2 you can create custom reports that can be displayed in the Reports tab of the system. This article explains the process for creating such reports. Note that the reporting system is being updated in Spira v4.0 and these instructions will not apply to v4.0 or later versions of the system.
In SpiraTest, when you create a new custom property in the incidents section, they are disabled by default. Unlike other parts of the system, the incident tracker has a customizable workflow. This article describes the steps necessary to enable the new custom properties in the workflow (which will make the custom property enabled).
This articles describes how to write custom reports in SpiraTest, SpiraPlan and SpiraTeam. It also can be used to modify the layout and styling of the various built-in reports.
This information applies to the following versions of Spira: