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 different musical taste. 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 geeky (and it’s true we all kind of are at some level), don’t like outdoor activities because they are too nerdy to do them, or they all like Star Wars and Videogames (I don’t like Star Wars but I do like Video games…). Most of the people that aren’t part of the Industry have specific thoughts about us, and sometimes they are right.
I wonder where these clichés came from, where they were generated, and since when do they exist? It seems like 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 with 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 a long time ago; it’s probably no longer valid or basically has never been valid at all:
“DEVs vs QAs,” an Eternal Fight, Forever Enemies.
Let’s stop for a second and ask ourselves, is this the way it needs to be?
I’m 100% sure that the answer is NO. I believe 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 incorrect (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 the relationship at all. Real communication, relationship, and partnership between the Dev and QA teams allow everything to work so much better.
Usually, a very common habit on Software projects is to leave the QA team out of the project’s preliminary stages (Planning, Estimates, and Requirements); this is the first mistake. Usually (though not always), the QA team has a clearer picture of the real scope of affected areas. With new requirements or a simple change in the software, their input becomes incredibly important. If the QA Team is not included in these stages, the planning or estimation process will typically have incorrect outcomes. People assume that the QA time needed for a requirement is 2 days, but often this varies; it might take only half the time, or it could take as the time invested in the development; there are cases when what took 2 days to develop could take almost 5 days to be properly tested.
Another bad practice in these stages is that the QA Team isn’t ready before the code is delivered due to bad communication with the Development team. If test data needs to be created, but the QA doesn’t know it due to a missed 5-minute conversation with the Developer, the whole process is brought down. Again, times may vary, some test data can be created in 5 minutes, some a full week, and that time lost 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 in the project. Every now and then, the Development team doesn’t want the QA team to raise a lot of defects because that would mean they did something wrong. Therefore, the QA team will be in a hurry to get everything out of their hands. If something goes wrong, then it is still in the Dev’s hands. These bad practices only generate unfinished projects, unfulfilled requirements, and late deliveries. At the end of the day, the most affected are the Clients, which is one of the worst things 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 something 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, we must 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 a certain amount of time; in order to accomplish such goal, we have to work together. I’d like to tell you about a time during a project when Dev and QA teams decided to work together:
At the beginning of the project, we were used to not finishing on time. Besides, the quality of the software was never good enough due to a lack of time. This problem continued until one day, we decided to change everything that we were doing since it was obviously not working. Under an agile methodology of 3 weeks releases, both the Dev and QA teams started having planning meetings to give more accurate time estimates. After that, people 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 ready when the code was delivered. We were testing during the development process, and basic defects were fixed before they were officially delivered to the QA environment. When we saw that this was working so well, we continued using this communication and workflow 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. All the major functionalities and UI issues were already detected and fixed during the development. The project was a major success for our client; they were so happy because we accomplished what we promised on the time. Ever since, we all started working as a single team on a daily basis. Our projects went so well in 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 working together.
I’m not saying this can fix all for any project or team, but it proves that clichés can be defeated and then transformed into a strength. You should all try it!
The worst thing that could happen is that you become unstoppable friends…
