In the world and today’s society there are many clichés. I think clichés can be some of the most hurtful things as they prevent us from knowing a new person with different nationality, religion, skin color, or with different musical taste.
How I fought a common cliché in the IT industry
At the end of the day we are just people who do the same things, eat the same things, think the same things, and feel the same things.
In the IT Industry there are some clichés, too. Let me give some examples: IT people are geeks (and it’s true we all kind of are in some level), we don’t like outdoor activities because we are too nerdy to do them, or that everyone likes Star Wars and Videogames (I don’t like Star Wars but I do like Video games…). Most of the people that aren’t in it have specific thoughts about the IT industry. Sometimes they are right.
I wonder where these clichés come from, however; where they were generated and since when do they exist? They have been around for a long time in our society. Maybe one person did all these things and the rest of us were labeled the same way. I don’t have a problem about that, but that’s the whole point of why clichés are so bad for society.
There’s one big cliché around the IT Industry that I think is the one really hurting us, and that may have perhaps been started long time ago. This cliché is probably no longer valid or basically has never been valid at all. “DEVs vs QAs” represents an eternal fight, forever enemies. Let’s stop for a second and ask ourselves, though, is this the way it needs to be?
I’m 100% sure that the answer is, NO. I believe that this all started because some Developer was too proud to accept that his code could have some defects, or because a QA was too proud to accept that whatever he found was not correct (known issue/as intended).
Throughout my 8 years of experience in IT companies, I have come to realize that the best projects are the ones where this cliché doesn’t affect anything at all. A real communication, relationship and partnership between the Dev and QA teams allows everything to work so much better.
Usually, a very common habit in the Software projects is to leave the QA team out from the preliminary stages (Planning, Estimates and Requirements) of the project. This is the first mistake in the project. Usually, just usually not always, the QA team has a clearer picture of the real scope of affected areas. With new requirements or a simple changes in the software, their input becomes incredibly important.
If the QA Team is not included on these stages, typically the planning or the estimation process will have incorrect outcomes. People assume that the QA time needed for a requirement is 2 days, but often the team only needs half or even an equal amount of time as the development team. Sometimes something that is developed in 2 days could take almost 5 days to be properly tested.
Another bad habit in these stages is that the QA Team doesn’t get ready before the code is delivered, due to bad communication with the Development team. If some test data is needed to be created but the QA person doesn’t know due to a missed 5 minute conversation with the Development person, the whole process is brought down. Some test data that can be created in 5 minutes, some also can take a full week to create it, and that lost time can’t be afforded in a software project.
During the development and the testing process, there are also two problems that can cause a big conflict towards the project. Sometimes the Development team doesn’t want the QA team to raise a lot of defects because that means they did something wrong. Therefore, the QA team will be in a hurry to get everything out from their hands. If something goes wrong then, it was still in Dev hands. These bad practices only generate an unfinished project, unfulfilled requirements and late deliveries. At the end of the day, the only affected person is the Client which is the worst thing in this industry.
But, let’s stop talking about all the bad things that happen because complaining isn’t worth it if you don’t do anything about it. What is the solution to this problem and what can we do to improve our Software processes or the relationship between Dev and QA?
First of all, we have to stop thinking we are two separate teams. The Devs need the QAs as the QAs need the Devs. We are a Software team no matter which task we are doing, we have to start thinking that we both have the same goal: deliver a software solution with enough quality to be out in production in certain amount of time. To accomplish that goal we have to work together.
I’d like to tell you about a time during a project when the Dev and QA teams decided to work together. At the beginning of that project we were used to never finishing on time. The quality of the software, due to a lack of time, was never good enough. This problem continued until one day we decided to change everything that we were doing because it was not working. Under an agile methodology of 3 weeks releases, both the Dev and QA teams started to have planning meetings to give time estimates that were more accurate. After that, the people that were going to be involved with the project had to know what the Dev was going to do, so the QA was fully informed. Therefore the QA members could be prepared when the code was delivered to them. During the development process we were doing testing, and basic defects were fixed before it was officially delivered to the QA environment. When we saw that this was working so well, we continued the communication and work flow in all aspects of our work.
The outcome of this exercise was very successful with 95% of the code tested and delivered 5 days before the release. During the development all the major functionalities and UI issues were already detected and fixed. The project was a major success for our client. They were so happy because we accomplish what we promise on the time. From that time onwards we all started working as a single team on a daily basis. Our projects went so well on the upcoming months that we never failed to miss a delivery date. The only small change we made was to have the Dev and QA teams work together.
I’m not saying that is a fix all for any project or team, but it proves that clichés can be defeated and then converted into a strength. You should all try it!
The worst thing that could happen is that you become unstoppable friends…