Harsh RB

Software Testing Methodologies Assignment

12 min read

Q1. Explain about KV chart with single, two and three variables

A Karnaugh-Veitch (KV) chart, also known as a K-map, is a graphical method used to simplify Boolean algebra expressions. It provides a systematic way to minimize logic expressions without using complex Boolean theorems.

Single Variable KV Chart

  • A single-variable function has only one input variable, say A.
  • Since there are only two possible values for a Boolean variable (0 or 1), there are 2² = 4 possible functions** of a single variable.

Structure:

  • The chart has two cells, one for each value of A:
    • One cell for A = 0
    • One cell for A = 1
AFunction Value
0f(0)
1f(1)

Each cell can either be 0 (False) or 1 (True), representing whether the function is true for that input value.

Example:

Two Variable KV Chart

  • For two variables, say A and B, there are 2² = 4 possible combinations of inputs: 00, 01, 10, 11.
  • Therefore, the K-map has 4 cells, arranged in a 2x2 grid.

Structure:

  • Rows represent values of A
  • Columns represent values of B
B=0B=1
A=00001
A=11011

Each cell represents a minterm (product term) of the two variables:

  • Cell (0,0): Ā·B̄
  • Cell (0,1): Ā·B
  • Cell (1,0): A·B̄
  • Cell (1,1): A·B

Grouping Rules:

  • Adjacent cells (horizontally or vertically) can be grouped together.
  • Diagonal adjacency does not count.
  • Each group simplifies the expression by eliminating the variable that changes between the two cells.

Example:

Three Variable KV Chart

  • With three variables (A, B, C), there are 2³ = 8 possible input combinations.
  • The chart is laid out in a 2x4 grid or 4x2 grid, depending on convention.

Structure:

  • Usually, A determines the row (2 rows)
  • B and C determine the column (4 columns)
BC=00BC=01BC=11BC=10
A=0000001011010
A=1100101111110

Each cell now represents a minterm of three variables.

Grouping Rules:

  • You can group 1s in powers of two: 1, 2, 4, or 8 cells.
  • Groups must be rectangular (or wrap around edges).
  • Maximize group size to reduce terms.

Example:

Q2. Explain good and bad state graphs

State graphs (also known as state transition diagrams) are essential tools in software testing and design, particularly when modeling systems that behave differently based on their current state and the inputs received. A good state graph is well-structured, logically consistent, and easy to test, while a bad state graph contains flaws like ambiguities, unreachable states, or missing transitions.

A good state graph follows these principles:

1. Well-Defined States
  • Each state must be clearly defined.
  • The total number of states should equal the product of all possible combinations of variables involved in defining the system’s state.
    • Example: If the state depends on a 3-bit flag (8 values) and a counter from 0–4 (5 values), there are 8 × 5 = 40 possible states.
2. One Transition per Input-State Pair
  • For every combination of state + input, there must be exactly one transition to another state (possibly the same).
  • This eliminates ambiguity and ensures predictable behavior.
3. Output Specification
  • Every transition must have an associated output action.
  • Even if the output is trivial, it must be meaningful and documented.
4. Reachability
  • All states should be reachable via some sequence of inputs starting from the initial state.
  • There should be no “orphan” states that can’t be reached under any condition.
5. Returnability
  • From any state, there should be a sequence of inputs that brings the system back to the same state.
  • This allows for repeatable and verifiable testing.
6. No Contradictions or Missing Transitions
  • There should be no missing or conflicting transitions.
  • Every possible input in every state must be accounted for — either by a valid transition or by explicitly handling invalid cases (e.g., error handling).
7. Equivalence Handling
  • Equivalent states (states that behave identically under all input sequences) should be merged to simplify the model.
  • Merging reduces complexity and improves clarity.

What Makes a Bad State Graph?

A bad state graph has structural or logical issues that make it hard to understand, test, or implement correctly.

1. Incorrect Number of States
  • Discrepancies between how many states the tester thinks exist vs. how many the programmer modeled.
  • Often due to misunderstanding or miscounting state variables.
2. Impossible or Unreachable States
  • Impossible states: Combinations of variables that cannot occur due to constraints.
  • Unreachable states: States that no sequence of inputs can reach.
    • These may indicate logic errors or missing transitions.
3. Contradictory or Missing Transitions
  • Multiple transitions defined for the same input-state pair → contradiction.
  • No transition defined for an input-state pair → ambiguity.
  • Programs must handle all cases; even staying in the same state counts as a valid transition.
4. Dead States
  • A state once entered cannot be exited → dead state.
  • May not always be a bug, but usually indicates a flaw unless intentional (e.g., shutdown state).
5. Incorrect Output Actions
  • The state and transitions may be correct, but the output produced during a transition is wrong.
  • Outputs must be verified independently.
6. Equivalent States Not Merged
  • Duplicate or functionally identical states increase complexity unnecessarily.
  • Harder to maintain and test.
7. Inadequate Coverage in Testing
  • Just covering all transitions (like a “grand tour”) isn’t enough.
  • Real-world testing should include:
    • 0-switch paths (single transitions)
    • 1-switch paths (two consecutive transitions)
    • Up to n-1 switches (all possible paths through n states)

Common Bugs in State Graphs

Type of BugDescription
Wrong number of statesProgrammer and tester disagree on how many states exist.
Wrong transitionsIncorrect next state for a given input-state pair.
Wrong outputsCorrect transition but incorrect output/action.
Equivalent states splitAccidentally duplicated states causing confusion.
Dead statesOnce entered, the system cannot exit.
Unreachable statesCannot reach a state from any input sequence.
Missing or ambiguous transitionsNo defined behavior for certain inputs.

Principles of State Testing

  1. Define expected behavior:

    • For each input sequence, define expected transitions, next states, and outputs.

  2. Use structured input sequences:

    • Start and end at the initial state.
    • Test various path lengths (switch coverage levels).

  3. Verify comprehensively:

    • Test inputs, transitions, and outputs separately and together.

  4. Focus on real-world scenarios:

    • Prioritize testing of critical paths rather than trying to test everything at once.

When Are State Graphs Useful?

  • Systems where output depends on past inputs (i.e., history matters).
  • Protocol implementation (e.g., TCP/IP handshake).
  • Device drivers with complex retry/recovery logic.
  • Parsing sequential data formats (e.g., XML, JSON).
  • Human-machine interfaces where order of actions matters.

Q3. Explain the working of testing tools: Jmeter/selenium/soapUI/Catalon

Each of these tools serves a specific purpose in the software testing ecosystem.

1. JMeter

  • Use: Performance & Load Testing
  • How it works: Simulates multiple users accessing an application or API to measure response time and system behavior under load.
  • Key features:
    • Supports HTTP, REST, SOAP, FTP, etc.
    • Graphical reports and real-time results
    • Easy to set up test plans with thread groups and samplers

2. Selenium

  • Use: Web UI Automation Testing
  • How it works: Automates browser actions like clicking buttons, filling forms, and navigating pages to simulate user behavior.
  • Key features:
    • Works with Chrome, Firefox, Edge, etc.
    • Integrates with frameworks like TestNG, JUnit
    • Supports scripting in Java, Python, C#, etc.

3. soapUI

  • Use: API Testing (SOAP & REST)
  • How it works: Tests web services by sending requests and validating responses for correctness and performance.
  • Key features:
    • Functional, security, and load testing for APIs
    • Mock services for backend simulation
    • Data-driven and assertion-based testing

4. Katalon Studio

  • Use: End-to-end Automation (Web, Mobile, API)
  • How it works: Combines UI and API automation in one tool with record-playback and scripting support.
  • Key features:
    • Built-in support for Selenium and Appium
    • Keyword-driven and data-driven testing
    • CI/CD integration and cloud execution

Q4. Explain graph matrtix relations

A graph matrix is a way to represent relationships between nodes in a graph using a matrix structure. Each row and column represents a node, and the entries (cells) in the matrix indicate whether and how two nodes are related.

What is a Relation?

A relation R is a rule that defines a connection or property between two elements of a set.

For example:

  • If we have a set of nodes {a, b, c}, then a relation R could be:
    • “a is connected to b” → written as aRb
    • “a ≥ b”
    • “a is the parent of b”

In graphs, if aRb, it means there is a link (edge) from node a to node b.

Types of Relations and Their Graph/Matrix Representation

TypeDefinitionExampleGraph / Matrix Behavior
TransitiveIf aRb and bRc, then aRc must also be trueIs connected to, is greater than or equal toIn a graph: if there’s a path from a→b and b→c, there should also be a direct link a→c (or at least the transitive closure should exist). In a matrix: if A[i][j] = 1 and A[j][k] = 1, then A[i][k] should also be 1.
ReflexiveEvery element relates to itself: aRaEquals (=), is acquainted withIn a matrix: diagonal elements (i,i) are all 1. In a graph: every node has a self-loop.
IrreflexiveNo element relates to itself: not aRaNot equals (≠), is a friend ofIn a matrix: diagonal elements are all 0. In a graph: no self-loops.
SymmetricIf aRb, then bRaIs connected to, is a relative ofIn a matrix: symmetric across the diagonal (A[i][j] = A[j][i]). In a graph: undirected edges (bidirectional).
AsymmetricIf aRb, then bRa is falseIs a parent of, is faster thanIn a matrix: not symmetric. In a graph: directed edges only one way.
AntisymmetricIf aRb and bRa, then a = bIs a subset of (⊆), is greater than or equal to (≥)In a matrix: if A[i][j] = 1 and A[j][i] = 1, then i = j. In a graph: only one-way edge unless nodes are the same.

Special Types of Relations

Equivalence Relations

  • A relation is an equivalence relation if it is:
    • Reflexive
    • Symmetric
    • Transitive

Example: Equality (=)

Implication:

  • The set is divided into equivalence classes, where all members of a class are equivalent under the relation.
  • Used in partition testing: test one member of a class, and you’ve effectively tested all others.

Matrix Property:

  • Symmetric (because symmetric)
  • Reflexive (diagonal all 1s)
  • Transitive (if A[i][j] and A[j][k], then A[i][k])

Graph Property:

  • Undirected
  • Self-loops on all nodes
  • Connected components represent equivalence classes

Partial Order Relations

  • A relation is a partial order if it is:
    • Reflexive
    • Antisymmetric
    • Transitive

Example: “Is a subset of”, “Is less than or equal to”

Implication:

  • Represents ordering between elements, but not all elements may be comparable.
  • Used in topological sorting, dependency management, etc.

Matrix Property:

  • Diagonal values = 1 (reflexive)
  • If A[i][j] = 1 and A[j][i] = 1 → i = j (antisymmetric)
  • If A[i][j] = 1 and A[j][k] = 1 → A[i][k] = 1 (transitive)

Graph Property:

  • Directed acyclic graph (DAG)
  • No cycles
  • Has at least one minimal and maximal element

A graph matrix is a square matrix where:

  • Rows and columns correspond to nodes.
  • Each cell (i, j) contains information about the relationship from node i to node j.

Basic Matrix Representation:

abc
a010
b001
c100

This matrix indicates:

  • a → b
  • b → c
  • c → a

Weighted Graph Matrix:

abc
a050
b002
c300

Here, numbers can represent:

  • Cost
  • Time
  • Distance
  • Probability

Used in shortest path algorithms (like Dijkstra or Floyd-Warshall).

Q5. How to find max path count arithmetic and lower path count arithmetic. Explain with an example

In software testing, especially in path testing, it’s important to determine how many distinct paths exist through a program. Two key metrics are:

  1. Maximum Path Count: The maximum number of possible execution paths.
  2. Lower Path Count: The minimum number of paths required to cover all links (edges) at least once.

We use arithmetic rules applied to control flow graphs or path expressions to compute these counts.

Maximum Path Count Arithmetic

This tells us the upper bound on the number of different execution paths that can be taken through a structured program.

Rules for Max Path Count:

  • Parallel Links (OR): Add weights
    • e.g., a + b → weight = weight(a) + weight(b)
  • Serial Links (AND): Multiply weights
    • e.g., ab → weight = weight(a) × weight(b)
  • Loop (Kleene Star): Use maximum loop iterations
    • e.g., (loop)*, if max iterations = n → weight = 1 + 1 + ... + 1 (n+1 times)

Note: Each link is initially assigned a weight of 1, representing one path.

Example:

Given this path expression:

a(b + c)d{e(fi)*fgj(m + l)k}*e(fi)*fgh

Let’s assume:

  • Inner loop (fi)*: can execute 0 to 3 times
  • Outer loop {...}*: can execute exactly 4 times

Step-by-step Calculation:

  1. Inner Loop (fi)*:

    • Can iterate 0, 1, 2, or 3 times → 4 paths
    • So, weight = 4

  2. Inner Section (e(fi)*fgh):

    • Links: e(4)fgh → 1×4×1×1×1 = 4

  3. Inside Outer Loop:

    • (m + l) → parallel links → weight = 1 + 1 = 2
    • So, j(m + l)k = 1×2×1 = 2
    • Full inner section becomes: e(fi)*fgj(m+l)k = 1×4×1×1×2×1 = 8

  4. Outer Loop {…}^4:

    • This block repeats 4 times
    • So, total weight = 8⁴ = 4096

  5. Full Expression:

    • Left side: a(b + c)d = 1×(1 + 1)×1 = 2
    • Right side: e(fi)*fgh = 1×4×1×1 = 4
    • Total Max Path Count = 2 × 4096 × 4 = 32,768

Lower Path Count Arithmetic

This gives the minimum number of test cases needed to ensure every link (edge) is executed at least once.

It follows the same arithmetic but uses minimum values where choices exist.

Same Example:

Use the same structure:

a(b + c)d{e(fi)*fgj(m + l)k}*e(fi)*fgh

Assume:

  • You must take both branches b and c (since they’re OR)
  • For loops, you take the loop at least once

Step-by-step:

  1. b + c → need both branches → weight = 1 + 1 = 2
  2. d → serial → multiply by 1 → still 2
  3. Inner loop (fi)* → must be taken at least once → weight = 1
  4. e(fi)*fgh = 1×1×1×1 = 1
  5. j(m + l)k = 1×(1 + 1)×1 = 2
  6. Full inside loop: e(fi)*fgj(m+l)k = 1×1×1×1×2×1 = 2
  7. Outer loop {...}* → must be taken at least once → weight = 2
  8. Final e(fi)*fgh = 1×1×1×1 = 1

Total = 2 × 2 × 1 = 4

Minimum Test Cases Required = 4

Graph View

Backlinks