Module4 PPT V2 - Part1
Module4 PPT V2 - Part1
Module4 PPT V2 - Part1
MODULE-IV
Software Testing and Maintenance
Requirement
Analysis
Where are We?
Design
System engineering
Analysis modeling
Design modeling
Integration test
Validation test
System test
Manual testing will require skilled labour, long time & Automation Testing saves time, cost and
will imply high costs. manpower. Once recorded, it's easier to run an
automated test suite
Any type of application can be tested manually, Automated testing is recommended only for stable
certain testing types like ad-hoc and monkey testing systems and is mostly used for System Testing
are more suited for manual execution.
Manual testing can be become repetitive and boring. The boring part of executing same test cases time
and again, is handled by automation software in
Automation Testing.
Dept. of CSE, SOE, Presidency University 7
Black Box Testing (Functional Testing)
• Uses only the Specification document to identify test cases.
• Knowing the specified function a component has been designed
for.
• Tests conducted at the interface of the component.
Black Box
Dept. of CSE, SOE, Presidency University 8
Black Box Testing
Advantages
• Independent of how the software is implemented.
Disadvantages:
• Redundancies may exist among test cases.
Advantages:
• Provides more coverage in testing conditions and decisions.
• Reveals hidden errors during coding.
Disadvantages:
• Missed cases in the code are obviously missed during testing too.
• In-depth knowledge of the programming language is needed.
Statement1; Can be
Statement2; represented as
Statement3; one node as there 1
Statement4; is no branch.
CFG
Statement1; 1 T
Statement2; 3
1 2
if X < 10 then 2
Statement3; 3 F
else
4
CFG
Statement4; 4
Dept. of CSE, SOE, Presidency University 14
More Examples of CFG
1 T
if X > 0 then 2
Statement1; 2 1 4
else
Statement2; 3 F 3
CFG
while X < 10 { 1
Statement1; 2 1 T
2 3 4
X++; } 3
CFG
min = A[0];
1
1
I = 1;
2
2
while (I < N) { F T
if (A[I] < min) 3 3
min = A[I]; 4 F T
I = I + 1; 5
5 4
}
print min 6
6
CFG
T
3
1 1 2
F
4
CFG CFG
T
2
1 4 Two paths are needed:
[1–2–4]
F 3 [1–3–4]
CFG
min = A[0]; 1
I = 1;
2
while (I < N) { F T
if (A[I] < min)
3
min = A[I]; F T
I = I + 1;
5 4
}
print min 6
CFG
1
Cyclomatic complexity =
2
F T The number of ‘regions’ in the
3 graph;
F T OR
5 4 The number of predicates + 1.
CFG
Predicates:
Nodes with multiple
1 exit arcs.
Corresponds to
2 branch/conditional
F T
statement in
3 program.
F T In this example:
5 4 Predicates = 2
• (Node 2 and 3)
6 Cyclomatic
Complexity
CFG
=2+1
=3
Step 3 – Find Basis Path Set
Independent path:
An executable or realizable path through the graph
from the start node to the end node that has not been
traversed before.
Must move along at least one arc that has not been yet
traversed (an unvisited arc).
The objective is to cover all statements in a program by
independent paths.
The number of independent paths to discover
<= cyclomatic complexity number.
Decide the Basis Path Set:
It is the maximal set of independent paths in the flow
graph.
NOT a unique set.
Step 3 – Example
• 1-2-3-5 can be the first independent path; 1-2-4-5 is another; 1-2-3-5-2-4-5 is one
more.
• There are only these 3 independent paths. The basis path set is then having 3 paths.
• Alternatively, if we had identified 1-2-3-5-2-4-5 as the first independent path, there
would be no more independent paths.
• The number of independent paths therefore can vary according to the order we
identify them.
Step 3
Cyclomatic complexity
1 = 3.
Need at most 3
2 independent paths to
F T cover the CFG.
3 In this example:
F T
[1–2–6]
5 4 [1–2–3–5–2–6]
[ 1 – 2 – 3 – 4 – 5 – 2 – 6]
6
CFG
Step 4 – Design Test Cases
Prepare a test case for each independent path.
In this example:
Path: [ 1 – 2 – 6 ]
• Test Case: A = { 5, …}, N = 1
• Expected Output: 5
Path: [ 1 – 2 – 3 – 5 – 2 – 6 ]
• Test Case: A = { 5, 9, … }, N = 2
• Expected Output: 5
Path: [ 1 – 2 – 3 – 4 – 5 – 2 – 6]
• Test Case: A = { 8, 6, … }, N = 2
• Expected Output: 6
These tests will result a complete decision and
statement coverage of the code.
Black Box Testing
A subsystem.
boolean isValidMonth(int m)
- Min (1)
- Min+1 (2)
- Nominal (100)
- Max-1 (199)
- Max (200)
Example 1 - Searching
boolean Search(
List aList, int key)
Precondition:
-aList has at least one element
Postcondition:
- true if key is in the aList
- false if key is not in aList
Equivalence Classes for Search
Sequence with a single value:
key found.
key not found.
Sequence of multi values:
key found:
• First element in sequence.
• Last element in sequence.
• “Middle” element in sequence.
key not found.
Test Data for Search
3 [ 1, 6, 3, -4, 5 ] 1 True
4 [ 1, 6, 3, -4, 5 ] 5 True
5 [ 1, 6, 3, -4, 5 ] 3 True
• We can come up with test data for each of the four cases, based on values of
the polynomial's discriminant (b2-4ac).
Software Quality Assurance
(SQA)
Contents
1. Elements of SQA
2. Role of the SQA Group
3. SQA Goals
4. Statistical SQA
5. Six-Sigma for Software Engineering
6. Software Safety
Standards
Reviews and Audits
Testing
Error/defect collection and analysis
Change management
Education
Vendor management
Security management
Safety
Risk management
measurement
changes in
business requirements
changes in
technical requirements
changes in
user requirements other
documents
software models
Project
Plan
data
Test
code
modified
SCIs
Project database
approved
Software Formal
engineering SCIs technical SCIs
tasks reviews
stored
SCIs
extracted
SCM
SCIs
controls
BASELINES:
System Specification
Software Requirements
Design Specification
Source Code
Test Plans/Procedures/Data
Operational System
u se -case s
b u sin e ss ru le s an aly sis m o d e l so u rce co d e
b u sin e ss fu n ct io n s sce n ario -b ase d d iag ram s o b je ct co d e
o rg an izat io n st ru ct u re flo w-o rie n t e d d iag ram s sy st e m b u ild in st ru ct io n s
in fo rm at io n arch it e ct u re class-b ase d d iag ram s
b e h av io ral d iag ram s Cons t ruc t ion
d e sig n m o d e l Cont e nt
arch it e ct u ral d iag ram s
Bus ine s s in t e rface d iag ram s
Cont e nt co m p o n e n t -le v e l d iag ram s
t e ch n ical m e t rics t e st case s
t e st scrip t s
t e st re su lt s
q u alit y m e t rics
Mode l
Cont e nt
V&V
Cont e nt
Proje c t
Ma na ge me nt
p ro je ct e st im at e s Cont e nt
p ro je ct sch e d u le
SCM re q u ire m e n t s
Pro je ct Plan
ch an g e re q u e st s Doc ume nt s SCM/ SQA Plan
ch an g e re p o rt s
Sy st e m Sp e c
SQA re q u ire m e n t s
Re q u ire m e n t s Sp e c
p ro je ct re p o rt s/ au d it re p o rt s
De sig n Do cu m e n t
p ro je ct m e t rics
Te st Plan an d Pro ce d u re
Su p p o rt d o cu m e n t s
Use r m an u al
Software
Vm.n
reporting
configuration auditing
version control
change control
identification
developer evaluates
check-out SCIs
change
change control
control process—III
process—III
Version Example
Dept. of CSE, SOE, Presidency University
3.3 Versioning Example
1. GIT
2. Team Foundation Server (Microsoft)
3. Rational Clear Case (IBM)
4. Visual SourceSafe (Microsoft)
Change SQA
Requests Plan
SCIs
SCM Audit
Dept. of CSE, SOE, Presidency University
3.5 Reporting
• The parts of the old/existing system that are appropriate for reuse are identified and
understood.
• These parts are then go through modification and enhancement, which are done on
the basis of the specified new requirements.
• The final step of this model is the integration of modified parts into the new system.
Boehm’s Model
• Boehm’s Model performs
maintenance process based on the
economic models and principles.
• It represents the maintenance
process in a closed loop cycle,
wherein changes are suggested and
approved first and then are
executed.
Taute’s Maintenance Model
Named after the person who proposed the
model, Taute’s model is a typical maintenance
model that consists of eight phases in cycle
fashion.
The process of maintenance begins by
requesting the change and ends with its
operation.
The phases of Taute’s Maintenance Model
are:
The phases of Taute’s Maintenance Model are:
97
Process Maturity Framework
Goal is the improvement of the software engineering process
– Success should not be based on incidental individual achievements
– Success should be based on repeatable and proven successful work
methods
Immature Mature
Software Software
Organization Organization
99
Fundamental concepts for
Process Maturity
Software Process Capability
– How good it can predict the expected outcome of a next
software project
Software Process Performance
– Actual results of a software project
Software Process Maturity
– The level in which a software process is explicitly defined,
managed, measured and controlled in order to achieve results
Software Process Institutionalization
– The level in which the software process is institutionalized with
respect to methods, standards and organizational structure
100
Levels of software maturity
Maturity level:
– A well defined level on the way to achieve an adult, a
mature software process
– A foundation for realizing continuous improvements
– Every level contains a group of process goals that, when
stable, form an important part of the software process
– Every level leads to the improvement of the process
capability of the organization
101
The staged CMMI model
Level 5
Optimizing
Level 4
Quantitatively
managed
Level 3
Defined
Level 2
Managed
Level 1
Initial
102
Initial
The (1)process can be described as ad-hoc, or even
software
chaotic
There are practically no processes defined
Success depends on individual input and achievements
The software process is not predictable regarding results
Schedules, budget, functionality and product quality is not
predictable
Works disastrous in crises situations
Can be successful in highly innovative environment
(e.g. start of the web-design world)
103
Managed
The (2)management procedures are used
basic project
Costs, schedules en functionality are ‘tracked’
Planning and managing of new projects are based on experience
with comparable projects
Needed process discipline is enforced such that earlier success can
be repeated with building an comparable application
Software requirements and work products are ‘baselined’
Disciplined environment in which planning and tracking are stable
and thus previous successes can be repeated
104
Definedfor(3)
Processes management and software engineering are
documented, standardized and integrated in a standard software
development process
All projects use an approved, adapted version of the standard
software process for the development and maintenance of software
Processes are used to let software managers and engineers be more
effective
There is a group responsible for the software process
There is training in the software process
The software process is stable and well defined and is able to
operate more effectively
105
Quantitatively
Detailed metrics of themanaged (4) and quality of products
software processes
are gathered
Quantitative goals are set for the software process and the product
quality
Use is made of a software process database in which the metrics
are gathered and analyzed
Projects have a control over the software process and product
quality such that the can work in defined limits
Risks of development in new technical environments are
recognized and managed
Software process is predictable and trends can be predicted
106
Optimizing
Continuously (5) process improvements are realized by
software
quantitatively feedback of the process and by trying out of
innovative ideas and technologies
The whole organization is focused on continuous improvement
Data regarding performance of the processes are used for cost-
benefit analyses
Innovations that make use of the best software engineering
practices are identified and spread over the whole organization
Software project teams analyze errors in order to find out how to
improve
‘Lessons learned’ are shared with other projects (team rooms,
Communities of Practice)
107
Operational use of CMM
How do you determine in practice the maturity of an organization?
Maturity
Indicate
Level
Contain
Process
Capability Key Process
Achieve Areas
Organized by
Goals
Common
Address Features Contain
Implementation or Key
Institutionalization
Describe
Practices
Infrastructure or
Activities
108
Key Process Areas Optimizing (5)
-Process change management
-Technology change management
-Defect prevention
Quantitatively
Managed (4) -Software quality management
-Quantitative process management
-Peer reviews
-Intergroup coordination
Defined (3) -Software product engineering
-Integrated software management
-Training program
-Organization process definition
Managed (2) -Organization process focus