TFD Design Activities

Creating a TFD is not just a matter of mechanically typing or drawing some information you already have in another form. It is a design activity that requires the tester to become a designer . A sound approach to getting your TFDs off and running is to go through three stages of activities: preparation, allocation, and construction.

Preparation

Collect sources of game feature requirements.

Identify the requirements that fall within the scope of the planned testing, based on your individual project assignment or the game's test plan. This would include any storyboards, design documents, demo screens, or formal software requirements, as well as legacy titles that the new game is based on such as a sequel or a spin-off.

Allocation

Estimate the number of TFDs required and map game elements to each.

Separate large sets of requirements into smaller chunks and try to cover related requirements in the same design. One way to approach this is to test various abilities provided in the game, such as picking up a weapon, firing a weapon, healing, and so on. Plan on having one or more TFDs for each ability depending on how many variations exist, such as distinct weapon types or different ways to regain health. Another approach is to map situations or scenarios to individual TFDs with a focus on specific achievements . These could be individual missions, quests, matches, or challenges, depending on the type of game you are testing. In this case, you are establishing that particular goals or outcomes are achievable according to which path you take in the game. Basing the TFD design on achievements could be used either instead of or in addition to the abilities approach. Don't try to squeeze too much into a single design. It's easier to complete and manage a few simple TFDs than one complex one.

Construction

Model game elements on their assigned TFDs using a "player's perspective."

A TFD should not be based on any actual software design structures within the game. The TFD is meant to represent the tester's interpretation of what she expects to happen as the game flows to and from the game states represented on the diagram. Creating a TFD is not as mechanical as constructing a combinatorial table. There is an element of art to it. TFDs for the same game feature may turn out quite different depending on which tester developed them.

Begin the TFD with a blank sheet or a template.You can start on paper and then transfer your work to an electronic form or do the whole thing in one shot on your computer. The use of templates is discussed later in this chapter. Use the following the steps to begin constructing your TFD from scratch. An example appears later in this chapter that illustrates the application of these steps.

1. Open a file and give it a unique name that describes the scope of the TFD.

2. Draw a box near the top of the page and add the text "IN" inside of it.

3. Draw a circle and put the name of your first state inside of it.

4. Draw a flow going from the IN box to your first state. Add the event name "Enter" to the flow. Note: Do not number any of the flows at this time. This will be done at the end to avoid recordkeeping and editing the numbers if you change the diagram during the rest of the design process. Unlike the steps given for developing a pairwise combinatorial table in Chapter 10, the middle steps for creating a test flow diagram do not have to be followed in any particular order. Construct your diagram as your mind flows through the game scenario you are testing. The creation of the diagram should be iterative and dynamic, as the diagram itself raises questions about possible events and their outcomes. Refer to the following steps when you get stuck or when you think you are done to make sure you don't leave out any parts of the process.

5. From your first state, continue to add flows and states. Flows can be connected back to the originating state in order to test required behavior that is transient (action) or missing (ignored, resulting in no action).

6. Record the traceability of each flow to one or more requirements, options, settings, or functions. This could be as simple as ticking it off from a list, highlighting portions of the game design document or done formally by documenting this information in a Requirements Traceability Matrix (RTMX).

7. For each flow going from one state (A) to another state (B), check the requirements for possible ways to go from B to A, and add flows as appropriate. If the requirements neither prohibit nor allow the possibility, review this with the game, feature, or level designer to determine if a requirement is missing (most likely), wrong, or ambiguous.

8. Once all requirements are traced to at least one flow, check the diagram for alternative or additional ways to exercise each requirement. If a flow seems appropriate, necessary, or obvious but can't be traced to any game documentation, determine if there might be a missing or ambiguous requirement. Otherwise, consider whether the flow is outside of the defined scope of the TFD currently being constructed .

Go through these final steps in the order they appear here:

9. Add the OUT box.

10. Select which state or states should be connected to the OUT box. Your criteria should include choosing places in the test that are appropriate for stopping one test and starting the next one or states that naturally occur at the end of the ability or achievement modeled by the TFD. For each of these states, provide a connecting flow to the OUT box with an "Exit" event. There should be no more than one such flow coming from any state.

11. Update your IN and OUT box names to IN_xxx and OUT_xxx where xxx is a brief descriptive name for the TFD. This is done at the end in case your scope or focus has changed during the process of creating the TFD.

12. Number all of the flows.