SOFTWARE TESTING

MODEL QUESTION PAPER -2

SECTION-A (4X2=8)

1. Define Test and Testcase.

Test: Testing involves identifying errors, faults, failures, & incidents. A test is the process of executing software with test cases.
The primary goal of testing is to find failure or to demonstrate correct execution.
Test Case: A test case is a specific test scenario with defined inputs & expected outputs associate with a particular program
behavior. Test cases help in systematically validating the functionality of the software.

2. What is decision table-based testing?

Decision table-based testing is a technique used in software testing that helps to identify test scenarios based on combinations of
inputs and their associated outputs or actions. It is a systematic way of representing complex business rules or conditions in a
tabular format, making it easier to derive test cases. A decision table consists of the following components: Condition , condition
entries, action, action entries

3. What is slice based test?

Slice-based testing, also known as data flow testing or program slicing, is a software testing technique that focuses on testing
specific scenarios or "slices" of a program's code based on the data flow within the program. The concept of program slicing
involves identifying the portions of code that are relevant to a particular variable or output of interest. This "slice" includes all the
statements and conditions that directly or indirectly affect the value of the variable or output being tested .

4. What is call Graph-based Integration?

Call graph-based integration testing, also known as call graph testing or integration testing using call graphs, is a technique used in
software testing to identify and test the integration points between different modules or components of a software system

A call graph is a graphical representation of the relationships between different components or modules in a software system,
showing how they call or invoke each other's functions or methods. It provides a visual representation of the control flow and
dependencies within the system.

5. What is exploratory testing?

Exploratory testing is a software testing approach that involves simultaneously learning about the software application, designing
and executing tests, and investigating the results. Unlike scripted or pre-defined test cases, exploratory testing relies on the tester's
experience, knowledge, and critical thinking skills to explore the software and uncover defects.

In exploratory testing, the tester does not follow a predetermined set of test cases or test scripts. Instead, the testing process is
guided by the information learned during the exploration of the software, and new tests are dynamically designed and executed
based on the outcomes of previous tests.

6. What is test-then-code cycle?

The test-then-code cycle, also known as test-driven development (TDD), is a software development
approach where the tests for a particular piece of code are written before the actual code is implemented. It
follows a cyclical process where developers iteratively write tests, implement code to pass those tests, and
then refactor the code as needed.
The test-then-code cycle is a core practice in agile software development methodologies, such as Extreme
Programming (XP), and is widely adopted in various software development environments and programming
languages.
 SECTION-B (4x5=20)

7. Explain the importance of software testing

8.Differentiate between weak Robust Vs Strong Robust Equivalence class testing.

9.How Def-Use Testing work? Explain with an example.
 10.What is Atomic System Function [ASF]? Explain the importance of ASFs

11.Explain object-oriented Integration Testing?

Object-Oriented Integration Testing is a type of software testing that focuses on verifying the interactions
and collaborations between different objects and components within an object-oriented system. It aims to
ensure that the objects and classes work correctly when integrated together and that the communication and
data flow between them are as expected.

In object-oriented integration testing, the following aspects are typically examined:

1. Interface Testing: This involves testing the interfaces (methods, properties, events) exposed by
objects and classes to ensure that they behave correctly when invoked or accessed by other objects or
components.
2. Interaction Testing: This focuses on testing the interactions between objects, such as how they
communicate with each other through method calls, message passing, or event handling.
3. Collaboration Testing: This tests the collaboration between multiple objects or components to
ensure that they work together correctly to achieve a specific functionality or use case.
4. Data Flow Testing: This verifies the correct flow of data between objects, ensuring that data is
passed, received, and processed accurately by the involved objects.
5. State-based Testing: This checks the state transitions of objects and how they respond to different
events or method calls based on their current state.
Object-oriented integration testing can be performed at different levels, such as:

1. Class Integration Testing: This tests the interactions between classes within the same package or
module.
2. Package/Module Integration Testing: This tests the integration of classes across different packages
or modules.
3. Subsystem Integration Testing: This tests the integration of multiple subsystems or components
within the application.
4. System Integration Testing: This tests the integration of the entire system with external systems,
databases, or third-party components.

12. What is Test Driven Development (TDD)? Explain the features or characteristics of TDD
13. Explain fundamental Approaches to Apply Test Cases with examples.
 14a) Explain Worst Case Boundary Value Testing (WCBVT) with an example.

14.b) Explain Equivalence Class Test Cases for the Commission Problem.

The commission problem is a common example used in software testing to illustrate the concept of
equivalence class partitioning. In this problem, a salesperson receives a commission based on their sales
amount, following a specific set of rules. The equivalence class test cases are designed to cover the different
ranges of input values and test the boundary conditions.

Here's an explanation of the equivalence class test cases for the commission problem:

1. Valid Equivalence Classes:

o Sales amount less than or equal to $0: This class represents negative or zero sales, where the
commission should be $0.
o Sales amount between $1 and $5,000 (inclusive): For this range, the commission should be
8% of the sales amount.
o Sales amount between $5,001 and $10,000 (inclusive): In this range, the commission should
be 10% of the sales amount.
o Sales amount greater than $10,000: For sales above $10,000, the commission should be 12%
of the sales amount.
2. Invalid Equivalence Classes:
o Non-numeric input: This class covers cases where the input for the sales amount is not a valid
number (e.g., alphabets, special characters).
 o Extremely large or small values: This class includes input values that are unrealistically large
or small, which may cause issues like overflow or underflow.

For each valid equivalence class, at least two test cases should be designed: one within the range and one at
the boundary. Here are some examples of test cases:

1. Valid Equivalence Classes:

o Sales amount less than or equal to $0: Test cases could be $0 and $-1.
o Sales amount between $1 and $5,000: Test cases could be $1, $2,500, and $5,000.
o Sales amount between $5,001 and $10,000: Test cases could be $5,001, $7,500, and $10,000.
o Sales amount greater than $10,000: Test cases could be $10,001 and a large value like
$100,000.
2. Invalid Equivalence Classes:
o Non-numeric input: Test cases could be "ABC" and "@#$%".
o Extremely large or small values: Test cases could be a very large number (e.g., 1e+100) and a
very small number (e.g., 1e-100).

These test cases aim to cover the different scenarios and boundary conditions to ensure that the commission
calculation logic works correctly for all possible inputs. By executing these test cases, any defects or issues
related to the commission calculation can be identified and addressed.

15.a) Explain the Guidelines & Observations for Decision table testing.
15.b) What is Data Flow Testing? Explain the characteristics of Data Flow Testing
16.a) How Path-Based Integration works?

16.b) Explain the characteristics & Importance of a Thread in System Testing

17.a) Explain Static Interactions in Multiple Processors with detailed example.
 17.b) What is Use Case Based Testing? Explain the steps in Use Case Based Testing

18.a) Explain TDD with Java &Junit with an example

18.b) Explain Exploratory & Context-Driven Testing Observation

Exploratory and Context-Driven Testing are two related concepts in software testing that emphasize a more
flexible and adaptive approach to testing, as opposed to following a predetermined and rigid test plan.

Exploratory Testing: Exploratory Testing is a hands-on approach to software testing where the tester
actively explores the application or system under test, simultaneously designing and executing tests based on
the information gained during the exploration process. It involves a simultaneous learning, test design, and
test execution process, guided by the tester's experience, knowledge, and intuition.

Key aspects of Exploratory Testing include:

1. Simultaneous Learning and Testing: Testers learn about the application while testing, and the
gained knowledge informs the next testing steps.
2. Unscripted and Improvised: Tests are not pre-scripted or planned in detail; instead, testers
improvise and adapt their testing based on the observed behavior and results.
3. Experience and Intuition-Driven: Testers rely on their experience, domain knowledge, and
intuition to guide the exploration and identify areas of interest or potential risks.
4. Rapid Feedback: Exploratory Testing provides rapid feedback on the application's behavior,
enabling early detection of defects and issues.

Context-Driven Testing: Context-Driven Testing is a broader principle that recognizes the importance of
considering the specific context and environment in which testing is performed. It emphasizes that testing
activities should be tailored to the unique circumstances and constraints of each project, rather than
following a one-size-fits-all approach.

Key aspects of Context-Driven Testing include:

1. Contextualized Testing: Testing activities are adapted to the specific project context, including
factors such as the development methodology, team dynamics, business domain, and stakeholder
expectations.
2. Focus on Value: Testing efforts are prioritized based on the perceived value and risks, taking into
account the project's context and goals.
3. Ongoing Learning and Adaptation: Testers continuously learn and adapt their testing approach
based on the evolving context and feedback from stakeholders.
4. Skilled Testers: Context-Driven Testing relies on skilled and experienced testers who can make
informed decisions and adapt their testing strategies based on the project's context.

While Exploratory Testing and Context-Driven Testing are distinct concepts, they are often used together.
Exploratory Testing is a powerful technique that allows testers to leverage their skills and experience to
uncover defects and issues within the context of a specific project or application. Context-Driven Testing
provides the overarching framework for tailoring testing activities to the unique circumstances of each
project, enabling the effective application of exploratory and other testing techniques.

Both Exploratory Testing and Context-Driven Testing emphasize the importance of tester expertise,
flexibility, and the ability to adapt to changing conditions and requirements. They encourage a more
dynamic and responsive approach to testing, rather than relying solely on predefined and rigid test plans or
scripts.