Hiccupps

A few months ago I was asked if I'd consider standing for the board of the Association for Software Testing . After giving it a lot of thought, and talking to some people, I decided that I probably did have something to offer, even if it's only the perspective of a relative outsider. Last week, at CAST 2019  the voting results were announced ... and I'm in ! For the record, then, here's my answers to the election questionnaire . Q1: Why are you an AST Member? When I first became a tester I sought out resources to help me learn what testing was. The first book I bought was Lessons Learned in Software Testing and I found that the way it described testing was the way I naturally wanted to test. I researched the authors and their other work which led me to Rapid Software Testing, joining AST, and completing the BBST Foundations course. I remain a member of AST because of its integrity, its dedication to the testing craft, and its commitment to a strong ...

Last week, unexpectedly, I became a Licensed Scrum Master. I knew I was attending a course run by Scrum Inc  with a group of my colleagues, but I had no idea that there was a short online multiple choice exam and a certification for me at the end. It's easy to be sceptical and sniffy about the industry around Scrum, but I try to go into training events in a positive frame of mind , looking to participate, open to having my views changed. I'm not sure that there was a seismic perspective shift for me on this occasion, but I still thought it'd be interesting to run a personal retrospective. Some background first: I've never worked on a Scrum team, although I manage testers on them. I'm very interested in ways that software can be developed and tested, and one of my favourite books in that space is  Extreme Programming Adventures in C# by Ron Jeffries, a great practical example of iteration, reflection, and honesty. A disclaimer too: without much visibility of...

How about if it wasn't Venn diagram, but instead it was a  When diagram? Would we know when things were going to get done if we had one of them? I'm sure I'm not the first person to make that phonetic connection, but perhaps I'm the first who has  sufficiently little shame to mention it publicly on Twitter : If I asked you to produce a "When diagram" for the project you're running, what would you think I was after? What kind of picture/chart/diagram would you draw for me? A handful of kind folk responded, each with something different: @joelmonte : When, in the project perspective, sounds like a milestones diagram.  It can be interconnected, and showing the dependencies of events...  But this is only my sunday-morning-wild-guess.  Do we also have "Why", "How" and most importantly "Who is to blame" diagrams? @always_fearful : Gant chart @hairyhatfield : A venn diagram with sets 'sooner'  'l...

The Cambridge Tester Meetup last night had talks from Jamie Doyle and Samuel Lewis. I took the opportunity to practice my sketchnoting again. Jamie is a business owner and an ex-tester and test manager. He described how, despite his background in testing, he has still kicked off product development based on sketchy 3am "great ideas" in teams without any testers. Having lost some money building the wrong thing, he's now an advocate of shifting testing left . He recommended that the C-level get testers in to provide risk assessments of ideas before they're committed-to, and that testers look to make contacts on that side of the business and get themselves in a position to be asked to help. He also shared some of the approaches and questions he used redoing the problematic project with a friendly tester from the bottom up. Interestingly for me, this exercise sounded like the kind of thing a business analyst might do. I see a lot of crossover between the test ...

  I really enjoyed providing pre-production comments on Rich Rogers' book on quality, Changing Times ,  so when the opportunity to do the same for George Dinwiddie came up recently, I took it. Why? Oh, a handful of reasons, including: I'm here for the testing and reviewing feels a lot like testing. (My definition of testing : the pursuit of relevant incongruity.) There's the interesting intellectual challenge of finding a way to provide the kind of review being requested effectively and efficiently. There's the interesting social challenge of delivering my thoughts in a way that conveys them respectfully, despite sometimes being critical. George's book is called Software Estimation Without Guessing and I knew up front that there would be two rounds of review for it. The first was on a version with a couple of chapters still to be written, the second with all content present but further editing still required. The publisher, The Pragmatic Bookshelf , p...

Skimming a recent issue of Significance , the journal of the Royal Statistical Society, I saw a reference to a paper called We Need Both Exploratory and Confirmatory by John Tukey, published in the 1980 in The American Statistician. I hunted it down and found much that felt familiar. Here's a few quotes: Exploratory data analysis is an attitude, a flexibility, and a reliance on display, NOT a bundle of techniques, and should be so taught. Confirmatory data analysis, by contrast, is easier to teach and easier to computerize. ... to implement the confirmatory paradigm properly we need to do a lot of exploratory work. Neither exploratory nor confirmatory is sufficient alone. To try to replace either by the other is madness. We need them both Science DOES NOT BEGIN WITH A TIDY QUESTION. Nor does it end with a tidy answer. No catalogue of techniques can convey a willingness to look for what can be seen, whether or not anticipated. Yet this is at the heart of exploratory d...

A few months ago, in Postcard CV , I wrote about some of the ways I've adapted my note-taking techniques  for interviewing. Although I did this largely for my own benefit, I like to think there is a positive effect for candidates too: I can be more in the moment with them if I'm not thinking about how I take my notes, I am motivated to invest in re-reading before I speak to them on subsequent occasions because I'm confident that the notes are in reasonable order, and I can re-engage with the candidate on topics we've covered, or threads that we didn't pick up in earlier conversations. My fieldstones for Postcard CV included things that I do verbally during interviews to try to help to put the candidate at ease, to signpost different phases of the interview, and to give an idea of what is and isn't expected of them. When I started writing that post, it became clear that it was the material on notes that wanted to come out and so I left the rest aside. I...

We don't have any business analysts at our place but I'm interested in the role and the potential insights a BA can bring to software development. Historically, I've wanted my testing to be concerned with more than whether the desired scope was implemented: I want it to wonder whether that scope is targeting the right problem and, if it is, whether some other scopes could solve it too, and what the relative merits of each are. I think this kind of work overlaps with the things a BA might do, but perhaps with sharper tools, and I perceive that there's crossover in the skill set too. To give my thoughts some more grounding I looked for an intro book and chose Business Analysis Agility by James Robertson and Suzanne Robertson. Why that one? Because it talks end-to-end about software development in contemporary environments, because it's got worked examples, and because I liked what Johanna Rothman's five-star review on Amazon said about it: This book bu...

  We play tricks on ourselves, Woody Zuill says. We think that we estimate because it gives us control. In reality, we estimate because we fear losing control. The irony, of course, is that we aren't in control : estimates are inaccurate, decisions are still based on them, commitments are also based on them, projects overrun, commitments are broken, costs spiral, ... Spending more time estimating typically doesn't make us better at estimating but it does take time away from doing.  Zuill's experience is that it's possible to build software without any estimates by taking an important piece of functionality, building only the absolutely critical pieces of it, and then putting it in front of someone. The doing, and the review of what's been done, will help to determine what should be done next. Sounds simple? Yes, but it's not easy . It's crucial to find allies and customers who are ready to accept it. Here's my tidied-up sketch...

I was at Cambridge Agile Exchange 's first Unconference the other night and I pitched a 15-minute discussion with the title  The value of testing is ... : I'm a tester and I'm interested in the value that others perceive testing brings to product development in their contexts. Where does testing add value? Where does it add most value? When does it add value? What kinds of testing activities deliver the right kind of value at the right kinds of costs? Do you need testers in order to test?  The participants in the session included product owners, scrum masters, developers, coaches, an ex-test manager, and a colleague from Linguamatics who has just switched to testing from linguistics. (And I'm still hiring .) The mission I had in mind was to gather data, to solicit and record views, and to not push some kind of militant testing agenda. I think that worked well, and if I had to pull one observation out it'd be how quickly the conversation turned to  th...