300144 300888 Object Oriented Analysis
Dr Mahsa Razavi
Object Oriented Analysis – 300144 1
Lecture 9
Quality Assurance & Acceptance Testing
References
Bhuvan’s book Chapter 9 Booch’s book Chapter 7 (7.5), 9
Object Oriented Analysis – 300144 2
Things in Last Lecture
• Understanding what are interface specifications
• Creating Graphic User Interface (GUI) Specifications for Actor-Use case Interfaces
• Creating User Interface (UI) Navigation Maps (Flow diagrams)
• Prototyping – its Importance and Relevance in Problem Space
3
Things in Previous Lectures
Class Diagram
▪ Most popular diagram for OOA/D
▪ Reveals the static structures of classes
Sequence Diagram
▪ Second most popular diagram for OOA/D
▪ Captures the dynamic interactions between different objects inside the system
4
Object Oriented Analysis
–
300144
Things in Previous Lectures (Cont.)
Class Diagram Sequence Diagram
5
Object Oriented Analysis
–
300144
Main Topics of Lecture
• Relating the analysis work done thus far to testing
• Differentapproachestotesting
• Test planning for the entire project
• Creation of test designs corresponding to packages
• Creation of test cases for use cases
Object Oriented Analysis – 300144 6
Relevance of Testing in OO Analysis
Strategic (Project size and type issues)
Tactical
(Units versus Acceptance test; test beds, results and other issues)
Strategic versus Tactical Aspects of Testing
Object Oriented Analysis – 300144 7
Relevance of Testing in OO Analysis (Cont.)
• Good analysis work requires good test planning
• Testingensures:
– Models and classes are correct
– System satisfies user requirements
• Testingrequirescarefulplanningandexecution
• Usecasesprovidekeystartingpointfortestingin
the problem domain
• Testing (quality control) is not quality assurance, but a part of it.
Object Oriented Analysis – 300144 8
Organization of testing
Test Plan
Strategic: Created for the entire Project.
Test Design 1
Test Case 1 Test Case 2
Test Design 2
Test Case 1 Test Case 2
Created per Package;
Tactical: Created per Element (like a Use case or a Class)
Test Case 3
Object Oriented Analysis – 300144
9
Test Case 3
Test Plan
• Focus on the higher, strategic aspect of testing → scope of testing, the time and cost of required resources, and other high-level matters
– Large Projects: require bigger system testing lifecycle and should factor-in the costs and time for rework resulting from testing
• Start as soon as package is developed
• Part of the iterative and incremental development
lifecycle
– Small Projects:
• Focus on testing almost the entire product when it becomes available
• Have relatively few walkthroughs and inspections
Object Oriented Analysis – 300144 10
What is Expected in a Test Plan
• The objective of the testing
• People and processes involved in testing
• The overall acceptance criteria
• List of test designs
• Approaches and methods to be used for testing in detail
• The responsibilities and schedule for testing
• Strategy for reporting of errors and re- testing
Object Oriented Analysis – 300144 11
Test Designs
• Test designs can be created based the understanding of the system at a subsystem or component level.
• The test designs result from package diagrams as well as from the use case documentations in modelling of the problem domain
• The user can also contribute to these test designs and may use these test designs for acceptance testing
Object Oriented Analysis – 300144 12
Test Designs – Format
• Name – name should be reflect the nature of the test design
• Module – indicates details of the subsystem, package or any other module within the target system. It contains a brief description of the type of package being tested, the preparation required for the package testing and the various categories of test case needed.
• Dependency – indicates the other test designs on which this test design depends. This is helpful when creating test cycles, incorporating the test design.
• List of test cases – this is a list of test cases that make up the test design.
Object Oriented Analysis – 300144 13
Test Types
User
Object Oriented Analysis – 300144
14
Programmer
Test Types (Cont.)
• Unit Test: dealing with testing the functionality of small units in the model and the system, such as the use cases and classes
• Component Test: where the functionality of an entire component or subsystem is tested
• SystemTest:wherefunctionalityoftheentire system, together with inter-dependencies between components, is tested
• Integration Test: dealing with testing the entire system as well as its interfaces with all other systems and databases already in production
Object Oriented Analysis – 300144 15
Test Types (Cont.)
• Acceptance Test: conducted by the users of the system independent of the developers, before accepting the system
• Operational Test: dealing with testing the system for its operational characteristics, such as performance, volume, security and scalability.
• Regression Test: performed over the entire system after bugs have been fixed even on one part or package of the system
Object Oriented Analysis – 300144 16
Relating Tests to Home Inspections
• Unit Test – whether the sinks, light fittings, toilet flushes work properly?
• Component Test – whether everything in the bathroom/kitchen/lounge works?
• System Test – does the house have any major issues or problems?
• Integration Test – does the granny flat added to the backyard affect anything in the house?
Object Oriented Analysis – 300144 17
Relating Tests to Home Inspections (Cont.)
• Acceptance Test – pre-settlement inspection
• Operational Test – are the rooms sound- proof? are the insulations good enough to keep the rooms warm in winter and cool in summer?
• Regression Test – whether a newly added wall socket would affect the rest of the house?
Object Oriented Analysis – 300144 18
Testing Approaches
• Black-white box testing: Deal with the openness or closeness of the element being tested
– Black box tests only concern with inputs and outputs – White box tests go detailed checking, i.e. logic in the
functions and procedures of software
• Manual or automated testing: Indicate the type of people and tools used in testing
– Manual testing involves with testers and the results are checked manually
– Automated testing uses automated testing tool to verify the software → use in regression testing when large amount of testing has to be repeated.
Object Oriented Analysis – 300144 19
Testing Approaches (Cont.)
• Vertical versus horizontal testing
– Indicate behavioural versus technical slicing of the
system for testing respectively.
– Vertical testing divides a system into subsystem from the application viewpoint and incorporating those divisions in the test design.
– Horizontal testing occurs when the approach to testing a system is based on its infrastructure rather than its functionality.
• The equivalence partitioning and boundary values
– Indicate how the test data is to be sampled for testing
– Equivalence partitioning is applicable to the data, time or any other variable that makes up the data entity.
– Boundary values are the edges of the equivalence partitions
Object Oriented Analysis – 300144 20
Use Case versus Class based Test Designs
Class 1 Class 2
Class 3 Class 4
Class 5
Use Case 1
Use Case 2
Use Case 3
Use Case 4
A test case for a use case cuts across many classes and vice versa that for a class test cuts across many use cases. Acceptance Tests
are mainly Focused on testing use cases.
Object Oriented Analysis – 300144
21
© www.methodscience.com
Test Case Format
• In general, a test case format would consist of the following parts.
• Identification–anameandnumbertoidentifya test case
• Purpose – the reason for the test (e.g. verifying business logic or checking the validity of the date field on a screen)
• Prerequisites – that are necessary before the test can be carried out. These prerequisites relate to a particular test case. The prerequisite for the entire test design for the module will be documented separately.
Object Oriented Analysis – 300144 22
Test Case Format (Cont.)
• Input – the data that has to be inputted in the system: MUST CONTAIN BOTH VALID AND INVALID DATA
• Actions – the actions or steps required on part of the tester in order to carry out the test
• Expected output – which will determine whether the test was a success or a failure
• Actual output – or a placeholder for recording the actual output as the test case gets executed
• Administrative details – of the tester carrying out the tests etc.
Object Oriented Analysis – 300144 23
Valid and Invalid Inputs in Test Cases
INPUT for “Patient Registration DATE” field
Comment
30 Sep, 2009
Typical valid standard input. Accept; Pass.
31 Dec, 2008.
Another valid input on the boundary. Accept; Pass.
29 Feb, 2011.
An Invalid input. System should reject for Pass.
00 00 0000. Another Invalid Input. System should reject for
test to Pass.
Object Oriented Analysis – 300144 24
Test Cases for Hospital Management System
Test case for ‘RegistersPatient’
Identification: Purpose: Prerequisites: Admin:
Test case for use case UC10-RegistersPatient Input valid details for Patients
Has to be a first-time patient
Carried out by Harry Potter
Input
Actions
Expected Output
Actual Output
Name: (Surname, First name Middle Initial) Smith, David L
Address: (house no, street no, street town, state, post code)
Unit 45, 34, Gaffao St., Ermington, Vic, 3142
Date of Birth: (YYYY MM DD) 1965 12 24
Telephone No: (99 9999 9999) 03 9002 4002
Medicare No: (M999999) M123456
Status: (Private/public) Public
The name, address, Date of birth, Telephone number, Medicare number and status (where public or private patient) is to be entered in the given format.
New patient should be created with a patient number generated by the system.
New registered patient in the name of Smith, David L with patient id: P 3001 who is a public patient with a Medicare number of M123456.
Object Oriented Analysis – 300144 25
Test Cases for Hospital Management System (Cont.)
Input
Actions
Expected Output
Actual Output
Name: (Surname, First name Middle Initial) Hassel, 123 L
Address: (house no, street no, street town, state, post code)
45, Hassler St, Mt. Anan, NSW 2333
Date of Birth: (YYYY MM DD) 1965 12 24
Telephone No: (99 9999 9999) 03 9003 5002
Medicare No: (M999999) M788456
Status: (Private/public) Private
The name, address, Date of birth, Telephone number, Medicare number and status (where public or private patient) is to be entered in the given format.
New patient should NOT be created due to WRONG Name data format entry. An error message should be generated.
Display message: Invalid name, given name contains numerical characters.
Name: (Surname, First name Middle Initial) Yallop, Graham N
Address: (house no, street no, street town, state, post code)
44, Nomess St, Erinsborogh, SA 2333
Date of Birth: (YYYY MM DD) 21 10 1966
Telephone No: (99 9999 9999) 03 8003 4544
Medicare No: (M999999) M2345321
Status: (Private/public) Private
The name, address, Date of birth, Telephone number, Medicare number and status (where public or private patient) is to be entered in the given format.
New patient should NOT be created due to WRONG Date of Birth data format. An error message should be generated.
Display message: Invalid Date of Birth. The format is YYYY MM DD. Please re- enter.
Object Oriented Analysis – 300144 26
Test Cases for Hospital Management System (Cont.)
Test case for ‘MaintainsCalendar’
Identification: Test case for use case UC22-MaintainsCalendar Purpose: This test case for the use case that deals with the maintenance of personal calendars by staff of the hospital Prerequisites: A valid staff member with a valid login
Admin: Carried out by Ron Weisley
Input
Actions
Expected Output
Actual Output
Login:
wes123
Roster Preferences: 21
Week start date: 22-11-2004
Hours: 38
The staff member logs in, clicks for his/her calendar, enters the preferred roster number and weekly hours
Calendar should be created/updated for the login staff member indicating his/her new work hours.
Roster for Week starting 22-11-2004.
Monday 1:00-8:30pm Tuesday 1:00-8:30pm Wednesday 1:00-8:30pm Thursday 1:00-8:30pm Friday 1:00-9:00pm
Object Oriented Analysis – 300144 27
Test Cases for Hospital Management System (Cont.)
Input
Actions
Expected Output
Actual Output
Login:
adn123
Roster Preferences: 22
Week start date: 22-11-2004
Hours: 50
The staff member logs in, clicks for his/her calendar, enters the preferred roster number and weekly hours
Calendar should NOT be created/updated for the login staff member indicating his new desired work hours exceeds the maximum allowed per week
Display message:
Invalid entry due to work hours > 38 hours per week
Login:
12223
Roster Preferences: 21
Week start date: 22-11-2004
Hours: 35
The staff member fails login due to wrong login
The staff member should NOT be able to login due to wrong login data format
Display message: invalid login. Please re-enter
Object Oriented Analysis – 300144 28
Test Cases for Hospital Management System (Cont.)
Test case for ‘PaysBill’
Identification: Test case for use case UC50-PaysBill
Purpose: This test case for the use case that describes the process by which a patient pays his medical bill
Prerequisites: Patient must be registered in the system
Admin: Carried out by John Citizen
Input
Actions
Expected Output
Actual Output
Login:
P2003
Payment type: Cash/cheque/Card/Bpay
Patient logs in and the bill is displayed. After checking the details the patient will opt for a payment type.
A printed bill for customer as an invoice to be settled.
Invoice No. 200303 Amount to be settled: $125
Date of Payment: 02/10/2004
Patient login: 1234X
Patient tries to login but fails as the login is incorrect
Prompt saying ‘Invalid Login/Password’. Please try again
Display message: ‘Invalid login. Please try again’
Object Oriented Analysis – 300144 29
Test Cases for Hospital Management System (Cont.)
Test case for ‘PaysBillOnInternet’
Identification: Test case for use case UC56-PaysBillOnInternet
Purpose: This test case for the use case that describes the process by which a patient pays his medical bill on the Internet by credit card Prerequisites: Patient must be registered in the system
Admin: Carried out by John Citizen
Input
Actions
Expected Output
Actual Output
Patient Login:
P2003
Payment type: Credit Card Credit card No.
1111 2222 3333 4444
Valid until:
10/2012
Type:
VISA
Patient logs in and the bill is displayed. After checking the details, the patient will opt to pay the bill on the Internet. Once the bill is checked, the card details are to be entered. Card will have to be authenticated.
A receipt indicating the receipt number for the payment made.
Payment authenticated. Receipt No.
200303
Amount:
$330.00
Patient Login:
P3423
Payment type: Credit Card Credit card No.
1111 2452 3323 44
Valid until:
10/2012
Type:
VISA
Patient logs in and the bill is displayed. After checking the details, the patient will opt to pay the bill on the Internet. Once the bill is checked, the card details are to be entered. Card will have to be authenticated.
Prompt saying the invalid input in the credit card details.
Object Oriented Analysis – 300144
Display message: Invalid credit card. Please enter credit card number again
30
From Use Cases to Test Cases
• Use case – what the system does to interact with the actors to achieve a measurable goal
• Userinterface–interfacingbetweenthesystemand user of the system, e.g. screens, forms
• Testcase–whethercorrect/incorrectinputwouldbe accepted/handled by the user interface to achieve the goal targeted by the use case
Object Oriented Analysis – 300144 31
Use Case for WithdrawCash
Use Case Thumbnail: UC10-WithdrawCash
Actors: A20-BusinessCustomer, A130-BusinessCustOp, A110-Teller
Use Case Description: this use case deals with withdrawal of a business customer via a business customer operator and a bank teller. A20-BusinessCustomer provides all the bank details, identification and the amount of withdrawn money. A130- BusinessCustOp enter the information and validate if the transaction is satisfied before handing the case to a bank teller. The teller will carry out withdrawal transaction. The cash and the receipt will be given to the customer.
Pre-Conditions: Customer is already registered in the system. Post-Conditions: Customer is given the cash and the receipt.
Object Oriented Analysis – 300144 32
Exercise – Test Cases for “WithdrawCash”
Test case for ‘WithdrawCash’
Identification: Test case for use case UC199-WithdrawCash
Purpose: This test case for the use case that a customer can withdraw his/her money from a teller with a given amount
Prerequisites: the customer has to be registered and the bank teller is logged in Admin: Carried out by John Citizen
Input
Actions
Expected Output
Actual Output
Amount (balance 1000 for saving and cheque, 2000 in credit):
500
Account Type (Credit, saving, cheque)
saving
The staff swift the bank card of the customer, and input the amount and account type based on the request of the customer
The transaction is valid and the customer will get 500 cash from the system, the balance is now updated to 500
The system update the customer balance to 500, and a receipt is printed
Amount (balance 1000 for saving and cheque, 2000 in credit):
1500
Account Type (Credit, saving, cheque)
saving
The staff swift the bank card of the customer, and input the amount and account type based on the request of the customer
The system notifies the bank teller that the amount is over the limit
Object Oriented Analysis – 300144
33
Use Case – MakeNewBooking
Use Case Thumbnail: UC10-MakeNewBooking
Actors: A20-OnlineCustomer, A130-OnlineCustOperator, A00-
Printer
Use Case Description: this use case deals with booking a new travel online. A20-OnlineCustomer selects destinations, date and time and any associated activities, such as car rental, hotel, etc. A20-OnlineCustomer also need to log onto the system in order to confirm the booking and pay the fee. The customer operator must double check the booking and contacting the customer if required. A receipt will be given to the customer.
Pre-Conditions: N/A.
Post-Conditions: Booking is issued with the receipt.
Object Oriented Analysis – 300144 34
35
User Interface (Mock-up Screen) for MakeNewBooking
Exercise – Test Cases for MakeNewBooking
Test case for ‘MakeNewBooking’
Identification: Test case for use case UC10-MakeNewBooking
Purpose: This test case for the use case that a customer make a new booking online Prerequisites: Internet and computer is available
Admin: Carried out by John Citizen
Input
Actions
Expected Output
Actual Output
From (A list of cities is available):
Sydney
To (A list of cities is available):
Los Angeles, USA
Depart On: 26/09/2012
Return On: 25/10/2012
Flexible with date (Yes/No): Yes
Car Rental/Accommodations/Tours: No Adults: 1; Children: 0; Infants: 1
The customer input the desirable information into the form, including From, To, Depart/Return dates, associate activities and travellers.
The system validates the form and find the corresponding trips.
The transaction is valid and the system will display the matching information to the customer
Matching information is shown on the form. It also suggests related activities for the trip
From (A list of cities is available):
Sydney
To (A list of cities is available):
Los Angeles, USA
Depart On: 26/09/2012
Return On: 25/10/2011
Flexible with date (Yes/No): Yes
Car Rental/Accommodations/Tours: No Adults: 1; Children: 0; Infants: 1
The customer input the desirable information into the form, including From, To, Depart/Return dates, associate activities and travellers.
The system validates the form and find the
The transaction is invalid and the system will display error message
Object Oriented Analysis – 300144
corresponding trips.
Error message is shown: “Invalid return date! Return date must be after Depart date.”
36
Case Study: Use Case Test • Use Case: GetDiary
• Cuts cross many classes – Diary
– Entry
– EntryByDate – EntryByDay – SimpleDate – SimpleTime
Object Oriented Analysis – 300144 37
Case Study: Use Case Test
• Develop a Java
program that reads entries from the a text file and generates the diary in a HTML file
# Diary.txt Peter’s event entries
# S M T W H F A: Sun, Mon, Tue, Wed, tHu, Fri, sAt
14/2 – valentine’s day
MTWHF 9-17 working hours
SA 14:30-4:30pm sports # or armchair sports
0/7 –
28 10am-11 11/5/20 –
F 8pm-10pm H 6pm- 1/0/16 -12pm 28/6 –
May is for holidays monthly meetings
Mike arrives in Sydney bar crawl
shopping
special morning session
Shirley’s birthday
java Diary < Diary.txt > Diary.html
Object Oriented Analysis – 300144 38
Case Study: Use Case Test
• Use Case: GetDiary that cuts cross many classes
– Diary
– Entry
– EntryByDate – EntryByDay – SimpleDate – SimpleTime
• java Diary < Diary.txt > Diary.html
Object Oriented Analysis – 300144 39
A Software Failure Story
• On June 4, 1996, the maiden flight of the European Ariane 5 launcher crashed about 40 seconds after takeoff. Media reports indicated that the amount lost was half a billion dollars — uninsured.
• Reason: the result of a software pitfall
• The problem was due to a floating-point error: a conversion from a 64-bit integer to a 16-bit signed integer, which should only have been applied to a number less than 215, was erroneously applied to a greater number, representing the “horizontal bias” of the flight. There was no explicit exception handler to catch the exception, so it followed the usual fate of uncaught exceptions and crashed the entire software, hence the on-board computers, hence the mission.
Object Oriented Analysis – 300144 40
Conclusions
• TestArchitecturehasTestPlansatprojectlevel, Test Designs at package level and Test Cases at unit level
• Class based test design focuses on classes as the basic testing unit and creates a test case to test each classes
• Use case based test design focuses on use cases as the basic testing unit and creates a test case to test each use case
• User acceptance testing can be use case based; unit testing by programmers can be class based;
• Test cases should contain both valid and invalid
input data
Object Oriented Analysis – 300144 41
Following Weeks – Lectures
Week 12:
• Architectural & Operational Requirements
• Guidance for Applied Project Week 13:
• An introduction to OOD Week 14:
• Revision for the final exam
– Highlight main contents of the unit
– Sample questions for checking understanding
– Format of final exam paper
– Explanation about the online exam
Object Oriented Analysis – 300144 42
• • •
Following Weeks – Practical Sessions
Week 12 Practical 9 (assessable)
– Test Cases
– Briefing session for project submission and marking
Week 13: Practical 10 (assessable)
– Operational Requirements
– Resolving outstanding issues in Project
Week 14: Practical 11 (non-assessable)
– Continuing with project work
– Resolving outstanding issues in project
– Preparing for the submission
Object Oriented Analysis – 300144 43
Project Work : (During Tutorials in the Lab);
Follow the Project Work Requirements given at the End of the Chapter;
Discuss Project Work with Team Members and Tutor;
Carry Out the Project Work
Object Oriented Analysis – 300144 44
RUP Case Study – Train Traffic Management System (TTMS)
Construction – 2
Object Oriented Analysis – 300144 45
Train Schedule Planning
• A train plan is central to the operation of the Train Traffic Management System.
• A train plan acts as a repository for all the pertinent information associated with the route of one particular train and the actions that take place along the way
• The diagram captures strategic decisions regarding the structure of the TrainPlan class
Object Oriented Analysis – 300144 46
Train Schedule Planning (Cont.)
• The parts that compose a train plan (much as a traditional entity-relationship diagram would do)
• Each train plan has exactly one crew and may have many general orders and many actions
• These actions to be time ordered, with each action composed of information such as time, a location, speed, authority, and orders
Object Oriented Analysis – 300144 47
Train Schedule Planning (Cont.)
• In theory, all train plans can be put in a single, centralised database, yield exactly one instance of each train plan.
• With expected communication delays and limited processing capability, the solution is as follows
– have a database of train plans at the dispatch centre
– with copies of individual plans distributed as needed at
sites around the network
– each train computer could retain a copy of its current plan
– If the plan changed, either as a result of dispatcher action or (less likely) by the decision of the train engineer, our software would have to ensure that all copies of that plan were updated in a timely fashion.
Object Oriented Analysis – 300144 48
Train Schedule Planning (Cont.)
• Whenthedispatchcentreinitiatesthechangeof the Train Schedule, the primary version of the plan would be updated first
• Then changes to all copies would be broadcast throughout the network, using the same mechanism, messagepassing design earlier
• Usingcommercial,off-the-shelfdatabase management systems on the dispatch computers allows us to address any requirements for database backup, recovery, audit trails, and security.
Object Oriented Analysis – 300144 49
Train Schedule Planning (Cont.)
Object Oriented Analysis – 300144 50