If you are a Software Project Manager, you already know the fatigue of going through details of multiple sources of data to come up with a unified view of how the project status looks like, to share it with your stakeholders. An important component of project status is Product Quality. As far as the product development ops. are concerned, the Product Quality is usually assessed by the defects. In this blog, let’s look at how defects play a role in Product Quality, and how, you, as a Project Manager would like to comprehend the impact of those defects on your product quality, and do effective Test Reporting.
For many years now, quantitative measures are considered important in assessing product quality. The rationale behind this approach is that businesses need numbers to estimate the work involved so that decisions can be made in terms of schedule, workforce required, and infrastructure. Unfortunately, as far as software defects are concerned, although numbers are indicative to an extent on the quality of the areas of product, most of the times, the numbers tend to get ‘bundled’ and has a negative effect on effective decision making.
Dashboards today are mostly bar charts, pie charts, and such, to indicate the areas that contribute to the defects distribution. But this approach does not really help pinpoint where exactly the issues are, because the areas by themselves could be complex. In a complex scenario with Software Supply Chain with lots of dependencies and distributed architecture, you could imagine how difficult it is to figure out where the issues are so that appropriate action can be taken.
Architectural diagrams and design diagrams are being frowned upon by code-centric software practitioners saying that they are a waste of time. I can understand lengthy word documents of specifications, but how can a detailed architectural diagram or a design diagram be counter-productive to efficient software development? The other reason that is quoted that the specifications or requirements keep changing, so we cannot have an architecture diagram. This could be true in some scenarios like front-end apps where there would be a lot of changes in the front-end because of changing customer preferences or when the product team is not able to exactly nail down what the end-users want and might resort to experimenting. But in general, in most of the cases, a tentative design or an architecture is required as a blueprint to start the work.
My intent behind bringing up architecture diagrams and designs is that they are excellent visualization tools of the current state of the product. There are tools available in the market which can be put in pipeline and can be changed as there are changes in customer expectations. When we have such tools, it would be a great idea to integrate defects distributions too in these diagrams so that the team can look at the defect density of each of the features, modules, and interfaces!
Imagine how easier it would be to state that there are five defects in the interface between Module A and Module B, rather than saying there are thirty defects in Module A and forty-five defects in Module B. The latter does not give any clue about where exactly these defects are in Module A and Module B and what action needs to be taken by management to address these issues. The former, in contrast, will clearly indicate visually where the problems are, so that the right amount of workforce and infrastructure can be allocated for those defects and schedule can be managed effectively too!
I look forward to see such integrations between test reporting via architectural diagrams (if they don’t exist already), which will make the team’s efforts efficient and effective!
For Project Management aspects related to Testing and Test Reporting, feel free to contact me.