6. Testing Guidelines

United Finance Limited
Testing Guidelines

Software Testing Guideline
Pagei
Table of Contents
Who will read this document ...............................................................................................................1
Introduction .......................................................................................................................................2
Purpose..............................................................................................................................................2
Scope.................................................................................................................................................2
Testing Method ..................................................................................................................................2
Automated Testing.................................................................... Error! Bookmark not defined.
Manual Testing......................................................................... Error! Bookmark not defined.
Test Approach....................................................................................................................................2
White box Testing..................................................................... Error! Bookmark not defined.
Black box Testing ..................................................................... Error! Bookmark not defined.
Types of Testing.................................................................................................................................3
Unit Test .................................................................................................................................3
Integration Test........................................................................................................................3
Functional Test........................................................................................................................4
System Test.............................................................................................................................4
Acceptance Test.......................................................................................................................6
General Testing Principal....................................................................................................................8
Complementary Reviews ....................................................................................................................8
Testing Documentation .......................................................................................................................9
Test Plan .................................................................................................................................9
Test Specification.....................................................................................................................9
Test Incident Report............................................................................................................... 10
Test Progress Report .............................................................................................................. 11
Appendix ......................................................................................................................................... 12
Test Documentation and Parties Involved ................................................................................ 12
Sample Test Case................................................................................................................... 13
Sample Bug Report................................................................................................................ 14
Sample Test Incident Report................................................................................................... 15
Sample Test Progress Report .................................................................................................. 16
Document Approval.......................................................................................................................... 17

Pageii
Document History
Version Date Reason For
Changes
Published By
[DBD.module.2016.01] [16 Oct 2016] First Draft [user/Emp ID]
Abbreviations
Abbreviation Elaboration Descriptions
PBA Primary Business Actor
The stakeholder that primarily benefits from the execution
of the use case.
PSA Primary System Actor
The stakeholder that directly interfaces with the system to
initiate or trigger the business or system event.
ESA External Server Actor
The stakeholder that responds to a request from the use
case.
ERA External Receiver Actor
The stakeholder that is not the primary actor but receives
something of value from the use case.

Page1
Who will read this document?
This document is authorizing for Reviewer, Project Manager, Designer, Developer, Tester and
System Audit.

Page2
1. Introduction:
Software testing is the process of analyzing a software item with the intent of detecting the defects by
identifying differences between developed and required requirements and to identify the bugs of
developed items.
2. Purpose:
The major purpose of this document is to provide a set of software testing guidelines for software
testers to make it ensured that the developed software system is properly tested and to pursue reliable
and quality product.
3. Scope:
The guidelines of this document is suitable for the projects, which have been developed by following
the SDLC. As for the maintenance of the project, these guidelines may need to be adjusted according
to the projects’ actualsituations.
It is important that users of this document (i.e. software project teams) should not treat these
guidelines as mandatory standards, but as a reference model; and should adopt the guidelines
according to individual project’s actual situation.
4. Testing Method: Tester can follow two types of test methods while perform testing a software. Two
types are:
(a) Automated Testing: Automated software testing is a process in which software tools execute
pre-scripted tests on a software application before it is released into production.
(b) Manual Testing: Manual testing is the process of manually testing software for defects. It
requires a tester to play the role of an end user and use most of all features of the application
to ensure correct behavior.
5. Testing Approach:
The test group should focus on two types of approach while testing software systems or software
components. No matter what levels of testing user choose, they mainly have to follow the bellow
approach.
(a) White Box Testing: White Box testing also known as Code Testing. It focuses on the
internal mechanism of a software system or software component to ensure that all code
statements and logical paths are tested. For this test approach, testers have to have full
knowledge of the internal workings or logics of the software systems or components.
(b) Black Box Testing: Black Box testing also known as Functional Testing. This type of testing
ignores the internal mechanism of a system or component and focuses solely on the outputs
generated in response to selected inputs and execution conditions. For this test approach,
testers do not need to know the internal workings or logic of the software systems or
components.

Page3
6. TYPES OF TESTING:
There are different types of Testing, each of which carries a specific functional purpose. Testers have
to focus on different Test Approach for each levels of testing.
(a) Unit Testing:
i. Scope: Unit Testing (or Module Testing) is the process of testing the individual
subprograms, subroutines, classes, or procedures in a program. The goal here is to
find discrepancy between the programs and the program specifications prior to its
integration with other units.
ii. Who & What will do:
- Programmers to define test cases during program development time.
- Programmers to perform Unit Testing after coding is completed.
- Programmers to include the final results of Unit Testing in the program
documentation
iii. Testing Guidelines:
- Testing should first be done with correct data,then with flawed data.
- Cross testing should be applied with more than one programmers.
- If there are critical sections of the program, design the testing sequence such
that these sections are tested as early as possible. A ‘critical section’ might be
a complex module, a module with a new algorithm, or an I/O module.
- A code review should be performed during the Unit Testing.
iv. Testing Approach: White Box testing.
(b) Integration Testing:
i. Scope: Integration testing, also known as integration and testing (I&T). The goal is to
combine individual software modules and test that module as a group to identify the
faults in the interaction between integrated units.
- Test Group to prepare an Integration Testing test plan and specification
before testing commences.
- Test Group, with the aid of the system analysts/programmers, to set up the
testing environment.
- Test Group to perform Integration Testing; and upon fault found they will
issue Test Incident Reports to system analysts/programmers, who would fix
up the liable errors.
- Test Group to report progress of Integration Testing through periodic
submission of the Integration Testing Progress Report.

Page4
- Both control and data interface between the programs must be tested.
- Testing can be done either Top Down or Bottom Up approach.
- As a result of the testing, an integrated software should be produced
iv. Testing Approach: Black-box & White-box Testing.
(c) Functional Testing:
i. Scope: The goal of functional testing is to verify that a software application performs
and functions correctly according to design specifications. Functional testing is a way
of checking software to ensure that it has all the required functionality that's specified
within its functional requirements.
- Test Group to prepare Functional Testing test plan and specification to be
recommended by the PSC before testing commences.
- Test Group will set up the testing environment in assistance with System
Analysts or Programmers.
- Test Group to perform Functional Testing; and upon fault found they will
issue test incident reports to system analysts/programmers, who would fix up
the liable errors.
- Test Group to report progress of Functional Testing through periodic
submission of the Functional Testing Progress Report.
- Users should be involved in this testing to give them familiarity with the
system to find out differences between users’ and developers’ interpretation
of the requirement specifications.
- Prepare a range of real life testing data in involvement with actual users of
the system.
- Testing should be done either Equivalence Partitioning or Boundary Value
Analysis approach.
iv. Testing Approach: Black-box Testing.
(d) System Testing:
i. Scope: System Testing, is a level of the software testing where a complete and
integrated software is tested to identify the errors in software. The goal is to check
the behavior of a complete and fully integrated software product based on the
software requirements specification (SRS) document. The main focus of this testing
is to evaluate Business/Functional/End-user requirements.

Page5
- Test group to prepare a System Testing test plan, to be endorsed by the PSC
before testing commences.
- Test group to prepare a System Testing test specification before testing
commences.
- Test group, with the aid of the designers/programmers, to set up the testing
environment.
- Test group in involvement with user representatives will perform system
testing; and upon fault found they will issue test incident reports to the
System analysts/programmers, who would fix up the liable errors.
- Test group to report progress of the System Testing through periodic
submission of the System Testing Progress Report.
iii. Testing Guidelines: There are numerous types of system testing exists. It is not
claimed that all types of system testing need to be performed. Test group should
identify what types of system testing is needed to perform. Different types of system
testing described below:
- Usability Testing: Usability testing ensures, the GUI is user-friendly and can
be easily handled.
- UI Testing: UI testing focuses on testing the Graphical User Interface (GUI)
of the Software. It ensures that the GUI functions according to the user
requirements and is tested in terms of color, alignment, size, and other
properties. UI testing is considered as a sub-part of usability testing.
- Performance Testing: It is mostly used to identify any bottlenecks or
performance issues rather than finding bugs in a software. Performance
testing may include Network delay, Client-side processing, Database
transaction processing etc. Performance Testing can have sub-types such as:
- Load Testing: It is a process of testing the behavior of a software by
applying maximum load in terms of software accessing and manipulating
large input data. Load testing is performed with the help of automated tools
such as Load Runner, AppLoader, IBM Rational Performance Tester,
Apache JMeter,Silk Performer,Visual Studio Load Test, etc.
- Stress Testing: Stress testing includes testing the behavior of a software
under abnormal conditions. For example, it may include taking away some
resources or applying a load beyond the actualload limit.
- Security Testing: Security testing is to test the security control of the system
by attempting to violate them. Test cases are designed to test the imposed
security checks and to search for security holes in the system. Code review

Page6
may be conducted on programs to detect any insecure codes such as hard
coding of passwords.
- Procedure Testing: Computer systems may not contain only computer
processes but also involve procedures performed by people. Any prescribed
human procedures, such as procedures to be followed by the system operator,
database administrator, or terminal user, should be tested during the System
test.
- Regression Testing: Regression testing is the verification that what is being
installed does not affect any already installed portion of the application or
other applications interfaced by the new application.
- Scalability Testing: Scalability testing is to test the ability of the system to
meet future efficiency requirements that may be beyond the current
performance requirement.
- Installation Testing: Installation testing is to test the validity of written
installation procedures for installing the system onto the target environment
i.e. to verify if the installation procedures are accurate and with
understandable instructions.
- Compatibility Testing: It focuses on testing the compatibility of the system
with other co-existing software such as operating system or web browser
which may affect the behavior (e.g. resources usage) and stability of the
system in the same environment (e.g. on same hardware).
iv. Testing Approach: Both Black Box & White Box Testing
(e) Acceptance Testing:
i. Scope: Acceptance Testing is the process of comparing the application system to its
specified requirements and the current needs of its end users. The goal is to determine
whether the software end product is acceptable or not by its end users.
- User representatives to prepare an Acceptance Testing test plan
recommended by PSC.
- User representatives to prepare an Acceptance Testing test specification
recommended by PSC.
- User representatives, with the aid of project team members, to set up the
testing environment.
- User representatives to perform Acceptance Testing; and upon fault found
they will issue test incident reports to the system analysts/programmers, who
will fix up the liable error.

Page7
- User representatives to report progress of the Acceptance Testing through
periodic submission of Acceptance Testing Progress Report.
iii. Testing Guidelines: There are mainly two types of acceptance testing,which are:
- Alpha Testing: The testing is taken place at the development environment
by some end users or user representatives. Developers can observe problems
while users are testing the system before deployment of the system to user
testing environment for User Acceptance Testing.
- Beta Testing: The testing is taken place at the user’s testing environment by
users. The objective of this testing is to determine the user satisfaction on the
system and the fitness within the operational environment.
- Precautions for project team
 communicate clearly to the users of their commitments on the testing
 as the end users physically involved; therefore, sufficient
presentation and training will be very important.
 development team must be available to resolve problems if required
 testing staff should be freed from their routine activities (ii)
iv. Testing Approach: Black Box Testing.
(See appendix-10.1 for Test Level & Parties Involved)

Page8
7. General Testing Principles:
Test Engineers should carefully consider the following points while conduct the testing of a system.
(a) As far as possible, testing should be performed by a group of people which is refereed as
“Test Group”. In most of the cases, test group is different from those performing design and
coding of the same system.
(b) Test cases must be written for invalid and unexpected, as well as valid and expected input
conditions. A good test case is one that has a high probability of detecting undiscovered
errors. A successfultest case is one that detects an undiscovered error.
(c) A necessary part of a test case is defining the expected outputs or results.
(d) Do not plan testing effort on assumption that no errors will be found.
(e) If much more errors are discovered in a particular section of a program than other sections, it
is advisable to spend additional testing efforts on this error-prone section as further errors are
likely to be discovered there. The later in the development life cycle a fault is discovered, the
higher the cost of correction.
(f) Success of testing relies on complete and unambiguous Test Specification.
8. Complementary Reviews:
The testing techniques which is discussed above is generally known as Bottom-Up approach. This
approach has one associated shortcoming, which are: Requirement and Design Errors are identified at
later stage. This may cause project failure or increase the costs. To avoid this, it is most important that
the following reviews should also be performed:
(a) Requirements Review
- to review the requirements specification with the objective to identify requirement
items that are incomplete, incorrect, inconsistent, or not testable.
- proposed participants: system analysts,test group, users and qc staffs.
(b) Design Review:
- to review the design specification with the objective to identify design items that are
incomplete, incorrect, inconsistent, or not testable.
- proposed participants: system analysts,test group, domain experts and QC staffs.
(c) Program Walkthrough
- to review the most critical program modules with the objective to identify errors as
against the program specifications.
- proposed participants: system analysts,programmers, and lead programmers.

Page9
9. Testing Documentation:
For each level of testing except Unit Test a test document should be prepared in a project. A typical
test document has the following items to be covered.
(a) Test Plan: The goal is to identify the items being tested, the features to be tested, the testing
tasks to be performed, and the personnel responsible testing. The test plan should provide at
least the following information:
i. Test Type: A single line to describe what types (e.g. functional, system test) of
testing is planning to conduct.
ii. Test Items:
- List the functional items and software features to be tested.
- For Link/Integration Testing, list the software items to be tested (which in
most of the cases should be ALL software items).
- For Function Testing, list the functions in the function catalogue (which in
most cases should be ALL functions).
- For System Testing, list the tests to be carried out
iii. Responsibilities of relevant parties: For each party, specify their corresponding
responsibilities for the testing levels.
iv. Estimation: For each test item, list the estimated effort required and duration.
v. Remarks: Describe any special constraint on the test procedures, identify any special
techniques and tools requirements that are necessary for the execution of this test.
(b) Test Specification: It is a detailed summary of what scenarios will be tested, how they will
be tested, how often they will be tested. Test specification may include the following
information.
i. Testing Environment:
- Hardware and software required;
- Number of terminals/computers required
- Testing tools
- Test database
- Operations support/Operating hour.
ii. Test Termination Criteria: To specify the criteria (e.g. Failing on certain critical
test cases, when no. of error reaches a certain limit, etc.) under which the testing
would be terminated.

Page10
iii. Test Cases: Test cases involve a set of steps, conditions, and inputs that can be used
while performing testing tasks. The following components may include in every test
case:
- Test Case Id
- Test Title
- Priority
- Test Steps
- Test Data
- Expected Result
- Actual Result
- Pass/Fail
(See appendix-10.2 for sample Test Case)
iv. Fault/Bug report procedures: It may include the following
- Error/Bug reporting procedures
- Change/Version control procedures of software modules
(See appendix-10.3 for sample Bug Report Form)
(c) Test Incident Report: The goalis to documentanyeventthatoccurs duringthe test
processwhichrequiresinvestigation.The reportistobe issuedtothe system
analysts/programmersforthe errorsfoundinthe testingprogress. The reportmayhave the
bellowinformation.
i. Test-incident-report-identifier: Specifythe uniqueidentifierassignedtothe test
incidentreport.
ii. Summary: Identify the test items and summarize the incidents.
iii. Incident Description: A description of the incident. The description should include
the following items:
- Inputs
- Expectedresults
- Differences
- Date andtime
- Procedure step
- Environment
- TestersandObservers
iv. Impact: If known,indicate whatimpactthisincidentwill have ontestplanandtest
procedure specification.

Page11
v. Results ofInvestigation:
- Classification of Incident
a. Design/Program error
b. Error relatedtotestingenvironment
c. Others
- Action taken
a. Design/Program changes.
b. TestingEnvironmentChanges
c. No actiontaken.
(See appendix-10.4 for sample test Incident Report)
(d) Test Progress Report: In order to show the progress of the test procedure, a test progress
report should be prepared by the test group. This document should be submitted to the PAT.
A test progress report may have the bellow features:
i. Test Module: Software or program module to be tested.
ii. Scenario: Test case name to be tested
iii. Complexity: Levelof complexity
iv. Responsible Tester: Person assigned to test the test case
v. Execution Date: Date of execution
vi. Test Status: Pass/Failstatus of test case
vii. Defect Id: Defect Id of defect report for the scenario
viii. Incident Id: Incident Id of incident report for the scenario
ix. Summary: A summary for showing overall status.
- Number of testers
- Test cycle duration
- Total number of test cases
- Number of test cases executed
- Number of defects encountered
- Number of incidents
(See appendix-10.5 for sample Test Progress Report)

Software TestingGuideline
Page12
10. APPENDIX:
10.1. TEST DOCUMENTATION AND PARTIES INVOLVED
Type of
Testing
What is being tested Testing against Test data Done by
Who does
sign-off
Unit Testing
Program units
subprograms job
control and procedures
Program
Specification
Correct data then
with flawed data
Programmer
Lead
Programmer
+
System
Analyst
Link/
Integration
Testing
Linkages/
interfaces between
program modules
Program
Specification
+
System
Specification
Control and data
interface,
returns/calls
Test Group
PSC
Function
Testing
Integrated software on
a function by function
basis
Function
Specification
Functions of the
integrated software
Test Group
System Testing Integrated software
User Objectives
+
System
Specification
User supplied tests
data
Test Group
Acceptance
Testing
Entire system
simulated in
production
environment
User
requirements/acce
ptance criteria
Live data where
possible
Users

Software TestingGuideline
Page13
10.2. SAMPLE TEST CASE FORM
Project Name:
Test Case Template
Test Case ID: Fun_10 Test Designed by: <Name>
Test Priority (Low/Medium/High):Med Test Designed date: <Date>
Module Name: Google login screen Test Executed by: <Name>
Test Title: Verify login with valid username and password Test Execution date: <Date>
Description: Test the Google login page
Pre-Conditions: User has valid username and password
Step Test Steps Test Data Expected Result Actual Result Status (Pass/Fail) Notes
1 Navigate to login page
User should be able to
login
User is navigated to
dashboard with
successfullogin
Pass2 Provide valid username User= example@gmail.com
3 Provide valid password Password:1234
4 Click on Login button
Post-Conditions: User is validated with database and successfully login to account. The account session details are logged in database.

Page14
10.3. SAMPLE BUG REPORTFORM
<<Bug Report>>
Bug Title (Single Line)
Submitted By: Your name and a way to contact you
Bug Found Date:
Date the bug was found goes here. include the time, if you are submitting more than
one bug
Versions:
Operating System and version
Software title and version
Other installed software,if applicable
Hardware information, if applicable
Bug Description:
A concise description of what the problem is. Pure description, no narrative or conversational language.
Severity:
Minor, Major, Terrible
Steps to Reproduce:
1. Step by step instructions on how to reproduce this bug.
2. Do not assume anything, the more detailed your list of instructions, the easier it is for the
developer to track down the problem!
Actual Behavior:
Type what happens when you follow the instructions. This is the manifestation of the bug.
Expected Behavior:
Type what you expected to happen when you followed the instructions. This is important, because you
may have misunderstood something or missed a step, and knowing what you expected to see will help the
developer recognize that.
Troubleshooting/Testing Steps Attempted:
Describe anything you did to try to fix it on your own.
Workaround:
If you found a way to make the program work in spite of the bug, describe how you did it here.

Page15
10.4. SAMPLE TEST INCIDENTREPORT

Page16
10.5. SAMPLE TEST PROGRESS REPORT
Figure: Progress Report
Figure: Progress Summary

Page17
11. Document Approval
Approved By Name Date Signature
Reviewer [Reviewer name] [Review date]
Project Manager [PM name] [approval date]

6. Testing Guidelines

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (7)

Similar to 6. Testing Guidelines

Similar to 6. Testing Guidelines (20)

6. Testing Guidelines