Unit – 5

Software Coding &

Testing
Outline
• Coding Standard & Coding
Guidelines
• Code Review
• Software Documentation
• Software Testing
• Testing Strategies
• Testing Conventional
Applications
• White Box Testing
• Black Box Testing
• Testing Techniques and Test Case
• Test Suites Design
• Testing Object Oriented
Applications
• Testing Web and Mobile
Applications
Coding Standard
• System design can be transformed into implementation
model.
• Goal – To implement the design in the best possible
manner.
• Objectives of coding are –
• Programs developed in coding should be readable.
• Should execute efficiently.
• The program should utilize less amount of memory.
• The programs should not be lengthy.
• Good software development organizations want their
programmers to maintain to some well-defined and
standard style of coding called coding standards.
• Coding standards are collections of coding rules,
guidelines, and best practices.
Coding Standard cont.
• The purpose of Having Coding Standards are :
o A coding standard gives a uniform appearance to the
codes written by different engineers.
o It improves readability, and maintainability of the code
and it reduces complexity also.
o It helps in code reuse and helps to detect error easily.
o It promotes sound programming practices and increases
efficiency of the programmers.
• A coding standard lists several rules to be followed such
as, the way variables are to be named, the way the
code is to be laid out, error return conventions, etc.
Coding Standard cont.
Some of the coding standards are given below :
• Limited use of global
• Standard headers for different modules
• Naming conventions for local variables, global
variables, constants and functions
• Indentation
• Error return values and exception handling
conventions
• Avoid using a coding style that is too difficult to
understand
• Avoid using an identifier for multiple purposes
• Code should be well documented
• Length of functions should not be very large
• Try not to use GOTO statement
What Are Coding Rules and
Guidelines?
Coding rules and guidelines ensure that software
is:

• Safe: It can be used without causing harm.

• Secure: It can’t be hacked.
• Reliable: It functions as it should, every time.
• Testable: It can be tested at the code level.
• Maintainable: It can be maintained, even as your
codebase grows.
• Portable: It works the same in every environment.
Coding Guidelines
Advantages of Coding Guidelines:

• Coding guidelines increase the efficiency of the

software and reduces the development time.
• Coding guidelines help in detecting errors in the
early phases, so it helps to reduce the extra cost
incurred by the software project.
• If coding guidelines are maintained properly, then
the software code increases readability and
understandability thus it reduces the complexity of
the code.
• It reduces the hidden cost for developing the
software.
Software Quality
• Software Quality remains an issue
• Who is to blame?
• Customers blame developers - Arguing that careless
practices lead to low-quality software.
• Developers blame Customers & other stakeholders -
Arguing that irrational delivery dates and continuous
stream of changes force to deliver software before it
has been fully validated.
• Who is Right? Both – and that’s the problem.
Code Review
• Code review is a software quality assurance activity in
which one or several people check a program mainly by
viewing & reading parts of its source code, & they do so
after implementation or as an interruption of
implementation.
• Code Review is carried out after the module is
successfully compiled & all the syntax errors have been
eliminated.
• Code Reviews are extremely cost-effective strategies
for reduction in coding errors and to produce high
quality code.
Code Walk Through
• Code walk through is an informal code analysis
technique.
• The main objectives of the walk through are to
discover the algorithmic and logical errors in the code.
• A few members of the development team are given the
code few days before the walk through meeting to read
and understand code.
• Each member selects some test cases and simulates
execution of the code by hand.
• The members note down their findings to discuss these
in a walk through meeting where the coder of the
module is present.
Code Inspection
• The aim of Code Inspection is to discover some
common types of errors caused due to improper
programming.
• In other words, during Code Inspection the code is
examined for the presence of certain kinds of errors.
o For instance, consider the classical error of writing a
procedure that modifies a parameter while the
calling routine calls that procedure with a constant
actual parameter.
o It is more likely that such an error will be discovered
by looking for these kinds of mistakes in the code.
• In addition, commitment to coding standards is also
checked.
Software Documentation
• Various kinds of software documents need to be
developed during software development process.
• The software document includes source code,
executable files, user manual, SRS, Design document,
test document, installation manual & so on.
• Purpose –
• Enhance the readability, understandability &
maintainability of software product.
• Reduce the effort & time required for maintenance.
• Useful in exploring the system effectively.
• Used to keep track of the progress of the project.
• Help in overcoming the manpower turnover
problem.
Software Documentation
cont.
• Different types of software documents can broadly be
classified into the following :
Internal Documentation
• It is a part of source code.
• It is provided through appropriate module headers and
comments embedded in the source code.
• It is also provided through the useful variable names,
module and function headers, code indentation, code
structuring, use of enumerated types and constant
identifiers, use of user-defined data types, etc.
• Even when code is carefully commented, meaningful
variable names are still more helpful in understanding a
piece of code.
• Good organizations ensure good internal documentation
by appropriately formulating their coding standards and
guidelines.
External Documentation

• External documentation can be done by creating

various types of supporting documents such as users’
manual, SRS document, design document, test
documents & so on.
• These documents are normally created during the
software development life cycle activities.
• A systematic software development style ensures that
all these documents are produced in an orderly fashion.
Software Testing
• Testing is the process of exercising a program with the
specific intent of finding errors prior to delivery to the
end user.
• Software testing is a critical element of software
quality assurance & represents the ultimate review of
specification, design & coding.
Software Testing cont.
Purpose – To ensure whether the software functions
appear to be working according to specification, design
& coding.

Objectives
According to Glen Myers the testing objectives are :
• Testing is a process of executing a program with
the intend of finding an error.
• A good test case is one that has high probability
of finding an undiscovered error.
• A successful test is one that uncovers an as-yet
undiscovered error.
Major objective – to deign tests that systematically
uncover types of error with minimum time & effort.
Who Test the Software
Developer -
• Understands the system but, will test
“gently” &, is driven by “delivery”
• Testing without plan is of no point - It
wastes time & effort

Tester -
• Must learn about the system, but, will
attempt to break it &, is driven by
quality
• Testing need a strategy Development
team needs to work with Test team,
“Egoless Programming”
When to Test the Software?
Verification & Validation
Verification - Are we building the product right?
• The objective of Verification is to make sure that the
product being develop is as per the requirements &
design specifications.

Validation - Are we building the right product?

• The objective of Validation is to make sure that the
product actually meet up the user’s requirements, &
check whether the specifications were correct in the
first place.
Verification & Validation
cont.
Verification • Process of evaluating
• Process of evaluating products software at the end of the
of a development phase to find development to determine
out whether they meet the whether software meets the
specified requirements. customer expectations and
requirements.
• • Activities involved: Testing
Activities involved: Reviews,
Meetings and Inspections like black box testing, white
box testing, gray box
• Carried out by QA team testing
• • Carried out by testing team
Execution of code is not comes
• Execution of code is comes
under Verification
• Explains whether the outputs under Validation
• Describes whether the
are according to inputs or not
• Cost of errors caught is less software is accepted by the
user or not
• Cost of errors caught is high
Software Testing Strategy
• We begins by ‘testing-in-the-small’ & move toward
‘testing-in-the-large’.
• Various testing strategies for conventional software
are Testing strategies
o Unit testing
o Integration testing
o Validation testing
o System testing

Software development
stages
Testing Strategy
• Unit testing – In this type of testing techniques are
applied to detect the errors from each software
component individually.
• Integration testing – It focuses on issues associated
with verification & program construction as components
begin interacting with one another.
• Validation testing – It provides assurance that the
software validation criteria meets all functional, behavioral
& performance requirements.
• System testing – In system testing all system
elements forming the system is tested as a whole.
Unit testing
• Unit is the smallest part of a software
system which is testable.
• It may include code files, classes and
methods which can be tested
individually for correctness.
• It concentrate on each unit of the software as
implemented in source code.
• It focuses on each component individual, ensuring that it
functions properly as a unit.
• The unit test focuses on the internal processing logic
and data structures within the boundaries of a
component.
Unit testing cont.
The various tests that are conducted during the unit test
are described as :
• Module interfaces are tested for proper information flow in
and out of the program unit.
• Local data are examined to ensure that integrity is
maintained.
• Boundary conditions are tested to ensure that the module
operates properly at boundaries established to limit or
restricted processing.
• All the independent paths are tested for ensuring that all
statements in the module have been executed only once.
• All error handling paths should be tested.
• Drivers & stub software need to be developed to test
incomplete software.
• The unit testing is simplified when a component with high
cohesion is designed.
Driver & Stub (Unit Testing)
• Driver – is a program that accepts
the test data & prints the relevant
results.
• Stub – is a subprogram that uses
the module interfaces & performs
the minimal data manipulation
• Component-testing if may be done in
(Unit Testing)
[Link] rest of the system
isolation
• In such case the missing software is replaced by Stubs
and Drivers and simulate the interface between the
software components in a simple manner

A B C
Driver & Stub (Unit Testing)
cont.–
Driver
• Driver and/or Stub software must be developed for each unit
test
• A driver is nothing more than a "main program"
• Driver
• Used in Bottom up approach
• Lowest modules are tested first.
• Simulates the higher level of components
• Dummy program for Higher level component
Stub –
• Stubs serve to replace modules that are subordinate (called
by) the component to be tested.
• A stub or "dummy subprogram"
• Stubs
• Used in Top down approach
• Top most module is tested first
• Simulates the lower level of components
• Dummy program of lower level components
Integration testing
• Integration testing is a level of
software testing where individual
units / components are combined
and tested as a group.
• It is the process of testing the interface between two
software units or modules
• Objective – to take unit tested components & build a
program structure that has been dictated by software
design.
• The focus of integration testing is to uncover errors in :
• Design & construction of software architecture.
• Integrated functions or operations at subsystem level.
• Interfaces & interactions between them.
• Resource integration and/or environment integration.
Integration testing cont.
• The integration testing can be
carried out using 2 approaches.
• Non-incremental integration
• Incremental integration
Integration testing
approach

Non-incremental Incremental integration

integration
Big bang Top down testing
Bottom up testing
Regression testing
Smoke testing
Big bang
• Big Bang Testing is an Integration testing approach in
which all the components or modules are integrated
together at once and then tested as a unit.
• This combined set of components is considered as an
entity while testing.
• If all of the components in the unit are not completed,
the integration process will not execute.
• Advantages:
• Convenient for small systems.
• Disadvantages:
• Hard to debug
• It is not easy to isolate errors while testing.
• In this approach it is not easy to validate test results.
• Since the Integration testing can commence only after "all" the
modules are designed, the testing team will have less time for
execution in the testing phase.
Incremental testing
• In the Incremental Testing approach, testing is done by
integrating two or more modules that are logically
related to each other and then tested for proper
functioning of the application.
• Then the other related modules are integrated
incrementally and the process continues until all the
logically related modules are integrated and tested
successfully.
• An incremental construction strategy includes :
• Top down integration testing
• Bottom up integration testing
• Regression testing
• Smoke testing
Top down integration
testing
• Top down testing is an incremental approach in which
modules are integrated by moving down through the
control structure.
• High level modules are tested first and then low-level
modules and finally integrated the low level modules to
high level to ensure the system is working as intended
• Stubs are used as a temporary module, if a module is
not ready for integration testing.
Bottom up integration
testing
• In bottom up integration the modules at the lowest
levels are integrated at first, then integration is done by
moving upward through the control structure.
• Lowest level modules are tested first and then high-level
modules and finally integrated the high level modules to
low level to ensure the system is working as intended.
• Drivers are used as a temporary module, if a module is
not ready for integration testing.
Regression testing
• Regression testing is used to check for defects
propagated to other modules by changes made to
existing program.
• Thus regression testing is used to reduce the side effects
of the changes.
• Repeated testing of an already tested program, after
modification, to discover any defects introduced or
uncovered as a result of the changes in the software
being tested
• Regression testing is done by re-executing the tests
against the modified application to evaluate whether the
modified code breaks anything which was working
earlier
• Anytime we modify an application, we should do
regression testing
• It gives confidence to the developers that there is no
When to do regression
testing?
• When new functionalities are added to the application
o E.g. A website has login functionality with only Email.
Now the new features look like “also allow login using
Facebook”
• When there is a change requirement
o Forgot password should be removed from the login
page
• When there is a defect fix
o E.g. assume that “Login” button is not working and
tester reports a bug. Once the bug is fixed by
developer, tester tests using this approach
• When there is a performance issue
o E.g. loading a page takes 15 seconds. Reducing load
time to 2 seconds
• When there is an environment change
o E.g. Updating database from MySQL to Oracle
Smoke testing
• The smoke testing is a kind of integration testing
technique used for time critical projects wherein the
project needs to be assessed on frequent basis.
• This test is performed after each Build Release
• Smoke testing verifies – Build Stability
• This testing is performed by “Tester” or “Developer”
• This testing is executed for Integration Testing, System
Testing & Acceptance Testing
• What to Test?
• All major and critical functionalities of the application is
tested
• It does not go into depth to test each functionalities
• This does not incudes detailed testing for the build
Validation testing
• The process of evaluating software during the
development process or at the end of the development
process to determine whether it satisfies specified
business requirements.
• Validation Testing ensures that the product actually meets the
client's needs.
• It provides final assurance that software meets all
informational, functional, behavioral, and performance
requirements.
• In validation testing the main focus is to uncover errors
in
o System input/output
o System functions & information data
o System interfaces with external parts
o User interfaces
o System behavior & performance
Validation testing cont.
• When custom software is build for one customer, a
series of acceptance tests are conducted to validate all
requirements.
• It is conducted by end user rather then software
engineers.
• If software is developed as a product to be used by
many customers, it is impractical to perform formal
acceptance tests with each one.
• Most software product builders use a process called
alpha and beta testing to uncover errors that only the
end user seems able to find.
Acceptance testing
• The acceptance testing is a kind of testing
conducted to ensure that the software
works correctly in the user work
• environment.
It is a level of the software testing where a system is
tested for acceptability.
• The purpose of this test is to evaluate the system’s
compliance with the business requirements.
• It is a formal testing conducted to determine whether or
not a system satisfies the acceptance criteria with
respect to user needs, requirements, and business
processes.
• It enables the customer to determine, whether or not to
accept the system.
• It can be conducted over a period of weeks or months.
Acceptance testing cont.
• The types of acceptance are
• Alpha test
• Beta test
• Alpha test –
• The alpha testing is a testing in which the version of
complete software is tested by the customer under the
supervision of developer.
• Testing is performed at developer’s site.
• The software is used in natural setting in presence of
developer.
• Test is conducted in controlled environment.
• Beta test-
• The beta testing is a testing in which the version of software
is tested by the customer without the developer being
present.
• Testing is performed at customer’s site.
• The end user records the problems & report them to
developer.
• The developer then makes appropriate modification.
System testing
• System testing is a level of testing that
validates the complete & fully
integrated software product.
• The purpose of a system test is to evaluate the end-
to-end system specifications.
• In system testing the software & other system
elements are tested.
• To test computer software, you spiral out in a
clockwise direction along streamlines that increase
the scope of testing with each turn.
• System testing verifies that all elements mesh
properly & overall system function/performance is
achieved.
• System testing is a series of tests conducted to fully
exercise the computer-based system.
System testing cont.
Various types of system tests are
• Recovery testing
• Security testing
• Stress testing
• Performance testing

The main focus of such testing is to test

• System functions & performance.
• System reliability & recoverability (recovery test).
• System installation (installation test).
• System behavior in the special conditions (stress test).
• System user operations (acceptance/alpha test).
• Hardware & software integration & collaboration
• Integration of external software & the system.
Types of System testing
Recovery Testing
• Recovery testing is intended to check the
system’s ability to recover from failures.
• The software is forced to fail & then it is
verified whether the system recovers
properly or not.
• If recovery is automatic (performed by the
system itself)
o Re-initialization, check pointing mechanisms,
data recovery, and restart are evaluated for
correctness.
• If recovery requires human intervention
o The mean-time-to-repair (MTTR) is evaluated
to determine whether it is within acceptable
limits.
Types of System testing
cont.
Security Testing
• Security testing verifies that system
protection mechanism prevent improper
penetration or data alteration.
• During this test, the tester plays the role of the
individual who desires to penetrate the system.

Stress Testing
• Determines breakpoint of a system to
establish maximum service level.
• The system is executed in a manner that
demands resources in abnormal quality,
frequency or volume.
• A variation of stress testing is a technique called
sensitivity testing.
• It is a testing in which it’s tried to uncover data
from a large class of valid data that may cause
instability.
Types of System testing
cont.
Performance Testing
• Evaluates the run time performance of the
software, especially real time software.
• Resource utilization such as CPU load,
throughput, response time, memory usage
can be measured.
• For big systems involving many users
connecting to servers, performance testing
is very difficult.
• Beta testing is useful for performance
testing.
Testing Conventional
Applications
There are two general approaches for the software testing.
• White box testing (Glassbox testing) - White box
testing is a testing technique, that examines the
program structure and derives test data from the
program logic/code. The other names of glass box
testing are clear box testing, open box testing, logic
driven testing or path driven testing or structural
testing.
• Black box testing - Black-box testing is a method of
software testing that examines the functionality of an
application based on the specifications. It is also
known as Specifications based testing. Independent
Testing Team usually performs this type of testing
during the software testing life cycle.
White box testing
• White box testing is a software testing method in which
the internal structure/ design/ implementation of the
item being tested is known to the tester.
• It is like the work of a mechanic who examines the
engine to see why the car is not moving.
• Focus is on ensuring that even abnormal invocations are
handled gracefully.
• Using white-box testing methods, you can derive test
cases that
o Guarantee that all independent paths within a module
have been exercised at least once
o Exercise all logical decisions on their true and false sides
o Execute all loops at their boundaries
o Exercise internal data structures to ensure their validity
White box testing cont.
• Why is it called White box testing ? - Because here the
testers require knowledge of how the software is
implemented.
• It is applicable to the following levels of software testing
o Unit Testing: For testing paths within a unit
o Integration Testing: For testing paths between units
o System Testing: For testing paths between subsystems
• Goal - to ensure that all statements and conditions have
been executed at least once ...
Why and When White-Box Testing:
• White box testing is mainly used for detecting logical
errors in the program code.
• It is used for debugging a code, finding random
typographical errors, and uncovering incorrect
programming assumptions.
• White box testing is done at low level design and
implementable code.
• It can be applied at all levels of system development
especially Unit, system and integration testing.
• White box testing can be used for other development
artifacts like requirements analysis, designing and test
cases.
Advantages & Disadvantages
Advantages :
• Reveals errors in "hidden" code.
• Spots the Dead Code or other issues with respect to best
programming practices.
• Testing can be commenced at an earlier stage as one need not
wait for the GUI to be available.
• Testing is more thorough, with the possibility of covering most
paths.
Disadvantages :
• Expensive as one has to spend both time and money to perform
white box testing.
• Every possibility that few lines of code are missed accidentally.
• In-depth knowledge about the programming language is
necessary to perform white box testing.
• Since tests can be very complex, highly skilled resources are
required, with thorough knowledge of programming and
implementation.
Whitebox Testing Techniques:
• A major White box testing technique is Code Coverage
analysis.
• Code Coverage analysis, eliminates gaps in a test case suite.
• It identifies areas of a program that are not exercised by a set
of test cases.
• Once gaps are identified, you create test cases to verify
untested parts of code, thereby increase the quality of the
software product.
• There are automated tools available to perform Code
coverage analysis.
Following are Whitebox testing techniques:
o Statement coverage: This technique is aimed at
exercising all programming statements with minimal tests.
o Branch and decision coverage: This technique is
running a series of tests to ensure that all branches are
tested at least once. Tools: An example of a
tool that handles branch coverage testing for C, C++ and
Java applications is TCAT-PATH
1. Statement coverage:
• Statement coverage is a white box testing technique,
which involves the execution of all the statements at
least once in the source code.
• Through statement coverage we can identify the
statements executed and where the code is not
executed because of blockage.
• Using this technique we can check what the source
code is expected to do and what it should not & also
used to check the quality of the code & the flow of
different paths in the program.
• The statement coverage covers only the true
conditions. The main drawback of this technique is that
we cannot test the false condition in it.
• The statement coverage is count as per below formula:
(Statement coverage = No of statements
Executed/Total no of statements in the source code * 100)
 1. Statement coverage:
Example:
Read A
Read B
if A>B
Print “A is greater than B”
else
Print "B is greater than A"
endif
• Set1 :If A =5, B =2
No of statements Executed: 5
Total no of statements in the source code: 7
Statement coverage =5/7*100 = 71.00%
• Set2 :If A =2, B =5 [False-Not supported by Statement
coverage]
No of statements Executed: 6
Total no of statements in the source code: 7
Statement coverage =6/7*100 = 85.20%
2. Branch/Decision coverage:
• Branch coverage is also known as Decision coverage or
all-edges coverage.
• It covers both the true and false conditions unlikely the
statement coverage.
• A branch is the outcome of a decision, so branch
coverage simply measures which decision outcomes
have been tested.
• This sounds great because it takes a more in-depth
view of the source code than simple statement
coverage.
• The formula to calculate decision coverage is:
Decision Coverage=(Number of decision outcomes
executed/Total number of decision outcomes)*100%
2. Branch/Decision coverage:
Example:
READ X
READ Y
IF (X > Y)
PRINT “X is greater that Y”
ENDIF
• To get 100% statement coverage only one test case is
sufficient for this pseudo-code.
• TEST CASE 1: X=10 Y=5
• However this test case won’t give you 100% decision
coverage as the FALSE condition of the IF statement is not
exercised.
• In order to achieve 100% decision coverage we need to
exercise the FALSE condition of the IF statement which will be
covered when X is less than Y.
• So the final TEST SET for 100% decision coverage will be:
TEST CASE 1: X=10, Y=5
TEST CASE 2: X=2, Y=10
3. Path coverage:
• The basis path method enables the test-case designer
to derive a logical.
• Complexity measure of a procedural design and use
this measure as a guide for defining a basis set of
execution paths.
• Test cases derived to exercise the basis set are
guaranteed to execute every statement in the program
at least one time during testing.
• All possible control paths taken, including
o All loop paths taken zero, once and multiple items in
technique
o The test case are prepared based on the logical
complexity measure of the procedure design
• Flow graph, Cyclomatic Complexity and Graph Metrices
are used to arrive at basis path.
3. Path coverage:

[Figure of Path coverage

example]
What is Software Metric?
• Measurement is nothing but quantitative
indication of size / dimension / capacity
of an attribute of a product / process.
• Software metric is defined as a
quantitative measure of an attribute a
software system possesses with respect
to Cost, Quality, Size and Schedule.
Cyclomatic complexity
• Cyclomatic complexity is a software metric used to
indicate the complexity of a program.
• It is useful for structured or White Box Testing.
• It is a quantitative measure of the number of linearly
independent paths through a program's source code.
• It was developed by Thomas J. McCabe, Sr. in 1976.
• Cyclomatic complexity can be calculated by using
control flow graphs or with respect to functions,
modules, methods or classes within a software program.
• Independent path is defined as a path that has at least
one edge which has not been traversed before in any
other paths.
Cyclomatic complexity
cont.
• In the graph, Nodes represent processing tasks while edges
represent control flow between the nodes.

• Lower the Program's cyclomatic complexity, lower the risk to

modify and easier to understand.
• It can be represented using the below formula:
Cyclomatic complexity = E - N + 2*P
where,
E = number of edges in the flow graph.
N = number of nodes in the flow graph.
P = number of nodes that have exit points
Flow graph notation for a
program:
• Flow Graph notation for a program defines several nodes
connected through the edges.
• Below are Flow diagrams for statements like if-else, While,
until and normal sequence of flow.
Example
i = 0;
n=4; //N-Number of nodes present in the graph
• while (i<n-1) do
j = i + 1;
• while (j<n) do
• if A[i]<A[j] then
• swap(A[i], A[j]);
• end do;
• i=i+1;
• end do;

Cyclomatic complexity = E - N + 2*P

=9-7+2=4
Basis Set - A set of possible execution path of a program
1, 7
1, 2, 6, 1, 7
1, 2, 3, 4, 5, 2, 6, 1, 7
1, 2, 3, 5, 2, 6, 1, 7
Uses of Cyclomatic
Complexity
Cyclomatic Complexity can prove to be very helpful in

• Helps developers and testers to determine

independent path executions.
• Developers can assure that all the paths have been
tested at least once.
• Helps us to focus more on the uncovered paths.
• Improve code coverage in Software Engineering.
• Evaluate the risk associated with the application or
program.
• Using these metrics early in the cycle reduces more
risk of the program.
Black box testing
• Black box testing is the software testing method which
is used to test the software without knowing the
internal structure of code or program.
• It is also known as functional testing & specification-
based testing.
• Basically software under test is called as “Black-Box”,
we are treating this as black box & without checking
internal structure of software we test the software.
• In Black Box Testing we just focus on inputs and output
of the software system without bothering about internal
knowledge of the software program.
• Tester has access only to running code and the
specification it is supposed to satisfy.
• Test cases are written with no knowledge of internal
workings of the code.
• No access to source code.
Black box testing cont.

• The above Black Box executable program can be any software

system you want to test.
• For example : an operating system like Windows, a website like
Google ,a database like Oracle or even your own custom application.
Under Black Box Testing , you can test these applications by just
focusing on the inputs & outputs without knowing their internal code
implementation.
• By applying black-box techniques, you derive a set of test cases that
satisfy the following criteria:
(1) test cases that reduce, by a count that is greater than one the
number of additional test cases that must be designed to achieve reasonable
testing, and
(2) test cases that tell you something about the presence or absence of
classes of errors, rather than an error associated only with the specific test at
Advantages & Disadvantages
Advantages :
• More effective on larger units of code than glass box testing.
• Tester needs no knowledge of implementation, including
specific programming languages.
• Tester and programmer are independent of each other.
• Tests are done from a user’s point of view.
• Will help to expose any ambiguities or inconsistencies in the
specifications.
• Test cases can be designed as soon as the specifications are
complete.
Disadvantages :
• Only a small number of possible inputs can actually be
tested, to test every possible input stream would take nearly
forever.
• Without clear and concise specifications, test cases are hard
to design.
• There may be unnecessary repetition of test inputs if the
tester is not informed of test cases the programmer has
already tried.
Blackbox Testing Techniques:
• Exhausting testing is not always possible when there is a
large set of input combinations, because of budget and time
constraint.
• The special techniques are needed which select test-cases
smartly from the all combination of test-cases in such a way
that all scenarios are covered
Two techniques are used
o Equivalence Partitioning: It is a software test design
technique that involves dividing input values into valid and
invalid partitions and selecting representative values from
each partition as test data.
o Boundary Value Analysis: It is a software test design
technique that involves determination of boundaries for
input values and selecting values that are at the
boundaries and just inside/ outside of the boundaries as
test data.
1. Equivalence partitioning:
• Equivalence Partitioning also called as equivalence class
partitioning.
• It can be applied at any level of testing and is often a good
technique to use first.
• The idea behind this technique is to divide (i.e. to partition) a
set of test conditions into groups or sets that can be
considered the same (i.e. the system should handle them
equivalently), hence ‘equivalence partitioning’.
• In equivalence partitioning technique we need to test only
one condition from each partition. This is because we are
assuming that all the conditions in one partition will be
treated in the same way by the software.
• Equivalence partitioning is a testing technique where input
values set into classes for testing.
Valid Input Class = Keeps all valid inputs.
Invalid Input Class = Keeps all Invalid inputs.
1. Equivalence partitioning cont.
Equivalence classes may be defined according to the
following guidelines:
1. If an input condition specifies a range, one valid and
two invalid equivalence classes are defined.
2. If an input condition requires a specific value, one valid
and two invalid equivalence classes are defined.
3. If an input condition specifies a member of a set, one
valid and one invalid equivalence class are defined.
4. If an input condition is Boolean, one valid and one
invalid class are defined.
• By applying the guidelines for the derivation of
equivalence classes, test cases for each input domain
data item can be developed and executed.
Example
• A text field permits only numeric characters
• Length must be 6-10 characters long
• Partition according to the requirement should be like this:

• While evaluating Equivalence partitioning, values in all

partitions are equivalent that’s why 0-5 are equivalent, 6 –
10 are equivalent and 11- 14 are equivalent.
• At the time of testing, test 4 and 12 as invalid values and
7 as valid one.
• It is easy to test input ranges 6–10 but harder to test input
ranges 2-600. Testing will be easy in the case of lesser test
cases but you should be very careful.
• Assuming, valid input is 7. That means, you belief that the
developer coded the correct valid range (6-10).
2. Boundary Value Analysis:
• It’s widely recognized that input values at the extreme
ends of input domain cause more errors in system.
More application errors occur at the boundaries of input
domain.
• ‘Boundary value analysis’ testing technique is used to
identify errors at boundaries rather than finding those
exist in center of input domain.
• Boundary value analysis is a next part of Equivalence
partitioning for designing test cases where test cases
are selected at the edges of the equivalence classes.
• Boundary value analysis is the process of testing
between extreme ends or boundaries between
partitions' of the input values.
• So these extreme ends like Start- End, Lower- Upper,
Maximum-Minimum, Just Inside-Just Outside values are
called boundary values and the testing is called
"boundary value analysis testing".
Example
• Suppose you have very important tool at office, accepts
valid User Name and Password field to work on that tool,
and accepts minimum 8 characters and maximum 12
characters. Valid range 8-12, Invalid range 7 or less than
7 and Invalid range 13 or more than 13.

Write Test Cases for Valid partition value, Invalid partition

value & exact boundary value.
• Test Cases 1: Consider password length less than 8.
• Test Cases 2: Consider password of length exactly 8.
• Test Cases 3: Consider password of length between 9 and
11.
• Test Cases 4: Consider password of length exactly 12.
• Test Cases 5: Consider password of length more than 12.
Advantages & disadvantages of BVA
Advantages :
• The BVA is easy to use and remember because of the uniformity of
identified tests and the automated nature of this technique.
• One can easily control the expenses made on the testing by
controlling the number of identified test cases.
• BVA is the best approach in cases where the functionality of a
software is based on numerous variables representing physical
quantities.
• The technique is best at user input troubles in the software.
• The procedure and guidelines are crystal clear and easy when it
comes to determining the test cases through BVA.
• The test cases generated through BVA are very small.

Disadvantages :
• This technique sometimes fails to test all the potential input values.
And so, the results are unsure.
• The dependencies with BVA are not tested between two inputs.
• This technique doesn’t fit well when it comes to Boolean Variables.
• It only works well with independent variables that depict quantity.
Comparison of Blackbox Testing & Whitebox
TestingBlack Box Testing White Box Testing
Black box testing is the Software White box testing is the software
testing method which is used to test testing method in which internal
the software without knowing the structure is being known to tester
internal structure of code or program. who is going to test the software.
This type of testing is carried out by Generally, this type of testing is
testers. carried out by software developers.
Implementation Knowledge is not Implementation Knowledge is
required to carry out Black Box required to
Testing. carry out White Box Testing.
Programming Knowledge is not Programming Knowledge is required
required to carry out Black Box to carry out White Box Testing.
Testing.
Testing is applicable on higher levels Testing is applicable on lower level of
of testing like System Testing, testing like Unit Testing, Integration
Acceptance testing. testing.
Black box testing means functional White box testing means structural
test or external testing. test or
interior testing.
Comparison of Blackbox Testing & Whitebox
Testing cont.
Black Box Testing White Box Testing
In Black Box testing is primarily In White Box testing is primarily
concentrate on the functionality of concentrate on the testing of program
the code of the system under test like
system under test. code structure, branches, conditions,
loops etc.
The main aim of this testing to check The main aim of White Box testing to
on what functionality is performing by check on how System is performing.
the system under test.
Black Box testing can be started White Box testing can be started
based on Requirement Specifications based on
documents. Detail Design documents.
The Functional testing, Behavior The Structural testing, Logic testing,
testing, Close box testing is carried Path testing, Loop testing, Code
out under Black Box testing, so there coverage testing, Open box
is no required of the programming testing is carried out under White
knowledge. Box testing, so there is
compulsory to know about
programming knowledge.
Test Case
• A TEST CASE is a set of actions executed to verify a
particular feature or functionality of your software
application.
• A Test Case contains test steps, test data, precondition,
postcondition developed for specific test scenario to
verify any requirement.
• The test case includes specific variables or conditions,
using which a testing engineer can compare expected
and actual results to determine whether a software
product is functioning as per the requirements of the
customer.
Test Suites design
• Test suite is a container that has a set of tests which
helps testers in executing and reporting the test
execution status. It can take any of the three states
namely Active, InProgress and completed.
• A Test case can be added to multiple test suites and
test plans. After creating a test plan, test suites are
created which in turn can have any number of tests.
• Test suites are created based on the cycle or based on
the scope. It can contain any type of tests, viz -
functional or Non-Functional.
Test Suite - Diagram:
Testing Object Oriented
Applications
• Objective – to uncover as much errors as possible with
manageable amount of efforts in realistic time span.
• The object oriented testing strategy is identical to
conventional testing strategy.
• The strategy is start testing in small & work outward to
testing in large.
• The basic unit of testing is class that contains attributes
& operations.
• These classes integrate to form object oriented
architecture & called collaborating classes.
Unit Testing in the OO Context
• The concept of the unit testing changes in object-
oriented software
• Encapsulation drives the definition of classes and
objects
o Means, each class and each instance of a class
(object) packages attributes (data) and the
operations (methods or services) that manipulate
these data
o Rather than testing an individual module, the
smallest testable unit is the encapsulated class
• Unlike unit testing of conventional software,
o which focuses on the algorithmic detail of a module
and the data that flows across the module interface,
o class testing for OO software is driven by the
operations encapsulated by the class and the state
behavior of the class
Integration Testing in the OO
Context
• Object-oriented software does not have a hierarchical control
structure,
• conventional top-down and bottom-up integration strategies
have little meaning
• There are two different strategies for integration testing of
OO systems.
o Thread-based testing
• integrates the set of classes required to respond to one input or
event for the system
• Each thread is integrated and tested individually
• Regression testing is applied to ensure that no side effects occur
o Use-based testing
• begins the construction of the system by testing those classes
(called independent classes) that use very few (if any) of server
classes
• After the independent classes are tested, the next layer of classes,
called dependent classes, that use the independent classes are
tested
• Cluster testing is one step in the integration testing of OO software
• Here, a cluster of collaborating classes is exercised by designing
Integration Testing in the OO
Context
• Object-oriented software does not have a hierarchical control
structure,
• conventional top-down and bottom-up integration strategies
have little meaning
• There are two different strategies for integration testing of
OO systems.
o Thread-based testing
• integrates the set of classes required to respond to one input or
event for the system
• Each thread is integrated and tested individually
• Regression testing is applied to ensure that no side effects occur
o Use-based testing
• begins the construction of the system by testing those classes
(called independent classes) that use very few (if any) of server
classes
• After the independent classes are tested, the next layer of classes,
called dependent classes, that use the independent classes are
tested
• Cluster testing is one step in the integration testing of OO software
• Here, a cluster of collaborating classes is exercised by designing
Validation Testing in an OO Context
• At the validation or system level, the details of class
connections disappear
• Like conventional validation, the validation of OO
software focuses on user-visible actions and user-
recognizable outputs from the system
• To assist in the derivation of validation tests, the tester
should draw upon use cases that are part of the
requirements model
• Conventional black-box testing methods can be used to
drive validation tests
Testing Web Applications
• WEB TESTING, or website testing is checking your web
application or website for potential bugs before its
made live and is accessible to general public.
• Web Testing checks for functionality, usability, security,
compatibility, performance of the web application or
website.
• To accomplish this, a testing strategy that encompasses
both reviews and executable testing is applied.
• During this stage issues such as that of web application
security, the functioning of the site, its access to
handicapped as well as regular users and its ability to
handle traffic is checked.
Content Testing
• Errors in WebApp content can be
o as trivial as minor typographical errors or
o as significant as incorrect information, improper
organization, or violation of intellectual property
laws
• Content testing attempts to uncover these and many
other problems before the user encounters them
• Content testing combines both reviews and the
generation of executable test cases
• Reviews are applied to uncover semantic errors in
content
• Executable testing is used to uncover content errors
that can be traced to dynamically derived content that
is driven by data acquired from one or more databases.
User Interface Testing
• Verification and validation of a WebApp user interface
occurs at three distinct points
• During requirements analysis
o the interface model is reviewed to ensure that it
conforms to stakeholder requirements
• During design
o the interface design model is reviewed to ensure
that generic quality criteria established for all user
interfaces have been achieved
• During testing
o the focus shifts to the execution of application-
specific aspects of user interaction as they are
manifested by interface syntax and semantics.
• In addition, testing provides a final assessment of
usability
Navigation Testing
• The job of navigation testing is to ensure that
o the mechanisms that allow the WebApp user to
travel through the WebApp are all functional and,
o to validate that each Navigation Semantic Unit
(NSU) can be achieved by the appropriate user
category
• Navigation mechanisms should be tested are
 Navigation links,
 Redirects,
 Bookmarks,
 Frames and framesets,
 Site maps,
 Internal search engines.
Component-Level Testing
• Component-level testing (function testing), focuses on
a set of tests that attempt to uncover errors in WebApp
functions.
• Each WebApp function is a software component
(implemented in one of a variety of programming
languages)
o WebApp function can be tested using black-box (and
in some cases, white-box) techniques.
• Component-level test cases are often driven by forms-
level input.
o Once forms data are defined, the user selects a
button or other control mechanism to initiate
execution.
Configuration Testing
• Configuration variability and instability are important
factors that make WebApp testing a challenge.
• Hardware, operating system(s), browsers, storage
capacity, network communication speeds, and a variety
of other client-side factors are difficult to predict for
each user.
• One user’s impression of the WebApp and the manner
in which he/she interacts with it can differ significantly.
• Configuration testing is to test a set of probable client-
side and server-side configurations
o to ensure that the user experience will be the same
on all of them and,
o to isolate errors that may be specific to a particular
configuration
Security Testing
• Security tests are designed to probe
o vulnerabilities of the client-side environment,
o the network communications that occur as data are
passed from client to server and back again, and
o the server-side environment.
• Each of these domains can be attacked, and it is the
job of the security tester to uncover weaknesses
o that can be exploited by those with the intent to do
so.
Performance Testing
• Performance testing is used to uncover
o performance problems that can result from lack of
server-side resources,
o inappropriate network bandwidth,
o inadequate database capabilities,
o faulty or weak operating system capabilities,
o poorly designed WebApp functionality, and
o other hardware or software issues that can lead to
degraded client-server performance
Testing Mobile Applications
• Mobile testing or mobile application testing is a process
by which application software developed for handheld
mobile devices is tested for its functionality, usability &
consistency.
• Testing mobile application is more complex & time
consuming as compared to traditional desktop & web
applications.
Challenges in Mobile testing
• There is a huge number of mobile devices available ranging
from handsets, to smart phones, to tabs, to ipads & wearable
tech
• There is diversity in mobile network operator such as CDMA,
GSM & so on.
• A mobile app can be a native app, a web app or a hybrid app
which has both contents.
• There are different OS for mobile such as Android, ios, windows
etc.
Testing Mobile Applications
cont. used for Mobile testing
Criteria
• To ensure that it is working as per the requirements.
• To work on different OS platforms, devices & networking
environment.
• Testing the mobile app during the interrupts such as
incoming calls, SMS, notifications, data cable insertion or
removal & so on.
• For installation, un-installation, updation on the devices.
• For security i.e. to check for attacks, authentication &
data security.
Testing tools
Win Runner – Is Mercury Interactive’s enterprise
automation tool.

Features -
• Automatic Recovery
• Silent Installation
• Support for various Environments
• Cost Effective
• Support Multiple data combination
• Multiple Verification
Testing tools cont.
Load Runner – HP Load runner is a software testing tool
from Hewlett-Packard.
It is used to test applications, measuring system
behaviour & performance under load.
HP Load runner can simulate thousands of users
concurrently using application software, recording & later
analyzing the performance of key components of the
application.

Features -
• Excellent monitoring & analysis interface
• Supports other languages
• No need to install it on server
• Support for most of the commonly used protocols
• GUI generated scripts
• Quickly point out the effect of the WAN