cpis 357 software quality & testing

16
CPIS 357 Software Quality & Testing I.Rehab Bahaaddin Ashary Faculty of Computing and Information Technology Information Systems Department Fall 2010

Upload: bunny

Post on 31-Jan-2016

51 views

Category:

Documents


1 download

DESCRIPTION

CPIS 357 Software Quality & Testing. I.Rehab Bahaaddin Ashary Faculty of Computing and Information Technology Information Systems Department Fall 2010. Chapter 1 :Basic Concepts and Preliminaries. Lecture Objectives The Quality Revolution Software Quality Role of Testing - PowerPoint PPT Presentation

TRANSCRIPT

Page 1: CPIS 357 Software Quality & Testing

CPIS 357 Software Quality & Testing

I.Rehab Bahaaddin Ashary

Faculty of Computing and Information Technology

Information Systems DepartmentFall 2010

Page 2: CPIS 357 Software Quality & Testing

Chapter 1 :Basic Concepts and Preliminaries

Lecture Objectives• The Quality Revolution• Software Quality• Role of Testing• Verification and Validation• Failure, Error, Fault and Defect• Notion of Software Reliability• Objective of Testing• What is a Test Case?• Expected Outcome• Concept of Complete Testing

Page 3: CPIS 357 Software Quality & Testing

The Quality Revolution

• Started in Japan by Deming, Juran, and Ishikawa during 1940s• In 1950s, Deming introduced statistical quality control to Japanese

engineers

• Statistical quality control (SQC) is a discipline based on measurement and statistics . Decisions are made and plans are developed based on the collection and evaluation of actual data in the for of metrics, rather than initiation and experience.

- SQC methods use seven basic quality management tool Pareto analysis, Trend Chart, Flow chart, Histogram, Scatter diagram, Control chart, Cause and effect diagram

Page 4: CPIS 357 Software Quality & Testing

The Quality Revolution

• Deming introduced Shewhart’s PDCA cycle to Japanese researchers.

Figure 1: The Shewhart cycle

• “Lean principle” was developed by Taiichi Ohno of Toyota“A systematic approach to identifying and eliminating waste through continuous improvement, flowing the product at the pull of the customer in pursuit of perfection.” defined by the National Institute of Standards and Technology (NIST)

Page 5: CPIS 357 Software Quality & Testing

The Quality Revolution

• In 1954, Juran spurred the move from SQC to TQC (Total Quality Control).

• Key Elements of TQC: - Quality comes first, not short-term profits - The customer comes first, not the producer - Decisions are based on facts and data - Management is participatory and respectful of all employees - Management is driven by cross-functional committees

• An innovative methodology developed by Ishikawa called cause-and-effect diagram (Fish bone diagram)

Figure 2: Ishikawa diagram

Page 6: CPIS 357 Software Quality & Testing

The Quality Revolution

• National Broadcasting Corporation (NBC) of United States broadcast a documentary

“If Japan Can ... Why Can’t We?” on June 24th, 1980

• Leaders in United States started emphasizing on quality• In 1987 Malcolm Baldrige National Quality Award was

introduced in U.S.A

Similar to the Deming prize in Japan

• In Baldrige National Award the quality is viewed as: Customer Driven Quality

Something defined by the customer

• In Deming prize, the quality is viewed as:

Something defined by the producer by conformance to specifications

Page 7: CPIS 357 Software Quality & Testing

Software Quality

• Five Views of Software Quality:Transcendental viewUser’s viewManufacturing viewProduct viewValue-based view

•The concept of software quality and the efforts to understand it In terms of measurable quantities data back to the mid 1970s McCall, Richards and Walters were the first to study the concept of software quality in terms of two quality factors and quality criteria.

Page 8: CPIS 357 Software Quality & Testing

Software Quality

•Quality Factors A quality factor represents behavioral characteristic of a system Examples: correctness, reliability, efficiency, and testability

Quality riterion Is an attribute of a quality factor that is related to software development Example: modularity is an attribute of software architecture

• Quality ModelsExamples: ISO 9126, CMM (Software Quality) TPI,TMM (Software Testing)

Page 9: CPIS 357 Software Quality & Testing

Role of Testing• Reach quality by repeat test – find defect – fix cycle during development.

•Assess how good our system is when we perform system level tests before releasing a product.

•Software testing is a verification process for software quality assessment and improvement.

•Software quality assessment divide into two categories:• Static analysisIt examines the code and reasons over all behaviors that might arise during run time

Examples: Code review, inspection, and algorithm analysis

•Dynamic analysis•Actual program execution to expose possible program failure•One observe some representative program behavior, and reach conclusion about the quality of the system

Page 10: CPIS 357 Software Quality & Testing

Verification and Validation

Verification Validation

• Evaluation of software system that help in determining whether the product of a given development phase satisfy the requirements established before the start of that phase.

• Building the product correctly

•Review interim work products during a project life cycle to ensure their quality.

• Used static analysis (inspection, walkthrough, review, analysis and checklist) and can use dynamic analysis.

• Evaluation of software system that help in determining whether the product meets its intended use.

•Building the correct product

• Performed towered the end of system development to determine if the entire system meet s the customer’s needs and expectation.

• Using variety of test since it is running in the real environment.

Page 11: CPIS 357 Software Quality & Testing

Failure, Error, Fault and Defect

•Failure A failure is said to occur whenever the external behavior of a system does not conform to that prescribed in the system specification

•Error• An error is a state of the system.• An error state could lead to a failure in the absence of any corrective action by the system

•FaultA fault is the adjudged cause of an error

•Defect•It is synonymous of fault•It is a bug

Page 12: CPIS 357 Software Quality & Testing

The Notion of Software Reliability

• It is defined as the probability of failure-free operation of a software system for a specified time in a specified environment

• It can be estimated via random testing

• Test data must be drawn from the input distribution to closely resemble the future usage of the system

• Future usage pattern of a system is described in a form called operational profile

Page 13: CPIS 357 Software Quality & Testing

The Objective of Testing

• The stakeholders in test process are programmer, test engineer, project manager and customers.

• Different stakeholders view a test process from different perspectives as explained below:

It does work It does not work Reduce the risk failure Reduce the cost of testing

Page 14: CPIS 357 Software Quality & Testing

What is The Test Case?

• Test Case is a simple pair of<input, expected outcome>

• State-less systems: A compiler is a stateless systemTest cases are very simple Outcome depends solely on the current input

Example: <25, 5>

• State-oriented: ATM is a state oriented systemTest cases are not that simple. A test case may consist of a sequences of <input, expected outcome> The outcome depends both on the current state of the

system and the current inputATM example:

< check balance, $500.00 >, < withdraw, “amount?” >,< $200.00, “$200.00” >, < check balance, $300.00 >

Page 15: CPIS 357 Software Quality & Testing

Expected Outcome

• An outcome of program execution may includeValue produced by the program (Local/Remote) State Change (of the program/of the database)A sequence of values which must be interpreted together for the outcome to be valid

• A test oracle is a mechanism that verifies the correctness of program outputs

Generate expected results for the test inputsCompare the expected results with the actual results of execution

• In exceptional case where extremely difficult to compute the expected outcome you can do the following:

Execute the program with the selected input. observe the actual output of program execution. verify the actual outcome is the expected outcome. use the verified outcome as an expected outcome in the subsequence run of the test case.

Page 16: CPIS 357 Software Quality & Testing

Concept of Complete Testing

• Complete or exhaustive testing means“There are no undisclosed faults at the end of test phase”

• Complete testing is near impossible for most of the systemThe domain of possible inputs of a program is too large

Valid inputsInvalid inputs

The design issues may be too complex to completely test It may not be possible to create all possible execution environments of the system