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!
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.
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.
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.
Testing is the key to avoid expensive re-work, and in some situations the only way to avoid life-threatening scenarios. In a recent example of catastrophic failure, France’s biggest telecom operator, Orange, experienced a software failure which affected the French emergency services for several hours, causing the death of five individuals while waiting for an ambulance to rescue them.
This is a reminder that while testing for defects is a given, an early approach to it would have increased the ability for Orange to identify the defect and be spared an avoidable tragedy.
The centre of every business is a satisfied customer. If the product is not reliable, you need to invest more money in fixing it. The earlier the defect is found, the less development rework is required, which minimises the implementation cost. Software with good quality brings happy clients, customer retention, reputation and brand image.
Read why you need to invest in software testing at - https://www.testhouse.net/blogs/10-reasons-your-organisation-must-embrace-automated-testing-in-2020/
This comment was deleted 4 years ago.