Index

• Introduction
• Workflows
• Milestone Delivery Protocol
• Bug Properties
• Process for Quality Control

Introduction

Welcome to the Quality Assurance Plan section. Here, you can read all the necessary information about our way to do the Quality Assurance process.

Tools used

As our game is an small project we are going too use Github Issues as our QA tracker. Labels can be personally edited for giving status to the bug. Milestones can also be created in order to have a better organisation. With this features every bug will be recorded in an efficent way.

Workflows

Pre-production

In the pre-production we have followed this workflow,our pre-production has been the external mileston called Concept discovery:

1. Assingn every document to a team member.

2. Update our scrum software(ClickUp) and move tasks to review when they are done.

3. This tasks will be randomly assigned to a team member and he will have look for mistakes or things to change.

4. If mistakes are found, the task will be reopened, if there are no mistakes,task will be considered DONE.

Beta and Alpha

Every week, we are going to make a build every Saturday using Appveyor. There will be a testing sessions performed by the Qa manager during the weekend. In case of external milestones other members of the team will also be testing the build in order to find as many bugs as possible. When finding a bug this will be the steps to take:

1. Introduce the bug in Github Issues and classify it.
2. Verify if it is a recurring bug.
3. Bug fixing
4. Testing fixed feature
5. Closing issue

Milestone Delivery Protocol

Internal Milestones:

We have planned to make 3 meetings a week, a presential on Wednesdays and two online meetings on Monday and Saturday. The build will be made on Saturdays and tested on Sundays. Bugs will also be fixed on Sundays. QA will be done by our QA manager,and he will be responsable of updating Issues. During the week, there will also be small playtest sesions, in order to test new features recently added.

External Milestones:

In case of having an external milestone,we are going to make the build on fridays,and make long sessions of playtesting,involving team members and other players, and ask them for feedback and any bug that they have found.In this case only critical bugs would be fixed, and new features wouldn't be added until the next milestone.

Bug Properties

First off, there is a common Bug Report template for all the team. Whenever a team member finds out a bug, it is needed to write detailed information about it. The bug template is as follows.

• Title: Brief description about the found issue.
• Description: Detailed information about the bug.
• Category: The type of bug. This is defined by how the found bug affects the videogame.
  • A: The bug crashes the game or freezes the screen.
  • B: Gameplay and game logic bug.
  • C: Graphics and audio issue.
• Priority: The degree of importance of the bug.
  • Critical: The bug needs to be corrected as soon as possible.
  • Very important: The bug needs to be rectified soon.
  • Important: The bug needs to be corrected fairly soon.
  • Slightly important: The bug needs to be corrected somewhat soon, but don't rush it.
  • Not important: The bug might be corrected in the future.
• Frequency: The rate at which the bug is produced.
  • Permanent: The bug always occurs.
  • High: The bug happens a high amount of times.
  • Medium: The bug happens sometimes.
  • Low: The bug hardly ever happens. It is even hard to reproduce it.
• Issue reproduction: A step-by-step of the actions to do in order to reproduce the issue.
• Issue corrected: The explanation of what should be the correct behavior of the program.
• Screenshots (optional): Although is optional, some screenshots definitely help to understand the problem better.
• Observations (optional): Any useful information that the team member considers important.

There are also the labels we will use in the development of the videogame in order to tag the bugs. Check them out in the next image. As can be seen, there are the name, color and description of the labels.

Process for Quality Control

Team Quality Assurance playtesting

As every Saturday there will be a new release available, Sunday is the day where our team members carry out a playtesting of the videogame in order to find al kind of bugs and issues about the videogame. The length of every session is about one hour, even though it can vary depending the size of the release. All the bugs found out must be reported to GitHub Issues.

External Quality Assurance playtesting

It is key to have testers that are neither developers nor friends with the development team members. This way, we have feedback from different points of views. The team must discuss who is the external tester. The QA manager will contact this person.

External playtesting structure

1. Introduction

Duration: 2 minutes. Brief explanation of how the playtesting will be developed. Explain why the information we will obtain will be useful.

2. Pre-play

Duration: 5 minutes. Interview with the playtester to obtain information about the type of gamer this person is.

3. Play

Duration: 15 minutes. Methods used: thinking aloud and observation.

4. Post-play

Duration: 10 minutes. Interview with the playtester to get information about the user experience and the aspects related to the gameplay.

5. Closure

Duration: 2 minutes. Thanks and farewell.