I heard that Gerry Weinberg has an exercise called “Mary hada little lamb,” in which you analyze each word in the sentence to elicit implicit meaning that might be important. This sounded interesting enough to try, so when the opportunity came to propose a topic at Test Retreat 2013 I went for it. My topic “Is testing for me?” didn’t end up formally scheduled but made a nice interstitial topic to discuss with those milling about in the main room.

I chopped the sentence into separate words and wrote them top-to-bottom on a large sticky note. Then, instead of giving some sort of prepared remarks, I elicited brainstorming from the gathered participants. Having received interesting feedback on my professional and personal strengths at Agile2013 that had left me questioning how best to use my evil powers for good, I wanted to hear how others were thinking about the testing field and how it fit them.

The resulting scrawled notes ended up a mindmap, the path of least resistance for me. I won’t say the discussion solved all my problems, but it did give me some direction for future exploration – exploration that might also be helpful to a newbie wondering whether to pursue a career in testing.

I started composing a list of things I’d recommend to people just starting out as testers to help them to evaluate whether to continue. I wanted to encourage them to jump right in but also think big, not waiting them to wait 5 years to reach out to the wider world of testing (like I did).

Here’s my current list. I blogged about various experiments I tried, so you can read for yourself to see what it’s like to select what’s a good starting point for you.

No matter how many times I think I’ve found all the meaning in my testing career, suddenly I realize there are more layers… but like a parfait, not an onion.

Donkey: Oh, you both have LAYERS. Oh. You know, not everybody like onions. What about cake? Everybody loves cake!
Shrek: I don’t care what everyone else likes! Ogres are not like cakes.
Donkey: You know what ELSE everybody likes? Parfaits! Have you ever met a person, you say, “Let’s get some parfait,” they say, “Hell no, I don’t like no parfait”? Parfaits are delicious!
Shrek: NO! You dense, irritating, miniature beast of burden! Ogres are like onions! End of story! Bye-bye! See ya later.
Donkey: Parfait’s gotta be the most delicious thing on the whole damn planet! – Shrek

It’s no secret: I adore testing software. It’s my weapon of choice, despite having happened upon it by chance many moons ago. (What other career transforms forgetfulness and clumsiness into strengths since they result in unexpected, non-happy path usage? Ultimately, I think it’s the variety that keeps me coming back for more on a daily basis.)

Given my feelings about testing, it came as no surprise to me that others would agree and rate this profession highly, whether on CareerBliss or elsewhere, as reported by Forbes. (I’ll also admit to having been a bit of an I/O Psych nerd back in the day, so this survey appeals to me in various ways.) I can’t seem to leave my curiosity at the door, so I had to go see for myself what questions were used as the basis of this data. (Yes, HR folks, that’s my story and I’m sticking to it.)

With categories like Company Culture, Work-Life Balance, The Place You Work, The People You Work For, The People You Work With, It’s Party Time!, Work Freedom, and Growth Opportunities, it almost felt like attending a company meeting at my current employer. (Did I mention we’re hiring a developer for my team?)

I was curious to see whether other testers had the same reaction to the questions used to generate the data that CareerBliss analyzed, so I culled out 5 questions of at-most-140-characters designed to find out.

Q1) Which people at work most affect your happiness: co-workers, boss, CEO?

Q2) How does the level of challenge in your work influence your feelings about your testing job?

Q3) Is there a job-provided perk/reward/tool that keeps you happy as a tester?

Not everyone has the same experience of software testing and my experience has certainly changed over time. I wanted to take a moment to consider the various aspects of software testing that the article identified:

requirements gathering – been there, done that both before and after implementation

documentation – frequent contributor, sometimes sole author

source code control – only for my automation code, but I didn’t set it up myself

code review – if you consider pairing with a developer on code during a sprint, then I’ve tried it and with some success

change management – not so much, though we did have a composition book in the testing lab to log all hardware changes to a system I worked on; sometimes it was more like a log of who I should hunt down to get the hardware back…

release management – the closest I get to this is being able to deploy to my cloud test environment and boy am I happy about that

actual testing of the software – bread and butter for me

I love having been involved in the entire software development process at various times during my career. (I’ve even prototyped some UI ideas, though I wouldn’t call that an area of strength or concentration. Glad to have those UXers on board these days!) I do feel that I’m an integral part of the job being done at the company. I am quite happy that my job involves frequently working with people.

However, I do take issue with this being presented as a positive aspect of the job:

software quality assurance engineers feel rewarded at work, as they are typically the last stop before software goes live

Doesn’t that smack of Gatekeepers to Quality to you? I don’t ever want to set up an adversarial relationship with my developers that says I need to defend the users against their disregard, and I don’t want to be involved only at the end as a last stop before kicking a product out the door. I know that happens at times but it’s not my preference. Positive personal interactions and preventative measures certainly contribute to my testing bliss.

Take the survey yourself at CareerBliss and let me know how your experience compares!

With only a week left in February, I’ll be wrapping up my own trial of the first Tester Merit Badge and posting my results, so I encourage you to try it for yourself. Do let me know if you’re playing along at home!

2. North, South, East, West.

Who says scripted test cases can’t be exploratory? Just because you have a protocol written down doesn’t mean your brain turned off when you began to execute it. As you go along working through a set of instructions, perhaps drawing from a user manual if you lack test scripts or specific test cases, keep your eyes open for what is going on around you, not just what fits the happy path of the case. Make notes of testing ideas and chase down something that’s off-script and keep track of what you do as you go along. If no test scripts or highly structured test cases exist for a particular aspect you want to test, skip ahead to requirement #3.

3. How Long and How Far.

Using an existing reference (if any) estimate the time to exploratory test an aspect of a feature of a software product. If you have been using test cases or test scripts for this testing, then use those as jumping off points for your exploration but don’t follow them. I tend to make a list of some test ideas and then pick and choose which ones to attempt during a particular exploratory session. If no ready-made resources exist for a particular aspect you want to test, skip ahead to requirement #4.

4. Walk the Distance.

Estimate time exploratory test an aspect of a feature of a software product without the aid of any existing materials. Use your knowledge and experience to take an educated guess at what needs to be done and build up a guess-timate. We’re going for ballpark and not precision here. Then, try it and see how close you were. That’s the beauty of iterative learning.

5. Map Maker. Map of the Place. Make a Model.

I see these physical representations of travel as essentially the same when it comes to software testing. This one is about precisely describing what you observe, which makes it a perfect artifact of your exploratory session. This could be a site map, a pairing of requirements description snippets with implemented user interface components, or even a sketch of different paths through a block of code (if you’re doing some white box preparation for your exploratory testing). We want to show what we observed rather than what we expect, so you can explicitly record your expectations if that helps you to clear your mind for the road ahead.

6. Finding Your Way Without Map or Compass.

Freestyle! Do some testing without any more explicit structure than a time box. Give yourself 15 minutes to wander around in an application without stating a particular agenda. You might even try accessing a piece of software through a less favored access point (e.g. a traditional website viewed from a smart phone).

7. Trail Signs Traffic.

This is an opportunity to write a different kind of test guide for another tester to follow. If we stick to the trail metaphor, you want to provide indications of the way out of the woods but you don’t dictate how the hiker travels between the boles of the trees bearing the blaze (or if you’re a big nature nerd the piles of rocks and sticks with their encoded messages about the trail ahead). I think Whittaker’s landmark tour is particularly apt for this example, so I recommend picking a part of your app to extract some landmarks. Avoid step-by-step instructions about how to wander between these milestones! You want to recognize the variation in execution that naturally occurs, even in the presence of a test script. In this case, doing it differently is a strength since you collectively will cover more of the application over time, although you may not encounter exactly the same scenery along the way.

8. Bus and Train Maps.

Use a publicly available source to map out a test. If you have a user manual for the application under test, that would be a good source for producing an expected route through an application. Just like a driver stuck in traffic, you don’t need to adhere to the planned route, so feel free to follow any detours that seem like better alternatives if you are feeling blocked or just want to take a more scenic route. Lacking a user manual for this particular product, try a description of some similar or competing product. Again, we’re exploring here, so having an inexact guide is no barrier to the experiment.

When you complete any or all parts of these badge “requirements” take a moment to reflect on whether the technique could be helpful to you in your regular testing work. You don’t have to migrate away from your current approach, but having some options always helps me to switch it up a bit when testing starts to feel monotonous – and I really think I’m doing it wrong when testing bores me! There is always too much testing to complete, so I certainly need to go exploring more often.

Drop me a line or post a comment here to let me know how the experiment went for you and I’ll post my own results here within the month.