Software Static Testing & Review Process

• Static testing involves evaluating a work product or process quality by individuals.

Review Types

• Informal reviews lack a defined process, and a formally documented output.
• Formal reviews follow a defined process, with a formally documented output.

Review Process Activities

• Planning
• Initiating the review
• Individual review
• Issue communication and analysis
• Fixing and reporting

Review Planning Process

• Define the review's scope, estimate effort/timeframe, and identify review characteristics.
• Select participants and set entry/exit criteria, ensuring entry criteria are met.

Entry Criteria for Formal Review

• A preliminary check should not reveal major defects.
• The work product should include line numbers and be cleaned up.
• Stable and available references are needed.
• The work product author should be available to participate.

Initiating Reviews

• Distribute work products and explain scope/objectives.
• Address any questions.

Individual Review

• Review all or part of the work documents.
• Note potential defects, recommendations, and questions.

Issue Communication and Analysis

• Communicate potential defects, like in a review meeting, and analyze/assign them ownership and status.
• Evaluate/document quality characteristics and review findings against exit criteria to decide on review outcome.

Logging in a Review Meeting

• The logging process should be observed.
• Discussion items should be handled appropriately, and defects should be categorized by severity (Critical, Major, Minor).
• Aim for efficient logging and positive review outcomes.

Discussion Phase of a Review Meeting

• Discussion phase resolves items, addressing different review types, like formal reviews.
• The facilitator manages discussions and evaluates quality characteristics like Testability, Readability, and Understandability.

Fixing and Reporting in Review Meetings

• Create defect reports, fix and communicate defects, and record status updates.
• Gather review metrics and check exit criteria.

Fixing Defects & Author's Role

• The author evaluates and decides on necessary fixes.
• Document issues even if no fix is required, and track changes clearly, communicating defects if needed.

Updating Defect Status, Metrics & Acceptance

• Update defect status, with confirmation from the originator when the correct issue is fixed with the correct resolution.
• Facilitators ensure all issues are addressed.
• Key review metrics include defects found/fixed, defects per page, time per page, and total review effort.
• Ensure exit criteria compliance, followed by formal approval and a final decision.

Roles and Responsibilities

• Authors create the work product and fix defects.
• Management ensures reviews are planned, decides on execution, assigns staff, monitors costs, and executes decisions.

Facilitator

• Ensures effectiveness, mediates, and ensures success.

Review Leader

• Hold overall responsibility and makes decisions.

Reviewers

• Possess specific technical skills, identify defects, and represent different perspectives.

Scribe

• Collects potential defects and records new ones.

Review Types

• Include Informal review, Walkthrough, Technical review, and Inspection

Informal Review

• Detects potential defects and generates new ideas, lacking formal processes and formal meetings.
• It is a buddy check, and documentation is not required, using optional checklists, and is agile-friendly.

Walkthrough

• Improves the software product through idea exchange, with optional individual preparation.
• The author leads the meeting, and scribes, checklists, scenarios, and dry runs are optional.
• Defect logs exist, and formality varies.
• Author leads members, members ask questions.

Technical Review

• Gaining consensus, evaluating quality, and involves technical peers and experts.
• Individual preparation is needed, with optional meetings and checklists, and mandatory scribe and defect logs.
• Technical experts examine quality and identify discrepancies.

Inspection

• Prevents similar defects and motivates future work, using a defined process/roles.
• Involves required preparation, technical peers, a mandatory scribe, and a facilitator-led meeting.
• The author cannot lead, defect logs are kept, and metrics are collected.
• Uses defined team roles/measurements to improve the work product and software development process.

Review Types

• More than one review can be applied in different orders.
• No single type guarantees success, but finding defects is a common goal.

Review Techniques, Checklist-Based Reviews

• Checklist-based review uses a list of questions or required attributes to guide.
• Scenario-based reviews use specific scenarios to evaluate a product.

Checklist-Based Reviewing

• Uses a guided process with different checklists for reviewers, questions, and learning from past reviews.
• Maintain checklists by removing outdated questions, keeping them concise (one page), and prioritizing the important questions.
• This approach is systematic, effective, and flexible.

Scenario-Based Reviews

• Structured and uses Use Cases, and Dry Run approach for validation.
• It focuses on realistic usage and user needs, while checklist-based focuses on detecting specific defect types.
• Scenarios provide guidance but should not limit exploration, and should look for missing features, especially what users need.