I guess it’s that time again.  What time is that, you ask?  It’s the time when discussion/debate flares up over Context-Driven. I’m not going to weigh in on the whole discussion of pros/cons, value/distraction, etc.  I am a consultant.  I am Context-Driven (and not just as a tester, it's simply the way I have operated since long before I was a tester and long before I became aware someone had coined a term and composed a set of principles around how I already operated).  The license plate on my car says “CONTEXT”. It works for me.  But my point isn’t to convince you that it’s right for you.  My point is to address a comment that I frequently hear that *feels* very sad to me.

“Where I work, I don’t have the freedom or authority to implement all this Context-Driven stuff, so I guess I don’t get to be part of the club.”

I find this sad, because I don’t agree.  It is my opinion that “Where I work, I don’t have the freedom or authority…” *is* a "driving context", making smart decisions about what you are empowered to choose, and appropriately trying to inform/educate those who are "driving your context" that there are other options qualifies as being Context-Driven... at least to me.

The 4th Annual Conference of the Association of Software Testing (CAST) 2009

Colorado Springs, Colorado, July 13-16, 2009

Serving Our Stakeholders

Opening Keynote by: Dr. Jonathan Koomey

Closing Keynote by: Robert Sabourin & Tim Coulter

Invited Speakers: Mike Dwyer and Kevin Brennan

The 4th Annual Conference of the Association of Software Testing (CAST) 2009

Colorado Springs, Colorado, July 13-16, 2009

Serving Our Stakeholders

Opening Keynote by: Dr. Jonathan Koomey

Closing Keynote by: Robert Sabourin & Tim Coulter

Invited Speakers: Mike Dwyer and Kevin Brennan

Did you ever felt like this “Why managers and developers want to teach me how to test?! I’m the tester. I know how to test!”. Ever wanted to teach the cook how to cook to satisfy your taste?
The trick I’ve learned is to let stakeholders influence what I test but decide how to test it myself. However this is not so simple: to let them influence I must make testing process crystal-clear for them. And it means different things in different contexts (and you know - context changes in time).

No further commentary needed.

--

Scott Barber

President & Chief Technologist, PerfTestPlus, Inc.

I’m a manager who is still testing. I can afford to do what like to. This makes me very productive at what I do. When setting objectives for a testing task I take into account following:

What must be done (the value of the task)

What I think I can do well

What else could I learn to do (better)

And I try to hire testers who are like me. And I try to treat them as myself – I take the same 3 things into account when set objectives for them. Well, I try to.

No I don’t mean TV show about people living weeks on a beach. I somehow mean show on a discovery channel. I want to tell you what I learned from a project. It was supposed for 3-4 experienced testers, but I did it all by myself. I had to sacrifice all my beliefs of test management to do so. That’s why I admit I no more understand how to manage testing (well).

Just red a blog about developers having no idea of what QA team is doing. As I can’t seem to be able to add a comment to Michael Furmaniuk’s blog (which is by the way in the list of blogs I read) I decided to write a short reflection here in my blog.
Well, developers may or may not know read our test cases and learn what tools we are using. But developers know for sure what the requirements we have and what the code testers get. They know the bugs testers report. What they are most curious about (in my experience) are two things:
1) How do we manage to find all those bugs they missed.
2) Why do we sometimes find them so late.