The purpose to test the software is to ensure that it works perfectly and as intended.
There are several levels of testing just as there are several approaches to testing. It is the levels that will ensure utmost quality, so let us begin with the levels first.
We write software based on requirements. Who would write software without a purpose? The purpose would be the milestone for the software to meet, and that milestone should be met without any glitches and troubles for either the software itself or for the user. Software testing addresses the major concerns that the software being developed has met the milestone and addresses all reasonable user behavior.
It is an art to have a clearly defined purpose for the software. It is based on this clearly defined purpose that software is designed. It is at the level of defining the purpose that the business or the product owner will test the purpose itself. Let us assume a software application to develop a calculator application. The business owner may not see the need of another calculator application when scores are already either making their mark or struggling in the market. However, if he has a well-defined USP for the new software, he might as well take the plunge to reinvent the wheel, so to say.
Once a purpose is determined, the software enters the design phase. A technical architect or equivalent will design the software based on the clearly defined purpose. A quality architect or equivalent will then verify that the design is aligned properly with the purpose and all features are covered in the design.
The design, after being vetted for quality moves to the hands of a software developer. If required, the design is split into various modules and developers simultaneously working on these modules independently. Each of these modules, by itself, has a clearly defined sub-purpose. The modules, once integrated, should dovetail into the main purpose. An apt analogy would be the manufacture of a car. The sub-purpose here would be the individual parts of the car and the purpose would be the car itself.
Just like a car manufacturer would like to test each part to ensure it meets the requirements of the overall purpose of a whole car, we need to test each module of the software to ensure it meets the sub-purpose assigned. This level of software testing, where each module is tested is called unit testing, and is one level in the testing ladder.
Once individual modules have been developed and unit tests confirm that they indeed meet the requirements set out for the module, the software architects assemble each of these modules and run quality tests to confirm that the software works as a whole. Taking another analogy, it is possible that the gas tank in a car is tested vigorously and so is the cap for the tank. But if the cap is either too small or too large to properly perform the act of closing the gas tank, the car cannot be manufactured. This level of testing in a software application is called integration testing and is the next step in the testing ladder.
Now that we are done with assembling the bits and testing the two and three pieces together, we move on to test the software as a whole. Or, simply put, take the car on a test drive. In this phase, we just don’t test to see if the software works. We test the software to see if it is working, if it meets the clearly defined purpose, and behave just exactly as the user would want it to. Of what use is a software if it does not behave as the user would want, even though it meets the purpose. You don’t want your car turning right when you turn the steering wheel left, right? Because a piece of software is to be used by a user and it needs to be usable by a user, the emphasis at this stage of testing is more on user behavior. This lays even more emphasis on the first two steps of the testing ladder, the unit testing and integration. This third step on the testing ladder is called system testing, and it is imperative that the first two steps of the ladder are negotiated properly without any stumble for this stage to be successful.
Is it just that we climb three steps of the ladder and certify that our software is good to go and hitch-free? Not at all. Like we test a car to see what the maximum load it can bear and continue to run without stalling, every software application needs to be tested for the maximum load it can handle. An application can probably work fine if it has 50 people working on it simultaneously. And, probably slow down when the user count reaches 60. It might even crash if the 61st user is logged on to use the software. We need to determine what optimal load the software can take based on the design and the user requirements and run a test incrementing the load gradually till the software crashes. We can determine the crash point at the maximum load that the software is comfortable performing as expected. This is the fourth step and is called load testing, or stress testing. However, not all applications may require load testing to be certified as successful in meeting the clearly defined purpose.
You might probably not have learnt how to test, drive, or test drive a car, but software? Probably yes, there’s all to software testing.
—-
Thanks to my friend Sridhar Joshi for beautifully editing this article for me.