Upload
hanis-solehah
View
230
Download
0
Tags:
Embed Size (px)
Citation preview
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. [email protected]. 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
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