Static Testing practice questions

Executing the static analysis tools on the source code.

Why it fails: Executing static analysis tools is an activity that takes place during the preparation phase or as a separate static testing task. It does not occur during the initiation phase, which is focused on planning and organizing the human-led formal review process.

Conducting the review meeting to discuss identified defects.

Why it fails: The review meeting itself is a separate phase that follows initiation and preparation. Initiation is the logistical setup, while the meeting is the actual execution where defects are discussed and recorded. They are distinct phases in the formal review lifecycle.

Replacement of all human-led formal review activities.

Why it fails: Static analysis is a supplement to, not a replacement for, human reviews. Tools are excellent at finding technical defects but lack the context to understand business requirements or architectural intent, which human reviewers are best equipped to analyze during a formal review process.

Detection of complex architectural design flaws in high-level diagrams.

Why it fails: Static analysis tools generally operate on source code, not on design diagrams or conceptual models. While they are great for code-level issues, they cannot understand high-level architectural intent, which requires human interpretation and critical thinking during a collaborative review session.

The principle of maintaining individual objectivity.

Why it fails: Objectivity is maintained by assessing the document based on standards and requirements rather than personal bias. Waiting to disclose a defect does not inherently compromise objectivity; rather, it delays the visibility of the defect, which impacts the efficiency of the review process and the project timeline.

The principle of formal review documentation.

Why it fails: Documentation requirements typically dictate that defects must be logged during the process. While not logging it immediately is a procedural failure, the core principle being violated here is the temporal aspect of defect discovery and resolution, which is critical for reducing total development costs.

The principle of defining clear entry criteria.

Why it fails: Entry criteria define the conditions required to start a review. While missing defects during preparation might suggest poor entry criteria, the specific act of withholding a found defect is a behavioral issue related to the efficiency of the review process rather than the initial entry conditions.

Formal Inspection

Why it fails: Formal inspections are highly structured, requiring defined roles, metrics collection, and formal entry and exit criteria. They are often too resource-intensive and slow for experienced teams that prioritize speed and agility over the rigorous documentation and formal process control inherent to this specific testing type.

Technical Review

Why it fails: Technical reviews are peer-driven sessions focusing on technical content and logic. While effective for quality, they are generally more structured than walkthroughs. For a team seeking the lowest possible overhead while still maintaining quality, a walkthrough offers a more streamlined approach to defect identification and peer alignment.

Audit

Why it fails: Audits are independent evaluations performed by external personnel to verify compliance with standards. They are not intended for defect finding in the traditional sense and carry significant overhead due to their regulatory or compliance nature, making them entirely inappropriate for routine, quick technical document defect identification.

Eliminates the need for regression testing entirely.

Why it fails: Static testing cannot account for changes in behavior during code updates or system integration. Regression testing remains necessary to ensure that new changes do not break existing functionality. Relying solely on static testing would lead to undetected regressions that occur only during execution and interaction with other components.

Ensures the software is 100% bug-free before deployment.

Why it fails: No testing method, including static testing, can guarantee a completely bug-free system. Software is complex, and dynamic interactions often reveal issues that static analysis cannot see. Static testing is an essential tool for risk mitigation, but it is not a silver bullet for achieving absolute perfection.

Checklist-based reviewing

Why it fails: Checklist-based reviewing uses a predefined list of questions to guide reviewers. While it improves consistency, it may not provide the deep, systematic coverage needed for a large, complex document. The checklist might not address all intricate business rules, and reviewers could still overlook subtle defects that require detailed, line-by-line analysis.

Perspective-based reading

Why it fails: Perspective-based reading assigns each reviewer a specific stakeholder viewpoint (e.g., tester, designer, end user). While this can uncover different types of defects, it may not guarantee complete coverage of all requirements. For a document with many complex business rules, a more structured, line-by-line technique is typically more effective for thorough defect detection.

Ad hoc reviewing

Why it fails: Ad hoc reviewing is an informal technique where reviewers receive little or no guidance and examine the document in an unstructured way. For a 60-page complex specification, this approach would likely miss many defects and provide inconsistent coverage. It is not suitable for a formal review requiring thoroughness and coordination among multiple reviewers.

The testing team executes a test script to identify a logic error in the billing module.

Why it fails: Executing test scripts is a form of dynamic testing, which occurs after the code is built. While this identifies the logic error, it does not represent the unique advantage of static testing, which is the ability to find defects without executing the code in a runtime environment.

Developers perform unit tests to verify that the API endpoints handle null inputs correctly.

Why it fails: Unit testing is a dynamic testing technique that requires code execution to verify behavior. Although beneficial for identifying defects, it does not demonstrate the static testing advantage of identifying issues in requirements or designs before any code is ever written or compiled for execution.

A performance tool monitors system latency to ensure compliance with non-functional requirements.

Why it fails: Performance monitoring is a dynamic technique that relies on system execution under load. This is useful for validating the system's runtime characteristics but does not provide the preventive benefits of static testing, which focuses on reviewing project artifacts prior to the existence of an executable system.

The Moderator

Why it fails: The moderator leads the review meeting and manages the process to ensure objectives are met. While they oversee the session, their primary focus is on team dynamics and progress rather than manually documenting every defect, which is the specific responsibility assigned to the scribe role.

The Author

Why it fails: The author creates the work product being reviewed. They participate to answer questions and understand feedback but do not document defects to avoid bias and ensure they can focus on processing the feedback provided by the reviewers, which is handled by the scribe.

The Reviewer

Why it fails: Reviewers focus on evaluating the work product, identifying defects, and suggesting improvements based on their expertise. They contribute their technical insights to the discussion but do not take on the responsibility of documenting the findings, as this would distract them from their primary objective of critical analysis.

Formal reviews must always include the participation of a test manager.

Why it fails: Participation requirements vary based on the context and the nature of the work product. While a test manager may participate in some reviews, they are not a mandatory role for all formal reviews, as the composition depends on the expertise needed for the specific document.

Formal reviews always require the use of automated static analysis tools.

Why it fails: Static analysis tools and formal reviews are separate techniques. While tools can assist in the review process, they are not a mandatory component of a formal review, which relies primarily on human expertise and structured communication to identify defects in the artifact under consideration.

Formal reviews are generally faster and cheaper than informal reviews.

Why it fails: Formal reviews are more intensive than informal reviews, often requiring significant time for preparation and meeting coordination. While they provide higher quality assurance and traceability, they are typically more costly and time-consuming than informal peer-to-peer reviews, which are intended for rapid feedback.

To determine which reviewers are qualified to participate in the session.

Why it fails: While selecting the right reviewers is important for success, entry criteria focus on the readiness of the artifact itself. Ensuring the document meets basic standards, such as being proofread, is the primary purpose of entry criteria, rather than selecting the participants for the meeting.

To provide a checklist that the author can use to fix defects found during the review.

Why it fails: Entry criteria are evaluated before the review begins, not during or after. A checklist for fixing defects is a part of the rework phase, which occurs after the review meeting and the documentation of findings, rather than being a condition for starting the review.

To track the number of defects found by each individual reviewer during the meeting.

Why it fails: Tracking defect counts per reviewer is a metric used for process improvement or evaluation of the review's effectiveness. This activity happens during or after the meeting, not as a precondition to starting the review, which is the function of the entry criteria.

To allow the author to defend their design decisions against reviewer criticisms.

Why it fails: Defensiveness can destroy the collaborative nature of a review. The goal is to find defects, not to engage in debates. If the author feels the need to defend their work, it usually indicates a failure in the review culture rather than a productive outcome.

To assign blame to the author for any defects discovered during the meeting.

Why it fails: Blame-oriented cultures are detrimental to the effectiveness of static testing. The focus should always be on the quality of the product and the improvement of the process, not on identifying an individual to hold accountable for defects found during the review.

To ensure the author can rewrite the code or document during the meeting.

Why it fails: Rework is a separate phase that occurs after the review meeting. The meeting is intended for discovery and documentation of defects, not for real-time editing of the documents, which would disrupt the flow and prevent a thorough examination of the work product.

A structured inspection with a designated moderator and scribe.

Why it fails: This is the definition of a formal inspection, which is the most rigorous form of review. It requires a predefined process, specific roles, and formal documentation of results, which is the exact opposite of an informal, ad-hoc review process.

A technical review conducted by a team with a predefined checklist.

Why it fails: Using a checklist and conducting a technical review implies a degree of formality and structure. While not as rigorous as an inspection, it is still a structured activity, which differentiates it from an informal review that relies on casual, unscripted peer interaction.

A formal walkthrough where the author explains the design to a group.

Why it fails: A walkthrough is a formal, planned activity where the author leads participants through the document. It has a specific purpose and structure, distinguishing it from an informal review, which has no such prescribed requirements or planning phases.

To verify that the reviewers have understood the author's intent.

Why it fails: Verification of reviewer understanding happens during the review meeting itself, through discussion and clarification. Rework is strictly about the author applying changes to the artifact based on the documented findings, not about checking the reviewers' comprehension of the original document.

To conduct a final assessment of the review's overall cost and time.

Why it fails: Analyzing the review's cost and time is a management activity that occurs after the review process is completed. It is not part of the rework phase, which is focused on technical corrections to the work product itself by the author.

To finalize the project plan based on the findings.

Why it fails: Rework is focused on the specific artifact under review, not the overall project plan. While findings might necessitate schedule adjustments, the primary goal of the rework phase is the technical improvement of the artifact, not administrative planning or project management.

Only at the end of the project to ensure the final delivery is clean.

Why it fails: Performing static analysis only at the end is ineffective and expensive. By that time, fixing defects is much more costly because they are deeply embedded in the system. Early identification is a fundamental principle of static testing and defect prevention.

Only after the system has passed all functional testing phases.

Why it fails: Static analysis should be performed long before functional testing begins. Relying on it after functional testing ignores the benefits of early defect discovery and means that the codebase might have been unnecessarily flawed during the testing phase, complicating the overall verification process.

Only when the code is deployed to the production environment.

Why it fails: Analyzing code in production is too late. Static analysis is a development-time activity meant to prevent defects from ever reaching production. Applying it at the deployment stage is counter-productive because the cost of fixing defects in production is significantly higher than during the development phase.

The review must be conducted by external auditors to ensure objectivity.

Why it fails: External auditors are not a requirement for formal reviews. While they might provide an objective perspective, the team's internal expertise is usually more valuable for understanding the product's context and logic, which is crucial for identifying complex defects effectively.

The review must result in at least one defect per page of documentation.

Why it fails: Measuring success by a predefined number of defects per page is a dangerous metric that encourages gaming the system. If the document is high-quality, it may have few defects; mandating a high defect count leads to trivial issues being flagged, which wastes time.

The author must be excluded from the meeting to prevent bias.

Why it fails: Excluding the author often hinders the review process because they are the best person to explain the intent of the documentation. A well-functioning team can handle the author's presence without bias, and their input is usually necessary for efficient clarification of design points.

A walkthrough is more formal than an inspection.

Why it fails: An inspection is actually the most formal of the review processes, while a walkthrough is considered less formal. The inspection process is strictly documented and requires specific, separate roles, whereas a walkthrough relies more on the author's presentation to guide the participants through the work.

A walkthrough requires a moderator and a scribe, but an inspection does not.

Why it fails: The roles of moderator and scribe are characteristic of formal inspections. Walkthroughs are less prescriptive regarding roles, so this statement is factually incorrect. Inspections are the ones that demand these distinct, defined roles to manage the process and ensure that defects are recorded accurately.

Inspections are never planned in advance, whereas walkthroughs are.

Why it fails: Both inspections and walkthroughs require planning, but the nature of the planning is different. Inspections require meticulous preparation for the meeting itself, whereas walkthroughs focus more on the author's preparation for their presentation. Neither is an unplanned activity in a professional software development environment.

The moderator acts as the lead author to explain complex sections.

Why it fails: The moderator must be a neutral party and explicitly should not be the author. If the author acts as the moderator, they may become defensive or overly influential, which undermines the objectivity of the inspection and prevents a truly impartial assessment of the work product's quality.

The moderator is responsible for fixing all identified defects.

Why it fails: Fixing defects is the exclusive responsibility of the author. The moderator's role is process-oriented, focusing on facilitation and documentation of findings. Assigning repair tasks to the moderator would conflict with their neutral, process-monitoring role, thereby blurring the lines of responsibility during the formal inspection lifecycle.

The moderator must have the final sign-off authority for the project.

Why it fails: The moderator does not hold authority over the project's success or final sign-off. Their influence is limited to the inspection process itself. Management or the project lead typically handles final sign-off, as their role is focused on project outcomes rather than the specific quality of the document.

The 'max_attempts' value is set too high for a secure system.

Why it fails: Setting 'max_attempts' to three is generally considered a standard security practice to prevent brute-force attacks. While security requirements vary, flagging this as a critical defect would be subjective without specific project constraints, making it a less obvious error than the encryption setting being completely disabled.

The 'timeout_seconds' value lacks a unit suffix.

Why it fails: The key name 'timeout_seconds' already explicitly defines the unit. Suggesting this as a defect is pedantic and does not address the actual functional or security risks inherent in the policy. A reviewer should focus on high-impact issues rather than syntax preferences that are clearly communicated by the naming convention.

The 'validate_user' flag should be set to 'false' for performance.

Why it fails: Setting user validation to false would remove an essential security check. Recommending this would introduce a vulnerability rather than resolve one. Static testing is intended to improve security and quality; therefore, suggesting a change that compromises system integrity would be contrary to the purpose of the review process.

Static analysis is more accurate than dynamic testing for finding run-time logic errors.

Why it fails: Static analysis cannot predict all runtime logic errors because it does not execute the code with real data. Dynamic testing is superior for identifying runtime failures, such as memory leaks or race conditions, which only manifest under specific operational conditions and state changes during actual program execution.

Dynamic testing is cheaper to perform because it requires less setup.

Why it fails: Dynamic testing often requires significant setup, including test environments, data preparation, and infrastructure. Conversely, static analysis is usually automated and requires minimal setup once integrated into the development pipeline. Therefore, static analysis is typically less expensive to execute continuously compared to the manual setup required for dynamic tests.

Static analysis replaces the need for any form of functional testing.

Why it fails: Static analysis cannot verify whether the software meets the user's requirements or functional needs. It only checks for adherence to coding standards and structural integrity. Functional testing is still mandatory to confirm that the software actually performs the tasks for which it was designed and built.

Assume the most logical implementation and document that in the test plan.

Why it fails: Assuming an implementation path creates a risk of mismatch between the developer's logic and the user's requirements. Testers should never assume behavior; instead, they must ensure requirements are clarified. If the requirement is ambiguous, the correct action is to flag it for the author to resolve immediately.

Ignore the ambiguity until the dynamic testing phase identifies it.

Why it fails: Postponing the identification of an ambiguity until dynamic testing is inefficient. By that point, code has already been written and potentially integrated. If the requirement was wrong, the cost to change it is significantly higher than simply clarifying the document during the review phase of development.

Ask the developer to decide how the error message should behave.

Why it fails: Developers are not the primary authority on requirement intent. While they may have technical input, the product owner or business analyst should clarify requirements. Leaving this decision to the developer ignores the business perspective and risks building functionality that does not align with user needs or stakeholder expectations.