Ch3 Flashcards Preview

ISTQB > Ch3 > Flashcards

Flashcards in Ch3 Deck (15)
Loading flashcards...
1

Benefits of a Review?

Early defect detection and correction
Development productivity improvements
Reduced development cost and timescales
Fewer defects in code
Reduced time and cost of dynamic testing
Improved communication between testers, analysts, developers and users
Conformance to standards leading to improved maintainability of code and documents

2

What are goals of Reviews?

Verification and validation of documents against specifications and standards

Consistency with predecessor documents

Completeness and conformance to standards

Identification of defects such as -
Errors, omissions, additions, inconsistencies, ambiguities
Readability, terminology, spelling, grammar, layout, structure

Process improvement

Skills improvement

Consensus

3

What are the phases of a Formal Review?

Planning  Kick-off  Individual Preparation  Review Meeting  Re-work  Follow-up

4

What some characteristics of Informal Reviews?

Informal peer assessment of document or work
No formal process, objectives, roles, entry/exit criteria or metrics
Record of findings is often not kept
May be performed on partially complete products
Examples
Buddy reviews
Desk check
Pair programming
Technical leader reviewing designs and code
Varies in usefulness depending on the reviewers
Main purpose:
Find defects and encourage best practice cheaply

5

What some characteristics of Walkthroughs?

Meeting led by the author of document being reviewed
Peer group participation
May take the form of scenarios and dry runs
Open-ended sessions
Take as much time as is needed
Solutions should not be discussed, only issues
Should produce a review report including list of findings
Scribe should not be the author
May vary from quite informal to very formal
Walkthroughs are very useful for highly visual products via story-boarding, workflow tools etc.
Walkthroughs (and Inspections) should find defects but not propose solutions – that is the author’s task after the meeting.

Main purposes:
Learning, gaining understanding, finding defects.

6

What some characteristics of Technical Reviews?

Examination of document for defects and technical suitability
Includes peers and technical experts
Optional management participation for decision-making
Ideally led by trained moderator (not the author)
Pre-meeting preparation by reviewers
Optional use of checklists
May vary from quite informal to very formal
Produces a review report with
List of findings, verdict whether the software product meets its requirements and recommendations
Main purposes:
Discuss document, make decisions, evaluate alternatives, find defects, solve technical problems and check conformance to specifications and standards.

The key difference between a Technical Review and a Walkthrough is the presence of technical experts or specialists.

7

Define Planning:

Define review objectives
Select the personnel
Allocate roles
Define the entry and exit criteria
Select which parts of documents to review

8

Define Kick-off:

Distribute documents
Explain the objectives, process and documents to participants

9

Define Individual preparation:

Prepare for the review meeting by reviewing the document(s)
Note potential defects, questions and comments

10

Define Follow-up:

Check that defects have been addressed
Gather metrics
Check on exit criteria

11

Define Review meetings:

Discuss or log issues, with documented results or minutes
Note defects, make recommendations and decisions about them
Evaluate and record issues

12

Define Rework

Fix defects found, typically done by the author
Record updated status of defects

13

What are the main roles in the Review process?

Moderator and Manager

14

Benefits of Static Testing?

 Performed early in the lifecycle, before software is written
 Analyse code or documents without running software
 Find defects in code or documents directly
 Defects are cheap to fix
 Add quality into software

15

Benefits of Dynamic Testing?

 Performed late in the lifecycle, after software is written
 Execute software and analyse results
 Observe failures in system which could identify defects in code
 Defects are expensive to fix
 Check quality of software