The last few weeks I have had the honour of being an assistant instructor for the current Foundations course in the AST's Black Box Software Testing (BBST) course.
Going in, I was a little nervous. Partly, I think, because I had agreed to be a "contingency instructor" for the course. That is, should one of the other instructors not be able to, well, instruct, I'd step in. Well, that happened. On top of that, the day-job is going nuts and I'm way behind on other writing (which is why I'm taking a minute to write a quick blog entry - don't tell anyone.)
Oh, I have presentations and a paper to prepare and.. well, never mind.
Some 20+ students dove in, and the instructors dove in with them. And the fun began. Really.
Exercises and reading and lectures and learning and group exercises and... thinking. Lots of thinking. And learning. When I took the course it was like trying to take a drink from a fire hydrant. Massive amounts of information and ideas and, well, huge learning.
You know what I've learned as an instructor? Lots. Huge learning. Massive amounts. I half expected this from teaching drumming and drumming workshops, but, whoa.
So, we are about to start the final lesson, then the exam. hooo-boy.
What have I learned most? If you want to really learn something, try explaining it to someone else.
Wednesday, March 21, 2012
Wednesday, March 14, 2012
So Much Older Then, Or, What Was Old Is New Now
Not so long ago, a significant portion of persons of a certain gender and a certain age range (at least in the US) were completely taken up, head-over-heels, gaga-over or enthralled by a series of novels about, yes, vampires.
Yes, the un-dead, feasting on the mortals around them. Living on the fringe of society, moving in and out with grace and ensnaring people with their obvious charms.
Yup. Interview With a Vampire was a really popular book and movie franchise.
Wait.
You thought I meant the Twilight series? Really? My oldest granddaughter (a pre- and early teen when the Twilight books first came out) certainly was enthralled by them. My lady-wife? nah. Me? right. Do I LOOK like someone who would be enthralled by them? Not likely.
Yet, the lady-wife made an observation one night as we were sitting sipping a glass of wine, and watching the 1979 film Dracula. She said "I think every time a new vampire novel or movie comes out, people who have not read or seen the earlier ones latch onto it as if this was the first time anything like that was written."
I've had some conversations with testers and other software folk recently that have convinced me that the lady-wife's view can apply to software development as much as, well, vampire novels and movies.
Part of this is time and age - Some folks of a certain age have seen the same set of ideas come around two or three times. Slap a new label on it and standard fare from my first programming gig in the early 1980's is all shiny and new. Just a new buzzword. In the meantime, there was another buzz-word label for it maybe 10 or 15 years ago.
I've seen a fair number of "hot trends" in software design and development come and go and come back and go and... heh - kind of like vampires I guess. They just WON'T STAY IN THEIR GRAVE!
Maybe that is because the underlying problem they were meant to solve was not solved. The hot trend that replaced them that was absolutely going to solve the problem, did not solve the problem either.
I think back to how eager I was - how ready to change the software world I was - and how I tried to convince the older, kinda-stodgy folks I worked with that I had this bright and shiny new way of doing things. One of them would sit back and tell a story from 15 years before. I'd wonder what THAT had to do with Real MODERN software design and development - I mean, punch cards? Might as well be stone tablets, right? Ah, the enthusiasm of youth.
As I was thinking about this, over a glass of medicinal single-malt scotch whisky last night following the local tester meeting, I got to wondering if the ideas that were bright and shiny-new for me in the early 1980's were retreads of other ideas. So I dug out some of my older books - stuff that was on the shelf for some time without being disturbed. I flipped through some of them and ... gads. There they were!
I wonder if instead of vampires, these ideas were really closer to the immortals in the movie (not the TV series) Highlander - with Sean Connery playing an Egyptian in the service of King Charles V of Spain... with a Japanese katana. (Yeah, that one.)
Ideas don't die - they can't be killed because they are immortal. You have to take their heads off with a sharp blade to really get rid of them. If you don't, they'll go underground for a while, change their identity and then come back. They are always there if you look carefully. Most people don't look carefully though.
The reason, as near as I can tell, is that the behavior - the underlying mannerisms and actions - of the humans who are developing software have not really changed since Admiral Hopper's team discovered the first "bug" in the computer. (I know she was not an Admiral at the time, but, you get the idea.)
Our flawed views impact our flawed behaviors which directly impacts our practices in developing software which directly impacts what we put out and what we make and how the software works and interact with humans and their flaws and imperfections and... you get the idea.
Maybe when an enthusiastic young software person (designer, developer, tester, analyst of any sort) comes into my office with an earth-shattering idea, I may resist the urge to sit back, sip my coffee, stroke my beard and tell a story from 20 or 25 or ... more years ago that leaves them wondering what anything done in COBOL on an IBM Mainframe has to do with modern software development using ... fill in the blank for whatever technology your shop uses.
What I have learned is that the technology changes. It changes very quickly - far faster than I expected 30 years ago. What has not changed in that time, and seemingly has not changed since the time of, well, ever - is how people make things - software in this case and how they interact with those things and each other.
For those who have not seen anything like this, let me say quite simply. The problem with computer software has nothing to do with the computers or the software. The core problem is the behavior of the human persons around it - those who develop the software, design it, use it.
It took me a long time to understand this, and I think I am beginning to see that I, and many others, have spent most of our careers trying to solve the wrong problems.
We have been trying to use technology to address a technology problem. The problem is not in the technology - it is the behavioral relationship we have (both developing and usiing) that technology. Until we find a way to address that I expect we'll continue to see bright shiny-new labels slapped on older approaches and techniques. We will continue to have slick snake-oil sold to bosses as THE SILVER BULLET to solve all their problems.
The fact is, none of those things will work. We need to fix the underlying problem - what we have been looking at "fixing" are the symptoms.
I think this will be an interesting journey.
Yes, the un-dead, feasting on the mortals around them. Living on the fringe of society, moving in and out with grace and ensnaring people with their obvious charms.
Yup. Interview With a Vampire was a really popular book and movie franchise.
Wait.
You thought I meant the Twilight series? Really? My oldest granddaughter (a pre- and early teen when the Twilight books first came out) certainly was enthralled by them. My lady-wife? nah. Me? right. Do I LOOK like someone who would be enthralled by them? Not likely.
Yet, the lady-wife made an observation one night as we were sitting sipping a glass of wine, and watching the 1979 film Dracula. She said "I think every time a new vampire novel or movie comes out, people who have not read or seen the earlier ones latch onto it as if this was the first time anything like that was written."
I've had some conversations with testers and other software folk recently that have convinced me that the lady-wife's view can apply to software development as much as, well, vampire novels and movies.
Part of this is time and age - Some folks of a certain age have seen the same set of ideas come around two or three times. Slap a new label on it and standard fare from my first programming gig in the early 1980's is all shiny and new. Just a new buzzword. In the meantime, there was another buzz-word label for it maybe 10 or 15 years ago.
I've seen a fair number of "hot trends" in software design and development come and go and come back and go and... heh - kind of like vampires I guess. They just WON'T STAY IN THEIR GRAVE!
Maybe that is because the underlying problem they were meant to solve was not solved. The hot trend that replaced them that was absolutely going to solve the problem, did not solve the problem either.
I think back to how eager I was - how ready to change the software world I was - and how I tried to convince the older, kinda-stodgy folks I worked with that I had this bright and shiny new way of doing things. One of them would sit back and tell a story from 15 years before. I'd wonder what THAT had to do with Real MODERN software design and development - I mean, punch cards? Might as well be stone tablets, right? Ah, the enthusiasm of youth.
As I was thinking about this, over a glass of medicinal single-malt scotch whisky last night following the local tester meeting, I got to wondering if the ideas that were bright and shiny-new for me in the early 1980's were retreads of other ideas. So I dug out some of my older books - stuff that was on the shelf for some time without being disturbed. I flipped through some of them and ... gads. There they were!
I wonder if instead of vampires, these ideas were really closer to the immortals in the movie (not the TV series) Highlander - with Sean Connery playing an Egyptian in the service of King Charles V of Spain... with a Japanese katana. (Yeah, that one.)
Ideas don't die - they can't be killed because they are immortal. You have to take their heads off with a sharp blade to really get rid of them. If you don't, they'll go underground for a while, change their identity and then come back. They are always there if you look carefully. Most people don't look carefully though.
The reason, as near as I can tell, is that the behavior - the underlying mannerisms and actions - of the humans who are developing software have not really changed since Admiral Hopper's team discovered the first "bug" in the computer. (I know she was not an Admiral at the time, but, you get the idea.)
Our flawed views impact our flawed behaviors which directly impacts our practices in developing software which directly impacts what we put out and what we make and how the software works and interact with humans and their flaws and imperfections and... you get the idea.
Maybe when an enthusiastic young software person (designer, developer, tester, analyst of any sort) comes into my office with an earth-shattering idea, I may resist the urge to sit back, sip my coffee, stroke my beard and tell a story from 20 or 25 or ... more years ago that leaves them wondering what anything done in COBOL on an IBM Mainframe has to do with modern software development using ... fill in the blank for whatever technology your shop uses.
What I have learned is that the technology changes. It changes very quickly - far faster than I expected 30 years ago. What has not changed in that time, and seemingly has not changed since the time of, well, ever - is how people make things - software in this case and how they interact with those things and each other.
For those who have not seen anything like this, let me say quite simply. The problem with computer software has nothing to do with the computers or the software. The core problem is the behavior of the human persons around it - those who develop the software, design it, use it.
It took me a long time to understand this, and I think I am beginning to see that I, and many others, have spent most of our careers trying to solve the wrong problems.
We have been trying to use technology to address a technology problem. The problem is not in the technology - it is the behavioral relationship we have (both developing and usiing) that technology. Until we find a way to address that I expect we'll continue to see bright shiny-new labels slapped on older approaches and techniques. We will continue to have slick snake-oil sold to bosses as THE SILVER BULLET to solve all their problems.
The fact is, none of those things will work. We need to fix the underlying problem - what we have been looking at "fixing" are the symptoms.
I think this will be an interesting journey.
Labels:
development,
relationships,
Software,
technology,
testing
I Didn't Leave X, X Left Me
I wonder how many folks have had this feeling.
A company I worked for, once upon a time, was by-far the absolute best company I worked for when I started there. It was still the best company I worked for five (5) years in. By 8 or 9 years in, it was certainly a really good place to work.
By the time I left, I dreaded going to work. Not just the "I kinda wish I could stay home and lounge for a day" kind of thing, but really, REALLY not wanting to face the morning and the drive down the highway and walking in the front door and walking to my desk and... yeah.
For a long time, I wondered if what had changes was, well, me. I wondered if I was seeing things that had always been there from a new angle, based on my change in responsibilities, job function and the like, or if the organization really had changed around me.
Part of me, the part that wanted to convince myself I was not a jerk, was absolutely certain that the company had changed. Another part of me, which tended to think I was/am a jerk, was pretty certain that the fault lay with me.
In the end, I left. There was a downward spiral in atmosphere and relationships, as in how communication happened between peers and bosses and others I needed to be able to work with. Well, to be fair, most of the people I worked with thought (I think) I was ok to work with - users, developers, even some BAs and PMs acted as if I was an "OK" kind of guy.
Some development bosses, not so much. My boss resigned (the day after my performance review) and I found myself with a new boss. Things spiraled faster and I left.
A few months ago, I was reading an article about a fellow who had been very active in a major political party here in the US. The interviewer asked him why he "left the party he had been a member of for his entire career." His response made me blink.
He said (paraphrasing) "I did not leave them. I still have the same core values I always had. I still believe the same things I always have when it comes to national domestic policy and international relations. The party left me. I found myself in a position where my core values, which had been right in the center of the party's position for years, were suddenly on the fringe because the party had shifted so far."
I got to thinking about both of these stories again today when I read two articles. One, a post by James Whittaker (softer testing high lord) and another by an executive leaving a large multi-national bank.
Whittaker recently left a position with Google - you remember them? The company with the "Don't be evil" thing? His post (here) includes one really telling passage - two sentences:
The other post was from a fellow named Greg Smith who was leaving Goldman Sachs. He did not post his musings in a blog, he posted them as an Op-Ed piece in the New York Times (here).
One sentence stood out for me in this letter:
I think what is perhaps as interesting to me in both of these instances are the reactions/comments given in response. Mr. Whittaker's is posted in a spot where most of the people who read it will be technical professional-types (developers, testers, designers, etc.,) Mr. Smith's has been plastered over news sites, LinkedIn, Yahoo! and who knows where else.
I think it interesting that people will so publicly stand and explain why they have had enough. Would there be more people willing to take a stand where they are not willing to sully themselves with the moral and ethical decline they see - the shift away from the lofty goals and ideals they once held and appreciated in the company they worked for.
In the end, for me, the question over whether the company I worked for changed, or my realization of the nature of the company I worked for changed, does not really matter. I saw the change, perceived it as not good for me, and left.
It was the right thing for me to do and I have not regretted it since. While I am not a "famous somebody" like Mr. Whittaker, or an instant celebrety like Mr. Smith, I wish them both well and peace with their decision.
Pax vobiscum.
A company I worked for, once upon a time, was by-far the absolute best company I worked for when I started there. It was still the best company I worked for five (5) years in. By 8 or 9 years in, it was certainly a really good place to work.
By the time I left, I dreaded going to work. Not just the "I kinda wish I could stay home and lounge for a day" kind of thing, but really, REALLY not wanting to face the morning and the drive down the highway and walking in the front door and walking to my desk and... yeah.
For a long time, I wondered if what had changes was, well, me. I wondered if I was seeing things that had always been there from a new angle, based on my change in responsibilities, job function and the like, or if the organization really had changed around me.
Part of me, the part that wanted to convince myself I was not a jerk, was absolutely certain that the company had changed. Another part of me, which tended to think I was/am a jerk, was pretty certain that the fault lay with me.
In the end, I left. There was a downward spiral in atmosphere and relationships, as in how communication happened between peers and bosses and others I needed to be able to work with. Well, to be fair, most of the people I worked with thought (I think) I was ok to work with - users, developers, even some BAs and PMs acted as if I was an "OK" kind of guy.
Some development bosses, not so much. My boss resigned (the day after my performance review) and I found myself with a new boss. Things spiraled faster and I left.
A few months ago, I was reading an article about a fellow who had been very active in a major political party here in the US. The interviewer asked him why he "left the party he had been a member of for his entire career." His response made me blink.
He said (paraphrasing) "I did not leave them. I still have the same core values I always had. I still believe the same things I always have when it comes to national domestic policy and international relations. The party left me. I found myself in a position where my core values, which had been right in the center of the party's position for years, were suddenly on the fringe because the party had shifted so far."
I got to thinking about both of these stories again today when I read two articles. One, a post by James Whittaker (softer testing high lord) and another by an executive leaving a large multi-national bank.
Whittaker recently left a position with Google - you remember them? The company with the "Don't be evil" thing? His post (here) includes one really telling passage - two sentences:
The Google I was passionate about was a technology company that empowered its employees to innovate. The Google I left was an advertising company with a single corporate-mandated focus.
The other post was from a fellow named Greg Smith who was leaving Goldman Sachs. He did not post his musings in a blog, he posted them as an Op-Ed piece in the New York Times (here).
One sentence stood out for me in this letter:
I truly believe that this decline in the firm’s moral fiber represents the single most serious threat to its long-run survival.
I think what is perhaps as interesting to me in both of these instances are the reactions/comments given in response. Mr. Whittaker's is posted in a spot where most of the people who read it will be technical professional-types (developers, testers, designers, etc.,) Mr. Smith's has been plastered over news sites, LinkedIn, Yahoo! and who knows where else.
I think it interesting that people will so publicly stand and explain why they have had enough. Would there be more people willing to take a stand where they are not willing to sully themselves with the moral and ethical decline they see - the shift away from the lofty goals and ideals they once held and appreciated in the company they worked for.
In the end, for me, the question over whether the company I worked for changed, or my realization of the nature of the company I worked for changed, does not really matter. I saw the change, perceived it as not good for me, and left.
It was the right thing for me to do and I have not regretted it since. While I am not a "famous somebody" like Mr. Whittaker, or an instant celebrety like Mr. Smith, I wish them both well and peace with their decision.
Pax vobiscum.
Sunday, March 4, 2012
Process and Ritual and Testing, Oh My.
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?
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?
Thursday, March 1, 2012
Thinking Testers, Unite! or Sometimes Thinking Needs Action
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.
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.
Labels:
CAST2012,
Coaching,
Smart People,
Test Coach,
Test Coach Camp
Subscribe to:
Posts (Atom)