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

Part 3 – Closing Notes

Video

Mindmap

Review

Points – Value – Problems

• Automation might become too expensive

• “Fancy” automation, like BDD, might be cool and enjoyable to work on, but managers must understand business value and risks of automation, and not let spending of project budget on toys for the sake of playing.
  • High investment costs
  • High maintenance costs
• Problems with user feedback
  • Not systematic
  • Not thorough
  • Not structured
  • Programmers are less than willing to investigate it
    • But testers are patient and empathetic with user feedback

• Any testing problems impact development and delivery.
  • The reason to have a smooth testing process is so that development can go faster.
  • Testing is headlights.

• Deep testing requires critical distance
  • “Distance” refers to the difference between one perspective and another.
  • Testing benefits from diverse perspectives.
  • Shallow testing doesn’t need critical distance but deeper or naturalistic long-form testing tends to *require* or *create* more distance from the builder’s mindset.

• Building is convergent mindset. Testing is divergent mindset.
  • Time and mental energy are required to switch between these 2.

• Another view of axis in Agile quadrant by Bach/Bolton
  • Envisioning Success vs. Anticipating Failure
  • Focusing Mindset vs. Defocusing Mindset

• Testability: if something goes wrong, how do we make sure that we spot it?
• Testability: can we isolate components for focused testing?
• Testability: can we simulate any system state that we want?
• “Mt. Mindset” – it’s a “central obstacle” that makes mindset switching hard
• Heuristic: even in Agile team it might be valuable to have a skilled tester who will stay focused in testing mindset – for finding deep problems.
• Trading Zone – a situation where people with different skillsets and mindsets work with each other.
  • There are Collaboration and Coercion types of trading zones

• Purpose of the model by Bach/Bolton
  • To provide a conversational tool to help talk about testing activities, shallow and deep. How developers and testers can work together to perform both.

Comment – Argue – Acknowledge

• As an automation engineer I can’t help but comment on James Bach’s notes about the subject.
• It’s not that the automation /might/ become too expensive. It’s about who pays for those expenses. Skilled testing and development of testing skills also have costs. But the former serves immediate needs of the project, and costs of the latter are spread between the project and the tester, and absorbed as the costs of the former. While automation is seen as the project item and the project deliverable, the business objectives for automation are not clearly set, direction on automation skill development is not provided, and resulting value added is questionable. Which ends up like project paying for programmers having fun coding automation.
• I wrote my own piece on the user feedback as a testing source. With all points mentioned by James Bach, there’s yet another one – practice of fixing problems after they were reported by users is not a prevention, not a detection, but continuous disaster recovery model. This is very damaging for reputation. It’s also passing expenses onto operations and customer support.
• In the book I read (and highly recommend) – The Organized Mind – the author reviews 2 mind functioning modes.
• “Daydreaming” or “Mind-Wandering” mode – the flow of connections among disparate ideas and thoughts, and a relative lack of barriers between senses and concepts; gateway to great creativity and solutions to problems that seemed unsolvable.
• “Central Executive” mode – heavily focused mode, prevents distractions; subconscious attentional filter actively working.
• Both modes are very important. But the author warns that switching between the modes quickly consumes mental energy.
• Both testing and programming mindsets require operation in both “mind-wandering” and “executive” mode. But switching from programming to testing requires serious “reload”. This also sets back any progress on the insights gained, so it’s ineffective and inefficient in the end.
• I first heard of testability concept from Michael Bolton during Rapid Software Testing workshop. Although I used it and created myself before, I didn’t think of it as a quality requirement. I thought of it as useful engineering tricks that help me do my work. But every work has costs. Every testing is aimed at risks. Testability has project level importance.
• There’s another aspect on testability: attitudes. I used to enjoy GUI automation challenges as they were interesting engineering challenges. But when I moved to leading roles I couldn’t help but wonder: why should I (or people reporting to me) spend 2 days creating workarounds for a trivial, 1-hour-job-kind improvement of GUI tables? Why should I wait 2 extra months before 2 component search becomes available, if we could get a mock in 3 days? My testing problems are not my personal problems. They are the project’s problems and risks. Instead of heroically overcoming obstacles my team could do twice as much testing.

SNACK

• Structure
  • The talk is organized as a time-boxed walkthrough of the concept.
  • As the end result is rather complex, multi-layer model, I find that such a step-by-step introduction was absolutely necessary to meet the purpose.
  • Logical structure is rather classic and well-formed: premise – conclusions, conditions.
    • Especially in contrast to the original models that rather claim and state but not convince and explain.
  • I observed 2 quite distinct presentation styles
    • Rather formal, professional presentation while conveying the main line
    • Rather emotional, artistic performance when illustrating with stories and examples
  • It’s important to mention (especially from diverse team perspective, where many have English as a 2nd language) that, despite of all complexity, the speech is easy to understand.
• Narrative
  • Summary
    • Developers and testers are often unclear of the roles and purpose of testing in agile development environments.
    • One of the examples circulated in the industry is “Agile Testing Quadrant”, but as per James Bach, Michael Bolton (and many other testers), that concept misrepresents and misses to much. The presentation enlists the problems and aims at fixing and refactoring of the Quadrant to address them.
    • New version represents cyclic, fractal nature of agile development and testing; emphasizes that different kind of testing happen all the way and throughout.
    • Key points
      • Testing helps to develop the vision for the product.
      • Checking and reviews help to build more frequently and fix problems on the go.
      • The reason to have a smooth testing process is so that development can go faster.
      • Having testing mindset is especially critical for discovery of deep, hidden, systemic problems.
    • The final part is about mindsets, difficulties of mindset switching, and concept of Trading Zone.
  • The whole talk is a well written and a well-presented story.
  • I find especially valuable that it can be reused and re-told to educate teams and managers.
  • As the story unfolds it can be paused for team discussions, and then continued taking understanding to the next level.
• Addressing
  • The talk directly (and successfully) addresses very important problem. Such a clarification was long time needed.
  • This talk must be seen by all testers and programmers, and – especially – managers. Even if the company is not planning or transitioning to Agile.
• Consistency
  • Title
    • Title on Vimeo says “Integrating Skilled Testing with Agile Development”
    • Title of the talk: “Skilled Testing and Agile Development Integrated”
    • Title of the final model: “RST Agile Testing Ecosystem v1.1”
  • I find the talk highly consistent, cohesive, and coherent.
  • That includes internal consistency, consistency with other materials on the authors’ blogs, consistency with RST methodology, and consistency with values of Context-Driven School of Testing.
• Keywords
  • Reification Fallacy
  • Reification (also known as concretism, hypostatization, or the fallacy of misplaced concreteness) is a fallacy of ambiguity, when an abstraction (abstract belief or hypothetical construct) is treated as if it were a concrete, real event, or physical entity.
  • Trading Zone