One of the best thing that I’ve ever did in all startups I worked on/founded is never to allow for any Quality Assurance (QA) or SDET (Software Development Engineer in Test) team to exist.

Hard rule, but a good one every time.

Two side notes to avoid the hurricane of pushback:

I’m not saying that SDETs are bad. Some of the ones I met were great. I’m saying the use of SDETs when not needed, which is mostly true for most of of startups/companies, is bad. A completely different argument.The need for having leaner team is becoming more and more obvious with:The use of the right engineering practices (DevOps, TDD, Automated CICD pipelines, etc.)All the AI tools that can help in producing more quality code (but not necessarily the best quality code – whatever best means for a company.)

That’s out of the way, let’s dig.

Something is broken on production. Who’s responsible?

If a bug is there on production, and you have developers and you have QA testers. Who’s responsible?

You can argue in too many ways. But if we have only developers, it will be the developers. If we have developers and testers, it will be both.

Hiring SDETs is a sign that we don’t trust our engineers.

Simple. If we trust engineers enough, why would we hire SDETs?

It’s the engineer responsibility after all for writing/generating the code. It’s not the QA engineer nor the SDET.

This is true for most startups and most companies. I do understand that sometimes, even for regulatory purposes or complex release flows, automated and manual tests should be conducted by someone – SDETs and QA mostly. But again, this is not true for the majority of startups/companies.

The 2nd order effect

The problem of having SDETs and QAer is that it creates a chain reaction on the whole SDLC (Software Development Lifecycle) and the whole team dynamic with design, sales and product. The following is exactly what was happening in a startup I joined.

It’s-not-my-problem Problem

As an engineer, if a bug is there on prod: “it’s not my problem. The SDET too didn’t think of this.” Simply, as an engineer, I don’t care about the code I put out. There’s always someone else to check after me. So, why should I? (Why should I care?)

I don’t own my destiny, nor I care

As an engineer, I no longer need to think about the feature end to end, not in product terms, not in the design phase nor in the delivery phase. There’s always someone else that will check my work later. Why waste my precious time on this.

Why do I care when this is live?

As an engineer, I simply don’t care. Anything I worked on will be released BY SOMEONE ELSE, by the SDET or DevOps or one someone else decides. I don’t think I need to be involved. We are a product company you say? True, but I’m a developer, not a product person, sorry. Ask the SDET when it’s ready to be pushed.

What about the recurrent problems with rollouts?

As an engineer, it’s true that we keep having problems with deployments and how we rollout features because I still need to be involved in that every time we need to release to a different environment and the SDETs know nothing about this. It’s OK. It’s a hassle. I see myself firefighting from time to time and I don’t feel in control over the whole feature cycle. But that’s OK since I don’t need to think much about everything I do.

Best Practices? Bye bye.

As an engineer, do I need to waste my time testing things? Yeah yeah TDD is a nice acronym, but it actually lengthen the implementation time and we are not that mature nor we have the time. We don’t have proper tests anyway so why start now? We have SDETs for [manual] tests! And manual tests are even better!

I don’t want to feed the dog nor flag the feature

As an engineer, I believe dogfooding is good. But that’s for product people to try things out. We are not mature enough to do it. Feature flags are expensive, complicated and hard to implement [Mohammad is here again: that’s, btw, the most absurd argument I’ve heard by any engineering team. Part ways (fire) that person on the spot. He’s a BSer.]

A simple change, for a big process change.

We parted away with all SDETs in the span of 2 months.

Removing SDETs actually improved the whole cycle. The ownership of features, start to finish is now engineer’s job. He/she must talk to sales, design and product to know why, how and when we’ll release. The engineer is no longer bounded by his/her title of being a damn engineer. He’s now set free to know what his/her team and his/her company is building end to end.

All of a sudden TDD is extremely important to guard engineers from themselves. They understand now the future risks of releasing something not automatically tested. They understand that they should version API because there’s backward compatibility with an old system. Feature flags seems like a no brainer to prioritize and implement now to help them with E2E testing on any environment they want. They can even now try things on prod by themselves. They can demo things, on prod, with a product manager before releasing the A/B test. They are in control now. Dogfooding and gradual releases seems a good idea now to make sure they’ve implemented the right flow for the users.

Salam, peace.