Chapter 12

Download as pptx, pdf, or txt
Download as pptx, pdf, or txt
You are on page 1of 17

Chapter Twelve

Software Quality Assurance

1
Overview of testing

 Quality Assurance: A set of activities designed to ensure that the


development and/or maintenance process is satisfactory to ensure a
system will meet its objectives.
 Quality Control: A set of activities designed to evaluate a
developed work product.
o QC activities focus on finding defects in specific deliverables -
e.g., are the defined requirements the right requirements.
o Testing is one example of a QC activity, but there are others such
as inspections.
 Testing: The process of executing a system with the intent of
finding defects.

2
Testing Objectives
 Execute a program with the intent of finding errors to
o Determine whether system meets specifications
o Determine whether system meets user’s needs
 What is defect?
o A defect is any error found by testing and reviewing activities (All
errors found by internal reviewer, external reviewer and
customer).

3
The Test Process

Test Test Preparation


Test Execution
Planning

SRS study Perform


testing
Create
Test Plan
Data Analysis
(by
Test leader) Create Test Bug
Review &
Design Reporting
Approval
Test - Analyze root
Report Causes of
defects
- Bug Fixing
- Identify
- Develop test - TC Updating
actions
cases, test scripts
- Prepare test
data
Bug Tracking
(Re-test)

4
Testing Activities
Requirements
Subsystem System Analysis
Unit
Design Document
Code Test Tested
Subsystem Document
User
Subsystem Unit Manual
Code T est
Tested Integration Functional
Subsystem Test Test
Integrated
Functioning
Subsystems
System

m
Tested Subsyste

Subsystem Unit
Code T est

5 tests by developer
Cont..
Client’s
Global Understanding User
Requirements of Requirements Environment

Functioning Validated Accepted


System PerformanceSystem System
Acceptance Installation
Test Test Test

Usable
Tests by client System
Tests by developer
User’s understanding
System in
Use
Can Tests by user
6
Testing stages
 There are 4 stages of Testing:
 Unit Test
 Integration Test
 System Test
 Acceptance Test

7
Cont..

8
Unit Test
Purpose: to verify that the component/module functions properly
Check:
ointernal data structures
oLogic
oboundary conditions for input/output data
Normally: White box oriented
Doer: Development team
Metrics: Test coverage:
oStatement
oBranch
oPath
oCondition

Individual subsystem
Confirm that subsystems is correctly coded and carries out the
9
intended functionality
Integration Test
 Purpose:
 Combining the individual components to uncover errors
associated with interfacing
 Normally: Black box oriented
 Doer: independent Test team
 Groups of subsystems (collection of classes) and eventually the
entire system
 Test the interface among the subsystem

10
System Test
 Purpose: To ensure that the system does what the
requirement specifies
 Types
o Function Testing
o Performance Testing
o Installation Testing
 Normally: Black box oriented
 Doer: independent Test team
 The entire system
 Determine if the system meets the requirements
(functional and global)
11
Acceptance Test
 Customer’s way to verify that what was wanted is what is built
 Uncovers more than requirements discrepancies
 Allows the customers to determine what they really want,
whether specified in the document or not.
 Customers may decide that the problem as changed and a
different solution is needed
 Normally: Black box oriented
 Doer: Customer/independent Test team
 Evaluates the system delivered by developers
 Demonstrate that the system meets customer requirements and is
ready to use
 Implementation (Coding) and testing go hand in hand
12
Testing types
 Functional test
o Function testing
o User Interface testing
o Data and database integrity testing
 User Interface: Layout
 Performance test
o Performance profiling
o Load testing
o Stress testing
o Volume testing
 Access control & Security test

13
Testing techniques
 Static Analysis:
o Hand execution: Reading the source code
o Walk-Through (informal presentation to others)- is a form of
software peer review "in which a designer or programmer leads
members of the development team and other interested parties
through a software product, and the participants ask questions and
make comments about possible errors, violation of development
o Code Inspection (formal presentation to others) - the process of
reviewing the code in an application to check for defects.
o Automated Tools checking - is a type of software that allows you to
design testing tasks and then it can automate the execution of those
tests
 syntactic and semantic errors
 departure from coding standards
 Dynamic Analysis:
 Black-box testing (Test the input/output behavior)
 White-box testing (Test the internal logic of the subsystem or
14
object)
Cont..
 Black box testing is a software testing methodology in which the
tester analyzes the functionality of an application without a thorough
knowledge of its internal design.
 White box testing, the tester is knowledgeable of the internal design
of the application and analyzes it during testing.

15
Test Case
 Test environment
 A test case includes:
o Action (sample: click on Add button, on a link, input birth
day…)
o Input data (valid/invalid/boundary data)
o Expected result (message, …)
 Good test case:
o Structure of TC is clear and reasonable.
o Follow requirement closely.
o Cover all of cases that can occur.
o Description and test conditions is brief and easy to understand
o Procedure and expected result is a step by step process

16
17

You might also like