QA With a Future: Full Stack SQE & SDET
Here at #VelocityConf and #FluentConf, I haven't been able to find a single booth that has spoken to a "QA person." It's as if they don't exist, at least not at this show. I'll admit, this isn't a "testing conference" but it is about building and deploying modern software and it's widely attended by developers and other very technical folks.
So why no "QA" people? Isn't testing important to deploying modern software? Absolutely! Booth staff report lots of conversations about automated testing, continuous testing and even the "manual tester problem" which roughly translates to, "What are companies going to do with all the manual testers?"
This isn't exactly a news flash, but traditional QA is going away, and fast. In it's place, companies large and small are eagerly looking to fill positions for "Full Stack Software Quality Engineering" and "Software Design Engineer in Test (SDET)."
One company I spoke with said that recruiting testers that can code (and coders that can test) is the single greatest challenge to their growth.
The reason for this shift is simple: Building and shipping software quickly (and often) requires a fast feedback loop. Handing off supposedly "finished" code to a separate QA group and then waiting days or weeks to get test results, only to turn around and spend more days or weeks "burning down the bugs" just doesn't cut it any more.
If I make changes at 11:30am, I should know if my code fails (or causes someone else's code to fail), before I even head out for lunch. When feedback comes that fast, there's a good chance I'll know where I broke it because what I was doing will still be fresh in mind. This kind of instant feedback can only be accomplished by automated tests that are ready when the code is.
This new world is very different than the old "automate the tests" approach where manual QA would be done after coding was "finished" and then some subset of manual tests would be "automated" as regression tests. If and when those regression tests were built, many would fail as new releases changed things. As a result, teams struggled to build and maintain automation and it wasn't unusual for automation coverage to be 20% or less.
In the new world, the formula emerging for "definition of done" is this:
Code + Test Coverage (that passes) = Done
The rush is on to build test automation that can deliver feedback in minutes, whenever something is changed in the code or configuration. This requires that tests be built at the same time the code is built (or even before, in the case of test driven development, TDD). This is only possible if tests get built in the same time (and space) that development gets done. Either you have to "embed" testers in the development teams where they will know what's being built as it's being built, or you need to ask developers to divide their time between writing code and writing tests.
If you want to keep the developers writing code, then you need to pair them with someone who understands the code and why it's being built in order to automate tests for them. That's where "full stack SQE" and "SDET" folks come in. If you can master those skills, the world is your oyster right now.
Want a real world example or a role model? Meet Eliran Shani on BlazeMeter's team:
Learn more about where Eliran works at the BlazeMeter careers page: