Types of testing

White Box Testing - White box testing, sometimes called glass box testing is a test case design
method that uses the control structure of the procedural design to derive test cases. Using white box
testing methods, the software engineer can derive test cases that:

 Guarantee that all independent paths within a module have been exercised at least once.

 Exercise all logical decisions on their true and false sides.

 Execute all loops at their boundaries and within their operational bounds.

 Exercise internal data structure to assure their validity.

White box testing was performed at all levels of development of I-Admit. The coding team took all
care to test the code and guarantee that it meets all the specifications as well as logically correct. All
loops were tested and all internal data structures evaluated and verified.

Black Box Testing - It focuses on the functional requirements of the software. That is black box
testing enables the software engineer to derive sets of input conditions that will fully exercise all
functional requirements for a program. Black box testing is not an alternative to white box
techniques. Rather it is a complementary approach that is likely to uncover a different class of errors
than white box methods. Black box testing attempts to find errors in their following categories

 Incorrect or missing functions

 Interface errors

 Errors in data structures or external data base access

 Performance errors

 Initialization and termination errors.

Unlike white box testing, which is performed early in the testing process, black box testing is to be
applied during later stages of testing. Black box testing was performed with the application code of
the software being developed to verify that it is functionally correct and gives appropriate output at
different situations of inputs. It was also verified that the software takes a good care of exceptional
conditions and errors are handled well and that the software does not crash. A strategy for software
testing integrates software test case design methods into a well-planned series of steps that result in
the successful construction of software. In many ways, testing is an individualistic process, and the
number of different types of tests varies as much as the different development approaches.

Unit Testing - Unit testing focuses verification effort on the smallest unit software design- the
module. Using the procedural design description as a guide, important control paths are tested to
uncover errors within the boundary of the module. The module interface is tested to ensure that
information properly flows into and out of the program unit under test. The local data structure is
examined to ensure that data stored temporarily maintains its integrity during all steps in
algorithmic execution. Boundary conditions are tested to ensure that the module operates properly
at boundaries established to limit or restrict processing. All independent paths (bases paths) through
the control structure are exercised to ensure that all elements in a module have been executed at
least once. And finally, all error-handling paths are tested. Application interface of our system was
unit tested at all levels of implementation, right from start of code writing, to integrating the code
with other modules. Every module was tested fully to check its syntax and logical correctness. Error
handling was implemented into relevant modules so that the code doesn’t crash on errors.

Integration Testing - Integration testing is a systematic technique for constructing the program
structures, while conducting test to uncover errors associated with interfacing, the objective is to
take unit tested modules and build a program structure that has been dictated by design. User
interface of i-Admit was developed in modules. All of them were joined together to make the
complete running application. While integrating these modules, integration testing was performed
on them to verify that they meet all interfacing requirements and that they pass relevant
information among themselves.

Validation Testing - At the culmination of integration testing software is completely assembled as a

Alpha Testing - It is virtually impossible for a software developer to foresee how the customer will
really use a program. When custom software is built for one customer a series of acceptance tests
are conducted to enable the customer to validate all requirements. A customer conducts the alpha
test at the developer site. The software is used in a natural setting with the developer “looking over
the shoulder” of the user and recording errors and usage problem. Alpha tests are conducted in a
controlled environment. Alpha tests were performed at our development site with the help of our
friends, who were called and asked to run the program in the manner they like, without our
guidance and errors and usage problems were noted and code was updated to remove all of them.

Beta Testing - The Beta test is conducted at one or more customer sites by the end user of the
software. Unlike alpha testing the developer is generally not present. Therefore, the beta test is a
live application of the software in an environment that cannot be controlled by the developer. The
customer records all problems that are encountered during beta testing and reports these to the
developer at regular intervals. As a result of problems reported during beta test the software
developer makes modification and then prepares for the release of software product to the entire
customer base. Beta testing of our system is not performed as the product is not yet fully developed
and has not been installed at the user site as it still is in the development phase. Beta testing will be
performed when the software is deployed at the user’s site.

System Testing - Ultimately software is incorporated with other system elements (new hardware,
information) and a series of system, integration and validation tests are conducted. It is actually a
series of different tests whose primary purpose is to fully exercise the computer-based system.
Although each test has a different purpose all work to verify that all system elements have been
properly integrated and perform allocated functions. System testing of this system was performed at
the development lab of this system by integrating 34 the functional systems to imitate the actual
work environment. Since no special hardware was needed for this purpose, the testing proceeded
and succeeded with no errors.

Recovery Testing - Many computer-based systems must recover from faults and resume processing
within a pre-specified time. In some cases, a system must be fault tolerant that is processing faults
must not cause overall system function to cease. Recovery testing is a system test that forces the
software to fail in a variety of ways and verifies that recovery is properly performed. If recovery is
automatic, re-initialization, check pointing mechanisms, data recovery, and restart are each
evaluated for correctness. If recovery requires human intervention the meantime to repair is
evaluated to determine whether it is within acceptable limits.

Security Testing - Security Testing attempts to verify protection mechanism built into a system will in
fact protect it from improper penetration. Security is provided for each user by giving them login
name and password. Security testing was done, as any other anonymous user can’t log in with a user
password if the user is already logged in.

Performance Testing - Performance Testing is designed to test run time performance of software
within the context of an integrated system. Performance Testing occurs throughout all steps in the
testing process. Performance tests are often coupled with stress testing and often require both
hardware and software instrumentation. That is, it is often necessary to measure resource utilization
in an exacting fashion. External instrumentation can monitor execution intervals, log events as they
occur, and sample machines take on a regular basis. By instrumenting a system, the tester can
uncover situations that lead to degradation and possible system failure.