Tuesday, May 12, 2015

CAST 2015: Pre-Conference Tutorials

When I look at conference programs, one thing I always look at are the "extras" - the things that are not part of the conference proper, but the add-ons that bring specific, useful ideas I can bring back to the office the next week and apply THEN.

When I look at those items, I look at a couple of main tests:
1. No deep thought is needed to answer "How do I apply this at my company?"
2. No fretting over "This stuff sounds great but the boss will never go for it."

If there are sessions that meet those tests, I'm willing to pay out extra money to attend. Plain and simple. Sometimes, it is the technique I am looking to learn and apply better. Sometimes, it is the consideration and thought provoking ideas I need to weigh - and other people's insight on that or related topics are appreciated.

When looking at the extra-cost "Specials" this year's CAST, the Conference of the Association for Software Testing, I looked for sessions that had something to offer that I, as an attendee, would be willing to pay my money to go learn.

I think the four we have lined up this year meet those simple tests - and offer significant insight to how software professionals at the top of their craft do their work, and their lessons can be applied specifically to testers.

Mobile App Coverage Using Mind Maps. 

Dhanasekar Subramaniam is offering what looks to be an interesting session on Mobile Testing, and using Mind Maps to help guide coverage. I met Dhanasekar in passing at CAST last year. He seemed very intelligent and had some very good ideas. Alas, my schedule last year was far too hectic to permit more than a simple chat. However, the session he presented got rave reviews from people I respect. Want to know more about him? Check out his "About this blog" page which explains a fair amount about his thought processes and ideas.

There are a lot of people who tell people how and what to do when testing Mobile Apps. In looking at this session, what strikes me is that it is based on real experience, with lessons learned and applied successfully. The core of the issue in many instances, is people have ideas that they have not examined deeply, not explored adequately. This session contains much that can be applied to people considering testing Mobile apps.

Frankly, I expect people who are interested in test coverage in general would get good ideas from this session.

Speaking Truth to Power.

Fiona Charles is reprising this session she did at CAST 2010, with a new twist and ideas. I'm intrigued by the idea that most of the time, testers who are truly experimenting and testing software will find information that is of great value to the team. Sometimes the information found is not the type that managers or "key players" want to hear. No one likes it when their pet project goes pear-shaped, do they?

Fiona does a deep dive on how we can deliver the difficult (perhaps, unpopular) messages we sometimes need to deliver.

Why Fiona? I find her to have information people can act on, or think deeply on and then act on. People tend to seek out those they agree with, all the time, maybe to reaffirm their biases? I'm not sure if that is wise. Fiona has the ability to question the presumptions and statements people make, either gently or directly, and drive to a crucial point. I find Fiona to be someone I learn something from even when we disagree.

Follow Your Nose Testing.

Christin Weidemann is presenting what looks to be an interesting take on testing. Not writing scripts or test plans or making bar charts to show progress, but testing. She is looking into "overturning convention" and considering the reinvention of testing practices.

The challenge I see so many people have with testing is they get wrapped in the rituals around it they forget that one major portion of testing is curiosity. So many forget the most important question I can think of in testing - "What happens?" Christin seems to be looking at how to focus on that very question.

I met Christin at CAST 2011 in Seattle. We were both in Michael Bolton's tutorial on mind mapping. Our paths have rarely crossed since, but she struck me as an intelligent, thoughtful tester.

Testing Fundamentals for Experienced Testers

Robert Sabourin looks at what it is to reinvent and develop yourself, even with years of experience.  Rob looks at how we can transfer skills from one environment or system to another. Simply put, fundamentals.

He challenges concepts others take for granted by looking at the characteristics, the areas of those fundamentals.

I met Rob in person a couple of years ago. I found the conversations with him to be interesting and intriguing. Like conversations with Fiona, I always learned something from them. 

These are merely the start of this year's CAST. Technically, they are not part of the conference itself. CAST contains many sessions. Some folks might find greater value in some sessions than in others. That is often the way at conferences, I guess.

There is a wide selection of track sessions and workshops that look at a variety of topics around testing and leadership and personal development. Check out the program here.

Early Bird Registration ends on June 5.  You can find information on Pricing and Registration here and information on the host hotel and venue here

I look forward to seeing you in Grand Rapids this August.

Sunday, May 10, 2015

CAST 2015: For Managers

I have been working with a group of people preparing for the 10th annual CAST - the Conference of the Association for Software Testing - in Grand Rapids, Michigan this coming August. 

The program was announced recently here.

We had over 100 submissions to work though and very few spots to fill which made deciding what proposals NOT to select far more difficult than which proposals TO accept.  After some discussion and back and forth exchanges, we pulled together what I think is a solid program

While we don't do formal "tracks" as some conferences do, today, I am looking at the sessions I believe to be of particular attention to Managers.

Josh Meier is presenting an interesting take on Culture of Quality. He'll be looking at the "Quality is everyone's responsibility" meme that gets cited so often by so many people. What makes this look interesting is that Josh is speaking from experience, as opposed to theory so many cite.

Ken De Souza is presenting a session on Feedback. Many people, including managers, struggle to give (and receive) meaningful feedback at any point in their career. While this is a challenge for people in supervisory or coaching/mentoring positions, Testers are giving feed back to other people, even though it is not often recognized as such, as in bug reports. 

Jeff Woodard is presenting a slightly different take on Feedback. In this case, Jeff is discussing how to use feedback to get to a fact-based evaluation and determining what is real, or not, for a team. 

Megan Studzenski is presenting a session on Training and Developing testers. This is something that is challenging for many organizations - getting people to be able to contribute in a meaningful way as quickly as possible even when they have little or no testing experience.   

Joseph Ours is presenting a session that I think managers in particular might find useful on Metrics.  He'll discuss the purpose of measurement tools and how to leverage measures and metrics effectively. 

Rob Bowyer has a session on Hiring. Simply put, hiring good testers is hard. Getting hired as a tester can likewise, be hard. This looks to be an informative session for managers and anyone else who has struggled with interviews for testing positions.

Right. There are many more sessions. Some folks might find greater value in some sessions than in others. That is often the way at conferences, I guess. These are the ones that, looking at the selected sessions, look like they'll have ideas specifically applicable for Managers.

Early Bird Registration ends on June 5.  You can find information on Pricing and Registration here and information on the host hotel and venue here

I look forward to seeing you in Grand Rapids this August.

Sunday, April 26, 2015

Community & Conferencing & CAST 2015, part 1

Let us begin with the definition of "community" in the Oxford Dictionary.

Community: com·mu·ni·ty /kəˈmyo͞onədē/ noun
1. a group of people living in the same place or having a particular characteristic in common;
2. a feeling of fellowship with others, as a result of sharing common attitudes, interests, and goals;

There are many, many people who talk about community in one form or other. When they talk about a community of testers, I tilt my head a bit and listen (or read) perhaps a bit more carefully than I do other times. I suspect it is because I am curious about what they mean and how they intend to use the phrase.

I admit that sometimes, particularly when it is someone with whom I have fundamental disagreement in areas of testing, I listen because I am suspicious of their motives. That may be a failing on my part. Or, it may be that I tend to think carefully and critically about certain things.  Among those things are words and how they are used.

My education included teachers from Catholic Religious Orders, Dominican, Franciscan and one Jesuit. Thinking carefully and how words get used was a hallmark of my education. Perhaps that is why when the first time I read There are good practices in context, but there are no best practices." my reaction was something of "Of course. Why is this revolutionary to some people?"

It seems that idea, perhaps more than any other single idea, is rather off-putting to some people. I understand the retort that such terms as "best practices" are misleading and lazy and disingenuous. I also understand the charges that people are selling snake oil as solutions to testing problems without actually understanding what those testing problems are.

I've written before about the idea of "best practices" and shall not repeat my argument here.

When I first read that idea, which is one of the Principles of the Context-Driven School of testing, it seemed I found a group of people with whom I join in that part of a community of testers. For some time, I have been working closer and closer with people. Some of them I agree with. Some I disagree with. The vast majority of them, I respect greatly.
In 2010 I went to my first CAST conference.  I found a large number of people who had inquisitive minds who were willing to talk and debate and discuss well into the early hours.

Every CAST I have attended and participated in since have born that out.

The fact is, some people do not like having their ideas challenged. Others thrive on it. Some people look at direct questions as an attack, sometimes personal ones intended for them them. (I expect that happens when people wrap so much of their own self identity with their work and ideas.) Some folks look at it as an opportunity to better understand something.

Some people, when their ideas are challenged, crumple up in a ball. Others attack the challenger. Others attack the right of the challenger to have a contrary opinion and voice them - IN PUBLIC.

If you have never attended or participated in CAST before. This might be a good opportunity to find out what it can be like hanging out with thinking people who are not willing to take everything, or anything, said from a podium at face value. A significant portion of each session - including keynotes - is dedicated to "open season" - where people in the audience can ask questions in a moderated, facilitated format.

I've been working with some really talented and dedicated people on this year's CAST. I think it will be worth your while to check it out. You can see more information on the conference here. There is a link to register from the same page.

The schedule is being announced later this week. It is going to be good, if I do say so myself.

Monday, March 23, 2015

On Spring, Gardening, Apple Pie and Defocusing

Too Much Fun

I've had an absolutely crazy couple of weeks. Way too much to do in too short of a period of time. Along with that, there has been too many things that are "absolutely top priority."  You know how that is - where there is a stack of "absolutely can not wait items."

Not just work stuff - but life stuff.  Home and family stuff that needs to be addressed. People who need help with something. All of this is important, right? All of it takes energy.

In the mean time, there is stuff that seems, well, maybe too big to handle on your own? Problems that don't seem to have a solution?

Maybe you never had that issue. Maybe you never had a problem like that.


Ah well - Winter seems to be gone, in my neighborhood anyway. Most of the snow has melted. There are some very large piles of snow that are hanging around - and even they are a shadow of what they were a month or so ago.

It has been warm all week. Now, "warm" is relative. I do live in Michigan. (Today we reached the scorching high temperature of 48F/8C.)

The result is, I could spend time working in the garden on Saturday. Gardening is a wonderful thing. No, really. Saturday, I cleaned up the last of the Christmas decorations that were in the front garden.

Well, these were fake poinsettias set in garden pots in the front yard, that had, around Christmas time, small, lighted trees on them. There was 1 one each side of the front steps. The small, lighted trees and the garland came down some time ago. I also took down the red led "mini-lights" that were on the weeping cherry tree in the front garden.

The lights are kind of fun. The last several years we've wrapped lights up the stem and onto branches of the tree. When they are lighted at night, the tree looks like a red palm tree.  Oh. We also wrap green lights around the tree. The green lights go on the tree first, then the red lights.

The red lights are turned on just before Christmas. They stay on until after Valentine's Day. My habit is to unplug the red lights and turn on the green lights on March 1 - St. David's Day. They stay on until sometime after St. Patrick's Day.

They need to come down shortly after that most years, because as the weather warms, the flowers in the garden begin awakening and the weeping cherry begins to bud out.  We need to get the lights off the tree before that gets going full steam. So, the red lights came down Saturday. I left the green lights on for now. They may come down tomorrow.


After putting the lights and fake flowers away, I got out the rake and gently raked around the plants in the front garden. The daffodils and other flowers beginning to poke out, if not blooming, were exposed from their layer of leaves that covered the garden all winter.

Scooping up those leaves is a very satisfying thing. Really. They are bagged up and the plants were exposed - and, to be perfectly frank. The garden looks really nice after this - in an early spring sort of way.

Working in the garden this time of year gives a certain level of satisfaction that may not be there at other times. The ground, as it awakens from its winter sleep, has a healthy scent of strength, growth and new life.

Clearing away the collected leaves and various bits of... stuff, that settled over the winter reveals new growth and a promise of beauty in a matter of weeks. Mind you, there is a certain beauty of the garden as it is.

It no longer looks as a wild, abandoned place. Instead, it looks like a place where the growing things can be seen for what they are and the promise that they have for beauty later in the year.

It is funny how satisfying a few minutes work can be. Obvious results and a sense of completion that often is missing in software. Sure. We can say we "finished" a project, but mostly we see evidence around that "finish."  We don't actually see the results.

Seeing results is pretty cool. That is why I like gardening.

Another reason is, you can do it and completely relax your mind.  There is no reason whatsoever to engage in deep thoughts on what is to be done or how - you just do it. And it is done. And it is a pleasure to look at.

Apple Pie

It is an excellent way to get something tangible done and free the mind. The thing is, sometimes the best thing you can do when you have a pile of work that "must get done," is to work on something unrelated. It helps clear the brain and rest the mind - even while working on something else.

Do you remember Men In Black? The movies with Will Smith and Tommy Lee Jones playing Agents in an unnamed, extra-governmental agency dealing with aliens? The third movie in the collection featured Will Smith going back in time to help a young Tommy Lee Jones deal with an evil alien before he can kill Tommy Lee Jones?

At one point, they wander into a diner for pie - well, because grand-daddy talked about the power of pie. Some debate, hemming and hawing - and -

Apple pie - with a slice of cheese on it.

And Will Smith's character goes off on how he always orders that and... the light goes on. The odd comment made earlier suddenly makes sense.

And there is a classic example of the point - Defocusing.

Stepping away from the problem at hand to work on something else. The mind is freed from what it has been mired in. While working on another problem, the solution sometimes (often) presents itself.

Why? In my case, it is because I let go and worked on something "mindless." This activity allows me to let off steam and mentally relax and let go.

This gives me two results.

One, a task I need to do gets done (like, work in the garden).
Two, in the midst of raking and pulling and cleaning, I find the answer I had been struggling to find while I was "working" on it.

I don't know if it will work work for everyone. I  just know it works for me - and a lot of people I know.

Saturday, March 21, 2015

On Needs, Wants and Being Told What to Do

Brace yourself. 

This is a bit of a rant.

For most of my 30+ years in software development, many of them have been working with companies where software is made to support their primary business. It might be Insurance or Manufacturing or Sales or Distribution & Transportation - but many of these companies, the people using the software don't pay for it. They really don't have an option. To do their jobs, they need to use whatever stuff they get from IT.

If this does not describe the type of organization you are working in, you might want to skip this. Of course, if you have worked in an organization like this, or might possibly work in an organization like this, or perhaps you're curious what has me so worked up - please read on. Thanks.

Sometimes IT people annoy me. Of course, sometimes Internal Business folks annoy me, too.

How often have we heard or heard about IT/software development folks, telling people in business units what they need from the software to do their jobs?  After all - the IT folks know what the computer systems do and can do and so they are the experts.


The accounting and finance courses I had in school, longer ago than I want to admit, while it helped me work through and understand journal entries and balance sheets and other basic finance and accountancy stuff - These do not give me enough understanding to tell the Chief Financial Officer or Company Treasurer or whatever, what they need from the software their staff uses in order to make good, informed decisions.

I can, however, discuss with them the intent they have for using new or changed software. I can discuss the gain they hope to achieve from said software. I can listen and take into consideration what their desire for the end product should look like.

When I am working on making software do something, I can do something else to help the people who need this for their jobs.

I will do my level best to make software and work with the team making the software, that fills the needs and purpose described and discussed.

When possible, I will do my level best to have it work as they wanted.

However - that is not a promise.

Instead, I will do my best to fill their need first.

I've learned that IT people see their "wants" as "needs" (rather like the "business" folks they make software for.)  Cool features or functionality are cool. They are pleasing to design and implement. Do the help the people they are intended to help? Sometimes, sure. Of course. Other times? I've seen too much time and effort put into something that business functional experts truly do not care about.

And what of the "Business" experts? 

The people who use the software every day to do their jobs. The people who make use of the results of that work, every day, to do their jobs. The "decision makers"  looking at reports or summaries or dashboards produced and built by IT - What about them?

Do these people understand the business rules the software is intended to follow? Do they understand what the software is intended to do and why? Do they understand the purpose of what it does now and what the change will be?

Do they understand or know this without asking IT folks for help?

When they do, can the IT folks help them without looking at the code?

Have people abdicated their responsibility and put others in place as their proxies?

Now, if these things sound familiar in your organization, is it any surprise that your software has problems?

None of us really like it when people with no clue what we need tell us what we should do next.

Do the people who are supposed to:
  • Understand the purpose behind the changes;
  • Understand the business rules that to be followed;
  • Understand the why behind these things;
Who is to blame for IT telling people what the changes will be and what the software will do?

Someone has to decide what it will do. I suggest it be someone who knows what the purpose and needs are.

Sunday, March 15, 2015

On Tradition, Tribal Knowledge and "Everyone Knows..."

Interesting story I heard on NPR a couple of years ago. (Oh, for those not in the US, NPR is a privately and publicly funded non-profit organization that serves as a national syndicator for some 900 public radio stations in the U.S., often associated with universities or other forms of learning.)  The story was around Holiday Traditions.

While the gist was the Winter holidays, Christmas, Hanukkuh, New Year's, etc., they talked about other Holidays as well. The guests being interviewed mentioned how family "traditions" are really, on average, a generation old. People associate doing something for a given Holiday if their family, when they were children, did that thing for the same Holiday. In turn, their children will associate doing what ever their family does for Holidays as "Traditional."

Whilst I was still actively competing in pipe bands and teaching workshops for drumming in pipe bands, I remember a panel discussion with a group of pipers and drummers from the US, Canada, Ireland and Scotland. We were talking about styles of drumming and interpreting music.

We got pulled in two significant directions, both of which I found fascinating and I wish I could have been in a place to take notes. We talked on how things can influence our interpretation of music and how we approach music. We talked about how jazz had influenced great drummers in the pipe band world from the 1940's and 50's. We talked about how emigration from Ireland and Scotland had brought musicians to the US and Canada and how they had taught people what they had learned.

The result was many people and pipe bands in the US and Canada tended to inherit an understanding that was, at best, behind the curve of leaders in the world of pipe band were by the 1960's and 70's. The Legion and Community pipe bands in North America tended to get taught "this is how we did it in..." one of the regiments in the British Army.

This got latched on to as "traditional."  The people they taught said the same thing to others they in turn taught.

I remember teaching a band that intended to begin competing some basic technique for bass and tenor drumming. There was a fair amount of resistance because I was teaching them stuff that was "wrong." Their argument was "This is how the British Army does it." I asked which regiment - then pulled out video tapes of the Edinburgh Tattoo, massed Pipes and Drums of the Scottish Division beating retreat and the Scots Guards Trooping the Colours. None of the tenor drummers did anything remotely similar to what they were doing.

Tradition had shifted. Memories had failed as the knowledge was passed on.

Working with some testers a while back there was a problem. The parameters used to run the job they needed run to verify some changes made way up-stream in the process did not seem to be working.

I asked them what they were seeing.  They were pretty confused. The people who had worked on this same set of parameters had given them instructions around what to do.  Essentially, they needed to change the date in the command line and "that is all."

Except it wasn't "all."

The job, the one that had not changed at all, was failing on a bad parameter. It wasn't running "correctly," it simply wasn't running. Nothing was being processed. The people who had run it the last couple of times were looking at it. They were asking the people who had run it before them. They were looking at the notes and instructions.

They looked to see if "something had changed" that would prevent it from running. They looked at the configuration. The "unhelpful" error message gave them no information or guidance. Then, after several days of fits and starts, a light went on.

"Look. This says {blah blah blah} and has a period inside the quotes. What if we add a period?"


The combination of "everyone knows how to do this" and half-remembered meaning and importance of one thong effectively slowed work on this by several calendar days. Instead of sailing through as most people expected, we got hung up on people trusting to half remembered information because the entire team, except for the folks doing this the first time, knew exactly what needed to be done. The entire team knew that "all you had to do was..."

The entire team knew about the documentation. They knew the intent. They knew the "tradition."

They did not remember why.

Ya want an example of this, "tribal knowledge" in a "fun" vein? Go watch "The Lone Ranger" - the one with Johnny Depp as Tonto. All the weird stuff Tonto is telling the Ranger. All the stuff that makes people, including the Ranger, go "huh? what?"

Then, as the Ranger is sitting with the Comanche Elders and says something Tonto had told him. They look at each other and ask "Who told you this?"

The "tribal knowledge" the Ranger got from Tonto was ... accurate only for Tonto's interpretation and world view. No one else had that vision or interpretation. To everyone one else, it was not merely wrong.  It was nonsense.

When you are sharing tribal knowledge with other people, how certain are you that you are sharing it accurately? How certain are you that the "why" is being understood?

Is the information you are sharing with other people on testing knowledge, wrong or nonsense?

Saturday, March 7, 2015

What My Dogs Taught Me about Permanence

People who know me, or have seen some of my presentations on testing in an Agile environment, have seen pictures of the cats who live in the house with my me and my dear lady-wife.  People who know me, or my lady-wife, a bit better know that we prefer dogs. The cats started to move in a couple of years after our last dog, Rosie, went to Rottweiler-Heaven.

Rosie was a wonderful critter and companion. She would mind the grandkids when they were sleeping. If there was high tension or a chance of what seemed to be violence, she would walk in between the people involved and nudge them away from each other until things calmed down. She weighed 100 pounds and had the strength to move most people, even if they don't really want to move. Slapping was not permitted when she was around.

Anyway. Rosie was a rescue. She came to us when she was not quite two years old. We suspect that part of the "issue" was that this cute little ball of puppy fun turned into a very VERY large dog in short order. The problem was, she was still mostly puppy.  Translated - there was a lot of work to do with her, so she would behave in ways that were acceptable, even when we were not home.

We spent a lot of time working with her, training her to act in certain ways. Like, staying out of the garden, both vegetables and flowers. And staying off the furniture. It took a bit to convince her that simply because food, like vegetables draining in a colander, about to go on the dinner table, was NOT fair game, even if she could reach it easily.

There was the time we came home from a Christmas Party and found that the plates of cookies and bars and treats on the dining table had been disturbed, slightly. Looking around, we realized one plate was missing - a paper plate full of cookies my sister had made. These were cookies my paternal grandmother used to make, only for Christmas. Wonderful stuff.

They also smelled differently than any of the other cookies and treats that were set out, waiting for our grandkids to come over that evening.

We found Rosie, and the plate... and the plastic-wrap covering, in the crate she used as a dog-bed (it really was a dog crate for big dogs. her blankets and toys were in there. It was her safe haven - her "lair." So, here was the plastic wrap in front of the crate. The paper plate was in the crate -

Crumbs were everywhere. Apparently, she really enjoyed those cookies. Ah well.

As I was saying, it took a while to train her and get her so she'd be able to please as much as she wanted to.

By the time she was 8 or 9 or so, she knew the boundaries of the yard where she could go, and not. She knew what games were allowed - the type of play - and what were not. We could "call" her by simply whispering her name. Where ever she was, she came at a trot. If we called twice - she ran to us.

We could look at her and she knew what was going on - she'd go stand by her leash to go for a walk. Or, she'd go to the back door so she could go outside with us. 

She never did like rain. One time, about this time, we had several days of rain - never seemed to stop. She disliked rain enough where she would not go outside to "do her business" because of it. As we were into the second day of rain, and she had still not gone to "do her business" - I got a large umbrella and took her outside.

She was wary of the idea of being outside when it was raining - then she realized that I was outside - AND NOT GETTING WET!  HOW COOL WAS THAT!?!? So, she went out, I held the umbrella over her - and she was much happier after that.

Rottweilers are not long-lived animals. About the time she turned 9, her hips began to hurt. She could not play in the same way she always liked to. We put rubber-backed rugs around for her to lie down on and be comfortable (the house has hardwood floors, no carpeting in most of the rooms.) We gave her different food, food for "old, senior dogs." We found some supplements to give her that helped with her joint pain.

When the grandkids came over, she played like she was 3 again. But then she spent the next several days hurting as a result. We changed her "lair" - checked with the vet and put in a heating pad for cold nights, under her blanket of course.

By the time she was 10 or so, she could walk into the room and look at us and tilt her head in a given way and let us know what she wanted. She rarely barked. We took her on shorter walks. Her muzzle was all white now, not the black it was when she was young.

When she was 11, she quickly went downhill. Slower. She had a hard time getting up and down steps. Then she developed a large lump. Quickly.

We took her to the vet to be tested, but we knew what was going on. She always liked going to the Vet. She always like "going bye-bye in the car." So, he took a sample from the lump and sent it off to a lab. Before we had an answer we knew it was time for her to go on.  That last trip to the vet she had a really hard time getting into the van. She whimpered for the first time as we helped her in.

When we got there, she looked up and got out (getting down was easier than up.)  We walked in and she nuzzled us, leaned against us, as she always did. We went in with her as she drifted off to sleep that last time. We got home and hung up her collar and leash, put her food and water dishes in the sink to be washed and put away.

We sat down in the living room feeling very sad.  My lady-wife said "The problem with dogs is, once they are perfect for the family and perfectly trained, you need to start getting ready to say good-bye. Because they don't live nearly as long as we do. Just as they get to be perfectly trained, it is time for them to go away and leave us."

Last July, I started a new phase in my adventure in testing.

I went to work for a company that was looking for someone to help improve their testing. They were looking for an experienced person who could guide and coach them in how they could do testing better.

In the interview process, the people I met seemed to "get it." They knew they needed help. They knew the company needed help. They knew they did not have the experience or understanding of testing to get beyond very simple, basic ideas. 

One of the had the title "Quality Architect" - meaning he was not a tester. He never claimed to be. He, like I am, is a member of ASQ - the American Society for Quality. He was a process hound - but not a model hound.  The idea of "best practices" in software was "not a best practice" in his description. There are good ideas, but none of them work all the time.

One was a Manager of Application Services. He had a bunch of diverse groups reporting to him. I was struck that this was a bit like the "Island of Misfit Toys." People with skills that were needed by the organization but did not fit in with a single project development team - or in a tool specific team.

We talked. There was common ground we could work on. There were some differences in views, mostly related to experiences. 

I took the gig. It has been a lot of work. (Maybe you noticed how my blog has been less active lately?) It has been good though. My immediate team has been willing to embrace some new ideas and carry them out into the broader community. The Manager has embraced ideas that he initially found challenging - and in talking about them and working through what they could look like at this company, he became a champion to other Managers and Directors.

We built a good working relationship. Quickly. He even came to the local tester meetup on a fairly regular basis.

During the interview process, in the "describe the company and your experiences" discussion, he said he had been there for ... a long time. His role had changed. He had taken on greater responsibilities and challenges. Then he said "The only way I can see myself leaving here is if {Large International Organization Not Known for Software} had an opening I could fill."

That company did. He applied - interviewed - accepted the position.

Just as he was "perfectly trained" - he left. Friday, yesterday, was his last day at the company.

He "moved on." Of course, this was for a new job opportunity and not a "moved on" like Rosie did (or Hilde-beast before her... or Honz before her...) Still he's going on an adventure. Relocation - New City - New State - New Company.

Good luck Brian - Enjoy the new adventure!

I still think my tweet yesterday applies...
"Didja ever notice that Managers are a bit like dogs -
get them perfectly trained & it is time for them to go away?"