Rhythm of Testing

Process and Ritual and Testing, Oh My.

2012-03-04T18:31:00.001-05:00

I've been having some interesting conversations lately. Well, I have a lot of interesting conversations, so that is not so unusual. The interesting thing about these is that they have been, well, interesting.

Not interesting in the way that some conversations on some online testing forums are interesting. Not interesting the way that some conversations in groups in LinkedIn are interesting (you know the ones - where someone posts a question to get folks to start to answer then the person posting the question shows how smart they are and gives the "right" answer...

These conversations were around "Process" and "Best Practices" and things of that ilk. Now, most of you who know me will realize that I take a dim view of 99.99999% of the "practices" that are labeled as "best." I concede that in some situations, there may be something I am not aware of that can be considered a "best practice" - in the literal definition, not the buzz-wordy defnition.

Where was I? Ah, yes.

These conversations were debating/arguing/asserting/rejecting the need of control and repeatability and measureability in software testing. What I apparently failed to comprehend was that sometimes these things must be done in order to make sure the product is of "good quality." I kept asking "How is it that this practice ensures the quality of the product? Is there another practice that could give you the same results?"

The answer reminded me of a passage from a pulp-fantasy-fiction book series I read a long time ago. You see, there was this particular race of dwarves who weren't terribly bright. One of them found a secret passage. At the time she found it,(yes, there are female dwarves) she was carrying a dead rat (seemingly for supper) and triggered the locking mechanism by accident. This opened the door that let her take this "secret short-cut."

Well, she was making the main characters in the book take an oath that they would never divulge the magic of the passage. One of them mentioned the trigger, which he noticed, she insisted it was magic. She pulled out the dead rat, waved it in front of the door - then stepped on the trigger. POOF! The door opened!

In her mind, the ritual of waving the dead rat then stepping just so on the floor was what opened the door. The others (outside observers) noticed what the real cause for the door opening was.

Because it did them no harm to allow her to hold on to her certainty, they let it go.

Now, in software testing, we sometimes find ourselves in the situation of the not-too-bright female dwarf. It worked this way the first time, therefore, this is the one true way to make it work every time.

Instead of a process, it becomes a ritual.

Are the processes we are working though aiding the testing effort, or are they gestures? Are they helping us understand the application, or is this the ritual we must go through to get green-lights on all the test cases?

If its the later, would an incantation help? Maybe something Latin-ish sounding like in Harry Potter?

Thinking Testers, Unite! or Sometimes Thinking Needs Action

2012-03-01T21:01:00.000-05:00

It is hard to believe that this is the First of March. This year is simply flying past.

Coming up, for me, is a BBST Foundations Course that I am an assistant instructor for. BBST is offered through AST - the Association for Software Testing. It is an amazing course - the product of an awful lot of people, notably Cem Kaner assisted by a Legion of folks.

Yes, 1 March is here, which means that CAST 2012 is fast approaching. CAST, the Conference for the Association for Software Testing is this July, in San Jose, California. The Registration for the Conference is open now. It is an interesting, if not astounding, experience. You can check out the official page here .

If you're reading this, I strongly suggest you go to, and participate in CAST. My first year was 2010. I was amazed, overwhelmed and, well, gobsmacked. This year's conference promises to be something, well, go to the link above and check it out for yourself. OK?

If you'd like to try your hand in presenting, or maybe you have presented elsewhere and want to try the formula used at CAST, the Emerging Topics track may be a solution. These are 20 minute snippets - enough for you to present the core of an idea and answer questions. The deadling for THOSE submissions is June 18.  The Call For Participation, and the information you'll need is here.

Emerging Topics tracks are 20 minutes long. Total. The interesting thing, like with all CAST tracks, is the discussion at the end. For Emerging Topics, the discussion is at least 5 minutes. (Translated, the track host will cut off each presenter at the 15 minutes mark. If you end before then, GREAT! More time for discussion!)

The information you need to know about submitting proposals is on the website at the link above. If you are a Thinking Tester, I encourage you to consider attending CAST. If you are interested in telling people about your ideas, I encourage you to consider submitting a proposal.

Now, I wrote about this before, but I'm going to mention it again - If you are a Thinking Tester and you help people become better testers - the Test Coach Camp is the weekend before CAST!

The Camp will be the weekend before CAST - in the same hotel where CAST is going to be held.  Space is LIMITED.

Matt Heusser wrote about it here. The official AST release and Call for Participation can be found here.

If you are interested in helping testers do their testing better, which is what Test Coaching is all about, and in Thinking Testers - Look into both of these - THEN ACT.

This is going to be a great week.

On Metrics & Myths or Your Facts are From the Land of Make Believe

2012-02-29T21:16:00.000-05:00

Its been a quiet week in Lake... Oh wait. I'm not a famous radio personality with a show centered on a town that does not exist. I'm a tester.

Sometimes though, I feel less like someone from Lake Wobegon, MN and closer to someone from Brigadoon. Both are fictional, mythical if you will, and both have certain charms and appeal about them. Except for one minor point. Out of context, they make very little sense.

So, the last several weeks I have been working away on studying metrics and concepts around them and things of that ilk. The cause of that was the combination of "training" required by the day-job, and getting the new set of metrics for the "Scorecard" - yup - Metrics applied to the individual, team, group and department. Oh my.

So, I went digging though my notes and found a variety of ideas, some good and some less than good, from a variety of sources, some reliable and some less than reliable. Some of these we just plain contradictory. Some had ideas that, in and of themselves seemed reasonable, until you considered the assumptions and presumptions that must be made and taken in for the numbers to actually make sense.

I found myself rereading articles by Cem Kaner, Doug Hoffman and others cautioning against misusing metrics. I likewise found learned discussions around how metrics can be relied on if you take emotion out of the equation and look just at the hard, empirical data.

Then I saw a tweet from Michael Bolton, recommending the writings of Laurent Bossavit as being worthy of consideration. So, I followed the link and began reading. What I found was a fellow who had written an e-book that seems interesting. Don't take my word for it. His Twitter handle is @Morendil. Search for him and begin reading. Or, check out his e-book - Cool title - The Leprechauns of Software Engineering. Find it here: http://leanpub.com/leprechauns You may not agree with everything, but much is worth your consideration.

Where was I? Oh yeah. Metrics.

Matt Heusser and I had an interesting chat last month while on a flight to New York. He asked me my view on metrics. I responded that my general view was that most people misuse the term and the concept.

I believe that metrics should serve to address questions we are seeking enlightenment on (kind of like testing, no?) A painfully large number of companies focus on stuff that is easy to count, without looking to see what that information might tell them - beyond the obvious.

I believe that most people trying to address questions with these "metrics" really don't have a good idea what the questions they want to ask are - and so they settle for what they can get easily. Things like bug counts, test cases, test cases executed per day, failure rates and things of that ilk. Instead of looking for things to help constructively help their staff, their people, do their work better, it is easier to look for control metrics.

They'll misquote Drucker or Lord Kelvin or - heck - maybe they've just heard so many truisms (that aren't really true) that are misquotes that they accept them at face value - an awful lot of us do. They'll look to change behaviors by making a big deal about metrics and ... well, stuff. What they get may not be what they intended to get.

Be careful in dealing with metrics - not all is what they appear.

Be careful when playing with dragons for you are crunchy and good with ketchup.

Where Has Pete Been, or Time Flies When You're... really busy

2012-02-29T21:05:00.000-05:00

I can not believe so much time has passed since my last blog post.

OVER A MONTH!

I have several in the works and will be posting one shortly after this - I promise.

Since the last update, I've been crazy busy at the day-job. I spent several days in New York with Matt Heusser hanging with some really smart people and talking about testing. I made some new friends and chatted with people I knew by reputation and cyberly - but met in person for the first time.

One night I participated in a panel discussion hosted by the Financial Services Special Interest Group of AST - the Association for Software Testing. What an interesting experience - lots of different view points and ideas around some seemingly simple questions.

We had a great time.

I've also had some interesting conversations when we got back - lots of interesting things happening in testing all around the world, it seems.

I had, at one point, signed up as a "contingency instructor" for the AST's BBST Foundations Course - translated, there were folks signed up, a head instructor and two assistants, and I agreed to help out if one of them could not do the class. As it is, I got an email this last week asking if I was willing to help out. So, I'll be doing some online instruction.

There have been a stack of problems facing day job stuff - projects that simply were not working right - lots of work there. Did I mention that before?

Oh yeah, I had "unexpected oral surgery" shortly after getting back from New York and I'm like WAY behind in my writing. Sorry folks - I'll get there - I promise.

I also have been trying to catch up on the music writing I've been trying to get done.

And of course, being a husband, dad and - Oh yeah, my neice got married as well.

So, sorry for the backlog - I'll get caught up soon.

I promise.

CAST 2012 Tracks, Workshops, Emerging Topics, Coaching And Deadline #1

2012-01-12T21:58:00.000-05:00

CAST 2012 is fast approaching!

Well, some folks may think that JULY is not all that "fast approaching" in January - HOWEVER - there are some important dates coming up.

The Call For Participation is up (here). There are three basic types of presentations:

Interactive Workshops (140 minutes);
Regular Track Sessions (70 minutes - at least 25 minutes for discussion);
Emerging Topics (20 minutes - at least 5 minutes for discussion);

The deadline for Regular Tracks and Workshops is January 16. As I write this, that is FOUR DAYS AWAY!

The information you need to know about submitting proposals is on the website at the link above. If you are a Thinking Tester, I encourage you to consider attending CAST. If you are interested in telling people about your ideas, I encourage you to consider submitting a proposal.

Now, if you think you might like to present, and are unsure of actualling presenting - the Emerging Topics track may be a solution. These are 20 minute snippets - enough for you to present the core of an idea and answer questions. The deadling for THOSE submissions is June 18. You can submit through the same process the Regular Track and the Workshop sessions are submitted.

Here's where it gets interesting. If you are a THINKING TESTER - and help people become better testers - the Test Coach Camp is the weekend before CAST!

Test Coach Camp will be held at the same hotel where CAST will be held.

Matt Heusser wrote about it here. The official AST release and Call for Participation can be found here.

These folks said it better than I can.

If you are interested in helping testers do their testing better, which is what Test Coaching is all about, and in Thinking Testers - Look into both of these - THEN ACT.

This is going to be a great week.

Janus Part 2: Looking Ahead 2012

2012-01-02T13:00:00.000-05:00

Last year was really incredibly busy for me. Work stuff happened that was crazy hectic, then the "speaker" thing moved from 1st to 2nd gear. Then the broader community expanded a bit more - or maybe my awareness of it did. The local testing group moved from "once in a while" to "monthly meetings".

What am I looking forward to in 2012? That is an interesting question.

Personal/Professional Development

This is something that is kind of included in the following areas. There is much I want to learn and much I want to participate in - to help learn and see how things work in the world and not just in the theory/idea stage. Broadly, I want to "engage closer" in the local test community, the broader community of thinking testers, a variety of projects and meetups and... life.

So, a little more detail...

Projects, Writing, Work.

The day-job is the day-job. Yeah, there will be some interesting projects there, including a cool mobile device project. The projects I mean here are some interesting side-projects - things with other people. There are some cool initiatives with Matt Heusser that are interesting. Matt is a bundle of energy with lots of ideas. I'm flying as his wing-man on some items coming up (more on that as they get closer on the horizon.)

I'm looking into doing more writing. Writing is cool. It is work I can do anywhere and still have some semblance of a home life. Its funny - the more you write on a topic, the more you find there is to learn about on the same topic. So, if I can continue the process of writing/learning/sharing - so much the better. There are some magazines I've decided I want to approach about article submission - and follow-up on some contacts from late in 2011. Look for more on this in the near future.

This past August, I expressed an interest in getting more involved in the EdSIG - Education Special Interest Group of the Association for Software Testing. Aside from a few emails, I've been really lax in that. I want to change that this year. I'd like to become more involved with, and as a result learn more about, training software testers - helping them learn and think and grow as craftsmen.

Two interesting factors here - First is the announced Test Coach Camp the weekend before CAST - the Conference for the Association of Software Testing. This year's conference theme is The Thinking Tester - its going to be cool. The Coach Camp though is a new addition and it looks fantastic - a peer conference to talk about improving how we coach testers. I'm excited about that.

The second interesting factor is I volunteered to be a "contingency" instructor (I kind of missed the rush of people signing up to be "assistant" instructors because I let non-work email slip a bit while wrapping a project) for the BBST Foundations Course this March. I don't know if it will balance out, but I'm looking forward to it.

Community

Aside from the education and learning stuff, there are other aspects I'm looking forward to engaging (OK, note, don't try and write something after watching "Office Space" and trying to sound "professional"). The local tester group is up and running - next meeting is in two weeks and on a topic that should bring about good discussion - we're talking metrics. Oh yeah, pass the popcorn.

Toward the end of 2011, I began attempting to be more helpful in online forums - I'm afraid some folks consider my approach "annoying" - others seem to realize I'm asking questions to help me form an answer, and will "play along".

There are, of course, a pile of conferences out there - the mentioned CAST conference in July. STPCon Spring, I'm afraid I can't make work, but there are other possibilities out there. It will be a busy, fantastic year that way, I think.

Cool People

There are many folks out there that I spend time with as much as I can. There are others that, if I can, I want to spend more time with, learning from, learning with, sharing ideas and getting a clue. Now, some are broadly spread - over North America, Europe, some in India... So, kind of a "I'd like to and I'm not sure I can make it work, but I want to" list.

In generally alphabetical order, people I really want to find a way to hang with and learn from this year...

Perze Ababa   Ajay Balamurugadas   Bernie Berger   Paul Carvalho
Salena Delesie   Markus Gaertner    Paul Holland     Phil Kirkham
Micahel Larsen   Darren McMillan   Catherine Powell   Mark Tomlinson
And of course, the folks I enjoy learning from already, although meetings are sometimes few and far between, and often only by Skype - Fiona Charles, Michael Bolton, James & Jon Bach, Griffin Jones, Nancy Kelln, Lanette Creamer, Matt Heusser, Mel Bugai, Lynn McKee... and all the rest.

For all you have done to help me learn, thank you. I look forward to learning with you all this year.

Janus Part 1: Looking Back 2011

2011-12-30T21:25:00.000-05:00

One of the benefits of taking four years of Latin is that you pick up all kinds of interesting things that many other folks may miss. Then again, an awful lot of people don't worry too much that "i.e." is an abbreviation of "id est" or, "that is". Just like "etc." is an abbreviation of "et cetera" - even though they may even SAY et cetera, I wonder how many know what it means? I'm mean enough to not say here, and say "look it up" - unless you remember your Latin as well.

Janus, for whom the month of January is named, looked both forward and back. That is a bit of what I want to do with this post and the next. The post I wrote last night was a precursor to these couple of posts, partly because the things described yesterday laid the foundation for this past year and the year to come.

What I wrote January 1, 2011:

The Road Ahead...

The interesting thing is I've been thinking about the future. Well, not THE future, but what lay ahead for me professionally and how that may impact the family. It would seem there are several items that are possibilities for the coming year. One path would be to look for new work opportunities, either as a contract/consultant or as a full time, permanent employee. Yeah, as if "permanent" means much.
A bunch of folks commented privately, "Dude, pretty gutsy to say you'll be looking for work when you're still employed." What I could not say then, was that in December, the entire staff of the company I worked for was told, in essence, that the company leadership was negotiating the sale of the company. We did not know to which other company, nor what the terms would be. Many of us speculated that the only reason we were told at that point, was because they needed us to sign releases of our stock options in case the sale closed before the end of the year.

It was not a bold move to make such a prediction - I simply knew there was a likelihood that I'd be looking for work. When one company assimilates, well, acquires, another company, "long term employment" prospects for the staff of the acquired company are not terribly high.

As it was, I was not let go. I was retained. One colleague resigned after accepting a new position. His last day, we had a farewell luncheon for him. By the end of the next day, myself and another tester were all that remained of our team. One other person, a developer, had been transferred from the development staff to testing. although others on the team

We are continuing, and moving forward.
Community

Another option is to become more involved in the testing community. Actually, I started working on that as well in 2010. What I mean is that reading blogs other folks write is a good way to learn what they're thinking is. Reading and participating in on-line forums is another way to both learn and become involved. Well, doing that as much as I can right now.

Of course, more actively engaging in both of these types of activities is on my list of things to do this coming year. Ya know, the funny thing is, the more I talk with folks about things I learn and have learned, the more I learn myself.
This continues. I've been writing. Alot. STP Magazine and TechTarget's SearchSoftwareQuality both have run articles I've written. my more in my blog, and more engaged in forums than ever before.

I expect this to continue and grow in the coming year. That would be way cool.

Local Testing Groups

Another thing, the local testing group, GR Testers, has been going in fits and starts for a while. Meetings have been sparse of late. The most recent one, December, was kind of fun. There were a bunch of us sitting around a table, lots of wings, good beer and folks talking about testing. Good way to spend an evening. There's another meeting coming up Monday, 3 January. It makes it the first time in quite a while that there were back to back monthly meetings. Normally, they are officially held every other month. It seems that as more people are showing an interest, the meeting frequency will pick up.

I wonder how many other local testing groups are out there that have a meeting schedule based on "whenever" instead of "We meet at this time, and here are the next couple of topics we're focusing on at these meetings..." I believe that the more people know about local groups, the more they are invited to participate and the more information that is available about them, the more active and the stonger the community there is.

I think that pretty well sums up what I'm looking to do with the local group. I believe that getting more people involved and talking about testing is vital to improving not only our individual tradecraft, but the abilities of the local community. Sharing well reasoned ideas can do nothing but good, presuming all are allowed to learn and ask questions

The GR Testers, the local testing group, is up and running strong. The group has met monthly since that January post. I've made it to most of the meetings. The ones I missed, I was out of town, usually at a conference. Cool.

Personal Development

Now, I realize that any of the above activities can lead to improving any individual participating. What I mean here is something a bit more. I had been signed up for the BBST Foundations course offered by the Association for Software Testing for a session in in the fall of 2010. Things happened and that session was cancelled. I could not take the session offered as an alternative.

The GOOD news, for me, is I am signed up to take the Foundations course this spring. YEAH! I am really looking forward to this. Everyone I know who took the course raves about it. Big-time excited.

I've continued reading blogs and articles and books and talking with people and... everything else. My goal is to continue learning and to continue to share what I learn.

For conferences, I'll be attending and presenting at STPCon in March in Nashville. I bought myself a birthday present and renewed my AST membership in October. If I can work it out, I'll be attending CAST in August in Seatle.
This happened beyond my wildest dreams. I took and passed the BBST Foundations course. Then, even though the schedule did not permit me to take the Bug Advocacy course - that is on the list for next year for me. I also took the Instructor's Course from AST. We'll see how the schedule works out this coming year.

Conferences. I presented at STPCon (Spring) in Nashville. I gave a joint presentation with my (then) boss, Kristin Dukic, as well as a presentation and lightning talk on my own. I then was flattered, and honored, to attend and participate in CAST. With Matt Heusser, I helped organize the Emerging Topics track, where a self-organized group selected topics submitted via a wiki - then ran for 20 minutes, every 25 minutes. It was astounding.

After CAST, I had the opportunity to present at STPCon Fall in Dallas. Matt Heusser and I did a day-long workshop (excerpts are on the Software Test Professionals site, under Podcasts) - then a joint track session on "Complete Testing". THAT was a lot of fun. I also presented a track session on my own as well as a lightning talk. Matt just gave a keynote.

Then since I was not busy enough, I presented at TesTrek in Toronto in November.

Whew.

Other Stuff

Scads of people have encouraged me this year. Among them, Matt Heusser, who put me in contact with the folks at TechTarget, and made the case that he could not do Emerging Topics at CAST on his own - which is how I got in. Cool, heh? THEN - Matt had so much fun with that, he asked if I'd be interested in doing a joint workshop in Dallas. Oh yeah. The interesting thing is that he's really a nice guy - as the folks who know him will attest.

Also - Fiona Charles is supportive and encouraging. She is really an amazing person who is willing to offer suggestions and ideas on how to improve articles, presentations, whatever. She also is way cool. She was one of the very first people that I consider a "Name" in testing, to ask for comments on a paper - the list me in the acknowledgements. Humbling.

Catherine Powell whom I met in person at STPCon in Nashville always has encouragement and good suggestions. Michael Larson is a great guy. He's got a great outlook on life and testing. His blog is inspiring. Doug Hoffman was the Head Instructor for the BBST Foundations course. What a smart guy. Nice as the day is long. We had several very nice chats both at CAST or at STPCon Fall. If you get a chance to see him present - DO. Cem Kaner - yes DOCTOR Kaner - the drive behind the BBST Courses. An ongoing inspiration.

There are more - Michael Bolton, Lynn McKee, Griffin Jones, Nancy Kelln, and many more. These are the people I look to for inspiration and mental reinvigoration.

And of course, my lady-wife, Connie.

I do not know what the future will bring. I will discuss what I hope for the future in the next post.

Rising From the Ashes or Finding Motivation in Disaster

2011-12-29T22:02:00.001-05:00

This has been an interesting year. There have been many fantastic things happen this year that at times it seemed like I was an observer, and not the one participating. I've presented at more conferences this year than I attended any year before this. People write emails asking questions, looking for insight or help with a sticky problem, as if I'm an expert.

I've written before about not feeling like an expert. This is not about that.

While preparing for STPCon this past October I had an interesting in a couple of thoughts. While working on the presentation, and a couple of papers, I mentioned one of these thoughts to a fellow member of the GR Testers group. We chatted (cyberly) for a moment on how failure can be a great motivator. We talked about people who had overcome problems and adversity to rise to great things.

Of course, there are also many examples of people who break under adversity.

I don't know what the differences are in those scenarios. I don't know why some people crumble, others recover and come back to where they were and others rise to greater success than they have ever known. The last group, to me, resembles space capsules, like the old Apollo capsules, that would whip around the moon to accelerate even faster than they were going. Yeah, in Star Trek Kirk did the same thing with the Enterprise around the Sun. Cool, no?

The second group, I kind of think of as being a bit like a rubber ball. Not a fancy "Super Ball" that used to be sold with the assurance that it would bounce higher than where it was dropped from (and rarely did as far as I know) but a plain bouncing ball. Comes back to where it was, but somehow not quite the same.

The first group, like I said. I don't know why people fail to recover. The just don't for a variety of reasons.

Me. Hah. I was moving up. I had left one company where I was simply unhappy, and joined another company as a Test Lead. There were "issues" there. I was hired to improve testing and change the way testing was being done. Well, things were not working out. I had a series of "those meetings" and the last one was handing me a package and me walking out the door. (I'll be happy to give more details over adult beverages sometime, if you really want to know.)

So, I went home, popped in a video, cracked an adult beverage and said "What happens next?"

Short term, I knew what had to happen - I needed to get ready to teach drum lessons that evening. So, I had a single beer, watched a movie, fried some bacon and eggs and felt sorry for myself for 3 hours. Then I made a strong pot of tea because I had work to do.

I made a list of what I was good at and what I was not good at (no PC here, not right then.) I went through the list of what I was good at that and highlighted those I liked to do and those I wanted to get better at doing.

I then went through the list of what I was not good at. I split that list into "so what?", "consider improving" and "fix it". I then considered a list of things I had read about and had done very little with or knew very little about. I also made a list of things I knew nothing about, but I'd seen mentioned in articles and blog posts and said "this might be worth looking into."

I then went on and read what I could, learned what I could and did some serious soul-searching on what I really wanted to do. I then looked at how I would fix the stuff I really needed to fix. This was hard - really, really hard.

This led me to the next step - Updating the resume, looking at what I wanted to do and where I wanted to do it. I knew that (at the time) West Michigan was not a hot-bed for top-flite testing jobs, project management jobs and my development experience was not in technology that was in demand. On top of that, the economy was beginning its downward slide. So, I figured it would be a good likelihood that I would need to relocate.

I looked and I looked... and I looked some more. One month, I applied to 158 jobs. All over the US, Scotland, Ireland and Australia.

I learned a lot. I've been applying those lessons ever since.

First - Be involved. Online, locally, within the company, within the team. Look for ways to learn and improve. If someone looks for advice, guidance or a sympathetic ear - do what you can. If something sounds familiar to a situation you were in, talk with them about your experience.

Second - Share. Now, in some ways, this is similar to the first lesson. Write. Blogs, forum posts, responses to posts or online articles.

Third - Learn. Keep learning, keep reading, keep thinking.

Four - Dare.

Five - Repeat.

Four years ago, the foundations for these really, really simple ideas were where I started. I landed a job after a stack of interviews. Some I knew would not be a good fit. Others, well, they decided it would not fit. I was ok with that. When I landed the gig I landed, I talked with people. I learned. I learned their applications, their methods and their personalities. I learned how they worked and did things.

I shared ideas and experiences. I contributed when I could and asked questions when I did not understand.

Then people began asking me questions - How can we learn more about... Have you ever run into...

As a result of one series of these conversations, I landed at TesTrek in Toronto, where I met Fiona Charles and Michael Bolton in person, for the first time. I also met a whole slew of people I had never met before, Nancy Kelln, Lynn McKee and slew of other bright folks.

That week in Toronto resulted in me getting more involved, helping revitalize/reinvigorate the GR Testers, then scrap my drumming blog and move to writing on testing. That helped with presenting at conferences... and that led to, well, this most astounding year.

Where did this come from? Getting fired.

You don't need to get fired/sacked/down-sized/happy-sized/whatever to do the same. If you want to grow, then do it. If you want to get involved, do it.

The fact is, doing these things may not make you a leader or a superstar or being called an expert. But, if the world comes tumbling down around you, if you have been doing these things, others can step up and help. If you have established connections and a reliable cadre of people, they can help just as you can help them.

On Patterns and Blinking and Puzzles and Expectation

2011-12-26T13:53:00.001-05:00

Our family has a lot of traditions around the winter holidays, Christmas and New Year. One tradition is working on a massive 1,000+ piece jigsaw puzzle. We see it as beneficial in many ways. When the kids or grandkids are around, for them to participate ("become engaged") this thing that we are doing, they need to slow down. I've yet to take any pleasure from assembling a puzzle that can be whipped through in an hour or two.

Our puzzles tend to take a week or more to be completed. We'll start them one evening, then each day tinker a bit as each person has a few moments. In the evening, we try and set aside 30 or 40 minutes to work on the puzzle together. We've found it a great extension of "dinner table conversation" where we get caught up with each others' day.

Oh, we both like doing puzzles too, which is perhaps the biggest reason why we do them.

So, this year's puzzle was a photograph of a Scottish castle, no I don't know which one, with hills and mountains and things in the background, a bit of water near the castle (hard to tell if it is a river or a loch or merely a fair sized pond.) Like a lot of the better, or harder, puzzles, there were many bits that, well, looked a lot like other bits.

In sorting out which bits are which, you need to look for subtle differences - small changes or variances in the overall image. So, this last week, I had a portion that I was sure were part of the castle's battlements - the tops of the walls or towers. Then I noticed another piece - JUST like the one I had in my hand. but a little different. There was a small line in the piece I had that was not in this new piece.

I blinked. Literally.

The portion I was working on was indeed part of the battlements - but the reflection of the battlements in the water - not the actual "top of the wall" stuff. I was reminded of a defect I had spent time trying to track down on a recent project.

I had a set of expected results and behavior, my "oracles" - and the results - what I was actually seeing, were really really similar, but not quite what I was expecting. It looked right, but something did not feel right. What I was expecting, based on the described behaviors and expected results, was generally what I was seeing. But something did not feel right.

It was kind of like the puzzle pieces. One looked like what I expected it to look like. The other was, well, different.

That got me thinking about other things.

How many times are we certain that what we expect is really what we should expect? Is it not possible that the expectations are the "bugs"? What is it that makes the "expected results" "right"? Even when you are the one who created the "expected" results, how well do you really understand the software? Do you have a certain understanding as to what the changes will result in?

In my case, my "expected results" were what was at fault - both in the puzzle and the testing.

Once I realized my mistake in the testing, it became much easier to move forward. I will never know about the puzzle, I'm afraid. The orange tomcat who lives in the house with us decided that he had enough of us assembling the puzzle.

I believe, but am not certain, that we found all the pieces after he scattered them from the table.

Should we try and put that puzzle together in the future, I expect we'll find out about any missing pieces.

Coaching and Learning and Opportunity to do Both

2011-12-17T22:06:00.000-05:00

My last post was fairly short, well, for me anyway. This one will be, too. No more rambling oddities that may, or may not, have anything to do with testing. Just kind of too the point.

My last post was on the Call for Participation being open for CAST 2012. It turns out that the weekend before CAST, July 14 and 15, there is another learning opportunity - Test Coach Camp. I'm pretty excited about this.

Test Coach Camp will be held at the same hotel where CAST will be held.

Matt Heusser wrote about it here. The official AST release and Call for Participation can be found here.

These folks said it better than I can.

If you are interesting in helping testers do their testing better, which is what Test Coaching is all about, right? Then I suggest you dive in to this.

Its going to be good.

CAST 2012, The Thinking Tester - Do You Know the Way to San Jose?

2011-12-12T20:10:00.001-05:00

This may well be the shortest blog post I've published in some time. There may be some rambling, but less than what I normally have. Don't look for a deep, thought-provoking idea buried in an apparently pointless story. Its not there.

So, here's the point. If you are a Thinking Tester then you need to know about CAST 2012. The Conference for the Association for Software Testing is scheduled for July 16 through 18 in San Jose, California.

The Call For Participation is up (here). There are three basic types of presentations:

Interactive Workshops (140 minutes);
Regular Track Sessions (70 minutes with at least 25 minutes for discussion);
Emerging Topics (20 minutes with at least 5 minutes for discussion);

The deadline for Regular Tracks and Workshops is January 16.

The information you need to know about submitting proposals is on the website at the link above.

If you are a Thinking Tester, I encourage you to consider attending CAST. If you are interested in telling people about your ideas, I encourage you to consider submitting a proposal.

On Improvement, Or Teams and Process

2011-12-03T11:16:00.000-05:00

I sometimes find it funny. I mean writing a blog and posting ideas and getting comments or seeing who agrees or disagrees via twitter and other "networking" sites.

My last post, on team building, had a reasonable number of hits from unique locations, garnered a few tweets/re-tweets and one public comment. I also got a couple of emails from people I know that essentially said (paraphrasing) "We need to assign people to jobs they want to do? What if we end up with three people on one function and functions with no one assigned to them? That's crazy! You can't operate that way!"

I kind of blinked and thought to myself, "Is that what I said?" So I reread that post and thought about it. I can see where someone might take that away as my point. And still, I don't really think that was what I said.

Consider this.

When talking about process improvement, particularly test process improvement, I say flat out that no cookie-cutter model will work in every shop and then will rarely work for every project in the same shop. To be able for a team to test effectively, someone must have a decent understanding of what the individuals on the team are capable of doing, what they are good at and how well they work together with other individuals on the team.

When you have some idea about the individuals, and you can look at the overall team's work (essentially looking at what the team as a whole is good at) then you can look for ways to optimize the strengths. If you can off-set weaknesses with strengths and make the areas of less-than-optimal performance a little closer to where you'd like them to be, you can free more time and resouces (like money and training/reading material, not people) to grow your whole team's capabilities.

Pairing testers where one is stronger in certain areas than another and allowing them to learn and develop skills while doing them, is one way to spread the workload and allow testers to experiment with mentoring other testers. It can also help develop a closer sense of teamwork and encourage people to turn to other testers for help, if they are not doing that already.

I have found no way to do those things without getting to know what the team members like to do, want to do and are good at doing.

I know we can't always get the fun tasks - the ones we really like doing. We can, however, learn about other things, or maybe find ways to improve and get better at the un-fun tasks. I know for me, some of the things I really find un-fun are the tasks I feel less than comfortable with. Yet as I learn more, those un-fun, scary, frightening things, the ones where I am an absolute novice at, are also the ones that as I learn more, and become better at, become more fun than un-fun.

I think that is the key right there. If we want to get better, sometimes we need to work on the un-fun things and learn about them. The team leader (manager, whatever) may have some idea of what the "fun" tasks are, but if each individual on the team has a different idea of what those fun tasks are, it is almost certainly going to lead to an un-fun experience.

Team leaders, I suspect that if you look, ask, talk and communicate with your team members, you'll find their idea of fun tasks and what they like doing and what they are good at will tend to be the same things. I exoect the same thing will be true with the the un-fun tasks, what they don't like doing and what they are not very good at will probably be the same.

By making the pool of un-fun tasks small for the individuals and the team, by getting the team members to expand their skills, I believe your core testing wull improve. I likewise believe your core team work and cooperation will improve. Finally, I believe your team's morale and sense of working together, their joint craftsmanship, will improve.

Those things will tend to improve the testing your team does. Then everyone will have more fun.

Team Building Or Putting the Fun Back in Dysfunctional

2011-11-24T11:36:00.001-05:00

We've all seen these annoying "team building exercises" where someone dreams up something "fun" that will help everyone "learn to work together."

They can range from the "trust building" thing where one person, blind-folded, follows the directions of someone to get them to a goal. Then there is the slightly more dangerous (hence fun to watch when things go pear-shaped... and they are almost certainly going to go pear-shaped) version where the blind-folded person crosses their arms and falls backward to be caught by another person.

Now, upper body strength may play a role in the success of this version. As does, well, paying attention and at least a rudimentary understanding of physics... and gravity. Usually things combine into a series of "oh my" type moments. Sometimes, well, they end with a little bump on the noggin. (Once in a while its a big bump.)

Then there is the version of "ice-breaker/team-building" thing where two people sit on the ground, back to back with their arms linked. Then, they work together to stand up. The idea is they support each other while using their legs to stand up. Things work just fine as long as both people apply equal pressure at the same rate. If they don't, well one stands up and the other gets dragged along for the ride. Or there's the fun alternative - where they mostly push against each other and end in a heap.

The thing is, most of these efforts strike me as artificial. Translated, they may "work" in some form or other. Most of the time, I see people l go through the motions because the boss told them to, or HR or, someone. They don't see the point.

Sometimes , when teams are "created" or "formed" or "built" or, whatever, you see the same kind of exercises. In these cases, they are even more artificial. People will go through the motions because if they don't, they figure they'll be fired. Fear is a great motivator, at least on some level.

What I don't understand is why so many people think it works.

Its like, oh, I don't know, boss-types throw people together and expect it to work by magic. Well, maybe not magic. I think maybe they expect it to work like a high school chemistry "experiment." You know the type - combine certain items in specific amounts in a specific sequence - POOF! Stuff Happens!

Well - Humans don't act that way. But, when you consider people as "resources" it strikes me as, well, demeaning at best. So, why, when we expect/need people to work together, do we act as if it will just "work."

Most of us will try and work it out and do the "team" thing. Its part of being a grown-up, mature, professional - right? We kind of expect it - and they kind of expect us to do it. So we do the whole storming-forming-norming thing and figure out what we need to do to do the job.

Then, how many times have people seen this?

About the time we sort out how to tolerate each other and actually work and get stuff done - GOOD stuff, not just the bare minimum - someone waves a wand and reorganizes the company (or department or whatever) and expects things to work at the same peak performance as before the change.

Then there is the "optimizing resources" version of that. Most of us have seen or heard of that version of the reorg game.

Someone looks at two departments or divisions or, for the "major league" players of that game, subsidiaries, and says "look at the cost savings we can get by combining X with Y!"

There may be real savings, as in total net savings when the dust settles. How long it takes the dust to settle is, in my mind, the question. This is a variation on the "team building games" but instead of a handful of people, its a bunch of people who may very well know little or nothing about what the other people do.

When this game gets played, I am afraid it is usually for a short-term gain - something to impact the financial statements this quarter or next quarter, with the promise of "real savings/benefits" five quarters in the future.

Then there is the really high-stakes version of the game: Borg, Inc assimilates Minuscule, Ltd.

Well, OK, that may be a slight overstatement. And, to be fair, I've worked for companies playing both parts. Still, for those in the company being acquired, the uncertainty of what is coming can be a bit unnerving. When questions get asked up-stream in the new "organization" and there is no response, then a couple of messages are being sent: 1) We're too busy to respond to your meaningless request for information; 2) Your future is your own (and it probably won't be here).

Now, those may not be what is intended to be sent, but usually that is what gets received by the "non-response."

What I see happen in those situations is a large-scale version of those team building exercise-games I was on about. I usually see a mix that has some posturing, some maneuvering, some "hoping for the best" and some resigned to fate. In the end, there may likely be "staff realignment" actions - meaning some folks get assigned to new groups and others get assigned to "pursuing new interests".

And the game starts again.

So, the hard part is, how do you make that tolerable, if not palatable? Can the people who are still there get by without gritting their teeth and going just a tad crazy? Can the people making the decisions over what the teams, either reorganized or made from those who survived the staff reduction/realignment?

Maybe, to both.

First, the players in the game - the rank and file folks like I have been for most of my working life - YOU are a crucial part of the mix. YOU can directly impact how the game gets played.

Here are some thoughts around what I mean.

People on other teams, groups, departments, whatever are probably not villains in their own mind. They may well be trying their best in circumstances they find challenging, at the least. They may very well see you as the villain.

How can you find out about that? Can you see if they are really villains? Can you see if they are as clueless as you have been told or come to believe?

Maybe. I can't be certain if you ever will. However, if they work in the same building or general location as you do, try this simple thing: Walk up and introduce yourself. :"Hi I'm Pete (well, only say that if your name is "Pete" - try putting your name in there instead) I work in department X. Can I join you?"

Talk with them. See what makes them tick. It may take many conversations, but it is worth a start. After all, you may also be able to dispel the myth that you have horns, a tail and cloven hooves for feet.

If they have a similar job function that you do, try talking with them about the problems they run into and how they get over/around them. Oh, and be willing to share what you are encountering as well. Make it a mutual learning experience.

Pretty simple, eh? I found it works pretty well. Not all the time and not 100% - but generally, it helps people see that other folks are, well, people too. It may also give you some insights as to why Tezm Z can't seem to turn out anything your team can work with. And the folks on Team Z may find out that you don't really mean to be a butt-head.

Things kind of work both ways like that.

Managers, Leaders, Bosses - you can play a role in this, too. Before "realigning" groups, have a thought to what the people in those groups are good at. Find strengths that complement other people's strengths. Combine them when you can.

I know - most of you believe you are giving it your best effort. A fair number of you do.

Others, admit it, if only to yourself, are looking to hit the target for head-count or "employee expense" (payroll) or "employee cost-reductions" (sacking high-paid folks) that you were told to hit. Wel,, you, boss, or whoever set those targets, is a boss too. Talk to them about this. Try anyway. Don't whine,

I call that the "penny-wise/pound-foolish" managenment style. Sure Jane makes a pile more money than these three people - what skills does she have, what knowledge does she have - do the others have those skills or knowledge? Do they together? What is the impact to the product (hence customers, hence sales, hence bottom line) if we sack her and leave them? What if we sack her and one of the other three?

Of course its not easy. Back when I was in school, the argument was that managers, directors and bosses were paid a pile more money than other folks because they could and would make "hard decisions." HELLO! That concept constitutes a "hard decision." Going with the simple "she makes more than the others, get rid of her" is not a "hard decision." If that is how you are operating, stop! Really.

OK, now a scary point. This is for line managers and staff - rank and file folks like me.

When you get "reorganized" you have an option. Agree to the terms or pack it in and find another gig. Simple. "But the economy is bad! Things are really tight! I just did my nails!"

It is your career and your life. Manage it. If you wait for other people to tell you what you can do, you may well be waiting a long time. If you don't like the terms or what you'll be doing after the reorg, update the resume and get it on the street. Sooner rather than later. It weill be better for everyone.

Line managers and leads. This is for you.

Find out what your people like to do. What makes them tick. I know that you generally try. The thing is, asking them flat out may be the least efficient way of finding out! These are people who are testers, right? They analyze and think about things, right? That means nothing is ever what it seems to them - RIGHT? So don't be surprised if the answer they give to the question about what they like doing or what they want to be doing in X years/months/whatever, is what they think YOU want to hear and not what they really would answer if talking about this over a beverage with teammates.

Work with your people to learn what they are like. I know, it can be really hard when you work hundreds (or more) of miles away from people who are supposed to be "direct reports". Still, make the effort to learn them - not just about them, but learn what they are like, how they respond and how they handle different forms of pressure.

I saw a really good example of this a couple of weeks ago. Ironically enough it was at a "team building"exercise. Some two dozen people were having an outing. They all worked in the same office and "knew" each other enough to generally associate a face with the corresponding name - at least first name. After lunch they had some games.

They were divided into two teams, very diplomatically. They reached into a bag and pulled out a necklace of plastic beads. Whatever color beads they pulled out, that was what team they were on.

The games they were to play were essentially children's games - some skill, some memory, some, a little of both. OK, there were some basic rules - some games took 2 people from each team, some took 1. No single person could play more than 2 games. Everyone had to play at least 1 game. After the teams were identified, they had 15 minutes to sort out who would do what games.

One team got together and debated on a name - what are they going to call themselves. That took several minutes. Then one person said "I'm really good at X and Y, but not so good at Z. So, I'll do X, I'll be the "partner" for Y, but (pointing at someone else) you do Z." He then assigned other people to other games. People just kind of blinked and did not really argue.

The other team took a different approach. The first question was "Who is good at what games?" Several people were good at multiple games, some were not sure, some said "Its been so long since I've done any of these, I just don't know." So, they tried the games. Yeah, they looked to see who was really the best players for each of the challenges.

After finding people for the hardest "skill" games, they were sorting out who would do the memory games and who would be the second players on the mutliple player games. The interesting thing was, those who had a game selected/assigned stayed by that game to make it easier for everyone else to see what games still needed people assigned to them.

About this time, the FIRST team realized what they were doing and declated it "cheating". Alas, it was time for the first challenge. Team 1 had a hard time remembering who was to do that game/challenge. They took a few minutes to get that sorted. Then they decided that writing down who would do what was a good idea. so, they began writing things down.

After being trounced in the first game/challenge, Team 1 had, concerns over who was to do the second challenge. It seems they had people assigned to three challenges and some people were not assigned to any. One brave soul stepped up for the second challenge (a 1 player game) and was likewise trounced by the Team 2 player.

This pattern continued. In one memory game, Team 1 took advantage of a mistake by the Team 2 player and won that game. In Jenga, Team 1 got very lucky when the Team 2 player bumped the table slightly when moving a pieve, sending the tower of blocks down. These were the only 2 "wins:" Team 1 had.

The other games all went to Team 2 - convincingly.

How does this apply to real work? I see an awful lot of knee-jerk reactions to situations - kind of like the Team 1 approach in general. Don't do that if at all possible, Really.

Find out what your people are good at, and find out what they like doing. If at all possible, accomodate those skills and preferences. If there are people who are willing to learn new skills, encourage them - let them practice the "game" the have an interest in. Encourage others to practice "games" as well. If there are skills that people don't have, and are needed to do what your group is assigned - ask the people who would be willing to learn the new skill - the new "game". Give them the option first.

Encourage your people and encourage them to help and support each other,

The next time the "sides" get chosen for the next game, they may not end up in the same Team 1 or Team 2 that they were on this time. Give them skills to move forward and make their new team better.

Put the fun back in what we do.

Thoughts from TesTrek 2011 - Part 2

2011-11-18T21:02:00.000-05:00

Thursday morning at TesTrek, in Toronto started with a keynote presentation by Michael Mah from QSM Associates on Offshoring, Agile Methods and the idea of a "Flat World." I could not stay as I was presenting in the first track session immediately following. My presentation on Integration Testing went over reasonably well, I thought. There were a fair number of people who were willing to participate and generally engage and some interesting discussion afterward.

To unwind, I went to Fiona Charles session on Test Strategy, She has given this as a full day workshop. Cramming it into a 90 minute session was challenging, but I thought gave a reasonable idea around the challenges of looking beyond templates and boilerplate.

I had a nice lunch conversation, again with Fiona and a handful of other people sitting around a table.

The balance of the day was a rush of impressions for me. I know the afternoon sessions occurred. Still, I found myself in interesting conversations with a people - many of whom I have named already. The thing is, without establishing relationships in the past, these conversations may not have happened.

Much of what I learn at conferences occurs in the "hallway track" - talking with people and discussing concepts of interest to us, whether they are on the program for the conference or not. There are a lot of people smarter than I am, with more experience than I have. The fun part for me is learning and sharing what I learn and have experienced.

The beauty of smaller conferences is that they give the intimacy that allows participants to meet a large number of people if they are willing to step outside of themselves. I can not encourage people enough to take advantage of that opportunity.

One thing that struck me was that I saw only a few people talking with other people they did not work with or know in advance. I'm always curious about that. The thing I consider to have been fortunate in is that I learned to swallow hard, overcome my shy, introspective tendencies and talk with people. Walk up, say "Hi, I'm Pete. Are you enjoying the conference? What have you been learning?" Sometimes it leads to interesting conversations.

Other times it is a little, less interesting. Folks say "Oh yeah, I have a session to go to. Maybe we can talk later." OK, no worries.

The thing is, I learned some time ago, and have blogged about it, that you need to allow time to talk with other people. It is a remarkable conference that has really significant, information-packed sessions in every time slot. Now, this is not a dig at TesTrek, don't get me wrong. I just find it interesting that there was not as much socializing/networking/confering as I saw. (There may have been more, in places I did not find, but I did not find or hear about them.)

I tweeted a few times inviting people to talk about anything to do with testing. Now, I had some fantastic conversations with Fiona, Adam Goucher, Tommas, Stephen and more. But what I found interesting was that of the tweets I sent out, the invitations (including the link to the blog post inviting people to confer at TesTrek) , resulted in one person saying "Are you Pete? I'm Heather! I saw your tweet!" That person was Heather Gardiner, with tulkita Technologies. We had a nice conversation, then we both had to deal with other things.

The thing is, and I think this holds for more testers, don't be afraid to meet and talk with other testers. Even folks like conference speakers, yeah, the "experts", like learning new things. You may not agree with them, and they may not agree with you. But, people who are thoughtful testers with a desire to learn and to share, are good sources for you to learn as well.

This, I think, is the great opportunity for people going to conferences: meeting people with a different viewpoint and learning. Smaller conferences, like TesTrek, give you the opportunity to meet people like you and have the chance to talk with every attendee.
Meet people. Talk with them. You never know what you might learn.

Thoughts from TesTrek 2011 - Part 1

2011-11-17T19:06:00.000-05:00

Last week I was in Toronto for the TesTrek Symposium hosted by Quality Assurance Institute. There were, what seemed to me, some 200 to 250 testers hanging out and talking about testing. In downtown Toronto. Cool.

So, I had the opportunity to spend time with people I had met briefly before the last two years I've been there. Yeah, it seems hard to believe this was my third TesTrek. Go figure.

The advantage of returning to the same conference, particularly if it is hosted in the same city, is you get to catch up and get to know other people you met there better than you can in a single meeting. In my case, I got to have a really nice series of conversations with both Tommas Marchese and Stephen Reiff - both of whom I met previously, but had the chance to spend time with each other, chat and learn.

Other people I see fairly frequently, mostly at other conferences, were Nancy Kelln, Adam Goucher, Fiona Charles. These folks are smart, capable testers. You hear a lot of marketing hype about "thought leaders" or "technical experts" or other buzzwords. You know what's really interesting? The people who are the real deal don't take those titles on themselves.

Monday and Tuesday at TesTrek consisted of a Manager's Workshop. This is an interesting model in that the participants break into groups and discuss topics of interest to, well, test managers. The times I've been involved in these workshops have been mentally invigorating, if not exhausting. This year, the day-job kind of got in the way so I could not attend and participate.

I drove to Toronto on Tuesday, checked into the hotel in Toronto, then went looking for the fun. I found the folks from the conference, like Darrin Crittenden and Nancy Kastl. I had the chance to sit down and have the first of many chats with Fiona and Tommas, and Nancy when she arrived from Calgary.

Wednesday opened with a "Pre-Keynote" by Tommas Marchese. His topic was "Heads Up Testers: Striving for Testing Excellence." In short, it was a call to action for testers to break out of the mold that some companies expect testers to stay in. He had several solid points and I thought it was an excellent start to the day.

The keynote following this, after all, this was a "pre-keynote" was a panel presentation with representatives from Microsoft, Micro Focus, HP and IBM-Rational. I did not find this an OK idea, and thought it would be better to have greater opportunity for audience participation, questions and the like.

The rest of the day was broken into workshop and presentation sessions. Tuesday these consisted of presentations around Test Measurement, Cloud Computing, Test Leadership, Security Testing and others. Nancy Kelln gave a workshop on Test Estimation that had originally been intended to be given along with her Partner-in-Crime/Conferences, Lynn McKee. She challenged people's expectations, just as I thought she might.

Tommas Marchese boldly gave a session on regression testing that he was not scheduled to give. Filling in and giving a presentation not your own can be a problem. He did a respectable job, I thought, and made some good points.

After the opening reception, with some more conversations, a handfull of us went to the Elephant & Castle around the corner for a quiet pint and conversation. I retired early to rest for the next day and prepare for my presentation.

Conference Attendence 201 - Learning While Confering, Continued

2011-10-30T12:38:00.001-04:00

I've written on this idea before. Here in fact. Many other people have written passionately about it as well. As I am fresh from presenting at STPCon Fall 2011 in Dallas and am getting my notes and reviewing my presentation for TesTrek 2011 (http://www.qaitestrek.org/2011/) in a couple weeks in Toronto, I wanted to take a moment and beat this drum one more time.

When you are at a conference, CONFER with people. Talk with them, ask question. Answer questions. Express opinions. Be open to learning. If you disagree with someone, let them know politely - and why. Maybe you are closer than you might realize and simply are stating the same thing different ways.

One really important point.

When the "official" sessions wind down and the "official" "networking opportunities" wrap up - look around for people just hanging from the conference. Then ask if you can join them. Ask what they do, where they do it, what they like about it. You may well learn really valuable ideas you can take back to the boss.

If you see a group of people from the conference sitting in the hotel bar/lounge/whatever, a quick scan will give you some idea of the conversation(s) going on. If it is vaguely related to software and/or testing, ASK IF YOU CAN JOIN THEM!

I know from my own experience, that if I have ANY energy left and no absolutely pressing duties elsewhere, I like to talk with other test professionals and learn. Yeah. I learn a lot just from talking with people. This last conference, I had some fantastic conversations with Doug Hoffman, Fiona Charles, Tony Bruce, Scott Barber, Dawn Haynes, Lanette Creamer, Catherine Powell, Robert Walsh, Dani Almog... the list goes on - Those are the folks that popped into my mind immediately. Testing Heavyweights all - and I gained insight, if not actionable information, from each conversation.

So, I invite any TesTrek Symposium attendee. If you see me sitting in a chair in the hallway sipping the web, or in the conference center lounge, please feel free to join me. Really. I like meeting people and sharing ideas, experiences and viewpoints.

I'm there to learn, too. Please help me learn.

STPCon Fall 2011 - Part IV

2011-10-29T21:44:00.002-04:00

Thursday was perhaps the most relaxing day I had the week in Dallas. I enjoyed a relaxed breakfast with a large number of testers and speakers at the conference - it is easy to relax when all of our speaking commitments have been fulfilled.

Some were still not quite done however. There were a series of talks called the "Rapid Fire Challenge" with a key idea packed into a five minute presentation. Dawn Haynes gave an interesting presentation around Tester Personalities. Lanette Creamer gave a fun presentation on "Tester Tricks" (where she listed Adam Goucher as her "favorite tool.") Mark Tomlinson talked about Risks and Costs of false positives in automation testing. Scott Barber gave a cool breakdown on ideas that were useful for determining what to test and what not to test. He called it FIBLOTS. Cool.

Then, Fiona Charles delivered a stunning keynote on the question of managing Testing or the Testing Process. Ummm - wow. I was tweeting comments from that as fast as I could. It was good. It was really good.

From there, I went to Doug Hoffman's presentation on computer assisted exploratory testing. Overall, I enjoyed it and got some ideas I need to consider. The huge drawback was that there was simply too much information to squeeze into 1 hour and 15 minutes. It would take at least a full day to get a good survey of the ideas - and a couple of days would be better.

From there, I ran into James Pulley - a fellow SQAForums Moderator. We had never met in person and this was a great opportunity.

From there, I spent some time trying to get my notes in order, get things sorted out and "filed" so I could make use of it later. The rest of the time there (which was not much by now) I spent it chatting with people, having a light lunch with Fiona Charles, Matt Heusser and Yvette Francino. After that, Matt, Fiona and I headed to the airport for our respective flights out.

All in all, this was a remarkable week.

STPCon Fall 2011 - Part III

2011-10-27T21:22:00.000-04:00

Wednesday at STPCon Fall was an interesting day. In the morning I had signed up to participate in the "Speed Geeking Breakfast Bytes" - 8 minute mini-presentations on a topic we wanted to be sure that people could head home with at the end of the conference. All the presenters were in a biiiiiiig room giving their presentations to a table of people all at the same time. We gave our presentations three times before the morning keynote for the day.

The topic I presented was was "Integration Testing Lessons from Pulp Fiction." Yeah. kind of a movie-theme for me this year - Harry Potter on Tuesday and Pulp Fiction on Wednesday. Fun! The first run through for me was a bit rough - actually, I did not finish before time was called. There were a couple of interruptions and, frankly, I probably needed another cup of coffee before launching into the first run. Sorry folks. The second and third run throughs went pretty well and everyone had fun. One participant in the third session was giving quotes from the movie at appropriate times!

The rest of the day was dedicated to simply going to sessions and hanging out with people I wanted to talk with. What a fantastic way to spend a conference - Not preparing for a presentation or answering questions about the presentation, but simply going to presentations and sitting in the back row. Cool.

I went to Dani Almog's presentation on Automated Test Oracles. There have been presentations before on a similar topic - what made his interesting was how he developed the oracles: "neural networks" developed from the data identified as correct or incorrect. Cool stuff. It requires a huge amount of rigor and control, not to mention structure, but it looked interesting to me how he went about building it.

The next session I went to was by Karen Johnson on Discipline in Teeting. Ironically, I got there late. Karen spoke to a really full room on how to keep motivated and moving forward. There were a lot of good suggestions - and she explained how she made use of each, from time-boxing to a form of "Pomodoro Technique" to setting small rewards, eg., "Finish this then go to and get a nice cup of .

One important aspect she suggested was to simply change location - literally. Go for a walk. Do something ELSE. Go somewhere else. Like, a coffee shop, a conference room and close the door. Forward the phone to voice mail. Find a park bench (or comparable) and try to clear your head so you can think better. What I thought was cool about this was how many people attending the session shared their ideas on what they try and do. It was really a fun session.

This brought us to lunch and the Lunch Keynote by Matt Heusser. Matt's topic was "How to Reduce the Cost of Testing on Monday." Meaning, things you can start with when you get back to the office to be able to focus on testing - not time reporting, not attending meetings, not preparing project status reports and status reports on the status reports and status reports on the status reports on the... yeah, you get the idea.

He talked about taking steps to open up communication - to help people be able to work more effectively and spend more time and energy focused on testing - so they are really testing, not sort-of-testing. It was really interesting.

After this, I headed up to listen to Lanette Creamer present on pairing programmers and non-programmers. Now, she did not mean the "Paired Programming" some of the XP (and other) folks mean. Instead, she meant more of spending some time working together to get things sorted out - either in planning, designing or executing tests - or talking about the application - or... yeah. A cool idea I like to call "Communication". I know its kind of a weird concept, but it seems to have some potential.

Following this, I caught up with Catherine Powell, a crazy-smart tester, Matt Heusser (who had come down to Earth after the success of his keynote) and a handfull of other folks for a quiet chat and a little relaxation. Wonderfull people.

We then headed off to the "Open Jam Sessions" - a bit of fun before dinner. Folks split up into groups to play a variety of games and fun exercises and generally have a good light series of exercises. Lots of fun.

More conversations with a variety of people over dinner then a little writing wrapped up my last full day in Dallas for STPCon - BUT - there was still Thursday to look forward to.

STPCon Fall 2011 - Part II

2011-10-27T00:05:00.001-04:00

Tuesday at STPCon in Dallas was an astounding day. Matt Heusser and I were slated to present a session entitled "On Complete Testing" immediately following Rex Black's morning keynote address. As I wanted to prepare the room for our presentation and make sure all our potential examples were queued up, I admit that I ducked out early.

Our Tuesday morning session started with a simple question to the participants "When the boss comes in and says 'We need this completely tested?' or 'We need this to be bug free' what is really meant?" at is complete testing?" We got an answer we expected - "That we have complete coverage in our testing." OK. Coverage of what? "Requirements."

We began discussing that idea, which drew out things like validation metrics, boundaries and equivalences defined within the requirements, and what can be done about undocumented requirements, assumptions and presumptions, expectations that were not communicated, and other problems.

We moved on state diagrams - mapping each potential state within the application and how that can be exercised. I pulled out a way cool example of a system I had worked on a few years ago. The basic functions worked really well. However, by sheer accident a memory leak in the application was found. At no I had tested a few years ago. This was an error found simply by letting the application idle over the weekend. This proved to be an example of a problem of strange problems that can occur outside of our control or way of expecting any issues.

We moved on to the idea of code coverage as a means toward complete coverage. This lead us to the differences between statement coverage and branch coverage. This was an interesting discussion on just what the differences could be and how we could potentially miss paths even if every branch is tested. We may miss combinations of branches. We agreed that the idea of "100 Percent" coverage of lines or branches still would not give us complete testing.

We did agree that none of these techniques would give us true complete testing in isolation. If we made use of all of these techniques, we would have a greater likelihood of coming close to "complete" testing.

We continued down through input combination coverage, the idea of of order and filtering of memory, state and interrupt problems. All in all, we had a rolling discussion and the hour and 15 minutes flew past for both Matt and I.

We had an absolute blast!

(Note - everyone who was in the session, we promised to send a transcript of the discussion to all who requested it. SO, those who dropped off their business cards or gave us their email address on the "signup list" - I'm still working on that and I'll get it out as quickly as I can. OK?)

The session wrapped up. We headed out and got a cool beverage, then had some really interesting hallway conversations, and headed to lunch.

The afternoon found me in a series of chats and conversations with people and just loving every minute of it. Around 3:30, I reached into my briefcase, pulled out and put on a tie I brought specifically for my upcoming presentation on test leadership.

My afternoon presentation was on Test Leadership Lessons from Harry Potter. Yes, I know, a geeky-nerdy topic, but that is kinda me.

I walked in, got a very nice introduction from Fiona Charles who introduced me as "a colleague and friend" - which left me gobsmacked (not a good thing to have happen just before speaking.) Suffice to say that the idea of technical leadership and the example of Harry Potter as a reluctant leader, one who is not appointed and does not seek to be a leader, but finds himself in that role, has similarities in the ideas of Technical Leadership expressed so well by Gerald Weinberg.

It was a fun session for me, and it seemed to me that the participants also had fun. I encouraged them to write - for themselves, in blogs, newsletters and, well, anywhere. Learn and share what you learn. Experiment and share your results. Be bold and dare greatly - (kinda like what testers are expected to do when testing, right?)

The session wrapped up and we retired to the "Welcome Reception" on the conference center's patio. This was a great evening with nice appetizers, great conversation, meeting people and generally having a great time. I was even interviewed by Yvette Francino for Search Software Quality! How Cool!

My day wrapped up with a nice relaxing evening back with another crowd of testers sharing stories and having a good day.

I can not imagine a better way I could have celebrated my 50th birthday.

:-)

STPCon 2011 Fall - Part 1

2011-10-26T22:52:00.000-04:00

It has been an interesting couple of days for me. I flew from GRR (yes, of ParkCalc fame) to Dallas with Matt Heusser. We talked about our joint presentations, our individual presentations and what we hoped to learn and hear while at STPCon.

We landed safely, after talking for FOUR HOURS! Yeah, in the plane to Detroit, waiting at Detroit for the lay-over, then on the flight to Dallas. I think the people around us were exceptionally glad that the flights were over. We had a fantastic conversation, the woman next to us said "Wow. I've never heard two guys get so excited about something so boring." I figure she was in marketing... or maybe upper management.

OK, so before I go on, let me just say that the turkey burger was delicious. I found an undocumented requirement. "Delicious AND well-done ground turkey." Bad night Sunday after a highly enjoyable conversation with Matt, Fiona Charles, Rich Hand, Abbie Caracostas and a bunch of other people.

Monday morning I had very little energy, my own fault in retrospect, but we still gave a fairly solid presentation. By afternoon I was closer to "up to speed" and could contribute much more. We learned a lot from doing the workshop in front of living, breathing, thinking people and have already begun making changes for the future.

What we presented, and the exercises we conducted, involved a series of testing ideas, problems and scenarios. We began with Matt talking about the idea of "quick attacks" testing. That is, doing some basic hits against an application even if you don't have much information about it. We then applied a series of exercises around that idea.

Then, we introduced the idea of working against states specifications and expectations and how insights to that will change approaches to testing against the same applications, and others. We then began discussing core ideas around bounds and equivalences in data and how that may impact our testing approach. After lunch, we moved on to discussing a variety of topics.

Matt and I knew that there would be far more information to talk about than we possibly could get into a single day workshop. We created a list of potential topics that could be of interest. We presented that list to the class, allowed them to add their ideas and vote for the topics of interest to them. Each participant was allowed three votes, we sorted based on the number of votes and began working our way down the list.

This was a hugely fun exercise for us and resulted in some interesting discussion among all the participants in the session, as well as Matt and I. What made an impression on some of the students is that we did not always agree. In fact, there were cases where we made a point of showing where we differed, and how our experience and environments, the context in which we worked, impacted some of those views.

As time wound down and we came to the end of the session, we had several topics we had not addressed. Matt pointed out to them that in testing, as in the exercise, we may not have time to test everything on "the list" to be tested. We will then have to work on the items that are of the most interest - Just as we selected topics that showed the most interest to discuss and work through with the students.

Monday night we settled down for a light supper of appetizers and various beverages with a host of intelligent people. The ideas and excellent conversation flowed, although I decided to call it a day and retire fairly early to prepare for Tuesday's sessions and get some rest.

No Black Swans Or Always Expect the Unexpected

2011-10-14T22:19:00.002-04:00

So, I expect many, if not most reading this, have heard of Taleb's Black Swan theory. He put this forward around those things that people write off as being so far in the extreme, or so improbable, that "no one" could predict them. Many folks far more learned than I have discussed this many times over. Not just around software events, but in disasters, both natural and, well, not so natural.

Fact is, I have seen so many things in software testing that other folks would write off as "improbable" or "unrealistic" or simply snort in derision over. There was the developer who once tried to say "No user would ever run this purge process with nothing to purge." Really? Never? They'd always know better because, well, they'd know never to do that? How would they know?

I can also think of the times I walked into the same trap, unwittingly. I learned. I learned to be aware that I can not anticipate everything. Now, sometimes that seems odd. Then again, when I think about it, I ran into the same kind of problems other folks had, like those for whom a test result, or worse, an actual event, in production or in the wider world. That problem was, and sometimes still is, perception.

My way of thinking, approaching problems or questions, is sometimes self-limiting. The fact is, I suspect it is the same for most people. What I believe, or maybe hope, is that my awareness of this can help me work around it and be open to multiple possibilities.

Hmmm - that sounds kinda wishy-washy.

What I mean is that I try and be open to the possibility that I missed something. Usually when I do miss something, its because of my own perceptions, my way of approaching a question or scenario. Broadly, my frames.

These models of thought can be usefull. If we are not aware of potential limitations, we will find ourselves in the "No user would ever do X" camp.

Now then. Something REALLY unexpected?

My lady-wife keeps a large garden. We also capture rain water in a couple of large barrels to water that garden. Sometimes, when there is a lot of rain, we will line up some buckets and catch extra water from the run-off of the car-port roof.

An interesting thing happened last week. The lady-wife was trimming some plants. One of the branches had some nice looking flowers on. She decided to put it in a rain-filled bucket until she could bring the flowers in the house. She looked in the first bucket in line and saw a small fish.

A FISH!

Just a small little guppy looking thing. No. We did not put it there. We have no idea how it got there, although we've bounced around some fun theories. Have we come up with a model for how it got there? Sure. Several. We don't know which, if any, is correct.

So a fish in the rain bucket is something I definitely did not expect.

Maybe I should have.

Of Bugs and Weeds or Why Tugging Gently May Reveal More Than Pulling Hard

2011-10-10T07:41:00.000-04:00

We have a fair sized garden for where we live. To be fair, my wife has the garden. I'm the laborer who makes some of the bigger chores happen.

One chore that we get to do twice a year (mid to late spring and early to mid fall) is pull Virginia Creeper vines out of the lilacs, mock oranges, off the fence, and generally out of everywhere we can pull it out from. Now, its a pretty enough plant. However, like most vines it tends to not "stay put" and grows pretty aggressively.

It can, and will, choke out other plants - it has done in a couple of ours and several of the neighbor's much loved mock orange trees. It looks a bit like poison ivy and actually works pretty well as a deterrent for keeping some of the unscheduled visits to the garden and yard from youngsters (and oldsters) in the area to a minimum - they don't realize that vine is NOT poison ivy.

In the fall, the leaves turn a stricking red - astoundingly bright color.

Did I mention that it grows REALLY fast?

While I pulled a huge amount from the one area I worked in, I know there is more there. I focused on the big mature stuff that would be sending out more runners in the spring. Any smaller vines I came across I also pulled but I did not go looking for them. (Kind of like looking for defects that really impact a system vs those that should be fixed but don't really impact anyone.)

Like many people dealing with this plant, I started out, many years ago, pulling hard and aggressively. I was going to show it who was the boss. I was going to WIN! Ummm, not so much. You see, vines tend to break off at resistance points. So if a couple of tendrils have looped themselves around a wire in a fence or a branch of another bush, the "stem" will break if you pull hard - the tendrils will hold the rest in place.

What I learned, and greatly amused my lady wife as she watched me do this, is I can identify a large vine, gently lift it and apply even pressure on it. That will break the tendrils off so I'll have a much large section with little or no resistance to pulling. I'll then look up to the top of the bushes (the lilacs along the North side are quite tall - over 10 feet) and watch what moves when I tug on the vine. That way, if the vine DOES break, I'll know generally where it broke off.

I've also found that if I start a gentle, consistent pressure, I'll get much more of the vine off per attempt than if I give it a good yank. Like all heuristics, that one is fallible. Sometimes it works, sometimes it doesn't. Much of the time through it works.

So as I was pulling vines this last week, I got to thinking about software defects. If I dive in aggressively looking for HUGE problems, I tend to find some. If I use a more gentle, subtle approach, I may find some of the same ones I found with the aggressive techniques. I also find others that I perhaps may not have found.

I'll experiment some more tonight when I get home. I need to transplant some of the smaller lilac bushes. It should be much easier since so much of the virginia creeper was pulled out of that portion of the garden.

An Exercise in Task Prioritization Or Where Has Pete Been?

2011-10-09T18:36:00.000-04:00

I find it astounding that the last blog entry I posted was written on August 24. That seems a long time for me to go between postings. That is not to say I have not thought about writing some thoughts down. In fact, I have a fairly lengthy list of post-it notes stuck on my bulletin board with "This would be a good topic for a blog entry." As of today, its quite a lengthy list.

The simple fact is, I fell into a common trap for software people - I'd see a side project and think "I can do that in my spare time, it can't take too long." Or, I'd say "Here's an opportunity for me to do X. Those don't come along too often. I can do that."

Pretty soon, I had more "side projects" than time to do them in.

On top of that, there was a "side project" at the day-job that needed to be addressed. Not a big deal, just a minor little thing of 40 to 60 hours and a couple months to do it. Of course, it was not on the project schedule because it was pretty small and could be done in the middle of other things. Until it was scheduled to be shipped to a customer. THEN the priority ramped up BIG time. (No one has ever seen that before, right?)

So, in the meantime...

I wrapped up slide decks for two presentations at two conferences;
Wrote up supporting articles on both;
Wrote an article taking a contrarian view toward the answer to a question asked;
Wrote up four short essays answering other questions;
Wrote up notes from CAST2011 and filed them neatly for later use;
Took the lady-wife on an extended weekend at a music festival that had no electiricity (and allowed no generators) in the camping area - and had a fantastic time;
Did the usual (and expected) "end of summer" family stuff;
Got caught up on the day-job's projects (well, relatively);
Slept in yesterday.

Oh, and the usual home maintenance stuff for a home built in 1888. (A friend of ours said "The only thing that works in an old house is the people." He's right. We stole the line and use it ourselves now.) Oh, and I fixed the annoying drip in the plumbing in the downstairs shower. (But that was today.)

The result is I missed a peer conference I had intended to participate in. I also did NOT submit any proposals in the last 6 weeks to speak at conferences coming up next year (yeah, there werre a bunch of deadlines that I waved to as they whished by.)

The good news, and things I'm quite pleased about, include a resumption of workshops on drumming (pipe band drumming to be particular.) I agreed to teach a bagpipe band's fledgling drum corps this year. I had done a series of workshops, fairly intense 4 and 5 hour sessions, starting with "holding the drumstick" and ending with "playing as an ensemble." They liked it so much that they asked me to repeat the lessons for their novices/newly joined drummers and pick up with more advanced material for last year's students. Cool.

The day job has had several "wins" from a business view, a software view, a testing view and personally. Things are far from perfect, but there looks to be an interesting time ahead.

So, expect an flurry of blog posts as I try and work myt way through the list.

What did I learn? Hmmm - Jury is still out on that one. Off the cuff, I'd say I should have learned to not take on more than I can handle. What I may have learned instead is that sometimes the stuff we agree to do had better be fun, because we may not have a chance to do other stuff that is fun.

Out of the Mouths of Babes or Testing Lessons from a Three Year Old

2011-08-24T19:22:00.000-04:00

While recently in Seattle (spot the CAST reference!) my lady-wife and I had a little time for sight-seeing and visiting and what not. A friend of the daughter and her husband live in the area with their two children, aged 9 months and 3 years. So, on touching base to say "hello" we get invited over for an evening - and jump at the chance.

We brought over a pecan pie fresh from a Cajun place down at Pioneer Sqaure, downtown (amazing food by the way - and the pie was straight from the oven) and a couple of bottles of wine and age appropriate presents for the two children. While visiting with the daughter's friend and playing with the kids (waiting for her husband to come home) I found myself engaged in an informative mentoring session with the 3 year old - Aidan.

Brilliant kid. You can tell his parents are terribly bright and spend a ton of time with him.

Now, most people with children, or have ever had dealings with children, will know that there is a key word in every 2 and 3 year old's vocabulary: "Why?"

Well, not Aidan. He looked right at us and asked "What happens?" Well, sometimes he said "What happened?" but he did so in the right context.

For example, a ballon popped "What happened?" "Well, I think it bumped against a stick or a pricker in the grass and that popped the balloon." (We were playing in the yard with a balloon.) "What happens?" "Well, sometimes if a balloon touches something sharp that can pop the balloon." "Oh."

So then it was time for him to play with his hard-hat and be a builder. "Can you build me a big building?" "Yup." (he leaves then comes back) "Is it done?" "Yup" "Great. Can you build me a barn now?" (he goes away and comes back.) "Is it done?" "Yup." "Great! Can you get some hay and straw and get a cow and a horse and some chickens for the barn?" "What happens?" "Well, then the animals can live in the nice bard you built." "Oh. What happens?"

About that time, Dad got home and Aidan went to go play with HIM until dinner was ready.

The rest of the evening and on the drive back to the hotel, that stuck with me. Not "Why" but the next best question a tester can ask: "What happens?"

CAST 2011 Emerging Topics and Wrap Up of Thoughts

2011-08-14T19:38:00.003-04:00

I started out looking at my previous several posts and realized how many times in each of them I used the work "amazing." I promise I will do my best to not let my still spinning head succumb to such a word in this post. The thing is, I find it really hard to NOT use that word when I've been inundated with intellectually stimulating ideas.

Emerging Topics

After opening up to opportunity for anyone attending CAST to submit an idea to speak on, we then allowed anyone who was interested to comment, rank or otherwise ask questions around the proposals. Matt Heusser and I reviewed these comments, rankings, questions (and their answers) to pull together a program from the ideas submitted. Many of the proposals were from people who had not spoken at a conference before. Personally, I found that exciting. Why?

We were opening up venues for people to speak to one of the more challenging conference audiences I have ever encountered. People who think, and who may not agree with some of your points, are not only encouraged to speak up and ask questions (or challenge the speakers) but are expected to do so.

When Ben Yaroch let us know that there was a strong likelihood that we'd be able to stream the ET sessions live, that got me even more excited (yeah, right, as if I could get more excited.) Adam the Volunteer (I never did get his last name) was a big help getting things going Monday afternoon. That left me free to make sure the presenters were ready and we had their slide decks (presuming they had some) available. Thanks Adam! I do appreciate it.

When Monday rolled around and we kicked off right after lunch, then the fun began. The ensuing afternoon was much what I expected - a variety of speakers on a broad range of topics, all packed into 15 minute slots with 5 minutes saved for questions. Some of the speakers were a little un-polished. We did not care - It was the crisp thoughts they had (not crisp Powerpoint skills) we were interested in.

Personally, I liked how many speakers used no slide decks at all, instead they focused on the flip chart in the room, using markers to interact with the people in the room. Coolness - no Death by Powerpoint here! :)

What was the best? Hoo boy. How do I choose?

Michael Larsen gave an interesting presentation on EDGE (a cool Boy Scout acronym) and how that can be applied to testing. Anna Royzman gave an experience report on how she got a mixed community of people to work together and apply exploratory approaches to improve UX and overall testing. Lanette Creamer gave a very very brave demonstration of testing on the fly around using tools everyone "knows" in new ways. Neil Thompson and Felipe Knorr Kuhn both gave interesting talks (hard playing facilitator when the topics draw you in, not my most shining moment.) Robert Berqvist gave an interesting comparison on the groove of music and the groove in testing - yeah, drummers love that kind of stuff. Ben Yaroch spoke to a packed room on leadership ideas drawn from the military, and how they can be applied to testing. Finally, the most challenging presentation for the day was Geordie Keitt's presentation on "Complexity Quandary, or Why Certified Testers Continue to be in Demand." This seemed almost tailor-made to draw on ideas in Michael Bolton's keynote, and to serve as a bridge between James Bach and Doug Hoffman's debate on the idea of Schools of testing being divisive. We gave him a double long session (45 minutes) and the discussion went over that. I was too busy moderating to tweet - great stuff though.

Tuesday, Eric Jacobsen kicked things off by talking about combatting Tester Fatigue (as I was still recovering from the flight and the excitement that comes from CAST, I thought it appropriate for me!) Bill Matthews gave a good session on Myth Busting for Testers. Frankly, I hated cutting both of them off when I did as I thought it was good stuff, and I only wish he had time for more. Just before lunch, I gave a short version of "Messy Integration Testing" and how things that seem to be unrelated probably were not and needed to be considered in testing. That was well received, I thought.

After Lunch, Todd Mazierski gave a short overview of Sinatra. This was followed by Geordie Keitt's All-Star Tester Revue (OK, I made that name up) Geordie stood up and played guitar and sang songs around a testing theme (it helps when you write them!) Then brought in a panel of Michael Bolton, Lanette Creamer, Dee Ann Pizzica who did some interesting improv comedy around a testing theme. Capped off by Lanette singing a song, with Geordie backing her on guitar - and Geordie closing the session with another original composition. What a great time. Matt Heusser wrapped the ET track with a lesson in communicating with "Agilistas" drawn from his experience.

We then turned the room over to Lightning talks - and I had the chance to go catch up with people.

One of the people I kept running into during the conference was Adam Yuret. No, not Adam the Volunteer mentioned before. He and I have met cyberly for some time, banter on Twitter and various on-line forums. All in all he's a good guy with ideas to consider.

Keynotes 'N Stuff

I was looking forward to hearing Cem Kaner's keynote this year. I missed him speaking last year as I was "otherwise engaged." Unfortunately, he had to cancel and was not able to attend CAST, so the workshop he was scheduled to teach got shuffled, and Michael Bolton slid into the keynote spot where Cem was scheduled to speak. Michael's keynote was astounding (avoiding the word "amazing" can ya tell?) He covered things I have been trying to express for some time. The minor issue encounterd, and gamely dealt with, was the projector simply did not work. The result was Michael gave a very academic-like reading of his document which was absolutely chock-full of ideas around the history of scientific thought and how it related to testing and the idea of context driven testing.

James Bach gave a keynote that, in my mind, was a solid argument on the benefits of avoiding processes that so many people advocate, and were challenged time and time again. All in all, it was a call-to-arms to reject the set-piece examples and practices that are part of so many people's views of "best practices."

I was sitting with two different groups on Monday and Tuesday. An amazing thing about CAST, so many people are welcoming and willing to engage in conversation no matter the topic or if you were a "famous" person. Based on comments around the table, both were well received.

A couple of things stand out at this point in my rambling narration. First, the hall was absolutely packed. When the requisite question "How many are at CAST for the first time?" it seemed to me that half the people in the hall raised their hands. It was an astounding sight. The first time attendees I met all very readily engaged in the spirit of the conference and actively participated. This bodes well for the future.

EdSIG - Education Special Interest Group

Tuesday night I participated in the discussions of the Education Special Interest Group. Topics on the table included getting more instructors for the BBST courses up and active, the upcoming next installment in the series, Test Design, ideas around why there are so many fewer students taking Bug Advocacy than are taking Foundations, branching out (reaching out?) to people who want to help but are not certain where to go to help. So, there are a stack of issues, including creating a "what to expect in this course" video for Foundations - hopefully so that the amount of work is not overwhelming to the student.

There is more, but much (for example Michael Bolton's workshop on test framing) is worthy of its own blog post.

I do want to thank the folks who organized the conference - I know James and Jon Bach were up to their eyebrows - but also Doug Hoffman, Ben Yaroch, Dawn Haynes (who is an all around trooper) - all the people who made all the big ideas (live web streaming for example) move from "idea" to "its happening now."

CAST 2011, General Observations

2011-08-11T02:29:00.000-04:00

I'm writing this the evening of Wednesday, August 10. This is the evening after the Workshop day of CAST 2011 in Seattle. Overall, this has been an amazing experience. The whole experience was highly rewarding in many ways.

James and John Bach took an unconventional approach to putting together the program. Speakers were chosen on reputatuon, not on submission topic. Yeah, it was different. At the same time, I had the opportunity to work closely with Matt Heusser on putting together the Emerging Topics track. This was a cool idea, an experiment, and overall, it came off well.

Another experiment was the live webcasting of the keynotes, the ET sessions, lightning talks and "tester interviews." The discussions were astoinding - no experiment there - certainty was closer to it. I personally appreciate the great conversations Neil Thompson, Bill Matthews, Fiona Charles, Paul Holland, Dawn Haynes (who is a terrific person and hard worker who does not get nearly enough credit for making things just work)

Oh - I met more people from Sweeden at a testing conference this year than I can imagine!

OK, other people I met whom I have not mentioned - yeah, there were a stack, but these stood out ... Lets see - Christin Wiedemann was in my class today, then - sitting behind me, and next to Michael Hunter was Cathy McBride. Oh! Another Alex Bantz was also there.

I had the pleasure of helping with the EdSIG meeting and looking for ways to get the people who were interested in helping in the SIG, and getting involved in BBST, actually involved and active, The thing is, this is also the same central idea behind keeping any non-profit, volunteer organization - finding tasks that need to be done, matching them up with people with the skills and interest in doing them, and matching them up.

My experience in Michael Bolton's Test Framing workshop really deserves its own post. For now, suffice to say it was interesting.

I had intended to decompress, have a quite dinner then get some work done. Instead, after finishing an adult beverage, as my "take out" dinner was about to come out, Selene Deliesie, Lynn McKee and Nancy Kelln walked into the restaraunt. What could I do? We sat down, enjoyed a meal together and had a fantastic conversation.

Now, it is very late, I'm remarkably tired and have more thoughts running through my head from the last three days and looking forward to more general thought absorption, internalization and a little sight-seeing tomorrow before heading home.

Thank you Seattle and AST for an amazing experience.

CAST 2011, Day 2, A Brief Summary

2011-08-11T01:53:00.000-04:00

Again, I had intended to write this last night. It is amazing top be how mentally and physically drained I am byt the end of each day at conferences. So many smart people it seems impossible to keep up.

Right, so, people. Had some really nice hallway conversations with Elana Houser, who was in the BBST Foundations course with me. We did not always agree with each other in the course, she is, however, a very good thinker. Lynn McKee, Nancy Kelln, Selena Delesie and had nice chats and gave great insights on discussion topics. I also brifely met Karen Johnson - OK folks, she is smart and wise - doesn't always come in the same package.

Amazing talk(s) with Michael Hunter - Yeah, the Braidy Tester guy. He really is as good and inspriational as his blog posts seem. Oh, now then, let's see, Had some Fantastic chats with Ajay.Balamurugadas. Ben Yaroch is crazy smart and a hard worker - really. Michael Larsen really DOES have as much energy as his podcasts make it seem like he does. Let's see. Also had some good visits with Justin Hunter, Paul Holland, Bill Matthews and Johan Jonasson - Phil McNealy is a good person to know as well.

One of the highlights for me was seeing the Emerging Topics track come together and be a reality. Some of the speakers had a bit of a rough go. Many had never presented outside their own company before - WHAT a daunting task! Yeah - Present a 20 minute idea in front of some of the best testers around. YEAH! Still, everyone made it through the experience, good information and ideas were shared - even if folks were a little nervous.

I had a chance to drop in the tail end of the Open Season of the BBST Experience track. Cool Q&A session, lots of energy. The Lightning Talks, which I dropped in on after the BBST talk ended, were interesting - ideas and "quick hits" with ideas. Fun.

I ended up having an interesting conversation with Felipe Knorr Kuhn, Gary Masnica, Phil McNealy and Lanette Creamer. Job Titles, Job Roles, What to Do, How things work... highly enjoyable, mentally invigorating. This set me up for a good session in the EdSIG - Education Special Interest Group.

Michael Larsen, me, some dozen other people talking via Skype with Rebecca Fiedler and Cem Kaner (who could not be at CAST.) Good ideas, much meaty discussion - look for another blog post on that before too long.

It was an amazing day.

Oh, I did not get elected to the Board of Directors for AST. Now, some folks tried to console me, I was unconsoleable. Well, technically, literally, there was nothing to console me about! I believe that each of the five candidates were eminently qualified to serve on the board and three were selected. This is good.

So, this morning, I find myself sitting at a table (starting this blog post actually) and Michael Hunter sat down to chat and have a little breakfast. Griffon Jones dropped his pack and went for a little breakfast, but got tied up. As it was, Michael and I had a great visit before we headed off to Michael Bolton's workshop on Test Framing. That, too, is another blog post.

CAST 2011, Day 1 A Brief Summary

2011-08-09T11:28:00.001-04:00

I had intended to write this last night. Alas, I was far too exhausted and flopped into the hotel room with the telly and the lady-wife, and promptly fell asleep.

So, Yesterday was an astounding day. I met a scad of people in person I had previously only met cyberly. That, if for no other, is an astounding reason to attend a conference.

The Who's Who I met... Ajay Balamurugadas - Yes, the fellow who came up with Weekend Testing, the point-man/advocate for self-education and training in India. Lanette Creamer - Testy Redhead, bright and enmthusiastic ball of energy. Johan Jonasson - from Sweeden, an enthusiastic and crazy smart advocate of context driven testing. Elan Houser who I met in a BBST course - really great thinker. Simon Schrijver - SimonSaysNoMore on Twitter - an astoundingly intelligent thinker. Neil Thompson Anna Royzman, Todd Mazierski, Robert Berqvist, Geordie Keitt, Ben Yaroch, Felipe Knorr Kuhn all were speakers in the Emerging Topics track I was helping moderate and helped coordinate.

I had an amazing dinner with Neil Thompson, Fiona Charles, Anne-Marie Charret, my lady-wife and ... EGADS! I've forgotten the name of the other lady/diner/participant! I'm Sorry! It was a fantastic conversation with little to do about testing, but EVERYTHING to do about testing.

Michael Bolton gave a Keynote yesterday that was thought provoking and interesting in developing thought ideas. Part of his theme was picked up in Geordie's ET session at the end of the day yesterday. It will be revisited later today with a track session with James Bach and Doug Hoffmann discussing the idea that the Schools of Software Testing is a divisive idea, or not.

There were other crazy smart people, HOWEVERR - I'm going to bail and write more later. BECAUSE! Sitting next to me right NOW is Markus Gaertner, Michael Larson, Matt Heusser and Ajay Balamurugadas and discussing the Tester Challenge they participated in last night. An astounding display of self-evolving thought.

More Cool Stuff from AST

2011-08-01T09:58:00.000-04:00

In July I blogged about being nominated for a position on the Board of Directors for the Association for Software Testing. You can find more on AST at the website. Its a cool group made up of interesting people.

So last week we got together and talked via Skype. It was half-jokingly referred to as a "debate" but it was less debate and more people talking about what they are interested in. (Come to think of it, there was a good deal of information shared and straight-forward answers given than in the pretend-political debates in the US the last several election cycles.)

In the course of the "ramp-up" some of us sent messages via twitter on what would be happening. That was picked up by a couple of other folks who asked if there would be a Q&A session via twitter. So, why not? We ran it by some other folks and picked a day and time...

So the DAY is TODAY! The First of August - 9:00 to 10:00 PM Eastern Time (yeah, I know, very US centric but its when those of us on twitter are available...) If you are interested in the AST and the elections, and want to participate in the town hall meeting on twitter, just follow the hashtag #ASTElect.

More information on the "almost debate" and the Twitter Town-Hall-Meeting will be available here.

Cross-Pollination or How Talking With Smart People Helps You Learn

2011-07-18T23:17:00.000-04:00

I was looking at some of my blog posts over the last 6 or 8 months or so. That made me wonder so I went back looking at some of my older blog posts. That made me wonder some more, so I went out looking for blogs from other people I respect. These people are involved in other groups or go to conferences or, well, just hang out with other testers and tester types.

I discovered something about myself, and I believe others, that led to this blog post.

Here's what I learned: The more you expose yourself to good thinkers and intelligent conversation and engage with them, the more you learn and the more you can learn.

I can't prove this with any firm science. What I can do is look at how things have changed since I went out looking for different sources. I can also see how other people, significant, famous testers, interact and learn from each other.

I've been fortunate in having the opportunity to go to various conferences the last few years. This has given me the chance to meet people whose writings I have read and enjoyed and I have learned from. I also have had the opportunity to meet people whose writings I have read and I disagreed with. Now, some folks might shake their head and say "They're wrong." For me, this was an opportunity to understand something I did not understand before. Possibly, I could learn from that understanding and find something to appreciate and find common ground for future meetings.

What has astounded me, is just how much I have learned and grown from all these meetings. Ideas I have had for some time and have been trying to formulate have found the form and structure I needed to organize them. The result has been, among other things, this blog, articles, an inteview, conference presentations.

Do you need to travel all over North America or the world to find the same level of thought provoking conversation? Hardly.

I bet there are people in your company or your community you can talk with and have the same experience. I bet there are others in your city or town who are interested in discussing similar things. Great ideas can come from many sources - not just the famous conference speakers and articles. They can come from the person in the cube next to you or from someone doing similar work at a different company in your town.

Want to see if I'm right? Try an experiment.

Talk with people at your company about meeting after hours to talk about software and testing. Then, have those people drop an email to people they know at other companies. Invite testers, designers, programmers/developers - anyone who works on software. Then talk.

You don't need a big group, a few people is a good start. Don't worry about being formal - just try talking with other people with an interest. Don't worry about being right - instead focus on sharing ideas.

Thats all.

Try sharing ideas and see what you can learn. Maybe other people will learn something from you.

A Moment's Thought: AST and Walking Among the Mighty

2011-07-07T19:49:00.001-04:00

The morning of June 24, I opened my email and found a message that said, in part:

...you have been nominated for AST's 2011-2012 Board of Directors Election. The Nominations and Elections Committee needs to confirm you are willing to run for the Board Of Directors. Can you confirm or disconfirm your interest in running?

Gobsmacked does not begin to describe my reaction. Astounded?  Thunderstuck? Not even close.

I asked a few questions. Actually, I asked a lot of questions. They involved expected time commitment, level of involvement and things of that nature. Mostly I was looking to weigh those expectations against the needs of my family and my day-job, you know, testing.

My problem, as my lady-wife well knows, is this: When I agree to something, I dive in head first and will put in massive amounts of time and energy to fulfill that commitment. In the past, it has sometimes been to the detriment of other things. I have learned to limit myself carefully. It can be a struggle to set aside things that are emotionally and mentally rewarding to deal with things that are more mundane, yet pressing, like painting the house or fixing that drip in the kitchen faucet. Let's face it, some things are just more fun than others. Sure, they all leave you with a sense of satisfaction, like, the house looks really nice or the annoying drip is not wasting water and costing money. Still, they don't have the mental stimulation that sharing time with people equally passionate about things as you are does.

I had come across the Association for Software Testing some time ago. How long ago, I don't rightly recall. It was while reading "Lessons Learned in Software Testing" that I read of the "Context Driven School of Testing." What I read made sense. It rang more true to me than the more procedural or dogmatic oriented approaches to testing. There was a reference to a Yahoo email group in the back of the book, and I signed up, and was accepted.

I remember reading in there of the Association for Software Testing and organizing a conference. Me, I stayed on the sidelines and dealt with other things, watching and observing the discussions with interest.

Fast forward several years.

In the fall of 2009, I found myself at a conference in Toronto, going in place of my boss, who could not attend at the last moment. I landed there. While I was sitting at breakfast, realizing that the nice friendly lady at the table chatting with the handful of us was Fiona Charles, whose writings I had read for some time, a voice rang out.

"Pete Walen! The last time we talked you had just been fired for doing your job!" With that, Michael Bolton sat down next to Fiona and tore into his breakfast along with the rest of us. (Talk about instant street-cred with a table full of people you have never met...) Mind you, we had "talked" by email and discussion forum posts and never in person.

Later at the same conference I met Lynn McKee and Nancy Kelln. Both left me absolutely amazed at their energy and excitement. In the midst of a lively discussion around measurement, metrics, goals and the like, huge issues for the company I was working for at the time, Michael and Fiona both said "You should join AST, you'd be very happy with that group." (Actually, that was a paraphrase of what was said, but you get the idea.)

Later that month, after returning home, I bought myself a birthday present of an AST membership. Shortly after returning home I met (in person) Matt Heusser. Rarely have I met someone with as much drive, energy and focus as Matt. He confirmed that joining AST was absolutely the right thing for me. Since that first meeting, Matt and I have worked to get the local tester group meeting, and helping its members, on a regular basis.

My first experience at CAST came the next summer. Another eye-opening experience. I met Fiona again, was introduced to Griffin Jones and a whole host of other people. I blogged very excitedly about it at the time. (See? Here and here.)

This spring I took the BBST Foundations course. The coursework was only part of the experience. Meeting people of differing backgrounds from around the world, even cyberly, was fantastic. I remain in contact with several of the class particpants through Skype and Twitter. Gotta love technology.

James and Jon Bach, Karen Johnson and others I met in person and was able to spend time in conversation with helped me better my undersanding of my chosen craft. Each of them are inspirational in their own way.

I was asked once, quite recently, what I liked about AST and why I kept my membership current, and did I think it was "worth it." Is it "worth it?" Absolutely. Why?

That took a bit more thought.

I realized that at the core of it, was the community that was the center of the Association. I found a group of people who may not agree with you (or even each other) on a topic and were willing to discuss ir like, well, adult professionals  Many of the members I have met demonstrate traits that I associate with people who are true masters of their craft. They will discuss an idea with you in order to learn, and posibly inform their own understanding of the concept. Of course, there is also the chance of teaching you and sharing their understanding with you.

Another thing I find attracting me to AST is the focus on Context. It is not merely being Context Aware. It is keeping Context at the center. It was the idea of Context Driven Testing that I found appealing originally when reading Lessons Learned. It is still sppealing to me. This recognition that context can and must color and drive testing and discussions arouind testing has pushed me to be a better tester, a better colleague and professional, and a better craftsman.

There have been many people who have encouraged me and pushed me forward in my development as a tester.  Those I named stand out for the mark they made and their willingness to talk with me easily, without let or reservation.

That is the third and most important point to me. Many AST members, from the very famous "someones" to the other faces in the crowd, are willing to put in time and effort to better the community of testers as a whole.

I am deeply honored to have been nominated for the Board of AST. I realized that if I had the opportunity to pass on the gifts I had received, I would. Someone like me who is not a jet-setting "famous tester" or author of testing books or a famous consultant, yet is one of the many who want to better themselves and those around them in their trade and craft, has a choice. We can allow the great ones of our craft to engage in this work alone. Or, we can say "Should I be elected by the members, I would serve."

I see it as an opportunity to "do my bit" for the greater good. Therefor, as I responded to the email, I am interested in running for the Board of Directors.

I was told I would need to prepare a short statement about my interest in AST. I'm suspect this is not "short" enough.

CAST 2011 Emerging Topics Track and Deadline

2011-06-24T13:44:00.001-04:00

No odd philosophical ramblings in this post. No questioning definitions or other people's dearly held beliefs. Still, I'm getting pretty excited.

The Conference for the Association of Software Testing (CAST) is coming up REALLY fast - August 8 through 10 in Seattle (to be precise) Part of the fun this year is to hold an "Emerging Topics" track - 20 minute sessions that anyone already attending the conference can submit a proposal to give.

Yeah, anyone who is registered and who wants to give a short talk on something they do not see covered in the balance of the program can do so.

Here's the catch: In order to make a schedule and give everyone attending the opportunity to review the abstracts for the Emerging Topics session they might be interested in, we will need to cut off entries and voting for them, on July 1, 2011.

So, if you are attending CAST and want to submit a proposal, or review and vote on proposals in the Emerging Topics track, please drop an email to me or Matt Heusser. We'll get you setup with access to see (and create) them.

UPDATE!!!!!!!!!!
July 20, 2011 -
The Submission and Voting period is now closed, selections and a schedule have been made. This has been an interesting, thought provoking and fun project to work on. I am looking forward to meeting everyone in person after communicating by email and telephone.

Thanks to all who participated - Pete

Managing and Controlling or One of These Things is Not Like the Other

2011-06-23T21:42:00.000-04:00

There are some interesting threads on various internet discussion forums. Some are interesting as in "this is a thought provoking conversation with a lot of good ideas." Some are more along the lines of "this is a very odd series of disjointed thoughts where people can not even agree on what they disagree on."

One was interesting in the "What is this guy talking about?" sort of way.

His assertion was that Exploratory Testing was fine for small groups of one or two testers. However, it was unsuitable for larger or regulated environments because testing could not be controlled. He also suggested that Exploratory Testing was not as thorough as fully scripted testing because you did not need to think about it before you did it.

Take a deep breath, Pete. Can we start with this, "What is the difference between Controlling and Managing?" His response was "None. They are the same thing."

Oh dear, oh my, oh dear.

Let's see. Being too lazy to look get out one of my physical dictionaries, I turned to Google and searched for "control definition", "manage definition", "controlling definition" and "managing definition".  I very scientifically grabbed the top search results (that were not paid advertisements) and found this...

Control: –verb
1. to exercise restraint or direction over; dominate; command.
2. to hold in check; curb.
      OR...
Control: -noun
1. the act or power of controlling; regulation; domination or command.
2. the situation of being under the regulation, domination, or command of another.

Then there is this...

Manage: -verb (used with object)
1. to bring about or succeed in accomplishing, sometimes despite difficulty or hardship.
2. to take charge or care of.
      OR...
Manage: -verb (used without object)
1. to conduct business, commercial affairs, etc.; be in charge.
2. to continue to function, progress, or succeed, usually despite hardship or difficulty; get along:

Now then, we have looked at the roots, now let us look at the -ing words in question.

Controlling: -adjective
1. inclined to control others' behavior; domineering
       And...
Managing: -adjective
1. having executive or supervisory control or authority

As I sit here, I think a bit on the interesting idea that Manage and Control are the same thing. Based on these definitions, I find it interesting that there can be a serious assertion made that they mean the same thing. Having said that, I know certain boss types who firmly believe this. Me, I'm far to liberal (at least in the traditional, apolitical sense of the word) to agree with this.

Liberal: -adjective
1. open to new behavior or opinions
2. favorable to or respectful of individual rights and freedoms

Now, if you want to exercise restraint or direction over your people (whom I suspect you refer to as "resources") or to dominate your staff or to hold them in check, have a great time. Your staff probably won't.

Oh, I won't be part of that game, either.

Now, if you want to be in charge and guide and supervise your staff, no worries from me. I'd be happy to discuss exactly what that means to you and I'd also be interested in knowing how your people perceive your style of management.

Now, to be sure, there is some overlap in some of the words. If the intent of "Control" follows the defntitions I found, I am simply not interested. If the intent of "Manage" follows the definitions I found, I may be interested and would be willing to talk about it. Having said that, if your use of "manage" really means "control" - I'm not going to play along.

Managing and Controlling are far from the same concept. If you want to be a Manager, consider just what the differences are.

Back in My Day: Confessions of a Curmudgeon

2011-06-22T19:56:00.001-04:00

When I first got into software for a living, the idea of "structured" anything was the red-hot burning idea that was going to save software from the horrible/bad/evil practices of people who were inept/wrong-thinking/clue-less practitioners of hocus-pocus. Structure was going to save us. Then it was CAD. Then it was Object Orientation. Then it was blah, blah. You get the idea.

I heard some folks talking about some "New Ideas" that they had heard about. Fantastic ideas, I thought. Instead of centralizing everything on a host server, they could have servers in a bunch of different places and have them all talk to the host. Then response times would be faster and the users would be able to get faster response. Astounding, eh?

Anyone else remember that new idea from, oh, 20 years ago?

Wait, that is sounding really, negative.

Let me try again.

Back when I was heavily involved in bagpipe bands, there was an amused expression that was reserved for folks who had been involved in pipe bands some years before, and no longer were/

"The older I get, the better I was."

The fact is, people's perceptions will change over time as our experiences inform those same perceptions. In the pipe band world, it seemed to inflate what the abilities were.

In reality, I have learned, now that I am part of the same "club," is that some folks really REALLY don't like change. Change in any form is bad. At the same time, things change as they grow, or they wither and die. You can't maintain existence without change. Well, maybe you can, but it is not really existence, it is a museum display - almost a "living history" lesson.

Change is inevitable.

Once it was suggested that since I was so "set in my ways" I may not like the changes that were coming and I could have a hard time adapting to them.

I resisted the temptation to look around for my cane and wave it about calling that individual a "young whippersnapper." For one thing, I don't use a cane or a walking stick. For another, I sympathized with his perception and lack of life (and maybe professional?) experience that would lead him to say that.

The thought that crossed my mind was "It is this very experience I have that allows me to see how he could have a view like that. I have been around a while and I like things a certain way. I have liked things in different ways before that, too.

When comments like the above are made, or when I think on change and flexibility, my mind sometimes wanders back to the companies I have worked for, the shops I have worked in. No two were the same, even remotely. Some were happier than others. Some were more efficient than others. Some turned out really good work.  Some were just jobs.

Some are examples of the same things I mentioned before. My own experiences shaped my perception of each of those organizations. As I learned more, I wanted to learn more.  My views changed related to that job as I was working there. I learned and experienced different things in different areas.

What does all this have to do with anything, let alone each other?

Well, simply put, I read a blog entry by The Maestro a couple of weeks ago.   My first reaction was "YES! EXACTLY" Then it made me think on some things.

What I discerned from that thinking is that each of these "revolutionary ideas" was intended to address a problem. Or at least, a perceived problem. The thing is that many are just that - perceived problems. I think the real cause is that people, myself included, don't want to do the painful self-examination that is required for real improvement.

It is easier to follow the herd and the glossy marketing people when they hold out a promise than it is to dig down and work on the problem we have.  This leaves us the desperate grasping at the just-out-of-reach silver bullet.

This is, I suspect, the core issue with all the trends over the last 30 years in my experience, and more.

Unless you are willing to face and address your real problems, you will never fix them and will keep grasping at quick-fix solutions that are not.

Well, maybe I'm just being a curmudgeon.

What Can Be So Hard About That? Or, Why Do Some Folk Think Other Folks' Jobs Are Easy?

2011-06-14T19:36:00.000-04:00

A funny thing happened the other day. I overheard some "sophisticated" city-dwelling folks talking about farming. To be more accurate, it was a group of folks from one of the "more affluent" suburbs of the city I live in. The kids were a little uncomfortable with their surrounding, a small-town eatery that had opened a really nice "deck" by a river. This was in a really rural area catering to farmers and their families. The deck was clearly a "let your hair down" establishment for young folks, farmers kids and younger farm hands to enjoy a cool beverage. It was also a short drive off the expressway, which is how they, and we, landed there.

So, the lady-wife and I were observing the to-and-fro of the regulars and these self-same sophisticated folks. One of the women made a comment that made me blink. "People talk about farming as if it is so hard. I don't know what they are talking about. You've seen my garden, that is some work, but really, how much more work can that be than my garden?"

The lady-wife's eyes looked like saucers (she's a Master Gardener and regularly says she's glad to not be a farmer). For me, I was not surprised. I was reminded of comments I've heard other people make like "Its just testing! How hard can that be!"

To be fair, I've also heard testers say things like "Why don't the developers get it right so we don't find stupid mistakes like this?"

You see, it strikes me that some folks simply don't get it. Whatever "it" is, they just don't get.

Here's what I mean. You've all heard that "a little knowledge is dangerous," right? If you have a small amount of experience with a tiny portion of what someone else does for a living, there is a tendency to extrapolate that experience to being what those who do this for a living do.

Many of us testers have run into the developer or project manager or some other manager type who sputters about how much time testers take and how can it possibly take "that long" to test - That it doesn't add anything and just slows the project down and you can get it done faster if you just...

What comes after that varies, but you get the idea, right?

Kind of troubling for those of us whose profession and craft is "just testing." No?

Then why do we say the same thing about developers? (See? I'm being polite.) A lot of times I'll say something like "software program code writers" since there are far more folks in "software development" than those who write the code. Yes, I know. I'm not nice sometimes. Yeah, sometimes I yank chains. At the same time, there are many, many more people in software development than the people called "developers."

I know, I'm kind of off in the weeds.

But not really.

When one group sets themselves or their craft above the skills of others as more sophisticated, challenging, difficult, advanced, whatever, it becomes easy to take the next step and raise yourself a notch or two over those who work with you, but are in the "lesser-skilled" trades and crafts.

I've done Project Management and Business Analysis. I've done programming (which at the time I started working in software included design and requirements gathering and communicating with business users.) I'm doing testing now. I've dabbled in DB stuff - enough to know I'd not be a good DBA - no passion or patience for it.

I do not understand how people can look down on others in a difference craft. All of them take specific skills, training, focus and discipline. To do them well, each of them are demanding and challenging and at the same time, they very rewarding.

There are a lot of instances where you see this mindset - something is easy to master because you can get the basics in 10 or 15 minutes. Learning to apply them is the hard part. Learning to master them takes longer. Just exactly how hard is it to do anything?

Want to find out? Try it. If you are a tester without development experience, try learning a programming language then try writing a simple program. Then test it. How many bugs did you find? If you have some development experience, try your hand at project management - at least get a bit of training then try to apply that training at work. Let's see what happens.

If you dabble a little bit, or took a course in college X years ago, you're an expert, right? Maybe the little exercise above will help you understand a tad more. How hard can anything really be?

After all, it is just testing, right? How hard is that?

Where No One has Gone Before: Exploratory Testing Lessons From Jean Luc Picard

2011-05-23T22:53:00.000-04:00

Great. You started out with a plan, maybe you had scripts to follow, maybe you had a nice neat plan - and before you know it you're off in the weeds.

Or worse, before you know it you've stumbled into some area that is completely uncharted and unknown. Its as if you were navigating a sailing ship 500 years ago and realized you were smack in the middle of the area that said "Here be Dragons" or some OTHER undesirable slogan.

None of us ever intend to get that far "out there" - well, I don't normally anyway. Most of the folks I've worked with don't normally get that far "out there" either. Usually. Unless we feel like - well - seeing what's out there.

When that happens you have a couple of choices. You can punt and start over, writing this off as a weird anomaly. Sometimes when this happens folks shrug and say something like "I don't know how this happened. It must have been something I did wrong." Frankly, I've said that once in a while as well. Sometimes when I do that, in the course of re-tracing what I did I find where I should have zigged and I actually zagged. I sometimes will make a note of it to return and intentionally follow that path after finishing off what I intended to do.

The odd thing is that sometimes I find myself out in the weeds again, just as unexpectedly as I was the first time. So, the choice we all face is to see if we have an idea what caused the event this time OR we can see where we can get from where we are right now.

I sometimes think of this as "X-Treme Exploratory Testing." Instead of blasting our way through whatever we just ran into, we sometimes need to carefully unravel the threads that we have around us.

Do you remember the Star Trek TNG episode where the Enterprise picked up their own distress call saw a massive explosion and a debris field that was their own ship? It was kind of like Groundhog Day - they found themselves in a "time-space continuum anomaly" where they repeated the same incident without knowing it.

As luck would have it, several of the recurring characters had a sense of deja-vu - around the time they picked up the distress call as I remember it. Then Data began saying things that were, un-Data-like. So, they decided to try and send messages to themselves each time the repeated the process to let them know what they had tried - and they'd know if it worked or not by them not blowing up. Cool, no?

What if you don't have an Android - humanoid artificial life form, not the phone - to tell you what did not work? What if you find yourself trying to repeat the same process and finding yourself back in the weeds everytime?

For me, the simplest tool is a legal pad with a pen - and I make note of what is done. See? Who needs Lieutenant Commander Data when I have Ensign Note Pad? ;) Now, since I began doing this all kind of other cool tools have become available - Rapid Reporter is one. Try it - I've read rave reviews but have not had the opportunity to put it through its paces myself - I look forward to it in the near future, however.

My point, such as it is, Don't be afraid of the unknown. We're TESTERS - that is what we do! We find the unknown and make it known! We head off into the weeds and chart a course out and back again.

If you stick to the path laid down in the script, you will have a fairly safe round of exercises. It won't be testing - but it will be safely predictable and you will be able to show nice charts and pictures showing what is done and what is left to be done, and you may even find some bugs.

It is when you head out to see what you can see that you really learn the product, the application or how it works.

It is your job to boldly go where no one has gone before.

Agile or You Keep Using that Word; I Do Not Think It Means What You Think It Means.

2011-05-16T22:34:00.000-04:00

Its funny. Many of the more recent blog posts have come from ideas or thoughts or reactions to comments and discussion at the local tester group meetings. I think there's a blog post in there, but this one is triggered around an idea I've have for some time. Of course, it came together clearly during a lightning talk at the most recent meeting.

Yes, yet again the local testing group had gathered to discuss testing and eat pizza. I don't know if it is the collection of bright people sitting around munching on pizza just talking - no slides, no formal agenda - just folks talking about testing - or if it is the collection of minds engaged in thought on the same topic that I find so interesting.

The Trigger

One of the presentations discussed "The Fundamental Flaw in Agile" - and was based on the presenter's experience around Agile environments in software development shops. Her premise, which I can find no fault with, was that most shops "doing Agile" make the same mistake that most shops did with "Waterfall" and experience very similar results. That is, the belief that there is a single inerrant oracle for "user information" for software development projects.

Mind you, she is no slouch and is extremely talented. In fact, one statement she made was the key to allow my mind to pull things together, and that in turn, lead to this blog post. You see, sometimes (like at conferences or presentations) I use twitter to take notes. Other times, I outline ideas then add ideas around that outline and that turns into a blog post. Then sometimes that blog post turns into the foundation for a presentation or longer paper.

You see, I've worked with some really bright people in agile environments. I've also worked with some really bright people in Agile environments. I've also had the pleasure of working with some really bright people in Waterfall environments.

Some of the people in the first group (agile) are also in the third group (Waterfall.)

Nah, Pete - you're kidding, right? Everyone knows that Waterfall is not agile.

Really?

I'd argue that the way most people functioned and called it "Waterfall" was anything other than "agile." It certainly had little to do with the Agile Manifesto. Now, I have some theories around that but they will wait for another time.

I might suggest that the ideas expressed in the Agile Manifesto were the extreme antithesis of how many folks "did Waterfall." I certainly would suggest that the idea of using "Agile" to fix software development practices of some shops is equivalent to the silver bullet solution that gave us project managers and business analysts and other folks getting involved in software development with limited experience in the field themselves.

Now, an aside. I do believe that some very talented people can help move a project nicely. They can be Project Managers. They can be Business Analysts. They can be Programmers and Testers and DBAs and on and on. The interesting thing, to me, is that when I got into software development, the common title for those people doing the bulk of that work was "Programmer." Anyone else remember when programmers were expected to sit down with business users or there representatives and discuss in a knowledgeable way how the software could help them do their work better? Now, avoiding images of people getting excited and yelling "I'm a people person!" why is it that we figure people who are good at technology stuff should be un-good with people stuff? I don't know either. But for now, let's leave that and consider it in another blog post. OK?

Right. Where was I? Oh, yes. Silver bullets.

Many shops where I've seen people "doing Agile" seem curious to me. In fact, I get curious about them in general. I ask questions and get answers like "No. We're Agile so we don't need documentation." A close second is "We're Agile so we don't need to do Regression testing." Third most common is something like "We're Agile so we don't track defects..." (now up to this point, no worries; the worries normally come after) "... because we don't do documentation."

Thus the thought that pops into my mind,,,

"I do not think it means what you think it means."

Now, I'm not the sharpest knife in the drawer. I make a lot of mistakes and I have said some really un-smart things in my time. Having said that, those folks I sometimes hear selling "Agile" to people - and neither the person selling nor the potential customer/client have a decent idea, or at least a more clearly formed idea of what "Agile" means, than I do. I mean, come ON!

Listen to what you are saying! "Oh, you have communication problems! That is because you use Waterfall! Agile fixes that! You have customers not getting what they need! That is because you use Waterfall! Agile fixes that too!" And on and on and on...

sorry. got excited there a moment.

Here's what I'm getting at. There are some really smart people who firmly believe that Agile methodologies are fantastic. I think there is a lot to recommend them. Really, I do. I can agree with everything listed in the Agile Manifesto - Really!

I disagree with the way some people interpret Agile. Why? Because they are missing the point. In my mind, the entire purpose - including dropping the stuff that is not needed, that does not move the project forward, etc., boils down to one thing: Simplify Communication.

By that I mean exactly that - help people communicate better by breaking down the barriers that get pur in the way by process or by culture or by evil piskies.

It seems to me, that is the greatest flaw in "Agile."

Without good communication, Agile projects will fail. Full stop. If you do not have good communication, nothing else matters.

When you replace one set of burdensome processes with another and wrap it in the banner of "Agile" have you really made it better? Really? Is the process the key? Really?

Do me a favor and grab a dictionary and look up the word "agile." Go ahead, I'll wait.

OK, you're back? I bet you found something like this...

Adjective: Characterized by quickness, lightness, and ease of movement; nimble.

Wait. Did you look up "Agile Development" or "agile"? Yeah, consider what the word means - not the methodology but the word.

Now. Someone please explain to me how folks demand that something be done because "that's what you do when you're Agile" is really agile? If they are following form over function - doing something by rote - without explaining to the rest of the team why this is important (I understand that each Scrum master or whatever the "leader" is called needs some leeway in approach) then will the team see any more value in this than in the "evil" methods of "Waterfall"?

Then again, in my experience, what is the difference between teams that were successful and those that were unsuccessful in Waterfall? Communication.

Incomplete Complete Testing

2011-05-14T21:24:00.000-04:00

In March, the local testing group got together to eat pizza and talk about testing. We tend to get together each month and discuss some aspect around testing and eat pizza. This time, we had a fun meeting where my boss and I gave a "preview" of a presentation we were slated to give at STPCon in Nashville later that month and starting testing groups. We had a decent size turnout and had a lively discussion.

One portion stuck out to everyone. There was an animated discussion around whether the efforts of a testing group could result in "complete" testing. This discussion was the result of a seemingly simple question, "Can you really have complete testing of an application?" It took almost no time for us to realize we had a topic for the April meeting.

The challenge was sent out and all interested were to bring the "proof" each had cited and be sure their arguments were well considered for the April meeting. After indulging in yet more pizza and an introduction/ice-breaking exercise, we settled down to business.

The core question revolved around what is "complete" and what is "testing." Could we agree on the terms? It seems simple enough, no? Have you ever tried to get a dozen or so people with different backgrounds, training and experience, some are testers, some are designers, some programmers, to agree on what something so simple? This actually took longer than I expected. Testing is more than "unit" testing. Testing is more than making sure things work. Yes? Well, maybe.  With a bit of discussion, we succeeded in getting an understanding we could work with.  That testing involves more than what many of us thought individually before the discussion and also involves aspects that others had not considered.

The interesting part of the conversation was around the idea of "proof" that complete testing was not only possible, but could reasonably be done. With some discussion around what constituted "proof," a realization dawned on most people that a conceptual "proof" (think a theorem from math class in high school) left room for an awful lot of wiggle-room.

You see, it may be possible in certain limited circumstances to test every possible combination of everything impacting the system and it may be possible that the full range of potential valid and invalid input data and it may also be possible to exercise all possible paths within the code and it may also be possible to exercise the full range of potential loops and paths for each possible combination of the paths executed within the system.

And then there is the reality of it. Can you really do all of that? Can you really do any of that? Really?

How small is the system you're testing?

The probability of those things and the costs associated with them is the issue. Really.

You may be able to cover somethings.  But all? Really?

You see, an awful lot of systems have fairly complex input data structures. Lots of potential valid input values. And lots more of potential invalid values. If you commit to "complete" testing will you really test all of them? Then there's the example of Doug Hoffman and the calculation of a square root. Simple, eh? Something about floating point and five significant digits and unsigned integers and if you need to be sure the routine is right, how do you do that?

I mean, its four Billion possible values, right? (c'mon - say that like Doctor Evil with the little finger pointed out. Four Bil-le-on ,,,) Can you test it? It depends, right? What kind of machine are you running on? An XT-Clone? A super computer?   Makes a difference, no? Well on one it might be completely impossible. On another, it might take 10 minutes and show that the formula works for every possible input value, except for two.

Then again, there's the question around the environment itself. If you're running on a Windows environment, What is all that stuff running in the background anyway? What happens if some of that stuff is not running - does it make a difference? How do you know? Are you certain?

Without knowing, how can you possibly say that you can test all the environmental configuration combinations? Can you test everything? If not, can you really say you can completely test your system?

So, you see where I'm going. And that is kind of where the conversation went at the meeting.

Can you test your systems completely? Really? Completely?

What Looks Like Is Wrong May Not Be What's Wrong: Testing Lessons From House, M.D.

2011-05-02T22:02:00.001-04:00

So a few weeks ago, I was trying to figure something out. I was getting weird error messages and strange results and generally odd behaviors when trying to run a test. Now, the odd part was, the behaviors shown and the error messages and the data stored in the DB simply did not, well, match.

There was no way those pieces could all go together. What could be going on? What could be causing these really unusual symptoms?

Now, I don't know what anyone else does in these situations. I know that the method I use for tracking down problems like this can best be described as "Housian" - Well, maybe "House-ian."

Yes, I turn to that ever so patient and thoughtful, gentle tempered example for all testers, the title character of "House M.D." Gregory House. The cuddly, lovable, always cheerful soul dispensing folksy wisdom in an gentle, kind way.

OK - If you ever watched the show, you know I'm, well, fibbing a bit. He isn't most of those things, usually.

What he is, is methodical. He may not be the gentlest soul, but there is something about him. You see, when problems simply can't co-exist - I think of it as two objects not being able to share the same space. I sort of learned that once upon a time. The core question is what are you going to do about it? How are you going to find the real problem that is triggering the first in the observable problems?

House uses a team of people to bounce competing ideas against. That can work in some circumstances, like when you have a short time to figure out what is wrong with a critically ill patient on television, and a commercial break is coming up. What I do like is to keep ideas flowing.

Sometimes I find myself looking at a symptom or two and trying to find a relationship. Is one causing the other? Can the "real" problem be something less than obvious? Maybe another set of problems is masking the real issue? Maybe the real issue has nothing at all to do with what I am seeing?

Yeah, I know. It kinda depends on what the symptoms are, right?

So, with this particular set of problems, I found myself thinking, "What would House do?" Other than belittling all the ideas from the Greek Chorus of supporting doctors, a common tactic is to focus on something that I can control - one symptom or set of symptoms and carry on with that. Maybe I'll find something related to what the core problem is.

So, I tired that. Nope. Nothing appeared to make sense. Back to square one.

Then something dawned on me. Maybe the clue to the real cause was being masked in the flood of stuff in the logs. Maybe I was ignoring the one piece of information I needed.

So I took a look at the logs again. (Folks who watch the show will see this as the "Hey, look at this little spot in this easily ignored place on the patient's body" moment.)

Bingo - there it was. The one little error message in the midst of spectacular dumps of... stuff. There was the clue I was ignoring all along.

Thanks, Doctor House. We were able to save the patient. Umm, project.

Happy Anniversary, Pete

2011-05-01T11:45:00.000-04:00

One year ago today I posted my first blog entry in my "new" blog on software testing.

As a result of the blog and tweeting about it, I've had the pleasure of meeting in person and cyberly a vast number of remarkably bright, talented and interesting people.

No one knows what is certain in the future. This last year has not progressed at all as I expected. Well, that may be too strong. There have been some things that went as I hoped, and others that left me absolutely gob-smacked.

For those who have shared this portion of the journey with me, "Thank you." The comments in the blog, by twitter, email and in person are encouraging and very much appreciated.

Now, let us see what the coming year holds for us all.

Stepping Up to Leadership: Lessons From Harry Potter

2011-04-30T10:37:00.001-04:00

I was thinking some time ago about how people can be leaders without having the word "lead" or "leader" in their title. What is it that makes a leader? Do leaders become a leader intentionally? Well, I expect some folks do. Some of those, however, I don't really consider real leaders - maybe managers, maybe bosses, possibly control-freaks.

I'm reminded of a line from Robert Heinlein about the advantage of hereditary monarchs is that on occasion you get a reluctant ruler who simply wants to do a good job. Its the ones who really want the job that you have to look out for.

In the rather interesting meanderings of my mind I was thinking back to discussions I had many years and a few jobs ago. There were, in my opinion then and now, an awful lot of managers and directors and not nearly enough leaders. Real leaders. The kind of people that colleagues turn to, not because of official channels or management chain, but because they know that person, or people, might just be able to help.

In pondering just where these thoughts might go, it dawned on me that there were many, many examples of the kind of leadership that I was thinking of. As I was pondering what it was that I was trying to say and how to say it, a weekend movie marathon featuring a certain young wizard kicked off and I had my answer.

I got to thinking that many "leaders" don't intend to be leaders.

Start by Deciding to Start

Some feel like they don't quite fit in.   They want to, they try to, and yet they simply don't feel satisfied with what is around them. They start looking for something else, something that maybe they can't quite put their finger on. They are still trying to fit in, not knowing why they don't or can't and then the Owl shows up. Well, maybe not an owl with an admission letter to Hogwarts, but something clicks. Something triggers, well, something.

For those of us without an owl, that "something" can be a decision that there is more out there - that taking charge of your own career is what you need to do. Maybe the feeling that you have had enough of other people making decisions for them about your career.

It is more than making you better at you job or making you more valuable to your company. It is making you more valuable to you. It is becoming a tradesman and craftsman instead of a laborer.

The first step when that "something" happens, is to find a mentor, a guide to help you. It may not be Albus Dumbledore, but someone with the experience and patience to guide and teach you is needed.

Study and Self-Education

Then, when you have found a mentor, study the craft of software testing. Online materials, blogs, articles, testing forums, all can help you find information. Books and magazines are great and many are available for download to e-readers.

Begin your learning by self-education. Then, you can turn to your mentor for guidance and clarification. Seek out ideas new to you. Challenge what you have been doing and what you are reading and focus on learning your craft.

Harry studies and is willing to branch out beyond what the various professors are teaching in class. If a 12 year old boy is brave enough to do that, what is stopping you?

Learn by Doing

The next step is to find the guts to actually try stuff new to you. Now, it may be new to the company as well, but that is OK. Now, it might be a really, really good idea to have a more experienced person looking over your shoulder when you try this the first time.

Doing something the first time, whether its the first time for just you or the first time for the company, can take a fair amount of courage. Reaching out and stretching to try and extend your abilities can be a little scary sometimes. Particularly if your expected results are uncertain.

Now, while it is unlikely that a hippogriff might rip your arm off if you are too forward, it may be that your pride may take a hit if your first attempt does not succeed. Not to worry. Trying something new always takes courage.

If results are "less than optimal" then look to what happened. Look to see where you went wrong and correct it the next time. If there is not a next time, it means that those who were making decisions for you will continue to always make decisions for you. That is why you stepped out, right? So try it again!

The fact is, sometimes the results can be absolutely astounding. You and those around you may very well be amazed at what you can achieve simply by trying to achieve it. Now, it may not be riding on the back of a flying animal most folks consider mythological, but it may be astounding in a technological sense for your shop and your company.

Networking: Building Relationships

One thing you must do, find some "friends." Now, many of us have "friends" we can hang with. That isn't what I mean. I mean that you should find people you can talk with about what you are trying to do, what you are trying to learn. Chances are, they will take an interest in it and share what they are trying to learn as well. They can be valuable to help compare notes and share experiences with.

The amazing thing is that they don't have to be in the same company as you, not even in the same city or town as you. Conferences (local, regional, national and international) are great resources for this - but may be rather pricey if the boss does not agree to foot the bill. Local testing groups can be a great option as well. If there is not group around you, START one!

I bet that you know people who work at other companies. I bet you know people at other companies who are testers or know testers or work with testers. Get in touch with them and bounce the idea around about starting a local testing group. (See how easy that is? You just started building relationships!)

Yeah, there may be some folks who know more than others do, or think they do (Hermione...) and that's OK. There is no reason why they won't have valuable insight into what you are talking about.

The thing is, be patient and grow and nurture your contacts list - your network. You may find yourself having others in your circle reaching out to you while you continue to learn.

Helping Others While You Learn

Now, you may think that won't happen. You may think it can't happen ("What do I know anyway? I'm no expert!") That's OK. You don't have to be an expert. You may need to think carefully.

Someone will ask questions of you, based on your experience. When that happens, and it will, see this as another opportunity for you to learn yourself, and teach others what you have already learned.    Now, you may not be learning the same thing. Its possible, but it is not a certainty.

They need help in an area where you have learned something. You may be able to provide it. You may also learn how to help others and in doing so learn another skill.

It is also OK if you express you own reservations to them. You can say "Yeah, I did this but I had people helping me..." The fact is, you did it and now you can help others.

Achieving Things You Never Thought You Could

The more you learn and the more you can apply what you learn, things that once seemed impossible for you will become regular occurrences, if not commonplace. Activities and events and practices that you once would not, or could not, dream of doing will become the norm.

You will then be able to reach out and impact things you never dreamed you could do. When this happens others will congratulate you - and encourage you to greater bounds. Others may turn to you and seek advice on things you have not thought about. Still others may ask you to help them with their problems, even if it is only to talk with them while having a coffee or tea or, something a bit stronger.

Being a Leader

The process of becoming a "leader" is never ending. There are always new areas to explore and new ideas to consider. Sometimes the ideas are revisiting old ideas and challenging some of the presumptions.

The point is, learning never ends. No person can ever learn everything there is to know on a topic. Speaking for myself, and not Harry, the more I learn, the more I realize I do not know and want to learn about.

I don't consider myself a leader, or an expert. Some other people have called me both. If they need a bucket to fit me in for their understanding and defining a relationship with me, that is fine. That part is not about me. The part that is about me is that I can learn and share what I have learned with others.

Mischief Managed.

Pliers, a Blowtorch & Mr Wolf: Integration Testing Lessons from Pulp Fiction

2011-04-26T21:58:00.001-04:00

So, at the most recent local tester meeting, a suggestion was made that the next meeting should consist of folks giving lightning talks based on pop culture references and how they relate to testing. COOL!

One of my colleagues suggested a "Pulp Fiction" idea - not that he wanted to give one, but he thought it would be "cool." So, sitting and having a coffee the next morning, I got to thinking about it. What in the remarkably violent film, featuring various actors in interesting, if not compromising, storylines, could possibly relate to testing. About half-way through the cup of coffee it hit me.

Now, James Bach, and others, when hearing someone explain a heuristic or oracle or rule or concept, will ask "What do you call that?" You see, there is something about identifying something - naming it - that makes it easier to refer to, gives you a point of reference, and other good things.

So, in sitting there drinking coffee, thinking about "Pulp Fiction" - it became remarkably clear. How does this possibly relate to testing? How does this relate to integration testing? Everything fell into place.

I give you, the "Pulp Fiction School of Integration Testing."

Consider that the vignettes in Pulp Fiction are related to eachother. They simply are not told in a linear manner. They are closer to the way life happens - lots of intertwined stories all happening at the same time.

Now, consider the way some folks do integration testing. Maybe "some" folks is not really accurate. Maybe "many" folks would be a better description. But they get some idea that the idea of "integration testing" consists of "end to end" scenarios. The thing is, most "real" people using "real" software in the "real" world don't always use software in a linear fashion.

So why do so many people test their software that way?

I don't know either.

When I think about some of the systems I have worked on, it simply does not make sense to rely on "end-to-end" testing. Really. Its kind of silly. Here's what I mean.

A system rarely does one thing at a time. People in one office or area will do one thing - a lot of times. Say, item maintenance in a warehousing system. Looking up information and checking descriptions and UPC codes and unit of measures and - lots of stuff. Folks in another office may be checking inventory on the same items the other folks are entering or checking or, whatever. Then, in yet another office, folks are handling orders customers are placing for the same items that the other folks were... you get the idea.

So why do so many folks test one thing, then the next then the next then... yeah, you get the idea to that, too.

Why don't we try and do integration testing closer to the way the "integrated" system actually gets used?

Ya know, kinda sloppy like life really is - or maybe like Pulp Fiction?

True Confessions or Feet of Clay

2011-04-20T22:03:00.002-04:00

Its funny how things work sometimes. You go to a conference as a speaker and folks look at you as if you have all the answers. People send you emails with questions and want an answer. Sometimes they want a "Yes" or a "No." Sometimes they are hoping that the "expert" they are asking will be able to shed some light on their archane situation. (Yeah, I've done that.)

I had a strange thing happen the other day. I was asked a question. Now, don't get me wrong, I get asked questions alot. I also ask lot of questions. So, the fact that there was a question involved in this is not the strange thing. The strange thing was the way the question was posed. And it has something to do with the first rambling paragraph. This person asked me a question and wanted an "expert's opinion."

What, me? Ask Michael Bolton or James Bach or Cem Kaner or Karen Johnson or Boris Beizer or Elisabeth Hendrickson or Fiona Charles or... you get the idea.

I guess my deal is that I don't feel like an expert. I feel like a guy who makes mistakes. Ask the folks I work with. Man, did I ever have a blooter this week. Huge mistake. I missed stuff that if I had looked more aggressively, that if I had tried a variation I had not considered, I would have found it. I didn't. Then there was another problem that was a calculated risk. We could not test everything because of a variety of constraints. Then, as folks are trying it in the field, they found a problem in an area we could not exercise. Gah.

The really weird thing is that even when I know I make mistakes, and my co-workers make mistakes, we all do our best to learn from them. We can each push eachother to achieve better and do better testing. How do we do that? By looking honestly at what we do - both right and wrong.

To do that, you must put aside the CYA mode that most of us have learned and admit our shortcomings - first to ourselves, individually, then to our team. Then, and not before then, you can learn from your mistakes.

Am I an exepert? I don't know - I don't feel like one. I'm a tester who sometimes makes mistakes, even though I try and avoid making them.

Fun and Games at STPCon 2011 - Part 3.

2011-04-05T07:45:00.000-04:00

Thursday at STPCon in Nashville was an interesting day for me. It was certainly the shortest as far as conference stuff went, which was probably a good thing. When I woke up, with the body still on "Eastern Time" and not "Central Time" I knew it was going to be a physically rough day. The head cold I was fighting was not letting up and the voice was threatening to simply go away.

So, I sucked down a couple cups of coffee, some juice, some cold-tablets to try and lessen the "ick" feeling and carried on.

First order of business was the "Speed Geeking Breakfast Bytes" - The topic I had submitted was "Stepping Up to Leadership: Lessons Learned from Harry Potter." Yes, I found a way to work Harry Potter into a testing conference. This was a "test" run of a longer presentation I was working on around technical leadership, or becoming a leader without having either "Lead" or "Manager" in your title. I'd had an outline and a set of talking points in place and took the opportunity to squeeze this into an 8 minute presentation (complete with Power Point slide deck!)

The idea of the "breakfast bytes" was to give the same 8 minute talk to three different groups. I made it though it - made reference to the other tables and their presentations and almost had a voice by the end. I think folks like the ideas and saw later there were tweets on some of them - Cool! Thanks Tweeps!

I fortified myself with yet more coffee and a couple more glasses of juice then caught Selena Delesie's presentation "Showing the Value of Testing." I really enjoyed the core of the presentation and the lively discussion during and after. Much tweeting from this session!

As the conference ended at Noon, and I was not leaving until the next morning. I decided that the wisest course of action was a nap. I never take naps. So, the boss and lady-wife (who had come down with us and had managed to see sights around Nashville and go to the social events with us) went shopping for the elusive boots and I stretched out.

A couple hours later, feeling much refreshed, I checked email, dealt with a couple of lingering day-job items then went to see what kind of trouble I could find.

Lo and behold! Here was James Bach with dice with Michael Czeisperger and Gabe Wharton. Being the un-shy person I have become, I joined in. It was interesting watching how James handled the interactions and compared the "results analysis" with other folk I have seen do the same "introductory game." It was enlightening in many ways.

Additionally, as the idea of observing and not participating is one I do not particularly care for, I soon had a set of dice as well. So, James deftly handled this newcomer with an interesting variation. I knew something was up when his notebook came out and was written in quickly. It turns out that my initial behavior gave him an idea for a new set of rules. When that was resolved, we compared my definition of the new game with his written note. Close enough to say they matched - a slight change in phrasing was the only difference with no change in meaning.

On a related note, I brought the same game to the first team meeting after the conference. Volunteers only, mind you. Three folks dove in and gleefully experienced the frustration and learning and critical thinking that it takes to solve these types of puzzles. In the end, they each reached the same conclusions by unique methods. That is a topic for another blog post, however.

Gabe was flying out shortly, however, James and Michael were not leaving until the next day. The boss, the lady-wife and I had plans to have dinner with Michael, as James was also unattached for the evening, we invited him as well.

The five of us had one of the most enjoyable nights I can remember with a bunch of testers. The conversation ran from education to schooling to un-schooling to testing to philosophy to learning to heuristics to beliefs back to testing (briefly) to the qualities of various red wines (we were in a steak house for dinner) to boots and the benefits of the various materials boots can be made from to the difference between hats and caps and jackets and coats and how cultural norms and more's can be touched by those definitions and impact what is considered "proper" behavior.

Needless to say, the evening flew by.

Fun and Games at STPCon 2011 - Part 2.

2011-04-04T19:39:00.002-04:00

At STPCon in Nashville, Wednesday, the second day of the conference itself, I was rather torn.

My day started with the "Power-up Issues" discussions. I found myself at a table with people passionate about testing and building teams and expanding team roles - the great regret I had was that it ended far too quickly. Another 30 or 45 minutes would have been great from my perspective, but, the breakout sessions were starting.

I knew Lynn McKee was speaking on a topic I was interested in that morning - metrics and how not not get trapped into abusing them. Well, actually her presentation title was "Deception Dangers of the Numbers Game." As it was, I had a conflict. Stuff at the day-job needed attending to and I was also dealing with a developing head cold and laryngitis. (Not a good combination for a conference. Oh, and for the Day-job stuff? I'm tentatively working on a paper called "A Funny Thing Happened on the Way to the Conference.")

So, as much as I would have liked to be there, I did appreciate the tweets (the many tweets) about what she said by Nancy Kelln and others who were present.

Another presentation I would have liked to see was Jim Hazen's on Automated Testing. I have known Jim cyberly for some time. As it was, he was speaking at the same time as Lynn - so again, I had to take a pass.

Selena Delesie's "Thriving as an Agile Test Manager" and Michael Czeisperger's "Wishful Thinking and Poor Planning: Load Testing in the Real World" both looked interesting to me in the next block, yet I was still not in a place to get there. While there were some interesting hallway conversations, I was kinda bummed that these presentations were opposite each other.

Another presentation I really would have liked to see was Catherine Powell's "Agile in a Waterfall World." As it was, I was doing a joint presentation with my boss at the same time. We were speaking on our experiences in creating testing groups for companies where there had not previously been one.

The title "No Box Mixes: Building a Test Group from Scratch" was drawn from that idea. It seems that at every conference I've been at for some time, there is at least one lost soul wandering about looking for ideas or help or something because they were expected to create a test group. The gist of our presentation was that there may not be a single "right" way to go about it, but there were things to keep in mind, like understanding what your mission is and being patient with yourself, your new team and your bosses. Kristin, my boss, and I had each been through this and we quite simply compared our experiences at different companies.

Much of Wednesday afternoon I spent in hallway conversations with a number of people. The one that stands most clearly in my memory was with Karen Johnson. We spoke for nearly an hour - AN HOUR! - on a variety of topics including strategy (one of my favorite topics) and empowering and encouraging people beyond their own norms and expectations and books and silly interfaces with airline registrations on smart phones. Mind you, my phone (like me) was clearly the luddite of the conference and so I relied on my trusty laptop to keep me connected to the world. We also exchanged slide decks and talked about the idea of presentations and presenting and how people perceive our respective, if very different, methods of delivery. What an amazingly enjoyable time for me. I came away from that discussion feeling refreshed and ready to take on the rest of the conference, if not the world.

That evening, the "conference party" was at the Wildhorse Saloon, downtown. This is owned by the same organization that owns the conference center where we were meeting. An interesting buffet selection (unless you were a vegetarion or vegan) with some interesting beverages and line-dancing and mechanical bull riding - Selena Delesie recorded some folks riding the bull and generally having a good time (you can find them on YouTube if you search diligently.)

After a brief foray to find my lady-wife some boots (the store was closed, hence the "brief" part) we settled in to a grand time before heading back to the conference center.

Interesting people I met that day included Neil Fitzgerald, Tonia Williams, Corey Anderson, Bill Bennett, Eric Pugh and Todd Miller. I know there were others, please don't be offended if I've left you out of this list.

Come to think of it, if I have, drop me a note and refresh my memory!

Fun and Games at STPCon 2011 - Part 1.

2011-04-02T21:50:00.000-04:00

I can hardly believe that it has been a month since I wrote a blog entry. It has been a remarkably busy month.

STPCon, the Software Testing Professionals Conference (as it is currently branded) was held in Nashville March 22 through 24. As has become common for many conferences, there were also workshops and tutorials on Monday, March 21. I was fortunate enough to have been selected to speak at the conference, along with my boss. So, we headed down on March 21, driving to Nashville. We are close enough that was a feasible option.

We had some interesting adventures on the drive down, but that will be a different story at another time.

We arrived Monday evening, checked into our rooms and collided with a variety of people we know. Monday evening was a nice relaxed evening with Nancy Kastl and Dan Mish, just chatting and talking about testing and enjoying each other's company.

Tuesday was the day of my first presentation. Before that, however, James Bach gave an astounding presentation on test coaching. I had seen recordings of James speaking, but this was the first time I heard him in person. I was impressed and inspired.

The first breakout session I went to was Karen Johnson's presentation on Strategy. What I thought interesting was her take on Strategy, as opposed to a document called a Test Strategy. It was interesting and, for me, very thought provoking.

This was the two great presentations I heard before I spoke. What an inspirational way to start my day!

My presentation was a session, as opposed to a workshop, on Test Process Improvement. The room was quite full, and most of the folks were interested in the ideas I presented. The gist of these, which I've written about before, focus on improving the skills and abilities of the test team, rather than a fixed process, to realize improvements in testing. It led to conversations that lasted through the week.

In the afternoon, Nancy Kelln gave a great presentation on working with and leading Business Testers. I hate to say it, but I was stopped by a couple of people who asked questions and wanted to chat, so I only caught the last 20 or 30 minutes or so. What I heard, I thought was very good, and I regret being delayed. and missing the start. I then heard Jon Bach's presentation on Threads - He called it "My Crazy Plan For Responding to Change." I had read some blog posts on the idea and thoroughly enjoyed it.

I then had an interesting hallway conversation with Jon and James Bach. It was brief, yet very enjoyable and informative.

The evening was a meet-and-greet where I got to catch up with people I had not seen in some time or had not had a chance to talk with much before in the day. For me, it was a who's-who list: Catherine Powell, Scott Barber, Dan Downing, Dawn Haynes, Jim Hazen, Lynn McKee, Nancy Kelln, Selena Delesie, Kristin Dukic - I know I'm forgetting some folks...

I kept running into during the day incliuded Abbie Caracostas. All in all, it was a great day and a good way to start a week of learning and thinking!

On Learning and Enlightenment and Software Testing

2011-03-02T21:11:00.000-05:00

This has been a remarkable week for me.

Over the weekend, I finished the "Lesson" portion of the Black Box Software Testing Foundations course from the Association for Software Testing. I wrote the exam Monday night. I'm not sure how to describe this experience. It was a massively intense (as opposed to mildly intense?) experience where there was a lot of information poured out. On top of that, the conversations in discussion forums around the lessons, quizes and whatnot tended to sometimes take on a life of their own. All in all I found myself in an intense learning experience where ideas did not so much flow as rush at you. (My lady-wife compares this to trying to drink from a firehose.)

I can safely say that there was more information about testing that came at me over the course of this class than I can remember having in some time. Invigorating does not begin to describe it.

So, as I'm catching up on other things, and decompressing from the experience, and dealing with work stuff and trying to keep up with that. I come across tweets about the EuroStar Testing Time Out. Then I realize that the first time out speaker is Lynn McKee! I've mentioned Lynn more than once in blog posts. She is really good and takes a fresh look on things. THEN, I see she has a blog post on the experience. Way Cool!

Then today I was working with the boss on polishing the presentation we're doing together at STPCon. She asked me what I thought I could apply from the class right now. I began listing off ideas where some of the concepts from BBST could be applied right then. There were others where some of the ideas would take a bit of work to explain, then maybe experiment with, They may have to wait a bit (we are pressed for time right now.)

This evening I looked at what was coming up and got all excited all over again. CAST is coming up in August. The main track sessions look amazing. I'm excited about the emerging topics track. There have been some interesting proposals submitted already. (We set some up as examples - and several people have submitted really good, interesting ideas.) If you have something you're passionate about, and are going to CAST, why not try your hand on an idea that you're passionate about? More information is here.

So, yeah, the more I learn, the more things I find interesting and the more I realize I want to know. Amazing, isn't it?

On Drumming and Learning and Testing

2011-02-20T16:18:00.002-05:00

I really don't have time to be writing this blog entry. I should be working on the exam study guide for the Black Box Software Testing (BBST) course I'm taking through the Association for Software Testing (AST.) If not that, I should be finishing answers submitted some time ago to Ask the Tester through STP. I'm getting there, but a couple of the answers I wrote I'm not really satisfied with. I also should be polishing the slides for the presentations I'm doing at STPCon next month. ALMOST done, is not DONE. Right?

I needed to come up for air after having a bit of a break in my schedule though.

One of the commitments I have that is fairly long-standing is teaching drumming. Since July, I've been working with a group of absolute novice drummers with a pipe band on the East side of Michigan - about two hours from my home. So, we got together once each month in July, August and September, then twice a month since then. We met on Saturday afternoons for four hours.

The youngest student is eight years old, the oldest is in his late 30's. The goal was to teach them enough where they could play with their band. Two students had some drumming experience outside of the world of bagpipe bands: one is a middle-school student learning drums through school; the other is his dad. Dad had some drumming but no formal training. The lesson in July consisted of "This is a drumstick. This is how you hold a drumstick."

The first week of December, one of the students made a comment that he felt like they were doing a lot of exercises but bot really getting what they needed to actually play with a band. I asked what he meant. He said "We do all this stuff, I'm learning a lot but I'm not sure how it applies to me playing in the pipe band." My response was "You all are closer than you think. There is no reason why at least two of you will not be able to play with the band at the band's ceilidh (a party/celebration - lots of music and dancing and bagpipes) in February. Everyone else will be able to play with the band by May." They looked at me in complete disbelief.

The next lesson, shortly before Christmas, I passed out a new exercise, a full sheet of music. I told them, "This is a drum salute that you will all be playing in February. All of you can play everything on this page."

Their performance was last night. My lady-wfie and I, grandson as well, drove across the State to go to the band's ceilidh, which is their biggest fundraising event of the year. The place was packed - hundreds of people in a hall. A short introduction and the drumming students came out first - before the full band. Then they played. They did really well. I was terribly proud of them and what they had done.

When they finished as a group, the pipers marched into the hall and joined them. The students who were not quite ready stepped back and moved off stage while the other drummers played the rest of the performance. At the end of the night, this band came out again along with the two guest pipe bands and played together. Some of the stiudents went out to play with the other bands, some did not feel comfortable doing that. No worries. No pressure. The idea was to have fun.

All of them are reinvogorated. The most consistent comment I heard from them was how much fun they had playing. Even the ever-so-cool teenage boy smiled and said that was a lot more fun than his school stuff.

So, after driving back across the State this morning (hoping to beat the nasty weather predicted) I was thinking about the drumming students experience and my own with BBST. Part of the opening lecture was about reading carefully. I muffed two questions on the last quiz and one on the one before because I did NOT read carefully enough.

In working on answers to the essay questions in the exam study guide, I find myself challenging my own statements, thinking hard about the answers and running through them in my mind. I am finding myself more challenged than I have in some time to look at how I think about things, testing in particular.

In the current project at work (yeah, I'm trying to keep up with that as well) I find myself thinking about concepts I've just read or re-read from the course. (If the boss thinks I was passionate about how testing can be better at the company before this course, look out!)

It IS more work than I expected. I knew it was going to be a lot of work; it is simply more than I thought it would be. At the same time, I'm also having fun learning and stretching how I think about things. That is very rewarding in itself. So, yeah, like the drumming students, I'm having fun.

Oh. I forgot to mention that STPStanley came along with us. We took a lot of pictures and will be posting some of them shortly.

Speaking and CASTing or Presenting Your Ideas In Context

2011-02-03T10:49:00.002-05:00

I'm really excited today.

I find test conferences amazingly inspirational. What I find to be the best part of many conferences are the converstions that presentations can inspire.

One way to get a lot of ideas out there is by lightning talks - quick presentations on a topic. Sometimes, that's it. Somebody talks for a few minutes and the next person gets up and talks on a totally different topic.

Some conferences, like CAST, are different. Any time someone presents an idea (gives a talk) there is scheduled time for discussion. If the participants in the discussion want to continue their chat after the alloted period of time they can grab a corner or a hallway and carry on. The next person gets up and gives their presentation and the cycle repeats itself.

Now, the CAST version of "lightning talks" has often been an "emerging trends" session track. This year the take is a little bit different. The idea is that you can check out the conference schedule and see what is being presented, what topics are being discussed. If there is one that you believe should be discussed and you want to present it, you can submit a proposal for the Emerging Topics track.

This track will feature 20 minute time slots which include 5 to 10 minutes of discussion, for the topic that people want to speak on and believe would be important.

Here's the cool part.

Instead of signing up on a paper stuck to a wall, you, the person with the idea, can enter a proposal at a WIKI set up specifically for this. (The good folks at Socialtext are contributing the wiki space, thanks folks!)

If you would like to speak at CAST 2011, you can propose a topic for the Emerging Topics session.

Now, each topic is slated for 20 minutes with at least five minutes for discussion. If you think that you would need more time to "do justice" to the topic, please make your case and reasons clear. The deal is, the more topics that get more time, the fewer the number of people who will have the chance to speak. So, the organizers would really like to make that the exception than the rule.

To propose a session, you need to join the CAST 2011 Socialtext group and create a wiki page using the proposal template.

Once you have created your proposal, other folks will be able to vote and comment on your proposal and others as well. You can read the notes, change your porposal - and evaluators can return and comment repeatedly as well, and change their scores!

Voting will be cut off a little early - right now the plan is July 15th. That way we can create and post a coherent program before the conference so folks can see what may be of interest to them in advance. The idea is to take the feedback from votes in serious consideration, along with conference theme and reputation of the speakers.

Now for the part that I am personally excited about...

In order to apply email either Matt Heusser (matt.heusser@gmail.com) or ME (peterwalen@msn.com) and ask to be invited to the CAST 2011 Emerging Topics Group on Socialtext. One of us will send you an email about the group and a link to follow. From there you can follow the instructions to add a talk or comment on a talk or whatever.

We also may need some help - one or two people to manage the rooms. Depending on how things go, that role might be expanded to include some wiki gardening and possibly help creating the schedule. You could be an ombudsman, sergeant-at-arms, or whatever other title you'd like.

We can not offer any compensation for helping out, nor for giving a talk. If you give a talk or help out, I would be personally in your debt. I can tell you from my previous experience that the conference will have greater value for you in that you can build deeper relationships, be more engaged and generally have a ton of fun while learning.

Matt says "One thing I can promise if you give a talk or help out with emerging topics: At CAST two thousand and eleven, at least ... you'll never have to eat a bagel alone."

My take is "If you give a talk or help out with the emerging topics at CAST2011, I'll think you're way cool."

UPDATE!!!!!!!!!!

July 20, 2011 -

The Submission and Voting period is now closed, selections and a schedule have been made. This has been an interesting, thought provoking and fun project to work on. I am looking forward to meeting everyone in person after communicating by email and telephone.

Thanks to all who participated - Pete

Motivation and Passion, or, Don't Harsh My Testing Buzz

2011-01-17T21:22:00.001-05:00

So, part of my daily morning ritual is to check email, check logs for runs I may have kicked off overnight, then check the "sanity" file. That contains links to a few comics on the web. One is Dilbert (duh, its like computer/engineer/geek/argue-about-best-Star-Trek-series heaven) the other is a web comic called Urban Jungle.

One of the Urban Jungle comics last week was interesting. For folks who've done anything for a period of time, the idea of burnout, or "Why am I doing this?" may not be a completely unknown feeling. Keeping that feeling at bay can sometimes be a challenge.

Now, Lynn McKee has given some really, really good stuff on testers, motivation and passion. I've attended two session she presented where she has done a fantastic job of moving people, particularly testers, forward to find ways to keep testers, and their leaders, passionate about what they do.

Other folks have made the observation that the problem for many leaders is to avoid de-motivating them.

Generally, I'm in the "You're responsible for finding your own inspiration" camp. Most of the time I think testers can and should seek out and develop their own sense of purpose and motivation - the drive to become better.

Now, I know that is not going to happen with every tester. I've worked with some who learned things thus and see any attempt to change thus as an accusation that doing thus is wrong or bad. Reminds me sometimes of the quote (I don't recall who said it) that people are more firmly wed to their ideas than to their spouses.

I also know that some folks will do what they are told to do and figure that the easiest way to get along is to, well, get along and not "make waves." After all, if you make waves or stick your neck out or do something non-conformist, bad things may happen.

If I were to think seriously about this, I'd suggest folks, managers and bosses and workers alike, think about what they do. If everything is going great do you need to consider learning something different? Are there newer skills that you can pick up? Are there new ideas getting floated around out there? How about new technologies?

I understand some reluctance on several of those points. I probably share them. After all, most folks who have done anything with computers or software for more than a few years have seen ideas bubble up, get embraced as the "next great thing" then fade away into oblivion. The funny thing is, a few years later a new name will be slapped on the idea or approach and it will be repackaged and rebranded as the "next great thing."

So what does that mean for you? Are you so complacent as to rest absolutely assured in what you do that you can wait for the bosses to tell you the next thing to learn? Are you so certain that what you are doing now will be the way you are doing things in five years? Really? Will there be no new ideas that can enter your thinking? Will there be no new insights to drive your curiosity?

If you are a testing boss, do you mandate every minute of what your people do? How about your resources? Are your people resources, like reams of paper or ink and toner cartridges?  Are your people assets to be developed and nurtured?

If I was the Universal Lord of Testing, with the authority to mandate one thing to all testing groups and bosses everywhere, it would be this: Allow some time each week for your people to see if there is something of interest to them that they want to learn more about. Then, let them learn about that.

Foster the sense of curiosity and excitement that you felt when you were learning about computers and software and programming and all the way-cool technology stuff. Even if the first machine you worked on is now sitting in a museum, I suspect you had that feeling once upon a time.

If you are not a boss and are a tester, I'd mandate this: Make the time to look for something of interest to you that you want to learn more about. Even if the boss does not "permit" it, the boss is ignoring the order from the Universal Lord of Testing (me) and therefore that "don't do it" order you get from them is improper and MUST be ignored. Even if you spend a few minutes at home, you know, your "own" time, surfing the web, looking up on-line testing discussion groups or looking for a local testing group, you may find more rewarding things than you know currently exist.

As my lady-wife is fond of saying, "In 10 years, you'll be 10 years older whether you do anything to make yourself better or not. You may as well make yourself better during that time."    She's really smart that way.

So, you take charge of your own career. Join an association - even if you need to pony up the membership fees yourself. Buy some books, even if the company won't reimburse your expenses, the read them. Find someone to share ideas with - or just ask questions of them.  Find something that is of interest to you and learn about it.

The tricky thing is that it doesn't matter if you're a tester or a boss or, something else. You can learn and improve and discover things to make yourself better. If you're a boss, lead by example. If you're not a boss, check what the boss is doing. If the boss is always looking for new stuff, new ideas and new thoughts, tune in and see what is happening. Maybe you'll learn something.

If the boss isn't doing that, meh, they're a boss not a technician. You're a tester.  Make yourself better. Its your career.

2011: A Look Forward

2011-01-01T22:27:00.001-05:00

On SQA Forums, someone posted a question about "New Year Resolutions." There were many of the usual suspect types of responses, e.g., get in shape, lose weight, gain training, learn something new...

I posted that some years ago I resolved not to make any "resolutions," as in commitments to myself, that I knew I would most likely not be able to fulfill. Yeah, a little snarky, but it was also pretty honest.

Therefore, as my last post was a look back on 2010, as I was sipping a brandy last night chatting with my lady-wife as she knitted and some show was on television, I had some thoughts running through my head. Pretty sad, eh? The days of running off to the local Scottish Society's Hogmanay are distant memories. Most of our friends we'd get together and play music to welcome the new year are now widely dispersed. I wonder if that makes us "old" - Hope not.

Ah yes, my thoughts.

Some of this I actually started thinking about late last year. I sent some emails to a handfull of people asking them for assistance. In some ways looking for advice, and in otherways, to be sounding boards for my thought processes. There are changes coming that I've been pondering.

For most of my career in software, I've worked for someone else. For most of that time, it was working for companies where producing software was to support their primary business. The software was not their product, it supported the product or its delivery. To be honest, working on the product the company makes is fun. It can be frustrating when I don't have the option of actually talking to the people who asked for a change or enhancement, and I speak with people who may understand what the people who asked for they really mean.

The Road Ahead...

The interesting thing is I've been thinking about the future. Well, not THE future, but what lay ahead for me professionally and how that may impact the family. It would seem there are several items that are possibilities for the coming year. One path would be to look for new work opportunities, either as a contract/consultant or as a full time, permanent employee. Yeah, as if "permanent" means much.

Community

Another option is to become more involved in the testing community. Actually, I started working on that as well in 2010. What I mean is that reading blogs other folks write is a good way to learn what they're thinking is. Reading and participating in on-line forums is another way to both learn and become involved. Well, doing that as much as I can right now.

Of course, more actively engaging in both of these types of activities is on my list of things to do this coming year. Ya know, the funny thing is, the more I talk with folks about things I learn and have learned, the more I learn myself.

Local Testing Groups

Another thing, the local testing group, GR Testers, has been going in fits and starts for a while. Meetings have been sparse of late. The most recent one, December, was kind of fun. There were a bunch of us sitting around a table, lots of wings, good beer and folks talking about testing. Good way to spend an evening. There's another meeting coming up Monday, 3 January. It makes it the first time in quite a while that there were back to back monthly meetings. Normally, they are officially held every other month. It seems that as more people are showing an interest, the meeting frequency will pick up.

I wonder how many other local testing groups are out there that have a meeting schedule based on "whenever" instead of "We meet at this time, and here are the next couple of topics we're focusing on at these meetings..." I believe that the more people know about local groups, the more they are invited to participate and the more information that is available about them, the more active and the stonger the community there is.

I think that pretty well sums up what I'm looking to do with the local group. I believe that getting more people involved and talking about testing is vital to improving not only our individual tradecraft, but the abilities of the local community. Sharing well reasoned ideas can do nothing but good, presuming all are allowed to learn and ask questions

Personal Development

Now, I realize that any of the above activities can lead to improving any individual participating. What I mean here is something a bit more. I had been signed up for the BBST Foundations course offered by the Association for Software Testing for a session in in the fall of 2010. Things happened and that session was cancelled. I could not take the session offered as an alternative.

The GOOD news, for me, is I am signed up to take the Foundations course this spring. YEAH! I am really looking forward to this. Everyone I know who took the course raves about it. Big-time excited.

I've continued reading blogs and articles and books and talking with people and... everything else. My goal is to continue learning and to continue to share what I learn.

For conferences, I'll be attending and presenting at STPCon in March in Nashville. I bought myself a birthday present and renewed my AST membership in October. If I can work it out, I'll be attending CAST in August in Seatle.

At the day-job, I've continued to be a pest, and will do so for some time. The cool thing is the boss is good with it. Something about "pushing everyone to improve..."

So, that is a combination of goals, intentions and plans for 2011. What the future will really bring, I'm not sure.

On the other hand, the lady-wife did give me a list of places where she'd like to live should a relocation option present itself...

2010, A Retrospective

2010-12-31T09:25:00.001-05:00

This year is drawing to an end. I know it is a tad lame to have a "look at the year that was" or any of the other cliche laden phrases that tend to be used to introduce these things.

The thing is, it has been an interesting year for me personally and professionally.

Let's see. General stuff. I retired the blog attached to my defunct drumming with bagpipe bands website. I replaced it with, this one. It had been in the "thinking about" phase for a long-time, and finally I decided to do it. Ya know what's interesting? As I think about other stuff - often Non-Testing stuff - something pops into my head about software development or testing or SOMETHING. Sometimes, that results in a blog post. Other times it leads to sitting in my big green comfy chair sipping a brandy and thinking.

Interesting work stuff at the day-job with interesting challenges early in the year. With a flurry of emails I found myself and the boss registered to attend QUEST in Dallas, Texas. This was a huge surprise to me as I was not expecting it at all, given limited budgets and going to TesTrek in Toronto the previous October. QUEST was interesting in that I met a number of people whose writings I had read, and had not met in real-life. I also got to connect with people I had met before and get back in touch in real-life.

May I received confirmation that I COULD attend CAST, which was being held around 15 minutes from my house - then in June it became clear that the scheduled release would conflict with attending CAST, so the company would neither pay the conference fee (something I was not too worried about) nor would they grant time-off. That one was a problem. July rolled around, schedules shifted again. I could be granted the time to go to CAST IF I was available during the conference. COMPROMISE! COOL!

Sunday evening of CAST had a great dinner and conversation with Fiona Charles and Griffin Jones and the lady-wife at a neighborhood Italian place. Recipes from Sicily and friendly folks and good wine and great conversation, little of it around testing, but all of it applicable to testing. What a great night.

Another night had a fantastic dinner out with a bunch of folks - Yeah, I know I blogged about that shortly after the event - it is still a great memory.

Dragged the boss in one evening to meet some of the great ones of the craft who would be there. Had a fantastic evening out with Nancy Kelln and Lynn McKee and the boss - more good wine (notice a trend?) and a great conversation.

Then, a bombshell was dropped that left me gob-smacked. It seems one of our dinner companions had a conflict and could not fulfill a speaking commitment in Toronto, would I be interested in being suggested as a an alternative speaker? Holy Cow. I thought about it briefly... and said Yes. One thing led to another and I did indeed speak at TesTrek in Toronto that October. Yeah, I blogged about that, too.

Stuff at the day-job continued to be interesting - meaning, really, really, busy.

So, things progressed. Talked with the boss about some interesting emails. The result of those chats was submitting proposals to a couple of conferences. I submitted proposals for a session similar to the session at TesTrek, but with a more advanced perspective than the general view there. The exciting thing was that the boss and I submitted a proposal for a joint presentation based on our experiences starting a QA/Testing team from scratch.

One conference said "no thanks" (although the boss was asked to consider a presentation in a different area) the other accepted both proposals! Yeah, that rocks. I get to hang with the cool kids at STPCon in Nashville this coming March.

More projects were successfully rolled out at the day job. There are some interesting things that seem to be happening there, they may lead to more ideas on blog posts.

The local testing group and its attempts spread its wings and fly has been great fun to watch and be a part of. Through it, I've met some terrific people, like Matt Heusser and Melissa Bugai , and have had fun sharing the adventure with them.

At home it was a good year in the garden. We had a good crop of strawberries and peppers and tomatoes, although some of the others were a little surprising in what were less prolific than expected. Several big projects got done - and inspired thoughts about, then blog posts about, software and testing.

We had some sadness in our lives this year. Stuff that led to serious rounds of soul-searching for "what is this all about." We also have had some great joys in our lives this year. For that, I am grateful. I don't know what 2011 will bring, but I am looking forward to the next year.

A Hero's Fall From Grace or Why a Big Pay Raise Is Better Than a Statue

2010-12-30T17:41:00.000-05:00

A couple of things happened recently that made me think of things I probably would not normally think of.

I know a fellow who works for a company that has one or two (depending on needs) "major" releases each year. They also generate and distribute monthly maintenance releases to address defects, bundle hot-fixes neatly into a package and all the other good things that come from such things.

A recent release had some "issues." Lots of issues. After working for 12 "work" days and a Saturday and Sunday thrown in as well, this fellow's boss made a comment that he had "saved them again" and was a "hero."

When thinking about this, I got to thinking about Selena Delesie's blog posts on "hero culture."

When teams pull together and work to overcome obstacles, amazing things can be achieved. Sometimes, the issues encountered require extra effort and creative thinking and good, if not great, communication between testers and developers to find solutions. This is a fantastic thing and is, I believe, the point of being a "hero" in our profession.

The part that makes me think, if not wonder, about this is when this becomes the rule, rather than the exception. When the same team that pulled together and found solutions and worked toward delivering the best product that can be delivered is expected to work long hours regularly, to repeat the same "pull out all stops" effort for every project, big or small, there is a danger.

That danger is that the edge, the creative thinking, the "Hey, what if..." factor gets worn down.

Now, I know there are a lot of potential reasons for this to happen. Some may be within the team itself. There may be factors at work where individuals like the drama, the "rush" of the massive push at the end.

There may also be issues around the development methodology or practices. If the only testing done in unit testing is validating the "happy path" then likelihood that builds will come fast and furious, depending on how quickly the detected defects are addressed.

Another possibility is that someone, possibly in the test group or outside the test group but involved in the projects, likes the chaos - the frantic push is something they thrive on.

Whatever the cause, when every project turns into a heroic stand worthy of an action movie, something is seriously wrong. When testers, or anyone else, are expected to perform super-human, or heroic, feats every project, the edge will be blunted. The probability of significant defects being missed increases with each cycle. Eventually, people will be working less effectively no matter how many hours, or how "hard" they are working.

In some shops, the option to simply say "No, I won't do this" may be a legitimate one. In shops where contractual requirements don't allow such a response, I don't have a solution. Now, I am aware of the need to keep regular releases going, I'm just not sure of a solution that works everywhere.

What I do know is that the bosses, the leaders at your shop need to make sure they don't need their people to be heroes each and every release. Horatius held the bridge, but he had help. The lone cowboy was a myth, just like superman.

On Exploration or How You Might Be Testing and Not Know It

2010-12-17T21:05:00.004-05:00

I had an interesting conversation earlier this week. A colleague dropped into the cube, grabbed a handful of M&M's and muttered something about how she kept finding defects and wasn't able to get any test scripts written because of it.

OK - That got my attention.

So, I asked her what she meant. It seems that the project she was working on was not terribly well documented, the design was unclear and the requirements were mere suggestions and she had gotten several builds. So, she was working her way through things as she understood them.

So she explained what was going on... She intended to make sure she was understanding them correctly so she could document them and write her test scripts. Then, she could start testing.

The problem was, she'd try different features and they didn't work like she expected. So, she'd call the developer and ask what she was doing wrong. Problem: She wasn't.

The issue, as she saw it, was that the code was so unstable that she could not work her way through it enough to understand how she was to exercise the application as fully as possible. To do that, the standard process required test cases written so that they could be repeated and "fully document" the testing process for the auditors. Because she kept finding bugs just "checking it out" she was concerned that she was falling farther and farther behind and would never really get to testing.

More M&Ms.

So we talked a bit. First response: "Wow! Welcome to Exploratory Testing! Your going through the product, learning about it, designing tests and executing them, all within writing formal test cases or steps or anything. Cool!"

Now, we had done some "introduction to ET" sessions in the past, and have gradually ramped up more time in each major release dedicated to ET. The idea was to follow leads, hunches and, well, explore. The only caveat was to keep track of what steps you followed so they could recreate "unusual responses" when they were encountered.

Explaining that the process she was working through actually WAS testing lead to, well, more M&Ms.

The result of the conversation was that the problems she was encountering were part of testing - not delaying it. By working through reasonable suppositions on what you would expect software to do, you are performing a far more worthwhile effort, in my mind, than "faithfully" following a script, whether you wrote it or not.

Mind you, she still encountered many problems just surfing through various functions. That indicated other issues - but not that she was unable to test.

That thought prompted another handful of M&Ms, and a renewed effort in testing - without a script.

Measurements and Metrics, Or How One Thing Led to Another

2010-12-16T21:53:00.001-05:00

So, once upon a time, my dear daughter and her beau gave me a combination "Christmas and New Job" present. Yeah, I was changing jobs in late December... What was I thinking? Not sure now, but it seemed like a good idea at the time.

Anyway, this gift was an M&M dispenser. Yeah. Pretty cool, eh? Turn the little thingie on the top and a handfull of M&Ms would fall through a little chute and come out the bottom. Not too shabby!

So, move along to the summer of 2008. The company I was working for had a huge, big, ugly release coming out. It was the first time with a new release process and schedule and nerves were pretty thin all the way around, developers, testers, support folks, bosses, everyone. Well, being the observant fellow, I realized that we were consuming a LOT of M&Ms - Of course, it helped that the dispenser was at my desk, in my humble cube/work-area.

So, I started keeping track of how much candy we went through. The only folks who partook of these multi-coloured delicacies were the QA/Tester group and a couple of brave developers who realized that we were not contagious and they could not catch anything from us. (They also learned that they might learn something from us and we testers might learn something from them.)

What I discovered was kind of interesting. As the stress-level went up, so did the consumption of M&M's. As things were going better and things were looking good, then consumption went down.

Using a simple Excel spreadsheet, I added up the number of bags eaten (it helps that they have the weight on them) as well as the partial bags each week. Then using the cool graphing tool in Excel, I could visually represent how much we went through. By correlation, the level of stress the team was under.

After about a month, I "published" the results to the team. SHOCK! GASP! We went through HOW MUCH??????

Then the boss sat down with me and looked at the wee little chart. "What was going on during this week?" Ah-HA! The first obvious attempt to match what the graph was showing. I tracked usage for the rest of the year. The amount the team consumed over the six months or so that I tracked, lined up remarkably with due dates and, interestingly, defects reported in testing.

One thing led to another, and the dispenser was put away for a time. In mid-2009, for reasons which now I don't recall, the M&Ms came back out. As the crew realized this, consumption went up. And up. And up. Eventually, I noticed that the same pattern demonstrated before was coming back.

I learned two things doing this exercise (which I continue to do.)

One, is that it is possible to measure one thing and be informed on another. Now, I am well aware of the First and Second Order (and other) Measurements described by some of the great ones in our craft. This exercise brought it home to me in ways that the theoretical discussions did not.

The other thing, sitting at a desk and making a meal of M&M's is a really, really bad idea.

Not the Happy Path or I am a Hi-Lo

2010-12-06T22:20:00.000-05:00

I was at a local tester meeting tonight. Tons of fun and a great conversation. There was a student from a local college attending. In the course of the discussion we were discussing the dangers of trusting the "happy path." The student asked, "What do you mean by that?"

So, we explained about looking only for what "worked" and not investigating other issues that were more problematic and probably more error-prone. In the midst of this, a story from over 20 years ago flooded back into my memory.

Mind you, it influenced me greatly at the time. It led me to some of my early revelations of software, development, testing and "revealed truth."

When the IBM PC AT was state of the art, I worked as a developer (programmer) for a small manufacturer that had its own warehouses and distribution center for its finished product. The company was a family run company located in fairly old buildings, well, from the late 1800's and early 1900's. One individual was the nemesis of the software development folks.

He was in charge of the warehouse - both finished products and component pieces. Any sofftware running on machines in the warehouse had to be run past him for approval. These were scattered around the varous floors of the warehouses. Now, these warehouses were monsters. Support posts were massive beams, 24"x24". The PCs were usually located near a beam.

The very old warehouses had a very small amount of leeway for placing pallets and the like. Placing a case or pallet even a few inches away from where it was supposed to be could cause a fair amount of problems for the hi-lo operators moving material from one area to another.

The curious bit was that at least once a week, a h-lo would hit (referred to as "bump") a support beam. This was usually result from navigating away from mis-placed pallets. Sometimes it was simply the operator missing a turn. Once in a while, they'd hit the power conduit that powered a PC on an early network connection. Once in a great while, they'd "take out" the PC itself. Oops.

Back to my story.

This same nemisis of software developemtn was finicky. Extremely finicky. He wanted to make sure that any data entered could be retrieved under any circumstnace. If the user hit "enter" or "save" he had the expectation that the data would be fully retrievable.

His favorite tactic during demonstrations where changes or enhancements were being demonstrated, was to have the demonstrator enter components or finished part information. He'd sometimes have the demonstrator repeat the process. In the middle of the repeat, after clicking "save" or going to the next page, he'd say "I'm a hi-lo." and unplug the power cord.

He'd count 20 and plug it back in.

Then he'd sit down next to the demonstrator and say "Show me what you just entered."

If you couldn't, he refused to accept the change until it could pass his "test."

How much work is it for your users to recover their work after a "that will never happen" event?

Winter Testing Workshop or How to Go Sledding With No Snow

2010-12-06T11:54:00.000-05:00

I found myself testing an application for the day job over the weekend. Thanks to the wonders of reasonably modern technology, and a decent broadband connection, I was able to do so from the comfort of home.

Here I was, Sunday afternoon, sitting at my dining room table connected to the office running tests that I needed to work through. It was a lovely day. Cold, but not terribly. The sun was even trying to peek out from the clouds that had been hiding it for most of the last week. We had some snow the Wednesday before - not quite two inches or so on the ground. By Sunday early afternoon, there was none on the pavement or sidewalks, and much that had been in the grass / yard had returned from whence it came.

So as I was working my way through a log file, I heard an obviously frustrated child outside. I looked up and saw the wee kids across the street looking quite perplexed. They wanted to go sledding on the small bank in their yard, leading down to the sidewalk. Problem: Most of the snow was gone, therefore, the sleds/slider-thingies they had simply were not working well. Sledding was pretty much out of the question - particularly when you're between the ages of 6 and 9 years.

When you're stuck with a testing project, without any clear way forward. What do you do? Send a terse email demanding whatever you need from whomever you believe should get it to you? I tried that when I was younger and more green in software testing than I am now. Didn't work so well.

How 'bout rail against the unfair universe? "Why do we do things like this?!? This is AWFUL!" Yeah, good luck with that, too.

Or, maybe, you could look around and see what options you have, even if they are so far outside the realm of possibility that all the "experts" would say "Don't waste your time!"

The kids across the street chose the third option. They put their two slides/sleds next to each other on the top of the "hill" that is the bank in their yard. Then, while the youngest held them down so the wind would not blow them away, the older two used a) a garden rake and b) a snow shovel to get enough snow from the REST of the yard tp make a run wide enough for both sleds that ran down the bank, across the sidewalk, and ended with a small berm (of snow) to keep them from going into the street.

They then proceeded to have a good 90 minutes of fun doing something that the "experts" (grown-ups) would have told them they could not possibly do.

A 9-year-old can think that creatively. Can we?

Of WikiLeaks and Diplomats or Software and Trust

2010-12-03T22:20:00.000-05:00

Um, unless you've been in a cave the last week or so, you've heard about the recent leak of Diplomatic "Cables" (what a love anachronism in 2010.) Not the leak, but the idea of telegrams.

So, listening to the radio on my way home from work last night, a commentator likened the situation that the US and its diplomatic "partners" are in to a teenager's private comments about their friends getting back to those friends. All of them. At once. They went on to talk about how they would and need to rebuild their trust to rebuild their relationship.

That got me thinking about some conversations I had a while ago, both in person and by email. The thing is, there was one really simple theme running throughout all of them. The entire development organization, not just the testers, not just the developers or designers or BAs or PMs - but all of them - must trust each other to be doing the best they can do, and they know how to do.

If that trust is lacking, the group will not be able to function properly. If one section of the group believes themselves superior in some way, that will show through to all the groups and will be as destructive to the overall relationship as, well, having private communications made public.

Through the Looking Glass or the Fear Factor of Management

2010-11-30T08:29:00.002-05:00

I finally have a bit of time to try and catch up on some reading. I don't know how strange this is, but I tend to read the same book two or three times, particularly if I can only read small segments at a time. As I'm not the widely travelled road-warrior spending long hours waiting in airport terminals, and when I am sitting in airport terminals I tend to have a stack of day-job stuff to read/respond to, I find myself falling farther and farther behind in my reading. The result is, I sometimes get to read a paragraph or two of a book, then get called away to deal with something.

I've been working my way through two books over the Thanksgiving weekend, both on software. Which ones do not really matter. I resolved to start the smaller one over completely and see if reading entire pages at a time made it better. (It did.)

I have also been trying to catch up on my long-list of blog posts that I intended to read and see what the great ones of our craft can teach me. The answer was: "Quite a bit." One stuck out though and prompted this post.

Selena Delesie wrote some time about Yes Men and the managers who like them. I had read enough of that post to say "I need to look that up when I get a moment." That moment finally came. Toward the end of her entry, Selena wrote "Have you worked with or for someone who is a dictator-type who thrives on working with ‘Yes’ Men?" This is my response:

Yes. To make matters worse, I did not even report to that manager, either directly or indirectly. I was in a completely different reporting line than he was. My Manager was a peer with him. However, as he managed a large development group I needed to work with (as QA and BA and PM) it presented all sorts of challenges. Forget that. It was not a "challenge." It was a "pain."

Management By Intimidation was the best way I can think of to describe his approach. Really, it was un-good. People who disagreed with him or had an opinion that did not exactly match his own were belittled, often publicly, or (as I learned later in private conversation then first-hand) had their position/employment threatened. Fear was a great motivational tool.

People who did not work for him but were in meetings with him could count on having any statement challenged, any assertion questioned. "You can't prove that, you have no evidence!" Never mind that the previous 15 minutes had been laying out evidence to support the statement he was challenging (gratuitously.) And even when assertions were presented as "possibilities" you could be certain that anything that could be in conflict with what he wanted done would be publicly thrashed.

Other managers were afraid of what he would say to the VP in private. He created a mystique of "getting things done" at all costs.

In a matter of months, from the time when he first joined the company to when I needed to interact with him or his people on a daily basis, this job went from the best job that I had ever had to the absolute worst one. In truth, I learned a lot during that time.

Managers in the business units were frustrated. When speaking with them, you know, doing my job, about needs and business function, several actually hung their heads and said "It doesn't really matter, Pete. No matter what I say, he's going to do what he wants to do and tell me this is the way it has to be." When I asked why they did not go to their leadership and look for support, to a man (they really all were males) the response was "If I don't put up with this, he won't have his people do what I really need to have done."

One interesting thing was if you did not have to interact with him to get your job done, and he needed you, you were the best buddy he had. Pals for life! Until there was a change or he did not get something he wanted.

This guy was also a huge believer in bell-curves. Particularly when they were applied to people. He also loved metrics. There was never a metric he did not proclaim the great value of, then manipulate to his own ends. Flagrantly. He also knew that no one would call him on it.

Finally, I did. Publicly. In a manager meeting. With the VP present. Hell hath no fury like a bully and a liar who is called on behavior. I knew it would cost me. I did not care. In the end, I could not work in an environment like that where people were truly afraid of the consequences of speaking out. I would no longer be complacent in an environment where the cost of taking a stand on the moral high-ground was more fearsome than what the toxic environment did to the person as a person.

I landed a new position. I did not realize how the toxicity of the last one lingered on me and I made some mistakes there. Nothing huge, but enough where my outlook had been changed to be more confrontational that it needed to be. I learned from that to. That's another blog post though.

I said I learned a lot there. I did. Here's part of what I learned:

Managers may not be leaders, but they need to manage well;
Human Mistakes are learning opportunities, not something whose outcomes should be dreaded;
Intimidation only works if one is willing to be intimidated;
Sometimes in the office, just like in the schoolyard, bullies will collapse when confronted by a united opposition;
Make sure you are not the bully.

What is Wanted and What They THINK is Wanted or Why Don't They Listen?

2010-11-15T21:00:00.001-05:00

A funny thing happened the other day. The 17 year old grandson was helping my lady-wife hook up a VCR (remember those?) to a TV. Now, the story is, the lady-wife has a "studio" where she makes quilts and other fabric stuff. She wanted a TV in the studio, with a VCR so she could play some of the instructional videos for techniques she hasn't tried. Now, since she has a large collection of VHS tapes, her plan was to simply hang on to them and play them on the "old" TV with the "old" VCR hooked up.

Well, the dear grandson looked at her TV and VCR and the cables and pronounced "this will never work." It seems that she needed a converter and completely different set of cables to make the TV worked. Her response was simple, "I just want to watch some videos."

"But it won't work like this. You won't get any channels."

"I don't want to watch TV, I want to watch some videos. That's all."

"But everything is digital now. This won't work without the right antenna and cables."

"I don't want to watch anything on TV. I just want to watch some videos. That's all."

"So, you don't want to watch TV? Just watch some movies? Oh."

Now, how many times do you have conversations where the IT/Development/Lords of Software "KNOW" what the users want to do? Have you ever dealt with folks who KNOW they know the business better than the people doing the business?

Yeah, I've dealt with them, too.

I remember one Very self-Important Person who told me flat out that "We drive technology and they don't know what the technology does or why they need a new system to replace what they have." I asked "What problems are they having that we need to change their systems and all their business processes?"

I was told that I clearly did not understand what their mission was or what my role was. I was working as a Business Analyst at the time. I knew then that I clearly did not like the idea of Lords of Software running a business because the people who are supposed to run it did not understand technology.

The moral of the story? Remember who is the servant and who is served.

On Communication and Documentation

2010-11-12T22:10:00.000-05:00

East is East and West is West

And Ne'er the twain shall meet.

Kipling knew more about developing software than some people I can think of, or have worked with on occasion.

I had a conversation this week that reminded me about good ol' Rudyard's poetry. I was talking with some folks I know and they were rather muttering about how they can't get questions answered. The funny thing is I've had conversations like that before. They all go something like this:

Me: "Hey, I've have a question about HIJ function in XYZ project."
Them: "The detail design has everything in it."
Me: "OK, well, I read that and the requirements doc and I'm still not sure about something."
Them: "The detail design doc has all the infromation you need."
Me: "Well, I read that and there's a couple things I don't understand. I wonder if we can talk about them."
Then: "We don't need to talk. Everything is in the documents you have. There's no room for questions."

Really?

Dear people,

Documents should assist communication, not replace it. Communication involves more than writing, or reading, a document. Since not everyone shares the same world-view, it seems that sometimes, when someone writes something, other people read it and may not understand completely. How can that be if "Everything is in the documents?"

Maybe it should be "Everything I think you need is in the documents." I'm not sure.

It always strikes me that the point of "Communication" is something that got talked about when I was taking classes an eon or two ago. I learned that communication is a process of transferring information from one person to another. I don't recall anything about "documents."

Now, don't get me wrong. Documents are great! I've written some myself! I have read many of them written by other people. The point of it is that the information should be conveyed between people. Documents can record decisions. Documents can support conclusions. Documents can serve as memory aides.

Documents are not, in themselves, communication. Just like East is not West.

Perspectives and Guy Fawkes and Movies

2010-11-05T20:50:00.000-04:00

So, working on my computer this morning, I saw a Tweet from a well regarded tester that said:

Remember, remember the 5th of November, The Gunpowder Treason and Plot,
I know of no reason Why the Gunpowder Treason Should ever be forgot.

Being of the mindset that I am, my immediate reaction was "Guy Fawkes? She's an American, what is she on about Guy Fawkes and the Bonfire Night for?"

So I asked if she had made a Guy? (Seemed perfectly reasonable I thought.) Her response was a little, well, not at all what I expected. We were several tweets into the conversation when I realized her tweet had actually nothing at all to do with Guy Fawkes day and was based on V for Vendetta - the movie.

From that point on, both of us understood why the other had no clue what we had been talking about.

This was pretty quick, compared to when things like this happen in the office, on projects. I sometimes wonder how it is that people can fail to realize that they are using the same terms or phrases or buzz-words and talking about completely different things.
So, Movie or Historical Event or Project?

Remember, remember the Fifth of November,

The Gunpowder Treason and Plot,

I know of no reason

Why the Gunpowder Treason

Should ever be forgot.

Guy Fawkes, Guy Fawkes, t'was his intent

To blow up the King and Parli'ment.

Three-score barrels of powder below

To prove old England's overthrow;

By God's providence he was catch'd

With a dark lantern and burning match...

Conference Attendance 101 or Learning while Conferring

2010-11-05T20:41:00.002-04:00

A couple weeks ago I blogged, excitedly, about my experience speaking at the TesTrek conference hosted by QAI in Toronto the week of October 18. I think this consititutes Part 2 of that post.

When I was younger and more "fill the schedule" oriented than I am now, when I went to a conference or user group meeting or seminars or whatever, I tried really, really hard to "get the most for the money spent" by being in a track session or workshop every single minute and moving quickly from one presentation to the next. I made a point of not getting drawn into conversations because I might miss a presentation. Even if there was not a presentation that I was really interested in attending, I made a point of going anyway. I needed to get my (well, my boss' anyway) money's worth!

How foolish of me.

Several years ago, I was sent as a "technical person" to a user group meeting for a software package my empplyer had purchased, installed and was using. I was the senior programmer for supporting the integration and customizations, and since they introduced a "technical track" that year, the software company "hosts" made a big deal about sending "technical experts" to learn about what was coming and what was going on. After a series of presentations with the same people sitting within a few seats of each other with the same "you've got to be kidding" looks on their faces as I'm sure I had, a small number of us began comparing notes. We skipped the next session, grabbed some drinks from the bar in the conference center, got out our pads of paper and did out own "track."

We had a number of people with similar experiences and problems and decided that we knew as much as the sales people who could not answer a single question about the product they were supposed to be giving us "technical information." The next day and a half I had two legal pads full of notes, diagrams and a stack of business cards from the folks sitting around the table. In my memory, we had 8 or 10 people who "snuck out" and "wasted the company's money." Except that all of us had solutions to problems we encountered that the vendor had not been able to address - and each of the solutions had been implemented somewhere and actually worked.

A few years ago at a regional conference, I ran into a couple of people who shared the same "this presenter does not get it" look on their face. The fact that one of them was a speaker I had listened to the day before, and been really really impressed with his information, did reinforce that a bit. We proceeded to have a "hallway conversation" that turned into several people sitting in comfy chairs drinking tea and/or soft drinks talking about the topic for the presentation we had just been in. We compared notes and war stories and annecdotes and experiences - and everyone came away with new ideas they did not have before (and did not get from the presentation we had all attended.)

From that point, every conference I've been to, I intentionally leave holes in my schedule. Lets face it. There may not be a speaker I want to hear or a topic I "really, really want to learn something about."

So, instead, I may seek out other interesting people I've seen during the conference, or heard ask intelligent questions, who are milling about (during that period between sessions) and talk with them - ask questions, SOMETHING. Those have been really enlightening the last couple of years, and lead to some great contacts and insight that I may not have gotten elsewhere.

Now, I know that walking up to someone can be a bit intimidating. So what - do it anyway. If they are speaking at the conference, they may well be open to a good conversation. If not, they may be as equally lost about "what session to go to next..." and maybe the right one is the one that starts in the hallway with the two of you and see what happens. More may join in and it could last and hour, or 10 minutes.

Either way, share conact information - let them know how to get in touch with you and find out how to get in touch with them. Easiest way to do that? Give them your card! Now, don't be like the guys who were talking with me at TesTrek and have a rather sheepish look and say "Our company doesn't give us business cards so I don't have any..."

TOO BAD! Business cards are cheap! A simple black ink on white card ("classic look...") can be made pretty inexpensively at most big-box office supply stores, or any small printing shop can help you. All you need is your name, something to identify what you do (like, in this case "software tester" might be appropriate) email address and phone number. Your address might be nice, but not needed.

So, since folks like lists, here's my list for conference attendees to do or bring for the the conference:

Business cards - lots and lots of business cards. Even if the company doesn't give you some, get some made;
Laptop or netbook computer or smartphone - great for taking notes (or checking email if you "chose poorly") and tweeting about the good (or bad) points the speaker is making;
An open mind - You never know what you might learn and how that might relate to your interests, both personal and professional;
Did I mention business cards?
Note book / scratch pad. Yeah, I know, many conferences will give out folders or portfolios and a lot of conference centers have little note pads for jotting things down. The problem is I find those note pads too little. The portfolios may be useful for other things - like holding all the papers/CDs/DVDs you may collect;
An open schedule - Have lists of "must see", "good to see" and "want to see" sessions, but don't feel you need to have every single timeslot open;
Your favorite mints or hard candy;
Business cards (did I say that already?);

OK. In the interest of "balance," here's my list of things to NOT do or not BRING:

Work. Leave the office behind. Your boss sent you there to learn, so learn. Those people who are trying to suck you in now are the same ones who want all of your attention all the time anyway, including on weekends if they think they might get it. They'll be waiting anyway to ruin your day when you get back. You're there to learn. Learn to talk with people you don't know and learn about them. It may help you in your job.
Work email. Yeah, I know, I mentioned bringing the laptop to check email or whatever. That work email that needs attention yesterday if not sooner can't really be dealt with while your in a conference session, so leave it for a while. Come back to it later - another hour or two won't make that big a difference. (I know. I've broken this rule, but just to be the exception that proves the rule...)
Extreme self assurance in the "rightness" of your position. Put the ego in "Neuteral" and you may learn something useful.

Be modest and humble. You don't need to know all the answers. If you did, there would be no reason for you to be there, right? Be open to new ideas, particularly ones that challenge your own ideas. Listen to what the other person has to say and weigh their message carefully before deciding to file it under "ignore." You may learn something, even if it is only insight into why you disagree with a given view.

TPI Presentation Summary

2010-10-24T11:39:00.000-04:00

This post resulted from typing up the notes taken on flip-charts that I promised to type and send to the participants in the workshop I did at TesTrek in Toronto. My thanks go to all the people who were there and participated in the discussion, particularly Lynn McKee, Paul Carvalho, Michael Bolton, Michael... the other Michael who did not have business cards and whose last name I don't recall. That this session took the path it did, and that the quality of the discussion it had was due very largely, if not entirely, to you. I know I learned a great deal and I was the one with the microphone.

My notes:

Test Process Improvement:

Lessons Learned from the Trenches

Flip-chart notes from TesTrek Conference, October 2010

Points made in discussion during presentation portion:

(In looking at testing…) How do I add value? (Lynn McKee)
Something’s wrong, Customers report “issues”

What’s an issue?
Issues may not be problems to everyone (Michael Bolton)
Expectations don’t match somehow

Problem in Requirements or Scope creep?

Points made in discussion of SWOT:

Allow your team to make mistakes (Paul Carvalho)

Nothing teaches more than failure…

Understand why you are doing something…

Introduction to SWOT Analysis:

SWOT is a tool to look at your team’s Strengths and Weaknesses while being aware of external Opportunities and Threats – Things that you may be able to take advantage of and those things that may block your progress.

These items are from the ideas that were volunteered by participants.

Strengths

Technically Competent
Dedicated
Finds “Good Bugs” fast
Detail Oriented
Shows Craftsmanship / Professional Pride in work
Team Gels
Good Communication (and skills)
Understands Roles
Big Test Case Toolbox
Adaptable
Has the trust of peers and colleagues

Weaknesses

Hard to say “No”
Resistant to change
Low technical knowledge
Poor estimation skills
Staff not as good as they think they are
Lack of creativity

Summary

The conversation around these points was important and I allowed it to flow freely, believing that they bore greater value than walking through a planned exercise. It was interesting to note that the strengths were drawn out very quickly, while the weaknesses took nearly twice as long and ended with far fewer items.

This is almost exactly in line with my experiences with using this technique.

It is easy to state what a person or team is good at – what their strengths are. Getting this down to specifics from the more general terms can be a bit more challenging, but usually bears fruit. Saying out loud (admitting to yourself and your team) what the weaknesses and short comings are is far harder. We all have frames around ourselves that limit our vision. We all want to be heroes in our own minds – no one wants to be the villain. Most people want to believe they are good if not very good at what they do.

Getting your team together and discussing what the weaknesses the team has means at some point people must trust each other to help improve individual shortcomings. If your list of strengths includes something about “teamwork” and people are not able or are unwilling to be honest with each other (yes, you can be polite and honest at the same time) then the “teamwork” strength needs to be removed from the list.

The greatest single challenge is to face yourself as you are. This is compounded when attempting to do this with, and in front of, co-workers and team members. The leader/manager may need to get help in doing this very hard task, and to break down the barriers that exist to allow frank discussion to occur. Tempers may flare and nerves will certainly be on edge. The “trick” is to allow cooling-off periods. Perhaps meeting for a couple hours each day for a couple of weeks instead of reserving three or four days in a row to do nothing but this would make it easier. This will allow people to talk privately and do their own reality-checks on what happens, or should happen.

Sometimes, the most potent force in this process is to have people thinking about these topics in the back of their minds while working on their “real” work. While focusing on a challenge, don’t be surprised if something pops into your mind related to the SWOT discussions and how that revelation can bear on the next discussion session.

AND SO, in simple language:

• To improve your Test Process, you must improve your team’s testing.
• To improve your testing, you must have a solid understanding of what your team is capable of RIGHT NOW.
• To understand your team’s capability, you must understand your team’s Strengths and Weaknesses.
• If you understand the Strengths and Weaknesses, you can consider what it is that Management or Customers are expecting.
• Recognizing what Management and Customers are expecting becomes your first Opportunity.
• Recognizing Opportunity may reveal things that will block those opportunities: Threats.
• Engaging in this process with your entire team will demonstrate to your team how serious you are to improving the team and making the individuals better at what they do.
• When you make the testing itself better, the Testing Process will be improved.

Conferences and Vacations and Learning

2010-10-23T23:12:00.001-04:00

So, my lady-wife and I don't do "anniversaries" - we do "annual honeymoons." We (try to) take a week and go be sweet-hearts. With the schedule at the day-job, getting a week off this summer was "not highly likely" which meant that a day or two here and there was the best one could hope for. However, I was able to schedule a full week off for our "honeymoon." We had planned to return to Beaver Island, in Lake Michigan, where we had gone after our wedding. Then, interesting things happened.

A colleague (well, highly regarded tester and speaker on testing and test consultant) asked if I'd be interested if she put my name forward as a possible candidate to fill her spot on the schedule at TesTrek, run by QAI. I was a little surprised, well, a lot surprised, and said I'd be happy, and honored, to be considered. The only drawback was the timing - the week slated to go to Beaver Island. That could be a problem. The week we try and reserve just for us would turn into a little bit of "us time" and a lot of "conference/work" time. Positive side, it was in Toronto.

With a little concern, I approached my Lady Wife and asked what she thought. Her response was "I LOVE Toronto!" So, away we went. As things happened, I found myself in a position to prepare an abstract and submit it to the folks at QAI. It was approved, which meant getting a presentation together that consisted of more than vague ideas.

The topic was one that I suspected may be a big draw - Test Process Improvement. That is one of the "Almost 124.7% certain to be on a Conference Agenda" topics, along with Estimation, Automation and Requirements. Now, this was not the intimidating part. The intimidating part was that there were a stack of people who were going to be there who would very probably disagree with me. I don't have a problem with that. In fact, I've gotten quite good at having people disagree with me. I can even be gracious when people can explain why clearly, and with a reasoneid argument. I've been known to get along quite well with people with whom I have a professional disagreement. Mind you, some folks have a harder time with that.

The thing was, I've done lunch and learns and training sessions and presentations for teams I've been on and led and worked with. I've been doing drumming workshops for many years, in addition to the group and private lessons I've done. The thing was, these weren't novices or non-testers I'd be speaking to - they were testers and test managers and consultants and maybe famous testing people. Gulp. Some of them were bound to know the topic better than I did. Then I remembered the Abstract I worked on and the presentation I had worked so hard on. This was sharing what I had learned - not what some expert said was the "right" way to do things. And that was my starting point.

I do not have answers nor do I have a magic wand to reveal the secrets that need to be revealed. But I can talk about what I learned myself. And if some of the people who wrote the things I read and tried some of their ideas were sitting in the room - fine! My hat's off to them and I'll credit them with being the source for ideas.

Now, I had done "practice runs" with the slides and watching myself in mirrors and such - and done a dry run with volunteer co-workers. I had three possible paths planned for the exercise portion, depending on the number of people, the room layout and, frankly, how the lead up to it went. Five minutes before I was to start, I had the projector ready, a bottle of water handy, the way-cool remote clickey thing to advance the slides was hooked up - and the wireless mic was clipped to my belt. No worries.

The "Track Host" walked up to introduce me and... the next 30 seconds were a warning. The "click on" for the wireless mic didn't. The cool remote thingie... didn't. I muttered something about testing software and not hardware and dove in. The next 90 minutes flew by. I asked questions, people answered, people asked questions, I responded - then attendees responded - then all of a sudden things were cruising.

Moral of the story - If you have never tried to present on a topic, ANY topic - try it. It does not need to be at a conference where "major names" are speaking. It could be a local testing group meeting, a company lunch and learn, something. Maybe a "lightning talk" at local meeting or regional conference? It does not need to be a 60 or 90 minute presentation. But make it something, somewhere.

The fact is, you know something that may help someone else. Someone else may likely have the same kind of questions you did. If you ever wondered what you could do to improve yourself - this may be it. Do something that may help someone else and learn about yourself. It may also help you meet some really way cool people.

Oh, we had a great honeymoon, too. Toronto's a great city to visit.

Improving Test Processes, Part IV, or The TPI Secret of Secrets

2010-10-12T19:48:00.000-04:00

So far, I rambled about Improving Processes. In Part I, I wrote about how we may recognize there's a problem, but may not be sure what the problem is. In Part II, I wrote about the problem of introspection and how hard it can be to see outside ourselves and look at how we really are. In Part III, I wrote about Don Quixote and the unattainable goal of Process when the Charter and Mission are in disarray.

The simple fact is, each of these things play a part in that which makes up Test Process Improvement.

Now for the secret. TPI is not the point. TPI is not the goal.

In the end, TPI doesn't really matter except as a means to the REAL goal.

The REAL goal is this: Better Value from your Testing Effort.

The thing is, most humans don't think in a clear fashion. I know I don't think in a way that can be described as linear in any way, shape or form. That is particularly true when I'm working on a problem. If I DID I would long ago have stopped looking into something I was testing because it did not feel right, even though there was nothing on the surface to indicate there was a problem. When I have one of those feelings, I sometimes will go over what I have for notes, look at the logs from the applications (not the nicely formatted versions, but the raw logs) or poke around in the database. Sometimes its nothing. Sometimes, I sit back and think "Well, look at that. Where did that come from?" (Actually, I sometimes say that out loud.)

That is the pay-off for me as a tester. I found something with a strong likelihood of causing grief for the users/customers which will in turn cause grief for my company.

I don't know how to describe that in a linear fashion. I wish I did, I'd probably be able to make a pile of money from it and live comfortably for the rest of my life from the earnings. The fact is, its too organic - organic in the sense that Jerry Weinberg used the term the first time I encountered it in this context (Becoming a Technical Leader) not in the Chemistry organic/carbon-based context.

The Test Script (and its companion, the formal Test Process Document) is not the Test. The Test is the part that is done by the M1-A1 Human Brain. Using that most powerful tool is the key to gaining value from testing - or improving the value you are currently getting.

You can have the best Process in the World of Software. You can have the best Charter and Mission statements. You can have the best tools money can buy.

Without encouraging your people to think when they are working, and rewarding them when they do it creatively and do it well, none of those other things matter.

Improving Processes, Part III, or, Why Don Quixote's Quest May Have Ended Better Than Yours Will

2010-10-04T20:53:00.002-04:00

A few weeks ago, while looking for some other information, I stumbled across the power point slides of a conference session on Test Process Improvement that I decided was "not a good fit" for me. Yeah, I walked out... about 10 minutes into it.

The premise was "If you don't have a Process, you need one. If you don't have a Process, you have Chaos and Chaos is bad." Following the obligatory introduction, and some seven minutes of what appeared to be gratuitous assertions, I said, "Enough" and walked out.

Having a Process is not a silver bullet. Simply having a Process will not magically fix your Chaotic environment. If you are trying to impose Process on the organization wearing your "Tester" white hat or the plate mail of the Quality Paladin, good luck. Most places where I've seen Chaos rule, its because someone with a lot of scrambled eggs on their hat likes it that way. (I wonder how many metaphors I can pull into one paragraph? Better quit there.)

However, if you have a Process and no one follows it, the question should be why not? My previous blog posts (Part II and Part I of this thread) talked about how the "problem" might not be the real problem and how you need to seriously look at what you are doing before you can fix what might need fixing.

When you look long and hard and honestly at what you and your group is doing, when you find the places where what is done varies from what The Process says, you must determine why this difference exists.

I suspect that it will boil down to a matter of relevance. The official Process has no relevance to the reality of what actually is needed in those situations. If it is a one-off, then there may be something that can be tweaked. If it is a regular occurrence, then the value of The Process comes into question. If it doesn't work, why pretend it does? Why bother having it at all?

Granted, The Process may have been relevant at one time and things may have changed since it was introduced. However, nothing is permanent. Change is inevitable. Even The Process may need to be updated from time to time.

When you do, look to the Purpose your team is to fulfill. Why do you exist? What is your Charter? What is your Mission? Do you have a Mission? I'll bet you do, even if you don't know what it is.

To start, look to what Management expects. If a boss-type is telling you that the Test Process needs improvement, try talking with them. Discuss with them what they believe needs to be improved or where the gaps are. This may become the basis of the group's Charter.

The Quest that you are expected to follow.

What are they seeing as "broken" that needs to be fixed?

If the gist is "there are too many defects being found by customers" ask if there are specific examples. Anecdotal evidence can paint a compelling story, yet without specific examples, you may never be able to find hard facts Is this a hunch or are there specific examples? Are these defects, as in they should have been found in testing?

Maybe these are aspects of the application that the customers expected to behave differently than they received? If they are, why is that? How can that be? How can the expectations be so different than what you believed it would be? After all! The Design and Requirements, that you based the tests on, matched perfectly!

Let us ask Dulcinea how these things can be so different than what they appear to be?

Improving Processes, Part II

2010-10-02T19:44:00.002-04:00

O would some power the giftie gie us
to see ourselves as others see us.

- Robert Burns, To a Louse

Right. So if you need that translated, Rabbie was saying this, in English:

O would some power the gift to give us
to see ourselves as others see us.

There are a couple of things that are just hard to do for most people. One, is to change our perspective and see what others see in us. The really hard part is similar to that: to look at ourselves honestly, and see what we really are like.

Any time that self examination comes into play, most folks will avoid it as much as possible. We can tell wee little fibs and stories and justify actions by many interesting machinations. Yet when we strip those aside, what are we left with?

That is the really hard part in any form of process improvement. When we look at ourselves, as individuals or as a group, the challenge is to set aside what we wish we were doing or like to think we do, and focus on our true actions.

If our real processes and the official process don't match, we need to ask ourselves, "Why not?"

Indeed, to see ourselves as we really are, or as others see us, can be an event that we don't want to face. Without doing that, we can never improve.

Improving Processes and Other Stuff, Part 1

2010-10-01T08:20:00.003-04:00

I've been teaching a lot of pipe band drumming workshops lately. Well, "a lot" compared to the last two years anyway. They can be hard, but generally are great fun. By the time I realize how tired I am, I'm half way home - close enough where a cup of Tim Horton's coffee will get me home (yes, there are some in Michigan.)

So, this last session was a mix of absolute beginners and those that were a step or two beyond that. They all play in the same band, or aspire to anyway, and so have a common bond between them. Part of the intention of the workshop organizers is to not only teach the beginners, but teach the more advanced players how to teach.

That actually is easier than it sounds, at least with drumming. I get to present an idea, work on some exercises, see who is getting it and who isn't. If it is a physical thing, there are other exercises to try. If it is a mental thing or thought process thing, then I present the same basic idea another way - changing the context sometimes makes it easier.

This last session we were working on triplets. Cool things, those triplets. They are also bread-and-butter stuff for pipe band drumming. The kind of thing where if you don't get them, your future as a pipe band drummer is quite limited. One guy was having a bit of a hard time with them than the other students. Mind you, these students ranged in age from 8 years to the mid-30's or so. This particular fellow was doing alright, but was having an issue with getting his head around the idea of "three notes where normally there are two."

I handed out a bunch of candy/sweets to the other participants and asked this fellow to play the bit he was having a problem with. Perfect. So I asked him to do it again. Perfect. Third time was still perfect. Hmmm... it does not look like its the actual "hard bit" thats the issue. So I had him play the exercise from the beginning. Trainwreck! Had him slow things down and do it again - same thing. The second time I noticed something in what he was doing. As he got closer to the "hard part" his grip tensed up (he gripped his sticks harder) his muscles in his forearms tensed visibly - both bad things for drummers. Try as he might, the sticks simply were not going to do what he wanted them to do. When he jumped right into it, things worked fine.

If the first step to solving a problem is recognizing you have a problem, how do you know what the problem is? In this poor fellow's case, he knew he had a problem and simply could not see what it was. It wasn't the problem he thought he was having - it some something else entirely. When he stayed relaxed throughout the line of the exercise, he played it flawlessly. Problem solved. But what was the problem?

When it comes to process improvement for nearly anything, I try and apply the same approach: There may be a problem, lets see what the symptoms are and see if we can isolate the problem - instead of whacking the symptoms or results of the problem.

When looking at Test Process Improvement in particular, the problem that gets described is usually a symptom or list of symptoms - not the actual problem. We can stomp on symptoms one at a time, without really addressing the crux if the problem. That will continue to churn and bubble and fester until something else breaks.

The "problems" presented usually are presented in a handfull of ways:

Testing is taking too long;
Testing costs too much;
Too many defects are being found by customers.

Of course, there are other variations, but what I have seen have usually falls into one (or more) of those complaints.

When I was younger and not as diplomatic as I am today, my reaction to each of those points generally ran something like "Compared to what?" Now, in my more mellow state and place of being, I only think that. Sometimes loudly, but what comes out of the mouth runs something like, "Can you explain what you mean by 'too long' so I can understand better what you expect? An awful lot of the time our original estimates on test effort or duration are based on the understanding of what the project will entail at the time the estimates are made. As the project develops, we learn more and that will impact both the revised effort estimates and the actual duration. What we are doing is based on the instructions given to us and the mandates for what critical processes must be validated. Perhaps this needs to be reconsidered."

So, I guess that's a long-winded version of "Compared to what?" but it tends to go over a bit better.

What I do wonder, however, when a boss-type says something like those statements, is "Are those symptoms or problems?" Are we running over timelines and cost estimates because of other things than lousy estimates? Are "due dates" being missed because of testing? Are there a flurry of defects keeping customers from using the new release?

Is there something else going on and these are perceptions of problems, rarther than symptoms of problems?

Requirements, Traceability and El Dorado

2010-09-29T20:23:00.000-04:00

The day-job has been crazy busy the last several weeks. I have several half-written entries that I want to finish and post and with the project hours, and stuff needed to be done at home, there simply has not been much time. However, I've been lurking in a couple of places, reading posts and email conversations, getting my fix of "smart people's thoughts" that way.

The interesting thing is that a couple of themes have crept back up and I finally have the chance to take a look at the topic(s) myself and consider some aspects I may not have considered.

The initial question revolved around defining requirements and establishing traceability of test plans, test cases and the like back to requirements. By extension, when executing the test cases defects found should likewise be able to be traced back to said requirements.

Now, folks who have read my blog in the past will realize that I've been writing about requirements off an and for some time. Well, actually, its more "on" than "off." I write about requirements and testing a lot. Possibly this is because the struggles of the company I work with on defining requirements and the subsequent struggles to adequately test the software products created from those requirements. Now, to be clear, it is not simply this company I am with that has an issue. Most places I've worked have been seriously "requirements challenged."

One thing that sends up every warning flag the back of my neck has is the idea that we can fully define the requirements before doing anything else. I know, Robin Goldsmith has an interesting book on defining "REAL requirements" and he has some good ideas. In light of the shops where I have worked over the last, oh, 25 and more years, some of these ideas simply don't apply. They are not bad ideas, in fact, I think testers should read the book and get a better understanding of it. (Look here to find it, yeah, I know its pretty pricey - expense it.)

Having said that, how many times have we heard people (developers, testers, analysts of some flavor, project managers, et al.) complain that the "customers" either "don't know what they want" or "changed their requirements." I've written before about the understanding of requirements changing, and how considering one aspect of a project may inform understanding on another. When this happens in design, development, or worse testing, the automatic chorus is that the "users" don't know what they want and work will need to be changed. All of us have encountered this right? This is nothing new, presumably.

My point with this revisit is that if you are looking to find the cause of this recurring phenomenon, look in a mirror. All of us have our own biases that effect everything we do - whether we intend to or not.

So, if your shop is like some I've worked in, you get a really nice Requirements Document that formally spells out the requirements for the new system or enhancement to the existing system. The "designers" take this and work on their design. Test planners start working on planning how they will test the software and (maybe) what things they will look for when reviewing the design.

Someone, maybe a tester, maybe a developer, will notice something; maybe an inconsistency, maybe they'll just have a hunch that the pieces don't quite go together as neatly as they should. So a question will be asked. Several things may happen. In some cases, the developer will be given a vague instruction to "handle it." In some cases, there will be much back and forth over what the system "should" do, then the developer will be told to "handle it."

At one shop I worked at, the normal result was a boss type demanding why QA (me) had not found the problem earlier.

My point is, defining requirements itself is an ongoing process around which all the other functions in software development operate.

Michael Bolton recently blogged on test framing. It is an interesting read. It also falls nicely into a question raised by Rebecca Staton-Reinstein's book Conventional Wisdom around how frames and perspectives can be both limiting and liberating.

This brings me back to my unanswered question on Requirements: How do you show traceability and coverage in advance when it is 99.99% certain that you do not know all the requirements? Can it really be done or is it a fabled goal that can't be reached - like the city of gold?

Wiser people than me may know the answer.

Learning and Teaching and Leading

2010-08-30T21:06:00.000-04:00

One thing I learned early on when teaching drumming students, particularly beginners, is that the person who learns the most is often the teacher.

It never seems to matter whether the lesson is an individual or group lesson, focused on one style or general drumming - the process of teaching beginners forces the instructor to reconsider things that the instructor simply does. This forces the teacher to reconsider all that he does, find interesting foibles or potential weaknesses, then correct or change them as needed for working with the student.

The interesting thing is that this reflection sometimes leads to profound understanding of what the student is learning and what the instructor is conveying. When preparing for the odd lunch-and-learn or training session at the office I never really had that kind of an experience - or when presenting such sessions.

On Improvement...

This last couple of weeks something interesting happened. I've been preparing a presentation on Test Process Improvement for TesTrek in October. I wasn't scheduled to present, or lead a workshop, but as a couple of presenters had to cancel, Viola! I'm on the presenters list. Then, a couple of other things came into my observation.

There have been several conversations on email lists I'm a participant in, as well as forums, on the dreaded M word. Yes - Metrics.

On top of this, I had a remarkably revealing email conversation with Markus Gartner - amazingly bright guy. This came about because the questions I submitted for the "Ask the Tester" were submitted after the magic number of 10 had been reached. However, they were forwarded to Markus and that presented me the opportunity to learn and be rinded of things I once knew and had forgotten (or channelled off into a safe place in my memory.)

My question to Markus was centered on his take of "Test Process Improvement" in an Agile environment. The bulk of his response was reasonably close to what I expected - in fact, reassuringly close to what I had prepared for the presentation so my confidence level increased dramatically in what I was saying. (Yes, a little reassurance is sometimes a good thing, particularly when one is a very little fish hanging out with very big fish.)

He had one idea that I did not have. And it left me gob-smacked. Tacked onto an already interesting sentence about the organization's management, Markus said "... or they don't trust testing anymore."

On Trust...

I was immediately thrown back many years to when Developers were called Programmers and when I was working as a COBOL Programmer on a large IBM mainframe. I had a Manager who did not trust his staff. Not because they were inexperienced, but because he simply did not trust them. To this day, I do not know why that was the case. I can surmise why, but it has little to do with the point. Suffice to say, it was an un-happy work environment.

Markus made an interesting observation. His point was that in Agile, the very purpose is to engender trust amongst all participants. Additionally, when management is invited to observe the meetings, they can gain an understanding of what is being done by their staff and as their understanding increases, so to should their level of trust.

When a group or a team has lost the trust of its management, the task of regaining that trust is nigh-on insurmountable. Likewise, if a manager or lead has lost the trust of the group they are to lead or manage, the results will almost certainly be dire.

On Process...

Thus, when the call comes down for "better metrics" or "process improvement" or any other number of topics. What is the underlying message? What is it that someone is hoping to gain? Do they know? CAN they know? Are they guessing?

Much is debated around QUANTifiable and QUALifiable considerations, measurement and understanding. I am not nearly bright enough to join into that fray fully-fledged.

What I have seen, however, is when Managers, Directors, VPs, EVPs, and big-bosses of all varieties are looking for something - nearly anything will suffice. A depressing number of times, I have seen management groups flail around what is wanted - then issue and edict announcing the new policy or practice or whatever it is. These tend to roll-out like clockwork, every three to six months.

Each company where I have worked that followed that practice engendered a huge amount of cynicism, resentment and distrust. The sad thing is that these rather stodgy companies - including some that were quite small and prided themselves on having no Dilbert-esque Pointy-Haired-Boss behaviors - were wasting an amazing opportunity.

The first step to fixing a "problem" is figuring out what the problem is. If there is no understanding over why policies or procedures are changing and no feed-back loop on the purposes behind the changed, will the average rank-and-file worker stand up and say "What do you hope to change/improve/learn from this?" At some companies - maybe. But I have seen relatively few times where the combination of policy-dujour and staff willing to stick their necks out and ask questions both exist in the same organization.

On Leadership...

What I have learned, instead, is to look at all sources of information. Explain what the problem or perceived problem is. Ask for input - then consider it fairly. To do so is not a sign of weakness - it is a sign of strength. That the leadership of the organization have enough trust in their workers to approach them with a problem and work together toward a solution.

This, in my mind, is the essence of building a team.

If you throw a bunch of people together without a unifying factor and expect great things it is silly in the extreme. In the military, "Basic Training" serves this purpose - laying the groundwork to trust your comrades and follow the direction of officers and non-commissioned officers. In the end though, the object is teamwork: learning to work together using each persons strengths to off-set others weaknesses.

Why is it that so many managers miss this rather elementary point? For a team to "work" they must learn to work together. If the Lead or Manager has not built the group into one capable of working together, like a team, what, other than professional pride, will get any results at all?

Although I can not prove this, in a scientific method as it were, I suspect that it is the essence of the problem mentioned above. The question I do not know the answer to, although suspect it, is the question of leadership in this instance.

Is it that they, the leaders, have no idea how to build a team? Is it possible that the step of instructing the fledgling team and shaping it into the needed form was too challenging? Could it be that in the process of doing so, their own closely held beliefs, habits and foibles were more dear than the building of a successful team?

If this basic lack is present, does it contribute to the selection of what is easy over what is right?

These are the ideas that have been floating through my mind while preparing the presentation and workshop lessons for the session at TesTrek. If the master knows that he is but a beginner in the craft, what of those who consider themselves experts in all aspects of our trade.

Can this be at the root of the behaviours I've seen first hand and read about? Are they feeling so insecure in their own abilities that they mistrust their own staff, the team they are charged with leading? Is it to make up for this lack, they flounder and grasp for tips or magic revelations that will show them the "path?" Is that why there is a continuing and perpetual drive for Metrics and Process Improvement?

Music, or Testerman's Ramble

2010-08-29T12:43:00.000-04:00

At one point in my life I played in a band that performed a variety of Irish traditional and folk music. We also played a fair amount of Scottish traditional and folk as well, however, it seems if you play or sing a single Irish song, you are labelled "Irish" and you'll be crazy-busy in March, and pretty slow the rest of the year. Unless you work really hard and play reasonably well.

So a side-effect of playing in a band that performs this stuff is, when you get good enough for people to pay you money to go to their towns, cities, festivals, whatever, you will run into other folks who play the same type of music. When schedules permit, this often devolves into a session / sessiun / wild-music-playing party. There are certain protocols that most folks follow in these events - and the fantastic thing is that usually the level of play is quite good. Tempos are snappy so reels drive forward and hornpipes can be lilty (and tend to run around Warp 9) and jigs are of a nature where feet rarely touch the ground.

Now, these uber-sessions are not so different than more traditional ones held in houses or coffee-shops or bars or clubs. The big difference is the recognition that there are no light-weight players and everyone has mastered their craft. This is not always the case at other sessions.

I have been out of the performing trad/folk music for several years now, and in the last year began attending some of the local sessions, just to get my feet wet. I was a bit rusty on bodhran, the Irish hand frame drum, which I had played for 20 years on stage and in sessions. My limited ability on penny whistle was nigh-on vanished - I remembered tunes and could call phrases from my memory to my finger tips, but I'm effectively starting over. With crazy work and home schedule it has been hard to find time to practice , let alone become "street legal" on whistle.

So, I show up at the Sunday night sessions and play a couple of tunes on whistle when they come up. I will also play the bodhran a bit, depending on the number of people there (it does not take many drums to become "too many" for the melody instruments - whistles, mandolins, fiddles, flutes, dulcimers and the like.)

This last Sunday there were a fair number of players. There were 8 or 9 "melody" players, a couple of guitars, a tenor-banjo, who played melody when he knew the tune and vamped when he did not - and me on drum (with the occaisional contribution of bones.) Some of the players are quite experienced and I have seen around for many years. Some are between beginner and novice. Some are "in between" levels of experience.

One tune in particular would have made me stop the band, if it was a "band" that was playing and have them start again. That typically isn't done in sessions - so I did the "drummer equivalent" and simply stopped playing. One of the mandolin players, who knew me and has also been around the block gave a little smile and he stopped as well. We were treated to a rare sight of 6 people who were absolutely certain what the "correct" tempo was for the tune that was being played - and none of them would give an inch - or a click on the metronome. The guitar players seemed to play along with which ever melody instrument was close to them and generally the best description was "trainwreck."

That reminded me of a projet I had worked on some time ago. I was not on the project originally, but was brought in as part of a desperation move to fix it. Like in the tune on Sunday, each of the participants knew what the right thing to do was. The problem was none of them agreed on what that thing was. "Blood on the Green" was an apt summation of that effort. The programmers were berated for not following instructions - but how do you follow instructions when there are multiple, conflicting sets of instructions?

Because of the "political nature" of the project, no managers or directors were willing to step up and take on some form of leadership role for fear that there would be repercussions for doing so. The PM, BA and Dev Lead floundered without some form of direction from their respective management teams. Information was contradictory at best.

In the end, a Director put his foot down, asserted control and forced the issue. Me being added to the project was part of forcing the issue. Until that point, the uncertainty of the leadership was sapping the ability of the project group to operate as an effective team. Like the music session last week, no one had a clear picture as to what was "right" and where the center of gravity was.

People can urge "Best Practices," "Standards," "Process" and "Metrics" all they want. In some contexts, that may be the right thing. However, wiothout a clear understanding of the intent of the effort, nothing will save the project. Ulysses S. Grant, that prescient Software Oracle (well, American General turned President) warned that indecision was worse than a wrong decision. Wrong decisions could be countered by "right" decisions, but no decision, from leadership, leaves your group floundering looking for a center.

Of Walkways and Fountains

2010-08-10T08:11:00.001-04:00

A Story

Once upon a time there was a business person who knew exactly what she wanted. So, she explained to an analyst precisely what it was that she wanted and all of the points that she wanted addressed and precisely how she wanted it addressed. The analyst said he understood exactly what she wanted.

So, the analyst went and assembled all the requirements and looked at everything that was spelled out. He gathered everything together.

He found that he had some very usable information and some that was less than useable. So, he dug and dug and found the perfect item that would fit the needs the user described and make it pleasing to her.

Then he assembled all the components and tested the product and found that it matched exactly what the user had asked for - and everything worked perfectly. The finished product was, indeed, a thing of beauty.

So, he called the user over to see the wonderful product he had made. She looked at it and said, "What is this?"

"Its what you asked for! It has everything you wanted!"

"No, this is..."

Have you ever heard of a project that matched the requirements precisely for what was needed to be included in the "finished product" only to find there was a complete mis-understanding about what the real purpose was?

Cast Curtain Call - Part 2 - Conversations

2010-08-09T20:12:00.003-04:00

I was very fortunate this last week to have had extended conversations with several people, some "movers and shakers" and some "well respected testers" and some "regular folks." Rather than sort out which is which, I'm going to focus on some of the great conversations I had, starting Sunday evening, through Thursday.

The hard part is picking out the bestest ones. So, I'm going to summarize some and the mental meanderings that resulted.

Monday, chatting with Griffin Jones, he asked bout the mission and charter for the group I work with. We had been talking about techniques and some of the on-line forum conversations around exploratory/ad-hoc/fully-scripted testing in light of Michael Bolton's blog entry on Testers: Get Out of the QA Business. He asked about this after what I thought was a tangent that was around the question of "what works best for what kind of environment?"

His simple question got me to wondering, other than the slogan on the company's internal wiki about the QA/Testing group, what is it that we are about? For some time, we have been working toward getting more people involved in the idea of tangible requirements, of QA helping define requirements and acting as a bridge in the design process. But that begged the question - What is our mission?

I wonder how many testing groups (or whatever each group calls itself) have a "slogan" but no "mission" or "purpose" statement that can be pointed to, where everyone knows about it. If you don't know about it, is it reasonable for people to act towards that - its a goal, right? How do you achieve a goal if you don't know what it is (I feel another blog post coming on, but not right now!)

I had several brilliant little chats with Scott Barber. It helps when you're sitting next to each other at the Registration table. We talked about a bunch of stuff - For those who have read his stuff or have read his articles or postings in various online forums for that matter, he really is as smart as he seems - Holy Cow!

We got onto the "mission" of testing groups and "doing things right" vs "doing things well enough." What most theory-centric folks sometimes forget is that there is a cost to "doing things 'right.'" If the product will be shipped for 2 weeks late because you want to run a 4 week duration system load test, costing approximately $1M, what will the company gain? What are the risks? If you're extremely likely to see significant problems within the first 8 to 12 hours and the likelihood decreases over time, what will that extra two or even three weeks going to get you - other than a delay to delivery and a dissatisfied customer? That, in itself, is one reason why testers should inform and advise but not make the final go/no-go decision.

Yeah - there's another blog post on that in detail.

Other people I met included Jeff Fry, where DOES he get all that energy? Then Selenia Delesie was holding court on lightning talks in the lobby. WHOA! Crazy-smart and the nice as the day is long. Selena gave two really good presentations - unfortunately, while I read the abstract and supporting paper, there were not enough of me to get to all the presentations that I wanted to get to. I think that's a sign of a fantastic conference - too many good simultaneous presentations.

Other folks I met included Michael Hunter, the Braidy Tester - What a guy, although he's now braidless. Paul Kam from DornerWorks is another really smart guy. DornerWorks was one of the sponsors of the conference. They did a lot to make this happen.

Tuesday night the "Rebel Alliance / CASTAway Social" was a hoot. Tester games and chicken-wings and varied and sundry edibles and drinkables - Thanks to Matt Heusser for making that happen. He's another one who is just crazy-smart and really friendly. If you have not seen his TWIST podcasts, check them out.

After the social, a bunch of folks went to dinner and had a fantastic time. If I recall correctly, there were 15 or 16 of us. I scored a major triumph by having Michael Bolton sit across from me at the end of the table. What an amazing time. Melisa Bugai was sitting with us as we discussed the likely causes of why the lights on the deck of the restaurant kept going out. Yes, we tested the theory when Melissa unplugged the rope light going around the railing. They all stayed on after that. WHOO-HOO!

The conversation, as any conversation with Michael, took many twists and turns. We talked on language and literacy and music and education and mental discipline and CBC radio shows and how each touched on testing. What a mind-bendingly enjoyable night.

Wednesday I had the great pleasure of dining with Lynn Mckee and Nancy Kelln - and my boss. Best part is, the boss picked up the tab! WHEEEEEEEEEEEEE! Another night of fantastic conversation on testing and wine and great food. Did I mention we talked about testing?

There were so many other great conversations - How can I give a recap of all of them? As it is, there is much to think on.

Testing and Integration and Systems, Oh, My! (Where the programmer meets the wizard)

2010-08-08T15:12:00.001-04:00

I was asked a question by a tester in the office the other day that got me thinking on this topic. Her question was "Will we need to do any integration or system integration testing?" Mind you, with some products, that is a perfectly reasonable request. In this shop, given what we do, we're pretty much doing some aspects of that any time we're running a test. Many times, we're testing within the boundary of our charter and exercising only so far. To continue to the next step requires live connections with external companies. We have connections to emulators, but I don't consider that to be a "real" situation - simply checking for handshakes and responses.

So, I thought a bit about the possibility that I have a different understanding of "System Integration Testing." That led me to that all-knowing repository of knowledge, Wikipedia, and found this:
System Integration Testing (SIT) is a testing process that exercises a software system's coexistence with others. System integration testing takes multiple integrated systems that have passed system testing as input and tests their required interactions. Following this process, the deliverable systems are passed on to acceptance testing.

Hmmmm. Well, I don't know if I'd buy that in total for our situation, or for most situations where I've worked.

So, I said, HEY! She has Foundation Level Certification from ISTQB.

ISTQB Glossary says:
System Integration Testing: Testing the integration of systems and packages; testing interfaces to external organizations.

Striking me a bit as "A painter is one who paints" I went looking at the individual terms. So:

Test: A set of one or more test cases. (taken from IEEE 829)

Testing: The process consisting of all lifecycle activities, both static and dynamic, concerned with planning, preparation and evaluation of software products and related work products to determine that they satisfy specified requirements, to demonstrate that they are fit for purpose and to detect defects.

Integration Testing: Testing performed to expose defects in the interfaces and in the interactions between integrated components or systems.

System: A collection of components organized to accomplish a specific function or set of functions. [IEEE 610]

System Testing: The process of testing an integrated system to verify that it meets specified requirements. [from W. Hetzel (1988), The complete guide to software testing – 2nd edition, QED Information Sciences, ISBN 0-89435-242-3.]

This made me think of the very first time I encountered "integration testing" when I was testing something I had not programmed.

Some folks remember the days when programmers talked to business users/clients and met with them to discuss what they needed, then worked on the design for the solution, then talked with the client again about the design and checked with the client and verified what we had worked on with them. We worked up sample reports and screen shots and went over them again. Talk about time-consuming, no?

So here I was a reasonably senior programmer being pulled into a project that was over a year late and had to be delivered - postively had to be delivered - in 2 months. The first task I was given was to "simply validate" a series of batch jobs (remember JCL on IBM mainframes?) and confirm that all the components together worked correctly and finished within the required timeframe, nightly.

No problem, I thought. Gathered what I needed to learn the systems it touched, met with the more senior programmers who wrote the programs and the JCL and what not, made sure I knew the exact sequences and limitations that they knew of. I set up a test run on a weekend. The idea was to take over the entire test system - a clone of the production system - fire the process up, monitor the logs while it ran then check the summary reports. If they all looked correct, run some SQL scripts to validate the DB was correct.

Only problem was, after 18 hours running, draining the system of all available resources, the first step had not completed. That, constitutes a problem in any book.

I worked all the next day on identifying the cause, literally. When the team walked into the main conference room Monday morning, I had the entire data flow for the system the wall - all the way around the room. Bottlenecks were circled in red, pages from DB schemas were taped to the wall, and a first draft of a solution was scribbled on data flow diagrams were on the table at my "usual" seat.

That version, after rebuilding the various PROCs that were needed (ummm, execution sequence for those who don't remember when green-bar ruled the computer world) the second version was tested the next weekend. This one took only 4 hours to run to completion. Better, but well outside the target window of 2 to 3 hours.

Next idea? Pull in a couple of other mainframe jockeys for ideas, grab a senior DBA and say "I need a process that will run in a variable number of initiators, up to at least 5 and ideally up to 7." They said, "Can we do that? Not sure, but it might be fun to try." And we did. It worked. It ran in 45 minutes.

What I learned then was that nothing "worked" until you had proven that all the parts worked in concert with all the other parts or components or systems it needed to work with, in the timeframe it needed to work.

I also learned something else that day. Testing rocks. From that point, I studied all I could, even though I was a "programmer." After changing jobs, I found myslef in a position to branch out beyond what was then my "career" and learn various flavours of Unix, languages that did not exist when I went to college. Then, there was a reorganization at the company I worked for.

Part of it was rolling out a previously non-existant group. From scratch. I took the chance and have not looked back. Without running those integration tests, I am not sure I would have chosen this path.