ok, let me put that in another way: half_even errors would be tested by using values that we know will produce errors under a half_even rounding scenerio.. and AFAICS, we haven't given qa any numbers like that, have we? Yet another way: surfacing half_even rounding errors the way we would get them would be hard to do, no? Given that... should we test the exact numbers we need to produce half_even rounding errors (in the old code) in order to show that there is not longer errors? Or are we good with just getting good numbers for variously scaled numbers as Nancy has done?

I don't know that this really tested anything about half_even rounding per se. To do that we would need to be much much more precise with a QA test plan... But if the plan was to make sure we didn't create new trouble by fixing the it, then I think the test is good enuf.

I agree that it is sufficient testing.

Looks like sufficient testing. What do others think?

SmartSite@UCDavis - 2.6.4.2 - Sakai 2.6.2 - Server "ucddev1"
gb2 v1.4.0-a4

TEST PROCESS
site DDD 123 123 w11, category, points, weighted by points
1 - have multiple items, assorted point values, multiple participants
2 - graded single items with varying point values, @ variety of scores, and checked course grade rounded as expected
3 - graded multiple items of equal weight (same point value) @ a variety of scores/items, for the same person, and verified course grade rounding
I can provide scores if needed but it's really boring.

once I figured out the rounding calculation method, everything rounded correctly.

I did NOT check multiple items with different weights. emailed Thomas if I need to be that obsessive.

QA RESULTS -
pass
unless I need to test more