As a tester, you’ve probably seen use cases, and they’ve probably informed some of the choices you make about how to test your product or service. (Maybe you’ve based test cases on use cases. I don’t find test cases a very helpful way of framing testing work, but that’s a topic for another post—or for further reading; see page 31. But I digress.)
Have you ever noticed that people represented in use cases are kind of… unusual?
They’re very careful, methodical, and well trained, so they don’t seem to make mistakes, get confused, change their minds, or backtrack in the middle of a task. They never seem to be under pressure from the boss, so they don’t rush through a task. They’re never working on two things at once, and they’re never interrupted. Their phones don’t ring, they don’t check Twitter, and they don’t answer instant messages, so they don’t get distracted, forget important details, or do things out of order. They don’t run into problems in the middle of a task, so they don’t take novel or surprising approaches to get around the problems. They don’t get impatient or frustrated. In other words: they don’t behave like real people in real situations.
So, in addition to use cases, you might also want to imagine and consider misuse cases, abuse cases, obtuse cases, abstruse cases, diffuse cases, confuse cases, and loose cases; and then act on them, as real people would. You can do that—and helpful and powerful as they might be, your automated checks won’t.
Good ideas, and I like the notion of misuse cases. I recently suggested to my team thinking in terms of personas such as the types of people that either customize everything, try to do things too quickly, never read copy on the page, make constant typos, the easily distracted, or double-click every link or button, etc. We have them listed in our own internal testing cheat sheet.
Michael replies: Lovely ideas. Keep ’em coming. 🙂
Use cases are useful for getting an idea of the user’s expected progression through the system.
I use them to create “happy path” test cases. These are generally the only actual test cases I create as they are used by other team members. I usually use a form of checklist (not always written down) for other parts of testing.
The points you make should be obvious to anybody in our profession. Unfortunately, these things still do need saying as there are still a large number of testers who do not have this mindset either through a lack of ability or a lack of training.
Anybody who only uses the use cases as a basis for their testing has no right to call themselves a tester.
Michael replies: Apropos of “should be obvious”, I think the missing mindset is at least in part due to an oversimplification of the idea of testing. What’s worse, to me, is that, as Orwell said, “(our language) becomes ugly and inaccurate because our thoughts are foolish, but the slovenliness of our language makes it easier for us to have foolish thoughts.” He also, said, though, “The point is that the process is reversible.” If we refine our language and our models, we might be able to induce a virtuous cycle instead of a death spiral. (Note that Orwell would probably be annoyed with me for using two stale metaphors, there.)
[…] Katrina Clokie Fluent Page Object Pattern – Anton Angelov(Automate The Planet) Very Short Blog Posts (28): Users vs. Use Cases – Michael Bolton Your Complete Guide to SoapUI – The Most Used Web Services Testing Tool […]
In my opinion, the test cases are important because they help the QA not to forget some of the important use cases that the users tend to do. However, I think that only about the abstract high-level test cases- good title and a couple of most important actions and validations. Combining them with exploratory testing can provide a high coverage.
Michael replies: If the important use cases that users tend to do are so important, why set up an extra structure called “test case”? Why not say, “Here’s a use case: investigate it.” (Or “test it.”)
Also, I have included your article in my weekly best-articles-about-programming-roundup Compelling Sunday- http://automatetheplanet.com/compelling-sunday-15/
That’s very nice of you. Thank you.
[…] Blog: Very Short Blog Posts (28): Users vs. Use Cases – Michael Bolton – http://www.developsense.com/blog/2015/05/very-short-blog-posts-28-users-vs-use-cases/ […]
Could you elaborate on what you mean by misuse case? I’m working on a product where users have found unexpected value by “misusing” the product. I would like to call this “hack-ability”, where hack is defined as using the product for other than its intended purpose (like using a flat-head screwdriver to open a paint can), but not everyone agrees with that use of the word “hack”. When I try to make a case for spending test time exploring this potential, the typical response I get is “but we’re making the product for X reasons, not Y, so don’t stray away from X.” While I understand I should focus on X, there’s immense potential in Y. How can I advocate for running those tests?
Michael replies: Referring to “misuse cases” is essentially a whimsical way of pointing out the limited—and sometimes outright impoverished—ways we have of modeling user behaviour and the test space, and the effect that has on finding problems that matter. But you raise an important point here: while testers find problems, we can also discover unanticipated value in the product. I imagine that part of the objections you’re hearing relate to a perception about opportunity cost: if you are spending time and attention on Y, you reduce the time and attention you can devote to finding problems related to X, which is likely the most important part of your mission. That concern, almost certainly, has at least some warrant. There is an overarching mission of testing, though: to learn about the product. If you can relate your study and exploration of Y to finding problems that threaten the value of X, then you might be able to get the best of both worlds; and if you discover a novel and valuable use for the product, your client may be more willing to broaden your assignment. Your credibility depends on how well you can demonstrate that there is indeed “immense” potential in Y. On the other hand, remember that you are being paid by the client, and whatever testing you do will have to keep the client satisfied. Your client is usually in an excellent position to ask “What have you done for me lately?”
Calling it “hackability” will probably face a customer acceptance problem. You might like to try calling it “value exploration” or “extensibility” instead.
Thank you for sharing this useful article
Thanks for the disabuse case!
Michael replies: I saw what you did there. Clever. 🙂
I realize you are not recommending that the use case actually be written to accommodate your typical user but I wanted to share that I have seen it attempted. It started something like: “David sits down to use the admin tool. He didn’t sleep well and he hasn’t had his first coffee…” 🙂
Very nice. A confident beginning.
Reminds me of an earlier project with a hotel room reservation system where the bug find of a month at one point was discovered half-accidentally when the same room reservation was modified in two browser instances at the same time.
The end result? You could get paid to stay in a hotel!