Here I’ll go back to a game I talked about previously and show some interesting game bugs, all of which came out of exploration and where the finding of one bug guided exploration to finding others, which led to some causal mapping. Of course, the idea of “bug chaining” and “causal mapping” is certainly valid in any context, not just games. But games can certainly make it a bit more fun!
I’ve posted quite a bit on game testing here, from being exploratory with Star Wars: The Old Republic, to bumping the lamp with Grand Theft Auto V, to ludonarrative in Elden Ring. I’ve also shown how comparative performance testing is done with games like Horizon Zero Dawn. These articles offered a bit of depth. What I want to do here is show the breadth of game testing and some of the dynamics involved since it’s quite a specialized sub-discipline within testing.
In the second post of this series I looked at a couple of games to drill in the idea of ludonarrative and what it means. Here I want to go back to a game I started with in the first post, Elden Ring, and take a much deeper look at the mechanics and the narratives from a ludonarrative testing standpoint.
Continuing on from the first part, I want to continue to give testers a look into a very specific, and often undocumented, form of testing in the context of games, which is the idea of ludonarrative. This has the benefit of also showing how quality can be very much a function of viewpoint.
I’ve long said that I do believe game testing is one of the best ways that testers can improve their skills. Yet there’s very little out there that’s substantive about game testing, particularly in terms of how testers are asked to think beyond just “test that the game works.” So let’s dig in to this a bit with a two part series that involves something even a lot of game testers seem unaware of, which is the concept of ludonarrative.
The notion of quality can be a complicated concept. Quality can be very situational and that very circumstantial nature of quality tends to happen at the horizon, where various aspects come together and meet. So let’s do a (very) deep dive into this with one of my favorite examples: game testing.
I’ve said before that testing games is hard and I’ve also shown that I created a game for interviewing test candidates. You wouldn’t be far off the mark to figure that I put a large focus on game-related thinking. This is because, in my experience, such thinking makes some of the best testers. But let’s talk about that a bit.
Actually, testing games is not all that much harder than testing other applications. What’s hard is sometimes being able to figure out how to test them well, given their numerous interfaces and means of interaction. Even harder is sometimes isolating the very specific, but very odd bugs that come up. I recently came across just this issue with a particular bug I found while testing a popular game.