One in particular that comes to my mind is: Jawbone One other personal favorite is Karhoo: The problem was that app codes never seemed to expire and people would use £100 worth in free rides.

There’s also Quibi. Here it wasn’t only product, I admit, it was more of a multiple reasons to fail, but bad product is one of them.

There is a very big list of startups that fail due to bad product or judgement. I joined my company in order to help others avoid this. It’s not my intention to actively not release fast in production. It’s more of: release fast in production quality work.

First, thank you. You raised some very interesting points here.

You are right about investors. They never ask about testing, but honestly, they don’t ask about programming languages neither. Or if your backend is using sql or nosql. They want things done. They are usually non-technical and they don’t want to get into these kind of details.

Or product is not just testing for bugs. Or main focus is to create a mindset inside the young organization, that keeps testing on the table. We try to ensure that each stage of software development aligns with the quality standards. We push for Agile and DevOps. We try to be the end user advocate and raise potential business issues. We try to find defects earlier in development because it’s much cheaper than finding them in production.

And no, all of the above is not taking more time. QA doesn’t mean loooong development time, loooong processes and loooong time to market.

You’re also right about the numbers. Those statistics are not all about bad product.

But that’s not what qa does. Or at least, this is not what I want to do. You are seeing qa as someone who’s doesn’t want to ship fast. You are seeing qa as someone who tries to fix all the bugs. This is not a health qa approach.

As a QA accelerator, we want a very short TTM in order to get fast feedback. We know that fixing all bugs could sometimes be a waste of time and effort, so we agree upon proper prioritization. QA doesn’t mean moving slow!

Don’t forget that there isn’t dev vs qa here. We all want the same thing. Quality in production.

I stand corrected. The numbers I displayed earlier were not product related.

You’re right. But also those big companies have legacy clients. They have a client base that accept those bugs.

As a tester, it’s in my DNA to see less bugs in production. Don’t you get mad when you see easily fixed bugs in very known apps? Don’t you start thinking how fast you would’ve fix those bugs and why are they present in prod?

Niiice! Let’s agree to disagree. I think there’s big a difference between “should not” and “choose not to”. The world is full of different projects and ideas, each needing their special something. This could mean a legal department, an office space, or hardware, qa, etc.

Good!

The answers will be as accurate as your question. If you’re wondering about a specific field, do share some details. If you’re wondering in general (I doubt it), well, here’s my 2c: commercial data providers, surveys, government dbs.