Software Testing and Quality Control

Requirement defects are raised after FPQ (likely Final Product Qualification or Formal Product Qualification). Before FPQ, requirements are still being clarified and finalized; raising defects during this stage would be premature as the requirements themselves may change. After FPQ, requirements are baselined, and any deviations from agreed requirements become legitimate defects. HLE (likely Higher Level Examination or High-Level Engineering) typically occurs earlier in the lifecycle.

Boundary Value Analysis (BVA) is the technique described. BVA complements Equivalence Partitioning by focusing test cases at the edges of equivalence partitions (minimum, minimum-1, maximum, maximum+1), where defects are most likely due to off-by-one errors. Equivalence Partitioning divides inputs into classes but doesn't specifically target edges. State transition and cause-effect graphs address different testing concerns.

Cognos models are tested through the 'Check Model' option in the Tools menu. This validates the model's structure, verifies relationships between query items, checks for inconsistencies, and ensures the model is ready for report generation before it's published.

Alpha testing is an internal acceptance testing phase conducted by the customer or end-users specifically at the developer's site or in a controlled environment. In contrast, beta testing is conducted by users in their own external or live environments.

ClearCase allows writing to elements that are checked out. This is the fundamental purpose of checkout in version control - to obtain a writable copy for modification. When you check out an element, you gain the ability to make changes, and those changes are tracked until you check the element back in.

In web application engineering, usability and performance (596823) are highlighted as the most critical aspects because users immediately abandon slow or confusing sites. While functionality is important for any software, usability and performance directly dictate web retention.

Localization testing (L10n testing) verifies that software adapts correctly to different languages and regional settings. It checks translation, character encoding, date/time formats, currency, and other locale-specific elements. Linguistic testing focuses specifically on language translation quality, not the broader adaptation across languages and regions.

Hybrid testing specifically combines top-down and bottom-up integration testing approaches. It uses stubs for lower modules while testing upper modules, and drivers for upper modules while testing lower modules, allowing parallel testing activities. Option A is too generic - many techniques combine methods, but 'hybrid' in this context refers to the specific top-down/bottom-up combination.

Test coverage analysis helps identify parts of the codebase that are not yet executed by the test suite, allowing developers to create additional test cases (596837) to fill those gaps. It is not a direct measure of quality (596839), nor is it limited only to listing exercised areas.

White box testing examines internal code structures, logic, and implementation. It is equivalently called glass box testing and clear box testing - all three terms refer to the same concept where the tester can 'see through' the code. The names are metaphors for transparent visibility into internal workings.

Content testing verifies textual and media content for accuracy, grammar, spelling, and clarity - similar to proofreading. It's widely used in web testing to ensure website content quality and correctness. It's also part of usability testing since poor content affects user experience. All three characteristics apply to content testing.

Decision coverage (also called branch coverage) requires that each decision point takes both true and false outcomes. It treats the entire boolean expression as a single decision - the expression as a whole must evaluate to both true and false, regardless of AND/OR operators within it. This differs from condition coverage which requires each sub-condition to be tested.

Class testing (unit testing for classes) requires a driver - test code that instantiates the class, calls its methods, and verifies results. Classes typically DO need instances of other classes (dependencies) to test interactions, and transitions between states should be tested. Option A correctly identifies that drivers are essential; B and C are incorrect.

Build Verification Test (BVT) and smoke test are often used interchangeably - both are quick tests run after each build to verify basic functionality and catch major errors that would make further testing pointless. BVT ensures the build is stable enough for detailed testing. Both A and B correctly describe aspects of BVT.