CHAPTER 3 STATIC TESTING Flashcards

Question

SCRIBE (recorder)

Answer 1

• gathers potential anomalies detected and reported as part of individual review • records new potential defects found during the review meeting, as well as decisions made at the meeting • should be invisible to the participants - „transparent”

Answer 2

• conducts a review, identifying potential defects in the work product under review • can be a subject expert - person working at the project - stakeholder - person with specific technical or business experience • can represent different viewpoints (of a tester, developer, user, operator, business analyst, usability specialist)

Answer 3

• bears overall responsibility fir the review process • decides who is to participate in the review, determines the place and date of the review • responsible for organising meetings

Answer 4

• INSPECTION most formal type - documented procedures - participation of pre established team - mandatory documentation of results • TECHNICAL REVIEW less formal • WALKTHROUGH less formal • INFORMAL REVIEW - no need for a defined process, info obtained doesn’t need to be formally documented

Answer 5

•BUDDY CHECK - PAIR REVIEW MOST COMMON IN AGILE PROJECTS CONVERSATION IN A KITCHEN MAIN GOALS detect potential defects POTENTIAL ADDITIONAL GOALS • generate new ideas, quickly solve simple problems FORMAL PROCESS • No formal process • can be run by an author, author’s peer, group of people DOCUMENTATION documentation is optional

Answer 6

SEQUENTIAL REVIEW OF WORK PRODUCT Usually when team can’t identify the cause of a software failure DRY RUNS E.g. manual simulation of the code execution - analyzing code line by line CODE REVIEW • MAIN GOALS: detect potential defects, improve quality, consider alternatives, evaluate compliance with standards POTENTIAL ADDITIONAL GOALS exchange information, train participants, teach consensus FORMAL PROCESS optional individual preparation before the meeting ROLES meeting usually chaired by the author, scribe present DOCUMENTATION OF RESULTS optional defect logs and review reports are created LEVEL OF FORMALISM from informal to formal, vantage form of scenarios, dry runs ot simulation

Answer 7

Performed by a technically qualified person „Expert panel” making design or technical decision that has a major impact ont further development MAIN GOAL obtain consensus, detect potential defects POTENTIAL ADDITIONAL GOALS assess the quality of a work product, increase confidence in it, generate new ideas, motivate authors to improve future work products, evaluate alternatives FORMAL PROCESS mandatory individual preparation before ROLES moderator conducts the meeting, not the author, scribe present DOCUMENTATION OF RESULTS defect logs and review reports LEVEL OF FROMALISM from formal to informal, review meeting optional

Answer 8

MAIN GOALS detect potential defect, assess quality od the work product, i increase confidence, prevent similar defects from occurring in the future POTENTIAL ADDITIONAL GOALS motivate authors to improve future work products and the software development process, create conditions for it, reach consensus FORMAL PROCESS formal process based on rules and checklists, mandatory individual preparation ROLES strictly defined, moderator leads the meetings, not author, scribe, reader role optional DOCUMENTATION OF RESULTS defect logs and review reports LEVEL OF FORMALITIES formal, entry and exit criteria, checklists. Measures are collected that are used to improve the process

Answer 9

1. 40,51% documentation defects 2. 23,20% non-compliance with standard 3. 7,22% defects in logic 4. 6,57% functional defects 5. 4,79% syntax defects 6. 4,62% data defects 7. 4,09% maintainability defects

Answer 10

• TIME TO PREPARE PER DEFECT • TIME TO PREPARE PER MAJOR DEFECT • NUMBER OF CRITICAL DEFECTS PER 1000 LINES OF CODE • NUMBER OF NON-CRITICAL DEFECTS PER 1000 LINES OF CODE • NUMBER OF LINES OF CODE CHECKED IN 1H • NUMBER OF DEFECTS PER SESSION • EFFORT TO PREPARE VERSUS EFFORT TO INSPECT • NUMBER OF LINES CHECKED IN ONE SESSION

Answer 11

• COMPLETENESS • CORRECTNESS • COHERENCE • STYLE • CONSTRUCTION RULES •

Answer 12

PLANNING —> REVUEW PREPARATIONS —> CHECKING ENTRY CRITERIA —> INSPECTION —> CHECKING EXIT CRITERIA —> REPORT PREPARATION —> FINAL ACTIONS

Answer 13

WALKTHROUGH Overall objective: do the right job Specific objective: education, consensus, understanding Trigger: author’s request Measurement: walkthrough instances INSPECTION O.O: do the job right S.o: defect detection, compliance checking T.: phase exit criteria M: product and process measurements

Answer 14

• selection of a proper review type and review technique for given situation and good for the team • having clear objectives defined during planning phase that can serve as measurable exit criteria • various review techniques used effectively to identify defects present in a work product • checklists used up-to-date and address the main risk • large documents are written and reviewed in batches - quick and frequent feedback • sufficient time to prepare for review - review scheduled in advance • authors are given feedback from reviewers • management support the review process • reviews are considered a natural process supporting progress and learning • involving people whose participation is conductive to achieving goals (different skills and view points) • involving testers and their viewpoint • allocation of sufficient time by participants • conducted in small pieces • detected defects are acknowledged, confirmed, and dealt with objectively • no waste of time activities • mutual trust and respect - judging product not a person • no gestures and behaviours suggesting boredom, hostility, irritation • due training • atmosphere supporting expanding knowledge and improvement

Answer 15

1. AD HOC REVIEW unstructured - each reviewer finds defects - little guidance sequential reading of the work product 2. CHECKLIST-BASED different reviewers, different checklists to increase the coverage - checklists max 10 items 3. SCENARIOS AND DRY RUNS based on use cases - dry runs: checking the product functionalities, also if it’s described correctly - taking into account risk analysis 4. ROLE-BASED REVIEW review from particular perspective, e.g. certain stakeholder - taking into account different types of end users or roles in the organization (user, administrator, performance testers etc.) - roles modeled by persona 5. PERSPECTIVE-BASED READING most effective - taking perspective of user, business analyst, designer, tester, system administrator, technical support engineer, regulator etc. - considering multiple views - different uses of a work product - balancing viewpoints