Hiccupps

Fiona Charles ran a workshop on business risk analysis for my team at Linguamatics last week. Across the day we covered risk-based testing , how it can help with prioritisation, and how it is often overlooked as a factor in test design. We also looked at how the presentation of risks and their potential impact to someone who matters can be a way to engage stakeholders in the testing effort. Hopefully, this would in turn encourage contribution to activities such as test idea generation, triage, and attempts to mitigate risk elsewhere during design and development. Stakeholders often expect a level of testing we can't deliver. (Fiona Charles) The approach to risk assessment that Fiona outlined has some similarity to a pre-mortem . Essentially: assume the system has been implemented then look for ways in which it could go wrong. It's important to understand who the relevant stakeholders are — they are more than just your users — and to solicit diverse perspectives in you...

The other week, I tweeted this: I want to make a list of @JerryWeinberg recordings. I've found around 35 so far, mostly interviews from podcasts and youtube. If you know of any, or any existing lists, can you send me links? I'll share the whole list when I've curated and tidied it. The response was bigger than I expected so I put a very quick and dirty list on this page initially. I've now replaced it with a Google spreadsheet: Jerry Weinberg Recordings If you know of other recordings, please tell me via Twitter or in the comments here. Thanks! Image: Agile.FM via Pinterest

We've all been there: frustrated by a request from a stakeholder for what we take to be significant new work without regard for the scale of it, the time it would take, or the current backlog. Recently, a colleague in that situation and ready to scream "NOOOOO!!!!" asked for my advice. What I said boiled down to this: Step back and think of at least three ways that the request could be interpreted. Sketch rough ideas for how you could do each of them, at what cost, with what compromises.  Share them with your stakeholder to clarify their desires and help them to guide the next steps. This is essentially Jerry Weinberg's  rule of three  and orange juice test  so I claim no great novelty here. What I do claim is that I feel a lot better when I follow these steps than when I instinctively reject some request based on poor assumptions and no conversation, landing myself in a needlessly defensive position. P.S. just to make this harder, don't forg...

This week Sime suggested  Tidy Data by Hadley Wickham  for the Test team book club: A huge amount of effort is spent cleaning data to get it ready for analysis, but there has been little research on how to make data cleaning as easy and effective as possible. This paper tackles a small, but important, component of data cleaning: data tidying. Tidy datasets are easy to manipulate, model and visualize, and have a specific structure: each variable is a column, each observation is a row, and each type of observational unit is a table.  Messy data needn't be bad data, but it might not be in a format that makes it easy to process. Many tables used for data presentation will contain implicit variables, such as person or result in the table here: If you've ever generated, aggregated, or inherited data of any scale for analysis you're almost certainly already familiar with the basic ideas. You've probably also done informally, with much cursing, copy-pasting, and...

The Line. As a model there's not much simpler than a single horizontal line but, for Jim Dethmer, Diana Chapman, and Kaley Klemp, it's sufficient in any quest to become a more conscious leader: at any given moment, a person is either above the line and conscious , or below it and unconscious .  In their book, The 15 Commitments of Conscious Leadership , they elaborate. Being above the line means being open, curious, and committed to learning while being below it means being closed, defensive, and committed to being right. To operate above the line is to have a By Me state of mind (to take responsibility for being in any situation, to let go of blame) while below it is To Me (to believe that external factors caused the situation, to have a "victim consciousness"). Above the line leads to healthy and trusting relationships while below the line leads to toxic and fear-based relationships. Shane Parrish, interviewing Dethmer on the Knowledge Project podcast , sug...

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