Inspections and Reviews

27.09.2016

Tensu & Sten

28.9.2016TUT / PERV COMP TIE-13106 1

Content

• Definitions

• Important in course inspections

• Inspection diary/record examples

• Other kind of inspections

28.9.2016TUT / PERV COMP TIE-13106 2

Inspections and reviews

• Inspection (tarkastus) = formal, the whole material is scanned through, a diary/memo is logged/written. Purpose is to find all kind of errors.

• Review (katselmointi, katselmus) = less formal, perhaps only certain parts of the material is reviewed, a diary/memo is not necessary kept. Purpose may be more like checking that phase or product.

28.9.2016TUT / PERV COMP TIE-13106 3

28.9.2016TUT / PERV COMP TIE-13106 4

3.1439 inspection• 1. a visual examination of a software product to detect and identify software

anomalies, including errors and deviations from standards and specifications. IEEE Std1028-2008 IEEE Standard for Software Reviews and Audits.3.3.

• 2. a static analysis technique that relies on visual examination of development products to detect errors, violations of development standards, and other problems

• 3. [Technique] examining or measuring to verify whether an activity, component, product, result, or service conforms to specified requirements. A Guide to the Project Management Body of Knowledge (PMBOK® Guide) - Fourth Edition

• NOTE Inspections are peer examinations led by impartial facilitators who are trained in inspection techniques. Determination of remedial or investigative action for an anomaly is a mandatory element of a software inspection, although the solution should not be determined in the inspection meeting. Types include code inspection; design inspection.

3.2562 review• 1. a process or meeting during which a work product, or set of work products, is

presented to project personnel, managers, users, customers, or other interested parties for comment or approval

• 2. a process or meeting during which a software product is presented to project personnel, managers, users, customers, user representatives, or other interested parties for comment or approval. IEEE Std 1028-2008 IEEE Standard for Software Reviews and Audits.

28.9.2016TUT / PERV COMP TIE-13106 5

Vocabulary = ISO/IEC/IEEE 24765-2010

Inspection team roles

Author

• prepare and revise the product

• make sure the product to be inspected is ready

Moderator

• lead the inspection

• make sure the inspection situation is efficient

Secretary

• document and classify findings (all, right)

• make sure the diary/record is complete

Inspector

• verify the product (inform all findings)

Reader (in code inspections only)

• tries to explain aloud what the code does.

28.9.2016TUT / PERV COMP TIE-13106 6

• Everybody should read the whole material (document/code) carefully before the inspection meeting

• Everybody marks suspected errors (findings) on his/her own material (paper copy or electronic version)

• Everybody has the commented material (paper copy or electronic version) with him/her in the inspection meeting

• The inspection meeting goes fluently if everybody has done the reading and error-marking beforehand.

28.9.2016TUT / PERV COMP TIE-13106 7

Important on course inspections, 1

• Inspection forms are: • summary and • findings list

• Inspection times will be at Moodle2 (Tensu(mandatory) and Coach (optional))

• Reserve such a time-slot (2 h) when the whole group can attend (start is at xy:00 hours)

• Material to be inspected can be updated, delivery to course staff should be three days before the inspection meeting.

28.9.2016TUT / PERV COMP TIE-13106 8

Important on course inspections, 2

• Timer clock can be started, when secretary/recorder starts filling the inspection forms

• At first secretary fills – "header information" (group, date, inspection

target,…) to both sheets – everybody's name and personal preparation

time for this inspection meeting (rounded to closest 15 minutes)

– number of everybody's personal findings (such ones that would be said aloud, no obvious typos)

– number of pages / LOC.

28.9.2016TUT / PERV COMP TIE-13106 9

Important on course inspections, 3

• Before start moderator checks that – everybody is present, and all have 2 hours

time for the meeting – everybody has the same material (modification

date, version number, number of pages)

• Everybody says one positive comment about the material (some detail), e.g. section x.y

• Then material is scanned through, led by the moderator. The first pages (cover page, version history, TOC) can be handled one by one, after that starting from chapter 1, section (x.y) by section.

• Mobile phone penalty is active, be wise.

28.9.2016TUT / PERV COMP TIE-13106 10

Important on course inspections, 4

• On document inspections, the findings list should be visible to attendees all the time. All inspectors can see easily if secretary did understand the comment right, and if (s)he keeps on with the pace.

• On code inspections, the code listing may be visible on most of the time (reading), and the findings list when secretary fills it, and when asked. So secretary would swap the view on screen between code and findings list.

• On code inspection, the reader/presenter (another coder, not the author) explains the code and others follow.

28.9.2016TUT / PERV COMP TIE-13106 11

Important on course inspections, 5

mod

sec

28.9.2016TUT / PERV COMP TIE-13106 12

28.9.2016TUT / PERV COMP TIE-13106 13

28.9.2016TUT / PERV COMP TIE-13106 14

Code inspections at TUT findings (average)

0

5

10

15

20

25

30

avg

stddev

TUT / PERV COMP TIE-13106 28.9.2016 15

Code inspections at TUT speed LOC / hour (average)

0

100

200

300

400

500

600

700

800

900

LOC/h

riviä/h

TUT / PERV COMP TIE-13106 28.9.2016 16

Code inspections at TUT total time / finding (min) (average)

0

10

20

30

40

50

60

kok.aika/löydös

TUT / PERV COMP TIE-13106 28.9.2016 17

Other kind of inspections

• Inspection meeting around the same table is the most effective, but it takes most time

• Many ”busy” companies and workers use asynchronous inspections: – everybody comments material – sends that to secretary, who makes summary – that summary may be reviewed, or just sent

to author.

• There are some inspection tools on web

• Even ”e-mail inspections” have some use…

TUT / PERV COMP TIE-13106 28.9.2016 18

Peer reviews in code version control

You may use peer reviews as partof continuous integraton;

GitLab

• merge request

GitHub

• pull request

28.9.2016TUT / PERV COMP TIE-13106 19

Some QA wall tables…

Rotten software is made, not born.

Bugs don't cause faults, programmers do.

Almost right means wrong.

Code smart, not hard.

Pain is temporary, pride is forever.

Trust no one.

Good code comes only by following the rules.

MOTIVATION IS EVERYTHING !!

28.9.2016TUT / PERV COMP TIE-13106 20

28.9.2016TUT / PERV COMP TIE-13106 21