Testing (vs. or not) Launching
Marat Chukmarov
2 replies
Hi, everyone! As a tester(on my main job), I push quality against deadlines, cause in indeterminant future developing with fear of risky changes quickly becomes unmaintainable.
However, I(as most of us, I believe) need to reach the point, where the product can bring some value, point, where validation of the idea starts, before losing interest/resources/hope. (I noticed, that in most places, a month is a magical deadline). After quick scaffolding, now I need to slow down a bit, to clean the kitchen, so I won't have to clean the garage, so to speak. (consider switching to TDD approach, where it's possible)
(like the definition of legacy: 'when the system makes more design decisions than you')
How do you, guys, do that? Budgeting on testing completely or, vice versa, going TDD? Or struggling in between? What tools do you use? Do you need any help with struggles?
(Solo, making the smallest single page application, basically, one-page dashboard/entry point to clarify team-work - scaling is dangerous when people start looking/working in all different directions instead of a single vision. And, yet, will go for test-first)
(from TDD to Lean Startup, but the whole video is great)
Replies
Artem Smirnov@artem_smirnov
@much_applied every time I need to prioritize, I'm asking myself, what would benefit my users the most? Would they prefer a sometimes faulty app and get the benefit now, or rather wait for a perfect experience? If you are in a competitive market, then your app needs to be perfect, with a full range of tests to make sure every release is even more perfect. If they need desperately something that your app gives them, then they would be happy even if it fails now and then (especially if you keep them informed and provide feedback channels, and if they know they're lucky to use some bleeding edge technology which is not perfect yet).
Share
@much_applied Hi Marat.
I had a similar concern when I first launched Noticeable. As a single maker it's just not possible at all to test all parts or to apply TDD to all developments and launch in a reasonable time frame. Besides, it does not make really sense to spend too much time on tests when you are not even sure if you will have people using your product.
What I did and that worked is to build a first MVP with manual tests only. Then, I found a few early testers before the public launch. At this stage, I started to add some unit and integrations tests to critical parts such as billing and core features.
If you have the chance your product is used by people, make sure you add tests for each issue reported and fixed. Regressions are the worst (but you should know :D). You can always improve the coverage over time. For sure, it depends on the type of products you are building but here is my experience.
Good luck with your project!