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
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
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.
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
In gauging agreement, he uses 8 point “congruence”
scale. Agile folks have talked about
the first of 5: 5 fingers: Completely and enthusiastically
4 fingers: Agree
3 fingers: Neutral, but willing to support.
2 fingers: Disagree
1 finger (index finger
Will actively fight it
0 fingers (fist): Over my
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
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
Product Roadmap (updated 2-4 times/year)
Release plan (every quarter)
I’ve requested the slides.
Jeffries keynote was mostly a walk thru of agile principles.
The statement that took me longest to grok:
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
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
3. Express all design
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,
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.
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
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
Naturally Collaboration is good, but achieving it can be
difficult. Agile relies heavily on