Foundation Level 3 Flashcards
Static testing
- the software under test does not need to be executed
- Code, process specification, system architecture specification or other work products are evaluated through manual examination
- with the help of a tool
Static testing objectives
- improving quality
- detecting defects
- assessing characteristics like readability, completeness, correctness, testability and consistency
Work Products Examinable by Static Testing
- Any work product that can be read and understood can be the subject of a review.
- work products need a structure against which they can be checked
Work products that are not appropriate for static testing
are difficult to interpret by human beings and that should not be analyzed by tools (e.g., 3rd party executable code due to legal reasons).
Value of Static Testing
- detect defects in the earliest phases of the SDLC
- identify defects which cannot be detected by dynamic testing (e.g., unreachable code, design patterns not implemented as desired, defects in non-executable work products).
- Communication will also be improved between the involved stakeholders
- Code defects can be detected using static analysis more efficiently than in dynamic testing
Differences between Static Testing and Dynamic Testing
- there are some defect types that can only be found by either static or dynamic testing.
- Static testing finds defects directly, while dynamic testing causes failures from which the associated defects are determined through subsequent analysis
- Static testing may more easily detect defects that lay on paths through the code that are rarely executed or hard to reach using dynamic testing
- Static testing can be applied to non-executable work products,
- Static testing can be used to measure quality characteristics that are not dependent on executing code
Typical defects that are easier and/or cheaper to find through static testing
- Defects in requirements (e.g., inconsistencies, ambiguities, contradictions, omissions, inaccuracies, duplications)
- Design defects
- Certain types of coding defects
- Deviations from standards
- Incorrect interface specifications
- Specific types of security vulnerabilities
- Gaps or inaccuracies in test basis coverage
Success Factors for Reviews
- Defining clear objectives and measurable exit criteria.
- Choosing the appropriate review type to achieve the given objectives, and to suit the type of work product, the review participants, the project needs and context
- Conducting reviews on small chunks, so that reviewers do not lose concentration during an individual review and/or the review meeting
- Providing feedback from reviews to stakeholders and authors so they can improve the product and their activities
- Providing adequate time to participants to prepare for the review
- Support from management for the review process
- Making reviews part of the organization’s culture, to promote learning and process improvement
- Providing adequate training for all participants so they know how to fulfil their role
- Facilitating meetings
Review types
- Informal review
- Walkthrough
- Technical Review
- Inspection
Selecting the right review type is key to achieving the required review objectives
Informal review
do not follow a defined process and do not require a formal documented output. The main objective is detecting anomalies.
Walkthrough
can serve many objectives, such as evaluating quality and building confidence in the work product, educating reviewers, gaining consensus, generating new ideas, motivating and enabling authors to improve and detecting anomalies
Technical Review
- performed by technically qualified reviewers and led by a moderator
- objectives of a technical review are to gain consensus and make decisions regarding a technical problem, but also to detect anomalies, evaluate quality and build confidence in the work product, generate new ideas, and to motivate and enable authors to improve
Inspection
find the maximum number of anomalies. Other objectives are to evaluate quality, build confidence in the work product, and to motivate and enable authors to improve. Metrics are collected and used to improve the SDLC, including the inspection process.
Roles and Responsibilities in Reviews
- Manager
- Author
- Moderator
- Scribe
- Reviewer
- Review leader
Manager Role
- decides what is to be reviewed
- provides resources, such as staff and time for the review
Author role
creates and fixes the work product under review
Review leader role
takes overall responsibility for the review such as deciding who will be involved, and organizing when and where the review will take place
Review Process Activities
- Planning
- Review initiation
- Individual review
- Communication and analysis
- Fixing and reporting
NB: f the required review is more formal, then more of the tasks described for the different activities will be needed.
Planning stage defines
the scope of the review, which comprises the purpose, the work product to be reviewed, quality characteristics to be evaluated, areas to focus on, exit criteria, supporting information such as standards, effort and the timeframes for the review
Review initiation
- goal is to make sure that everyone and everything involved is prepared to start the review
making sure that every participant has access to the work product under review, understands their role and responsibilities and receives everything needed to perform the review.
Individual review
Every reviewer performs an individual review to assess the quality of the work product under review, and to identify anomalies, recommendations, and questions by applying one or more review techniques (e.g., checklist-based reviewing, scenario-based reviewing). The ISO/IEC 20246 standard provides more depth on different review techniques. The reviewers log all their identified anomalies, recommendations, and questions.
Communication and analysis
- anomalies identified during a review are not necessarily defects => discuss
- the decision should be made on its status, ownership and required actions.
Fixing and reporting
for every defect, a defect report should be created so that corrective actions can be followed-up. Once the exit criteria are reached, the work product can be accepted. The review results are reported.
