p>Testing software before release seems like a no-brainer, but it has to be lightweight and spread out, else it can end up as a low-priority risk and never get done.
Good testing leads to reliable and predictable software. The kind of software that is fun to release and friendly to live with. Ask yourself… would you rather release a product that was A) full of bugs, unpredictable, prone to crashing or confusing to your customers or B) software that just does it’s job and lets you move onto the next thing? We like B.
A few fun facts
- Most software is not thoroughly tested, usually due to budgetary restrictions, poor planning or lack of technical know-how.
- It is far cheaper to fix a problem before it is released than to fix it after it’s released.
Good testing plans are sometimes axed from high-profile development project because of budgetary restrictions. The unfortunate and costly side-effect of that comes after release, in the form of user unhappiness and organizational firedrills that should never happen. Sales, Marketing, Customer Service, Operations, Finance, all departments are affected. Competitors can throw salt on the wounds. The cost of fixing a problem after release is far more than the cost of finding and fixing it before release.
Sometimes good testing is skipped due to speed-to-market, difficulty implementing a testing plan or lack of technical know-how. Many initial product releases are dictated by dates set in stone far in advance. If a project takes more time than expected, often the amount of testing is reduced to stay on target for the due date. We work in short cycles and believe in releasing often, which helps us answer speed-to-market issues and have lighter testing plans that are more likely to be performed.
The most difficult testing plan to implement is the one that involves the most people. Usually that is the BETA release of a product, which occurs prior to release and involves exposing the new product to existing or potential customers in hopes of getting high-quality feedback from them. Due to budget limits, BETA’s are often handled by corporate staff who’s main expertise is something other than managing BETA releases, and the customers involved are usually doing so voluntarily and, frankly, usually don’t return the kind of results that make the effort effective, without incentive. Because of this, it’s common for BETA’s to start off looking good, only to become diluated watery messes with limited benefit. Go through a few of those and it’s easy to see why BETA testing might get axed.
Our belief in short, flexible, development cycles and end-user involvment allow us to get the kind of feedback that your new software needs before we near the first release of your product. That spreads the weight out from a heavy BETA and allows you to respond to feedback during the development process. It also prevents the worst kind of suprise that a BETA can bring: finding out that you’ve made isn’t what your users want and that you have to go back to the drawing board or punt due to your deadline.
Implementing a good, practical, useful testing plan requires experience and know-how. We choose the kinds of testing that are most likely to make your project succeed without bogging down the project. We cherry pick from these kinds of testing:
- Unit: Makes sure that the each chunk of code does what it was designed to.
- User Interface: Makes sure that the interactive parts of your system work.
- Usability: Makes sure that your system is easy to use.
- Regression: Makes sure that new changes don’t break existing functionality.
- Load: Makes sure that your system can handle a lot of people using it at the same time.
Some of these tests we implement ourselves. Others may involve you or your customers. We only do what’s worthwhile. We know that it’s cheaper to test than not to and that you will be happier with a well tested product.
For more information about how we can create high quality, fully tested, software for you, please contact us.