Testing Plan

by
Bora ÇAKMAZ
Alper ÇÖMEN
Berkay ERGİN
Table of Contents
1 Overview 3
1.1 Unit Test 3
1.2 Integration Test 3
1.3 System Test 3
1.3.1 Functional Test 4
1.3.2 Performance Test 4
1.3.3 Security Test 4
1.3.4 Recovery Test 4
1.4 User Acceptance Test 4
2 High-Level Milestones 5
3 Test Staffing 6
4 Test Process 7
4.1 Test Tasks 7
4.1.1 Front End 7
4.1.2 Back End Data Storage 7
4.2 Test Process Approach 7
5 Testing Methods 9
6 Measurements 10
7 Testing Risks 11
7.1 Requirements 11
7.2 Time 11
7.3 Hardware/Software 11
7.4 Personnel 11
8 Software Tools 12
9 Testing Support 13
10 Personnel Support 14

Overview
We will perform a series of different tests to fully exercise the DPBS
system. Our primary objective by doing these tests, is to determine
the limitations and measure the capabilities of the DPBS system.

Details about the tests are as follows:

Testing Plan
Page 2 of 13
Unit Test

Test an individual unit of the software, e.g., a “Window” class. It will

be done by its developer.

The objectives of unit test are to:

Identify unit-level defects by causing corresponding failures to occur.
Determine if the unit is complete and ready to be submitted for
integration as part of a code build.

Integration Test

Test two or more system components(classes), specifically for the

components(classes) that have been distributed across multiple
platforms, e.g., client and database server, to prove them interface
with each other correctly and there are no gaps in the data flow.

The objectives of integration test are to:

Cause failures involving the distribution of integrated system
components.
Confirm that the group of components can be fully integrated to satisfy
requirements.

System Test

The System tests will focus on the behavior of the DPBS system. User
scenarios will be executed against the system. Overall, the system
tests will test the whole system and verify that it meets the
requirements defined in the requirements document.

Functional Test
The objective of this test is to ensure that each element of the
application meets the functional requirements.

Performance Test
These tests ensure that the DPBS system provides acceptable
response times and does not exceed the specified performance
criteria. During these tests, we will measure response times.

Testing Plan
Page 3 of 13
Security Test
There won’t be any security test in Disease Prediction By
Symptoms since it does not require any kind of authorization.
Like login, logout, change password etc.

Recovery Test
Since we do not use a database to store the medical data, we
won’t be needing any recovery tests made in this part.

User Acceptance Test

Once the system is ready for implementation, user representatives will

perform User Acceptance Testing. The purpose of these tests is to
confirm that the system is developed according to the specified user
requirements and is ready for operational use.

Testing Plan
Page 4 of 13
High-Level Milestones
Four major milestones are listed here:

We will focus on Unit Test during Iteration 1. For each function and
class, we need write some testing codes and test all possible inputs
(valid/invalid, bounded/random value, etc), to see if the results come
out as expected. We plan to complete this phase by 6 May 2021.

We will conduct Integration Test during Iteration 2, when user

interface and data storage parts are ready. We need test the interfaces
between system classes to see if they talk to each other correctly. We
plan to complete by 8 May 2021.

We will perform System Test after the whole system is ready. We need
test all system functionalities, as well as error management, to see if
the system is functional, secure and robust enough. We plan to
complete by 10 May 2021.

We will organize potential users to perform User Acceptance Test at

the end of this project, to see if the system meets the specified user
requirement. We plan to complete it by 12 May 2021.

Testing Plan
Page 5 of 13
Test Staffing
The participants for testing will be:

Unit Testing is the responsibility of the Bora Çakmaz, Alper Çömen,

Berkay Ergin

Integration Test is the responsibility of the Bora Çakmaz, Alper

Çömen, Berkay Ergin

System Test is the responsibility of Bora Çakmaz, Alper Çömen,

Berkay Ergin

User Acceptance Test is the Responsibility of the User

Representatives

The test team is responsible for:

writing the detailed plan for the test (if necessary)

supervising the execution of the test

providing resources for the test

documenting the results of the test

updating the plan as a result of the test

Testing Plan
Page 6 of 13
Test Process

4.1 Test Tasks

4.1.1 Front End

Questions
Selecting all answers that apply
Selecting one answer that apply
Selecting no answer that apply

Menu
Returning to previous or next pages
Resetting answers

Exit

Back End Data Storage

Test Process Approach

1. Test Preparation Alper

Includes creating a Test Plan, Schedule & Test Çömen
Approach, and making resources available.

2. Design/Build Test Bora

Includes identifying Test Cycles, Test Cases, Test Çakmaz
Data, Expected Results, etc.
3. Build Test Procedures Berkay
Includes setting up procedures such as Error Ergin
Management / Defect Tracking systems.
4. Build Test Environment Bora
Includes hardware, software and test database Çakmaz
set-ups.

5. Execute Integration Test Berkay

Ergin

Testing Plan
Page 7 of 13
6. Execute System Test Alper
Çömen

7. Execute User Acceptance Test Bora

Çakmaz

Testing Methods
Special programs, or drivers, may be written to supply the appropriate
environment and inputs to the unit being tested, especially during unit
test phase. We plan to use Decision-technique as the primary testing
approach, and White-box technique as a secondary testing approach.

A wide range of inputs will be entered by the user to receive an output

that graphically well represents the trained data. Here, we plan to use
Boundary Test technique to test error handling. Start with known good
and valid values, then try expected bad values, such as not entering
any symptoms or entering very unlikely cases such as selecting all
symptoms. We’ll also test and evaluate the training model and derive
its statistics such as mean absolute error (MAE), precision, recall and
accuracy to ensure that our training model is working as intended.

We will also have intensive testing of the Front End fields and screens.
We will make sure that Windows GUI Standards, and screen & field
look and feel maintain consistency with the rest of the application. We
will check for valid, invalid and limit data input.

Testing Plan
Page 8 of 13
Measurements
We plan to track the following measurements:

System’s response time

Mean time between two failures

Total number of defects

Severity of each defect

Mean time required to find a defect

Testing Plan
Page 9 of 13
Testing Risks

Requirements
Our test plan and test schedule is based on our requirements
document. Any further changes in that document will affect here
and updated.

Time
The schedule for each phase is very aggressive and could affect
testing. A delay in one of the other phases could result in a
subsequent delay in the test phase. Henceforth we can not indicate
a specific time for this section.

Hardware/Software
There won’t be any server related to this project for now. We will
use our personal devices (mobile phones, computers etc.).

Personnel
We will test our own product.

Testing Plan
Page 10 of 13
Software Tools
We plan to use Bugzilla to provide issue tracking and assignment for
the testers to catalog any bugs/defects.

Testing Plan
Page 11 of 13
Testing Support
We will require the following hardware:

Our personal devices.

We will require the following software:

PyCharm Community Edition

Selenium

Testing Plan
Page 12 of 13
Personnel Support
The Test Team will require support from medical personnels
specialised in their fields.

Testing Plan
Page 13 of 13