Sindhi College

Dept of Computer Science

Subject: ST – Question Bank (Solved)
Class: 6th sem BCA
2024-25 (Even sem)
PART-A

I. Answer any Four questions, each carries Two marks. (4x2=8)

1. What is Software Testing?

Ans: Software Testing is a method to assess the functionality of the software program.
The process checks whether the actual software matches the expected requirements and
ensures the software is bug-free. The purpose of software testing is to identify the errors,
faults, or missing requirements in contrast to actual requirements.

2. What is Equivalence Class?

Ans: Equivalence classes refer to groups of input values that are treated the same
way by the software system being tested. Test cases are designed to represent each
equivalence class to ensure that the system behaves consistently for al! values within that
class. This approach helps in reducing the number of test cases needed while maintaining
thorough test coverage. This allows for efficient test case creation while achieving good
test coverage.

3. Define Object Oriented Testing.

Ans: Object-Oriented Testing is a software testing process that is conducted to test the
software using objectoriented paradigms like, encapsulation, inheritance, polymorphism,
etc. The software typically undergoes many levels of testing from unit testing to system
testing. !n simple words, Object Oriented Testing is a collection of testing techniques to
verify and validate object oriented software.
4. What is fault and error?
Ans:  Fault:
 A fault, also known as a bug or defect, is an issue in the software's code or design that
causes it to produce incorrect or unexpected results. It is a flaw introduced during the
development process.
 Error:
 An error is a mistake or discrepancy encountered when a human interacts with the
software, often as a result of a fault. It is the manifestation of a fault during the execution
of the software, leading to incorrect behavior or output.

5. Define sandwich integration.

Ans: Sandwich Integration Testing is a hybrid approach that combines elements of both
Top-Down and Bottom-Up Integration Testing strategies. In this method, testing starts
simultaneously from the top (main control modules) and the bottom (individual modules)
towards the middle layers of the software system.

6. Define weak normal equivalence class testing.

Ans: Weak Normal Equivalence Class Testing [WNECT) is a fundamental technique in
software testing, particularly within the domain of equivalence class testing. This method
is termed "weak" because it operates under the assumption of a single fault, implying that
any failure is attributed to an issue within a single input variable at a time.

7. Define Software testing.

Ans: Software Testing is a method to assess the functionality of the software program.
The process checks whether the actual software matches the expected requirements and
ensures the software is bug-free. The purpose of software testing is to identify the errors,
faults, or missing requirements in contrast to actual requirements.

8. What are Equivalence classes?

Ans: Equivalence classes refer to groups of input values that are treated the same way
by the software system being tested. Test cases are designed to represent each
equivalence class to ensure that the system behaves consistently for al! values within that
class. This approach helps in reducing the number of test cases needed while maintaining
 thorough test coverage. This allows for efficient test case creation while achieving good
test coverage.

9. What is thread?
Ans: A thread in system testing is a sequence of interconnected Atomic System
Functions (ASF) that together accomplish a specific user task or workflow in a
system. It includes all the steps a user takes to achieve a particular outcome to ensure
that the system correctly executes the complete sequence of operations required.
10. What is composition?
In software testing, composition refers to the practice of combining multiple
components or objects to create a more complex system. It involves testing how
these combined parts interact and work together to ensure they function as expected
when integrated.
11. Define exploratory testing.
Ans: Exploratory testing is an approach to software testing where testers
simultaneously design and execute test cases based on their domain knowledge,
experience, and intuition. Unlike traditional scripted testing exploratory testing
involves testers exploring the software application dynamically, without predefined
test cases. Testers learn about the application as they test, uncovering defects,
understanding functionalities and identifying potential risks through an iterative and
explorative approach. The goal of exploratory testing is to discover issues that might
not be found through structured testing techniques.

12. Define SATM.

Ans: The SATM system is designed as a teaching tool or simplified version of a commercial
ATM system, containing only the essential features required to perform basic ATM functions
such as transactions and user interactions. This reduced complexity allows for focused
development and testing, making it an ideal candidate for educational purposes.
 PART-B

II. Answer any Four questions, each carries Five marks. ( 4 x 5 = 20 )

1. Explain Top down and Bottom up integration.

Ans: Top down integration testing uses software testing approach fare testing begins with the
highest level modules or components and gradually processes towards lower level modules. In
this strategy the focus is on integrating and testing the main control modules or components first,
followed by the integration of subordinate modules. Stubs or simulated modules are used to
stand in for lower level modules that have not yet been developed or integrated.
• Working of top down integration testing
1. Start with main module: the testing process begins with the main or top level module of
the software system.
2. Subordinate module integration: once the main module is tested integration proceeds to
the next level of modules that are directly dependent on the main module.
3. Stubs usage: stubs are used to stimulate the behaviour of lower level modules that are not
yet integrated. Stubs provide the necessary input and mimic the output of the missing models.
4. Incremental integration: integration is done incrementally with each level of modules
being added and tested in a step by step manner.
5. Testing continuous downwards: the integration and testing process continuous
downwards through the hierarchy of modules until a components are integrated and tested
together.
Bottom -up integration testing is software testing approach that starts with testing individual
modules or components at the lowest level and gradually processes towards higher level modules
are the complete system. In this strategy lower level modules are integrated and tested first and
then focused shift to integrating higher level modules that depend on the already tested your
level components. Drives are used to stimulate the behaviour of fire level modules that are not
yet developed or integrated.

• Working of bottom of integration testing

1. Start with Lowest-Level Modules: Testing begins with the individual modules at the lowest
level of the software system.
2. Higher-Level Module Integration: Once the lower-level modules are tested, integration
proceeds to the next level of modules that depend on the already tested components.
3. Drivers Usage: Drivers are used to simulate the behavior of higher-level modules that are not
yet integrated. Drivers provide the necessary input and mimic the output of the missing modules.
4. Incremental Integration: Integration is done incrementally, with each level of modules being
added and tested in a step-by-step manner.
5. Testing Continues Upwards: The integration and testing process continues upwards through
the hierarchy of modules until all components are integrated and tested together.

2) Explain model based testing.

Ans: Model-Based Testing [MBT) is a methodology in software testing where test cases are
derived from models that represent the desired behavior of the system under test. These models
can be viewed as abstract representations of the system's functionalities, capturing the various
states, transitions, inputs, and outputs. The primary goal of MBT is to ensure that the system
behaves as expected by systematically exploring these models to generate comprehensive test
cases.
Key Components of Model Based Testing
1. Models: • Definition: Models are simplified representations of the system that capture
essential behavior and logic. They can take various forms, such as state machines, flowcharts,
Petri nets, or UML diagrams.
• Purpose: Models serve as the basis for generating test cases and providing a blueprint of the
system’s expected behavior
2. Test Case Generation:
• Process: Test cases are automatically or manually derived from the models. This involves
identifying all possible paths or sequences of actions within the model that need to be tested.
This systematic approach helps ensure coverage of different scenarios edge cases, and potential
points of failure.
3. Execution and Validation:
• Execution: The generated test cases are executed on the actual system to verify its behaviour
against the model.
Validation: Results are compared with the expected outcomes defined in the model. deviations
are analyzed to identify defects or inaccuracies in the model or the system.

3) Explain Retrospective on MDD & TDD.

Ans: In software development, understanding different methodologies and their impacts on the
development process is crucial. Model-Driven Development (MDD) and Test-Driven
Development [TDD) are two such methodologies, each offering unique perspectives and
approaches. Both MDD and TDD offer valuable perspectives for software development. MDD
provides a high-level, structured approach that ensures completeness and consistency, while
TDD focuses on incremental development and strong fault isolation. Combining the strengths of
both methodologies can lead to a more robust and maintainable software development process,
catering to both big-picture design and detailed, test-driven implementation.
4) Discuss Structure based testing.
Ans: Structure-based testing, also known as white-box testing, involves designing test cases
based on the internal structure of the software. This approach aims to validate the flow of inputs
through the code, ensuring that all paths are exercised and potential errors are identified early.
Here’s a concise explanation for 5 marks:
1. Definition: Structure-based testing is a testing technique where the internal structure of
the software is used to design test cases. It requires knowledge of the code, architecture,
and implementation details.
2. Techniques: Common techniques in structure-based testing include:
o Statement Coverage: Ensures each statement in the code is executed at least once.
o Branch Coverage: Ensures every branch (decision) in the code is taken at least
once.
o Path Coverage: Ensures all possible paths through the code are tested.
o Condition Coverage: Ensures each condition in a decision is evaluated to both
true and false.
 3. Advantages:
o Helps in identifying hidden errors and vulnerabilities within the code.
o Ensures a thorough testing process by covering all possible paths and branches.
o Provides a clear understanding of the code logic and helps in optimizing it.
4. Challenges:
o Requires detailed knowledge of the code, which might not always be available to
testers.
o Can be time-consuming and complex, especially for large codebases.
o May not detect issues related to missing functionalities or integration problems.
5. Applications:
o Particularly useful in critical systems where reliability and correctness are
paramount.
o Employed in unit testing, integration testing, and during the debugging process.
Structure-based testing is a crucial technique in software testing that complements other testing
methods, ensuring a comprehensive evaluation of the software's internal logic and structure.

5) Explain next date function complexities.

Ans: Testing the NextDate function involves several complexities due to the nature of date
calculations and the specific requirements of the function. Some key complexities in testing the
NextDate function are:
1. Input Domain Complexity: The NextDate function operates within specific ranges for month,
day, and year inputs. Testing all possible combinations within these ranges can be challenging
and time- consuming, especially considering edge cases and boundary conditions.
2. Leap Year Handling: Testing the function's behaviour around leap years adds complexity.
Ensuring that the function correctly identifies leap years and adjusts the date calculation
accordingly requires thorough testing to cover all scenarios, including leap day (February 29th)
considerations.
3. Invalid Input Scenarios: Testing for invalid inputs, such as providing a day beyond the valid
range for a specific month or entering an incorrect month number, requires comprehensive test
cases to validate the function's error-handling mechanisms.
4. Boundary Testing: Testing at the boundaries of the input ranges (e.g., the last day of a month,
the last month of the year) is crucial to verify the function's accuracy in handling critical
transition points.
5. Combination Testing: Verifying the function's behavior for various combinations of valid and
invalid inputs adds complexity. Testing scenarios where multiple input variables interact to
determine the output date is essential to ensure comprehensive coverage.
6. Output Verification: Validating the correctness of the output date generated by the NextDate
function against expected results for a wide range of input scenarios is a key aspect of testing
complexity.
7. Error Handling: Testing the function's ability to handle errors gracefully, such as providing
informative error messages for invalid inputs or exceptional cases, requires thorough testing to
ensure robust error management.

6) What are the types of Boundary value testing?

Ans: Boundary value testing is a critical technique in software testing where special focus is
placed on the values at the edge of input domains. The four t3TJes of boundary value testing are:
1.Normal Boundary Value Testing: Normal Boundary Value Testing (NBVT) is a technique that
focuses on testing the boundaries of the input space to uncover potential errors that often occur
near extreme values of input variables. The rationale behind NBVT is to test input values at their
minimum, just above the minimum, at a nominal value, just below the maximum, and at the
maximum value. This approach helps to identify common errors such as off-by-one errors,
incorrect conditional checks (using < instead of <=), and misunderstandings about where
counting should start (from zero or one). Normal Boundary Value test cases for two variables.

2. Robust Boundary Value Testing: Robust Boundary Value Testing extends Normal Boundary
Value Testing by including values just outside the valid range. It tests the system's ability to
handle inputs slightly beyond the expected boundaries.
Robust Boundary Value Testing is crucial for systems where input validation directly impacts
functionality and security. By including tests for inputs just outside the accepted ranges, RBVT
helps ensure that the application is secure against unusual or unexpected inputs, enhancing the
overall resilience and reliability of the system. This testing approach is particularly valuable in
protecting against errors that could lead to exceptions, system crashes, or security breaches.
Robust boundary value test cases for two variables are shown in Figure 2.2
3. Worst-Case Boundary Value Testing: Worst-Case Boundary Value Testing examines the
effects of all combinations of boundary values across multiple variables. It explores interactions
between variables at their boundary conditions.
This type of testing is particularly useful in critical systems where failure can result in significant
consequences, ensuring that the system is robust against a wide range of inputs and,
conditions. It's essential for ensuring the reliability and stability of system in real world scenarios
where multiple factors may affect outcomes simultaneously.
The result of the two-variable version of this is shown in Figure 2.3.

4. Robust Worst-Case Boundary Value Testing: Robust Worst-Case Boundary Value Testing
combines out-of-range values for multiple variables to stress test the system. It includes extreme
combinations, even those outside the valid input ranges. This approach focuses on evaluating
the software's behavior under extreme conditions while also testing for robustness against
unexpected inputs and variations in the boundary values of multiple variables simultaneously.

7. Explain slice based testing.

 Ans: Slice-based testing is a testing technique that focuses on verifying specific parts
of a program by analysing "slices" of code. A program slice consists of all parts of a program
that affect the values computed at some point of interest, known as a slicing criterion. This
criterion typically includes a Data variable and a program point. The primary goal of slice-
based testing is to isolate and test parts of a program that contribute to the outcome at
specific points. It reduces the complexity involved in understanding and testing the entire
program.
Characteristics or Features of Slice Based Testing Slice-based testing is a specialized approach
within software testing focused on analysing specific "slices" of code related to certain variables
or conditions. The key characteristics or features of slice- based testing are:
1. Slicing Criterion: Testing revolves around a specific variable or set of variables that influence
the program's behaviour at a certain point or over a section of the program. The slicing criterion
typically includes the variable of interest and the specific location in the code.
2. Program Slices: A slice is a subset of a program that includes all the statements that could
affect the values of the variables in the slicing criterion at specific points. It isolates the parts of
code that are directly relevant to the criterion.
3. Data Flow Analysis: Slice-based testing relies heavily on data flow analysis to determine how
data moves through the program and which parts of the program are affected by and affect the
slicing criterion.
4. Static and Dynamic Slicing: • Static Slicing: Analyses the program’s source code without
executing it, providing slices based on potential data flow. « Dynamic Slicing: Generates slices
based on actual execution paths and runtime data, which are specific to a particular execution
instance.
5. Reduction of Complexity: By focusing on slices, testers can reduce the complexity of the test
environment and concentrate on verifying specific functionalities without the overhead of the
entire program’s context.

8. Explain Top down and Bottom up integration.

Ans: Top down integration testing uses software testing approach fare testing begins with the
highest level modules or components and gradually processes towards lower level modules. In
this strategy the focus is on integrating and testing the main control modules or components first,
followed by the integration of subordinate modules. Stubs or simulated modules are used to
stand in for lower level modules that have not yet been developed or integrated.
• Working of top down integration testing
1. Start with main module: the testing process begins with the main or top level module of
the software system.
2. Subordinate module integration: once the main module is tested integration proceeds to
the next level of modules that are directly dependent on the main module.
3. Stubs usage: stubs are used to stimulate the behaviour of lower level modules that are not
yet integrated. Stubs provide the necessary input and mimic the output of the missing models.
4. Incremental integration: integration is done incrementally with each level of modules
being added and tested in a step by step manner.
5. Testing continuous downwards: the integration and testing process continuous
downwards through the hierarchy of modules until a components are integrated and tested
together.
Bottom -up integration testing is software testing approach that starts with testing individual
modules or components at the lowest level and gradually processes towards higher level modules
are the complete system. In this strategy lower level modules are integrated and tested first and
then focused shift to integrating higher level modules that depend on the already tested your
level components. Drives are used to stimulate the behaviour of fire level modules that are not
yet developed or integrated.

• Working of bottom of integration testing

1. Start with Lowest-Level Modules: Testing begins with the individual modules at the lowest
level of the software system.
2. Higher-Level Module Integration: Once the lower-level modules are tested, integration
proceeds to the next level of modules that depend on the already tested components.
3. Drivers Usage: Drivers are used to simulate the behavior of higher-level modules that are not
yet integrated. Drivers provide the necessary input and mimic the output of the missing modules.
4. Incremental Integration: Integration is done incrementally, with each level of modules being
added and tested in a step-by-step manner.
5. Testing Continues Upwards: The integration and testing process continues upwards through
the hierarchy of modules until all components are integrated and tested together.

9. Explain model based testing.

Ans: Model-Based Testing [MBT) is a methodology in software testing where test cases are
derived from models that represent the desired behavior of the system under test. These models
can be viewed as abstract representations of the system's functionalities, capturing the various
states, transitions, inputs, and outputs. The primary goal of MBT is to ensure that the system
behaves as expected by systematically exploring these models to generate comprehensive test
cases.
Key Components of Model Based Testing
1. Models: • Definition: Models are simplified representations of the system that capture
essential behavior and logic. They can take various forms, such as state machines, flowcharts,
Petri nets, or UML diagrams.
• Purpose: Models serve as the basis for generating test cases and providing a blueprint of the
system’s expected behavior
2. Test Case Generation:
• Process: Test cases are automatically or manually derived from the models. This involves
identifying all possible paths or sequences of actions within the model that need to be tested.
This systematic approach helps ensure coverage of different scenarios edge cases, and potential
points of failure.
3. Execution and Validation:
• Execution: The generated test cases are executed on the actual system to verify its behaviour
against the model.
Validation: Results are compared with the expected outcomes defined in the model. deviations
are analyzed to identify defects or inaccuracies in the model or the system.

10. Explain the features of Junit.

• JUnit is a widely-used testing framework for Java that supports test-driven development and
automated testing. JUnit helps developers write and run repeatable tests, ensuring that the code
behaves as expected.
1.Annotations: JUnit uses annotations to define test methods and setup/teardown methods.
Common annotations include:
• @Test: Marks a method as a test method.
• © Before: Specifies a method that runs before each test.
• @After: Specifies a method that runs after each test.
• @BeforeClass and @ AfterClass: Define methods that run once before and after all tests in a
class, respectively.
2. Assertions: JUnit provides a set of assertion methods to verify expected outcomes. Common
assertions include:
• assertEquals(expected, actual): Checks that two values are equal.
• assertTrue(condition): Checks that a condition is true.
assertFalse(condition): Checks that a condition is false.
assertNot null object): Checks that an object is not null.
3. Test runners: junit test runners execute tests and provides feedback on test results. The
default test runners runs all test methods in a class and reports the result.
4. Integration: JUnit integrates seamlessly with Java IDEs (like Eclipse and IntelliJ IDEA) and
build tools (like Maven and Gradle). This integration facilitates continuous testing by allowing
tests to be run automatically as part of the build process.

11. Discuss Testing Life Cycle.

Ans: The Testing Life Cycle is a critical framework in software development that
systematically identifies, diagnoses, and resolves issues within a software product to
ensure quality and reliability. By following a structured approach, teams can effectively
address defects, enhance functionality, and meet specified requirements. This disciplined
process helps prevent defects from reaching production, reducing costs and increasing
user satisfaction. The Testing Life Cycle in the below diagram illustrates the various
stages involved in identifying and resolving issues during software development. This
cycle is an integral part of ensuring software quality through systematic testing and issue
management.
 1. Specification (Spec): The testing cycle begins at the specification phase, where
requirements are defined and documented. It is crucial to have a clear, thorough, and
unambiguous specification because errors at this stage can propagate through to later
stages, leading to more severe issues.
2. Design: During the design phase, the specifications are transformed into a design plan
that outlines the software architecture and its components. Faults can arise here if the
design does not accurately or efficiently implement the specifications. Such design faults
could be logical errors in flow or inefficient architecture choices.
3. Coding: In the coding phase, developers write the actual code based on the design
documents. This stage is prone to introducing faults due to human error in implementing the
design logic, misunderstanding requirements, or syntactical errors in the code.
4. Testing: Once coding is completed, the testing phase begins to check the software for
defects {faults} and ensure that it performs as expected. The goal is to identify and
document any incidents arising from faults in the software.
5. Classify Fault: When a fault causes an incident, the issue is analyzed and classified.
This involves determining the nature of the fault, such as whether it's due to a requirem
ent misunderstanding, design error, or coding mistake. Classifying incidents helps in
prioritizing them for fixes.
6. Isolate Fault: Once an incident is reported and classified, the next step is to isolate the
specific part of the code or design that is causing the problem. This precise identification is
critical for effectively addressing the fault without introducing new issues.
 7. Fault Resolution; The final phase in the testing cycle is resolving the fault. This
involves modifying the code or design to fix the issue and verifying that the fix resolves
the problem without causing additional problems. This stage is crucial as inadequately
resolved faults can lead to further errors or even new faults.

12. Explain special value testing.

Ans: Special Value Testing also known as ad hoc testing is a form of functional testing that
relies on the tester's domain knowledge, experience with similar programs, and
understanding of potential weak points in the software to design test cases. This approach is
highly dependent on the tester's judgment and expertise as no specific guidelines are
followed other than best engineering practices. Special Value Testing can be valuable in
uncovering faults that may not be easily detected by other testing methods. Testers using
this approach often consider unique or critical scenarios that may not be covered by
traditional boundary value testing.
Characteristics of Special Value Testing
 Tester-Driven: Special Value Testing heavily relies on the tester's judgment, experience,
and expertise. The effectiveness of this testing approach is highly dependent on the
individual tester's capabilities and insights in identifying critical test scenarios.
 Domain Knowledge: Testers leverage their in-depth understanding of the-application's
domain to anticipate potential error-prone areas. By applying domain knowledge, testers
can pinpoint specific functionalities or modules where defects are more likely to occur
and focus their testing efforts accordingly.
 Ad Hoc Approach: Special Value Testing follows an ad hoc approach, lacking
standardized procedures or guidelines. Testers have the flexibility to design test cases
based on their intuition, experience, and knowledge without strict adherence to
predefined testing methodologies. This creative freedom allows testers to explore unique
scenarios that may not be covered by traditional testing techniques.
 Targeting "Soft Spots": Special Value Testing aims to target "soft spots" within the
software, which are areas known to be prone to errors or vulnerabilities. These soft
spots may include complex calculations, unusual input types, historically problematic
modules, or functionalities with a higher likelihood of defects. By focusing on these
critical areas, testers can uncover hidden issues that might not be revealed through
standard testing methods.
 Importance of Special Value Testing- This method is particularly valuable for:
 Uncovering Rare Issues: By focusing on specific, often rare conditions that are not
typically covered by other testing methods.
 Highly Contextual Applications: Effective in complex systems where the tester's deep
understanding of the application can guide the testing process.
 Areas Prone to Errors: Particularly useful in areas known for their susceptibility to bugs,
where testers can apply their insights to explore specific scenarios thought to be risky.

13. Explain weak normal and strong normal equivalence testing.

Ans: Weak Normal Equivalence Class Testing [WNECT) is a fundamental technique
in software testing, particularly within the domain of equivalence class testing. This
method is termed "weak" because it operates under the assumption of a single fault,
implying that any failure is attributed to an issue within a single input variable at a
time. WNECT aims to simplify the testing process by reducing the number of test
cases to a manageable few, each representing different equivalence classes or
intervals of input variables.
Key characteristics-
1. Equivalence Classes: Inputs are divided into groups (or classes) where each group
represents a set of values that the system should theoretically treat the same. These
classes are defined based on both the input value ranges [valid or invalid) and their
expected behaviours.
2. Single Fault Assumption-. WNECT operates under the premise that failures are due
to issues with one specific input variable at a time. This approach simplifies the
analysis of test results and helps focus on isolating faults in distinct areas of the
system.
3. Representative Sampling: From each equivalence class, one representative sample
is chosen for testing. The idea is that testing this single value is sufficient to infer the
behaviour for all values within that class, assuming the system treats all of them
equivalently
Strong Normal Equivalence Class Testing (SNECT) is an advanced method within
the framework of equivalence class testing used in software testing. This approach
builds on the concepts of Weak Normal Equivalence Class Testing by incorporating
 multiple variables simultaneously in each test case, rather than examining them
individually. SNECT is designed to detect more complex interactions between
variables that might not be evident when variables are tested in isolation.
Key Characteristics of*Strong Noiinai Equivalence Class Testing
1. Multiple Variable Integration: Unlike weak testing, which might consider one
variable at a time, strong testing involves creating test cases that combine
representative values from multiple equivalence classes across different variables.
This approach helps identify issues arising from the interactions between these
variables.
2. Normal Equivalence Classes: This form of testing focuses on normal (valid)
equivalence classes, meaning it uses combinations of values that are all expected to
be handled correctly by the system. The purpose is to confirm that the system behaves
as expected under various combinations of normal conditions.
3. No Single Fault Assumption: SNECT moves away from the single fault
assumption prevalent in weak testing methods. By integrating multiple variables in
each test case, it acknowledges that faults might be caused by complex interactions
between variables rather than issues with individual inputs

PART C

III. Answer any Four questions, each carries Five marks. ( 4 x 8 = 32 )

1)Explain SATM.
Ans: The Simple ATM System [SATM) serves as a practical example to illustrate the
complexities involved in integration and system testing of a client-server architecture. With a set
of functionalities captured in a series of interactive screens, the SATM system provides an ideal
case to examine how different components within an ATM interface work together to handle
user transactions seamlessly.
Problem Statement: The Simple ATM system simulates real-world banking transactions via an
interface shown in Figure 1.6. It demonstrates how various components interact to complete
user-driven tasks.
Identity Key user interaction
 Inserting the ATM card.
 Selecting a transaction type.
 Receiving the card and receipt.
 Entering the PIN.
 Performing the transaction.
A terminal is equipped with various user interaction components like a card slot, keypad,
and screens for displaying messages and options. Customers interact with the SATM by
using a plastic card encoded with a personal account number (PAN). The system
progresses through multiple screens, each corresponding to different stages of
transaction processing from card insertion, PIN entry, transaction selection, to the final
transaction execution. The SATM interacts with bank customers using a sequence of 15
interactive screens as depicted in Figure 1.7. Each screen represents a different stage of
the transaction process, capturing all necessary user interactions and system responses

. Initial Interaction: When a customer approaches the SATM, the interface shown on screen 1
prompts them to insert their ATM card into the card slot. This triggers a verification process
where the system checks the personal account number (PAN] encoded on the card against an
internal database.
. Authentication: If the PAN is verified, the system advances the customer to screen 2, asking
for a PIN. If the PAN does not match, screen 4 appears, indicating the card is invalid and will be
retained. After correct PIN entry, the customer moves to screen 5; incorrect entries after three
attempts lead to screen 4 where the card is retained.
Transaction Selection: On screen 5, the customer selects from available transactions: balance
inquiry, deposit, or withdrawal. The system then navigates to different screens based on the
selection:
Balance Inquiry: Leads directly to screen 14 showing the account balance.
Deposit: If the deposit slot is operational (as per the terminal control file), the system proceeds to
screen 7 to accept the deposit amount. If there is an issue, it moves to screen 12. Following the
deposit, the system processes the transaction and updates the balance on screen 14.
Withdrawal: The system first checks the status of the withdrawal chute. If it's jammed, screen 10
is displayed. If it's operational, screen 7 appears for entering the withdrawal amount. Post this, if
the funds are insufficient, screen 8 is shown; otherwise, the system processes the withdrawal and
displays the new balance on screen 14.

2)Explain STLC.
Ans: The Testing Life Cycle is a critical framework in software development that
systematically identifies, diagnoses, and resolves issues within a software product to ensure
quality and reliability. By following a structured approach, teams can effectively address defects,
enhance functionality, and meet specified requirements. This disciplined process helps prevent
defects from reaching production, reducing costs and increasing user satisfaction. The Testing
Life Cycle in the below diagram illustrates the various stages involved in identifying and
resolving issues during software development. This cycle is an integral part of ensuring software
quality through systematic testing and issue management.
1. Specification (Spec): The testing cycle begins at the specification phase, where requirements
are defined and documented. It is crucial to have a clear, thorough, and unambiguous
specification because errors at this stage can propagate through to later stages, leading to more
severe issues.
2. Design: During the design phase, the specifications are transformed into a design plan that
outlines the software architecture and its components. Faults can arise here if the design does not
accurately or efficiently implement the specifications. Such design faults could be logical errors
in flow or inefficient architecture choices.
3. Coding: In the coding phase, developers write the actual code based on the design documents.
This stage is prone to introducing faults due to human error in implementing the design logic,
misunderstanding requirements, or syntactical errors in the code.
4. Testing: Once coding is completed, the testing phase begins to check the software for defects
{faults} and ensure that it performs as expected. The goal is to identify and document any
incidents arising from faults in the software.
5. Classify Fault: When a fault causes an incident, the issue is analyzed and classified. This
involves determining the nature of the fault, such as whether it's due to a requirem ent
misunderstanding, design error, or coding mistake. Classifying incidents helps in prioritizing
them for fixes.
6. Isolate Fault: Once an incident is reported and classified, the next step is to isolate the specific
part of the code or design that is causing the problem. This precise identification is critical for
effectively addressing the fault without introducing new issues.
7. Fault Resolution; The final phase in the testing cycle is resolving the fault. This involves
modifying the code or design to fix the issue and verifying that the fix resolves the problem
without causing additional problems. This stage is crucial as inadequately resolved faults can
lead to further errors or even new faults.

3)Explain object- oriented testing.

Ans: Testing object-oriented software can be categorized into different levels, each focusing on
specific aspects of the system.
1. Unit Testing: Unit testing in object-oriented systems involves testing individual units or
components of the system in isolation to ensure they function correctly. Unit testing in object-
oriented systems involves testing individual units or components of the system in isolation to
ensure they functions correctly. Unit testing focuses on testing the smallest testable parts of a
software application, fenown as units or components. In object-oriented programming, classes
are often considered as units for testing. The purpose of unit testing is to validate the behavior of
individual classes, methods, or functions to ensure they meet the specified requirements. Unlike
procedural programming, object-oriented programming introduces concepts such as composition,
encapsulation, inheritance, and polymorphism, which create unique challenges and opportunities
for testing. Effective unit testing helps identify issues early, ensures that each part of the system
behaves as expected, and facilitates easier integration and maintenance.
a. Operation/Method Testing: Test individual methods or operations to ensure they perform their
intended functions correctly.
b. Class Testing: Test a class in isolation, including all its methods and interactions with internal
components.
2. Integration Testing: Test interactions between classes to ensure they work together as
expected. Integration testing is a crucial phase in software development, especially in object-
oriented systems, where the goal is to ensure that different classes and their methods interact
correctly after individual unit testing is complete. This process involves combining tested units
(classes and methods] into larger modules and testing them as a group. Integration testing can be
challenging due to the complexities introduced by object-oriented principles such as
encapsulation, inheritance, and polymorphism. We will explore various integration testing
strategies.
3. System Testing: Test the entire system in an environment that closely resembles production to
ensure it meets all specified requirements.

4) Explain ten best practices for software testing excellence.

Ans: Best Practices of Software Testing Software testing is a important part of the software
development lifecycle to ensure the quality, reliability, and performance of software products.
Over the years, the software development field has seen numerous proposed solutions to its
challenges. From high-level programming languages like FORTRAN and COBOL to modern
methodologies such as Agile programming and test-driven development, the industry has
explored various approaches to enhance software development.
1. Model-Driven Agile Development: Combining traditional model-driven development (MDD)
with agile practices creates a powerful approach. Models help identify details that might be
overlooked and are useful for maintenance, while agile practices like test-driven development
(TDD) enhance flexibility and responsiveness. Example: Using UML diagrams to model the
software architecture while applying TDD to develop features incrementally.
2. Careful Definition and Identification of Levels of Testing: Defining clear levels of testing,
such as unit, integration, and system testing ensures that each level focuses on specific objectives
and avoids redundancy.
Example: Implementing unit tests to check individual functions, integration tests to verify the
interaction between modules, and system tests to validate the entire application.
3. System-Level Model-Based Testing: Using executable specifications allows automatic
generation of system-level test cases to ensure comprehensive testing aligned with requirements.
Example: Generating test cases from a model specified in a tool directly links to the
requirements.
4. System Testing Extensions: For complex systems, beyond basic thread testing, include thread
interaction testing, stress testing, and risk-based testing to uncover deeper issues. Example:
Applying stress testing to a banking application to reveal thread interaction faults under heavy
load, and prioritizing tests based on the risk of failure.
5. Incidence Matrices to Guide Regression Testing: An incidence matrix records the
relationships between features and procedures (or use cases and classes), guiding the order of
builds, fault isolation, and regression testing. Example: Creating an incidence matrix for an e-
commerce platform to track dependencies between user features and backend services,
facilitating efficient regression testing.
6. Use of MM-Paths for Integration Testing: MM-paths, which track multiple modules'
interaction paths, are effective for integration testing and can be used alongside incidence
matrices for better test coverage. Example: Using MM-paths to test the integration of different
services in a banking application ensures all interaction paths are validated.
7. Intelligent Combination of Specification-Based and Code-Based Unit-Level Testing:
Combining specification-based testing (focusing on what the software should do) with code-
based testing (focusing on how the software works) provides comprehensive coverage. Example:
Writing unit tests for a payment processing module using both the specifications provided (to
verify functionality) and examining the code to ensure all paths are tested.
8. Code Coverage Metrics Based on the Nature of Individual Units: Selecting appropriate
code coverage metrics based on the specific characteristics of the code ensures relevant and
effective testing.
Example: For a critical security module, aiming for 100% branch coverage to ensure all possible
execution paths are tested.
9. Exploratory Testing during Maintenance: Exploratory testing, where testers actively explore
the software without predefined test cases, is especially useful for understanding and testing
legacy code. Example: Conducting exploratory testing on an old inventory management system
to identify hidden issues before implementing new features.
10. Test-Driven Development (TDD) : TDD involves writing tests before coding, ensuring
excellent fault isolation and continuous integration of small, tested increments. Example:
Developing a new feature for a mobile app by first writing unit tests that define the desired
functionality, then writing the code to pass those tests, and iterating this process.
These best practices represent a combination of tried-and-true methods and innovative
approaches the that can significantly enhance the quality and effectiveness of software testing.
By integrating these practices, testers can achieve a high level of software testing excellence to
ensure that software is reliable, efficient, and meets user expectations.

5) Explain Interaction in single processor.

Static interactions in a single processor refer to the relationships and dependencies between
components or elements within the processor that remain constant and do not change during
the execution of a program. These interactions are typically defined at design time and do not
involve dynamic changes based on inputs or events.
Example:
Static Interactions in a Single Processor Scenario:
1.ATM Welcome Screen Display
Static Welcome Message Display:
Data: Welcome message stored in the ATM's memory.
Event: ATM powers on.
Thread; The ATM processor retrieves and displays the welcome message.
Interaction: The welcome message is consistently displayed on the screen every time the ATM
is powered on, regardless of any other operations or timing, managed by the single processor.
2. Card Reader Activation:
Data: Status of the card reader (ready or not ready}.
Event: ATM initialization.
Thread: The processor checks the card reader status.
Interaction: The card reader is set to 'ready' status upon ATM initialization, ensuring it is
prepared to accept cards, managed solely within the single processor

Dynamic interactions in a single processor refer to the behavior of components within a

computing system that change over time or in response to specific inputs or events. These
interactions involve the dynamic processing of data, state changes, and the execution of tasks
within a single processing unit.
Example:
Dynamic Interactions in a Single Processor Scenario:
ATM Transaction Authentication and Logging
1.Card Insertion and PIN Entry: •
Data: User's card information and entered PIN. •
Event: User inserts card and enters PIN.
Thread: The system reads the card data, verifies the PIN against stored information, and checks
for valid authentication.
Interaction: The system dynamically verifies the PIN and authentication status in real-time,
ensuring the correct PIN is entered before allowing further actions. All these operations are
managed within the single processor of the ATM.
2. Transaction Selection:
Data: Available transaction types (e.g., balance inquiry, withdrawal).
Event: User selects the desired transaction type.
Thread: The system processes the user's selection and prepares to execute the chosen
transaction.
Interaction: The system updates the display and internal state based on the user s selection, to
ensure that the selected transaction is prepared for execution within the single processor
3. Logging the Transaction:
Date: Details of the transaction, such as type, timestamp, and user actions.
Event: Completion of the transaction selection process.
Thread: The system logs the transaction details into a local log file for record-keeping and
auditing.
Interaction: The system dynamically logs the transaction in real-time to ensure that all details
are accurately recorded for future reference. This process is entirely handled within the single
processor of the ATM.

6)Explain pros and cons of test driven development.

Advantages of TDD
1. Working Code: TDD ensures that something always works due to the tight test/code cycles,
leading to a more reliable codebase.
2. Fault Isolation: TDD excels in fault isolation as any failing test indicates that the issue lies in
the most recently added code.
3. Supportive Test Frameworks: TDD is supported by a variety of test frameworks such as JUnit
for Java, making it easier to implement and maintain tests.
4. Early Detection of Issues: TDD encourages developers to write tests before writing the actual
code, leading to early detection of potential issues and bugs.
5. Improved Code Quality: By continuously running tests and refactoring code, TDD can result
in higher code quality and maintainability over time.

Disadvantages of TDD:
1. Dependency on Test Frameworks: TDD heavily relies on test frameworks, and without them,
it becomes challenging to practice TDD effectively.
2. Limited Design Opportunities: The bottom-up nature of TDD may limit opportunities for
elegant design as it focuses on incremental improvements through refactorings.
3. Inadequate for Deep Faults: TDD may not effectively reveal deeper faults that require a
comprehensive understanding of the code such as those uncovered by data flow testing.
4. Learning Curve: TDD may have a steep learning curve for developers who are new to the
practice, as it requires a shift in mindset and workflow.
5. Time-Consuming: Initially, TDD may seem time-consuming as developers need to write tests
alongside the code, which can slow down the development process compared to traditional
methods.

13) Explain the characteristics of Dataflow testing.

Ans: Characteristics of Data Flow Testing Data flow testing is a detailed method of structural
testing aimed at examining how data is handled within software applications. It looks specifically
at the lifecycle of variables from their initialization to their final use in computations. Some key
characteristics of data flow testing are:
1. Definition and Use of Variables: Data flow testing focuses on the points in the code where
variables are defined (given a value] and where these values are subsequently used. This can
include checking variables in conditions, calculations, or as arguments in function calls.
2. Detection of Anomalies: The primary aim is to detect data flow anomalies, which can indicate
faults in the program. These include situations where a variable is defined but never used, used
before it is defined, or redefined without any subsequent use before another definition.
3. Program Graphs: It utilizes program graphs to visually represent the flow of data through the
program. These graphs help in tracing the sequence of events that affect data, making it easier to
spot potential issues.
4. Static Analysis: Data flow testing often involves static analysis, meaning it analyzes the code
without actually executing the program. This allows for detecting certain types of errors and
inefficiencies in code handling of data statically
5. Complexity in Manual Execution: Due to the detailed nature of tracking each variable’s flow
through software, data flow testing can be complex and time-consuming, especially without the
help of sophisticated tools.
6. Suitability for Object-Oriented Code: This type of testing is particularly effective for object-
oriented programming, where the interactions between methods and objects involve numerous
variable definitions and uses.
7. Complementary to Other Testing Methods: While it can be used as a standalone testing
approach, data flow testing is often most effective when used in conjunction with other testing
strategies like path testing. It provides an additional layer of assurance by focusing on aspects of
the code's logic specifically related to data handling.
8. Coverage Metrics: Data flow testing includes various coverage metrics to assess the extent of
testing. These metrics evaluate how thoroughly the data-related aspects of the program code are
tested, ensuring that all potential data interactions are examined.
9. Tool Dependency: Effective data flow testing can depend significantly on the availability of
tools due to its complexity, especially for larger codebases. The lack of commercial tools may
limit its use in some environments.
10. Enhanced Debugging and Maintenance: By identifying how data moves and changes within
a program, data flow testing helps pinpoint where errors occur, making debugging easier and
helping maintain the code more effectively.

14) Explain test-then code cycle.

 Ans: In TDD, the development process is broken down into short, iterative cycles known as
"Test-Then- Code" Cycles. Test-Then-Code Cycles are iterative development cycles where tests
are written before the actual code implementation. It is also known as Test-Driven Development
(TDD) cycles.
The process typically involves the following steps: Test-Driven Development (TDD) is a
software development approach where tests are written before the actual code implementation.
This process involves the following steps:
1. Write a Test:
• Begin by defining a test case that outlines the expected behavior of a specific functionality.
• The test is designed to fail initially as the corresponding functionality has not been
implemented yet.
2. Run the Test:
• Execute the test to confirm that it fails as expected.
• This step validates the test's correctness and ensures that the feature is genuinely missing.
3. Write Code:
• Implement the simplest code necessary to make the failing test pass.
• The focus is on writing code that fulfills the requirements of the test case.
4. Run All Tests:
• After implementing the new functionality, run all existing tests, including the newly added one.
• This step verifies that the new code integrates smoothly with the existing system and does not
break any existing functionality. If the test fails, it indicates that the code implementation is
incorrect or incomplete.
5. Refactor:
• Refactor the code to enhance its structure, readability, and performance without altering
• Refactoring ensures that the code remains clean and maintainable its external behaviour.
• It is essential to ensure that all tests continue to pass after refactoring.
6. Repeat:
• Iterate through this cycle for each new piece of functionality or improvement.
• By continuously following this process, developers build a robust codebase with
comprehensive test coverage.
 15) Explain pros and cons of test- driven development.
Ans: Advantages of TDD
1. Working Code: TDD ensures that something always works due to the tight test/code cycles,
leading to a more reliable codebase.
2. Fault Isolation: TDD excels in fault isolation as any failing test indicates that the issue lies in
the most recently added code.
3. Supportive Test Frameworks: TDD is supported by a variety of test frameworks such as JUnit
for Java, making it easier to implement and maintain tests.
4. Early Detection of Issues: TDD encourages developers to write tests before writing the actual
code, leading to early detection of potential issues and bugs.
5. Improved Code Quality: By continuously running tests and refactoring code, TDD can result
in higher code quality and maintainability over time.

Disadvantages of TDD:
1. Dependency on Test Frameworks: TDD heavily relies on test frameworks, and without them,
it becomes challenging to practice TDD effectively.
2. Limited Design Opportunities: The bottom-up nature of TDD may limit opportunities for
elegant design as it focuses on incremental improvements through refactorings.
3. Inadequate for Deep Faults: TDD may not effectively reveal deeper faults that require a
comprehensive understanding of the code such as those uncovered by data flow testing.
4. Learning Curve: TDD may have a steep learning curve for developers who are new to the
practice, as it requires a shift in mindset and workflow.
5. Time-Consuming: Initially, TDD may seem time-consuming as developers need to write tests
alongside the code, which can slow down the development process compared to traditional
methods.

16)Explain ten best practices for software testing excellence

Ans: Best Practices of Software Testing Software testing is a important part of the software
development lifecycle to ensure the quality, reliability, and performance of software products.
Over the years, the software development field has seen numerous proposed solutions to its
challenges. From high-level programming languages like FORTRAN and COBOL to modern
methodologies such as Agile programming and test-driven development, the industry has
explored various approaches to enhance software development.
1. Model-Driven Agile Development: Combining traditional model-driven development (MDD)
with agile practices creates a powerful approach. Models help identify details that might be
overlooked and are useful for maintenance, while agile practices like test-driven development
(TDD) enhance flexibility and responsiveness. Example: Using UML diagrams to model the
software architecture while applying TDD to develop features incrementally.
2. Careful Definition and Identification of Levels of Testing: Defining clear levels of testing,
such as unit, integration, and system testing ensures that each level focuses on specific objectives
and avoids redundancy.
Example: Implementing unit tests to check individual functions, integration tests to verify the
interaction between modules, and system tests to validate the entire application.
3. System-Level Model-Based Testing: Using executable specifications allows automatic
generation of system-level test cases to ensure comprehensive testing aligned with requirements.
Example: Generating test cases from a model specified in a tool directly links to the
requirements.
4. System Testing Extensions: For complex systems, beyond basic thread testing, include thread
interaction testing, stress testing, and risk-based testing to uncover deeper issues. Example:
Applying stress testing to a banking application to reveal thread interaction faults under heavy
load, and prioritizing tests based on the risk of failure.
5. Incidence Matrices to Guide Regression Testing: An incidence matrix records the
relationships between features and procedures (or use cases and classes), guiding the order of
builds, fault isolation, and regression testing. Example: Creating an incidence matrix for an e-
commerce platform to track dependencies between user features and backend services,
facilitating efficient regression testing.
6. Use of MM-Paths for Integration Testing: MM-paths, which track multiple modules'
interaction paths, are effective for integration testing and can be used alongside incidence
matrices for better test coverage. Example: Using MM-paths to test the integration of different
services in a banking application ensures all interaction paths are validated.
7. Intelligent Combination of Specification-Based and Code-Based Unit-Level Testing:
Combining specification-based testing (focusing on what the software should do) with code-
based testing (focusing on how the software works) provides comprehensive coverage. Example:
Writing unit tests for a payment processing module using both the specifications provided (to
verify functionality) and examining the code to ensure all paths are tested.
8. Code Coverage Metrics Based on the Nature of Individual Units: Selecting appropriate
code coverage metrics based on the specific characteristics of the code ensures relevant and
effective testing.
Example: For a critical security module, aiming for 100% branch coverage to ensure all possible
execution paths are tested.
9. Exploratory Testing during Maintenance: Exploratory testing, where testers actively explore
the software without predefined test cases, is especially useful for understanding and testing
legacy code. Example: Conducting exploratory testing on an old inventory management system
to identify hidden issues before implementing new features.
10. Test-Driven Development (TDD): TDD involves writing tests before coding, ensuring
excellent fault isolation and continuous integration of small, tested increments. Example:
Developing a new feature for a mobile app by first writing unit tests that define the desired
functionality, then writing the code to pass those tests, and iterating this process.
These best practices represent a combination of tried-and-true methods and innovative
approaches the that can significantly enhance the quality and effectiveness of software testing.
By integrating these practices, testers can achieve a high level of software testing excellence to
ensure that software is reliable, efficient, and meets user expectations.

17) Explain test cases of Commission problem.

Ans: While creating test cases for the Commission Problem, it is important to cover various
scenarios to ensure the accuracy and reliability of the program. Here are some example test
cases that can be used to validate the functionality of the Commission program:
 Boundary Value Test Cases:
Test Case 1: Inputting the sales of locks as 0, stocks as 0, and barrels as 0 should result in
zero total sales and zero commission.
Test Case 2: Inputting the sales of locks as 200, stocks as 200, and barrels as 200 should test
the upper bounds of the sales values.
Test Case 3: Inputting the sales of locks as 201, stocks as 201, and barrels as 201 should test
values just outside the upper bounds.
  Valid Input Test Cases:
Test Case 4: Inputting the sales of locks as 50, stocks as 30, and barrels as 20 should
calculate the total sales and commission accordingly.
Test Case 5: inputting the sales of locks as 100, stocks as ISO, and barrels as 75 should
test different sales combinations.
 Invalid Input Test Cases:
Test Case 6: Inputting negative values for sales of locks, stocks, or barrels should result
m an error message.
Test Case 7: Inputting non-numeric values for sales should prompt the user to enter
valid numeric inputs.
 Edge Cases Test Cases:
Test Case 8: Inputting the sales of locks as 1, stocks as 1, and barrels as 1 should test
the lower bounds of the sales values.
Test Case 9: Inputting the sales of locks as 200, stocks as 0, and barrels as 0 should
test the scenario where only one type of product is sold.
 Commission Calculation Test Cases:
Test Case 10: Inputting the sales of locks as 100, stocks as 50, and barrels as 25 should
verify the commission calculation based on the given prices for each product.
These test cases cover a range of scenarios including boundary values, valid inputs, invalid
inputs, edge cases, and commission calculations to ensure thorough testing of the Commission
program. Additional test cases can be designed based on specific requirements and
functionalities of the program.

18) Explain Boundary value testing.

Ans: Boundary value testing is a critical technique in software testing where special focus is
placed on the values at the edge of input domains.
Importance of Boundary Value Testing:
1. High Error Detection Rate at Boundaries; Many errors in software occur at the boundaries of
input ranges due to off-by-one errors and other boundary-related issues. Boundary value testing
specifically targets these potentially problematic areas, which increases the likelihood of
catching bugs that might not be detected by other testing methods that use values well within
the range.
2. Efficiency: Boundary value testing is a cost-effective method in terms of the number of test
cases generated versus the potential defects found. By focusing on the edge cases, it reduces
the number of test cases needed compared to exhaustive testing, which would require much
more time and resources.
3. Common Requirement Specifications: Requirements often define operations or behaviours at
the limits of input ranges (e.g., "the age should be between 18 and 60"). Testing these boundary
conditions directly checks the system's adherence to its specified requirements.
4. Usability and Reliability: By ensuring that the software behaves correctly at boundary values,
developers can improve the usability and reliability of their software. This is because handling
boundary conditions gracefully often reflects the software's ability to handle unexpected or
extreme inputs, which are critical in real-world operations.
5. Early Defect Identification: Identifying defects at the boundaries early in the testing process
can lead to more efficient debugging and resolution, reducing the likelihood of critical issues in
later stages of development.
6. Integrates with Other Test Methods: This method can be effectively combined with other
testing strategies such as equivalence partitioning (where inputs are divided into logically similar
groups), further refining the efficiency and effectiveness of the testing process.

Example for Boundary Value Testing: Suppose a function is designed to accept an integer
value from 1 to 100 inclusive. Boundary would generate test cases for values at and around the
boundaries:
Just below the minimum boundary [e.g., 0]
At the minimum boundary [e.g., 1]
Just above the minimum boundary [e.g., 2)
Just below the maximum boundary [e.g., 99]
At the minimum boundary [e.g., 100)
Just above the maximum boundary [e.g., 101)

The four types of boundary value testing are:

1. Normal Boundary Value Testing: Normal Boundary Value Testing focuses on testing values at
the boundaries within the valid range.
2. Robust Boundary Value Testing: Robust Boundary Value Testing extends Normal Boundary
Value Testing by including values just outside the valid range. It tests the system's ability tD
handle inputs slightly beyond the expected boundaries.
3. Worst-Case Boundary Value Testing: Worst-Case Boundary Value Testing examines the
effects of all combinations of boundary values across multiple variables. It explores interactions
between variables at their boundary conditions.
4. Robust Worst-Case Boundary Value Testing: Robust Worst-Case Boundary Value Testing
combines out-of-range values for multiple variables to stress test the system. It includes extreme
combinations, even those outside the valid input ranges.