REPORTSoftware 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. Ahmad Khairulamin bin Zamri 191822. Ameer Wafin Bin Ilias 190253. Nur Hanis Solehah Binti Mohd Rosli 191514. Iffah Nabilah Syaza Binti Khairul Nizam 191495. Nurul Syafinaz Binti Azman 19365

Signatures of Approval

22 April 2023

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. Ahmad Khairulamin bin Zamri2. Ameer Wafin Bin Ilias3. Nur Hanis Solehah Binti Mohd Rosli4. Iffah Nabilah Syaza Binti Khairul Nizam5. 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- 11pm

Monday

Gamelan room

Session 2

10 am-12pm

Tuesday

Gamelan room

SESSION IS FULL!

CHOOSE ANOTHER SESSION?

YOU HAVE CHOOSE

BACK EXIT

SELECT

SELECT

SESSION 1

9PM- 11PM

MONDAY

GAMELAN ROOM

YOU HAVE SUCCESFULLY REGISTERED

Design 2

UTP CoQ Online Registration Login

BACK 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 SUBMIT

Co-Curriculum ListSeach

SPORTS

VOLUNTEER WORK AND COMMUNITY SERVICES

ARTS & CULTURAL CATEGORY

Badminton Football Rugby Tennis Swimming

Peer Group Counseling

Recreation & Adventure 1

Student Voluntary Activities

Gamelan 1 Gamelan II Modern Music I Modern Music II

Gamelan 1 Class Sessionso Session 1

9PM- 11PM

TUESDAY

BADMINTON HALL,UTP

o Session 29PM- 11PM

THURSDAY

BADMINTON HALL, UTP

LIST OF STUDENTS FOR BADMINTON SESSION 1

No NAME ID COURSE YEAR Gender Day1. Ali bin Abu 12345 Bis 2nd Male Tuesday

You have been successfully registered Badminton Session 1

DONE

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 E-learning 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 Component3.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.

USER

OPEN

FILL

CHECK

DATABASE

-details saved in database

-listed the name and details in table for each session

WEBSITE

-link registration for Coq course session

DETAILS

-Sessions for each courses

-Available Sessions for chosen course

COQ COURSES

-view the list of students

AVAILABILITY

session is still available

-session is full

REGISTER

-name

-id

-course

-year

-submission of sessions

CoQ COURSES

-list of CoQ courses

-category of courses

ADMIN

LOGIN AS ADMIN

-username

-password

CoQ COURSES

View the list of students

-Print the list of students

CHECK

OPEN

DATABASE

-details saved in database

-listed the name and details in table for each session

Additional Material (contents)

ADDITIONAL ISSUESDuring 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. Ahmad Khairulamin bin Zamri 19182/ ICT2. Ameer Wafin Bin Ilias 19025/ ICT3. Nur Hanis Solehah Binti Mohd Rosli 19151/ ICT4. Iffah Nabilah Syaza Binti Khairul Nizam 19149/ BIS5. Nurul Syafinaz Binti Azman 19365/ BIS

Revision History

Revision # Revision Date

Description of Change Author

1 28/9/2005 First Draft Massachusetts Institute of Technology

TABLE OF CONTENTS

No Title Page Number1 Introduction2 System Overview3 Objective4 Scope5 Test Approach

5.1 Black Box Testing &White Box Testing

6 Test Plan 6.1Features to be tested 6.2Features not to be tested 6.3Testing Tools and Environment

7 Test Cases 7.1 Purpose 7.2Test Case Template 7.3Test Case UTP Co-Q Online Registration

8 ADDITIONAL MATERIALSAPPENDIX 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

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 co-

curriculum 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

Bounding Value Analysis

Basis Path Testing

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

Technique EffortCode

coverageDefects found

Combination of black box +

dumb

10 min 50% 25%

Combination of white box +

dumb

30 min 80% 50%

Combination of black box +

smart

2 hr 80% 50%

Combination of white box +

smart

2.5 hr 99% 100%

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.

R isks 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

Input

Expected

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 co-

curriculum

Module Name Students

Status Created

Test Information

Name Ali

ID 19152

Input Validation (USER)

No Test Cases Input

Data

Expected Value Actual Result Pass/

Fail

Rema

rks

1 Select Display message

“Register your Co-Q

class now online”

Display message

“Register your Co-Q

class now online”

Pass

2. Select one of

the course

Course list are selected Course list are

selected

pass

3. Select the

session on the

radio button

Session button are

selected

Session button are

selected

Pass

4. View

availability of

the sessions

Display box “Check

class availability” and

view

Display box “Check

class availability”

and view

Pass

5. Enter empty

value for

name

Display error message

“Name”

Display error

message “Name”

Pass

6. Enter empty

value for ID

Display error message

“ID”

Display error

message “ID”

Pass

7. Select option

button for

course

programme

Display selected course

programme

Display selected

course programme

Pass

8. Enter empty

value for year

Display error message

“Year of study”

Display error

message “Year of

study”

9. Select the

gender on the

radio button

Gender button are

selected

Gender button are

selected

Pass

10. Select submit

button

Click “Submit for

session 1” or “Submit

for session 2” are

successful

Click “Submit for

session 1” or

“Submit for session

2” are successful

Pass

11. Submit

button for

session is

choose

Popup message “The

Class session os still

available” are

successful

Popup message “The

Class session os still

available” are

successful

Pass

Input Validation (ADMIN)

No Test Case Input

Data

Expected value Actual Value Pass/

Fail

Rema

rks

1. Enter empty

value for

email

Display error message

“Enter your email

address”

Display error

message “Enter your

email address”

Pass

2. Enter empty

value for

password

Display error message

“Enter your password”

Display error

message “Enter your

password”

Pass

3. Login Click “Login” box are

successful.The Login

button is visible and

active

Click “Login” box

are successful.The

Login button is

visible and active

Pass

4. Select one of

the course

Course list are selected Course list are

selected

Pass

5. Student list The name list are

showed in the page

The name list are

showed in the page

Pass

6. View another

Entry box

Display box “View

another Entry List” are

successful and back to

previous page

Display box “View

another Entry List”

are successful and

back to previous

page

Pass

7. Logout Click “logout” box are

successful. The Logout

button is visible and

active

Click “logout” box

are successful. The

Logout button is

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 Milestone Description Planned date

User Requirement Proposal submitted and

approval from advisor

12nd June 2015

M1 User Requirement

Approved

19th June 2015

System

Requirement

Approval of Prototype 10th July 2015

M2 Approval of Software

Requirement

14th July 2015

Architectural

Design

M3 Approval of Architectural

Design

27th July 2015

Approval of Detailed Design 29th July 2015

Detailed Design Completion of Coding 1st August 2015

Transfer M4 & M5 Acceptance Test Successful 3rd August 2014

M6 Completion of Product and

report

9th August 2015

Submission of Report and

Product

14th August 2015

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

22 April 2023

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. Ahmad Khairulamin bin Zamri2. Ameer Wafin Bin Ilias3. Nur Hanis Solehah Binti Mohd Rosli4. Iffah Nabilah Syaza Binti Khairul Nizam5. 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 For

Registration. Retrieved fromhttp://worldofindependent.50webs.com/

Registration%20Test%20Case%20v1%20Ap proved.pdf