Static Testing (Part 2)

Tram Ho

In part 1, I talked about the review work product process, in this part I will talk about the types of reviews and the review techniques.

5. Roles and responsibilities in standard review

  • Author:
    • Create products for review
    • Fix work product defect detected during review (if necessary)
  • Manager:
    • Responsible for planning the review
    • Decide on the implementation of the review
    • Assign attendees, costs and time for review
    • Monitor expenses incurred
    • Make decisions in case of unsatisfactory output
  • Facilitator (aka moderator)
    • Ensure the effectiveness of the review (when held)
    • As intermediaries, if necessary between parties when they have different viewpoints
    • Often the one who decides the success of a review
  • Review leader
    • Take on the overall role of the review
    • Decide who will participate in the review and decide on the location and time for this review
  • Reviewer
    • This could be an expert on a work product issue that needs a review, or people on the same project, who are interested in a work product, or who have a specific technical or professional background. work-related products to review
    • Identify potential defect problems in your work product through reviews
  • Scribe (or recorder)
    • Reconcile / refer back to potential errors found during personal review
    • Record new potential errors, open points, decisions during the review meeting

6. Types of reviews

  • Informal review (non-standard review):
    • The main purpose: to detect potential defect
    • Additional purposes: Create new ideas or new solutions, quickly solve minor problems
    • Not based on standard procedures
    • May not include the review meeting
    • Can be done by colleague / colleague of author or by many people
    • Review results can be recorded or not
    • The value of a review depends largely on the reviewer
    • Can use the checklist or not
    • Commonly used in the Agile development model
  • Walkthrough
    • The main purpose: finding defect, improving software products, reviewing alternative implementations, assessing compliance with standards and specifications
    • Exchange technical ideas or parts that need to be changed, train participants, reach consensus
    • The chair of the review meeting is the author of the reviewed work work product
    • The Scribe role is required
    • Logging and reporting potential defect may or may not be present
  • Technical review
    • Purpose: to reach consensus, identify potential risks
    • Possible goals: evaluate quality and create trust in the product, create new ideas, motivate and allow the author to improve future product features, consider needing to replace it with existing products. at or not
    • Mandatory reviewers need to prepare before the review meeting
    • Review meetings may not be required, ideally organized with a moderator
    • Scribe is required
    • It is necessary to log the detected defect and review report
  • Inspection
    • The main purpose: identify potential defect, assess quality and create trust in the product, prevent similar defect in the future by helping the author analyze the root cause.
    • Purpose achieved: promote and enable the author to improve future product features and development processes, reaching consensus
    • Follow a predefined process with standard, document-based and checklist output
    • Reviewer or colleague with the author or expert in the field related to the product being reviewed
    • The input and output criteria should be used
    • Scribe is required
    • Need to build bug reports and reports through the review

7. Apply techniques to review

  • Adhoc:
    • In the Adhoc review technique, reviewers are provided with very little or no instructions on how to perform the task.
    • Reviewers must regularly read the material continuously, identify and record the problems they encounter / detect in the product.
    • Adhoc is the most common technique used when there is very little preparation
    • This technique is highly dependent on reviewers’ skills and may have the problem that a large number of issues are reported by different reviewers.
  • Checklist-based:
    • The review checklist-based technique is a methodical review technique, that is, reviewers will determine the issue based on the checklist allocated during the review initiation stage.
    • A review checklist includes a set of questions based on potential defect, often from previous experience.
    • The checklist will be specific to each type of work product reviewed and regularly maintained to cover missing issues in the previous version.
    • The main benefit of the checklist-based technique is the ability to systematically cover typical defect types
  • Scenarios and dry runs:
    • In scenario-based review, reviewers are provided with instructions on how to read and understand work products
    • The scenario-based approach is to instruct reviewers to perform “dry runs” of work products based on the desire to use the work product (if the work product is a document with an appropriate format such as a use case).
    • This method gives reviewers better guidance on how to identify defect types more easily than the check list method.
  • Role-based:
    • This technique is a reviewer evaluating the work product on the personal views of the stakeholders in the project
    • Specifically, these roles can be end-user (experienced, inexperienced) or play roles in the organization such as: user administrator, system administrator, performance tester
  • Perspective-based:
    • Similar to role-based, this reviewer stands in view of the different stakeholders in the review process. Typical stakeholders include: end user, marketing, designer, tester or operation. Using the perspectives of different stakeholders has the benefit of being more insightful in the individual review process and also having The effect of reducing duplicate issues
    • Based on evaluation studies, Perspective-based techniques are most effective in reviewing system work product documents, including requirements and techniques.

8. Success factors for review

  • Factors of organizational success include:
    • Each review must be clearly defined, providing a review plan, review participants and outcome measurement criteria to end the review process.
    • The types of reviews applied should be appropriate to achieve the goals and fit with the software products and review participants
    • Attendees need adequate time to prepare
    • The review is scheduled with full notice to the participants
  • Human factors involved in the review:
    • Invite the right people to participate in the review to achieve specific review goals such as inviting people with different skills or perspectives
    • Testers are very valuable when participating in reviews and also to learn about work products, which need to prepare well for effective testing and prepare for early testing.
    • Review meetings should be well managed so that attendees can see the value of the time they spend

References:

ISTQB Foundation 2018 syllabus

Share the news now

Source : Viblo