May 11, 2015

Quality Assurance Should be “Everybody’s Job”

BY :     May 11, 2015

Quality is everyone's jobIn every testing course or lecture, we are told that quality assurance is not the same as testing, and that quality must be built from the beginning and not tested at the end. And, also, that assuring quality is everyone’s job. This sounds perfect theoretically, but is really difficult to put into practice.

An example from my own experience

Recently, I had to test an application. It wasn’t completely new, but an old one migrated to a new technology with a new database model (which implied a data migration). My team wasn’t involved in the project from the start. When we took part, the application was already in the Pre-production stage for us to test. So, we faced a lot of problems in doing that, because there was no documentation about how the program worked and how they had to migrate the data. It was because the business analyst had trusted the development team analyst to do the job, but this person had left the project in the middle of it, to some of the developers. The new team worked in its own way and did the best they could, given the situation; however, their best wasn’t the right approach. Some functionalities were misunderstood, the application didn’t do what it was supposed to and the data weren’t properly migrated. Though we expected the business analyst would take matters in his own hands, we were surprised that he didn’t. So, it was we, the testing team, who became some kind of ‘quality leaders’ and did our best to make sure the migration was done correctly and that the application worked as the user expected it.

But our best effort wasn’t good enough and resulted in a small disaster when the application was given to the final users, as we didn’t have the time to test it properly and completely. This not only led to the appearance of defects in the Production stage, tarnishing the public image of the company to some extent, but also resulted in the frustration of everyone involved in the development of the application.

So, what was the problem here? The client and the development team got ‘Quality Control’ and ‘Quality Assurance’ mixed up. Why do they have to think about quality if they can do things the way they want, considering that there would be someone at the end of the chain to find what is wrong and would tell them to correct it? Why do they have to bother to assure quality if someone will control it eventually?

I’m sure it has happened to you as well and that you also have the feeling that users, analysts and developers think that we, the testers, are the ones responsible for the quality of a project. It’s true that we are responsible for quality, but we are not the only ones. Everyone involved in a software project should be responsible for it and all of us should work together to assure quality, doing things right from the beginning. Quality can only be achieved if everybody cares about achieving it.

It is easy to say how everything should work, but it will be very difficult to fulfill it, since it requires a change in mindset. We know for sure that, when someone has been working in a way for a long time, it is really difficult to make him/her change. So, it should be our duty as testers to facilitate this process and try to have everyone involved in quality from the beginning of the project until the end of it. This way we can avoid difficult and frustrating situations and can have a better work environment.

Paloma Rodríguez

About

Paloma Rodriguez has been Test Engineer for Sogeti Group since 2011. In this role, she manages testing projects and participates in various publications and training activities.

More on Paloma Rodríguez.

Related Posts

Your email address will not be published. Required fields are marked *

1 + 8 =


  1. Tim Western · May 16, 2015 Reply

    While I agree, that quality should be the responsibility of everyone from the managers, devs, technical writers, analysts, and testers, I disagree with the entire Assurance meme. We can’t assure anything, people who say that are trying to apply industrial memes and methods to a product that is always unpredictable, never exactly the same as last time (because each customer is unique), and let’s be honest, that most teams that separate development and testing into silos on products like this, where they are brought in N sprints late, are not only behind the quality curve, they are more behind than teams that have testers and other analysts involved for the duration of the product. Assurance of quality of software, is not a reasonable thing to expect from such an abstract industry. However, that doesn’t mean we shouldn’t be concerned about improving quality throughout the process, rather than waiting to ‘test it in at the end.’

    • Paloma Rodríguez · May 18, 2015 Reply

      Evidently, it is impossible to assure quality. We can do our best, but we can never be sure that it’s not going to fail. But that doesn’t mean that we don’t have to work for it and that we don’t have to try to achieve the highest quality in the software product we are building together. And that is what I tried to explain in this post: everyone involved in the development of an application should be involved in quality, so that be can have the best product fom the beginning. Although this doesn’t mean that the product is perfect.

*Opinions expressed on this blog reflect the writer’s views and not the position of the Sogeti Group