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), doesn’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 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 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, 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 had 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 on IT companies, I have come to realize that the best projects are the ones where this cliché doesn’t affect the relationship 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 on Software projects is to leave the QA team out of the preliminary stages (Planning, Estimates and Requirements) of the project; this is the first mistake in the project. 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 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 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 on 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 towards 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 hands. These bad practices only generate unfinished projects, unfulfilled requirements and late deliveries. At the end of the day, those who result most affected are the Clients and that 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 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 on 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 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. During the development process we were 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 using this communication and workflow in all aspects of our work.
The outcome of this exercise was very successful, with a 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 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 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 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…