Interactive Exploration – Photographing

This is the second post in the interactive exploratory testing series. The first post provided a relatively large amount of context as well as ending with a challenge. So let’s continue to explore this idea of exploratory testing with interactive fiction.

So let’s recap: what was the challenge? The challenge was to add a photographing action to our game. Well, actually, the challenge was simply for you to think about what adding a photographing action would mean for the game.

You might have left the last post thinking: “What is he talking about? I have a life to live; I don’t have time to sit here and learn Inform 7.” That’s okay! Part of the challenge was realizing you didn’t have to in order to think about the problem and think about how you would like to test it. That’s a core part of exploration.

Did You Try the “Obvious”?

As a tester, one of the first things you probably should have thought of was to try the game (I certainly told you how) and attempt a command (I provided a solution file that showed commands) to photograph something. How about this:

> photograph statue
That's not a verb I recognize.

Ah. So we learn right there that there is no basis for photographing at all. And this matters because I mentioned Inform provided lots of rules already in place to handle various actions. And you saw that navigating actions (“north”, “east”) and other actions (“look at”) were already modeled. So learning whether any concept of “photographing” existed was certainly something to be thinking about fairly quickly.

This is a key part of exploration: when you are provided material, do you take the time to assimilate from it what you can? And then do you immediately see if you can apply your understanding in the context you have been given? Even if — and particularly if — you feel you don’t have all the information you might need? This is part of the key traits of a good specialist tester: inquiry, curiosity, investigation, and experimentation. And, I might add, showcasing those traits in the context of varying levels of uncertainty.

Was that an “obvious” thing to try? Well, let’s not get hung up on that right now. Even with this action not working — or even if you had no clue whether it did or didn’t — there is plenty we could have been thinking about regarding how such an action would work once it was implemented. There is plenty we could have been thinking about regarding what we, as testers, would be looking for in the game when/if this action was possible. I’ll revisit this in a little bit. Let’s get into a little implementation.

Implementing Photographing

To support the player using a “photograph” command in Inform, we need to create a new type of action for that command. We also need to create the grammar by which this action will be understood. Here’s what we need:

Photographing is an action applying to one visible thing and requiring light.
Understand "photograph [something]" as photographing.

Incidentally, you’ll see all the relevant source text that was added in the latest version of the source itself under the following: Volume – Story Mechanics -> Book Actions -> Part – Photographing.

Let’s talk about what those initial statements mean.

The first statement is creating the action and it’s providing two qualifications on that action. What this design states is that the player, when attempting a photographing action, can’t photograph in the dark (“requiring light”) and that they need to be photographing something and, further, it must be something they can see (“one visible thing”).

I should note that the word “visible” tells Inform that the player — or, rather, the player character (whom the player controls in the game) — does not need to be able to touch the thing in question; just being able to see it is good enough. (As a tester, did your tester senses kick in right there and wonder how something could be visible but not touchable?)

Let’s consider that second line. This shows the pattern of words that are needed to match the expectations of the action. When square brackets — [ and ] — are used inside double-quoted text, they are used to substitute a varying textual value. This is saying that the player can photograph something. Clearly we wouldn’t want to have to write an Understand statement for every possible object that the player could photograph, so this is the way that Inform allows us to be generic.

Consider Sensitivities

This does bring up a good point, however. Let’s consider again that kinds hierarchy I showed in the first post:

The thing kind is pretty high up the list. So here “something” — literally some + thing — would refer to anything that is of the kind thing or below. That’s important because you could imagine a bug creeping in if some developer wrote the grammar line like this:

Understand "photograph [someone]" as photographing.

In that case, the action would only work on someone — of the person kind — which means it would not work on things, given the hierarchy.

As a tester, ask yourself this: did you need to know this? This sounds like an implementation detail that developers have to worry about, no? Well, this is where the discipline of testing intersects with that of development. What I just showed above is a particular sensitivity of Inform. It’s possible to create “Understand” statements that negate a series of objects in the model world. Important? Yes!

  • As a tester, you’ll want to know that this is possible.
  • As a tester, you’ll want to be aware of how it can happen.
  • As a tester, you might want to be able to spot these things in the code yourself.

Again: traits of a specialist tester. If you have a tester who does not want to do those things, or continually shows no aptitude to do so, you probably don’t have a good tester on your hands. But that’s what exercises like this are for: the guide the habit and build up the intuition.

Testing the Rules

All applications, regardless of how they are constructed, are effectively rule-based to a certain extent. Inform just makes that much more literal which allows us to explore these ideas a bit more effectively.

To support this photographing action, based on what I said in the previous post for the design process, you need to consider the rules that are carried out when an action takes place. Let’s recap what I said in that post. Specifically, the rules that govern actions are as follows:

  • Check: does the action make sense
  • Carry Out: perform the action
  • Report: describe the result of the action
  • Before: allow preliminary activities to happen before the action is tried
  • Instead: block or divert the action
  • After: allow for unexpected consequences after the action has taken place

The first set of these are considered the “normal” way that actions should be performed in all circumstances, unless exceptional circumstances apply. The second are to be used when there are exceptional circumstances that the game should account for. I’ll explain a bit of this as we go forward. For now, like any good tester, just soak in the emerging requirements.

As a tester, based solely on what I told you in the previous post, you likely had been intuiting that there are certain things to consider for an action:

  1. What words will the player use as part of the command?
  2. What are the normal action processing rules for that command?
  3. What changes on the model world will the action have?
  4. What circumstances might make the action go differently than intended?

Now we can flesh out the requirements a little more. This is exactly what you would do as a tester trying to better understand how to test, right? So:

  • Regarding point 2: That’s where Inform developers use Check, Carry Out, Report action processing rules.
  • Regarding point 4: That’s where Inform developers use Before, Instead, After action processing rules.

So as a tester, and exploring the idea of “photographing” as an action, what should be the normal thing that happens? What does it mean for the action to “make sense”? Put another way, what kind of check rules should we have and tell the business and the developers that we are going to test for?

Report Rules – Consider Output

One school of thought for testing and for development says to start with the outcomes. Say what you want the output to look like and then figure out how to produce that output. In our case, that’s quite a bit simpler than with many applications. So as a tester, have you thought about that? You knew there was the desire for a photographing action. As I indicated in the previous post, certain rules are operative to indicate the output and above I expanded slightly on that. This is where a Report rule comes in.

So what should be the basic output of a photographing action, assuming there are no complications? How about this:

“You snap a photo of the statue.”

I should mention that a convention of the text adventure medium is that stories are generally told in second-person, present tense. This can be changed but I don’t plan on bucking the convention here. However, that’s certainly something that may have come up in your tester mind: how should the game respond to the player? If you looked at (explored) the output of the game from the previous post, you saw a few “you” and “you’re” (see the description of Long Water or the description of the Albert Memorial).

Okay, so that output is not bad. Obviously it would need to be conditionalized for the objects that the player might photograph. So let’s say the implementation that the developers provide is this:

Report photographing:
    say "You snap a photo of [the noun]."

Here we’re using those square brackets again. This time we’re conditionalizing so that whatever noun (direct object) the player referred to when using the verb (photograph) will be the one that is printed. Again: does this matter to you as a tester? It should. It’s helping you better understand how things are constructed, which can be pointing you to certain sensitivities.

What the above source is basically saying is that there is a report rule for photographing. This rule does nothing except say some text.

You obviously weren’t expected to know the syntax for Inform — although you’ll build that up as we go (and, again, you may be inclined to explore my previous tutorial posts) — but, as a tester, you were certainly expected, given the context you were provided, to think about what output of this command would look like. And here, as a tester, we are saying that the basic operation — again, assuming no exceptional circumstances — is that the player is informed that they took a picture of whatever it is they referred to in the command.

Inform has this cool feature where you can create test statements as part of the source text itself. So as a tester I know I need to be in a certain location (one of the rooms with the statue, or the sculpture, or the memorial). So how about this:

Test photograph with "photograph statue" holding the camera in Broad Walk.

If you play the game and type the command test photograph, you get this:

>test photograph
(first moving to Broad Walk)


>[1] photograph statue
You snap a photo of the statue of Queen Victoria.

So that seems to work. You could feel free to play the game itself and not only try out the test command but also navigate around and take pictures of the other objects in the game. From this point forward, I’m not going to show the output of test commands and leave that for you to try.

Check Rules – Consider Invalid Conditions

Reporting the action is one thing, but we also said that rules had to check if the action made sense. This is a large part of what should have been triggering your tester mentality. Let’s reframe it: what does it mean for the “photographing” action to not make sense? This is nothing more or less than the distinction between testing invalid conditions and valid conditions.

Well, one thing should be fairly obvious, right? The player should not be able to photograph something if they are not carrying the camera.

This is something that, as testers, we could have thought of regardless of knowing the implementation. The developers and business would likely agree that this reality check makes sense and, as such, let’s say it gets implemented as so:

Check photographing when the camera is not carried:
    say "You can hardly photograph without your camera." instead.

A good test for this is covered with test camera-not-held.

What I did is make sure the player dropped their camera, moved to a room that had an item to photograph, and then try to take a picture. If you tried it out, do you think that output looks good?

Don’t Stop at One Test!

What else did you think of from a testing perspective? Well, what if the player tries to photograph the camera? Would they actually do that? Who knows but right now if they do so, there is no check rule that would prevent them from doing so. And the report rule would happily report as such:

>photograph camera
You snap a photo of the camera.

Not ideal. Another check rule seems useful here:

Check photographing when the noun is the camera:
    say "Unless you've got some setup with mirrors, that's going to to be tricky." instead.

A test statement is provided by test photo-camera. The output is a bit snarky, perhaps. But maybe the player deserves it. That will teach them to do silly things in our game!

Testing is About Exploring Options

Are you getting a feel for how all this works?

I’m using the photograph action as a very simple way to introduce you to the concepts that I want to have you explore. I’ve been putting emphasis on the source text here just so you can see what things look like. In future posts, there’s going to be much less emphasis on this and more on simply the exploratory testing you perform when I give you the context for something else the game is going to support.

Even with this simple photographing action, as a tester, what you probably came up with as some conditions are:

  • Test photographing some object.
  • Test photographing some person.
  • Test photographing nothing at all.
  • Test photographing myself.
  • Test photographing the camera.
  • Test photographing something I’m holding.
  • Test photographing something I’m wearing.
  • Test photographing something that is inside something that you can see through.
  • Test photographing something that is inside something that you cannot see through.
  • Test photographing something that is intangible.

Given the initial source text that we’re starting with, you have nowhere near the level of items in game to appropriately conduct all of these tests. In fact, that was part of my intent: I didn’t want to sway how you thought about the testing by providing obvious cues in the game text.

There’s also some other things you may have thought of as a tester. Is there the concept of a limit to how many pictures the player can take? Is the simulation going to model film of some sort that has to be put into the camera? Should the simulation include that level of detail? What kind of camera is this: digital? Traditional? Does it matter?

Again, what’s the appropriate level of simulation? And a large part of understanding how to frame tests around that question is understanding what role the camera will play in the context of the game. Should the player be able to review photos they have taken for some reason? Can they have the photos developed? Can they give those photos to other characters in the game?

Hint: This notion of the “appropriate level of simulation” is going to come up in future challenges. This is akin to a tester asking how much of a given business domain is being represented faithfully in an application.

Another thing to note is that all of these assumptions were about the player using the verb “photograph”. What if, instead, they attempted to use “take picture of statue”. And that, you might realize, could get interesting because “take” here can also be used in a very different sense: as in “take statue”. In the latter command, the player is trying to take an object, but in the former they are not trying to take the statue. In fact, they aren’t trying to literally “take” a picture as in picking one up.

Again, all of this can be thought about without understanding the first thing about how to implement these ideas in Inform. But do notice that having some familiarity with games like this can certainly help. This is no more or less “unfair” than how knowing web applications or mobile apps will give you certain ideas of what you can and should be thinking about.

So Where Do We Go From Here?

As we go forward, I’m going to present certain challenges and the solution to those.

You can even try creating your own source text if you want by copying mine and using it with inform. If you don’t want to download the IDE for your platform of choice, you can also use a very slimmed-down web version called PlayFic. If you create an account there, you can type in — or copy — source text into the browser.

Having an understanding of those rules I’ve talked about here can help frame your thinking for these challenges. I covered Report and Check above. There’s not much to do with Carry Out in this particular example because the action simply occurs. It has no ramifications on game state. If there was limited film in the camera, then, perhaps, a carry out rule would be in place to use up one bit of film for each picture taken.

Keep in mind that those rules — Check, Carry Out, Report — are what we want to consider for how actions normally behave, as I said before. Let’s consider how actions might be handled in exceptional circumstances.

Before Rules – Consider Preconditions

We have a check rule above about the player not holding the camera. But let’s say that we, as testers, believe that if the camera is in the room where the player is, the game should assume that the player means to photograph with the camera. Thus the game should automatically pick up the camera for the player and take the photo.

This, by the way, is called an “implicit action” in the context of games like this. This is a perfect example of where you want to let the action go through, but you want to do something before it occurs:

Before photographing:
    if the camera is in the location of the player:
        silently try taking the camera;
        say "You grab the camera first."

We actually already almost have a viable test. Remember the camera-not-held test? That one I specifically dropped the camera and then moved to a room to test the photographing action. In this case, however, the pre-condition is slightly different: I need to drop the camera in the room where the player tries to photograph. You can see how this works with the test implicit-camera.

One thing to note here is that a before rule is occurring before the action has taken place but is not stopping the action. That’s something important to understand as a tester.

After Rules – Consider Postconditions

Sometimes we might have need to indicate something after all of the rules have fired. This means the action has taken place so we can’t do anything about it one way or the other. Again, something important to understand as a tester. For this example, let’s just assume the game responds if the player tries to take a picture of a certain object that the game indicates people are making fun of. The code:

After photographing the Albert Memorial:
    say "Passerby can't believe you would waste your time photographing that."

See how it works with the test bad-photo.

Instead Rules – Consider Alternate Paths

Finally, let’s consider a situation where you want the action to be attempted but stopped. This is where a “(do something else) instead” rule kicks in, which, as you can see is quite different from Before and After. Here let’s just say the game is going to have a thing against selfies:

Instead of photographing when the noun is the player:
   say "You never got into the 'selfie' craze."

You can try this out with the test photo-self.

Rule-Based Testing

Think about most testing you do. Don’t these rules seem to match up, at least conceptually with what you do?

  • Before: set up a precondition or make sure a context is operative
  • Check: can I even do this and what makes sense to do
  • Carry out: do it
  • Instead: do something else, based on something I just thought of or because something happened
  • Report: look for the output
  • After: do some specific thing besides just looking at output, perhaps cleanup

In the context of Inform, it might help you to understand that a rulebook is a list of rules to be followed in sequence until one of them makes a decision. So in our source text we have two check rules and one each of the other rules, with the exception of Carry Out. So there is a Check rulebook that is filled with Check rules and similarly for the others. The point is that a rulebook gathers together rules about making some decision about an action being taken.

As a tester, that should be tripping your Spidey-Sense big time! Any system of rules gathered into a rulebook implies certain rules should take precedence. What if the rules are fired out of order? What if one rule overrides another? What if one rule contradicts another?

What I’ll say for right now is that Inform gathers all such rules and sorts them in order so as to give more specific rules first choice about whether they want to intervene in the action.

You Made It!

We went through our first challenge. You had a whole lot thrown at you. If you’ve stuck with me this far, things will get easier now in terms of me not having to throw walls of text at you. We’ll be able to focus on some challenges.

So how is this going to work? Truth be told, I’m sort of playing this by ear. I usually do these sessions live.

One way I could do this is have a short post that presents the challenge and then a second post that presents a possible solution. That said, that could get annoying for readres. That approach (barely) worked with the photographing example because it was relatively simple and because the goal was to use it as an introduction to concepts rather than to consider (and implement) all possibilities.

Beyond the question of “how to continue” is the more important one: of “should I continue.”

Was This Worthwhile?

Was this interesting? Does this seem worth continuing? Is it an interesting way to explore and engage testers?

Here’s what I do know. Different people in different contexts take different lengths of time to internalize testing, as a discipline and as an activity. However, all such people, usually regardless of context, benefit from a practical approach but also one that engages their mind and provides a memorable experience.

My goal is here is to provide an instantly accessible environment in which to learn, the guidance to get started, the support to keep practicing, and the encouragement to enjoy yourself along the way.

My goal is also to have to the challenge topics be relevant, the structure conducive to learning, the pace and scope appropriate, and — most of all — a focus on practical examples in an engaging context that can be translated immediately not just to your own career, but in your efforts to introduce others to the discipline.


This article was written by Jeff Nyman

Anything I put here is an approximation of the truth. You're getting a particular view of myself ... and it's the view I'm choosing to present to you. If you've never met me before in person, please realize I'm not the same in person as I am in writing. That's because I can only put part of myself down into words. If you have met me before in person then I'd ask you to consider that the view you've formed that way and the view you come to by reading what I say here may, in fact, both be true. I'd advise that you not automatically discard either viewpoint when they conflict or accept either as truth when they agree.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.