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?

  • UpbeatAd1974@alien.topB
    link
    fedilink
    English
    arrow-up
    1
    ·
    10 months ago

    QA is never a priority until you start having outages every week in production, normally around series A if someone in the engineering has a quality mindset or series B if clients churn because of unreliable product this starts to be a concern.

    QA adoption within engineers is cultural and it takes time to mentor people, create processes, and adopt those processes, in my experience the tech side of it is the easier part to put in place.
    Helps tremendously if the CTO or VP empowers QA from early on.