Learn about Static testing

1. What is Static Testing?

Static testing is a software testing technique to find bugs in software / applications without executing code. Unlike dynamic testing, it is a technique that requires code execution. Static testing is done to avoid errors early in the early stages of software development, it also makes it easy to identify and resolve errors. It also helps find bugs that might not be found in Dynamic testing.

There are 2 main types of static testing techniques:

• Manual testing, also known as review activities
• Automated testing is the use of tools for analysis

2. Why Static testing is needed

• Static testing allows for early detection of defects before performing dynamic testing (eg during requirements or evaluating design specifications, screening of product backlog, etc.).
• Defects detected early are often much cheaper than defects found later in the life cycle, especially compared to defects found after the software is actively deployed and used.
• Increased development productivity (e.g. due to improved design, more maintainable code)
• Reduce development costs and time
• Reduce testing costs and time
• Identify defects that are not easily found by dynamic testing
• Detect and repair defects more efficiently and before performing dynamic testing

3. Static testing procedure

The review process consists of 5 main activities:

• Planning
• Initiate review
• Individual review
• Issue communication and analysis
• Fixing and report

1.Planning

• Define the scope, including the purpose of the review, the documents or parts of the document for review, and the quality characteristics to evaluate
• Estimate the effort and time frame
• Define review features such as review type with roles, activities, and checklist
• Select people to participate in reviews and assign roles
• Define the input and output criteria for each type of formal review
• Check that the entry criteria is met

2. Initiate review

• Distributing work products and other materials such as form log issue, checklists, and work related products
• Explain scopes, goals, processes, roles, and products to participants
• Answer any questions that members may have during the review session

3.Individual review

• Review all or 1 part of the product
• Documenting potential errors, recommendations and questions

4.Issue communication and analysis

• Communicates potential faults identified
• Analyze potential bugs, assign ownership and status to it
• Evaluate and record the quality characteristics
• Review findings found with the output criteria to make a review decision

5.Fixing and report

• Create a bug report
• Fix found errors
• Report bugs to everyone
• Note, update the state of the error
• Data collection (types of review formals)
• Check that the output criteria is met
• Accept the product when the output criteria are met

4. What types of static testing include?

What is testing review?

Review in static testing is a process or meeting conducted to look for potential flaws in any design or program. Another meaning of review is that all team members know the progress of the project and sometimes a variety of thoughts can lead to great proposals.

Commonly used review techniques:

The participants of the review:

• Moderator: Perform input checks, track rework, train team members, schedule meetings
• Author: Responsible for fixing found errors and improving document quality
• Scribe: Record what happened, log bug and attend review meeting
• Reviewer: Check document for defect and inspection
• Manager: Decide to do the review and make sure the goal is met

Informal Reviews:

• Main Purpose: Detecting potential errors not participating in any official process
• Review meeting: Led by author
• Performed by: 1 co-author or more people
• Result: can be recorded
• Use of checklist: can be there or not

Walkthrough:

• Main purpose: find bugs, improve software products, review alternative implementations, evaluate compliance with specifications. Individuals may or may not prepare prior to review.
• Review meeting: yes, lead by author of software product
• Scribe: required
• Use of checklist: can be there or not
• Result: Logs of potential bugs and review reports can be run. May change in practice from informal to formal

Technical review:

• Main purpose: reach consensus, detect potential bugs
• Reviewer: should be the technical colleague of the author and technical expert. Individuals are asked to prepare before reviewing
• Review meeting: yes or no, ideally led by a trained moderator (not the author)
• Scribe: required, the ideal is not the author
• Use of checklist: can be there or not
• Result: Logs of potential bugs and review reports can be run

Inspection review:

• Main purpose: detect potential faults, prevent similar faults in the future Follow a defined procedure with officially recorded output: based on rules and checklist Individuals are required to prepare before review Roles in review must be clearly defined
• Review meeting: yes, led by a trained moderator (not the author)
• Reviewer: is a colleague of the author or expert in other fields related to the product
• Specified: input and output criteria used
• Scribe: required
• Result: logs of potential errors and process review can be performed

5. Techniques to use in Static testing

There are several review techniques that can be applied in individual review operations (i.e., individual preparations) to detect defects. These techniques can be used for the audit types described above. Effectiveness depends on the rating used.

Commonly applied evaluation techniques

• Ad hoc
• Checklist-based
• Scenarios and dry runs
• Perspective-based
• Role-based

1. Review technique Adhoc

• The reviewer is provided with little or no instructions on how to perform this task.
• Special consideration is a commonly used technique that requires little preparation
• This technique is highly dependent on the skills of the assessor and can lead to many duplicate issues reported by different assessors.

2.Review Techniques: Checklist based

• Is a systematic technique
• The evaluator detects problems based on the checklist
• The assessment checklist includes a set of questions based on potential defects, which can be drawn from experience.
• Checklists should be specific to work product type
• The main advantage of checklist-based techniques is that it has a systematic coverage of the typical types of defects.
• Not only simply follow the checklist in the personal review, but also to look for defects outside the checklist.

3.Review Techniques: Scenarios and dry runs

• In the scenario-based assessment, the evaluator is provided with structured instructions on how to read through the work product.
• Scenario-based assessment assists the evaluator to perform a “dry run” on a work product based on expected usage of the work product (eg use cases).
• These scenarios provide the evaluator with better instructions on how to identify error types than simple checklist items.
• However, assessors should not be bound into documented situations. The evaluator should also look for defects outside of situations

4.Review Techniques: Perspective-based

• The evaluator assumes different stakeholders’ perspectives in individual reviews.
• The views of typical stakeholders include end users, marketers, designers, testers or operations.
• Using the differing perspectives of stakeholders leads to a deeper personal assessment with fewer problems overlapping among reviewers.
• In addition, perspective reading also asks reviewers to try to use the work product in question to create the product they will derive from it. For example, a tester would try to create draft acceptance tests if performing a reading from the point of view of the requirement specification to see if all the required information has been included.
• Read from point of view, the checklist is expected to be used.

5. Review Techniques: Role based

• Role-based assessment is a technique in which the assessor evaluates work product from the perspective of each stakeholder role.
• Typical roles include specific end-user types (experienced, inexperienced, senior, sub-level, etc.), and specific roles in the organization (user admin, administrator). system staff, performance testers, etc.).
• The same principles apply as in the reading from the point of view because the roles are similar.

6.Main bugs are found in static testing

• Deviation from standards
• Code is not maintained
• Error in design
• Error was in the requirement
• Specifications are not consistent
• Usually, errors discovered during static testing are due to security gaps, undeclared variables, boundary violations, syntax violation, inconsistent interface, etc.

References:

Syllabus 2018

https://www.guru99.com/testing-review.html