Decapitathlon

Quality Assurance Plan

Amos Room (B00254109)
Nathan Bone (B00248653)

Contents
Testing Review
Project Plan
Risk Analysis
Quality Assurance Testing
Testing Methodologies
Functional Testing
Non-Functional Testing
Acceptance Testing
User Feedback
Feedback Questionnaire

Testing Review
Project Plan Review
Our project plan is to create a fast-paced 'arcade puzzle' game, titled Decapitathlon, to be played on
web browsers and hosted on our website. The game will be composed of several short microgames,
each with a time limit of five seconds to complete. Gameplay will be spread out over a series of 10
different stages, each composed of 12 different microgames with a final unlockable stage containing
all microgames that are present in the game.
Risk Analysis
Project Scale
During testing, due to the large scale of the project and the random nature of the game, there
is the risk that some microgames will be overlooked and not tested as rigorously as
other games in the project. To help prevent this, as we go through our initial testing of the
game we we will play through each microgame that we have developed as opposed to each
stage of the game. This will allow us to test each and every game equally and help us check
for errors a lot better.
Developer Bias
As we test through the game there is the risk that we may have a certain level of bias
towards the project. This will only allow us to look at the game from our own perspective,
which in turn could lead to us overlooking some aspects of the project. To help prevent this
we intend to utilise user testing. This will help us gain helpful insight from a different
perspective and give us feedback as to what players feel should and should not be changed
with the project.

Quality Assurance Testing

Software Testing Methodologies
In testing the full game throughout development, we will have to use a pre existing methodology to
guide us through the testing and allow us a structure that will ensure we can test the game
efficiently and make sure we get as much information as possible. To decide what the best
methodologies to use for Functional and Non-Functional testing, we have taken to researching
several different methodologies and their pros and cons to make an informed decision.
Functional Testing
Unit Testing
The Unit testing part of a testing methodology is the testing of individual software modules
or components that make up an application or system. This covers a very narrow and well
defined scope. Unit tests focus on very small unit of functionality. They cover the interaction
of the code with memory only and do not cover any interaction with network, database or
file systems. These dependencies are hard coded into the code while testing.
This is a very simple way to check small areas of code and provide they work. The problem
is that these check that they work in isolation and need more testing to see that they work in
tandem with other parts of the code and these only provide small amounts of data.
Integration Testing
The Integration testing part of a testing methodology is the testing of the different
modules/components that have been successfully unit tested. Integration test involve testing
the modules which access network, databases and file systems. They reveal out the issues
with network modules or databases and more importantly in the connections between small
units of code. Often when the modules/units are wired together there are issues and these
issues only start to come up in these tests which is incredibly useful.
Acceptance Testing
Acceptance Testing is the final phase of functional testing and involves making sure all the
product/project requirements have been met and that the end users experience matches what
is expected and that the system operates as expected. There is no real downside to this
testing. This allows us to make sure we have put in everything we have wanted to and be
sure the game is how we want it and the consumer experiences it the way we want them to.

Non-Functional Testing
Performance, Load and Stress Testing
There are several we can test the performance of our project. These include:
Performance testing where we measure how a system behaves under an increasing
load both numbers of users and data volumes.
Load testing to verify that the system can operate under the expected load required
during individual stages
Stress testing where we can find any weak points through excessive load beyond
what it can support.
These can be useful but can only really be used in certain circumstances within our game
project and it may not be feasible.
Usability Testing
The usability testing part looks at the end-user usability using five main aspects
satisfaction, learability, memorability, efficiency, and errors to test the ease at which a user
can access and play our game and use different aspects of the game. This is extremely useful
as we can test how the consumer reacts and make changes to improve the users experience
to make the game even better.
Compatibility Testing
Compatibility testing involves testing the application on multiple different operating
systems, hardware and software configurations, web browsers, mobile devices and any other
programs or products that may access our game and play it. These tests check that the
project will work as expected across all different hardware and software combinations that it
could come into contact with. This is extremely important to get it to work and to get as
many people playing it as possible we need it to work on different systems and this is the
only way to get this information and make changes to get things working for people on
different systems.

Acceptance Testing
User Feedback
In order to help improve our project, and to gain the most insightful feedback possible, we intend to
utilize user testing. This is a process that will be done once the initial stages of the project have been
implemented and initially testing by team members.
During this process, groups of people will be selected at random to take part in a closed Beta test.
Testing will be limited to testers only playing through one stage of the project at a time, during
which they will be monitored to check how they react to certain areas of the game. Once they have
completed playing through each stage they will then be asked a series of questions from our
feedback questionnaire. The answers to these questions will be documented for future reference
during later parts of the testing process. When looking over the results of acceptance testing, we
will take into consideration what has been said about the game, what the general player consensus is
regarding certain aspects of the project and what is and is not feasible to be changed during future
development.
By using this process, we will be able to gain feedback from a different persons perspective, that of
the user who will actually be playing the game as it is released. This will help eliminate any
development bias held by team members who have worked on the game during testing.

Decapitathlon
User Feedback Questionnaire
Tester Name:
Age:
Gender:
Stage Number:
Did the game run as expected?

Was it clear what your goals were during the game?

Did the controls feel intuitive?

Did the gameplay feel consistent?

Did each microgame stand out as a unique challenge?

Do you feel the game is presented well?

Is there anything you would like to see changed?

What was your overall experience with the game?

Reaction Notes: