Please enable JavaScript.
Coggle requires JavaScript to display documents.
CTFL - Chapter 3: Static Testing - Coggle Diagram
CTFL - Chapter 3: Static Testing
Static Testing Basics
Examine the software work products
Manual
e.g., Reviews
Review Techniques
Ensure user stories are complete and understandable
Testable acceptance criteria
By Tools
e.g, Static Analysis
Part of security testing
Incorporate into automated build and delivery systems
E.g A compiler
Type of static analysis tool that analyzes the software code written using a specific computer language.
Objectives
Incorporated into continuous integration frameworks
Evaluate maintainability and security (Spelling checkers and readability tools are other examples of static analysis tools)
Identify problems prior to dynamic testing
Benefit
Static Testing
Early detection of defects before dynamic test execution
Prevent defects in design or coding
Reduced development timescales due to the number of bugs significantly reduced
Improve communication between team members while participating in reviews
Early and Frequent Stakeholder Feedback
Prevent misunderstanding about requirements
Change to requirements are understood & implemented earlier
Feedback helps the development team to improve their understanding of what they are building
Differences between Static and Dynamic Testing
Static Testing
Easily detect defects
Can be applied to non-executable work products
Find defect directly
Measure quality characteristics that are not dependent on executing code
Dynamic Testing
Can only applied to executable work products
Measure quality characteristics that are dependent on executing code
Causes failures from which the associated defects are determined through subsequent analysis
Work Product Review Process
Groups of Activities
Individual Review
Each of the participants
alone
will review all or part of the work product
Note potential defects, recommendations, questions, and comments
Communication & analysis
Analyze potential defects, assigning ownership and status to them
Evaluate and document quality characteristics
Communicating the identified potential defects
Evaluate the review findings against the exit criteria to make a review decision
Review Initiation
Explain the scope, objectives, process, roles, and work products to the participants
Answer any questions that participants may have about the review
Distribute the work product and other material if needed
Fixing and Reporting
Create defect reports for those findings that require changes
Gather metrics (formal review types)
Fixing defects found, typically done by the author.
Planning
Identify review characteristics
Select the people to participate in the review and allocating roles
Estimate effort and timeframe
Define the entry and exit criteria for more formal review types
Defining the scope
Roles and responsibilities in Reviews
Author
Create the work product under review
Fixs defects in the work product under review (if necessary)
Manager
Decides on the execution of reviews
Assign staff, budget and allocates time in project schedules
Is responsible for review planning
Monitors ongoing cost-effectiveness
Moderator (or Facilitator)
Responsible for ensuring no bug fixing will be discussed in the review meeting
Meditates, if necessary, between the various points of view
Ensure effective running of review meetings (when held)
Review Leader
Take overall responsibility of the review
Decides who will be involved and organizes when and where it will take place
Reviewer
May represent different perspectives (Tester, programmer, BA, etc)
Identify potential defects in the work product under review
Scribe (or Recorder)
Collect potential defects found during the individual review activity
Records new potential defects, open points, and decisions from the review meeting
Review Types
Objectives
Find defects, gain understanding, educate participants
The focus of any review depends on the agreed objectives of the review
Types
Informal
Quickly find defects and an inexpensive way to achieve some limited benefit
Generating new ideas or solutions, quickly solving minor problems
Walkthrough
The meeting is led by
the author
The appointment of a scribe who is not the author is mandatory
Technical review
Scribe is mandatory, ideally not the author
Individual preparation before the review meeting is required
The review meeting is optional, ideally led by
a trained facilitator
(typically not the author)
Inspection
Scribe is mandatory
Follow a defined process with formally documented outputs based on rules and checklists
The review meeting is led by
a trained facilitator
Metrics are collected and used to improve the entire software development process
Success Factors for Reviews
Each review has clear objectives, defined during review planning & used as measurable exit criteria
Review types are applied which are suitable to achieve the objectives
Participants have adequate time to prepare for the review
Reviewers should provide feedback to authors and relevant stakeholders early and frequently