I had intended to write this last night. Alas, I was far too exhausted and flopped into the hotel room with the telly and the lady-wife, and promptly fell asleep.
So, Yesterday was an astounding day. I met a scad of people in person I had previously only met cyberly. That, if for no other, is an astounding reason to attend a conference.
The Who's Who I met... Ajay Balamurugadas - Yes, the fellow who came up with Weekend Testing, the point-man/advocate for self-education and training in India. Lanette Creamer - Testy Redhead, bright and enmthusiastic ball of energy. Johan Jonasson - from Sweeden, an enthusiastic and crazy smart advocate of context driven testing. Elan Houser who I met in a BBST course - really great thinker. Simon Schrijver - SimonSaysNoMore on Twitter - an astoundingly intelligent thinker. Neil Thompson Anna Royzman, Todd Mazierski, Robert Berqvist, Geordie Keitt, Ben Yaroch, Felipe Knorr Kuhn all were speakers in the Emerging Topics track I was helping moderate and helped coordinate.
I had an amazing dinner with Neil Thompson, Fiona Charles, Anne-Marie Charret, my lady-wife and ... EGADS! I've forgotten the name of the other lady/diner/participant! I'm Sorry! It was a fantastic conversation with little to do about testing, but EVERYTHING to do about testing.
Michael Bolton gave a Keynote yesterday that was thought provoking and interesting in developing thought ideas. Part of his theme was picked up in Geordie's ET session at the end of the day yesterday. It will be revisited later today with a track session with James Bach and Doug Hoffmann discussing the idea that the Schools of Software Testing is a divisive idea, or not.
There were other crazy smart people, HOWEVERR - I'm going to bail and write more later. BECAUSE! Sitting next to me right NOW is Markus Gaertner, Michael Larson, Matt Heusser and Ajay Balamurugadas and discussing the Tester Challenge they participated in last night. An astounding display of self-evolving thought.
Showing posts with label Exploratory Testing. Show all posts
Showing posts with label Exploratory Testing. Show all posts
Tuesday, August 9, 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.
Monday, May 23, 2011
Where No One has Gone Before: Exploratory Testing Lessons From Jean Luc Picard
Great. You started out with a plan, maybe you had scripts to follow, maybe you had a nice neat plan - and before you know it you're off in the weeds.
Or worse, before you know it you've stumbled into some area that is completely uncharted and unknown. Its as if you were navigating a sailing ship 500 years ago and realized you were smack in the middle of the area that said "Here be Dragons" or some OTHER undesirable slogan.
None of us ever intend to get that far "out there" - well, I don't normally anyway. Most of the folks I've worked with don't normally get that far "out there" either. Usually. Unless we feel like - well - seeing what's out there.
When that happens you have a couple of choices. You can punt and start over, writing this off as a weird anomaly. Sometimes when this happens folks shrug and say something like "I don't know how this happened. It must have been something I did wrong." Frankly, I've said that once in a while as well. Sometimes when I do that, in the course of re-tracing what I did I find where I should have zigged and I actually zagged. I sometimes will make a note of it to return and intentionally follow that path after finishing off what I intended to do.
The odd thing is that sometimes I find myself out in the weeds again, just as unexpectedly as I was the first time. So, the choice we all face is to see if we have an idea what caused the event this time OR we can see where we can get from where we are right now.
I sometimes think of this as "X-Treme Exploratory Testing." Instead of blasting our way through whatever we just ran into, we sometimes need to carefully unravel the threads that we have around us.
Do you remember the Star Trek TNG episode where the Enterprise picked up their own distress call saw a massive explosion and a debris field that was their own ship? It was kind of like Groundhog Day - they found themselves in a "time-space continuum anomaly" where they repeated the same incident without knowing it.
As luck would have it, several of the recurring characters had a sense of deja-vu - around the time they picked up the distress call as I remember it. Then Data began saying things that were, un-Data-like. So, they decided to try and send messages to themselves each time the repeated the process to let them know what they had tried - and they'd know if it worked or not by them not blowing up. Cool, no?
What if you don't have an Android - humanoid artificial life form, not the phone - to tell you what did not work? What if you find yourself trying to repeat the same process and finding yourself back in the weeds everytime?
For me, the simplest tool is a legal pad with a pen - and I make note of what is done. See? Who needs Lieutenant Commander Data when I have Ensign Note Pad? ;) Now, since I began doing this all kind of other cool tools have become available - Rapid Reporter is one. Try it - I've read rave reviews but have not had the opportunity to put it through its paces myself - I look forward to it in the near future, however.
My point, such as it is, Don't be afraid of the unknown. We're TESTERS - that is what we do! We find the unknown and make it known! We head off into the weeds and chart a course out and back again.
If you stick to the path laid down in the script, you will have a fairly safe round of exercises. It won't be testing - but it will be safely predictable and you will be able to show nice charts and pictures showing what is done and what is left to be done, and you may even find some bugs.
It is when you head out to see what you can see that you really learn the product, the application or how it works.
It is your job to boldly go where no one has gone before.
Or worse, before you know it you've stumbled into some area that is completely uncharted and unknown. Its as if you were navigating a sailing ship 500 years ago and realized you were smack in the middle of the area that said "Here be Dragons" or some OTHER undesirable slogan.
None of us ever intend to get that far "out there" - well, I don't normally anyway. Most of the folks I've worked with don't normally get that far "out there" either. Usually. Unless we feel like - well - seeing what's out there.
When that happens you have a couple of choices. You can punt and start over, writing this off as a weird anomaly. Sometimes when this happens folks shrug and say something like "I don't know how this happened. It must have been something I did wrong." Frankly, I've said that once in a while as well. Sometimes when I do that, in the course of re-tracing what I did I find where I should have zigged and I actually zagged. I sometimes will make a note of it to return and intentionally follow that path after finishing off what I intended to do.
The odd thing is that sometimes I find myself out in the weeds again, just as unexpectedly as I was the first time. So, the choice we all face is to see if we have an idea what caused the event this time OR we can see where we can get from where we are right now.
I sometimes think of this as "X-Treme Exploratory Testing." Instead of blasting our way through whatever we just ran into, we sometimes need to carefully unravel the threads that we have around us.
Do you remember the Star Trek TNG episode where the Enterprise picked up their own distress call saw a massive explosion and a debris field that was their own ship? It was kind of like Groundhog Day - they found themselves in a "time-space continuum anomaly" where they repeated the same incident without knowing it.
As luck would have it, several of the recurring characters had a sense of deja-vu - around the time they picked up the distress call as I remember it. Then Data began saying things that were, un-Data-like. So, they decided to try and send messages to themselves each time the repeated the process to let them know what they had tried - and they'd know if it worked or not by them not blowing up. Cool, no?
What if you don't have an Android - humanoid artificial life form, not the phone - to tell you what did not work? What if you find yourself trying to repeat the same process and finding yourself back in the weeds everytime?
For me, the simplest tool is a legal pad with a pen - and I make note of what is done. See? Who needs Lieutenant Commander Data when I have Ensign Note Pad? ;) Now, since I began doing this all kind of other cool tools have become available - Rapid Reporter is one. Try it - I've read rave reviews but have not had the opportunity to put it through its paces myself - I look forward to it in the near future, however.
My point, such as it is, Don't be afraid of the unknown. We're TESTERS - that is what we do! We find the unknown and make it known! We head off into the weeds and chart a course out and back again.
If you stick to the path laid down in the script, you will have a fairly safe round of exercises. It won't be testing - but it will be safely predictable and you will be able to show nice charts and pictures showing what is done and what is left to be done, and you may even find some bugs.
It is when you head out to see what you can see that you really learn the product, the application or how it works.
It is your job to boldly go where no one has gone before.
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.
Subscribe to:
Posts (Atom)
