Brainscape's Knowledge GenomeTM

Browse over 1 million classes created by top students, professors, publishers, and experts.


See full index

tester istqb cards > chapter 3: static testing > Flashcards

chapter 3: static testing Flashcards

1
Q

Testing that involves the execution of the test item

A

Dynamic testing

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
1
Q

A condition that deviates from expectation.

A

Anomaly

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

A type of review that follows a defined process with a formally documented output.

A

Formal review

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q
  • A type of review that does not follow a defined process and has no formally documented output
A

Informal review

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

A type of formal review that uses defined team roles and measurement to identify defects in a work product, and improve the review process and the software development process.

A

Inspection

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

A type of STATIC TESTING in which a work product or process is evaluated by one or more individuals to detect defects or to provide improvements.

A

Review

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

The process of evaluating a component or system without executing it, based on its form, structure, content, or documentation

A

Static analysis

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

Testing that does not involve the execution of a test item.

A

Static testing

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q
  • A formal review by technical experts that examine the quality of a work product and identify discrepancies (a lack of similarity between two or more facts) from specifications and standards. See also: peer review
A

Technical review

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

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. Reference: After ISO 20246 Synonyms: structured walkthrough See also: peer review

A

Walkthrough

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

static testing objectives

A

-improving quality

-detecting defects

-assessing characteristics like readability, completeness, correctness, testability and consistency.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

Testers, business representatives and developers work together during example mappings, collaborative user story writing and backlog refinement sessions to ensure that user stories and related work products meet defined criteria,

A

the Definition of Ready

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

-Review techniques can be applied to

A

-ensure user stories are complete and understandable

  • include testable acceptance criteria.

-By asking the right questions, testers explore, challenge and help improve the proposed user stories.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

Almost any work product can be examined using static testing:

A

Examples:
requirement specification documents
source code
test plans
test cases
product backlog items
test charters (Documentation of the goal or objective for a test session.)
project documentation
contracts
models.

-Any work product that can be read and understood can be the subject of a review. However, for static analysis, work products need a structure against which they can be checked (e.g., models, code or text with a formal syntax).

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

-Work products that are not appropriate for static testing include

A

those that 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).

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

value of static testing

A

-Static testing can detect defects in the earliest phases of the SDLC, (principle of early testing)

identifies defects which cannot be detected by dynamic testing (e.g., unreachable code, design patterns not implemented as desired, defects in non-executable work products).

-provides the ability to evaluate the quality of, and to build confidence in work products

-By verifying the documented requirements, the stakeholders can also make sure that these requirements describe their actual needs.

-Communication will also be improved between the involved stakeholders. For this reason, it is recommended to involve a wide variety of stakeholders in static testing.

-Code defects can be detected using static analysis more efficiently than in dynamic testing, usually resulting in both fewer code defects and a lower overall development effort.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

Differences between Static Testing and Dynamic Testing

A

-Static testing and dynamic testing practices complement each other.

-Similar because they support the detection of defects in work products

differences:
Static and dynamic testing (with analysis of failures) can both lead to the detection of defects, however 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, while dynamic testing can only be applied to executable work products

Static testing can be used to measure quality characteristics that are not dependent on executing code (e.g., maintainability), while dynamic testing can be used to measure quality characteristics that are dependent on executing code (e.g., performance efficiency)

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
17
Q

static testing code execution vs dynamic testing code execution

A

Static testing can be used to measure quality characteristics that are not dependent on executing code (e.g., MAINTAINBILITY ),

while dynamic testing can be used to measure quality characteristics that are dependent on executing code (e.g., PERFORMANCE EFFICIENCY)

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
18
Q

Typical defects that are easier and/or cheaper to find through static testing:

A

Defects in requirements (e.g., inconsistencies, ambiguities, contradictions, omissions [omission is something that has been left out or excluded], inaccuracies, duplications)

Design defects (e.g., inefficient database structures, poor modularization)

Certain types of coding defects (e.g., variables with undefined values, undeclared variables, unreachable or duplicated code, excessive code complexity)

Deviations from standards (e.g., lack of adherence to naming conventions in coding standards)

Incorrect interface specifications (e.g., mismatched number, type or order of parameters)

Specific types of security vulnerabilities (e.g., buffer overflows)

Gaps or inaccuracies in test basis coverage (e.g., missing tests for an acceptance criterion)

19
Q

can static and dynamic testing be applied to all test levels?

A

yes

20
Q

-A failure to deliver what the stakeholder wants can result in

A

costly rework,

missed deadlines,

blame games,

and might even lead to complete project failure.

21
Q

-If the required review is more formal,

A

then more of the tasks described for the different activities will be needed.

22
Q

work products with review

A

The size of many work products makes them too large to be covered by a single review.

The review process may be invoked a couple of times to complete the review for the entire work product.

23
Q

The activities in the review process are:

A

Planning. During the planning phase, 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, shall be defined.

Review initiation. During review initiation, the goal is to make sure that everyone and everything involved is prepared to start the review. This includes 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. Since the anomalies identified during a review are not necessarily defects, all these anomalies need to be analyzed and discussed. For every anomaly, the decision should be made on its status, ownership and required actions. This is typically done in a review meeting, during which the participants also decide what the quality level of reviewed work product is and what follow-up actions are required. A follow-up review may be required to complete 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.

24
Q

A review technique in which a work product is evaluated to determine its ability to address specific scenarios.

A

scenario-based review

25
Q

A review technique guided by a list of questions or required attributes.

A

checklist-based reviewing

26
Q

Reviews involve various stakeholders, who may take on several roles. The principal roles and their responsibilities in reviews are:

A

Manager – decides what is to be reviewed and provides resources, such as staff and time for the review

-is responsible for ensuring the availability of resources such as staff and time for the review process

Author – creates and fixes the work product under review
-responsible for fixing anomalies identified during review

Moderator (also known as the facilitator) – ensures the effective running of review meetings, including mediation, time management, and a safe review environment in which everyone can speak freely


Scribe (also known as recorder) – collates (collect and combine in proper order) anomalies from reviewers and records review information, such as decisions and new anomalies found during the review meeting

Reviewer – performs reviews. A reviewer may be someone working on the project, a subject matter expert, or any other stakeholder
-Examines the work product for errors or possible improvements

Review leader – takes overall responsibility for the review such as deciding who will be involved, and organizing when and where the review will take place

-Follows up on the implementation of required changes to the work product

27
Q

There exist many review types ranging from informal reviews to formal reviews.

The required level of formality depends on factors such as:

A

the SDLC being followed,

the maturity of the development process

the criticality and complexity of the work product being reviewed

legal or regulatory requirements

the need for an audit trail

28
Q

-The same work product can be reviewed with different review types, e.g., first an informal one and later a more formal one.

-Selecting the right review type is key to achieving the required review objectives.

The selection is not only based on the objectives, but also on factors such as the:

A

project needs

available resources

work product type and risks

business domain

company culture

29
Q

Some commonly used review types are:

A

Informal review,

Walkthrough,

Technical Review

Inspection

30
Q

do not follow a defined process and do not require a formal documented output. The main objective is detecting anomalies.

A

informal review

31
Q

walkthrough objectives

A

evaluating quality and building confidence in the work product

educating reviewers

gaining consensus

generating new ideas

motivating and enabling authors to improve

detecting anomalies.

-Reviewers might perform an individual review before the walkthrough, but this is not required.

example:
* Main purpose: detecting potential defects
* Use of checklists is optional
* May take the form of scenarios, dry runs, or simulations
* Individual preparation before the review meeting is optional
* Scribe is mandatory

32
Q

Technical Review objectives

A

A technical review is performed by technically qualified reviewers and led by a moderator.

The objectives of a technical review are:
gain consensus and make decisions regarding a technical problem,

to detect anomalies,

evaluate quality and build confidence in the work product,

generate new ideas

to motivate and enable authors to improve.

33
Q

Inspection

A

A type of formal review that uses defined team roles and measurement to identify defects in a work product, and improve the review process and the software development process.

As inspections are the most formal type of review, they follow the complete generic process

-The main objective is to find the maximum number of anomalies.

-Other objectives are to :
evaluate quality

build confidence in the work product

to motivate and enable authors to improve

–Metrics are collected and used to improve the SDLC, including the inspection process. In inspections, the author cannot act as the review leader or scribe.

34
Q

There are several factors that determine the success of reviews, which include:

A

Defining clear objectives and measurable exit criteria. Evaluation of participants should never be an objective

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 (when held)

Providing feedback from reviews to stakeholders and authors so they can improve the product and their activities (see section 3.2.1)

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

35
Q

collect and combine

A

collate

36
Q

can be applied for both verification and validation.

A

Static testing

37
Q

-can identify problems prior to dynamic testing while often requiring less effort, since no test cases are required, and tools are typically used.

A

Static analysis

38
Q
  • is often incorporated into CI frameworks
A

-Static analysis

39
Q

-While largely used to detect specific code defects, it is also used to evaluate maintainability and security.

A

static analysis

40
Q

-Spelling checkers and readability tools are other examples of

A

static analysis tools.

41
Q

can be created at different phases, such as requirements gathering, design, coding, testing, and deployment.

are the tangible outputs or artifacts that are produced during various stages of a project or process.

A

work products

42
Q

quality characteristics refer to

A

functional and non-functional testing

quality characteristics are about what qualities of the system you’re measuring.

43
Q

make less severe

A

mitigate

44
Q

to hold back

A

hinder

tester istqb cards (12 decks)

Brainscape helps you reach your goals faster, through stronger study habits.
© 2024 Bold Learning Solutions. Terms and Conditions