Getting started with a new report
Before starting a new report it is assumed that Quality-time has been deployed properly. Follow these instructions for the deployment: https://quality-time.readthedocs.io/en/latest/deployment.html
An effective dashboard is more than a collection of charts and metrics — it is a carefully structured interface that directs attention to what matters most. Poorly designed dashboards often overwhelm users with excessive detail or visual clutter, making it difficult to locate relevant information or distinguish signal from noise. In contrast, the philosophy behind Quality-time is to focus attention on actionable, meaningful insights. By structuring dashboards around well-defined subjects, prioritising non-functional requirements, and clearly highlighting deviations that require attention, teams can ensure the dashboard becomes a reliable tool for decision-making rather than a passive collection of data. A well-designed dashboard enables development teams and stakeholders to respond quickly, stay aligned on quality goals, and maintain control over software health.
Per installation of Quality-time there is one main screen that can contain several reports (dashboards). The top-level report also shows donut charts. These charts collect data from all underlying reports.
The below image depicts how information is collected from individual reports to the top level report. The top level report can be seen as a summary of all underlying reports in this Quality-time instance.
!
Teams are free to create multiple reports for various reasons. One could create a report for the front end and one for the back end software, for instance. However, it is advised to create a report based on responsibility. If one team is responsible for the quality of both the front end and the back end software, a single report makes it easier for this team to focus their attention on the right priorities.
Quality-time is designed to present a high-level overview of the overall software quality and quality care, while also enabling users to progressively explore potential areas of concern. This drill-down functionality is organised across three main levels.
The top level consists of donut charts, offering a visual summary of the software’s quality and state of the quality care.
!
At the second level, users can review individual metrics to identify which specific aspects may require further attention.
!
The third level provides detailed information on the entities that contribute to a given metric, available under the “entities” tab.
!
From this point, users can investigate the root cause of an issue in greater depth by following the provided source link to the relevant artefact or external system.
Once a new Quality-time report has been created, the following steps are recommended to ensure effective configuration and alignment with the development context.
Choosing a good structure for the report
Understand the application that is being developed, including its technology stack, and determine how to structure the Quality-time report accordingly.
- Does the application include a front-end, back-end, or both?
- Which subjects are relevant given the application’s architecture and development approach?
know the application that is being developed and its stack and decide on how to organise the Quality-time report (what subjects) does the application have a front end or just a back end know the application that is being developed and its stack and decide on how to organise the Quality-time report (what subjects)
https://quality-time.readthedocs.io/en/latest/reference.html#subjects
Each subject should be configured with appropriate metrics. There are two approaches:
- Include all available metrics (recommended for full coverage).
- Select a subset of metrics relevant to the team’s focus.
See: Using the missing metrics metric
Step 2a: Create a Quality Report subject and install the missing metrics metric and configure it based on the team's input regarding the stack and scanning tools in the pipeline
Step 2b: Create the subject
-
Determine which non-functional requirements (e.g. performance, security, maintainability) are most important to monitor.
-
Consider which metrics or visualisations will be most useful when the report is shared with stakeholders, such as management, particularly in exported form.
A Quality-time report can be both a dynamic, near realtime report and a printed, static report. To serve both managing roles and developing roles, it is recommended to optimise the layout of a report and rearrange the content.
- set the subjects in order of priority
- for each subject, change the order of the metrics based on priority
- set report title, subtitle and comment
- set subject title, subtitle and comment for all subjects
- rearrange donut charts
tags can be used for multiple purposes reporting → non-functional requirements and as a short cut
Refer to the official documentation for instructions on configuring notifications:
Define with the team how quickly alerts should be acted upon:
Review all metrics that are not purely informative (i.e. those not marked in blue). In collaboration with the development team:
-
Determine the threshold at which a metric should trigger a warning (yellow).
-
Identify the values that should be considered critical (red).
==TODO== use the graphical example for this to understand what the metric will do