4 ms·

I'm torn on this. On the one hand, I really dislike when my developers behave as if their job is done as soon as the code is written and that all that's left to

I'm torn on this. On the one hand, I really dislike when my developers behave as if their job is done as soon as the code is written and that all that's left to do is to "throw it over the wall" to QA and Ops. But that is perhaps my more general view that developers who understand how their code actually runs and how it's tested, generally do a better job and are more valuable. On the other hand, I do feel that the notion of shift left, taken to an extreme, leads to the undervaluation of specialized QA roles. QA professionals have a specific set of skills focused on testing, finding bugs, and ensuring the usability of software. If you distribute these responsibilities among developers, who may not have the same level of expertise in testing, there's a risk that the quality of the software could decline. As other comments here have mentioned, just as DevSecOps requires developers to integrate security into the development process, shift left ends up meaning a demand for a really broad skill set from developers, including expertise in testing and quality assurance. And it's pretty difficult for professionals to maintain a high level of expertise across multiple disciplines. I mean...specialization exists for a reason; it allows professionals to hone their skills in a specific area, ultimately leading to better outcomes (hopefully? usually?). So "shift left" aims to streamline the development process and integrate quality from the start, but it can inadvertently marginalize QA expertise and overburden developers, potentially compromising quality and security. I do think management often has no idea how many different specialties and expertise there are within engineering. They often conflate it all since it's just "engineering". The amount of expertise devs are expected to know these days has gotten kind of absurd.

rsyring 3y ago
The article addresses your concerns regarding QA: > One of the myths is that testing is done by developers and hence QA teams will become redundant. In reality, QA teams will work more closely with development teams. Developers will be aware of testing needs. Testers will get insights into what's being developed. A related myth is that Shift Left is not aligned to Agile practices. This myth is also busted since greater collaboration between QA and development teams means that they can iterate faster.
- Uehreka 3y ago
  That feels a little “no true scotsman” to me. Like sure, if implemented correctly, Shift Left isn’t “developers are now also testers and can sign off on stories”. But in practice, it often becomes that. And while some may say that “that’s not Real Shift Left”, I’d argue that if a practice works great if you do it right but almost always fails the same way when you actually try to do it… well, that’s a problem with the practice itself.
esafak 3y ago
We can at least ask developers to write proper tests and own (be on call) for their own mistakes. I think having a separate QA team write tests leads to bad incentives. If I were to set up a QA Team they would write tools under the platform engineering org.
- rsyring 3y ago
  Developers and QA teams should be doing different kinds of testing. Devs should be writing the majority of tests that can be automated. QA teams should be testing for things that can't be or are difficult to automate (e.g. UI/UX) and trying to break things in ways developers don't usually think about.
lsofzz 3y ago
> overburden developers Please. Doing a perfunctory role does not equate to "overburden". I'll get grads from a third-world who will _happily_ take the burden off these developers if you so insist. > I do think management often has no idea how many different specialties and expertise there are within engineering. That is true. It is every one's responsibility to inform mgmt of this and keep open channel.
- lsofzz 3y ago
  > That is true. It is every one's responsibility to inform mgmt of this and keep open channel. And vice-versa (should of said).
- lsofzz 3y ago
  > overburden developers Given by today's standard, _most_ if not all the code I review out in the wild are these: - Search your question on $search_engine - Land to stackoverflow - Copy - Paste - Write some crappy unit test (important but still crappy IMHO) - CI - Boom land on production Where is this special fairy of "overburden"'ed devs you speak of? Very few code today are _true_ innovations. It's a pile of abstractions over abstraction shite.
  - mvdtnz 3y ago
    Most code should be implementing business rules in the simplest and most maintainable way possible. I don't need developers "innovating" on my codebase. And you can't find typical business rules on Stack Overflow. Getting this right is much harder than it sounds.
    - lsofzz 3y ago
      > Most code should be implementing business rules in the simplest and most maintainable way possible. I don't need developers "innovating" on my codebase. Fair dinkum. That's you. You may be biased towards it due to past experiences and I understand it. However, with that mentality where there are no "innovation"(s) involved, you'll only get donkeys that live within the echo chamber. And, may be that's what you want.

rsyring 3y ago

The article addresses your concerns regarding QA: > One of the myths is that testing is done by developers and hence QA teams will become redundant. In reality, QA teams will work more closely with development teams. Developers will be aware of testing needs. Testers will get insights into what's being developed. A related myth is that Shift Left is not aligned to Agile practices. This myth is also busted since greater collaboration between QA and development teams means that they can iterate faster.

Uehreka 3y ago
That feels a little “no true scotsman” to me. Like sure, if implemented correctly, Shift Left isn’t “developers are now also testers and can sign off on stories”. But in practice, it often becomes that. And while some may say that “that’s not Real Shift Left”, I’d argue that if a practice works great if you do it right but almost always fails the same way when you actually try to do it… well, that’s a problem with the practice itself.

esafak 3y ago

We can at least ask developers to write proper tests and own (be on call) for their own mistakes. I think having a separate QA team write tests leads to bad incentives. If I were to set up a QA Team they would write tools under the platform engineering org.

rsyring 3y ago
Developers and QA teams should be doing different kinds of testing. Devs should be writing the majority of tests that can be automated. QA teams should be testing for things that can't be or are difficult to automate (e.g. UI/UX) and trying to break things in ways developers don't usually think about.

lsofzz 3y ago

> overburden developers Please. Doing a perfunctory role does not equate to "overburden". I'll get grads from a third-world who will _happily_ take the burden off these developers if you so insist. > I do think management often has no idea how many different specialties and expertise there are within engineering. That is true. It is every one's responsibility to inform mgmt of this and keep open channel.

lsofzz 3y ago
> That is true. It is every one's responsibility to inform mgmt of this and keep open channel. And vice-versa (should of said).
lsofzz 3y ago
> overburden developers Given by today's standard, _most_ if not all the code I review out in the wild are these: - Search your question on $search_engine - Land to stackoverflow - Copy - Paste - Write some crappy unit test (important but still crappy IMHO) - CI - Boom land on production Where is this special fairy of "overburden"'ed devs you speak of? Very few code today are _true_ innovations. It's a pile of abstractions over abstraction shite.
- mvdtnz 3y ago
  Most code should be implementing business rules in the simplest and most maintainable way possible. I don't need developers "innovating" on my codebase. And you can't find typical business rules on Stack Overflow. Getting this right is much harder than it sounds.
  - lsofzz 3y ago
    > Most code should be implementing business rules in the simplest and most maintainable way possible. I don't need developers "innovating" on my codebase. Fair dinkum. That's you. You may be biased towards it due to past experiences and I understand it. However, with that mentality where there are no "innovation"(s) involved, you'll only get donkeys that live within the echo chamber. And, may be that's what you want.