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

 To assure the quality of the product. Quality software is bug free, delivered on time and
within budget, meets customer requirements and is maintainable.
 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?

 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
correctness and accuracy of working.
 A successful test is one that uncovers an as-yet-undiscovered error.

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
 Creating good test cases : A good test case is the one that has a high probability of
finding an undiscovered error.
 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.
 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.

1
 Chapter-1 Basics of Software Testing and Testing Methods

Testing Principles
#1) Testing Shows the Presence of Defects
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 free.
The objective of testing is to find more and more hidden defects using different techniques
and methods.
Testing can reveal undiscovered defects and if no defects are found then it does not mean
that the software is defect free.
Example 1:
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
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.
Example 2:
We have seen several advertisements for soaps, toothpaste, handwash or disinfectant sprays etc
on television.
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) 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.

2
 Chapter-1 Basics of Software Testing and Testing Methods

 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
immediately rather than fixing them in the development phase.

#3) Exhaustive Testing is Not Possible

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.
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
cost. Hence it is always said that exhaustive testing is practically not possible.

#4) Testing is Context-Dependent

Different domains are tested differently, thus testing is purely based on the context of the
domain or application.
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

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
and again over the period of time then these set of tests are not capable enough to
identify new defects in the system.

3
 Chapter-1 Basics of Software Testing and Testing Methods

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

#7) Absence of Error

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
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
or in the production environment.

Software testing is done for many reasons

• To check the reliability of the software
• To ensure that the software does not contain any bug.
• 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

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

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.

4
 Chapter-1 Basics of Software Testing and Testing Methods

Fault : It is an anomaly in the software that may cause it to behave incorrectly, and not
according to its specification.

Defect : It can be simply defined as a variance between expected and actual result. It is the
deviation of the customer requirement.

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.

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

Reasons for occurrence of BUGS

 Specification not detailed enough
 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.
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
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
objective, such as to exercise a particular program path or to verify compliance with a
specific requirement.
Different Skills of software tester :
5
 Chapter-1 Basics of Software Testing and Testing Methods

 Communication skills
 Domain knowledge
 Desire to learn
 Technical skills
 Analytical skills
 Planning
 Integrity
 Curiosity
 Think from users perspective
 Be a good judge for product

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

Entry criteria, specifies when that phase can be started .

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.
 All requirements coverage has been achieved.
 All severe bugs are resolved.
 Testing Deadlines
6
 Chapter-1 Basics of Software Testing and Testing Methods

 Management decision.

Verification versus Validation

Verification
“Are we building the product right:
The software should conform to its specification.
Validation
“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.

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

Verification Phase:
1. Overall Business Requirement: In this first phase of the development cycle, the product
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,
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,
the final decision is taken.

7
 Chapter-1 Basics of Software Testing and Testing Methods

4. Low level design: In this phase the detailed integral design for all the system modules is
specified.
5. Coding:. A suitable programming language is decided based on requirements. Coding is done
based on the coding guidelines & standards.

Validation:

Unit Testing: Unit tests designed in the module design phase are executed on the code during
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.
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.

8
 Chapter-1 Basics of Software Testing and Testing Methods

Advantages of V-model:
 Simple and easy to use.
 Testing activities like planning, test designing happens well before coding.
 Saves a lot of time.
 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.
 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.
 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
needed technical expertise.
 High confidence of customer s required for choosing the V-Shaped model approach.
Since, no prototypes are produced, there is a very high risk involved in meeting customer
expectations.
Difference between Verification & Validation

Verification Validation
1. Are you building it right? 1. Are you building the right thing?
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
includes the checking for and mainly involves the checking
documentation, code etc. of the overall product.

9
 Chapter-1 Basics of Software Testing and Testing Methods

4. Done by developers. 4. Done by Testers.

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

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.

Give any four differences between Quality Assurance and Quality Control.
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
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
be created by a process
10
 Chapter-1 Basics of Software Testing and Testing Methods

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

Definition and Implementation, Testing
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

Methods of Testing
There are two methods of testing
1. Static testing
2. Dynamic testing
What is static testing
Static testing involves in reviewing the documents to identify the defects in the early stages of
SDLC.
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.
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
performed and is everything working well, as expected. That kind of testing would be an
example of dynamic testing

11
 Chapter-1 Basics of Software Testing and Testing Methods

The BOX Approach:

White Box testing
Explain white box testing with example ?
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,
improving design and usability, strengthening security.
3. White Box Testing is defined as the testing of a software solution's internal structure,
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.
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.
12
 Chapter-1 Basics of Software Testing and Testing Methods

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.

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

What do you verify in White Box Testing?

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

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

• A = -1, B = -3
White Box Testing Tools
Below is a list of top white box testing tools.
• Veracode
• EclEmma
• RCUNIT
• NUnit
• JSUnit
• JUnit
• CppUnit

White box is further classified as

• Static Testing
• Structural testing

Static Testing includes

1. Inspections
2. Structural walkthroughs
3. Technical review
1. Inspections
Describe Inspection under static testing.
 Inspections are the most formal type of reviews.
 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,
potentially giving a different slant and interpretation at the inspection meeting.
 The other participants are called inspectors.
14
 Chapter-1 Basics of Software Testing and Testing Methods

 Each is tasked with reviewing the code from a different perspective, such as a User, a
tester, or a product support person.
 This helps bring different views of the product under review and very often Identifies
different bugs.
 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.

There are four roles in inspection:

1. Author of the code: the person who had written the code
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.
• 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.

Static testing- Structural Walkthrough

Describe structural walk through under static testing.
 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.
 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.
1) Walkthroughs are the next step up in formality from peer reviews.

15
 Chapter-1 Basics of Software Testing and Testing Methods

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

Compare walk through and inspection (four point).

3.Technical Review:
Describe technical review under static testing
i. Formal Review
ii. Peer Reviews

16
 Chapter-1 Basics of Software Testing and Testing Methods

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
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.
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 Examining
the Code.
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.

ii. Peer Reviews:

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

17
 Chapter-1 Basics of Software Testing and Testing Methods

 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.
 Peer reviews are informal.

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.

1. Code Functional Testing : FUNCTIONAL TESTING is a type of software testing that

validates the software system against the functional requirements/specifications.

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

3. Code Complexity Testing : used for measuring the complexity of a software program.

Functional testing

18
 Chapter-1 Basics of Software Testing and Testing Methods

• FUNCTIONAL TESTING is a type of software testing that validates the software system
against the functional requirements/specifications. ... Functional testing mainly involves black
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.
Functional Testing Types
• Unit Testing.
• Integration Testing.
• System Testing.
• Regression Testing.
• Smoke Testing.
• Acceptance Testing.
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.

Code Coverage testing

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.
• Code coverage system gathers information about the running program.
Why use Code Coverage?
• It helps you to measure the efficiency of test implementation
• It offers a quantitative measurement.
• It defines the degree to which the source code has been tested.
Code Coverage Methods
Following are major code coverage methods
 Statement Coverage

19
 Chapter-1 Basics of Software Testing and Testing Methods

 Decision Coverage
 Branch Coverage
 Condition Coverage
Statement Coverage
• 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.

Source Code:

Scenario 1:
If A = 3, B = 9

The statements marked in blue color are those which are executed as per the scenario
Number of executed statements = 5,
Total number of statements = 7
Statement Coverage: 5/7 = 71%
Scenario 2:
If A = -3, B = -9

20
 Chapter-1 Basics of Software Testing and Testing Methods

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

Statement Coverage: 6/7 = 85%

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

What is covered by Statement Coverage?

1. Unused Statements
2. Dead Code
3. Unused Branches
4. Missing Statements
Decision Coverage
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
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.
4. All these methods focus on covering the most important combinations..

Example of decision coverage

Consider the following code-

21
 Chapter-1 Basics of Software Testing and Testing Methods

Scenario 1:
Value of a is 2

The code highlighted in yellow will be executed. Here the "No" outcome of the decision If (a>5) is
checked.
Decision Coverage = 50%
Scenario 2:
Value of a is 6

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

Test Case Value of A Output Decision Coverage

1 2 2 50%

2 6 18 50%

Branch Coverage
 Branch Coverage is a white box testing method in which every outcome from a code
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.
22
 Chapter-1 Basics of Software Testing and Testing Methods

 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:

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
 Branch coverage method removes issues which happen because of statement coverage testing
 Allows you to find those areas which are not tested by other testing methods
Example : 1
Consider the following code:

Scenario : 1
Test case : 1
A=7
B=5

23
 Chapter-1 Basics of Software Testing and Testing Methods

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

Scenario 2:
Test case 2:
A=5
B=7

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

24
 Chapter-1 Basics of Software Testing and Testing Methods

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

Cyclomatic Complexity, V(G) :
 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.
 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.
 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.
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.

25
 Chapter-1 Basics of Software Testing and Testing Methods

BLACK BOX TESTING

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

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.

Steps :
 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.
 Tester determines expected O/P's for all those I/P's
 Tester compares actual O/P's with expected O/P's.
 Defects if any are fixed and retested.

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 non-functional attributes such as
performance, reliability or usability.
Stages in Requirements based Testing:
 Defining Test Completion Criteria - Testing is completed only when all the functional
and non-functional testing is complete.
 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.
 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.

27
 Chapter-1 Basics of Software Testing and Testing Methods

Requirements Testing process:

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

 This is one of the software testing technique in which the test cases are designed to
include values at the boundary.
 If the input data is used within the boundary value limits, then it is said to be Positive
Testing.
 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
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
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 .
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

28
 Chapter-1 Basics of Software Testing and Testing Methods

other numbers are invalid values. Under this technique, boundary values 0, 1,2, 9,10,11 can be
tested.
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
 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.
 It saves time.
Examples of Equivalence Partitioning technique
Assume that there is a function of a software application that accepts a particular number 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.
1. 1. OTP Number = 6 digits

29
 Chapter-1 Basics of Software Testing and Testing Methods

Let's see one more example.

A function of the software application accepts a 10 digit mobile number.
1. 2. Mobile number = 10 digits

30
 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
page.
We can see in the example, there are only three test cases for each example and that is also the
principal of equivalence partitioning which states that this method intended to reduce the number
of test cases.

Positive and negative testing

Describe positive testing & negative testing. Also write test cases for them.
Positive Testing:
 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.
 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
positive scenario.
 Positive Testing always tries to prove that a given product and project always meets the
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.
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,
31
 Chapter-1 Basics of Software Testing and Testing Methods

• 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.
Positive Test Scenarios:
· Password textbox should accept 6 characters
· 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:
· Password textbox should not accept less than 6 characters
· Password textbox should not exceeds more than 20 characters
· Password textbox should not accept special characters.
Practical Examples of positive and negative testing
Here, the user is expected to put in only numerical values as shown below:

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

32
 Chapter-1 Basics of Software Testing and Testing Methods

2. 0, 252 (Entering out of boundary values)

3. Null input
4. -2 (Entering out of range values)
5. +56 (Entering a valid value prefixed by a special character)

Compare Positive and negative testing

Positive Testing Negative Testing

 Test for a specific number of user

 Test for excessive (load) inputs
inputs

 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
view Eg: Numbers like 9999999999 of view Eg: 99999abcde

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

 To check whether all client

 Anything that is not mentioned in the
requirements are met while doing the
client requirement is tested
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

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

33
 Chapter-1 Basics of Software Testing and Testing Methods

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

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. 6. It is least exhaustive and least time

consuming.

7. It is a structural testing of a system. 7. It is a behavioral testing of a system.

MSBTE Questions
1. Define software testing.
2. List the objectives of software testing.
3. Describe the roles and responsibilities of a Test Leader.
4. Define following terms-Failure, Error, Defect and Bug.
5. Explain when to start and stop testing.
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 ?
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

34
 Chapter-1 Basics of Software Testing and Testing Methods

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
analysis
19. What is Equivalence partitioning .Explain with example
20. Describe positive testing & negative testing. Also write test cases for them.
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:
24. Name some Negative Test Scenarios:
25. Compare Positive and negative testing
26. Distinguish between white box testing and black box testing.(any six)

35