English | EN Quality Assurance Should be u0026quot;Everybodyu0026#x27;s Jobu0026quot;
May 11, 2015
In 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.
About the author
