“I can only show you the door. You’re the one that has to walk through it.” – Morpheus

---

Now for some of you, last week’s open path Test Method reveal may have been an eye opener, particularly people coming from non-game development testing. For others it may almost seem pointless when you can just “test against the GDD directly”; why do you even need such an open Test Method?

Because the value is in the building of knowledge!

I know the games industry can be quite dynamic and fast paced but that doesn’t mean you can’t have a 5-10 year plan for building an extensive resource for your team.

They’re open so they can be reused “as is” on each project.

They’re open so they’re dynamic and fast-paced.

They’re open so they can be relied upon by the team for years to come.

CR1000 is always going to be CR1000 and the trials and tribulations of previous attempts at fixing CR1000 issues are there for all to learn from.

That’s the goal, but that goal is not achievable without a dependable tester and our Test Script must support them too!

Expected Behaviour

For our example, this one is easy and it’s pretty much the same as the heading of the Test Script:

Expected Behaviour 1

The game does not crash to system.

Now we have “Expected Behaviour 1” because it allows for multiple Expected Behaviours but as we’re using a simple Test Script to explain the overall structure, that’s all we have here.

I would also ask my testers that they include the official Expected Behaviour in a bug they write up that falls within a Test Case. No making it up, stick to the line. It avoids misinterpretation.

The Expected Behaviours are kept short and sweet so any extra information that may help explain the Expected Behaviours or is required knowledge goes into…

Important Information

For the example we’re using, Important Information would look like this:

Important Information 1
"System" refers to any of the following, depending on the platform:
Desktop on PC
Home on Xbox
Games Home on PS

If the game has crashed to the Main Menu within the game, please refer to CR1000B.

As you can see, it’s aimed at making the Expected Behaviour clearer, without over complicating it and pointing someone in the right direction if they’re looking for something similar.

It helps keep a tester on track but it doesn’t necessarily help them test. That’s the job of…

QA Notes

QA Notes is specifically aimed at guiding a tester down the right path, (and also showing a developer the potential path taken).

In this section you would find things like:

QA Notes 1
Be sure to focus on areas where multiple processes are running or where there is a heavy load on the engine.
Attempt to interrupt the system during those processes.
E.g. Attempt to interrupt saving/load, attempt to create as many data points as possible to a save file, attempt to spawn extra assets or disconnect a host mid-session.

QA Notes 2
Be sure to create a Test Matrix of areas covered and append to this Test Script.

Like Important Information, it’s not an overwhelming dump of information but a potential path for a tester.

The important thing is to keep the Test Matrix logged for future inspiration.

As the awesome Morpheus said “I can only show you the door. You’re the one that has to walk through it.”, (the idea being that the Expected Behaviour is the door 😅. I know I’m pushing these quotes.)

We’re leaning on the experience of our awesome testers to fill in the blanks here, which I believe they’re more than capable of!

---

Wrapping Up

We’re halfway through the Test Script but I’m keeping these short and sweet for now!

So next week, we’ll finish off with:

🔹Test Method
🔹Labelling
🔹Examples of Passes and Failures

Now that I think about it though, Test Method may need its own post.

Take it easy!!