Spira Custom Reports

We have just released the new timesheet functionality in SpiraTeam and SpiraPlan v8.5. With this new release, timesheets and time entries are stored in dedicated database tables and then used to update the corresponding artifact totals. This means that you can now report on the time entered per-person, per-day as well as per-artifact. This custom report shows you how to access this new data.

You may need to get the report that groups and aggregates the output results. This article explains how to achieve this using XSLT.

Built-in reports in Spira may not have included Tags column in the grid by default.
This can be easily fixed by cloning standard report and slightly editing it.

The Cost of Quality (CoQ) is about both product quality and process quality. As part of these considerations, quality assurance can focus on additional patterns. In this article, we will discuss how to graphically show the regression test efficiency.

The Cost of Quality (CoQ) is about both product quality and process quality. As part of these considerations, quality assurance can focus on additional patterns. In this article, we will discuss how to graphically show the defect resolution time metric.

The Cost of Quality (CoQ) is about both product quality and process quality. As part of these considerations, quality assurance can focus on additional patterns. In this article, we will discuss how to graphically show the software stability metric.

The Cost of Quality (CoQ) is about both product quality and process quality. As part of these considerations, quality assurance can focus on additional patterns. In this article, we will discuss how to graphically show the test cycle time metrics for test cases.

The Cost of Quality (CoQ) is about both product quality and process quality. As part of these considerations, quality assurance can focus on additional patterns. In this article, we will discuss how to graphically show the defect detection rate.

The Cost of Quality (CoQ) is about both product quality and process quality. As part of these considerations, quality assurance can focus on additional patterns. In this article, we will discuss how to graphically show the test case coverage metric.

The Cost of Quality (CoQ) is about both product quality and process quality. As part of these considerations, quality assurance can focus on additional patterns. In this article, we will discuss how to graphically show the summary of test case reusability.

Existing Release Task progress widget (Product home page -> Development tab) displays the status for top 4 releases.
In case you need to have the full list of the releases and their task progress then custom reporting functionality of Spira will help to deliver that.

For audit or any other purposes, you may need to extract a list of program and project membership report.
This is possible with a custom report (must be using Spira 8.3+).

Please note that this report is to be used in addition to reviewing the list of users who currently are system admins.
Also consider that if there is no active project under the program user is member of - it will not be listed in this report

You may need to create a report of Tasks with their folders. From Spira v8.3 it is now possible to display the name of the folder, just like it can be done for Test Cases and Test Sets 

If you would like to create a custom report that shows list of Pending Test Runs and step counts, follow the steps below (note that you must be on at least Spira v8.3). 

This report will provide very similar information to the Pending Test Run widget on the Product Home Page.

To get a table that summarizes the test run count by status / by build, this article explains how to accomplish this.

For audit or any other purposes, you may need to extract a list of changes to system admin permissions for users. This is possible with a custom report (must be using Spira 8.2+).

Please note that this report is to be used in addition to reviewing the list of users who currently are system admins.

In case you need to get an execution date and time of the test step but keep the standard Test Run detailed report format, the fastest way is to modify the existing one. This article explains how to achieve that.

Several customers have asked for a way to display a grid of all the requirements in a product, showing the test coverage for just a specific release or sprint vs. the whole product. We already have a Requirements Regression Coverage graph that shows this information at summary level, but what if we want to see the individual requirements' names. Luckily, Spira custom reports comes to the rescue!

Entity SQL uses a little different structure than traditional SQL and sometime, it can be that even if the query is working fine in SQL or T-SQL it may throw an error when creating a custom queries in Spira using ESQL. Here are some of the most known errors that may prevent you from getting a successful result.

In case you need to create a report that displays the list of projects in the system in Excel, HTML format this article explains how to achieve that.

The Cost of Quality (CoQ) is about both product quality and process quality. As part of these considerations, quality assurance can focus on additional patterns.  In this article, we will discuss how to graphically show the summary information on these metrics.

You may need answer questions like: who today is able to see the source code in product X, or who can bulk edit requirements. You can do so using custom reports. The example below answers the first of the above questions.

If you need show the list of test sets with their test cases, execution statuses and related builds, follow this article to produce a custom report to do so.

You may need to create a list of test cases associated with a particular incident status to know that those incidents have been fixed and can now be verified by rerunning the tests.

This article explains how to generate a list of the test cases associated with incidents containing this status.

Customers frequently want to review the monthly processing times of requirements across various requirement types in specific Work-in-Progress (WIP) stages like Developed and Tested, categorizing them into four timelines: under 30 days, under 60 days, under 90 days, and above 90 days. This article addresses this request.

The Spira User Interface allows the indenting of requirements to accommodate the hierarchical thought process people envision in structuring the requirements. When these requirements are documented in a report format, the indentation visible in the user interface is missed. Some customers would prefer to see this indentation replicated in the report. This article addresses this requirement.

Often, the project stakeholders want to assess the effectiveness of the team’s development processes to prioritize tasks and allocate resources more efficiently. This request requires a time series analysis of time taken to get things addressed in the development state. Such a request looks at breaking the time taken (t) into various cohorts, such as under 30 days (t<30), falling between 30 and 60 days (30 < t < 60), falling between 60 and 90 (60 < t < 90), and more than 90 (t>90). This article addresses these requests.

Not all tasks are created equal in a project! Some activities may not contribute to the MVP and will be a "nice to have" rather than "must to have." Therefore, the analysis of tasks within a project may also look at the priority types of the tasks. This article addresses this need.

Not all tasks are created equal in a project! Some activities may not contribute to the MVP and will be a "nice to have" rather than "must to have." Therefore, the analysis of tasks within a project may also look at ideas based on the type of tasks. This article addresses this need.

Sometimes, the analysis of tasks may be associated with both known and unknown releases. Simultaneously, analysis may also involve tasks either associated to requirements within a known release or just stand alone without connection to a release. Furthermore, this analysis may be limited only to the tasks in progress or not started at all. This article addresses how to accomplish this request. 

Analyzing tasks is not limited to project releases. Sometimes, tasks may be unassigned to a release further impacting how certain project releases can't even start. So, applying Pareto level (80/20 rule) thoughts can be extended to dig deeper into the tasks. This article helps with this approach.   

One of the frequent activities that is monitored in a plan-driven project is the schedule delays due to tasks. This article helps visualizing the tasks across the iterations to evaluate any task delay patterns that can be addressed.  

As part of ongoing monitoring of risks, one of the the charts that people monitor is called a risk burn down chart. This article helps with creating a risk burn down chart.

You may want to see what product membership for a product was like historically - what users in what role were able to access the product at a specific point in time.

Starting from Spira 7.13 it is possible to track product membership changes and use custom reporting to review this historical data.

A customer wanted to be able to report on the number of times that a defect had been reopened a product. In addition, they wanted to found out how many defects had been reopened 1, 2, or 3 times since being originally created. The Spira custom reporting functionality makes this very easy.

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 a specific status and the audit log of the status changes. That is best done by using the History table and the main Incident table together in a custom report

A customer wanted to get a report of the average test execution duration per test case in the system. Now the test case automatically gets updated with the most recent test execution duration when you run the test case. However, instead of the duration of the most recent run, we want the average of all the runs of the test case. That's where a custom report comes in handy.

A customer asked is how they could run a report to display the number of test cases created per day for a specific date range. You can of course just run the test case summary report and export the data to Excel, but using Spira's custom reporting functionality, you can also do it inside the application.

A customer wanted to get some specific requirements' test coverage reports covering the following two key metrics:

• Number of Test Cases per Requirement
• Number of Test Cases with no mapped requirements (with capability to view specific test cases with no mapped requirements)

You can just run the out of the box test case detailed report and manually filter the data in Excel, but using the power of Spira custom reporting, you can get exactly what you want in a single document.

A customer wanted to get a report of the number of requirements that have changed with mapped test cases that are yet to be updated (with capability to view specific requirements). When a requirement is changed and a test case is not yet changed, the test case has a suspect flag set automatically to True. So, the best way to get this data is to get a report of the number of requirements that are linked to at least one suspect test case.

This article focuses on the last stages of the risk management prior to rejection or closure. This mainly addresses evaluated and open risks. 

As part of the Risk Management Life Cycle, the Risk Evaluation stage reviews unresolved risks for subsequent analysis. There are many types of risk evaluation that can be done but some of the common ones are evaluating by probability and impact assessment done on the risks. This KB article discusses the approach to evaluate the unresolved risks.

The second stage of risk management lifecycle involves analyzing the risks identified. This involves expert judgement or first level subjective analysis to evaluate which risks are worth spending more time on. This article addresses how to report on such an analysis done.

One of the frequent questions that the product or project teams face is knowing the number of risks across the risk breakdown structure.  This risks identified metric not only helps with the team's ability to ensure their commitments are met but also increase the confidence that the product or project team is managing the project effectively. This article addresses how to report this metric.

We had a customer that was looking to display a table of the different test configurations that were tested and looking to display the results of all the test cases in a test set / release by configuration. Ideally they wanted an small inline bar graph as well. Using the custom reporting functionality of Spira, this is possible.

This article explains how to get the most recent comment and add it as a column for an artifact summary report (if it is not already displayed).

When the data for creation date, start date, and end date are good, we can aggregate the data in a graphical format. This article will demonstrate how to write a simple query to show the trends of these lagging metrics.  

When aggregating lead time and cycle time graphically, it is important to ensure correct data is present in the required date fields that mark the appropriate workflow status required for computing the lead time and cycle time metrics. This article explains how to perform some diagnostics before aggregating data in the graphs using the task module.

One of the frequent questions that the Agile Project teams face is computing the cycle and Lead time.  Depending upon the team's practices, this computation may be applied for Requirements, Tasks, or Defects. This article addresses how to create a report for lead time and cycle time based on tasks.

This article describes how to retrieve artifact's associations due to the dependency type that become challenging.

This article provides instructions on creating Custom Graphs for Program Capabilities and Milestones.

Sometimes you may need to get the list of incidents associated with a requirement but that can be challenging in case an implicit association exist.
This article can help you to get these associations.

Import/export tools (including Custom reports ) are limited on row handling, due to performance issues it may cause. To get more than 10000 rows at the time, you will need to do it in batches or filter the report in some logical way.
This article explains how to override that limitation with minimum manual efforts.

One of our customers recently asked about creating a report that brought the test set, test  case, and test step in a specific format to help them with their test planning.  This KB article explains how this can be done.

The build in requirements test coverage metrics include all test cases in a project, not just those in specific statuses. This custom report lets you get the count of requirements and the percentage coverage by test cases in a specific status.

By default Spira displays duration values in hours formatted as 0.00 number. If you wish to format these values as hhh:mm:ss then you need to change the XSLT in a custom report.

If you want to get a report of all the users in the system split by their role per product then this article helps you to achieve that. The custom reporting module in Spira allows you to create a custom report to extract that information.

One of the customers recently asked about including a link as an additional column in the tabular report so that it is easy for the receiver to directly access the link instead of navigating through the system. This article provides the query to accomplish this request as part of their query.

In a series of EVM articles, part 1, part 2, and part 3, we discussed about implementing the earned value management (EVM) lagging indicators. In this article, we will discuss the forecasting metrics.

This is the final extension to the Earned Value Management. The main difference here is that the the task module contains the details of the costs that needs to be aggregated and added to the cost of time at the blended rate. 

This is an extension of the earlier EVM article on implementing schedule metrics alone. In this article, let us explore adding cost metrics, such as the cost variance and the cost performance index, with summarized costs tracked at the release level.

Recently, an attendee in a conference asked me how Spira can support the earned value management (EVM) for project tracking. The question came up as cost is not part of the standard Spira setup. This article addresses this need. 

If you need to report against the artifacts owned by one user, but across multiple products - this article helps you to achieve that. The report example focuses specifically on incident and tasks, but can be changed to include more or different artifacts.

This article describes the steps to do so you can display the Jira ID field in certain reports and on list pages.

Spira currently limits the statuses available for the requirement artifact due to the support the requirement status level automation. One request, despite infrequent, is to address how to accommodate excluding requirements at a release level or reporting on requirements in this 'required but currently unavailable' requirement status. This article addresses this requirement.   

This article shows examples of how to find all artifacts of one type associated to another artifact. For example, getting the list of Requirements associated to a Release, or showing all Risks associated to a Requirement. This mimics what a user may see in the corresponding Associations tab but in a report.

A customer recently asked how to get a list of all risks across all projects within a portfolio. This article explains how to create such a report.

This article explains how to create several different example custom reports for program level artifacts and their associations.

While custom images in custom report headers and footers are not directly supported this article explains a workaround so that you can embed an image or a  logo inside the custom report.

We had a customer ask us how they could find all the test cases that are NOT part of a specific test set. Now there is unfortunately not a way to do it directly in the Spira UI. However that is where the handy custom reporting functionality comes in!

When using the SpiraPlan ODATA API to create custom reports in popular reporting platforms such as PowerBI and/or Tableau, customers have had some common questions. In this article we answer some of the most frequent ones.

This article explains how to generate a simple test execution report that includes the list of test cases, execution dates and raised defects using PowerBI.

If you need to extract comments for artifact, for a period of time or filtered by comment creator - you can easily do that using Custom Report tool or - if you're using SpiraPlan you can use OData or (PowerBI Desktop) to visually create reports and analysis.

A customer recently posted on the forums that they wanted to create a similar graph to the built-in Requirements Summary one using Spira custom graphs and ESQL. In this article we include an example.

This article explains how to create a graph of the number of requirements by status, assigned to any open release in a product, using the custom graphing engine.

In this article we will show how to get an artifact's and product's multi-select custom property values. Report views for artifacts and products contain all custom fields, but for those custom fields that use custom lists, only the ID of the custom list value(s) are shown. Here is what to do if you want to find the text that matches those IDs.

A customer of ours asked for a custom report for displaying the list of  failed Test Cases that do not have any incidents attached or created during testing.

When you run the Test Set Summary Report and filter by a specific test set or a very narrow filter, you will often see the matching test sets and all of the folders in the product. This article explains how you can modify the report to exclude the folders from the output.

Some customers have asked how to create a custom report that lets them trace back from Incidents to Test cases (information about each incident with all the IDs of the test cases associated to that Incident). This is the opposite to Test Case Traceability report.

This article explains the process.

A customer recently asked how to format the date format removing the time component in the custom report. This article address how it can be done.

We had a customer that was looking to add the current document version to the grid of attachments shown in the standard Test Case Detailed report. This article explains how you can easily add this field.

One of our customers asked us how to extract the defects/incidents linked to the blocked test cases in a report. This article shows you how to do this using a simple custom report.

With SpiraPlan, you have the ability to create and manage risks, requirements and test cases in the same system. You can use the Associations feature to link the requirements to risks, and the test coverage feature to link requirements to test cases. However, as part of a risk based testing methodology, you will often want to see which of your test cases have the greatest overall, aggregate associated risk; if you are limited in time, these are the most critical tests to execute. This custom report generates such a view for you quickly and easily.

With SpiraPlan, you have the ability to create and manage both risks and requirements in the same system. You can use the Associations feature to link the requirements to risks. However, as part of a risk based testing methodology, you will often want to see which of your requirements have the greatest overall, aggregate associated risk. This custom report generates such a view for you quickly and easily.

With SpiraPlan, you have the ability to create and manage risks, requirements and test cases in the same system. You can use the Associations feature to link the requirements to risks, and the test coverage feature to link requirements to test cases. However, it is often useful to be able to generate a traceability matrix between test cases and their associated risks. This custom report generates such a table for you quickly and easily.

With SpiraPlan, you have the ability to create and manage both risks and requirements in the same system. You can use the Associations feature to link the requirements to risks. However, it is often useful to be able to generate a traceability matrix between requirements and risks. This custom report generates such a table for you quickly and easily.

A customer once asked how to create a velocity comparison chart for their Scrum Team to measure planned versus actual velocity across the releases. This article addresses how this chart can be created.

A customer recently asked about creating a custom graph based on a set of values in a custom list on an artifact. This article explains how this can be done. 

In one of the training sessions on reporting, a request came up on how data in the XSLT can be sorted similar to ordering results using the ORDER BY clause in ESQL. Both ESQL and XSLT offer its own power which is beyond the scope of this article. But, this article explains a simple way to sort the folders and the tasks in these folders by filtering out the tasks in the root folder and filtering tasks that do not have a name filled in.

A customer had a list of custom properties on the requirement artifact. Some of these custom properties on some requirement had data filled in. When they pulled a report of these requirements, some of these empty custom properties took up much of the report space. So, the customer wondered about reporting only those non-empty custom properties on the artifact. This article explains how this can be achieved.

A customer once asked how to create a list of all test cases that have electronic signature approval recorded.  For example, let us say that you have electronic signature turned on for a specific transition operation in the Test Case. Then, how do we create a list of all the test cases that have electronic signature recorded? 

We had a customer that was looking to use the Custom Reporting feature in Spira to generate a simple use case report that matched their existing template and format. This article shows how you can do this yourself.

A customer asked us if we could provide a report of all the incidents across all projects and programs. In SpiraPlan you already have a Program Incidents list page that shows this information.  However sometimes you want the information in a report format.

Imagine you have a situation where you want to display a requirements test coverage graph for requirements organized by a multi-select custom property. In this article we show how you can use that property to display a custom graph in the Spira reporting dashboard.

A customer wanted to know the way to correctly format their reports so that they would look correctly in HTML and MS-Word in terms of the headings.

We had a customer looking for a consolidated report of the test sets and their test cases, grouped by release and test set folder. The report needed to have the individual test case instances in the test set along with the associated test runs.

Sometimes you will load in data into SpiraTeam using Excel, Google Sheets or other methods where you end up with dates that are invalid, for example tasks that have an end date before their start date! This article explains how you can use a custom report to quickly find them.

Sometimes you will want to get an idea how fast your manual and automated tests are taking. You can use the custom graphing feature to create a custom graph for this.

SpiraTest comes with a built in graph for displaying the requirements' test coverage information. However sometimes you want the raw data and percentages rather than just the graphical form. This KB article shows how you can use the custom reporting functionality to do this.

Sometimes you want to be able to create a Requirements Traceability Matrix (RTM) and include custom properties in the different traced/linked items. You can do some of  this using the standard report and customizing the XSLT template, but for more complex changes, it may be better to use a custom ESQL report.

Some customers have asked us how they can create a program-level requirements traceability report (RTM) in Spira using the custom reporting functionality. This article explains the process.

Spira allows custom property at the test step level. This functionality allows testers additional flexibility. When custom reports are designed, some customers prefer to show the custom property at the test step level. This article discusses how to structure the ESQL query to accommodate this need. 

In our standard requirements traceability report, we display a list of test cases associated with the current requirement. However for parent requirements (Epics) that have child requirements that map to test cases, they are don't display the child requirements' test cases. This article explains how you can modify the report to include them.

A customer posted a question about a sample custom report generated from Spira. In this example we show how we use the custom reporting tools in Spira to generate the release notes of another one of our products Rapise.

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.

We recently needed to get a report of a set of requirements and include the associated tasks and enhancements/bugs related to the new requirements so that we could have a virtual design session. We took the standard Requirements Detailed Report and make some changes. This article provides that report in case you ever need something similar

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.

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:
  • test cases
    • test steps
• For each test step, the linked:
  • attachments
  • incidents

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)

If you want to generate a list of all the test case folders in a product, here is an example template to get you started

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.

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.

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.

Sometimes you create user accounts in SpiraTeam for real users to login and test the system. For example you may have a UAT (user acceptance testing) phase, or a crowdsourced testing event (like our Software Testing Bowl). You then want to turn over the data to a third party supplier, but you need to anonymize the users' personal information

A customer of ours asked for a custom report / graph for displaying the count of incidents by project and by priority.

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.

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 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.

Sometimes you want to get a report of all the users in the system. The custom reporting system in Spira allows you to create a custom report of all the users. This articles describes the process for creating such a report.