In this post, i will try to explain various testing methods which we follow in real time. As a developer we must perform unit test and should document it by writing test cases. We will discuss more about test case writing in near future. Today we will try to learn the terminology.
Unit Testing
A unit test is a procedure used to validate that a particular module of source code is working properly from each modification to the next. The procedure is to write test cases for all functions and methods so that whenever a change causes a regression, it can be quickly identified and fixed. Ideally, each test case is separate from the others; constructs such as mock objects can assist in separating unit tests. This type of testing is mostly done by the developers and not by end-users.
Validation and system testing
Validation testing is a concern which overlaps with integration testing. Ensuring that the application fulfils its specification is a major criterion for the construction of an integration test. Validation testing also overlaps to a large extent with system testing, where the application is tested with respect to its typical working environment. Consequently for many processes no clear division between validation and system testing can be made. Specific tests which can be performed in either or both stages include the following.
Regression testing. Where this version of the software is tested with the automated test harnesses used with previous versions to ensure that the required features of the previous version are still working in the new version.
Recovery testing. Where the software is deliberately interrupted in a number of ways, for example taking its hard disc off line or even turning the computer off, to ensure that the appropriate techniques for restoring any lost data will function.
Security testing. Where unauthorized attempts to operate the software, or parts of it, are attempted. It might also include attempts to obtain access the data, or harm the software installation or even the system software. As with all types of security it is recognized that someone sufficiently determined will be able to obtain unauthorized access and the best that can be achieved is to make this process as difficult as possible.
Stress testing. Where abnormal demands are made upon the software by increasing the rate at which it is asked to accept data, or the rate at which it is asked to produce information. More complex tests may attempt to create very large data sets or cause the software to make excessive demands on the operating system.
Performance testing. Where the performance requirements, if any, are checked. These may include the size of the software when installed, the amount of main memory and/ or secondary storage it requires and the demands made of the operating system when running within normal limits or the response time.
Usability testing. The process of usability measurement was introduced in the previous chapter. Even if usability prototypes have been tested whilst the application was constructed, a validation test of the finished product will always be required.
Alpha and beta testing. This is where the software is released to the actual end users. An initial release, the alpha release, might be made to selected users who would be expected to report bugs and other detailed observations back to the production team. Once the application has passed through the alpha phase a beta release, possibly incorporating changes necessitated by the alpha phase, can be made to a larger more representative set users, before the final release is made to all users.
Integration testing
Integration testing can proceed in a number of different ways, which can be broadly characterized as top down or bottom up. In top down integration testing the high level control routines are tested first, possibly with the middle level control structures present only as stubs. Subprogram stubs were presented in Section 2 as incomplete subprograms which are only present to allow the higher level control routines to be tested. Thus a menu driven program may have the major menu options initially only present as stubs, which merely announce that they have been successfully called, in order to allow the high level menu driver to be tested.
Top down testing can proceed in a depth-first or a breadth-first manner. For depth-first integration each module is tested in increasing detail, replacing more and more levels of detail with actual code rather than stubs. Alternatively breadth-first would proceed by refining all the modules at the same level of control throughout the application. In practice a combination of the two techniques would be used. At the initial stages all the modules might be only partly functional, possibly being implemented only to deal with non-erroneous data. These would be tested in breadth-first manner, but over a period of time each would be replaced with successive refinements which were closer to the full functionality. This allows depth-first testing of a module to be performed simultaneously with breadth-first testing of all the modules.
The other major category of integration testing is bottom up integration testing where an individual module is tested from a test harness. Once a set of individual modules have been tested they are then combined into a collection of modules, known as builds, which are then tested by a second test harness. This process can continue until the build consists of the entire application.
In practice a combination of top-down and bottom-up testing would be used. In a large software project being developed by a number of sub-teams, or a smaller project where different modules were being built by individuals. The sub-teams or individuals would conduct bottom-up testing of the modules which they were constructing before releasing them to an integration team which would assemble them together for top-down testing.
User Acceptance Testing (UAT) is a process to obtain confirmation by a Subject Matter Expert (SME), preferably the owner or client of the object under test, through trial or review, that the modification or addition meets mutually agreed-upon requirements. In software development, UAT is one of the final stages of a project and will often occur before a client or customer accepts a new system.
Users of the system will perform these tests which, ideally, developers have derived from the client's contract or the user requirements specification.
Test designers will draw up formal tests and devise a range of severity levels. The test designer may or may not be the creator of the formal test cases for the same system. The focus is on a final verification of the required business function and flow of the system, emulating real-world usage of the system. The idea is that if the software works as intended and without issues during a simulation of normal use, it will work just the same in production. These tests are not focused on fleshing out simple problems (spelling mistakes, cosmetic problems) or show stoppers (major problems like the software crashing, software will not run etc.). Developers should have worked out these issues during unit testing and integration testing.
The results of these tests will give confidence to the customers of how the system will perform in production.
