The importance of Quality Assurance roles

I’ve been working for several years now as a Quality Assurance Analyst (Also doing some Automation work) for big companies (Like Accenture, Hewlett-Packard and MercadoLibre) and I’ve learned a lot in the process. I’ve worked in places where the QA was seen as a key role in the SDLC and some other places where we didn’t even existed at all. Really, like, there was no QA Analysts. This is common ground for some Start ups trying to making it in the industry and cutting off expenses, where the developer is his own Business Analyst, Tester and even Designer is some cases.

Why is that a thing? Can that work? Well, the answer is yes.
I’ve seen many projects and apps running without a QA. Devs doing all the heavy work, even in some disbelief of what value a tester could bring to the table. So how does that work? This is an example of what I’ve seen:
When the planning meeting is held (In the case you’re working with SCRUM):

  • Usually when the Business Analyst role doesn’t exist, there are no user stories. Just titles like “Migration of Database” or “Gallery Carousel front”.
    - Acceptance Criteria doesn’t exist either, so the ending of the feature is measured by the Dev’s common sense and knowledge.
    - The work begins and Developers struggle between moving forward with development and spending time testing and re-testing what they’ve been working on.
    - Usually the code is placed in GIT or other repository so in the best case scenario they have some unit tests covering some percentage of the code running on the CI and the next step is usually to ask a coworker to perform some smoke testing on the feature alone. (While the coworker is also struggling between his own code and tests).
    In result, some deploys would be successful, with non-critical or zero bugs and everyone would be happy, or, if that isn’t the case, they’ll be forced to perform partial or total rollback on the changes they just deployed. This is the “Headless chicken” stage where devs and leads are running against the clock to solve the issue. Then there’s the retro. Then peace, quiet. Then, another planning meeting.
    And the cycle repeats itself.

I mean… being totally honest this could happen also with a QA Analyst in the team. We are humans too, right? We make mistakes, we could’ve overlooked some major bug, some important test that was not contemplated in any test case scenario, BUT, in my experience, is different when you have a person, or two, or a whole team fully dedicated to the task of achieving and maintaining a certain level of quality to the product. This is what we do. What we think, what we analyze and what we breathe all day. We are constantly thinking how to break the code before the clients breaks it on purpose (or unintentionally).
This doesn’t mean that devs should not perform their own testing. It’s important to clear out of the way some of the most common and foreseeable bugs, like the character length on a text input or the characters allowed in an email syntax. We don’t want those close encounters of the third kind…

Although there’s always been some kind of dislike or competition between Devs and QAs, — Dog and Cats kinda tale — in the end we are all trying to do the same: Deliver what was asked for, in the best possible way. And we are here not only to point out what needs to be changed or corrected, but also to take some load off in planification, execution, tracking, reporting and more importantly, time.

In summary, more tests implies less rework, happier and trustful clients, devs focused mainly on the development and on the long run a lot of money saved for the company.