Quality Assurance at Openbravo

November 16, 2009

The perfect fit

Filed under: openbravo — obqateam @ 2:28 pm

Very often, people is using the term “QA” for grouping so many disciplines that the very concept of Quality Assurance has become something difficult to describe.

In a previous post, we were trying to describe what Quality is. If the concept of Quality is so diffuse, it is not surprising that the discipline that must assure it was also diffuse.

Quality Assurance or Quality Control?

No, we are not going to start a new QA vs QC debate here. We will try just to put some borderline that works with our objectives of improving Quality.

Software Development is a complex process. Generally speaking, you could say that is like if process of building a house started by designing and making plaster panels, cutting down the trees to make the wood you will need, and so on. And, as an industry, it is not mature enough to be fully reliable. Would you buy a car with a sticker in the steering wheel saying:

Enzo Ferrari car

An Enzo Ferrari (source Wikipedia)

ACarForYou ltd. do not represent or warrant to you that:

(a) your use of this car will meet your requirements,
(b) your use of this car will be uninterrupted, timely, secure or free from accidents,

(c) any information obtained by you as a result of your use of this car will be accurate or reliable, and
(d) that defects in the components provided to you as part of this car will be corrected.

However, Software industry makes millions while including a text like that in the EULAs.

A well established discipline in other industries like Quality Assurance is, in Software, a matter of opinion. But there are some basics to work with.

Nowadays, every development task has some kind of inherent quality process. There are spell checkers, autocompletion abilities, and other useful stuff. Even a basic task like compiling will take care of a number of issues.

A well-trained developer is also able to run the code (s)he just wrote to test a kind of flows and check that after fixing the compilation-time errors, the code actually do anything.

We cannot say this tasks do nothing for improving code’s quality, although we will say it is not Quality Assurance nor Quality Control. It is part of Coding Phase. Does it mean that not Quality Assurance exist during Coding Phase? Of course not.

Nice things as Peer Reviews happens while coding. If you see a programmer using Vim for developing Java (get it) code, probably you would suggest switching to Eclipse (get it) or other IDE.

We, as a Quality Assurance department, believe that no specific task adds quality per se. Peer reviews are not suitable for most of the projects. They are expensive since most valuable resources (experienced developers) are the bottleneck. And may be Vim is just what meet developer’s requirements about an IDE, so installing and fine-tuning Eclipse is basically a cool way to waste time.

So, the major goal is to find the perfect fit. A set of processes, tools and disciplines that maximize the quality of the developed code.

Continuing this set of posts we will go deep into some processes, like Black Box Testing (including automation), Unit Testing and User Acceptance Testing.

We will analyze some tools that helps us, like Defect Tracking System, Test Cases Manager and Shared Virtual Machines.

We expect also to cover disciplines such as Agile Development, Professional Testing and Project Management among others.


November 6, 2009

Next steps in Quality Assurance

Filed under: openbravo — obqateam @ 6:17 pm

In Software Development, quality is a must. Every company, from start-ups to market leaders, seek for deliver quality. But the real question is, what quality means?

Quality? What Quality?

According ISO, quality is:

“The totality of features and characteristics of a product or service that bear on its ability to satisfy stated or implied needs”

And it is a very comfortable definition. Only problem is that cannot be used directly to measure the quality level of a working piece of software.

So, some extra work is required. First, I will remove the “or service” part, since I would like to talk about Development.

Business, Process and Product Requirements

For each of us dealing with Software Development, it will sound familiar to say that “stated or implied needs” is an abstract way of naming the Requirements.

So, simplifying the ISO statement, we could say that quality is:

“The totality of features and characteristics of a product or service that bear on its ability to satisfy stated or implied needs Requirements”

Now is crystal clear, isn’t it? (If your answer is ‘yes’, please stop reading this post)

Improvement areas

There are several classifications for the features and characteristic of a product, but I like the ISO 9126:1991 way:

  • Functionality: A set of attributes that bear on the existence of a set of functions and their specified properties. The functions are those that satisfy stated or implied needs. (ISO 9126: 1991, 4.1)
  • Reliability: A set of attributes that bear on the capability of software to maintain its level of performance under stated conditions for a stated period of time. (ISO 9126: 1991, 4.2)
  • Usability: A set of attributes that bear on the effort needed for use, and on the individual assessment of such use, by a stated or implied set of users. (ISO 9126: 1991, 4.3)
  • Efficiency: A set of attributes that bear on the relationship between the level of performance of the software and the amount of resources used, under stated conditions. (ISO 9126: 1991, 4.4)
  • Maintainability: A set of attributes that bear on the effort needed to make specified modifications. (ISO 9126: 1991, 4.5)
  • Portability: A set of attributes that bear on the ability of software to be transferred from one environment to another. (ISO 9126: 1991, 4.6)

What is Quality all about?

Drilling down into the definition of quality until something meaningful happened is far from easy. And the main issue about it is due to the fact that quality is a perception. One single attribute cannot define quality by itself. Deliverance of zero-bug software is a major objective but it cannot be isolated from the rest. A Java function doing nothing will accomplish the goal.

The idea then is to gather as much information from different sources, seeking for a comprehensive list of requirements to fulfill. And, after that, negotiating priorities according Company strategic goals will lead us to the next level.

In next posts we will start the process that (hopefully) will significantly improve current quality level

Create a free website or blog at WordPress.com.