LUCY NYAMBURA KINYUA.

15/02506.
BBIT.
PART TIME.
TEST PLAN DOCUMENT.
1.0 INTRODUCTION.
This is the Software Test Plan for the Automatic Payroll System with Image Capturing. The
automated payroll system project satisfies mostly the needs of the Human Resource Department
of a company to manage employees’ personal data (citizen identity number, name, surname,
birthdate, birthplace, educational information etc.), annual leaves, payroll, performance evaluation
and so on. In order to develop a consistent, durable, reliable and well-integrated system which will
be introduced to the end users soon, there has to be a testing procedure with a satisfying procedure
and plan. For this purpose, this document is prepared.

1.1 Goals and objectives.

This document is aimed at giving a detailed plan of test strategy, test schedule, resources,
environment for performing Unit test, Integration test, System test and Acceptance test of the
payroll system. This Software Test Plan supports the following objectives.
 Define the activities required to prepare for and conduct System together with User Acceptance
testing.
 To communicate to all responsible parties, the tasks which they are to perform.
 Communicate to all responsible parties the System Test strategy.
 Define deliverables and responsible parties.
 Communicate to all responsible parties the various Dependencies and Risks.
 To define the test tools and environment needed to conduct the software tests.
With the help of the testing platform the aim is to have a project with the following quality criteria
being satisfied;
 Being error-free
 High performance
 Logically correctness
 Compatibility between modules
 Easy-to-use
 Genuinely real-time

1.2 Statement of scope.

This document describes the plan and procedures that will be used to verify that the payroll system
performs as specified in the Software Requirements Specification (SRS). The scope of this
document is to cover development and testing of the system. It also covers descriptions of the
methods used in the testing process of the payroll system, plan of the testing phase, procedures to
be followed and techniques of keeping records during testing. During the development of the
project, each component of every module is supposed to be tested by the responsible developer
right after its implementation is finished. It is necessary to have a comprehensive and systematic
plan for testing the code units as they are developed and integrated into the overall system. This
plan will address all testing that will occur. The test scope includes the following:
 Testing of all functional, application performance, security and use cases requirements.
 End-to-end testing and testing of interfaces of all systems that interact with the payroll system.

1.3. Major Constraint.

1. Time.
Time is a major constraint since we have a limited time period to complete the project. Thus, the
duration period that can be reserved for testing process will clearly affect the result.
2. Data.
Since the payroll system is composed of many modules running concurrently and passing data to
each other during the run, minimizing the amount of data being transferred between modules is a
goal in the sense of data constraint.
3. Number of People in the Team.
Testing process is also limited with the number of people in the team since concurrent processes
speed up the whole testing process. The testing process will be as fast-moving as number of people
in the team can serve.
4. Hardware Device Capabilities.
Our project is partially dependent on hardware devices. For example, it is dependent on CPU
capabilities since we are trying to implement a real-time system. During both functional and
behavioral testing, since we use hardware devices that we can afford, testing and surely the future
of the project will be affected.
5. Test Results over Costs.
Test results over cost ratio are also another constraint in testing. If a test is not useful as it costs, it
will be postponed and more useful tests will be regarded as more important. This manner will also
affect the testing procedure.

2.0 TEST PLAN.

This section describes the overall testing strategy that we are going to use for testing the payroll
system project.

2.1 Software (SCI’s) to be tested.

The payroll system project is being developed mostly for organizations for their HR department
who wants to control and manage their employee’s data in a more appropriate and neat way. With
the help of the payroll system they will be able to manage their personal data, control mechanism
to authorize and authenticate for the employees’ entry in a better way, attendance of the employees
and their payroll. They will be able to save all the data regarding to their employee's including
their attendance and payroll info. The admin will be able to add/delete new user/employee to/from
the system. Any record of the data they add, edit and delete will be kept in the payroll system
database in a secure manner. With all this data info it will be easy for organizations to ensure
efficient payment and attendance of the employees. All components and their integration and
finally all system will be tested in testing phase.

2.2. Testing strategy.

In this document, the whole testing process of the payroll system is described. A bottom-up
approach test methodology will be used. First the units are tested separately and then their
integrations are tested. After those application based tests, their validation tests from previous
reports are declared. Finally, high-order tests are explained. All steps of testing process which are
completed, still in progress and planned to be made in the future will be stated in the following
sections.

2.2.1. Unit testing.

The payroll system project includes two main components to undergo unit testing, first one is
Database Handler and the other is Interface handler. In this two units there are three modules.
First one is admin module, the second is employee self service module and finally the Payroll
module. Those two components are tested separately in order to make sure that each component
does not have any internal errors and works properly.

2.2.2. Integration Testing.

Integration testing will focus on testing the interfaces between code units, components, and
subsystems (Module). It is the responsibility of the developer who wrote the code module to find
and fix the defect. Once the defect has been found and fixed, the integration test must be repeated.
After all the modules pass the unit testing, they get to be tested whether they work correctly when
they are running concurrently and communicating to each other. This specification is vital since
although each module might be working individually, different implementations coming from
different modules may conflict while running together which is to be located during integration
testing and to be recorded for fixing. Integration tests of the payroll system mainly includes the
integration of main units, namely Database handler and Interface Handler.

2.2.3. Validation Testing.

Result of this test is going to show whether expectations in design are met or not. The Software
Requirements Specification document defines the functional and non-functional requirements of
the payroll system Project. Every single requirement in this document must be considered one-by-
one and the software must be guaranteed to satisfy all these requirements. Test cases and scenarios
are defined and will be run to ensure the correct working of the project as a whole. The order of
validation is the same as integration.

2.2.4. High‐order testing.

While computing unit testing and integration testing, there will be computing of some high-order
testing, namely; performance testing and alpha testing.
 2.2.4.1 Performance Tests.
Performance Tests will be made to see whether the program runs in real time as it should be.
Performance test will be conducted to ensure that the payroll system’s response times meet the
user expectations and does not exceed the specified performance criteria. During these tests,
response times will be measured under heavy stress and/or volume.

2.2.4.2 Alpha Tests.

To perform Alpha testing there will be assembling of the three existing role of the payroll system
project and make the accounts accordingly and perform alpha test on each role type. After this the
system will be checked to see whether the application has bugs or not.

2.3. Test Metrics.

The following metrics will be used:
 Number of Test Cases Executed
 Number of Bugs Detected
 Number of Bugs Fixed
 Number of Priority Bugs Fixed

2.4 Testing tools and environment.

Testing tools are important for the success of testing phase and naturally the success of product.
a) Hardware- A PC/Laptop with a hard disk space of about 2 GB full installation incl. two
language modules and a minimum of only about 1 GB installation incl. two language modules
and a memory of more than 512 MB with default cache settings.
b) Software- at least a work station which is a Windows 8 and above.
c) Database- MS SQL Server
d) Development languages- C #
e) Application server- Microsoft Visual Studio
f) Internet Explorer browser- to test system testing
As the payroll system project is an internet based project thus hardware won’t be an issue for
components of our model since network components are standard on most of the computers so the
only test environment for the payroll system application would be the operating system. As the
payroll system application is supposed to work under both Windows and Linux through the
existing internet browsers. In the tests, it will be guaranteed that all features of our application
work under both 32-bit and 64-bit operating systems on any internet browsers without any
problem.

2.5 Test Schedule.

A detailed test procedure schedule can be found on the following table:

Task. Dates.
Unit Testing Feb 7- Feb 14
Integration Testing Feb 15- Feb 22
 Validation Testing Feb 23- March 1
System Testing March 2- March 9
Table 1: Test Schedule.

3.0 TEST PROCEDURE.

In this section, the test strategies and methods will be explained in detail. The process of using
them and applying them to the project will be analyzed.

3.1. Unit test cases.

These test cases constitute the very basic test cases that are going to be used in order to find the
main beginning errors. Since the project mainly queries the database and display information via
graphical user interface, unit test cases can be classified in two main groups namely Database
Handler and Interface Handler. These are described in detail below;
Database Handler:
The payroll system uses a huge database containing database tables needed to keep information.
There are three basic functions implemented in the project namely add new information, edit the
existing information and delete information. Database handler will check these three functions
whether they are appropriately doing their work on the database in the intended way. Therefore,
our database handler test cases will be as follows.
 Whether the admin or HR can add new entry to the database successfully.
 Whether the admin or HR can edit the existing entries successfully.
 Whether the admin or HR can delete information successfully.
 Whether the employee can access their payroll and personal details.

Interface Handler: In order to manage the data, our project has a graphical user interface, designed
in a user-friendly manner. Interface handler will answer the questions below:
 Whether the fields, buttons, grids etc. are in the right place on the page.
 Whether the buttons are doing their work in an intended way.

3.2. Integration testing.

From the time that we integrate all the modules, the testing of the functionalities of each role type
comes on to the stage. Since payroll system project has security issues both in and out of the scope
of the employees there are specific permissions related to each user type (authorization) and
authentication mechanism. The Integration Testing Procedure is given below
a) Firstly, creation of three users who have the three role types namely, HR, employee, admin.
b) Then we will log in with the user names and passwords of each user type. This tests whether
the authentication mechanism works correctly.
c) Then we will also try some wrong user name and/or wrong password. We expect an error
message by trying this case. After testing authentication mechanism, we are going to test the
capabilities of each role type:
Employee Role Type Test Cases:
 Can employee see his/her personal information successfully?
  Can employee evaluate personal information and his/her manager’s performance
successfully?
HR Role Type Test Cases:
 Can HR see all employees’ personal data successfully?
 Can HR see all employees’ performance evaluation successfully?
 Can HR edit all employees’ personal information?
 Can HR add a new employee by entering required personal information of that employee
successfully?
 Can HR see the list of all employees that work?
 Can HR evaluate the performance of his/her employees’?
Admin Role Type Test Cases:
 Can admin add a new user to the system successfully?
 Can admin introduce a new role type to the system successfully?
 Can admin edit the specifications of an existing role?

3.3. Validation testing.

The payroll system is implemented according to the specifications explained in the documents of
SRS and SDS. Therefore, it is important for to check whether the functions and capabilities that
were mentioned in those documents are implemented successfully. The test case functions to be
checked here:
 Is the data design consistent with the reports?
 Is the architecture design consistent with the reports?
 Does the interaction between modules work correctly?

3.4. High‐order testing (a.k.a. System Testing).

3.4.1 Performance Test.
Since the payroll system uses a huge database manipulation and requires a listing of entries in
some cases, there should be a test for the performance of the system and RAM usage of the system.
Therefore, the test cases below should be held:
 Does the project work in real time?
 How fast can the queried data be achieved from database?
 What is the maximum number of the online users at the same time?
3.4.2 Alpha Tests.
Since there are three role types each role will be done individually in order to clearly see the bugs
of the system.

3.5 Testing Resources and Staffing.

First, each unit is checked out in the same environment defined in the specifications report then
these code pieces are combined together and embedded to the main source code of the project.
During combination process, each unit is taken and combined with the other unit and this
combination process is held all together in order not to face with problems that can be occur due
to the changes on these combined implementations. Finally, system tests will be held. Then, end-
users take part in testing operations. The updates on the features and the functionalities of the
system will be described in detail to the end-users.

3.6 Test Work Products.

Test work product is mainly done through a TRAC which is an open source, web-based project
management and bug-tracking tool. Whenever a bug is found on the system the users are informed
via TRAC system. Thus the system is checked on a daily basis.

3.7 Test Record Keeping and Test Log.

Testing procedures usually results with bugs. When a bug is found, this bug will be recorded in
TRAC. Also, progress of the bugs will be recorded in TRAC and when it is resolved, related ticket
in TRAC will be completed. Also, during the improvement of the project, after fixing errors, the
code will be saved hence the application will be versioned and archived.