Please enable JavaScript.

Coggle requires JavaScript to display documents.

Review Process, static testing - Coggle Diagram

- - - - not have formal documented output
      - not follow a defined process
    - - characterized (đặc trưng) by team participation
      - document results of the review
      - document procedure for conducting the review
  - - - identify review characteristic: review type with role, activity, checklist
      - select the people to participate in the review & allocate role
      - estimate effort & timeframe
      - define the entry & exit criteria for more formal review type (inspection - kt)
      - define scope include purpose of review, what documents/part of documents to review, quality characteristics to be evaluated
      - check entry criteria are met or not (for more formal review type)
    - - explain the scope, objective, process, roles, work product to participant
      - answer question that participant have about the review
      - distribute work product (physical or by electronic means),
        other material (issue log form, checklist, related work product)
    - - analyze potential defect, assign ownership & status to them
      - evaluate & document quality characteristic
      - communicate identified potential defect (in a review meeting)
      - evaluate the review finding against the exit criteria to make a review decision (reject, major changes needed, accept, possibly with minor changes)
    - - review all/part of work product
      - note potential defect, recommendation, question
    - - create defect report for those findings that require changes to a work product
      - fix defect found (typically done by the author) in the work product reviewed
      - record updated status of defect (in formal review), potentially including the agreement of the comment originator
      - gather metrics (for more formal review type)
      - check that exit criteria are met or not (for formal review type)
      - accept the work product when the exit criteria are reached
  - - - mediate, if necessary, btw the various points of view (trung gian)
      - is often the person upon whom the success of the review depends
      - ensure effective running ò review meetings
    - - task overall responsibility for the review
      - decide who will involved & organize when & where it will take place (diễn ra)
    - - decide on the execution of review
      - assign staff, budget, time
      - monitor ongoing cost-effectiveness
      - execute control decision in the event of inadequate outcome
      - is responsible for review planning
    - - identify potential defect in work product under review
      - represent different perspective - quan điểm (tester, developer, user, operator, business analyst, usability expert)
      - subject matter expert, person working on prj, stakeholder with an interest in the work product, individual with specific technical/business background
    - - create the work product under review
      - fix defect in work product under review (if necessary)
    - - collate potential defects found during the individual review activity
        đối chiếu
      - record new potential defect, open points, decision from the review meeting
  - - - factor of choosing review types
        
        available resource
        
        product type & risk
        
        business domain
        
        company culture
        
        project
        
        other selection criteria
    - - walkthrough
        
        main purpose: find defect, improve sw product,
        consider alternative implementation,
        evaluate conformance (sự phù hợp)
        to standard & specification
        
        vary in practice from quite informal to very formal
        
        possible additional purpose: exchange idea about technique or style variation, train of participant, achieve consensus (sự đồng thuận)
        
        scribe is mandatory
        
        individual preparation before the review meeting is optional
        
        review meeting is led by the author of the work product
        
        use of checklist is optional
        
        take the form of scenarios (kịch bản), dry runs, simulation
        
        potential defect log & review report are produced
      - technical review
        
        main purpose: gain consensus, detect potential defect
        
        possible additional purpose: evaluate quality & build confidence in work product, generate new ideas, motivate & enable authors to improve future work product, consider alternative implementation
        
        reviewer should be technical peers of author, technical expert in the same or other discipline (lĩnh vực)
        
        Potential defect logs and review reports are produced
        
        individual preparation before the review meeting is required
        
        Review meeting is optional, ideally led by
        a trained facilitator (typically not the author) - ng dieu hanh
        
        Scribe is mandatory, ideally not the author
        
        Use of checklists is optional
      - informal review (buddy check,
        pairing, pair review)
        
        main purpose: detect potential defect
        
        possible additional purpose: generate new idea/solution,
        quickly solve minor problem
        
        not based on a formal (documented) process
        
        not involve a review meeting
        
        be performed by a colleague of the author
        (buddy check) or by more people
        
        result is documented
        
        vary in usefulness depending on the reviewer
        
        use of checklist is optional
        
        very commonly used in Agile development
      - inspective (kt)
        
        Main purposes: detect potential defects, evaluate quality,
        building confidence in work product,
        prevent future similar defects through author learning
        &root cause analysis
        
        Reviewers are either peers of the author or experts in other disciplines that are relevant to the work product
        
        Possible further purposes: motivate & enable authors to improve future work products & software development process, achieve consensus
        
        Follows a defined process with formal documented outputs, based on rules and checklists
        
        Uses clearly defined roles
        
        Individual preparation before the review meeting is required
        
        Specified entry and exit criteria are used
        
        Scribe is mandatory
        
        Review meeting is led by a trained facilitator (not the author)
        
        Author cannot act as the review leader, reader, or scribe
        
        Potential defect logs and review report are produced
        
        Metrics are collected and used to improve the entire software development process, including the inspection process
  - - - Participants dedicate adequate time and attention to detail (danh)
      - Reviews are conducted on small chunks, so that reviewers do not lose concentration during individual review and/or the review meeting
      - Adequate training is provided, especially for more formal review types such as inspections
      - A culture of learning and process improvement is promoted (thuc day)
      - Defects found are acknowledged, appreciated, and handled objectively
      - The meeting is well-managed -> participants consider it a valuable use of their time
      - The review is conducted in an atmosphere of trust; the outcome will not be used for the evaluation of the participants
      - Participants avoid body language and behaviors that might indicate boredom, exasperation, or hostility to other participants (buc tuc, thu dich)
      - The right people are involved to meet the review objectives
      - Testers are seen as valued reviewers who contribute to the review and learn about the work product, which enables them to prepare more effective tests, and to prepare those tests earlier
    - - document -> provide quality control to author early
        & feedback on defect
      - participant have adequate (du) time to prepare
      - checklist -> address main risks
      - Reviews are scheduled with adequate notice
      - review technique: suitable for defect identification
      - Management supports the review process (e.g., by incorporating adequate time for review activities in project schedules)
      - review type -> achieve objective & suitable to type & level of work product & participant
      - Reviews are integrated in the company's quality and/or test policies.
      - clear objective
- - - - typical defect is easier &
        cheaper to find & fix on static testing
        
        gaps of inaccuracies in test basis traceability of coverage
        (missing test for an acceptance criterion)
        
        security vulnerability (sự dễ bị tổn thương) (susceptibility to buffer overflows)
        
        incorrect interface specification (different unit of measurement used by the calling system than by the called system
        
        deviation from standard (lack of adherence to coding standard)
        sự tuân thủ /i/
        
        coding defect
        
        variable with undefined values, variables is declared but
        never used, unreachable code, duplicate code
        
        design defect
        
        inefficient algorithms/database structure
        high coupling (khớp nối), low cohesion (sự kết nối /i/)
        
        req defect
        
        inconsistency, contradiction
        omission, inaccuracy, redundancy
      - static testing can be used to improve the consistency, internal quality of work product, while dynamic testing focus on externally visible behavior
      - static testing can find defect with much less effort
      - static testing find defect in work product directly rather than identify failure caused by defect when sw is run
    - - objective
        
        find different types of defect
        
        identify defect as early as possible
        
        provide assessment of quality of work product