05. Static Techniques - idavidov13/ISTQB-Foundation GitHub Wiki
Static test techniques provide a powerful way to improve the quality and productivity of software development. The fundamental objective of static testing is to improve the quality of software work products by assisting engineers to recognize and fix their own defects early in the software development process. Static techniques include both reviews and static analysis.
Static analysis
The process of evaluating a component or system without executing it, based on its form, structure, content or documentation.
Static testing
Testing a work product without code being executed. Reviewing work products such as requirements, user stories, and source code.
Work products that can be examined by static testing
• Any type of specification: business requirements, functional requirements, secu-rity requirements.
• Epics, user stories and acceptance criteria.
• Code (done using a tool to analyze the code with respect to the criteria of interest).
• Testware, that is, any type of work product to do with testing, for example test plans, test conditions, test cases, test procedures and automated test scripts.
• User guides, help text, wizards and other things designed to help the user to more effectively use the system.
• Web pages (there are also static analysis tools to analyze whether any links are broken for example).
• Contracts (a particularly important work product to review, as a lot of money may be riding on the specific wording), project plans, schedules and budgets.
• Models such as activity diagrams or other models used in model-based testing (MBT).
Benefits of static testing
Static testing is a very suitable method for improving the quality of software work products. It is also important that the quality improvement is not achieved just once, but has a more permanent nature. The feedback from the static testing process to the development process allows for process improvement, which supports the avoidance of similar errors being made in the future.
The main benefits are:
• Since static testing can start early in the life cycle, early feedback on quality issues can be established, for example an early validation of user requirements rather than late in the life cycle during acceptance testing. Feedback during design review or backlog refinement is more useful than after a feature has been built.
• By detecting defects at an early stage, rework costs are most often relatively low, and thus relatively cheap improvements to the quality of software products can be achieved, as many of the follow-on costs of late updates are avoided, for example additional regression tests, confirmation tests, etc.
• Defects are more efficiently detected and corrected, particularly since this is done before dynamic test execution.
• Defects that are not easily found by dynamic testing, such as security vulnerabilities, are identified.
• Defects in future design and code are prevented by uncovering inconsistencies, ambiguities, contradictions, omissions, inaccuracies and redundancies in requirements.
• Since rework effort is substantially reduced, development productivity figures are likely to increase.
• Reduced development cost and time.
• Reduced testing cost and time. If defects are found and fixed before test execution starts, there are fewer to find in testing, so more tests pass, and there are fewer defect reports to write and fewer confirmation tests to run after fixes. This saves both time and money.
• Reduced total cost of quality over the software's lifetime. If defects are found and fixed early, then there should be fewer that get through to later testing or operation. The defects that are not there do not need to be investigated or fixed, saving time and money.
• Improved communication within the team, since there is an exchange of information between the participants during reviews, which can lead to an increased awareness of quality issues.
Differences between static and dynamic testing
Dynamic testing - Testing that involves the execution of the software of a component or system.
Static and dynamic testing have the same objectives: to assess the quality of work products and identify defects as early as possible. But static and dynamic testing are not the same. They find different types of defect, so they are complementary and are best used together. Compared to dynamic testing, static testing finds defects rather than failures.
REVIEW PROCESS
Review - A type of static testing during which a work product or process is evaluated by one or more individuals to detect issues and to provide improvements.
Informal review - A type of review without a formal (documented) procedure.
Formal review - A form of review that follows a defined process with a formally documented output.
Roles in a formal review
-
The author
-
Management
-
Facilitator (often called moderator)
-
Review leader
-
Reviewers
-
Scribe (or recorder)
Types of review
Informal review (for example buddy check, pairing, pair review) - A type of review without a formal (documented) procedure.
• Main purpose/objective: detecting potential defects.
• Possible additional purposes: generating new ideas or solutions, quickly solving minor problems.
• Not based on a formal (documented) review process.
• May not involve a review meeting.
• May be performed by a colleague of the author (buddy check) or by more people.
• Results may be documented (but often are not).
• Varies in usefulness depending on the reviewer(s).
• Use of checklists is optional.
• Very commonly used in Agile development.
Walkthrough - A type of review in which an author leads members of the review through a work product and the members ask questions and make comments about possible issues.
• Main purposes: find defects, improve the software product, consider alternative implementations, and evaluate conformance to standards and specifications.
• Possible additional purposes: exchanging ideas about techniques or style variations, training of participants, and achieving consensus.
• Individual preparation before the review meeting is optional.
• Review meeting is typically led by the author of the work product.
• Use of a scribe is mandatory.
• Use of checklists is optional.
• May take the form of scenarios, dry runs or simulations.
• Potential defect logs and review reports may be produced.
• May vary in practice from quite informal to very formal.
Technical review - A formal review type by a team of technicallyqualified personnel that examines the suitability of a work product for its intended use and identifies discrepancies from specifications and standards.
• Main purposes: gaining consensus, detecting potential defects.
• Possible further purposes: evaluating quality and building confidence in the work product, generating new ideas, motivating and enabling authors to improve future work products, considering alternative implementations.
• Reviewers should be technical peers of the author, and technical experts in relevant disciplines.
• Individual preparation before the review meeting is required.
• Review meeting is optional, ideally led by a trained facilitator (typically not the author).
• Scribe is mandatory, ideally not the author.
• Use of checklists is optional.
• Potential defect logs and review reports are typically produced.
Inspection - A type of formal review to identify issues in a work product, which provides measurement to improve the review process and the software development process.
• Main purposes: detecting potential defects, evaluating quality and building confidence in the work product, preventing future similar defects through author learning and root cause analysis.
• Possible further purposes: motivating and enabling authors to improve future work products and the software development process, achieving consensus.
• A defined process is followed, with formal documented outputs, based on rules and checklists.
• There are clearly defined roles, such as those specified in Section 3.2.2 which are mandatory and may include a dedicated reader who reads/paraphrases the work product aloud during the review meeting.
• Individual preparation before the review meeting is required.
• Reviewers are either peers of the author or experts in other disciplines that are relevant to the work product.
• Specified entry and exit criteria are used.
• A scribe is mandatory.
• The review meeting is led by a trained facilitator/moderator (not the author).
• The author cannot act as the review leader, facilitator, reader or scribe.
• Potential defect logs and review reports are produced.
• Metrics are collected and used to improve the entire software development process, including the inspection process.