Post on 26-Jun-2020
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