Software Testing: Functional Testing
Categorize This
Just as the Software Testing Cycle can be segregated into various levels, the actual testing process itself can be broken up into various categories. The first overall element deals with functional testing – ensuring that the product is working and that it is doing the right thing – the Verification and Validation approach. The various categories of functional testing must be successfully completed before higher, more complex levels of testing can be performed.
Unit Testing
Unit testing, or modular testing as it is sometimes called, is usually performed at the developer level. This type of testing is normally conducted by someone other than the primary developer. The reason this scheme is preferred is to get as many eyes as possible looking at the code. The coder may make some assumptions that prevent him/her from being objective as to the functionality of the unit. Having others test the unit may not guarantee an error-free module, but it goes a long way in that direction.
The software testing group may or may not be involved at this level. If they are, it will most likely be at a more informal level. Collaborative activity at this time encourages teamwork and cohesiveness. The goal here is to always keep the final outcome in mind: successful product delivery.
Integration Testing
This is where the testing team can make a big impact. How well do the units so far developed work with each other? The concern here is not so much checking what the finished product will look like or how it will perform; more so, how well do the currently released modules function together as a new component. This is putting the building blocks together to see what we‚ve accomplished so far.
As I have indicated in previous articles, this type of testing should be done in its own testing environment. The testing team needs to be able to try things that may have disruptive effects on others. Nothing is more unsettling to a developer than to have the data change unexpectedly while he/she is trying to get a complex algorithm to function in an expected manner.
System Testing
This is the first time the program is altogether as a single entity just waiting to perform its magic. At this point, the testing team should be documenting each and every fallacy it finds. Risk assignment is very important here. The faults may be very low risk: wrong size or color of the font. Or they may be major: pressing the ŒStart‚ key causes the computer to shut down. Most defects, and their associated risks, will be somewhere in between. The test team must have a formal way of reporting each failure in order to allow the developer to easily reproduce the condition.
Requirement validation is of utmost importance here. This is the first level that actively assesses the functionality of the complete application. Ensuring that the resulting output is the one desired is the ultimate goal.
System Integration Testing
System Integration should be performed, if not on the customer‚s system, on a system as close to the users‚ structure as possible. Most of the major defects should have been discovered and corrected by this time. The goal here is to ensure that the application will work when it is installed in its final destination.
User Acceptance Testing
As its name implies, user acceptance testing (or UAT) is the customer‚s opportunity to authenticate the performance of the soon-to-be delivered product. The user may use existing test cases or develop those of his own choosing. At any rate, the testing is usually performed by individuals in the user‚s group or individuals specifically identified to perform this task. The aim is to have new, objective eyes viewing the outcome from a different perspective.
Regression Testing
Regression testing may occur at any time during the testing process. Typically what it means is to re-run tests that had previously passed. The object here is to ensure that no new bugs have been introduced by the enhancements that were added to correct or enrich the product. This is an excellent time to introduce automation into the testing scheme (but that is an entirely different subject for another time).
There are a couple of other categories of testing that involve the end-user: Alpha and Beta testing. Each has its own unique environmental circumstances.
Alpha Testing
Typically, Alpha testing is performed in a controlled atmosphere at the developer‚s location. Outside users are invited in to play with the new application in a controlled environment. Local experts, which may consist of members of the original development and testing teams, are readily available to answer any questions that may arise.
Beta Testing
Beta testing, on the other hand, may be the exercising of the new application in the end-user‚s production environment. Frequently, it is run side-by-side with the existing program (if the application is a replacement) or may be run in a Œsandbox‚ setting to allow the new users the opportunity to get used to the look and feel of the new item.
To be continued…
What I have presented here is certainly not an end-all approach. Testing categories, when and how they are performed, are part of a continuously varying process. Each project will have its own requirements and restrictions. The most important aspect to remember is to approach the mission with a set of plans that can be adapted and modified to provide the most complete method of achieving an end-product that is as successful as possible.
