PART -A

1 a) Identifying Defects and ensures the quality of a software. [ 1M ]

b) Path, Test Case Selection, Control Flow Graph, Cyclomatic Complexity [ 1M ]
c)It refers to a set of input values or conditions that are logically related and meaningful for
testing a specific aspect of the software. [ 1 M ]
d) Testability in the context of domains and interfaces is the ease of effectively testing
software components, ensuring that they can be readily tested with appropriate test cases
and that different domains and interfaces can be isolated and manipulated for accurate
evaluation. [ 1M ]
e) The reduction procedure in the context of path products involves simplifying test case
generation by identifying and eliminating redundant or equivalent paths, optimizing testing
efficiency while maintaining comprehensive coverage. [ 1M ]
f) In logic-based testing, specifications define the conditions that must be satisfied by the
software under test, including input-output relationships, functional behavior, and
constraints. Test cases are then generated based on these specifications to systematically
check whether the software behaves as expected according to the logical conditions
specified. [ 1 M ]
g) A "good" state graph is complete, correct, clear, concise, modular, easy to maintain,
supports effective testing, and balances performance considerations. [ 1M ]
h) Improve testability by modular design, clear interfaces, dependency injection, separation
of concerns, logging, automated testing, mocking, testable architecture, and CI/CD pipelines
[ 1M ]
.i) a square matrix A to the power of n (where n is a positive integer) involves multiplying the
matrix by itself n times. Mathematically, if A is an m×m square matrix, then An represents
the result of multiplying A by itself n times. An=A×A×…×A [ 1M ]
j) A graph matrix is a square array with one row and one column for every node in thegraph. •
Each row-column combination corresponds to a relation between the node corresponding to.
the row and the node corresponding to the column. [ 1M ]
PART-B
2 ANS: ) Black Box Testing vs. White Box Testing [ 10 M ]

Black Box Testing: Testing technique where testers examine the functionality of a system
without knowing its internal structure or implementation details. Testers focus solely on the
system's inputs, outputs, and behavior.
White Box Testing: Testing technique where testers have knowledge of the internal structure,
design, and code of the system. Testers design test cases based on the system's internal logic
and paths through the code.
.Manual Testing vs. Automated Testing:
Manual Testing: Testing performed manually by human testers without the use of automated
tools or scripts. Testers interact with the system, execute test cases, and observe results
manually.
Automated Testing: Testing performed using automated testing tools and scripts that execute
predefined test cases automatically. Tests are scripted to simulate user interactions and verify
system behavior.
Functional Testing vs. Non-Functional Testing:
Functional Testing: Testing focused on verifying that the system behaves according to its
functional requirements. Test cases validate specific features, operations, and functionalities
of the system.
Non-Functional Testing: Testing focused on evaluating aspects of the system's performance,
reliability, usability, security, and other non-functional requirements.
Validation vs. Verification:
Validation: Process of evaluating a system to ensure that it meets the customer's requirements
and intended use. It answers the question, "Are we building the right product?"
Verification: Process of evaluating a system to ensure that it adheres to its specifications and
requirements. It answers the question, "Are we building the product right?"
Testing versus Debugging : The phrase “ Test and Debug “ is treated as a single word.
The purpose of testing is to show that a program has bugs.
The purpose of debugging is find the error or misconception that led to the program’s failure
and to design and implement the program changes that correct the error.
3 ANS: ) [ 10 M]
REQUIREMENTS, FEATURES AND FUNCTIONALITY BUGS: Various categories in
Requirements, Features and Functionlity bugs include:
Requirements and Specifications Bugs:
Requirements and specifications developed from them can be incomplete ambiguous, or
self-contradictory. They can be misunderstood or impossible to understand.
The specifications that don't have flaws in them may change while the design is in progress.
The features are added, modified and deleted.
Feature Bugs:
Specification problems usually create corresponding feature problems.
A feature can be wrong, missing, or superfluous (serving no useful purpose). A missing
feature or case is easier to detect and correct. A wrong feature could have deep design
implications.
Feature Interaction Bugs:
Providing correct, clear, implementable and testable feature specifications is not enough.
Features usually come in groups or related features. The features of each group and the
interaction of features with in the group are usually well tested.
The problem is unpredictable interactions between feature groups or even between
individual features. For example, your telephone is provided with call holding and call
forwarding. The interactions between these two features may have bugs.
Specification and Feature Bug Remedies:
Most feature bugs are rooted in human to human communication problems. One solution is
to use high-level, formal specification languages or systems.
Such languages and systems provide short term support but in the long run, does not solve
the problem.
Testing Techniques for functional bugs: Most functional test techniques- that is those
techniques which are based on a behavioral description of software, such as transaction
flow testing, syntax testing, domain testing, logic testing and state testing are useful in
testing functional bugs.
STRUCTURAL BUGS: Various categories in Structural bugs include:
Control and Sequence Bugs:
Most of the control flow bugs are easily tested and caught in unit testing.
Another reason for control flow bugs is that use of old code especially ALP & COBOL code
are dominated by control flow bugs.
Control and sequence bugs at all levels are caught by testing, especially structural testing,
more specifically path testing combined with a bottom line functional test based on a
specification.
Logic Bugs:
Bugs in logic, especially those related to misundertanding how case statements and logic
operators behave singly and combinations
Also includes evaluation of boolean expressions in deeply nested IF-THEN-ELSE constructs.
Processing Bugs:
Processing bugs include arithmetic bugs, algebraic, mathematical function evaluation,
algorithm selection and general processing.
Examples of Processing bugs include: Incorrect conversion from one data representation to
other, ignoring overflow, improper use of grater-than-or-eual etc
Initialization Bugs:
Initialization bugs are common. Initialization bugs can be improper and superfluous.
Superfluous bugs are generally less harmful but can affect performance.
Data-Flow Bugs and Anomalies:
Most initialization bugs are special case of data flow anamolies.
A data flow anomaly occurs where there is a path along which we expect to do something
unreasonable with data, such as using an uninitialized variable, attempting to use a variable
before it exists, modifying and then not storing or using the result, or initializing twice
without an intermediate use.

DATA BUGS:
Data bugs include all bugs that arise from the specification of data objects, their formats,
the number of such objects, and their initial values.
Data Bugs are atleast as common as bugs in code, but they are foten treated as if they
didnot exist at all.
Dynamic data bugs are due to leftover garbage in a shared resource. This can be handled in
one of the three ways: (1) Clean up after the use by the user (2) Common Cleanup by the
resource manager (3) No Clean up
Static Data are fixed in form and content. They appear in the source code or database
directly or indirectly, for example a number, a string of characters, or a bit pattern.
CODING BUGS:
Coding errors of all kinds can create any of the other kind of bugs.
Syntax errors are generally not important in the scheme of things if the source language
translator has adequate syntax checking.
If a program has many syntax errors, then we should expect many logic and coding bugs.
The documentation bugs are also considered as coding bugs which may mislead the
maintenance programmers.

INTERFACE, INTEGRATION, AND SYSTEM BUGS:

Various categories of bugs in Interface, Integration, and System Bugs are:
External Interfaces:
Internal Interfaces:
Hardware Architecture:
Operating System Bugs:
Software Architecture:
Integration Bugs:
Integration bugs are bugs having to do with the integration of, and with the interfaces
between, working and tested components.
These bugs results from inconsistencies or incompatibilities between components.
System Bugs:
System bugs covering all kinds of bugs that cannot be ascribed to a component or to their
simple interactions, but result from the totality of interactions between many components
such as programs, data, hardware, and the operating systems.
TEST AND TEST DESIGN BUGS:

5 ANS: ) [ 10 M ]
Dataflow testing is a technique used to identify and evaluate the execution of data flows
within a software program. It aims to detect potential flaws related to the handling of data
variables, such as uninitialized variables, incorrect variable assignments, and data
dependencies.
I)-DU Paths Testing:
Strategy: This approach focuses on testing all "definition-use" (DU) pairs within the program.
A DU pair consists of a variable definition (where the variable is assigned a value) and its
subsequent use (where the variable's value is referenced).
Example: Consider a simple program that calculates the area of a rectangle. We want to test
the DU pairs for the variables "length" and "width." In this case, we would ensure that each
path from the definition of "length" and "width" to their respective uses in the area
calculation is tested. For instance, one test case might involve assigning specific values to
"length" and "width" and verifying that the calculated area is correct.
II)All-Defs Testing:
Strategy: This strategy involves testing all variable definitions (Defs) within the program. It
aims to ensure that every variable is assigned a value before it is used elsewhere in the
program.
Example: Consider a banking application that calculates the interest accrued on a savings
account. In this scenario, we would want to test all the variable definitions related to
interest calculation, such as the principal amount, interest rate, and time period. Each test
case would involve assigning specific values to these variables and verifying that the interest
calculation is accurate.
III)All-Uses Testing:
Strategy: This approach focuses on testing all variable uses (Uses) within the program. It
aims to verify that all values produced by the program are correctly utilized in subsequent
computations or outputs.
Example: Suppose we have a weather forecasting application that predicts the temperature
for the next day based on historical data. We want to ensure that all temperature
predictions are based on accurate input data. In this case, we would test all the uses of
historical temperature data in the prediction algorithm. Each test case would involve
providing different sets of historical temperature data and verifying that the predicted
temperatures are within an acceptable range.
6 ANS: ) A decision table is divided into four main quadrants:
Conditions: List of all the inputs or conditions that can affect the decision. These are typically
placed on the left side of the table.
Actions: Possible actions or outcomes based on the conditions. These are usually placed on
the bottom part of the table.
Condition Alternatives: Different possible values or states for each condition, represented as
columns in the table.
Action Stubs: Indication of which action(s) should be taken for each combination of
condition alternatives, aligned with the columns of condition alternatives.
Steps to Create a Decision Table and Derive Test Cases:
Step 1: Identify Conditions and Actions
Step 2: Determine Condition Alternatives
Step 3: List All Possible Combinations
Step 4: Define Actions for Each Combination
Step 5: Derive Test Cases
Example same as 7 answer Example

7 ANS: [ 10 M ]
Identify Inputs and Outputs: First, you need to identify the inputs or conditions that
influence the system's behavior and the corresponding outputs or actions that result from
these inputs.
Create the Decision Table: The decision table is typically organized into columns
representing different conditions or inputs and rows representing various combinations of
conditions. The intersection of rows and columns specifies the corresponding actions or
outputs.
Define Conditions and Actions: Each column in the decision table represents a condition or
input variable, and each row represents a unique combination of these conditions. The last
column(s) in the table represent the actions or outputs.
Fill in the Table: Populate the table with all possible combinations of input conditions and
the expected outputs or actions. This may involve considering all possible combinations or
focusing on specific scenarios of interest.
Analyze and Simplify: Review the decision table to ensure completeness and accuracy.
Simplify the table if necessary by removing redundant rows or columns.
Generate Test Cases: Test cases can be derived directly from the decision table by selecting
specific combinations of input conditions that cover all possible scenarios and ensuring that
each unique combination is tested.
Let's consider a scenario where a system determines whether a customer is eligible for a
loan based on their income and credit score:
Conditions:
Income: Low, Medium, High
Credit Score: Poor, Fair, Good
Actions:
Eligibility for Loan: Yes, No

Income Credit Score Eligibility for Loan

Low Poor No

Low Fair No

Low Good No

Medium Poor No

Medium Fair Yes

Medium Good Yes

High Poor No

High Fair Yes

High Good Yes

In this decision table, each row represents a unique combination of income and credit score,
and the last column specifies whether the customer is eligible for a loan based on these
conditions.
Test cases can then be derived from this decision table to ensure comprehensive testing
coverage:
Test Case 1: Low Income, Poor Credit Score (Expected Result: Not eligible for loan)
Test Case 2: Medium Income, Fair Credit Score (Expected Result: Eligible for loan)
Test Case 3: High Income, Good Credit Score (Expected Result: Eligible for loan)
8) States in software systems refer to the current condition or situation of the system,
including variables, object states, and user interactions. They influence testing strategies by
dictating behavior variation, state transitions, boundary conditions, concurrency
considerations, and error handling validation. Testing strategies often incorporate state-
based testing techniques to ensure comprehensive coverage of system states and
transitions.
8 ANS: )_ In software systems, a "state" represents a specific condition or configuration of
the system at a given time, influenced by past events, inputs, or actions. States are crucial
for understanding how an application behaves and responds to different inputs over time.
States influence testing strategies: tests that cover various system states and transitions
between them. This includes ensuring that the system behaves correctly in different states,
properly handles transitions, maintains state across sessions or restarts, and recovers from
failures. Testing must also address initialization, state persistence, and the specific
challenges of automated testing in managing and replicating system state

9 ANS): [ 10 M ]

 Modular Design
 Clear Requirements and Specifications
 Dependency Injection
 Mocking and Stubbing
 Logging and Instrumentation
 Separation of Concerns
 Test Automation
 Continuous Integration and Deployment (CI/CD)
 Error Handling and Logging
 Usability and Accessibility Testing
10 ANS): The basic toolkitconsistsof:
Matrix multiplication, which is used to get the pathexpression from every node to every
other node.
 A partitioning algorithm for converting graphs with loops into loop-free graphs of
equivalence classes.
Acollapsingprocess(analogoustothedeterminantofamatrix),whichgetsthepathexpressionfro
manynode to any other node

11 ANS): Adjacency Matrix: [ 10 M ]

An adjacency matrix is a square matrix used to represent whether there is a connection between pairs of
vertices in a graph.In an undirected graph, the adjacency matrix is symmetric since the connection between
vertex i and vertex j is the same as the connection between vertex j and vertex i.In a directed graph, the
adjacency matrix mightnot be symmetric as the connection from vertex i to vertex j can be different
from the connection from vertex j to vertex i.The adjacency matrix helps in quickly determining which vertices
are adjacent to each other andthe nature of their connection (e.g., weighted or unweighted, directed or
undirected).
Incidence Matrix:
An incidence matrix is a matrix representation of a graph where rows correspond to vertices and columns correspon
to edges.
Each entry in the matrix indicates whether a vertex is incident to an edge.
In directed graphs, the incidence matrix can represent the directionality of edges.
The incidence matrix is particularly useful in analyzing properties related to edges and their connections to
vertices.
Significance in Analyzing Graph Structures:
Graph Connectivity
Path Finding and Distance
Graph Properties
Network Flow Analysis
Spectral Graph Theory