No odd philosophical ramblings in this post. No questioning definitions or other people's dearly held beliefs. Still, I'm getting pretty excited.
The Conference for the Association of Software Testing (CAST) is coming up REALLY fast - August 8 through 10 in Seattle (to be precise) Part of the fun this year is to hold an "Emerging Topics" track - 20 minute sessions that anyone already attending the conference can submit a proposal to give.
Yeah, anyone who is registered and who wants to give a short talk on something they do not see covered in the balance of the program can do so.
Here's the catch: In order to make a schedule and give everyone attending the opportunity to review the abstracts for the Emerging Topics session they might be interested in, we will need to cut off entries and voting for them, on July 1, 2011.
So, if you are attending CAST and want to submit a proposal, or review and vote on proposals in the Emerging Topics track, please drop an email to me or Matt Heusser. We'll get you setup with access to see (and create) them.
UPDATE!!!!!!!!!!
July 20, 2011 -
The Submission and Voting period is now closed, selections and a schedule have been made. This has been an interesting, thought provoking and fun project to work on. I am looking forward to meeting everyone in person after communicating by email and telephone.
Thanks to all who participated - Pete
Friday, June 24, 2011
Thursday, June 23, 2011
Managing and Controlling or One of These Things is Not Like the Other
There are some interesting threads on various internet discussion forums. Some are interesting as in "this is a thought provoking conversation with a lot of good ideas." Some are more along the lines of "this is a very odd series of disjointed thoughts where people can not even agree on what they disagree on."
One was interesting in the "What is this guy talking about?" sort of way.
His assertion was that Exploratory Testing was fine for small groups of one or two testers. However, it was unsuitable for larger or regulated environments because testing could not be controlled. He also suggested that Exploratory Testing was not as thorough as fully scripted testing because you did not need to think about it before you did it.
Take a deep breath, Pete. Can we start with this, "What is the difference between Controlling and Managing?" His response was "None. They are the same thing."
Oh dear, oh my, oh dear.
Let's see. Being too lazy to look get out one of my physical dictionaries, I turned to Google and searched for "control definition", "manage definition", "controlling definition" and "managing definition". I very scientifically grabbed the top search results (that were not paid advertisements) and found this...
Control: –verb
1. to exercise restraint or direction over; dominate; command.
2. to hold in check; curb.
OR...
Control: -noun
1. the act or power of controlling; regulation; domination or command.
2. the situation of being under the regulation, domination, or command of another.
Then there is this...
Manage: -verb (used with object)
1. to bring about or succeed in accomplishing, sometimes despite difficulty or hardship.
2. to take charge or care of.
OR...
Manage: -verb (used without object)
1. to conduct business, commercial affairs, etc.; be in charge.
2. to continue to function, progress, or succeed, usually despite hardship or difficulty; get along:
Now then, we have looked at the roots, now let us look at the -ing words in question.
Controlling: -adjective
1. inclined to control others' behavior; domineering
And...
Managing: -adjective
1. having executive or supervisory control or authority
As I sit here, I think a bit on the interesting idea that Manage and Control are the same thing. Based on these definitions, I find it interesting that there can be a serious assertion made that they mean the same thing. Having said that, I know certain boss types who firmly believe this. Me, I'm far to liberal (at least in the traditional, apolitical sense of the word) to agree with this.
Liberal: -adjective
1. open to new behavior or opinions
2. favorable to or respectful of individual rights and freedoms
Now, if you want to exercise restraint or direction over your people (whom I suspect you refer to as "resources") or to dominate your staff or to hold them in check, have a great time. Your staff probably won't.
Oh, I won't be part of that game, either.
Now, if you want to be in charge and guide and supervise your staff, no worries from me. I'd be happy to discuss exactly what that means to you and I'd also be interested in knowing how your people perceive your style of management.
Now, to be sure, there is some overlap in some of the words. If the intent of "Control" follows the defntitions I found, I am simply not interested. If the intent of "Manage" follows the definitions I found, I may be interested and would be willing to talk about it. Having said that, if your use of "manage" really means "control" - I'm not going to play along.
Managing and Controlling are far from the same concept. If you want to be a Manager, consider just what the differences are.
One was interesting in the "What is this guy talking about?" sort of way.
His assertion was that Exploratory Testing was fine for small groups of one or two testers. However, it was unsuitable for larger or regulated environments because testing could not be controlled. He also suggested that Exploratory Testing was not as thorough as fully scripted testing because you did not need to think about it before you did it.
Take a deep breath, Pete. Can we start with this, "What is the difference between Controlling and Managing?" His response was "None. They are the same thing."
Oh dear, oh my, oh dear.
Let's see. Being too lazy to look get out one of my physical dictionaries, I turned to Google and searched for "control definition", "manage definition", "controlling definition" and "managing definition". I very scientifically grabbed the top search results (that were not paid advertisements) and found this...
Control: –verb
1. to exercise restraint or direction over; dominate; command.
2. to hold in check; curb.
OR...
Control: -noun
1. the act or power of controlling; regulation; domination or command.
2. the situation of being under the regulation, domination, or command of another.
Then there is this...
Manage: -verb (used with object)
1. to bring about or succeed in accomplishing, sometimes despite difficulty or hardship.
2. to take charge or care of.
OR...
Manage: -verb (used without object)
1. to conduct business, commercial affairs, etc.; be in charge.
2. to continue to function, progress, or succeed, usually despite hardship or difficulty; get along:
Now then, we have looked at the roots, now let us look at the -ing words in question.
Controlling: -adjective
1. inclined to control others' behavior; domineering
And...
Managing: -adjective
1. having executive or supervisory control or authority
As I sit here, I think a bit on the interesting idea that Manage and Control are the same thing. Based on these definitions, I find it interesting that there can be a serious assertion made that they mean the same thing. Having said that, I know certain boss types who firmly believe this. Me, I'm far to liberal (at least in the traditional, apolitical sense of the word) to agree with this.
Liberal: -adjective
1. open to new behavior or opinions
2. favorable to or respectful of individual rights and freedoms
Now, if you want to exercise restraint or direction over your people (whom I suspect you refer to as "resources") or to dominate your staff or to hold them in check, have a great time. Your staff probably won't.
Oh, I won't be part of that game, either.
Now, if you want to be in charge and guide and supervise your staff, no worries from me. I'd be happy to discuss exactly what that means to you and I'd also be interested in knowing how your people perceive your style of management.
Now, to be sure, there is some overlap in some of the words. If the intent of "Control" follows the defntitions I found, I am simply not interested. If the intent of "Manage" follows the definitions I found, I may be interested and would be willing to talk about it. Having said that, if your use of "manage" really means "control" - I'm not going to play along.
Managing and Controlling are far from the same concept. If you want to be a Manager, consider just what the differences are.
Wednesday, June 22, 2011
Back in My Day: Confessions of a Curmudgeon
When I first got into software for a living, the idea of "structured" anything was the red-hot burning idea that was going to save software from the horrible/bad/evil practices of people who were inept/wrong-thinking/clue-less practitioners of hocus-pocus. Structure was going to save us. Then it was CAD. Then it was Object Orientation. Then it was blah, blah. You get the idea.
I heard some folks talking about some "New Ideas" that they had heard about. Fantastic ideas, I thought. Instead of centralizing everything on a host server, they could have servers in a bunch of different places and have them all talk to the host. Then response times would be faster and the users would be able to get faster response. Astounding, eh?
Anyone else remember that new idea from, oh, 20 years ago?
Wait, that is sounding really, negative.
Let me try again.
Back when I was heavily involved in bagpipe bands, there was an amused expression that was reserved for folks who had been involved in pipe bands some years before, and no longer were/
"The older I get, the better I was."
The fact is, people's perceptions will change over time as our experiences inform those same perceptions. In the pipe band world, it seemed to inflate what the abilities were.
In reality, I have learned, now that I am part of the same "club," is that some folks really REALLY don't like change. Change in any form is bad. At the same time, things change as they grow, or they wither and die. You can't maintain existence without change. Well, maybe you can, but it is not really existence, it is a museum display - almost a "living history" lesson.
Change is inevitable.
Once it was suggested that since I was so "set in my ways" I may not like the changes that were coming and I could have a hard time adapting to them.
I resisted the temptation to look around for my cane and wave it about calling that individual a "young whippersnapper." For one thing, I don't use a cane or a walking stick. For another, I sympathized with his perception and lack of life (and maybe professional?) experience that would lead him to say that.
The thought that crossed my mind was "It is this very experience I have that allows me to see how he could have a view like that. I have been around a while and I like things a certain way. I have liked things in different ways before that, too.
When comments like the above are made, or when I think on change and flexibility, my mind sometimes wanders back to the companies I have worked for, the shops I have worked in. No two were the same, even remotely. Some were happier than others. Some were more efficient than others. Some turned out really good work. Some were just jobs.
Some are examples of the same things I mentioned before. My own experiences shaped my perception of each of those organizations. As I learned more, I wanted to learn more. My views changed related to that job as I was working there. I learned and experienced different things in different areas.
What does all this have to do with anything, let alone each other?
Well, simply put, I read a blog entry by The Maestro a couple of weeks ago. My first reaction was "YES! EXACTLY" Then it made me think on some things.
What I discerned from that thinking is that each of these "revolutionary ideas" was intended to address a problem. Or at least, a perceived problem. The thing is that many are just that - perceived problems. I think the real cause is that people, myself included, don't want to do the painful self-examination that is required for real improvement.
It is easier to follow the herd and the glossy marketing people when they hold out a promise than it is to dig down and work on the problem we have. This leaves us the desperate grasping at the just-out-of-reach silver bullet.
This is, I suspect, the core issue with all the trends over the last 30 years in my experience, and more.
Unless you are willing to face and address your real problems, you will never fix them and will keep grasping at quick-fix solutions that are not.
Well, maybe I'm just being a curmudgeon.
I heard some folks talking about some "New Ideas" that they had heard about. Fantastic ideas, I thought. Instead of centralizing everything on a host server, they could have servers in a bunch of different places and have them all talk to the host. Then response times would be faster and the users would be able to get faster response. Astounding, eh?
Anyone else remember that new idea from, oh, 20 years ago?
Wait, that is sounding really, negative.
Let me try again.
Back when I was heavily involved in bagpipe bands, there was an amused expression that was reserved for folks who had been involved in pipe bands some years before, and no longer were/
"The older I get, the better I was."
The fact is, people's perceptions will change over time as our experiences inform those same perceptions. In the pipe band world, it seemed to inflate what the abilities were.
In reality, I have learned, now that I am part of the same "club," is that some folks really REALLY don't like change. Change in any form is bad. At the same time, things change as they grow, or they wither and die. You can't maintain existence without change. Well, maybe you can, but it is not really existence, it is a museum display - almost a "living history" lesson.
Change is inevitable.
Once it was suggested that since I was so "set in my ways" I may not like the changes that were coming and I could have a hard time adapting to them.
I resisted the temptation to look around for my cane and wave it about calling that individual a "young whippersnapper." For one thing, I don't use a cane or a walking stick. For another, I sympathized with his perception and lack of life (and maybe professional?) experience that would lead him to say that.
The thought that crossed my mind was "It is this very experience I have that allows me to see how he could have a view like that. I have been around a while and I like things a certain way. I have liked things in different ways before that, too.
When comments like the above are made, or when I think on change and flexibility, my mind sometimes wanders back to the companies I have worked for, the shops I have worked in. No two were the same, even remotely. Some were happier than others. Some were more efficient than others. Some turned out really good work. Some were just jobs.
Some are examples of the same things I mentioned before. My own experiences shaped my perception of each of those organizations. As I learned more, I wanted to learn more. My views changed related to that job as I was working there. I learned and experienced different things in different areas.
What does all this have to do with anything, let alone each other?
Well, simply put, I read a blog entry by The Maestro a couple of weeks ago. My first reaction was "YES! EXACTLY" Then it made me think on some things.
What I discerned from that thinking is that each of these "revolutionary ideas" was intended to address a problem. Or at least, a perceived problem. The thing is that many are just that - perceived problems. I think the real cause is that people, myself included, don't want to do the painful self-examination that is required for real improvement.
It is easier to follow the herd and the glossy marketing people when they hold out a promise than it is to dig down and work on the problem we have. This leaves us the desperate grasping at the just-out-of-reach silver bullet.
This is, I suspect, the core issue with all the trends over the last 30 years in my experience, and more.
Unless you are willing to face and address your real problems, you will never fix them and will keep grasping at quick-fix solutions that are not.
Well, maybe I'm just being a curmudgeon.
Tuesday, June 14, 2011
What Can Be So Hard About That? Or, Why Do Some Folk Think Other Folks' Jobs Are Easy?
A funny thing happened the other day. I overheard some "sophisticated" city-dwelling folks talking about farming. To be more accurate, it was a group of folks from one of the "more affluent" suburbs of the city I live in. The kids were a little uncomfortable with their surrounding, a small-town eatery that had opened a really nice "deck" by a river. This was in a really rural area catering to farmers and their families. The deck was clearly a "let your hair down" establishment for young folks, farmers kids and younger farm hands to enjoy a cool beverage. It was also a short drive off the expressway, which is how they, and we, landed there.
So, the lady-wife and I were observing the to-and-fro of the regulars and these self-same sophisticated folks. One of the women made a comment that made me blink. "People talk about farming as if it is so hard. I don't know what they are talking about. You've seen my garden, that is some work, but really, how much more work can that be than my garden?"
The lady-wife's eyes looked like saucers (she's a Master Gardener and regularly says she's glad to not be a farmer). For me, I was not surprised. I was reminded of comments I've heard other people make like "Its just testing! How hard can that be!"
To be fair, I've also heard testers say things like "Why don't the developers get it right so we don't find stupid mistakes like this?"
You see, it strikes me that some folks simply don't get it. Whatever "it" is, they just don't get.
Here's what I mean. You've all heard that "a little knowledge is dangerous," right? If you have a small amount of experience with a tiny portion of what someone else does for a living, there is a tendency to extrapolate that experience to being what those who do this for a living do.
Many of us testers have run into the developer or project manager or some other manager type who sputters about how much time testers take and how can it possibly take "that long" to test - That it doesn't add anything and just slows the project down and you can get it done faster if you just...
What comes after that varies, but you get the idea, right?
Kind of troubling for those of us whose profession and craft is "just testing." No?
Then why do we say the same thing about developers? (See? I'm being polite.) A lot of times I'll say something like "software program code writers" since there are far more folks in "software development" than those who write the code. Yes, I know. I'm not nice sometimes. Yeah, sometimes I yank chains. At the same time, there are many, many more people in software development than the people called "developers."
I know, I'm kind of off in the weeds.
But not really.
When one group sets themselves or their craft above the skills of others as more sophisticated, challenging, difficult, advanced, whatever, it becomes easy to take the next step and raise yourself a notch or two over those who work with you, but are in the "lesser-skilled" trades and crafts.
I've done Project Management and Business Analysis. I've done programming (which at the time I started working in software included design and requirements gathering and communicating with business users.) I'm doing testing now. I've dabbled in DB stuff - enough to know I'd not be a good DBA - no passion or patience for it.
I do not understand how people can look down on others in a difference craft. All of them take specific skills, training, focus and discipline. To do them well, each of them are demanding and challenging and at the same time, they very rewarding.
There are a lot of instances where you see this mindset - something is easy to master because you can get the basics in 10 or 15 minutes. Learning to apply them is the hard part. Learning to master them takes longer. Just exactly how hard is it to do anything?
Want to find out? Try it. If you are a tester without development experience, try learning a programming language then try writing a simple program. Then test it. How many bugs did you find? If you have some development experience, try your hand at project management - at least get a bit of training then try to apply that training at work. Let's see what happens.
If you dabble a little bit, or took a course in college X years ago, you're an expert, right? Maybe the little exercise above will help you understand a tad more. How hard can anything really be?
After all, it is just testing, right? How hard is that?
So, the lady-wife and I were observing the to-and-fro of the regulars and these self-same sophisticated folks. One of the women made a comment that made me blink. "People talk about farming as if it is so hard. I don't know what they are talking about. You've seen my garden, that is some work, but really, how much more work can that be than my garden?"
The lady-wife's eyes looked like saucers (she's a Master Gardener and regularly says she's glad to not be a farmer). For me, I was not surprised. I was reminded of comments I've heard other people make like "Its just testing! How hard can that be!"
To be fair, I've also heard testers say things like "Why don't the developers get it right so we don't find stupid mistakes like this?"
You see, it strikes me that some folks simply don't get it. Whatever "it" is, they just don't get.
Here's what I mean. You've all heard that "a little knowledge is dangerous," right? If you have a small amount of experience with a tiny portion of what someone else does for a living, there is a tendency to extrapolate that experience to being what those who do this for a living do.
Many of us testers have run into the developer or project manager or some other manager type who sputters about how much time testers take and how can it possibly take "that long" to test - That it doesn't add anything and just slows the project down and you can get it done faster if you just...
What comes after that varies, but you get the idea, right?
Kind of troubling for those of us whose profession and craft is "just testing." No?
Then why do we say the same thing about developers? (See? I'm being polite.) A lot of times I'll say something like "software program code writers" since there are far more folks in "software development" than those who write the code. Yes, I know. I'm not nice sometimes. Yeah, sometimes I yank chains. At the same time, there are many, many more people in software development than the people called "developers."
I know, I'm kind of off in the weeds.
But not really.
When one group sets themselves or their craft above the skills of others as more sophisticated, challenging, difficult, advanced, whatever, it becomes easy to take the next step and raise yourself a notch or two over those who work with you, but are in the "lesser-skilled" trades and crafts.
I've done Project Management and Business Analysis. I've done programming (which at the time I started working in software included design and requirements gathering and communicating with business users.) I'm doing testing now. I've dabbled in DB stuff - enough to know I'd not be a good DBA - no passion or patience for it.
I do not understand how people can look down on others in a difference craft. All of them take specific skills, training, focus and discipline. To do them well, each of them are demanding and challenging and at the same time, they very rewarding.
There are a lot of instances where you see this mindset - something is easy to master because you can get the basics in 10 or 15 minutes. Learning to apply them is the hard part. Learning to master them takes longer. Just exactly how hard is it to do anything?
Want to find out? Try it. If you are a tester without development experience, try learning a programming language then try writing a simple program. Then test it. How many bugs did you find? If you have some development experience, try your hand at project management - at least get a bit of training then try to apply that training at work. Let's see what happens.
If you dabble a little bit, or took a course in college X years ago, you're an expert, right? Maybe the little exercise above will help you understand a tad more. How hard can anything really be?
After all, it is just testing, right? How hard is that?
Subscribe to:
Posts (Atom)
