REPORT

Software Design Description

(SDD)
Project title: UTP CoQ Online Registration
Printing Date: 14.8 2015
Department and University: Information
Technology, University Teknologi PETRONAS

REVISION PAGE
Overview
This report is for the software design description of the UTP CoQ Online Registration
Project. This report will explain in details about the process of design and the details of
design for the project.

Target Audience
Our target audience for this project is students of Universiti Teknologi PETRONAS and
the Block B Curriculum Unit.

Project Team Members

1.
2.
3.
4.
5.

Ahmad Khairulamin bin Zamri

Ameer Wafin Bin Ilias
Nur Hanis Solehah Binti Mohd Rosli
Iffah Nabilah Syaza Binti Khairul Nizam
Nurul Syafinaz Binti Azman

19182
19025
19151
19149
19365

Signatures of Approval
14 November 2015

To Whom It May Concern

Dear Sir/Ms

TDB2163 SOFTWARE ENGINEERING CLASS PROJECT

This letter will confirm that student below is currently enrolled TDB2163

SOFTWARE ENGINEERING. This student is expected to complete their

class project which contribute 20% of their coursework mark. Detail of
the student as below:
1.
2.
3.
4.
5.

Ahmad Khairulamin bin Zamri

Ameer Wafin Bin Ilias
Nur Hanis Solehah Binti Mohd Rosli
Iffah Nabilah Syaza Binti Khairul Nizam
Nurul Syafinaz Binti Azman

Project Title: Co-curriculum Online Registration System

It will a helpful for me, if you could assist them in their project.

Sincerely

Table of Contents
1 INTRODUCTION
1.1 Design Overview
1.2 Requirements Traceability Matrix
2 SYSTEM ARCHITECTURAL DESIGN
2.1 Chosen System Architecture
2.2 Discussion of Alternative Designs
2.3 System Interface Description
3 DETAILED DESCRIPTION OF COMPONENTS
3.n Component-n
4 USER INTERFACE DESIGN
4.1 Description of the User Interface
4.1.1 Screen Images
4.1.2 Objects and Actions
5 ADDITIONAL MATERIAL
Relevant IEEE

1. INTRODUCTION
1.1 Design Overview.
Online registration for CoQ unit is designed to meet the requirements of users which is
the students who taking the curriculum subjects and the administrator who control the
data and details of the CoQ units.
The design basically fulfilled both the user and administrator requirement such as user
friendly and easily to control the system.

1.2 Requirements Traceability Matrix (RTM).

The requirement traceability matrix is used to show the many to many relationship
between requirements and test cases. The RTM used table to show the relationship
mapped by each requirements on the test cases.

2. System Architectural Design

Design 1

SEARCH

GO

CO-Q Registration
Foundation Studies Programme
Undergraduate Studies Programme
Postgraduate Studies Programme

COURSE OFFERED IN MAY 2015

Gamelan 1
Gamelan 2
Caklempong 1
Caklempong 2
Modern Music 1
Modern Music 2
Sport Science
Swimming

SESSIONS
Session 1
9pm-

SELECT

11pm

Monday
Gamelan room
Session
10 am-

2
SELECT

12pm

Tuesday
Gamelan room

SESSION IS FULL!
CHOOSE ANOTHER SESSION?

BACK

YOU HAVE CHOOSE

SESSION 1

EXIT

9PM- 11PM
MONDAY
GAMELAN ROOM
BACK

PROCEED

YOU HAVE
SUCCESFULLY
REGISTERED

Design 2
UTP CoQ Online Registration
BACK

Login

HOME

UNIVERSITY TEKNOLOGY PETRONAS

UTP CO- Curriculum Registration

UTP Students? Taking this sem?
Register your Co-Q Class Now Online.

UTP CoQ Online Registration

Login

Student Co-Q Registration

Name*

ID*

Course*

Year of Study

BACK

Co-Curriculum List
Seach

SUBMI

SPORTS

Badminton

Rugby

Football

Tennis

Swimming

VOLUNTEER WORK AND COMMUNITY SERVICES

Peer Group
Counseling

Recreation
&
Adventure

Student Voluntary
Activities

ARTS & CULTURAL CATEGORY

Gamelan 1

Gamelan II

Modern Music
I

Modern Music
II

Gamelan 1 Class Sessions

o Session 1
9PM- 11PM
TUESDAY
BADMINTON HALL,UTP

o Session 2
9PM- 11PM
THURSDAY
BADMINTON HALL, UTP

SUBMIT

CONTINU

LIST OF STUDENTS FOR BADMINTON

SESSION 1
No

1.

NAME
Ali bin Abu

ID
12345

COURSE
Bis

DONE

YEAR
2nd

Gender
Male

Day
Tuesday

You have been successfully registered

Badminton Session 1
BACK

2.1 Chosen System Architecture

The chosen System Architecture is Design 2 because it is more systematic and it is easier
for the user to choose their desired course and sessions. For the Design 2 it is more user
friendly and it is easier for the storage of details from the students. For the admin or CoQ
Unit, the details of students have been listed in the table and the CoQ unit can refer to the
table and they can use it for other purpose such as printed it and give the copy to the
lecturer.
Besides that, if the table already full the students have to choose another session. Every
session have their own limits such as each session 50 students. If the sessions is full, a
message will be pop up to the user informed that the session already full and the student
have to choose another session.
This Design 2 is chosen for our project because it is easier for us as the admin and for the
user also.

2.2 Discussion of Alternative Design

For the alternative design which is Design 1, we planned it to apply it in the E-learning in
UTP. After we have tried it in the developing stages, we found out it is not easy to comply
with the E-learning and we decided to come out with one page that the students can open
it anytime using the url given. For the future improvement, the Block B unit have decided
to consider it and to comply with UTP management to include the software in the Elearning system.
For the Design 1, we put the CoQ Registration together with the other courses provided
in the UTP, so the students can also register their CoQ online in the E-learning. Before
this, Block B/ CoQ Units also use E Learning as a medium for them to inform the
students whether they already can register their session for CoQ. The CoQ Units will
inform the students the dates and time for the students to register their sessions and the
students have to go to Block B for registration.

2.3 System Interface Description

For Design 2, the first page is the Home page of the CoQ Online Registration. After the
user click at the Register

your Co-Q Class Now Online.,

the system

will provide the user the page of Students CoQ Registration page. In this page, the
students need to fill some of their important details to be stored in the database such as
name, ID, course, and year of study. This information will be displayed in the table and
database as the reference of students, lecturer and CoQ Units.
After the student have filled the details and click the submit button, the system will
provide them the list of courses offered in that semester. The user only need to choose
their registered courses of CoQ by clicking the button that have their CoQ name on it.
After they click on the course such as badminton course, the session for the badminton

course will be display on the next page. The user only need to click on the radio button
from each session. For example, the user click on the radio button of session 1, and they
click on the continue button, the page will display the table of the list of students that
have been registered. Their name will be automatically filled in the table. After they click
the DONE button, the message of they already successfully registered for their session
will be appear. Besides that, the details of their chosen session also will be display on the
page.

3.0 Detailed Description of Component

3.n Component-n
For the development of software, many components such as software involve in
developing it. As the system focused on the Online Registration for CoQ Unit, it involves
the development of online website. The online website is built for the students to open it
or doing the registration in any time as long there is internet connected to their device
such as laptop or phone.
For the website, the components involved are
1. HTML which is Hypertext Markup Language.

HTML is used to display website or webpage to the user by online. The

information of course registration such as the list of courses can be display in the
webpage.
2. CSS which is Cascading Style Sheet
We used to make design for the webpage. CSS have a lot of function to decorate
the webpage such as font, function, radio button, image display, color and the size
of the fonts and may more. The webpage can be decorated as the admin wants it
to be appear to the user.
3. Bootstrap Server Function
Bookstrap Server Function is an intermediary element in cellular networks which
provides application independent functions for mutual authentication of user
equipment and server. Bookstrap also act as the template for the website for the
development of the website.
4. PHP/ PHPMyAdmin
PHP/PHPMyAdmin is used in this project as a software for the database. When
the students make the registration, the details of their chosen session will be
recorded in the database. This database is used as the reference for the admin to
check and to update anything related to it. Besides that, php also is used to
connect the website and the database.
5. My SQL
My SQL is used as the programming code for the database. Any programming
code and instruction to be apply in the database will be programmed in mySql. By
using MySql, expressions can be used at several points in SQL statement, such as
SELECT statements and many more.
6. Javascript
Javascript is used to display the pop up message to the user such as You have
been successfully registered for the session 1.

4. USER INTERFACE DESIGN

4.1 Desription of user interface

Based on the design that have been made, it will give user the easy way to choose their
desired session for CoQ. The CoQ team will provide the list of courses that are offered in
that semester. The students or user will choose based on the course offered that has been
displayed. It is easier for the students because students do not have to fill the forms or
provide the personal details to the system because the system have record it based on
their ID that they entered at the beginning of the e-learning.
After the students has choose their courses, the system will provide the list of sessions for
the course chosen and the students only have to select their chosen session and if the
session is full, the students need to go back to the session and choose it again. If the
session is not full, the successful message and the details of the session will be appear.
The system will ask the user whether to proceed with the session or to change the session.
If the student click proceed, the session chosen will be recorded in database of Co-Q unit.

4.1.1 Screen Images

USER INTERFACE
FRONT PAGE OF WEBSITE

The user will click the blue line which is Register your Co-Q Class Now
Online!
Second page (List of all CoQ Courses that are offered in that semester
The user will select any of the blue boxes based on their registered
courses
Third page ( The sessions from the chosen course)

Forth Page(Checking Class Availability)

Last Page(Register for the session by filling up details/ Successfully

Registered)

ADMIN INTERFACE
First page (Login as admin)

Second page (Check the list of students by each courses)

Third page(Check the database, admin can use it as reference and

print the data)

4.1.2 Objects and Actions

For object and action, we include on how to process of the website and the action of each
object in the websites. Besides that, we also will include the function of each page in the
website from the front page to the end until the user have been successfully registered.
Moreover, we also will include the page that is viewed by the admin and what are
functions that an admin can do in the website.
For the first page of website it displayed the front page of University Teknologi
PETRONAS and on that page there is a registration for CoQ Courses Session online.
After the user click on the link, the list of CoQ offered in that semester will be displayed.
The user need to choose the courses and click on that course.
After they click on the course, the sessions from each courses will be display. For
example, if they choose badminton courses, the sessions for the badminton will be
display such as Session 1 and Session 2. The user can check the availability of the class
by clicking the button of checking the availability. It will display whether the session is

still available or the session already full. If the session already full, the user need to
choose another session.
If the session is still available, the user can register for their session. The user need to fill
the details in the form such as name, id, course and the year of study. The user also need
to click for the radio button for each session and submit the details together with the
session that they have chosen.
After the user have submit the message of successfully registered will be displayed. It
means the registration from the students have been recorded. The student only can
register for each session only once because the system has been design with a unique
attribute of the ID. Once the student have entered their ID, their ID will be recorded and
if they cannot register again for another session. This will help the system from having
the redundancy of data for the database.

As for the admin, the admin can login to the system by login as the admin. The admin can
check the database of the system and they also can check the list of students from each
course. For the admin the list of courses will be display as Please choose Coq Course
that you want to view. If the admin click on the badminton course. The list of the students
registered for the Coq will be display. The admin can use this data as reference and they
can print the list of the students from the database.
The system have been set up the limit from each sessions. From each session, the limit
for registration is only 30 students per session. The limit can be change based on the
requirement from the lecturer. After the session have filled until 30 students, the system
will inform the user that the session already full and the user need to choose another
session.
First of all we will include the object model of online registration from
both user and admin.

WEBSITE

-link registration
for Coq course
session

USER
DATABASE

REGISTER

-name
-id
-course
-year

-details
saved in
database
-listed
the name
and
details in
table for
each

AVAILABILITY

session is still available

-session is full

DETAILS
-Sessions for each
courses
-Available Sessions
for chosen course
COQ COURSES

-submission of sessions

-view the list of students

ADMIN

LOGIN AS
ADMIN
-username
-password

CHEC
DATABASE
-details saved in
database
-listed the name and
details in table for
each session

OPEN
CoQ COURSES

View the list of students

-Print the list of students

Additional Material (contents)

ADDITIONAL ISSUES
During the design of this project, there are some issues which design that we want to use
whether the design that are collaborated with the e-learning of UTP or the design that we
built on the other page beside of UTP e-learning page. After all the considerations from
Block B and group members, we decided to use the design that will be display on the
website. Any collaboration with the E-learning system, will be taken as a future
development by the CoQ Unit of Block B.

DFINITIONS, ACRONYMS, AND

ABBREVIATIONS
BR Business Requirement
BRS Business Requirement Specification.
CA Configuration accounting
CC Configuration control
CM Configuration management
CMP Configuration management plan
CMT Configuration Management Tool

CRC Class, Responsibility, Collaboration

DDD Database design document

FP Function Point
FTC Federal Trade Commission (U.S.)
GUI Graphical User Interface

SDP Software development plan

SRR Software requirements review
SDD System and software design document
SOA Service-oriented architecture
STAF Software testing automation framework

TTM Test traceability matrix

REFERENCES

Guru. 2015. How to create Requirement Traceability Matrix (RTM). Retrieved from
http://www.guru99.com/traceability-matrix.html
Khella,A. 2002 October. Objects-Action Interface model. akhella@cs.umd.edu. Retrieved
from https://www.cs.umd.edu/class/fall2002/cmsc838s/tichi/oai.html

SOFTWARE TEST DOCUMENTATION

(STD)
UTP CO-CURRICULUM ONLINE REGISTRATION
AUGUST 14, 2015
INFORMATION TECHNOLOGY OF UNIVERSITY
TECHNOLOGY PETRONAS

REVISION PAGE

OVERVIEW
This document describe the plan and specifications to verify and validate the software
and results.
TARGET AUDIENCE
The students of University Technology Petronas and Co-Curriculum Registration Units.
PROJECT TEAM MEMBERS
1.
2.
3.
4.
5.

Ahmad Khairulamin bin Zamri

19182/ ICT
Ameer Wafin Bin Ilias
19025/ ICT
Nur Hanis Solehah Binti Mohd Rosli
19151/ ICT
Iffah Nabilah Syaza Binti Khairul Nizam
19149/ BIS
Nurul Syafinaz Binti Azman
19365/ BIS

Revision History
Revision #

Revision
Date

Description of Change

Author

28/9/2005

First Draft

Massachusetts
Institute of
Technology

TABLE OF CONTENTS
No
1
2
3
4
5
6

Title
Introduction
System Overview
Objective
Scope
Test Approach
5.1 Black Box Testing &White Box
Testing
Test Plan
6.1Features to be tested
6.2Features not to be tested
6.3Testing Tools and Environment
Test Cases
7.1 Purpose
7.2Test Case Template
7.3Test Case UTP Co-Q Online
Registration
ADDITIONAL MATERIALS
APPENDIX A
8.1Manual Testing Questions &
Answer
8.2Plan Approval Process
8.3Test Results
8.4Test Incident Reports
8.5 Letter Template
8.6Acronym & Abbreviations in
Software Testing
8.7References

Page Number

1. INTRODUCTION
The project is about to create co-curriculum unit software to make it easier for
students and lecturer. The students can register the course online and no need to come to
Co-Curriculum block that far from the hostels. Therefore, the registration from cocurriculum unit will be systematic. The students can choose the course by the category
that are available in the semester. There will be sessions to be choose by the students and
they can choose to be in available sessions. There are only one ID that can be register
which means one ID for one student in one class. If the sessions are full, the system will
inform the students by pop-out at the page. After the students has successfully register the
course, they can logout or back to homepage of the page.
There are also UTP registration co-Q page for admins use. Admins can login the
system to see the list of the sessions. There will be easier to admins to categorize the list
of students in every course that are available. So this is basically the flow of the UTP
registration co-Q system.

2. SYSTEM OVERVIEW
The Co-Curriculum unit registration were using php, mysql, bootsrap, html, css and
xampp. The system qualification testing in each build of the system should be interpreted
to mean planning and performing tests of the current build of the system to ensure that
the system requirements to be implemented in the system. The steps that we use to test
software qualification are independence in system qualification testing.We fulfill the
requirements and put the details of the software in the system.The test cases is include in
the system. The detailed design or implementation of software in the system from
contributing the process. Secondly, testing on the target computer system. The system
qualification testing include testing on the target computer system or an alternative
system approved by the acquirer. Next, preparing for system qualification testing. It also
has the test preparations, test cases and test procedures to be used for system qualification
testing and the traceability between the test cases and the system requirements.
Therefore, dry run of system qualification testing.We also try running the system test
cases and procedure to ensure that the system is complete.There are also the screen shot
of the software and is ready for witnesses testing. Besides, performing system
qualification testing. This participation shall be in accordance with the system test cases
and procedures.Thus, we doing revision and retesting. We retesting the software and
updte the software development. The error of the system will be recover. Lastly, we
analyzing and recording system qualification test results.

3. OBJECTIVES
The test suite should provide coverage metrics and verify that each section is
working as intended. The test should verify that a section is ready to be deployed in the
field as soon as the test is completed.

4. SCOPE
Testing will be performed as a continuous process throughout the life cycle as the
product is in production. Due to the involved nature of testing, test planning will be a
continuous process that changes in scope alongside the products development. This test
plan template will be updated alongside the overall product and will reflect any changes
in scope, design, and time schedule. Test plans must be developed for each level of
product testing.

5. TEST APPROACH
The system is the initial qualification tets for the UTP Co-Curriculum unit to make it
easier for the Register units to determine the course that has been registered by the
students. It is because the register units were doing the registration manually so
sometimes there are duplication and missed of the data.
The software for the online registration system that we used are JAVA interface .It
allow a class to become more formal about the behavior it promises to provide. Interfaces
form a contract between the class and the outside world. This archive is a high-level
overview characterizing our testing procedure for the UTP Registration Co-Q unit. Its
goal is to convey venture wide quality benchmarks and strategies. This record will
address the diverse measures that will apply to the unit, coordination and framework
testing of the predetermined application. We will use testing criteria under the white box,
black box, and system testing paradigm. All through the testing procedure we will be
applying the test documentation particulars portrayed in the IEEE Standard 829-1983 for
Software Test Documentation.

5.1 Test Approach

Testing

Black Box

White Box

Equivalent
Partitioning

Basis Path Testing

Bounding Value
Analysis

Loop Testing

Control Structure
Testing
Comparison Testing
Fuzz Testing

Black Box Testing

Equivalent Partition
In equivalence-partitioning technique we need to test only one condition from each
partition. This is because we are assuming that all the conditions in one partition will
be treated in the same way by the software. If one condition in a partition works, we
assume all of the conditions in that partition will work, and so there is little point in
testing any of these others.We accept the greater part of the conditions in that
segment will work, thus there is little point in testing any of these others. Thus, if one
of the conditions does not work, then we accept that none of the conditions in that
segment will work so again there is little point in testing any more in the partition.

Bounding Value Analysis

Boundary value analysis where we can apply it to the whole of a string of characters
example name or ID. The number of characters in the string is a partition, for
example between 1 and 30 characters is the valid partition with valid boundaries of 1
and 30.

The invalid boundaries would be 0 characters and 31 characters. Both of

these should

produce an error message.

Comparison testing
We want to run all versions in parallel with a real-time comparison of results, we
have to test under three possible combinations: Identical, Similar, and heterogeneous
combinations of hardware and software platforms. Such tests will bring out possible
associated problems like effect of platforms on software, effect of different
resolutions and size of screen on appearance, impact of varieties of browsers in web
applications, and so on. By doing these tests we can benchmark performance of

software and also, one can recommend suitable hardware and software platform for
the given software.

Fuzz Testing
Code

Technique

Effort

Combination of black box +

10 min

50%

25%

30 min

80%

50%

2 hr

80%

50%

2.5 hr

99%

100%

coverage

Defects found

dumb
Combination of white box +
dumb
Combination of black box +
smart
Combination of white box +
smart

6. TEST PLAN
6.1 Features To Be Tested
The following features are the major functional capabilities of the project that need to be
tested at all phases of the testing cycle.
USERS
1.) Login ID
2.) Choose course
3.) Choose sessions
4.) Put details of the students
5.) The Submit button is visible and active
6.) User creation

ADMINS
1)Login email and password
2)Choose course
3)Review the list

6.2 Features Not To Be Tested

1)Register twice
2)Redundance activity

6.3. Testing tools and environment

Hardware
The system requires a single standard desktop PC, as well as a basic smart
phone with a data plan. There are no restrictions on what these 2 items
need to be other than they can run the software in any capacity.
Software
This project has an android software requirement. The phone must have an
android operating system and the desktop will need an android emulator.
Risks and Assumptions
The only risk associated with this project will be in the 2 month time table
for completion. Any and all testing must be done before the project
delivery date is set.

7. TEST CASES

7.1 Purpose
This UTP online registration Test Case Document identifies all conditions to be
implemented within the Registration course tests. These conditions are mandatory for an
acceptable and successful implementation of the function, Registration.

Tested By:
Test Type
Test Case Number
Test Case Name
Test Case Description

Item(s) to be tested
1
2
Specifications
Expected
Input

Output/Result

Procedural Steps
1
2
3
4
5

6
7

7.3 Test Case UTP Co-Q Online Registration

Test Cases
Test Scenario Name

Registration

Description

Registration course for UTP cocurriculum

Module Name

Students

Status

Created

Test Information
Name

Ali

ID

19152

Input Validation (USER)

No

Test Cases

Input

Expected Value

Actual Result

Data
1

2.

Select

Select one of

Display message

Display message

Register your Co-Q

Register your Co-Q

class now online

class now online

Course list are selected

Course list are

the course
3.

Pass/

Rema

Fail

rks

Pass

pass

selected

Select the

Session button are

Session button are

session on the

selected

selected

View

Display box Check

Display box Check

availability of

class availability and

class availability

the sessions

view

and view

Enter empty

Display error message

Display error

value for

Name

message Name

Enter empty

Display error message

Display error

value for ID

ID

message ID

Select option

Display selected course

Display selected

button for

programme

course programme

Display error message

Display error

Pass

radio button
4.

5.

Pass

Pass

name
6.
7.

course
programme
8.

Enter empty

Pass
Pass

value for year

Year of study

message Year of
study

9.

Select the

Gender button are

Gender button are

gender on the

selected

selected

Select submit

Click Submit for

Click Submit for

button

session 1 or Submit

session 1 or

for session 2 are

Submit for session

successful

2 are successful

Submit

Popup message The

Popup message The

button for

Class session os still

Class session os still

session is

available are

available are

choose

successful

successful

Expected value

Actual Value

Pass

radio button
10.

11.

Pass

Pass

Input Validation (ADMIN)

No

Test Case

Input
Data

1.

2.

Enter empty

Display error message

Display error

value for

Enter your email

message Enter your

email

address

email address

Enter empty

Display error message

Display error

value for

Enter your password

message Enter your

password
3.

Login

Pass/

Rema

Fail

rks

Pass

Pass

password
Click Login box are

Click Login box

successful.The Login

are successful.The

button is visible and

Login button is

Pass

4.

Select one of

active

visible and active

Course list are selected

Course list are

the course
5.
6.

Student list

Pass

selected
The name list are

The name list are

showed in the page

showed in the page

View another

Display box View

Display box View

Entry box

another Entry List are

another Entry List

successful and back to

are successful and

previous page

back to previous

Pass
Pass

page
7.

Logout

Click logout box are

Click logout box

successful. The Logout

are successful. The

button is visible and

Logout button is

active

visible and active

Pass

8. APPENDIX A
8.1 Manual Testing Questions & Answers
1. What is basis for test case review?
The main basis for test case review is testing techniques oriented review,
requirements oriented review and defects oriented review.

2. What are the contents of SRS documents?

Software requirements specifications and Functional requirements specifications.
3. Suppose your software and report has to deliver to lecturer at 5.00 P.M, At
that time your team member caught a high severity defect at 3P.M. But the
lecturer is cannot wait for too long. Then what is the procedure should the
team members follow?

Send him the problems software to the lecturer then ask him to wait. After the
lecturer see the siftware, explain the situation and ask some more time to fix the bug. If
the lecturer is not ready to give some more time then analyze the impact of bug and try to
find workarounds for the defect and mention these issues in the notes as known issues or
known bugs.
4. Give me examples for high priority and low severity defects?
Suppose in UTP Co-Q Online Registration there is one registration form for students.
In that form, the submit button cannot be click and submit but actually at the back end it
is happening properly with out any mistake means only missing of message. So, we can
consider this issues as high priority but low severity defects.

5. Explain about Bug Life Cycle?

1) Tester->
2) Open defect ->
3) Send to developer
4) ->If accepted moves to step 5 else sends the bug to tester gain
5) Fixed by developer->
6) Regression testing->
7) No problem inbuilt and logout (If problem inbuilt then reopen the issues to step 3)

6. How you can decide the number of test cases is enough for testing the given
modules?

The developed test cases are covered all the functionality of the application we can
say the test cases are enough.

7.How does you perform regression testing, means what test cases u select for
regression?
Regression testing will be conducted after any bug fixed or any functionality
changed. During defect fixing procedure some part of coding may be changed or
functionality may be manipulated. In this case the old test cases will be updated or
completely are written.

8. If a very low defect (user interface) is detected by you and the developer not
compromising with the defect, what will you do?
1)Reproduce the defect
2)Capture the defect screenshots
3)Document the proper inputs that we are used to get the defect in the defect report
4)Send the defect report with the screenshots, procedure for defect reproduction.
Before that, we must check the computer hardware configuration that is same as
developer system configuration and check the system graphic drivers are properly
installed or not.

9. What is positive and negative testing. Explain with example?

Positive testing - testing the system by giving the valid data

Negative testing- testing the system by giving the invalid data

10. What is your involvement in test plan?

Test lead is involved in preparing test plan test engineers are no way related in
preparing test plan role TE is test case design, and execution and bug tracking and
reporting them generally TL is involved in preparation of the test Plan.

11. Drawbacks of automated testing?

Expensive and lack of expertisation.

8.2 Plan Approval Process

Phase
User Requirement

Milestone

Description
Proposal submitted and

Planned date
12nd June 2015

approval from advisor

User Requirement

19th June 2015

Approved
Approval of Prototype

10th July 2015

M2

Approval of Software

14th July 2015

M3

Requirement
Approval of Architectural

27th July 2015

M4 & M5
M6

Design
Approval of Detailed Design
Completion of Coding
Acceptance Test Successful
Completion of Product and

29th July 2015

1st August 2015
3rd August 2014
9th August 2015

report
Submission of Report and

14th August 2015

M1
System
Requirement

Architectural
Design
Detailed Design
Transfer

Product

8.3 Test Results (php database)

8.4 TEST INCIDENT REPORTS

UTP Co-Q Online Registration Trouble reports

Project :
Code Number :

Date :
System under Test:

Software version:
Reported version:

Title:

Description:

Solution :

Modules Changed:

Comments:

Approved: _____________

Date: ___________

8.5 LETTER TEMPLATE

14 November 2015

To Whom It May Concern

Dear Sir/Ms

TDB2163 SOFTWARE ENGINEERING CLASS PROJECT

This letter will confirm that student below is currently enrolled TDB2163

SOFTWARE ENGINEERING. This student is expected to complete their

class project which contribute 20% of their coursework mark. Detail of
the student as below:
1.
2.
3.
4.
5.

Ahmad Khairulamin bin Zamri

Ameer Wafin Bin Ilias
Nur Hanis Solehah Binti Mohd Rosli
Iffah Nabilah Syaza Binti Khairul Nizam
Nurul Syafinaz Binti Azman

Project Title: Co-curriculum Online Registration System

It will a helpful for me, if you could assist them in their project.

Sincerely

8.6 Acronyms and abbreviations in software testing

ACM Association for Computing Machinery.
AFIPS American Federation of Information Processing Societies.
AIAT Artificial Intelligence Applications Testing.
ANSI American National Standards Institute http://www.ansi.org/
AMC Average Method Complexity
AQAP Allied Quality Assurance Publication
ARIN American Registry for Internet Numbers
ASTF Automated Software Test Framework
ASCII American Standard Code for Information Interchange
ATP Acceptance Test Procedure
ASTF Automated software test framework
ATLM Automated testing lifecycle methodology
ATRT Automated test and retest
ATG Automated test generator
ATLM Automated testing lifecycle methodology
AUT Application under test
ACC (Attribute Component Capability) analysis

BCS British Computer Society

BERT Bit Error Test (Diagnostic Tests)
BIST Built-in self-test (Diagnostic Tests)

BS British Standard
BONDING Bandwidth On Demand Interoperability Group
BR Business Requirement
BRS Business Requirement Specification.
BS7925-1 British Standard BS 7925-1 Vocabulary of terms in software testing
BVA Boundary Value Analysis
BITE Browser Integrated Test Environment

CA Configuration accounting
CASE Computer-Aided Software Engineering
CC Configuration control
CDR Critical design review
CE Critical error
CERT Computer Emergency Response Team
CHAP Challenge Handshake Authentication Protocol
CISP Cardholder information security program
CI Configuration item
CID Configuration identification
CM Configuration management
CMM Capability Maturity Model
CMMI Capability Maturity Model Integrated
CMP Configuration management plan
CMT Configuration Management Tool

COA Cost of achievement

COPS Common Open Policy Service
CORBA Common Object Request Broker Architecture
COTS Commercial Off-The-Shelf
COF Cost of failure
CR Change Request
CRC Class, Responsibility, Collaboration
COQ cost of quality
CRUD Create, Read, Update, Delete

DARPA Defense Advanced Research Projects Agency

DDD Database design document
DDS Data distribution service
DBA Dynamic Bandwidth Allocation
DDS Digital Data System
DES Data -Encryption Standard
DEF Defense Standard
DHS Department of Homeland Security (U.S.)
DDD Detailed Design Document
DFD Data Flow Diagram
DOD Department Of Defense (USA)
DOM Document Object Model
DRE Defect Removal Efficiency

DSDM Dynamic Systems Development Methodology

DTI Department of Trade and Industry (UK)

ECMA European Computer Manufacturers Association

EIA Electronic Industries Association
ERD Entity Relationship Diagram
ETSI European Telecom Standards Institute
FDD Functional Design Document
FDD Feature driven development - software development process. It is one of a number of Agile
methods for developing software.
FVT Function verification test
FA Functional audit
FAQ Frequently Asked Questions
FTP File Transfer Protocol
FDA Food and Drug Administration
FnPt Function point
FC Function Count
FISMA Federal Information Security Management Act (U.S.)
FP Function Point
FTC Federal Trade Commission (U.S.)

GOSIP Government Open Systems Interconnection Profile

GUI Graphical User Interface

GTAC Google Test Automation Conference

GTA Google Test Analytics

HCM Hardware configuration management

HIPAA Healthcare Portability and Accountability Act of 1996
HIPO Hierarchy, Input, Processing, Output
HOL Higher Order Logic
[Acronyms and abbreviations in software testing Back to Top]

IDE Integrated Development Environment

IDD Interface design document
IEC International Electrotechnical Commission
IEEE Institute of Electrical and Electronics Engineers
IDL Interface design language
IRC Internet relay chat
I-P-0 Input-Process-Output
IPsec Internet Protocol Security
ISAKMP Internet Security Association and Key Management Protocol
ISDN Integrated Services Digital Network
lSLE Integrated Software Lifecycle Environment
ISO International Organization for Standards

JAD Joint Application Development

JTC1 Joint Technical Committee 1
KBSA Knowledge-Based Software Assistant
KLOC Thousands of lines of code
LCL Lower control limit
LCSAJ Linear Code Sequence And Jump (a software analysis method)
LOC Lines of code
LSRT Long-Sequence Regression Testing

MDD Model-driven development (agile model-driven development - AMDD)

MOD Ministry of Defence (UK)
MTBF Mean Time Between Failure
MTTF Mean Time To Fail
MTTR Mean Time To Repair
MTTCF Mean time to critical failure

NCSA National Cyber Security Alliance

NFR Nonfunctional requirements
NIST National Institute of Standards and Technology
NBS National British standard

ORD Object Relationship Diagram

OCM Operational configuration management

OSI Open Systems Interconnection
OKRs Objectives and key results

PA Physical audit
PCA Performance and Coverage Analysis
PDR Preliminary design review
PERT Program Evaluation and Review technique Diagram
PIR Postimplementation review
PCRTS Problem and Change Request Tracking System
PIM Platform-Independent Model
PIPEDA Personal Information Protection and Electronic Documents Act
PIM Platform-independent model
POF Probability of Failure
POST Power- On Self - Test (Diagnostic Tests)
PSI Platform-Specific Implementation
PT Problem Ticket
PTR Problem trouble report

QA Quality Assurance
QC Quality Control
QMS Quality Management System
QoS Quality of Service

QUES Quality Evaluation System

RAD Rapid Application Development

RAT Real Application Testing [Abbreviation used by Oracle]
RCA Root cause analysis
RTM Requirements traceability matrix
RFC Request for Change
RFC Request for comments
RFP Request for Proposal
RMI Remote Method Invocation
ROI Return on Investment
RIB Reflexive User Interface Builder
RTM Requirements traceability matrix
RST Reverse Semantic Traceability
RPF Record and Playback framework

SA Structured Analysis
SADT Systems Analysis and Design Technique
SCA Static Code Analysis
SC Security Checklist
SCA Source Code Analyzer
SCR Software Change Request
SDK Software Development Kit

SC Standards committee
SDLC Software development life cycle
SDP Software development plan
SEI Software Engineering Institute
SG Standards group
SIR System Investigation Report
SLC Software life cycle
SQS Software quality system
SQSP Software quality system plan
SRR Software requirements review
SDD System and software design document
SMARTS Software Maintenance and Regression Test System
SSH Secure Shell
SOA Service-oriented architecture
STAF Software testing automation framework
Std standard (IEEE designation)
STEP Systematic Test and Evaluation Process
START Structured Testing and Requirements Tool
STL Software testing lifecycle
STR Software trouble report
STR System trouble report
SUT System Under Test
SETs Software engineers in test

TCAT Test Coverage Analysis Tool

TCB Trusted Computing Base
TCDY Test case design yield
TDD Test-driven development
TDGEN Test filelData Generator
TLS The Transport Layer Security
TOE Target of Evaluation
TPT Time Partition Testing
TQC Total quality control
TTCN Testing and Test Control Notation
TTCN-1 Tree and Tabular Combined Notation version 1
TTM Test traceability matrix
TRR Test readiness review
TEMs Test engineering managers
TAP Test Automation Program
UCL upper control limit
UDF unit development folder
UML Unified Modelling Language
UDDI Universal Description, Discovery and Integration
UML TP UML Testing Profile
URI Uniform Resource Identifier
URL Uniform Resource Locator

USM User-based Security Model

UTC Usability-Test Candidate

VE Virtual environment
V&V Verification and validation
VNC Virtual network computing
XP eXtreme Programming

8.7 References
Massachusetts Institute of Technology (2005, November 28). Software Test Report.
Retrieved from http://www.slideshare.net/Softwarecentral/software-test-plan
?qid=215bbe5e-9b9a-42e0-8802-7aa6d614e6a7&v=qf1&b=&from_search=6

Sigma Five PTE LTD (2008, February 25). Online Movie Ticketing System . Test Case
Registration. Retrieved fromhttp://worldofindependent.50webs.com/
Registration%20Test%20Case%20v1%20Ap

proved.pdf

For