Software Testing and Risk-Based Testing Fundamentals

Smart Identification relies on an object repository to learn object properties and fallback behaviors. When using descriptive programming (DP), there is no object repository, so Smart Identification cannot be applied as it has no learned properties or ordinal identifiers to reference. DP requires complete, explicit property descriptions.

Faults discovered later require rework across more artifacts: code that depends on the faulty logic, tests that assumed incorrect behavior, documentation describing the wrong behavior, and potentially deployed systems. This cascade increases cost exponentially. Option A is a specific case, not the general principle.

Black-box testing focuses solely on inputs and outputs without examining the internal code structure. Therefore, a black-box tester does not need to understand or read the source code. Distractors describe valid characteristics like analyzing requirements or finding system weaknesses.

To answer this question, the user needs to have knowledge about testware, which refers to the artifacts developed during the testing process, including test cases and test datasets.

Now, let's go through each option and explain why it is right or wrong:

A. needs configuration management just like requirements, design and code: This option is correct. Testware, just like other software artifacts, should be managed through configuration management to keep track of changes, versions, and releases.

B. should be newly constructed for each new version of the software: This option is incorrect. Testware should be reused as much as possible to save time and resources. However, it should be updated and modified as necessary for each new version of the software.

C. is needed only until the software is released into production or use: This option is incorrect. Testware is needed throughout the software development lifecycle, including after the software is released, for maintenance and future updates.

D. does not need to be documented and commented, as it does not form part of the released: This option is incorrect. Testware, like any other software artifact, should be documented and commented to explain its purpose, functionality, and usage.

Therefore, the correct answer is:

The Answer is: A

To understand this question, the user needs to know what an incident logging system is and its purpose. An incident logging system is a tool used to record and track defects or issues that occur during the software development lifecycle. It provides a centralized location to manage and resolve incidents, allowing teams to identify and address problems more efficiently.

Now, let's go through each option and explain why it is right or wrong:

A) only records defects: This option is incorrect. While an incident logging system is primarily used to record and track defects, it can also be used to capture other issues, such as requirements gaps, design flaws, and usability problems.

B) is of limited value: This option is incorrect. An incident logging system is a critical tool for managing defects and issues during the software development lifecycle. It provides value by allowing teams to capture, track, and resolve incidents more effectively, which can improve software quality and reduce development costs.

C) is a valuable source of project information during testing if it contains all incidents: This option is correct. An incident logging system that captures all incidents can provide valuable insights into the quality of the software being tested. By analyzing the types and frequency of incidents, teams can identify trends and areas that require further attention. This information can be used to improve the testing process, highlight areas for improvement, and make informed decisions about the software's readiness for release.

D) should be used only by the test team: This option is incorrect. While the test team is responsible for managing the incident logging system, other stakeholders, such as developers, project managers, and business analysts, can benefit from the information it provides. By sharing incident reports and metrics, teams can collaborate more effectively and make informed decisions about the software's quality and readiness for release.

The Answer is: C

Higher-quality development methods (like code reviews, static analysis, test-driven development) prevent defects from entering the code in the first place. Fewer defects mean less time spent finding, reporting, and retesting bugs during formal testing phases. Prevention is cheaper than detection.

Risk level determines the intensity of testing. Higher risk areas require more intensive and thorough testing to ensure quality and reliability. Risk-based testing allocates effort based on potential impact.

Inherent risk is the assessment of risk without considering controls or mitigations. It represents the raw, natural risk level in a system or process before any security measures or controls are applied.

Risk-based testing prioritizes testing efforts based on the level of risk associated with each feature or requirement. Higher-risk areas require more thorough and earlier testing to mitigate potential failures. Option A correctly states that higher risk items receive earlier test coverage, which is the fundamental principle of risk-based testing.

Risk Control is the process of implementing decisions and protective measures to reduce risks to acceptable levels or maintain them within specified limits. It follows risk identification and analysis phases. Option C correctly identifies Risk Control as the process focused on implementing risk mitigation measures.

In Risk-Based Testing (RBT), risk identification is an ongoing process that occurs throughout the lifecycle. It is defined in the initial test strategy and continuously performed on an ad-hoc basis as new risks emerge. Distractors stating it occurs only once are incorrect.

Business Analysts are primarily responsible for identifying and documenting the business impact of requirements or business processes. They work with stakeholders to understand business value and consequences. Option A correctly assigns this responsibility to Business Analysts, who bridge business needs and technical solutions.

Solution Designers and IT Architects are primarily responsible for identifying the probability of failure for requirements or business processes. They assess technical feasibility, system constraints, and implementation complexity. Option B correctly assigns this technical risk assessment to Solution Designers/IT Architects who understand technical challenges.

Risk level is calculated by multiplying the impact of failure by the probability of failure. This formula Risk = Impact × Probability is standard in risk assessment methodologies. Option A correctly states this calculation, while other options incorrectly multiply impact with unrelated factors like Solution, Requirement, or Test level.

Risk reassessment at consecutive phases doesn't always trigger estimate revisions. Estimates are revised only when reassessment reveals significant new information that materially changes the risk profile. Option C correctly indicates that estimate revisions occur sometimes, not always or never, depending on what the reassessment uncovers.

Before conducting risk assessment, requirements or reference documents should be at least relatively stable and close to baseline. While perfect baselining isn't mandatory, documents need sufficient stability to make risk assessment meaningful. Option B correctly reflects this practical requirement - documents need near-baseline stability rather than formal baselining or being in draft state.

Maintenance Testing uses two main methodologies: Breadth Testing (testing all affected areas broadly) and Depth Testing (deep testing of specific changed areas). Options b, c, and d describe other testing types but not the specific methodologies for maintenance testing. Option A correctly identifies the two primary approaches used when maintaining existing software.

Formal reviews require participants to prepare materials in advance, making statement ii false. The review is led by a trained moderator who is not the author (i true), follows a formal process for follow-up actions (iii true), and its primary goal is defect detection (iv true).

White box testing evaluates the internal structure and code of software, which is why it is called structural testing. Error guessing and experience-based testing are black-box, non-structural techniques.

Security testing focuses on uncovering vulnerabilities in the system that could be exploited by malicious actors, including viruses and other external threats. Recovery testing verifies system restoration after failures, performance testing measures responsiveness under load, and functionality testing checks if features meet requirements without addressing security concerns.