While looking over some presentations of new software projects/companies, it was hard to ignore the fact that some of them had missing major functionalities or even worse, the investors were pointing out some showstopper bugs. I’m talking about new companies, young ones, that probably got already a round of investment.

Other thing I noticed was that some companies, after 6 to 12 months after their initial investment, end up drowning in bugs and refactorings which are causing dev work to hinder and not develop new features as planned. Those missing features are often the reason of a failed second investment round.

Of course, these are the worse case scenarios and it’s not happening for ALL the startups. It’s not something I wish, it’s just something that I see everyday. All the major sources specify the same kindof news: “About 90% of startups fail. 10% of startups fail within the first year. Across all industries, startup failure rates seem to be close to the same. Failure is most common for startups during years two through five, with 70% falling into this category.”

Identifying this problem, I took the role of the CTO for a testing company. The main goal is to help start-ups building quality work. This is what it matters, because others success is our success. Our role is to bring expertise and fresh perspective to projects, contributing to the overall improvement of software quality within an organization.

So, how important is QA for you, and when do you decide it’s time to invest in it? Have you seen good ideas not getting investment because of bad quality? How is anybody overcoming this?

  • LogicalGrapefruit@alien.topBEnglish
    1·
    10 months ago

    Frankly I see much more of the opposite problem: startups waiting way too long to ship because they’re trying to fix all the bugs / set it up to scale / etc.

    • bhooo121@alien.topOPBEnglish
      1·
      10 months ago

      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.