Chapter 5: Coding & Testing

5.0 Introduction
This chapter entails the construction of the system to the reader and its code which will be
followed by testing of the system which includes system testing whereby we will be looking at
Unit testing, Black box Testing, White box testing, Module testing and the sample test runs.
Following the testing phase is the installation of the system with the training of the users, system
conversion, file conversion that is data migration.
5.1 Modules
Basically the system has one major section with its own sub-modules. The major section is the:-
 Asset Register module
 Asset Management module

5.1.1 Asset Register module

 The sub-modules found within the Asset Register module are as follows.

The maintenance module contains such sub modules as creation, updating of user and asset
details.
 Creating of accounts – this module is used by customers when making their payments
according to their monthly bills thereby updating their records.
 Updating of accounts – the administrator will be responsible for using this module in
updating accounts registered by any customers, for example when a client wants to
change his password or no longer wants to use a contract account.
 View accounts/ Tables – the operations clerks will be able to print customer statements
from the system for a particular month and then send them to customers such that they
will be able to make payments in time.

5.1.2 Asset Management module

The sub-modules found within the Asset Management module allows the user to perform the
following functions:

 Routine maintenance of assets – it maintains the system users from the database. It
facilitates functions such as adding a new system user, deleting a user and also changing
a user’s login details.
 Send service request– the utilities module allows the user to perform a backup of the
database in case a risk occurs such as data redundancy and therefore the need to restore
the database to its original state.
 Asset condition calculations– the utilities module allows the user to perform a backup of
the database in case a risk occurs such as data redundancy and therefore the need to
restore the database to its original state.

5.2 Pseudo Code for the modules

Below is the program structure and pseudo code for the main modules of the new system:-

5.2.1 Logging On
Enter ecnumber and password
If correct then
Go to the asset page
Else
If logon is unsuccessful then
Go To visit the I.T Unit.
End if
5.2.2 Asset Management module

If registered
Case 1 View Asset Details
Case 2 View Routine Table
Case 3 Send a mail to I.T Unit
If Valid Name, Email and Message then
Send mail
Else
Fail sending mail
Else Log out

5.2.3 Update Asset Register module

If role is equal to I.T Unit staff

Else if record is available
Update account
Else
Create new
End if
End if
Log out
5.2.4 Search Asset Register
Invoke a database query
If query is valid then
Refresh report data
View report on screen
Set report to be printable
Else
Generate informative message to user
End if

5.3 Program code segments

This section shows sections of the code that where made so that the system would become
functional. Code segments performing functions which are add, update, search and validate
payments were selected.

Make Payment (Direct payments module)

Option Explicit

Public add_state As Boolean

Public Old_ID As String
Public rs_payment_ae As New ADODB.Recordset
'Public IDENTIFIER As Long
Public sFORM As Form

Private Sub cmdcalc2_Click()

txtsubtotal1 = Format$((Val(txtbalance.Text) + Val(txtmonthadjusts.Text) +
Val(txtinterest.Text)), "#,##0.00")
txtsubtotal2 = Format$((Val(txtrental.Text) + Val(txtmetrecalls.Text) +
Val(txtmisccharges.Text) + Val(txtinterest.Text) + Val(txtsubtotal1.Text)), "#,##0.00")
txtvat = Format$((0.175 * txtsubtotal2.Text), "#,##0.00")
txtdue = Format$((Val(txtsubtotal2.Text) + Val(txtvat.Text)), "#,##0.00")
cmdupdate.Enabled = True
cmdcalc2.Enabled = False
End Sub

Private Sub cmdcalculate_Click()

If is_empty(txtreceived) = True Then Exit Sub
If Val(txtreceived.Text) < 1 Then MsgBox "Please enter a valid number or a number not less
than 1.", vbExclamation: txtreceived.SetFocus: Exit Sub
txtbalanceCD = Format((txtdue.Text) - (txtreceived.Text))
cmdcalc2.Enabled = True
cmdcalculate.Enabled = False
txtreceived.Enabled = True
End Sub
Private Sub cmdupdate_Click()
If dotsCounter(txtreceived.Text) > 1 Then MsgBox "Only one dot or (.) allowed.Please check
it!", vbExclamation: txtreceived.SetFocus: Exit Sub

If is_empty(txtreceived) = True Then Exit Sub

'On Error GoTo Err

CN.BeginTrans

Dim rs_currentpay As New ADODB.Recordset

With rs_currentpay
.Open "Select * FROM tblCurrentPayments", CN, adOpenStatic, adLockOptimistic
.AddNew
.Fields("AccountNumber") = txtaccnum.Text
.Fields("DateOfPayment") = Format(DTPicker1.Value, "mm/dd/yy")
.Fields("BalanceBF") = txtbalance.Text
.Fields("PaymentReceived") = txtreceived.Text
.Fields("TotalDue") = txtsubtotal2.Text
.Fields("BalanceCD") = txtbalanceCD.Text
.Update
End With
'-Update the tblPayments
With rs_payment_ae
.Fields("BalanceBF").Value = txtbalanceCD.Text
.Fields("BalanceCD").Value = txtbalanceCD.Text
.Fields("SubTotal1").Value = txtsubtotal1.Text
.Fields("SubTotal2").Value = txtsubtotal2.Text
.Fields("Due").Value = txtdue.Text
.Fields("DateOfPayment") = Format(DTPicker1.Value, "mm/dd/yy")
.Fields("Current").Value = .Fields("Due")
.Fields("MetredCalls").Value = 0
.Fields("Rental").Value = 0
.Update
End With

CN.CommitTrans
Set rs_currentpay = Nothing

'sFORM.reloadRecord
MsgBox "Payment has been successfully made.", vbInformation
Unload Me
Unload FRM_PAYMENTS
Call printreceipt

Exit Sub
'Err:
' CN.RollbackTrans
' Call prompt_err(Err)
End Sub

5.4 Testing
Before the system can be installed on a clients’ machine it is essential to conduct tests in order to
check for errors such as syntax errors and some errors which might compromise on the quality of
the system.
The testing for the Bill Enquiries and Payments System for Virtual Telecommunications was
done in the following phases:-
 Unit testing
 Module testing
 System testing
 Acceptance testing

5.4.1 Unit testing

This testing technique focuses on a unit of the program which can either be a function or a
module. All the modules within the system were tested to verify whether there were any errors
such as runtime errors that might occur whilst the system is in operation. There are two different
techniques that we used for the unit testing and these are:
 Black box testing – this involved testing of the inputs and outputs produced by the system
without taking into consideration the internal operations of the system. This involved
checking outputs such as reports to verify whether they were producing the required
outputs.
 White box testing – this technique pays detail to the internal processes of the system. It
focuses on the internal working detail of a unit and identifies errors not shown through
black box.

5.4.2 Module Testing

Different units within a module are combined to test on the functionality of a module as a whole.
More than one module in the system is tested to see if they are meeting the required
functionalities
.
5.4.3 System Testing
This process of the system testing cycle tests all programs and this ensures that everything
necessary is in place, for instance proper documentation. It involves testing of the whole system
to measure efficiency and effectiveness of the system. It is essential to measure the systems’
functionality with the stated objectives and this is done during the process of system testing.
Functions such as security and output generation will be taken into account as users go through
the system. There are also other issues that are taken into consideration such as the compatibility
of the software to the hardware and how the system will adapt to computer threats.
The diagram below gives a summarized overview of the testing process.
Testing phases outline

Unit Testing

Module Testing

System Testing

Acceptance
Testing

5.4.4 Acceptance Testing

The users need to accept the system and they can only do so after they have tested the system
themselves and accept to use the system. This is one of the final stages before the system is
accepted for use. In this stage errors and omissions that the developers might have missed are
discovered. The system will be installed to a sample group of users who will provide feedback
on the systems’ functionality.
5.5 Test Results
Testing Of the System
This is the phase where the system will be tested for functionality. The strategies that are to be
used are the following: -

 Validation
 Verification
5.5.2 Validation
Validation is concerned with building the right system and evaluating whether it is meeting the
organizational needs and objectives. We check whether the final product meets the expectations.
The developed system went through a series of tests with the objective of detecting errors and
then correcting the identified errors. This process was to ensure that the system would be
delivered for final use without errors.
Validation is also concerned with showing the invalid data being entered into the system and
how the system validates the data to inform the user through the use of pattern notifications.
Only when the data integrity of the data to be saved is met, that is only when data can be
accepted and saved into the system.

Scenario1: When a user enters a wrong password.

The system will pop up an alert notification as shown below.
Scenario2: When a user types in an asset Delivery Date which is after the current date which the
asset is being captured into the system the system will also display a message box informing the
user of the invalid action.

5.5.3 Verification
When we were building the system we were concerned with whether we are building the product
in the right way. The major focus was to build a system that would suffice all user requirements.
In other words the question that was being addressed is are we building the product rightly. A
system can be built that may be exceptionally functional but not necessarily addressing the
problem at hand so there was need to do systems reviews of the project so that we would not
deviate from the system focus. We had to use sample data to verify whether the system was
accepting the correct inputs and giving the correct results.
Scenario1: When a user enters alphabetic characters in the date put box, the following message
will be shown:

Scenario 2:When a user leaves some required fields empty the, for example leaving the asset
useful life field empty when capturing a new asset into the system following message is shown
by the system.
5.5.4 Test methodologies applied
The following system testing methodologies were applied:
 unit testing
 module testing
 acceptance testing
5.5.4.1 Unit Testing
Individual components of the system were tested independently without other system
components.
The following bookings form shows the results from unit testing. The form shows the required
components involved and the data displayed as per user requirement and design requirement.
New Asset Details form showing results from unit testing

When one has entered the details correctly the message box shown on the form will approve that
the details has been entered and updated correctly.

5.5.4.2 Module Testing

This method of testing involved combining dependent components and functions together and
testing them. A single component was tested without other system modules. We tested all
modules separately.
Administration module testing data
Login testing
 Login testing involved testing of whether the supplied username and password can
actually give access to the user
 We tested whether the user can access the modules made available to the user.
 We tested to see if the system allowed a user who supplies the wrong credentials be
allowed more than three tries to remember their password.
The message box below shows you that you have provided a wrong password.

New user profile

 Does the system allow for new users profiles to be defined for the new system
  Can user profiles be deleted or edited.

Shows the message that appears when a new user is created.

If new user has been accepted the message box below will be shown.
New users
 Can the system add new users under the various profiles
 Can the system capture the new users new password
 Can the password be changed or edited for the user.
 Can a user be deleted from the system
Setting program access
 Can the system set access levels for the different user profiles?
 Can access levels be changed for the different profiles?
We tested the access levels of the management user group to see if they were restricted to the
access levels they had been granted. Fig 5.4 shows the access rights this user group has been
granted.

Access level granted to new

users upon creation

5.7.1 Login testing

  Login testing involved testing of whether the supplied username and password can
actually give access to the user.
 We tested to see if the system allowed a user who supplies the wrong credentials be
allowed more than three trials to remember their password.

5.7.2 Beta testing (Validation)

This type of testing aims to show the invalid data being entered into the system and how the
system validates the data to inform the user through the use of message boxes. Only when the
data integrity of input is to be saved is met that the data can be accepted and saved into the
system. The system was tested using real data supplied by the clerk and all the administrators
who would be using the system were inputting their data.

5.7.3 Validation of null fields

This aims to inform the user of a field that is required and has been omitted before the data is
saved. This is shown by the result of the diagram below.

5.7.4 Record deleting verification

When a user wants to delete a record the system will ask the user to verify whether he/she wants
to delete that record, in case they would want to delete that record by mistake. This is shown by
the diagram below.
Verification and validation was concluded by a statement revealing that the system was correctly
validated and conformed to its stated objectives.

5.8 System security

5.8.1 Back up Plan

System back up is as follows
 System application backup
 Database backup
5.8.2 System application backup
The system application must have its own independent backup for when there is need to reinstall
the system. The system can thus be reinstalled in cases that the system is not functional due to
any reason that may cause system function not to be as expected.

5.8.3 Database backup

Database backup is in the following stages
 Primary backup
 Secondary backup

The Database Management System as set by the administrator does this. To invoke this facility
set the backup plan within the SQL 2000 server. Care should be taken to set the following

Parameter to set Parameter value

Number of days when to set backup days Everyday

Backup files Database and log files

Database pathway Any directory not in the same drive
as the database

5.8.5. Secondary Backup

Secondary is centered on backup that is to a secondary backup storage that is

 Backup tapes.
 Offsite backup premise
Secondary backups help to secure the companies data so that it is safe from internal company
disasters.
5.9 Conclusion
Installation and testing of the new system was done and was successful and action is to move on
to the next phase, which is the Maintenance phase.