Testing the Limits With Jon Bach – Part I
After Twitter-stalking him, making some harassing phone calls and sending threatening letters, Jon Bach (@jbtestpilot) cheerily agreed to take part in our Testing the Limits series. Much like his brother, Jon has a remarkable understanding of software testing – both in theory and in practice. Having worked for companies like Quardev, LexisNexis, HP and Microsoft, Jon is also a blogger, author and software testing consultant. An expert, in the truest sense of the term.
In the first installment of our two-part interview, we get Jon’s thoughts on sibling rivalry; the blame spiral of software development; the emergence of “agile-fall”; testing at a startup vs. testing in the enterprise; John Schneider as Jon Bach and more. Check back tomorrow for part II.
uTest: A few months back, we asked your buddy Andy Muns who’d win a fight between you and your brother (this was a big debate in the uTest office). He said you would win hands down. Would he be right? And since you and your brother seem to share the same testing philosophy, what would do you think the fight would be about?
JB: It’s hard to fight with someone who stayed in their room for most of our childhood. He was either reading or doing science experiments with a microscope or the chemistry set. It got worse when we got the TRS-80 in 1980. In fact, that’s probably the last time we fought — over who got computer time next. My memory may be fuzzy, but just when it came to blows, he programmed a user name and password dialog? Something clever like that. Now it’s better just to learn from him and do my best to keep up — but that’s true for all younger brothers, I think.
As for modern-day fighting, sponsor me for a testing certification and let’s see what he’d do.
uTest: Say you’re named grand poobah of the QA universe… what’s your first decree?
JB: Effective today, “Quality Assurance” is now “Quality Assistance”.
(Try it. Watch what happens when you start using it.)
uTest: When there are delays in development process, why does testing always seem to take the blame? Is their role just misunderstood? Or is it really the testing team’s fault? How can companies avoid this seemingly never-ending spiral?
JB: Often, we’re saved until last. It’s like the novel is written, the movie is produced, but the reviews aren’t in yet, leaving the creators in a heightened state of worry and concern. It’s a lot of stress to be in that position. As testers shine the light on the product, looking for risks and vulnerabilities, the light is really shining on *us*. We’re being tested just as much as that software, so we tend to be sensitive and aware of being in a critical position as others wait for our findings.

How should testers respond when their bugs are rejected by clients?
In my recent post with my
Before I get into the story of this fascinating bug, I wanted to take a moment to introduce you to 


When it comes to software development and programming, few people have been read, linked to, tweeted, quoted or plagiarized more than Joel Spolsky (
Self improvement is a lousy business model. Mobile app developers understand this better than most. For every app to help you lose weight or improve your IQ, there are basically 10x as many to help you drink more, find your nearest trans-fat vendor or change the channel without standing up to get the remote. What a world we live in!



