SOFTWARE TESTING

2 Marks
[Link] software testing.
• Software testing is an important process in the Software Development
Lifecycle(SDLC).
• Software testing is the process of executing a software application to uncover
defects, validate requirements, and ensure correct operation in its environment.
2. What is equivalence class testing (ECT) give an example.
• Equivalence Class Testing (ECT) is a method used in software testing where it
divides input data into groups (classes).Each class contains values that behave
similarly in the system.
• Triangle Example
If (5,5,5) gives Equilateral Triangle, then:
(6,6,6), (100,100,100), will give the same result.
So testing many similar values is redundant.
3. Define test and test case.
• A test is the process of executing software to find failures. Testing helps to
identify errors, faults, failures, and incidents.
• A test case is a set of inputs, execution conditions, and expected results. It is
used to check specific functionality of the software.
4. What is decision table based testing.
• Decision table testing is a strong functional testing method. It is based on
logical rules.
• It shows inputs and outputs clearly in a table format. Helps testers design test
cases using different condition combinations.
5. What is slice based testing.
• Slice-based testing is a testing technique that focuses on testing specific parts
(slices) of a program.
• The main goal is to test only the important parts of the program instead of the
whole program.
6. What is specification based testing? Give an example.
• Specification-based testing (also called functional testing or black box testing) is
a testing technique in which the functionality of the software is tested based on
requirements and specifications, without knowing the internal code or
implementation.
• Example: Google Search (The user enters text in the search [Link] shows
search [Link] user does not know how Google finds the results internally.)
7. What is weak robust equivalence class testing (WRECT).
• WRECT is a testing methodology that focuses on evaluating how a system
handles both valid and invalid input, With a specific emphasis on scenarios
where unexpected inputs are provided.
• This approach aims to uncover vulnerabilities related to error handling.
[Link] du-path and dc-path.
• A DU-path is a path in a program’s control flow graph that traces the flow of data
from the point where a variable is defined to the point where its value is used.
• A DC-path is a special type of DU-path in which the variable, once defined, is
used without undergoing any redefinition or modification before its usage,
thereby ensuring that the value used is the initially defined with no modifications.
9. What is code based testing? give an example.
• Code-Based Testing is a type of software testing method.
• It focuses on testing the structure of the code.
• It checks the intended flow of the program execution.
• Ex : Checking Whether conditional statements are implemented correctly
10. What is data flow testing.
• Data flow testing is a structural testing method that focuses on,Where variables
get values , Where those values are used.
• It is a white-box testing technique because it checks the internal code.
11. Write a note on equivalence class testing (ECT).
• Equivalence Class Testing (ECT) is a method used in software testing where it
divides input data into groups (classes).
• Each class contains values that behave similarly in the system.
• Testing one value from each class represents the whole class.
• Ex : Triangle Problem.

12. What do you mean by SATM system.

• The SATM system is a software testing example that represents how an ATM
machine works in real life.
• It shows how multiple components (screens, hardware, software, bank server)
work together to complete banking transactions like, Balance enquiry, Cash
withdrawal.
13. What is Top-Down Integration Testing ?

• Top-down integration testing is a testing technique in which testing starts from

the top-level modules and gradually integrates lower-level modules. Stub
modules are used for missing lower modules.
 • Example/Application:
In an online shopping app, the main menu is tested first, then payment and cart
modules are integrated step by step.
14. what is Client-Server Testing ?
• Client-server testing is the process of testing communication and interaction
between client systems and server systems.
• Example/Application:
Testing whether a banking mobile app correctly sends user requests to the bank
server and receives responses.
15. What is Call Graph-Based Integration Testing?
• Call graph-based integration testing is a technique where testing is performed
based on the calling relationships between modules represented using a call
graph.
• Example/Application:
If Module A calls Module B and Module B calls Module C, testing is done
according to this calling sequence.
16. What is Path-Based Integration Testing ?
• Path-based integration testing focuses on testing execution paths between
integrated modules.
• Example/Application:
Testing all possible paths in an ATM system such as card insertion → PIN
verification → cash withdrawal.
17. What is Pairwise Integration Testing ?
• Pairwise integration testing tests the interaction between every pair of modules in
a system.
• Example/Application:
Testing interaction between login-payment, login-cart, and payment-cart
modules separately.
18. what is Thread in System Testing ?
• A thread is a sequence of related activities or operations performed together in a
system.
• Example/Application:
In an e-commerce system, product selection → add to cart → payment is
considered one thread.
19. What is Taxonomy of Interactions ?
• Taxonomy of interactions classify and organize different types of interactions
between system components during testing.
• Example/Application:
Interactions may include user-interface interaction, database interaction, and
network interaction.
20. What is Define-Use Testing?
• Define-Use Testing is a data flow testing technique that checks where variables
are defined and where they are used in a program.
• It helps identify errors such as using a variable before it is initialized.
21. What is Object-Oriented Testing?
• Object-Oriented Testing is the process of testing object-oriented software that
uses classes and objects.
• It verifies the correctness of methods, objects, and interactions between classes.
22. What is Exploratory Testing?
• Exploratory Testing is a testing approach in which test design and execution are
performed simultaneously.
• Testers explore the application without predefined test cases.
23. What is Test-Then-Code Cycle?
• Test-Then-Code Cycle is a development approach where test cases are written
before the actual code.
• The code is then developed to satisfy the test cases.
• It helps ensure that requirements are met from the beginning.
24. What is Test-Driven Development (TDD)?
• Test-Driven Development (TDD) is a software development methodology in which
tests are written before coding.
• Developers write a test, develop code to pass the test, and then improve the
code.
25. What is Model-Based Testing?
• Model-Based Testing is a testing technique that generates test cases from system
models.
• The model represents the expected behaviour of the software.
26. What is Use-Case-Based Testing?
• Use-Case-Based Testing derives test cases from use cases that describe user
interactions with the system.
• It focuses on validating system functionality from the user's perspective.
27. Mention any Two Issues of Object-Oriented Testing.
• Inheritance Complexity.
• Encapsulation
5 Marks
1. What is boundary value testing ? explain the importance of boundary value
testing.
• Boundary Value Testing (BVT), is a specification-based (black-box) testing
technique.
• It focuses on testing the boundary values of the input domain because errors are
most likely to occur at the edges of input ranges rather than in the middle.
Importance :
1. High Error Detection at Boundaries
• Many defects occur due to off-by-one errors or wrong comparison
operators.
• Boundary testing directly targets these weak spots.
2. Efficiency
• Detects more defects compared to random testing.
• Saves time and cost.
3. Matches Requirement Specifications
• Most requirements define limits (e.g., age 18–60, marks 0–100).
• BVA ensures these rules are correctly implemented.
4. Improves Reliability and Usability
• Proper handling of boundary inputs leads to stable behavior.
• Reduces crashes and improves real-world performance.
5. Reduces Risk of System Failures
• Testing boundary values helps identify conditions that may cause the
system to crash or behave unexpectedly.
• It ensures the application can handle extreme input values safely.
6. Enhances Software Quality
• By detecting defects early in the testing process, Boundary Value Testing
improves the overall quality of the software.
• It helps deliver a more accurate and dependable application to users.

2. Explain the importance of software testing.

[Link] Can Be Identified Early

• Software testing helps to find bugs and errors at an early stage.
• Early detection makes bugs easy and cheap to fix.
[Link] with Scalability
• Testing checks how software behaves under heavy load.
• It identifies scalability issues in the application, for better working.
[Link]-Effectiveness
• Fixing bugs after release is costly and time-consuming.
• Testing during development saves money and effort.
 [Link] Risks
• Testing finds problems early in the development process,early fixing
reduces the risk of project failure.
• It avoids major system breakdowns in future.
[Link] Security
• Testing helps identify security vulnerabilities
• It prevents attackers from exploiting software weaknesses, protects
sensitive user and business data.
6. Improves Software Quality
• Testing ensures that the software functions according to the specified
requirements.
• It improves the overall quality, performance, and reliability of the
application.
7. Increases Customer Satisfaction
• A well-tested software product provides a better user experience.
• Fewer errors and smooth performance increase customer trust and
satisfaction.

3. Write the advantage and disadvantage of equivalence class testing.

Advantages of Equivalence Class Testing

1. Efficiency
• Fewer test cases are required because inputs are grouped into equivalent
classes.
• This reduces the time and effort needed for testing.
2. Good Coverage
• It tests representative values from each input class.
• This helps ensure that different input conditions are adequately covered.
3. Error Detection
• It is effective in identifying errors related to invalid inputs.
• It helps verify that the system correctly handles both valid and invalid data.
4. Simple Method
• The technique is easy to understand and apply.
• Test cases can be designed quickly by dividing inputs into classes.
5. Cost-Effective
• Reducing the number of test cases lowers testing costs.
• It helps optimize the use of testing resources without compromising quality.
Disadvantages of Equivalence Class Testing
1. Assumes Independent Inputs
• The technique assumes that input conditions are independent of each
other.
 • In real-world applications, inputs may interact and affect system behavior.
2. May Miss Boundary Values
• It focuses on input classes rather than boundary values.
• Important defects occurring at the boundaries may remain undetected.
3. Limited Coverage
• It does not test every possible input value.
• Some defects may be missed if they occur outside the selected
representative values.
4. Subjective Classification
• Different testers may create different equivalence classes.
• This can lead to variations in test case design and coverage.
5. Not Suitable for Complex Logic
• It may not effectively test applications with complex business rules.
• Additional testing techniques may be needed to achieve complete
coverage.

4. How def-use testing works? Explain with example.

Def-Use testing works by checking how variables are defined and then used in a
program.
Steps with Explanation (Theory Example):
1. Identify Variables → List all variables in the program that need to be tested.
2. Construct Program Graph → Represent statements as nodes and control flow
as edges to show data movement.
3. Determine Definition Points (DEF) → Find where variables are assigned
values (initialization, assignment, input).
4. Identify Usage Points (USE) → Find where variables are used in computations
(C-use) or conditions (P-use).
5. Trace DU-Paths → Trace paths from definition to use for each variable.
6. Identify DC-Paths → From DU-paths, find paths where the variable is not
redefined before use.
7. Test Each Path → Create test cases to execute DU and DC paths.
8. Analyze Results → Verify correct value flow and program behavior.

Example :
Consider a program that calculates student grades:
• Marks are used to compute the average, and the average is then used to
decide the grade.
 • Paths can be traced from marks to average calculation, and from average to
grade decision.
• Some paths are definition-clear, meaning the value is used directly without
redefinition.
• Test cases with different marks check if the grade is correctly assigned and
results confirm proper data flow.

5. Explain normal boundary value testing(NBVT) With an example.

• Normal Boundary Value Testing (NBVT) is a software testing technique used

to verify the behavior of a system at the boundary values of input ranges.
• The objective of NBVT is to ensure that the system behaves correctly when
inputs are at their lower and upper limits.
• It helps identify errors such as incorrect comparisons, wrong calculations,
and off-by-one mistakes.
• NBVT improves the reliability and accuracy of software by verifying that
boundary conditions are handled properly.
Example : Two Variables (GST System)
• Scenario: GST Payment System
• Variables
• Total Sales (x₁): ₹20 to ₹10,00,000
• GST Rate (x₂): 5% to 28%
• Boundary Testing for Total Sales

Sales GST Purpose

20 5% Minimum Boundary
500000 18% Nominal value
999999 28% Just below max
1000000 28% Maximum boundary

Boundary Testing for GST Rate (Sales fixed at ₹50,000)

• (50,000, 5%)
• (50,000, 12%)
• (50,000, 18%)
• (50,000, 28%)
Result :
• These test cases verify that GST is calculated correctly at the minimum and
maximum valid boundaries.
• They help ensure that the system handles boundary values without errors.
6. Explain the levels of testing in v-model.

Levels of Testing in V-Model

• The V-Model is a software development model that integrates testing activities
with development activities.
• It is an improved version of the Waterfall Model where each development
phase has a corresponding testing phase.
• The left side of the V represents development phases, while the right side
represents testing phases.
1. Unit Testing
• Unit Testing corresponds to the Detailed Design phase.
• It tests individual modules or components of the software.
• It helps detect coding and logic errors at an early stage.
2. Integration Testing
• Integration Testing corresponds to the Preliminary Design phase.
• It verifies the interaction between different software modules.
• It helps identify interface and communication defects.
3. System Testing
• System Testing corresponds to the Requirements Specification phase.
• It tests the complete software system as a whole.
• It ensures that the system meets user and business requirements.
Conclusion
• The V-Model establishes a clear relationship between development and testing
activities.
• This approach improves software reliability and quality.
7. Discuss the guidelines and observation for data flow testing.

Guidelines :

1. Understand Program Structure

• Understanding the program structure and control flow graph helps in
analyzing how the program executes.
• It also helps in identifying Def-Use pairs and program slices for better testing.
2. Integrate with Other Testing Methods
• It can be combined with unit testing, integration testing, and system testing.
• This improves the overall quality and effectiveness of testing.
3. Regularly Update Test Cases
• Test cases should be updated whenever there are changes in the code.
• New code creates new paths, so new test cases are required.
4. Use Automated Testing Tools
• Automated tools help analyze data flow paths more efficiently.
• They reduce manual effort and improve the accuracy of testing.

Observations:

1. Complexity and Cost

• Data flow testing is complex, time-consuming, and costly, especially for large
programs.
2. Tool Dependency
• Data flow testing depends on tools as manual testing is difficult.
• Tools make the testing process easier and more efficient.
3. Learning Curve
• It requires a good understanding of data flow concepts.
• Beginners may find it difficult to apply effectively.
4. Effective Defect Detection
• Data flow testing is effective in identifying variable-related defects.
• It helps detect anomalies such as undefined or unused variables.

8. What is decision table. Explain the characteristics of decision tables.

A decision table is a tabular representation of conditions and their corresponding

actions, used to model and analyze decision-making logic in a structured and
systematic manner.
 Characteristics of decision table.
1. Conditions
• Conditions are input factors that influence decision-making.
• They represent different situations or criteria that must be evaluated.
2. Actions
• Actions are the outputs produced based on the evaluated conditions.
• Different combinations of conditions can lead to different actions.
3. Visual Representation
• Decision tables use a tabular format to represent conditions and actions.
• This makes complex decision logic easy to understand and analyze.
4. Scalability
• Decision tables can handle a large number of conditions and actions.
• They help organize complex decision-making processes efficiently.
5. Flexibility
• Decision tables are easy to modify when requirements change.
• New conditions or actions can be added without redesigning the entire table.
6. Accuracy
• They help ensure that all possible condition combinations are considered.
• This reduces the chances of missing important test cases or decisions.
•

9. What is System Testing ? What are the Key Objectives of System

Testing ?
• System Testing is a type of software testing in which the complete and integrated
software system is tested as a whole.
• It is performed to verify whether the system meets the specified requirements
and functions correctly.

Key Objectives of System Testing

1. Verify Complete System Functionality
• Ensures all modules work together correctly as a complete system.
• Checks whether system operations function according to requirements.
2. Validate System Requirements
• Verifies both functional and non-functional requirements.
• Ensures the software satisfies user and business needs.
3. Identify Defects and Errors
• Detects issues related to integration, data flow, and functionality.
• Helps identify system failures before deployment.
4. Evaluate System Performance
• Tests system speed, responsiveness, and stability.
• Verifies system performance under different workloads.
 5. Ensure Proper User Interaction
• Checks whether the user interface works correctly.
• Ensures smooth interaction between user and system.
6. Test System Security and Reliability
• Verifies system protection against unauthorized access.
• Ensures reliable operation under different conditions.

10. Explain the features or Characteristics of System Testing.

Features / Characteristics of System Testing
1. Complete System Testing
• System Testing is performed on the fully integrated software system.
• All modules and components are tested together as a complete
application.
2. Requirement Based Testing
• Testing is conducted based on functional and non-functional
requirements.
• It ensures the software meets user and business expectations.
3. End-to-End Testing
• The entire workflow of the application is tested from start to end.
• It validates complete system functionality and data flow.
4. Black Box Testing Technique
• System Testing mainly follows the black box testing approach.
• Testers focus on inputs and outputs without checking internal code
structure.
5. Validation of Functional and Non-Functional Requirements
• It verifies functions such as login, transactions, and reporting.
• It also checks performance, security, usability, and reliability.
6. Independent Testing Process
• System Testing is usually performed by an independent testing team.
• This helps provide unbiased evaluation of the software system.

11. How Pair wise Integration Testing Works ?

Pairwise Integration Testing tests the interactions between pairs of modules to
ensure that integrated components work correctly.

Working :
1. Pair Selection
• Modules are selected in pairs based on their dependencies and interactions.
• The selection is guided by software architecture and integration points.
 2. Test Scenario Design
• Test cases are designed to cover interactions between each pair of modules.
• Scenarios focus on data flow, input-output relationships, and error handling.
3. Isolation of Pairs
• Each pair of modules is tested separately from other modules.
• This helps identify integration issues specific to that pair.
4. Combinatorial Testing
• Pairwise testing covers all possible interactions between pairs of modules.
• It reduces the number of test cases while maintaining good coverage.
5. Execution and Analysis
• Test cases are executed to verify module interactions.
• Results are analyzed to identify communication or data-related issues.
6. Issue Identification and Resolution
• Integration defects are detected and documented.
• Issues are fixed to ensure correct interaction between modules.
7. Iterative Process
• Testing is repeated after defects are fixed.
• Test scenarios may be refined based on feedback and results.

12. What is GUI Testing ? Explain GUI Testing Strategies.

• GUI (Graphical User Interface) is a visual interface that allows users to interact
with a software application using graphical elements such as buttons, menus,
icons, and text boxes.
• It provides an easy and user-friendly way to access system functions.
GUI Testing Strategies
1. Functional Testing
• Functional testing verifies that all GUI components perform their intended
functions correctly.
• It checks buttons, menus, input fields, and other interface elements to
ensure proper behavior.
2. Usability Testing
• Usability testing evaluates the user-friendliness and ease of use of the
graphical interface.
• It helps ensure that users can navigate and operate the application
efficiently.
3. Compatibility Testing
• Compatibility testing ensures that the GUI functions correctly on different
browsers, operating systems, and devices.
• It helps identify display and functionality issues across various platforms.
 4. Localization Testing
• Localization testing verifies that the GUI supports different languages,
regions, and cultural settings.
• It checks translations, date formats, currency symbols, and localized
content.
5. Accessibility Testing
• Accessibility testing ensures that the GUI can be used by people with
disabilities.
• It verifies features such as screen reader support, keyboard navigation, and
proper color contrast.

13. Write the Importance of Craftmanship in Software Testing.

Importance of Craftsmanship in Software Testing
1. Quality Assurance
• High craftsmanship ensures that software is tested thoroughly.
• It helps identify and fix defects before the software reaches users.
2. Reliability
• Skilled testers can anticipate potential issues and risks.
• This helps ensure that the software performs consistently under different
conditions.
3. User Satisfaction
• Well-tested software provides a better user experience.
• It reduces failures and improves customer satisfaction.
4. Cost Efficiency
• Early detection of defects saves time and development effort.
• It reduces the overall cost of software maintenance and corrections.
5. Continuous Improvement
• Testers continuously improve their skills, tools, and testing practices.
• This leads to more effective and efficient testing processes.

6. Professional Excellence
• Craftsmanship encourages accuracy, responsibility, and attention to detail.
• It promotes high standards in planning, execution, and reporting of testing
activities.

14. What is Atomic System Function (ASF) ? Explain the Importance of ASFs.
• An Atomic System Function (ASF) is the smallest unit of functionality within a
system that can be independently tested.
• Each ASF represents a single, indivisible operation performed by the system.
 • Importance of ASFs :
1. Enhanced Test Coverage
• Every small unit of functionality is tested individually.
• This helps achieve comprehensive test coverage.
2. Fault Isolation
• Defects can be traced to a specific ASF easily.
• This makes debugging and issue resolution faster.
3. Incremental Testing and Integration
• New functionalities can be tested as they are developed.
• Supports smooth integration of system components.
4. Foundation for Automation
• ASFs are suitable for automated testing.
• Automated tests provide consistent and repeatable results.
5. Improved Quality Assurance
• Each ASF is validated independently.
• This improves the overall quality and reliability of the system.
6. Risk Mitigation
• Defects can be identified at an early stage.
• Early detection reduces the risk of major system failures.

15. Explain the Context of Interaction in Interaction Testing.

• Context of Interaction refers to understanding how different entities within a
system interact with each other.
• The context of interaction can be understood through the following key
factors:
1. Interacts With Relationship
• This relationship shows how data, actions, events, and threads interact with
each other.
• Understanding these interactions helps identify possible faults.
Example: In an ATM system, entering a PIN (action) interacts with stored
account data for verification.
2. Location (Time and Position)
a) Time
• Interactions occur at specific moments or over a period of time.
• Timing can influence system behavior.
b) Position
• Interactions may occur at different physical or logical locations.
• Different locations can create different interaction conditions.
 Example: ATM transactions during peak hours may behave differently due to heavy
usage.
3. Time Views
a) Instantaneous View
• Focuses on events occurring at a specific point in time.
• Checks the system response at that moment.

b) Duration View
• Considers the entire period of an interaction.
• Evaluates system behavior throughout the process.
Example: Card reading occurs instantly, while the complete ATM transaction takes
a certain duration.
4. Processor Rules
a) Execution Time
• Threads require time to execute.
• Operations cannot be completed instantly.
b) Simultaneity
• Multiple threads cannot execute simultaneously on a single processor.
• Operations must follow the correct sequence.
c) Event Duration
• Events take time to occur and cannot happen at the exact same instant.
• Proper sequencing helps prevent conflicts.
Example: In an ATM, card reading, PIN verification, transaction processing, and
receipt printing occur in sequence.

16. Explain the process of Testing based on Models/ Explain the model based
testing. **
• Model-Based Testing (MBT) is a testing technique in which test cases are derived
from models that represent the expected behavior of a system.
• The model acts as the basis for generating, executing, and validating test cases.
The process of testing based on models involves the following steps:

1. Model Creation
• A model of the system is created based on requirements and specifications.
• The model represents system states, inputs, outputs, and behavior.
2. Model Validation
• The created model is checked for correctness and completeness.
• This ensures that the model accurately reflects the intended system
behavior.
 3. Test Case Generation
• Test cases are automatically generated from the validated model.
• Different system scenarios and conditions are covered.
4. Test Execution
• The generated test cases are executed on the actual software system.
• The system behavior is observed and recorded.
5. Result Comparison
• Actual results are compared with the expected results defined in the model.
• Any mismatch indicates a defect in the system.
6. Defect Analysis and Correction
• Identified defects are analyzed and reported.
• Necessary corrections are made to the software.
7. Model and Test Maintenance
• Models and test cases are updated whenever requirements change.
• This ensures that testing remains accurate throughout the software lifecycle.

17. Explain Issues in object Oriented Testing.

Object Oriented Testing Issues :
• Object-Oriented Testing is the process of testing software developed using
classes and objects.
• Testing object-oriented systems is challenging due to features such as
encapsulation, inheritance, and polymorphism.

1. Units for Object-Oriented Testing

• Classes and objects are the basic units of testing.
• Interactions between objects increase testing complexity.
2. Implication of Composition
• Objects are often composed of other objects.
• A defect in one object may affect the behavior of related objects.

3. Implication of Encapsulation
• Encapsulation hides internal data and implementation details.
• This makes it difficult to access and test internal states directly.
4. Implication of Inheritance
• Child classes inherit properties and methods from parent classes.
• Changes in parent classes may introduce defects in derived classes.
5. Implication of Polymorphism
• The same method can behave differently for different objects.
• All possible implementations must be tested to ensure correctness.
 6. Object Interactions and Dependencies
• Objects communicate and depend on one another to perform tasks.
• Errors in interactions can be difficult to identify and isolate.

18. Explain the difference between top down and bottom up integration.

Aspect Top-Down Integration Testing Bottom-Up Integration Testing

Testing starts from top-level Testing starts from lower-level

Approach modules and moves upward.
modules and moves downward.

Testing Low-level modules are tested

Main modules are tested first. first.
Order

Uses stubs to replace lower- Uses drivers to simulate higher-

Replace level modules.
level modules.

Error High-level design errors are Low-level module errors are

Detection found early. found early.

System Overall system structure is Complete system is visible only

Visibility visible early. after integration.

Testing a website starting from Testing database modules before

Example integrating the user interface.
the Home Page.

19. Differentiate between Weak Normal Vs Strong Normal Equivalence Class

Testing.

Weak Normal Equivalence

Aspect Strong Normal Equivalence Class Testing
Class Testing

One test case is selected from Test cases are selected to cover all possible
Definition
each valid equivalence class. combinations of valid equivalence classes.

Picks a single representative Picks values from all valid classes and
Input Selection
value from each valid class. combines them in different ways.
 Weak Normal Equivalence
Aspect Strong Normal Equivalence Class Testing
Class Testing

Provides basic coverage for Offers more comprehensive coverage by

Coverage
individual input classes. considering multiple valid classes together.

Execution Fewer test cases → faster Larger number of test cases → slower
Efficiency execution, lower cost. execution, higher cost.

More complex to design and execute due to

Complexity Simple to design and execute.
combinations.

More effective in detecting defects caused

Defect Detection Detects defects related to
by interactions between multiple input
Capability individual equivalence classes.
classes.

20. Differentiate between Weak Robust Vs Strong Robust Equivalence Class

Testing

Weak Robust Equivalence Class

Aspect Strong Robust Equivalence Class Testing
Testing

Selects one valid input from Considers combinations of inputs from all
Definition each equivalence class along equivalence classes, including invalid and
with boundary values. boundary values.

One representative value per All possible combinations of values across

Input Selection
class + boundary values. classes (valid + invalid).

Minimal coverage, focuses on Maximum coverage, includes all

Coverage
validity and boundaries. combinations and invalids.

Suitable when quick, low-cost Suitable when exhaustive testing is required

Suitability
testing is needed. for critical systems.

Low complexity, fewer test

Complexity High complexity, large number of test cases.
cases.

Defect Detects common defects related Detects a wider range of defects, including
Detection to individual valid, invalid, and those caused by interactions between
Capability boundary inputs. multiple valid and invalid input combinations.
21. Differentiate Between Model Driven Development versus Test Driven
Development.

Model-Driven Development Test-Driven Development

Aspect (TDD)
(MDD)

Uses high-level models to guide Uses tests written before the

Approach code.
development.

Focuses on the overall system Focuses on detailed and

Perspective incremental development.
structure (big picture).

Starts with creating a Starts with writing test cases for

Process functionality.
comprehensive model.

More structured but may have Simpler to start but may require
Complexity multiple iterations.
higher initial complexity.

Fault Ensures completeness and Provides excellent fault isolation

Isolation consistency through models. through failing tests.

Produces complete and Provides continuous validation

Advantages and immediate feedback.
consistent system designs.

8 Marks
1. Explain the testing life cycle. ***
 • The Testing Life Cycle is a process used in software development to find and
fix problems in software.
Stages of the Testing Life Cycle
1. Specification :
• This is the first stage of the testing life cycle.
• In this stage, software requirements are written clearly.
• Requirements must be easy to understand and complete.
• Mistakes in requirements can cause problems in later stages.
2. Design
• In this stage, requirements are changed into a design plan.
• The design shows how the software will be built.
• Logical mistakes or poor structure can cause design faults.
3. Coding
• In the coding stage, programmers write the software code.
• Coding is done using the design plan.
• Errors can happen because of human mistakes.
4. Testing
• Testing starts after coding is finished.
• The software is run to check for errors.
• Testing checks whether the software works as expected.
5. Classify Fault
• When an incident is found, the fault is studied.
• The fault is classified based on its cause.
• It is checked whether the fault is due to: Requirement mistake, Design mistake ,
Coding mistake
• This helps decide which fault should be fixed first.
6. Isolate Fault
• In this step, the exact place of the fault is found.
• The faulty part of the code or design is identified.
• This helps to fix the problem correctly.
7. Fault Resolution
• This is the final stage.
• The fault is fixed by changing the code or design.
• The fix is checked to make sure the problem is solved.

2. A) Explain robust worst case boundary value testing (RWCBVT)with example.

• Robust Worst Case Boundary Value Testing (RWCBVT) is a software testing

technique that tests all valid and invalid boundary values of input variables.
• It evaluates different combinations of boundary values to ensure the system
behaves correctly under extreme conditions.
 • For each input variable, we consider:
Min−1 → below minimum (invalid)
Min → minimum value
Min+1 → just above minimum
Normal → typical value
Max−1 → just below maximum
Max → maximum value
Max+1 → above maximum (invalid)
• Example: Flight Booking System
Variables
• Number of Travelers (T) → 1 to 5
• Class of Service (C) → Economy, Business, First Class
Boundary Values
• For Travelers (T): {0, 1, 2, 3, 4, 5, 6}
• For Class (C): {Economy, Business, First, Invalid Class}
• Test Case Combinations :
• 0 travelers with Economy class → Below minimum value, system should
reject the booking.
• 1 traveler with Economy class → Minimum valid value, system should
accept the booking.
• 3 travelers with Business class → Normal value, system should accept
the booking.
• 5 travelers with First Class → Maximum valid value, system should
accept the booking.
• 6 travelers with Invalid Class → Above maximum and invalid input,
system should reject the booking.
Conclusion
• RWCBVT provides maximum test coverage by considering valid and invalid
boundary values.

2. B) What is special value testing? explain characteristics of special value

testing.**
• Special Value Testing (SVT), also known as Ad Hoc Testing, is a functional
testing technique that uses special, unusual, or error-prone input values to
identify defects in a software application.
Characteristics of Special Value Testing
1. Tester-Driven
• It depends completely on the tester.
• The tester’s experience and knowledge are very important.
 2. Domain Knowledge
• The tester must understand the application deeply.
• They focus on areas where errors are more likely to occur.
3. Ad Hoc Approach
• There is no standard procedure or strict testing rules.
• The tester has the freedom to create test cases and explore different
scenarios.
4. Targeting “Soft Spots”
• This testing focuses on complex calculations, rare input values, frequently
failed modules, and special date conditions.
• The goal is to identify hidden defects that may not be found through regular
testing.
5. Quick Defect Detection
• It helps discover defects in a short period without extensive planning.
• It is useful for finding unexpected errors that are often missed by formal
testing techniques.

3. A) Explain Equivalence class test cases for NextDate Function. ( 8 M)

B) Write advantages and disadvantages of def-use testing.
Advantages of def-use testing :
1. Better Coverage
• It checks how variables are defined and used throughout the program.
2. Finds Bugs Early
• It helps identify data flow errors during the early stages of testing.
3. Improves Code Quality
• Developers write more reliable code by focusing on variable usage.
4. Detects Unused Variables
• It helps identify variables that are defined but never used.
5. Improves Software Reliability
• Proper verification of data flow reduces the chances of software failures.
Disadvantages of Def-Use Testing
1. Complex
• It becomes difficult to apply in large and complex programs.
2. Takes More Time
• Analyzing all Def-Use paths requires significant effort and time.
3. Needs Good Knowledge
• Testers must have a clear understanding of program structure and data flow.
4. Difficult to Maintain
• Test cases need frequent updates whenever the code changes.
5. Tool Dependency
• Effective Def-Use testing often requires specialized automated tools.
6. A) Explain guidelines and observations of decision table testing.
Guidelines and Observations of Decision Table Testing
1. When to Use Decision Tables
a) Complex Decision Logic :
▪ Suitable for systems that contain multiple conditions and if–else
statements.
▪ Helps represent complex business rules in a simple tabular format.
b) Interdependent Inputs :
▪ Useful when multiple inputs are related and influence each other.
▪ Ensures that all combinations of related inputs are considered.
c) Calculation Operations :
▪ Effective for applications involving calculations and formula-based
decisions.
▪ Helps verify the correctness of different calculation outcomes.
2. Challenges with Scalability
a) Extended Entry Tables
▪ As the number of conditions increases, the size of the decision table grows
rapidly.
▪ Large tables can become difficult to manage and understand.
b) Table Simplification
▪ Similar rules can be combined to reduce table size.
▪ Simplification improves readability and maintenance.
c) Table Factoring
▪ Large decision tables can be divided into smaller tables.
▪ This makes testing and analysis easier.
3. Iterative Refinement
▪ Decision tables may not be perfect in the initial stage.
▪ They should be refined and updated based on testing results.
▪ It helps ensure complete coverage of conditions and actions.

B) What is dataflow testing ? Explain the characteristics of data flow testing.(8 M)

7. A) Explain the components of a test case.

1. Test Case ID
• A unique identifier assigned to each test case.
• It helps in identifying, tracking, and managing test cases efficiently.
2. Purpose
• A brief description of the objective of the test case.
• It specifies what functionality or feature is being tested.
 3. Test Created By
• The name of the person who designed the test case.
• It helps in obtaining clarification and maintaining accountability.
4. Test Environment
• The hardware and software setup required for executing the test.
• It includes details such as operating system, browser, network, and
application version.
5. Test Procedure
• A sequence of steps to be followed while executing the test case.
• It ensures that testing is performed consistently and accurately.

7 .B) Explain the limitation of boundary value analysis.

1. Focus on Boundaries Only
• Boundary Value Analysis mainly tests the minimum and maximum values of
inputs.
• Errors occurring within the valid input range may remain undetected.
2. Not Suitable for Complex Logic
• BVA is not effective for applications with complex business rules.
• It cannot adequately test multiple decision-making conditions.
3. Limited for Multiple Inputs
• It does not effectively test interactions between several input variables.
• Defects caused by combinations of inputs may be missed.
4. Cannot Detect All Errors
• BVA focuses only on boundary-related defects.
• Logical, functional, and design errors may not be identified.
5. Assumption-Based
• It assumes that most defects occur at boundary values.
• In practice, errors can also occur at non-boundary values.
6. Requires Additional Testing Techniques
• BVA alone is not sufficient for complete software testing.
• It is often combined with techniques such as Equivalence Class Testing and
Decision Table Testing for better coverage.

8. A) Explain random testing , mention its advantages and disadvantages.

• Random Testing is a software testing technique in which test inputs are
generated randomly.
• The inputs are not selected based on boundary values, equivalence classes,
or predefined test cases.
• It is used to discover unexpected defects by testing the system with a variety
of random inputs.
Advantages of Random Testing
1. Better Coverage
• It covers a wide range of input scenarios.
• It may identify defects that are missed by planned test cases.
 2. Unbiased Testing
• Test cases are selected randomly without human preference.
• This reduces unconscious bias during testing.
3. Simple to Perform
• Random test cases can be generated quickly.
• It requires less effort in test case design.
4. Helps Find Unexpected Defects
• Random inputs may expose unusual errors that are not considered during
planned testing.
• It is useful for identifying hidden defects in the software.

Disadvantages of Random Testing

1. Less Efficient
• A large number of tests may be required to achieve sufficient coverage.
• Some important test cases may still be missed.
2. Difficult to Reproduce Errors
• Failures caused by random inputs can be difficult to repeat.
• Testers need to record the failing inputs for future analysis.
3. No Guaranteed Coverage
• There is no assurance that all requirements or paths will be tested.
• Critical areas of the application may remain untested.

4. Time-Consuming
• A large number of random test cases may need to be executed.
• This can increase the overall testing time and effort.

B) Explain the guidelines and observation about equivalence class testing.

Guidelines and Observations About Equivalence Class Testing
1. Comprehensive Testing Levels
• Weak equivalence class testing may not cover all possible input
combinations.
• Strong equivalence class testing provides more thorough coverage.
2. Strongly Typed Languages
• Strongly typed languages automatically detect many invalid input types.
• In such cases, robust testing may provide limited additional benefits.
3. Prioritizing Error Conditions
• Robust equivalence testing is useful when error handling is critical.
• It helps identify and verify error scenarios effectively.
4. Input Data Characteristics
• Equivalence class testing works best for inputs defined by ranges or discrete
values.
• It helps organize test cases based on similar input behavior.
 5. Combining with Boundary Testing
• Equivalence class testing can be combined with Boundary Value Testing.
• This improves test coverage and defect detection.
6. Complex Functions
• It is particularly useful for testing functions with multiple conditions and
rules.
• Proper identification of equivalence classes helps improve testing accuracy.

9. A) Explain decision table design format with example.

1. Condition Stub
• Lists all the conditions related to the problem.
• Conditions are usually in the form of Yes (Y), No (N), or Don’t Care (-).
• Location: Left side of the table.
2. Condition Entries
• Shows the values of each condition for every rule.
• Each column represents a combination of conditions.
• “Don’t care (–)” means the condition does not affect the outcome.
• Location: Right of condition stub.
3. Action Stub
• Lists all possible actions (outputs) based on conditions.
• Location: Below the condition stub.
4. Action Entries
• Indicates which action is taken for each rule using X (or mark).
• Location: Below condition entries.
5. Rules
• Each column represents a rule (combination of conditions + action).
• Shows all possible decision scenarios.

Example: Subscription System

• Conditions: Condition stub R1 R2 R3 R4
C1: User is over 18 User is over 18 Y Y N N
C2: Payment received Action Stub
• Actions: Payment receipt Y N Y N
A1: Activate subscription Activate subscription X
A2: Send reminder Send reminder X
A3: Reject application Reject application X X
 9. B) Explain the importance or benefits of slice based testing.
1. Focused Testing
• It concentrates on the most important and critical parts of the software.
• This improves the effectiveness of testing and defect detection.
2. Reduced Complexity
• The program is divided into smaller and manageable parts.
• This makes the software easier to understand and test.
3. Improved Debugging
• Errors can be identified more quickly during testing.
• Detected defects can be fixed easily and efficiently.
4. Enhanced Test Coverage
• Critical modules and functionalities are tested thoroughly.
• This increases confidence in the quality of the software.
5. Cost-Effective Testing
• It saves testing time and resources.
• It avoids unnecessary testing of less important areas.

10. Explain fundamental approaches to apply test cases with examples.

• Test cases are designed to verify whether software works correctly.
• There are two fundamental approaches used to identify and apply test cases:
1. Specification-Based Testing
2. Code-Based Testing
Specification-Based Testing :
• Specification-Based Testing is also called Functional Testing or Black-Box
Testing.
• It tests software based on requirements and specifications without knowing
the internal code.
• This testing focuses on what the system does rather than how it does it.
Importance of Specification-Based Testing
1. Requirement Validation
• It checks whether the software meets user and business requirements.
2. Functional Verification
• It verifies that all functions of the software work correctly.
3. Early Defect Detection
• It helps identify missing or incorrect functionalities.
4. User-Oriented Testing
• It evaluates the software from the user's perspective.
Example
ATM Login System
• Enter a valid PIN and verify that access is granted.
• Enter an invalid PIN and verify that access is denied.
 Code-Based Testing (Structural Testing)
• Code-Based Testing is also known as Structural Testing or White-Box Testing.
• It focuses on testing the internal structure and logic of the code.
• It verifies the intended flow of program execution.
Importance of Code-Based Testing
1. Code Coverage
• It ensures that different parts of the code are executed and tested.
2. Error Detection
• It helps identify logical and programming errors in the code.
3. Improved Software Quality
• It improves software quality by verifying the program structure.
4. Reliability Enhancement
• It increases software reliability by reducing hidden defects.
Example
Student Grade Calculation Program
• Test all grade conditions (A, B, C, Fail) in the code.
• Verify that each decision path executes correctly and produces the expected
result.

11. A) Explain generalizing boundary value analysis (BVA)

• Generalizing Boundary Value Analysis (GBVA) is a technique used to extend
Boundary Value Analysis to handle a wide range of variables, contexts, and data
types.
• It improves the applicability and effectiveness of BVA by adapting it to different
testing requirements.
1. Generalizing by Number of Variables
• For a function with multiple variables, all variables are kept at their nominal
values except one.
• Each variable is tested at its boundary values independently to ensure
comprehensive coverage.

Example:
• Consider a travel fare system with variables: Age (10–65 years), Distance (0–
100 km), and Hours of Service (1–24 hours).
• One variable is tested at boundary values while the others remain at normal
values.

2. Generalizing by Types of Ranges

• Different types of input ranges require different boundary value selections.
• The testing approach depends on the nature of the input data.
 Types of Ranges:
• Discrete and Bounded Variables: Example – day of a month, month of a
year.
• Variables without Explicit Bounds: Example – values that do not have a
predefined upper limit.
• Boolean and Logical Variables: Example – True/False conditions.
• Context-Specific Variables: Example – ATM transaction type or customer
PIN.

B) Explain robust boundary value testing(RBVT) with example.

• Robust Boundary Value Testing (RBVT) is an extension of Normal Boundary Value
Testing (NBVT).
• In NBVT, we test values inside the valid range, In RBVT, we also test values just
outside the valid range.
• RBVT checks how robust the system is when it receives invalid or unexpected
inputs.
• It tests whether the system, Accepts valid inputs correctly and Rejects invalid
inputs safely
• Boundary Values used :

• Min−1 (Below Minimum)

• Min (Minimum)
• Min+1 (Just Above Minimum)
• Nominal (Normal Value)
• Max−1 (Just Below Maximum)
• Max (Maximum)
• Max+1 (Above Maximum)

• Example :

Scenario: Online Application Form (Age Input)

Valid age range: 18 to 65 years

Test Value Meaning Expected Result

17 Min− (below min) Reject
18 Min Accept
19 Min+ Accept
42 Nominal Accept
64 Max− Accept
65 Max Accept
66 Max+ Reject
12. Explain the forms or variations of equivalence class testing with example.
Forms (Variations) of Equivalence Class Testing :

1. Weak Normal Equivalence Class Testing

• Weak Normal Equivalence Class Testing is a basic method in equivalence
class testing.
• It is called weak because it assumes only one fault at a time.
• If an error happens, it is assumed that only one input variable is wrong.

• Purpose :
• Used to test representative values from valid equivalence classes.
• Reduces the number of test cases while ensuring basic coverage.
• Example – ATM Withdrawal Limit
Scenario : ATM allows withdrawal from ₹100 to ₹10,000

Step 1: Equivalence Classes (Valid only – Normal Testing)

• Low valid amount: ₹100 – ₹1,000
• Medium valid amount: ₹1,001 – ₹5,000
• High valid amount: ₹5,001 – ₹10,000
• WNECT tests only valid inputs
Step2 : Test Cases

Test Case Input Class

TC1 ₹500 Low
TC2 ₹3000 Medium
TC3 ₹8000 High

2. Strong Normal Equivalence Class Testing (SNECT):

• Strong Normal Equivalence Class Testing (SNECT) is an advanced method in
equivalence class testing.

• It improves Weak Normal Testing by testing multiple variables together.

• It helps find Interaction problems between inputs.
• Purpose :
• Tests combinations of valid equivalence classes.
• Provides better coverage than weak normal testing.
• Example – Next Date Function
Scenario: System accepts valid date (Day: 1–31, Month: 1–12, Year: valid
range)
Step 1: Equivalence Classes (Valid only – Combined Testing)
• Valid normal date → e.g., mid-month
• End of month → 30/31 days
• Leap year February → 29 Feb valid
 Step 2: Test Cases
Test Case Input ( D-M-Y) Class
TC1 15-6-2023 Normal valid
TC2 30-4-2023 Month-end (30days)
TC3 29-2-2024 Leap year valid

3. Weak Robust Equivalence Class Testing

• It Assumes single fault.
• Tests both Valid inputs and Invalid inputs
• Checks system behaviour with wrong inputs also.
• Purpose :
• Verifies system behavior for both valid and invalid inputs.
• Assumes that only one input variable is invalid at a time.
• Example – Next Date Function
Scenario: System should reject invalid inputs
Step 1: Equivalence Classes (Invalid – One at a time)
• Invalid day (<1 or >31)
• Invalid month (<1 or >12)
• Invalid year (out of range)
Step 2 : Test Case

Test Case Input ( D-M-Y) Class

TC1 32-5-2023 Invalid day
TC2 10-15-2023 Invalid month
TC3 10-5-1811 Invalid Year
4. Strong Robust Equivalence Class Testing
• It Assumes multiple faults, Includes both Valid inputs, Invalid inputs
• Tests combinations of correct and wrong data.
• Used to find hidden system weaknesses.
• Purpose :
• Tests combinations of multiple valid and invalid inputs.
• Helps identify defects caused by interactions between incorrect inputs.
• Example – Next Date Function
Scenario: System should handle multiple invalid inputs together
Step 1: Equivalence Classes (Multiple Invalid)
• Invalid day + invalid month
• Invalid month + invalid year
Step 2 : Test Cases

Test Case Input ( D-M-Y) Class

TC1 32-13-2023 Invalid day + month
TC2 0-15-1811 Invalid day + year
13. A) Explain test case for triangle problem in decision table based testing.
Triangle Problem :
• The triangle problem is used to determine whether three given sides form a
valid triangle.
• If a valid triangle is formed, it is classified as Scalene, Isosceles, or Equilateral
using decision table testing.
Step 1: Triangle Inequality Conditions
A triangle exists only if all the following conditions are true:
• c1: a < b + c
• c2: b < a + c
• c3: c < a + b
Observation:
• If any one of these conditions is false, the sides do not form a triangle.
• The output will be Not a Triangle (A1).

Step 2: Side Equality Conditions

These conditions are used to identify the type of triangle.
• c4: a = b
• c5: a = c
• c6: b = c
Observation:
• All sides different → Scalene Triangle.
• Exactly two sides equal → Isosceles Triangle.
• All three sides equal → Equilateral Triangle.
Step 3: Actions
• A1: Not a Triangle
• A2: Scalene Triangle
• A3: Isosceles Triangle
• A4: Equilateral Triangle
• A5: Impossible Case

Step 4: Logic
a) Not a Triangle
• If any triangle inequality condition fails, the sides do not form a triangle.
• Example: (1, 2, 4) → A1
b) Scalene Triangle
• All triangle inequalities are true and all sides are different.
• Example: (3, 4, 5) → A2
c) Isosceles Triangle
• All triangle inequalities are true and exactly two sides are equal.
• Example: (2, 3, 2) → A3
d) Equilateral Triangle
• All triangle inequalities are true and all three sides are equal.
• Example: (5, 5, 5) → A4
 Step 5: Test Cases

Case a b c Output

DT1 4 1 2 Not a triangle

DT2 1 4 2 Not a triangle

DT3 1 2 4 Not a triangle

DT4 5 5 5 Equilateral

DT5 3 4 5 Scalene

DT6 2 2 3 Isosceles

DT7 2 3 2 Isosceles

DT8 3 2 2 Isosceles

14. Explain commission problem with all its possible conditions.

Commission Problem
• The Commission Problem is a software testing example used to calculate the
commission earned by a salesperson.
• The commission depends on the number of Locks, Stocks, and Barrels sold and
the total sales amount.
• It is commonly used to demonstrate Equivalence Class Testing, Boundary Value
Testing, Decision Table Testing, and Data Flow Testing.

1. Commission Problem using Equivalence Class Testing . **

Step 1: Identify Input Variables
• Locks (1–70)
• Stocks (1–80)
• Barrels (1–90)

Special Case:
• Locks = -1 (Sentinel Value)

Step 2: Identify Equivalence Classes

Valid Classes
• L1: 1 ≤ Locks ≤ 70
• S1: 1 ≤ Stocks ≤ 80
• B1: 1 ≤ Barrels ≤ 90
 Invalid Classes
• L2: Locks < 1 or Locks > 70
• S2: Stocks < 1 or Stocks > 80
• B2: Barrels < 1 or Barrels > 90

Step 3: Generate Test Cases using Strong Robust Equivalence Class Testing

Case Locks Stocks Barrels Output

SR1 -2 40 45 Locks Invalid

SR2 35 -1 45 Stocks Invalid

SR3 35 40 -2 Barrels Invalid

SR4 -2 -1 45 Locks + Stocks Invalid

SR5 35 -1 -1 Stocks + Barrels Invalid

SR6 -2 40 -1 Locks + Barrels Invalid

SR7 -2 -1 -1 All Invalid

2. Commission Problem using Boundary Value Testing

Step 1: Identify Boundary Values

Locks (1–70) Barrels (1–90)

• Min−1 = 0 • Min−1 = 0

• Min = 1 • Min = 1

• Min+1 = 2 • Min+1 = 2

• Max−1 = 69 • Max−1 = 89

• Max = 70 • Max = 90

• Max+1 = 71 • Max+1 = 91

Stocks (1–80)
• Min−1 = 0
• Min = 1
• Min+1 = 2
• Max−1 = 79
• Max = 80
• Max+1 = 81
 Step 2: Generate Test Cases

Case Locks Stocks Barrels Output

BV1 0 40 45 Invalid Lock

BV2 1 40 45 Valid

BV3 2 40 45 Valid

BV4 69 40 45 Valid

BV5 70 40 45 Valid

BV6 71 40 45 Invalid Lock

3. Commission Problem using Decision Table Testing

Step 1: Product Prices

Product Price

Locks ₹45

Stocks ₹30

Barrels ₹25

Step 2: Sales Limits

• Minimum sales: At least 1 Lock, 1 Stock, and 1 Barrel.
• Maximum sales: 70 Locks, 80 Stocks, and 90 Barrels.
• If any limit is exceeded, commission is not calculated.
Step 3: Commission Slabs

Total Sales Commission

Up to ₹1000 10% of Total Sales

₹1001 – ₹1800 ₹100 + 15% of amount above ₹1000

Above ₹1800 ₹220 + 20% of amount above ₹1800

Step 4: Define Conditions

• C1: Total Sales ≤ ₹1000
• C2: ₹1001 ≤ Total Sales ≤ ₹1800
• C3: Total Sales > ₹1800
• C4: Sales Limit Exceeded
Step 5: Define Actions
• A1: 10% Commission
• A2: ₹100 + 15% Commission
• A3: ₹220 + 20% Commission
• A4: No Commission

Step 6: Decision Table

Conditions / Actions R1 R2 R3 R4
C1 Y N N N
C2 N Y N N
C3 N N Y N
C4 N N N Y
A1 X
A2 X
A3 X
A4 X

Step 7: Test Cases

DT1 – Sales under ₹1000
• Locks = 5, Stocks = 5, Barrels = 5
• Total Sales = ₹500
• Commission = ₹50

DT2 – Sales between ₹1001 and ₹1800

• Locks = 15, Stocks = 15, Barrels = 15
• Total Sales = ₹1500
• Commission = ₹175

DT3 – Sales above ₹1800

• Locks = 20, Stocks = 25, Barrels = 30
• Total Sales = ₹2400
• Commission = ₹340

Invalid Cases
• DT4: Locks = 80 → Commission = ₹0
• DT5: Stocks = 85 → Commission = ₹0
• DT6: Barrels = 95 → Commission = ₹0
4. Commission Problem using Define use Testing.
Step 1: Identify Variables
• Locks
• Stocks
• Barrels
• TotalSales
• Commission
Step 2: Define and Use Variables
• Locks, Stocks, and Barrels are entered by the user.
• TotalSales is calculated using the values of Locks, Stocks, and Barrels.
• Commission is calculated based on TotalSales.
Step 3: Def-Use Paths
• D1: Locks → TotalSales
• D2: Stocks → TotalSales
• D3: Barrels → TotalSales
• D4: TotalSales → Commission
• D5: Commission → Display Output
Step 4: Test Cases

Case Purpose
DF1 Verify Locks are correctly used in TotalSales calculation
DF2 Verify Stocks are correctly used in TotalSales calculation
DF3 Verify Barrels are correctly used in TotalSales calculation
DF4 Verify Commission is correctly calculated from TotalSales
DF5 Verify Commission is correctly displayed to the user

15. Explain next date function with all possible test cases.
BOUNDARY VALUE TESTING
Boundary Value Testing (BVT) is a technique used to test values at the edges
(minimum and maximum) of input domains, where errors are most likely to occur.
The Next Date function takes three inputs:
• Day (1–31)
• Month (1–12)
• Year (e.g., 1900–2100)

Boundary Values:
• Day → 1, 2, 30, 31
• Month → 1, 2, 11, 12
• Year → 1900, 1901, 2099, 2100
 Test Case Generation:
• One variable is tested at its boundary values while the other variables are kept at
normal values.
• This helps identify errors that occur at the limits of input ranges.
• Example Test Cases:

Test Input Expected

Description
Case (D-M-Y) Output

TC1 1-1-2000 2-1-2000 Normal boundary (min day)

TC2 31-1-2000 1-2-2000 End of 31-day month

TC3 30-4-2000 1-5-2000 End of 30-day month

TC4 28-2-2001 1-3-2001 Non-leap year February

TC5 29-2-2000 1-3-2000 Leap year case

TC6 31-12-2000 1-1-2001 Year change boundary

Thus, Boundary Value Testing helps verify correctness of the Next Date function at
critical cases like month-end, leap year, and year-end.
DECISION TABLE BASED TESTING

• Decision table is used to represent different conditions and corresponding

actions.

Conditions
• Month: Specifies the current month (different months have different number of
days).
• Day: Specifies the current day within the month.
• Year: Determines whether it is a leap year or non-leap year.

Actions
• A1: Increment Day
• A2: Move to Next Month
• A3: Move to Next Year
• A4: Move to February 29
Decision Table for Valid Scenarios
Analysis (Rules)
• Rule 1: For any normal day (not last day), increase the day by 1
(e.g., 14 March → 15 March)
• Rule 2: For the last day of any month except December, move to next month
(e.g., 31 January → 1 February)
• Rule 3: For December 31, move to next year
(e.g., 31 Dec 2022 → 1 Jan 2023)
• Rule 4: For February 28 in a non-leap year, next date is March 1
(e.g., 28 Feb 2023 → 1 Mar 2023)
• Rule 5: For February 28 in a leap year, next date is February 29
(e.g., 28 Feb 2024 → 29 Feb 2024)
• Rule 6: For February 29 in a leap year, next date is March 1
(e.g., 29 Feb 2024 → 1 Mar 2024)
• Rule 7: For the last day of 30-day months, move to next month
(e.g., 30 April → 1 May)
• Rule 8: For the last day of 31-day months (except December), move to next
month
(e.g., 31 July → 1 August)
Test cases Derived from Decision Table:

Case ID Day Month Year Expected Output

DT1 15 6 2022 16/6/2022

DT2 30 4 2022 1/5/2022

DT3 31 12 2022 1/1/2023

DT4 28 2 2023 1/3/2023

DT5 28 2 2024 29/2/2024

DT6 29 2 2024 1/3/2024

DT7 30 4 2024 1/5/2024

DT8 31 5 2024 1/6/2024

EQUIVALENCE CLASS **
• The Next Date function takes day, month, and year as input and returns the next
date.
• In equivalence class testing, inputs are divided into valid and invalid classes.

Valid Equivalence Classes

• M1: Month has 30 days
• M2: Month has 31 days
• M3: Month is February
• D1: Day between 1 and 28
• D2: Day = 29
• D3: Day = 30
• D4: Day = 31
• Y1: Year is leap year
• Y2: Year is non-leap year
Invalid Equivalence Classes
• M4: Month < 1
• M5: Month > 12
• D5: Day < 1
• D6: Day > 31
• Y3: Year below valid range
• Y4: Year above valid range

Test Case using weak robust equivalence Class Testing :

• In weak robust equivalence class testing, we test the system by taking one
invalid input at a time, while keeping the other inputs valid.

Case ID Month Day Year Expected Output

WR1 6 15 1912 16/6/1912 (Valid case)

WR2 -1 15 1912 Invalid month (not in range 1–12)

WR3 13 15 1912 Invalid month (not in range 1–12)

WR4 6 -1 1912 Invalid day (not in range 1–31)

WR5 6 32 1912 Invalid day (not in range 1–31)

WR6 6 15 1811 Invalid year (below range)

WR7 6 15 2200 Invalid year (above range)

• This helps in checking whether the system correctly identifies and rejects invalid
values.
16. A) Explain worst case boundary value testing with example.
• Worst-Case Boundary Value Testing (WCBVT) is a testing technique in which
boundary values of all input variables are tested together at the same time.
• Unlike Normal BVT, which changes one variable at a time, WCBVT tests all
possible combinations of boundary values of all variables.
• This helps to find errors that occur due to interaction between variables at
extreme values.
• Example : Online Shopping System Test case Combinations
A system allows users to, Items Delivery
▪ Select number of items 1 Regular
▪ Choose delivery option.
1 Express
Variables :
2 Regular
▪ x₁: Number of Items : Range 1 to 20 )
▪ x₂: Delivery Option : 1=Regular, 2=Express ) 2 Express

10 Regular
Boundary Values: 10 Express
For Number of Items:
• 1 (Minimum) 19 Regular
• 2 (Just above minimum)
19 Express
• 10 (Normal value)
• 19 (Just below maximum) 20 Regular
• 20 (Maximum) 20 Express

B) Explain Eqivalence Class Test Cases for the commission Problem. ( 8 M)

17. Discuss the guide lines for boundary value testing.

1. Understand Variable Relationships
• Check if variables depend on each other.
• Avoid impossible or unrealistic combinations.
• Example: June 31 is invalid (only 30 days).
2. Apply Testing Widely
• Apply testing to input, output, and internal variables.
• Check error messages properly.
• Ensure output stays within valid limits.
3. Use Semantic Understanding
• Understand real-world meaning of the program.
• Follow logical constraints of the problem.
• Example: Fuel cannot be zero in mileage calculation.
 4. Create Diverse Test Cases
• Include minimum, maximum, and normal values.
• Test near boundary values (just above/below).
• Include out-of-range values for robustness.
5. Avoid Only Technical Thinking
• Do not focus only on numbers.
• Think practical real-world scenarios.
• Example: Cannot transfer negative money.
6. Test Multiple Variables Carefully
• When a system has multiple inputs, boundary values should be tested for each
variable.
• One variable can be varied while keeping the others at normal values.
7. Verify Error Handling
• The system should properly handle invalid and out-of-range values.
• Appropriate error messages should be displayed for incorrect inputs.
8. Maintain Realistic Test Data
• Test cases should represent practical and meaningful real-world situations.
• Unrealistic combinations should be avoided unless they are being tested
intentionally.

18. List the characteristics of data flow testing.

Characteristics :
[Link] and Use of Variables
• Data Flow Testing checks where variables are defined and where they are
used.
• It ensures that variables are used correctly throughout the program.
2. Detection of Anomalies
• It helps identify errors such as using a variable before it is defined.
• It can also detect unnecessary or incorrect variable assignments.
3. Program Graphs
• Program graphs are used to represent the flow of data within a program.
• They help visualize variable definitions, uses, and movement clearly.
4. Static Analysis
• Data Flow Testing analyzes the source code without executing the program.
• It helps identify potential defects during the early stages of development.
5. Coverage Metrics
• Coverage rules are used to measure how thoroughly variables are tested.
• They ensure that important definition-use paths are not missed.
6. Tool Dependency
• Automated tools are often required for effective Data Flow Testing.
 • Tools help analyze large and complex software systems efficiently.
7. Enhanced Debugging and Maintenance
• It helps locate defects quickly by tracing variable usage.
• Proper analysis makes the code easier to maintain and modify.
8. Suitability for Object-Oriented Code
• Data Flow Testing can be applied to object-oriented programs.
• It helps verify the usage of variables and methods in classes and objects.
9. Complementary to Other Testing Methods
• It is often combined with path testing and other testing techniques.
• This improves overall test coverage and software quality.
10. Complexity in Manual Execution
• Performing Data Flow Testing manually can be difficult and time-consuming.
• The complexity increases significantly for large software projects.

17. What is Test Driven Development ( TDD ) ? Explain the features , advantages and
disadvantages. ( explain features of TDD 5M )**
• Test Driven Development (TDD) is a software development methodology in which
tests are written before the actual code.
• It follows a test-first approach, where developers write a test, develop the code
to pass the test, and then improve the code through refactoring.

Features of TDD
1. Test-First Approach
• Tests are written before the actual code is developed.
• This ensures that the code meets the specified requirements.
2. Incremental Development
• Development is carried out in small and manageable steps.
• Each feature is implemented and tested individually.
3. Red-Green-Refactor Cycle
• Developers first write a failing test (Red).
• Then they write code to pass the test (Green) and improve the code
(Refactor).
4. Automated Testing
• TDD relies on automated testing frameworks.
• Tests can be executed frequently to validate code changes.
5. Improved Code Quality
• TDD encourages writing clean, modular, and maintainable code.
• It helps improve software reliability and readability.
 6. Early Bug Detection
• Defects are identified at the unit testing stage itself.
• Early detection reduces debugging effort and development cost.

Advantages of Test Driven Development (TDD)

1. Early Bug Detection
• Defects are identified during the development stage itself.
• This reduces debugging effort and maintenance cost.
2. Improved Code Quality
• TDD encourages writing clean, modular, and maintainable code.
• It improves the reliability of the software.
3. Better Test Coverage
• Every functionality is supported by a test case.
• This ensures comprehensive testing of the application.

Disadvantages of Test Driven Development (TDD)

1. Time-Consuming Initially
• Writing test cases before coding requires extra time.
• Development may be slower during the initial stages.
2. Requires Skilled Developers
• Developers need a good understanding of testing concepts.
• Beginners may find TDD difficult to implement effectively.
3. Difficult for Complex Systems
• Writing tests for large or complex systems can be challenging.
• Maintaining a large number of test cases may increase effort.

18. Explain Test – Then Cycles with Detailed Example.

• The Test-Then-Code Cycle is a development approach used in Test-Driven
Development (TDD) where tests are written before the actual code.
• It helps ensure that the software meets requirements through continuous testing
and improvement.

The Test-Then-Code Cycle involves the following steps:

1. Write a Test
• Create a test case that defines the expected behavior of a feature.
• Initially, the test fails because the functionality has not yet been
implemented.
2. Run the Test
• Execute the test to confirm that it fails.
• This verifies that the test is valid and the feature is currently missing.
 3. Write the Code
• Implement the minimum amount of code required to make the test pass.
• The focus is only on satisfying the test requirements.
4. Run All Tests
• Execute all existing tests along with the new test.
• This ensures that the new code works correctly and does not affect existing
functionality.
5. Refactor
• Improve the code structure, readability, and maintainability.
• Refactoring should not change the external behavior of the program.
6. Repeat
• Add new tests for additional functionality.
• Continue the cycle until all requirements are implemented.

Example: Leap Year Function

1) Write a Test :
assertTrue(isLeapYear(2024));
• The test checks whether 2024 is a leap year.
• Initially, the test fails because the function is not implemented.
2) Write the Code
boolean isLeapYear(int year){
return year % 4 == 0;
}
• The minimum code is written to pass the test.
3) Run the Test
• Execute the test again.
• The test passes because 2024 is correctly identified as a leap year.
4) Refactor and Repeat
• Improve the code if necessary without changing its behavior.
• Add more test cases and repeat the cycle.

19. Explain Interaction in Single Processor.

• Interaction in a single processor system refers to the relationship and
communication between different system components.
• Since only one processor is available, all activities are executed in a coordinated
manner.
• Interaction in a single processor can be studied under two categories:
1. Static Interaction
• Static interaction analyzes the relationships between components without
executing the program.
• It focuses on system structure, dependencies, and logical relationships.

A) Duration and Port Device : This concept focuses on communication through

ports, devices, and physical connections within the system.
1. Ports and Devices
• Ports are communication points through which devices exchange
information with the system.
• Devices use these ports to send and receive data during operation.
2. Physical Interaction
• Physical interaction occurs when hardware devices communicate with each
other.
• For example, in an ATM system, the card reader interacts with the processor
through input and output ports.

B) Propositional Logic Analysis : This concept uses logical relationships

between conditions to analyze interactions and dependencies.
1. Contraries
• Contraries are two statements that cannot both be true at the same time.
• However, both statements may be false.
2. Sub-Contraries
• Sub-contraries are two statements that cannot both be false.
• However, both statements may be true.
3. Contradictories
• Contradictories are two statements where one must be true and the other
must be false.
• Both statements cannot have the same truth value.
4. Subalterns
• Subalterns are statements where the truth of one statement implies the
truth of another.
• They help in analyzing logical dependencies between conditions.
Example
• In an ATM system, the card reader, authentication module, and database
module have predefined relationships.
• These relationships can be analyzed without executing the system.
2. Dynamic Interaction **
• Dynamic interaction analyzes the behavior of components during program
execution.
• It focuses on runtime communication between data, events, and threads.
A) N-Connectedness : N-connectedness describes the degree of connectivity
and communication paths between devices.
0-Connected Devices
• No direct connection exists between the devices.
• Communication cannot occur between them.
1-Connected Devices
• A single direct connection exists between two devices.
• Information can be exchanged through one communication path.
2-Connected Devices
• Two connections exist between devices.
• This provides additional communication paths and reliability.
3-Connected Devices
• Three or more connections exist between devices.
• This improves fault tolerance and communication efficiency.

B) Interaction Types : Interaction types describe how data, events, and threads
interact with one another during execution.
1. Data-to-Data Interaction
• Data-to-data interaction occurs when one data item affects another data
item.
• For example, in an ATM, the withdrawal amount affects the account balance.
2. Event-to-Event Interaction
• Event-to-event interaction occurs when one event triggers another event.
• For example, card insertion triggers the PIN entry process.
3. Thread-to-Thread Interaction
• Thread-to-thread interaction occurs when multiple threads communicate
and coordinate with each other.
• For example, one ATM thread verifies the PIN while another thread accesses
account information.
Example :
• In an ATM system, card insertion, PIN verification, account validation, cash
withdrawal, and receipt printing occur in sequence.
• These interactions take place during execution and represent dynamic
interaction.
20. Write top 10 best Practices of Software Testing Excellence.
1. Model-Driven Agile Development
• It combines model-based development with agile practices.
• It helps improve software quality and development efficiency.
2. Careful Definition and Identification of Testing Levels
• It clearly defines unit, integration, and system testing levels.
• It ensures complete test coverage and avoids redundancy.
3. System-Level Model-Based Testing
• It uses system models to generate test cases.
• It ensures testing is aligned with system requirements.
4. System Testing Extensions
• It includes advanced testing techniques such as stress and risk-based testing.
• It helps identify defects in complex systems.
5. Incidence Matrices for Regression Testing
• It records relationships between features and test cases.
• It supports efficient regression testing and fault tracking.
6. Use of MM-Paths for Integration Testing
• It analyzes interactions between software modules.
• It improves integration testing effectiveness.
7. Intelligent Combination of Specification-Based and Code-Based Testing
• It combines black-box and white-box testing approaches.
• It provides comprehensive software testing coverage.
8. Code Coverage Metrics Based on Unit Nature
• It uses appropriate coverage metrics for different software units.
• It helps measure testing effectiveness accurately.
9. Exploratory Testing During Maintenance
• It allows testers to actively explore the system.
• It helps discover hidden defects that formal tests may miss.
10. Test-Driven Development (TDD)
• It involves writing tests before implementing the code.
• It supports early defect detection and continuous validation.

21. Explain Object Oriented Integration Testing.

• Object-Oriented Integration Testing is the process of testing the interactions
between classes and objects in an object-oriented system.
• It ensures that integrated objects communicate and work together correctly after
unit testing.
Levels of Object-Oriented Testing
1. Unit Testing
• Unit testing verifies individual units or components in isolation.
• It includes operation/method testing and class testing.
2. Integration Testing
• Integration testing verifies interactions between classes and objects.
• It ensures that collaborating classes work together correctly.
3. System Testing
• System testing verifies the complete object-oriented system.
• It ensures that all requirements are satisfied.

Object-Oriented Integration Testing Process

1. Class Interaction Testing
• Class Interaction Testing verifies the communication between different classes
in the system.
• It ensures that methods, attributes, and messages are exchanged correctly
between classes.
2. Object Collaboration Testing
• Object Collaboration Testing checks how multiple objects work together to
perform a specific task.
• It helps identify defects that occur when objects interact and share
responsibilities.
3. Interface Testing
• Interface Testing verifies that interfaces between classes and objects function
correctly.
• It ensures that data passed between components is accurate and follows the
expected format.
4. Message Passing Testing
• Message Passing Testing checks whether objects send and receive messages
correctly.
• It verifies that the receiving object responds appropriately to the messages it
receives.
5. Inheritance Testing
• Inheritance Testing verifies that child classes correctly inherit properties and
methods from parent classes.
• It ensures that inherited functionality works as expected without introducing
errors.
 6. Polymorphism Testing
• Polymorphism Testing verifies that the same method behaves correctly for
different object types.
• It ensures that all method implementations produce the expected results.
7. Integration Validation
• Integration Validation checks whether all integrated classes and objects work
together as a complete subsystem.
• It ensures that interactions between components satisfy the specified
requirements.
Example
• In an ATM system, the CardReader, Authentication, Account, and Transaction
classes interact with each other.
• Object-Oriented Integration Testing verifies that these classes exchange data
correctly and work together to complete transactions successfully.

22. A) Explain Dynamic Interactions in Multiple Processors with detailed

example.
• Dynamic interactions in multiple processors refer to interactions that occur
when data and tasks are distributed across more than one processor during
execution.
• These interactions involve communication, synchronization, and coordination
between processors.
Key Concepts
1. Concurrency and Parallelism
• Multiple tasks can execute simultaneously on different processors.
• This improves system performance and efficiency.
2. Synchronization
• Synchronization ensures that shared resources are accessed correctly.
• Mechanisms such as mutexes and semaphores help coordinate processors.
3. Communication Protocols
• Processors communicate through message passing or shared memory.
• This enables real-time data exchange between processors.
Example: ATM Withdrawal Process
• The ATM processor sends a withdrawal request to the bank server.
• The bank server verifies the account balance and approves the request.
• The ATM then dispenses cash and updates the transaction records.
• This interaction requires coordination between multiple processors.
B) What is client server testing? Explain the testing strategy.
• Client-Server Testing is a testing technique used to verify communication
between client applications and server systems.
• It ensures that requests, responses, data processing, and security functions work
correctly.
Testing Strategies
1. Identify Client-Server Interactions
• It identifies all interactions between the client and the server.
• This includes requests, processing, and responses.
2. Develop Test Cases
• It creates test cases for normal, error, and boundary conditions.
• This ensures complete testing of client-server communication.
3. Simulate Network Conditions
• It tests the system under different network conditions.
• This helps evaluate performance and reliability.
4. Concurrency Testing
• It verifies the system's ability to handle multiple client requests
simultaneously.
• It ensures that performance is maintained under heavy load.
5. Security Testing
• It verifies that data transmission between client and server is secure.
• It helps identify vulnerabilities and security threats.

23. A) Explain the process of finding Threads in SATM System.

• A thread is a complete sequence of user interactions performed to achieve a
specific task in the SATM system.
• Finding threads helps identify all possible user paths and create effective test
cases.

Step 1: Define the Scope of the SATM System

• Identify major ATM functions such as card insertion, PIN entry, transaction
selection, and cash withdrawal.
• Determine the boundaries of the system to be tested.
Step 2: Identify Key User Interactions
• Identify actions such as inserting the ATM card, entering the PIN, selecting a
transaction, and receiving a receipt.
• These interactions form the basis for thread identification.
 Step 3: Model the System with FSMs
• Create FSMs to represent ATM states and transitions.
• Main states include Card Entry, PIN Entry, and Await Transaction Choice.
Step 4: Identify Port Events
• Identify input events such as digit entry and cancel.
• Identify output events such as display messages and card ejection.
Step 5: Create a Hierarchy of State Machines
• Develop detailed FSMs for important operations such as PIN entry.
• This helps represent system behavior at different levels.
Step 6: Trace Paths Through the FSMs
• Trace all possible paths through the state machines.
• Each path represents a thread.
▪ Thread 1: Card Entry → Correct PIN → Await Transaction Choice
▪ Thread 2: Card Entry → Incorrect PIN → Retry → Correct PIN → Await
Transaction Choice
▪ Thread 3: Card Entry → PIN Entry → Cancel → Eject Card
Step 7: Define Test Cases Based on Threads
• Create test cases for each identified thread.
• Cover successful, retry, and cancellation scenarios.
▪ Test Case 1: Successful Transaction

• Insert ATM card

• Enter correct PIN
• Select transaction
• Receive receipt.
• Test Case 2: Incorrect PIN with Retry
• Insert ATM card → Enter incorrect PIN → Re-enter correct PIN →
Complete transaction.
• Test Case 3: PIN Entry Cancellation
• Insert ATM card → Start entering PIN → Press cancel → Card ejected.

B) What is Lewis and Clark's Expedition? Compare Exploratory Testing and Lewis
and Clark Expedition.
• Lewis and Clark's Expedition is a testing metaphor where testers explore an
unfamiliar software system similar to explorers discovering new territory.
• The objective is to understand the system, discover risks, and identify defects
without relying heavily on predefined test cases.
 Aspect Exploratory Testing Lewis & Clark Expedition

Find defects while learning Explore and understand an

Purpose unfamiliar system.
the system.
Learning, mapping, and
Focus Testing and defect discovery. investigation.

Focuses on exploration before

Planning Minimal planning is required. detailed testing.

Test Test cases are created during Test cases may be created after
Cases testing. exploration.

Gain knowledge about the

Goal Detect defects quickly. application.

24. A) How Neighborhood Integration Testing Works?

• Neighborhood Integration Testing focuses on testing a module together with its
neighboring modules.
• Working :
Step 1: Cluster Identification
• Identify groups of modules that have strong dependencies.
• These groups form a neighborhood or cluster.
Step 2: Testing Scope Definition
• Define the modules and interactions to be tested.
• Determine the boundaries of each neighborhood.
Step 3: Scenario Design
• Design test scenarios that focus on module interactions.
• Consider data flow, communication, and shared functionality.
Step 4: Integration Testing
• Test the interactions between neighboring modules.
• Verify that modules work together correctly.
Step 5: Boundary Testing
• Test boundary conditions and edge cases.
• Identify issues related to data limits and exceptional situations.
Step 6: Error Handling
• Verify error handling and recovery mechanisms.
• Ensure the system remains stable during failures.
 Step 7: Regression Testing
• Perform regression testing after modifications.
• Confirm that existing integrations still work correctly.
Step 8: Collaborative Issue Resolution
• Work with developers to resolve identified integration issues.
• Improve communication and data exchange between modules.

B) Explain the General Procedure for Finding Threads in System Testing.

• A thread is a complete sequence of user interactions and system responses that
achieves a specific task.
Step 1: Define the Scope of the System
• Identify the main functionalities and boundaries of the system.
• Determine what parts of the system need testing.
Step 2: Identify Key User Interactions
• Identify the primary tasks performed by users.
• These tasks help determine the main threads.
Step 3: Model the System with FSMs
• Create Finite State Machines (FSMs) to represent system states and
transitions.
• States represent conditions, while transitions represent events.
Step 4: Identify Port Events
• Identify input and output events at system ports.
• Input events include user actions, while output events include system
responses.
Step 5: Create a Hierarchy of State Machines
• Break complex FSMs into multiple levels.
• High-level FSMs show major states, while lower-level FSMs show detailed
behavior.
Step 6: Trace Paths Through the FSMs
• Identify all possible paths from the initial state to the final state.
• Each path represents a possible thread.
Step 7: Define Test Cases Based on Threads
• Develop test cases for each identified thread.
• Cover normal, error, and boundary scenarios.

25. A) Explain Dynamic interactions in single processor with detailed example. *

B) Explain the Features or Characteristics of Model-Based Testing (MBT).
 Features of Model-Based Testing (MBT)
1. Model-Driven Approach
• It uses models as the basis for testing.
• It represents the expected behavior of the system.
2. Automated Test Case Generation
• It automatically generates test cases from models.
• It reduces manual effort and saves time.
3. Increased Test Coverage
• It tests different paths and scenarios in the system.
• It helps cover edge cases that may be missed manually.
4. Early Detection of Defects
• It identifies defects during the modeling stage.
• It helps improve software quality and reduce costs.
5. Reusable Models
• It allows models to be reused in different projects.
• It provides consistency and saves development time.

26. A) How Bottom – Up Integration Testing works ? Explain with an example.

• Bottom-Up Integration Testing is an integration testing approach in which
testing starts from the lowest-level modules and gradually moves upward.
• Working :
1. Start with Lowest-Level Modules
• Testing begins with the individual modules at the lowest level.
• Each module is tested independently.
2. Higher-Level Module Integration
• The tested lower-level modules are integrated with higher-level
modules.
• This process continues level by level.
3. Use of Drivers
• Drivers are used to simulate the behavior of higher-level modules.
• They provide necessary input and control to the lower-level modules.
4. Incremental Integration
• Modules are integrated gradually in small steps.
• Each newly added module is tested before moving further.
5. Testing Continues Upwards
• Integration and testing continue until all modules are combined.
• Finally, the complete system is tested as a whole.
 • Example: E-Commerce Application
Lowest-Level Module Testing
• Payment Processing and Inventory Management modules are tested
individually.
• Payment validation and inventory updates are verified.
Higher-Level Module Integration
• Inventory Management is integrated with Payment Processing.
• Drivers are used to simulate the Order Fulfillment module.
Further Integration
• Order Fulfillment is integrated with Payment Processing and Inventory
Management.
• Drivers are replaced by actual modules.
Complete System Testing
• All modules are integrated and tested together.
• Data flow, error handling, and system performance are verified.

B) Discuss the Basic Concepts for Requirements Specification in System

Testing.
• Requirements specification defines the information needed to understand and
test a system.
• Basic components :
1. Data
• Data refers to the information used and created by the system.
• Examples include records, variables, files, and database values.
2. Actions
• Actions are operations performed by the system.
• They transform inputs into outputs and perform specific tasks.
3. Devices
• Devices are the sources and destinations of system inputs and outputs.
• Examples include keyboards, card readers, printers, and display screens.
4. Events
• Events are system inputs or outputs that occur at devices.
• They trigger actions and state changes within the system.
5. Threads
• Threads represent a sequence of actions and events performed to achieve
a user goal.
• They describe complete workflows from the user's perspective.
27. A) Explain Static Interactions in a Single Processor with detailed example. **
B) Explain Exploratory and Context – Driven Testing Observations.
• Exploratory and Context-Driven Testing emphasize learning, investigation, and
adapting testing techniques based on the situation.
• The important observations of Exploratory and Context-Driven Testing are
explained below:
1. Suitability in Agile Environments
• Exploratory testing is useful in agile environments where requirements
change frequently.
• It helps testers quickly adapt to new features and changing conditions.
2. Dependence on Domain Experience
• The effectiveness of exploratory testing depends on the tester's domain
knowledge.
• Experienced testers can identify risks and design meaningful tests more
effectively.
3. Tester Motivation and Creativity
• Successful exploratory testing requires curiosity, creativity, and active
involvement.
• Motivated testers are more likely to discover hidden defects and
unexpected behaviors.
4. Challenge of Predictive Measurement
• Exploratory testing does not easily support effort estimation and
measurement.
• The number of defects found cannot be predicted in advance.
5. Management of Exploratory Testing
• Exploratory testing requires proper planning and documentation.
• Test charters and recorded findings help track testing progress

28. A) How Path Based Integration Testing works ?

• Path-Based Integration Testing focuses on testing important execution paths
through a software system.
• Working :
1. Path Identification
• Identify critical paths that represent important functionalities and user
transactions.
• These paths cover major system operations.
2. Path Selection
• Select paths based on complexity, risk, dependencies, and impact on the
system. Priority is given to critical paths.
 3. Test Scenario Design
• Design test scenarios for the selected paths.
• Include input data, expected outputs, and execution steps.
4. Path Execution
• Execute the test cases along the selected paths.
• Verify data flow and module interactions.
5. Result Analysis
• Analyze test results and identify deviations from expected behavior.
• Detect data flow errors and integration issues.
6. Issue Resolution
• Work with developers to resolve identified defects.
• Ensure proper communication and integration between modules.

B) Explain the Characteristics and importance of a thread in system testing.

• A thread is a sequence of actions and events that a user follows to achieve a
specific goal. It represents a complete workflow from the beginning to the end
of a task.
Characteristics and importance :
1. Sequence of Operations
• A thread represents the sequence of steps performed by a user.
• It ensures smooth transitions between different stages of execution.
2. User-Centric
• A thread is designed from the user's perspective.
• It focuses on how users interact with the system.
3. Integration
• It verifies the interaction between different Atomic System Functions
(ASFs).
• It ensures that integrated components work together correctly.
4. End-to-End Testing
• It covers the complete process from start to finish.
• It validates the entire user workflow.
5. Real-World Simulation
• It simulates actual user behaviour and operating conditions.
• It helps test realistic scenarios and edge cases.
6. Fault Detection and Isolation
• It helps identify defects and locate their source.
• It simplifies troubleshooting and debugging.
29. A) Explain Static interaction in Multiple processor with detailed example.
• Static interaction in multiple processors refers to the relationships and
communication between processors that are analyzed without executing the
system.
• It focuses on processor connections, dependencies, and resource sharing.
• The main aspects of static interaction in multiple processors are explained
below:
1. Processor Relationships
• It identifies how processors are connected and communicate with each
other.
• It helps understand system structure and dependencies.
2. Resource Sharing
• It analyzes shared resources such as memory, files, and databases.
• It helps identify potential conflicts before execution.
3. Task Allocation
• It determines how tasks are distributed among processors.
• It ensures balanced workload and efficient processing.
Example
• In an online banking system, one processor handles authentication, another
processes transactions, and a third maintains transaction logs.
• The relationships and communication paths between these processors can
be analyzed without executing the system.

B) What is Use Case Based Testing ? Explain the steps in Use Case Based
Testing.
• Use Case Based Testing is a testing technique in which test cases are derived
from use cases that describe how users interact with the system.
• The steps involved in Use Case Based Testing are explained below:
Step 1: Identify Use Cases
• Gather and document the use cases that describe the functional
requirements of the system.
• Each use case outlines the interactions between the user and the
system.
Step 2: Analyze Use Cases
• Break down each use case into individual steps and scenarios.
• Identify the main success path and alternate or exception paths.
Step 3: Create Test Cases
• Derive test cases from each scenario described in the use case.
• Ensure that both normal and error conditions are covered.
 Step 4: Prioritize Test Cases
• Prioritize test cases based on business importance and risk.
• Focus first on critical and frequently used functions.
Step 5: Execute Test Cases
• Execute the test cases on the system under test.
• Record the actual results obtained during testing.
Step 6: Validate Results
• Compare the actual results with the expected results.
• Identify and document any discrepancies or defects.

30. A) Explain TDD with Java and JUnit example.

• Test Driven Development (TDD) is a software development approach in which
test cases are written before the actual code.
• Java and JUnit are commonly used to implement TDD by creating automated
test cases and validating program behavior.
• The TDD process using Java and JUnit is explained below:
Step 1: Write a Test
• Create JUnit test cases for the required functionality.
• Example: Test a Calculator class for addition and subtraction.
assertEquals(5, [Link](2,3));
assertEquals(1, [Link](3,2));
Step 2: Run the Test
• Execute the test cases using JUnit.
• Initially, the tests fail because the Calculator methods are not
implemented.
Step 3: Write the Code
• Implement the minimum code required to pass the tests.
• Java code :
public static int add(int a, int b){
return a + b;}
public static int subtract(int a, int b){
return a - b;}
Step 4: Run All Tests and Refactor
• Execute all tests again and verify that they pass.
• Refactor the code if necessary without changing its behavior.
Conclusion
• TDD follows the cycle Write Test → Run Test → Write Code → Run Tests →
Refactor.
• Java and JUnit help automate testing and improve software quality.