9 – Beta Testing

• Understand the importance of testing
• Know how to test, and how to fix the problems testing identifies
• Build your problem solving skills
• Make independent progress on your games project

• Testing
• Unit Test
• Beta Test
• User Acceptance Test

• Stakeholder
• Scrum Master
• Milestone

• User Experience
• Iteration
• Version Control

Last lesson, you…

• Reviewed your progress so far, and decide what you will be working on next.
• Held a stand up meeting, and set a weekly milestone
• Made more independent progress on your project

Today, you will…

• Learn about beta testing and how it influences development.
• Test and review another game before improving your own.
• Make further independent progress on your project.

A really important part of making anything is making sure that it works. Testing is a really important part of any project, but it’s particularly important when you’re working in an Agile way. The downside of lots of rapid changes and experimentation is that it is really easy to break things along the way.

When tests find issues, these become bugs to be fixed during the next sprint – once a program is vaguely finished, this becomes a really important part of the process. Likewise, testing and user feedback drive development of new features – companies like Facebook, Amazon, and Google do this all the time, adding in new things that respond to what their users want.

Testing needs to be detailed, and it needs to be performed often. You’ve been testing after every sprint, and that’s about right, though there’s no harm in testing more. It does seem like testing might start to become a lot of work, and in the latter stages of development, it does!

Thankfully, some of the hard work can be done for us, by our computer. It can check our code for errors, and even test our game with a series of programmed inputs to see if and how it works. However, whilst our computer can check if our game code is correct, what it can’t do is tell us if our game is actually any good. For that, we need real humans – beta testers.

Types of test:

• Unit Tests – the automatic testing that our computers do for us. These are typically a list of tests written by the developer that ensure everything actually works as intended. Tests should involve situations that are good (expected ), such as the user playing the game as normal. They should also involve situations that are not good (erroneous), such as the user pressing all the keys, or lots of things at random, or even doing things that shouldn’t even be possible – users will find a way! Finally, tests might also involve situations that are maybe good (boundary), such as the user pressing a key just before the level ends, slightly too early, and so on.
• User Acceptance Tests – sometimes called Alpha Testing, these come next, and are the first stage of human testing. These tests should make sure that the game is actually playable, things like buttons not being covered up by other graphics, timers not being impossibly short, the game actually running at a sensible speed, and so on. These are things which might be correct in terms of their code making sense, but don’t physically work. They should also make sure that everything that was an original requirement has been included. These tests are usually performed by the development team themselves, who check all the features are there. They don’t ask if the game is actually fun, though!
• Beta Tests – these are the last stage of testing, performed by real users in a real environment. They might be paid testers, but they are not the developers of the game. Sometimes, a game is released to the public as a beta version. This stage of testing assumes that the game mostly works, and looks at it as if it were a finished product. Beta testers may still locate bugs that escaped in earlier stages, but what their feedback is about more than anything else is whether the game is actually any good. Beta testers should be critically analysing the game, but at the same time looking to find issues. Effectively they become reviewers who are also trying to break everything on purpose. The goal here is to reach a point where the game performs well, everything works, and testers want to play it.

Developers can’t beta test their own work, so at this stage, you need to partner up with another group. You should swap games, although be prepared to help them get your game set up, and don’t forget to ask for help if you need it yourselves.

You should then play each others games, thinking about the critical analysis you did back in week 1, as well as the evaluation skills you use at the end of every topic. You need to produce some written feedback that explains to the other group what works well about their game, as well as areas for improvement.

Once you’re in your group, you should hold your next stand up. You should review the beta test feedback you have recieved, and decide what to do next. This sprint will be about responding to the feedback you have received, and improving your game. Each member of your group should have tasks which will help you all meet your milestone.

In your group, look at your milestone – what you want to have done at the end of the lesson. Once you’ve agreed on this, start working! Give yourself enough time to discuss your progress at the end, and self-evaluate how well you met your goal.

Remember – if you’re making changes, you should be doing these on a copy of the original work, so that you can go back if needed!

In this lesson, you…

• Learned about beta testing and how it influences development.
• Tested and reviewed another game before improving your own.
• Made further independent progress on your project.

In the next lesson, you will…

• Finalise the progress on your games project.
• Present your project to the class as a tech demo.

• Submitted your beta test feedback for another group.

• Met your milestones for the week.

• Exceeded your milestones for the week .