Tag Archives: Abuse Cases

Learning about Personas – What I Read Last Week (28th July 2019)

A few months ago I came across the term ‘Abuse Cases’ in a blog post by Nicola Owen. It was a term that I’d never come across before. This inspired me to write a blog post where I provided my own interpretation of Abuse Cases.

Abuse Cases – Understanding Motives

When Ministry of Testing announced their latest Power Hour event on Personas, I was eager to submit a question about Abuse Cases. Gem Hill beat me to it (although she didn’t use the term Abuse Cases). I see Abuse Cases as being examples of ways the application could be misused. This question didn’t just focus on ways the product could be misused, but also how a product could be attacked.

Check out The Club for a full list of questions and answers from the Power Hour.


Personas – Power Hour
Cassandra H. Leung dedicated an entire hour to answering questions about Personas on The Club. Questions were asked about personas templates, edge cases and personas for those who would misuse an application.

Social Media Discussion

Superhuman discussion (Twitter)
Twitter discussion shared by Cassandra via the Persona Power Hour as an example of a persona created to show how an application could be misused.

Smoke Testing vs Sanity Testing
After finding the discussion about smoke and sanity testing on LinkedIn, I decided to setup another discussion on The Club to see if anyone else had some ideas to share.

Articles and Blog Posts

Learning from Failure: The tricky iOS Environment – Melissa Eaden – Testing and Movies and Stuff
This article contains a tale of a mistake that led to iOS issues and the lessons learned from this mistake.
“Issues…can give us an opportunity to change practices, habits, and better understand the system we are working with.”

“Cheating” Is Necessary – Melissa Eaden – Testing and Movies and Stuff
Is it cheating to look things up? Or ask for clarification?

How to form a regression testing plan with these 5 questions – Mike Kelly – Tech Target
There are many things to consider when setting up a regression test plan. Here, we look at questions about goals, coverage, techniques, maintenance, environment and reporting that should be asked while putting together a regression test plan.

It’s Automation Logs! Better Than Bad, They’re Good! – Paul Grizzaffi – Responsible Automation
In this article, we look at the importance of useful logging and what is required to make it useful.

Testers, Please speak to the developers
This week I published my write up of the 99 second talk I gave at the Birmingham test meetup last week. In this post I talk about the importance of speaking to the developers. Communication ensures that everything understands the requirements and identify ways to make the application more testable.

Other blogs that share lists of test related articles

https://5blogs.wordpress.com/ (daily)
http://blog.testingcurator.com/ (weekly)
http://thatsabug.com/ (weekly)
https://weapontester.com/tea-time (weekly)

Testing Conferences

The Club
A forum for discussing, asking questions, answering questions, and requesting help. Run by the Ministry of Testing.

Feel free to recommend anything that you think is of interest.
Main image taken from http://www.publicdomainpictures.net


Abuse Cases – Understanding Motives

Before identifying how a user might misuse an application, we need to understand why a user might misuse the application.

“Sometimes when I try to understand a person’s motives I play a little game. I assume the worst. What’s the worst reason they could possibly have for saying what they say and doing what they do?”

Petyr Baelish, Game of Thrones Season 7 Episode 7, The Dragon and the Wolf

I was not able to attend Test Bash Brighton this year, however I do enjoy reading about other people’s experiences. Today, I came across a blog post by Nicola Owen containing a write up of her notes. Included in this post were the notes for the talk by Claire Reckless and Jahmel Harris, titled ‘United by Security: The Test that Divides Us’. Nicola included a photo of the following slide:

Slide from Test Bash Brighton talk ‘United by Security: The Test that Divides Us’ by Claire Reckless and Jahmel Harris. Photo taken by Nicola Owen.

Abuse Cases vs. Use Cases

I’m already familiar with the concept of use cases, where a specific scenario is created that suggests a way in the application may be used. The use case would demonstrate a method in which the user may interact with a product. It would then go on to demonstrate how the user would gain value from this interaction.

Abuse case would have a similar concept. Except the abuse case would suggest a situation that would be undesirable for the business. This is a specific scenario that suggests a way the application may be used, but in a way that would benefit a malicious user. What reasons might a user have for interacting with the application in an unintended way? How might they do this? Would they be successful if they tried?

One thing I really like about the idea of Abuse Cases is that they don’t just look at how a user might misuse the application. They also think about why a user might misuse the application.

Creating Abuse Cases

I decided to have a think about how a user might attempt to abuse the software applications I’m currently working on. I test applications designed to control scientific instruments and analyse data collected from running measurements with these instruments. We often sell to the pharmaceutical industry who have strict rules about how experiments are conducted and the data used. The settings used for an measurements must be logged, and the data cannot be manipulated or deleted.

A user who works for a pharmaceutical company may be under pressure to get a drug approved by the FDA. They may choose to manipulate result data, or change the way a measurement is run so that the results better support the product for FDA approval. They may also attempt to generate fake data so that the FDA can approve the drug sooner.

By understanding the motivation of a malicious user, we were then able to identify potential ways a user might attempt to misuse the application. We then investigated if it was possible for the user to do this.

Unintended Consequences

“Your scientists were so preoccupied with whether or not they could that they didn’t stop to think if they should.”

Ian Malcolm, Jurassic Park

During her keynote at the UKSTAR testing conference, Fiona Charles constantly asked the question ‘What could go wrong?’

In this talk, there were many examples of the unintended consequences of technology. Some were caused by a human which directly affected other humans. In these examples, the human will have deliberately misused the application on purpose.

There were others that had a negative effect on society and the environment. These would not be caused directly by other humans, and wouldn’t usually have been done on purpose. Examples included self service checkouts. To make it easier for a customer to quickly scan items at the checkout, there has been an increase in the amount of plastic packaging used. This has had a negative impact on the environment.

Abuse cases like these usually don’t carry a motive. This makes them a lot harder to understand or anticipate. Despite this, they are still something to think about. The best method would be to question everything – assumptions, biases, objectives and decisions.


Unlike Use Cases, which need to be successful, an Abuse Case must be unsuccessful.
When people talk about the importance of understanding the end-user, this should apply to both good and bad users. We should also think about the ethical implications of the application and the potential impact it might have on society or the environment.

By anticipating abuse cases in advance, we can create software that is safer and more secure.

Main image taken from publicdomainpictures.net