[Systers-dev] Status of testing bug 506024

[Robin Jeffries]

Well, we finished the "pretesting" (in a real world, this would be unit
testing, and would be done by the developer (me), but it took emails being
sent and received by 5 different addresses, so it really "took a village" to
test this.  And each time I would look harder for the main bug, I would find
new ones.)

We are ready to start the real testing cycle.  The bug where badly formed
unsubscribe-from-conversation URLs cause a crash is not fixed (that is
tested by SBT10), but I will be off the grid for the next 2 days, so I can't
fix it till then.  I don't believe that it interacts with any of the other
bugs, and we could push this set of changes without having fixed that.

Kathy Gee, the release coordinator is creating some new lists so that things
can be tested fresh.  As we learned (thanks Kari, Kathy and Malveeka), the
SBT bugs take some significant coordination, but once we got past the bug,
they can be done in about 20 minutes or so.  The others can be done by
individuals mostly.  We would love for folks to sign up for a fraction of
the tests.  Asking questions about what you are really supposed to be doing
to do a specific test is the only way we will get our instructions complete
and clear, so ask away.

One issue: I found another bug that has only cosmetic implications (and
seems to have been around forever), but I couldn't figure out the solution
(got far enough to convince myself it wasn't interacting with the other
bugs), so I've filed a new bug
https://bugs.launchpad.net/systers/+bug/513110 and we will fix it later.
 HOWEVER, it has implications for testing this set.

For various tests, you are asked to subscribe to a list and set your
preferences for "Subscribe to new conversations" to yes or no.  When you go
into your options page for the list, it will initially show you to have that
set to No.  It lies.  (more correctly, this info is stored in two places and
they are out of sync.  But all decisions about sending you emails are based
on the sql database value, which is not the value you see there).  So
   - do not trust the value you see there, especially if it is set to No
   - when you change it, you will need to change it to yes, press submit,
then change it to no, and press submit again.  Otherwise, the code is being
smart, and thinks that no real change has been made (it went from no to no)
and no change is made to the database.

If you forget these steps while testing the SBT bugs, there will be quite a
bit of confusion and it may look like we have bugs (we do, but our tests are
not testing that bug).

Enjoy.  I hope to come back to a set of passed tests, and we can push these
changes over to systers this weekend and get back to conversations that are
not trashed by replies going into the bit bucket.

Robin