Creating Bug Trends Reports in Targetprocess | Defect Trend Charts

Bug Trends and Dynamics

The Bug Trends (or Defect Trends, Bug Dynamics) report in Software Testing calculates total number of bugs that the QA team has opened and closed over time. The reports are important for management to understand the overall trend at which the bugs are processed. Moreover the report may help to check whether bug discovery and resolution rates are declining toward the end of the iteration as expected.

The totals are based on the per intervals of time (such as daily, weekly, monthly), per QA Build or per time-based work scope (Release, Iteration, Sprint).

Visual Reports for Bug Trends and Dynamics in Targetprocess help you to create visual representation of Bug Trends.

Bug Trends and Dynamics. Image 1

Moreover list of bugs used as data source may be filtered (such as per Project, per Feature, per Owner or Assignment, per Tag etc.) and split into categories. As a result multiple separate trends per each category can be presented in the same report or dashboard.

Sparkline charts is one more tool for tracking Bug Dynamics briefly. The charts can be added to Project card and Team cards on your views, and provide you with bird's eye overview only number of new and closed bugs within the Project or Team during last 16 weeks.

Bug Trends and Dynamics. Image 2

Visual Reports for Bug Trends and Dynamics

To create any report described below, start with + Create > Report action in the left menu.

Visual Reports for Bug Trends and Dynamics

Create Report from Template

There are predefined Templates for Visual Reports available. In QA section, two of them named New Bugs Trend and Closed Bugs Trend help to create Bug Trends reports just in few clicks.

Create Report from Template

Here is how predefined Closed Bugs Trend report is configured:

Bug Trends and Dynamics. Image 5

Configure Report Manually

On Setup tab it is possible to configure similar report manually:

NameClosed Bugs Trend
Projects and teamsMark with checkboxes projects and teams for which Bug Trends should be displayed in the report
FilterApply an Advanced Filter to Bugs. For instance, for Closed Bugs Trend only closed bugs should be filtered. In the default template we filter bugs closed within last 182 days only.
?EndDate >= Today - 182(days)
X axisIn the default template we group closed Bugs per week:
WEEK(End Date)
Y axis In the default template we display count of closed Bugs per Project:
Count of Records, Project
Chart typeLine chart

Bug Trends and Dynamics. Image 5

Press Finish setup button in the header area. The report appears in the left menu.

Configure Advanced Reports

The reports can be easily customized. Press Set up Report button for this purpose.

We recommend to add Trendline to your report.

Settings for Open Bug Trends and Closed Bug Trends

Settings for Open Bug Trends and Closed Bug Trends are not the same. Here are the differences between them:

Open Bug TrendsClosed Bug Trends
Filter?CreateDate >= Today - 182(days)?EndDate >= Today - 182(days)
X axisCreate DateEnd Date


Bug Dynamics reports are based on Create Date and End Date fields. Create Date field is filled in with timestamp of the current moment whenever a new Bug is created. End Date field is filled in with timestamp of the current moment when a Bug is moved to its final workflow state.

On X axis it is possible to apply grouping by Day, Week, Month, Quarter, Year.

Alternatively, on X axis it is possible to calculate totals per QA Build or per time-based work scope (Release, Iteration, Sprint) instead of dates.

Open Bugs Trend per Build

Filter?Build is not None and Build.BuildDate >= Today - 182(days)
X axisBuild
X axis SortAscending, by Create Date

Settings for Open Bug Trends and Closed Bug Trends

Bug Trends and Dynamics. Image 8

Closed Bugs Trend per Release

Filter?EndDate is not None and Release.StartDate >= Today-182(days)
X axisRelease
X axis SortAscending, by Release Start Date

Bug Trends and Dynamics. Image 9

Bug Trends and Dynamics. Image 10

Closed Bug Trends distribution

Data in the report can be distributed by categories. For example, let's create multi-color stacked chart for Bug Trends by Severity. For this purpose put Severity field to the Color selector:

Closed Bug Trends distribution

As a result in the report closed bugs with different severities become shown with different colors. Legend with explanation is also displayed:

Bug Trends and Dynamics. Image 12

Open and Closed Bug Trends on the same chart

It is possible. Here are examples how the report can be configured:

Filter?CreateDate >= Today - 182(days) or EndDate >= Today - 182(days)
X axisWe could use default Create Date and End Date fields here, but it will result in quite long trend for bugs created in the past. We are not interested in the past part of the trend because we are interested in last 182 days only. To improve our chart let's trim the tail and count all bugs created earlier than 182 days ago together.

We'll create custom formula TrimmedCreateDate and put it to the axis together with End Date field, grouped by week:

WEEK(End Date)

Here is how custom formula TrimmedCreateDate is configured:
IIF(CreateDate >= TODAY - 182 days, CreateDate, TODAY - 183 days)

Y axisCount of Records

Here is how the report looks in Line chart mode:

Open and Closed Bug Trends on the same chart

Same chart can be also displayed in Stacked Bar mode:

Bug Trends and Dynamics. Image 14

Data in the report can be distributed by categories. For example, let's create line chart for Bug Trends by Severity. For this purpose put Severity field to the Y axis together with Count of Records field:

Bug Trends and Dynamics. Image 15

Sparklines on Cards

In the non-project management world, sparkline graphs work as quick time-span mini-reports featuring the dynamics of certain states or activities. The sparkline graphs usually look like tiny ragged lines.

Sparkline charts can be added to Project card and Team card within Customize Cards feature.

Bug Trends and Dynamics. Image 2

Here's the logic behind the sparklines for user stories and bugs:

Any sparkline covers a time span of 16 weeks. Why 16 weeks? It's convenient in terms of iterations and releases, as in agile project management iterations usually take 2 weeks. So, this stands for ~ 8 most recent iterations. If you count each tiny sub-bar, this would total to 16 (in the sparkline for Designers and Philadelphia Flyers teams. The Support team has less than 16 weeks history, most likely). The 16 weeks time-span seems to be working well for iterationless development, too, as in Kanban.

The zero line is the vague blue line in the middle (or, the red one, for bugs).

The actual numbers shown on the top and on the bottom represent the max. number of user stories done or added, respectively, at any given week out of those 16. If you see the max. number, for a week that goes shortly after the 4th week, then you get an idea of how many user stories have been done in the previous or in the following weeks. There's no need to show the numbers for each week, as it would make this tiny graph too clogged. The same logic stands true for bugs.

The numbers on the very right, in the sparkline, relate to the current week.

The "total" numbers show how many user stories were done in those 16 weeks (on the top) and how many were added (at the bottom). Sames for bugs: the total fixed number is on the top, and the total added — at the bottom.

If you're a stakeholder, or a Scrum Master, or VP of Development, or anyone who wants to keep an eye on how those several teams are doing, this report is indispensable. With the least time spent, you get the maximum info. And - yes - there's no recency bias. You are able to embrace the whole span of 16 weeks in that little space.

Finally, this logic is condensed to a mouse-over text tooltip.

Interpreting the Reports

The team might find bugs especially quickly in poorly written code, in newly integrated code, with improved testing, or during an exceptional event. On the other hand, bugs are more difficult to find in a high quality product and with ineffective testing.

When the team resolves bugs faster than it finds them, the number of active bugs will start to decrease. When the team starts to find fewer bugs, the product is stabilizing.

The reports and sparklines are not only about the counts of bugs and user stories. For example, if you see that your sparkline for user stories is keeping low, close to zero, and your bug numbers are pulsating with action, this means that this team is currently working to make the release stable (most probably).

Still have a question?

We're here to help! Just contact our friendly support team

Email us
The more details you can give us the better
Live chat
Prefer instant messaging? Try our live chat
Service Desk
Add tickets, comments and track status in our Helpdesk
Slack Community
Shape the future direction of Targetprocess

Find out more about our APIs, Plugins, Mashups and custom extensions. Join our community of passionate users and even discuss directly with our developers.

Start your free trial

Enter your email
By clicking "Continue", you acknowledge and agree that we will process your personal data in accordance with our Service Privacy Policy and Terms of Service.

We’ve sent you a confirmation e-mail — please, go check it.

Or get a live
product demo