An unexpected event in the last week has caused me to have to write three tests in less than two days. It often takes me at least that long to write *one* test, and I started thinking (now that they’re finished) about the test writing process. If you’ve ever written a test before, you probably know what I’m talking about, but if not, let me give you a little insight.

The first thing I do is create an outline. Well, not so much an outline as a list of problem types I’d like to have in the test. Almost immediately after that, I have to pare down the list because the second thing I consider is time. It’s difficult to ask more than about 10 questions on a 50-minute test, and if there are proofs involved—yeesh. Then there are the times when I already have a great problem in mind but soon realize that it would have to be the only problem on the test. At this point I have a tentative-but-probable list of problem types.

The next step is the hardest part: actually writing the problems. Fortunately, it’s usually the most fun, too. I am a firm believer in “nice” answers, so I often reverse engineer my problems. This typically involves starting with a problem, solving it, then tweaking coefficients or other parameters to give the desired result. If I’m feeling particularly adventurous, I’ll solve the problem with variable parameters, then solve an equation to find the necessary values for those parameters. For example, if I want a Laplace transform to end up having a nice partial fraction decomposition like

then I can rearrange the equation to get

and this now suggests possible differential equations that will lead to this form. Say

or

By starting with a solution I’m happy with, I can work backwards to create a problem that will give that solution. (Actually, I started with a different partial fraction decomposition:

but that leads to the wrong kind of differential equation. See, I even tweak my examples!)

Once the problems are written, it’s time to organize them. Spacing and problem order can take a surprising amount of time. I like to put a relatively easy problem on the first page so students get off to a good start. (Of course, that can backfire, so I try to be very careful with what I call “easy”.) The last page almost always has the hardest question(s) because they often require the most space. I also tell my students that it is possible to judge (my evaluation of) problem difficulty based on the amount of space provided. If you only have 0.5″ to answer the question, if probably wasn’t meant to be hard. On the other hand, if you only took three lines to answer that full-page problem, you might want to go over it again.

The last step is assigning points. I used to make every test worth 100 points, but that meant for a 10-question test, the questions averaged 10 points each. Sometimes that makes sense, but “Compute the derivative of cos(2*x*)” doesn’t really feel like a 10-point problem, does it? Now I assign point values based on how much I think the problem is worth, and the test is worth whatever the total is. A 62-point test? OK. Maybe 48 points? No problem.

So there you have it. Writing tests takes more work than you might have thought. How about all you teachers out there? What do you do when you write tests?

Tags: reverse engineering, tests, writing

November 29, 2007 at 7:40 pm |

Ah, yes, test writing. Seems to me that it should get easier, but it seems like it takes me just as long to write a good test as it did years ago.

I’ve done reverse engineering in Calculus: it’s particularly nice when you have a problem involving Critical Points, because it’s nice on a test if the derivative factors nicely (or doesn’t, depending on the point you want to make). Or in Linear Algebra, especially with Eigen-stuff problems.

One trick I’ve also found is not to have 1 point on the final equal 1 point on exams. I used to make mid-semester exams 100 points but since exams might be 20% of the final grade and the final exam might be 30%, that required a final exam with 150 points. In theory it was nice to have a lot of 10 point problems on the final; in reality I found my students got bogged down. Now I don’t worry about matching, and I just weight the exams accordingly.

January 25, 2008 at 11:19 am |

I also very rarely give 100-pt tests. I teach pre-calculus, and it’s hard to give a test or quiz with more than 10 or 15 questions because we also have only 50 minutes (minus the 5 minutes just getting ready to take the test!). I usually make up the tests and then assign point values for each question… so I, too, end up with tests worth 72 or 85 or some other random number of points. I remember while I was student teaching that bothered my supervising teacher (the one assigned from my university who was an English teacher). She thought that tests should all be 100 points. (Guess that makes the percentages easier to figure!)

January 25, 2008 at 7:53 pm |

Before I switched to my current grading scheme (based on percentages), I used a total-point grade: (pts earned)/(pts possible). It made more sense to make the tests uniform in that case, since that was the only way to have them weighted equally. Now, I don’t need to do that – I could even make the tests worth 1000 points, though my students might object to that.

January 26, 2008 at 7:13 am |

It was quite liberating (and a huge time-saver) to give up on the idea of 100 point exams. Sometimes 1/4 of the time spent in test preparation could be taken up by fudging points up and down, aiming for a total of 100 without making any one problem too significant.

The 1000 point idea resonates with me. Inevitably when grading a 67 point exam, I find myself staring at student work on a 4 point problem and wanting to give 2 1/2 or 3 1/2 points out of 5. So I do, and my students tolerate it, probably better than if that 4 page exam was worth 500 points and all scores were natural.

January 29, 2008 at 6:18 am |

[…] Review Sheets I was re-reading the post Writing Tests recently, and thinking about how I prepare for exams. In particular, I was thinking about how I […]