As the whole talk is about 45 minutes long, I post series of the review in my blog.

Part 2 – Refactoring and Walkthrough

Video

Mindmap

Review

Points – Value – Problems

• Axis in refactored version by Bach/Bolton
  • High Value of Product – Low Cost of Development
  • Synthesizing – Analyzing
• Core agile values in version by Bach/Bolton
  • Deliver frequently
  • Cultivate craftsmanship
  • Collaborate across roles
  • Avoid excess formalization
  • Apply appropriate heuristics
  • Seek a sustainable pace
  • Develop and apply tools
• Clock-wise cycle in version by Bach/Bolton
  • Discover something worth building
    • ->develop the design
  • Build some of it
    • build cleanly and simply
  • Build with change in mind
    • ->foster testability
  • Study what we built
    • ->experiment imaginatively and suspiciously
• It’s important to talk about what’s really happening; many people give up and simplify because they don’t want to sound controversial. But it indulges misunderstanding of testing.
• Cycle is fractal in nature. Activities are not sequential steps. Activities overlap. Inside of the activities there are sub-cycles.
• Fitting testing into Agile quadrants by Bach/Bolton
  • 12-3 o’clock: Testing that helps to develop the vision for the product
    • Explore definitions of “done”
    • Engage with diverse users
    • Specify product with rich examples
    • Review reports from the field
    • Explore design tradeoffs
    • Refine user stories
  • 3-6 o’clock: Output checking and review that helps to avoid simple coding errors and regressions
    • Automate low-level checks
    • Establish shared coding style
    • Investigate and fix bugs as we go
    • Review each others’ code
    • Build the product frequently
    • Refactor for maintainability
  • 6-9 o’clock: Any preparation needed for a test process that allows development to go quickly
    • Prepare test infrastructure
    • Make the product easy to test
    • Test in parallel with coding
    • Identify and explore product risks
    • Minimize disruption when changing product
    • Remove obstacles and distractions to testing
  • 9-12 o’clock: Deep testing for hidden, rare, or subtle problems
    • Assess whether we’re “done”
    • Model in diverse ways
    • Develop rich test data
    • Test and check against risks
    • Investigate mysteries
    • Tell compelling bug stories

Comment – Argue – Acknowledge

I’m going to compare Crispin/Gregory version with Bach/Bolton’s as well as my understanding and critique of both versions.

• When I look at the Crispin/Gregory version of the quadrants, I first of all see an attempt (or intent) to group and categorize certain types of testing and non-testing activities. I also see intent to separate these groups from one another.
• And I also see problems.
  • I’m not clear on the grouping.
    • Why Functional Tests are in “Supporting the Team” group and Usability Testing in “Critique Product”? Why Story Testing is in “Supporting the Team” group and Exploratory Testing in “Critique Product” – aren’t the stories supposed to be first and foremost explored?
  • I’m not clear on separation.
    • All testing is (at least – should be) done with testing mindset. It must equally apply to unit testing (which is much bigger practice than output checking), to security testing, and all other kinds. All of these kinds are also tool-assisted to some extent, but never solely done by tools.
  • I can see a point in the notion of “Technology Facing” for low level checks and things like HTML validators. But that’s it.
    • Accessibility testing is aimed at discovery of barriers for people, not technology flaws. Security testing is concerned with weaknesses that lead to violation of business rules.
  • Similarly, “business facing” makes sense only in terms of business value. But then – ALL tests are intended to discover threats to the business value.
• Putting everything together: the model is full of internal contradictions.

• The presentation of the model by James Bach and Michael Bolton projects notion of circular movement, which makes a good connection to the iterative depiction of agile software development.
• The model is also fundamentally inclusive: programming and testing are encapsulated within and organically grow into each other – to the contrast of another model that separates testing from development in the first place.
• The sentences are purpose-oriented, in active voice – to the contrast of passive statements in another model. E.g. “test and check against risks” vs. “functional tests”.
• I’m not sure what to make of color coding on both models.
• Values and guidance.
  • Values are literally central in Bach/Bolton model. I couldn’t find any in another one, and centerpiece is given to “Q1-Q2-Q3-Q4” there.
  • Bach/Bolton model also provides an all-round guidance on purposes and the activities; it even can be used as an agile testing strategy poster. Another model only presents references to artifacts and testing tasks.