Just finished attending Pacific NW Software Conference (PNSQC) 2008

The proceedings (PDF) will be freely available online in about a month.

Monday, I attended Janet Gregory’s workshop on Test Quadrants (from Marick’s blog):

Doing Q2 (story/acceptance Test Driven Development) first makes Q1  (unit TDD) easier.
Supporting the team tests are done before the code is created.

Pair testing with Dev+Test and Dev driving (keyboard) help Dev’s understand how testers think.

Focus on:  “Steel thread” / “thin slice”, that is End to end - something goes thru

Once devs do it, they understand Why - improves testability

Steel thread code may not be complete - could have some things hard coded.

Add layers of testing - multiple steel threads

How to intro?  Ask them to try it 2-3 iterations.

 There is a little bit of rework if you don't build bottom up, but more testable.

With FIT tool,

Takes time to write fixtures.   On average 4 hours/fixture.

Initially every new story requires 1 or more next fixtures.

2 different attendees had tried FIT and stopped using it.  (Chet Hendrickson also mentioned after Wed. Keynote that FIT wasn’t always suitable for them).

Pair (test+dev) in the fixing of a function test so devs don't change the intent of a test.

Critique Product tests are done after code created.  Q3 is Exploratory Testing and End2End business scenarios.   Q4 is performance and ilities testing.

Tuesday

Sam Kaner’s Art of building consensus focused on meeting leader or facilitator for gathering information meetings and group problem solving.  See his Facilitator's Guide to Participatory Decision-Making for many details.  This was the basis for LAWST style workshop facilitators.

In gauging agreement, he uses 8 point “congruence” scale.    Agile folks have talked about the first of 5:                5 fingers:                 Completely and enthusiastically agreed
                4 fingers:             Agree
                3 fingers:             Neutral, but willing to support.
                2 fingers:             Disagree
                1 finger (index finger please J), Will actively fight it
                0 fingers (fist):  Over my dead body

Brosseau’s “It IS all about you” focused on:
            What is your contribution to this situation?

My Birds Of a Feather (BOF) lunch table on Model Based Testing generated good discussions.

In the Industry Collaboration panel, Marshall focused on innovation (up/over/down) by abstracting an idea from another field (generalize, up), taking over to your field (over), and then generating equivalent field specific equivalent (generate, down).   Hoffman gave analogy of Accounting profession versus software quality profession.

Hamlet’s talk (and paper) on Collaboration among software components, shows why system and integration testing are essential and unpredictable even from solidly test components (classes or units).  He did a toy example with floating point functions and suggested refining domains into sufficiently small slices to allow prediction of output (sort of like CAD or Finite Element analysis).  Toths estimating techniques was an interesting high level comparison of processes and techniques along with factors to take into consideration when choosing.

SPIN Meeting on “Agile Planning” started to look a lot like normal project planning to me (with different names):
                Product Vision (e.g. 1 year)
                                Product Roadmap (updated 2-4 times/year)
                                                Release plan (every quarter)
                                                                Sprint plan (3-6/quarter)

I’ve requested the slides.

Wednesday

Jeffries keynote was mostly a walk thru of agile principles.

The statement that took me longest to grok:

Frequent small features minimize drift and maximize value of Surprise.        “Surprised this isn't what we wanted.”
Surprises are good when found early before too much invested.  So maximizing them early is of greatest benefit.

Other pithy statement: “Too much design is less fatal than too early design.”

With incremental development, refactoring allows

   Slowly but surely you square up the pylons and walls.

Tedious.  This is never fun, just hard the work.   The best they know.

Simple Design   (4 rules in priority order 1 is top)

1.   Run all tests

2.   Remove all duplication.

3.   Express all design ideas

Sometimes Comments to express the Why,

Comments should not be necessary for what the code does.

Maybe have comment to explain why named function needed

4.   Minimize entities (LOC, methods, classes)
Don't remove class if it expresses intention

"Stabilization" is just testing because we didn't know what was going on.

Testing to know where we are.

McCaffrey’s “Determining best alternative” (MSDN Magazine Nov. 2008 article) was a nice simple review of some simple voting techniques. 

I was moderator for lunch panel discussion on Does Collaborative Quality help.   I was too focused on moderating to absorb content.  L    Larsen mentioned that handoffs in processes reduce collaboration.

Johnson’s storytelling techniques came with nice stories to illustrate some simple points.

Smith’s “selling your idea to management” was very short lecture followed by long exercise/practice session.   Talk to manager from their perspective (their priorities and commitments).

We should do X,
to get benefit Y,
else with no change the result is Z.

Thus I would like you to take action A

Naturally Collaboration is good, but achieving it can be difficult.  Agile relies heavily on collaboration.