Skip to content

QA Plan

Jump to bottom
Pablo edited this page Mar 8, 2020 · 22 revisions

In this section, we'll explain the tools, methods, parameters and test that we'll use during the development of the game in order to ensure that it has a solid programming background and it is fun to play.

Table of Contents

Milestone delivery protocol

Big Releases

We'll do a major internal QA testing one week before the delivery of bigger milestones, done both with team members and external users. After the issues have been detected and reported, we'll be fixing them in the week we have of security margin.

Milestone Release Date Major QA Testing Date
Vertical Slice 23/04/2020 15/04/2020
Alpha 17/05/2020 10/05/2020
Gold 10/06/2020 01/06/2020

Small Milestones

We'll make a weekly build, followed by a QA test session in order to detect weekly issues and to report them to fix them as soon as possible.

Software to be used

Github Issues

In order to report and solve bugs we'll be using Github Issues. All reported issues must follow the issue template guidelines in order the ensure that the process is efficient.

GitHub Issues

Bug Report Parameters

Template

Template

Summary: Explain briefly (1-2 sentences) what is the issue.

Type:

  • Game breaking, unplayable.
  • Bug that makes game less playable than intended.
  • Aesthetic, graphical or audio bug.

Priority:

  • Urgent: It needs to be addressed and fixed immediately.
  • High: It needs to be addressed and fixed within 48-72 hours.
  • Medium: It needs to be addressed and fixed within a week.
  • Low: It needs to be addressed and fixed if there aren't more important tasks to do at the moment.

Frequency:

  • Always: Occurs more than 70% of the time.
  • High: Occurs 40-70% of the time.
  • Regular: Occurs 10-40% of the time.
  • Low: Occurs less than 10% of the time.

Steps to reproduce: Explain how the reproduce the issue step by step in a detailed way so other co-workers can fully understand it.

Actual result: Explain what happens when you follow "Steps to reproduce".

Expected result: Explain what should happen when you follow "Steps to reproduce".

Build: Build number in which the issue occurs.

Labels

  • In Review: The person with the bug assigned claims to have fixed it and it is waiting for QA approval in order to mark it as completed.
  • Fixed: Issue is fixed and approved by QA Manager.
  • Priority: That issue should be solved first in the issue queue.
  • Duplicate: The issue already exists. The QA Manager will close the issue.
  • Invalid: Issue marked as invalid because it doesn't comply with the reporting requirements.
  • WontFix: The bug has been detected and reported

Other Parameters

Assignees: Person assigned to fix the issue. Labels: Indicates information about the bug that will be seen in a sight. Projects: We won't use that property as we'll only use one project. Milestone: The issue will be assigned to the milestone in which we are currently working.

Workflows used

This is the workflow that we'll be using for our QA tests: Workflows

Process for Quality Testing

Internal QA test

The team will be making internal QA tests every week. They will be big tests if we are in front an important delivery or small tests if we are in the normal production process.

  • Big Test
    • It will be performed by the entire team.
    • It will consist in a 1-hour session in which all the team will be searching for bugs and reporting them to GitHub Issues.
    • After the session, the QA manager will make sure that they are correctly reported.
  • Small Test
    • It will have an approximate duration of 30-45 minutes.
    • It will be performed by one or two team members.

External QA test

External users will play the game and report bugs and errors in the same way that it is done in "Internal QA test". It will have an approximate duration of 30-45 minutes. It is important because external people will play the game differently than team members so they are likely to find different bugs caused by different results. External testers may be any people, there are no requirements nor limitations.

External Playtesting

We'll perform a playtesting session with people who are not from the team

  • Presentation (2 min)
    • Explain the user briefly what are we going to do.
    • Ask them about themselves and how are they feeling.
  • Pre-game questions (5 min)
    • Which is your favourite genre and game?
    • Do you usually play games?
  • In-game (20 min)
    • Thinking Aloud Method
    • Test holder observes tester and takes notes.
    • Test holder and taster don't interact during the game session.
  • Post-game questions (10 min)
    • What is your general opinion about the game?
    • What would you improve?
    • What would you remove from the game?
    • What would you keep in the game?

Disclaimer

Fallout Strategy is a non-profit game for educational purposes only. We do not intend to earn profit from it, since it is part of a university project. All the assets - sprites and audio - used in our game from the original Fallout are property of Interplay Entertainment.

Clone this wiki locally