Re-tracing a corrected algorithm

Name:

Date:

Class:

Quick Questions

Shade in the A or B circle for each question.

1. You fixed a bug that gave the wrong output for the input 5. What should you do first to check the fix?

A Trace it using a brand new input and forget about 5

B Trace the corrected algorithm again using the input 5

2. Which is the better way to re-trace a corrected algorithm?

A Draw a new trace table and fill it in from the start

B Reuse the old trace table and only change the last row

3. Your re-trace with the failing input now gives the expected output. Are you finished testing?

A No, test other inputs that take the other paths too

B Yes, one passing trace proves the whole algorithm works

4. An algorithm has IF mark >= 50 THEN OUTPUT "Pass" ELSE OUTPUT "Fail". You fixed the operator and traced mark = 60. What should you also trace?

A A mark below 50, such as 30, to test the ELSE path

B Another mark above 50, such as 70, to test the THEN path again

5. After your fix, an input that used to work now gives the wrong output. What does this tell you?

A The fix is fine because the original bug is gone

B The fix created a new error that needs to be found

Match the Pairs

Draw a line connecting each item on the left to its match on the right.

Left column		Right column
1Input 45, expected 'Pass', actual now 'Pass'		Ascore \| passed \| OUTPUT 45 \| Yes \| Pass
2New trace table: score 50, 49, 100		BTest 1: score 80 -> expect Pass Test 2: score 20 -> expect Fail
3Start a fresh trace table for the same failing input after the fix, and fill it in again from the first step		CRe-tracing with the same input that failed shows the fix worked: the actual output now matches the expected output.
4Test the other paths too: use one input for the IF branch and one for the ELSE branch		DTrace the corrected algorithm with other inputs too, so every path is tested and the fix did not create a new error.
5Fix made: changed > to >=. Only re-traced the other inputs, not the failing one.		EOnly one input and one path was checked. Test the other paths too, to make sure the fix did not create a new error.
6Fix made. Traced score 50 only. Output is correct, so the algorithm is finished.		FThe original failing input was not traced again, so you cannot be sure the fix solved that error. Re-trace the same failing input first.

Definitions

re-trace

Fill in the Blanks

Complete each line of code by filling in the missing parts.

IF mark __ 50 THEN OUTPUT "Pass" ELSE OUTPUT "Fail"

INPUT n REPEAT _ TIMES OUTPUT "Hi"

IF age >= 13 ___ age <= 18 THEN OUTPUT "Teen" ENDIF

IF score > 50 THEN OUTPUT "Pass" ____ OUTPUT "Fail"

average ← total _ count OUTPUT average

Spot the Error

Shade in the letter of the line that contains an error.

Question 1

A SET total ← 0

B REPEAT 3 TIMES

C SET total ← total + 2

D OUTPUT total + 2

Question 2

A INPUT marks

B IF mark >= 50 THEN

C OUTPUT "Pass"

D ELSE

E OUTPUT "Fail"

Question 3

A SET count ← 0

B WHILE count > 3

C SET count ← count + 1

D OUTPUT count

Question 4

A INPUT age

B IF age >= 13 OR age <= 18 THEN

C OUTPUT "Teen"

D ELSE

E OUTPUT "Not a teen"

Question 5

A INPUT a

B INPUT b

C SET total ← a + b

D SET average ← total / 3

E OUTPUT average

Answer Key

Re-tracing a corrected algorithm

Section A: Quick Questions

B — Trace the corrected algorithm again using the input 5

A — Draw a new trace table and fill it in from the start

A — No, test other inputs that take the other paths too

A — A mark below 50, such as 30, to test the ELSE path

B — The fix created a new error that needs to be found

Section B: Match the Pairs

Input 45, expected 'Pass', actual now 'Pass' → Re-tracing with the same input that failed shows the fix worked: the actual output now matches the expected output.

New trace table: score 50, 49, 100 → Trace the corrected algorithm with other inputs too, so every path is tested and the fix did not create a new error.

Start a fresh trace table for the same failing input after the fix, and fill it in again from the first step → score | passed | OUTPUT 45 | Yes | Pass

Test the other paths too: use one input for the IF branch and one for the ELSE branch → Test 1: score 80 -> expect Pass Test 2: score 20 -> expect Fail

Fix made: changed > to >=. Only re-traced the other inputs, not the failing one. → The original failing input was not traced again, so you cannot be sure the fix solved that error. Re-trace the same failing input first.

Fix made. Traced score 50 only. Output is correct, so the algorithm is finished. → Only one input and one path was checked. Test the other paths too, to make sure the fix did not create a new error.

Section C: Definitions

re-trace — After a fix, trace the algorithm again with the same failing input, then other inputs, to check the output now matches what was expected.

Section D: Fill in the Blanks

IF mark >= 50 THEN OUTPUT "Pass"
ELSE OUTPUT "Fail"

INPUT n
REPEAT n TIMES
  OUTPUT "Hi"

IF age >= 13 AND age <= 18 THEN
  OUTPUT "Teen"
ENDIF

IF score > 50 THEN OUTPUT "Pass"
ELSE OUTPUT "Fail"

average ← total / count
OUTPUT average

Section E: Spot the Error

D — After a fix, a new trace table with the same input shows total is 6, so the output should be 6. OUTPUT total + 2 prints 8, so the output does not match what was expected. It should be OUTPUT total.

A — The variable is read in as marks but the IF tests mark. When you re-trace with the same input, mark has no value. The first line should be INPUT mark.

B — Re-tracing the corrected algorithm shows count starts at 0, so count > 3 is false straight away and the loop never runs. The condition should be count < 3 so it outputs 1, 2, 3.

B — With OR the condition is true for every age. Testing the other paths with age 10 gives "Teen" instead of "Not a teen". It should be AND so both conditions must be true.

D — A fix can create a new error, so re-trace it. Two numbers were added, so the average must divide by 2. Dividing by 3 gives the wrong output, for example a=4 and b=6 gives 3.33 instead of 5.