So, part of my daily morning ritual is to check email, check logs for runs I may have kicked off overnight, then check the "sanity" file. That contains links to a few comics on the web. One is Dilbert (duh, its like computer/engineer/geek/argue-about-best-Star-Trek-series heaven) the other is a web comic called Urban Jungle.
One of the Urban Jungle comics last week was interesting. For folks who've done anything for a period of time, the idea of burnout, or "Why am I doing this?" may not be a completely unknown feeling. Keeping that feeling at bay can sometimes be a challenge.
Now, Lynn McKee has given some really, really good stuff on testers, motivation and passion. I've attended two session she presented where she has done a fantastic job of moving people, particularly testers, forward to find ways to keep testers, and their leaders, passionate about what they do.
Other folks have made the observation that the problem for many leaders is to avoid de-motivating them.
Generally, I'm in the "You're responsible for finding your own inspiration" camp. Most of the time I think testers can and should seek out and develop their own sense of purpose and motivation - the drive to become better.
Now, I know that is not going to happen with every tester. I've worked with some who learned things thus and see any attempt to change thus as an accusation that doing thus is wrong or bad. Reminds me sometimes of the quote (I don't recall who said it) that people are more firmly wed to their ideas than to their spouses.
I also know that some folks will do what they are told to do and figure that the easiest way to get along is to, well, get along and not "make waves." After all, if you make waves or stick your neck out or do something non-conformist, bad things may happen.
If I were to think seriously about this, I'd suggest folks, managers and bosses and workers alike, think about what they do. If everything is going great do you need to consider learning something different? Are there newer skills that you can pick up? Are there new ideas getting floated around out there? How about new technologies?
I understand some reluctance on several of those points. I probably share them. After all, most folks who have done anything with computers or software for more than a few years have seen ideas bubble up, get embraced as the "next great thing" then fade away into oblivion. The funny thing is, a few years later a new name will be slapped on the idea or approach and it will be repackaged and rebranded as the "next great thing."
So what does that mean for you? Are you so complacent as to rest absolutely assured in what you do that you can wait for the bosses to tell you the next thing to learn? Are you so certain that what you are doing now will be the way you are doing things in five years? Really? Will there be no new ideas that can enter your thinking? Will there be no new insights to drive your curiosity?
If you are a testing boss, do you mandate every minute of what your people do? How about your resources? Are your people resources, like reams of paper or ink and toner cartridges? Are your people assets to be developed and nurtured?
If I was the Universal Lord of Testing, with the authority to mandate one thing to all testing groups and bosses everywhere, it would be this: Allow some time each week for your people to see if there is something of interest to them that they want to learn more about. Then, let them learn about that.
Foster the sense of curiosity and excitement that you felt when you were learning about computers and software and programming and all the way-cool technology stuff. Even if the first machine you worked on is now sitting in a museum, I suspect you had that feeling once upon a time.
If you are not a boss and are a tester, I'd mandate this: Make the time to look for something of interest to you that you want to learn more about. Even if the boss does not "permit" it, the boss is ignoring the order from the Universal Lord of Testing (me) and therefore that "don't do it" order you get from them is improper and MUST be ignored. Even if you spend a few minutes at home, you know, your "own" time, surfing the web, looking up on-line testing discussion groups or looking for a local testing group, you may find more rewarding things than you know currently exist.
As my lady-wife is fond of saying, "In 10 years, you'll be 10 years older whether you do anything to make yourself better or not. You may as well make yourself better during that time." She's really smart that way.
So, you take charge of your own career. Join an association - even if you need to pony up the membership fees yourself. Buy some books, even if the company won't reimburse your expenses, the read them. Find someone to share ideas with - or just ask questions of them. Find something that is of interest to you and learn about it.
The tricky thing is that it doesn't matter if you're a tester or a boss or, something else. You can learn and improve and discover things to make yourself better. If you're a boss, lead by example. If you're not a boss, check what the boss is doing. If the boss is always looking for new stuff, new ideas and new thoughts, tune in and see what is happening. Maybe you'll learn something.
If the boss isn't doing that, meh, they're a boss not a technician. You're a tester. Make yourself better. Its your career.
Monday, January 17, 2011
Saturday, January 1, 2011
2011: A Look Forward
On SQA Forums, someone posted a question about "New Year Resolutions." There were many of the usual suspect types of responses, e.g., get in shape, lose weight, gain training, learn something new...
I posted that some years ago I resolved not to make any "resolutions," as in commitments to myself, that I knew I would most likely not be able to fulfill. Yeah, a little snarky, but it was also pretty honest.
Therefore, as my last post was a look back on 2010, as I was sipping a brandy last night chatting with my lady-wife as she knitted and some show was on television, I had some thoughts running through my head. Pretty sad, eh? The days of running off to the local Scottish Society's Hogmanay are distant memories. Most of our friends we'd get together and play music to welcome the new year are now widely dispersed. I wonder if that makes us "old" - Hope not.
Ah yes, my thoughts.
Some of this I actually started thinking about late last year. I sent some emails to a handfull of people asking them for assistance. In some ways looking for advice, and in otherways, to be sounding boards for my thought processes. There are changes coming that I've been pondering.
For most of my career in software, I've worked for someone else. For most of that time, it was working for companies where producing software was to support their primary business. The software was not their product, it supported the product or its delivery. To be honest, working on the product the company makes is fun. It can be frustrating when I don't have the option of actually talking to the people who asked for a change or enhancement, and I speak with people who may understand what the people who asked for they really mean.
The Road Ahead...
The interesting thing is I've been thinking about the future. Well, not THE future, but what lay ahead for me professionally and how that may impact the family. It would seem there are several items that are possibilities for the coming year. One path would be to look for new work opportunities, either as a contract/consultant or as a full time, permanent employee. Yeah, as if "permanent" means much.
Community
Another option is to become more involved in the testing community. Actually, I started working on that as well in 2010. What I mean is that reading blogs other folks write is a good way to learn what they're thinking is. Reading and participating in on-line forums is another way to both learn and become involved. Well, doing that as much as I can right now.
Of course, more actively engaging in both of these types of activities is on my list of things to do this coming year. Ya know, the funny thing is, the more I talk with folks about things I learn and have learned, the more I learn myself.
Local Testing Groups
Another thing, the local testing group, GR Testers, has been going in fits and starts for a while. Meetings have been sparse of late. The most recent one, December, was kind of fun. There were a bunch of us sitting around a table, lots of wings, good beer and folks talking about testing. Good way to spend an evening. There's another meeting coming up Monday, 3 January. It makes it the first time in quite a while that there were back to back monthly meetings. Normally, they are officially held every other month. It seems that as more people are showing an interest, the meeting frequency will pick up.
I wonder how many other local testing groups are out there that have a meeting schedule based on "whenever" instead of "We meet at this time, and here are the next couple of topics we're focusing on at these meetings..." I believe that the more people know about local groups, the more they are invited to participate and the more information that is available about them, the more active and the stonger the community there is.
I think that pretty well sums up what I'm looking to do with the local group. I believe that getting more people involved and talking about testing is vital to improving not only our individual tradecraft, but the abilities of the local community. Sharing well reasoned ideas can do nothing but good, presuming all are allowed to learn and ask questions
Personal Development
Now, I realize that any of the above activities can lead to improving any individual participating. What I mean here is something a bit more. I had been signed up for the BBST Foundations course offered by the Association for Software Testing for a session in in the fall of 2010. Things happened and that session was cancelled. I could not take the session offered as an alternative.
The GOOD news, for me, is I am signed up to take the Foundations course this spring. YEAH! I am really looking forward to this. Everyone I know who took the course raves about it. Big-time excited.
I've continued reading blogs and articles and books and talking with people and... everything else. My goal is to continue learning and to continue to share what I learn.
For conferences, I'll be attending and presenting at STPCon in March in Nashville. I bought myself a birthday present and renewed my AST membership in October. If I can work it out, I'll be attending CAST in August in Seatle.
At the day-job, I've continued to be a pest, and will do so for some time. The cool thing is the boss is good with it. Something about "pushing everyone to improve..."
So, that is a combination of goals, intentions and plans for 2011. What the future will really bring, I'm not sure.
On the other hand, the lady-wife did give me a list of places where she'd like to live should a relocation option present itself...
I posted that some years ago I resolved not to make any "resolutions," as in commitments to myself, that I knew I would most likely not be able to fulfill. Yeah, a little snarky, but it was also pretty honest.
Therefore, as my last post was a look back on 2010, as I was sipping a brandy last night chatting with my lady-wife as she knitted and some show was on television, I had some thoughts running through my head. Pretty sad, eh? The days of running off to the local Scottish Society's Hogmanay are distant memories. Most of our friends we'd get together and play music to welcome the new year are now widely dispersed. I wonder if that makes us "old" - Hope not.
Ah yes, my thoughts.
Some of this I actually started thinking about late last year. I sent some emails to a handfull of people asking them for assistance. In some ways looking for advice, and in otherways, to be sounding boards for my thought processes. There are changes coming that I've been pondering.
For most of my career in software, I've worked for someone else. For most of that time, it was working for companies where producing software was to support their primary business. The software was not their product, it supported the product or its delivery. To be honest, working on the product the company makes is fun. It can be frustrating when I don't have the option of actually talking to the people who asked for a change or enhancement, and I speak with people who may understand what the people who asked for they really mean.
The Road Ahead...
The interesting thing is I've been thinking about the future. Well, not THE future, but what lay ahead for me professionally and how that may impact the family. It would seem there are several items that are possibilities for the coming year. One path would be to look for new work opportunities, either as a contract/consultant or as a full time, permanent employee. Yeah, as if "permanent" means much.
Community
Another option is to become more involved in the testing community. Actually, I started working on that as well in 2010. What I mean is that reading blogs other folks write is a good way to learn what they're thinking is. Reading and participating in on-line forums is another way to both learn and become involved. Well, doing that as much as I can right now.
Of course, more actively engaging in both of these types of activities is on my list of things to do this coming year. Ya know, the funny thing is, the more I talk with folks about things I learn and have learned, the more I learn myself.
Local Testing Groups
Another thing, the local testing group, GR Testers, has been going in fits and starts for a while. Meetings have been sparse of late. The most recent one, December, was kind of fun. There were a bunch of us sitting around a table, lots of wings, good beer and folks talking about testing. Good way to spend an evening. There's another meeting coming up Monday, 3 January. It makes it the first time in quite a while that there were back to back monthly meetings. Normally, they are officially held every other month. It seems that as more people are showing an interest, the meeting frequency will pick up.
I wonder how many other local testing groups are out there that have a meeting schedule based on "whenever" instead of "We meet at this time, and here are the next couple of topics we're focusing on at these meetings..." I believe that the more people know about local groups, the more they are invited to participate and the more information that is available about them, the more active and the stonger the community there is.
I think that pretty well sums up what I'm looking to do with the local group. I believe that getting more people involved and talking about testing is vital to improving not only our individual tradecraft, but the abilities of the local community. Sharing well reasoned ideas can do nothing but good, presuming all are allowed to learn and ask questions
Personal Development
Now, I realize that any of the above activities can lead to improving any individual participating. What I mean here is something a bit more. I had been signed up for the BBST Foundations course offered by the Association for Software Testing for a session in in the fall of 2010. Things happened and that session was cancelled. I could not take the session offered as an alternative.
The GOOD news, for me, is I am signed up to take the Foundations course this spring. YEAH! I am really looking forward to this. Everyone I know who took the course raves about it. Big-time excited.
I've continued reading blogs and articles and books and talking with people and... everything else. My goal is to continue learning and to continue to share what I learn.
For conferences, I'll be attending and presenting at STPCon in March in Nashville. I bought myself a birthday present and renewed my AST membership in October. If I can work it out, I'll be attending CAST in August in Seatle.
At the day-job, I've continued to be a pest, and will do so for some time. The cool thing is the boss is good with it. Something about "pushing everyone to improve..."
So, that is a combination of goals, intentions and plans for 2011. What the future will really bring, I'm not sure.
On the other hand, the lady-wife did give me a list of places where she'd like to live should a relocation option present itself...
Friday, December 31, 2010
2010, A Retrospective
This year is drawing to an end. I know it is a tad lame to have a "look at the year that was" or any of the other cliche laden phrases that tend to be used to introduce these things.
The thing is, it has been an interesting year for me personally and professionally.
Let's see. General stuff. I retired the blog attached to my defunct drumming with bagpipe bands website. I replaced it with, this one. It had been in the "thinking about" phase for a long-time, and finally I decided to do it. Ya know what's interesting? As I think about other stuff - often Non-Testing stuff - something pops into my head about software development or testing or SOMETHING. Sometimes, that results in a blog post. Other times it leads to sitting in my big green comfy chair sipping a brandy and thinking.
Interesting work stuff at the day-job with interesting challenges early in the year. With a flurry of emails I found myself and the boss registered to attend QUEST in Dallas, Texas. This was a huge surprise to me as I was not expecting it at all, given limited budgets and going to TesTrek in Toronto the previous October. QUEST was interesting in that I met a number of people whose writings I had read, and had not met in real-life. I also got to connect with people I had met before and get back in touch in real-life.
May I received confirmation that I COULD attend CAST, which was being held around 15 minutes from my house - then in June it became clear that the scheduled release would conflict with attending CAST, so the company would neither pay the conference fee (something I was not too worried about) nor would they grant time-off. That one was a problem. July rolled around, schedules shifted again. I could be granted the time to go to CAST IF I was available during the conference. COMPROMISE! COOL!
Sunday evening of CAST had a great dinner and conversation with Fiona Charles and Griffin Jones and the lady-wife at a neighborhood Italian place. Recipes from Sicily and friendly folks and good wine and great conversation, little of it around testing, but all of it applicable to testing. What a great night.
Another night had a fantastic dinner out with a bunch of folks - Yeah, I know I blogged about that shortly after the event - it is still a great memory.
Dragged the boss in one evening to meet some of the great ones of the craft who would be there. Had a fantastic evening out with Nancy Kelln and Lynn McKee and the boss - more good wine (notice a trend?) and a great conversation.
Then, a bombshell was dropped that left me gob-smacked. It seems one of our dinner companions had a conflict and could not fulfill a speaking commitment in Toronto, would I be interested in being suggested as a an alternative speaker? Holy Cow. I thought about it briefly... and said Yes. One thing led to another and I did indeed speak at TesTrek in Toronto that October. Yeah, I blogged about that, too.
Stuff at the day-job continued to be interesting - meaning, really, really, busy.
So, things progressed. Talked with the boss about some interesting emails. The result of those chats was submitting proposals to a couple of conferences. I submitted proposals for a session similar to the session at TesTrek, but with a more advanced perspective than the general view there. The exciting thing was that the boss and I submitted a proposal for a joint presentation based on our experiences starting a QA/Testing team from scratch.
One conference said "no thanks" (although the boss was asked to consider a presentation in a different area) the other accepted both proposals! Yeah, that rocks. I get to hang with the cool kids at STPCon in Nashville this coming March.
More projects were successfully rolled out at the day job. There are some interesting things that seem to be happening there, they may lead to more ideas on blog posts.
The local testing group and its attempts spread its wings and fly has been great fun to watch and be a part of. Through it, I've met some terrific people, like Matt Heusser and Melissa Bugai , and have had fun sharing the adventure with them.
At home it was a good year in the garden. We had a good crop of strawberries and peppers and tomatoes, although some of the others were a little surprising in what were less prolific than expected. Several big projects got done - and inspired thoughts about, then blog posts about, software and testing.
We had some sadness in our lives this year. Stuff that led to serious rounds of soul-searching for "what is this all about." We also have had some great joys in our lives this year. For that, I am grateful. I don't know what 2011 will bring, but I am looking forward to the next year.
The thing is, it has been an interesting year for me personally and professionally.
Let's see. General stuff. I retired the blog attached to my defunct drumming with bagpipe bands website. I replaced it with, this one. It had been in the "thinking about" phase for a long-time, and finally I decided to do it. Ya know what's interesting? As I think about other stuff - often Non-Testing stuff - something pops into my head about software development or testing or SOMETHING. Sometimes, that results in a blog post. Other times it leads to sitting in my big green comfy chair sipping a brandy and thinking.
Interesting work stuff at the day-job with interesting challenges early in the year. With a flurry of emails I found myself and the boss registered to attend QUEST in Dallas, Texas. This was a huge surprise to me as I was not expecting it at all, given limited budgets and going to TesTrek in Toronto the previous October. QUEST was interesting in that I met a number of people whose writings I had read, and had not met in real-life. I also got to connect with people I had met before and get back in touch in real-life.
May I received confirmation that I COULD attend CAST, which was being held around 15 minutes from my house - then in June it became clear that the scheduled release would conflict with attending CAST, so the company would neither pay the conference fee (something I was not too worried about) nor would they grant time-off. That one was a problem. July rolled around, schedules shifted again. I could be granted the time to go to CAST IF I was available during the conference. COMPROMISE! COOL!
Sunday evening of CAST had a great dinner and conversation with Fiona Charles and Griffin Jones and the lady-wife at a neighborhood Italian place. Recipes from Sicily and friendly folks and good wine and great conversation, little of it around testing, but all of it applicable to testing. What a great night.
Another night had a fantastic dinner out with a bunch of folks - Yeah, I know I blogged about that shortly after the event - it is still a great memory.
Dragged the boss in one evening to meet some of the great ones of the craft who would be there. Had a fantastic evening out with Nancy Kelln and Lynn McKee and the boss - more good wine (notice a trend?) and a great conversation.
Then, a bombshell was dropped that left me gob-smacked. It seems one of our dinner companions had a conflict and could not fulfill a speaking commitment in Toronto, would I be interested in being suggested as a an alternative speaker? Holy Cow. I thought about it briefly... and said Yes. One thing led to another and I did indeed speak at TesTrek in Toronto that October. Yeah, I blogged about that, too.
Stuff at the day-job continued to be interesting - meaning, really, really, busy.
So, things progressed. Talked with the boss about some interesting emails. The result of those chats was submitting proposals to a couple of conferences. I submitted proposals for a session similar to the session at TesTrek, but with a more advanced perspective than the general view there. The exciting thing was that the boss and I submitted a proposal for a joint presentation based on our experiences starting a QA/Testing team from scratch.
One conference said "no thanks" (although the boss was asked to consider a presentation in a different area) the other accepted both proposals! Yeah, that rocks. I get to hang with the cool kids at STPCon in Nashville this coming March.
More projects were successfully rolled out at the day job. There are some interesting things that seem to be happening there, they may lead to more ideas on blog posts.
The local testing group and its attempts spread its wings and fly has been great fun to watch and be a part of. Through it, I've met some terrific people, like Matt Heusser and Melissa Bugai , and have had fun sharing the adventure with them.
At home it was a good year in the garden. We had a good crop of strawberries and peppers and tomatoes, although some of the others were a little surprising in what were less prolific than expected. Several big projects got done - and inspired thoughts about, then blog posts about, software and testing.
We had some sadness in our lives this year. Stuff that led to serious rounds of soul-searching for "what is this all about." We also have had some great joys in our lives this year. For that, I am grateful. I don't know what 2011 will bring, but I am looking forward to the next year.
Thursday, December 30, 2010
A Hero's Fall From Grace or Why a Big Pay Raise Is Better Than a Statue
A couple of things happened recently that made me think of things I probably would not normally think of.
I know a fellow who works for a company that has one or two (depending on needs) "major" releases each year. They also generate and distribute monthly maintenance releases to address defects, bundle hot-fixes neatly into a package and all the other good things that come from such things.
A recent release had some "issues." Lots of issues. After working for 12 "work" days and a Saturday and Sunday thrown in as well, this fellow's boss made a comment that he had "saved them again" and was a "hero."
When thinking about this, I got to thinking about Selena Delesie's blog posts on "hero culture."
When teams pull together and work to overcome obstacles, amazing things can be achieved. Sometimes, the issues encountered require extra effort and creative thinking and good, if not great, communication between testers and developers to find solutions. This is a fantastic thing and is, I believe, the point of being a "hero" in our profession.
The part that makes me think, if not wonder, about this is when this becomes the rule, rather than the exception. When the same team that pulled together and found solutions and worked toward delivering the best product that can be delivered is expected to work long hours regularly, to repeat the same "pull out all stops" effort for every project, big or small, there is a danger.
That danger is that the edge, the creative thinking, the "Hey, what if..." factor gets worn down.
Now, I know there are a lot of potential reasons for this to happen. Some may be within the team itself. There may be factors at work where individuals like the drama, the "rush" of the massive push at the end.
There may also be issues around the development methodology or practices. If the only testing done in unit testing is validating the "happy path" then likelihood that builds will come fast and furious, depending on how quickly the detected defects are addressed.
Another possibility is that someone, possibly in the test group or outside the test group but involved in the projects, likes the chaos - the frantic push is something they thrive on.
Whatever the cause, when every project turns into a heroic stand worthy of an action movie, something is seriously wrong. When testers, or anyone else, are expected to perform super-human, or heroic, feats every project, the edge will be blunted. The probability of significant defects being missed increases with each cycle. Eventually, people will be working less effectively no matter how many hours, or how "hard" they are working.
In some shops, the option to simply say "No, I won't do this" may be a legitimate one. In shops where contractual requirements don't allow such a response, I don't have a solution. Now, I am aware of the need to keep regular releases going, I'm just not sure of a solution that works everywhere.
What I do know is that the bosses, the leaders at your shop need to make sure they don't need their people to be heroes each and every release. Horatius held the bridge, but he had help. The lone cowboy was a myth, just like superman.
I know a fellow who works for a company that has one or two (depending on needs) "major" releases each year. They also generate and distribute monthly maintenance releases to address defects, bundle hot-fixes neatly into a package and all the other good things that come from such things.
A recent release had some "issues." Lots of issues. After working for 12 "work" days and a Saturday and Sunday thrown in as well, this fellow's boss made a comment that he had "saved them again" and was a "hero."
When thinking about this, I got to thinking about Selena Delesie's blog posts on "hero culture."
When teams pull together and work to overcome obstacles, amazing things can be achieved. Sometimes, the issues encountered require extra effort and creative thinking and good, if not great, communication between testers and developers to find solutions. This is a fantastic thing and is, I believe, the point of being a "hero" in our profession.
The part that makes me think, if not wonder, about this is when this becomes the rule, rather than the exception. When the same team that pulled together and found solutions and worked toward delivering the best product that can be delivered is expected to work long hours regularly, to repeat the same "pull out all stops" effort for every project, big or small, there is a danger.
That danger is that the edge, the creative thinking, the "Hey, what if..." factor gets worn down.
Now, I know there are a lot of potential reasons for this to happen. Some may be within the team itself. There may be factors at work where individuals like the drama, the "rush" of the massive push at the end.
There may also be issues around the development methodology or practices. If the only testing done in unit testing is validating the "happy path" then likelihood that builds will come fast and furious, depending on how quickly the detected defects are addressed.
Another possibility is that someone, possibly in the test group or outside the test group but involved in the projects, likes the chaos - the frantic push is something they thrive on.
Whatever the cause, when every project turns into a heroic stand worthy of an action movie, something is seriously wrong. When testers, or anyone else, are expected to perform super-human, or heroic, feats every project, the edge will be blunted. The probability of significant defects being missed increases with each cycle. Eventually, people will be working less effectively no matter how many hours, or how "hard" they are working.
In some shops, the option to simply say "No, I won't do this" may be a legitimate one. In shops where contractual requirements don't allow such a response, I don't have a solution. Now, I am aware of the need to keep regular releases going, I'm just not sure of a solution that works everywhere.
What I do know is that the bosses, the leaders at your shop need to make sure they don't need their people to be heroes each and every release. Horatius held the bridge, but he had help. The lone cowboy was a myth, just like superman.
Friday, December 17, 2010
On Exploration or How You Might Be Testing and Not Know It
I had an interesting conversation earlier this week. A colleague dropped into the cube, grabbed a handful of M&M's and muttered something about how she kept finding defects and wasn't able to get any test scripts written because of it.
OK - That got my attention.
So, I asked her what she meant. It seems that the project she was working on was not terribly well documented, the design was unclear and the requirements were mere suggestions and she had gotten several builds. So, she was working her way through things as she understood them.
So she explained what was going on... She intended to make sure she was understanding them correctly so she could document them and write her test scripts. Then, she could start testing.
The problem was, she'd try different features and they didn't work like she expected. So, she'd call the developer and ask what she was doing wrong. Problem: She wasn't.
The issue, as she saw it, was that the code was so unstable that she could not work her way through it enough to understand how she was to exercise the application as fully as possible. To do that, the standard process required test cases written so that they could be repeated and "fully document" the testing process for the auditors. Because she kept finding bugs just "checking it out" she was concerned that she was falling farther and farther behind and would never really get to testing.
More M&Ms.
So we talked a bit. First response: "Wow! Welcome to Exploratory Testing! Your going through the product, learning about it, designing tests and executing them, all within writing formal test cases or steps or anything. Cool!"
Now, we had done some "introduction to ET" sessions in the past, and have gradually ramped up more time in each major release dedicated to ET. The idea was to follow leads, hunches and, well, explore. The only caveat was to keep track of what steps you followed so they could recreate "unusual responses" when they were encountered.
Explaining that the process she was working through actually WAS testing lead to, well, more M&Ms.
The result of the conversation was that the problems she was encountering were part of testing - not delaying it. By working through reasonable suppositions on what you would expect software to do, you are performing a far more worthwhile effort, in my mind, than "faithfully" following a script, whether you wrote it or not.
Mind you, she still encountered many problems just surfing through various functions. That indicated other issues - but not that she was unable to test.
That thought prompted another handful of M&Ms, and a renewed effort in testing - without a script.
OK - That got my attention.
So, I asked her what she meant. It seems that the project she was working on was not terribly well documented, the design was unclear and the requirements were mere suggestions and she had gotten several builds. So, she was working her way through things as she understood them.
So she explained what was going on... She intended to make sure she was understanding them correctly so she could document them and write her test scripts. Then, she could start testing.
The problem was, she'd try different features and they didn't work like she expected. So, she'd call the developer and ask what she was doing wrong. Problem: She wasn't.
The issue, as she saw it, was that the code was so unstable that she could not work her way through it enough to understand how she was to exercise the application as fully as possible. To do that, the standard process required test cases written so that they could be repeated and "fully document" the testing process for the auditors. Because she kept finding bugs just "checking it out" she was concerned that she was falling farther and farther behind and would never really get to testing.
More M&Ms.
So we talked a bit. First response: "Wow! Welcome to Exploratory Testing! Your going through the product, learning about it, designing tests and executing them, all within writing formal test cases or steps or anything. Cool!"
Now, we had done some "introduction to ET" sessions in the past, and have gradually ramped up more time in each major release dedicated to ET. The idea was to follow leads, hunches and, well, explore. The only caveat was to keep track of what steps you followed so they could recreate "unusual responses" when they were encountered.
Explaining that the process she was working through actually WAS testing lead to, well, more M&Ms.
The result of the conversation was that the problems she was encountering were part of testing - not delaying it. By working through reasonable suppositions on what you would expect software to do, you are performing a far more worthwhile effort, in my mind, than "faithfully" following a script, whether you wrote it or not.
Mind you, she still encountered many problems just surfing through various functions. That indicated other issues - but not that she was unable to test.
That thought prompted another handful of M&Ms, and a renewed effort in testing - without a script.
Thursday, December 16, 2010
Measurements and Metrics, Or How One Thing Led to Another
So, once upon a time, my dear daughter and her beau gave me a combination "Christmas and New Job" present. Yeah, I was changing jobs in late December... What was I thinking? Not sure now, but it seemed like a good idea at the time.
Anyway, this gift was an M&M dispenser. Yeah. Pretty cool, eh? Turn the little thingie on the top and a handfull of M&Ms would fall through a little chute and come out the bottom. Not too shabby!
So, move along to the summer of 2008. The company I was working for had a huge, big, ugly release coming out. It was the first time with a new release process and schedule and nerves were pretty thin all the way around, developers, testers, support folks, bosses, everyone. Well, being the observant fellow, I realized that we were consuming a LOT of M&Ms - Of course, it helped that the dispenser was at my desk, in my humble cube/work-area.
So, I started keeping track of how much candy we went through. The only folks who partook of these multi-coloured delicacies were the QA/Tester group and a couple of brave developers who realized that we were not contagious and they could not catch anything from us. (They also learned that they might learn something from us and we testers might learn something from them.)
What I discovered was kind of interesting. As the stress-level went up, so did the consumption of M&M's. As things were going better and things were looking good, then consumption went down.
Using a simple Excel spreadsheet, I added up the number of bags eaten (it helps that they have the weight on them) as well as the partial bags each week. Then using the cool graphing tool in Excel, I could visually represent how much we went through. By correlation, the level of stress the team was under.
After about a month, I "published" the results to the team. SHOCK! GASP! We went through HOW MUCH??????
Then the boss sat down with me and looked at the wee little chart. "What was going on during this week?" Ah-HA! The first obvious attempt to match what the graph was showing. I tracked usage for the rest of the year. The amount the team consumed over the six months or so that I tracked, lined up remarkably with due dates and, interestingly, defects reported in testing.
One thing led to another, and the dispenser was put away for a time. In mid-2009, for reasons which now I don't recall, the M&Ms came back out. As the crew realized this, consumption went up. And up. And up. Eventually, I noticed that the same pattern demonstrated before was coming back.
I learned two things doing this exercise (which I continue to do.)
One, is that it is possible to measure one thing and be informed on another. Now, I am well aware of the First and Second Order (and other) Measurements described by some of the great ones in our craft. This exercise brought it home to me in ways that the theoretical discussions did not.
The other thing, sitting at a desk and making a meal of M&M's is a really, really bad idea.
Anyway, this gift was an M&M dispenser. Yeah. Pretty cool, eh? Turn the little thingie on the top and a handfull of M&Ms would fall through a little chute and come out the bottom. Not too shabby!
So, move along to the summer of 2008. The company I was working for had a huge, big, ugly release coming out. It was the first time with a new release process and schedule and nerves were pretty thin all the way around, developers, testers, support folks, bosses, everyone. Well, being the observant fellow, I realized that we were consuming a LOT of M&Ms - Of course, it helped that the dispenser was at my desk, in my humble cube/work-area.
So, I started keeping track of how much candy we went through. The only folks who partook of these multi-coloured delicacies were the QA/Tester group and a couple of brave developers who realized that we were not contagious and they could not catch anything from us. (They also learned that they might learn something from us and we testers might learn something from them.)
What I discovered was kind of interesting. As the stress-level went up, so did the consumption of M&M's. As things were going better and things were looking good, then consumption went down.
Using a simple Excel spreadsheet, I added up the number of bags eaten (it helps that they have the weight on them) as well as the partial bags each week. Then using the cool graphing tool in Excel, I could visually represent how much we went through. By correlation, the level of stress the team was under.
After about a month, I "published" the results to the team. SHOCK! GASP! We went through HOW MUCH??????
Then the boss sat down with me and looked at the wee little chart. "What was going on during this week?" Ah-HA! The first obvious attempt to match what the graph was showing. I tracked usage for the rest of the year. The amount the team consumed over the six months or so that I tracked, lined up remarkably with due dates and, interestingly, defects reported in testing.
One thing led to another, and the dispenser was put away for a time. In mid-2009, for reasons which now I don't recall, the M&Ms came back out. As the crew realized this, consumption went up. And up. And up. Eventually, I noticed that the same pattern demonstrated before was coming back.
I learned two things doing this exercise (which I continue to do.)
One, is that it is possible to measure one thing and be informed on another. Now, I am well aware of the First and Second Order (and other) Measurements described by some of the great ones in our craft. This exercise brought it home to me in ways that the theoretical discussions did not.
The other thing, sitting at a desk and making a meal of M&M's is a really, really bad idea.
Monday, December 6, 2010
Not the Happy Path or I am a Hi-Lo
I was at a local tester meeting tonight. Tons of fun and a great conversation. There was a student from a local college attending. In the course of the discussion we were discussing the dangers of trusting the "happy path." The student asked, "What do you mean by that?"
So, we explained about looking only for what "worked" and not investigating other issues that were more problematic and probably more error-prone. In the midst of this, a story from over 20 years ago flooded back into my memory.
Mind you, it influenced me greatly at the time. It led me to some of my early revelations of software, development, testing and "revealed truth."
When the IBM PC AT was state of the art, I worked as a developer (programmer) for a small manufacturer that had its own warehouses and distribution center for its finished product. The company was a family run company located in fairly old buildings, well, from the late 1800's and early 1900's. One individual was the nemesis of the software development folks.
He was in charge of the warehouse - both finished products and component pieces. Any sofftware running on machines in the warehouse had to be run past him for approval. These were scattered around the varous floors of the warehouses. Now, these warehouses were monsters. Support posts were massive beams, 24"x24". The PCs were usually located near a beam.
The very old warehouses had a very small amount of leeway for placing pallets and the like. Placing a case or pallet even a few inches away from where it was supposed to be could cause a fair amount of problems for the hi-lo operators moving material from one area to another.
The curious bit was that at least once a week, a h-lo would hit (referred to as "bump") a support beam. This was usually result from navigating away from mis-placed pallets. Sometimes it was simply the operator missing a turn. Once in a while, they'd hit the power conduit that powered a PC on an early network connection. Once in a great while, they'd "take out" the PC itself. Oops.
Back to my story.
This same nemisis of software developemtn was finicky. Extremely finicky. He wanted to make sure that any data entered could be retrieved under any circumstnace. If the user hit "enter" or "save" he had the expectation that the data would be fully retrievable.
His favorite tactic during demonstrations where changes or enhancements were being demonstrated, was to have the demonstrator enter components or finished part information. He'd sometimes have the demonstrator repeat the process. In the middle of the repeat, after clicking "save" or going to the next page, he'd say "I'm a hi-lo." and unplug the power cord.
He'd count 20 and plug it back in.
Then he'd sit down next to the demonstrator and say "Show me what you just entered."
If you couldn't, he refused to accept the change until it could pass his "test."
How much work is it for your users to recover their work after a "that will never happen" event?
So, we explained about looking only for what "worked" and not investigating other issues that were more problematic and probably more error-prone. In the midst of this, a story from over 20 years ago flooded back into my memory.
Mind you, it influenced me greatly at the time. It led me to some of my early revelations of software, development, testing and "revealed truth."
When the IBM PC AT was state of the art, I worked as a developer (programmer) for a small manufacturer that had its own warehouses and distribution center for its finished product. The company was a family run company located in fairly old buildings, well, from the late 1800's and early 1900's. One individual was the nemesis of the software development folks.
He was in charge of the warehouse - both finished products and component pieces. Any sofftware running on machines in the warehouse had to be run past him for approval. These were scattered around the varous floors of the warehouses. Now, these warehouses were monsters. Support posts were massive beams, 24"x24". The PCs were usually located near a beam.
The very old warehouses had a very small amount of leeway for placing pallets and the like. Placing a case or pallet even a few inches away from where it was supposed to be could cause a fair amount of problems for the hi-lo operators moving material from one area to another.
The curious bit was that at least once a week, a h-lo would hit (referred to as "bump") a support beam. This was usually result from navigating away from mis-placed pallets. Sometimes it was simply the operator missing a turn. Once in a while, they'd hit the power conduit that powered a PC on an early network connection. Once in a great while, they'd "take out" the PC itself. Oops.
Back to my story.
This same nemisis of software developemtn was finicky. Extremely finicky. He wanted to make sure that any data entered could be retrieved under any circumstnace. If the user hit "enter" or "save" he had the expectation that the data would be fully retrievable.
His favorite tactic during demonstrations where changes or enhancements were being demonstrated, was to have the demonstrator enter components or finished part information. He'd sometimes have the demonstrator repeat the process. In the middle of the repeat, after clicking "save" or going to the next page, he'd say "I'm a hi-lo." and unplug the power cord.
He'd count 20 and plug it back in.
Then he'd sit down next to the demonstrator and say "Show me what you just entered."
If you couldn't, he refused to accept the change until it could pass his "test."
How much work is it for your users to recover their work after a "that will never happen" event?
Subscribe to:
Posts (Atom)
