Design And Implementation Of A Distributed Recruitment Management System

4.2.4    Implementation Tools
The tools needed for the implementation of the recruitment management system are as follows:
Eclipse IDE: The bootstrap framework used to develop the front end of the R.M.S was utilised in eclipse integrated development environment here the framework was adapted to suit the needs of the R.M.S. Eclipse was also used to implement the logic of the R.M.S in PHP.
Apache WampServer: Apache Wampserver was used to simulate the client server architecture implemented by the R.M.S by utilising my personal computers home port number (127.0.01) as a server port number thus transforming my P.C to both a Client and a Server simultaneously.
MySQL DBMS: MySQL database management system was used to provide a graphical interface for the creation of the R.M.S database and tables within the R.M.S. It also provided integrity checks to ensure that data stored within the databases tables thus conformed to the specifications set out by the R.M.S thus ensuring that the information provided by the R.M.S is correct at all times.
4.3    Testing
The ultimate objective of testing is to ensure that the system performs as designed and expected and to ensure that it meets the user’s needs. More specifically, testing is the process
of exercising the system and its components to locate, investigate, and correct errors and bugs. A testing process is said to be successful if faults are identified. Effective testing does not just happen; it must be carefully planned. A complete test plan incorporates testing strategies, testing procedures, test data, and a testing schedule.
Testing can be performed as either top-down or bottom-up. Test procedures are required for creating test data
There are several level of testing, they include:
4.3.1    Pilot testing
Pilot testing is concerned with installing a system on a user site (or a user simulated environment) for testing against continuous and regular use It is one of the ways in which acceptance testing is carried out. It involves the users just before actual release if the software to ensure the users become familiar with the release contents and ultimately accepts it. Often it is considered a Move to Production activity for ERP releases or a beta test for commercial products. It typically involves many users and is conducted over a short period of time in tightly controlled conditions. The two forms of pilot testing are Alpha Testing and Beta Testing (Patrick Oladimeji, 2007).
Alpha testing is an internal acceptance testing carried out by the test team. This is usually done in preparation for beta testing. In beta testing, the system is released to a limited number of people to carry out further tests. Because the system is now in the hands of the public there is no formal methodology for testing. The most common method of testing is continuous use of the system to find out its weakness. These weaknesses are sent back to the developers as bug reports and these bugs are fixed in the next build of the system.
4.3.2    Integration testing
The testing of individual units helps in removing local faults, but does not exercise the interactions among different units. Integration testing is the activity of exercising such interactions by pulling together the different modules composing a system. It is characterized by involving different interacting units which have been in general developed by different programmers. In this case the code is still visible, but with a higher granularity. Faults that can be revealed by means of integration testing include interface problems, missing functionalities, and unforeseen side-effects of procedure invocation (as far as traditional procedural programming languages are concerned) (Carlo Ghezzi, 2004).
The above are only a few examples of all the possible problems that can arise during integration of a software system. In particular, many problems are language specific, or specific to classes of languages. Before choosing an integration testing strategy, it is thus very important to take into account the class of problems the test must address. For example, when using a strongly typed language, many different interface errors as the ones related to the wrong type of parameters in a procedure call can statically be identified and removed. The fundamental issue in integration testing is the choice of an integration order, i.e., the order in which the different units, or modules, are integrated. It is possible to identify five main strategies as far as the integration order is concerned, namely (Alessandro Orso, 2004):
=>   Top-down,
=>    Bottom-up,
=>    Big-bang,
=>    Threads,
=>    Critical modules.
The top-down integration strategy is the one in which the integration begins with the higher module in the hierarchy defined by the use relation among modules, i.e., it starts with the module that is not used by any other module in the system. The other modules are then added to the system incrementally, following the use hierarchy. In this way, there is no need for drivers, but complex stubs are needed.