COLLEGE OF TECHNOLOGY

DIPLOMA IN BUSINESS INFORMATION TECHNOLOGY

DBIT 506
MOUREEN MIGARE 19 /06101
0115387431
HOSPITAL VACCINE SYSTEM

SYSTEM TEST PLAN

SUPERVISOR :MR. MADARA

TABLE OF CONTENTS

TEST PLAN:...................................................................................
INTRODUCTION: ..........................................................................................................
TEST PLAN OBJECTIVES:.................................................................................
TEST PLAN SCOPE:..............................................................................................
USER VALIDATION .........................................................................................................
DATA ENTRY AND STORAGE ...........................................................................................
DATA RETRIEVAL.....................................................................................
ERROR REPORTING AND RECOVERY ...............................................................................
MAJOR CONSTRAINTS ..................................................................................................
TEST PLAN: ....................................................................................................................
TEST PROCEDURE:.........................................................................................................
UNIT TESTING ......................................................................................................
MODULE TESTING........................................................................................................
INTEGRATION TESTING ..................................................................................................
SYSTEM TESTING.........................................................................................
VALIDATION TESTING..........................................................................................
USABILITY TESTING........................................................................................................
ACCEPTANCE TESTING....................................................................................................
SECURITY TESTING .........................................................................................................
TESTING TOOLS AND ENVIRONMENT.............................................................................
HARDWARE REQUIREMENTS ...............................................................................
SOFTWARE REQUIREMENTS .................................................................................
TEST SCHEDULE.......................................................................................
POST CONDITIONS .........................................................................................................
Alpha test..................................................................................................
Beta test ............................................................................................................
CONCLUSION..................................................................................
RECOMMENDATION ....................................................................................................

TEST PLAN:
INTRODUCTION:
Testing refers to the subjection of a program to a series of inputs to determine if the program
meets the expected conditions by giving the expected results. One of the objectives is to
determine if the program has any defects, errors or unexpected behavior.
The general testing process involves: testing of individual program units for example;
objects, testing of sub-systems/modules that consist of many units working together and
finally the testing of the whole system
of integrated sub systems. Also this phase determines whether the project can undergo the
real time
Environment execution without any break downs.

TEST PLAN OBJECTIVES:

The major goals of testing the system are as follows;
● To develop an appropriate test schedule.
● To establish test cases for the system.
● To test the various fields in the system for invalid entries.
● To analyze and compare the test results with expected test results.
● To find out if the system meets its functional requirements stated in SRS.
● To deal with any errors that may occur during running of the system.
● To ensure that the system is comprehensive and acceptable to its users

TEST PLAN SCOPE:

This document will give a detailed step by step testing procedure for the different areas of
testing in the
system. The various areas of the system require different testing methods and the results will
be analyzed
and evaluated. The test will mainly be restricted to the following areas;

USER VALIDATION
The system should authenticate the user by prompting him/her to enter the credentials where
the user is
allowed to gain access to the system else if the credentials are not valid, then the user cannot
access any
information from the system.

DATA ENTRY AND STORAGE

The system allows users to enter their required data and is verified and submitted to store it in
the centralized
location known as a database
.
DATA RETRIEVAL
All records will be stored in the database. The system Admin or the user will query the
system database to retrieve any information. The user will be able to retrieve any information
that is accessible to him/her through the search box where some specifications have been
made.

ERROR REPORTING AND RECOVERY

The system will provide an error message incase wrong inputs are made for example when a
user inputs a
password that does not match with the re-entered password. The system is more robust and
can be able to
handle errors if they occur. Incase the user forgets the password, the system provides a way to
recover the
password which is fast and efficient to recover.

MAJOR CONSTRAINTS
● Hardware constraints > The tests to be carried out will require certain computer
components that
the agency may take a while to acquire and therefore pose a major constraint on the testing.
● Software constraints > Genuine software is rather expensive and the developer may
have a problem
acquiring all genuine software needed to successfully run the tests.
● Monetary constraints > When undertaking any project money is always an issue, the
limited
resources will hinder the testing of the system.

TEST PLAN:
In this plan, the test time is identified, what is being tested and the expected output as well as
the actual inputs. The test plan is always written as soon as one has identified the
requirements. If a project lacks a test plan then the software produced will be low quality.
The system will be tested with sample data to see how it would handle input and output
functions as well as extreme data to determine the system behavior in overload situation
which will directly slow the system that behaves in failure or extreme situations. The
following testing are the ones to be done;
● Unit testing.
● Module testing.
● Integration testing.
● Acceptance testing.
● System testing.
● Usability testing.
● Validation testing.

UNIT TESTING
TYPE OF TEST
Unit testing
AREAS TESTED EXPECTED RESULTS
● Numeric fields Should accept numbers only
Character fields Should accept only text
● Login Should accept the correct
password and username.
● Datagrid view Should be able to display
database information.
● Date fields Should be selected from
calendar.
● Buttons Should be clicked to direct the
user.

MODULE TESTING
Involves testing for reliability and a module constitutes related components;
TYPE OF TEST
Module Testing
AREAS TESTED EXPECTED RESULTS
● New module Should add new record to the
database
● Delete module Should remove records from the database
● Next module Should move to the next record
● Previous module Should move to the previous record
● Search module Should find records specified by user from the database
● Edit module Should allow one to modify
● existing records
● First module Should move to the first record
● Last module Should move to the last record

INTEGRATION TESTING
This test proves that all areas of the system interface with each other correctly and that there
are no gaps in
the data flow. Final integration Test proves that the system works as integrated unit when all
the fixes are
complete.

TYPE OF TEST AREA TESTED EXPECTED OUTCOME

Integration Testing Do changes, updates and Input/changes or/and

inputs updates
made on the system reflect made reflect the ones in the
 the database respectively
changes in the database?

SYSTEM TESTING
This is whereby all units, sub-systems and objects are integrated together to form the whole
system. The
tests in this case include testing integration of the various units and checking that the overall
system gives
the desired results from the input entered.
TYPE OF TEST AREA TESTED EXPECTED OUTCOME
System Testing Does the system connect
successfully to the database?
Connection is successful

TYPE OF TEST AREA TESTED EXPECTED OUTCOME

System Testing Does the system connect Connection is successful

successfully to the database?

VALIDATION TESTING
This is intended to show that the system confirms to its specifications and that it meets the
expectation of
the customer buying the system. It involves checking processes like inspection and reviews at
each stage
of the development. It checks whether the system has met the functionalities of the users or
the requirements. The outcomes are:
● A deviation from the system and deficiency list is uncovered.
● The functional characteristics confirm to the specification are acceptable.
● The system is released to the users or customers to interact with it and in case there
are problems, the
developer makes changes to the required parts of the system

.USABILITY TESTING
It involves looking for bugs not in the functionality of the system program, but in the layout
and utility of
the user interface. It is often performed on a prototype before the actual system code is
written, so it’s easy
to change if needed. This is a situation where the user gives an opinion on what the user
interface is like. It also focuses on making sure the system is user friendly and users can use it
comfortably.

ACCEPTANCE TESTING
This is the verification that the final product meets the institutions” requirements. It ensures
that all the
components of the system are tested. It describes the acceptance testing process, such as the
features to be
tested, pass/fail criteria, approach to testing, roles and responsibilities, resources requirements
and schedule.
It also defines the functionality to be tested, the requirements verified by the test, test
precondition, test
steps and test.

SECURITY TESTING
The system is secure from unauthorized users. Error message box pop out every time wrong
credentials are
provided. The system is only accessible by users with the correct credentials or valid details.
The login
mechanism is put in place to ensure only registered customers will gain access to the system
information.
Different users of the system are provided with different login details that allow them access
different
functionalities of the system.

TESTING TOOLS AND ENVIRONMENT

HARDWARE REQUIREMENTS
1. Flash disk.
2. Computer
3. Printer
4. Compact disk
5. Uninterruptible power supply(UPS)

SOFTWARE REQUIREMENTS

Operating system; windows 8.1

Programing language; VB.Net
Database system; Microsoft Access
Antivirus software; AVG and 360 Total Security

POST CONDITIONS
Alpha test
In this test, international testers run live data through the system checking out for bugs not
found in integration test.
Beta test
This is the next step where the program is actually released to the users with the
understanding that the program is being tested. Through this the expected user is able to
identify the errors, which are reported to
the developer and then corrected.

CONCLUSION
The program was able to fulfill its basic functionality, it was able to login, to search and
display the
alternatives of the search criteria, to confirm all patients records.
The application of Microsoft access and visual basic programming helped make the work
much easier
since it allowed the use of objects to represent real life entities containing both attributes and
behavior.

RECOMMENDATION
The developer would like to see the program include data type validation to ensure that only
the correct
data type is entered.