Software Testing

22518
Chapter 1
Basics of software testing and Testing Methods
(R-04, U-04, A-06 =14 Marks)
1.1 Software Testing, Objective of Testing.
1.2 Failure, Fault, Error, Defect, Bug terminology
1.3 Test Case, When to Start and Stop Testing
1.4 Quality Assurance, Quality Control and Verification - Validation
1.5 Static and dynamic testing.
1.6 The box approaches: White Box Testing: Inspections, Walkthroughs, Technical
Review, Code Functional Testing, Code Coverage Testing, Code Complexity Testing.
1.7 Black Box Testing: Requirement Based Testing, Boundary Value Analysis, Equivalence
Partitioning.

Mrs. Shubhangi Chintawar

Lecturer
VESP
 Software Testing (22518) CO5I

1.Basics of software testing and Testing Methods

1.1. Software Testing, Objective of Testing.
Definition: -
Testing can be defined in simple words as “Performing Verification and Validation of the Software
Product” for its correctness and accuracy of working.
The testing of software is an important means of assessing the software to determine its quality
It is not sufficient to demonstrate that the software is doing what it is supposed to do.
It is more important to demonstrate that s/w is not doing what it is not supposed to do.
Objectives of Testing
1. Finding defects which may get created by the programmer while developing the software.
2. Gaining confidence in and providing information about the level of quality.
3. To prevent defects.
4. To make sure that the end result meets the business and user requirements.
5. To ensure that it satisfies the BRS that is Business Requirement Specification and SRS that is
System Requirement Specifications.
6. To gain the confidence of the customers by providing them a quality product.

1.2. Failure, Fault, Error, Defect, Bug terminology

1. Problem, error, and bug are probably the most generic terms used.
2. Anomaly, incident, and variance don’t sound quite so negative and infer more unintended
operation than an all-out failure.
3. Fault, failure, and defect tend to imply a condition that’s really severe, maybe even
dangerous. It doesn’t sound right to call an incorrectly colored icon a fault. These words also tend
to imply blame: “It’s his fault that the software failed.
4. As all the words sound the same, they are distinguished based on the severity and the
area in which the software failure has occurred.
5. When we run a program the error that we get during execution is termed on the basis of
runtime error, compile time error, computational error, and assignment error.
6. The error can be removed by debugging, if not resolved leads to a problem and if the
problem becomes large leads to software failure.
7. A bug can be defined as the initiation of error or a problem due to which fault, failure,
incident or an anomaly occurs.

1
Software Testing (22518) CO5I

Testing is the process of identifying defects, where a defect is any variance between actual and
expected results.
“A mistake in coding is called Error, error found by tester is called Defect, defect accepted by
development team then it is called Bug, build does not meet the requirements then it Is Failure.”

DEFECT: It can be simply defined as a variance between expected and actual.

Defect can be categorized into the following:

Wrong: When requirements are implemented not in the right way. This defect is a variance from
the given specification. It is Wrong!

Missing: A requirement of the customer that was not fulfilled. This is a variance from the
specifications, an indication that a specification was not implemented, or a requirement of the
customer was not noted correctly.

Extra: A requirement incorporated into the product that was not given by the end customer. This
is always a variance from the specification, but may be an attribute desired by the user of the
product. However, it is considered a defect because it’s a variance from the existing requirements.

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

developer. Error normally arises in software; it leads to change the functionality of the program.

BUG: A bug is the result of a coding error. An Error found in the development environment before
the product is shipped to the customer. A programming error that causes a program to work poorly,
produce incorrect results or crash. An error in software or hardware that causes a program to
malfunction. Bug is terminology of Tester.

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.

FAULT: An incorrect step, process or data definition in a computer program which causes the
program to perform in an unintended or unanticipated manner. A fault 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. It is the result of the error.
The program to find the factorial of a number given below lists a few errors, problems and failures
in a program.

2
Software Testing (22518) CO5I

For example
1. #include<stdio.h>
2. void main()
3. {
4. int i , fact, n;
5. printf(“enter the number “);
6. scanf(“%d”,&n);
7. for(i =1 ;i <=n;i++)
8. fact = fact * i;
9. printf (“the factorial of a number is ”%d”, fact);
10. }
As in line number 4 the fact is not initialized to 1, so it takes garbage value and gives a wrong
output, this is an example of a bug.
If fact is initialized to zero (fact = 0) then the output will be zero as anything multiplied by zero
will give the output as zero. This is a bug which can be removed by initializing fact = 1 during
initializing.
As the fact is declared as integer, for the number till 7! will work perfectly. When the number
entered is 8, the output is garbage value as the integer limit is from – 32767 to +32768, so in
declaration change the initialization to long int fact

Software Bug: A Formal Definition

Definition: A bug can be defined in simple terms as any error or mistake that leads to the failure of the
product or software either due to the specification problem or due to communication problem, regarding
what is developed and what had to be developed.
A software bug occurs when one or more of the following factors are true:
1. The software doesn’t do something that the product specification says it should do.
2. The software does something that the product specification says it shouldn’t do.
3. The software does something that the product specification doesn’t mention.
4. The software doesn’t do something that the product specification doesn’t mention but should.
5. 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.

Software Tester Skills: -

1. They are explorers: - Software testers aren’t afraid to venture into unknown situations. They
love to get a new piece of software, install it on their PC, and see what happens.
2. They are troubleshooters: - Software testers are good at figuring out why something doesn’t
work. As they find the bugs it is their responsibility to give the solution also.
3. They are relentless: - Software testers keep trying. They may see a bug that quickly vanishes
or is difficult to recreate. Rather than dismiss it as a fluke, they will try every way possible to
find it.
4. They are creative: - Testing the obvious isn’t sufficient for software testers. Their job is to
think up creative and even off-the-wall approaches to find bugs. Their perception of finding the
bug is more than that of a programmer.
5. They are perfectionists: - They strive for perfection, but they know when it becomes
unattainable and they want to be close as they can to the solution.
6. They exercise good judgment: - Software testers need to make decisions about what they will
3
Software Testing (22518) CO5I

test, how long it will take, and if the problem they’re looking at is really a bug. The job of a
software tester is in time constraints. They have to find the bugs as early as possible.
7. They are tactful and diplomatic: - Software testers are always the bearers of bad news. They
have to tell the programmers about the various bugs and the error that exist in their program
and it has to be told carefully. Good software testers know how to do so tactfully and
professionally and know how to work with programmers who aren’t always tactful and
diplomatic.
8. They are persuasive: - Bugs that testers find won’t always be viewed as severe enough to be
fixed. Testers need to be good at making their points clear, demonstrating why the bug does
indeed need to be fixed, and following through on making it happen.

1.3 Test Case, When to Start and Stop Testing

Test Case: -
A TEST CASE is a set of conditions or variables under which a tester will determine whether a system
under test satisfies requirements or works correctly. The process of developing test cases can also help
find problems in the requirements or design of an application When to start and stop testing of software
When to Start Testing?
An early start to testing reduces the cost and time to rework and produce error-free software that is
delivered to the client. However, in Software Development Life Cycle (SDLC), testing can be started
from the Requirements Gathering phase and continued till the deployment of the software.
It also depends on the development model that is being used. For example, in the Waterfall model,
formal testing is conducted in the testing phase; but in the incremental model, testing is performed at
the end of every increment/iteration and the whole application is tested at the end.
1. Testing is done in different forms at every phase of SDLC −
2. During the requirement gathering phase, the analysis and verification of requirements are also
considered as testing.
3. Reviewing the design in the design phase with the intent to improve the design is also
considered as testing.
4. Testing performed by a developer on completion of the code is also categorized as testing.
When to Stop Testing?
It is difficult to determine when to stop testing, as testing is a never-ending process and no one can
claim that a software is 100% tested. The following aspects are to be considered for stopping the
testing process −
1. Testing Deadlines
2. Completion of test case execution
3. Completion of functional and code coverage to a certain point
4. Bug rate falls below a certain level and no high-priority bugs are identified
5. Management decision

4
Software Testing (22518) CO5I

1.4 Quality Assurance, Quality Control and Verification - Validation

Verification and Validation

Verification
1. It makes sure that the product is designed to deliver all functionality to the customer.
2. Verification is done at the starting of the development process. It includes reviews and
meetings, walkthroughs, inspection, etc. to evaluate documents, plans, code, requirements
and specifications.
3. It answers the questions like: Am I building the product, right?
4. Am I accessing the data right (in the right place; in the right way).
5. It is a Low-level activity
6. Performed during development on key art facts, like walkthroughs, reviews and
inspections, mentor feedback, training, checklists and standards.
7. Demonstration of consistency, completeness, and correctness of the software at each stage
and between each stage of the development life cycle.
Validation
1. Determining if the system complies with the requirements and performs functions for
which it is intended and meets the organization’s goals and user needs.
2. Validation is done at the end of the development process and takes place after verifications
are completed.
3. It answers the question like: Am I building the right product?
4. Am I accessing the right data (in terms of the data required to satisfy the requirement)?
5. It is a High-level activity.
6. Performed after a work product is produced against established criteria ensuring that the
product integrates correctly into the environment.
7. Determination of correctness of the final software product by a development project with
respect to the user needs and requirements.

5
Software Testing (22518) CO5I

Distinguish between Verification and validation

Sr.No Verification Validation

The verifying process includes checking It is a dynamic mechanism of testing

1
documents, design, code, and program and validating the actual product

2 It does not involve executing the code It always involves executing the code

Verification uses methods like reviews, It uses methods like Black Box
3 walkthroughs, inspections, and desk- Testing, White Box Testing, and non-
checking etc. functional testing

It checks whether the software meets

Whether the software conforms to
4 the requirements and expectations of a
specification is checked
customer

It finds bugs early in the development It can find bugs that the verification
5
cycle process cannot catch

Target is application and software

6 architecture, specification, complete Target is an actual product
design, high level, and database design etc.

QA team does verification and makes sure With the involvement of testing team
7 that the software is as per the requirement validation is executed on software
in the SRS document. code.

8 It comes before validation It comes after verification

Quality Assurance and Quality Control

Quality Assurance
1. A part of quality management focused on providing confidence that quality requirements
will be fulfilled.
2. All the planned and systematic activities implemented within the quality system that can
be demonstrated to provide confidence that a product or service will fulfill requirements
for quality
3. Quality Assurance is fundamentally focused on planning and documenting those processes
to assure quality including things such as quality plans and inspection and test plans.
4. Quality Assurance is a system for evaluating performance, service, or the quality of a
product against a system, standard or specified requirement for customers.
5. Quality Assurance is a complete system to assure the quality of products or services. It is
not only a process, but a complete system including also control. It is a way of management.

6
Software Testing (22518) CO5I

Quality Control
1. A part of quality management focused on fulfilling quality requirements.
2. The operational techniques and activities used to fulfill requirements for quality.
3. Quality Control on the other hand is the physical verification that the product conforms to
these planned arrangements by inspection, measurement etc.
4. Quality Control is the process involved within the system to ensure job management,
competence and performance during the manufacturing of the product or service to ensure
it meets the quality plan as designed.
5. Quality Control just measures and determines the quality level of products or services. It is
a process itself.

Distinguish between Quality Assurance and Quality Control

Sr.No Quality Assurance Quality Control

Activities which ensure the Activities which ensure the verification of

1 implementation of processes, developed software with respect to documented
procedures and standards requirements.

Focuses on processes and Focuses on actual testing by executing Software

2 procedures rather than conducting with intent to identify bugs/defects through
actual testing on the system. implementation of procedures and processes.

3 Process oriented activities. Product oriented activities.

4 Preventive activities. It is a corrective process.

It is a subset of the Software Test QC can be considered as the subset of Quality

5
Life Cycle (STLC). Assurance.

6 Quality audit is e.g. Testing and review are the e.g.

1.5 Static and dynamic testing.

Static Testing
1. Static testing is performed when the system is not running.
2. This testing is also called a Non-execution technique or verification testing.
3. Static testing works with peer review, and mostly referred to as pen and pencil run.
4. Manually checks the code, requirement documents, and design documents to find errors.
5. The main objective of this testing is to improve the quality of software products by finding
errors in the early stages of the development cycle.
6. Static testing involves manual or automated reviews of the documents.
7. This review is done during an initial phase of testing to catch Defect early in STLC.
8. It examines work documents and provides review comments

7
Software Testing (22518) CO5I

Dynamic testing
1. Dynamic testing is testing that is performed when the system is running.
2. This testing is also called an Execution technique or validation testing.
3. It checks for functional behavior of the software system, memory/CPU usage and overall
performance of the system.
4. The main objective of this testing is to confirm that the software product works in conformance
with the business requirements.
5. Dynamic testing executes the software and validates the output with the expected outcome.
6. Dynamic testing is performed at all levels of testing and it can be either black or white box
testing.

Distinguish between Static and Dynamic Testing

Sr.No. Static Testing Dynamic Testing

Testing was done without executing the

1 Testing is done by executing the program
program

2 This testing does the verification process Dynamic testing does the validation process

Dynamic testing is about finding and fixing the

3 Static testing is about prevention of defects
defects

Static testing gives an assessment of code Dynamic testing gives bugs/bottlenecks in the
4
and documentation software system.

Static testing involves a checklist and

5 Dynamic testing involves test cases for execution
process to be followed

This testing can be performed before

6 Dynamic testing is performed after compilation
compilation

Static testing covers the structural and Dynamic testing techniques are Boundary Value
7
statement coverage testing Analysis & Equivalence Partitioning.

8 Cost of finding defects and fixing is less Cost of finding and fixing defects is high

Return on investment will be high as this Return on investment will be low as this process
9
process involved at an early stage involves after the development phase

More reviews comments are highly More defects are highly recommended for good
10
recommended for good quality quality.

11 Requires loads of meetings Comparatively requires lesser meetings

Static testing covers the structural and Dynamic testing techniques are Boundary Value
12
statement coverage testing Analysis & Equivalence Partitioning.

8
Software Testing (22518) CO5I

1.6 The box approach: White Box Testing: Inspections, Walkthroughs, Technical
Review, Code Functional Testing, Code Coverage Testing, Code Complexity Testing.

The Box approach: -

There are two types of testing 1. White Box and Black Box testing
Blackbox testing involves testing from an external or end-user type perspective. On the other hand,
Whitebox testing is based on the inner workings of an application and revolves around internal
testing.

White Box Testing

WHITE BOX TESTING is testing a software solution's internal structure, design, and coding. It is
also known as Clear Box testing, Open Box testing, Structural testing, Transparent Box testing,
Code-Based testing, and Glass Box testing. It is usually performed by developers.
In this type of testing, the code is visible to the tester. It focuses primarily on verifying the flow of
inputs and outputs through the application, improving design and usability, strengthening security.

Tester Needs to have knowledge of the internal working of the code.

Look inside the source code and find out which unit of the code is behaving inappropriately..
Aspects missed out in black box testing are tested.

Advantages
1. As the tester has knowledge of the source code
2 . It becomes very easy to find out which type of data can help in testing the application effectively.
3. Extra lines of code can be removed which can bring in hidden defects.
4. It helps in optimizing the code.
5. Due to the tester's knowledge about the code, maximum coverage is attained during writing test
cases.

Disadvantages
1.Due to the fact that a skilled tester is needed to perform
2. Necessity to create a full range of inputs to test each path and condition make the white box
testing method time-consuming.
3. Some conditions might be untested as it is not realistic to test every single one.
4. Specialized tools like code analysers and debugging tools are required.

9
Software Testing (22518) CO5I

Black box testing

BLACK BOX TESTING is defined as a testing technique in which functionality of the Application
Under Test (AUT) is tested without looking at the internal code structure, implementation details
and knowledge of internal paths of the software. This type of testing is based entirely on software
requirements and specifications. In Black Box Testing we just focus on inputs and output of the
software system without bothering about internal knowledge of the software program.

The tester is unaware of the system architecture and does not have access to the source code.
Testers interact with the system's user interface by providing inputs. Examining outputs without
knowing how and where the inputs are worked upon.

Advantages
1. Well suited and efficient for large code segments.
2. Code Access not required.
3. Test is performed from a user’s point-of-view and not of the designer’s.
4. Tester is free from any pressure of knowledge of specific programming languages to test the
functionality of an application.
5. Test cases can be designed as soon as the specifications are complete.

Disadvantages
1. Blind Coverage, since the tester cannot target specific code segments or error prone areas.
2. Testing every possible input stream is not possible because it is time-consuming.
3. Inefficient testing, due to the fact that the tester only has limited knowledge about an application.
4. The test cases are difficult to design.

Static White Box Testing

White-box testing is the process of carefully and methodically reviewing the software design,
architecture, or code for bugs without executing it. It's sometimes referred to as structural analysis.
White-box (or clear-box) testing implies having access to the code, being able to see it and review.
Static white-box testing is the process of carefully and methodically reviewing the software design,
architecture, or code for bugs without executing it. It’s sometimes referred to as structural analysis.
Advantage of static white-box testing is that it gives the team’s black-box testers ideas for test
cases to apply when they receive the software for testing. They may not necessarily understand the
details of the code, but by listening to the review comments they can identify feature areas that
sound troublesome or bug-prone.
10
Software Testing (22518) CO5I

Types of Static White Box Testing

1. Inspections
2. Walkthrough
3. Technical Review

Inspections
1. Inspections are the most formal type of reviews.
2. They are highly structured and require training for each participant.
3. Inspections are different from peer reviews and walkthroughs in that the person who presents
the code, the presenter or reader, isn’t the original programmer.
4. This forces someone else to learn and understand the material being presented, potentially giving
a different slant and interpretation at the inspection meeting.
5. The other participants are called inspectors.
6. Each is tasked with reviewing the code from a different perspective, such as a user, a tester, or
a product support person.
7. This helps bring different views of the product under review and very often identifies different
bugs.
8. One inspector is even tasked with reviewing the code backward—that is, from the end to the
beginning—to make sure that the material is covered evenly and completely.

Walkthroughs
1. A walk through is an evaluation process which is an informal meeting, which does not require
preparation.
2. Author presents their developed artifact to an audience of peers.
3. Peers question and comment on the artifact to identify as many defects as possible.
4. In a walkthrough, the programmer who wrote the code formally presents (walks through) it to a
small group of five or so other programmers and testers.
3. The reviewers should receive copies of the software in advance of the review so they can
examine it and write comments and questions that they want to ask at the review.
4. Having at least one senior programmer as a reviewer is very important.

Technical Review
1. Formal Review
2. Peer Review

1. Formal Review
1. A formal review is the process under which static white-box testing is performed.
2. A formal review can range from a simple meeting between two programmers to a detailed,
rigorous inspection of the code.

There are four essential elements to a formal review

1. Identify Problems: - .The goal of the review is to find problems with the software—not
just items that are wrong, but missing items as well. All criticism should be directed at the code,
not the person who created it. Participants shouldn’t take any criticism personally. Leave your
egos, emotions, and sensitive feelings at the door.
11
Software Testing (22518) CO5I

2. Follow Rules: - A fixed set of rules should be followed. They may set the amount of
code to be reviewed (usually a couple hundred lines), how much time will be spent (a couple
hours), what can be commented on, and so on. This is important so that the participants know what
their roles are and what they should expect. It helps the review run more smoothly.
3. Prepare: - Each participant is expected to prepare for and contribute to the review.
Depending on the type of review, participants may have different roles. They need to know what
their duties and responsibilities are and be ready to actively fulfill them at the review. Most of the
problems found through the review process are found during preparation, not at the actual review.
4. Write a Report: - The review group must produce a written report summarizing the results
of the review and make that report available to the rest of the product development team. It’s
imperative that others are told the results of the meeting—how many problems were found, where
they were found, and so on.

2. Peer Reviews
1. The easiest way to get team members together and doing their first formal reviews of the
software is through peer reviews, the least formal method.
2. Sometimes called buddy reviews, this method is really more of a discussion.
3. Peer reviews are often held with just the programmer who wrote the code and one or two other
programmers or testers acting as reviewers.
4. Small group simply reviews the code together and looks for problems and oversights.
5. To assure that the review is highly effective all the participants need to make sure that the four
key elements of a formal review are in place: Look for problems, follow rules, prepare for the
review, and write a report.
6. As peer reviews are informal, these elements are often scaled back. Still, just getting together to
discuss the code can find bugs.

Dynamic White Box Testing

Dynamic white-box testing, in a nutshell, is using information you gain from seeing what the code
does and how it works to determine what to test, what not to test, and how to approach the testing.
Another name commonly used for dynamic white-box testing is structural testing because you can
see and use the underlying structure of the code to design and run your tests. Dynamic white-box
testing isn’t limited just to seeing what the code does. It also can involve directly testing and
controlling the software.

The four areas that dynamic white-box testing encompasses are

1. Directly testing low-level functions, procedures, subroutines, or libraries. In Microsoft
Windows, these are called Application Programming Interfaces (APIs).
2. Testing the software at the top level, as a completed program, but adjusting your test
cases based on what you know about the software’s operation.
3. Gaining access to read variables and state information from the software to help you
determine whether your tests are doing what you thought and, being able to force the software to
do things that would be difficult if you tested it normally.
4. Measuring how much of the code and specifically what code you “hit” when you run
your tests and then adjusting your tests to remove redundant test cases and add missing ones.

12
Software Testing (22518) CO5I

Dynamic White Box Testing versus Debugging

1. It’s important not to confuse dynamic white-box testing with debugging.
2. The goal of dynamic white-box testing is to find bugs. The goal of debugging is to fix them.
3. They do overlap, however, in the area of isolating where and why the bug occurs. You’ll
learn more about this in Chapter 18, “Reporting What You Find,” but for now, think of the
overlap this way.
4. As a software tester, you should narrow down the problem to the simplest test case that
demonstrates the bug.
5. If its white-box testing, that could even include information about what lines of code look
suspicious.
6. The programmer who does the debugging picks the process up from there, determines
exactly what is causing the bug, and attempts to fix it.

Structural Testing-
1. Code Functional Testing,
2. Code Coverage Testing,
3. Code Complexity Testing

1. Code functional testing

a. Data Flow
Data flow coverage involves tracking a piece of data completely through the software. With black-
box testing, testers only know the value of the variable is at the beginning and at the end. With
dynamic white-box testing it checks intermediate values during program execution. Based on this
tester decides to change some of the tests and takes variable interesting or even risky values.
At the unit test level this would just be through an individual module or function. The same tracking
could be done through several integrated modules or even through the entire software product—
although it would be more time-consuming to do so. During data flow, the check is made for the
proper declaration of variables declared and the loops used are declared and used properly.

void main( )
{
int a,b,c;
printf(“Enter values of a and b”);
scanf(“%d%d”,&a,&b);
C=a+b;
C=c/2;
print(“Average=%d”,c);
}
o/p:- Enter values of a and b 2 4
Average=3
Intermediate values a==2 b=4 , C=6, C=3

13
Software Testing (22518) CO5I

b. Data coverage
Coverage is a measure of the completeness of the set of test cases. Consider the data first.
Data includes all the variables, constants, arrays, data structures, keyboard and mouse input, files
and screen input and output, and I/O to other devices such as modems, networks, and so on.
For example
1. #include<stdio.h>
2. void main()
3. {
4. int i , fact= 1, n;
5. printf(“enter the number “);
6. scanf(“%d”,&n);
7. for(i =1 ;i <=n;i++)
8. fact = fact * i;
9. printf (“the factorial of a number is ”%d”,
fact);
10. }

The declaration of data is complete with the assignment statement and the variable declaration
statements. All the variables declared are properly utilized.

2. Code Coverage Testing,

For comprehensive coverage you must also test the program’s states and the program’s flow
among them. You must attempt to enter and exit every module, execute every line of code, and
follow every logic and decision path through the software. Examining the software at this level of
detail is called Code-coverage analysis is a dynamic white-box testing technique because it
requires you to have full access to the code to view what parts of the software you pass through
when you run your test cases.
a. Program Statements and Line Coverage
1. The most straightforward form of code coverage is called statement coverage or line coverage.
2. If you’re monitoring statement coverage while you test your software, your goal is to make
sure that you execute every statement in the program at least once.
3. With line coverage the tester tests the code line by line giving the relevant output.
For example
1. #include<stdio.h>
2. void main()
3. {
4. int i , fact= 1, n;
5. printf(“enter the number “);
6. scanf(“%d”, &n);
7. for(i =1 ;i <=n; i++)
8. fact = fact * i;
9. printf (“the factorial of a number is ”%d”, fact);
10. }

14
Software Testing (22518) CO5I

example of the Visual Basic debugger in operation

For very small programs or individual modules, using a debugger is often sufficient. However,
performing code coverage on most software requires a specialized tool known as a code coverage
analyzer
` b. Branch Coverage
1. Attempting to cover all the paths in the software is called path testing.
2. The simplest form of path testing is called branch coverage testing.
3. To check all the possibilities of the boundary and the sub boundary conditions and it’s branching
on those values.
4. Test coverage criteria requires enough test cases such that each condition in a decision takes on
all possible outcomes at least once, and each point of entry to a program or subroutine is invoked
at least once.
5. Every branch (decision) taken each way, true and false.
6. It helps in validating all the branches in the code making sure that no branch leads to abnormal
behavior of the application.

If you test this program with the goal of 100% statement coverage, you need to run only a single
test case with the Date$ variable set to January 1, 2000.
The program would then execute the following path: Lines 1, 2, 3, 4, 5, 6, 7

Need to try a test case for a date that’s not January 1,2000.
If you did, the program would execute the other path through the program: Lines 1, 2, 5, 6, 7

15
Software Testing (22518) CO5I

Most code coverage analyzers report both statement coverage and branch coverage results
separately.

c. Condition Coverage
An extra condition is added to the IF statement in line 2 that checks the time as well as the date.
Condition coverage testing takes the extra conditions on the branch statements into account.

If you were concerned only with branch coverage, the first three conditions would be redundant
and could be equivalence partitioned into a single test case.

But, with condition coverage testing, all four cases are important because they exercise different
conditions of the IF statement in line 4.

3. Code Complexity Testing (Cyclomatic Complexity)

Cyclomatic complexity of a code section is the quantitative measure of the number of linearly
independent paths in it. It is a software metric used to indicate the complexity of a program. It is
computed using the Control Flow Graph of the program. The nodes in the graph indicate the
smallest group of commands of a program, and a directed edge in it connects the two nodes i.e. if
the second command might immediately follow the first command.
For example, if source code contains no control flow statement then its cyclomatic
complexity will be 1 and source code contains a single path in it. Similarly, if the source code
contains one if condition then cyclomatic complexity will be 2 because there will be two paths
one for true and the other for false.
16
Software Testing (22518) CO5I

Mathematically, for a structured program, the directed graph inside control flow is the
edge joining two basic blocks of the program as control may pass from first to second.
So, cyclomatic complexity M would be defined as,
M=E–N+2
where,
E = the number of edges in the control flow graph
N = the number of nodes in the control flow graph
Or
M= P + 1
Where P = Number of predicate nodes (node that contains condition)
Steps that should be followed in calculating cyclomatic complexity and test cases design are:

Construction of graph with nodes and edges from code.

Identification of independent paths.
Cyclomatic Complexity Calculation
Design of Test Cases

The cyclomatic complexity calculated for above code will be from the control flow graph. The
graph shows seven shapes(nodes), seven lines(edges), hence cyclomatic complexity is 7-7+2 = 2.
Or M= P + 1, Where P = Number of predicate nodes (node that contains condition)
M=1+1= 2.

Use of Cyclomatic Complexity:

1. Determining the independent path executions thus proven to be very helpful for
Developers and Testers.
2. It can make sure that every path has been tested at least once.
3. Thus help to focus more on uncovered paths.
4. Code coverage can be improved.
5. Risk associated with the program can be evaluated.

17
Software Testing (22518) CO5I

1.7 Black Box Testing: Requirement Based Testing, Boundary Value Analysis, Equivalence
Partitioning.

Requirement Based Testing

Requirements-based testing is a testing approach in which test cases, conditions and data are
derived from requirements. It includes functional tests and also nonfunctional attributes such as
performance, reliability or usability.

Stages in Requirements based Testing

1. Defining Test Completion Criteria: - Testing is completed only when all the functional and
non-functional testing is complete.
2. Design Test Cases: - A Test case has five parameters namely the initial state or pre-
condition, Test ID, the inputs, expected outcomes and actual outcomes.
3. Execute Tests: - Execute the test cases against the system under test and document the
results.
4. Verify Test Results: - Verify if the expected and actual results match each other.
5. Verify Test Coverage: - Verify if the tests cover both functional and nonfunctional aspects
of the requirement.
6. Track and Manage Defects: - Any defects detected during the testing process goes through
the defect life cycle and are tracked to resolution. Defect Statistics are maintained which
will give us the overall status of the project.

Requirements testing process

1. Testing must be carried out in a timely manner.
2. Testing process should add value to the software life cycle, hence it needs to be effective.
3. Testing the system thoroughly is impossible hence the testing process needs to be efficient
as well.
4. Testing must provide the overall status of the project, hence it should be manageable.

Positive Testing
Positive Testing is a testing process where the system validated against the valid input data.
In this testing tester always checks for only valid sets of values and checks if an application behaves
as expected with its expected inputs.
The main intention is to check whether software applications are not showing error when not
supposed to & showing error when supposed to. Keeping a positive point of view & only executing
the positive scenario. Positive Testing always tries to prove that a given product and project always
meets the requirements and specifications.

18
Software Testing (22518) CO5I

Negative Testing
Negative Testing is a testing process where the system validated against the invalid input data.
A negative test checks if an application behaves as expected with its negative inputs.
Such testing is to be carried out keeping a negative point of view & only execute the test cases for
only invalid sets of input data.
The main reason behind Negative testing is to check the stability of the software application against
the different variety of incorrect data.

Boundary Value Analysis

1. Boundary conditions are special because programming, by its nature, is susceptible to problems
at its edges.
2. The boundary conditions are defined as the initial and the final data ranges of the variables
declared.
3. If an operation is performed on a range of numbers, odds are the programmer got it right for the
vast majority of the numbers in the middle, but maybe made a mistake at the edges.
4. The edges are the minimum and the maximum values for that identifier.

For example
1. #include<stdio.h>
2. void main()
3. {
4. int i , fact=1, n;
5. printf(“enter the number “);
6. scanf(“%d”,&n);

7. for(i =1 ;i <=n;i++)
8. fact = fact * i;
9. printf (“the factorial of a number is ”%d”, fact);
10. }

The boundary condition in the above example is for the integer variable:- -32,768 to 32,767

Sub-Boundary Conditions
Sub-boundaries are internal to the software, Not noticeable by an end user but still need to be
checked by the software tester. These are known as sub-boundary conditions or internal boundary
conditions.
Enter Character to find its ASCII value
19
Software Testing (22518) CO5I

Sub boundaries are (0-9 , a-z, A-Z, Symbols )

0 through 9 are assigned to ASCII values 48 through 57.
The slash character, /, falls before 0. The colon, :, comes after 9.
The uppercase letters A through Z go from 65 to 90. The lowercase letters span 97 to 122.

Equivalence Partitioning
Equivalence partitioning is the process of methodically reducing the huge (infinite) set of
possible test cases into a much smaller, but still equally effective, set. Divides the input domain
of the program into classes of data from which the test cases can be divided.
For example
Input text box accept only number between 4 to 10
4 to 10 - Valid input
More than 10- Invalid input
Less than 4 - Invalid input
Choose test case based on these partition and also select boundary test cases as 3,4,10,11.

Consider the possibilities for entering a filename in the standard Save As dialog box
A Windows filename can contain any characters except \ / : * ? “ < > and |.
Filenames can have from 1 to 255 characters. If you’re creating test cases for filenames, you will
have equivalence partitions for valid characters, invalid characters, valid length names, names that
are too short, and names that are too long.

20
Software Testing (22518) CO5I

DECISION TABLE BASED TESTING

Decision tables are used in many engineering disciplines to represent complex logical
relationships. An output may be dependent on many input conditions and decision tables give a
pictorial view of various combinations of input conditions. There are four portions of the decision
table and are shown in Table. The decision table provides a set of conditions and their
corresponding actions.

Parts of the Decision Table

The four parts of the decision table are given as:
1. Condition Stubs: All the conditions are represented in this upper left section of the decision
table. These conditions are used to determine a particular action or set of actions.
2. Action Stubs: All possible actions are listed in this lower left portion of the decision table.
3. Condition Entries: In the condition entries portion of the decision table, we have a number
of columns and each column represents a rule. Values entered in this upper right portion of
the table are known as inputs.
4. Action Entries: Each entry in the action entries portion has some associated action or set of
actions in this lower right portion of the table. These values are known as outputs and are
21
Software Testing (22518) CO5I

dependent upon the functionality of the program.

Example
Three types of customers are defined: a regular customer, a silver customer, and a gold
customer (these types are assigned by the amount of business the customer does with the print
shop over a 12-month period).
A regular customer receives normal print rates and delivery. A silver customer gets an 8 percent
discount on all quotes and is placed ahead of all regular customers in the job queue. A gold
customer gets a 15 percent reduction in quoted prices and is placed ahead of both regular and silver
customers in the job queue. A special discount of x percent in addition to other discounts can be
applied to any customer’s quote at the discretion of management

State Testing
The other side of software testing is to verify the program's logic flow through its various states.
A software state is a condition or mode that the software is currently in. Windows Paint program
in the pencil drawing state. This is the initial state in which the software starts. Notice that the
pencil tool is selected, the cursor looks like a pencil, and a fine line is used to draw onscreen.

The same program in the airbrush state. In this state, the airbrush tool is selected, airbrush sizes are
provided, the cursor looks like a spray-paint can, and drawing results in a spray-paint look.

22
 Software Testing (22518) CO5I

Testing the Software’s Logic Flow

• It’s often impossible to traverse all paths to all states.
• The solution for software testing is to apply equivalence partition techniques to the
selection of the states and paths, assuming some risk because you will choose not to test all
of them, but reducing that risk by making intelligent choices.
Creating a State Transition Map
The state transition diagram should be easily understandable and should be able to explain clearly
about the various stages the software passes through

A state transition map should show the following items:

• Each unique state that the software can be in.
• The input or condition that takes it from one state to the next.
• Set conditions and produced output when a state is entered or exited.

Reducing the Number of States and Transitions to Test

• Visit each state at least once.
• Test the state-to-state transitions that look like the most common or popular.
• Test the least common paths between states.
• Test all the error states and returning from the error states.
• Test random state transitions.

23
Software Testing (22518) CO5I

Graph based testing

• Graph Based Testing is also called as State Based Testing
• It provides a framework for model-based testing.
• Each and every application is building of some objects.
• All such objects are identified and graph is prepared.
• Black-box methods based on the nature of the relationships (links) among the program
objects (nodes), test cases are designed to traverse the entire graph.
• Finite state modeling – Nodes represent user observable states of the software and links
represent transitions between states.
• Transaction flow testing – Nodes represent steps in some transaction and links represent
logical connections between steps that need to be validated.
• Data flow modeling – nodes are data objects and links are transformations from one data
object to another.

Steps in graph testing:

• Build a graph model.
• Identify the test requirements.
• Select test paths to cover those requirements.

In order to design test design cases following steps are used:

• Understanding the system
• Identifying states and inputs.
• Create a state graph model of the application.
• Verify whether State graph that we modeled is correct in all details.
• Generate sequence of test actions. Derive test data so that those test paths can be executed.
•

User documentation testing

As a software tester - testing the software is not sufficient, Responsibility is to cover all the parts
that make up the entire software product and assuring that the documentation is also correct.

Types of Software Documentation

• Packaging text and graphics
• copyright information
• Marketing material
• service contracts

24
Software Testing (22518) CO5I

• Warranty/registration card that the customer fills out and sends in to register the software.
• End User License Agreement
• Installation and setup instructions
• User’s manual
• Online help
• Samples, examples, and templates
• Error messages

The Importance of Documentation Testing

• It improves usability. Much of that usability is related to the software documentation.
• It improves reliability. Reliability is how stable and consistent the software is.
• It lowers support costs. The reason is that users who are confused or run into unexpected
problems will call the company for help, which is expensive. Good documentation can
prevent these calls by adequately explaining and leading users through difficult areas.

The Realities of Documentation Testing

• Documentation often gets the least attention, budget, and resources
• It’s possible that the people writing the documentation aren’t experts in what the software
does.
• Printed documentation takes time to produce, sometimes weeks or even months.

Important Questions
1. Define software Quality Assurance and software Quality Control.
2. Define following terms-Failure, Error, Defect and Bug.
3. State process of Black box testing with labeled diagram? List any four techniques of black
box testing.
4. Enlist the objectives of software testing.
5. Design any four boundary value test cases for textbox which accept numbers from 1-999.
6. Define Static testing and Dynamic testing.
7. Differentiate between Verification and Validation.
8. Apply equivalence partitioning on application which display result on basis of percentage
obtained in exam.
9. Define White box testing and explain any two techniques of white box testing.
10. Write down the criteria when to start and when to stop testing.
11. Describe the use of decision table in black box testing with the help of suitable example.
12. Design test cases for railway reservation system.
13. Design test cases for hostel admission form of your institute.
14. Explain Static White Box Testing techniques in detail.
15. Differentiate between White box testing and black box testing.

25