Software testing unit 2

White box testing: It is a way of testing the software in which the tester has
knowledge about the internal structure or the code or the program of the
software.
Black box texting: It is a way of software testing in which the internal structure
or the program or the code is hidden and nothing is known about it.
Static Testing is a type of a software testing method which is performed to
check the defects in software without actually executing the code of the
software application
Dynamic Testing is a type of Software Testing which is performed to analyze
the dynamic behaviour of the code. It includes the testing of the software for
the input values and output values that are analyzed.
Differentiations:

Static Testing Dynamic Testing

It is performed in the It is performed at the

early stage of the later stage of the
software development. software development.

In static testing whole In dynamic testing

code is not executed. whole code is executed.

Static testing prevents Dynamic testing finds

the defects. and fixes the defects.

Static testing is less Dynamic testing is

costly. highly costly.

It includes It involves functional

walkthroughs, code and nonfunctional
review, inspection etc. testing.
White and black box

Black Box Testing White Box Testing

It is a way of software testing in It is a way of testing the software in

which the internal structure or the which the tester has knowledge about
program or the code is hidden and the internal structure or the code or
nothing is known about it. the program of the software.

It can be referred to as outer or It is the inner or the internal software

external software testing. testing.

It is mostly done by software It is mostly done by software

testers. developers.

It is mostly done by software It is mostly done by software

testers. developers.

It is mostly done by software It is mostly done by software

testers. developers.

White BOX:
Static Testing
1) Static testing is a type of testing which requires only the source code of
product, not the binaries or executable.
2) Static testing can be done by humans or with the help of specialized
tools.
3) Static testing does not involve executing the program on computers.
4) It involves:
i) The code works according to the functional requirements.
ii) The code has been written in accordance with the design developed
iv) The code handles errors properly.
Static Testing Desk Checking:
1) It is done manually by the author of the code.
2) It is method to verify the portions of the code for correctness.
3) Such verification is done by comparing the code with design or
specifications to make sure that the code does what it is suppose to do
and effectively.
4) This is desk checking that most programmer do before compiling and
executing the code.
5) Whenever error are found the author applies the corrections for errors
on the spot.

Static Testing Walkthrough:

1) The author of the work product explains the product to his team
(reviewers).
2) Participants can ask questions if any.
3) Meeting is led by the author.
4) Informal procedure.
5) Suitable for small teams.

Static Testing Inspections:

1) The main purpose is to find defects and meeting is led by trained
moderator.
2) This review is a formal type of review where it follows strict process to
find the defects.
3) Reviewers have checklist to review the work products.
4) They record the defect and inform the participants to rectify those errors
Structural testing
This testing include: i) Code ii) Code structure iii) Internal Design iv) and how
they are coded.
In this testing tests are actually run by the computer on the built product

Code Functional Testing:

1) Initial part of Structural testing which do some quick checks by
developers before subjecting the code to more complex testing.
2) Developer perform certain obvious tests such as input variables &
corresponding expected output variables
3) Developer can build a “Debug Version” of the product by putting print
statements and making program is passing through the right loops and
iterations the right number of times

Code Coverage Testing:

1) Code coverage testing involves designing and executing test cases and
finding out the percentage of code that is covered by testing.
2) The percentage of code covered by a test is found by adopting a
technique called instrumentation of code.
3) This instrumented code can monitor and keep an audit of what portions
of code are covered.
4) The tools also allow reporting on the portions of the code that are
covered frequently, so that the critical or mostoften portions of code can
be identified.

Code Complexity Testing:

1) Cyclomatic complexity is metric that quantifies the complexity of a program.
2) For that a program is represented in the form of a flow graph.
3) Flow graph consist of nodes and edges.
Black BOX:
1) Black box testing involves looking at the specifications and does not
require examining the code of a program.
2) It is done from the customer’s viewpoint.
3) Tester knows the set of inputs and expected outputs.

Requirement Based Testing:

1) It deals with validating SRS.
2) Some of the requirements are implied or implicit.
3) Explicit requirements are stated and documented as part of the SRS &
BRS.
4) TRS: Test Requirements Specification it is document which consist of
explicit requirements (SRS) as well as implicit requirements ( by test
team ).
Positive and Negative Testing:
1) Positive testing tries to prove that a given product does what it is
supposed to do.
2) When a test case verifies the requirements of the product with a set of
expected output, it is called positive test case.
3) Negative testing is done to show that the product does not fail when an
unexpected input is given
4) This testing covers scenarios for which the product is not designed and
coded.
Boundary Value Analysis (BVA):
1) Most of the defects in software products hover around conditions and
boundaries.
2) By boundaries means “limits” of values of the various variables.
3) Use of right comparison operator <= , =,>.
4) Different loops
5) In boundary value analysis boundary values are tested of valid and
invalid partition.
Equivalence Partitioning:
1) It involves identifying a small set of representative input values that
produce as many different output conditions as possible.
2) This reduces the number of permutations and combinations of input,
output values used for testing.
3) That result in increasing the coverage and reducing the effort involved in
testing
User Documentation Testing:
1) It covers all the a) manuals , b) user guides , c) installation guides , d)
setup guides , e) read me file, f) software release notes and g) online
help these are all provided along with the software to help the end user
to understand the software system.
2) To check if what is stated in the document is available in the product.
3) To check if what is there in the product is explained correctly in the
document.
4) User documentation testing is done to ensure the documentations
matches the product and vice-versa.
Graph Based Testing:
1) A cause–effect graph is a directed graph that maps a set of causes to a
set of effects.
2) The causes may be thought of as the input to the program, and the
effects may be thought of as the output.
3) Usually the graph shows the nodes representing the causes on the left
side and the nodes representing the effects on the right side
Decision Tables:
1) Decision table lists the various decision variables , conditions , actions.
2) The variables that contribute to the decision are listed as the columns of
the table.
3) The last column of the table is the action to be taken for the combination
of values of the decision variables.