Hiccupps

The State of Testing report for 2020 has just been released. I continue to support the collection and publication of this kind of analysis because it can help us to see ourselves from a different perspective and identify changes to our work and context over time.  This time around, the authors comment: We are seeing many indications reinforcing the increasing  collaboration of test and dev, showing how the lines between our teams are getting blurrier with time. We are also seeing how the responsibility of testers is expanding, and the additional tasks that are being required from us in different areas of the team's tasks and challenges.  We were also able to see some low level changes and expansions in the technologies tested, the technologies used to test, and the technologies that may be relevant in the future I'd love to see more longer-term trend data published and, while I doubt it's easy to generate, something about approaches and outcomes similar to S...

Back when I had hair and an East German army surplus jacket and carried a record bag with me everywhere, we wrote a fanzine and released records together. Our first contact was twenty years ago this year. Twenty years since he sent me a copy of his debut 7" single, the first release on his Kitchen Records label. Twenty years since I gushed this review onto the poorly-photocopied pages of my zine, Robots and Electronic Brains : The Fabulous Nobody, Love and the City (Kitchen) 7" Some days I just feel like I'm getting old and other days I know it's so. Given the kick I'm getting out of the three cuts on this limited-edition 7", today must be one of the latter. Three dreamsongs of naive romance for the big city lights that could've been written for a 1930s stage play and revived for a 1940s screen adaptation starring Fred Astaire who'd do a slow soft shoe routine to the whistle solo and lean against a lampost smoking a fag for the rest. I ask...

Much of  Definition of The Engineering Method  by Billy Vaughn Koen chimes with what I've come to believe about testing.  In part, I think, this is because thinkers who have influenced my thinking were themselves influenced by Koen's thoughts. In part, also, it's because some of my self-learned experience of testing is prefigured in the article. In part, finally, it's because I'm reading it through biased lenses, wanting to find positive analogy to something I care about.  I recognise that this last one is dangerous. As Richard Feynman said in Surely You're Joking, Mr. Feynman!: "I could find a way of making up an analog with any subject ... I don’t consider such analogs meaningful.”  This is a short series of posts which will take an aspect of Definition of The Engineering Method that I found interesting and explore why, taking care not to over-analogise. Getting Myself Koen Sota so Good Meta is Better The Tester as Engineer? --00-- In thi...

Much of  Definition of The Engineering Method  by Billy Vaughn Koen chimes with what I've come to believe about testing.  In part, I think, this is because thinkers who have influenced my thinking were themselves influenced by Koen's thoughts. In part, also, it's because some of my self-learned experience of testing is prefigured in the article. In part, finally, it's because I'm reading it through biased lenses, wanting to find positive analogy to something I care about.  I recognise that this last one is dangerous. As Richard Feynman said in Surely You're Joking, Mr. Feynman!: "I could find a way of making up an analog with any subject ... I don’t consider such analogs meaningful.”  This is a short series of posts which will take an aspect of Definition of The Engineering Method that I found interesting and explore why, taking care not to over-analogise. Getting Myself Koen Sota so Good Meta is Better The Tester as Engineer? --00-- It is ...

Much of Definition of The Engineering Method by Billy Vaughn Koen chimes with what I've come to believe about testing.  In part, I think, this is because thinkers who have influenced my thinking were themselves influenced by Koen's thoughts. In part, also, it's because some of my self-learned experience of testing is prefigured in the article. In part, finally, it's because I'm reading it through biased lenses, wanting to find positive analogy to something I care about.  I recognise that this last one is dangerous. As Richard Feynman said in Surely You're Joking, Mr. Feynman!: "I could find a way of making up an analog with any subject ... I don’t consider such analogs meaningful.”  This is a short series of posts which will take an aspect of Definition of The Engineering Method that I found interesting and explore why, taking care not to over-analogise. Getting Myself Koen Sota so Good Meta is Better The Tester as Engineer? --00-- The ...

Much of  Definition of The Engineering Method  by Billy Vaughn Koen chimes with what I've come to believe about testing.  In part, I think, this is because thinkers who have influenced my thinking were themselves influenced by Koen's thoughts. In part, also, it's because some of my self-learned experience of testing is prefigured in the article. In part, finally, it's because I'm reading it through biased lenses, wanting to find positive analogy to something I care about.  I recognise that this last one is dangerous. As Richard Feynman said in Surely You're Joking, Mr. Feynman!: "I could find a way of making up an analog with any subject ... I don’t consider such analogs meaningful.”  This is a short series of posts which will take an aspect of Definition of The Engineering Method that I found interesting and explore why, taking care not to over-analogise. Getting Myself Koen Sota so Good Meta is Better The Tester as Engineer? --00-- So...

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...

It's nothing personal I'm sure but at this week's Cambridge Agile Exchange Ben Mancini told me that I'm a failure. Ouch! Failure, he says, is "the state or condition of not meeting a desirable or intended objective ... may be viewed as the opposite of success" and his hypothesis is that failure provides more learning than success but that we talk more about success than failure. In his talk, Ben showed examples of people who have succeeded despite repeated failure, talked about the negative effects of failure, ways to reframe perceived failure, and the benefits of pushing through failure's cloud to its silver lining. Along the way he shared some of his own failures and invited us to share personal faux pas with our neighbours in the audience then look for the learnings in them. One of the reasons I attend meetups is to be provoked into thought so, in no particular order ... In my time I've certainly done things that I'd have preferred ...

A friend lent me two books on metrics. One was so thumpingly wrong I could not finish it. One was so joyfully right I had to read it end-to-end, despite the author's recommendation not to. Dave Nicolette will be pleased to know that his book, Software Development Metrics , was the second of the two. Why so right? Because immediately I felt like I was in the hands of a pragmatist, a practitioner, and a personable guide. By page 8 he's chattily differentiated measures and metrics, identified a bunch of dimensions for projects, and then categorised metrics too. Along the way, he drops this piece of wisdom (p. 5): The sort of development process you're using will influence your choice of metrics. Some metrics depend on the work being done in a certain way. A common problem is that people believe they're using a given process, when in fact they're working according to a conflicting set of assumptions. If you apply metrics that depend on the process being done cor...