VI Semester BCA degree examination,July/August-2024

COMPUTER SCIENCE
Software Testing
(NEP SCHEME)
SCHEME OF VALVATION

PART-A
1. .Define software testing. 2M
Software testing is the process of evaluating and verifying that a software product or
application does what it’s supposed to do. The benefits of good testing include preventing
bugs and improving performance.

2. Define test case. 1M

The test case is defined as a group of conditions under which a tester determines whether a
software application is working as per the customer's requirements or not. Test case
designing includes preconditions, case name, input conditions, and expected result. A test
case is a first level action and derived from test scenarios.

1M
3. Write Equivalence classes.2M
Equivalence partitioning involves identifying “equivalence classes,” which are groups of
input values that exhibit similar behavior in the software. We group input values into these
classes and select representative test cases to validate the software’s functionality. This
approach helps us efficiently test the software with optimal coverage.

4.What do you mean by SATM system.

SATM system is a acronym for Simple Automatic Teller Machine. 2M
5.Mention any two issues of Object Oriented testing.
Issues with Object Oriented Testing in Software Testing
1. Dynamic testing of classes is not possible in an OO program 1M
 2. In object-oriented programs, control flow can be monitored with message passing
between objects. 6. Define Exploratory testing. 1M
6.What is meant by exploratory testing.
Exploratory testing is a highly effective approach to testing software that gives testers the
freedom to adapt and experiment on the fly based on their observations of the system and
user behaviors. It allows you to unlock the full potential of your testing team and achieve
better results by catching issues that rigid and traditional testing approaches might miss. 2M

PART B
7.Explain testing life cycle.

The Six Phases of STLC Phases 2M

STLC Phases

The Software Testing Life Cycle (STLC) consists of the following six phases: 3M

1. **Requirement Analysis**
- Understand and analyze the requirements.
- Identify testable requirements.
- Prepare Requirement Traceability Matrix (RTM).
- Identify testing priorities and focus areas.
2. **Test Planning**
- Develop the test plan and strategy.
- Define scope and objectives of testing.
- Estimate effort and resources required.
- Identify testing tools and environment setup.
- Plan for risk management and mitigation.

3. **Test Case Development**

- Create detailed test cases and scripts.
- Prepare test data as per the requirements.
- Review and get the test cases approved.
- Ensure test cases cover all scenarios.

4. **Test Environment Setup**

- Set up the hardware and software environment.
- Install necessary tools and applications.
- Configure the test environment as per requirements.
- Verify the environment setup is complete.

5. **Test Execution**
- Execute test cases and log the results.
- Report any defects or issues found during testing.
- Retest the fixed defects.
- Track the status of defects and test coverage.

6. **Test Cycle Closure**

- Evaluate exit criteria and ensure all objectives are met.
- Prepare test summary report.
- Archive test cases, scripts, and data.
- Conduct retrospective meetings to discuss lessons learned.
 - Provide feedback and recommendations for future projects.
8.Discuss Special value testing.
Special value testing, also known as boundary value testing, is a software testing technique
that focuses on testing the boundaries or limits of input values. It is based on the observation
that errors often occur at the edges of input ranges, making boundary testing crucial for
identifying potential defects. 1M

### Key Aspects of Special Value Testing: 2M

1. **Identification of Boundaries:**
- Determine the input and output boundaries of the software components.
- Identify minimum, maximum, just inside, just outside, typical values, and error values for
inputs.

2. **Selection of Test Cases:**

- Select test cases that include the boundary values of each input domain.
- Include test cases for values that are just below, just above, and exactly on the boundary
limits.

3. **Testing Techniques:**
- **Boundary Value Analysis (BVA):** Focuses on creating test cases for the values at the
edges of the input range.
- **Equivalence Partitioning:** Often combined with BVA to divide input data into
partitions and test each partition's boundaries.

### Steps in Special Value Testing: 2M

1. **Identify Input Range:**

- Define the valid and invalid range of input values for the software under test.

2. **Determine Boundaries:**
- Identify the lower and upper boundaries of the input range.
- Include values just outside the boundaries for negative testing.
3. **Create Test Cases:**
- Develop test cases for values at, just below, and just above the boundaries.
- Ensure coverage of typical and extreme input values.

4. **Execute Test Cases:**

- Run the developed test cases on the software.
- Observe and record the behavior of the software for each test case.

5. **Analyze Results:**
- Compare actual outcomes with expected outcomes.
- Identify any discrepancies or defects.

9.Write the difference between Weak normal and Strong normal Equivalence testing.
### Key Differences 5M
- **Test Case Selection**:
- Weak Normal: Selects one representative value from each equivalence class.
- Strong Normal: Selects multiple values, including boundaries, from each equivalence
class.
- **Defect Detection**:
- Weak Normal: Less effective in detecting boundary-related defects.
- Strong Normal: More effective in detecting defects at boundaries and within equivalence
classes.
- **Effort and Complexity**:
- Weak Normal: Lower effort, simpler to implement.
- Strong Normal: Higher effort, more comprehensive testing.
- **Use Case**:
- Weak Normal: Suitable for initial, quick validation of functionality.
- Strong Normal: Suitable for thorough testing, especially in critical systems where
boundary-related defects are crucial to catch.
10.Write difference betweenTop-Down and Bottom-up Integration. 5M
The difference between Top-down and Bottom-up Integration testing is that the former
moves downward, and the latter moves upward. Top-down focuses on designing and testing
the top module before merging it with sub-modules. Bottom-up, on the other hand, combines
the sub-modules to test them and moves upward thereafter.
Characteristic Top-Down Integration Testing Bottom-Up Integration Testing

Tests the highest-level modules

Tests the lowest-level modules
Approach first and then works down the
first and then works up the order.
hierarchy.

It uses stubs to simulate the lower- It uses drivers to simulate the

Stubs
level modules. higher-level modules.

Complexity Less complex. More complex.

Data Intensity Less data intensive. More data intensive.

Focuses on identifying and

Focuses on identifying and
Risk coverage mitigating risks later in the
mitigating risks early on.
testing process.

It is better suited for testing

It can be used to test large and
Scope smaller and less complex
complex systems.
systems.

It is suitable for systems that

It is suitable for systems that have a
Suitability need a clear hierarchical
clear hierarchical structure.
structure.

It can help to ensure that the

It can help to identify and mitigate
Benefits lower-level modules are working
risks early on.
as expected.

It can be challenging to implement It can be time-consuming and

Drawbacks
for large and complex systems. data-intensive to execute.

Operating systems, database

Device drivers, embedded
Examples systems, and word-processing
systems, and microcontrollers.
software.

Main module calls the sub modules Sub modules integrated with the
top module(s)
Uses stubs as a replacement for
Other missing sub modules Makes use of drivers as a
Differences replacement for main/top
Implemented on modules
structured/procedure-oriented
programming Beneficial for object-oriented
 programming
Significant to identify errors at the
top levels Good to determine defects at
lower levels
Difficult to observe the output
Simple to perform Easy to observe and record the
results
Highly complex and data-driven
11.Explain Model based testing.5M
Model-based testing is nothing but a simple testing technique in which we get different test
cases that are described by the model. In this type, the test cases are generated via both online
and offline test case models.
Significance of Model-Based Testing 5M
1. Early Defect Detection: Model-Based Testing (MBT) makes it possible for testers to
find problems during the requirements or design phases by using model validation. By
doing this, flaws are kept from spreading to more expensive fixing development
phases.
2. Lower Maintenance Costs: Since test cases are derived from models, any
modifications to the system can immediately update the appropriate test cases, which
in turn can reflect any changes made to the models. This lessens the work and expense
of maintaining test cases, particularly in complex and large-scale systems.
3. Reusable Test Assets: Models and tes3Mt cases developed during the software
development lifecycle can be utilized again for regression testing. This guarantees
uniformity in testing procedures across projects and helps optimize the return on
investment in testing efforts.
4. Encouragement of Agile and DevOps Methods: Because it facilitates quick
feedback loops and continuous testing, it works well with Agile and DevOps
approaches. As part of the CI/CD pipeline, test cases can be automatically developed
and run, giving developers quick feedback and guaranteeing the quality of
deliverables.
5. Enhanced Test Coverage: It generates test cases from models that describe all
potential system behaviors and scenarios, assisting in ensuring thorough test coverage.
This aids in the early detection of possible flaws throughout the development process.
12.Write Retrospective on MDD verseus TDD.
Approach and Focus: 1M
 MDD: Focuses on high-level design and automated code generation, reducing manual
coding efforts.
 TDD: Emphasizes thorough testing and incremental development, with a strong focus
on code quality and functionality.
Development Process: 2M
 MDD: Starts with creating models that are later transformed into code. The process is
more top-down.
 TDD: Starts with writing tests, followed by code implementation to pass the tests.
The process is more bottom-up.
Tool Support: 1M
 MDD: Relies on modeling and code generation tools (e.g., UML tools, EMF, etc.).
 TDD: Relies on testing frameworks and tools (e.g., JUnit, NUnit, etc.).
Flexibility and Adaptability: 1M
 MDD: May struggle with rapid changes due to its reliance on predefined models.
 TDD: More adaptable to changes, as it encourages incremental development and
continuous refactoring.
 PART C
13.Discuss the test cases for Commision problem.
10M(EACH TEST CASE 1M)
### Test Cases for Commission Problem

1. **Test Case 1: Minimum Sales Boundary**

- **Input**: Sales = 0
- **Expected Output**: Commission = 0
- **Purpose**: Verify commission calculation at the minimum sales boundary.

2. **Test Case 2: Just Above Minimum Sales**

- **Input**: Sales = 1
- **Expected Output**: Commission as per rate for sales > 0
- **Purpose**: Verify commission calculation just above the minimum sales boundary.

3. **Test Case 3: Mid-Range Sales**

- **Input**: Sales = 500
- **Expected Output**: Commission as per mid-range rate
- **Purpose**: Verify commission calculation for mid-range sales.

4. **Test Case 4: Upper Boundary of Mid-Range Sales**

- **Input**: Sales = 999
- **Expected Output**: Commission as per mid-range rate
- **Purpose**: Verify commission calculation at the upper boundary of mid-range sales.

5. **Test Case 5: Lower Boundary of High Sales**

- **Input**: Sales = 1000
- **Expected Output**: Commission as per high sales rate
- **Purpose**: Verify commission calculation at the lower boundary of high sales.
6. **Test Case 6: Mid-Range High Sales**
- **Input**: Sales = 5000
- **Expected Output**: Commission as per high sales rate
- **Purpose**: Verify commission calculation for mid-range high sales.

7. **Test Case 7: Upper Boundary of High Sales**

- **Input**: Sales = 10000
- **Expected Output**: Commission as per highest rate
- **Purpose**: Verify commission calculation at the upper boundary of high sales.

8. **Test Case 8: Just Above Upper Boundary Sales**

- **Input**: Sales = 10001
- **Expected Output**: Commission as per highest rate
- **Purpose**: Verify commission calculation just above the upper boundary of high sales.

9. **Test Case 9: Negative Sales Input**

- **Input**: Sales = -100
- **Expected Output**: Error message or commission = 0
- **Purpose**: Verify system handles invalid negative sales input appropriately.

10. **Test Case 10: Zero Sales Input**

- **Input**: Sales = 0
- **Expected Output**: Commission = 0
- **Purpose**: Verify commission calculation when there are no sales.

14.Discuss the guidelines for Boundary Value Testing. (10M(EACH POINT 1M)
### Guidelines for Boundary Value Testing in Software Testing

1. **Identify Boundaries:**
 - Clearly define the input and output boundaries for the application under test.
- Determine the lower and upper limits for each input parameter.

2. **Include Boundary Values:**

- Create test cases that include values at the exact boundaries.
- Include values just below and just above the boundary limits.

3. **Consider Valid and Invalid Boundaries:**

- Test both valid boundary values (within the expected range) and invalid boundary values
(outside the expected range).
- Ensure the system handles both types of boundaries correctly.

4. **Use Equivalence Partitioning:**

- Combine boundary value testing with equivalence partitioning to ensure comprehensive
test coverage.
- Test cases should include typical values from within each equivalence partition in addition
to boundary values.

5. **Test Single Parameters Independently:**

- When testing boundaries, vary one parameter at a time while keeping others at their
typical values.
- This helps isolate the effects of each boundary value on the system.

6. **Focus on Critical Boundaries:**

- Prioritize testing of boundaries that are critical to the application's functionality.
- Pay extra attention to boundaries associated with significant business rules or calculations.

7. **Automate Boundary Testing:**

- Use automated testing tools to execute boundary value tests efficiently.
- Automation ensures that boundary tests can be run repeatedly and consistently.

8. **Document Test Cases:**

 - Clearly document each boundary test case, including the input values and expected
outcomes.
- Maintain a record of all boundary conditions tested for future reference and regression
testing.

9. **Consider Multi-Dimensional Boundaries:**

- For applications with multiple input parameters, consider testing combinations of
boundaries.
- Test cases should include scenarios where multiple parameters are at their boundary
values simultaneously.

10. **Review and Update Boundaries:**

- Regularly review and update boundary test cases to reflect any changes in requirements
or application logic.
- Ensure that new boundary conditions introduced by updates or enhancements are also
tested.

15.List the characteristics of Data flow testing. (10M EACH POINT ONE MARK)
### Characteristics of Data Flow Testing in Software Testing

1. **Focus on Variable Lifecycle:**

- Concentrates on the lifecycle of data variables within the code, tracking their definition,
usage, and destruction.

2. **Detection of Anomalies:**
- Identifies potential data anomalies such as uninitialized variables, unused variables, and
improperly modified variables.

3. **Path-Based Testing:**
- Involves testing specific paths in the program where variables are defined, used, and
potentially redefined.

4. **Emphasis on Data Interactions:**

 - Analyzes the interactions between different data elements to ensure they are used
correctly and consistently.

5. **Use of Data Flow Graphs:**

- Utilizes data flow graphs to represent the flow of data through the program, highlighting
points of definition, use, and destruction.

6. **Control Flow and Data Flow Integration:**

- Integrates both control flow and data flow information to provide a comprehensive view
of the program's execution and data handling.

7. **Coverage Criteria:**
- Employs specific coverage criteria such as definition-use (du) pairs, definition-clear (dc)
paths, and all-paths testing to ensure thorough testing of data flow.

8. **Identification of Critical Paths:**

- Identifies critical paths where data values are passed and manipulated, ensuring these
paths are tested for correctness.

9. **Improvement of Code Quality:**

- Aims to improve the overall quality and reliability of the code by ensuring that data is
handled correctly throughout the program.

10. **Detection of Logical Errors:**

- Helps in detecting logical errors related to the use of data, such as data not being used
after being defined (dead code) or data being used without being defined (undefined use).

16.Discuss top ten best practices for software testing excellence.(10M,EACH POINT 1M)
Achieving excellence in software testing involves implementing best practices that ensure the
delivery of high-quality, reliable, and efficient software. Here are the top ten best practices
for software testing excellence:

### 1. **Early and Continuous Testing**

**Shift Left Testing:** Integrate testing early in the software development lifecycle (SDLC).
This helps identify defects sooner, reducing the cost and effort required to fix them.
Continuous testing throughout development ensures ongoing quality.

### 2. **Comprehensive Test Planning**

**Detailed Test Plan:** Develop a comprehensive test plan that outlines the testing strategy,
scope, objectives, resources, schedule, and deliverables. This plan should cover all types of
testing, including functional, non-functional, regression, and acceptance testing.

### 3. **Automated Testing**

**Automate Where Possible:** Implement automated testing for repetitive and regression
test cases. Automated tests increase efficiency, ensure consistency, and allow testers to focus
on more complex and exploratory testing.

### 4. **Risk-Based Testing**

**Prioritize by Risk:** Focus testing efforts on areas of the application that pose the highest
risk to the business. Identify and prioritize critical functionalities and high-impact areas to
ensure they are thoroughly tested.

### 5. **Test-Driven Development (TDD) and Behavior-Driven Development (BDD)**

**TDD and BDD Practices:** Adopt TDD to write tests before code, ensuring that the
software meets its requirements from the outset. Use BDD to improve collaboration between
developers, testers, and business stakeholders by defining tests in natural language.

### 6. **Continuous Integration and Continuous Deployment (CI/CD)**

**CI/CD Pipelines:** Integrate testing into the CI/CD pipeline to ensure that code changes
are automatically tested before being merged and deployed. This practice helps catch defects
early and ensures faster delivery of high-quality software.

### 7. **Comprehensive Test Coverage**

**Achieve High Coverage:** Aim for high test coverage across unit, integration, system, and
acceptance tests. Use code coverage tools to identify untested parts of the codebase and
ensure that all critical paths and edge cases are tested.

### 8. **Effective Use of Test Data**

**Realistic Test Data:** Use realistic and diverse test data that represents actual usage
scenarios. Anonymize and sanitize production data to protect sensitive information while
ensuring test accuracy.

### 9. **Performance and Security Testing**

**Non-Functional Testing:** Include performance, load, stress, and security testing in your
test strategy. Ensuring that the application meets performance benchmarks and is secure
against vulnerabilities is crucial for overall software quality.

### 10. **Continuous Improvement and Learning**

**Regular Reviews and Retrospectives:** Conduct regular reviews and retrospectives to

evaluate the effectiveness of your testing processes. Encourage continuous learning and
improvement by staying updated with the latest testing tools, techniques, and industry trends.

17)Explain the object oriented integration testing. 10M

Object-Oriented Integration Testing (OOIT) is a critical phase in the software testing process
for object-oriented software systems. It focuses on testing the interactions between objects to
ensure that they work together correctly. Here are some key points about OOIT:

### Key Concepts in OOIT 4M

1. **Integration Levels**:
- **Class Level**: Testing interactions between methods within a single class.
- **Cluster Level**: Testing interactions between groups of related classes (also known as
clusters).
 - **System Level**: Testing interactions across the entire system, involving multiple
clusters or subsystems.

2. **Testing Approaches**:
- **Bottom-Up Integration Testing**: Starts with testing the lowest-level components
(classes or clusters) and progressively integrates and tests higher-level components.
- **Top-Down Integration Testing**: Starts with the top-level components and integrates
and tests lower-level components progressively.
- **Sandwich Integration Testing**: Combines both bottom-up and top-down approaches
to integrate and test components simultaneously at different levels.

3. **Types of Tests**:
- **Unit Tests**: Focus on individual methods and classes to ensure they function correctly
in isolation.
- **Integration Tests**: Focus on the interactions between objects and classes to ensure
they work together as expected.
- **System Tests**: Validate the entire system's behavior, including interactions across
different clusters and subsystems.

4. **Test Design Techniques**:

- **Scenario-Based Testing**: Involves creating test scenarios that simulate real-world use
cases and workflows.
- **Use Case Testing**: Based on the use cases defined during the requirements phase,
focusing on testing the system’s functionality from the end-user perspective.
- **State-Based Testing**: Focuses on the states and state transitions of objects, ensuring
that objects behave correctly in different states.

### Challenges in OOIT 3M

- **Complex Interactions**: Object-oriented systems often have complex interactions

between objects, making it challenging to design comprehensive test cases.
- **Inheritance and Polymorphism**: These object-oriented principles add complexity to
testing, as subclasses may inherit behavior from superclasses, and polymorphic methods may
behave differently based on the object's actual type.
- **Encapsulation**: While encapsulation promotes modularity, it can make it difficult to
access and test internal states and behaviors of objects.

### Best Practices for OOIT 3M

1. **Use Automated Testing Tools**: Leverage tools and frameworks like JUnit (for Java),
NUnit (for .NET), and pytest (for Python) to automate integration tests.
2. **Mock Objects and Stubs**: Use mock objects and stubs to simulate the behavior of
complex objects and external dependencies, allowing for isolated testing of interactions.
3. **Continuous Integration**: Integrate testing into the continuous integration (CI) pipeline
to ensure that integration tests are run frequently, catching issues early.
4. **Incremental Testing**: Integrate and test components incrementally to manage
complexity and identify integration issues early in the development process.
5. **Thorough Test Coverage**: Ensure comprehensive test coverage by designing tests that
cover various interaction paths, use cases, and states.

18.Discuss interaction in single processor.

Interaction in a single processor during software testing refers to how different software
components, tasks, or threads interact and share resources on a single CPU. Understanding
and testing these interactions are crucial for ensuring the correct and efficient execution of
software. Here are key aspects and considerations:

### Key Concepts in Interaction on a Single Processor 4M

1. **Task Scheduling**:
- **Preemptive Scheduling**: The operating system can interrupt and switch tasks,
ensuring that high-priority tasks get CPU time. Common in modern operating systems.
- **Cooperative Scheduling**: Tasks voluntarily yield control, which can lead to simpler
designs but risks one task hogging the CPU.

2. **Synchronization Mechanisms**:
- **Mutexes and Locks**: Ensure that only one thread or task can access a resource at a
time, preventing race conditions.
- **Semaphores**: Signaling mechanisms that control access to shared resources.
 - **Monitors**: High-level synchronization constructs that manage concurrent access to
objects.

3. **Inter-Process Communication (IPC)**:

- **Shared Memory**: Different tasks or threads access a common memory area, requiring
careful synchronization.
- **Message Passing**: Tasks or processes send messages to each other, often used to
avoid direct shared memory access.

4. **Resource Sharing and Contention**:

- **Critical Sections**: Code segments where shared resources are accessed and need
protection to prevent concurrent access issues.
- **Deadlocks**: Situations where tasks or threads are waiting indefinitely for resources,
often due to improper synchronization.

### Testing Interactions on a Single Processor 2M

1. **Concurrency Testing**:
- Focuses on ensuring that concurrent tasks or threads execute correctly without interfering
with each other.
- Use of stress tests and load tests to simulate high levels of concurrency and identify
potential issues.

2. **Race Condition Detection**:

- Identify scenarios where the timing of task execution can lead to inconsistent or incorrect
results.
- Tools like dynamic analysis, static code analysis, and specific race condition detectors can
be used.

3. **Deadlock Testing**:
- Detect situations where tasks or threads are unable to proceed due to mutual resource
dependency.
- Static analysis tools, runtime detection, and deadlock prevention algorithms can help
identify and prevent deadlocks.
4. **Performance Testing**:
- Measure the impact of task interactions on overall system performance.
- Identify bottlenecks caused by contention for CPU or other resources.
- Use profiling tools to analyze CPU usage, task switching, and resource contention.

5. **Correctness Testing**:
- Ensure that tasks interact correctly, maintaining data integrity and correct sequencing of
operations.
- Use of assertions, invariants, and formal methods to verify correctness.

### Tools and Techniques for Interaction Testing 2M

1. **Testing Frameworks**:
- Use of frameworks like JUnit for Java, NUnit for .NET, and pytest for Python to write and
manage tests.
- Specialized tools for concurrency testing, such as ConTest for Java.

2. **Static Analysis Tools**:

- Tools like Coverity, SonarQube, and FindBugs analyze code for potential concurrency
issues without executing it.

3. **Dynamic Analysis Tools**:

- Tools like Valgrind, ThreadSanitizer, and Intel Inspector analyze running programs to
detect issues like race conditions and memory errors.

4. **Simulation and Modeling**:

- Use of simulation tools to model and analyze task interactions under various scenarios and
configurations.

### Best Practices for Interaction Testing on a Single Processor 2M

1. **Design for Concurrency**:
- Follow best practices in concurrent programming, such as minimizing shared state, using
immutable objects, and designing with synchronization in mind.

2. **Incremental Testing**:
- Test interactions incrementally, starting with small, isolated components and gradually
integrating more complex interactions.

3. **Use of Mock Objects**:

- Simulate components and interactions to test specific scenarios without needing the entire
system.

4. **Thorough Documentation**:
- Document interactions, synchronization mechanisms, and potential concurrency issues to
aid in understanding and testing.

5. **Continuous Integration**:
- Integrate testing into the continuous integration (CI) pipeline to ensure that interaction
tests are run frequently, catching issues early in the development process.