Chapter 3: Static Techniques
In this chapter we will discuss on the following topics.
- 3.1 Static Techniques and the Test Process (U)
- 3.2 Review Process (U)
- 3.3 Static Analysis by Tools (U)
3.1 Static Techniques and the Test Process
Dynamic testing requires the execution of software, where as static testing techniques rely on the reviews(also called as manual examination) and static analysis(automated analysis) of the code or other project documentation without the execution of the code.
A review could be done entirely as a manual activity, but there is also tool support. The main manual activity is to examine a work product and make comments about it. Any software work product can be reviewed, including requirements specifications, design specifications, code, test, plans, test specifications, test cases, test scripts, user guides or web pages.
Reviews are a way of testing software work products (including software code) and can be performed well before dynamic test execution. Defects detected during reviews early in the software development life cycle are often much cheaper to remove then those detected by running tests on the executing code.
Reviews, static analysis and dynamic testing have the same objective-identifying defects. They are complementary; the different techniques can find different types of defects effectively and efficiently. Compared to dynamic testing, static techniques find causes of failures (defects) rather than the failures themselves.
Typical defects that are easier to find in reviews than in dynamic testing include: requirement defects, design defects, deviations from standards, incorrect interface specifications and insufficient maintainability.
Benefits of reviews include early defect detection and correction, development productivity improvements, reduced development timescales, reduced testing cost and time, lifetime cost reductions, fewer defects and improved communication. Reviews can find omissions, for example, in requirements, which are unlikely to be found in dynamic testing.
3.2 Review Process
The different types of reviews vary from informal, characterized by no written instructions for reviewers, to systematic, characterized by team participation, documented results of the review, and documented producers for conducting the review. The formality of a review process is related to factors such as the maturity of the development process, any legal or regulatory requirements or the need for an audit trail.
The way a review is carried out depends on the agreed objectives of the review. For example: to gain understanding, to educate new members, to find defects, to take decisions.
3.2.1 Activities of a Formal Review
A typical formal review has the main activities as given below:
1. Planning
- Allocating roles
- Checking entry criteria
- Defining entry and exist criteria for more formal review types
- Defining the review criteria
- Selecting the personnel
- Selecting which parts of documents to review
2. Kick-off
- Explaining the objectives, process and documents to the participants
- Distributing documents
3. Individual preparation
- Preparing for the review meeting by reviewing the documents
- Noting potential defects, Questions and comments
4. Examination, evaluation, recording of results (Review meeting)
- Discussing or logging, with documented results or minutes
- Examining/evaluating and recording issues during any physical meetings or tracking any group electronic communications
- Nothing defects, making recommendations regarding handling the defects, making decisions about the defects
4. Rework
- Fixing defects found
- Recording updated status of defects
6. Follow-up
- Gathering metrics
- Checking that defects have been addressed
- Checking on exist criteria
3.2.2 Roles and Responsibilities
A typical formal review will include the roles mentioned below:
- Author: the writer or person with chief responsibility of the document(s) to be reviewed.
- Manager: decides on the execution of reviews, allocates time in project schedules and determines if the review objectives have been met.
- Moderator: the person who leads the review of the document or set of documents, including planning the review, running the meeting, and following-up after the meeting. If necessary, the moderator may mediate between the various points of view and is often the person upon whom the success of the review rests.
- Reviewers: individuals with a specific technical or business background (also called checkers or inspectors) who, after the necessary preparation, identify and describe findings (e.g., defects) in the product under review. Reviewers should be chosen to represent different perspectives and roles in the review process, and should take part in any review meetings.
- Scribe (or recorder): documents all the issues, problems and open points that were identified during the meeting.
Looking at software products or related work products from different perspectives and using checklists can make reviews more effective and efficient.
3.2.3 Types of Reviews
A single software product or related work product may be the subject of more than one review. If more than one type of review is used, the order may vary. For example, a technical review may be carried out before an informal review. The main purposes, characteristics and options of common review types are:
Informal Review
Main purpose: inexpensive way to get some benefit
Characteristics:
- No formal process
- May take the form of pair programming or a technical lead reviewing designs and code
- Results may be documented
- Varies in usefulness depending on the reviewers
Walkthrough
Main purpose: learning, gaining, understanding, finding defects
Characteristics:
- Meeting led by author
- May take the form scenarios, dry runs, peer group participation
- Open-ended sessions
- Optional pre-meeting preparation of reviewers
- Optional preparation of a review report including list of findings
- Optional scribe (who is not the author)
- May very in practice from quite informal to very formal
Technical Review
Main purposes: discussing, making decisions, evaluating alternatives, finding defects, solving technical problems and checking conformance to specifications, plans, regulations, and standards.
Characteristics:
- Documented, defined defect-detection process that includes peers and technical experts with optional management participation
- May be performed as a peer review without management participation
- Ideally led by trained moderator (not the author)
- Pre-meeting preparation by reviewers
- Optional use of checklists
- Preparation of a review report which includes the list of findings, the verdict whether the software product meets its requirements and, where appropriate, recommendations related to findings
- May very in practice form quite informal to very formal
Inspection
Main purpose: finding defects
Characteristics:
- Led by trained moderator (not the author)
- Usually conducted as a peer examination
- Defined roles
- Includes metrics gathering
- Formal process based on rules and checklists
- Specified entry and exist criteria for acceptance of the software product
- Pre-meeting preparation
- Inspection report including list of findings
- Formal follow-up process (with optional process improvement components)
- Optional reader
Inspections,technical reviews and Walkthroughs can be performed within a peer group, i.e., colleagues at the same organizational level. This type of review is called a “peer review”.
3.2.4 Success Factors for Reviews
Success factors for reviews include:
- Checklists or roles are used if appropriate to effectiveness of defect identification
- Defects found are welcomed and expressed objectively
- Each review has clear predefined objectives
- Management supports a good review process (e.g., incorporating adequate time for review activities in project schedules)
- People issues and psychological aspects are dealt with
- Review techniques are applied that are suitable to achieve the objectives and to the type and level of software work products and reviewers
- Training is given in review techniques, especially the more formal techniques such as inspection
- There is an emphasis on learning and process improvement
- The right people for the review objectives are involved
- Testers are valued reviewers who contribute to the review and also learn about the product which enables them to prepare tests earlier
- The review is conducted in an atmosphere of trust; the outcome will not be used for the evaluation of the participants
3.3 Static Analysis by Tools
The objective of static analysis is to find defects in software source code and software models. Static analysis is performed without actually executing the software being examined by the tool; dynamic testing does execute the software code. Static analysis can locate defects that are hard to find in dynamic testing. As with reviews, Static analysis finds defects rather than failures. Static analysis tools analyze program code (example: control flow and data flow), as well as generated output such as HTML and XML.
The value of static analysis is:
- Detecting dependencies and inconsistencies in software models such as links
- Early detection of defects prior to test execution
- Early warning about suspicious aspects of the code or design by the calculation of metrics, such as high complexity measure
- Identification of defects not easily found by dynamic testing
- Improved maintainability of code and design
- Prevention of defects, if lessons are learned in development
Typical defects discovered by static analysis tools include:
- Inconsistent interfaces between models and components
- Missing and erroneous logic (such as potentially infinite loops)
- Overly complicated constructs
- Programming standards violations
- Referencing a variable with an undefined value
- Security vulnerabilities
- Syntax violations of code and software models
- Unreachable or dead code
- Variables that are not used or are improperly declared
Static analysis tools are typically used by developers before and during component and integration testing or when checking-in code to configuration management tools, and by designers during software modeling. Static analysis tools may produce a large number of warning massages, which need to be well-managed to allow the most effective use of the tool. Many Compilers offer some support for static analysis, such as the calculation of metrics.
Posts
