G&W Chapter 22: Test Cases Software Specification Lecture 29

Slides:



Advertisements
Similar presentations
Informatics 43 – April 30, What is a test case? An input to a system, and the correct output. An “input” may be complex. Example: – What is an input.
Advertisements

Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory,Requirements Engineering Course, Dr. Abdollahzadeh 1 Requirements.
1 درس مهندسي نيازمندي استاد دكتر عبداله زاده دانشجو خيرالنسا مرچانت RE in The Year 00: A Research Perspective.
Requirements Engineering Process – 1
Functional Testing Test cases derived from requirements specification document – Black box testing – Independent testers – Test both valid and invalid.
Software testing techniques Software testing techniques Testing based on specifications Presentation on the seminar Kaunas University of Technology.
1 Software Testing (Part-II) Lecture Software Testing Software Testing is the process of finding the bugs in a software. It helps in Verifying and.
ITEC 370 Lecture 5 Requirements. Review Requirements –What did you learn? –Why are requirements part of the process? –What is the difference between a.
1 REQUIREMENT ENGINEERING Chapter 7. 2 REQUIREMENT ENGINEERING Definition Establishing what the customer requires from a software system. OR It helps.
Chapter 5: Requirement Engineering Process Omar Meqdadi SE 2730 Lecture 5 Department of Computer Science and Software Engineering University of Wisconsin-Platteville.
Black-Box Testing Techniques II Prepared by Stephen M. Thebaut, Ph.D. University of Florida Software Testing and Verification Lecture 5.
Testing Basics of Testing Presented by: Vijay.C.G – Glister Tech.
Black-Box Testing Techniques I
Unit Testing 101 Black Box v. White Box. Definition of V&V Verification - is the product correct Validation - is it the correct product.
Black Box Testing Focuses in the functional requirements of the program It is not an alternative to white-box techniques It is a complementary approach.
Case Study: Black-Box Testing Prepared by Stephen M. Thebaut, Ph.D. University of Florida Software Testing and Verification Lecture 6.1.
Requirements Validation
LECTURE 19 23/11/15 Software Quality and Testing.
Test Case Designing UNIT - 2. Topics Test Requirement Analysis (example) Test Case Designing (sample discussion) Test Data Preparation (example) Test.
1 The Requirements Problem Chapter 1. 2 Standish Group Research Research paper at:  php (1994)
Week 6 MondayTuesdayWednesdayThursdayFriday Testing III Reading due Group meetings Testing IVSection ZFR due ZFR demos Progress report due Readings out.
REQUIREMENTS ENGINEERING PROCESSES Chapter 6. Activities in Requirements Engineering processes  Requirements elicitation;  Requirements analysis; 
Chapter 4 – Requirements Engineering
PREPARED BY G.VIJAYA KUMAR ASST.PROFESSOR
Equivalence partitioning
White-Box Testing Techniques IV
Domain Testing Functional testing which tests the application by giving inputs and evaluating its appropriate outputs. system does not accept invalid and.
TESTING TOOLS MANUAL APPROACH BY J.ADI SESHU.
White-Box Testing Techniques IV
IS301 – Software Engineering V:
Black-Box Testing Techniques I
Prepared by Stephen M. Thebaut, Ph.D. University of Florida
Lecture on Black Box Testing
Case Study: Black-Box Testing
Requirements Elicitation – 1
Chapter 13 & 14 Software Testing Strategies and Techniques
Requirements and Specifications
Prepared by Stephen M. Thebaut, Ph.D. University of Florida
Prepared by Stephen M. Thebaut, Ph.D. University of Florida
Prepared by Stephen M. Thebaut, Ph.D. University of Florida
The Design Process.
Chapter 24 Testing Object-Oriented Applications
G&W Chapter 24: Making Agreements Software Specification Lecture 31
G&W Chapter 17: Preferences Software Specification Lecture 24
Prepared by Stephen M. Thebaut, Ph.D. University of Florida
Black-Box Testing Techniques III
Requirements Analysis
Testing and Test-Driven Development CSC 4700 Software Engineering
Prepared by Stephen M. Thebaut, Ph.D. University of Florida
G&W Chapter 19: Ambiguity Metrics Software Specification Lecture 26
Static Testing Static testing refers to testing that takes place without Execution - examining and reviewing it. Dynamic Testing Dynamic testing is what.
G&W Chapter 25: Ending Software Specification Lecture 32
G&W Chapter 16: Constraints Software Specification Lecture 23
G&W Chapter 20: Technical Reviews Software Specification Lecture 27
Software testing.
Chapter 19 Testing Object-Oriented Applications
Chapter 10 – Software Testing
White-Box Testing Techniques I
Chapter 19 Testing Object-Oriented Applications
Black-Box Testing Techniques III
Requirements Engineering Process – 1
Black-Box Testing Techniques II
Requirements Validation – I
G&W Preface Software Specification Lecture 4
Prepared by Stephen M. Thebaut, Ph.D. University of Florida
Prepared by Stephen M. Thebaut, Ph.D. University of Florida
Prepared by Stephen M. Thebaut, Ph.D. University of Florida
Black-Box Testing Techniques II
Think about your view of QA
G&W Chapter 15: Attributes Software Specification Lecture 22
Presentation transcript:

G&W Chapter 22: Test Cases Software Specification Lecture 29 Prepared by Stephen M. Thebaut, Ph.D. University of Florida

Part V: Greatly Improving the Odds of Success Ambiguity Metrics Technical Reviews Measuring Satisfaction Test Cases Studying Existing Products Making Agreements Ending

Rationale Designing black-box test cases jointly with clients early in the requirements process is an extremely effective way to stimulate anticipation of product use (and therefore elicit requirements). stimulus response

Test Case Forms / Sources Stimulus-response pairs, as in: “If X happens, the product should do Y.” Input and output conditions Causes and Effects Scenarios / Use-Cases: threads of hypothetical product behavior Marketing brochures User manuals

Black-Box Coverage Strategies Equivalence Partitioning: sampling valid and invalid equivalence classes of stimuli (“inputs”). Boundary Value Analysis: exploring valid and invalid stimuli near constraint boundaries.

Black-Box Coverage Strategies (cont’d) Cause-Effect Analysis: systematic exploration of valid and invalid stimuli combinations. Intuition and Experience: explore unexpected or unusual product use or environmental scenarios.

G&W’s Black-Box Testing Process Construct test cases by imagining that the product has been built and asking “What if” questions. Answer the test cases, and discuss with stakeholders to obtain agreement. Attempting to reach agreement will generally lead to new “What if” questions. Add these to the list, answer them, and repeat the process until the list stabilizes.

G&W’s Black-Box Testing Process (cont'd) Review the list with a team of designers and professional writers to identify over-constrained replies; revise to give the greatest possible design freedom – but no more. Document the cases so they will become the starting basis for system and acceptance tests.

Automatic Test Case Synthesis? Could test cases (e.g., scenarios – threads of hypothetical product behavior) be generated automatically / semi-automatically during the early stages of RE to stimulate anticipation?

Automatic Test Case Synthesis? (cont’d) One approach: model fragmentary, incomplete (and possibly conflicting) requirements in a rule-base and use a forward-chaining execution engine to generate scenarios of product behavior. (Marcel: Thebaut/ Interrante,1991)

G&W Chapter 22: Test Cases Software Specification Lecture 29 Prepared by Stephen M. Thebaut, Ph.D. University of Florida