Janus Part 1: Looking Back 2011

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

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

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

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?

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:

1. Interactive Workshops (140 minutes);
2. Regular Track Sessions (70 minutes with at least 25 minutes for discussion);
3. 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

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.