It seems some folks reading my blog are looking for answers to questions I pose or consider, or to scenarios and situations I describe. A couple of posts have been anchors in LinkedIn discussions - and the most common theme in the comments was "The author did not give any solutions."
No kidding.
That is not why I write ~99% of my blog posts.
That people find value in some of them is wonderful and deeply humbling to me. That people find lessons in some of them they might be able to apply themselves is fantastic.
However, most of the time, I am writing for myself.
If I am not presenting answers to problems, it is likely that I am writing to sort out problems in my mind. Some of these get published. Many of them sit in a queue and cyberly moulder away. A few get deleted completely.
So, if you are looking for solutions to problems similar to what I sometimes describe, I wish you luck.
Sometimes the easiest way for me to identify possible solutions is to do my best to describe what I am facing with as much care as I can. By doing my best to describe what is happening, without emotion (that does not mean without passion,) I can read what I write and say "I wonder if that guy has thought about... blah.?"
I find insights I had not considered. Sometimes I get insights from comments, which I appreciate. Sometimes I consider what options there are. Sometimes I realize that the options I was hoping for are not there.
And So...
If you are one of the people who regularly reads my blog posts, thank you. I really do appreciate that you take a part of your day to read what I posted. If you are looking for answers to problems I write about, please don't be upset if I don't describe them and then give an answer.
Please don't be offended.
It simply is not why I write these posts.
Sunday, January 26, 2014
Saturday, January 18, 2014
On Managing Teams, Personality Traits and Hiring
I was having a coffee and a chat the other day, wearing my "consultant hat" as one guy I know describes it. The fellow I was sitting with was a manager who was almost beside himself with frustration.
"Why can't people make a decision and stick with it? How come people always leave the decisions to me to make when they should be able to make them and not bother me about them?"
Wow. I can see where there is a good deal of frustration here. "What kind of decisions are people expecting you to make? Have you tried working with your staff so they understand what you expect them to do?"
"Everything! Every. Little. Thing."
He pounded the table top at each word to emphasize the point - I actually was afraid he'd spill the coffee which was quite tasty - and quite hot.
"Everything from what junior developer should be working on what functions to how those functions should be designed. They don't come to me with questions around how to design solutions, or to settle something where there are two designs that can be chosen. They come to me to make the design! I don't have time for that! Yesterday a guy that is supposed to be a 'senior development analyst' came to me to ask if a simple search function should use cache or not? He's a senior level person and is asking this kind of question? Why can't I get people who are really motivated and self-starters? This is making me NUTS!"
With another pound on the table for emphasis that rattled the spoons and rocked the cups. A little bit slopped over the rim of my cup and was caught by the saucer. I was saddened a little by this.
I slipped a paper napkin between the cup and saucer, took a sip of the very nice coffee and said, "It seems there is a disconnect somewhere. Can you tell me about the people you bring on and the types of people you are looking for?"
He slumped back in his chair and actually looked kind of sad, almost defeated.
"I bring in people who seem really sharp in the interview. Their references are fantastic. Their experience looks great. Lately I've been using LinkedIn to check them out. They seem really good and I think they'll help turn the team around when they come in. But it turns out that most of them aren't as sharp as they seemed. I'm not sure why the last guy had as many recommendations on LinkedIn as he did. He made so many mistakes and did so many things wrong, I could not believe it. He's just not very good." (Pause while he drank some coffee.)
"Still he's not the worst person in the group. He does OK as long as he gets close supervision. But that means I need to watch him like a hawk, every day. That is really hard when I need to watch what the rest of the group is doing like a hawk as well. If I don't they'll screw something up and then the QA group, they're pretty worthless too from what I can see - they never test the right things, won't find the bugs they're supposed to find and it gets to production and then there is hell to pay."
And here I get the first real clue what is going on.
"So, let me see if I understand. You have hired a team where every person you bring in you think is a motivated, expert self-starter and it turns out they are not. So you need to direct everything they are doing to the smallest detail. That means you are spending so much time overseeing their work that you are working far more than you should to do that and get the work done you need to get done. Correct?"
"Wow! That is exactly my problem! What can we do about it?" (Possible break though? he said 'we.")
"Let me ask another question. If you're spending all this time on stuff you should not have to, are you able to get work done you need to get done on time? Is that getting in the way?"
"Oh man, That's IT! I have a hard time getting things in on time - sometimes its at the last minute that I deliver it. Sometimes I can't turn it in until a day or two later than I needed to get it in. My {company buzzword for 'boss'} is beginning to think I can't do anything on time. That is a problem."
"Ouch. Yeah. That kind of stinks. Are your developers able to get their work done on time? Do they meet the Stage Gate and Code Complete dates in the model you use?"
"Well, sometimes. Sometimes they need to work late nights over weekends to finish code. Then when I go over it with them, I find a lot of problems. Sometimes I see that they completely ignored the design I told them to follow. I can't keep up with them when they are working at home at night or over the weekend. When they are not giving me regular updates on progress I can't make sure they are doing it right."
"I can see that might be a problem for you. Tell me something else. When you hire someone, is that to expand the group or replace people? If you are replacing people are they people who quit voluntarily or are they let go?"
"Well, fortunately, I have not had to let very many people go. It seems the worst of them know they are under-performing and quit on their own. I feel bad for the companies that hire them. They are not very good."
"But you hired them and thought they'd be amazing when you hired them. What happened?"
"I made a mistake. They were not as good as I thought I guess. While we were talking I was reminded of something. Its like when you get a puppy. Have you ever had dogs?"
"Yes. Our last dog was a rottweiler - she was 100 pounds, very sweet, a wonderful baby sitter and lived to be 11 years old."
"Really? I don't trust rottweilers, they are too violent. Maybe you got an exception. Well, my wife got a puppy when the kids were in school. We thought it would be a good thing. It was all sweet and played a lot when it was little. When it was older, its true personality came out. It growled a lot, growled at my wife a lot. It was ok with the kids, but we had to watch it all the time. It growled at me a lot. When it tried to bite me, we had it put down. A dog that changes that much can't be trusted around kids."
As a response was forming in my mind on the similarity to how his "motivated, self stater" developers and the family dog showed similar changes, he said. "Well, think about this and we can talk. I need to get this problem sorted out soon. Thanks for the coffee." And he headed out.
As he walked for the door, the Unicorn over in the corner caught my eye, looked at him, then rolled his eyes.
He looked kind of sad.
I agreed with the Unicorn.
"Why can't people make a decision and stick with it? How come people always leave the decisions to me to make when they should be able to make them and not bother me about them?"
Wow. I can see where there is a good deal of frustration here. "What kind of decisions are people expecting you to make? Have you tried working with your staff so they understand what you expect them to do?"
"Everything! Every. Little. Thing."
He pounded the table top at each word to emphasize the point - I actually was afraid he'd spill the coffee which was quite tasty - and quite hot.
"Everything from what junior developer should be working on what functions to how those functions should be designed. They don't come to me with questions around how to design solutions, or to settle something where there are two designs that can be chosen. They come to me to make the design! I don't have time for that! Yesterday a guy that is supposed to be a 'senior development analyst' came to me to ask if a simple search function should use cache or not? He's a senior level person and is asking this kind of question? Why can't I get people who are really motivated and self-starters? This is making me NUTS!"
With another pound on the table for emphasis that rattled the spoons and rocked the cups. A little bit slopped over the rim of my cup and was caught by the saucer. I was saddened a little by this.
I slipped a paper napkin between the cup and saucer, took a sip of the very nice coffee and said, "It seems there is a disconnect somewhere. Can you tell me about the people you bring on and the types of people you are looking for?"
He slumped back in his chair and actually looked kind of sad, almost defeated.
"I bring in people who seem really sharp in the interview. Their references are fantastic. Their experience looks great. Lately I've been using LinkedIn to check them out. They seem really good and I think they'll help turn the team around when they come in. But it turns out that most of them aren't as sharp as they seemed. I'm not sure why the last guy had as many recommendations on LinkedIn as he did. He made so many mistakes and did so many things wrong, I could not believe it. He's just not very good." (Pause while he drank some coffee.)
"Still he's not the worst person in the group. He does OK as long as he gets close supervision. But that means I need to watch him like a hawk, every day. That is really hard when I need to watch what the rest of the group is doing like a hawk as well. If I don't they'll screw something up and then the QA group, they're pretty worthless too from what I can see - they never test the right things, won't find the bugs they're supposed to find and it gets to production and then there is hell to pay."
And here I get the first real clue what is going on.
"So, let me see if I understand. You have hired a team where every person you bring in you think is a motivated, expert self-starter and it turns out they are not. So you need to direct everything they are doing to the smallest detail. That means you are spending so much time overseeing their work that you are working far more than you should to do that and get the work done you need to get done. Correct?"
"Wow! That is exactly my problem! What can we do about it?" (Possible break though? he said 'we.")
"Let me ask another question. If you're spending all this time on stuff you should not have to, are you able to get work done you need to get done on time? Is that getting in the way?"
"Oh man, That's IT! I have a hard time getting things in on time - sometimes its at the last minute that I deliver it. Sometimes I can't turn it in until a day or two later than I needed to get it in. My {company buzzword for 'boss'} is beginning to think I can't do anything on time. That is a problem."
"Ouch. Yeah. That kind of stinks. Are your developers able to get their work done on time? Do they meet the Stage Gate and Code Complete dates in the model you use?"
"Well, sometimes. Sometimes they need to work late nights over weekends to finish code. Then when I go over it with them, I find a lot of problems. Sometimes I see that they completely ignored the design I told them to follow. I can't keep up with them when they are working at home at night or over the weekend. When they are not giving me regular updates on progress I can't make sure they are doing it right."
"I can see that might be a problem for you. Tell me something else. When you hire someone, is that to expand the group or replace people? If you are replacing people are they people who quit voluntarily or are they let go?"
"Well, fortunately, I have not had to let very many people go. It seems the worst of them know they are under-performing and quit on their own. I feel bad for the companies that hire them. They are not very good."
"But you hired them and thought they'd be amazing when you hired them. What happened?"
"I made a mistake. They were not as good as I thought I guess. While we were talking I was reminded of something. Its like when you get a puppy. Have you ever had dogs?"
"Yes. Our last dog was a rottweiler - she was 100 pounds, very sweet, a wonderful baby sitter and lived to be 11 years old."
"Really? I don't trust rottweilers, they are too violent. Maybe you got an exception. Well, my wife got a puppy when the kids were in school. We thought it would be a good thing. It was all sweet and played a lot when it was little. When it was older, its true personality came out. It growled a lot, growled at my wife a lot. It was ok with the kids, but we had to watch it all the time. It growled at me a lot. When it tried to bite me, we had it put down. A dog that changes that much can't be trusted around kids."
As a response was forming in my mind on the similarity to how his "motivated, self stater" developers and the family dog showed similar changes, he said. "Well, think about this and we can talk. I need to get this problem sorted out soon. Thanks for the coffee." And he headed out.
As he walked for the door, the Unicorn over in the corner caught my eye, looked at him, then rolled his eyes.
He looked kind of sad.
I agreed with the Unicorn.
Monday, January 13, 2014
Pandora's Box Testing
Anyone who has been around software testing for more than a wee, tiny bit is likely to have heard such terms such "Black Box,", "White Box" (or Glass Box) or "Grey Box" testing. There is one Box of testing that includes all of these approaches. It is, I believe, the most prevalent form of testing in use, world wide. It is also the type of testing that is talked about the least. I believe this is because most people who practice this form of testing are either in complete denial that they are doing this or have no possible clue that they are doing this.
To Review -
Black Box Software Testing is testing done without, or ignoring, knowledge of the design or code.
White (or Glass) Box Software Testing is testing done while making use of knowledge of design or code.
Grey Box Software Testing is testing done with some knowledge of the design or code.
Pretty straight forward, yes?
Certain "experts" tell us that these things can give us ALL the testing types there are. Testing is encompassed by these terms. Of course, that presumes that we can test all the requirements and all the possible combinations and paths through the code and all the potential cycles and ... yes. I think you see.
These, however, are mere shadows of the trust that most testers put into the test method they don't even realize they are using. This is the most commonly used test method world wide - bar none.
If we look at the sheer numbers of people using it then, by most commonly used measures, this counts as the overwhelming favorite.
If we accept that the numbers of people using the method measures something important, as certain advocates of certain commercial training programs would have us accept, then this is, hands down, the most accepted method ever.
Pandora's Box Testing
Yes. There it is. The most commonly used test method world wide - bar none. I bet some of you reading this have used it and did not even know it. I know that, in retrospect, I have used it as well. The challenge is to not use it.
Let us consider why using this most commonly used method a bad idea.
Pandora's Box, from Greek mythology, focuses on Zeus "getting even" with Prometheus the Titan, who gave fire to mortals. So, Epimetheus, the brother of Prometheus, is given a gift - Pandora to be his wife. Pandora is given a gift by Zeus, a container that is sealed. Zeus tells her to never open it, and gives the key to Epimetheus with the same instructions.
While Epimetheus is sleeping, Pandora's curiosity gets the better of her and she takes the key from him. Then, she opens the container.
Evil things flew out of the container - causing Pandora to scream and try to close it. She fails to stop the evil from entering the world. It spread around the world, to every corner. Epimetheus rushes to her, having been awoken from sleep by her scream. He sees what she has done. They open the container and the last thing contained in it flies out - Hope. In some versions, the Spirit of Hope, Elpis.
In most versions told to children, this is seen as a positive sign. A good thing to counter all the evil that had been loosed in the world.
This is an incorrect interpretation.
Hope, without positive action to support it and make that which is hoped for come to fruition, is the greatest evil of all.
And that is what most "testing" that is done, world wide, actually is - trusting in hope.
When "testing" measures "quality" and "quality" is defined as conformance to requirements, are we acting based on reason? Can we be certain that the requirements are right? Can we test positive and negative conditions for the requirements? Can we only test the requirements? Is there anything else we can test that would provide information about the software?
Do we have an interest in doing more than this? Do we have a reason to do more than this?
Are we trusting to luck in our testing if we don't do more?
Are we hoping that is good enough testing?
To Review -
Black Box Software Testing is testing done without, or ignoring, knowledge of the design or code.
White (or Glass) Box Software Testing is testing done while making use of knowledge of design or code.
Grey Box Software Testing is testing done with some knowledge of the design or code.
Pretty straight forward, yes?
Certain "experts" tell us that these things can give us ALL the testing types there are. Testing is encompassed by these terms. Of course, that presumes that we can test all the requirements and all the possible combinations and paths through the code and all the potential cycles and ... yes. I think you see.
These, however, are mere shadows of the trust that most testers put into the test method they don't even realize they are using. This is the most commonly used test method world wide - bar none.
If we look at the sheer numbers of people using it then, by most commonly used measures, this counts as the overwhelming favorite.
If we accept that the numbers of people using the method measures something important, as certain advocates of certain commercial training programs would have us accept, then this is, hands down, the most accepted method ever.
Pandora's Box Testing
Yes. There it is. The most commonly used test method world wide - bar none. I bet some of you reading this have used it and did not even know it. I know that, in retrospect, I have used it as well. The challenge is to not use it.
Let us consider why using this most commonly used method a bad idea.
Pandora's Box, from Greek mythology, focuses on Zeus "getting even" with Prometheus the Titan, who gave fire to mortals. So, Epimetheus, the brother of Prometheus, is given a gift - Pandora to be his wife. Pandora is given a gift by Zeus, a container that is sealed. Zeus tells her to never open it, and gives the key to Epimetheus with the same instructions.
While Epimetheus is sleeping, Pandora's curiosity gets the better of her and she takes the key from him. Then, she opens the container.
Evil things flew out of the container - causing Pandora to scream and try to close it. She fails to stop the evil from entering the world. It spread around the world, to every corner. Epimetheus rushes to her, having been awoken from sleep by her scream. He sees what she has done. They open the container and the last thing contained in it flies out - Hope. In some versions, the Spirit of Hope, Elpis.
In most versions told to children, this is seen as a positive sign. A good thing to counter all the evil that had been loosed in the world.
This is an incorrect interpretation.
Hope, without positive action to support it and make that which is hoped for come to fruition, is the greatest evil of all.
And that is what most "testing" that is done, world wide, actually is - trusting in hope.
When "testing" measures "quality" and "quality" is defined as conformance to requirements, are we acting based on reason? Can we be certain that the requirements are right? Can we test positive and negative conditions for the requirements? Can we only test the requirements? Is there anything else we can test that would provide information about the software?
Do we have an interest in doing more than this? Do we have a reason to do more than this?
Are we trusting to luck in our testing if we don't do more?
Are we hoping that is good enough testing?
Sunday, January 12, 2014
Skills, Abilities, Learning and Confusing Education for Training
In early December I joined a group of testers in Cleveland, OH for a two and a half day workshop on Skills for Testers. This Workshop, called WHOSE, was an AST event and was focused on experiential reports of skills the participants actually used in their work.
Several things came out of this. First was a list of skills themselves. More importantly, in the minds of many of the participants, was explaining what we meant by each skill - even where there were competing definitions. We also explained how and in what contexts we learned and first used the skills. Finally, we looked at information for people to use to learn or improve each skill themselves.
It was a daunting task.
For our purpose, we defined a Skill as:
The ability to perform some action for a purpose.
We agreed that to be included, a skill must be
For the same reason that Colleges and Universities that teach tools and "in demand" "hot skills" are failing in their primary mission: Educating People.
What IS Education?
The Oxford American Dictionary gives this:
noun
1. the process of receiving or giving systematic instruction, especially at a school or university;
Miriam-Websters gives us:
noun
One of my history professors, alas, long departed from this world, explained very patiently to a student majoring in business administration who was whining that "the stuff" he was learning in her class (a 100-level survey course that was popular among students majoring in business and education) would do him "no good in the real world" that the purpose of taking courses outside of a student's primary area of study was for them to learn how to think, how to identify and define patterns of behavior and how to draw conclusions from said thinking and pattern identification.
She went on to, very patiently, explain "Doctor Barkham and I have discussed this several times. He asks questions that could lead to very interesting research for someone interested in the development of management theory and practices from the early Georgian period to today." I should mention that "Doctor Barkham" was not his real name. He was, however, the chairman of the department overseeing Business Administration studies.
When he protested that what was being taught in the class was pointless, she gently smiled and observed that perhaps he should have enrolled in a trade school. I'm not sure why he got mad, she rather had a point.
If one wants to "learn a trade" then by all means, go to a trade school where you can get the information on how to do a given job and finish very quickly, compared to a University or a liberal-arts College.
OK, folks outside the US may not know that in the US "university" and "college" tend to get used interchangeably. Here, a "college" is not a trade school, they tend to be a smaller liberal-arts "mini-university." Where most universities are made up of many "Schools" of "Colleges" a stand alone "college" is typically a single school. Community and junior colleges offer two year degrees, Associate Degrees, that typically can be transferred to larger four year colleges or universities. Some also offer certifications in specific "in demand" areas such as culinary arts or criminal justice studies.
Trade Schools may call themselves Colleges or Universities, they tend to be private, for-profit establishments. They may offer anything from auto mechanics to heavy equipment operation to hair styling to computer networking or programming. They tend to be non-accredited. The drawback is, they do not offer a "Bachelors Degree" - because they are not allowed to in most states.
On Skills.
The Skills we focused on at WHOSE were skills that one needs in software in general, and software testing in particular. They were not tool specific. They were the core needs to be a good craftsman and professional.
Why?
The skills we looked at, debated and wrestled with, were, in our view, the skills that were the foundation to what a tester needs. We had skills that were very elementary. We also had skills that would be needed by a senior tester who was helping more junior testers. We had skills that would help a test manager or a tester would need to work with a test manager or higher.
These were building blocks.
We started with a massive list - over 200 - items then searched through them, identified those which were essentially duplicates, grouped them by nature and application of the skills. Things like,
Communication, Coaching & Mentoring, Logic and Rational Thought, Modeling, Planning, Risk Management, Speaking & Writing, Test Design, Test Approach and more. These were the subject of debate and discussion and wrestling.
One challenge was identifying what certain people meant by items they listed as skills. We found that sometimes people applied different labels to what others would define as the same skill. Identifying these instances was difficult. They ranged from the very academic to the very rudimentary.
Describing the context we learned a skill as well as apply and teach the skill was time consuming. The task seemed monumental. What we took on, was monumental. It also is an on-going process.
The work involved is not done. Editing is still underway as well as organizing and refining the classifications. One task which needs to be addressed, in my mind, is defining at what point in ones career are each of these skills required.
Should a novice, fledgling tester look at the entirety of the list, they would likely be disheartened. That task remains.
Future Development
Given that the people involved are volunteering their time and effort, I am not, nor I think are the people who organized the workshop, disheartened. Every day, participants are looking at, reading and making refinements to areas they volunteered to work on. Reviews are on going as people finish writing and editing.
The interesting thing are the differences in context where participants learned and work with the skills. They give credence to the sometimes contentious notion (among some circles) of what "context driven" means and is for testers.
For this, I see great value in this work. It is not an exhaustive list. It is not the framework for a commercial training or certification program.
It is a collection of fundamental skills to master. Some will have greater or lesser value to you, based on your context. One thing I have learned though, is your context changes. Learning how to apply or reapply skills is something we must master.
Several things came out of this. First was a list of skills themselves. More importantly, in the minds of many of the participants, was explaining what we meant by each skill - even where there were competing definitions. We also explained how and in what contexts we learned and first used the skills. Finally, we looked at information for people to use to learn or improve each skill themselves.
It was a daunting task.
For our purpose, we defined a Skill as:
The ability to perform some action for a purpose.
We agreed that to be included, a skill must be
- Demonstrable - You can show it to someone else
- Isolatable - To a single repeatable element
- Observable - After demonstration and explanation I know it when I see it
- Improvable - Can be done better or worse, and you can improve with practice
- Comparable - It is possible to observe people modeling skills and determine a relative qualitative ranking that most people agree on - at least between a novice, intermediate, and an expert.
For the same reason that Colleges and Universities that teach tools and "in demand" "hot skills" are failing in their primary mission: Educating People.
What IS Education?
The Oxford American Dictionary gives this:
noun
1. the process of receiving or giving systematic instruction, especially at a school or university;
the theory and practice of teaching;
a body of knowledge acquired while being educated;
a body of knowledge acquired while being educated;
Miriam-Websters gives us:
noun
1 a : the action or process of educating or of being educated; also : a stage of such a process
b : the knowledge and development resulting from an educational process
b : the knowledge and development resulting from an educational process
One of my history professors, alas, long departed from this world, explained very patiently to a student majoring in business administration who was whining that "the stuff" he was learning in her class (a 100-level survey course that was popular among students majoring in business and education) would do him "no good in the real world" that the purpose of taking courses outside of a student's primary area of study was for them to learn how to think, how to identify and define patterns of behavior and how to draw conclusions from said thinking and pattern identification.
She went on to, very patiently, explain "Doctor Barkham and I have discussed this several times. He asks questions that could lead to very interesting research for someone interested in the development of management theory and practices from the early Georgian period to today." I should mention that "Doctor Barkham" was not his real name. He was, however, the chairman of the department overseeing Business Administration studies.
When he protested that what was being taught in the class was pointless, she gently smiled and observed that perhaps he should have enrolled in a trade school. I'm not sure why he got mad, she rather had a point.
If one wants to "learn a trade" then by all means, go to a trade school where you can get the information on how to do a given job and finish very quickly, compared to a University or a liberal-arts College.
OK, folks outside the US may not know that in the US "university" and "college" tend to get used interchangeably. Here, a "college" is not a trade school, they tend to be a smaller liberal-arts "mini-university." Where most universities are made up of many "Schools" of "Colleges" a stand alone "college" is typically a single school. Community and junior colleges offer two year degrees, Associate Degrees, that typically can be transferred to larger four year colleges or universities. Some also offer certifications in specific "in demand" areas such as culinary arts or criminal justice studies.
Trade Schools may call themselves Colleges or Universities, they tend to be private, for-profit establishments. They may offer anything from auto mechanics to heavy equipment operation to hair styling to computer networking or programming. They tend to be non-accredited. The drawback is, they do not offer a "Bachelors Degree" - because they are not allowed to in most states.
On Skills.
The Skills we focused on at WHOSE were skills that one needs in software in general, and software testing in particular. They were not tool specific. They were the core needs to be a good craftsman and professional.
Why?
The skills we looked at, debated and wrestled with, were, in our view, the skills that were the foundation to what a tester needs. We had skills that were very elementary. We also had skills that would be needed by a senior tester who was helping more junior testers. We had skills that would help a test manager or a tester would need to work with a test manager or higher.
These were building blocks.
We started with a massive list - over 200 - items then searched through them, identified those which were essentially duplicates, grouped them by nature and application of the skills. Things like,
Communication, Coaching & Mentoring, Logic and Rational Thought, Modeling, Planning, Risk Management, Speaking & Writing, Test Design, Test Approach and more. These were the subject of debate and discussion and wrestling.
One challenge was identifying what certain people meant by items they listed as skills. We found that sometimes people applied different labels to what others would define as the same skill. Identifying these instances was difficult. They ranged from the very academic to the very rudimentary.
Describing the context we learned a skill as well as apply and teach the skill was time consuming. The task seemed monumental. What we took on, was monumental. It also is an on-going process.
The work involved is not done. Editing is still underway as well as organizing and refining the classifications. One task which needs to be addressed, in my mind, is defining at what point in ones career are each of these skills required.
Should a novice, fledgling tester look at the entirety of the list, they would likely be disheartened. That task remains.
Future Development
Given that the people involved are volunteering their time and effort, I am not, nor I think are the people who organized the workshop, disheartened. Every day, participants are looking at, reading and making refinements to areas they volunteered to work on. Reviews are on going as people finish writing and editing.
The interesting thing are the differences in context where participants learned and work with the skills. They give credence to the sometimes contentious notion (among some circles) of what "context driven" means and is for testers.
For this, I see great value in this work. It is not an exhaustive list. It is not the framework for a commercial training or certification program.
It is a collection of fundamental skills to master. Some will have greater or lesser value to you, based on your context. One thing I have learned though, is your context changes. Learning how to apply or reapply skills is something we must master.
Saturday, January 11, 2014
Balance and Conferences and Life, Oh My!
My blog post for the end of 2013 (here) generated some questions on twitter and email - apparently some folks had a problem leaving comments or generally wanted to ask stuff "off line." No worries.
I promised one Question Asking (QA) person that she had prompted my second blog post for 2014 - here it is...
Folks talk about Work-Life Balance and I'm not entirely certain what they mean. By that, I work to maintain a lifestyle for my family and I. I do work I enjoy because otherwise, well, I've done work I did not enjoy and the cost was far more than what money I could make.
For me, the question is not around "Work Life Balance," the question is around Life? What kind of life do I want to have?
Life
At one point, I spent every possible hour when not at the day job playing drums in one band or another. It was a lot of fun. It was loads of work, practicing, honing skills, learning new skills and techniques - but generally it was fun. Things changed, I added a sweetheart to the mix and suddenly, I need to reorganize things. Time I spent with her meant less time playing drums. That was OK - in fact, it was more than OK.
As time went on and the relationship with the sweetheart grew deeper, my "commitment" to the remaining bands waned a bit. I could not do the things I wanted to do with her and still do the "band" things I was doing. So the role of bands changed. I found myself playing in just one band, and teaching private lessons.
I had more time for living and home work and gardening and - Oh yeah, I got married.
I had a job, I had a wife and now family, I had a band. That band was based 3 hours away. Band practice was Sunday, every Sunday. Performances were on weekends. So, "off season" I'd be gone every Sunday from roughly 6:30 or 7:00 AM until roughly 12 hours later. During the performance season, I'd leave the house on a Friday, sometimes after day-job work - sometimes earlier if I took the day off. I'd return sometime on Sunday. Sometimes the lady-wife would come with me - sometimes not.
When it was time to change again - 5 years and then some is a long time to not be home on weekends - the reasons were simple. What had been fun was now more work than fun. The amount of things to do around the home and garden we so many, that there was not joy in the doing of them. So, I hung up my kilt and drum stuff and began spending loads of time around the house doing things. For a while, a few bands would ask me to come and teach or do a workshop. I did those - for a while. Things changed again.
The last several years I have not been active in any form of organized music - which sounds weird since I've been playing music since I was a kid. I discovered I have a wonderful life at home. I can enjoy the work in the garden without thinking "I need to get this done NOW because otherwise I won't be able to until after" every single week.
Going Independent was another flavor of that. I have very fixed hours at my client - usually - unless I am on the road somewhere out of town. When I'm in town, my hours are pretty fixed. I get home and can do things around the house. I can do writing or reading in the evening - sometimes the telly is on. Sometimes we're sitting quietly.
Paperwork - invoices, bills, that junk, I usually deal with on a Saturday morning after a bit of a lie in. The house is quiet and I can sit and do it.
We can have a nice dinner together. We have weekend excursions - out to an antique show or catch a band playing or get together with friends - without the hassle of the phone ringing or being paged.
Some nights, I do no writing. I do nothing even vaguely computer or software related. Don't even get the laptop out. Extremely relaxing.
This plays into my thoughts on changing how I choose conferences to participate in.
Conferences
There are a bunch of them. You may have noticed. Being a privateer (which is how I prefer to see myself instead of an "independent") if my company pays for me to go to a conference, that company is me.
When I was working for another company and wanted to go to a conference. Usually the boss types went along with it. When I went as a speaker, they thought it was way cool. Look! Good PR! One company was extremely supportive. One company, that bought the company I had been working for (and somehow I survived the happy-sizing) had concerns that I would possibly say things they did not approve of.
Since the presentations had been prepared before "the assimilation" a compromise was reached. I gave a disclaimer that "The ideas and views expressed are not necessarily the ideas and views of TLA Corp, its subsidiaries, its Board of Directors nor management and staff." SO I said that.
and added "... but they probably should be."
Thus I was already on the road to becoming a Privateer.
So conferences that were not paid for by the company counted as "vacation" time. This astounded some of my co-workers that I would use vacation time and my own money to go to a conference. I'm not sure why. I wanted to get better and pick up ideas and concepts new to me. That would be less likely to happen if I stayed reading the same stuff by the same people.
After going to several conferences, and speaking at a moderate number, I noticed a trend. Some very large conferences, there was a lot of "social activities" that did not really fit my idea of social. I mean, there was a fair amount of drinking, as long as the drink tickets held out, but when the designated function ended, people tended to scatter.
The idea of conferring - exchanging ideas outside of the lectures/presentations seemed foreign to a fair number, if not most, of the attendees. I noticed that several speakers hung around the conference center wearing their name tags, apparently with the intent of making themselves available for said conversations. When I began speaking, I took up the same practice "I'll be at tonight if you want to talk on this more, or, grab me at lunch or breakfast tomorrow and we can talk - or set up a time to meet"
I made that offer many times. I remember one conference where I spoke, and two other speakers I know and respect made the identical offer. That evening - the number of people from the conference in the hotel/conference center bar for conversation was .... 3.
When I am at a conference, I want to pick up ideas I have not heard before. Or - I want a meaningful reconsideration of ideas I have heard. I am open, willing and excited to discuss ideas I have, as well as ideas I disagree with - particularly with people who disagree with me. However, the conversations I want to have need to be polite and informative. When asked "What about?" I reserve the right to dismiss you if the response is "Look, I've done the work on this. Trust me."
Explain to me why I should? What research supports you? Is there anyone other than you who can support this? Are there any real examples of this working - as you described - recently? When have you done this?
I am willing to be the one everyone disagrees with. Other speakers, organizers, participants - just give me evidence why you disagree - not statements of belief. When there is nothing but empty assertions to "trust me" then we settle into wars of religion. Not a whit of evidence on either side - just firm belief in the "correctness" of their position."
Lately - I've seen a fair number of conferences retreat into fuzzy stuff. I'm not interested is listening in on people's epistemological bubbles.
The result is - I've begun screening more carefully the conferences I wish to participate in, either as a speaker or as a person attending.
When I spend my money traveling to a conference, I want to believe it was well spent. Otherwise, I'd be better off spending the money on a trip with my lady-wife.
I promised one Question Asking (QA) person that she had prompted my second blog post for 2014 - here it is...
Folks talk about Work-Life Balance and I'm not entirely certain what they mean. By that, I work to maintain a lifestyle for my family and I. I do work I enjoy because otherwise, well, I've done work I did not enjoy and the cost was far more than what money I could make.
For me, the question is not around "Work Life Balance," the question is around Life? What kind of life do I want to have?
Life
At one point, I spent every possible hour when not at the day job playing drums in one band or another. It was a lot of fun. It was loads of work, practicing, honing skills, learning new skills and techniques - but generally it was fun. Things changed, I added a sweetheart to the mix and suddenly, I need to reorganize things. Time I spent with her meant less time playing drums. That was OK - in fact, it was more than OK.
As time went on and the relationship with the sweetheart grew deeper, my "commitment" to the remaining bands waned a bit. I could not do the things I wanted to do with her and still do the "band" things I was doing. So the role of bands changed. I found myself playing in just one band, and teaching private lessons.
I had more time for living and home work and gardening and - Oh yeah, I got married.
I had a job, I had a wife and now family, I had a band. That band was based 3 hours away. Band practice was Sunday, every Sunday. Performances were on weekends. So, "off season" I'd be gone every Sunday from roughly 6:30 or 7:00 AM until roughly 12 hours later. During the performance season, I'd leave the house on a Friday, sometimes after day-job work - sometimes earlier if I took the day off. I'd return sometime on Sunday. Sometimes the lady-wife would come with me - sometimes not.
When it was time to change again - 5 years and then some is a long time to not be home on weekends - the reasons were simple. What had been fun was now more work than fun. The amount of things to do around the home and garden we so many, that there was not joy in the doing of them. So, I hung up my kilt and drum stuff and began spending loads of time around the house doing things. For a while, a few bands would ask me to come and teach or do a workshop. I did those - for a while. Things changed again.
The last several years I have not been active in any form of organized music - which sounds weird since I've been playing music since I was a kid. I discovered I have a wonderful life at home. I can enjoy the work in the garden without thinking "I need to get this done NOW because otherwise I won't be able to until after
Going Independent was another flavor of that. I have very fixed hours at my client - usually - unless I am on the road somewhere out of town. When I'm in town, my hours are pretty fixed. I get home and can do things around the house. I can do writing or reading in the evening - sometimes the telly is on. Sometimes we're sitting quietly.
Paperwork - invoices, bills, that junk, I usually deal with on a Saturday morning after a bit of a lie in. The house is quiet and I can sit and do it.
We can have a nice dinner together. We have weekend excursions - out to an antique show or catch a band playing or get together with friends - without the hassle of the phone ringing or being paged.
Some nights, I do no writing. I do nothing even vaguely computer or software related. Don't even get the laptop out. Extremely relaxing.
This plays into my thoughts on changing how I choose conferences to participate in.
Conferences
There are a bunch of them. You may have noticed. Being a privateer (which is how I prefer to see myself instead of an "independent") if my company pays for me to go to a conference, that company is me.
When I was working for another company and wanted to go to a conference. Usually the boss types went along with it. When I went as a speaker, they thought it was way cool. Look! Good PR! One company was extremely supportive. One company, that bought the company I had been working for (and somehow I survived the happy-sizing) had concerns that I would possibly say things they did not approve of.
Since the presentations had been prepared before "the assimilation" a compromise was reached. I gave a disclaimer that "The ideas and views expressed are not necessarily the ideas and views of TLA Corp, its subsidiaries, its Board of Directors nor management and staff." SO I said that.
and added "... but they probably should be."
Thus I was already on the road to becoming a Privateer.
So conferences that were not paid for by the company counted as "vacation" time. This astounded some of my co-workers that I would use vacation time and my own money to go to a conference. I'm not sure why. I wanted to get better and pick up ideas and concepts new to me. That would be less likely to happen if I stayed reading the same stuff by the same people.
After going to several conferences, and speaking at a moderate number, I noticed a trend. Some very large conferences, there was a lot of "social activities" that did not really fit my idea of social. I mean, there was a fair amount of drinking, as long as the drink tickets held out, but when the designated function ended, people tended to scatter.
The idea of conferring - exchanging ideas outside of the lectures/presentations seemed foreign to a fair number, if not most, of the attendees. I noticed that several speakers hung around the conference center wearing their name tags, apparently with the intent of making themselves available for said conversations. When I began speaking, I took up the same practice "I'll be at
I made that offer many times. I remember one conference where I spoke, and two other speakers I know and respect made the identical offer. That evening - the number of people from the conference in the hotel/conference center bar for conversation was .... 3.
When I am at a conference, I want to pick up ideas I have not heard before. Or - I want a meaningful reconsideration of ideas I have heard. I am open, willing and excited to discuss ideas I have, as well as ideas I disagree with - particularly with people who disagree with me. However, the conversations I want to have need to be polite and informative. When asked "What about
Explain to me why I should? What research supports you? Is there anyone other than you who can support this? Are there any real examples of this working - as you described - recently? When have you done this?
I am willing to be the one everyone disagrees with. Other speakers, organizers, participants - just give me evidence why you disagree - not statements of belief. When there is nothing but empty assertions to "trust me" then we settle into wars of religion. Not a whit of evidence on either side - just firm belief in the "correctness" of their position."
Lately - I've seen a fair number of conferences retreat into fuzzy stuff. I'm not interested is listening in on people's epistemological bubbles.
The result is - I've begun screening more carefully the conferences I wish to participate in, either as a speaker or as a person attending.
When I spend my money traveling to a conference, I want to believe it was well spent. Otherwise, I'd be better off spending the money on a trip with my lady-wife.
Sunday, January 5, 2014
When All Seems Lost or Beating the Advance
We have seen projects run very well and succeed by any measure of succeed the team or the clients could choose to imagine. We have seen projects fail so dismally that no amount of spin or explanation or anything else will convince anyone that it was something other than a shambles. We have seen projects that fall somewhere in between.
Putting this another way, we have been active professionals in a variety of environments and have seen what happens when things go well or poorly.
What happens when projects are a series of failures? What happens when projects are more than failures and are disasters? What happens when our software projects become the lead story in local, or worse, national news coverage? What do we do?
As software testers, our task is to alert the project team to risks to the project and to the greater organization itself. We can not make the decision to implement or not implement the changes. We can not demand that something happen or not happen.
We can describe the likely outcomes. We can describe the areas of weakness and uncertainty within the application.
When people push "The Decision" on to the Software Testing group or QA, they are abdicating their responsibility to the project stakeholders and the customers of the effort.
Most of the time when I have seen this happen, or when I have been the one in the project room when the "leadership" looks at me and asks "Do we go?" they, the "leaders" have been abdicating their responsibility. They are symbolically washing their hands of the matter and pass it to someone else so what ever happens with the decision, the person "who made the decision" will be blamed and not them.
The technical term for this type of behavior is "cowardly."
The challenge for testers, QA folks, whatever you are called in whatever organization you are in, is to not give up. James Bach wrote a fantastic piece on Finding Your Own Integrity (parts 1 and 2). For me, integrity includes standing my ground and speaking truth no matter the cost.
We can do that diplomatically and be fairly nuanced, or we can call rubbish rubbish. The context, the individual situation should help you make that determination.
So, when people are trying to pass decisions that should be theirs to make, know why they are doing it. Then act with integrity. Resist. In the face of disaster, resist.
I can hear the protests now... "But I have a wife and kids to provide for and a house and car note to pay and shoes and groceries and..."
Let me ask this: If people are setting you up to take the fall, and you let them, without resisting, without taking reasonable steps in response, what is the logical outcome? How many times will you be humiliated publicly, professionally, in front of your colleagues, before you stand up?
When you do stand up, after some number of cycles of you and your fellow testers taking the blame for absolute failure or projects being delayed (another form of failure in the eyes of people who worry about such things) or any other form of "Testing did it wrong," how much support will you have from others?
The more a simple lie is repeated, the more it is accepted by the unthinking and uncritical observers and people hearing it. You must respond with simple truth. Not excuses - but fact. Demonstrable, documented, proven fact.
Do not take failure of the entire project on yourself. When a project fails, it is rarely the fault of one person. Mistakes can be made. Recover and move on.
If you act with openly with integrity, you may find yourself with more allies and a greater support network than you realized you had. Even if that is not the case, you have met those who make a career out of blaming others, particularly for their own failures, with honor.
It may end your job. True.
Not responding honorably will drain your soul, your spirit and you are likely to lose your job soon anyway.
Go forward and meet them.
Boldly.
Putting this another way, we have been active professionals in a variety of environments and have seen what happens when things go well or poorly.
What happens when projects are a series of failures? What happens when projects are more than failures and are disasters? What happens when our software projects become the lead story in local, or worse, national news coverage? What do we do?
As software testers, our task is to alert the project team to risks to the project and to the greater organization itself. We can not make the decision to implement or not implement the changes. We can not demand that something happen or not happen.
We can describe the likely outcomes. We can describe the areas of weakness and uncertainty within the application.
When people push "The Decision" on to the Software Testing group or QA, they are abdicating their responsibility to the project stakeholders and the customers of the effort.
Most of the time when I have seen this happen, or when I have been the one in the project room when the "leadership" looks at me and asks "Do we go?" they, the "leaders" have been abdicating their responsibility. They are symbolically washing their hands of the matter and pass it to someone else so what ever happens with the decision, the person "who made the decision" will be blamed and not them.
The technical term for this type of behavior is "cowardly."
The challenge for testers, QA folks, whatever you are called in whatever organization you are in, is to not give up. James Bach wrote a fantastic piece on Finding Your Own Integrity (parts 1 and 2). For me, integrity includes standing my ground and speaking truth no matter the cost.
We can do that diplomatically and be fairly nuanced, or we can call rubbish rubbish. The context, the individual situation should help you make that determination.
So, when people are trying to pass decisions that should be theirs to make, know why they are doing it. Then act with integrity. Resist. In the face of disaster, resist.
I can hear the protests now... "But I have a wife and kids to provide for and a house and car note to pay and shoes and groceries and..."
Let me ask this: If people are setting you up to take the fall, and you let them, without resisting, without taking reasonable steps in response, what is the logical outcome? How many times will you be humiliated publicly, professionally, in front of your colleagues, before you stand up?
When you do stand up, after some number of cycles of you and your fellow testers taking the blame for absolute failure or projects being delayed (another form of failure in the eyes of people who worry about such things) or any other form of "Testing did it wrong," how much support will you have from others?
The more a simple lie is repeated, the more it is accepted by the unthinking and uncritical observers and people hearing it. You must respond with simple truth. Not excuses - but fact. Demonstrable, documented, proven fact.
Do not take failure of the entire project on yourself. When a project fails, it is rarely the fault of one person. Mistakes can be made. Recover and move on.
If you act with openly with integrity, you may find yourself with more allies and a greater support network than you realized you had. Even if that is not the case, you have met those who make a career out of blaming others, particularly for their own failures, with honor.
It may end your job. True.
Not responding honorably will drain your soul, your spirit and you are likely to lose your job soon anyway.
Go forward and meet them.
Boldly.
 |
| Le Réveil - The Awakening Auguste Marie Raffet A solitary drummer beats the Call to Arms and the Advance summoning fallen soldiers to form ranks and once more defend France. |
Subscribe to:
Posts (Atom)
