Kevin Wright’s blog

Functionality testing refers to the testing of programmatic features and is most appropriate for sites of higher complexity that contain features such as database access, dynamic page generation, and Java applets, namely features that require actual programming (rather than HTML page building).

Unit Testing

Functionality testing should start at the source, namely by the programmers who write the code. When programmers test their own code, module by module, it is referred to as unit testing. Each programmer tests his or her own modules thoroughly and does not start a new module before testing and fixing the previous one. The programmer tests not simply by running the code a few times to see if it works, but rather by feeding the code common, uncommon, and even unexpected inputs to make sure it handles them correctly and does not malfunction. This technique is the most cost-effective and efficient testing method and is a way of promoting ‘quality at the source.’ Programmers who are willing and able to thoroughly test their own code module by module, after each is written, generally find defects faster than other testers and are able to fix them in the shortest time. Unit testing stops problems before they can crop up in other modules, and it prevents other testers from having to spend time finding, isolating, and documenting these defects, then retesting for them later (regression testing) to make sure they were fixed.
Requiring programmers to thoroughly test their own code can be difficult to enforce, however, for several reasons. First, most programmers like to write code, not test it. Some see testing as monotonous work that is not part of their job. Second, programmers are often under extreme pressure to produce usable code as fast as possible. Therefore, the emphasis is often on quantity rather than quality. If programmers are on a tight schedule, there is little chance they will want to spend ‘extra’ time thoroughly testing their own code instead of logging the completion of that module and starting work on a new feature.
You should do your best to encourage programmers to take the time to test their own code thoroughly and fix defects they find before turning it over. One motivation is to let it be known that you will be monitoring the quality of the modules during testing.

Integration Testing

When the various modules are combined and the features are all running together, it is said to be integrated, and testing of the full program is called integration testing. Although all of the modules may seem to work perfectly in isolation, they often exhibit defects when combined as a system. Reasons include unexpected inputs and outputs between modules, incompatible variables, and just about anything else that can go wrong. Professional software testers are experienced in finding such flaws, and integration testing is usually performed in force by nonprogrammers. By not knowing how the site is constructed, they are more likely to operate the software in a way programmers had not anticipated, and so uncover errors programmers would not uncover.
Website features should be tested in an ongoing manner, while still in development. Testing the site this way allows the project manager to realistically monitor the site’s progress, by building testing time right into implementation. For example, if QA testing does not start until after the whole site is supposedly ‘finished,’ you would have no idea how many defects are actually lurking out there in the code and how long it will take to fix them. In addition, there is a good chance the defects will be repeated in various forms throughout the site. If the site is tested as it is being built, however, defects-especially those in the software architecture-can be caught earlier and will be easier to fix, and will cause fewer follow-on defects, lending a gauge of actual progress to date.

Regression Testing

The most thorough method of testing is not only to test for defects fixed from the previous versions, but also to retest for defects fixed in earlier versions. This process of repeatedly retesting for defects to see if any old ones have reappeared is called regression testing. Good record-keeping of what version of the software exhibited the defect is essential to regression testing. For example, if a particular defect was found in a database query on Monday, and fixed on Tuesday, it is wise to continue testing for it in subsequent days and even weeks to follow. At first glance, this process may seem excessive; however, regression testing can uncover serious problems and safeguard against them. Defects that were apparently fixed may recur for various reasons. An old copy of a particular file may have been used by mistake to build a later file, or a new or different programmer may attempt to optimize code and reintroduce an old error.
Another reason to perform regression testing is that in the process of fixing old defects, new defects may be introduced. It is entirely possible for a programmer to inadvertently introduce one new defect for every 20 fixed. Regression testing allows a much better chance of discovering these potentially serious defects.

Compatibility Testing

Testing the site on the various kinds of user hardware and software configurations is called compatibility testing. If the site has programs that run on the user’s browser (client-side programs), such as Java applets, JavaScript, or various plug-ins, it should go through compatibility testing. With the various versions of Java and JavaScript that have been released, it is possible that features that work fine on one machine may stall or malfunction on another. Problems reveal themselves in such situations that might never be discovered otherwise.