(B) Difference Between Validation and Verification Testing. Ans

(B) Difference Between Validation and Verification Testing. Ans

SOFTWARE TESTING

Q. 1. (a) What is Branch Testing?

Ans. It is a measure of how many branches or decisions in a module have been executed during testing. If the Branch coverage is (95% for new code or 75% for code under maintainenence then the test scripts require review and enhancement.

(b) Difference between Validation and Verification testing. Ans.

Verification / Validation
1. It is a static process of verifying documents, design and code.
2. It does not involve executing the code.
3. It is human based checking of document files.
4. It uses methods like inspections, walke throughs, Desk-checking etc.
5. It generally, comes first–done before validation.
6. It can catch errors that validation cannot catch. / 1. It is a dynamic process of validating/
testing the actual product.
2. It involves executing the code.
3. It is computer based execution of program.
4. It uses methods like black-box, gray box, white box testing etc.
5. It generally follows verification.
6. It can catch errors that verification cannot catch.

(c) Define Test cases.

Ans. It defines the items to be tested provide traceability to SRS, SDD, User operations or installation guides. It specifies the input, output, environment procedures, intercase dependencies of each test case.

(d) Explain the Load testing and Performance testing.

Ans. Load Testing: It is a type of non-functional testing. A Load test is type of software testing which is understand to condustand the behaviour of the application under a specific expected load. Load testing is performed to determine a system’s behaviour under both normal and at peak conditions. It helps to identify the maximum operating capacity of an application as well as any bottlenecks and determine which element is causing degradation. Load testing is meant to test the system by constantly and steadily increasing the load on the system till the time it reaches the threshold limit.

Performance Testing: Performance testing is the testing which is performed to ascertain how components of a system are performing, given a particular situation. Resource usage scalability and reliability of the product are also validated under this testing. It is focussed on addressing performance issues in the design and architecture of software product.

(e) What is Risk Analysis?

Ans. All software projects benefits from risk analysis. Using risk analysis at the

beginning of a project highlights the potential problem areas. This helps developers

and managers to mitigate the risks. Risk analysis is well-defined process that prioritizes modules for testing.

A Risk contains three components:

(a) The risk, ri, associated with a project (i < 1 ton) (b) The probability of occurrence of a risk, (Ii)

(c) The impact of the risk, (xi).

Risk analysis consists of first testing the potential problems and then assigning a probabiliting and severity values for each identified problem. By ranking the results, the tester can identify the potential problems most in need of the immediate attention and select test cases to address those needs.

Q.2. (a) Explain the testing process with its types.
Ans. Software testing is the process of executing a program or system with the intent

of finding errors. It is an activity that aims at evaluating an attibute or capability of a

program or system and determing that it meets the required results. There are the following types of testing.

Testing

Black box testing White box testing

(i) (ii) (iii) (iv)

Boundary value

Equivalence class

Decision table

Cause effect graphing

Static testing Dynamic testing

Analysis

Testing Bassd testing

Technique

Black Box Testing: It is a strategy where testing is based on the functionaling of the program. It involves only the observation of output on the basis of certain given input values. No attempt is made to analyze the code i.e., internal structure of the program is ignored. So it is also called as Black Box Testing as the contents of the black box are unknown.

Functionality of the black box is completely understood in terms of Inputs and

Outputs.

I/P test data

Input Domain

System under test

O/P test data

Output Domain

It is carried out from the customers/users point of view.

Types of Black Box Testing.

(i) Boundary Value Analysis (BVA): It is based on the concept that the density of the defect is more towards the boundaries. That is the input value may be on the boundary,

just below the boundary and even their nominal values (i.e., the mid value of the range.

Set of Input values–{min, min +), nominal, max–1, max} i.e., values are taken from within the domain.

a < x < b c < y < d

d

c

a b

Thus, for a program of n variables, boundary value analysis yields 4n + 1 test cases. (ii) Equivalence Class Testing: In this method, input domain of a program is partitioned into a finite number of equivalence classes and one can assume that the test of a representative value of each class is equivalent to that of any other value i.e., if one test case in a class detects an error, than all other test cases would be expected to find the same error. The idea of equivalence class testing is to identify the test cases by

using one element from each equivalence class.

(iii) Decision Table Based Testing: Decision tables are precise and compact way of modelling complicated.

This technique is ideal for situations where number of combinations of actions are taken under varying set of conditions.

It consists following 4 potions: (a) Stub portion

(b) Entry potion

(c) Condition portion, and

(d) Action portion.

Rules

Condition stub / Condition entry
Action stub / Action entry

Structure fo a decision table

A column in the entry portion is a rule. Rules indicate which actions are taken for the conditional circumstances indicated in the condition portion of the rule.

Number of Test Cases = Number of Rules

(iv) Case Effect Graphing Technique: It is a testing technique that aids in selecting test cases that logically relate causes (inputs) to effects (outputs) to produce test cases. A ‘case’ represents a distinct input condition that brings about an internal change in the system. An ‘effect’ represents an output condition, a system transformation a state resulting from a combination of causes.

For White-BOX testing refer to Q.No. 3(a) End. Term Examination May-June 2013 (Next-Question).

(b) Does testing guarantee the absence of Error? Elaborate.

Ans. Testing can show the presence of errors not their absence. We cannot test a program to guarantee that it is error free. Such a goal is impossible to achieve for virtually

all programs, even trivial programs. Again, psychological studies tell us that people

perform poorly when they set out on a task that they know to be infeasible or impossible.

For instance, if you were instructed to solve the crossword puzzle in the sunday Times in 15 minutes we would probably observe little, if any progress after 10 minutes because most of us would be resigned to the fact that the task seems impossible. If you were asked for a solution in four frows, however we could reasonably expect to see more progress in the initial 10 minutes. Defining program testing as the process of uncovering errors in a program makes it a feasible task, thus overcoming this psychological problem.

Q.3. (a) What is White box testing? Explain with its types. Write its advantages and disadvantages

Ans. White BOX testing is a way of testing the external functionality of the code by examining and testing the program code. White BOX testing is used to test the program code, code structure and internal design flow.

White Box testing is of two types:

1. Static White BOX testing.

2. Dynamic white BOX testing.

Static Testing: Static testing is a type of testing in which the program source code is tested without running it we only need to examine and review the code we need not to execute the code. We need to find out whether.

• The code works according to the functional requirements.

• The code has been written in accordance with the design developed earlier in the project life cycle.

• The code handlles errors properly.

Static testing can be done by humans or with the help of specialized tools.

Dynamic White Box Testing: In dynamic testing, we test a running program. In this we try to test the internal logic of the program. It involves running the actual product against some pre-designed test cases to exercise as much of the code as possible.

Whole box Testing

Static testing Dynamic testing

Code walk through

Cope

Inspection

Unit testing

Unit converge

Cope complexity

Statement
coverage
Path
coverage
Condition
coverage
Function
coverage

Advantage of White Box Testing:

1. White Box testing helps us to identify memory leaks. When we allocate memory, we should explicity release that memory also. If this is not done then over time, there would be no memory available for allocating memory on requests. This can be done using debuggers also that can tally allocated and freed memory.

2. Performance Analysis: Code coverage tests can identify the areas of code that are executed most frequently.

3. White Box testing is useful in identifying boltleneeks in resource usage.

4. White Box testing can help identify security holes in dynamically generated code.

5. Testing can be commenced at an earlier stage, one need not wait for the GUI

to be available.

Disadvantages of White Box Testing

1. Since tests can be very complex, highly skilled resources are required, with thorough knowledge of programming and implementation.

2. Test script maintainance can be burden if the implementation changes too frequently.

3. Since this method of testing is closely tied with the application being testing, tools to cater to every kind of implementation/platform maynot be readily available.

(b) Describe three ways to find out the Cyclomatic Complexity of a program or flow chart?

Ans. The cyclomatic complexity is also known as structural complexing because it

gives internal view of the code. This approach is used to find the number of independent

paths through a program. This provides us the upper bound for the number of tests that must be conducted to ensure that all statements have been executed at least once and every condition has been executed on its true and false side.

Cyclomatic complexity can be calculated by one of the three methods.

First Method: Cyclomatic complexing V(G) of a graph G with n vertices, e edges and p connected components is calculated as

V (G) = e − n + 2 p

A

B

C F D

E

G

H N

I J O P

K L

M

Q

R DD Path graph

Second Method: Cyclomatic complexity V(G) of a flow graph G is equal to the number of predicate (decision) nodes plus one.

V (G) = π + 1

where π is the number of predicate nodes contained in the flow graph G.

Third Method: Cyclomatic complexing is equal to the number of regions of the flow graph.

V (G) = number of regions

for example, consider the DD path graph of the triangle Problem. Cyclomatic complexity by the first method can be calculated as

V (G) = e − n + 2 p

Number of edges, e = 23

Number of nodes, n = 18

V(G) = 23 – 18 + 2 = 7

ByIInd Method: Cylomatic complexing will be calculated as

V(G) = π + 1

= 6 + 1 = 7

By 33rd Method Cyclomatic complexity will be calculated as

V(G) = Number of regions = 7

The cyclomatic complexing is 7. Hence, there are seven independent paths.

Q.4. (a) How can we reduce number of test cases in Black Box Testing? Explain with example.

Ans. Equivalence partitioning method is used to reduce the total number of test cases in black box testing. In this method the input domain data is divided into different equivalence data classes. This method is typically used to reduce the total number of test cases into a finite set of testable test cases, still covering maximum requirements. In short it is the process of taking all possible test cases and placing them into classes. One test value is picked from each class while testing.

For example: If you are testing for an input box accepting numbers from 1 to 1000 then there is no use in writing thousand test cases for all valid input numbers plus other test cases for invalid data. Using equivalence partitioning method above test cases can be divided into three sets of input data called as classes. Each test case is a representative of respective class. So in above example we can divide our test cases into three equivalence classes of some valid and invalid inputs.

Test cases for input box accepting numbers between 1 and 1000 using

Equivalence Partitioning.

1. One input data class with all valid inputs. Pick a single value from range 1 to

1000 as a valid test case. If you select other values between 1 and 1000 then result is going to be some. So one test case for valid data should be sufficient.

2. Input data class with all values below 1, as a invalid input data test case.

3. Input data with any value greater than 1000 to represent third invalid input class.

So using equivalence partitioning you have categorized all possible test cases into three classes. Test cases with other values from any class should give you the same result.

We have selected one representative from every input class to design our test cases. Test case values are selected in such a way that largest number of attributes of equivalence class can be exercised.

Equivalence partitioning uses fewest test cases to cover maximum requirements.

(b) Take any example of your choice and write down the number, of Test cases.

Ans. Consider a program for the determination of the nature of roots of a quadratic

equation. Its input is a triple of positive integers (Say a, b, c) and values may be from

interval [0, 100]. The program output may have one of the following words.

[Not a quadratic equation Real roots; Imaginary roots, Equal roots] Quadratic Equation will be of type:

ax2 + bx + c = 0

Roats are real if (b2 – 4 ac) > 0

Roots are imaginary if (b2 – 4 ac) < 0

Roots are equal if (b2 – 4 ac) = 0

Equation is not quadratic if a = 0

Total number of Test cases = 4n + 1

where n → number of inputs

= 4(3) + 1 = 13 Test cases

Boundary value test cases are given as:

Test Case / a / b / c / Expected Output
1
2
3
4
5
6
7
8
9
10
11
12
13 / 0
1
50
99
100
50
50
50
50
50
50
50
50 / 50
50
50
50
50
0
1
99
100
50
50
50
50 / 50
50
50
50
50
50
50
50
50
0
1
99
100 / Not Quadratic Real Roots Imaginary Roots Imaginary Roots Imaginary Roots Imaginary Roots Imaginary Roots Imaginary Roots Equal Roots
Real Roots Real Roots Imaginary Roots Imaginary Roots

Q.5. (a) Explain GUI testing Environment with its issues.

Ans. The main characteristics of any graphical user interface (GUI) application is

that it is event driven. Users can cause any of several events in any order. Many GUIs

have event sequence that is not guided. One benefit of GUI applications to testers is that there is little need for integration testing. Unit testing is typically at the “button level”; that is buttons have functions and these can be tested in the usual unit–level sense. The essence of system-level testing for GUI applications is to exercise the event driven nature of the application. Unfortunately, most of the models in UML are of little help with event-driven systems. The main exception is behavioural models, specifically statecharts and their simples case, finite-state machines (FSMS).

Regression testing becomes a problem with GUIs as well. This is because the GUI may change significantly across version of the application, even though the underlying application may not. A test designed to follow that path since a button, menu item, or dialog may have changed location or appearance.

Another problem is the sequencing problem. Some functionality of the system may only be accompolished by following some complex sequence of GUI events. To generate a set of test cases, test designers must be certain that their suite covers all the functionaling of the system and also has to be sure that the suite fully exercises the GUI itself. The difficully in accompolishing this task is two fold: to deal with domain size and with sequences. In addition, the tester faces more difficulty when they have to do regression testing. These issues have driven the GUI testing problem domain towards automation. Many different techniques have been proposed to automatically generate test suites that are complete and that simulate user behaviour.

(b) Explain testing tools with its types.

Ans. There are two typers of testing tools.

(A) Static testing tools.

(B) Dynamic testing tools.

(A) Static Testing tools: Static testing tools seek to support the static testing process. These tools do not involve actual input and output. They do not test the actual execution of the software.

These tools include the following:

(a) Flow analyzers: They ensure consistency in data.

(b) Path tests: They find unused code and code with contradictions.

(c) Coverage analyzers: If ensures that all logic paths are tested.

(d) Interface analyzers: It examines the effects of passing variables and data between modules.

(B) Dynamic testing tools: Dynamic testing tools support dynamic testing process. These tools test the software system with ‘live’ data. Dynamic testing tools include the following.

(a) Test driver: It inputs data into a module-under–test (MUT).

(b) Test beds: If simultaneously displays source code along with the program under execution.

(c) Emulators: The response facilities are used to enulate parts of the system not yet developed.

(d) Mutation analyzers: The errors are delibrately ‘fed’ into the code in order to test fault tolerance of the system.