SOFWARE TESTING

MODEL PAPER-4

SECTION-A (4X2=8)
1.What is Code Based Testing? Give an example.

Code-based testing, also known as white-box testing or structural testing, is a software testing technique that
involves examining and testing the internal structure and implementation of the code. Unlike black-box
testing, which focuses on testing the functionality from an external perspective, code-based testing relies on
an understanding of the code's internal logic, data structures, and control flows.

The primary goal of code-based testing is to ensure that the code is properly designed, implemented, and
follows best practices for coding standards, error handling, and code coverage.

2What is Data Flow Testing?

Data flow testing is a white-box testing technique that focuses on testing the flow of data through a program or
application. It is used to identify potential defects or anomalies in the way data is defined, used, and manipulated
within the code. The primary objective of data flow testing is to ensure that the data is correctly handled and processed
throughout the program's execution.

3.What is pair wise Integration Testing

Pairwise Integration Testing, also known as Pairwise Testing or All-Pairs Testing, is a type of integration
testing technique used in software testing. It is based on the concept of testing all possible pairs of input
parameter values or component interactions, rather than testing all possible combinations.

The main idea behind pairwise integration testing is that most defects or failures in software systems are
caused by interactions between pairs of components or parameter values

4.What is a thread in System Testing?

In the context of system testing, a thread refers to a particular sequence or flow of test cases that are
executed together to verify a specific functionality, feature, or scenario within the system under test.

A thread in system testing is designed to ensure that the various components and modules of the system
work together seamlessly and as intended when performing a particular task or operation. It typically
involves executing a series of test cases in a specific order, simulating real-world usage scenarios and
verifying the end-to-end functionality of the system.

5. What are taxonomy of interactions?

he taxonomy of interactions refers to a classification or categorization of the different types of interactions

that can occur between components or objects in a software system during integration testing. This
taxonomy helps in identifying and understanding the various forms of interactions, which can assist in
designing effective integration test cases.

6. What is model based testing (MBT)?

Model-Based Testing (MBT) is a software testing approach that involves creating abstract models of the system under
test (SUT) and using those models to derive test cases automatically or semi-automatically. The models are typically
created using formal notations, such as state machines, decision tables, or domain-specific languages, which capture
the requirements, behavior, and structural aspects of the system.
SECTION-B (4X5=20)
7.Explain the levels of testing in V-Model.
8.What is Decision Table? Explain the Characteristics of Decision Tables.

9.Discuss the commission Problem using Define-Use Testing.

10. Explain the features or characteristic of system testing.
11.Explain the context of interaction in interaction in testing
12.Differentiate between model driven development versus test driven development

Model-Driven Development (MDD) and Test-Driven Development (TDD) are two different approaches to
software development, each with its own principles and focus areas. Here are the key differences between
them:

Model-Driven Development (MDD):

1. Focus: MDD emphasizes the creation and use of models as the primary artifacts for software
development. Models are visual or formal representations of the system's structure, behavior, and
requirements.
2. Approach: In MDD, models are created first, and code is generated (semi-automatically or
automatically) from these models using model-to-code transformations or code generators.
3. Abstraction Level: MDD operates at a higher level of abstraction, allowing developers to work with
domain-specific concepts and constructs rather than focusing on low-level implementation details.
4. Productivity: MDD aims to increase productivity by automating repetitive tasks and reducing the
effort required for coding, thereby allowing developers to concentrate on higher-level design and
analysis.
5. Tools: MDD relies heavily on specialized modeling tools, code generators, and model transformation
engines to facilitate the development process.
6. Maintenance: Changes in the system often require updating the models, which can then be used to
regenerate the code, potentially reducing the effort required for manual code changes.

Test-Driven Development (TDD):

1. Focus: TDD emphasizes writing automated tests before writing the actual production code. The tests
serve as a specification for the desired behavior of the system.
2. Approach: In TDD, developers write a failing test case first, then write the minimum amount of
production code necessary to make the test pass, and finally refactor the code to improve its design
and structure.
3. Abstraction Level: TDD operates at the code level, with tests and production code being written in
the same programming language.
4. Productivity: TDD aims to improve code quality and maintainability by ensuring that the code is
thoroughly tested from the start and by promoting a highly iterative and incremental development
process.
5. Tools: TDD relies on unit testing frameworks and tools that support automated testing and
continuous integration.
6. Maintenance: As the code evolves, the existing tests act as regression checks, helping to ensure that
new changes do not break existing functionality.

While MDD and TDD have different focuses and approaches, they are not mutually exclusive. In some
cases, they can be combined or used in a complementary manner. For example, models created in MDD can
be used to generate test cases or skeletons for TDD, or TDD can be employed to ensure the correctness of
the generated code in an MDD process.

SECTION-C (4X8=32)
13.a) Explain Generalizing Boundary Value Analysis (BVA).

13.b) Explain Robust Boundary Value Testing (RBVT)with an example.

14. Explain the forms or variation of equivalence class testing with examples.

Equivalence class testing is a black-box testing technique that divides the input domain of a program or
system into partitions or equivalence classes, where each class represents a set of valid or invalid inputs that
are expected to produce the same behavior or output. Within each equivalence class, one or more
representative test cases are selected to cover the class. There are several forms or variations of equivalence
class testing, each focusing on different aspects of the input domain or system behavior. Here are some
common forms with examples:

1. Input Equivalence Classes:

o This form focuses on partitioning the input data into valid and invalid equivalence classes
based on the specified input conditions or constraints.
 o Example: For a function that calculates the square root of a number, the input equivalence
classes could be:
 Valid: Non-negative numbers
 Invalid: Negative numbers
2. Output Equivalence Classes:
o This form partitions the expected outputs or results into equivalence classes based on the
specified output conditions or requirements.
o Example: For a function that calculates the grade of a student based on their score, the output
equivalence classes could be:
 A (score between 90 and 100)
 B (score between 80 and 89)
 C (score between 70 and 79)
 D (score between 60 and 69)
 F (score below 60)
3. State Equivalence Classes:
o This form is applicable to systems or programs with multiple states, where the equivalence
classes represent different states or state transitions.
o Example: For a vending machine system, the state equivalence classes could be:
 Idle state (waiting for input)
 Item selection state
 Payment state
 Dispensing state
4. Interface Equivalence Classes:
o This form focuses on partitioning the inputs or outputs based on the interface specifications
or requirements of the system or component under test.
o Example: For a web application with a registration form, the interface equivalence classes for
the "password" field could be:
 Valid: Passwords meeting the specified length and complexity requirements
 Invalid: Passwords not meeting the specified length or complexity requirements
5. Boundary Value Equivalence Classes:
o This form partitions the input or output values into equivalence classes based on the boundary
conditions or edge cases.
o Example: For a function that calculates the area of a rectangle based on the length and width
inputs, the boundary value equivalence classes for the length and width could be:
 Valid: Positive non-zero values
 Boundary: Zero values
 Invalid: Negative values
6. Decision Table Equivalence Classes:
o This form uses decision tables to represent the combinations of input conditions and their
corresponding actions or outputs, with each combination representing an equivalence class.
o Example: For a loan approval system, the decision table equivalence classes could be based
on combinations of factors like credit score, income, and loan amount.

These forms or variations of equivalence class testing can be applied individually or combined based on the
specific requirements, complexity, and characteristics of the system under test. By carefully identifying and
testing representative cases from each equivalence class, testers can increase the likelihood of uncovering
defects or inconsistencies in the system's behavior while minimizing the number of test cases required.

15.a) Explain the test cases for the triangle problems in decision table-based testing.
Decision table-based testing is a black-box testing technique that uses decision tables to represent the
combinations of input conditions and their corresponding actions or outputs. The triangle problem is a
common example used to illustrate decision table-based testing.

In the triangle problem, the task is to determine the type of triangle (equilateral, isosceles, scalene, or not a
triangle) based on the lengths of its three sides. The input conditions are the relationships between the three
sides (side1, side2, and side3), and the actions or outputs are the different types of triangles.

Here's a decision table that represents the triangle problem:

Condition Rule 1 Rule 2 Rule 3 Rule 4 Rule 5 Rule 6 Rule 7 Rule 8

side1 == side2 ==
T F F F F F F F
side3
side1 == side2 !=
F T F F F F F F
side3
side1 != side2 ==
F F T F F F F F
side3
side1 != side2 !=
F F F T F F F F
side3
side1 + side2 <=
F F F F T F F F
side3
side1 + side3 <=
F F F F F T F F
side2
side2 + side3 <=
F F F F F F T F
side1
All other cases F F F F F F F T
Not a Not a Not a Not a
Action Equilateral Isosceles Isosceles Scalene
triangle triangle triangle triangle

Based on this decision table, we can derive the following test cases for the triangle problem:

1. Equilateral Triangle Test Case:

o Input: side1 = 5, side2 = 5, side3 = 5
o Expected Output: Equilateral triangle
2. Isosceles Triangle Test Cases:
o Test Case 1: Input: side1 = 4, side2 = 4, side3 = 3
o Test Case 2: Input: side1 = 3, side2 = 5, side3 = 5
o Expected Output: Isosceles triangle
3. Scalene Triangle Test Case:
o Input: side1 = 3, side2 = 4, side3 = 5
o Expected Output: Scalene triangle
4. Not a Triangle Test Cases:
o Test Case 1: Input: side1 = 1, side2 = 2, side3 = 5 (sum of two sides is less than the third
side)
o Test Case 2: Input: side1 = 2, side2 = 3, side3 = 6 (sum of two sides is less than the third
side)
o Test Case 3: Input: side1 = -2, side2 = 3, side3 = 4 (negative side length)
o Expected Output: Not a triangle

These test cases cover all the rules or combinations of input conditions defined in the decision table,
ensuring comprehensive testing of the triangle problem. By executing these test cases, we can validate the
correctness of the system's behavior in determining the type of triangle based on the given side lengths.
It's important to note that decision table-based testing is a structured and systematic approach to test case
design, helping to ensure that all possible combinations of input conditions are considered and tested.
However, it may not be suitable for all types of problems or systems, especially those with complex or
continuously varying input domains.

15.b) How Sandwich Integration Testing Works? Explain with an example.

Sandwich Integration Testing, also known as Top-Down and Bottom-Up Integration Testing, is a hybrid
testing approach that combines the advantages of both top-down and bottom-up integration testing
techniques. It aims to test the integration of components or modules from both ends, starting with the
highest-level components and the lowest-level components simultaneously.

The sandwich integration testing process typically involves the following steps:

1. Start with Stubs and Drivers:

o Stubs: At the bottom level, stubs are created to simulate the behavior of the lower-level
components or modules that are not yet available or implemented.
o Drivers: At the top level, drivers are created to simulate the behavior of the higher-level
components or the main program that will interact with the components being tested.
2. Top-Down Integration Testing:
o Begin by testing the top-level components or modules using the drivers and stubs.
o Integrate and test the lower-level components or modules one by one, replacing the
corresponding stubs with the actual components as they become available.
3. Bottom-Up Integration Testing:
o Simultaneously, start testing the lowest-level components or modules using the stubs and
drivers.
o Integrate and test the higher-level components or modules one by one, replacing the
corresponding stubs with the actual components as they become available.
4. Sandwich Integration:
o As the top-down and bottom-up integration testing progresses, the two ends (top and bottom)
eventually meet in the middle, forming a "sandwich" of integrated components.
o The remaining components or modules in the middle are then integrated and tested.
5. System Testing:
o Once all components and modules have been integrated and tested, perform system testing to
verify the overall functionality and behavior of the complete system.

Example:

Consider a software system for an e-commerce website that consists of the following components:

1. User Interface (UI)

2. Shopping Cart
3. Inventory Management
4. Order Processing
5. Payment Gateway Integration
6. Shipping Module

In sandwich integration testing, the process might look like this:

1. Start with Stubs and Drivers:

o Create stubs for the Inventory Management, Order Processing, Payment Gateway Integration,
and Shipping Module components.
o Create a driver for the User Interface component.
2. Top-Down Integration Testing:
o Test the User Interface component using the driver and stubs for the lower-level components.
 oIntegrate and test the Shopping Cart component, replacing the corresponding stubs with the
actual component.
3. Bottom-Up Integration Testing:
o Test the Inventory Management component using stubs for the Order Processing and
Payment Gateway Integration components.
o Integrate and test the Order Processing component, replacing the corresponding stubs with
the actual component.
4. Sandwich Integration:
o Integrate the top-down (UI and Shopping Cart) and bottom-up (Inventory Management and
Order Processing) components, forming the "sandwich."
o Integrate and test the Payment Gateway Integration and Shipping Module components in the
middle.
5. System Testing:
o Perform system testing on the fully integrated e-commerce website to verify its overall
functionality and behavior.

The sandwich integration testing approach helps identify integration issues early in the testing process by
testing components from both ends simultaneously. It also allows for parallel testing and development of
different components, potentially reducing the overall testing and development time. However, it can be
more complex to manage and coordinate compared to pure top-down or bottom-up integration testing
approaches.

16.a) Explain Dynamic Interaction in Multiple Processor with detailed example.

16.b) What is Client Server Testing? Explain the testing Strategy
17.a) Explain the process of finding threads in the SATM System.

The SATM (Search and Thread Management) system is designed to efficiently handle and manage threads
of conversation or activities. Finding threads within this system involves identifying and organizing related
messages or activities into coherent threads. Here’s a detailed process of how this can be achieved:

Process of Finding Threads in the SATM System

1. Data Collection
o Gather Messages/Activities: Collect all messages or activities that need to be analyzed. This
data could come from various sources like emails, chat logs, forum posts, or task
management logs.
2. Preprocessing
o Text Cleaning: Remove any irrelevant information, such as stop words, punctuation, and
special characters, to clean the data.
o Normalization: Convert all text to a standard format, such as lowercasing, to ensure
consistency.
3. Feature Extraction
o Tokenization: Break down the text into individual words or tokens.
o Vectorization: Convert the tokens into numerical vectors using techniques like TF-IDF
(Term Frequency-Inverse Document Frequency) or word embeddings (Word2Vec, GloVe).
o Metadata Extraction: Extract relevant metadata such as timestamps, authorship information,
and subject lines.
 4. Similarity Measurement
o Text Similarity: Calculate the similarity between messages or activities using techniques like
cosine similarity, Jaccard similarity, or semantic similarity using embeddings.
o Metadata Similarity: Consider similarities in metadata, such as timestamps (for
chronological relevance), sender/receiver (authorship connections), and subject lines.
5. Thread Identification
o Clustering: Use clustering algorithms (e.g., K-means, DBSCAN) to group similar messages
or activities into clusters, where each cluster represents a potential thread.
o Chronological Ordering: Order the messages within each cluster chronologically to
maintain the flow of conversation.
6. Thread Validation
o Manual Review: Optionally, have human reviewers validate the identified threads to ensure
accuracy and relevance.
o Algorithmic Validation: Implement metrics such as cohesion (how closely related the
messages in a thread are) and coherence (logical flow within the thread) to validate threads
automatically.
7. Thread Management
o Labeling: Assign meaningful labels or titles to each thread for easy identification.
o Indexing: Index the threads for efficient search and retrieval.
o Visualization: Provide visual representations (e.g., hierarchical tree views, timelines) for
better understanding and navigation of threads.

17.b) What is Lewis and Clark’s Expedition Compare Exploratory Testing and the Lewis and Clark
Expedition.

The Lewis and Clark Expedition, also known as the Corps of Discovery Expedition, was a significant
journey undertaken by Meriwether Lewis and William Clark from 1804 to 1806. Commissioned by
President Thomas Jefferson, its primary goal was to explore and map the newly acquired Louisiana
Territory, find a practical route to the Pacific Ocean, and establish an American presence before European
powers tried to claim it. The expedition provided valuable information about the geography, biology,
ethnology, and natural resources of the western part of the continent.

Comparison between Exploratory Testing and the Lewis and Clark Expedition

1. Purpose and Objectives

o Lewis and Clark Expedition: The primary objectives were to explore uncharted territories, document
findings about the natural environment, establish relationships with Native American tribes, and
map a route to the Pacific Ocean.
o Exploratory Testing: The primary goal is to discover issues, bugs, and unexpected behavior in
software by exploring it without predefined test cases. Testers aim to understand how the system
behaves in various scenarios and identify areas that need improvement.
2. Preparation and Planning
o Lewis and Clark Expedition: Extensive planning was required, including gathering supplies, recruiting
a team, and obtaining necessary permissions and support. However, the journey involved navigating
unknown territories with many unforeseen challenges.
o Exploratory Testing: While some initial planning is necessary, such as understanding the software
domain and setting up the testing environment, testers often proceed with minimal formal planning,
allowing flexibility to explore and adapt as they discover new aspects of the software.
3. Approach and Methodology
o Lewis and Clark Expedition: The approach was largely empirical and observational. The team
recorded their observations, made maps, collected specimens, and adjusted their routes based on
findings and environmental conditions.
 o Exploratory Testing: Testers use an empirical approach to learn about the software through direct
interaction. They record observations, take notes on behavior, and modify their testing paths based
on discoveries, continuously refining their understanding of the software.
4. Adaptability and Flexibility
o Lewis and Clark Expedition: The team had to be highly adaptable, dealing with unexpected
geographical features, weather conditions, and encounters with indigenous peoples. They adjusted
their strategies and routes based on real-time information and challenges.
o Exploratory Testing: Testers must be flexible and adapt their testing strategies based on the
behavior of the software. They may change focus areas, test different scenarios, or delve deeper into
certain functionalities as they uncover issues or learn more about the software's behavior.
5. Outcome and Documentation
o Lewis and Clark Expedition: The outcome included detailed maps, scientific observations, and
journals documenting their journey, discoveries, and interactions with native tribes, which provided
invaluable information for future explorers and settlers.
o Exploratory Testing: The outcome includes detailed bug reports, notes on software behavior, and
insights into potential areas for improvement. Testers document their findings to help developers
understand and fix issues, as well as to inform future testing efforts.
6. Value and Impact
o Lewis and Clark Expedition: The expedition had a profound impact on American history,
contributing to the expansion westward, the understanding of the continent’s geography, and the
establishment of trade routes and diplomatic relationships.
o Exploratory Testing: This testing approach significantly enhances the quality of software by
uncovering issues that might not be found through scripted testing alone. It helps improve user
experience, reliability, and performance, ultimately contributing to the success of the software
product.

Conclusion

The Lewis and Clark Expedition and exploratory testing share similarities in their exploratory nature,
adaptability, and empirical methodologies. Both involve venturing into the unknown, making real-time
observations, and adapting strategies based on discoveries. The outcomes of both processes provide valuable
insights and knowledge that significantly impact their respective fields—geographical and scientific
knowledge in the case of Lewis and Clark, and software quality and reliability in the case of exploratory
testing.

18.Explain Test-Then-Code Cycles with Detailed Example

The "Test-Then-Code" cycle is a fundamental practice in Test-Driven Development (TDD), an approach to

software development where tests are written before the code itself. This cycle ensures that the codebase is
continuously tested and meets the requirements before being implemented. The Test-Then-Code cycle
consists of three main steps: writing a failing test, writing the minimal amount of code to pass the test, and
then refactoring the code. Here is a detailed example to illustrate this process.

Example: Developing a Simple Calculator

Step 1: Write a Failing Test

The first step in the Test-Then-Code cycle is to write a test for a new functionality that does not yet exist.
Suppose we want to add a simple addition function to our calculator. We start by writing a test for this
function.

import unittest

class TestCalculator(unittest.TestCase):

def test_add(self):
 calculator = Calculator()
result = calculator.add(2, 3)
self.assertEqual(result, 5)

if __name__ == '__main__':
unittest.main()

At this point, the Calculator class and the add method do not exist. Running this test will result in a failure
because the Calculator class is not defined.

Step 2: Write the Minimal Code to Pass the Test

Next, we implement the minimal amount of code required to make this test pass. We create the Calculator
class and the add method.

class Calculator:

def add(self, a, b):

return a + b

# Now, running the test again should pass.

Step 3: Refactor the Code

After making the test pass, we can refactor the code to improve its structure without changing its behavior.
In this simple example, the code is already quite minimal, so there's no significant refactoring needed.
However, in more complex cases, this step might involve cleaning up the code, renaming variables for
clarity, or extracting methods to reduce duplication.

Additional Functionality: Subtraction

Let’s extend our example to include a subtraction function using the same Test-Then-Code cycle.

Step 1: Write a Failing Test for Subtraction

We add a new test for the subtraction functionality.

class TestCalculator(unittest.TestCase):
def test_add(self):
calculator = Calculator()
result = calculator.add(2, 3)
self.assertEqual(result, 5)

def test_subtract(self):
calculator = Calculator()
result = calculator.subtract(5, 3)
self.assertEqual(result, 2)

if __name__ == '__main__':
unittest.main()

Running this test will fail because the subtract method does not exist yet.

Step 2: Write the Minimal Code to Pass the Test

We implement the subtract method in the Calculator class.

class Calculator:
def add(self, a, b):
return a + b
 def subtract(self, a, b):
return a - b

Running the tests again should now result in both tests passing.

Step 3: Refactor the Code

Once again, we check if any refactoring is needed. The code is already quite minimal, so no significant
refactoring is necessary.

Summary

The Test-Then-Code cycle involves:

1. Writing a Failing Test: Define the functionality by writing a test that initially fails.
2. Writing the Minimal Code to Pass the Test: Implement just enough code to make the test pass.
3. Refactoring the Code: Clean up the code while ensuring that all tests still pass.

By following this cycle, developers ensure that their code is continuously tested and that each new feature is
well-defined and correctly implemented before moving on. This leads to a more reliable and maintainable
codebase.