8 SYSTEM TESTING

The goal of testing is to improve the programs quality. Quality is assured

primarily through some form of software testing. The history of testing goes back to
the beginning of the computing field. Testing is done at two Levels of Testing of
individual modules and testing the entire system. During the system testing, the
system is used experimentally to ensure that the software will run according to the
specifications and in the way the user expects. Testing is very tedious and time
consuming. Each test case is designed with the intent of finding errors in the way the
system will process it.

The purpose of testing is to discover errors. Testing is the process of trying to

discover every conceivable fault or weakness in a work product. It provides a way
to check the functionality of components, sub-assemblies, assemblies and/or a
finished product. It is the process of exercising software with the intent of ensuring
that the Software system meets its requirements and user expectations and does not
fail in an unacceptable manner. There are various types of test. Each test type
addresses a specific testing requirement.

8.1 LEVELS OF TESTING

The software underwent the following tests by the system analyst.

8.1.1 White Box Testing

 By using this technique it was tested that all the individual logical paths were
executed at least once. All the logical decisions from validating the user to checking
the accountability of a doctors role of login and communication between the
patients were tested on both their true and false sides. All the loops were tested with
data in between the ranges and especially at the boundary values.

Thus in white box testing we the software tester has knowledge of the inner
workings, structure and language of the software used, or at least its purpose. It is
purpose. It is used to test areas that cannot be reached from a black box level.

8.1.2 Black Box Testing

By the use of this technique, the missing functions like index1, index2 and
inbox modules were identified and placed in their positions. The errors in the
interfaces especially the connectivity error with the MySQL database were identified
and corrected by replacing the correct placeholder to indicate the user with proper
format for the date. This technique was also used to identify the initialization of log-
in and termination errors of log-out and correct them.

Thus in black box testing without any knowledge of the inner workings,
structure or language of the module being tested based on certain common
programing and logical skills. Black box tests, as most other kinds of tests, must be
written from a definitive source document, such as specification or requirements
document, such as specification or requirements document. It is a testing in which
the software under test is treated, as a black box .you cannot see into it. The test
provides inputs and responds to outputs without considering how the software
works.
8.1.3 Unit Testing

It is the verification of a single module usually in the isolated environment.

The System Analyst tests each and every module individually by giving a set of
known input data and verifying for the required output data. The System Analyst
tested the software Top Down model starting from the top of the model. The units
in a system are the modules and routines that are assembled to perform a specific
function. The modules should be tested for correctness of login applied and should
detect errors in coding. This is the verification of the system to its initial objective.
This is a verification process when it is done in a simulated environment and it is a
validation process when it is done in a line environment.

Unit testing involves the design of test cases that validate that the internal
program logic is functioning properly, and that program inputs produce valid
outputs. All decision branches and internal code flow should be validated. It is the
testing of individual software units of the application .it is done after the completion
of an individual unit before integration. This is a structural testing, that relies on
knowledge of its construction and is invasive. Unit tests perform basic tests at
component level and test a specific business process, application, and/or system
configuration. Unit tests ensure that each unique path of a business process performs
accurately to the documented specifications and contains clearly defined inputs and
expected results.

Unit testing is usually conducted as part of a combined code and unit test
phase of the software lifecycle, although it is not uncommon for coding and unit
testing to be conducted as two distinct phases.
Test strategy and approach
Field testing will be performed manually and functional tests will be written
in detail.

Test objectives

All field entries must work properly.

Pages must be activated from the identified link.
The entry screen, messages and responses must not be delayed.

Features to be tested

Verify that the entries are of the correct format

No duplicate entries should be allowed
All links should take the user to the correct page.

Modules tested under unit-testing:

Patient Registration:
In this module problem was encountered with the form validation like
verification of the validity of email, date of birth format and password
confirmation this was rectified by using java-script validation code and Html5
form validation.
Logoff Module of both patient and doctor:
Even though http-session was used for tracking of user but when logoff button
the session just was failed to expire. (That is we can just go back to old pages
 using back button of the browser) This problem was rectified by including the
java-script code by disabling the back button once the logoff was clicked.
Patient Service:
In this module the problem of control flow was persisting that is from services
offered page if click the home tab it took us to the initial home page with login
tab as before this was eliminated by creating a new index page and
hyperlinking with the existing page.
Patient Communication:
In the communication module the status of doctor online and offline was
known only by manually pressing the refresh button. This was modified to
enhance the user experience by adding a java-script code for auto refresh in
the existing page.

8.1.4 Integration Testing

The purpose of unit testing is to determine that each independent module is

correctly implemented. This gives little chance to determine that the interface
between modules is also correct and for this reason integration testing must be
performed. One specific target of integration testing is the interface. Whether
parameters match on both sides as to type, permissible ranges, meaning and
utilization. Module testing assures us that the detailed design was correctly
implemented; now it is necessary to verity that the architectural design specifications
were met. Chosen portions of the structure tree of the software are put together. Each
sub tree should have some logical reason for being tested. It may be a particularly
difficult or tricky part of the code; or it may be essential to the function of the rest
of the product. As the testing progresses, we find ourselves putting together larger
and longer parts of the tree, until the entire product has been integrated.
 Integration tests are designed to test integrated software components to
determine if they actually run as one program. Testing is event driven and is more
concerned with the basic outcome of screens or fields. Integration tests demonstrate
that although the components were individually satisfaction, as shown by
successfully unit testing, the combination of components is correct and consistent.
Integration testing is specifically aimed at exposing the problems that arise from
the combination of components.

Software integration testing is the incremental integration testing of two or

more integrated software components on a single platform to produce failures caused
by interface defects.

The task of the integration test is to check that components or software

applications, e.g. components in a software system or one step up software
applications at the company level interact without error. Some of common error
encountered while integration testing were,

Problem encountered with logoff from doctor login that is the failure of
redirecting properly to desired web-page.
In patient registration the patient while entering the password and
conformation password the program is not validating the correctness of both
the inputs.

8.1.5 Functional test

Functional tests provide systematic demonstrations that functions tested are
available as specified by the business and technical requirements, system
documentation, and user manuals.
Functional testing is centered on the following items:

Valid Input : identified classes of valid input must be accepted.

Invalid Input : identified classes of invalid input must be rejected.

Functions : identified functions must be exercised.

Output : identified classes of application outputs must be exercised.

Systems/Procedures: interfacing systems or procedures must be invoked.

Organization and preparation of functional tests is focused on requirements, key

functions, or special test cases. In addition, systematic coverage pertaining to
identify Business process flows; data fields, predefined processes, and successive
processes must be considered for testing. Before functional testing is complete,
additional tests are identified and the effective value of current tests is determined.

8.1.6 Validation Testing

The main aim of this testing is to verify that the software system does what it was
designed for. The system was tested to ensure that the purpose of automating the
system Machine Order. Alpha testing was carried out to ensure the validity of the
system.

8.1.7 Output Testing

Asking the users about the format required by them tests the outputs generated
by the system under consideration .The output format on the screen is found to be
correct as the format was designed in the system design. Output testing was done
and it did not result in any change or correction in the system.
 8.1.8 User Acceptance Testing
User Acceptance Testing is a critical phase of any project and requires
significant participation by the end user. It also ensures that the system meets the
functional requirements.

The system under consideration is tested for user acceptance by constantly

keeping in touch with prospective system users at time of developing and making
changes whenever required. The following points are considered.

Input screen design

Output screen design

Online message to guide the user

Menu driven system

Format of adhoc queries and reports

8.1.9 Performance Testing

Performance is taken as the last part of implementation. Performance is
perceived as response time for user queries, report generation and process related
activities.

8.2 Test Cases:

We are following Ad-Hoc testing.

Test Test Case Test Case Expected Result Actual Test Test Test
Case Name Description Result Result Seve Priority
Id rity
(P/F)
001 Login Login stage To verify login Login P - -
(Patient & name, password successful
Doctor)

002 RegistratiEnter the Registration Registrati P - -

on require successful on
details and successful
(Both in
login
Patient &
Doctor)

003 RegistratiClick Must show error Registrati F High 1

on submit by on
leaving successful
(Both in
certain
Patient &
fields blank.
Doctor)

004 Logoff Click logoff It must take you Logoff P - -

button to login page successful
(Both in
Patient &
Doctor)

005 After- Click back The previous But the F Very -

Logoff button of the session must be previous High
web page expired. session
(Both in
was
Patient &
displayed
Doctor)

006 Online / A) When Status of doctor It shows P - Low

Offline Doctor is must be online in desired
Status online. patient module. result only
on
b) When Status of doctor
refreshing
Doctor is must be offline.
the page in
offline.
 both the
case.

007 Selection Enter the Retrieve As P - -

of medicine information from expected
medicine details database