Test your prototype

You’ve been testing your work along the way as you created and refined your prototype. However, before you complete working on a prototype it can be very helpful to have a focused period of testing. This can be particularly useful if you want to add a prototype to your portfolio, share it more widely, or submit it to a game jam or as an assignment.

In this tutorial, you’ll:

• Plan acceptance tests for your prototype.
• Consider the role that structured user testing will play in your testing phase.
• Learn more about exploratory testing and how it can help you improve your prototype.

First, let’s take a moment to reflect on why testing is so important. After all, you’ve already spent a long time working on your prototype, testing it as you go — what extra value does a testing phase add?

Testing is the main way that you can:

• Confirm that the experience meets your technical requirements and behaves as expected.
• Identify unexpected behaviour — this could be a bug that needs fixing or a bigger issue.
• Evaluate the overall user experience.

You need to test all of these things to assure the quality of the experience that you share with your users.

It’s also important to evaluate the design of your experience and how it meets the needs of your target users. Moving beyond acceptance tests, it’s important to consider what it feels like to play your game or explore your experience.

Your experience has grown from an idea into a curated design document, and the document itself may have changed as your prototype evolved. When you have a real, testable experience, you can start considering how it will perform for users in a real-life situation. For that, you need to center your target user in testing.

You’ll explore user testing in more detail later in this tutorial — for now, take a moment to reflect on their needs to inform your own testing.

How does the experience meet your user’s needs?

It’s very important to get feedback from users themselves as part of testing, something that will be discussed in greater detail later in this tutorial. You should consider their needs in each type of testing that you do.

Consider the following questions from the perspective of your target users:

• What is fun, engaging or useful about the experience?
• As a user, what does it feel like when I’m challenged? Is this challenge intentional?
• Where are the points of frustration? How long do they last and can they currently be addressed by the user?
• Do the user expectations established by the experience get met with an appropriate outcome?

As you evaluate how well your prototype delivers on your design intentions, you should also complete this user experience-focused evaluation. There’s no substitute for user testing, but this is a good way to frame meeting their needs as a key priority as you iterate your prototype before you reach that stage.

While you can make educated guesses on how users will respond to an experience based on previous software interactions, you will never know for certain how a feature will perform or how your users will feel about your experience until you can share a playable version with them.

You may have had some assumptions challenged if you worked through the paper prototyping process for your idea earlier in this learning experience. In a similar way, when you take your experience to user testing it is likely that you will make many new discoveries about the way that different users within your target group engage and interact with your experience.

Every user will approach your experience differently, which is one of the key strengths of interactive experiences: user agency. Each singular game can be played in a near infinite number of playstyles and everyone using an app will have a particular goal in mind. When you have a prototype that is usable or playable, continuous testing with a wide range of testers is highly recommended and will help you create a stronger, more cohesive product.

Extend your learning

There is a whole genre of videos and articles dedicated to creators reacting to unexpected user interactions with their software, including:

• exploits
• speedruns
• strategies
• workflows
• new use cases

Take some time to search for examples related to the specific interactive experience type that you’re most interested in to gain insights from other creators and their experiences of user testing and exploration.

As part of scoping and refining your prototype, you identified the core interactions and the required functionality that your experience must provide. This can form a blueprint for a series of acceptance tests to help you identify whether the experience works as expected. These tests will help you evaluate your implementation of the requirements for the experience.

At first glance, it might seem strange to test expected behaviour. If something seems to be working as expected, why dedicate additional time and resources to check? Well, if your users can’t actually interact with your prototype experience and achieve the outcomes that you expect on a consistent basis, then it’s not complete!

To define a set of acceptance tests for your prototype:

1. Go back to the list of core interactions you defined for your prototype and any enhancements you made after greyboxing that led to additional interactions. Check that this is up-to-date.

2. For each interaction, record the possible user behavior and the expected outcome(s). You may have just one acceptance test per interaction for a simple experience, but it’s common to have many possibilities for complex ones. For example, one test might be: “When the player character is moved within 5 units of the mysterious plant, the firefly VFX is triggered.” This list will form the basis of your acceptance testing.

3. You might find behavior that isn’t defined but that you really like — that’s not a bad thing! Make sure to record this so you can include it in your next testing phase.

The more complex your experience, the more acceptance tests you may need to perform to ensure that you have comprehensively tested it. As your example experience is tightly focused, you should be able to define a reasonably short set of expected behavior acceptance tests.

Unexpected behaviour is the most commonly encountered process while testing your real-time experience. This occurs any time a mechanic or interaction doesn’t work as expected. Testing for this often needs to be more comprehensive than just going through acceptance tests — actual users rarely interact with experiences in such a methodical way!

Examples of common unexpected behaviors include:

• Application crashes.
• A player character falling through the map or walking through a wall.
• Mechanics not triggering when intended.

Consider an example

Imagine that while testing a game that you have made you find that the player character falls through the map. There are multiple areas within your code and scene you would need to double check in order to work out what is causing this behavior before you can fix the issue.

You work out that this particular issue is likely related to one or more of the following areas:

• The physics system
• The player character setup
• The level geometry and collision

Through repeated testing, you discover that all three of the above systems are causing the issue. This takes some time to work out over multiple test sessions — and that’s absolutely normal.

You also make particular note that if one of the related systems is changed in the future to accommodate a new feature or fix other unexpected behaviours, it will require repeat testing to ensure the issue hasn’t returned.

Sometimes an issue (or bug) that you find can help you consider your real-time experience from a new angle and adjust your initial design. There are plenty of examples in software where a bug turned into a feature. Super Mario’s multi-coin blocks, increasing difficulty in Space Invaders, and the flashing green LED that signals when your computer is writing information to disk were all born accidentally!

You’ve explored how to test for expected behaviors with a structured testing approach. But what about unexpected behaviors that can’t be found through acceptance testing?

However, there is another side of testing that is less structured and more creative. Exploratory testing, as the name implies, focuses on exploring your project in an open-ended fashion to find issues, bugs, and things you might need to change.

There are still some key principles to keep in mind so you can test successfully and promptly.

Cognitive thinking vs scripted testing

Running acceptance tests is a scripted process. There is a clearly defined objective and a specific criteria to test against. This involves following a set of predetermined instructions. Exploratory testing, in contrast, has you design the test cases and execute them simultaneously. While scripted testing could theoretically be carried out by a machine, exploratory testing relies heavily on the cognitive ability of a human.

Approach instead of a technique

When you’re doing exploratory testing, it can be helpful to think about the testing in a different way. You’re not trying to execute a specified technique in the experience, you’re trying to engage with features in the many different ways that your users might engage with them. Rather than focusing on the design-intended technique for users, what other methods could they try to use to achieve the same outcome? Exploring these different methods is at the heart of exploratory testing.

Investigate, Discover, Learn, Experiment (IDLE)

When doing exploratory testing, it’s important to:

• Investigate
• Discover
• Learn
• Experiment

This approach is referred to using the acronym IDLE. This method of testing only works if the tester is familiar with the software and continues to build upon their knowledge with repeated exposure and interaction, hence this acronym.

Consider the previous example of a player character falling through a level or walking through some walls in a game and imagine that this specific situation was fixed once. Testing the specific scenario in which this incident arose didn’t replicate the same result; however, you now know that this behavior could occur again and that you need to watch out for it. Let’s apply the exploratory guidance principles to this bug.

In the acceptance testing stage, you confirmed that the player clipping bug stopped occurring under the specified conditions. You may have closed the issue, but the exploratory testing has just begun.

Knowing there is precedent, and keeping IDLE in mind, what else could you do to trigger this bug? Note down your ideas before you continue reading.

Check your work

Here’s a list of things that you could investigate through exploratory testing:

• Changing player character values
• Purposefully controlling the character in unconventional ways
• Running at walls while pointing the camera the opposite direction
• Holding items while running at the wall
• Dropping items while running at the wall
• Jumping at the wall, grabbing and dropping an item mid jump against a wall

This short list could continue for far longer, limited only by the creativity of the tester and the particular experience that you are testing.

Exploratory testing can also involve an extended testing journey. Imagine that you find a different issue when testing what happens while the player carries or drops items. Exploratory testing gives you the freedom to flexibly adapt to your findings and start investigating the new issue instead, with a plan to return to the initial player clipping issue later.

Including user testing as part of your testing process can give you really helpful feedback, both on specific areas you’re particularly interested in and the overall experience. If some of these users share the profile of your target players or users, that can also be incredibly helpful in terms of targeted feedback from the audience that you’re hoping to specifically engage.

Introduction to user feedback and testing will provide you with a more detailed overview of the value of user testing and guidance on running sessions for your experience. If you’re new to user testing, we recommend reviewing the tutorial and using it as a guide to help incorporate it into your prototype development process.

Extend your learning

If you’d like to learn more about playtesting, you can also explore the Playtesting project in the course Design and Publish Your Original Game: Unity USC Games Unlocked.

Throughout your testing, you will be constantly engaging with your software in a variety of ways. This will naturally expose you to aspects of your design that were impossible to consider beforehand. During this process, it’s critical to consider your user’s perspective, how it relates to your design, and how your implementation impacts it.

Software is constantly evolving and it’s important to use the feedback you get from each type of testing to iterate and refine the experience that you are creating. This might involve cutting features, rescoping your experience, or starting again. This iteration is part of the process of development — arguably the most important and most time consuming part.

When you’ve completed testing of your prototype and have addressed issues and iterated it in response to relevant feedback, you’ll be ready to polish your prototype by applying what you’ve learned about each of the domains of the Creative Core pathway. If you are completing this learning experience as part of that pathway, this will become your independent project.

In the next tutorial, you’ll review the guidance and get started!