Nike Testing

When I started writing this blog I had no idea what I was going to write about. I don't remember that ever happening before - usually I know exactly what I want to talk about and more-or-less how I want to say it.

When I test, however, I find myself in a similar situation all the time: I sit down for a bout of testing and discover that I haven't a clue what to test or how to test it. For example, I currently own the entire Macintosh client for Live Mesh. How do I get started testing that?

If I don't know where to start, it probably doesn't matter where I start so long as I get started. Once I started writing this, I picked up momentum and eventually discovered that I had a pile of words - i.e., this blog post. Other times I discover that I have nothing, in which case I start over with a new first word. In both cases I learn about what I do or do not have to say about my topic.

Likewise, once I start testing I pick up momentum and eventually discover that I have a pile of defects to log. Or I discover that I have nothing, in which case I move on to a different area or switch to a different testing strategy. In both cases I learn about what I can and cannot say about the state of my application.

One reason I believe this Simply Get Started Already strategy works for me is that doing something - anything - gets me into gear, which I find to be a prerequisite for slipping into Flow. When I am in Flow, information flows effortlessly and I know exactly what to do, where to do it, and how to do it. If I'm not where I need to be, the information guides me there.

Until I start analyzing.

What is the best word to use here? Does that sentence flow as well as it could? Should this be one paragraph or two?

That isn't the functionality I meant to invoke. What's the proper order to go through this checklist? Would five objects be better than six?

Are these really the best examples I could give?

Are these repro steps really as short as they could be?

While I do not want to ignore these issues, neither do I want to sidetrack myself out of Flow. I find that editing myself is a surefire route out of Flow, whereas writing down the words as they come to me, and executing the tests as they come to me, without regard to their correctness or perfectness or Best Optionness, tends to take me deeper into Flow. By keeping these two states of consciousness separate, I can better focus on and stay in each one, and I ultimately make more forward progress and come up with an end result more to my liking than when I attempt to do everything all at once.

How about you? What do you do when you don't know what to do or where to start? Let me know!

*** Want a fun job on a great team? I need a tester! Interested? Let's talk: Michael dot J dot Hunter at microsoft dot com. Great testing and coding skills required.

Comments

• Anonymous
  August 07, 2008
  I take it differently. There are time when i get stuck (both with developing and testing) and when that happens, I just go with the flow. When I get stuck Testing something, I just start using it. For instance, recently I'm collaborating with our Quality Assurance team to test our Debugger. Sometimes I hit so many bugs that I wish someone else would report it for me and I could just go on and on finding them. Other times, I feel like I'm sitting in a perfect world using the perfect Debugger. When that happens, I Stop testing it and Start using it. I don't target any area to test, I ignore the test matrices, and I ignore my team lead :). I just become somebody who has paid a substantial amount of money to get his work done perfectly, and mostly its not so long before I realize that this is not a perfect world after all :). Its different when I get stuck while developing something and writing code/developing algorithms. When that happens, and I've got no clue where to go, I play cricket :) or pool or just go to the gym. I think its mighty dangerous if you are a developer and you keep on developing when you have no clue where to go. Its a recipe for a civil war between you and you tester:). Sometimes taking a break works while testing too after all it takes a lot of creativity to develop something (out of nothing but ideas). And it takes (creativity)^2 to test it since you need to know exactly what what the developer trying to achieve and be smarter to know where he has missed a footing.