Software Testing and Quality Control

The Power-On Self-Test (POST) is a diagnostic routine that runs immediately after a computer is powered on. It tests hardware components like the video card (B), performs BIOS identification (C), and checks memory chips (D) to ensure basic functionality before booting. ScanDisk (A) is a Windows disk utility that runs optionally to check for file system errors and bad sectors - it is NOT part of the POST process.

Functional testing focuses on validating that the system behaves according to requirements by examining inputs and outputs without regard to internal implementation. It tests 'what' the system does rather than 'how' it does it internally. System testing is broader (tests entire system), Acceptance testing validates against user/business requirements, and White box testing specifically DOES look at internal code/logic - making it the opposite of what the question describes.

Functional testing focuses on validating that the system behaves according to requirements by examining inputs and outputs without regard to internal implementation. It tests 'what' the system does rather than 'how' it does it internally. System testing is broader (tests entire system), Acceptance testing validates against user/business requirements, and White box testing specifically DOES look at internal code/logic - making it the opposite of what the question describes. Note: This is a duplicate of question 134086.

Performance testing is the umbrella term that encompasses stress testing and load testing. Load testing checks system behavior under expected load, stress testing pushes beyond expected limits, and performance testing evaluates overall system responsiveness, stability, and scalability under various conditions. The other options are unrelated: Recovery testing checks system recovery after failures, Compatibility testing validates interoperability, and Comparison testing compares different versions or systems.

Sanity testing is a quick, cursory testing performed to determine if a new software version is stable enough to warrant further major testing efforts. It's a subset of regression testing focused on core functionality. If sanity testing fails (major bugs in critical features), the build is rejected without wasting time on comprehensive testing. Regression testing is broader (checks all functionality), Load testing checks performance under load, and Install/Uninstall testing validates installation processes.

Smoke testing (also called build verification testing) is performed to check if the application is stable enough for further major testing and is working properly without failing in critical areas. It's a preliminary testing to determine the basic 'smoke' doesn't come out of the application when run - indicating it's stable enough for deeper testing. Sanity testing is similar but narrower (tests specific fixes), Load testing checks performance, and Usability testing evaluates user experience.

Adhoc testing is informal testing done without formal planning or documentation. System integration testing is structured, stress testing checks system limits, and ADA testing relates to the Americans with Disabilities Act - not relevant.

Ad-hoc frameworks have three key characteristics: (A) Some data in datasheet but not truly data-driven, (B) Test steps embedded in Action scripts (high maintenance, low reuse), and (C) Reactive scripting for single issues. These describe poorly structured automation. Option D (None) is incorrect because A, B, and C all accurately describe ad-hoc framework traits.

Test Script Modularity framework emphasizes creating small, independent, reusable script modules (B) which improves maintainability (A) and uses abstraction layers to hide components (D). It does NOT heavily depend on datasheets for each execution - that describes a data-driven framework.

Data-driven testing has maintainability challenges (A) because each test case needs separate data files. Finding specific data files (B) is difficult as test suites grow. Error tracing (D) is harder during unattended runs, especially when recovery scenarios activate. Extensibility (C) isn't inherently worse - scripts can be as extensible as other frameworks.

Keyword Driven Frameworks make tests readable like manual test cases (A true). They don't require extensive tool training because testers only need to learn keywords, not the underlying tool (B false). The test plan can indeed be structured in spreadsheets with input and verification data (C true). Testers primarily learn keywords and the test plan format (D true). Options A, C, and D are correct.

A Hybrid Framework combines multiple framework types (B true). It includes core components like Data Driven Engine, Component Functions, and Support Libraries (C true). The App Map bridges the automation framework with the application being tested (D true). Option A is incorrect because hybrid frameworks are widely used, not limited.

Test Automation Frameworks are designed to be tool-independent in their architectural principles. A framework provides structure, methodology, and organization patterns that can work across different automation tools. While implementation may use specific tools, the framework concept itself is about methodology and best practices, not tool dependency.

The two methods are 'Convert Requirements to Tests' (batch conversion) and 'Generate a Test from Requirements' (individual test creation). Options B and D use 'Convert a Test' which is backward - you don't convert tests from requirements. Option C reverses the direction.

Within the Requirements module, traceability links are created between requirements (parent-child relationships). Test Cases, Tests, and Defects belong to other modules and are linked differently through cross-module traceability.