The Software Testing Club recently put out an eBook called "99 Things You Can Do to Become a Better Tester". Some of them are really general and vague. Some of them are remarkably specific.
My goal for the next few weeks is to take the "99 Things" book and see if I can put my own personal spin on each of them, and make a personal workshop out of each of the suggestions.
Suggestion #75: Use the box itself to help you. Look at the edges of your box. Create a bigger box, look at what is now in the box and decide what you might
want to follow up. Look at the edges again, can you push any of them out a bit? What would you find if you did? Do quick, cheap, experiments on stuff that seems unlikely to surprise you - because sometimes it will. --Anna Baik
There are two very valuable quotes that I turn to often, and I use them quite frequently. The first one I tend to attribute to Steve Covey. He may not have first said it, but he's the context in which I first heard it:
"Sometimes the greatest break-throughs come from breaks with."
The second one I do know its original source, and that is Albert Einstein:
“We can't solve problems by using the same kind of thinking we used when we created them.”
Both fit very well with this suggestion. Also, this one is so well worded that I'm not going to change a thing...
Workshop #75: Use the box itself to help you. Look at the edges of your box. Create a bigger box, look at what is now in the box and decide what you might
want to follow up. Look at the edges again, can you push any of them out a bit? What would you find if you did? Do quick, cheap, experiments on stuff that seems unlikely to surprise you - because sometimes it will.
One of the things that me and my test team have been working on is this large modular script. It's automation, but not quite. It's actually designed to aide exploratory testing, and we've been pairing on it and working through some interesting issues. What is it's purpose? We're designing it to be a TAXI cab.
Say what?
OK, this may require a little explanation. One of the things I have been working on and have become borderline obsessed with is the fact that we tend to look at automation as a hands off affair. We start a script, it runs, and we get a nice, pretty report when it's all finished. For some things, that's great. It makes a lot of sense to do highly repetitive tasks or run regression tests in this fashion. What it doesn't do is give us a chance to make real time considerations as to what is being displayed or what we are seeing. Also, as I often point out, it doesn't matter how we stack the containers or what order we put the rail cars, we're still on a set of rails that goes from point A to point B. We can modify our seat assignment, but that's about it.
Fully manual exploratory testing is the opposite end of the spectrum. We are completely unbounded, and can do anything we want to… but we are also human, fallible, and most importantly, we get tired and impatient. Getting into interesting scenarios and playing around with them is great fun, but sometimes there's so much we need to do, and so much we need to bring. It feels a bit like being dropped in the middle of Central Park in New York City, or at Ahikibara in Tokyo; just us, a backpack and a map. We can go anywhere, but we need to do it all on foot.
What we wanted to do instead was create something in between. A way to configure and move stuff around, go to interesting destinations, an then hoof it. When we're done, we get get back in, and be taken somewhere else. In short, automation not as a train, but as a TAXI cab.
Why am I mentioning this? Because too often we see the same things and we approach them the same way out of habit. We have great maps, but we only take one street to get where we want to go. Why not mix it up and try to do something different? Usually because it's not practical, and to be fair, this approach isn't "practical", either. It is fun, it it interesting, and we are seeing some very interesting scenery along the way. Yes, we are being surprised in the process… hey, did you know we could do that? Wait, where did this screen come from? I don't remember seeing *that* before!
I'm not suggesting that you need to go off the deep end and try to reinvent the way you test or rewrite a bunch of your automation code, but I am suggesting that you be willing to take a different look at how you approach common things, be willing to make a break with routine.
Bottom Line:
All of us have time limits and resource limits and demands that make it hard to break out of the mold that we are in, but we don't do our applications (or our customers) an favors by being set in our ways. To quote David Lee Roth: "…and I'm searching for the latest thing, a break in this routine. I'm talkin' some new kicks; ones like you ain't never seen!"
No comments:
Post a Comment