Full group retrospective

The blog team is using Bret as customer. RubLog is a combination of a CGI, a template, a document repository, and a URL that returns one HTML output. They’ve created a harness that copies the files for one blog (from multiple ones) to the places, then visits the URLs and detects chages. They prevent date/time info from getting in, and the harness will detect changes due to some change in RubLog. The template and CGI file are stored with the blogs, so one change should not break all tests.

Lesson for the day: When you run tests and think everything is passing, make sure you check the numbers of tests executed (they found they weren’t executing tests instead of everything was passing).

They also got into exploratory mutation testing — commenting out lines of code and running tests to determine where tests failed and then considering whether they needed tests to fill the gaps.

The vettest team opted for the CGI approach (don’t remember if I posted that or not) for our web server. We also decided to do acceptance testing through IE because in our spikes, that was the most successful approach given the time. We’re also doing it in part to question the belief that automation through the GUI is worse than through interfaces.

Brian posted three charts. One is comfort zone confessions — places where one claims to be pushing beyond one’s comfort zone but really have no intention of giving whatever they’re trying a fair chance. The second is comfort zone confirmations — places where we pushed beyond our comfort zones and found that the comfort zone feelings were actually correct. The final chart is for comfort zone celebrations — places where we pushed beyond our comfort zones and ended up changing our minds because we found there’s a better way. Bret questioned whether there was a lot of comfort zone pushing (which James speculated may be due to lack of tension because of people coming in an open mind). Jeremy said that one of the discussions last night (I think the acceptance testing/role of testing talk which I was not involved in) was pushing him far from his comfort zone.

Other pushing out the comfort zones mentioned (without naming names): the through the GUI testing the vettest team is doing, paired programming, multiple subroutines, lack of knowledge/experience with OO, Ruby, testing, lack of usefulness, and doing the same thing people do when they’re not here (came wanting vacation but ended up doing same thing). Another observation was made that there might be conflicting comfort zones and when one person is in their zone, others might be learning from them and be outside their zone.

Day 2 Group Retrospective

We split up into 3 sets of pairs (actually 2 pairs and a triple) to focus on three tasks:

• An acceptance testing framework (using the DOM)
• Conversion of data from word doc into usable stuff
• Developing an initial page that displays the case information

After spending the time to do the development, here’s where we stand:

• Acceptance testing — needs refactoring, approximates Brian’s test (posted earlier)
• Data conversion — needs some hand tweaking
• CGI — investigated alternatives, settled with thin GUI (CGI library)

Other retrospective stuff:

• The acceptance test triple was able to do lots of acceptance testing without “real” code
• Morning discussion (of acceptance testing approaches) meant less stories done
  

Test Ideas (Day 2 Iteration)

Beginning day 2, we decided to go with the cgi approach because it already handles POST requests. Since we’ll have 140 tests, the GET method of form submittal will quickly be unwieldy. We then delayed acceptance testing strategies until noon.

Then, we began brainstorming test ideas (the next story we’ll be implementing):

• Click a test and see results
• Submit with no tests selected
• Choose all tests
• choose tests, submit, choose tests, submit
• malformed requests — customer trust
• > 1 user
• browser compatibility

  Test 1 for QA2:
  start url
  expect main page
  submit
  expect main page
  click test 5
  expect same main page
  diagnostic info for 5
  click 1, 93
  expect same main page
  diagnostic info exactly 1, 93

Day #1 Wrap Up

First, I want to apologize for the last AF post (not the RSS feed one — the one before that). It’s chaotic and disjointed. Maybe I’ll edit it, though I think I have enough to do staying on top of the current stuff. The conversation that I was blogging was the hardest part of the day for me to blog. Part of the problem was I didn’t think about group dynamics and laptop power dynamics, so I was effectively sitting outside the circle of the group. There were also lots of comments back and forth and it was hard to summarize them. I’ll have to try something different for tomorrow’s wrap up session.

Second, Erik posted a couple of comments on the posts earlier today, and I figured I’d just address them in a new post (since I was doing one anyhow). His first comment is about FIT and the feasibility of holding off on it. I’m probably not the best person to talk about this, since I missed this evening’s discussion of FIT. I do know that at dinner, Cem said that he didn’t see how FIT would help them for the RubLog project, but that the vet stuff should be able to get some benefit from it. I imagine that I’ll pick up some more of what my team will do with FIT tomorrow.

Erik’s second comment asked whether we had already split into groups or we were doing the spikes as one group. We’ve already split. The RubLog stuff already has some mechanism for serving pages associated with it, so they didn’t need the spikes we did today. I think the teams are supposed to remain fairly set, though I don’t recall anything being said either way, so this is just my opinion. I think even after just one day, a person switching teams would have a large learning curve to climb to get up to speed and that’s only going to increase. Things like pair programming can help with that, and it might be an interesting experiment to try in a few days. I don’t know.

Third, the vet stuff is accessible from outside. I was going to put the URL here, but I don’t remember it at the moment. I’ll get it tomorrow (and leave this point in as a reminder to do so).

Fourth, Bret told me that he had put the stories for the RubLog project on the Agile Fusion Wiki. The stuff he’s putting up there is at http://www.testing.com/cgi-bin/agile-fusion?RubLogProject

Finally, some thoughts on blogging a live event. In my reading of others’ blogs, I’ve seen talk recently about live blogging (at some of the recent blogging conferences in particular). They warned that one of the dangers associated with live blogging was not participating as deeply. I think that was to some extent present for me today. Tomorrow, I may try posting a little less and summarizing a little more, but I wasn’t consciously trying to get everything today either, so I don’t know for sure how the entries will be different from today’s.

I did find, however, that the act of creating entries on the fly helped in my processing the information – it was clearer to me (particularly when I was trying to summarize people’s comments mentally) and it feels like it has “stuck” better than other similar types of events I’ve been in. Tying that into the more usual content of this blog (no, not my ongoing obsession with RSS feeds), it seems like I’m much more an active learner than I thought. I’m learning stuff better by creating the posts. At the same time, it could be argued that I’m doing both active and reflective learning (which does in fact correspond to my test results — I’m fairly close to the middle on most scales). The active part is in the explaining what I’m learning and what’s going on here to others (all of you reading this), while the reflective part comes from the summarizing and editorializing I do around the other stuff.

I guess it hadn’t hit me before how blogging could address both sides of a learning styles pair like this. Maybe that’s why I like it so much — it lets me exercise skills in both areas.

I’ll have to ponder that more. Anyhow, it’s off to bed now — stay tuned tomorrow for more Agile Fusion news (and the occasional other random thought should I have time for them

RSS Feeds

I just found mention of a new website, BlogStreet (http://www.blogstreet.com). It has a beta service where you put in the URL of a blog and it generates an RSS feed for it! (via Elwyn Jenkins)

Oh happy day! Happy day!

Group discussion

Did some stories, did some code mining, did a feature walkthrough (so they know where they’re going). Talked about what scenario testing is and what the role of testing is on projects. They’ve already found a big stack of bugs in the existing code.

Synopsis of their discussion of scenario testing:
Got through the demo and started trying to figure out things for tomorrow — came up with some programming tasks. Cem pulled the group back and suggested that they should ask whether any of them would want to use this product (even after doing some of the tasks) and figure out how they would approach answering the question. Cem suggested having a couple of people go off and learn a lot about blogs and blog features and who the appropriate customer for the tool is, then appraise the tool to determine where it is and where it isn’t. This led to discussion about whether the testing group sits as a service organization to the programming team or to the customers. They also talked about the technical tasks that a testing group performs that are out of the scope for the customers (bugs that customers will never imagine, tools the customer will never create, but which testers would find/create). This got cut off by time. Key moment (according to James): Mike said the reason there is a customer representative in an XP group is to have one concrete answer. This caused a concerned murmur from the testers, and served as an anchor point for the discussion. The tester serves as a source of light to illuminate customer decisions and other decisions the customer might want to make. Since testers are not primarily focused on designing and building the project, they’re freed up to look for potential problems and inconsistencies in case the customer rep does not fully represent the issues of the entire community. James sees programmers as primary client — all things good come from the programmers. Cem talked about how a key part of agile development is untraining the busy work from the testers and retraining them in how to be do more productive stuff

We had some interesting discussion about the planning game. Some people felt the planning game took too long (particularly given the time scale of this project), others (who weren’t used to XP planning games felt it took far less time than what they were familiar). Mike H. felt it was long because there were things that he would have liked to talk about later on, suggestions of more breaks and spreading the planning game out over the course of several days were also brought up. BC suggested that some of the stress came from our unvoiced assumptions conflicting together. Mike would prefer to let the assumptions float and deal with them when someone is about to code the story. Mike F. suggested spike time between story generation and estimation.
3 groups of people needing representation on project:

• Stakeholders — anyone impacted by product (includes end users)
• Stakeholdes with influence — stakeholders with power to influence design (includes anti-stakeholders, such as hackers)
• Representative

Cat food analogy — the people who buy the cat food don’t eat it, so most of the money goes into the packaging and not the contents of the can. Cats have traits that serves as reasoning for why they don’t like food. For software, the buyers don’t use it and if the users don’t like it, while they’re just finicky users.

Subtitling heuristic — Translate “No user would do that” as “No user that I can think of that I like would try to do that” What about hackers, accidents, that kind of thing?

Agency law — effectively reflecting someone else’s point of view

We began a list of things to do tonight:

• Anderson-style brainstorming styles of doing automated acceptance tests for HTML based applications
• Learn FIT
• Learn shams
• Discussion of the role of testing
• Discussion of difference between customer representative and stakeholder community