Skip to main content

What is Software Quality?

What is software quality?



“Why do we never have the time to do it right the first time, but always have time to do it over and over after the first time?” – Anonymous 


Quality is something that happens at every stage of Software Development!


When I talk about Software Quality, almost everyone in the Information Technology world thinks about “Software Testing”. Unfortunately, this is a myopic view of Quality as a specific team effort and not as something, that should be embedded and part of the complete Software Development Life Cycle!

Quality can be defined and need not be an “ambiguous term” for an organization.

For any software, quality is more aptly seen from a view of what the customers considers as ‘Quality’. Although, this is not the only way to consider ‘Quality’.

Quality must be seen from the viewpoint of ALL stakeholders involved with the product. Apart from this, ‘Quality’ should be considered as everybody’s responsibility. From an operational standpoint, we do consider “Quality / Testing Teams” to take ownership. Although, testing teams can be made more relevant and productive, if the organization culture promotes a very high-degree of collaboration between the Quality / Testing Team and all the other teams involved in developing the product or providing services.

Quality can be defined with two perspectives –

1. Quantitatively: A quantitative representation of software quality is very easy and directly refers to using metrics (or “measurements”), such as – “If ALL the customer requirements are met, we have achieved quality” . Here, the underlying assumption is, that the software development team (includes all sub-teams) have documented each and every stated or unstated customer requirements as part of a requirements management document / software.

2. Qualitatively: A qualitative representation of software quality is very complex and directly refers to understanding the “perspectives” of various stakeholders (i.e. customers, business analysts, sales team etc…). For example, “If the ‘Product Usability’ is very high, the product shall be of very high-quality” . This may be true, for products with few but very important features! Some of these can be measured, although these are still subjective, such as by understanding the “Customer Satisfaction Scores”, “Customer Usability Exercises”, “UAT Feedback” etc…

 

It is very important for every product / project stakeholder to understand the above perspective. Only such an understanding can promote a healthy organization culture amongst various teams to work together and come up with revolutionary software products, that can change this world.

- Written by Anand Nanavati (SupraDigit Solutions)

Comments

Popular posts from this blog

The Top 4-Ways to Build the Right Test Strategy

A Test Strategy is created to guide all teams on steps to achieve software quality objectives. With software companies adopting agile practices in a big way, an effective Test Strategy becomes even more important with iterative / sprint-based application development. A test strategy being a live document, should ideally plan to integrate the business, development, testing, and management teams, define the quality objectives for the intended application and chart-out a path on how all the teams can help achieve these. The test owner and the team can build an effective test strategy with these 4 best-practices: A)   Focus on Prevention – Helps avoid major issues and rework on projects. ü Prioritize requirements and business rules. ü   Communicate changes in priorities immediately and effectively to important project stakeholders. ü Strictly review and implement common require

Reduce Your App Development Costs by More than 50% by "Simply Preventing Bugs"!

"Be a yardstick of quality. Some people aren’t used to an environment where excellence is expected.”— Steve Jobs Everybody loves to avoid a disaster, but there is a “proactive” effort to do activities that can prevent a disaster from happening. Most of the executives do not want to “get involved” in such “proactive” efforts, simply due to the love of fixing urgencies Or having a mindset that it’s not important.   I remember, when once I was working with the Quality Assurance team on a product. The development team simply refused to spend efforts on the most essential “unit testing” for their developed components! The intent was to release the software to the QA team as soon as possible and focus more on so-called “core development”. Over the years, looking at multitude of projects failing in-spite of highly experienced resources, reasonable time and the intent, I have uncovered that, prevention is the “Most Important” and “Ignored” part of software development. Why should we