Software Testing, QA and Agile Methodologies

Agile is a project management methodology emphasizing iterative development, adaptive planning, and rapid delivery. It's not about people management (HR), pure process management, or product design aesthetics.

Extreme Programming (XP) is a software development technique/framework, not a programming language or related to Windows XP. It emphasizes pair programming, testing, and frequent releases.

Scrum defines a sprint as a maximum 30-day (1 calendar month) iteration. Modern practice uses shorter 2-week sprints, but the formal Scrum Guide caps it at 30 days.

XP reduces cost of change through multiple short development cycles (typically 1-2 weeks), enabling frequent feedback and adaptation. Long cycles increase change cost, and single cycles eliminate iterative benefits.

XP includes all three practices: pair programming (continuous review), extensive code review, and comprehensive unit testing. These together ensure code quality and rapid feedback.

Agile components are Scope (define what to build), Define (plan details), Develop (build), Evaluate (review/adapt). The D-D-D-E pattern captures the iterative cycle of defining, executing, and evaluating work.

Scrum, XP, and Lean Development are all Agile methodology types. Scrum uses sprints and roles, XP emphasizes engineering practices, and Lean focuses on eliminating waste and delivering value.

ISO/IEC 12119 is the standard titled 'Information technology - Software packages - Quality requirements and testing'. It specifically defines quality requirements for software packages. The other standards serve different purposes: 14143 covers software measurement (function point analysis), 15271 addresses IT service management, 15504 is process assessment (SPICE), 12207 covers software life cycle processes, and 15939 covers measurement processes.

ISO/IEC 12207 'Systems and software engineering - Software life cycle processes' is the standard that defines software life cycle processes including acquisition, supply, development, operation, maintenance, and disposal. This matches the question precisely. 12119 covers software package quality requirements, 14143 is about function point analysis, 15271 relates to IT service management, 15504 covers process capability assessment, and 15939 addresses measurement processes.

ISO/IEC 15271 is the official guide and companion document for implementing the software life cycle processes standard, ISO/IEC 12207. Other options represent unrelated standards.

ISO/IEC 15504 is the international standard for software process assessment, commonly known as SPICE (Software Process Improvement and Capability Determination). Other options represent different standards.

ISO/IEC 15939 'Systems and software engineering - Measurement process' is the standard specifically defining the measurement process for systems and software. It establishes the measurement process as a support process in the software life cycle. 14143 covers function point analysis (a specific measurement technique), 12119 covers software package quality, 15504 covers process assessment (SPICE), 12207 defines life cycle processes, and 15271 relates to IT service management.

ISO/IEC 14143 'Information technology - Software measurement - Functional size measurement' is the international standard for software measurement, specifically focusing on function point analysis (FPA). It provides the framework for measuring software functional size. 12119 covers software package quality requirements, 15504 covers process assessment, 15271 relates to IT service management, 12207 defines life cycle processes, and 15939 covers the measurement process (not measurement itself).

Bottom-up integration starts with terminal or leaf modules and progressively integrates higher-level modules. Top-down integration starts from the topmost module. Terminal modules have no sub-modules to call, making them the natural starting point for bottom-up testing.

Exit criteria define the specific conditions, coverage targets, and quality thresholds that must be met to determine when a test level or testing phase has been completed.

Test reporting should focus on both technical details (boundary conditions, state machines, load generators) AND business impact (risk management, reputation, revenue impact from test escapes). Option C correctly combines both aspects.

Metrics collected during and at the end of a test level are used to assess the adequacy of the objectives, the suitability of the test approach, and the overall effectiveness of the testing process against its goals.

Testing and quality assurance costs are LESS than external failure costs. Catching defects internally (through testing) is much cheaper than releasing defective software, which causes customer support, warranty claims, reputation damage, and lost sales. This is the core economic argument for investing in QA.

Black box testing focuses on inputs and outputs without knowledge of internal implementation - this is the definition of functional testing. Structural testing (glass box) requires code knowledge, performance testing measures speed/scalability, and requirements testing validates against specifications (though all functional tests ultimately trace to requirements).

To answer this question, the user needs to have a basic understanding of static analysis and its limitations.

Static analysis is a technique for analyzing software without executing it. The technique involves examining the program's source code and/or binary code to identify potential errors, security vulnerabilities, and other issues.

Static analysis can help find many types of issues in software, but it also has limitations. Here are the explanations for each option:

A. The use of a variable before it has been defined:
Static analysis can detect the use of a variable before it has been defined. This is because static analysis examines the code to identify potential issues before the code is executed.

B. Unreachable (“dead”) code:
Static analysis can detect unreachable ("dead") code. This is because it examines the code to identify code paths that will never be executed.

C. Memory leaks:
Static analysis can detect potential memory leaks in some cases, but it cannot detect all memory leaks. This is because some memory leaks are caused by runtime behavior that cannot be detected through static analysis.

D. Array bound violations:
Static analysis can detect potential array bound violations, but it cannot always detect all violations. This is because some array bounds are determined at runtime and can only be detected through dynamic analysis.

Therefore, the correct answer is:

The Answer is: C. Memory leaks.