Many companies I’ve been at are in a race to see how much like Spotify they can be and apply concepts of Chapters and Guilds. What I routinely see is companies get this bit wrong. Particularly around so-called “quality guilds.” So let’s talk about this. Continue reading The Copy+Paste Culture →

In our testing industry we’ve borrowed ideas from the physics realm to provide ourselves some glib phrases. For example, you’ll hear about “Schrödinger tests” and “Heisenbugs.” It’s all in good fun but, in fact, the way that physics developed over time certainly has a great deal of corollaries with our testing discipline. I already wasted people’s precious time talking about what particle physics can teach us about testing. But now I’m going to double down on that, broaden the scope a bit, and look at a wider swath of physics. Continue reading Testing Helps Us Understand Physics →

In the United States we are currently going through one of our normal rounds of political craziness as we move towards a new election. This is not a political blog and I don’t want to add to the crazy. Thus this post will not discuss current political viewpoints, whether for or against, and will have nothing to do with current candidates. Rather this post will discuss one specific aspect of politics that has a historical context that relates to how our testing industry has evolved and continues to evolve. Continue reading What Can Politics Teach Us About Testing? →

Awhile back I talked about being cross-discipline associative. I did something similar to this approach when I asked what time travel could teach us about testing. Let’s see how this works with another domain entirely. Continue reading What Can Particle Physics Teach Us About Testing? →

I’ve always been interested in the different ways that testers think and how those modes of thinking directly apply to the work testers do. What it comes down to for me is how people learn. This ultimately impacts how they evolve their career. And, in a somewhat loaded statement, how a tester has evolved their career tells me how useful they are going to be.

In talking about test teams as inventors, I mentioned that Albert Szent-Gyorgyi said “Discovery consists of looking at the same thing as everyone else does and thinking something different.” I wanted to go back to that thought because it’s not the act of “thinking something different” but rather the act of “thinking differently” that really matters to me. This is even more so the case in an industry where testing and development continue to move closer together and, in fact, often merge.

In a previous post I talked about inventors as people who see and think differently. I also brought the idea of inventors having to institute cultural change in some cases. What I didn’t do is how an inventor utilizes their skill-set and mind-set to get that change going. So let’s talk about that. Hopefully I won’t make too much of a fool of myself.

In various posts I’ve tried to show how I believe testers can invent solutions to problems they are encountering. These solutions do not always have to be tool-based in nature. Sometimes you are presenting a new way of thinking about processes, sometimes you are reframing problems, sometimes you a providing a hopeful vision, sometimes you are in fact coming up with ad-hoc tools, and sometimes you are coming up with new techniques. At the core of this, however, is thinking about problems and thinking about solutions. It’s about being an inventor.

I find myself in a philosophical mood today and it’s based on some experiences with testers that simply don’t ask questions. As testers we have to ask questions. Lots of questions. We also have to recognize when we are getting answers. Sometimes, however, we have to realize that sometimes answers aren’t that easy to come by. And here I’m not just talking about the idea that no one has the answers. What about when answers just aren’t possible at all? Can that happen? Of course it can. It depends on the types of questions being asked and the context in which answers are expected. (See my time travel post for one example of this.)

So — just bear with me here — I want every tester out there to consider a question: what existed before the big bang?

Some testers — and most managers — like to talk about metrics. One thing that often doesn’t get discussed is what I call metric dissociation. Here’s my thought: metrics should be easily or directly interpretable in terms of product or process features. If they’re not, I think they are dissociated from the actual work that’s being done and thus there’s great danger of the metrics being misleading, at best, or outright inaccurate, at worst.

When a professional discipline has a vocabulary for expressing the fundamental concepts on which it’s based, then you have a means for how practitioners in the discipline can make sure they’re talking about the same things. The problem with establishing such a vocabulary is that many people have come to use a variety of different terms or, even in those cases where the terms are the same, the definitions used are different. This is why I like to encourage people to think operationally.

So why are so many testers I meet so bad at this? Is this just not something they’re encouraged to do? Or am I just being too picky about how people use terms?

I really enjoyed the book Ubiquity: Why Catastrophes Happen by Mark Buchanan. This book doesn’t talk about quality assurance or testing at all, but it does talk about how things can change very quickly and how a certain context can dictate how things change. I definitely recommend the book for anyone working in a software development context because I found I could abstract ideas out of the context that the book talks about and apply them to the idea of change initiatives, faulty software, and the social context of software engineering environments I have worked within.

I’ll distill a little bit of what I got out of the book here, in the hopes of encouraging you to read it.

F. Scott Fitzgerald, in his essay called The Crack-up from 1936, defined a “first rate intelligence” as the ability to hold “two opposed ideas in the mind at the same time and still retain the ability to function.” David Lapin, one time CEO of Strategic Business Ethics, and now CEO of Lapin International, referred to the “space of paradox” wherein trust and innovation had to co-exist. Donald Schön talks about the “generative metaphor” in his 1963 The Displacement of Concepts, which was the idea of bringing domains that appear to be different together in a single concept or design. Dorothy Leonard-Barton talked about “creative abrasion” in her 1995 The Well-Springs of Knowledge which was focused on bringing people with differing views together.

James Collins and Jerry Porras encapsulated a lot of these ideas in a style of thinking called “the genius of the and” in their 1997 Built to Last: Successful Habits of Visionary Companies. It’s that book I’ll focus on here because I think the concept of the “genius of the and” is one that people can readily rally around. Built to Last is not a book that talks about quality assurance or testing at all, but it does talk about a very common thinking pattern in both of those fields.

As I write this, NASA’s UARS (Upper Atmosphere Research Satellite) is about to plop back to Earth. The orbit of the satellite puts it somewhere between 57 degrees north latitude and 57 degrees south. That spans the width of the world between northern Canada and the tip of South America. Where exactly it will come down is hard to say because the deviations that are possible, due to a variety of factors, make such predictions potentially wildly inaccurate.

I think the degree to which deviations can magnify like this is interesting and may even have some correlation in what we deal with in software projects.