Chapter 12 Levels of Testing

Slides:



Advertisements
Similar presentations
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Processes.
Advertisements

1 Requirements and the Software Lifecycle The traditional software process models Waterfall model Spiral model The iterative approach Chapter 3.
Diane Pozefsky. Interactions  There is no “right answer”  Typically people and product are fixed  … can adapt process  (which is where we will start)
PROC-1 3. Software Process. PROC-2 What’s a process? Set of activities in creating software It involves creativity –hard to automate –Requires human judgment.
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide 1 Software Processes.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 1 Slide 1 المحاضرة الثانية.
Software Project Management
1 Chapter 4 - Part 1 Software Processes. 2 Software Processes is: Coherent (logically connected) sets of activities for specifying, designing, implementing,
29 September Interactions  There is no “right answer”  Typically people and product are fixed  … can adapt process  (which is where we will.
System Development Life Cycle Process of creating and altering systems or software by using methodologies or models to develop the systems in a logical.
Software Processes Coherent sets of activities for specifying, designing, implementing and testing software systems.
Software Modeling SWE5441 Lecture 3 Eng. Mohammed Timraz
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 17 Slide 1 Rapid software development.
Alternate Software Development Methodologies
©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 3Slide 1 Software Processes l Coherent sets of activities for specifying, designing, implementing.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Process Models.
©Ian Sommerville 2000 Software Engineering, 6th edition Slide 1 Software Processes l Coherent sets of activities for specifying, designing, implementing.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Processes.
CMSC 345, Version 1/03 An Overview of Software Processes Reference: Software Engineering, by Ian Sommerville, 6 th edition, Chapter 3.
Chapter 3 Software Processes.
S/W Project Management Software Process Models. Objectives To understand  Software process and process models, including the main characteristics of.
Software Processes Sumber dari : cc.ee.ntu.edu.tw/~farn/courses/SE/ch4.ppt.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Processes.
CS 360 Lecture 3.  The software process is a structured set of activities required to develop a software system.  Fundamental Assumption:  Good software.
©Ian Sommerville 2000, Mejia-Alvarez 2009 Slide 1 Software Processes l Coherent sets of activities for specifying, designing, implementing and testing.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Processes.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 3 Slide 1 Software Processes l Coherent sets of activities for specifying, designing,
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 8 Slide 1 Software Prototyping l Rapid software development to validate requirements.
Rapid software development 1. Topics covered Agile methods Extreme programming Rapid application development Software prototyping 2.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Processes.
Chapter 2 Software processes. Topics covered Software process models Process activities Coping with change.
WATERFALL DEVELOPMENT MODEL. Waterfall model is LINEAR development lifecycle. This means each phase must be completed before moving onto the next!!! WHAT.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Processes.
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide 1 Software Processes.
Chapter 2 – Software Processes Lecture 2 1Chapter 2 Software Processes.
Software Development Process CS 360 Lecture 3. Software Process The software process is a structured set of activities required to develop a software.
10 September Interactions  There is no “right answer”  Typically people and product are fixed  … can adapt process  (which is where we will.
1 Chapter 2 SW Process Models. 2 Objectives  Understand various process models  Understand the pros and cons of each model  Evaluate the applicability.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Processes.
SOFTWARE DEVELOPMENT Presented By : Emporiumtech This presentation is brought you by
Laurea Triennale in Informatica – Corso di Ingegneria del Software I – A.A. 2006/2007 Andrea Polini II. Software Life Cycle.
Information Systems Development
Announcements/Assignments
Software Development - Methodologies
Methodologies and Algorithms
Integrating Quality Activities in the Project Life Cycle
Software Development methodologies
Software Processes (a)
Software Myths Software is easy to change
Software Process Models
Chapter 2 SW Process Models
Chapter 2: Software Process Models
Software Processes.
Requirements and the Software Lifecycle
Introduction to Software Engineering
Information Systems Development
Chapter 2 Software Processes
Software Engineering Lecture 18.
Software life cycle models
An Overview of Software Processes
An Overview of Software Processes
CHAPTER 10 METHODOLOGIES FOR CUSTOM SOFTWARE DEVELOPMENT
CS310 Software Engineering Lecturer Dr.Doaa Sami
Software Processes Process should be
Software Processes.
Chapter 2: Software Process Models
Software Engineering Lecture 17.
Information system analysis and design
Presentation transcript:

Chapter 12 Levels of Testing Software Testing: A Craftsman’s Approach, 3rd Edition Levels of Testing

Levels and Life Cycle Models Levels of testing depend primarily on the software life cycle used. BUT, most forms of testing levels are derived from the V-Model version of the good, old Waterfall Model. Iterative models introduce the need for regression testing. System testing is greatly enhanced when an executable specification is used. Software Testing: A Craftsman’s Approach, 3rd Edition Levels of Testing

Software Development Life Cycle Models Waterfall (presumes perfect foresight) Incremental (delayed prototypes) Rapid Prototyping (elicit user feedback) Operational Specification (executable) Transformational Implementation (lab only) Agile Methods Increasingly Operational views Ref. Agresti, New Paradigms of Software Development IEEE Tutorial Software Testing: A Craftsman’s Approach, 3rd Edition Levels of Testing

The Waterfall Model Output of a phase is the input to the next phase Requirements Specification Preliminary Design Detailed Design Coding Unit Testing Output of a phase is the input to the next phase Integration Testing System Testing Software Testing: A Craftsman’s Approach, 3rd Edition Levels of Testing

The Waterfall Model (continued) Requirements Specification what Preliminary Design what how Detailed Design what how Coding how Unit Testing Integration Testing Feedback Cycles System Testing Software Testing: A Craftsman’s Approach, 3rd Edition Levels of Testing

The Waterfall Model (aka the V-Model) Levels of Abstraction and Testing Requirements Specification System Testing Preliminary Design Integration Testing Detailed Design Unit Testing Coding Software Testing: A Craftsman’s Approach, 3rd Edition Levels of Testing

The Waterfall Model: Advantages Framework fits well with levels of abstraction levels of management programming language packaging Phases have clearly defined end products Convenient for project management Works well with Functional Decomposition Massive parallel development Software Testing: A Craftsman’s Approach, 3rd Edition Levels of Testing

The Waterfall Model: Disadvantages Long customer feedback cycle resolving faults found during system testing is extremely expensive "Exists for the convenience of management" (-- M. Jackson) stifles creativity and unnecessarily constraints designer's thought processes Stresses analysis to the exclusion of synthesis High peak in manpower loading profile "Requires perfect foresight" -- William Agresti any errors, omissions in early phases will propagate Software Testing: A Craftsman’s Approach, 3rd Edition Levels of Testing

Incremental Software Development Requirements Specification Detailed Design Preliminary Design Series of Builds Coding Unit Testing Integration Testing Regression Testing Progression Testing Software Testing: A Craftsman’s Approach, 3rd Edition Levels of Testing

Define Prototype Objectives Rapid Prototyping Software Development Define Prototype Objectives Build Prototype Series of Prototypes Preliminary Design Customer Feedback Detailed Design Coding Unit Testing Integration Testing System Testing Software Testing: A Craftsman’s Approach, 3rd Edition Levels of Testing

Rapid Prototyping Why prototype? To determine feasibility To obtain early customer feedback Keep or dispose? To be rapid, many compromises are made. If a prototype is kept, it will be extremely difficult to modify and maintain. Best practice: dispose once purpose has been served. Software Testing: A Craftsman’s Approach, 3rd Edition Levels of Testing

Software Development with an Executable Specification Develop executable specification execute spec Requirements Specification Preliminary Design Customer Feedback Detailed Design Coding Unit Testing Integration Testing System Testing Software Testing: A Craftsman’s Approach, 3rd Edition Levels of Testing

Executable Specifications Why use an executable specification? To determine behavior To obtain early customer feedback Other uses? Automatic generation of system test cases. Develop order of test case execution Training Early analysis Software Testing: A Craftsman’s Approach, 3rd Edition Levels of Testing

Transformational Implementation Formal Requirements Specification Series of Transformations Working System Customer Testing Requirements Specification System Testing Software Testing: A Craftsman’s Approach, 3rd Edition Levels of Testing

Transformational Specification Pros and Cons Advantages: Intermediate Waterfall phases (design, code, test) are eliminated. Customer tests delivered system All maintenance is done on specification Disadvantages: Specification must be very formal (predicate calculus) Series of transformations is not well understood; tends to be specific to application domains Very limited success so far. Doesn't scale up well. Knowing what to change in the formal specification is difficult Software Testing: A Craftsman’s Approach, 3rd Edition Levels of Testing

Agile Methods Many flavors Customer-Driven Goals eXtreme Programming (XP) SCRUM Test-Driven Development Customer-Driven Goals Respond to customer Reduce unnecessary effort Always have something that works Software Testing: A Craftsman’s Approach, 3rd Edition Levels of Testing

Length of Feedback Cycle (Customer/Developer) Where would you put the other life cycle models? Waterfall Agile Software Testing: A Craftsman’s Approach, 3rd Edition Levels of Testing

Hybrid Models Because they replace the Requirements specification phase, rapid prototyping and executable specifications can be merged with the iterative models. The Agile Models are highly iterative, but they typically are not used in combination with rapid prototyping or executable specifications. Software Testing: A Craftsman’s Approach, 3rd Edition Levels of Testing