Michael Bolton It’s common these days to hear people say that they don’t want to focus on finding bugs; they want to focus on preventing bugs. They want to focus on “building quality in”. Let’s face it: building quality in is a pretty great idea, and preventing bugs from reaching customers is a really good thing. On this, reasonable people agree. To prevent bugs from reaching customers, you’ll have to become a … Read more
On my iPad, I’m reading a discussion on LinkedIn. A reply piques my interest, and I want to alert a colleague to it. I tap on the dots in the upper right. The options offered are are “Message (the author of the reply)”, “Share via…”, and “Report”. I tap on “Share via…” Nothing happens. I move to my computer, and go to the same reply. The three dots in the … Read more
So this happened today… I mean, there’s supposedly a book about that. It gets a little wackier. I don’t know how the algorithms are coming up with the categories in the lower half of the list.
Selenium! Playwright! Cypress! Postman! There’s constant hubbub around these tools and others primarily focused on checking output—and now the din is getting louder about low-code or no-code tools for checking output. (Last year I reviewed a couple of those, here and here. Did these companies use their own tools to test their own tools? Either a Yes or No answer would be disturbing.) Want some heuristics for choosing tools of … Read more
I sit down with a coffee, retrieve my mail, and open it up. I’ve received a spammy kind of message. It provides a link to unsubscribe. The link returns {“code”:1020,”message”:”fail”}. I’ve received another spammy kind of message, this time from Yellow Pages (yp.ca). In the text, it is addressed to “[{Recipient.FirstName}]”. The message asks “How do you show up online?” Better than YellowPages shows up in my inbox, I hope. … Read more
Deep testing — testing that maximizes the change of finding every elusive bug that matters — is the kind of testing work that engages and motivates serious testers. Developers tend to prefer shallow testing that doesn’t disrupt the developer’s mindset and the developer’s focus on getting the danged product built. (Before anyone gets too upset, note that the shallowness of shallow testing is a feature, not a bug. There’s lots more … Read more
A few years ago, a friend introduced me to a recording of the mind-blowing musical Hamilton (if you haven’t seen or heard it, do yourself a favour and check it out). Our whole family was, for a time, obsessed with it. A few months after that, I was preparing for a talk at Xebia in Amsterdam. I was wondering how I could spice up the talk a little by doing … Read more
A while back I wrote a post on coverage. In fact, I’ve written a few posts about coverage, but I’m talking about this one. A question came up recently on LinkedIn that helped me to realize I had left out something important. In that post, referring to coverage as “the proportion of the product that has been tested”, I said A software product is not a static, tangible thing; it’s a … Read more
A tester asks… How do we handle production bugs? When management asks “Did you test this?”. how do I respond? When management asks “Why didn’t you find that bug?”, the first step is to accept in your own mind responsibility for looking for bugs, but not a commitment to finding every bug. The latter is a great aspiration, but an unreasonable commitment, and management shouldn’t be holding you to it. … Read more
Frequently, both online and in face-to-fact conversations, testers express reservations to me about making a clear distinction between testing and checking when talking to others. It’s true: “test” is an overloaded word. In some contexts, it refers to a heuristic process: evaluating a product by learning about it through experiencing, exploring and experimenting; that’s what testers refer to when they’re talking about testing, and that’s how we describe it in … Read more