Static Testing Flashcards
What is static testing?
Testing the software under test without executing the code.
Relies on manual examination (reviews) and automated analysis (static analysis) of the code or any other work product.
The main objectives are:
- Improving quality
- Detecting defects
- Preventing defects from being coded
Assessing quality characteristics:
- Readability
- Completeness
- Consistency
- Correctness
- Testability
Review techniques can be applied to ensure user stories are complete and understandable and include testable acceptance criteria .
What is Static Analysis?
Is the process of evaluating a component or system without executing it.
Often implemented in the CI framework.
It is typically used to :
- Detect specific code defects
- Evaluate maintainability
- Evaluate security
Typical defects found are:
- Referencing a variable with an undefined value
- Inconsistent interfaces between modules and components
- Improper declaration of variables
- Unreachable (dead) code that should be removed
- Missing or erroneous logic (infinite loops)
- Syntax violations of code and software models
- Highly complex functions
- Programming standards violations
- Security vulnerabilities
What is the difference between Static vs Dynamic Testing?
Static vs Dynamic testing
* Static testing finds defects in work products - Dynamic testing finds failures caused by defects when running the software
* Static testing is used to improve the consistency and internal quality - dynamic testing focuses on externally visible behavior
* Find different types of defects
* Static testing is possible on non-executable work products
* Both measure quality characteristics, BUT:
Static testing - quality characteristics not depending on executing code (code quality, maintainability,
etc)
* Dynamic testing - quality characteristics depending on executing code (performance efficiency, functionality, etc)
What are the typical defects found by static testing?
Typical defects that are easier and cheaper to find with static testing compared to dynamic testing:
* Requirement defects
* Design defects
* Coding defects
* Deviations from standards
* Incorrect interface specifications
* Security vulnerabilities
* Gaps or inaccuracies in test basis traceability or coverage
* Most maintainability defects can only be found by static testing
What are the keys benefits of Early and Frequent feedback ?
Build the right product through early communication of quality issues.
Focus on the right items by preventing misunderstandings in requirements and priorities.
What are the review process activities ?
Planning
Review Initiation
Individual Review
Communication Analysis
Fixing and reporting
What are the scopes of Review Process - Planning?
- Define the Purpose of the Review
What it means:
Clarify why the review is being conducted.
Examples:
A code review to detect performance bottlenecks in a new feature.
A requirements review to ensure the business requirements are correct and testable.
2. Identify What Is Being Reviewed
What it means:
Specify which work product(s) (or sections of it) will be in scope.
Examples:
A software requirements specification (focusing only on the user authentication section).
Source code modules responsible for database interactions.
3. Determine Quality Characteristics to Check
What it means:
Decide on which quality attributes or risk areas will be emphasized.
Examples:
Correctness of calculations in a complex financial application.
Testability of requirements to ensure they are clear and measurable.
Performance if there is a known history of slow response times.
4. Set Specific Focus Areas
What it means:
Pinpoint any areas of heightened importance or known risk.
Examples:
Performance hot spots in a large data-processing feature.
Security compliance in a payment gateway module.
Edge-case scenarios in an algorithm that handles date/time manipulations.
5. Define Entry and Exit Criteria
What it means:
Identify the conditions that must be met before a review starts (entry) and the conditions for completing the review (exit).
Entry Criteria Examples:
All chapters of a design document are drafted and approved by the author.
The code has passed basic compilation/unit tests.
Exit Criteria Examples:
No critical defects remain in the specifications.
Formal sign-off is obtained from all reviewers.
6. Identify Supporting Information and Standards
What it means:
List reference documents or standards that guide the review, especially in regulated or safety-critical industries.
Examples:
ISO 26262 for automotive software.
HIPAA compliance guidelines for healthcare systems.
7. Estimate Effort and Define a Realistic Time Frame
What it means:
Estimate how much time and effort reviewers will need and ensure the schedule is realistic.
Examples:
Three days per reviewer for a detailed architecture review.
A quick half-day review session for a short user interface specification.
8. Select Participants and Assign Roles
What it means:
Determine who will be involved (e.g., moderator, author, reviewers) and clarify each person’s responsibilities.
Examples:
Moderator: Schedules the review meeting and oversees communication.
Author: Provides the draft work product and answers questions.
Reviewers: Examine the document or code and log issues.
Recorder (Scribe): Documents all anomalies, decisions, and follow-up actions.
Putting It All Together
Once the scope is set—covering the purpose, work product, focus areas, entry/exit criteria, supporting references, estimates, and roles—the review moves on to initiation, individual review, communication/analysis, and finally fixing/reporting.
What are the goals of Review Initiation?
Confirm Entry Criteria: Check whether conditions to begin (e.g., all documents ready) are met.
Distribute Materials: Provide work products, checklists, templates, and any related documents to reviewers.
Roles & Responsibilities: Ensure all participants know their role (moderator, author, reviewers, recorder).
Kick-off Meeting: Introduce the review scope, objectives, and instructions for logging issues.
What are the goals of Individual Review?
Examine Work Product: Each reviewer independently reads and assesses the assigned sections.
Identify Issues: Note anomalies, questions, and recommendations (e.g., via checklist-based or scenario-based techniques).
Log Findings: Record all defects or improvement suggestions for later discussion.
What are the goals of Communication & Analysis?
Discuss Logged Issues: Participants collectively review each anomaly’s severity, ownership, and next actions.
Decide on Status: Confirm which findings need fixes or further discussion, and whether any additional reviews are needed.
Check Exit Criteria: Assess if the review objectives have been met or if further work is required.
What are the goals of Fixing & Reporting?
Create Defect Reports: Document all issues that require changes; assign them to the appropriate person (often the author).
Implement Fixes: The author (or designated team member) updates the work product to address identified defects.
Verify & Close: Confirm all exit criteria are satisfied and no critical issues remain.
Final Report: Communicate review results, decisions, and next steps to stakeholders.
What are the 5 main types of Review Techniques?
- Ad Hoc
What It Is: An informal method where reviewers freely examine the material (code, documents) with no strict structure or script.
How It Works: Testers rely on their experience and intuition to spot issues. There are no formal checklists or detailed procedures—they “just look around” for potential defects. - Checklist-Based
What It Is: Reviewers use a predefined list of items or criteria to systematically check.
How It Works: Each checklist item represents a potential defect source or quality requirement (e.g., coding standards, compliance rules). Reviewers ensure each item is addressed, thereby minimizing overlooked areas. - Scenarios and Dry Runs
What It Is: Reviewers mentally simulate how the system or process would operate under specific scenarios, often walking through the code or documentation step by step.
How It Works: They perform a “dry run,” picturing how users or the system flow would behave, verifying logic and identifying missteps or missing details before actual execution. - Role-Based
What It Is: Reviewers adopt a specific role (e.g., end user, developer, business analyst) to assess the material from that perspective.
How It Works: Each role focuses on needs or concerns typical to that viewpoint. For example, an “end user” might check for usability or clarity, a “developer” might check for maintainability or consistency in code structure, etc. - Perspective-Based
What It Is: Similar to role-based, but each reviewer chooses a unique perspective or stakeholder viewpoint (e.g., security expert, performance specialist).
How It Works: By adopting these varied perspectives, reviewers collectively uncover different types of issues. Each perspective systematically seeks problems relevant to its domain (security, performance, legal, etc.).
What are some success factors for reviews?
- Clear, predefined objectives
- Measurable exit criteria
- The review is conducted in an atmosphere of trust; the outcome will not be used for the evaluation of the participants
- Review types are applied that are suitable to achieve the objectives
- Large work products are written and reviewed in small chunks
- Feedback is given to the participants so the process and their activities can be improved
- Participants have adequate time to prepare for the review
- Reviews are made part of the organizational culture to promote learning and improvement
- Management supports the review process
- Adequate training is given; especially for the more formal review types
- Facilitate meetings
