Fun is desirable in nearly every game, though sometimes fun defies analysis. To maximize your game’s fun, ask yourself these questions:
- What parts of my game are fun?
- What parts need to be more fun?
Fun isn’t normally one of the characteristics we consider as testers for most software apart from games. Still, there’s at least 3 ways we should be looking at the concept of fun as we’re testing:
- Application is fun when intended to be
The most obvious one is when we’re testing software that’s designed to be fun. If we’re testing a game or recreational app, we should certainly be raising issues if that game loses its shine. I find this to be particularly true in the mobile space these days (though that may be because that’s where I play most software-based games). There’s been a large number of games that I downloaded, played once and abandoned because I quickly lost interest in them. The game just wasn’t enough fun to hold my interest. Maybe some portion of the challenge required more effort than I was willing to invest and I got frustrated. Maybe it wasn’t challenging enough. Maybe there was a lot of repetition or actions spent just getting from place to place. Getting the right balance is a critical point for developing a game – if the game’s target audience doesn’t get engaged in the game, the time spent developing it may end up being a waste. As testers, it’s not uncommon to get tired of or even frustrated with the app we’re testing. We see it constantly for extended periods of time, warts and all. If we find ourselves getting bored with a game we’re testing, we need to determine whether it’s overexposure, it’s a case of us not being a member of the target audience or if there’s an actual issue that might cause many of our users to quickly abandon the game. If the latter, that falls into the scope of information we should be raising to the team for discussion.
- Application is not anti-fun
This is getting into the realm of usability testing. While an application may not be designed to be fun, we generally don’t want it to be a frustrating experience either. Non-intuitive UIs, overly complicated actions, or a lack of flow through the task can all leave a user muttering under their breath and potentially even lead them to stopping using the system we’ve built. Rather than using a lens of looking where the fun should be, we need to look at the overall system through the lens of where the fun ISN’T. This requires going beyond the scope of the individual feature we’re investigating and looking at how it interacts with the other parts of the system. It requires an understanding of the problems our users want to solve with our software and the contexts they want to solve them in.
- Testing itself should be fun
The last place where fun should come in in our analysis is in an examination of our testing process itself. Tasks that aren’t enjoyable should be periodically reviewed. Is the task even still providing value? (If not, perhaps the solution is to drop the task.) Is there another way that we could approach the task – automation (fully or in part), restructuring, adding a gamification element or something else that could make it more enjoyable? Is it a task that could be performed by someone else – perhaps the current task owner is just burned out on the task, and a new perspective might revitalize the task? With the constant schedule pressure many testers face these days, it can be hard to find the time to step back and evaluate the work we’re doing. We get into ruts, repeating things we’ve done before simply because that’s what we did before, and never notice that we’re no longer efficiently providing value. Our sense of dread for a task or boredom during the task can be an early warning sign that it might be time to take a step back and re-evaluate.
What other ways do you see the lens of fun applying to testing?