1. How entrepreneurs waste money on software
  2. Technical debt will run your business into the ground
  3. When is technical debt OK?
  4. You’re doing it wrong: Using “cheaper” developers
  5. You’re doing it wrong: Skimping on design
  6. You’re doing it wrong: Skimping on testing

There are lots of ways that entrepreneurs try to reduce the costs of building their product. These might include hiring  “cheaper” developers or skimping on design. This post will discuss another way that startups try to shave costs off their products in unproductive ways.

This time, we’ll focus on the perils of trying to save money by skipping testing. When you skimp on testing, you’re hurting your business and product in several ways:

You’ll lose users at launch

If a new user has a problem using your app, they won’t come back.

You’ll anger the customers you’ve gained so far

Your hard-won user base will flock to your competition. Or they’ll go right back to the solution they’ve always used – the solution that you were trying to replace.

You erode your credibility

You know who tends to leave reviews in the App Store? Frustrated users. An outbreak of 1-star reviews will discourage other potential customers from using your app. This is lethal for companies trying to gain trust in a crowded marketplace.

You end up paying more to fix the bugs you missed by not testing your code

Along with the opportunity costs of frustrated users, fixing bugs that have made it into the wild tends to be more time consuming (and expensive) than finding those bugs early on in the development process.

In a follow-up post, we’ll cover proven and economic ways to test your code base – and keep your users happy.

And as a bonus, here are some less-than-ideal approaches to testing that many startups rely on:

Have someone in the office test it

“We’ll just have Bob in support play with it for while” – Common Startup CEO

Letting the people you work with test your application is an excellent way to get user feedback. This is even better if they are the intended user of your app. When this is done informally it’s known as Hallway Testing (as in grabbing passersby in the hallway to use your software). Hallway testing is an invaluable tool. It should be used early in the development process. But it is not a replacement for a skilled testing professional.

Have the developer test it

It is the developer’s responsibility to provide basic testing. But they shouldn’t be relied on for everything. By definition, the person who wrote the software is *not* the person who is best at testing it. An outside participant will have better context to see what can be improved. The development process produces habits of reusing the same steps to get the app to function.

Developers don’t have insight on how your “typical” customer may use your app. And there are cost considerations too: good quality assurance professionals will do a better job of testing your app at a fraction of the cost of a good developer.

Wait for development to be complete before beginning testing

You should do a thorough test run before releasing software to the public. But you shouldn’t wait until development is complete to begin testing.

Testing should be done throughout the development process. This is important. A major benefit of testing early and often is the feedback loop it provides.

By getting early feedback, you can identify problems and make changes before they become baked-in (hard to change) parts of the software. Good testers will find your bugs. They will use your app in many odd configurations with old devices and low cell coverage, and they’ll run into things you wouldn’t expect.

Another benefit is early knowledge of your software’s weak spots. This can help you avoid spending development money on less important features when there are critical things to finish.

Testing as an after-thought

For many of the reasons previously explained, testing is a critical component of your software’s success. Too many startups treat it as a task to breeze through just before shipping.

Take aways

  • Work with people who are experienced in breaking mobile applications. If you don’t have those people on staff, budget for external testers.
  • Leave room in your release cycle and budget for hardening of the application.

Also published on Medium.

1 Comment

Leave a Reply

Your email address will not be published. Required fields are marked *