Effective Testing
This little article isn’t going to show in depth code, but is an important part of development.
Most people don’t realize what it takes to test an application properly. Let’s use a small example.
We have a members area with a login. A user can log into their account by typing in their username and password. If they type it wrong, they are told they can’t get in and can try again.
To test this, we have to define the scenarios that could occur and test for them. For the above example, some scenarios are:
1 - a user types a correct username and password and gets in
2 - a user types an incorrect username but correct password
3 - a user types a correct username but incorrect password
4 - the user hits the submit button without typing anything in
5 - the information typed in is a string of malicious code and not a real username/password
6 - the user types a correct username, but has a space at the beginning
7 - someone tries to pass information to the php page to check the login, but they didn’t use the actual login page
8 - someone copied the login page and is trying to login using it maliciously
There are probably more, but these give you an idea of the things we need to test. And each item may need tested more than once to account for slight differences or to test a sub-scenario. Along with that, we need to make sure that it is accurately connecting to the database and not just saying ‘Yup, it’s ok’, we need to make sure if logged in correctly everything gets set properly. The error messages should appear and be appropriate to the error.
PLUS - now we need to test each of those scenarios on IE and Firefox. Maybe we need to test on Mac safari also. What about needing to test it on AOL browser?
If there is a problem we have to identify the actual problem to get it fixed. Then guess what, we need to test it all again! Not just the part that had an error, but everything. Why? Because the fix we just did may have broken something else.
Ugh. This is just for a simple login. When you start getting more complex information and interactions between various database tables, the job of testing can become even more complex.
We may fix 25 bugs in a project before it even gets to an end user. They may be as simple as an error message is appearing white instead of red. But it’s a bug that needs fixed since we missed it when we originally coded. This doesn’t mean the code is bad or the programmers aren’t good. Everyone programs with some bugs. We’re human. You don’t even want to know how many bugs there are in Windows or Mac OS that are known and not fixed. 
The point is, testing is a very integral, though time consuming, part of the whole development process.