Let’s continue our interactive exploration example. Here I’m going to provide a bit more of a complex scenario for you to consider. My hope is that you will take the time to engage with this idea, exploring the ideas around the central idea, and figure out how you would ultimately craft tests.
The business and design team have come up with a core scene in which the player does something that essentially makes surviving part of the game possible. Ultimately that goal will be to escape Kensington Gardens. It’s this scene that the business wants implemented in the game. The developers have provided the start of an implementation, which I’ll show you shortly.
You may ask: “What good does showing me the implementation do? I don’t know the requirements or what the business wants implemented.”
You’re right: you don’t know the requirements yet. But does that stop you from exploring an idea?
The Current Implementation
Consider release 3 of the game. Specifically, the bits that are added and relevant are shown below.
The following sections under Chapter – Broad Walk:
- Section – Bird Woman
- Section – Bird Feed
- Section – Small Coin
- Section – Red Ruby
- Section – Pigeons
- Section – Context
The following under Volume – Story Mechanics:
The following under Volume – Story World
And, for the first time, we have a bit under Volume – Story Plotting:
All of these are small bits of source code — and in English no less! — that should allow you to get a good feel for the parts that were added based on the business scenario.
Whoa! Wait … what? So developers added that source based on the business scenario … but … where is that scenario?
That will be provided in the next post. That may seem unfair and I fully admit I’m throwing that wrench in on purpose. Although sometimes we, as testers, do have to explore something that has been partially crafted based on information that we have only an approximation of based on meetings we weren’t called to.
In this case, I just want readers to see how they do reasoning about the system given only the source text. It’s an important way to practice building the intuition for exploration.
A Few Inform Bits
I will add in a few bits here, specific to Inform, that may guide some of your thinking. After all, we’re often not operating with a total lack of information, right?
Inform considers everything as happening in a given room as being essentially visible to the player character (i.e., the protagnist being controlled by the player). There is no built in notion of “seeing across rooms”, even if those “rooms” are outdoors.
- Everything that exists in the model world exists in one of the rooms.
- The concept of “scope” determines what the player can interact with.
- Scope is understood, by default, to be that which is visible and/or touchable in a particular room.
A slight recap on the idea of actions:
- Actions are what the player tries to do in the game.
- Actions occur due to commands that the player has typed.
- An action will either succeed or fail.
As I said in the first post in this series, Inform divides time up into turns and those turns can be grouped together into scenes. A few points on that:
- Inform makes sure that any action falls entirely inside or entirely outside of a scene.
- Scene changes occur outside of actions.
These ideas fit into the wider context of that which you have already seen in previous posts.
Is Something Missing?
If you looked at the source text, and you might be saying: “Hey! What happened to all that photographing stuff we did?” As it turns out, business decided we weren’t going to add that feature after all. But that’s okay because all we did is some exploring of the idea — which helped us learn about wider aspects of the application — and we didn’t create a lot of artifacts around that. In fact, we only created a few test statements.
That’s a good point to keep in mind about exploratory testing and even testing in general. You don’t necessarily have to create large, or many, sources of truth. (See my post on sources of truth.)
Testers need to be moving at the speed of decisions in some cases. Like writing fiction, sometimes you have to be willing to throw things away. Even more appositely, this is similar to how development spikes are kept lightweight enough to learn from but ultimately throw away.
Assuming you’re following through and actually trying the challenges, do you feel a bit overwhelmed? Or do you feel like it’s just not worth it? Do you feel you have way too little information to go on, so why bother? Do you feel that you are being asked to understand something you don’t know, thus finding all this a bit unfair or, at best, skewed?
Well … welcome to testing. Welcome to exploration. Welcome to attempting to reason about something where you don’t have a map. Feeling some friction with these challenges is expected.
Keep in mind your goal for this post: it’s just to reason about things; to spot things; to draw conclusions based upon limited evidence. One of the most important aspects of exploratory testing is attention to detail, particularly in the face of uncertainty. The next post will show you what I hope you reasoned about, at minimum, and we’ll get into that business scenario. Finally, given that you do know how to type commands into the game, and you have a working example of the game, you might want to try it out. What commands would you use to test the game that’s in place so far?
See you next time and happy exploring!