Alright folks, here’s the next installment of the play-by-play. This week was a shorter one due to observing the American holiday, and it was also shorter due to the huge wave of things happening this week (it was hard remember everything). Enjoy, and as always, I appreciate your comments.

Click on the “Read more” link below to view the full play-by-play.

Monday, Day 1:

1. Observed President’s Day, and stayed at home watching TV and reading Slashdot.

Tuesday, Day 2:

1. I proposed an idea to management called Testing Regression Days. Basically, there was need to do semi-formal regression testing after each internal release, so I wrote up a blog post that described a proposed method. In my excitement for the position [I'm now able to try out things in practice that previously were only described in theory] I wrote the post with more of an authoritative, Manager of the Testing Group-style tone. Although stakeholders loved the idea — especially doing charter regressions and not just simple verification (see the post) — one stakeholder said I should have checked with him first. [I totally agree. I definitely should have.] In hindsight, as of this writing, using exploratory testing for regression testing is a much deeper topic than I expected, and I think we’ve only hit the surface.
2. [Things are fuzzy as of this writing, but: ] I was just about to set the testers off on some new charters, when our sys-admin came storming in the room. He looked slightly panicked, and after raising his hands in the air to get everyone’s attention, he said, “[sic] We’ve had a security breach on one of our servers. Everybody needs to stop what they’re doing.” We didn’t know exactly what happened, but we did what we were told. [Whoa.]
3. I was later told the reason for the security breach which I should not repeat here, but one of the running themes for this day was “This was a network intrusion, and that ceasing all network activity will help the sys-admin out immensely.” Since we couldn’t use the network [Hence, we couldn't test the latest build -- or any build, for that matter -- since it lived on a central server.] I sent my testers off to do their other work while I spent time writing my first play-by-play. Testing for this day was pretty much halted.
4. As a side-effect of the security breach, our main site – http://www.openplans.org — was taken down, and a “We’re sorry for the inconvenience” message was put up in its place.

Wednesday, Day 3:

1. Today, generally, was the fallout period. The bomb was dropped yesterday, and today was the day we got everything back up. Our main site stayed down, and the sys-admin delved deeper into the details of the specific problem: How. When. Where. What needed changing, and how we should respond. As is my guess with all breaches, passwords were changed, and general infrastructure was improved.
2. Unfortunately, our main site was still down. With it was the blog I mentioned earlier, which prevented me from reporting the findings of the test group. How was I going to tell stakeholders what we were up do? During the flurry of it all, was I even going to?
3. Thankfully, our QA builds were back up, and were were able to start getting things done. We started back on some charters and tried recovering from the bombshell as best we could.

Thursday, Day 4:

1. Only a few things important this day. The first was that one of my testers found an okay bug; it wasn’t critical, but it wasn’t superficial superficial either. What was important about it was that the tester got my attention [She had a question.], which then sparked a great conversation about bug advocacy and about general report writing. I was happy with this conversation because I was able convey my ideas easily [This isn't always the case.] and she seemed genuinely interested in the topic. [I was thrilled. I loved it.] After finishing our conversation, and writing the bug report together, she submitted it and continued on what she was working on.
2. At the same time she submitted her bug, our triage guy [We have one guy that does triage for all bugs.] must have been on top of his game: He quickly found the bug my tester submitted, and decided quickly that it was a duplicate of a bug opened about 1000 tickets ago. [Aw man. It was a great report! We had a discussion!!! It was exemplary! How could it be closed???] It was closed, unfortunately, and to my dismay, was just nature of the beast. I thought about mentioning it to her, about saying that, “Even though it was duplicate, it was still a good bug,” but hesitation got in the way, and I eventually left it alone. Looking back, in hindsight, I think I was more affected by the result than she was.
3. The second thing important was news from management: “Because of such-and-such, and such-and-such-and-such, our Big Deadline is being pushed back by two weeks.” [What? Really???] Yes, it was. My first reaction was one of confusion, but then I became excited because it meant I had the position for another two weeksT I was told this was a calculated decision meant to make all of our lives easier. Whatever the rational, this meant the Big Deadline was now April 2nd.

Friday, Day 5:

1. While testing a charter, one of my testers pinged me on IRC and asked if there were “happy paths” of the product drawn up, and whether or not we would want to draw some. [Of course there weren't; we're flying by the seat of our pants.] This begged the questions: Who should draw them? Should we? Do we really need them? Will they help, or will they just make us feel better? If we draw them, how detailed should they be? To what extent should we rely on them? Would these box in our testing process, conforming more to the scripted-style of testing? Or am I just paranoid? I didn’t know the right answers to these questions, so I encouraged the tester to draw up whatever seemed helpful.
2. Putting my developer hat on, I had to make a change to a part of our software in order to facilitate testing. [I had to fix a bug that made a certain part of the project literally untestable.] After fixing the bug, and trying to update the “QA build” that we were using, and found that there were three different copies of the same piece of software! [I wasn't the one who organized this stuff.] I fumbled around for a little bit trying to figure out the one were actually testing from, but finally, and a bit of trial and error, I updated the build that needed to be updated. In hindsight, the copies of the build were clearly marked, but the folder organization was like the New York City subway: Although there’s signs, you’ll likely get lost the first time.
3. To my surprise, and without warning, the books I asked for in week one came in. [Thank you manager.]

UPDATE: Continue on to week three. >>