The modern QA: the Cinderella syndrome
Ranting about how we've twisted the Quality Assurance job description until it's become impossible to fulfill (well).
PSA: The situation depicted in this text holds true for most of the european tech landscape, and is specially true for late-stage startups. I am well aware that the QA role is evolving differently in big-tech-and-close-friends, but this post is just not about it.
Most of my time as an individual contributor, I spent it doing QA. It’s always been my favourite position in the team because it let’s you try all the jobs in the restaurant kitchen: siding with the Product peer, contributing across the stack, being consistently exposed to the coding practices of talented engineers, participating in rollouts, owning the business domain and model, impersonating the customer and working really close to their feedback. I’ve always felt a good QA has a say in everything, and an endless learning path. It’s the gift that keeps on giving. And as a cherry on top, because you don’t need to be a particularly stellar developer to implement a test suite, you can jump from stack to stack, never marry a technology and stay safe from framework cults.
However, quality -like good infrastructure, marketing budgets or workers’ rights- is one of the pillars that become less than an afterthought when profit shrinks or VCs stop picking up the phone. Struggling companies tend to get nervous and they try to impress the market with a constant drip of new features. Time to market and new contracts is everything that matters, and actually operating those features is a problem for tomorrow (or the next quater report).
Something similar happens with new-born companies: they don’t even know if the audience is going to like or understand the product, so investing money in its ability to work well, sustain traffic or comply with laws is a luxury.
And precisely in these companies, is where I see a setup that inevitably precedes what I call The Cinderella Syndrome:
The company invests less money in salaries, so they don’t get the best talent in the market (this is code for engineers that don’t know how to, or don’t want to test)
The pressure to launch makes up for features that are designed, coded and pushed in a hurry, and rapidly growing, obscure codebases, no time for documentation
High churn in the team means many hands stirring the soup, low domain knowledge
They see QA as a job, not an activity. So it doesn’t happen if there’s no QA peer on board.
And then comes the Cinderella job posting:
Innovative, industry leader company is seeking a Quality Assurance Engineer. Their main responsabilities will be:
Automating our test suite
Surprise: there’s two years worth of features in production, and zero tests coded. They will expect you acquire functional knowledge, identify what to test, start a test suite and catch up with the product ASAP while you test and ship code for the newly pushed features, week by week.
Perform manual acceptance tests
Because the job of the PO ends up in the refinement, you’ll have to make sure the coded features resemble whatever was in their minds, and sign it off
Champion and implement quality assurance amongst the software engineers
To this day, the manager hasn’t been able to hire people who actually test what they develop or consider quality as part of their job. So now they are pushing this responsibility to you, hoping you will teach them, coach them, watch them, and enforce a test coverage % that feels fit for an audit -in your spare time. Furthermore, they want you to lead everyone to a place they don’t want to go, without formal authority -and for the record, don’t you dare seeking formal authority as an engineering manager with a QA background: you’ll be underestimated, since you lack the pedigree of a true developer
Perform compliance, accessibility, and localization testing (I promise you, this week I’ve seen openings for QA’s with strong Japanese, German and other languages, plus English, based in Spain)
We’ve revoked our localization tool license and fired our legal and UX team, so now we expect you to be a catchall for everything and spare us a lawsuit.
Requirements: proficient in Java, React, K8s, Swagger, AWS in general, Mocha, Jira and the W3C guidelines (I swear I’ve seen this one today).
We don’t know what a QA engineer actually does, so here’s the comprehensive list of everything we use. We won’t have time to teach you, so we expect you to just land and figure everything out on day 2.
Extra ball: strong knowledge of BDD tools and Gherkin
Someone sold us this fantastic tool that would allow us to have automated acceptance tests, just by having the PO write them in natural language. We later found out these tools actually require 3 layers of coding/abstractions, the PO is too busy to download an IDE, and the test suite was abandoned after some developer spent two days writing login test scenarios that no one ever executes.
To summarize it, this close-fisted approach to QA as a tax has driven companies to repicture the quality engineer as a manager, a full-stack engineer, a manual tester and a subject matter expert, all in one person and very often in a context of unmanageable tech debt and lack of quality culture. If you’re a fellow QA and you’ve been there, you know it’s impossible to perform well.
But even worst than the hypocrisy of having you handle that workload, is the fact that with this twisting of the job description, we’ve also reframed the actual personality of the engineer in question. You need to be naturally equipped and interested in being on a driving position, a really strong communicator to liaise with stakeholders, users and engineers, firm and charismatic enough to introduce fundamental changes in the way the product is shipped, and of course, you need to stay technical. And this is completely unfair, since we don’t expect backend engineers, or frontend engineers, or SSREs to all be leaders, great communicators, pioneers. We understand that some engineers just want to keep working on their craft, that some will want to become architects, and others may want to jump into management -and that people will want different things during their working life, because not even climbers remain in rockstar mode year after year. But we do require that from QA engineers, and they better accept it because hey, the demand is shrinking, generative AI holds a big promise for testing, and I heard Meta doesn’t have QAs anymore. A test engineer that’s only interested in testing is generally disregarded in a way that a SE who just wants to code won’t face so often. Moreover, and this might be controversial, I think this is why there are so many women in QA roles compared to software engineer ones: we’ve traditionally accepted to invest double effort for half the return, we’ve been socialized to contribute without authorship, to lead surreptitiously, to clean up after others, and to always excel just to keep our seat. So we just put up with this kind of BS.
So there’s the Cinderella syndrome in QA: you’ll never own the house, and it seems you should be grateful for the shelter the team provides you, but in return you must do the job of a cook, a cleaner, a seamstress, a merchant, a manager, and fill the gaps that years of mishiring, rushing and stumbling have left in the product. An abusive expectation, and job that can’t be done well.