Section 0005.e ended with the need for evidence of what each student can do, and assessment is how a teacher gathers that evidence and puts it to use. Assessment is best understood as a cycle. It starts with a purpose, since the same task can serve different ends. It continues with gathering evidence, through quick checks during learning, rubrics for larger work, and explanations that reveal understanding behind a finished product. Then the evidence is interpreted, by looking for patterns across the class and within groups. Finally, it is acted on, both by the teacher, who adjusts instruction, and by students, who use feedback to improve. This section follows that cycle.

Purposes: formative and summative#

The first distinction is about purpose. Formative assessment gathers evidence during learning to guide next steps, informing both teacher and students while learning is still under way. Summative assessment evaluates learning at the end of a unit, as an end-of-unit project graded with a rubric does. In a unit with short daily checks and a graded final project, the daily checks are formative and the project is summative. What defines the category is how the results are used, not the format of the task: the same quiz is formative if it shapes tomorrow's lesson and summative if it produces a final grade. Stakes matter as well, because they affect whether the evidence is honest. If exit tickets count heavily toward grades, students have reason to copy answers or hide confusion, so using tickets as low-stakes evidence for planning, instead of as grades, keeps the information they provide trustworthy.

Gathering evidence#

Formative assessment depends on tools that are quick enough to use often and revealing enough to act on. Useful formative tools in computer science include exit tickets, short tasks completed at the end of a lesson, such as one code-tracing question; code-tracing questions in general, which show whether students can follow what a program does; Parsons problems, described under 0005.d; peer code review, in which students read and comment on each other's code, giving feedback during the work; and observation with a checklist. Observation captures practices as they are being carried out, such as how students test, debug, or collaborate, which are hard to see in a test. A brief one-on-one walkthrough, in which a student explains a piece of code, reveals understanding directly. Automatic graders have a place too, but they are limited: they may show that code works without revealing why it works or how the student got there, so other tools are needed to reveal reasoning.

Larger work calls for a rubric, which makes the criteria for quality explicit. A rubric for a programming project can assess functionality, design, readability, and process separately, instead of scoring only whether a program runs, and a rubric that awards all its points for a working program doesn't assess readability or design at all. Criteria should reflect what the course values. Sharing the rubric with students before they begin, along with examples of quality work, lets students see what quality looks like and guides their work. Each criterion needs a clear definition. A criterion such as "creativity" with no description makes grading inconsistent, since different graders, or the same grader on different days, will read it differently, and vague criteria may also favor students who already share the teacher's unstated expectations.

A finished artifact, however, can hide what its maker understands, which is why authentic assessment of project work combines artifacts with explanations. Code walkthroughs, in which a student explains the program, and written reflections from each student help show each student's understanding. This matters most where the artifact alone is ambiguous: in group work, where one student may have done most of the coding; with copied code; and with code produced by generative AI. Explanations, process, and live modification of code are much harder to outsource than a finished product, so assessment that gives them more emphasis shows understanding more reliably. If a teacher suspects that a student didn't write submitted code, asking the student to walk through and modify it checks understanding without making assumptions. A reflection prompt such as "Describe a bug you found, how you diagnosed it, and what you would do differently" reveals both process and metacognition, the student's awareness of their own thinking.

Interpreting evidence#

Evidence is useful only when someone looks at it for patterns. Teachers should examine assessment results for patterns and then decide whether to reteach, regroup, or offer extensions. If many students' answers on a nested-loop question show that they believe the inner loop runs only once in total, the pattern points to reteaching how the inner loop runs for each pass of the outer loop, using tracing. If only some students miss questions about boundary cases, a small-group lesson on boundaries while the others take an extension targets the specific error without holding everyone back.

Two further habits make interpretation more accurate. The first is to disaggregate results, separating them by group, such as by gender or by role in group projects. Data broken down this way can reveal equity issues that total scores hide, such as how classroom structures and group roles affect who participates and who learns. The second is to question the assessment itself. If nearly everyone misses a question, the likeliest explanation is that the question or the instruction was flawed, not that the whole class failed to learn, and looking at how students answered each question can reveal which.

Acting on evidence: feedback#

The teacher's response to evidence is adjusting instruction, and the student's response depends on feedback. Effective feedback is timely, specific, and directed at how to improve. "Your loop works for typical input. Try an empty array and trace what happens to total / size" is specific and gives a next step, which "Good job" or "Check your edge cases" doesn't. Feedback should be directed at the task, not the person, so "This variable name hides its purpose; try one that says what it holds" helps where "You're careless with names" doesn't. Timing matters because feedback is useful only while students can still act on it, which is why feedback on drafts does more than comments on a final submission. Feedback in programming should also treat errors as a normal part of the work, which they are for every programmer. Sharing debugging stories, including the teacher's own, and giving credit for diagnosing errors treat errors as information and support persistence. All of these practices assume that every student has a fair chance to learn and to show it, and 0005.g turns to what that requires.

• formative assessment: assessment during learning that guides next steps
• summative assessment: assessment that evaluates learning at the end of a unit
• exit ticket: a short task completed at the end of a lesson
• peer code review: students reading and commenting on each other's code
• rubric: a scoring guide that makes criteria explicit
• authentic assessment: assessing artifacts together with explanations, such as code walkthroughs and reflections
• code walkthrough: a student explaining how a program works
• metacognition: awareness of one's own thinking
• disaggregating data: separating results by group to reveal patterns that totals hide
• feedback: information to a student that is timely, specific, and directed at how to improve

Practice: practice questions for 0005.f