Developers February 18, 2020

Software Testing for MVPs


Hello everyone, this is my first time posting on Indie Hackers :)

I think you are the most qualified people I could ask for an opinion regarding software testing in the MVP phases of a product.

The common belief is that software testing is not necessary at the beginning because it slows down the process, and building features fast is a priority if you plan to get on the market asap.

I'm wondering, is this really the case? My first thought is that if the product becomes successful, you may have lots of technical debt. Of course you could build everything from scratch, but isn't that a waste of time and resources?

One can say that developing without tests is justified by the fact that the product can fail, but why starting a project with the idea that it'll fail? I think that's already starting off on the wrong foot.

Happy to hear your opinions about this :)

Thank you!

  1. 4

    I'm a TDD truther, so I think you should always be testing.

    That said, I do fall off the rails on new projects, if nothing more, for sake of speed of development early on (typically pre-customers / pre-MVP POC stuff).

    A good rule of thumb that I employ is to /always/ write a test when you have to fix a bug. Even if you sluff off at the beginning just to get something out the door, you can still start improving test coverage by writing tests to replicate things you've run into in production.

    The implication there is that because you're not writing tests, you're more likely to have bugs, thus, writing tests for said bugs will at the very least keep you from running into them again in the future.

  2. 2

    You're trying to strike a balance between speed and quality. If your code is terrible you will have bugs and your product will be seen as unreliable... and your brand will not be trustworthy, even if you do solve the pain point when it does work.

    Scoping is so important - that's why you often hear that you should do a few things well. If you're only launching with the most important thing that will show your usefulness, then you'll have time to test it and make sure it works well before you go live.

  3. 2

    Technical debt should be viewed as a tool, not a problem. You just have to understand how to manage it effectively. You shouldn't test extensively just because it's a thing you feel like you are supposed to do.

    If you are solving a big enough problem for people, your early adopters will be much more excited about that than bugs. Customers also don't care about what's happening behind the scenes (for most products).

    You just need to always be aware of the state of your code, what issues can hurt you in the short-term, and what debt can cripple you in the long-term. Then manage that accordingly as your product grows and you iterate.

  4. 2

    Yes, indeed. That's exactly the race that happens when a company accumulates technical debt: it either earns enough to repay the debt or fails, and starting with technical debt means it will be harder to convince great engineer to remain at your company.

    If you have a team, unit tests are mandatory. If you are a single experienced developer, it should be possible to manage the technical debt resulting from not testing in the first weeks.

    Eventually a codebase will become complex enough that not having tests will slow down the development speed considerably.

    So, unless you know what you're doing and understand the risks, write tests.