Hiccupps

In knowledge work it's usual for ideas to need to be shared. In software development a common direction of travel for concepts is from one set of people with a vision for a feature to another set of people who will bring it to life. Sounds simple, right? But it isn't simple and many ways exist to try to address that lack of simplicity, including thick wodges of functional specification and layers of sign-offs through to terse sticky notes, a chat, and iteration. Whatever the approach there's one constant: a commitment of time from the idea holders. An anti-pattern common in our industry is that these individuals often also have emerging and urgent tasks which trump the merely important ones ... such as the sharing of ideas. Despite our best intentions we've seen it at our place too, and it impacts the quality of the thing that we can build in the time available to us. Naturally, this kind of problem can be tackled at all sorts of levels. At one level, I was in...

Last weekend I was talking Testability at DEWT 9 . Across the two days I accumulated nodes on the mind map above from the presentations, the facilitated discussions, and the informal conversations. As you can see it's a bit dense (!) and I'll perhaps try to rationalise or reorganise it later on. For now, though, this post is a brain dump based on the map and a few other notes.  --00-- Testability is the ease with which the product permits itself to be tested (its intrinsic testability) ... but also factors outside of the product that enable or threaten its testing (so extrinsic ) ... meaning that people, knowledge, opportunity, time, environments, and so on can be part of testability. Desired outcomes of increasing testability might include easier, more efficient, testing and learning better feedback, risk identification and mitigation building  trust and respect across project teams The term testability can be unhelpful to non-testers ... and also...