University Institute of Engineering

DEPARTMENT OF COMPUTER SCIENCE

& ENGINEERING
Bachelor of Engineering (Computer Science & Engineering)
Subject Name: Software Engineering
Subject Code: 22CST-313
Prepared by:
Er. Puneet Kaur(E6913)

Software Testing DISCOVER . LEARN . EMPOWER

1
 Chapter-7
Software Testing
• Software Testing Fundamentals

• Strategic Approach to Software Testing

2
Software Testing Fundamentals
• Software testing can be stated as the process of verifying and
validating that a software or application is bug free, meets the
technical requirements as guided by it’s design and development and
meets the user requirements effectively and efficiently with handling
all the exceptional and boundary cases.

3
Software Testing Fundamentals
• The process of software testing aims not only at finding faults in the
existing software but also at finding measures to improve the software
in terms of efficiency, accuracy and usability.
• It mainly aims at measuring specification, functionality and
performance of a software program or application.

4
Software Testing Fundamentals
• Software testing can be divided into two steps:
1. Verification: it refers to the set of tasks that ensure that software
correctly implements a specific function.

2. Validation: it refers to a different set of tasks that ensure that the

software that has been built is traceable to customer requirements.
Verification: “Are we building the product right?”
Validation: “Are we building the right product?”

5
Software Testing Fundamentals
• Software Testing can be broadly classified into two types:
• Manual Testing: Manual testing includes testing a software manually, i.e.,
without using any automated tool or any script.
• In this type, the tester takes over the role of an end-user and tests the
software to identify any unexpected behavior or bug.
• There are different stages for manual testing such as unit testing,
integration testing, system testing, and user acceptance testing.
• Testers use test plans, test cases, or test scenarios to test a software to
ensure the completeness of testing.
• Manual testing also includes exploratory testing, as testers explore the
software to identify errors in it.

6
Software Testing Fundamentals
• Automation Testing: Automation testing, which is also known as Test
Automation, is when the tester writes scripts and uses another
software to test the product.
• This process involves automation of a manual process.
• Automation Testing is used to re-run the test scenarios that were
performed manually, quickly, and repeatedly.
• Apart from regression testing, automation testing is also used to test
the application from load, performance, and stress point of view.
• It increases the test coverage, improves accuracy, and saves time and
money in comparison to manual testing.

7
Software Testing Fundamentals
• Software testing is a process used to identify the correctness,
completeness and quality of developed computer software.
• It is the process of executing a program / application under positive
and negative conditions by manual or automated means.
• It checks for the :-
• Specification
• Functionality
• Performance Software Testing

8
Software Testing Fundamentals
• Software Testing is important as it may cause mission failure, impact
on operational performance and reliability if not done properly.
• Effective software testing delivers quality software products satisfying
user’s requirements, needs and expectations.

9
Software Testing Fundamentals
• Bug, Fault & Failure Error
• An error is a human action that produces the incorrect result that
results in a fault.
• Bug : The presence of error at the time of execution of the software.
• Fault : State of software caused by an error.
• Failure : Deviation of the software from its expected result. It is an
event. A person makes an Error That creates a fault in software That
can cause a failure in operation

10
Software Testing Fundamentals
• Software Tester is the one who performs testing and find bugs, if they
exist in the tested application.
• Program Manager-
• The planning and execution of the project to ensure the success of a
project minimizing risk throughout the lifetime of the project.
• Responsible for writing the product specification, managing the
schedule and making the critical decisions and trade-offs.

11
Software Testing Fundamentals
• QA Lead-
• Coach and mentor other team members to help improve QA
effectiveness
• Work with other department representatives to collaborate on joint
projects and initiatives
• Implement industry best practices related to testing automation and
to streamline the QA Department.

12
Software Testing Fundamentals
• Test Analyst Lead
• Responsible for planning, developing and executing automated test
systems, manual test plans and regressions test plans.
• Identifying the Target Test Items to be evaluated by the test effort
• Defining the appropriate tests required and any associated Test Data
• Gathering and managing the Test Data
• Evaluating the outcome of each test cycle

13
Software Testing Fundamentals
• Test Engineer
• Writing and executing test cases and Reporting defects
• Test engineers are also responsible for determining the best way a
test can be performed in order to achieve 100% test coverage of all
components

14
Software Testing Strategies

• Software testing or Quality Assurance strategies describe how to

mitigate product risks of stakeholders at the test level, which kinds of
testing are to be done and which entry and exit criteria will apply.

• They’re made based on development design documents.

15
FACTORS TO CONSIDER IN CHOOSING
SOFTWARE TESTING STRATEGIES
• RISKS. Risk management is paramount during testing, thus consider the
risks and the risk level.
• For an app that is well-established that’s slowly evolving, regression is a
critical risk.
• That is why regression-averse strategies make a lot of sense.
• For a new app, a risk analysis could reveal various risks if choosing a risk-
based analytical strategy.
• OBJECTIVES. Testing should satisfy the requirements and needs of
stakeholders to succeed. If the objective is to look for as many defects as
possible with less up-front time and effort invested, a dynamic strategy
makes sense.

16
FACTORS TO CONSIDER IN CHOOSING
SOFTWARE TESTING STRATEGIES
• SKILLS. Take into consideration which skills the testers possess and lack,
since strategies should not only be chosen but executed as well.
• A standard compliant strategy is a smart option when lacking skills and
time in the team to create an approach.
• PRODUCT. Some products such as contract development software and
weapons systems tend to have requirements that are well-specified.
• This could lead to synergy with an analytical strategy that is requirements-
based.
• BUSINESS. Business considerations and strategy are often important.
• If using a legacy system as a model for a new one, one could use a model-
based strategy.

17
FACTORS TO CONSIDER IN CHOOSING
SOFTWARE TESTING STRATEGIES
• REGULATIONS. At some instances, one may not only have to satisfy
stakeholders, but regulators as well.
• In this case, one may require a methodical strategy which satisfies
these regulators.

18
STRATEGY IN SOFTWARE TESTING
• The main objective of software testing is to design the tests in such a
way that it systematically finds different types of errors without taking
much time and effort so that less time is required for the
development of the software.

19
STRATEGY IN SOFTWARE TESTING
• The overall strategy for testing software includes:

20
STRATEGY IN SOFTWARE TESTING
• Before testing starts, it’s necessary to identify and specify the
requirements of the product in a quantifiable manner: Different
characteristics quality of the software is there such as maintainability that
means the ability to update and modify, the probability that means to find
and estimate any risk, and usability that means how it can easily be used by
the customers or end-users. All these characteristic qualities should be
specified in a particular order to obtain clear test results without any error.

• Specifying the objectives of testing in a clear and detailed manner.

Several objectives of testing are there such as effectiveness that means
how effectively the software can achieve the target, any failure that means
inability to fulfill the requirements and perform functions, and the cost of
defects or errors that mean the cost required to fix the error. All these
objectives should be clearly mentioned in the test plan.
21
STRATEGY IN SOFTWARE TESTING
• For the software, identifying the user’s category and developing a
profile for each user.
Use cases describe the interactions and communication among
different classes of users and the system to achieve the target. So as
to identify the actual requirement of the users and then testing the
actual use of the product.
• Developing a test plan to give value and focus on rapid-cycle testing.
Rapid Cycle Testing is a type of test that improves quality by
identifying and measuring the any changes that need to be required
for improving the process of software. Therefore, a test plan is an
important and effective document that helps the tester to perform
rapid cycle testing.
22
STRATEGY IN SOFTWARE TESTING
• Robust software is developed that is designed to test itself.
The software should be capable of detecting or identifying different classes
of errors. Moreover, software design should allow automated and
regression testing which tests the software to find out if there is any
adverse or side effect on the features of software due to any change in
code or program.
• Before testing, using effective formal reviews as a filter.
Formal technical reviews is technique to identify the errors that are not
discovered yet. The effective technical reviews conducted before testing
reduces a significant amount of testing efforts and time duration required
for testing software so that the overall development time of software is
reduced.

23
STRATEGY IN SOFTWARE TESTING
• Conduct formal technical reviews to evaluate the nature, quality or ability of
the test strategy and test cases.

The formal technical review helps in detecting any unfilled gap in the testing
approach. Hence, it is necessary to evaluate the ability and quality of the test
strategy and test cases by technical reviewers to improve the quality of software.
• For the testing process, developing a approach for the continuous
development.

As a part of a statistical process control approach, a test strategy that is already

measured should be used for software testing to measure and control the quality
during the development of software.
24
 References

• [Link]
• [Link]
and-approaches
• [Link]
• [Link]
ing_overview.htm
• [Link]

25
THANK YOU

26
 University Institute of Engineering
DEPARTMENT OF COMPUTER SCIENCE
& ENGINEERING
Bachelor of Engineering (Computer Science & Engineering)
Subject Name: Software Engineering
Subject Code: 22CST-313
Prepared by:
Er. Puneet Kaur(E6913)

Software Testing DISCOVER . LEARN . EMPOWER

27
 Chapter-7
Software Testing
• Validation Testing

• System Testing

28
Validation Testing

• The process of evaluating software during the development process

or at the end of the development process to determine whether it
satisfies specified business requirements.
• Validation Testing ensures that the product actually meets the client's
needs. It can also be defined as to demonstrate that the product
fulfills its intended use when deployed on appropriate environment.
• It answers to the question, Are we building the right product?

29
Validation Testing

• Validation Testing, carried out by QA professionals, is to determine if

the system complies with the requirements and performs functions
for which it is intended and meets the organization’s goals and user
needs.
• This kind of testing is very important, as well as verification testing.
• Validation is done at the end of the development process and takes
place after verification is completed.

30
Validation Testing

• Thus, to ensure customer satisfaction, developers apply validation

testing.
• Its goal is to validate and be confident about the product or system
and that it fulfils the requirements given by the customer.
• The acceptance of the software from the end customer is also its
part.

31
Validation Testing

• When software is tested, the motive is to check the quality regarding

the found defects and bugs.
• When defects and bugs are detected, developers fix them. After that,
the software is checked again to make sure no bugs are left.
• In that way, the software product’s quality scales up.

32
Validation Testing

• The aim of software testing is to measure the quality of software in

terms of a number of defects found in it, the number of tests run and
the system covered by the tests.
• When bugs or defects are found with the help of testing, the bugs are
logged and the development team fixes them.
• Once the bugs are fixed, testing is carried out again to ensure that
they are indeed fixed and no new defects have been introduced in the
software.
• With the entire cycle, the quality of the software increases.

33
Validation Testing - Workflow
• Validation testing can be best demonstrated using V-Model. The
Software/product under test is evaluated during this type of testing.
•

34
Activities

• Unit Testing
• Integration Testing
• System Testing
• User Acceptance Testing

35
Validation Testing Variations:
• Component/Unit Testing – The aim of the unit testing is to look for bugs in the software
component. At the same time, it also verifies the work of modules and objects which can
be tested separately.
• Integration testing- This is an important part of the software validation model, where
the interaction between the different interfaces of the components is tested. Along with
the interaction between the different parts of the system, the interaction of the system
with the computer operating system, file system, hardware, and any other software
system it might interact with, is also tested.
• System testing- System testing is carried out when the entire software system is ready.
The main concern of system testing is to verify the system against the specified
requirements. While carrying out the tests, the tester is not concerned with the internals
of the system but checks if the system behaves as per expectations.
• Acceptance testing- During this testing, a tester literally has to think like the client and
test the software with respect to user needs, requirements, business processes and
determine whether the software can be handed over to the client or not.
36
Validation Testing Variations:
• Alpha testing- This type of testing is done at the developers’ site by
potential customers/users. Any problems encountered during this
testing are rectified by the developers then and there.
• Beta testing- Once the software passes the alpha testing stage, beta
testing is done at the user’s end.
• Regression testing- This testing is done after the desired changes or
modifications are made to the existing code. The code, when put to
test, may have certain errors that can be resolved by making essential
changes. The software is again put to test after these changes are
made to check whether the new code fulfils customer requirements
or not.

37
Stages of Validation testing Process
• Validation Planning – To plan all the activities that need to be included
while testing.
• Define Requirements – To set goals and define the requirements for
testing.
• Selecting a Team – To select a skilled and knowledgeable development
team (the third party included).
• Developing Documents – To develop a user specification document
describing the operating conditions.
• Estimation/Evaluation – To evaluate the software as per the specifications
and submit a validation report.
• Fixing bugs or Incorporating Changes – To change the software so as to
remove any errors found during evaluation.

38
System Testing
• System Testing is a type of software testing that is performed on a
complete integrated system to evaluate the compliance of the system
with the corresponding requirements.
• In system testing, integration testing passed components are taken as
input.
• The goal of integration testing is to detect any irregularity between
the units that are integrated together.
• System testing detects defects within both the integrated units and
the whole system. The result of system testing is the observed
behavior of a component or a system when it is tested.
39
System Testing
• System Testing is carried out on the whole system in the context of either
system requirement specifications or functional requirement specifications
or in the context of both.
• System testing tests the design and behavior of the system and also the
expectations of the customer. It is performed to test the system beyond the
bounds mentioned in the software requirements specification (SRS).
• System Testing is basically performed by a testing team that is independent
of the development team that helps to test the quality of the system
impartial. It has both functional and non-functional testing.
• System Testing is a black-box testing.

40
System Testing
• System Testing is performed after the integration testing and before
the acceptance testing.
•

41
System Testing Process

42
System Testing Process
• Test Environment Setup:
Create testing environment for the better quality testing.
• Create Test Case:
Generate test case for the testing process.
• Create Test Data:
Generate the data that is to be tested.
• Execute Test Case:
After the generation of the test case and the test data, test cases are
executed.

43
System Testing Process
• Defect Reporting:
Defects in the system are detected.
• Regression Testing:
It is carried out to test the side effects of the testing process.
• Log Defects:
Defects are fixed in this step.
• Retest:
If the test is not successful then again test is performed.

44
Types of System Testing

• Usability Testing- mainly focuses on the user's ease to use the application,
flexibility in handling controls and ability of the system to meet its objectives
• Load Testing is necessary to know that a software solution will perform under
real-life loads.
• Regression Testing involves testing done to make sure none of the changes
made over the course of the development process have caused new bugs. It
also makes sure no old bugs appear from the addition of new software modules
over time.
• Recovery testing is done to demonstrate a software solution is reliable,
trustworthy and can successfully recoup from possible crashes.

45
Types of System Testing

• Migration testing- is done to ensure that the software can be moved from
older system infrastructures to current system infrastructures without any
issues.
•
Functional Testing - Also known as functional completeness
testing, Functional Testing involves trying to think of any possible missing
functions. Testers might make a list of additional functionalities that a
product could have to improve it during functional testing.
•
Hardware/Software Testing - IBM refers to Hardware/Software testing as
"HW/SW Testing". This is when the tester focuses his/her attention on the
interactions between the hardware and software during system testing.

46
 References

• [Link]
[Link]#:~:text=SYSTEM%20TESTING%20is%20a%20level,a%20la
rger%20computer%2Dbased%20system.
• [Link]
• [Link]
on_testing.htm#:~:text=Software%20Testing%20%2D%20Validation%
20Testing,actually%20meets%20the%20client's%20needs.
• [Link]

47
THANK YOU

48
 University Institute of Engineering
DEPARTMENT OF COMPUTER SCIENCE
& ENGINEERING
Bachelor of Engineering (Computer Science & Engineering)
Subject Name: Software Engineering
Subject Code: 22CST-313
Prepared by:
Er. Puneet Kaur(E6913)

Software Testing DISCOVER . LEARN . EMPOWER

49
 Chapter-7
Software Testing
• Black Box Testing

50
Black Box Testing
• Black Box Testing is a software testing method in which the
functionalities of software applications are tested without having
knowledge of internal code structure, implementation details and
internal paths.
• Black Box Testing mainly focuses on input and output of software
applications and it is entirely based on software requirements and
specifications.
• It is also known as Behavioral Testing.

51
Black Box Testing

• The above Black-Box can be any software system you want to test.
• For Example, an operating system like Windows, a website like
Google, a database like Oracle or even your own custom application.
• Under Black Box Testing, you can test these applications by just
focusing on the inputs and outputs without knowing their internal
code implementation.
52
How to do Black Box Testing

• Initially, the requirements and specifications of the system are examined.

• Tester chooses valid inputs (positive test scenario) to check whether SUT
processes them correctly. Also, some invalid inputs (negative test scenario)
are chosen to verify that the SUT is able to detect them.
• Tester determines expected outputs for all those inputs.
• Software tester constructs test cases with the selected inputs.
• The test cases are executed.
• Software tester compares the actual outputs with the expected outputs.
• Defects if any are fixed and re-tested.

53
Types of Black Box Testing

• There are many types of Black Box Testing but the following are the
prominent ones -
• Functional testing - This black box testing type is related to the
functional requirements of a system; it is done by software testers.
• Non-functional testing - This type of black box testing is not related
to testing of specific functionality, but non-functional requirements
such as performance, scalability, usability.
• Regression testing - Regression Testing is done after code fixes,
upgrades or any other system maintenance to check the new code
has not affected the existing code.
54
Advantages

• Tests are done from a user’s point of view and will help in exposing
discrepancies in the specifications.
• Tester need not know programming languages or how the software
has been implemented.
• Tests can be conducted by a body independent from the developers,
allowing for an objective perspective and the avoidance of developer-
bias.
• Test cases can be designed as soon as the specifications are complete.

55
Disadvantages

• Only a small number of possible inputs can be tested and many

program paths will be left untested.
• Without clear specifications, which is the situation in many projects,
test cases will be difficult to design.
• Tests can be redundant if the software designer/developer has
already run a test case.

56
Testing Techniques
• Black box testing can be done in following ways:
• 1. Syntax Driven Testing – This type of testing is applied to systems
that can be syntactically represented by some language. For example-
compilers, language that can be represented by context free
grammar. In this, the test cases are generated so that each grammar
rule is used at least once.

57
Testing Techniques
• 2. Equivalence partitioning – It is often seen that many type of inputs
work similarly so instead of giving all of them separately we can group
them together and test only one input of each group.
• The idea is to partition the input domain of the system into a number
of equivalence classes such that each member of class works in a
similar way, i.e., if a test case in one class results in some error, other
members of class would also result into same error.

58
Testing Techniques
• The technique involves two steps:
• Identification of equivalence class – Partition any input domain into
minimum two sets: valid values and invalid values. For example, if
the valid range is 0 to 100 then select one valid input like 49 and one
invalid like 104.
• Generating test cases –(i) To each valid and invalid class of input
assign unique identification number.
(ii) Write test case covering all valid and invalid test case considering
that no two invalid inputs mask each other.

59
Testing Techniques
• To calculate the square root of a number, the equivalence classes will
be:
(a) Valid inputs:
• Whole number which is a perfect square- output will be an integer.
• Whole number which is not a perfect square- output will be decimal
number.
• Positive decimals
• (b) Invalid inputs:
• Negative numbers(integer or decimal).
• Characters other that numbers like “a”,”!”,”;”,etc.
60
Testing Techniques
3. Boundary value analysis – Boundaries are very good places for
errors to occur. Hence if test cases are designed for boundary values of
input domain then the efficiency of testing improves and probability of
finding errors also increase. For example – If valid range is 10 to 100
then test for 10,100 also apart from valid and invalid inputs.

61
Testing Techniques
4. Cause effect Graphing – This technique establishes relationship
between logical input called causes with corresponding actions called
effect. The causes and effects are represented using Boolean graphs.
The following steps are followed:
• Identify inputs (causes) and outputs (effect).
• Develop cause effect graph.
• Transform the graph into decision table.
• Convert decision table rules to test cases.

62
63
Testing Techniques
• 5. Requirement based testing – It includes validating the requirements
given in SRS of software system.
• 6. Compatibility testing – The test case result not only depend on product
but also infrastructure for delivering functionality. When the infrastructure
parameters are changed it is still expected to work properly. Some
parameters that generally affect compatibility of software are:
• Processor (Pentium 3,Pentium 4) and number of processors.
• Architecture and characteristic of machine (32 bit or 64 bit).
• Back-end components such as database servers.
• Operating System (Windows, Linux, etc).
64
 References

• [Link]
• [Link]
• [Link]
testing/
• [Link]
testing-vs-white-box-testing/

65
THANK YOU

66
 University Institute of Engineering
DEPARTMENT OF COMPUTER SCIENCE
& ENGINEERING
Bachelor of Engineering (Computer Science & Engineering)
Subject Name: Software Engineering
Subject Code: 22CST-313
Prepared by:
Er. Puneet Kaur(E6913)

Software Testing DISCOVER . LEARN . EMPOWER

67
 Chapter-7
Software Testing
• White Box Testing

68
White Box Testing

• White Box Testing is software testing technique in which internal

structure, design and coding of software are tested to verify flow of
input-output and to improve design, usability and security.
• In white box testing, code is visible to testers so it is also called Clear
box testing, Open box testing, Transparent box testing, Code-based
testing and Glass box testing.

69
White Box Testing

• It is one of two parts of the Box Testing approach to software testing.

• Its counterpart, Black box testing, involves testing from an external or
end-user type perspective.
• On the other hand, White box testing is based on the inner workings
of an application and revolves around internal testing.

70
White Box Testing

• White box testing techniques analyze the internal structures the used
data structures, internal design, code structure and the working of
the software rather than just the functionality as in black box testing.
• It is also called glass box testing or clear box testing or structural
testing.

71
What do you verify in White Box Testing?

• White box testing involves the testing of the software code for the
following:
• Internal security holes
• Broken or poorly structured paths in the coding processes
• The flow of specific inputs through the code
• Expected output
• The functionality of conditional loops
• Testing of each statement, object, and function on an individual basis

72
Working process of white box testing:
• Input: Requirements, Functional specifications, design documents,
source code.
• Processing: Performing risk analysis for guiding through the entire
process.
• Proper test planning: Designing test cases so as to cover entire code.
Execute rinse-repeat until error-free software is reached. Also, the
results are communicated.
• Output: Preparing final report of the entire testing process

73
Testing techniques
• Statement coverage: In this technique, the aim is to traverse all
statement at least once. Hence, each line of code is tested.
• In case of a flowchart, every node must be traversed at least once.
Since all lines of code are covered, helps in pointing out faulty code.

74
Testing techniques

75
Testing techniques
• Branch Coverage: In this technique, test cases are designed so that
each branch from all decision points are traversed at least once.
• In a flowchart, all edges must be traversed at least once.

76
77
Testing techniques
• Condition Coverage: In this technique, all individual conditions must
be covered as shown in the following example:

• READ X, Y
• IF(X == 0 || Y == 0)
• PRINT ‘0’
• In this example, there are 2 conditions: X == 0 and Y == 0. Now, test
these conditions get TRUE and FALSE as their values. One possible
example would be:
• #TC1 – X = 0, Y = 55
• #TC2 – X = 5, Y = 0

78
Testing techniques
• Multiple Condition Coverage: In this technique, all the possible
combinations of the possible outcomes of conditions are tested at least
once. Let’s consider the following example:
• READ X, Y
• IF(X == 0 || Y == 0)
• PRINT ‘0’
• #TC1: X = 0, Y = 0
• #TC2: X = 0, Y = 5
• #TC3: X = 55, Y = 0
• #TC4: X = 55, Y = 5
• Hence, four test cases required for two individual conditions.
Similarly, if there are n conditions then 2n test cases would be required.

79
Testing techniques
• Basis Path Testing: In this technique, control flow graphs are made
from code or flowchart and then Cyclomatic complexity is calculated
which defines the number of independent paths so that the minimal
number of test cases can be designed for each independent path.
Steps : Make the corresponding control flow graph
• Calculate the cyclomatic complexity
• Find the independent paths
• Design test cases corresponding to each independent path

80
Testing techniques
• Flow graph notation: It is a directed graph consisting of nodes and
edges. Each node represents a sequence of statements, or a decision
point. A predicate node is the one that represents a decision point
that contains a condition after which the graph splits. Regions are
bounded by nodes and edges.

81
Testing techniques
• Cyclomatic Complexity: It is a measure of the logical complexity of
the software and is used to define the number of independent paths.
For a graph G, V(G) is its cyclomatic complexity.
Calculating V(G):
• V(G) = P + 1, where P is the number of predicate nodes in the flow
graph
• V(G) = E – N + 2, where E is the number of edges and N is the total
number of nodes
• V(G) = Number of non-overlapping regions in the graph

82
83
Example
•
V(G) = 4 (Using any of the above formulae)
No of independent paths = 4
• #P1: 1 – 2 – 4 – 7 – 8
• #P2: 1 – 2 – 3 – 5 – 7 – 8
• #P3: 1 – 2 – 3 – 6 – 7 – 8
• #P4: 1 – 2 – 4 – 7 – 1 – . . . – 7 – 8

84
Testing techniques
• Loop Testing: Loops are widely used and these are fundamental to
many algorithms hence, their testing is very important. Errors often
occur at the beginnings and ends of loops.
• Simple loops: For simple loops of size n, test cases are designed that:
• Skip the loop entirely
• Only one pass through the loop
• 2 passes
• m passes, where m < n
• n-1 ans n+1 passes

85
Testing techniques
• Nested loops: For nested loops, all the loops are set to their minimum
count and we start from the innermost loop. Simple loop tests are
conducted for the innermost loop and this is worked outwards till all
the loops have been tested.
• Concatenated loops: Independent loops, one after another. Simple
loop tests are applied for each.
If they’re not independent, treat them like nesting.

86
Advantages:
• White box testing is very thorough as the entire code and structures
are tested.
• It results in the optimization of code removing error and helps in
removing extra lines of code.
• It can start at an earlier stage as it doesn’t require any interface as in
case of black box testing.
• Easy to automate.

87
Disadvantages:
• Main disadvantage is that it is very expensive.
• Redesign of code and rewriting code needs test cases to be written
again.
• Testers are required to have in-depth knowledge of the code and
programming language as opposed to black box testing.
• Missing functionalities cannot be detected as the code that exists is
tested.
• Very complex and at times not realistic.

88
89
 References

• [Link]
testing/
• [Link]
box_testing.htm
• [Link]

90
THANK YOU

91
 University Institute of Engineering
DEPARTMENT OF COMPUTER SCIENCE
& ENGINEERING
Bachelor of Engineering (Computer Science & Engineering)
Subject Name: Software Engineering
Subject Code: 22CST-313
Prepared by:
Er. Puneet Kaur(E6913)

Quality Management DISCOVER . LEARN . EMPOWER

92
 Chapter-8
Quality Management
• SEICMM

93
Capability maturity model (CMM)

• CMM was developed by the Software Engineering Institute (SEI) at

Carnegie Mellon University in 1987.

• It is not a software process model. It is a framework which is used to

analyze the approach and techniques followed by any organization to
develop software products.
• It also provides guidelines to further enhance the maturity of the
process used to develop those software products.

94
Capability maturity model (CMM)

• It is based on profound feedback and development practices adopted

by the most successful organizations worldwide.

• This model describes a strategy for software process improvement

that should be followed by moving through 5 different levels.

• Each level of maturity shows a process capability level. All the levels
except level-1 are further described by Key Process Areas (KPA’s).

95
Key Process Areas
• Each of these KPA’s defines the basic requirements that should be
met by a software process in order to satisfy the KPA and achieve that
level of maturity.

• Conceptually, key process areas form the basis for management

control of the software project and establish a context in which
technical methods are applied, work products like models,
documents, data, reports, etc. are produced, milestones are
established, quality is ensured and change is properly managed.

96
Levels of CMM
• The 5 levels of CMM are as follows:
• Level-1: Initial –
• No KPA’s defined.

• Processes followed are adhoc and immature and are not well defined.
• Unstable environment for software development.
• No basis for predicting product quality, time for completion, etc.

97
Levels of CMM
• Level-2: Repeatable –

• Focuses on establishing basic project management policies.

• Experience with earlier projects is used for managing new similar natured projects.
• Project Planning- It includes defining resources required, goals, constraints, etc. for the project. It
presents a detailed plan to be followed systematically for successful completion of a good quality
software.
• Configuration Management- The focus is on maintaining the performance of the software
product, including all its components, for the entire lifecycle.
• Requirements Management- It includes the management of customer reviews and feedback
which result in some changes in the requirement set. It also consists of accommodation of those
modified requirements.
• Subcontract Management- It focuses on the effective management of qualified software
contractors i.e. it manages the parts of the software which are developed by third parties.
• Software Quality Assurance- It guarantees a good quality software product by following certain
rules and quality standard guidelines while development.
98
Levels of CMM
• Level-3: Defined –

• At this level, documentation of the standard guidelines and procedures takes place.
• It is a well defined integrated set of project specific software engineering and management
processes.
• Peer Reviews- In this method, defects are removed by using a number of review methods like
walkthroughs, inspections, buddy checks, etc.
• Intergroup Coordination- It consists of planned interactions between different development
teams to ensure efficient and proper fulfillment of customer needs.
• Organization Process Definition- It’s key focus is on the development and maintenance of the
standard development processes.
• Organization Process Focus- It includes activities and practices that should be followed to improve
the process capabilities of an organization.
• Training Programs- It focuses on the enhancement of knowledge and skills of the team members
including the developers and ensuring an increase in work efficiency.
99
Levels of CMM
• Level-4: Managed –

• At this stage, quantitative quality goals are set for the organization for
software products as well as software processes.
• The measurements made help the organization to predict the product and
process quality within some limits defined quantitatively.
• Software Quality Management- It includes the establishment of plans and
strategies to develop a quantitative analysis and understanding of the
product’s quality.
• Quantitative Management- It focuses on controlling the project
performance in a quantitative manner.

100
Levels of CMM
• Level-5: Optimizing –

• This is the highest level of process maturity in CMM and focuses on continuous
process improvement in the organization using quantitative feedback.
• Use of new tools, techniques and evaluation of software processes is done to
prevent recurrence of known defects.
• Process Change Management- Its focus is on the continuous improvement of
organization’s software processes to improve productivity, quality and cycle time
for the software product.
• Technology Change Management- It consists of identification and use of new
technologies to improve product quality and decrease the product development
time.
• Defect Prevention- It focuses on identification of causes of defects and to prevent
them from recurring in future projects by improving project defined process.
101
102
 References

• [Link]
maturity-model-cmm/
• [Link]
capability-maturity-model
• [Link]
ty_maturity_model.htm

103
THANK YOU

104
 University Institute of Engineering
DEPARTMENT OF COMPUTER SCIENCE
& ENGINEERING
Bachelor of Engineering (Computer Science & Engineering)
Subject Name: Software Engineering
Subject Code: 22CST-313
Prepared by:
Er. Puneet Kaur(E6913)

Quality Management DISCOVER . LEARN . EMPOWER

105
 Chapter-8
Quality Management
• Software Quality

• Software Reliability

106
Software Quality

• Software quality product is defined in term of its fitness of purpose.

• That is, a quality product does precisely what the users want it to do.
• For software products, the fitness of use is generally explained in
terms of satisfaction of the requirements laid down in the SRS
document.
• Although "fitness of purpose" is a satisfactory interpretation of
quality for many devices such as a car, a table fan, a grinding machine,
[Link] software products, "fitness of purpose" is not a wholly
satisfactory definition of quality.

107
Software Quality

• Example: Consider a functionally correct software product. That is, it

performs all tasks as specified in the SRS document.

• But, has an almost unusable user interface. Even though it may be

functionally right, we cannot consider it to be a quality product.

108
Software Quality

• The modern view of a quality associated with a software product

several quality methods such as the following:
• Portability: A software device is said to be portable, if it can be freely
made to work in various operating system environments, in multiple
machines, with other software products, etc.
• Usability: A software product has better usability if various categories
of users can easily invoke the functions of the product.
• Reusability: A software product has excellent reusability if different
modules of the product can quickly be reused to develop new
products.
109
Software Quality

• Correctness: A software product is correct if various requirements as

specified in the SRS document have been correctly implemented.

• Maintainability: A software product is maintainable if bugs can be

easily corrected as and when they show up, new tasks can be easily
added to the product, and the functionalities of the product can be
easily modified, etc.

110
Software Quality Management System

• A quality management system is the principal methods used by

organizations to provide that the products they develop have the
desired quality.
• A quality system subsists of the following:
• Managerial Structure and Individual Responsibilities: A quality
system is the responsibility of the organization as a whole. However,
every organization has a sever quality department to perform various
quality system activities. The quality system of an arrangement should
have the support of the top management. Without help for the
quality system at a high level in a company, some members of staff
will take the quality system seriously.

111
Software Quality Management System

• Quality System Activities: The quality system activities encompass

the following:
• Auditing of projects
• Review of the quality system
• Development of standards, methods, and guidelines, etc.
• Production of documents for the top management summarizing the
effectiveness of the quality system in the organization.

112
Software Reliability

• Software Reliability means Operational reliability. It is described as

the ability of a system or component to perform its required functions
under static conditions for a specific period.
• Software reliability is also defined as the probability that a software
system fulfills its assigned task in a given environment for a
predefined number of input cases, assuming that the hardware and
the input are free of error.

113
Software Reliability

• Software Reliability is an essential connect of software quality,

composed with functionality, usability, performance, serviceability,
capability, installability, maintainability, and documentation.

• Software Reliability is hard to achieve because the complexity of

software turn to be high.

114
Software Reliability

• While any system with a high degree of complexity, containing

software, will be hard to reach a certain level of reliability, system
developers tend to push complexity into the software layer, with the
speedy growth of system size and ease of doing so by upgrading the
software.

115
Software Reliability

• For example, large next-generation aircraft will have over 1 million

source lines of software on-board; next-generation air traffic control
systems will contain between one and two million lines; the upcoming
International Space Station will have over two million lines on-board
and over 10 million lines of ground support software; several
significant life-critical defense systems will have over 5 million source
lines of software. While the complexity of software is inversely
associated with software reliability, it is directly related to other vital
factors in software quality, especially functionality, capability, etc.

116
 References

• [Link]
• [Link]
quality#:~:text=Software%20quality%20is%20defined%20as,defect%2
0management%20and%20quality%20attributes.
• [Link]
=According%20to%20ANSI%2C%20Software%20Reliability,time%20in
%20a%20specified%20environment.&text=Software%20Reliability%2
0is%20hard%20to,software%20tends%20to%20be%20high.
• [Link]
reliability
117
THANK YOU

118
 University Institute of Engineering
DEPARTMENT OF COMPUTER SCIENCE
& ENGINEERING
Bachelor of Engineering (Computer Science & Engineering)
Subject Name: Software Engineering
Subject Code: 22CST-313
Prepared by:
Er. Puneet Kaur(E6913)

Quality Management DISCOVER . LEARN . EMPOWER

119
 Chapter-8
Quality Management
• Software Review

• Formal technical Review

120
Software Review
• Software Review is systematic inspection of a software by one or
more individuals who work together to find and resolve errors and
defects in the software during the early stages of Software
Development Life Cycle (SDLC).
• Software review is an essential part of Software Development Life
Cycle (SDLC) that helps software engineers in validating the quality,
functionality and other vital features and components of the
software.

121
Software Review
• It is a whole process that includes testing the software product and it
makes sure that it meets the requirements stated by the client.
• Usually performed manually, software review is used to verify various
documents like requirements, system designs, codes, test plans and
test cases.

122
Objectives of Software Review
• The objective of software review is:
• To improve the productivity of the development team.
• To make the testing process time and cost effective.
• To make the final software with fewer defects.
• To eliminate the inadequacies.

123
Process of Software Review

124
Types of Software Reviews

There are mainly 3 types of software reviews:

• Software Peer Review:
Peer review is the process of assessing the technical content and
quality of the product and it is usually conducted by the author of the
work product along with some other developers.
Peer review is performed in order to examine or resolve the defects in
the software, whose quality is also checked by other members of the
team.

125
Types of Software Reviews
• Peer Review has following types:
(i) Code Review:
Computer source code is examined in a systematic way.
(ii) Pair Programming:
It is a code review where two developers develop code together at the same
platform.
(iii) Walkthrough:
Members of the development team is guided bu author and other interested
parties and the participants ask questions and make comments about defects.
(iv) Technical Review:
A team of highly qualified individuals examines the software product for its
client’s use and identifies technical defects from specifications and standards.
(v) Inspection:
In inspection the reviewers follow a well-defined process to find defects.
126
Types of Software Reviews
• Software Management Review:
Software Management Review evaluates the work status. In this
section decisions regarding downstream activities are taken.
• Software Audit Review:
Software Audit Review is a type of external review in which one or
more critics, who are not a part of the development team, organize
an independent inspection of the software product and its processes
to assess their compliance with stated specifications and standards.
This is done by managerial level people.

127
Advantages of Software Review
• Defects can be identified earlier stage of development (especially in
formal review).
• Earlier inspection also reduces the maintenance cost of software.
• It can be used to train technical authors.
• It can be used to remove process inadequacies that encourage
defects.

128
Formal Technical Review

• Formal Technical Review (FTR) is a software quality control activity

performed by software engineers.
• Objectives of formal technical review (FTR):
Some of these are:
• Useful to uncover error in logic, function and implementation for any
representation of the software.
• The purpose of FTR is to verify that the software meets specified
requirements.
• To ensure that software is represented according to predefined standards.
• It helps to review the uniformity in software that is development in a
uniform manner.
• To makes the project more manageable.

129
Formal Technical Review

• In addition, the purpose of FTR is to enable junior engineer to

observer the analysis, design, coding and testing approach more
closely.
• FTR also works to promote back up and continuity become familiar
with parts of software they might not have seen otherwise.
• Actually, FTR is a class of reviews that include walkthroughs,
inspections, round robin reviews and other small group technical
assessments of software.
• Each FTR is conducted as meeting and is considered successfully only
if it is properly planned, controlled and attended.
130
Formal Technical Review

• The review meeting:

Each review meeting should be held considering the following constraints-

Involvement of people:
• Between 3, 4 and 5 people should be involve in the review.
• Advance preparation should occur but it should be very short that is at the
most 2 hours of work for every person.
• The short duration of the review meeting should be less than two hour.
Gives these constraints, it should be clear that an FTR focuses on specific
(and small) part of the overall software.
131
Formal Technical Review

• At the end of the review, all attendees of FTR must decide what to do.
• Accept the product without any modification.
• Reject the project due to serious error (Once corrected, another app
need to be reviewed), or
• Accept the product provisional (minor errors are encountered and are
should be corrected, but no additional review will be required).
• The decision was made, with all FTR attendees completing a sign-of
indicating their participation in the review and their agreement with
the findings of the review team.

132
Formal Technical Review

• Review reporting and record keeping :-

• During the FTR, the reviewer actively records all issues that have been
raised.
• At the end of the meeting all these issues raised are consolidated and
a review list is prepared.
• Finally, a formal technical review summary report is prepared.

133
Formal Technical Review

• It answers three questions :-

• What was reviewed ?
• Who reviewed it ?
• What were the findings and conclusions ?

134
Formal Technical Review

• Review guidelines
Guidelines for the conducting of formal technical reviews should be
established in advance.
• These guidelines must be distributed to all reviewers, agreed upon,
and then followed.
• A review that is unregistered can often be worse than a review that
does not minimum set of guidelines for FTR.

135
Formal Technical Review

• Review the product, not the manufacture (producer).

• Take written notes (record purpose)
• Limit the number of participants and insists upon advance preparation.
• Develop a checklist for each product that is likely to be reviewed.
• Allocate resources and time schedule for FTRs in order to maintain time schedule.
• Conduct meaningful training for all reviewers in order to make reviews effective.
• Reviews earlier reviews which serve as the base for the current review being
conducted.
• Set an agenda and maintain it.
• Separate the problem areas, but do not attempt to solve every problem notes.

136
 References

• [Link]
review/
• [Link]
• [Link]
software-
engineering/#:~:text=Formal%20Technical%20Review%20(FTR)%20is,
formal%20technical%20review%20(FTR)%3A&text=The%20purpose%
20of%20FTR%20is,represented%20according%20to%20predefined%2
0standards.

137
THANK YOU

138
 University Institute of Engineering
DEPARTMENT OF COMPUTER SCIENCE
& ENGINEERING
Bachelor of Engineering (Computer Science & Engineering)
Subject Name: Software Engineering
Subject Code: 22CST-313
Prepared by:
Er. Puneet Kaur(E6913)

Quality Management DISCOVER . LEARN . EMPOWER

139
 Chapter-8
Quality Management
• SQA

140
SQA

• Software quality assurance is a planned and systematic plan of all

actions necessary to provide adequate confidence that an item or
product conforms to establish technical requirements.

• A set of activities designed to calculate the process by which the

products are developed or manufactured.

141
SQA Encompasses

• A quality management approach

• Effective Software engineering technology (methods and tools)
• Formal technical reviews that are tested throughout the software
process
• A multitier testing strategy
• Control of software documentation and the changes made to it.
• A procedure to ensure compliances with software development
standards
• Measuring and reporting mechanisms.
142
SQA Activities

• Software quality assurance is composed of a variety of functions

associated with two different constituencies ?

• The software engineers who do technical work and an SQA group that
has responsibility for quality assurance planning, record keeping,
analysis, and reporting.

143
Activities of SQA
• Following activities are performed by an independent SQA group:
• Prepares an SQA plan for a project: The program is developed during
project planning and is reviewed by all stakeholders.
• The plan governs quality assurance activities performed by the
software engineering team and the SQA group.
• The plan identifies calculation to be performed, audits and reviews to
be performed, standards that apply to the project, techniques for
error reporting and tracking, documents to be produced by the SQA
team, and amount of feedback provided to the software project
team.
144
Activities of SQA
• Participates in the development of the project's software process
description: The software team selects a process for the work to be
performed.
• The SQA group reviews the process description for compliance with
organizational policy, internal software standards, externally imposed
standards (e.g. ISO-9001), and other parts of the software project
plan.

145
Activities of SQA
• Reviews software engineering activities to verify compliance with
the defined software process: The SQA group identifies, reports, and
tracks deviations from the process and verifies that corrections have
been made.
• Audits designated software work products to verify compliance with
those defined as a part of the software process: The SQA group
reviews selected work products, identifies, documents and tracks
deviations, verify that corrections have been made, and periodically
reports the results of its work to the project manager.

146
Activities of SQA
• Ensures that deviations in software work and work products are
documented and handled according to a documented
procedure: Deviations may be encountered in the project method,
process description, applicable standards, or technical work products.

• Records any noncompliance and reports to senior

management: Non- compliance items are tracked until they are
resolved.

147
Components of SQA System

• An SQA system always combines a wide range of SQA components.

These components can be classified into the following six classes −
• Pre-project components
• This assures that the project commitments have been clearly defined
considering the resources required, the schedule and budget; and the
development and quality plans have been correctly determined.

148
Components of SQA System

• Components of project life cycle activities assessment

• The project life cycle is composed of two stages: the development life
cycle stage and the operation–maintenance stage.
• The development life cycle stage components detect design and
programming errors. Its components are divided into the following
sub-classes: Reviews, Expert opinions, and Software testing.
• The SQA components used during the operation–maintenance phase
include specialized maintenance components as well as development
life cycle components, which are applied mainly for functionality to
improve the maintenance tasks.
149
Components of SQA System

• Components of infrastructure error prevention and improvement

• The main objective of these components, which is applied throughout
the entire organization, is to eliminate or at least reduce the rate of
errors, based on the organization’s accumulated SQA experience.
• Components of software quality management
• This class of components deal with several goals, such as the control
of development and maintenance activities, and the introduction of
early managerial support actions that mainly prevent or minimize
schedule and budget failures and their outcomes.

150
Components of SQA System

• Components of standardization, certification, and SQA system

assessment
• These components implement international professional and
managerial standards within the organization. The main objectives of
this class are utilization of international professional knowledge,
improvement of coordination of the organizational quality systems
with other organizations, and assessment of the achievements of
quality systems according to a common scale. The various standards
may be classified into two main groups: quality management
standards and project process standards.

151
Components of SQA System

• Organizing for SQA – the human components

• The SQA organizational base includes managers, testing personnel,
the SQA unit and the persons interested in software quality such as
SQA trustees, SQA committee members, and SQA forum members.
Their main objectives are to initiate and support the implementation
of SQA components, detect deviations from SQA procedures and
methodology, and suggest improvements.

152
Pre-project Software Quality Components

• These components help to improve the preliminary steps taken

before starting a project. It includes −
• Contract Review
• Development and Quality Plans

153
Pre-project Software Quality Components

• Contract Review
• Normally, a software is developed for a contract negotiated with a
customer or for an internal order to develop a firmware to be
embedded within a hardware product.
• In all these cases, the development unit is committed to an agreed-
upon functional specification, budget and schedule.
• Hence, contract review activities must include a detailed examination
of the project proposal draft and the contract drafts.

154
Pre-project Software Quality Components

• Specifically, contract review activities include −

• Clarification of the customer’s requirements
• Review of the project’s schedule and resource requirement estimates
• Evaluation of the professional staff’s capacity to carry out the
proposed project
• Evaluation of the customer’s capacity to fulfil his obligations
• Evaluation of development risks

155
Pre-project Software Quality Components

• Development and Quality Plans

After signing the software development contract with an organization
or an internal department of the same organization, a development
plan of the project and its integrated quality assurance activities are
prepared.
• These plans include additional details and needed revisions based on
prior plans that provided the basis for the current proposal and
contract.

156
Pre-project Software Quality Components

• Most of the time, it takes several months between the tender

submission and the signing of the contract.
• During these period, resources such as staff availability, professional
capabilities may get changed.
• The plans are then revised to reflect the changes that occurred in the
interim.

157
Issues of Project Development
• The main issues treated in the project development plan are −
• Schedules
• Required manpower and hardware resources
• Risk evaluations
• Organizational issues: team members, subcontractors and
partnerships
• Project methodology, development tools, etc.
• Software reuse plans

158
Issues of Project Quality
• The main issues treated in the project’s quality plan are −
• Quality goals, expressed in the appropriate measurable terms
• Criteria for starting and ending each project stage
• Lists of reviews, tests, and other scheduled verification and validation
activities

159
 References

• [Link]
ware_quality_management_sqa_components.htm

• [Link]

• [Link]
[Link]

160
THANK YOU

161
 University Institute of Engineering
DEPARTMENT OF COMPUTER SCIENCE
& ENGINEERING
Bachelor of Engineering (Computer Science & Engineering)
Subject Name: Software Engineering
Subject Code: 22CST-313
Prepared by:
Er. Puneet Kaur(E6913)

Quality Management DISCOVER . LEARN . EMPOWER

162
 Chapter-8
Quality Management
• ISO 9000

163
ISO 9000

• ISO (International Standards Organization) is a group or consortium of

63 countries established to plan and fosters standardization.
• ISO declared its 9000 series of standards in 1987. It serves as a
reference for the contract between independent parties.
• The ISO 9000 standard determines the guidelines for maintaining a
quality system.
• The ISO standard mainly addresses operational methods and
organizational methods such as responsibilities, reporting, etc.
• ISO 9000 defines a set of guidelines for the production process and is
not directly concerned about the product itself.

164
Types of ISO 9000 Quality Standards

165
Types of ISO 9000 Quality Standards

• The ISO 9000 series of standards is based on the assumption that if a

proper stage is followed for production, then good quality products
are bound to follow automatically. The types of industries to which
the various ISO standards apply are as follows.

• ISO 9001: This standard applies to the organizations engaged in

design, development, production, and servicing of goods. This is the
standard that applies to most software development organizations.
.

166
Types of ISO 9000 Quality Standards

• ISO 9002: This standard applies to those organizations which do not

design products but are only involved in the production. Examples of
these category industries contain steel and car manufacturing
industries that buy the product and plants designs from external
sources and are engaged in only manufacturing those products.
Therefore, ISO 9002 does not apply to software development
organizations.
• ISO 9003: This standard applies to organizations that are involved
only in the installation and testing of the products. For example, Gas
companies

167
How to get ISO 9000 Certification?

• An organization determines to obtain ISO 9000 certification applies to

ISO registrar office for registration. The process consists of the
following stages:

168
How to get ISO 9000 Certification?

• Application: Once an organization decided to go for ISO certification,

it applies to the registrar for registration.
• Pre-Assessment: During this stage, the registrar makes a rough
assessment of the organization.
• Document review and Adequacy of Audit: During this stage, the
registrar reviews the document submitted by the organization and
suggest an improvement.

169
How to get ISO 9000 Certification?

• Compliance Audit: During this stage, the registrar checks whether the
organization has compiled the suggestion made by it during the
review or not.
• Registration: The Registrar awards the ISO certification after the
successful completion of all the phases.
• Continued Inspection: The registrar continued to monitor the
organization time by time.

170
ISO 9000 history and revisions: ISO 9000:2000,
2008, and 2015
• ISO 9000 was first published in 1987 by the International Organization
for Standardization (ISO), a specialized international agency for
standardization composed of the national standards bodies of more
than 160 countries.

• The standards underwent major revisions in 2000 and 2008. The most
recent versions of the standard, ISO 9000:2015 and ISO 9001:2015,
were published in September 2015.

171
ISO 9000:2000

• ISO 9000:2000 refers to the ISO 9000 update released in the year
2000.
• The ISO 9000:2000 revision had five goals:
• Meet stakeholder needs
• Be usable by all sizes of organizations
• Be usable by all sectors
• Be simple and clearly understood
• Connect quality management system to business processes

172
ISO 9000:2015 principles of Quality Management

• The ISO 9000:2015 and ISO 9001:2015 standards are based on seven
quality management principles that senior management can apply to
promote organizational improvement.

173
174
ISO 9000:2015 principles of Quality Management

• Customer focus
• Understand the needs of existing and future customers
• Align organizational objectives with customer needs and expectations
• Meet customer requirements
• Measure customer satisfaction
• Manage customer relationships
• Aim to exceed customer expectations

175
ISO 9000:2015 principles of Quality Management

• Leadership
• Establish a vision and direction for the organization
• Set challenging goals
• Model organizational values
• Establish trust
• Equip and empower employees
• Recognize employee contributions

176
ISO 9000:2015 principles of Quality Management

• Engagement of people
• Ensure that people’s abilities are used and valued
• Make people accountable
• Enable participation in continual improvement
• Evaluate individual performance
• Enable learning and knowledge sharing
• Enable open discussion of problems and constraints

177
ISO 9000:2015 principles of Quality Management

• Process approach
• Manage activities as processes
• Measure the capability of activities
• Identify linkages between activities
• Prioritize improvement opportunities
• Deploy resources effectively

178
ISO 9000:2015 principles of Quality Management

• Improvement
• Improve organizational performance and capabilities
• Align improvement activities
• Empower people to make improvements
• Measure improvement consistently
• Celebrate improvements

179
ISO 9000:2015 principles of Quality Management

• Evidence-based decision making

• Ensure the accessibility of accurate and reliable data
• Use appropriate methods to analyze data
• Make decisions based on analysis
• Balance data analysis with practical experience

180
ISO 9000:2015 principles of Quality Management

• Relationship management
• Identify and select suppliers to manage costs, optimize resources, and
create value
• Establish relationships considering both the short and long term
• Share expertise, resources, information, and plans with partners
• Collaborate on improvement and development activities
• Recognize supplier successes

181
 References

• [Link]
certification
• [Link]
9000#:~:text=ISO%209000%20is%20defined%20as,to%20organization
s%20of%20any%20size.

182
THANK YOU

183
 University Institute of Engineering
DEPARTMENT OF COMPUTER SCIENCE
& ENGINEERING
Bachelor of Engineering (Computer Science & Engineering)
Subject Name: Software Engineering
Subject Code: 22CST-313
Prepared by:
Er. Puneet Kaur(E6913)

Software Testing DISCOVER . LEARN . EMPOWER

184
 Chapter-7
Software Testing
• Basis Path Testing

185
Basis Path Testing

• Basis path testing, a structured testing or white box testing technique

used for designing test cases intended to examine all possible paths
of execution at least once.
• Creating and executing tests for all possible paths results in 100%
statement coverage and 100% branch coverage.

186
Basis Path Testing

• Basis Path Testing is a white-box testing technique based on the

control structure of a program or a module.
• Using this structure, a control flow graph is prepared and the various
possible paths present in the graph are executed as a part of testing.
Therefore, by definition,
• Basis path testing is a technique of selecting the paths in the control
flow graph, that provide a basis set of execution paths through the
program or module.

187
Basis Path Testing

• Since this testing is based on the control structure of the program, it

requires complete knowledge of the program’s structure. To design
test cases using this technique, four steps are followed :
• Construct the Control Flow Graph
• Compute the Cyclomatic Complexity of the Graph
• Identify the Independent Paths
• Design Test cases from Independent Paths

188
Basis Path Testing (Notations)

• Control Flow Graph –

A control flow graph (or simply, flow graph) is a directed graph which
represents the control structure of a program or module. A control
flow graph (V, E) has V number of nodes/vertices and E number of
edges in it. A control graph can also have :
• Junction Node – a node with more than one arrow entering it.
• Decision Node – a node with more then one arrow leaving it.
• Region – area bounded by edges and nodes (area outside the graph is
also counted as a region.).

189
190
Notations
• Below are the notations used while constructing a flow graph :
• Sequential Statements –

191
Notations
• If – Then – Else –

192
Notations
• Do – While –

193
Notations
• Switch – Case

194
Cyclomatic Complexity
• The cyclomatic complexity V(G) is said to be a measure of the logical
complexity of a program. It can be calculated using three different
formulae :
• Formula based on edges and nodes :V(G) = e - n + 2*PWhere,
e is number of edges,
n is number of vertices,
P is number of connected components.
• For example, consider first graph given above,
• where, e = 4, n = 4 and p = 1 So, Cyclomatic complexity V(G) = 4 - 4 + 2
*1=2
195
Cyclomatic Complexity
• Formula based on Decision Nodes :
• V(G) = d + P where,
d is number of decision nodes,
P is number of connected nodes.
• For example, consider first graph given above,
• where, d = 1 and p = 1 So, Cyclomatic Complexity V(G) = 1 + 1 = 2

196
Cyclomatic Complexity
• Formula based on Regions :V(G) = number of regions in the graph For
example, consider first graph given above,
• Cyclomatic complexity V(G) = 1 (for Region 1) + 1 (for Region 2) = 2
• Hence, using all the three above formulae, the cyclomatic complexity
obtained remains same. All these three formulae can be used to
compute and verify the cyclomatic complexity of the flow graph.

197
Independent Paths
• An independent path in the control flow graph is the one which
introduces at least one new edge that has not been traversed before
the path is defined.
• The cyclomatic complexity gives the number of independent paths
present in a flow graph.
• This is because the cyclomatic complexity is used as an upper-bound
for the number of tests that should be executed in order to make sure
that all the statements in the program have been executed at least
once.

198
Advantages
• Basis Path Testing can be applicable in the following cases:
• More Coverage –
Basis path testing provides the best code coverage as it aims to achieve
maximum logic coverage instead of maximum path coverage. This results in
an overall thorough testing of the code.
• Maintenance Testing –
When a software is modified, it is still necessary to test the changes made
in the software which as a result, requires path testing.
• Unit Testing –
When a developer writes the code, he or she tests the structure of the
program or module themselves first. This is why basis path testing requires
enough knowledge about the structure of the code.
199
Advantages
• Integration Testing –
When one module calls other modules, there are high chances of
Interface errors. In order to avoid the case of such errors, path testing
is performed to test all the paths on the interfaces of the modules.
• Testing Effort –
Since the basis path testing technique takes into account the
complexity of the software (i.e., program or module) while computing
the cyclomatic complexity, therefore it is intuitive to note that testing
effort in case of basis path testing is directly proportional to the
complexity of the software or program.

200
 References

• [Link]
ath_testing.htm
• [Link]
testing/
• [Link]
• [Link]

201
THANK YOU

202
 University Institute of Engineering
DEPARTMENT OF COMPUTER SCIENCE
& ENGINEERING
Bachelor of Engineering (Computer Science & Engineering)
Subject Name: Software Engineering
Subject Code: 22CST-313
Prepared by:
Er. Puneet Kaur(E6913)

Software Maintenance and Reuse DISCOVER . LEARN . EMPOWER

203
 Chapter-9
Software Maintenance and Reuse
• Software Maintenance

• Types of Maintenance

• Software Maintenance Models

204
Software Maintenance

• Software Maintenance is the process of modifying a software product

after it has been delivered to the customer.

• The main purpose of software maintenance is to modify and update

software application after delivery to correct faults and to improve
performance.

205
Need for Maintenance
• Software Maintenance must be performed in order to:
• Correct faults.
• Improve the design.
• Implement enhancements.
• Interface with other systems.
• Accommodate programs so that different hardware, software, system
features, and telecommunications facilities can be used.
• Migrate legacy software.
• Retire software.

206
Why are modifications required?
• There are number of reasons, why modifications are required, some of them are
briefly mentioned below:
• Market Conditions - Policies, which changes over the time, such as taxation and
newly introduced constraints like, how to maintain bookkeeping, may trigger
need for modification.
• Client Requirements - Over the time, customer may ask for new features or
functions in the software.
• Host Modifications - If any of the hardware and/or platform (such as operating
system) of the target host changes, software changes are needed to keep
adaptability.
• Organization Changes - If there is any business level change at client end, such as
reduction of organization strength, acquiring another company, organization
venturing into new business, need to modify in the original software may arise.

207
Categories of Software Maintenance
• Maintenance can be divided into the following:
• Corrective maintenance:
Corrective maintenance of a software product may be essential either
to rectify some bugs observed while the system is in use, or to
enhance the performance of the system.
• Adaptive maintenance:
This includes modifications and updations when the customers need
the product to run on new platforms, on new operating systems, or
when they need the product to interface with new hardware and
software.

208
Categories of Software Maintenance
• Perfective maintenance:
A software product needs maintenance to support the new features
that the users want or to change different types of functionalities of
the system according to the customer demands.
• Preventive maintenance:
This type of maintenance includes modifications and updations to
prevent future problems of the software. It goals to attend problems,
which are not significant at this moment but may cause serious issues
in future.

209
Cost of Maintenance

• On an average, the cost of software maintenance is more than 50% of

all SDLC phases. There are various factors, which trigger maintenance
cost go high.

210
Real-world factors affecting Maintenance Cost

• The standard age of any software is considered up to 10 to 15 years.

• Older software's, which were meant to work on slow machines with less
memory and storage capacity cannot keep themselves challenging against
newly coming enhanced software on modern hardware.
• As technology advances, it becomes costly to maintain old software.
• Most maintenance engineers are newbie and use trial and error method to
rectify problem.
• Often, changes made can easily hurt the original structure of the software,
making it hard for any subsequent changes.
• Changes are often left undocumented which may cause more conflicts in
future.

211
Software-end factors affecting Maintenance Cost

• Structure of Software Program

• Programming Language
• Dependence on external environment
• Staff reliability and availability

212
Maintenance Activities

213
Maintenance Activities

• These activities go hand-in-hand with each of the following phase:

• Identification & Tracing - It involves activities pertaining to
identification of requirement of modification or maintenance. It is
generated by user or system may itself report via logs or error
messages. Here, the maintenance type is classified also.
• Analysis - The modification is analyzed for its impact on the system
including safety and security implications. If probable impact is
severe, alternative solution is looked for. A set of required
modifications is then materialized into requirement specifications.
The cost of modification/maintenance is analyzed and estimation is
concluded.

214
Maintenance Activities

• Design - New modules, which need to be replaced or modified, are

designed against requirement specifications set in the previous stage.
Test cases are created for validation and verification.
• Implementation - The new modules are coded with the help of
structured design created in the design step. Every programmer is
expected to do unit testing in parallel.

215
Maintenance Activities

• System Testing - Integration testing is done among newly created

modules. Integration testing is also carried out between new modules
and the system. Finally the system is tested as a whole, following
regressive testing procedures.
• Acceptance Testing - After testing the system internally, it is tested for
acceptance with the help of users. If at this state, user complaints
some issues they are addressed or noted to address in next iteration.

216
Maintenance Activities

• Delivery - After acceptance test, the system is deployed all over the
organization either by small update package or fresh installation of
the system. The final testing takes place at client end after the
software is delivered.
• Training facility is provided if required, in addition to the hard copy of
user manual.
• Maintenance management - Configuration management is an
essential part of system maintenance. It is aided with version control
tools to control versions, semi-version or patch management.

217
Software Maintenance Process Models
• The activities involved in a software maintenance project are not unique and
depend upon several factors like extent of modification required, conditions of
existing product, resource availability to maintenance team, expected project risks
etc.
• The following maintenance models have been proposed:
• Quick-fix Model
• It is an adhoc approach to maintain the software. It is a fire fighting approach,
waiting for the problem to occur and then trying to fix it as quickly as possible.

218
Software Maintenance Process Models
• Iterative Enhancement Model
• The iterative enhancement model, which was originally proposed as a process
model, can be easily adapted for maintaining a software system. It considers that
the changes made to the software system are iterative in nature.
• It involves following stages:
a)Requirement analysis
• The requirements for change are analyzed to begin the software maintenance
process
b)Classification of requested modifications
• After analysis, the requested modifications are classified according to the
complexity, technical issues, and identification of modules that will be
affected.

219
Software Maintenance Process Models
c)Implementation of requested modifications
• At the end, the software is modified to implement the
modification request. At each stage, the documentation is updated
to accommodate changes of requirements analysis, design, coding
and testing phases. It is essential to have a complete
documentation before implementation of iterative enhancement
model begins.

220
Software Maintenance Process Models
• Reuse-oriented Model
• The reuse-oriented model assumes that the existing program components
can be reused to perform maintenance. This approach can be represented by
a reverse engineering cycle followed by a forward engineering cycle. It is
also known as software reengineering.
• The old code is analyzed to extract the module specifications. The module
specifications are then analyzed to produce the design.
• The design is analyzed(abstracted) to produce the original requirements
specification.
• The change requests are then applied to this requirements specification to
generate new requirements specification. Then forward engineering is
applied to finally apply the changes to the code.

221
Software Maintenance Process Models

222
 References

• [Link]
maintenance
• [Link]
ntenance_overview.htm
• [Link]
maintenance/

223
THANK YOU

224
 University Institute of Engineering
DEPARTMENT OF COMPUTER SCIENCE
& ENGINEERING
Bachelor of Engineering (Computer Science & Engineering)
Subject Name: Software Engineering
Subject Code: 22CST-313
Prepared by:
Er. Puneet Kaur(E6913)

Software Maintenance and Reuse DISCOVER . LEARN . EMPOWER

225
 Chapter-9
Software Maintenance and Reuse
• Software Reverse Engineering

• Software Reuse

226
Software Reverse Engineering
• Software Reverse Engineering is a process of recovering the design,
requirement specifications and functions of a product from an
analysis of its code. It builds a program database and generates
information from this.
• The purpose of reverse engineering is to facilitate the maintenance
work by improving the understandability of a system and to produce
the necessary documents for a legacy system.

227
Reverse Engineering Goals
• Cope with Complexity.
• Recover lost information.
• Detect side effects.
• Synthesize higher abstraction.
• Facilitate Reuse.

228
Steps of Software Reverse Engineering
• Collection Information:
This step focuses on collecting all possible information (i.e., source design
documents etc.) about the software.
• Examining the information:
The information collected in step-1 as studied so as to get familiar with the
system.
• Extracting the structure:
This step concerns with identification of program structure in the form of
structure chart where each node corresponds to some routine.
• Recording the functionality:
During this step processing details of each module of the structure, charts
are recorded using structured language like decision table, etc.
229
Steps of Software Reverse Engineering
• Recording data flow:
From the information extracted in step-3 and step-4, set of data flow
diagrams are derived to show the flow of data among the processes.
• Recording control flow:
High level control structure of the software is recorded.
• Review extracted design:
Design document extracted is reviewed several times to ensure consistency
and correctness. It also ensures that the design represents the program.
• Generate documentation:
Finally, in this step, the complete documentation including SRS, design
document, history, overview, etc. are recorded for future use.

230
Software Reuse
• Code reuse, also called software reuse, is the use of
existing software, or software knowledge, to build new software
• Almost all artifacts associated with software development, including
project plan and test plan, can be used again. However, the important
items that can be effectively used again are,
• Requirements specification
• Design
• Code
• Test cases
• Knowledge
231
Basic issues in any reuse program

• The following are some of the basic issues that must be for starting
any reuse program,
• Component creation
• Component indexing and storing
• Component search
• Component understanding
• Component adaptation
• Repository maintenance

232
Basic issues in any reuse program

• Component creation
• The reusable components have to be first identified. The selection of
the correct kind of components having the potential for reuse is best.
• Component indexing and storing
• Indexing requires classification of the again usable components so
that they can be easily found when looking for a component for
reuse. The components need to be stored in a Relational Database
Management System (RDBMS) or an Object-Oriented Database
System (ODBMS) for efficient access when the number of
components becomes large.
233
Basic issues in any reuse program

• Component searching
• The programmers need to search for correct components matching
their needs in a database of components. To be able to search
components efficiently, the programmers require a perfect method to
tells the components that they are looking for.
• Component understanding
• The programmers need a prefect and sufficiently complete
understanding of what the component does to be able to decide
whether they can reuse the component or not. To understand, the
components should be well documented and should do something
simple in the code.
234
Basic issues in any reuse program

• Component adaptation
• Before they can be reused, the components may need adaptation,
since a selected component may not exactly be mixed the problem at
hand. However, tinkering with the code is also not the best solution
because this is very likely to be a source of faults.

235
Basic issues in any reuse program

• Repository maintenance
• It once is created requires repeated maintenance. New components,
as and when made have to be entered inside the repository. The
faulty components have to be followed.
• Further, when new applications mixed, the older applications become
obsolete. In this case, the obsolete components might have to be
deleted from the repository.
• Domain analysis
• The aim is to find the reusable pieces for a problem domain.

236
Advantages of software reuse

• Software products are costly.

• Software project managers are worried about the expensive software
development and are desperately find for ways to cut development
cost are,
• A possible way to reduce development costs is to use parts again
from previously developed software.
• In addition to decrease development cost and time, use again also
leads to the higher quality of the developed products.

237
The reuse approach
• Although reuse is often simply thought of as the reuse of system
components, there are many different approaches to reuse that may
be used.
• Reuse is possible at a range of levels from simple functions to
complete application systems.
• The reuse landscape covers the range of possible reuse techniques.

238
239
The reuse approach
• Key factors for reuse planning:
• The development schedule for the software.
• The expected software lifetime.
• The background, skills and experience of the development team.
• The criticality of the software and its non-functional requirements.
• The application domain.
• The execution platform for the software.

240
THANK YOU

241