Testing Time Out Inteview at EuroSTAR Software Testing Conference
Shmuel Gershon interviews one of software testing’s most familiar faces, Michael Bolton. They discuss important issues affecting testing today so make sure you tune into this very special Testing Time Out.
Why Do Some Testers Find The Critical Problems?
Today, someone on Twitter pointed to an interesting blog post by Alan Page of Microsoft. He says: “How do testers determine if a bug is a bug anyone would care about vs. a bug that directly impacts quality (or the customers perception of quality)? (or something in between?) Of course, testers should report anything that may annoy a user, but learning to differentiate between an ‘it could be better’ bug … Read more
One Test Per Requirement
Despite all of the dragons that Agile approaches have attacked successfully, a few still live. As crazy as it is, the idea of one test check per requirement has managed to survive in some quarters. Let’s put aside the fact that neither tests nor requirements are valid units of measurement, and focus on this: If you believe that there should be one test per requirement, then you have to assume … Read more
You’ve Got Issues
What’s our job as testers? Reporting bugs, right? When I first started reading about Session-Based Test Management, I was intrigued by the session sheet. At the top, there’s a bunch of metadata about the session—the charter, the coverage areas, who did the testing, when they started, how long it took, and how much time was spent on testing versus interruptions to testing. Then there’s the meat of the session sheet, … Read more
Exegesis Saves (Part 3) Beyond the Bromides
Over the last few blog posts, some colleagues and I have been analyzing this sentence: “In successful agile development teams, every team member takes responsibility for quality.” Now, in one sense, it’s unfair for me to pick on this sentence, because I’ve taken it out of context. It’s not unique, though; a quick search on Google reveals lots of similar sentences: “Agile teams work in a more collaborative and open … Read more
Exegesis Saves! (Part 2) Transpection with James Bach
Last evening, after a long session of collecting and organizing a large number of contributed responses to yesterday’s testing challenge, I was going over my own perspectives on the sentence “In successful agile development teams, every team member takes responsibility for quality.” James Bach appeared on Skype, and we began an impromptu transpection session. It went more or less like this: James: I saw your original challenge and a couple … Read more
Exegesis Saves! (Part 1)
This morning, I read a sentence that bugged me. “In successful agile development teams, every team member takes responsibility for quality.” I’ve seen sentences of that general form plenty of times before. Whether I’ve reacted or not, they’ve always bugged me, and today I decided to probe into why. Rather than doing so on my own, I thought it would be more fun and more interesting to involve my community, … Read more
Jerry Weinberg Interview (from 2008)
In the spring of 2008, I was privileged to chat with Jerry Weinberg on why he was favouring CAST with his only conference appearance of that year, other than the Amplifying Your Effectiveness conference, of which he’s a co-founder and host. CAST that year saw the launch of Jerry’s book Perfect Software and Other Illusions About Testing. It’s now available as an e-book, too. Jerry will not, so far as … Read more
Public Rapid Software Testing Classes, Calgary and Berlin
I’m delighted to announce that I’ll be doing a one-hour lunchtime presentation on test framing for the Software Quality Discussion Group in Calgary, February 10, 2011. The session is free! However, space is limited to the first 50 people who register, so don’t delay. I’ll be in Calgary to present a public offering of Rapid Software Testing class, February 7-9, 2011. It’s being organized by Nancy Kelln of Unimagined Testing … Read more
When A Bug Isn’t Really Fixed
On Monday, January 10, Ajay Balamurugadas tweeted, “When programmer has fixed a problem, he marks the prob as fixed. Programmer is often wrong. – #Testing computer software book Me: why?” I intended to challenge Ajay, but I made a mistake, and sent the message out to a general audience: “Challenge for you: think of at least ten reasons why the programmer might be wrong in marking a problem fixed. I’ll … Read more