Month: September 2011

Published inQualityTesting

The Value of Testing … Relative to Quality

written by

The perceived value of testing is often related to how test teams believe — and promote — the idea that they “test for quality.” The reason I say that is because I maintain quality is value to someone whose opinion matters. You might want to check out my post on testing for quality where I covered a lot of these points. What I didn’t cover in that post is the value of testing itself. The value of testing can be trickier than you may think. Let’s start with this: people will place different value to the quality they perceive. Do we agree on that? If so, I argue that the value of testing that people perceive will be in direct proportion to how much they believe your testing tells them what they need to know. Different people will need to know different things given that their valuations regarding quality will be different in some cases.

What you end up with is dynamic assessment of value and it’s here that testers can start to think a bit more deeply about how what they do provides value.

Continue reading The Value of Testing … Relative to Quality →

Published inQualityTesting

“Testing for Quality” and Making Informed Decisions

written by

Sometimes you’ll hear testers talk about how they “test for quality.” My problem with that phrase is that it’s a potentially dangerous one. It’s an even more dangerous expectation unless some ideas of what the phrase actually means are sorted out. Once you have an idea of what “test for quality” actually means, maybe you can craft intelligent processes around the phrase.

If you’re going to do that, make sure you know why you test and make sure you have some idea of what quality means. Without some thinking around those two areas, “testing for quality” is nothing more than something you say to make managers feel good.

Continue reading “Testing for Quality” and Making Informed Decisions →

Published inThinking

Testers Are Not Either-Or

written by

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.

Continue reading Testers Are Not Either-Or →

Published inThinking

Deviations Magnify – And That Can Be a Good Thing!

written by

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.

Continue reading Deviations Magnify – And That Can Be a Good Thing! →

Published inQualityTesting

How Big Is Your Testing Umbrella?

written by

I’ve worked with lots of testers who often take on more work than they should because they have the idea that the work they are taking on is what testers should be doing. It’s often not a question of whether they should do this work given their other constraints, but rather just a focus on how they can regardless of those constraints. Granted, many companies seem to foster this by job descriptions that suggest someone needs to be a developer, DBA, business analyst, and tester all in one. A main aspect of my job description as a quality assurance and test practitioner comes down to defining a role, usually separate from the relatively anodyne job descriptions we’re all used to.

Continue reading How Big Is Your Testing Umbrella? →

Published inBDDTesting

Testing By Any Other Name…

written by

In my post Are We Defocusing Our Development and Test Practices? I was talking about the various “driven-development” terms. I had brought up how Behavior Driven Development (BDD) seems to have largely come about because some people felt that the term “test” was a bit too confusing for some people or, at the very least, off putting for some reasons that are not explained very well. There was thus apparently a shift to “examples” that talked about “behavior” and this was somehow different than a test. And this somehow made everything a bit better. But did it? What was it about the terms “test” and “testing” that were just not working? I’d rather people deal with that problem before thinking we need to come up with new acronyms. I say that because, ultimately, the concepts of a “test” and the activity of “testing” is still very much there.

Continue reading Testing By Any Other Name… →

Published inBDDTesting

Are We Defocusing Our Development and Test Practices?

written by

As a tester, you’ll hear about behavior-driven development (BDD). Sometimes this goes by acceptance test-driven development (ATDD) or maybe even acceptance test-driven planning (ATDP). You may hear that these are related to test-driven development (TDD). After a while you might start to wonder if these are just different ways of saying the exact same thing.

Continue reading Are We Defocusing Our Development and Test Practices? →

Published inAutomationQTP

Show Some Class When Using QTP

written by

A lot of testers use QTP as a record-and-playback tool first and then add some logic to start building a framework around whatever their test scripts are. That’s an approach that can work but those same testers often don’t utilize one of the key strengths of QTP, which is it’s object-oriented structure.

Rather than treat it as obvious that using classes is a good idea and without giving a tutorial to object-oriented programming here, I plan to showcase some specifics to keep in mind when using a class-based approach in QTP as well as give a specific example of how this approach can be useful by showing how you can encapsulate your logic for better maintainability.

Continue reading Show Some Class When Using QTP →

Published inThinking

Winning Battles, Losing Wars

written by

One thing I’ve found that’s helpful to me in my career as a tester is the ability to abstract information from one venue to another. Testers and especially those who do Quality Assurance activities must be reasonably adept at abstracting knowledge from one domain and applying it in another, all the while accounting for those parts that don’t apply in the new domain. There are many ways to look at this but here I want to consider problem solving as a technique. I’m going to look at the technique of problem solving in relation to the domain of combat. My goal is to show how you can translate aspects of the combat domain into your more traditional day-to-day scenarios.

Continue reading Winning Battles, Losing Wars →

Published inTestingThinking

What Can Time Travel Teach Us About Testing?

written by

I have long maintained that testing is ultimately about thinking. A lot of your work is going to be predicated upon spotting incongruous elements (whether in documents or application code), resolving potential ambiguities in what you read or see, and dealing with potential inconsistencies or outright contradictions. Sometimes people will frame problems in such a way that your ability to “solve” or deal with the problem effectively is compromised from the start.

A good way to practice your thinking skills is to apply them in an entirely different arena than software testing.

Continue reading What Can Time Travel Teach Us About Testing? →