My first job involved writing developing test suites for a platform (with few software layers). Each layer again had many levels of tests - unit(api), component

My first job involved writing developing test suites for a platform (with few software layers). Each layer again had many levels of tests - unit(api), component(state machines), integration(2 layers), alpha, finally-a-swiss-knife test script. Doing at that time - I disliked my job (may be coz we did scripting in an obscure language). It was ridiculous the amount of effort we spent to develop whole suite. Level of tests was so stringent may be a healthcare product or aircraft software could only be more detailed or comprehensive. As this complex product evolved at rapid pace - one of the key differentiating factors of this product and others were time to market and product reliability - benefit reaped was many folds from test suite. Many LOB directors realised that efficiency of our platform had to do with test suites. If I've to run a successful company - I would heavily rely on such a test suite. Having said that - its hard to write detailed TDD in early stage startups. I didn't write TDD at my last startup work but I had a swiss-army-script to test. In this case, reliability of software is on a developer who developed it. But once a component is proven and it goes as core software of your startup - it should be baked with test suite.