Software Testing Fundamentals

Quality Center (now HP Application Lifecycle Management) is primarily a test management tool that provides comprehensive functionality for managing the entire testing lifecycle - from test planning and requirement management to test execution and defect tracking. While it does include test execution capabilities, its primary purpose is test management. Options B and C are incorrect because test execution is just one feature, not the primary purpose or an equal purpose.

A Walk Through is characterized by three key elements: Scenario (defining the test situation), Dry Run (practicing the test execution), and Peer Group (involving team members in the review process). While pre-meeting preparations happen, they're not defining characteristics, and walk-throughs typically don't include formal metrics or formal follow-up processes.

Logging test execution outcomes is NOT a major task of Exit Criteria - it's an ongoing task during test execution. Exit criteria focus on evaluation tasks: checking test logs against criteria, assessing if more tests are needed, and writing summary reports for stakeholders. Logging happens continuously and is not part of the exit decision process.

Risk analysis considers two major components: the probability that a negative event will occur (likelihood), and the potential loss or impact associated with that event (consequence). Both factors are essential - a highly likely event with minimal impact may be less critical than a rare event with severe consequences.

Mutation testing involves introducing small changes (mutations) to a program to test whether existing test cases can detect these faults. If tests fail to detect the introduced mutations, it indicates the test suite may be inadequate. This helps evaluate test quality and coverage.

White Box Testing techniques are also called Structural Testing because they examine the internal structure, design, and code implementation of the software. This contrasts with Black Box testing (which examines functionality without looking at internal code) and experience-based techniques.

Acceptance testing is the final testing phase conducted by end-users or customers to validate that the system meets business requirements and is ready for deployment. It is NOT done by QC or QA teams, who perform earlier testing phases. Senior management may review results but don't conduct the testing.

The testing sequence is: Unit → Integration → System → Acceptance. Integration testing combines multiple units, so unit testing MUST be completed first. System testing, stress testing, and UAT come AFTER integration testing, not before.

The four main types of testing are Unit, Integration, System, and Acceptance testing. These form the standard V-model testing hierarchy. Since all four types listed are correct, 'All of the above' is the right answer.

Quality has multiple dimensions: meeting requirements (specifications), zero defects (technical perfection), AND customer satisfaction (fitness for use). All three perspectives are valid definitions of quality in different contexts. Option 1 & 3 only excludes the zero-defects view, which is incomplete.

Reviews (static testing), static analysis (code analysis), and dynamic testing (running tests) all share the primary objective of identifying defects in software. None of these activities directly fix defects - fixing is a separate remediation activity after detection.

Test Readiness Review (TRR) is conducted by the Test Manager to ensure test artifacts are complete, requirements are traceable, and the test environment is ready before testing commences. Test engineers participate but the Test Manager is responsible for conducting it.

Requirements specifications serve as input for User Acceptance Test (UAT) cases. UAT validates that the system meets user requirements as specified. Unit tests use code/design specs, integration tests use design specs, and UAT focuses on requirement validation.

Impact Analysis is primarily used in Maintenance Testing to assess the potential effects of changes on existing system components. When modifications are made during maintenance, impact analysis helps identify which parts of the system might be affected, ensuring comprehensive test coverage. While other testing types may use impact analysis, maintenance testing relies on it most heavily because changes to existing systems carry the highest risk of unintended side effects.

Test Conditions are derived from Specifications, which include requirements documents, design specifications, and other stakeholder needs. Specifications provide the basis for identifying what needs to be tested. Test conditions are the specific items or attributes that will be tested, and they must be traceable back to the original requirements. Test cases are created FROM test conditions, not the other way around.

According to the ISTQB software testing standard, 'Functional testing' is classified as a test type (testing what the system does). The other options—Component, System, and Acceptance testing—are categorized as test levels, not test types.

Boundary value analysis is a functional testing technique that tests values at the boundaries of input domains (e.g., minimum, maximum, just below/above boundaries). It focuses on the functional behavior at edge cases. Usability, performance, and security testing are non-functional testing types.

A test completion criterion defines the conditions, such as coverage metrics or bug thresholds, under which testing is deemed sufficient and can stop. It does not dictate when a single test finishes or how test inputs are generated.

BS 7925-1 is specifically titled 'Vocabulary of Terms in Software Testing' and provides standardized definitions. ISO/IEC 12207 covers software life cycle processes, not testing terminology. ANSI/IEEE 829 defines test documentation formats, and ANSI/IEEE 729 is not a real testing standard.