JNTU B.Tech III SOFTWARE TESTING METHODOLOGIES Previous Question Paper (November/December - 2020 - R16)

In software testing, dichotomies represent pairs of opposing concepts or strategies that help testers categorize testing activities and understand the trade-offs involved in the testing process. The primary dichotomies are:

• Testing vs. Debugging: Testing is the process of executing a program with the intent of finding errors, whereas debugging is the diagnostic process of locating, analyzing, and correcting the root cause of those errors.
• Function vs. Structure: Functional testing (Black-box) focuses on verifying that the software performs its intended functions according to requirements without regard to internal code. Structural testing (White-box) examines the internal logic, control flow, and data structures of the code.
• Random vs. Partition Testing: Random testing involves selecting test cases from the input domain based on probability distributions. Partition testing involves dividing the input domain into equivalence classes and selecting representative test cases from each to ensure comprehensive coverage.
• Positive vs. Negative Testing: Positive testing verifies that the system performs as expected under normal, valid conditions. Negative testing attempts to break the system by providing invalid, unexpected, or boundary inputs to ensure robust error handling.
• Static vs. Dynamic Testing: Static testing involves reviewing or analyzing code, requirements, and design documents without executing the software. Dynamic testing requires the actual execution of the code to observe its behavior and output.
• Manual vs. Automated Testing: Manual testing relies on human testers to execute test cases without automation tools, which is useful for exploratory testing. Automated testing uses scripts and tools to execute repetitive tests, increasing efficiency and consistency in regression testing.
• Verification vs. Validation: Verification ensures the product is built correctly according to specifications (Are we building the product right?). Validation ensures the product meets the user's actual needs and expectations (Are we building the right product?).

A Transaction is a unit of work seen from a system user's perspective. It represents an operation that begins with an input or a request and ends with an output or a completion signal, typically involving a sequence of operations, database updates, or state changes within a system.

Transaction flow testing is a black-box testing technique used to verify the functional requirements of a system by tracing the path of a transaction through the system's components. It focuses on the validity of the sequence of states and transitions triggered by specific inputs.

The process involves identifying all possible transaction paths, including both successful paths and error-handling paths. The key steps include:

1. Identify all transactions and their associated inputs/outputs.
2. Represent the system as a directed graph where nodes represent states and edges represent the transitions between them.
3. Define the paths through the graph that represent valid transaction sequences.
4. Design test cases to cover these paths, ensuring that every transition is exercised and that the system correctly handles invalid sequences or unexpected inputs.

For example, consider an ATM Withdrawal Transaction:

In this flow, transaction testing would verify:

• The successful path where the PIN is valid and funds are sufficient.
• Negative paths, such as entering an incorrect PIN (leading to a retry or lockout) or requesting an amount exceeding the balance (leading to a rejection message).
• System recovery paths, such as what happens if the network connection drops during the 'Update Account' step.

By testing these flows, testers ensure that the system maintains data integrity and follows the intended business logic under all conditions.