- Image via Wikipedia
A few months ago, I wrote about my first 3 months at Atlassian. I’ve been doing a lot of Exploratory testing. It’s taught me about following through on my own thought process when I’m asking important testing questions. I’ve gotten better at thinking through different scenarios while using an app. I’m not a master like the co-worker with whom I test everyday (He IS a master), but I’m improving and it feels good.
I have, however, felt that I have a dirty little secret. I’ve been carrying around with me since I started working at Atlassian and learning how to improve my Exploratory Testing skills.
Taking a deep breath…
I love code! I love it! I love it! I love it! I love writing it! I love reading it! I love breaking it! Compiling it makes me so freaking happy!
After a day when I’ve had my IDE open (I don’t care which one, any will do), I leave work feeling satisfied! The days when I work on automated tests or do anything with a script are always my best days at work, even if I’m tired, even if it took me a while to get results, even if I’ve endured crazy looks from the 5 people I had to ask in order to figure out WTF I am doing. Today, I came home after working through an automation problem with our test infrastructure expert and my brain was so tired that I could barely spell my own name, yet I feel energized. I love working with test automation.
So am I still a tester?
I’ve felt so conflicted about this lately. If I’m so interested in working with code and scripts, what does that say about me as a tester? Does this mean I’m a dev in disguise? Am I a wolf in tester’s clothing?
This situation reminds me of one of my best friends from college. She came out as bi-sexual during our freshman year. She was in a phase were she had a lot of questions about herself and the world around her as it related to this new way she had of defining herself. I remember she came home with me to see my hometown (we were effectively trading, I had been to see hers) and we went to a local lesbian bookstore. She asked the sales clerk if they had any books on bi-sexuality. “We might if it existed” the clerk sniffed. Once we were outside of the store, my friend explained that even within the gay community, bi-sexuality was a somewhat controversial topic.
What my friend taught me, is that there are areas within human existence that we might try to neatly categorize, but in the end, people are too beautifully messy for labels to apply. We are labeled in many areas of our lives including our careers. So if I self-identify as a tester, does that mean that I am creating a career trajectory for myself where I’m shunted away from code because I don’t have a developer job on my resume? Will I be ostracized by some in the testing community because I tend to embrace code alongside exposing its flaws?
Here is where I think the truth lies:
- There are people who who see testing skills and coding skills as mutually exclusive as are the people who fill those jobs. I hope I never work for them.
- We’re never going to solve big problems in testing unless some of us are not just passable, but extremely good at writing and architecting code.
- Not having the word “developer” on my resume doesn’t mean I don’t know how to work with references or that I can’t recurse through a stack of calls.
- Exploratory testing skills such as observing, questioning and critical thinking are just as important as coding skills. There’s no compromise here.
- There are other testers who also self-identify as straddling the dev-test line. They are my heroes and role models. (Perhaps they deserve their own blog post, if I named them and why, this post would be quite lengthy).
I’m finished with the part of my career where I justify my identity as dev-test to myself or others. The tagline next to my name means the same thing today as it did when I put it there. I’m guessing that it will take me longer to become masterful at both sides of this equation as well as the resulting intersection, but I will not stop trying.
Good for you! I sit on the developer side of the line, but I still consider testing to be a significant part of my responsibilities. I wish I could convince more of my colleagues to see things the same way.
I’m sure your interest in coding helps when you’re working with developers. Any time two people from different disciplines are working together it helps to have an understanding of how the other’s job works.
A little history: http://chrismcmahonsblog.blogspot.com/2007/02/bay-area-td-dt-summit-happened.html
Dev – Tester: both engineer. I guess it would be great for each developer to understand core testing as it would be great for each tester to understand core development.
Nice post, it sounds like you are gaining a good mix of skills.
One of our recent recruits was a wannabe developer who we’d hired with a view of helping improve our automated tests. He actually said he’d like to eventually work his way into a development role in his interview, no biggie we liked him & even if we got a few years out of him then that’s all good. However this said developer now groans whenever he has to do a bit of coding, a convert? possibly? I think personally he enjoys manual testing a lot more.
On the other end of the spectrum a couple of years back we’d hired an experienced performance tester, who spent a few years with us. He was very talented but getting results from his talent proved difficult, he lacked passion for testing. He after a long career in testing has now moved on to the land of development.
Myself I think I’m in the in between land, I love both, I might favor manual testing slightly more, but pro-active testing is what really makes me tick, that’s where I get my kicks
You hit on a few of the things I think are critical for good testing.
The first (and the subject of an internal talk I’m giving tomorrow) is Balance. Too much of one thing is bad for testing – more balance in any aspect makes you a better tester.
A metaphor I use too frequently is “the testers toolbox”. Testing well is much harder than most people (including most testers) realize. A tester needs a deep toolbox in order to solve problems, and “technical skills” give you a huge advantage. The other half of that is using the right tool for the right job (“if all you have is a hammer …”). Plenty of testers with technical skills don’t know how to leverage their tech skills to make them a better tester.
A testers mind combined with the processing power of a computer is huge. Thanks for coming out!
Welcome out of the closet! I’m right there with you. I discovered some years ago that I like making stuff just as much as breaking it. Like you, I consider myself to be both a developer and a tester. Also like you, I do not like to be constrained by someone else’s pre-defined categories.
hi Marlena,
great to have such self-assessment occasionally to move forward while still looking at the rear-view mirror.
about “dev test exclusive” — I think having the coding knowledge and “passion” is a complimentary to each other and not exclusive.
I agree about your observation- having seen the IDE and writing some code in a day, would give a greatest satisfaction. I think we need to leverage that skill into better testing. As @AlanPa [ http://marlenacompton.com/?p=1877#comment-5907 ] pointed out, a great set of tools in our pockets that we could leverage.
I am currently adding another complexity to myself with my role getting into project management aspects. i recently received peer feedback to transition to project management; but i love testing, coding and design. :)
about #4 on ET/Coding – absolutely they are 2 faces of the same coin and go hand in hand. End of the day, our customers, the end users. whta good is coding without ET approach, they are certainly complimentary. I think we need both skills concurrently. i like your tag.
I suppose I’m a closeted bitestual as well, for all the good it may do us. ;-)
Unfortunately the either/or dichotomy for testers is true for everyone else in IT as well. As long as people are seen as (and hired as) technical assets, it will be difficult for some to see nuance and versatility as an asset.
Bravo!
Keep blurring that line, Marlena!
As long as you can look at the code you’re writing and be reasonably sure the time wouldn’t have been better spent doing something else, there’s no problem being tester/dev-toolsmith. I love the times when I’m coding and script hacking, but the discipline to put away the IDE and start testing again always seems the hardest thing.
Oh, I’m so glad to read this. Test automation is probably really my favorite thing, and I’m in heaven using IntelliJ to work on FitNesse, Watir and Canoo WebTests. I probably spend more time doing exploratory testing, and yes, I love that too, but having started my career as a programmer – it might be that automation is my first love.
Great post.
I encourage all of the testers in my group to code, on project work, test automation, and tool creation, or even personal projects. In my own experience, knowing how to code and how software is built helps me to test it – I know what areas are more likely to have problems and I’m able to work with the devs to prevent issues before they make it into the build.
A balanced set of skills is great to have.
Thanks for the comments you guys have made about my post. I’m writing this from a hotel in Kuala Lumpur, Malaysia which is why I’ve been a bit delayed in responding back. (and that’s another post entirely).
I love the mix of testers and developers who’ve responded to this post which has clearly struck a chord. In reading through the comments, some of the points that stood out to me:
There are some ideas in there I’d like to chase down a bit further. But for now, I think I’ll go admire the view.
Appropriate as I was able to use the term ‘dev-curious’ last week at work ;)
I loved this piece. It makes me want to get coding again. I just haven’t done nearly enough of it for the last few years.
The most fun I had coding wasn’t in a dev role, which was often rather boring. It was working as an auditor on fraud investigations, trying to write smarter ways to gather evidence, and find patterns, to understand just what had been done.
Also, as a test manager carrying out the initial planning for Y2K at a big insurance company I was writing some fancy code to crawl through the libraries with the production programs, JCL and schedules to understand where all the inter-dependencies were.
I loved all that coding. I wasn’t’ any less an auditor or a tester because I could code. It just meant I was more effective at those particular jobs. The routines I was writing were a powerful means of understanding what was going on. How could that be any more relevant to testing?