Documente Academic
Documente Profesional
Documente Cultură
CONSTRUCTION
SDM.618
Author:
Adegbite, Abimbola
Creation Date:
Last Updated:
DOCUMENT CONTROL
Change Record
Date
Author
Version
Change Reference
22-Mar-16
22-Mar-16
Adegbite, Abimbola
Adegbite, Abimbola
Draft 1a
Revision
No Previous Document
SDM 600
Reviewers
Name
Position
Olatunde Alalade
Azeem Yusuf
Bisi Aina
Distribution
Copy
No.
Name
Location
1
2
3
4
CONTENTS
Document Control......................................................................................................................... 2
Change Record............................................................................................................................... 2
Reviewers....................................................................................................................................... 2
Contents........................................................................................................................................ 3
OVERVIEW................................................................................................................. 4
1.1
1.2
1.3
1.4
Software Identification................................................................................................. 4
Dates........................................................................................................................... 4
Resources................................................................................................................... 4
Environment................................................................................................................ 4
TEST MODEL............................................................................................................. 6
2.1
2.2
2.3
2.4
Methodology................................................................................................................ 6
Tools............................................................................................................................ 6
What Was Tested........................................................................................................ 6
What Was Not Tested.................................................................................................. 6
TEST DETAIL............................................................................................................. 7
ISSUES RAISED........................................................................................................ 8
4.1
Issues Outstanding..................................................................................................... 8
RECOMMENDATIONS.............................................................................................10
6.1
6.2
Open Issues.............................................................................................................. 11
Closed Issues............................................................................................................ 11
OVERVIEW
To achieve full accountability for all transactions and for LASG, to be able to report all receivable
transactions that are tied to respective customers, services and MDAs, the LASG Integrated Billing System
encourages all transactions to be initiated from its Enterprise Resource Planning (ERP Financials)
System.
The Tests are based on Clients requirement and System Functionality. It also takes into consideration the
internal mechanism of the system and focuses on the output generated against any input and execution of
the system.
1.1 Software
Identification
Name
Version
1.2
Dates
1.3
Resources
Tester
Developer
Business Analyst
1.4
Adegbite, Abimbola
Apatira, Lookman Lajubutu, Ayodeji
Freeman, Adeyinka
Environment
Test PCs
Test Server
05/01/2016
22/03/2016
54 Days
TEST MODEL
2.1
Methodology
Due to the short period of time allotted for test execution, the Web sites source code will be frozen while
being tested. In view of the criticality of the application, critical and general fixes were done while testing
efforts, changes will not be scheduled while a unit of code is being tested. The testing effort used a
combination of manual and automated testing, due to the limited duration of the testing; only automated
tools that had a minimum learning curve was used. Due to the lack of available sophisticated tools and
time, no attempt will be made to collect more sophisticated metrics such as code.
2.2
Tools
2.3
Type
Name
Brief Description
FUNCTIONALITY
FUNCTIONALITY
Links
Forms
FUNCTIONALITY
APPLICATION
SPECIFIC
FUNCTIONAL
REQUIREMENT
APPLICATION
SPECIFIC
FUNCTIONAL
REQUIREMENT
APPLICATION
SPECIFIC
FUNCTIONAL
REQUIREMENT
APPLICATION
SPECIFIC
FUNCTIONAL
REQUIREMENT
COMPATIBILITY
NAVIGATION
INSTRUCTION
USABILITY
USABILITY
USABILITY
Accessibility
Cross Browser
USABILITY
USABILITY
SECURITY
Layouts
Cross-Site Scripting
SECURITY
SQL Injection
SECURITY
2.4
Type
Data Integration
Connection Speed
Link to Home Page on Every Page
Error Message Spellings
Navigation
Name
Performance Testing
ISSUES RAISED
Issues Raised
Issues Closed
Central Billing System (CBS)
SDM.618 Application Test Report
3.1
None
Just One issue was deferred to the Point of Deployment
Issues Outstanding
Module
Severity
Type
Summary
Workaround
Plan
Data Base
Medium
Enhancement
Writing a script to get completed/ printed registration forms
None
Developer is to write the script when he is to deploy the application in Abuja
There are different types of tests that are used to validate that software performs the intended function with the
anticipated features. Below are the various types of tests carried out
a) Smoke Testing
This testing was done whenever a Build is received (deployed into Test environment) for Testing to make sure the
major functionalities are working fine, Build can be accepted and Testing can start.
b) System Integration Testing
This is the Testing performed on the Application under test, to verify the entire application works as per the
requirements. Critical Business scenarios were tested to make sure important functionalities in the application works
as intended without any errors.
c) Regression Testing
Regression testing was performed each time a new build is deployed for testing which contains defect fixes and new
enhancements, if any. Regression Testing is being done on the entire application and not just the new functionalities
and Defect fixes. This testing ensures that existing functionalities works fine after defect fix and new enhancements
are added to the existing application. Test cases for new functionalities are added to the existing test
cases and executed.
4.1
Deficiencies
Module
Unneeded Login on top right of the Page when a Wrong Password is used
Fields to add Name and Surname can accept figures rather than Alphabets
Fields in the Admin Module should have examples to Improve Usability
Experience
Compulsory Fields are not defined with Asterisk
User Login
Manage Admin
Admin
Portal Wide
5
5.1.1
LESSONS LEARNT
BEST PRACTICES
A lot of activities was carried out by the Testing team during the Test Phase of this Project. Some of them could have
saved time, some proved to be a good & efficient way to work. An Example of this was the repetitive task of creating
an Employee manually was time consuming. This task was automated by creating scripts and run each time, which
saved time and resources.
Smoke test cases were automated and the scripts were run, which ran fast and saved time.
Automation scripts were prepared to create new users and Employees, where lot of records need to be created for
Testing.
Business critical scenarios are separately tested on the entire application which are vital to certify they work fine.
EXIT CRITERIA
RECOMMENDATIONS
Recommendation
The IPPIS Registration Portal is suitable for release to the Live environment
provided that the known Closed issues and workarounds are approved by the
project management team.
As the Exit criteria was met, this application is suggested to Go Live by the
Testing team. Appropriate User/Business acceptance testing should be
performed before Go Live.
8.1
Open Issues
Issue
8.2
Resolution
Responsibility
Resolution
Responsibility
Closed Issues
Issue
Forgot ref id on the registration login page is Broken or Dead. Remove Link as
the message needed is on the top part of the Page
Kindly add ippis url to sms and email sent to users/ employees
fields that need to be in numbers and user key in alphabets, flag out error
message
fields that needs to be in characters and user key in numbers, flag out error
message
Tried creating a new admin HR for Lagos state teaching hospital, Not receiving
sms or email
If and admin detail is edited, admin should still have the same user code but a
new password can be sent to email/ mobile phone
if hr regenerate token, employee ref id should be the same and new token can
be sent to email/ phone no
Email address and phone no should be unique across board
HR should not be able to see any of this menus. http://prntscr.com/8wec2h
Kindly change fix this http://prntscr.com/8wf645 . message should read
manage all university and teaching hospitals
Change content as shown in this URL http://prntscr.com/8wf902
change content as shown in URL http://prntscr.com/8wffut
Manage LOV's button is not responsive
Confirmation date on employment information page should not be compulsory
when support search by mda with either name or id or phone no, it should only
display the employee been searched for
Searched for an employee to make changes to employee email, not found
error message was displayed and i was not able to update
We should have same detail for managing both MDA's and UTH's
Phone no and email address should be unique system wide
Central Billing System (CBS)
SDM.618 Application Test Report
Issue
Resolution
Responsibility
APPROVALS
The undersigned acknowledge that they have reviewed the Test Report and agree
with the information presented within this document. Changes to this Test Report
will be coordinated with, and approved by, the undersigned, or their designated
representatives.
Signature:
Print Name:
Title:
Role:
Date:
Signature:
Print Name:
Title:
Role:
Date:
Signature:
Print Name:
Title:
Role:
Date: