Six Testing Personas to Avoid

If you are working for a company that makes software for end users, you have probably heard of user personas.  A user persona is a representation of one segment of your application's end users.  For example, if you worked for a company that made a website for home improvement supplies, one of your user personas might be New Homeowner Nick, who has just purchased his first home and might not have much experience fixing small things in his house.  Another persona might be Do-It-Yourself Dora, who has lots of experience fixing everything in her home herself.

It occurred to me recently that there are also testing personas.  But unlike our user personas, these personas are ones we want to avoid!  Read on to see if one of these personas applies to you.

1. Test Script Ted

Ted loves running manual test scripts and checking them off when they're completed.  It gives him a feeling of satisfaction to see tests pass.  He doesn't particularly care if he doesn't understand how his application works; he's just satisfied to do what he's told.  But because he doesn't understand how the application works, he sometimes misses important bugs.  If he sees something strange, but it's not addressed in the test plan, he just lets it slide.  His job is to test, not figure things out!

2. Automation Annie
Annie considers herself an automation engineer.  She considers manual testing a colossal waste of her time.  She'd rather get into the hard stuff: creating and maintaining automated tests!  When a new feature is created, she doesn't bother to do any exploratory testing; she'll just start coding and she figures her great automation will uncover any issues.

What Ted and Annie have in common:
Ted and Annie are making the same mistake for different reasons; they are not taking the time to really learn how their application works.  They're both missing bugs because of a lack of understanding; Ted doesn't understand the code that makes the features work, and Annie doesn't understand the use cases of the application.

How not to be Ted or Annie:
To be a thorough tester, it's important to take the time to understand how your features work.  Try them out manually; explore their limits.  Look in the code to see if there are other ways you might test them.  Ask questions when you see things that don't make sense.

3. Process Patty
Patty is passionate about quality.  She likes things to work correctly.  But she likes having processes and standards even more!  She's got test plans and matrices she's expecting her team to follow to the letter.  Regression testing must be completed before any exploratory testing is done, and there are hundreds of regression tests to be run.  The trouble is, with releases happening every two weeks there's no time to do any exploratory testing.  There's no time to stop and think about new ways to test the product, or what might be missing.  The team needs to get all those regression tests completed!

4. Rabbit Hole Ray
Ray is passionate about quality too; he doesn't want any bug to go unnoticed.  So when he sees something strange in the application when it runs on IE10, he's determined to find out what's wrong!  He will take days to investigate, looking at logs and trying different configuration scenarios to reproduce it. He doesn't want to be bothered with the standard regression tests that he's leaving undone as the feature is being released. And he doesn't care that only 1% of their customers are using IE10.  He's going to solve the mystery!

What Patty and Ray have in common:
Patty and Ray are both wasting time.  They are focused on something other than the primary objective: releasing good software on time with a minimum of defects.  Patty is so caught up in the process that she doesn't see the importance of exploratory testing, which could find new bugs.  And Ray is so obsessed with that elusive bug he's exploring that he's ignoring important testing that would impact many more users.

How not to be Patty or Ray:
When testing a new feature or regression testing existing ones, it's important to think about which tests will have the biggest impact and plan your testing accordingly.  Be careful not to get too caught up in processes, and if that elusive bug you're searching for won't be that impactful to end users, let it go.

5. Job Security Jim:
Jim's been working at his current position for years.  He knows the application like the back of his hand.  He's the go-to guy for all those questions about how the most ancient features behave.  He knows there's no way the company will let him go; he knows too much!  So he doesn't feel like there's any reason to learn new skills.  What he knows has served him just fine so far.  Who needs to waste time after work learning the latest programming language or the newest testing tool?

6. Conference Connie:
Connie is so excited about tech!  She loves to hear about the latest testing techniques and the latest development trends.  She signs up for webinars, goes to conferences, reads blog posts, and takes courses online.  She knows a little about just about everything!  But she's never actually implemented any of the new things she learns.  She's so busy going to conferences and webinars that she barely has time to do her regular testing tasks.  And besides, trying things out is a lot of work.  It's easier to just see how other people have done it.

What Jim and Connie have in common:
Jim and Connie seem like total opposites at first: Jim doesn't want to learn anything new, and Connie wants to learn everything new.  But they actually have the same problem: they are not growing as testers.  Jim is content to do everything he's already learned, and doesn't see any reason to learn anything more.  But he could be in for a shock one day if his company decides to rewrite the software and he suddenly needs a new skill.  And Connie has lots of great ideas, but great ideas don't mean anything unless you actually try them out.  Her company isn't benefiting from her knowledge because she's not putting it to use.

How not to be Jim or Connie:
It's important to keep your testing skills fresh by learning new languages, tools, and techniques.  You don't have to learn everything under the sun; just pick the things that you think would be most beneficial to your current company, learn them, and then try to implement them in one or two areas.  Your teammates will be thankful for the new solutions you introduce, and you'll be developing marketable skills for your next position.

Be a great tester, not a persona!
We all become some of these personas now and then.  But if we can be aware of them, we can catch ourselves if we start to slip into Automation Annie or Rabbit Hole Ray, or any of the others.  Great testers learn their application better than anyone else, they make good choices about what to test and when, and they keep their skills updated so their testing keeps getting better.