PANIMALAR INSTITUTE OF TECHNOLOGY

(JAISAKTHI EDUCATIONAL TRUST)

CHENNAI 6000 123

DEPARTMENT OF IT
(Accredited to National Board of Accreditation)

IT8076 SOFTWARE TESTING

III YEAR – VI SEMESTER

UNIT - 1

IT6004 – SOFTWARE TESTING DEPARTMENT OF IT Page 1

 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 Support of
Developing a Defect Repository.

TESTING AS AN ENGINEERING ACTIVITY

Poor quality software that can cause loss of life or property is no longer
acceptable to society. Failures can result in catastrophic losses. Conditions demand
software development staff with interest and training in the areas of software
products and process quality.

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 ability to meet all user requirements.

In response to the demand for high quality software, and the need for well
educated software professionals, there is a movement to change the way software is
developed and maintained. The profession of software engineering is slowly
emerging as a formal engineering discipline.

The education and training of engineers in each engineering discipline is

based on the teaching of related scientific principles, engineering processes,
standards, methods, tools, measurements and the best practices as given in the figure
below.

The software development should be viewed and taught as an engineering

discipline. Quality is of prime importance in both the process and the product. Using
an Engineering approach to software development implies that:

 The development process is well understood

 projects are planned
 life cycle models are defined and adhered to
 standards are in place for products and process
 measurements are employed to evaluate products and process quality
 Components are reused.
 Validation and verification processes play a key role in quality determination
 Engineers have proper education, training and certification

IT6004 – SOFTWARE TESTING DEPARTMENT OF IT Page 2

 Fig. 1.1 Elements of the Engineering Disciplines

 A test specialist is one whose education is based on the principles, practices and
processes that constitute the software engineering discipline, and whose specific
focus is on one area of that discipline – software testing.

 A test specialist who is trained as an engineer should have knowledge of test related
principles, processes, measurements, standards, plans, tools and methods, and
should learn how to apply them to the testing tasks to be performed.

IT6004 – SOFTWARE TESTING DEPARTMENT OF IT Page 3

PANIMALAR INSTITUTE OF TECHNOLOGY DEPT OF IT

TESTING AS A PROCESS:

Process has been described as a series of phases, procedures, and steps that result
in the production of a software product. Embedded within this are several processes and
one such process is testing.

Testing itself consists of two processes. They are Verification and Validation.

Fig. 1.3 – Example Processes embedded in the software development

Process

Validation is the process of evaluating a software system or components during

or atthe end of, the development cycle in order to determine whether it satisfies
specified requirements.Validation is usually associated with traditional execution based
testing that is exercising the code with test cases

Verification is the process of evaluating a software system or component

todetermine whether the products of a given development phase satisfy the conditions
imposed at the start of that phase.Verification is usually associated with activities such
as inspections and reviews of software deliverables.

Verification Validation
1. Verification addresses the concern: "Are 1. Validation addresses the concern: "Are
you building it right?" you building the right thing?"
Verification is a static practice of verifying Validation is a dynamic mechanism of
documents, design, code and program. validating and testing the actual product.
2. It does not involve executing the code. 2. It always involves executing the code.
3. It is human based checking of 3. It is computer based execution of
documents and files. program.
4. Verification uses methods like 4. Validation uses methods like black box
inspections, reviews, walkthroughs, and (functional) testing, gray box testing, and

III/VI SEM 4
 PANIMALAR INSTITUTE OF TECHNOLOGY DEPT OF IT

Desk-checking etc. white box (structural) testing etc.

5. Validation is to check whether software
5. Verification is to check whether the
meets the customer expectations and
software conforms to specifications.
requirements.
6. It can catch errors that validation 6. It can catch errors that verification
cannot catch. It is low level exercise. cannot catch. It is High Level Exercise.
7. Target is requirements specification,
7. Target is actual product-a unit, a module,
application and software architecture, high
a bent of integrated modules, and effective
level, complete design, and database
final product.
design etc.
8. Verification is done by QA team to
8. Validation is carried out with the
ensure that the software is as per the
involvement of testing team.
specifications in the SRS document.
9. It generally comes first-done before
9. It generally follows after verification.
validation.

Definitions of Testing:
1. Testing is generally described as a process as a group of procedures carried

out toevaluate some aspects of a piece of software.

2. Testing can be described as a process used for revealing defects in software,

and establishing that the software has attained a specified degree of quality

with respect to selected attributes. Testing is a dual-purpose process – one

that reveals defects, and the other one to evaluate quality attributes of the

software such as reliability, security, usability and correctness.

Testing and Debugging are two different activities.

Debugging process begins after testing has been carried out and the tester has
notedthat the software is not behaving as specified.

Debugging or Fault Localization is the process of

(1) Locating the fault or defect

(2) Repairing the code, and
(3) Retesting the code

Testing as a process has economic, technical and managerial aspects.

III/VI SEM 5
PANIMALAR INSTITUTE OF TECHNOLOGY DEPT OF IT

 Economic aspects are related to the reality that resources and time
areavailable to the testing group on a limited basis

 Technical Aspect of testing relate to the techniques, methods,

measurements,and tools used to insure that the software under test is a defect free and
reliable for the conditions and constraints under which it must operate.

 Managerial Aspect – The organizational policy for testing must be

definedand documented. Testing must be planned, testers should be trained, the process

should have associated quantifiable goals that can be measured and monitored.

TESTING MATURITY MODEL

TMM is based on the Capability Maturity Model (CMM), and it was first
developed by the Illinois Institute of Technology.

Full form of TMM is Test Maturity Model.

It is a detailed model for test process improvement.

It can be complemented with any process improvement model or can be used as a

STAND ALONE model.

Different Levels of Maturity Model

The five levels of the TMM helps the organization to determine the maturity of its
process and to identify the next improvement steps that are essential to achieving a
higher level of test maturity.

III/VI SEM 6
PANIMALAR INSTITUTE OF TECHNOLOGY DEPT OF IT

III/VI SEM 7
 PANIMALAR INSTITUTE OF TECHNOLOGY DEPT OF IT

TMM Levels Goals An objective of TMM levels

Level 1: Initial Software should run  At this level, no process areas are identified
successfully  An objective of testing is to ensure that
software is working fine
 This level lacks resources, tools, and trained
staff
 No Quality Assurance checks before software
delivery

Level 2: Defined Develop testing and  This level distinguish testing from debugging &
debugging goals and they are considered distinct activities
policies  Testing phase comes after coding
 A primary goal of testing is to show software
meets specification
 Basic testing methods and techniques are in
place

Level 3: Integrated Integration of testing into  Testing gets integrated into an entire life cycle
the software lifecycle  Based on requirements test objectives are
defined
 Test organization exists
 Testing recognized as a professional activity

Level 4: Management Establish a test  Testing is a measured and quantified process

and Measurement measurement program  Review at all development phases are
recognized as tests
 For reuse and Regression Testing, test cases are
gathered and recorded in a test database
 Defects are logged and given severity levels

Level 5: Optimized Test process optimization  Testing is managed and defined

 Testing effectiveness and costs can be
monitored
 Testing can be fine-tuned and continuously
improved
 Quality control and Defect prevention are
practiced

III/VI SEM 8
 PANIMALAR INSTITUTE OF TECHNOLOGY DEPT OF IT

 Process reuse is practiced

 Test related metrics also have tool support
 Tools provide support for Test Case design and
defect collection

Difference between CMM & TMM

CMM TMM

 CMM or Capability Maturity Model is for  TMM or Test Maturity Model describes the
judging the maturity of the software process of testing and is related to monitoring the
processes of an organization quality of software testing model

The internal structure of TMM maturity levels

TESTING AXIOMS

Axioms: “rules of the road” or the “facts of life” for software testing and software
III/VI SEM 9
PANIMALAR INSTITUTE OF TECHNOLOGY DEPT OF IT

development.
1. It’sImpossibletoTestaProgramCompletely
2. Software Testing Is a Risk-BasedExercise
3. TestingCan’tShowThatBugsDon’tExist
4. The More Bugs You Find, the MoreBugs There Are
5. The PesticideParadox
6. Not All the Bugs You Find Will BeFixed
7. WhenaBug’saBugIsDifficulttoSay
8. Product Specifications Are NeverFinal
9. SoftwareTestersAren’ttheMostPopularMembersofaProjectTeam
10. Software Testing Is a Disciplined TechnicalProfession

1. It’s Impossible to Test a Program Completely

due to four key reasons:
 The number of possible inputs is very large.
 The number of possible outputs is very large.
 The number of paths through the software is very large.
 The software specification is subjective

Ex: Microsoft Windows Calculator

Assume that you are assigned to test the Windows Calculator. You decide to start
with addition. You try 1+0=. You get an answer of 1. That’s correct. Then you try
1+1=. You get 2. How far do you go? The calculator accepts a 32-digit number, so you
must try all the possibilities up to
1+99999999999999999999999999999999=
Once you complete that series, you can move on to 2+0=, 2+1=, 2+2=, and so on.
Eventually you’ll get to
99999999999999999999999999999999+99999999999999999999999999999999=
Next you should try all the decimal values: 1.0+0.1, 1.0+0.2, and so on.

it’s impossible to completely test a program, even software as simple as a

calculator. If you decide to eliminate any of the test conditions because you feel they’re
redundant or unnecessary, or just to save time, you’ve decided not to test the program
completely.

2. Software Testing Is a Risk-Based Exercise

One key concept that software testers need to learn is how to reduce the huge domain of
III/VI SEM 10
PANIMALAR INSTITUTE OF TECHNOLOGY DEPT OF IT

possible tests into a manageable set, and how to make wise risk-based decisions on
what’s important to test and what’s not.

Above graph shows the relationship between the amount of testing performed and the
number of bugs found. If you attempt to test everything, the costs go up dramatically
and the number of missed bugs declines to the point that it’s no longer cost effective to
continue.
If you cut the testing short or make poor decisions of what to test, the costs are low but
you’ll miss a lot of bugs. The goal is to hit that optimal amount of testing so that you
don’t test too much or too little.

3.Testing Can’t Show That Bugs Don’t Exist

You’re an exterminator charged with examining a house for bugs. You inspect the house
and find evidence of bugs
House1 :
Findings :—maybe live bugs, dead bugs, or nests. Conclusion :- You can safely say that
the house has bugs.

House2 :
Findings :- no evidence of bugs. no signs of an infestation.
Maybe you find a few dead bugs or old nests but you see nothing that tells you that live
bugs exist.

Conclusion : your search you didn’t find any live bugs. Unless you completely
dismantled the house down to the foundation, you can’t be sure that you didn’t simply
just miss them.
Software testing works exactly as the exterminator does. It can show that bugs exist,
but it can’t show that bugs don’t exist. You can perform your tests, find and report
bugs, but at no point can you guarantee that there are no longer any bugs to find.

4. The More Bugs You Find, the More Bugs There Are
Reasons
III/VI SEM 11
PANIMALAR INSTITUTE OF TECHNOLOGY DEPT OF IT

 Programmers have bad days. Like all of us, programmers can have off days. Code
written one day may be perfect; code written another may be sloppy.
 Programmers often make the same mistake. Everyone has habits. A programmer
who is prone to a certain error will often repeat it.
 Some bugs are really just the tip of the iceberg. Very often the software’s design
or architecture has a fundamental problem. A tester will find several bugs that at
first may seem unrelated but eventually are discovered to have one primary
serious cause.

5. The Pesticide Paradox

The test process repeats each time around the loop. With each iteration, the software
testers receive the software for testing and run their tests. Eventually, after several
passes, all the bugs that those tests would find are exposed. Continuing to run them
won’t reveal anything new.
To overcome the pesticide paradox, software testers must continually write new
and different tests to exercise different parts of the program and find more bugs.

6. Not All the Bugs You Find Will Be Fixed

reasons why you might choose not to fix a bug:
 There’s not enough time. In every project there are always too many software
features, too few people to code and test them, and not enough room left in the
schedule to finish. If you’re working on a tax preparation program, April 15 isn’t
going to move—you must have your software ready in time.
 It’s really not a bug. Maybe you’ve heard the phrase, “It’s not a bug, it’s a feature!”
It’s not uncommon for misunderstandings, test errors, or spec changes to result
in would-be bugs being dismissed as features.
 It’s too risky to fix. You might make a bug fix that causes other bugs to appear.
Under the pressure to release a product under a tight schedule, it might be too
risky to change the software. It may be better to leave in the known bug to avoid
the risk of creating new, unknown ones.
 It’s just not worth it. This may sound harsh, but it’s reality. Bugs that would occur
infrequently or bugs that appear in little-used features may be dismissed.

7. When a Bug’s a Bug Is Difficult to Say

rules to define a bug

III/VI SEM 12
PANIMALAR INSTITUTE OF TECHNOLOGY DEPT OF IT

 The software doesn’t do something that the product specification says it should
do.
 The software does something that the product specification says it shouldn’t do.
 The software does something that the product specification doesn’t mention.
 The software doesn’t do something that the product specification doesn’t mention
but should.
 The software is difficult to understand, hard to use, slow, or—in the software
tester’s eyes—will be viewed by the end user as just plain not right.

8. Product Specifications Are Never Final

You’re halfway through the planned twoyear development cycle, and your main
competitor releases a product very similar to yours but with several desirable features
that your product doesn’t have.
 Do you continue with your spec as is and release an inferior product in another
year?
 Or, does your team regroup, rethink the product’s features, rewrite the product
spec, and work on a revised product?

9. Software Testers Aren’t the Most Popular Members of a Project Team

The goal of a software tester is to find bugs, find them as early as possible, and make
sure they get fixed.
 Find bugs early.
 Temper your enthusiasm
 Don’t always report bad news

10. Software Testing Is a Disciplined Technical Profession

 If software testers were used, they were frequently untrained and brought into
the project late to do some “ad-hoc banging on the code to see what they might find.”
Times have changed.
 The software industry has progressed to the point where professional software
testers are mandatory. It’s now too costly to build bad software.

TESTING FUNDAMENTALS:

Basic Definitions:

1. Error:
An Error is a mistake, misconception, or misunderstanding on the part ofsoftware
developers.

2. Faults:
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 as “bugs”.

III/VI SEM 13
PANIMALAR INSTITUTE OF TECHNOLOGY DEPT OF IT

3. Failures:
A failure is the inability of a software or component to perform its required functions
within specified performance requirements.A Fault in the code does not always produce
a failure. In fact, faulty software may operate over a long period of time without
exhibiting any incorrect behavior. When the proper conditions occur the fault will
manifest itself as a failure. The conditions are:

1. The input to the software must cause the faulty statements to be executed.
2. The faulty statements must produce different results than the correct statements.
3. The incorrect internal state must propagate to the output, so that the result of the
fault is observable

4. Test Cases:

The tester has to select a set of input data and then execute the software with the input
data under a particular set of conditions to detect defects. The tester has to know the
proper output for the given input in order to check whether the software has passed the
test or not.

A test case is a test related item which contains the following information:-

 A set of test inputs :-These are data items received from an external sourceby
the code under test. The external source can be hardware, software or human.
 Execution Condition:-These are conditions required for running the test,
for example , a certain state of database, or a configuration of hardware devices.
 Expected Outputs:-These are the specified results to be produced by thecode
under test
5. Test :
A test is a group of related test cases, or a group of related test cases and test
procedures (steps needed to carry out a test)
A group of related tests is sometimes referred to as a test set. A group of related tests
that are associated with the database, and are usually run together is sometimes referred
to as test suite.

6. 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.
A program, or a document that produces or specifies the expected outcome ofa test, can
serve as an oracle. Example include a specification, design documents, set of
requirements.Other sources are regression test suites. The suite usually contains
components with correct results for previous versions of software.

7. Test Bed:
A test bed is an environment that contains all the hardware and software
needed to test a software components or a software system.

III/VI SEM 14
PANIMALAR INSTITUTE OF TECHNOLOGY DEPT OF IT

This include testing environment, eg:- simulators, emulators memory checkers,

hardware probes, software tools etc

8. Software Quality :

Two concise definition for quality are found in the IEEE standards Glossary
of SoftwareEngg Terminology
a. Quality relates to the degree to which a system, system component, or process
meets specified requirements

b. Quality relates to the degree to which a system, system components , or process

meets customer or user needs, or expectations

9. Metrics:
A metrics is a quantitative measure of the degree to which a system, system
component or process possesses a given attribute. There are product and process
metrics. A very commonly used example software products metrics is software size,
usually measured in Lines Of Code (LOC)

10. Quality Metrics:

It is a quantitative measurement of the degree to which an Item possesses a
given quality attribute.

Examples of quality attributes are:

i. Correctness :- the degree to which the system performs its intended function
ii. Reliability :- the degree to which the software is expected to perform its
requiredfunction under stated conditions for a stated period of time

iii. Usability :-related to the degree of effort needed to learn , operate, prepare
input,and interpret output of the software.

iv. Integrity:- Relates to the systems ability to withstand both intentional

andaccidental attacks

v. Portability:-Relates to the ability of the software to be transferred from

oneenvironment to another.
vi. Maintainability:- the effort needed to make change in the software

vii. Interoperability: - the effort needed to link or couple one system to another.

viii. Testability attribute is of more interest to developers/testers than to clients.

It canbe expressed in the following two ways:

a) The amount of effort needed to test the software to ensure it performs according
III/VI SEM 15
PANIMALAR INSTITUTE OF TECHNOLOGY DEPT OF IT

tospecified requirements (relates the number of test cases needed)

b) The ability of the software to reveal defects under testing conditions (some s/w is
designed in such a way that defects are well hidden during ordinary testing
conditions)

11. Software Quality Assurance Group:-

The Software Quality Assurance group (SQA) is a team of people with the necessary
training and skills to ensure that all necessary actions are taken during the development
process so that the resulting software conforms to established technical requirements.

They work with project managers and testers to develop quality-related policies and
quality assurance plans for each project.

12.Reviews:-
Review are types of static testing techniques that can be used to evaluate the quality
of the software artifacts such as requirement document , a test plan, a design
document ,a code component. Reviews are also a tool that can be applied to revealing
defects in these types of documents.

Definition:
A review is a group meeting whose purpose is to evaluate a software
artifact or a set of software artifacts.

SOFTWARE TESTING PRINCIPLES

Principles play an important role in all engineering disciplines and are usually
introduced as a part of an educational background in each branch of Engineering.

Testing Principles are important to test specialists/ Engineers because they provide the
foundation for developing testing knowledge and acquiring skills.

They also provide guidance for defining testing activities as performed in the practice of
a test specialist.

A principle can be defined as

1. A general or fundamental , law, doctrine, or assumptions;

2. A rule of code of conduct;
3. The laws or facts of nature underlying the working of an artificial device.

There are totally 11 principles for software testing

III/VI SEM 16
 PANIMALAR INSTITUTE OF TECHNOLOGY DEPT OF IT

Principle 1: Testing is the process of exercising a software components

using aselected set of test cases, with the intent of
(i) Revealing Defects
(ii) Evaluating Quality

Principle 2: When the test objectives is to detect defects, then a good test case
is onethat has a high probability of revealing a yet-undetected defect(s).

Principle 3:- Test results should be inspected meticulously

Principle 4:- A test case must contain the expected output or result.

III/VI SEM 17
PANIMALAR INSTITUTE OF TECHNOLOGY DEPT OF IT

Principle 5:- Test case should be developed for both valid and invalid input
conditions.

Principle 6:- The probability of the existence of additional defects in a

softwarecomponent is proportional to the number of defects already
detected in that component.

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

III/VI SEM 18
PANIMALAR INSTITUTE OF TECHNOLOGY DEPT OF IT

Principle 9:- Testing should be planned

Principle 10:- Testing activities should be integrated into the software.

Principle 11:- Testing is a creative and challenging task.

III/VI SEM 19
PANIMALAR INSTITUTE OF TECHNOLOGY DEPT OF IT

III/VI SEM 20
PANIMALAR INSTITUTE OF TECHNOLOGY DEPT OF IT

THE TESTER’S ROLE IN A SOFTWARE DEVELOPMENT ORGANIZATION:-

III/VI SEM 21
 PANIMALAR INSTITUTE OF TECHNOLOGY DEPT OF IT

ORIGINS OF DEFECTS

Defects have detrimental(negative) effects on software users and software engineers

work very hard to produce high quality software with a low numbers of defects. The
origins of defects are given below:

ORIGINS OF DEFECTS

1. Education: The software engineer did not have the proper educational background
toprepare the software artifacts. They did not understand how to do something. For
example, a software engineer who did not understand the precedence order of operators
III/VI SEM 22
 PANIMALAR INSTITUTE OF TECHNOLOGY DEPT OF IT

in a particular programming language could inject a defect in an equation that uses the
operators for calculation.

2. Communication:-The software engineer was not informed abut something by

acolleague. For example , if engineer 1 and engineer2 working on interfacing modules,
and engineer 1 doesn’t inform engineer2 that no error checking code will appear in the
interfacing module he is developing, engineer 2 might have an incorrect assumption
relating to the presence /absence of an error check and defects will result.

3. Oversight :- The software engineer omitted to do something .For example a

softwareengineer might omit an initialization statement

4. Transcription:- The software engineer knows what to do, but makes a mistake
indoing it. A simple example is a variable name being misspelled when entering the
code.

5. Process:- The process used by the software engineer misdirected the action.
Forexample, a development process that did not allow sufficient time for a detailed
specification to be developed and reviewed could lead to specification defects.

A successful test is a one that reveals the presence of defect. A tester role is
compared with the role of a doctor. A doctor who is in the process of constructing a
diagnosis for an ill patient, develops hypotheses about possible illness using her
knowledge of possible diseases, and the patients symptoms. Tests are made in order to
make the correct diagnosis. A successful text will reveal the problem and the doctor can
begin the treatment. Completing the analogy of doctor and ill patient, one could view
defective software as the ill patient. Testers as doctors need to have knowledge about
possible defects (illness) in order tom develop defect hypotheses. They use the
hypotheses to:-

 Design Test cases;

 Design Test procedures;
 Assemble test sets;
 Select the testing levels(unit, integration,etc) appropriate for the tests;
 Evaluate the result of the tests;

Very useful concept related to defects, testing, and diagnosis is that of the fault
model. A fault (defect) model can be described as a link between the error made (eg., a
missing requirement, a misunderstood design elements, a typographical error) and the
fault/ defect in the software.

Example of fault model a software engineer might have in memory is “an incorrect
value for a variable was observed because the precedence order for the arithmetic
operators used to calculate its value was incorrect”  this could be called as “incorrect
operator precedence operator”.

III/VI SEM 23
PANIMALAR INSTITUTE OF TECHNOLOGY DEPT OF IT

DEFECT CLASSES:-

Defect can be classified in many ways. It is important for an organization to adapt a

single classification scheme and apply it to all projects. Developers, testers and SQA staff
should try to be as consistent as possible when recording defect data.
Defects are assigned to four major classes reflecting their point of origin in the
software life cycle- the development phases in which they were injected. These classes
are:-
o Requirements\ Specification Defect Classes
o Design Defect Classes
o Code Defect Classes
o Testing Defect Classes

III/VI SEM 24
 PANIMALAR INSTITUTE OF TECHNOLOGY DEPT OF IT

Requirements and Specification Defects:-

The beginning of software life cycle is critical for ensuring high quality in the
software being developed. Defects injects in early phases can persist and be very difficult
to remove in later phases.

Since many requirements are written using natural language representation, there are
very often occurrences of ambiguous, contradictory, unclear, redundant, and imprecise
requirements.

Some specific requirements/specification defects are:

1.Functional Description Defects:-

The overall description of what the product does, and how it should behave
(Input/Output), is incorrect, ambiguous, and /or incomplete.

2.Feature Defects

Features may be described as distinguishing characteristics of a software component or

system. Features refers to functional aspects of software that map to functional
requirement described by the user and the client, it also maps quality such as
performance and reliability. Feature defects are mainly due to features description that
are missing, incorrect, incomplete or superfluous.

3.Feature Interaction Defects:-

These defects are due to incorrect description of how the features should interact. For
ex:- suppose one feature of a software system supports adding a new customer to a
customer database. This feature interacts with another feature that categorizes the new
customer. Classification feature impacts on where the storage algorithm places the new
customer in the database, and also affects another feature that periodically support
sending advertising information to customers in a specific category.

4.Interface Description Defects:-

These are defects that occur in the description of how the target software is to interface
with external software, hardware and users.

For detecting many functional description defects, black box testing techniques, which
are based on functional specification of the software, offer the best approach. Black Box
testing techniques such as equivalence class partitioning, boundary value analysis, state
transition testing, and cause and effect graphing are useful for detecting functional type
of defects.
III/VI SEM 25
 PANIMALAR INSTITUTE OF TECHNOLOGY DEPT OF IT

BlackBox based tests can be planned at the unit, integration, system and acceptance
levels to detect requirements/specification defects.

DESIGN DEFECTS:-

Design defects occur when system components, interactions between system

components, interaction between the components and outside software /hardware, or
users are incorrectly designed. Design of algorithm, control, logic, data elements,
module interface description, and external software/ hardware/ user interface
description. When describing these defects we assume that the detailed design
description for the software modules is the pseudo code level with processing steps

1. Algorithmic and Processing Defects:-

These occur when the processing steps in the algorithm as described by the pseudo code
are incorrect. Eg:- the pseudo code may contain a calculation that is incorrectly
specified, or the processing steps in the algorithm written in pseudo code language may
not be in the correct order.

2. Control, Logic and Sequence Defects:-

Control defect occur when logic flow in the pseudo code is not correct. For example,
branching to soon, branching to late, or use of an incorrect branching, condition. Other
examples in this subclasses are unreachable pseudo code elements, improper nesting,
improper procedure or function calls. Logic defects usually relate to incorrect use of
logic operators.

3. Data Defects:-

These are associated with incorrect design of data structures. For example a record may
be lacking a field, an incorrect type is assigned to a variable or field in a record, an array
may not have the proper number of elements assigned, or storage space may be
allocated incorrectly.

4. Module Interface Description Defects :-

These are defects derived from, for example, using incorrect, and/or inconsistent
parameter type, an incorrect number of parameters, or an incorrect ordering of
parameters

5. Functional Description Defects:-

The defects in this category include incorrect, missing, and/or unclear design element.
For example, the design may not properly describe the correct functionality of a module.

III/VI SEM 26
 PANIMALAR INSTITUTE OF TECHNOLOGY DEPT OF IT

6. External Interface Description Defects:-

These are derived from incorrect design description for interfaces with COTS
components, external software systems, databases and hardware devices(eg:-I/O
devices). Other example are user interface description defects where there are missing
or improper commands, improper sequence of commands, lack of proper message,
and/or lack of feedback message for the users.

CODING DEFECTS:-

Coding Defects are derived from errors in implementing the code. Coding defects
classes are closely related to design classes especially if pseudo code has been used for
detailed design. Some coding defects come from a failure to understand programming
language constructs, and miscommunication with the designer.

1. Algorithm and Processing Defects:-

Adding levels of programming detail to design , code related algorithmic and processing
defect would now include unchecked overflow and underflow conditions, comparing
inappropriate data types, converting one data type to another, in correct ordering of
arithmetic operators, misuse or omission of parenthesis, precision loss and incorrect use
of signs.

2. Control, Logic and Sequence Defects :-

On the coding level these would include incorrect expression of case statements,
incorrect iteration of loops and missing paths

3. Typographical Defects:-

These are principally syntax errors, for example incorrect spelling of variable name, that
are usually detected by compiler, self reviews, or peer reviews

4. Initialization Defects:-

These occur when initialization statements are omitted or are incorrect. This may occur
because of misunderstanding or lack of communication between programmers, and /or
programmers and designers, carelessness, or misunderstanding of programming
environment.

5. Data Flow Defects:-

There are certain reasonable operational sequences that data should flow through. For
example a variable should be initialized, before it is used in a calculation or in
acondition. It should not be initialized twice before there is an intermediate use. A
III/VI SEM 27
 PANIMALAR INSTITUTE OF TECHNOLOGY DEPT OF IT

variable should not be disregarded before it is used.

6. Data Defects :-

These are indicated by incorrect implementation of data structures. For example, the
programmer may omit a filed in a record, an incorrect type or access is assigned to a file,
an array may not be allocated the proper number of elements.

7. Module Interface Defects:-

As in the case of module design elements, interface defects in the code may be due to using
incorrect or inconsistent parameter types, an incorrect number of parameters, or
improper ordering of the parameters, improper design, programmer may implement an
incorrect sequence of calls or calls to non existent modules

8. External Hardware, Software Interface Defects:-

These defects arise from problems related to system calls, links to databases, input/output
sequences, memory usage, resource usage, interrupts and exception handling, data
exchange with hardware, protocols formats, interface with build files, and timing
sequences

TESTING DEFECTS:

Defects are not confined to code and its related artifacts. Test plans, test cases,
test harnesses, and test procedures can also contain defects. Defects in test plans are
best detected using review techniques.

1. Test Harness Defect:-

In order to test software, especially at the unit and integration levels, auxiliary code
must be developed. This is called the test harness or scaffolding code. Test harness code
should be carefully designed, implements and tested since it is a work product and much
of this code can be reused when the new release of the software are developed.

2. Test Case Design and Test Procedure Defects:-

These would encompass incorrect, incomplete, missing, inappropriate test cases, and
test procedures. These defects are again best detected in test plan reviews. Sometimes,
Defects are revealed during the testing process itself by means of a careful analysis of
test conditions and test results. Repairs will then have to be made.

III/VI SEM 28
PANIMALAR INSTITUTE OF TECHNOLOGY DEPT OF IT

DEFECT EXAMPLES:-THE COIN PROBLEM

The following example illustrates some instance of the defect classes. A simple
specification, a detailed design description and the resulting code are shown and defects
in each are described. These defects could be injected via one or more defect sources.

The fig 1.6 show the sample informal specification for a simple program that calculates
the total monetary value of a set of coins. The program could be a component of an
incentive cash register system to support retail store clerks. This simple example shows
requirements/ specifications defects, functional descriptions defects and interface
description defects.

A SAMPLE SPECIFICAITON WITH DEFECTS is given

The Functional Description defects arise because the functional description is

ambiguous and incomplete .It does not state that the input, number_of_coins, and the
output, number_of_ dollars and number_of_cents, should all have values of zero or
greater.

The number _of_coins cannot be negative and the values in dollars and cents cannot be
negative in the real world domain .

Formally stated set of preconditions and post conditions would be helpful, and
would address some of the problem with the specification. These are also useful for
designing black box tests.

A precondition is a condition that must be true in order for a

III/VI SEM 29
PANIMALAR INSTITUTE OF TECHNOLOGY DEPT OF IT

software
component to operate properly.

In this case a useful precondition would be one that states for example ,

Number_of_coins>=0

A Post condition is a condition that must be true when a software

component

completes its operation properly.

A useful post condition would be :-

Number_of _dollars, number_of_cents>=0

Interface Description defects relates to the ambiguous and incomplete description

ofuser software interaction. It is not clear from the specification how the user interacts
with the program to provide input and how the output is to be reported. Because of
ambiguities in the user interaction description the software may be difficult to use.

The below figure shows the specification transformed into a design description. There
are numerous design defects, some due to the ambiguous and incomplete nature of the
specifications.

III/VI SEM 30
PANIMALAR INSTITUTE OF TECHNOLOGY DEPT OF IT

Design defects include the following:

Control, Logic and Sequencing Defects:-

The defect in this subclass arises from an incorrect “while” loop condition(should be
less than or equal to six)

Algorithmic and Processing Defects:-

These arise from the lack of error checks for incorrect and /or invalid inputs, lack of
III/VI SEM 31
PANIMALAR INSTITUTE OF TECHNOLOGY DEPT OF IT

path where users can correct erroneous inputs, lack of a path for recovery from input
errors. The lack of an error check could be counted as functional design defects since the
design does not adequately describe the proper functionality for the program.

Data Defects:-

This defect relates to an incorrect value for one of the elements of the integer array,
coin_values, which should read 1,5,10,25,50,100

External Interface Description Defects:-

These are defects arising from the absence of input messages or prompts that
introduced the program to the user and request inputs.

The user has no way of knowing in which order the number of coins for each
denomination must be input, and when to stop inputting values.

There is absence of help message and feedback for user if he wishes to change an input
or learn the correct format and order for inputting the number of coins.

The control and logic design defects are best addressed by white box based tests,
(condition/Branch testing, loop testing)

The program below is a C like programming language. Without effectives reviews the
specification and design defects could propagate to the code. Here additional defects
have introduced in the coding phase.

III/VI SEM 32
PANIMALAR INSTITUTE OF TECHNOLOGY DEPT OF IT

III/VI SEM 33
PANIMALAR INSTITUTE OF TECHNOLOGY DEPT OF IT

Control , Logic and Sequence Defects:-

These include the loop variable increment step which is out of the scope of the loop.
Note that incorrect loop condition(i<6) is carried over from design and should be
counted as a design defects

Algorithmic and Processing Defects:-

The division operator may cause problems if negative values are divided, although
this problem could be eliminated with an input check.

Data Flow Defects:-

The variable total_coin_value is not initialized. It is used before it is defined.

Data Defects:-

The error in initializing the array coin_values is carried over form design and should
be counted as design defect.

External Hardware, Software Interface Defects:-

The call to the external function “scanf” is incorrect. The address of the variable must
be provided (&number_of_coins)

Code Documentation Defects:-

The documentation that accompanies this code is incomplete and ambiguous. It

reflects the deficiencies in the external interface description and other defects that
occurred during the specification and design. Vital information is missing for anyone
who will need to repair, maintain or reuse this code.

The control, logic and sequence, data flow defects found in this sample could be
detected by combination of white and black box testing techniques.

Black Box tests may work well to reveal the algorithmic and data defects. the code
documentation defects require a code review for detection. The external software
interface defects would probably be caught by a good complier.

Poor quality of this small program is due to defects injected during several of the life
cycle phases with probable causes ranging from lack of education, a poor process, to
oversight on the part of the designers and developers.

We must catalog defects and try to eliminate them by improving education, training,
communication and process.

III/VI SEM 34
PANIMALAR INSTITUTE OF TECHNOLOGY DEPT OF IT

DEVELOPER/ TESTER SUPPORT FOR DEVELOPING A

DEFECTREPOSITORY

It is important if you are a member of a test organization to illustrate to

management and colleagues the benefit of developing a defect repository to store defect
information.

As Software Engineers and Test Specialists we should follow the example of engineers in
other disciplines who realized the usefulness of defect data.

A requirement for repository development should be a part of testing and/or debugging

policy statements.

Defect monitoring should continue for each ongoing project. The distribution of defects
will change as you make changes in your processes. The defect data is useful for
testplanning, a TMM level 2 maturity goals. It helps you to select applicable testing
techniques, design and the test cases you need and allocate the amount of resources you
will need to devote to detecting and removing these defects.

This in turn will allow you to estimate testing schedules and costs. The defect data can
support debugging activities as well.

THE DEFECT REPOSITORY, AND SUPPORT FOR TMM MATURITY

GOALS
III/VI SEM 35
PANIMALAR INSTITUTE OF TECHNOLOGY DEPT OF IT

As shown in the fig.1.9, a defect repository can help to support achievements and
continuous implementation of several TMM maturity goals including controlling and
monitoring of test, software quality evaluation and control , test measurements, and test
process improvement.

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. In the same way when defect or
error is found in the design during design review then the design can be corrected and it
can be re-issued. But if the error is not caught in the specifications and is not found till
the user acceptance then the cost to fix those errors or defects will be way too
expensive.
If the error is made and the consequent defect is detected in the requirements
phase then it is relatively cheap to fix it.
Similarly if a requirement specification error is made and the consequent defect
is found in the design phase then the design can be corrected and reissued with
relatively little expense.
The same applies for construction phase. If however, a defect is introduced in
the requirement specification and it is not detected until acceptance testing or even once
the system has been implemented then it will be much more expensive to fix. This is
because rework will be needed in the specification and design before changes can be
made in construction; because one defect in the requirements may well propagate into
several places in the design and code; and because all the testing work done-to that
point will need to be repeated in order to reach the confidence level in the software that
we require.
It is quite often the case that defects detected at a very late stage, depending on
how serious they are, are not corrected because the cost of doing so is too expensive.
Average cost to fix a defect = (Number of people * number of days) * cost per person-day

(Number of fixed defects)

III/VI SEM 36
PANIMALAR INSTITUTE OF TECHNOLOGY DEPT OF IT

DEFECT PREVENTION STRATEGIES

What is Defect Prevention?

Defect prevention is one of the important activity in any software project. It is QA
process to identify the root causes of defects and improve the process to avoid
introducing defects, which help to improve the quality of the software product.
In Defect prevention phase testers are involved in the studying and reviewing
requirement specification document. Basically this is an art to review the requirement
documents. While studying these documents testers run into different queries or
misleading or unclear requirements. Tester & other team member’s needs to come up
with such type of queries and get
resolved from stakeholders. So based on queries raised by team, stakeholder provide
inputs & provide changed/updated requirement specification document.
A quality process should produce close to zero - defect software that meets the
user requirements. In this article, we will go through step- by - step, the various
practices/techniques that can help you prevent defects in your software, and how to
catch them if they already exist.

Understanding Customer Requirements

When a customer provides you a requirement, it’s not that you start working on it
there and then (Figure 1, below). You first need to understand clearly what the customer
wants.
Once you have gone through the requirement, put down what you have
understood. Then, get your understanding confirmed from the customer. Doubts, if any,
in the requirement
specification, must be clarified at this stage. Do not procrastinate or hesitate in asking
your queries.

III/VI SEM 37
PANIMALAR INSTITUTE OF TECHNOLOGY DEPT OF IT

While working on the development of system software tools, I have seen many defects
creeping in due to misinterpretation of the requirement specification. Fixing such
defects at a later stage can prove costly. So, it is very important that you get your
understanding verified from the customer.

Peer Review
Functioning as a team is a skill. Delivering a high quality product is no responsibility of
an individual. It's the entire team who is responsible for it. If the product fails, each
team member is responsible for it.
Review is an important part of team work. Peer Review refers to participation of team
members in the development and assessment of task/activity performed by an
individual.

In this process, illustrated in Figure 2 below, a team member requests an artifact to be

reviewed. The other team members then provide their review comments which may
include corrections, suggestions and doubts on the artifact.

The artifact is then updated based on the review comments. This process is repeated till
the artifact is up to satisfaction of all the team members. Of course, in case of any
conflict it is the Project Leader who makes the final judgment.

Reviews are critical at the following stages of software development:

a. Requirement Specification Review. As we discussed in the last point,

understanding the customer requirement is very important. So, while you prepare the
Requirement Specification, get it reviewed by your team members. Ten people in a team

III/VI SEM 38
PANIMALAR INSTITUTE OF TECHNOLOGY DEPT OF IT

may have ten interpretations of the specification. Discuss it out within your team, and
then pass your understanding to the customer for verification.

b. Design Review. Once the requirement specification gets finalized, we move on to

the design phase. In the design stage, you would now think about how to approach the
problem.As you will agree, review at this stage is vital. Selection of a wrong strategy can
put the entir e system in a miserable state. Reviews performed at this stage will help you
in:

*Analyzing various strategies to solve the problem.

* Analyzing feasibility of each strategy.
* Knowing advantages/disadvantages of each strategy.
c. Code Review. Code Review involves examining the source code to find defects.
While working on development of system software tools, I have been a witness to how
code review can really help you find defects.

It is good to let someone in your team walk through you code, and do the review. All the
members must review the code changes with respect to other modules and give their
feedback in case some side-effect is suspected.

Many defects such as memory leaks, wrong passing of arguments, unreachable code,
lack of readability, high complexity and maintainability issues can be identified via
code review. Finding defects at the coding stage, and fixing them there and then, would
prove to be less expensive than finding them in the testing stage.

PART A
1. Define Software Engineering. (R) (MAY 2012)
Software Engineering is a discipline that produces error free software with in a time
and budget.
2. Define software Testing. ( R) ( DEC 2012), (May/June 2014)
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.
3. List the elements of the engineering disciplines. (R) (MAY 2012, Dec
2014)
 Basic principles  Standards
 Processes  Measurements
III/VI SEM 39
PANIMALAR INSTITUTE OF TECHNOLOGY DEPT OF IT

 Tools  Code of ethics

 Methods  Body of knowledge
 Best practices
4. Differentiate between verification and validation? (AN) (U.Q Nov/Dec
2009)
S.N
Verification Validation
O

Verification is the process of Verification is the process of

evaluating software system or valuating software system or
1 component to determine whether component during or at the end of
the products of a given the, the development phase satisfy
development phase satisfy the the conditions imposed at the start
conditions imposed at the start of of that phase.
Verification
that phase. is usually associated Verification is usually associated
2
with activities such as inspections with Traditional execution _based
and reviews of the s/w deliverables. testing i.e., Exercising the code with
test cases.
5. Define the term Testing. (R) ( DEC 2012)
 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.

III/VI SEM 40
PANIMALAR INSTITUTE OF TECHNOLOGY DEPT OF IT

6. Differentiate between testing and debugging. (AN) (U.Q Nov/Dec

2008)
Testing Debugging
Testing as a dual purpose process Debugging or fault localization is the
Reveal defects process of
To evaluate quality attributes Locating the fault or defect
Repairing the code, and
Retesting the code.

7. Define process in the context of software quality. (R) ( Nov/Dec 2009)

Process, in the software engineering domain, is a set of methods, practices, Standards,
documents, activities, polices, 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.

8. Define the term Debugging or fault localization. (R) (Nov 2011)

Debugging or fault localization is the process of Locating the fault or defect
Repairing the code and Retesting the code.

9. List the levels of TMM(Testing Maturity Model). (R)(Apr-May 2018)

The testing maturity model or TMM contains five levels. They are
Level1: Initial
Level2: Phase definition
Level3: Integration
Level4: Management and Measurement
Leval5: Optimization /Defect prevention and Quality Control

10. List the members of the critical groups in a testing process (R)
(Nov/Dec 2008)
 Manager

III/VI SEM 41
PANIMALAR INSTITUTE OF TECHNOLOGY DEPT OF IT

 Developer/Tester
 User/Client
11. Define Error. (R) (Nov 2011)
An error is mistake or misconception or misunderstanding on the part of a software
developer.

12.Define Faults (Defects)., (R) (May/June 2014)

A fault is introduced into the software as the result of an error. It is an anomaly in
the
software that may cause nit to behave incorrectly, and not according to its
specification.

13. Define failures. (R) (MAY 2012 & May/June 2014)

A failure is the inability of a software or component to perform its required
functions
within specified performance requirements.
14.Define Test Cases. (R)
 A test case in a practical sense is attest related item which contains the following
information.
 A set of test inputs. These are data items received from an external source by the
code under test. The external source can be hardware, software, or human.
 Execution conditions. These are conditions required for running the test, for
example, a certain state of a database, or a configuration of a hardware device.
 Expected outputs. These are the specified results to be produced by the code
under test.

III/VI SEM 42
PANIMALAR INSTITUTE OF TECHNOLOGY DEPT OF IT

15. Distinguish between fault and failure. (AN) (May/June 2009)

Fault Failure
A fault is introduced into the software A failure is the inability of a software or
as the result of an error. It is an component to perform its required
anomaly in the software that may cause functions within specified performance
nit to behave incorrectly, and not requirements.
according to its
specification.

16.Write short notes on Test, Test Set, and Test Suite (U).
 A Test is a group of related test cases, or a group of related test cases and test
procedure.
 A group of related test is sometimes referred to as a test set.
 A group of related tests that are associated with a database, and are usually run
together, is sometimes referred to as a Test Suite.

17. Define Test Oracle. (R) (April/May 2013 & April/May 2015) (Apr-May
2018)
Test Oracle is a document, or a piece of software that allows tester to determine
whether a test has been passed or failed.
18.Define Test Bed. (R) (April/May 2013 & April/May 2015)(Nov/Dec 2017)
A test bed is an environment that contains all the hardware and software needed to
test a software component or a software system.
19.Define Software Quality. (R)
 Quality relates to the degree to which a system, system component, or process
meets specified requirements.
 Quality relates to the degree to which a system, system component, or process
meets Customer or user needs, or expectations.

III/VI SEM 43
PANIMALAR INSTITUTE OF TECHNOLOGY DEPT OF IT

20. List the Quality Attributes. (R)

 Correctness  Portability
 Reliability  Maintainability
 Usability  Interoperability
 Integrity

21.Define SQA group. (R)

The software quality assurance (SQA) group is a team of people with the
necessary training and skills to ensure that all necessary actions are taken during
the development process so that the resulting software confirms to established
technical requirements.
22. Define reviews. (R)
A review is a group meeting whose purpose is to evaluate a software artifact or a set
of Software artifacts. Review and audit is usually conducted by a SQA group.
23. List the sources of Defects or Origins of defects. Or list the
classification of defect (May/June 2009) (R)
 Education
 Communication
 Oversight
 Transcription
 Process
24. What is the role of process in software quality?(U) (Nov/Dec 2013)
Software process is a set of activities and associated results which produces a
software product. These activities are mostly carried out by software engineers.
There are four fundamental process activities which are common to all software
processes. These activities are software specification, software development,
software validation, software evolution.

25. What do you mean by software defect? Write one example. (U)
(Nov/Dec 2013)
III/VI SEM 44
PANIMALAR INSTITUTE OF TECHNOLOGY DEPT OF IT

A software defect is a deficiency in a software product that causes it to perform

unexpectedly. From a software user’s perspective, a defect is anything that causes
the software not to meet their expectations. In this context, a software user can be
either a person or another piece of software.
Example:
User
The software will help me accomplish a task
Expectation:

Software Defect: Desired software functionality is missing

26. Why We Do Debugging? (U) (April/May 2013)

Debugging is done when the errors are found in testing process and those errors
will be eliminated in debugging.

27. Mention the quality attributes of software (R) (April/May 2015)

 Correctness
 Reliability
 Adequacy
 Learnability
 Robustness
 Maintainability
 Readability
 Extensibility
 Testability
 Efficiency
 Portability

III/VI SEM 45
PANIMALAR INSTITUTE OF TECHNOLOGY DEPT OF IT

28. Mention the objectives of Software Testing(U) (Nov/Dec 2016),

(May/June 2016)(Nov/Dec 2017)
Software Testing has different goals and objectives.The major objectives of
Software testing are as follows:
 Finding defects which may get created by the programmer while
developing the software.
 Gaining confidence in and providing information about the level
of quality.
 To prevent defects.
 To make sure that the end result meets the business and user
requirements.
 To ensure that it satisfies the BRS that is Business Requirement
Specification and SRS that is System Requirement Specifications.
 To gain the confidence of the customers by providing them a quality
product.
29. Define defects with an example.(U). (Nov/Dec 2016)
A defect is an error or a bug, in the application which is created. A
programmer while designing and building the software can make mistakes or
error. These mistakes or errors mean that there are flaws in the software.
These are called defects.
Examples:

Scenario 1: The software will allow a user to make online payments using a
debit card.
Defect: The option of selecting a debit card for making payments is missing.
Scenario 2: The software will help me in avoiding spelling mistakes.
Defect: The feature for detecting the spelling error is missing.

30. Differentiate Error, defect and Failure. (ANALYZE) (May/June

2016)
ERROR: An error is a mistake, misconception, or misunderstanding on
the part of a software developer.

DEFECT: Defect is an error found AFTER the application goes into

production. It commonly refers to several troubles with the software
products, with its external behavior or with its internal features. In other
words Defect is the difference between expected and actual result in the
context of testing. It is the deviation of the customer requirement.

III/VI SEM 46
PANIMALAR INSTITUTE OF TECHNOLOGY DEPT OF IT

FAILURE: A failure is the inability of a software system or component to

perform its required functions within specified performance requirements.
When a defect reaches the end customer it is called a Failure. During
development Failures are usually observed by testers.

31.Mention the role of test engineer in software development

organization.(U) (APR/MAY 2017)

Test engineers/QA testers/QC testers are responsible for:

 To read all the documents and understand what needs to be tested.
 Based on the information procured in the above step decide how it is to be
tested.
 Inform the test lead about what all resources will be required for software
testing.
 Develop test cases and prioritize testing activities.
 Execute all the test case and report defects, define severity and priority for
each defect.
 Carry out regression testing every time when changes are made to the code
to fix defects.
32. What are the sources of defects. (R)(APR/MAY 2017)
 Miscommunication of requirements introduces error in code
 Unrealistic time schedule for development
 Lack of designing experience
 Lack of coding practices experience
 Human factors introduces errors in code
 Lack of version control
 Buggy third-party tools
 Last minute changes in the requirement introduce error
 Poor Software testing skill
PART – B (16 – MARKS)
1. Explain in detail about the elements of engineering disciplines.

2. Discuss about the role of process in software quality.

3. Draw the 5-level structure of the testing maturity model and

discuss about it.

4. Explain in detail about the software testing principles.

5. Give an example for defect classes and discuss them in detail.

III/VI SEM 47
PANIMALAR INSTITUTE OF TECHNOLOGY DEPT OF IT

6. Explain in detail the tester’s role in a software development

organization

7. Explain in detail defect classes, the defect repository and test

design

8. Explain in detail about defect analysis in coin problem

III/VI SEM 48