Unit 4 - Practice Quiz

Software testing is a process of executing a program or application with the intent of finding software bugs. While it can't prove the complete absence of errors, its main goal is to identify and report them so they can be fixed before release.

A test case specifies the inputs, execution conditions, testing procedure, and expected results to verify a specific feature or functionality of a software application.

Functional testing validates the software system against the functional requirements. It checks what the system does, such as user login, data entry, and other core functionalities.

Non-Functional testing checks how the system performs. Aspects like performance (speed), usability, reliability, and security are non-functional attributes.

White box testing is called 'glass-box' or 'structural' testing because the tester has full visibility into the internal code structure and logic of the application to design test cases.

Black box testing focuses on the external behavior of the software without any knowledge of the internal implementation. It's based purely on what the system is supposed to do.

Equivalence Partitioning divides input data into partitions of equivalent data. The theory is that testing one value from each partition is sufficient to cover all values within that partition, thus reducing redundancy.

Boundary Value Analysis (BVA) focuses on testing the values at the boundaries of an input domain. For a range of 10-50, this includes the minimum (10), maximum (50), just below minimum (9), and just above maximum (51).

Unit Testing is the first level of testing where individual components or modules of the software are tested in isolation, usually by the developer who wrote the code.

Integration Testing is performed after Unit Testing. Its purpose is to expose defects in the interfaces and interactions when different software modules are combined and tested as a group.

System Testing is a level of testing that validates the complete and fully integrated software product. It evaluates the system's compliance with its specified requirements.

User Acceptance Testing (UAT) is the final phase of testing, performed by the end-users or clients, to verify that the software meets their business requirements and is acceptable for deployment.

API (Application Programming Interface) testing validates the functionality of the business logic layer without involving the user interface. It checks if the APIs meet expectations for functionality, reliability, performance, and security.

Cross-Browser Testing is a specific type of Web Testing that ensures the web application works as expected across different web browsers, maintaining its functionality and appearance.

Selenium IDE is a simple tool, primarily a browser extension, that allows users to record their actions in a web browser and then play them back as an automated test. It's ideal for beginners and creating quick regression tests.

Selenium IDE is implemented as a browser add-on or extension, which makes it very easy to install and access directly from the browser's toolbar for recording and playing back tests.

Selenium WebDriver provides a programming interface (API) for creating and executing test scripts using languages like Java, C#, Python, etc. This offers more flexibility and power than the simpler, codeless record-and-playback model of Selenium IDE.

Performance Testing is a non-functional testing type that measures how a system performs in terms of key metrics like response time, throughput, and resource utilization, especially under heavy load.

Security Testing is a process intended to uncover flaws in the security mechanisms of an information system that protect data and maintain functionality as intended. Its main goal is to find vulnerabilities before malicious attackers do.

AI-assisted testing tools leverage machine learning to analyze an application, automatically generate relevant test cases, identify redundant tests, and even 'self-heal' broken test scripts when the UI changes, significantly speeding up the testing process.

Three-point Boundary Value Analysis involves testing values at the boundary, just inside the boundary, and just outside the boundary. For the range [0, 100], the lower boundary is 0 (test values: -1, 0, 1) and the upper boundary is 100 (test values: 99, 100, 101).

Integration Testing specifically focuses on verifying the interfaces and interactions between different software modules or components. A defect in data passing between two modules is a classic example of an integration issue.

This requirement describes how well the system performs a function (its performance characteristics like speed and capacity), not what the system does. This is the definition of Non-Functional Testing, specifically Performance Testing.

White-box testing involves analyzing the internal structure and logic of the code. Ensuring that all decision branches are executed is a specific white-box technique known as Branch Coverage or Decision Coverage.

Selenium WebDriver uses language bindings (Java, Python, C#, etc.) that allow testers to write sophisticated, robust test scripts with programming constructs, external library integrations (like databases), and advanced test execution frameworks. Selenium IDE is primarily a record-and-playback tool with limited logic capabilities.

Equivalence Partitioning divides input data into classes from which test cases can be derived. For the age range 18-99, there are three main partitions: one invalid partition below the range (age < 18), one valid partition (18 ≤ age ≤ 99), and one invalid partition above the range (age > 99). The set {15, 45, 105} picks a single representative value from each of these three partitions.

Effective API testing validates the contract. For a DELETE operation, this means checking for a success status code (like 200 or 204) and, crucially, verifying the state change by confirming the resource is actually gone (e.g., via a follow-up GET request that should now fail).

Stress Testing is designed to determine the system's robustness and breaking point by subjecting it to extreme loads, often well beyond its expected operational capacity. Load Testing, in contrast, evaluates performance under expected or normal peak loads.

UAT is the final phase of testing, performed by clients or end-users, to validate that the system works for them in a real-world context and fulfills the agreed-upon business needs. It is less about finding low-level bugs and more about validating overall business fitness.

Cross-Site Scripting (XSS) is a vulnerability where an attacker injects malicious scripts into content from otherwise trusted websites. When the script is executed in a victim's browser, it can lead to session hijacking or data theft. The use of <script> tags is a classic method for testing for XSS.

Mobile devices constantly change network conditions (Wi-Fi, cellular, offline). Testing for interruptions, network handovers, and varying latency is a critical and unique aspect of mobile testing that is not a primary concern for stationary desktop applications.

Defect clustering, which is an application of the Pareto Principle (80/20 rule) to software testing, observes that a large percentage of defects are often concentrated in a small, complex part of the system. This helps teams focus their testing efforts where they are most likely to be effective.

Record and playback tools often rely on specific locators (like absolute XPath) that are prone to breaking when developers change the UI layout or element attributes. This makes the recorded test scripts "brittle" and hard to maintain over the life of a project.

One of the most powerful features of modern AI-assisted testing tools is "self-healing." When a UI element's locator changes (e.g., its ID is modified), the AI can analyze the page, find the intended element based on other attributes, and automatically update the test script, significantly reducing maintenance effort.

In a bottom-up integration strategy, lower-level modules are integrated first. To test this cluster, a 'driver' is created. A driver is a test program that calls the functions of the lower-level module and simulates the behavior of a yet-to-be-developed higher-level module. Stubs are used in top-down integration.

Compatibility testing verifies that the software works as expected across different environments. In web testing, this prominently includes different browsers, operating systems, and screen resolutions. An issue that appears in one browser but not others is a classic compatibility defect.

Statement Coverage is a white-box testing metric that measures the percentage of executable statements in the source code that have been exercised by the test suite. Achieving 100% statement coverage means every line of code has been run at least once.

Regression Testing is a type of functional testing performed to ensure that a change, such as a bug fix or a new feature, has not adversely affected existing functionalities. It involves re-running a subset of existing tests to check for unintended side effects.

System Testing is a black-box testing level that evaluates the complete and fully integrated software product. Its main purpose is to verify that the system meets the specified functional requirements (what it does) and non-functional requirements (how well it does it, e.g., performance, security) as a whole.

Latency, often used interchangeably with response time, is a critical performance metric. It measures the total time it takes for a single request to be processed, from the moment it is sent by the client until the client receives the full response from the server.

Let the conditions be A (userIsAdmin), B (userIsEditor), C (document.isPublished()), and D (!document.isLocked()). The expression is (A || B) && (C && D). MC/DC requires that every condition is shown to independently affect the outcome. To satisfy this, we need a baseline case and a variation for each condition:

1. Baseline (Outcome=True): A=T, B=F, C=T, D=T -> (T || F) && (T && T) -> True
2. A affects outcome: A=F, B=F, C=T, D=T -> (F || F) && (T && T) -> False
3. B affects outcome: A=F, B=T, C=T, D=T -> (F || T) && (T && T) -> True
4. C affects outcome: A=T, B=F, C=F, D=T -> (T || F) && (F && T) -> False
5. D affects outcome: A=T, B=F, C=T, D=F -> (T || F) && (T && F) -> False
   This set of 5 test cases ensures each of the four conditions (A, B, C, D) independently affects the decision's outcome, fulfilling the MC/DC criteria.

This problem involves both data and control flow interdependencies. The most critical interactions occur at the boundaries. The most effective strategy is to combine Boundary Value Analysis for the continuous variable (weight) with Equivalence Partitioning for the discrete variable (country). The two most important partitions for country are "USA" (which triggers a UI change) and any other country (which does not). By testing all weight boundaries against these two partitions, you cover the data-driven logic (fee calculation) and the UI logic (state field visibility) simultaneously and efficiently, uncovering potential interaction bugs.

This is a classic integration defect. The 'contract' between the two services has been broken. Unit tests passed because they test the components in isolation (with mocks). While System and UAT would eventually find the bug, the most precise and earliest level to detect this kind of inter-service communication failure is during Component Integration Testing, where the primary goal is to verify the interfaces and interactions between collaborating components.

The key evidence is that throughput has hit a ceiling, but the primary application server's resources (CPU, memory) are underutilized. This strongly suggests the bottleneck is external to the application server itself. A saturated database connection pool or a rate-limited third-party API are common examples of downstream dependencies that would limit the overall system throughput without maxing out the local application's CPU.

This is a classic Unrestricted File Upload vulnerability. The application failed to properly validate the file on the server-side (e.g., by checking MIME type or enforcing a strict, safe filename). The use of a double extension (.php.jpeg) is a common trick to bypass simple extension checks. Because the malicious file containing server-side code (PHP) was uploaded and later executed by the server, this constitutes Remote Code Execution (RCE), which is one of the most critical security vulnerabilities.

The core architectural principle of WebDriver is the client-server model mediated by the driver. This separation is key. First, it enables cross-browser testing: your Java code doesn't change whether you're targeting Chrome or Firefox. Second, tools that inject JavaScript (like Selenium RC) run within the same security sandbox as the application under test. This can lead to conflicts and security restrictions. WebDriver's approach, using browser automation APIs provided by the vendor (via the driver), operates at a privileged level, mimicking a real user more closely and avoiding these sandbox issues.

This question explores the often-blurry line between functional and non-functional testing in specific domains. For a high-frequency trading platform, a transaction that is 'correct' but 'late' is effectively a failure. The performance attribute (speed) is so integral to the function's purpose that its failure constitutes a functional defect. The requirement being stated as a quantifiable metric (99.9% in 10ms) makes it a testable, contractual part of the system's function.

Consumer-Driven Contract Testing is excellent for preventing integration issues caused by structural changes (e.g., a field is renamed or a data type changes). However, it does not, by itself, verify the business logic. For example, a contract test can verify that a response contains an integer field named totalPrice, but it cannot verify if the totalPrice was calculated correctly. That level of validation requires functional or integration tests that check the business logic.

Unlike a simple 'click', a gesture is a complex interaction defined by a path, duration, and speed. Emulating these consistently in an automated script is very difficult. Minor differences in screen resolution, pixel density, or the OS's event processing loop can cause a simulated gesture that works on one device to fail on another. This inconsistency is a primary source of test flakiness for gesture-based automation, making it a much harder problem than simple element tapping.

While all options are valid AI applications, Predictive Test Selection (also called Test Impact Analysis) offers the most significant optimization for the developer feedback loop in a mature CI/CD context. In large systems, running the entire test suite can take hours. By intelligently selecting only the relevant tests (e.g., the 5% of tests that cover the 2% of code that just changed), AI can provide developers with feedback in minutes instead of hours, dramatically accelerating the development and deployment cycle.

This scenario presents a problem of combinatorial explosion. With 15 boolean inputs, the total number of possible input combinations is , which equals 32,768. Testing every single combination is impractical and time-consuming, yet for safety-critical software like a flight control system, the risk associated with missing a specific combination of inputs is extremely high. This forces the test manager to rely heavily on risk-based testing strategies (like Cause-Effect Graphing or Pairwise Testing) to select a manageable subset of tests, directly confronting the challenge that exhaustive testing is impossible.

Data Flow Testing focuses on the lifecycle of variables. A def-def (or DD) path is one where a variable is defined, and then redefined without any intervening use. This is an anomaly because the first assignment had no purpose. While not always a bug, it often points to a logical error, a copy-paste mistake, or dead code that can be removed, making the code cleaner and less prone to future errors.

Sandwich integration is a hybrid strategy that aims to get the benefits of both top-down and bottom-up approaches. It focuses on a middle layer (in this case, the Business Logic Layer) as the primary point of integration. Testing proceeds upwards from this layer (integrating the UI) and downwards (integrating the Data Access Layer) simultaneously. This allows the most critical business logic to be tested early, and the parallel nature of the testing can save time, although it can be more complex to manage.

This is a classic timing issue with modern web apps. The test script proceeds at a fixed speed, while the AJAX call's duration varies. The intermittent failure is a tell-tale sign of a race condition. Using a fixed pause is brittle and inefficient. The most robust solution is to use an explicit wait that is tied to an observable application state. Waiting for the loading spinner to disappear is a perfect synchronization point, as it directly indicates that the asynchronous operation has completed. The test will then proceed immediately, making it both reliable and fast.

This is a problem of finding a stable locator amidst dynamic attributes. button[type='submit'] is not specific enough; there could be other submit buttons. button.primary.large is better but could break if the class names are changed for styling purposes. div > button:first-of-type is very brittle as it depends on the DOM structure. The selector button[id*='-login'][class*='primary'] is the most robust because it combines two pieces of information: a stable partial ID (-login is likely constant) and a key class name. This combination makes it highly specific and resilient to changes in the exact ID, other class names, or the element's position in the DOM.

The defining constraint of the problem is the lack of access to the source code, which immediately rules out any white-box techniques. Decompiling the library (Option B) is often illegal and technically difficult. While performance/security (Option C) and integration (Option D) are important, the primary task is to verify the core functional correctness of the complex calculations. Given the detailed documentation of rules, systematic black-box techniques are the perfect fit. Decision Table Testing is particularly well-suited for scenarios with many complex business rules.

This is a key conceptual distinction. Load testing is about verification against requirements ('Does the system meet its performance goals at the expected Black Friday peak load?'). Stress testing is about discovery and robustness ('At what point does the system break, and how does it break? Does it recover gracefully?'). Spike testing (Option B) is a specific type of stress test. While both test types measure response time and resource utilization, their fundamental goals are different: verification vs. breaking point analysis.

This problem requires combining two different testing heuristics. First, standard 3-value BVA for the range [100, 200] gives us {99, 100, 101} and {199, 200, 201}. Second, the rule about 'multiples of 10' creates an important equivalence partition within the valid range. We must test a value from this partition. However, since 100 and 200 are already boundaries that are also multiples of 10, a truly thorough test should also check boundaries of this special logic inside the main range. Therefore, testing 110 (a multiple of 10) and 190 (another multiple of 10 near a boundary) provides strong coverage. The selected option combines the outer boundaries and inner partition boundaries efficiently.

High uptime SLAs are validated by testing a system's reliability and recoverability. The most direct way to do this is through a combination of endurance (soak) testing to find issues that emerge over time, and 'chaos engineering' principles like deliberately causing failures. Terminating instances and measuring if the system recovers automatically without user-facing downtime directly tests the mechanisms (failover, redundancy) that are put in place to achieve a high uptime guarantee. The other options test performance, functionality, and usability, which are important but do not directly validate the 99.95% uptime claim.

The core distinction between Alpha and Beta testing lies in the 'who' and 'where'. Alpha testing is the 'internal' UAT phase. It's a dress rehearsal before showing the product to the outside world. Beta testing is the first time the product is exposed to real, external users who are not part of the development organization. This exposure to diverse, real-world environments, data, and usage patterns is the main value of beta testing. While bug finding and feedback collection happen in both, the environment and the participants are the defining factors.