Software testing answers questions that development testing and code reviews can't.

 ♦ Does it really work as expected? 

♦ Does it meet the users' requirements? 

♦ Is it what the users expect? 

♦ Do the users like it? 

♦ Is it compatible with our other systems? 

♦ How does it perform? 

♦ How does it scale when more users are added?

 ♦ Which areas need more work? 

♦ Is it ready for release? 

What can we do with the answers to these questions? 

♦ Save time and money by identifying defects early

 ♦ Avoid or reduce development downtime

 ♦ Provide better customer service by building a better application 

♦ Know that we've satisfied our users' requirements

 ♦ Build a list of desired modifications and enhancements for later versions

 ♦ Identify and catalog reusable modules and components 

♦ Identify areas where programmers and developers need training

WHAT DO WE TEST? 

First, test what's important. Focus on the core functionality—the parts that are critical or popular—before looking atthe 'nice to have' features. Concentrate on the application's capabilities in common usage situations before going onto unlikely situations. For example, if the application retrieves data and performance is important, test reasonablequeries with a normal load on the server before going on to unlikely ones at peak usage times. It's worth sayingagain: focus on what's important. Good business requirements will tell you what's important. 

The value of software testing is that it goes far beyond testing the underlying code. It also examines the functionalbehavior of the application. Behavior is a function of the code, but it doesn't always follow that if the behavior is "bad"then the code is bad. It's entirely possible that the code is solid but the requirements were inaccurately orincompletely collected and communicated. It's entirely possible that the application can be doing exactly what we'retelling it to do but we're not telling it to do the right thing.

A comprehensive testing regime examines all components associated with the application. Even more, testingprovides an opportunity to validate and verify things like the assumptions that went into the requirements, theappropriateness of the systems that the application is to run on, and the manuals and documentation that accompanythe application. More likely though, unless your organization does true "software engineering" (think of LockheedMartin, IBM, or SAS Institute) the focus will be on the functionality and reliability of application itself. 

Testing can involve some or all of the following factors. The more, the better. 

♦ Business requirements

 ♦ Functional design requirements 

♦ Technical design requirements 

♦ Regulatory requirements 

♦ Programmer code

 ♦ Systems administration standards and restrictions 

♦ Corporate standards 

♦ Professional or trade association best practices 

♦ Hardware configuration 

♦ Cultural issues and language differences