Chapter-1

Basics of Software Testing and Testing Methods

Introduction
Define software testing.
Software Testing is the process of executing a program with the intent of finding errors.

The purpose of test process is

al
 To assure the quality of the product. Quality software is bug free, delivered on time and
within budget, meets customer requirements and is maintainable.

aim
 To detect softwarte failures so that defects may be discovered andcorrected.
 To show that the software performs the intended function properly

What is Software testing?

aK
 Software Testing is the process of executing a program with the intent of finding
errors.
 Software testing is performing Verification and Validation of the Software Product for its
em
correctness and accuracy of working.
 A successful test is one that uncovers an as-yet-undiscovered error.
Se

Objectives of software testing :

 Finding error : Software Testing is the process of executing a program with the intent of
finding errors. A successful test is the one that uncovers an undiscovered error
of.

 Creating good test cases : A good test case is the one that has a high probability of
finding an undiscovered error.
Pr

 Quality improvement : Testing should systematically uncover different classes of errors

in a minimum amount of time and with a minimum amount of effort.
 Satisfying customer requirements: A secondary benefit of testing is to ensure that it
satisfies the BRS that is Business Requirement Specification and SRS that is System
Requirement Specifications.

1
 Chapter-1
Basics of Software Testing and Testing Methods
 Reliability and quality : the data collected though testing can also provide an indication
of the software’s reliability and quality. But testing cannot show the absence of defect-it
can only show that software defects are present.

Testing Principles
#1) Testing Shows the Presence of Defects

al
Testing can show the defects are present, but cannot prove that there are no defects.
Even after testing the application thoroughly we cannot say that the product is 100% defect

aim
free.
The objective of testing is to find more and more hidden defects using different techniques
and methods.

that the software is defect free.

Example 1:
aK
Testing can reveal undiscovered defects and if no defects are found then it does not mean
em
Consider a Banking application, this application is thoroughly tested and undergoes different
phases of testing like SIT, UAT etc. and currently no defects are identified in the system.
However, there might be a possibility that in the production environment, the actual customer
Se

tries a functionality which is rarely used in the banking system and the testers overlooked that
functionality, hence no defect was found till date or the code has never been touched by
developers.
of.

Example 2:
We have seen several advertisements for soaps, toothpaste, handwash or disinfectant sprays etc
on television.
Pr

Consider a handwash advertisement which says on the television that 99% germs can be
removed if that specific handwash is used. This clearly proves that the product is not 100%
germ-free. Thus in our testing concept, we can say that no software is defect free.

2
 Chapter-1
Basics of Software Testing and Testing Methods
#2) Early Testing
The cost involved in fixing defects in the early stages is very less when compared to those
that are found during the later stages of testing.

Now the question is how early should the testing start?

 Once the requirements are finalized, the testers need to involve for testing.

al
 Testing should be performed on requirement documents, specification or any other
type of document so that if requirements are incorrectly defined then it can be fixed

aim
immediately rather than fixing them in the development phase.

#3) Exhaustive Testing is Not Possible

aK
It is not possible to test all the functionalities with all valid and invalid combinations of
input data during actual testing. Instead of this approach, testing of a few combinations is
considered based on priority using different techniques.
em
For Example, If suppose we have an input field which accepts alphabets, special characters, and
numbers from 0 to 1000 only. Imagine how many combinations would appear for testing, it is
not possible to test all combinations for each input type.
The testing efforts required to test will be huge and it will also impact the project timeline and
Se

cost. Hence it is always said that exhaustive testing is practically not possible.
of.

#4) Testing is Context-Dependent

Different domains are tested differently, thus testing is purely based on the context of the
domain or application.
Pr

For Example, Testing a banking application is different than testing any e-commerce or
advertising application. The risk associated with each type of application is different, thus it is
not effective to use the same method, technique, and testing type to test all types of application.

#5) Defect Clustering

3
 Chapter-1
Basics of Software Testing and Testing Methods
During testing, it may happen that most of the defects found are related to a small number
of modules because modules may be complex or coding related to such modules may be
complicated etc.

#6) Pesticide Paradox

 Pesticide Paradox principle says that if the same set of test cases are executed again

al
and again over the period of time then these set of tests are not capable enough to
identify new defects in the system.

aim
 In order to overcome this the set of test cases needs to be regularly reviewed and
revised.

#7) Absence of Error

aK
If the software is tested against wrong requirements, in such cases, even finding defects and
fixing them on time would not help as testing is performed on wrong requirements which are not
em
as per needs of the end user.
For Example, suppose the application is related to an e-commerce site and the requirements
against “Shopping Cart or Shopping Basket” functionality which is wrongly interpreted and
tested. Here, even finding more defects does not help to move the application into the next phase
Se

or in the production environment.

of.

Software testing is done for many reasons

• To check the reliability of the software
• To ensure that the software does not contain any bug.
Pr

• To check that the software was made according to its specification.

• To check that the software meets its requirements.
• To check that users are able to use the software.
• To check software works with other software and hardware it needs to work with.
• To improve quality of software by removing maximum possible errors or defects.
1. Test methodologist or Methodology specialist

4
 Chapter-1
Basics of Software Testing and Testing Methods
Testing Terminologies
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.

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

al
developer. It is the one that is generated because of the wrong login, loop or syntax. The error
normally arises in software; it leads to a change in the functionality of the program.

aim
Fault : It is an anomaly in the software that may cause it to behave incorrectly, and not
according to its specification.
aK
Defect : It can be simply defined as a variance between expected and actual result. It is the
deviation of the customer requirement.
em
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 bug is the terminology of Tester.
Se

Testing is the process of identifying defects, where a defect is any variance between actual
and expected results.
of.

Reasons for occurrence of BUGS

 Specification not detailed enough
Pr

 Specification changing constantly

 Specification not communicated well to the entire development team
 Planning not done properly
 Design is quick , changed or not well communicated.
 Coding errors can be traced to S/W’s complexity, poor documentation, schedule pressure,
or plain mistakes.

5
 Chapter-1
Basics of Software Testing and Testing Methods
Test Case
 Test case is a well-documented procedure designed to test the functionality of the
feature in the system.
 For designing the test case, it needs to provide set of inputs and its corresponding
expected outputs.
 A test case in software engineering is a set of conditions or variables under which a tester

al
will determine whether an application or software system is working correctly or not.
 A set of test inputs, execution conditions, and expected results developed for a particular

aim
objective, such as to exercise a particular program path or to verify compliance with a
specific requirement.
Different Skills of software tester :


Communication skills
Domain knowledge
aK
 Desire to learn
em
 Technical skills
 Analytical skills
 Planning
Se

 Integrity
 Curiosity

of.

Think from users perspective

 Be a good judge for product
Pr

Explain when to start and stop testing.

 An early start to testing reduces the cost, time to rework and error free software
that is delivered to the client.
 Testing can be started from the Requirements Gathering phase and lasts till the
deployment of the software.
 However it also depends on the development model that is being used.

6
 Chapter-1
Basics of Software Testing and Testing Methods
 For example in Water fall model formal testing is conducted in the Testing phase, but in
incremental model, testing is performed at the end of every increment/iteration and at the
end the whole application is tested.
 Testing is done in different forms at every phase of SDLC like during Requirement
gathering phase, the analysis and verifications of requirements are also considered
testing.

al
Entry criteria, specifies when that phase can be started .

aim
Testing can be started from the Requirements Gathering phase once all requirements have been
finalized
Exit criteria may include:
 All test plans have been run.


aK
All requirements coverage has been achieved.
All severe bugs are resolved.
 Testing Deadlines
em
 Management decision.

Verification versus Validation

Se

Verification
“Are we building the product right:
of.

The software should conform to its specification.

Validation
Pr

“Are we building the product right”

The software should do what the user really wants.

Q) Describe V-model with labeled diagram. State its any two advantages and
disadvantages. Also write where it is applicable.
Q) Explain verification and validation with neat diagram

 V-model means verification and validation model.

7
 Chapter-1
Basics of Software Testing and Testing Methods
 V-model is evolved from waterfall model. It is sequential path of execution of processes.
Each phase must be completed before the next phase begins.
 Under V-model, the corresponding testing phase of the development phase is planned in
parallel.
 So there is verification on one side of V & validation phase on the other side of V.

al
Verification Phase:
1. Overall Business Requirement: In this first phase of the development cycle, the product

aim
requirements are understood from customer perspective. This phase involves detailed
communication with the customer to understand his expectations and exact requirements.
2. Software Requirement: Once the product requirements are clearly known, the system can be
designed. The system design comprises of understanding & detailing the complete hardware,
aK
software & communication set up for the product under development.
3. High level design: High level specification are understood & designed in this phase. Usually
more than one technical approach is proposed & based on the technical & financial feasibility,
em
the final decision is taken.
4. Low level design: In this phase the detailed integral design for all the system modules is
specified.
Se

5. Coding:. A suitable programming language is decided based on requirements. Coding is done

based on the coding guidelines & standards.
of.

Validation:

Unit Testing: Unit tests designed in the module design phase are executed on the code during
Pr

this validation phase. This helps to eliminate bugs at an early stage.

Components testing: This is associated with module design helps to eliminate defects in
individual modules.
Integration Testing: It is associated with high level design phase & it is performed to test the
coexistence & communication of the internal modules within the system
System Testing: It is associated with system design phase. It checks the entire system
functionality & the communication of the system under development with external systems.

8
 Chapter-1
Basics of Software Testing and Testing Methods
Most of the software & hardware compatibility issues can be uncovered using system test
execution.
Acceptance Testing: It is associated with business requirement analysis and involves testing the
product in user environment.

al
aim
aK
em

Advantages of V-model:
Se

 Simple and easy to use.

 Testing activities like planning, test designing happens well before coding.
 Saves a lot of time.
of.

 Higher chance of success over the waterfall model.

 Proactive defect tracking – that is defects are found at early stage.
 Avoids the downward flow of the defects.
Pr

 Works well for small projects where requirements are easily understood.
Disadvantages of V-model:
 Very rigid and least flexible.
 Software is developed during the implementation phase, so no early prototypes of
the software are produced.

9
 Chapter-1
Basics of Software Testing and Testing Methods
 If any changes happen in midway, then the test documents along with requirement
documents has to be updated.
When to use the V-Model
 The V-shaped model should be used for small to medium sized projects where
requirements are clearly defined and fixed.
 The V-shaped model should be chosen when ample technical resources are available with

al
needed technical expertise.
 High confidence of customer s required for choosing the V-Shaped model approach.

aim
Since, no prototypes are produced, there is a very high risk involved in meeting customer
expectations.
Difference between Verification & Validation

Verification
1. Are you building it right?
aK Validation
1. Are you building the right thing?
em
2. Ensure that the software system 2. Ensure that functionalities meet the
meets all the functionality. intended behavior.
3. Verification takes place first and 3. Validation occurs after verification
Se

includes the checking for and mainly involves the checking

documentation, code etc. of the overall product.
4. Done by developers. 4. Done by Testers.
of.

5. Have static activities as it includes 5. Have dynamic activities as it

the reviews, walkthroughs, and includes executing the software
inspections to verify that software against the requirements.
Pr

is correct or not.
6. It is an objective process and no 6. It is a subjective process and
subjective decision should be involves subjective decisions on
needed to verify the Software. how well the Software works.

Quality Assurance, Quality Control, Testing

10
 Chapter-1
Basics of Software Testing and Testing Methods
Quality Assurance : A set of activities designed to ensure that the development and/or
maintenance process is adequate to ensure a system will meet its objectives.
Quality Control : A set of activities designed to evaluate a developed work product.
Testing : The process of executing a system with the intent of finding defects.

al
aim
aK
Give any four differences between Quality Assurance and Quality Control.
em
Quality Assurance Quality Control
1) Process oriented activities. 1) Product oriented activities.
2) QA is the process of managing for 2) QC is used to verify the quality of
quality. the output
Se

3) They measure the process, identify 3) They measure the product, identify
the deficiencies/weakness and the deficiencies/weakness and
suggest improvements. suggest improvements.
4) Relates to all products that will ever 4) Relates to specific product
of.

be created by a process

5) Activities of QA are Process 5) Activities of QC are Reviews and

Definition and Implementation, Testing
Pr

Audits and Training

6) Verification is an example of QA 6) Validation/Software Testing is an
example of QC
7) Preventive activities. 7) It is a corrective process.
8) Quality assurance is a proactive 8) Quality control is a reactive process.
process
9) QA is a managerial tool 9) QC is a corrective tool
10) It is done before Quality control 10) It is done after Quality assurance

11
 Chapter-1
Basics of Software Testing and Testing Methods
Methods of Testing
There are two methods of testing
1. Static testing
2. Dynamic testing
What is static testing

al
Static testing involves in reviewing the documents to identify the defects in the early stages of
SDLC.

aim
Example : if you go to a car showroom to buy a car. What do you do? You take a look at the
color, interiors and exteriors of the car. You have not started or taken a test drive yet but you have
done some kind of testing . That would be an example of static testing.
What is dynamic testing.
aK
Dynamic testing involves in the execution of code. It validates the output with the expected
outcome.
Example : Once you take a look at the car now you do the test drive so you can see how it
em
performed and is everything working well, as expected. That kind of testing would be an
example of dynamic testing
Se
of.
Pr

12
 Chapter-1
Basics of Software Testing and Testing Methods

al
aim
aK
em
The BOX Approach:
White Box testing
Explain white box testing with example ?
Se

1. White box testing is also known as Clear Box testing, Open Box testing, Structural
testing, Transparent Box testing, Code-Based testing, and Glass Box testing.
2. It focuses primarily on verifying the flow of inputs and outputs through the application,
of.

improving design and usability, strengthening security.

3. White Box Testing is defined as the testing of a software solution's internal structure,
Pr

design, and coding. In this type of testing, the code is visible to the tester. It is usually
performed by developers.
4. In white box testing, test cases are created by looking at the code to detect any Potential
failure scenarios.
5. Therefore, the test plans need to be updated before starting white box testing and only
after a stable build of the code is available.

13
 Chapter-1
Basics of Software Testing and Testing Methods
6. During white box testing, analyze the code of the application block and prepare test cases
for testing the functionality to ensure that the class is behaving in accordance with the
specifications and testing for robustness.
7. A failure of a white box test may result in a change that requires all black box testing to
be repeated and white box testing paths to be reviewed and possibly changed.

al
Example: A tester, usually a developer as well, studies the implementation code of a
certain field on a webpage, determines all legal (valid and invalid) AND illegal inputs

aim
and verifies the outputs against the expected outcomes, which is also determined by
studying the implementation code. The white box testing is done with respect to all
statements, variables, loops, structures, interface within the software.

aK
What do you verify in White Box Testing?
White box testing involves the testing of the software code for the following:
em
• Internal security loopholes
• Broken or poorly structured paths in the coding processes
• The flow of specific inputs through the code
Se

• Expected output
• The functionality of conditional loops
• Testing of each statement, object, and function on an individual basis
of.

White Box Testing Example

• Consider the following piece of code
Pr

14
 Chapter-1
Basics of Software Testing and Testing Methods

al
aim
The goal of White Box testing is to verify all the decision branches, loops, statements in
the code.
To exercise the statements in the above code, White Box test cases would be
• A = 1, B = 1
• A = -1, B = -3
White Box Testing Tools
aK
Below is a list of top white box testing tools.
em
• Veracode
• EclEmma
Se

• RCUNIT
• NUnit
• JSUnit
of.

• JUnit
• CppUnit
Pr

White box is further classified as

• Static Testing
• Structural testing

15
 Chapter-1
Basics of Software Testing and Testing Methods
Static Testing includes
1. Inspections
2. Structural walkthroughs
3. Technical review
1. Inspections

al
Describe Inspection under static testing.
 Inspections are the most formal type of reviews.

aim
 They are highly structured and require training for each participant.
 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.
 These forces someone else to learn and understand the material being presented,
aK
potentially giving a different slant and interpretation at the inspection meeting.
 The other participants are called inspectors.
 Each is tasked with reviewing the code from a different perspective, such as a User, a
em
tester, or a product support person.
 This helps bring different views of the product under review and very often Identifies
different bugs.
Se

 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.
of.

There are four roles in inspection:

1. Author of the code: the person who had written the code
Pr

2. Moderator: who is expected to formally run the inspection according to the process?
3. Inspectors: are the people who actually provide review comments for the code.
4. Scribe: who takes detail notes during the inspection meeting and circulates them to the
inspection team after the meeting.

• The author or moderator selects review team.

• The inspection team assembles at the agreed time for inspection meeting.

16
 Chapter-1
Basics of Software Testing and Testing Methods
• The moderator takes the team sequentially through the program code.
• If any defect is found they will classify it as minor or major.
• A scribe documents the defects.
• For major defects the review team meets again to check whether the bugs are resolved or
not.

al
Static testing- Structural Walkthrough
Describe structural walk through under static testing.

aim
 One of the static testing methods is structural walkthrough.
 In walkthroughs, a set of people look at the program code and raise questions for
the author.

aK
 The author explains the logic of the code and answers the questions.
 If the author is unable to answer some questions, he or she then takes those
questions and finds their answers.
em
1) Walkthroughs are the next step up in formality from peer reviews.
2) 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.
Se

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.
of.

4) Having at least one senior programmer as a reviewer is very important.

Pr

17
 Chapter-1
Basics of Software Testing and Testing Methods
Compare walk through and inspection (four point).

al
aim
3.Technical Review:
aK
Describe technical review under static testing
em
i. Formal Review
ii. Peer Reviews
Se

What is Formal Review? List four essential elements to a Formal Review.

(Meaning of formal review - 2 Marks, Four essential elements - 2 Marks)
Ans: A formal review is the process under which static white-box testing is performed. A formal
of.

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.
Pr

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.
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

18
 Chapter-1
Basics of Software Testing and Testing Methods
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 Examining
the Code.
4.Write a Report. The review group must produce a written report summarizing the results of

al
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

aim
they were found, and so on.

ii. Peer Reviews:

aK
 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.
 Sometimes called buddy reviews, this method is really more of a discussion.
em
 Peer reviews are often held with just the programmer who wrote the code and one or two
other programmers or testers acting as reviewers.
 Small group simply reviews the code together and looks for problems and oversights.
 To assure that the review is highly effective all the participants need to make sure that the
Se

four key elements of a formal review are in place: Look for problems , follow rules,
prepare for the review, and write a report.
of.

 Peer reviews are informal.

Pr

19
 Chapter-1
Basics of Software Testing and Testing Methods
Structural White Box Testing/Dynamic white box testing
Dynamic white box testing is also called as structural testing because you can see and use the
underlying structure of code to design and run your tests.
It is a measure which describes the degree of which the source code of the program has been
tested.

al
1. Code Functional Testing : FUNCTIONAL TESTING is a type of software testing that
validates the software system against the functional requirements/specifications.

aim
2. Code Coverage Testing: Code coverage determines which statements in a body of code have
been executed through a test run and which statements have not.

aK
Code Coverage testing is determining how much code is being tested. It can be calculated
using the formula: Code Coverage = (Number of lines of code exercised)/(Total Number of
lines of code) * 100%
em
3. Code Complexity Testing : used for measuring the complexity of a software program.
Se

Functional testing
• FUNCTIONAL TESTING is a type of software testing that validates the software system
against the functional requirements/specifications. ... Functional testing mainly involves black
of.

box testing and it is not concerned about the source code of the application.
• It uses black-box testing techniques, in which the tester has no knowledge of the internal system
logic.
Pr

Functional Testing Types

• Unit Testing.
• Integration Testing.
• System Testing.
• Regression Testing.
• Smoke Testing.
• Acceptance Testing.

20
 Chapter-1
Basics of Software Testing and Testing Methods
How is functional testing carried out?
 Functions (or features) are tested by feeding them input and examining the output.
 Functional testing ensures that the requirements are properly satisfied by the application. This
type of testing is not concerned with how processing occurs, but rather, with the results of
processing.
 Functional testing is important because it always verifies that your system is fixed for release.

al
Code Coverage testing

aim
What is Code coverage?
• Code coverage is a measure which describes the degree of which the source code of the program
has been tested.
• It is one form of white box testing which finds the areas of the program not exercised by a set of

•
test cases.
aK
Code coverage system gathers information about the running program.
Why use Code Coverage?
• It helps you to measure the efficiency of test implementation
em
• It offers a quantitative measurement.
• It defines the degree to which the source code has been tested.
Code Coverage Methods
Se

Following are major code coverage methods

 Statement Coverage
 Decision Coverage
of.

 Branch Coverage
 Condition Coverage
Statement Coverage
Pr

• Statement Coverage is a white box testing technique in which all the executable statements in
the source code are executed at least once.
• It is used for calculation of the number of statements in source code which have been executed.
• The main purpose of Statement Coverage is to cover all the possible paths, lines and statements in
source code.

Let's understand this with an example, how to calculate statement coverage.

21
 Chapter-1
Basics of Software Testing and Testing Methods
Source Code:

al
Scenario 1:

aim
If A = 3, B = 9

aK
The statements marked in blue color are those which are executed as per the scenario
em
Number of executed statements = 5,
Total number of statements = 7
Se

Statement Coverage: 5/7 = 71%

Scenario 2:
If A = -3, B = -9
of.
Pr

The statements marked in blue color are those which are executed as per the scenario.
Number of executed statements = 6
Total number of statements = 7

22
 Chapter-1
Basics of Software Testing and Testing Methods

Statement Coverage: 6/7 = 85%

But overall if you see, all the statements are being covered by 2nd scenario's considered. So we
can conclude that overall statement coverage is 100%.

al
What is covered by Statement Coverage?
1. Unused Statements

aim
2. Dead Code
3. Unused Branches
4. Missing Statements
Decision Coverage aK
1. Decision Coverage is a white box testing technique which reports the true or false outcomes of
each boolean expression of the source code.
2. The goal of decision coverage testing is to cover and validate all the accessible source code by
em
checking and ensuring that each branch of every possible decision point is executed at least once.
3. In this coverage, expressions can sometimes get complicated. Therefore, it is very hard to achieve
100% coverage. That's why there are many different methods of reporting this metric.
Se

4. All these methods focus on covering the most important combinations..

of.

Example of decision coverage

Consider the following code-
Pr

Scenario 1:
Value of a is 2

23
 Chapter-1
Basics of Software Testing and Testing Methods

The code highlighted in yellow will be executed. Here the "No" outcome of the decision If (a>5) is
checked.

al
Decision Coverage = 50%
Scenario 2:

aim
Value of a is 6

aK
The code highlighted in yellow will be executed. Here the "Yes" outcome of the decision If (a>5) is
checked.
Decision Coverage = 50%
em
Test Case Value of A Output Decision Coverage

1 2 2 50%
Se

2 6 18 50%
of.

Branch Coverage
 Branch Coverage is a white box testing method in which every outcome from a code
Pr

module(statement or loop) is tested.

 The purpose of branch coverage is to ensure that each decision condition from every branch is
executed at least once.
 It helps to measure fractions of independent code segments and to find out sections having no
branches.
For example, if the outcomes are binary, you need to test both True and False outcomes.
The formula to calculate Branch Coverage:

24
 Chapter-1
Basics of Software Testing and Testing Methods

Advantages of Branch coverage:

 Allows you to validate-all the branches in the code
 Helps you to ensure that no branched lead to any abnormality of the program's operation

al
 Branch coverage method removes issues which happen because of statement coverage testing

aim
 Allows you to find those areas which are not tested by other testing methods
Example : 1
Consider the following code:

aK
em
Se

Scenario : 1
of.

Test case : 1
A=7
B=5
Pr

25
 Chapter-1
Basics of Software Testing and Testing Methods

al
aim
Branch covered = 1
Branch coverage = no of branches executed / total number of branches
= ½ = 50%

Scenario 2:
Test case 2:
aK
em
A=5
B=7
Se
of.
Pr

Branch covered = 1
Branch coverage = no of branches executed / total number of branches
= ½ = 50%

26
 Chapter-1
Basics of Software Testing and Testing Methods

al
aim
By using 2 test cases we have 100% branch coverage
Total branch executed by both test cases = 2
Total branches = 2
By using these two test cases we can obtained 100% branch coverage

CODE COMPLEXITY TESTING

aK
Cyclomatic Complexity, V(G) :
em
 Cyclomatic complexity is a software metric used to measure the complexity of a program.
 It was developed by Thomas McCabe in 1976.
 It is the measure of the amount of logic in a code module of 3rd and 4th generation languages.
Se

 If V(G) is excessively high then it leads to a code which is at higher risk due to difficulty in
testing.
 The threshold value is 10.
of.

 When V(G) > 10; then the likelihood of code being unreliable is much higher.
 It must be remembered that a high V(G) shows a decreased quality in the code resulting in higher
defect that become costly to fix.
Pr

Cyclomatic Complexity
• The complexity number helps in understanding the complexity of a program .
• If this no. is large means program is highly complex and is high risk associative.
• If the no.is small means program is less complex and is less risk associative.

27
 Chapter-1
Basics of Software Testing and Testing Methods

al
aim
aK
em
BLACK BOX TESTING
Se
of.
Pr

 This method is named so because the software program, in the eyes of the tester, is like a
black box; inside which one cannot see.
 Black Box Testing is a software testing technique in which functionality of the software
under test is tested without looking at the internal coding structure.
 The tester would only know the “legal” inputs and what the expected outputs should be,
but not how the program actually arrives at those outputs.
 Also known as functional testing, behavioral testing, or specification-based testing.

28
 Chapter-1
Basics of Software Testing and Testing Methods
 Black box testing, which is also known as behavioral, opaque-box, closed-box,
specification-based, is a Software Testing method that analyses the functionality of a
software/application without knowing about the internal structure/design of the item that
is being tested
 It compares the input value with the output value.
 The main focus in black box testing is on the functionality of the system as a whole.

al
Steps :

aim
 Tester chooses some valid i/p's and checks whether S/W under test process them
correctly.
 Tester chooses some invalid i/p's and checks whether S/W under test process
them correctly.
aK
 Tester determines expected O/P's for all those I/P's
 Tester compares actual O/P's with expected O/P's.
em
 Defects if any are fixed and retested.

Requirement based testing

Se

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

Stages in Requirements based Testing:

 Defining Test Completion Criteria - Testing is completed only when all the functional
and non-functional testing is complete.
Pr

 Design Test Cases - A Test case has five parameters namely the initial state or
precondition, data setup, the inputs, expected outcomes and actual outcomes.
 Execute Tests - Execute the test cases against the system under test and document the
results.
 Verify Test Results - Verify if the expected and actual results match each other.

29
 Chapter-1
Basics of Software Testing and Testing Methods
 Verify Test Coverage - Verify if the tests cover both functional and non-functional
aspects of the requirement.
 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:

al
 Testing must be carried out in a timely manner.
 Testing process should add value to the software life cycle, hence it needs to be effective.

aim
 Testing the system exhaustively is impossible hence the testing process needs to be
efficient as well.
 Testing must provide the overall status of the project, hence it should be manageable.

Boundary Value Analysis

aK
 This is one of the software testing technique in which the test cases are designed to
em
include values at the boundary.
 If the input data is used within the boundary value limits, then it is said to be Positive
Testing.
Se

 If the input data is picked outside the boundary value limits, then it is said to be Negative
Testing.
 Boundary value analysis is another black box test design technique and it is used to find
of.

the errors at boundaries of input domain rather than finding those errors in the center of
input.
 Each boundary has a valid boundary value and an invalid boundary value. Test cases are
Pr

designed based on the both valid and invalid boundary values. Typically, we choose one
test case from each boundary.
There are three guidelines for boundary value analysis :
1) One test case for exact boundary values of input domains.
2) One test case for just below boundary value of input domains .
3) One test case for just above boundary values of input domains .

30
 Chapter-1
Basics of Software Testing and Testing Methods
Examples of Boundary value analysis concept are:
Consider a textbox which should accept number from 1 to 100
One test case for exact boundary values of input domains each means 1 and 100.
One test case for just below boundary value of input domains each means 0 and 99.
One test case for just above boundary values of input domains each means 2 and 101.
For Example: A system can accept the numbers from 1 to 10 numeric values. All

al
other numbers are invalid values. Under this technique, boundary values 0, 1,2, 9,10,11 can be
tested.

aim
Boundary values are validated against both the valid boundaries and invalid boundaries.
The Invalid Boundary Cases for the above example can be given as follows
0 - for lower limit boundary value
11 - for upper limit boundary value

Equivalence partitioning
aK
em
 In equivalence partitioning the range is divided into various classes and from each class
you test a single value, if it is pass the full class is pass and if it is fail the full class is
fail.
Se

 It saves time.
Examples of Equivalence Partitioning technique
Assume that there is a function of a software application that accepts a particular number of
of.

digits, not greater and less than that particular number. For example, an OTP number which
contains only six digits, less or more than six digits will not be accepted, and the application will
redirect the user to the error page.
Pr

1. 1. OTP Number = 6 digits

31
 Chapter-1
Basics of Software Testing and Testing Methods

al
aim
aK
em
Let's see one more example.
A function of the software application accepts a 10 digit mobile number.
1. 2. Mobile number = 10 digits
Se
of.
Pr

32
 Chapter-1
Basics of Software Testing and Testing Methods
In both examples, we can see that there is a partition of two equally valid and invalid partitions,
on applying valid value such as OTP of six digits in the first example and mobile number of 10
digits in the second example, both valid partitions behave same, i.e. redirected to the next page.
Another two partitions contain invalid values such as 5 or less than 5 and 7 or more than 7 digits
in the first example and 9 or less than 9 and 11 or more than 11 digits in the second example, and
on applying these invalid values, both invalid partitions behave same, i.e. redirected to the error

al
page.
We can see in the example, there are only three test cases for each example and that is also the

aim
principal of equivalence partitioning which states that this method intended to reduce the number
of test cases.

Positive and negative testing aK

Describe positive testing & negative testing. Also write test cases for them.
Positive Testing:
em
 Positive Testing is testing process where the system validated against the valid input data.
 In this testing tester always check for only valid set of values and check if an application
behaves as expected with its expected inputs.
Se

 The main intention of this testing is to check whether software application not showing
error when not supposed to & showing error when supposed to.
 Such testing is to be carried out keeping positive point of view & only execute the
of.

positive scenario.
 Positive Testing always tries to prove that a given product and project always meets the
Pr

requirements and specifications.

 Positive testing check the expected behavior of application.

Negative Testing:
Negative Testing is testing process where the system is validated against the invalid input data. A
negative test checks if a application behaves as expected with its negative inputs.

33
 Chapter-1
Basics of Software Testing and Testing Methods
Such testing is to be carried out keeping negative point of view & only execute the test cases for
only invalid set of input data.
• Positive testing is carried out against the valid inputs,
• In negative testing the application is validated against the invalid inputs.
The objective behind this is to make sure the system shows error when it's supposed to and does
not show error when it's not supposed to.

al
Positive Test Scenarios:
· Password textbox should accept 6 characters

aim
· Password textbox should up to 20 characters
· Password textbox should accept any value in between 6-20 char’s length.
· Password textbox should accept all numeric & alphabets values.
Negative Test scenarios: aK
· Password textbox should not accept less than 6 characters
· Password textbox should not exceeds more than 20 characters
em
· Password textbox should not accept special characters.
Practical Examples of positive and negative testing
Se

Here, the user is expected to put in only numerical values as shown below:
of.
Pr

Let’s establish some ground rules here as well:

Requirements:
• The ID has to be a number between 1- 250
• The ID is mandatory.
Therefore here are some positive and negative test scenarios for this particular pane.
Positive test scenarios: Below are some positive testing scenarios for this particular pane.

34
 Chapter-1
Basics of Software Testing and Testing Methods
1. 12 (Entering a valid value between the range specified)
2. 1,250 (Entering the boundary value of the range specified)
Negative test scenarios: Below are some negative testing scenarios for this particular pane.
1. Ab (Entering text instead of numbers)
2. 0, 252 (Entering out of boundary values)
3. Null input

al
4. -2 (Entering out of range values)

aim
5. +56 (Entering a valid value prefixed by a special character)

Compare Positive and negative testing

Positive Testing

 Test for a specific number of user

aK Negative Testing


Test for excessive (load) inputs
inputs
em
 
Checks for valid set of values Checks for invalid set of values

 Its done by giving the positive point of  Its done by keeping the negative point
Se

view Eg: Numbers like 9999999999 of view Eg: 99999abcde

 Done to identify known set of test  Done with unknown set of test
conditions conditions
of.

 To check whether all client 

Anything that is not mentioned in the
requirements are met while doing the
client requirement is tested
Pr

project

 In positive test scenarios, password test  Password test box should not exceed
should accept 6- 20 characters more than 20 characters

 Accept all numeric and alphabetic 

Do not accept special character
values

Distinguish between white box testing and black box testing.(any six) 6M

35
 Chapter-1
Basics of Software Testing and Testing Methods

White box testing Black box testing

1.This needs the knowledge of software in 1. This does not need the knowledge of
detail. software in detail

2. It is also called as transparent box or 2.It is also called as opaque box, dark box
glass box testing. testing

al
3.This can be performed by only developers 3. This can be performed by end users or
and professional testers. anyone.

aim
4. The testing is proper here with respect to 4. The testing is only by trial and error
the domain ,data etc. methods.

5. It is suited for algorithm testing. 5. It is not suited for algorithm testing.

6. It is exhaustive and time consuming.

7. It is a structural testing of a system.

aK
6. It is least exhaustive and least time
consuming.

7. It is a behavioral testing of a system.

em
MSBTE Questions
Se

1. Define software testing.

2. List the objectives of software testing.
3. Describe the roles and responsibilities of a Test Leader.
of.

4. Define following terms-Failure, Error, Defect and Bug.

5. Explain when to start and stop testing.
Pr

6. Explain verification and validation with neat diagram

7. Differentiate between Verification and Validation.
8. Define software Quality Assurance and software Quality Control.
9. Give any four differences between Quality Assurance and Quality Control.
10. Define Static testing and Dynamic testing.
11. Difference between Static testing and Dynamic testing.
12. Explain white box testing with example ?
36
 Chapter-1
Basics of Software Testing and Testing Methods
13. Describe Inspection under static testing.
14. Describe technical review under static testing
i. Formal Review
ii. Peer Reviews
15. What is Formal Review? List four essential elements to a Formal Review.
16. Describe BLACK BOX TESTING

al
17. What is Requirement based testing. What are the Stages in Requirements based Testing:
18. Describe Boundary Value Analysis . What are three guidelines for boundary value

aim
analysis
19. What is Equivalence partitioning .Explain with example
20. Describe positive testing & negative testing. Also write test cases for them.
aK
21. Positive testing is carried out against the valid inputs,
22. In negative testing the application is validated against the invalid inputs.
23. Name some Positive Test Scenarios:
em
24. Name some Negative Test Scenarios:
25. Compare Positive and negative testing
26. Distinguish between white box testing and black box testing.(any six)
Se
of.
Pr

37