Please enable JavaScript.
Coggle requires JavaScript to display documents.
K1 - Static Testing (1- Work product can be examined using static testing,…
K1 - Static Testing
1- Work product can be examined using static testing
2 - Specifications
3- including business requirements
8 - functional requirements
10 - security requirements
7 - Epics, user stories, and acceptance criteria
9 - Architecture and design specifications
12 - Code
14 - Testware, including test plans, test cases, test procedures, and automated test scripts
4- User guides
13 - Web pages
5- Contracts, project plans, schedules, and budget planning
11 - Configuration set up and infrastructure set up
6 - Models, such as activity diagrams, which may be used for Model-Based testing
3.1 Static Testing Basics
FL-3.1.1 (K1) Recognize types of software work product that can be examined by the different static testing techniques
15 - Reviews can be applied to any work product that the participants know how to read and understand.
16 - Static analysis can be applied efficiently to any work product with a formal structure (typically code or models) for which an appropriate static analysis tool exists.
17 - Static analysis can even be applied with tools that evaluate work products written in natural language such as requirements (e.g., checking for spelling, grammar, and readability).
3.2 Review Process
FL-3.2.2 (K1) Recognize the different roles and responsibilities in a formal review
3.2.2 Roles and responsibilities in a formal review
1 - A typical formal review will include the roles below:
3 - Author
3.1 Creates the work product under review :check:
3.2 Fixes defects in the work product under review (if necessary) :check:
2 - Management
2.3 Is responsible for review planning :check:
2.4 Decides on the execution of reviews :check:
2.2 Assigns staff, budget, and time :check:
2.1 Monitors ongoing cost-effectiveness :check:
2.5 Executes control decisions in the event of inadequate outcomes :check:
6 - Facilitator (often called moderator)
6.1 Ensures effective running of review meetings (when held) :check:
6.2 Mediates, if necessary, between the various points of view :check:
6.3 Is often the person upon whom the success of the review depends :check:
7 - Review leader
7.1 Takes overall responsibility for the review
:check:
7.2 Decides who will be involved and organizes when and where it will take place : :check:
5 - Reviewers
5.1 May be subject matter experts, persons working on the project, stakeholders with an interest in the work product, and/or individuals with specific technical or business backgrounds :check:
5.2 Identify potential defects in the work product under review :check:
5.3 May represent different perspectives (e.g., tester, developer, user, operator, business analyst, usability expert, etc.) :check:
4 - Scribe (or recorder)
4.1 Collates potential defects found during the individual review activity :check:
4.2 Records new potential defects, open points, and decisions from the review meeting (when held) :check:
4.3 In some review types, one person may play more than one role, and the actions associated with each role may also vary based on review type. :check:
4.4 In addition, with the advent of tools to support the review process, especially the logging of defects, open points, and decisions, there is often no need for a scribe. :check: