This document provides an overview of software testing concepts. It discusses testing as an engineering activity and process. It introduces the Testing Maturity Model which describes stages of test process improvement. Basic definitions are provided for terms like error, fault, failure, test case, test oracle. Software testing principles and the tester's role are described. The origins and costs of defects are discussed. Defect classes are classified into requirements, design, code, and testing defects. The concept of a defect repository to catalog defect data is introduced. Examples of coin problem defects are given to illustrate defect classification.

1. SOFTWARE TESTING
UNIT I
By
Gnana Jeslin
AP/CSE
RMKCET

2. UNIT I INTRODUCTION
Testing as an Engineering Activity – Testing as a Process – Testing
Maturity Model- Testing axioms – Basic definitions – Software Testing
Principles – The Tester’s Role in a Software Development Organization –
Origins of Defects – Cost of defects – Defect Classes – The Defect
Repository and Test Design –Defect Examples- Developer/Tester upport
of Developing a Defect Repository

3. COURSE OUTCOME
Understand the impact of defects in software
development process

4. SOFTWARE TESTING
• Testing is generally described as a group of procedures carried out to
evaluate some aspect of a piece of software.
• Testing can be described as a process used for revealing defects in
software, and for establishing that the software has attained a
specified degree of quality with respect to selected attributes.

5. Testing as an Engineering Activity
• Software systems are becoming more challenging to build.
• New methods, techniques, and tools are becoming available to support
development and maintenance tasks.
• Poor quality software that can cause loss of life or property is no longer
acceptable to society.
• Highly qualified staff ensures that software products are built on time, within
budget, and are of the highest quality with respect to attributes such as reliability,
correctness, usability, and the ability to meet all user requirements.

6. Using an engineering approach to software
development implies that:
• The development process is well understood
• Projects are planned
• Life cycle models are defined
• Standards are in place for product and process
• Measurements are employed to evaluate product and process quality
• Components are reused
• Validation and verification processes play a key role in quality determination
• Engineers have proper education, training, and certification.

7. Testing as a Process

8. Testing as a Process
Process in Engineering Domain
• Process, in the software engineering domain, is the set of methods,
practices, standards, documents, activities, policies, and procedures
that software engineers use to develop and maintain a software
system and its associated artifacts, such as project and test plans,
design documents, code, and manuals.

9. Testing as a Process
The Role of Process in Software Quality
• The need for software products of high quality has pressured those in
the profession to identify and quantify quality factors such as
usability, testability, maintainability, and reliability, and to identify
engineering practices that support the production of quality
products having these favorable attributes.

10. Testing as a Process
• The software development process has been described as a series of
phases, procedures, and steps that result in the production of a
software product.
• Embedded within the software development process are several
other processes including testing.

11. Testing as a Process

12. Testing as a Process
Testing is related to two other processes.
• Validation is the process of evaluating a software system or component
during, or at the end of, the development cycle in order to determine
whether it satisfies specified requirements.
• Verification is the process of evaluating a software system or component
to determine whether the products of a given development phase satisfy
the conditions imposed at the start of that phase.

13. Testing Maturity Model
Testing Maturity Model is a means for developing quality software
The focus of the TMM is on testing as a process in itself that can be evaluated and
improved.
In the testing domain possible benefits of test process improvement are the
following:
• smarter testers
• higher quality software
• the ability to meet budget and scheduling goals
• improved planning
• the ability to meet quantifiable testing goals

14. Testing Maturity Model
• TMM follows a staged architecture for process improvement models.
• It contains stages or levels through which an organization passes as its
testing
• process evolves from one that is ad hoc and unmanaged to one that is
managed, defined, measured, and optimizable.

15. Testing Maturity Model

16. Testing Maturity Model

17. Testing Axioms
An axiom is a sentence or proposition that is not proved or
demonstrated and is considered as obvious or as an initial
necessary consensus for a theory building or acceptation.

18. Testing Axioms
1. It is impossible to test a program completely.
2. Software testing is a risk-based exercise.
3. Testing cannot show the absence of bugs.
4. The more bugs you find, the more bugs there are.
5. Not all bugs found will be fixed.

19. Testing Axioms
6. It is difficult to say when a bug is indeed a bug.
7. Specifications are never final.
8. Software testers are not the most popular members of a project.
9. Software testing is a disciplined and technical profession.

20. Basic Definitions
Error
• An error is a mistake, misconception, or misunderstanding on the part of
a software developer.
• For example, a developer may misunderstand a design notation, or a
programmer might type a variable name incorrectly.

21. Basic Definitions
Faults (Defects)
• A fault (defect) is introduced into the software as the result of an error.
• It is an anomaly in the software that may cause it to behave incorrectly,
and not according to its specification.
• Faults or defects are sometimes called ―bugs.

22. Basic Definitions
Failures
A failure is the inability of a software system or component
to perform its required functions within specified
performance requirements

23. Basic Definitions
Test Cases
A test case in a practical sense is a test-related item which contains the following
information:
1. A set of test inputs.
2. Execution conditions.
3. Expected outputs.

24. Basic Definitions
Test
A test is a group of related test cases, or a group of related test cases and test
procedures.
• A group of related tests – Test Set
• A group of related tests that are associated with a DB and are usually run
together - Test Suite

25. Basic Definitions
Test Oracle
A test oracle is a document, or piece of software that allows testers to
determine whether a test has been passed or failed.
Test Bed
A test bed is an environment that contains all the hardware and software
needed to test a software component or a software system.
Eg‘s Simulators, emulators, Memory Checkers, software tools.

26. Software Testing Principles
Principle 1
Testing is the process of exercising a software component using a selected set of test
cases, with the intent of
(i) revealing defects, and
(ii) evaluating quality.

27. Software Testing Principles
Principle 2
When the test objective is to detect defects, then a good test case is one that has a high
probability of revealing a yet undetected defect(s).
Principle 3
Test results should be inspected meticulously.

28. Software Testing Principles
Principle 4
A test case must contain the expected output or result.
Principle 5
Test cases should be developed for both valid and invalid input conditions.
Principle 6
The probability of the existence of additional defects in a software component is
proportional to the number of defects already detected in that component.

29. Software Testing Principles
Principle 7
Testing should be carried out by a group that is independent of the
development group.
Principle 8
Tests must be repeatable and reusable.
Principle 9
Testing should be planned.

30. Software Testing Principles
Principle 10
Testing activities should be integrated into the software life cycle.
Principle 11
Testing is a creative and challenging task

31. Difficulties And Challenges For The
Tester
• A tester needs to have comprehensive knowledge of the software
engineering discipline.
• A tester needs to have knowledge from both experience and education as
to how software is specified, designed, and developed.
• A tester needs to be able to manage many details.

32. Difficulties And Challenges For The
Tester
• A tester needs to have knowledge of fault types and where faults of a
certain type might occur in code constructs.
• A tester needs to reason like a scientist and propose hypotheses that
relate to presence of specific types of defects.
• A tester needs to have a good grasp of the problem domain of the
software that he/she is testing. Familiarly with a domain may come from
educational, training, and work-related experiences.

33. The Tester’s Role In A Software
Development Organization
•The tester’s job is to
•Reveal defects,
•Find weak points,
•Inconsistent behaviour,

34. The Tester’s Role In A Software
Development Organization
• The tester’s job is to identify:
• Circumstances where the software does not work as expected.
• It is difficult for developers to effectively test their own code. A tester needs very
good programming experience in order to understand how code is constructed, and
to know where and what types of, defects could occur.
• A tester should work with the developers to produce high-quality software that
meets the customers’ requirements.

35. ORIGINS OF DEFECTS
• Defects have detrimental affects on software users, and software engineers work very
hard to produce high-quality software with a low number of defects.
1. Education
2. Communication
3. Oversight
4. Transcription
5. Process

36. ORIGINS OF DEFECTS

37. FAULT MODEL
• A fault (defect) model can be described as a link between the error made (e.g., a
missing requirement, a misunderstood design element, a typographical error), and the
fault/defect in the software.
• In the past, fault models and fault lists have often been used by developers/ testers in
an informal manner, since many organizations did not save or catalog defect-related
information in an easily accessible form.
• To increase the effectiveness of their testing and debugging processes, software
organizations need to initiate the creation of a defect database, or defect repository.

38. COST OF DEFECTS
• The cost of defects can be measured by the impact of the defects and when we find
them.
• Earlier the defect is found lesser is the cost of defect.
• For example if error is found in the requirement specifications during requirements
gathering and analysis, then it is somewhat cheap to fix it.
• The correction to the requirement specification can be done and then it can be re-
issued.

39. DEFECT CLASSES
• Defects can be classified in many ways.
• The four classes of defects are as follows,
• Requirements and specifications defects,
• Design defects,
• Code defects,
• Testing defects

40. 1. Requirements and Specifications Defects
• Defects injected in early phases can be very difficult to remove in
later phases.
• Since many requirements documents are written using a natural
language representation, they may become
• Ambiguous,
• Contradictory,
• Unclear,
• Redundant,
• Imprecise.

41. 1. Requirements and Specifications Defects
• 1.1 Functional Description Defects
• 1.2 Feature Defects
• 1.3 Feature Interaction Defects
• 1.4 Interface Description Defects

42. 2. Design Defects
•Design defects occur when the following are
incorrectly designed,
• System components,
• Interactions between system components,
• Interactions between the components and outside
software/hardware, or users

43. 2. Design Defects
• 2.1 Algorithmic and Processing Defects
• 2.2 Control, Logic, and Sequence Defects
• 2.3 Data Defects
• 2.4 Module Interface Description Defects
• 2.5 Functional Description Defects
• 2.6 External Interface Description Defects

44. 3. Coding Defects
• Coding defects are derived from errors in implementing the code.
• Coding defects classes are similar to design defect classes.
• Some coding defects come from a failure to understand
programming language constructs, and miscommunication with
the designers.

45. 3. Coding Defects
• 3.1 Algorithmic and Processing Defects
• 3.2 Control, Logic and Sequence Defects
• 3.3 Typographical Defects
• 3.4 Initialization Defects

46. 3. Coding Defects
• 3.5 Data-Flow Defects
• 3.6 Data Defects
• 3.7 Module Interface Defects
• 3.8 Code Documentation Defects
• 3.9 External Hardware, Software Interfaces Defects

47. 4. Testing Defects
• Test plans, test cases, test harnesses, and test procedures can also
contain defects. These defects are called testing defects.
• Defects in test plans are best detected using review techniques.
• 4.1 Test Harness Defects
4.2 Test Case Design and Test Procedure Defects

48. DEFECT CLASSES & DEFECT REPOSITORY

49. DEFECT REPOSITORY
• The defect repository concept supports storage and retrieval of defect data
from all projects in a centrally accessible location.
• Defect classification scheme is a necessary first step for developing the
repository.
• Defects found both during reviews and execution-based testing should be
cataloged.
• Supplementary information can be added to the defect repository, Staff
members can use this data for test planning, test design, and fault/defect
diagnosis

50. Developer/Tester Support for Developing a
Defect Repository
• Software engineers and test specialists should follow the examples of
engineers in other disciplines who make use of defect data.
• A requirement for repository development should be a part of testing and/or
debugging policy statements.
• Forms and templates should be designed to collect the data. Each defect and
frequency of occurrence must be recorded after testing.
• Defect monitoring should be done for each on-going project. The distribution
of defects will change when changes are made to the process.

51. Developer/Tester Support for Developing a
Defect Repository

52. Developer/Tester Support for Developing a
Defect Repository
• The defect data is useful for test planning.
• It is a TMM level 2 maturity goal.
• It helps a tester to select applicable testing techniques, design the test cases,
and allocate the amount of resources needed to detect and remove defects.
• This allows tester to estimate testing schedules and costs.

53. Developer/Tester Support for Developing a
Defect Repository
• The defect data can support debugging activities also.
• A defect repository can help in implementing several TMM maturity goals
including
• Controlling and monitoring of test,
• Software quality evaluation and control,
• Test measurement,
• Test process improvement.

54. Defect Examples: Coin Problem
• This program calculates the total rupees value for a set of coins. The
user inputs the amount of 25p, 50p and 1rs coins. There are size
different denominations of coins. The program outputs the total
rupees and paise value of the coins to the user
• Input : number_of_coins is an integer
• Output : number_of_rupees is an integer
• number_of_paise is an integer

55. Thank You….