One hat too many
I often hear that a challenge for testers who started out as programmers is shifting their mindset from creation to testing. That makes sense to me. That’s a big switch, to go from “How do I get this to do what I want it to?” to “How might this bug somebody who matters? Does this solve the problem?”
I am experiencing the reverse challenge. I started in testing and am now learning to write scripts in Ruby to help my testing. The struggle I have is keeping my focus narrowed on getting the code to do what I want. Instead, I constantly throw up stumbling blocks for myself:
“Oh, but what if somebody tries to do this?”
“What if we don’t have that data?”
“Ack, will that design take too long to run?”
“Well, this will work, but would it be nicer this way?”
“Someone might want to be able to do this later. Right?”
It makes for slow, painful, and inefficient creation. In fact, it reminds me of the path my writing process takes at times. Instead of focusing on creation — words on paper — I stop and think about the effectiveness of a sentence or word, or consider theme or some other big picture concern. What I do get done is typically of good quality… but is it worth spending more time and getting less done?
I find I am much more efficient and productive when I put the ideas down — all of them — then revisit for editing and revising (or “testing” — determining what might need editing and revising).
Hopefully I can find this mindset for scripting as well.
I’m also a tester learning Ruby. I find it helpful to fill my code with lines like:
#TODO: handle case when there is no data
Then I can more easily build the “happy path” and know that I’ll circle back and cover those corner cases later.
Thanks for your comment! Since writing this post, I’ve discovered the power of #TODO as well. It definitely seems to help to be able to assure your brain, “Ok, this will be taken care of. It’s ok to move on before you lose your next thought.”