Test Personas You Should Not Work With

No votes yet.
Please wait...

If you work at a company that develops software for users, then you should have definitely met such a concept as a test persona.

What is a persona? A persona is in some way a representation of a certain type of end-users of software that is being developed.

For example, if the X company develops a website that sells private houses, then one of the engaged test personas should be an owner or a resident that has recently bought a house and can provide useful information on how to select a house for sale.

Christine Jackvony, a famous QA engineer, gives us top 4 examples of test personas that you should never work with. So let’s analyze these imagined personas.

Bad Examples of Test Personas

Bad Examples of Test Personas

Test persona 1 (Ted)

Ted likes to run manual tests and delete them when work is finished.

He is really satisfied when watching a test run process.

He is not really interested in the way software functions, he just likes to do only what he is asked to.

But since he doesn’t really understand software functionality, he misses critical defects.

If he notices that software functions improperly, he doesn’t add this information to a test plan, not paying attention to it.

He believes that his main task is to test software but not be aware of specific of its work. And it’s a big disadvantage for a quality assurance team.

Test persona 2 (Anna)

Anna thinks that she is a world-class automated tester. She sees manual testing as just meaningless waste of time.

She prefers to work on some very complex tasks such as creating and maintaining automated tests.

When a new feature is created, she doesn’t think about exploratory testing, she simply starts creating software code since she believes that automation helps to find even the most invisible bugs.

What common features do Ted and Anna have?

They make the same mistake every day: none of them ever wants to spend his/her time studying software functionality.

They always miss defects due to the lack of such understanding: Ted doesn’t understand software code that makes a feature work and Anna doesn’t know specific of using software.

Test persona 3 (Patty)

Patty always assures software quality. She is very happy when everything works properly but she prefers such things as a process and standards of testing.

She hopes that other team members will follow her test plans and methods.

She believes that all regression tests should end when exploratory tests start but since regression has many tests, a big hitch takes place.

Unfortunately, if there is a release every month, a project team has no time to perform exploratory tests.

Test persona 4 (Ray)

Ray also thinks he is completely responsible for software quality so no bug should be missed.

When Ray opens a website in IE11 and sees a broken layout, he will do everything to find the reason for the bug’s appearance.

He can spend weeks studying the problem and he doesn’t care that IE11 is used only by up to 10% from all popular web browsers. He should find out all secrets.

What common features do Patty and Ray have?

They just waste their working time. They are focused on everything but primary tasks: developing qualitative software that contains as few bugs as possible.

Patty is so focused on a testing process that doesn’t understand the importance and necessity to perform exploratory testing, that helps to find new defects.

And Ray is so focused on studying every bug that simply ignores important testing processes, that may be helpful for much more future (potential) users.

Instead of conclusion

Sometimes each of us can act as some type of a test persona. But if we know the details of each of them, we can stop being Patty or Anna.

Good QA engineers know well their software, can take only conscious decisions on what to test and how and constantly improve their skills by making their software testing methods better.

Leave A Comment