With the increasing success of cloud deployment and SaaS business models software has replaced many companies.  Today’s largest bookseller is not Borders, its Amazon, a software company. Netflix, a software company, left BlockBuster in the dust.

Software Quality is still a problem

As software usage becomes more mission critical in almost every aspect of life, understanding and thus improving software quality also becomes critical. These days, agile methodologies have worked toward integrating QA with development rather than having QA as an afterthought through test driven development combined with scrum methodologies to form time-boxes for short iterations resulting in working prototypes very early in the development cycle. And as development cycles shorten, better testing techniques and test design with better tools for performance testing, automated testing, etc. have come forth.  Structured testing has made significant strides in processes, methods and techniques, (i.e. TMAP, TPI, etc…). However, from the QA perspective, we are still mostly focusing on development and testing methodologies and working to integrate them to be better and more efficient.  But before jumping in to getting better at development and testing, our end goal needs a closer look.

Defining Quality

The problem with quality is that it is an abstract concept and cannot be measured easily. It’s presence is difficult to define and see, yet it’s easy to point out its absence. So before finding the solution, whether complex or simple, let’s examine what quality is.  Many have put for their definitions of what quality is:

  • ISO 25010: the degree to which the system satisfies the stated and implied needs of its various stakeholders, and thus provides value.
  • Roland Petrasch: the existence of characteristics of a product which can be assigned to requirements.
  • Roger Pressman: conformance to explicitly stated functional and performance requirements, explicitly documented development standards, and implicit characteristics.

There are numerous other definitions, but they all reference the satisfaction of requirements or conformance to requirements in some way. So when defining quality it is important to first understand requirements and to distinguish between functional and non-functional requirements.  Put simply, functional requirements are what the system is supposed to do, such as retrieve a file, or complete a query.  If a customer complains about quality, yet if all the requirements were completed, then does that mean bad quality? Requirements can be fully satisfied and the result can still be ‘bad’ quality, at least from the perspective of the end user.

This leads us to non-functional requirements which refer to how ‘well’ the functions are accomplished. ‘Well’ is rather ambiguous and dependent on the eyes of the beholder or end user. This leads us to concept of modeling quality, in order to understand it and then evaluate it in a quantifiable way.

At XBOSoft, we believe that quality is in the eyes of the end user. Given that, quality encompasses much more than satisfying requirements, but requires a holistic approach to evaluate it. And with evaluation, we can then improve. I’ll continue blogging on defining and measuring quality in the coming weeks.

The forthcoming blogs by our staff members will be discussing different experiences and tips that we’ve come across through the years in working with our clients in helping them improve their software quality. Feel free to drop them a line and comment, or give us ideas on what you’d like to hear about.