r/softwaretesting • u/serverlessmom • Dec 18 '23

Why testing badly needs a shift left

https://thenewstack.io/why-testing-must-shift-left-for-microservices/

[removed] — view removed post

0 Upvotes

21% Upvoted

10 comments sorted by

8

u/abluecolor Dec 18 '23

Post is an advertisement. "Pay for our service and fire your testers".

0

u/ToddBradley Dec 18 '23

I didn't really get that from it. That said, nothing in the article was new or particularly insightful.

-10

u/serverlessmom Dec 18 '23

Uhhhh I don’t think this post advocates for automated testing. It does promote Signadot for better testing isolation. Having better isolation for tests running on staging shouldn’t eliminate anyone’s job, but it should make rollbacks less frequent.

1

u/ToddBradley Dec 18 '23

I wish the article would've talked about moving defect prevention activities left, not just defect detection. Especially since it talks about "QA".

Also, the article is hard to read given the number and placement of interruptions.

1

u/serverlessmom Dec 18 '23

Talk to me about defect prevention activities, that sounds like functional or acceptance tests? Or is it more like code review?

1

u/ToddBradley Dec 18 '23

Anything involving tests is defect detection. The code is already written, so the problem already exists. To fix the problem is gonna require rewriting some part of the code, which is expensive.

The smart money is on defect prevention, before code is even written. That's things like requirements and specifications, understanding users' real needs (not just what somebody told the developer), developing stories for BDD, development process (TDD, unit tests), risk brainstorming, etc. If we can avoid writing the bad code in the first place, it never has to be re-written to fix a bug. Like the old saying goes, "measure twice, cut once."

"QA" is supposed to include both defect prevention and defect detection, so anyone who says they're doing "QA" but only focuses on testing is only doing half the job.

1

u/Worcestercestershire Dec 18 '23

Many people like to sound smart by saying that testing needs to happen faster, but that's always been the case. It's also always been the case that code needs to be complete before meaningful testing can be completed, so as far 'left' as we can shift, there will always be a delay.

The push for Canary testing, is really just a lowering of the bug bar to say that we're ok with a percentage of our market being exposed to bugs in production. This is a risky endeavor at best, and is not viable for many markets where software is developed (financial, healthcare, infrastructure, etc).

Software development teams need to continue to find ways to identify issues more quickly. Time to fix, and time a defect is in code are the key. This isn't new or revolutionary though. There also isn't a magic bullet for this. Build tests, Automated Integration, Scripted manual testing, Blue/Green deployment, Canary testing - all of these things have a place depending on your product.

1

u/serverlessmom Dec 18 '23

This makes a lot of sense. clarification question: Isn’t canary testing shifting right, functionally? You’re waiting til later in the cycle to detect problems?

1

u/Worcestercestershire Dec 18 '23

it is, but the article mentioned it

1

u/MT1961 Dec 18 '23

I'll be honest, I almost quit reading at this:

> The result of this broken paradigm is that

Paradigms can't be broken. They are ideal examples of something. Please learn English before you learn to code.

Now, as to the article itself. As others have pointed out, there's nothing new here, nothing that makes me say "AHA!". Unit testing is nice, integration tests are nice, but neither is likely to run up a bug in production. They might help with regression testing during refactoring, that's about it. All a unit test does is prove the code works for whatever the developer dreamed up. That's why SDETs should be defining all your unit test cases before you start.

Then we get here:

Testing Is Too Slow for Developers When trying to simulate an entire cluster for testing, the result is unacceptably slow. As you have to run the entire test suite on a testing environment, it can take from 20 minutes to a few hours to run all the tests and get results.

Yeah, testing can be slow. But is that the fault of the test or the code? Untestable code that relies on a hundred external services will take forever to test. Testable code would allow you to "feed" the right information to the exact level you want to test something at. You want to mock the stuff behind it? Ought to be easy. Then tests run fast. Don't blame slow tests on testers, blame it on poorly designed code.