CHAPTER FIVE

TESTING AND IMPLEMENTATION PHASE

5.0 INTRODUCTION
Testing is a process, which reveals errors in the program. It is the major quality
measure employed during software development. During software development.
During testing, the program is executed with a set of test cases and the output of the
program for the test cases is evaluated to determine if the program is performing as it
is expected to perform.

Testing is the process in which the system is run on manually created input so that the
system is correctly working as desired or not, during systems testing, the system is
used experimentally to ensure that the software does not fail. In other words, we can
say that it will run according to its specifications and in the way users expect. Special
test data are input for processing, and the results examined.

A limited number of users may be allowed to use the system so that analyst can see
whether they try to use it in unforeseen ways. It is desirable to discover any surprises
before the organization implements the system and depends on it.

This phase determine the error in the project. If there is any error then it must be
removed before delivery of the project. For determining errors various types of test
action are performed.

5.1 TYPES OF TESTING

A. Unit Testing: Unit testing focuses verification effort on the smallest unit of
software design – the module. Using the detail design description as a guide,
important control paths are tested to uncover errors within the boundary of the
module. The relative complexity of tests and the errors detected as a result is
limited by the constrained scope established for unit testing. The unit test is
always white box oriented, and the step can be conducted in parallel for multiple
modules.

Unit testing is normally considered an adjunct to the coding step. After source
level code has been developed, reviewed, and verified for correct syntax, unit test

1
case design begins. A review of design information provides guidance for
establishing test cases that are likely to uncover errors. Each test case should be
coupled with a asset of expected results.

Because a module is not a stand-alone program, driver and/or stub software must
be developed for each unit test. In most applications a driver is nothing more than
a main program that accepts test case data passes such data to the module(to be
tested), and prints the relevant results. Stubs serve to replace modules that are
subordinate (called by) the module to be tested. Stub or “dummy subprogram”
users the subordinate modules interface may do minimal data manipulation, prints
verification of entry and returns.

Drivers and stubs represent overhead. That is, both are software that must be
written but that is not delivered with the final software product. If drivers and
stubs are kept simple, actual overhead is relatively low. Unfortunately, many
modules cannot be adequately unit tested with “simple” overhead software. In
such cases, complete testing can be postponed until the integration test step.

Unit testing is simplified when a module with high cohesion is designed. When
only one function is addressed by a module, the number of test cases is reduced
and errors can be more easily predicted and uncovered.

Each module can be tested using the following two Strategies:

Black Box Testing:

In this strategy some test cases are generated as input conditions that fully execute all
functional requirements for the program. This testing has been uses to find errors in
the following categories:
 Incorrect or missing functions
 Interface errors
 Errors in data structure or external database access
 Performance errors
 Initialization and termination errors.
In this testing only the output is checked for correctness. The logical flow of the data
is not checked.

2
White Box testing:

In this the test cases are generated on the logic of each module by drawing flow
graphs of that module and logical decisions are tested on all the cases. It has been uses
to generate the test cases in the following cases:

 Guarantee that all independent paths have been executed.

 Execute all logical decisions on their true and false Sides.
 Execute all loops at their boundaries and within their operational bounds
 Execute internal data structures to ensure their validity.

B. Integrating Testing: Integration testing ensures that software and subsystems

work together a whole. It tests the interface of all the modules to make sure that the
modules behave properly when integrated together. Integration testing is a
systematic technique for construction the program structure while at the same time
conduction 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.

Integration testing can be categorized into two types, namely top-down integration or
bottom-up integration. Top-down integration is an incremental approach to the
construction of program structure. Modules are integrated by moving downward
through the control hierarchy, beginning with the main control module. Modules
subordinate to the main control module are incorporated into the structure in either a
depth-first or breadth-first manner. The bottom-up integration testing as its name
implies, begins construction and testing with atomic modules. Because modules are
integrated for the bottom up processing required for modules subordinate to given
level is always available and the need for stubs is eliminated.

The selection of an integration strategy depends upon software characteristic and,

sometime project schedule. In general, a combined approach that uses the top-down
strategy for the upper levels of the program structure, coupled with a bottom-up
strategy for the subordinate levels, may be the best compromise.

C. System Testing: Involves in-house testing of the entire system before delivery to
the user. Its aim is to satisfy the user the system meets all requirements of the client's
specifications.

3
A classics system testing problem is “finger pointing”. This occurs when a defect
is uncovered, and one system element developer blames another for the problem.
Rather than including in such nonsense, the software engineer should anticipate
potential interfacing problems and (1) design error handling paths that test all
information coming from other elements of the system.(2) conduct a series of tests
that simulate bad data or other potential errors at the software interface; (3) record
the results or tests to use as “evidence” if finger pointing does occur (4) participate
in the planning and design of system test to ensure that software is adequately
tested.

There are many types of system tests, which are worthwhile for software-based
systems, as detailed hereunder:
 Recovery testing is a system test that forces the software to fail in a variety
of ways that verifies that recovery is properly performed.
 Security testing attempts to verify that protection mechanisms built into a
system will protect it from improper penetration
 Stress tests are designed to confront programs with abnormal situations.
 Performance testing is designed to test the run-time performance of
software within the context of an integrated system.

5.2 DOCUMENTATION

Documentation describes an information system and helps the users who must
interact with it. Accurate documentation can reduce system downtime, cut
cost, and speed up maintenance task.

Documentation is essential for successful system operation and maintenance.

In addition to supporting a system’s users, accurate documentation is
essential for developers who must modify the system, add new features or
perform maintenance.

Documentation includes program documentation and user documentation.

4
 A. PROGRAM DOCUMENTATION

The program documentation is a kind of documentation that gives a comprehensive

procedural description of a program. It shows as to how software is written. Program
documentation even has the capability to sustain any later maintenance or
development of the program. The program documentation describes what exactly a
program does by mentioning about the requirements of the input data and the effect of
performing a programming task.

Input Types
It is necessary to determine the various types of inputs. Inputs can be categorized as
follows:
 External inputs, which are prime inputs for the system.
 Internal inputs, which are user communications with the system.
 Operational, which are computer department’s communications to the system?
 Interactive, which are inputs entered during a dialogue.
Input Media
At this stage choice has to be made about the input media. To conclude about the
input media consideration has to be given to;
 Type of input
 Flexibility of format
 Speed
 Accuracy
 Verification methods
 Rejection rates
 Ease of correction
 Storage and handling requirements
 Security
 Easy to use
 Portability

Keeping in view the above description of the input types and input media, it can be
said that most of the inputs are of the form of internal and interactive. As
Input data is to be the directly keyed in by the user, the keyboard can be considered to
be the most suitable input device.
B. SYSTEM DOCUMENTATION

5
System documentation includes all of the documents describing the system itself from
the requirements specification to the final acceptance test plan. Documents describing
the design, implementation and testing of a system are essential if the program is to be
understood and maintained. Like user documentation, it is important that system
documentation is structured, with overviews leading the reader into more formal and
detailed descriptions of each aspect of the system. System documentation describes
the system’s functions and how they are implemented.

Following is a list of functionalities of the system:

Administrator:-

In this module the Administrator has the privileges to add all the Employees and register
them in the organization and check the information of the Employee and check the status
of the leave when they have taken and what type of leave they have taken and search is
done based on the employee and report is generated based on employee.

Search:-

This module contain complete search like Leave search, Type of Leave, Employee based
on the leave and starting and ending day of leave.

Employee:-

In this module employee has the privileges to use his username and password for login
and he can see the request given by the customer and he can pass the process to the
Business Manager and maintain the record of the customers.

Reports:-

This module contains all the information about the reports generated by the
Employees based on the Performance and by the leave status.

Authentication:-

This module contains all the information about the authenticated user. User without
his username and password can’t enter into the login if he is only the authenticated
user then he can enter to his login.

Test case scenario

6
In the following scenario we are documenting some of test cases as a sample

Test case ID: 01

Test case name: login
Input: username and password
Expected output: login to the system
Produced output: login to the system

Test case ID: 02

Test case name: registration
Input: employee detail
Expected output: record created successfully message
Produced output: record created successfully.

Test case ID: 03

Test case name: Apply leave
Input: Leave detail
Expected output: Leave requested successfully
Produced output: Leave requested successfully

Test case ID: 04

Test case name: salary payment
Input: salary detail
Expected output: paid successfully message employee salary
Produced output: paid successfully message employee salary

Test case ID: 05

Test case name: view detail
Input: employee name and employee number.
Expected output: employee detail
Produced output: employee detail

Test case ID: 06

Test case name: update record

7
Input: employee detail
Expected output: updated successfully message
Produced output: updated successfully message

C. USER DOCUMENTATION

User documentation consists of instructions and information to users who will interact
with the system and includes user manuals help screen.

A person should be able to

1) Login to the system through the first page of the application.

2) Change the password after logging into the system.

3) See his/her eligibility details (like how many days of leave he/she is eligible
for etc.).

4) Query the leave balance.

5) See his/her leave history since the time he/she joined the company/college.

6) Apply for leave, specifying the from and to dates, reason for taking leave,
address for communication while on leave and his/her superior’s email id.

7) See his/her current leave applications and the leave applications that are
submitted to him/her for approval or cancellation.

8) Approve/reject the leave applications that are submitted to him/her.

9) Withdraw his/her leave application (which has not been approved yet).

10) Cancel his/her leave (which has been already approved). This will need to be
approved by his/her Superior.

11) Get help about the leave system on how to use the different features of the
system.

5.2.1 USER GUIDE/MANUAL

When a user runs the application the first interface that comes up is the login
interface, the login interface enables different users such as staffs and the
administrator to select their account type by choosing from the combo-box
option available at the interface and login with their login credentials

8
(username and password) using the text-boxes to fill the information and
click on the login button to proceed.

Figure 5.1: Login Page

Suppose a user select his account type as “Administrator” and fills in the correct login
credentials on the login interface and then click on login button, the system will log
him into the Admin interface, the Admin page allows a user to navigate around the
admin interface easily which enables him to manage login credentials, view
dashboard, add new employee to the system, view leave records, manage leave and
also manage leave requests by simply clicking on any of the buttons below.

Figure 5.2: Home Page

The important functions of the normal users include the following:

 Sending registration form to administrator
9
  Changing his/her account information like the password.
 Viewing Information about the tourism.

5.2.2 IMPLEMETATION

Implementation is a realization of technical specification or algorithm as a program,

software component through computer programming and deployment (Joshua. 2016).
This chapter describes the different phases of the EMS with regards with how the
system is developed, implemented and tested using the suitable tools, programming
language and technology.

At the previous chapter, the paper began with the description of requirements analysis
and design of the proposed system in details, and in this chapter the paper shall
explore the several aspects of the joined system that weighs the leave and attendance
management combined, outlining the procedures carried out during the testing
procedure and finger print implementation which refines the function of the system
and guide users on how to operate. The following materials listed below are the
hardware and software components used for the implementation of the system for
which this report has been written.

Main Features
The main features added to the system include:

 Employee profiles
 Leave management
 Admin profile
 Dashboard

All these added features have the function of adding user, updating, deleting and
retrieving data through the search function. It also has the ability to generate report
automatically and sends email notifications to the admin. The system is implemented
under the following hierarchy of access.

It has two main access levels:

 The Administrator

10
  Employee

All the users are warped to one login interface making each user to login through the
means of valid user-ID, password and user type combination. After accessing the
system, the administrator has the ability to perform various task like assigning role to
a user which will determine his access level. The employee on the other hand has a
unique fingerprint template preserved in the system during registration which enables
him to mark his attendance on daily work days.

Consistent, the application was built with similar look on every page having the same
navigation, header, background image and logo.

Easy navigation for users in order to amble around the system with the help of the
system’s navigation buttons which are clearly presented and labeled pointing user to
the intended page. The use of text font and colors where carefully considered to
provide visual appeal.

Data Validation

Procedures are designed to detect errors in data at a lower level of detail.

Data validations have been included in the system in almost every area
where there is a possibility for the user to commit errors. The system will
not accept invalid data. Whenever an invalid data is keyed in, the system
immediately prompts the user and the user has to again key in the data and
the system will accept the data only if the data is correct. Validations have
been included where necessary.

The system is designed to be a user friendly one. In other words the

system has been designed to communicate effectively with the user. The
system has been designed with popup menus. The validation criteria in this
project are as follows.

In Portal System also, the user inputs are validated before storing them,
and then further for displaying etc. The main validations that are done in
Portal System are as follows: – All the screens have a similar look and
feel. They all have the almost same color combinations in its background.

This provides a better user interface to the users.

11
 I. The primary key values cannot be duplicated.

II. All the entries in any combo box have been sorted in
alphabetical order. This helps a user while selecting a value
from the combo box.

5.3 HARDWARE AND SOFTWARE CONFIGURATION

In this phase we used two major types of configuration including:-

[Link] HARDWARE SPECIFICATION

The selection of hardware is very important in the existence and proper
working of any software. In the selection of hardware, the size and the
capacity requirements are also important.

The Web Based Manufacturing System can be efficiently run on Pentium

system with at least 128 MB RAM and Hard disk drive having 20 GB.
Floppy disk drive of 1.44 MB and 14 inch Samsung color monitor suits the
information system operation.(A Printer is required for hard copy output).

 Pentium processor -------- 233 MHZ or above

 RAM Capacity -------- 128MB or above
 Hard Disk -------- 20GB
 Floppy disk -------- 1.44 MB
 CD-ROM Drive -------- 32 HZ
 Keyboard -------- 108 Standard

[Link] SOFTWARE SPECIFICATION

One of the most difficult tasks is that, the selection of the software, once
system requirement is known is determining whether a particular software
package fits the requirements. After initial selection further security is
needed to determine the desirability of particular software compared with
other candidates.
 Operating System -------- Windows 7 or above
 Browser -------- IE, Chrome

12
 Web/Application Server -------- apache web server

 Database Server -------- MySQL

 Database Connectivity -------- JDBC

 Other Tools & Technologies -------- PHP, HTML,CSS

13