Software Testing Fundamentals

Structure-based (white-box) testing coverage is measured by which code elements have been executed: decision outcomes (branch coverage), statements (line coverage), and conditions within decisions (condition coverage). Partitions, boundaries, and cause-effect graphs relate to black-box specification-based techniques, not structure-based analysis.

Boundary Value Analysis operates on the assumption that behavior is consistent within equivalence partitions - input ranges where the system produces similar results. This assumption allows testers to focus on boundaries (where behavior changes) rather than testing every value within a continuous portion of the input domain.

Maintenance testing employs two main methodologies: Breadth testing (testing across multiple areas to ensure changes haven't adversely affected other parts of the system) and Depth testing (thoroughly testing the specific changed area). Retesting and confirmation testing refer to rerunning failed tests after fixes, while sanity testing is a quick subset of regression testing.

White box testing is also known as structural testing because it focuses on the internal structure, pathways, and logic of the software code. Design-based, error guessing, and experience-based techniques are separate paradigms or black-box/hybrid methodologies.

Equivalence partitioning divides input data into groups (partitions) that are expected to be processed similarly. The key principle is that testing one value from each partition is sufficient to find defects affecting that partition, rather than testing every possible value. This makes testing more efficient while maintaining good coverage.

Use cases describe how users interact with the system to accomplish specific goals in real-world scenarios. Test cases derived from use cases are particularly valuable for discovering defects in actual user workflows and process flows, rather than just testing individual features in isolation. They help validate the system from a user's perspective.

Designing the tests is part of the Test Design phase, which occurs before Test Implementation and Execution. Creating suites, executing tests, and comparing results are core activities of the implementation and execution phase, making 'Designing the Tests' the correct choice.

White box testing techniques require visibility into the internal code structure and include statement coverage, decision/branch coverage, and condition coverage. Boundary value analysis is a black box technique because it focuses on input and output values at boundaries without examining internal code logic. It relies on understanding the input domain rather than the code implementation.

Project risks are high-level organizational and managerial concerns that could impact project delivery, such as unclear requirements, stakeholder conflicts, poor communication, unrealistic deadlines, inadequate resources, or organizational changes. Options B, C, and D describe product risks (technical risks related to the software itself) rather than project risks.

In a risk-based testing approach, identified risks directly inform the extent of testing to be performed. High-risk areas receive more thorough testing attention, while lower-risk components may be tested less extensively. This ensures that limited testing resources are allocated where they'll provide the most value in finding critical defects early.

The Planning phase of a formal review focuses on logistical preparation: defining review criteria, selecting appropriate team members based on expertise, allocating roles (moderator, author, reviewers, scribe), and scheduling the review meetings. Activities like explaining objectives, individual preparation, and follow-up occur in other phases (Kick-off, Preparation, and Rework/Follow-up respectively).

The Scribe (also called Recorder) is responsible for documenting all issues, problems, defects, and open points identified during a formal review meeting. The Moderator manages the review process, the Author created the work product being reviewed, and the Manager may sponsor the review but doesn't typically document issues.

A walkthrough is an informal peer review technique characterized by: meeting scenarios where the author presents the work, conducting a dry run through the document/code, and involving a peer group of colleagues. Key characteristics include its informal nature, lack of formal training requirements, minimal preparation, and absence of formal follow-up processes or metrics collection.

Static analysis analyzes source code without executing it. It can find syntax errors, dead code, undefined variables, and array bound violations. However, memory leaks are dynamic run-time anomalies that static analysis cannot reliably identify, requiring dynamic execution to detect accurately.

Incidents (defects or issues) are typically raised against tangible deliverables like requirements, documentation, and test cases when problems are found. Improvements suggested by users are generally categorized as enhancement requests or feature requests, not as incidents. User suggestions for improvements represent potential future enhancements rather than defects requiring incident reports.

Security testing is a type of functional testing specifically focused on evaluating system vulnerabilities and protection mechanisms against malicious threats like viruses, malware, and unauthorized access from outsiders. It tests authentication, authorization, encryption, and other security controls. Recovery testing deals with system restoration after failures, performance testing measures system responsiveness under load, and functionality testing validates features work as specified - none of these focus on threat detection.

Exit criteria evaluation involves checking logs, assessing if more tests are needed, and writing reports. Logging the outcomes of test execution is part of the Test Execution phase, not a task of evaluating or executing the Exit criteria phase itself.

Load testing involves subjecting a system to varying workloads to measure performance characteristics like response time, throughput, and resource utilization. It helps identify performance bottlenecks and ensures the system functions properly under different load conditions. Integration testing focuses on interfaces between components, system testing validates the complete system, and usability testing evaluates user experience - none specifically test workload performance behavior.

Integration level testing specifically targets the interfaces and interactions between integrated components or modules. It exposes defects that occur when components work together, such as data flow problems, interface mismatches, or timing issues. System level testing evaluates the complete system, unit testing focuses on individual components, and component testing isolates specific parts - none specifically target inter-component interfaces.

Static analysis involves examining program code without executing it to find defects, vulnerabilities, or violations of coding standards. It uses automated tools or manual review to analyze source code structure, logic, and potential errors. Batch programs and test plans are not analyzed, and black box testing is dynamic (requires execution) rather than static.