Every single organization needs to acquire or create software pieces. It doesn’t matter if it´s a short integration package or a huge core system, everyone wants software quality. And I mean “want” as a synonym of desire, instead of a real understanding of what software quality truly is.
We can find several misconceptions among IT professionals regarding software quality,
The first inaccurate idea: the software development process will guarantee quality. Well, it certainly can help, but what process are we talking about here? The management framework? The development process? I hear people saying: “Because we use SCRUM we can deliver better quality than a RUP project” Why? Maybe you can deliver products faster than when using RUP, but with the same quality issue (or even worse). Some vendors claim that using CMMI improves quality, and this might be true. But projects tend to cost more than necessary with the additional overhead needed to comply with CMMI practices. Even worse, sometimes an information government process, like ITIL, is perceived as a sufficient way to guarantee software quality.
Another misconception is to think that a specific kind of test performed will assure the desired quality. Well, performing a test is better than not doing any testing at all, but sometimes you end up with a set of scenarios that don’t represent the reality of your operation. If you go to the checklist you can say “We perform unit testing and selenium automated tests, we are following the process” but this doesn’t mean quality has improved per se.
What is then the right way to ensure your product is built with quality? A deep functional and technical understanding of the product to focus your tests in the relevant quality attributes for your context could be a good starting point. Which leads us to the main idea of this article: In this day and age you cannot keep defining the software attributes as “functional” and “non-functional”, because in the last category every single team will define whatever they think it is important without understanding what they are saying: some people will talk about scalability, performance or security but when you ask them about these concepts you will find an incomplete definition of each one.
The recommendation: use a standard definition for software quality attributes, ensure all members in the team, both technical and non-technical, on the side of the client side as well as the development side, understand all concepts and then decide what you need to test. A place to start could be the ISO/IEC 25000 series of standards [1] Particularly the ISO/IEC 25010 taxonomy [2] which finally identify in an explicit way important quality attributes for software products as Learnability, User Interface Aesthetics, Maintainability or Testability. [See Figure 1] In total there are 31 well-defined categories to allow the teams to focus in what really matters in their projects because an application to present a three days music festival schedule (with an expected lifetime of two weeks) will not have the same quality requirements than a mobile banking platform.
Figure 1. ISO/IEC 25010 taxonomy for software quality attributes. [Taken from www.iso25000.com]
Again the biggest problem observed among different projects during the past few years is some sort of technical ignorance about quality attributes. First what they mean, then how to test them. The knowledge of decision makers in projects may come from a university course or some years of experience, but they are not seeing further in topics like security, user experience or maintainability in mobile platforms, leading the projects to poor results after spending a lot of money in non-automated functional testing.
The other big problem is poor knowledge about the business model and, in particular, the company roadmap: What is expected to happen in six months, one year, how will the competition react, what will the market require? This leads to building poor test cases. If your direct contact with the client is not able to identify how many users will use the solution, in exactly which environments (operating systems, browsers, devices, connection bandwidth), the expected information size growth in the upcoming months, the user demographics (age, gender, educational level), at the beginning of a project then you are probably speaking with the wrong people.
Summary
Nowadays, software quality could mean designing and testing solutions based on a well-defined set of quality attributes related to the customer specific needs. The costs of software quality will be associated to the time added to the construction effort to ensure every quality attribute needed is attained.
Quality in software depends on understanding what you need from the beginning, what the software quality attributes are and how to test each one in a fast and repeatable way. This is not going against agile approaches, but it needs experienced team members identifying what is needed and helping the customers make the right decisions.
This is an introduction to a series of articles describing and discussing each group of quality attributes according to ISO/IEC 25010 taxonomy.
References
[1] The ISO/IEC 25000 series of standards.
[2] ISO/IEC 25010
About Perficient Latin America: Perficient Latin America specializes in software development and team augmentation services. With offices in Colombia, Mexico and the US as well as more than 30 years experience focusing on reducing software development projects´ Total Cost of Ownership for North American and Latin American and companies.
