In this section; the Quality Assurance (QA) plan, we'll be explaining the tools, methods, parameters and tests that we'll be using during the project, with the object to ensure that Warcraft II: The Stolen Artifacts is a solidly programmed and fun game.

• Tools used
• Milestone delivery protocol
  • External milestones
  • Internal milestones
• Workflows used
• Bug report parameters
  • Parameters for the template
  • Label parameters
  • Other parameters
• Process for Quality Assurance & Quality Testing
  • Internal QA test
  • External QA test
  • External QT
  • Bug Fixing

The tool it will be used for reporting bugs is Github issues. The process for reporting a bug is to just press the “New issue” button and fill the template that is provided to describe everything that is needed to know about the bug. Every reported bug must be reported following the parameters specified by the issue template we use. If it is necessary, a label can be added to a issue, which provides miscellaneous important information about the bug.

A week before every external milestone there will be a major internal QA testing where all the team will participate. There will also be three or four external Quality Tests. After these sessions, the team will make the pertinent changes to the game.

April 17th:

• Vertical Slice

May 15th:

• Alpha

June 6th:

• Gold

A build will be made every saturday, and a QA test session will be made every sunday. In this test session one or two members of the team, including the QA manager will be testing the game. Instead of internal tests, several external tests will be made every three weeks, unless it is the week before an external milestone.

Workflow for performing the QA tests and its implications.

Workflow for performing the Quality Tests and its implications.

• Title: Short phrase about what the bug is about.

• Summary: Provides a quick explanation about the bug.

• Type: Which type of bug it is, regarding how important it is to the playability:*

         -A: Game breaking bug or bug that makes the game unplayable.
         -B: Bug that makes the game less playable as intended. 
          Example: Player does 10 units of damage, instead doing the intended 20 units of damage.
         -C: Aesthetic, graphical or audio bug.
  

• Priotity: It must be indicated the priority of the bug among the others:*

         -Urgent: Bug needs to be fixed immediately.
         -High: Bug needs to be fixed within a day or two. 
         -Regular: Bug needs to be fixed within a week.
         -Low: Bug needs to be fixed whenever there aren't any high or critial bugs.
  

• Frequency: It must be indicated how often the bug uccurs in a normal play session:*

         -Always: Unavoidable bug. Occurs every play session.
         -High: Occurs very often, but is avoidable.
         -Regular: Not a very common bug. Occurs seldom.
         -Low: Very rare bug. Harldy ever occurs.
  

• Steps to reproduce: It has to be explained in detail how to reproduce the bug.

• Actual result: It has to be explained what happens in the game when someone follows the “Steps to reproduce”.

• Expected result: It has to be explained what it should happen when someone follows the “Steps to reproduce”.

• Build: Build number in which the bug occurs.

• ClaimFix: This label is put when the person that has the bug assigned claims to have fixed it.

• Duplicate: The bug is repeated. In this case, the QA manager, has to file the issue.

• Fixed: This tag is assigned after someone claim fixes the bug, and tested the game again, the bug is actually fixed.

• Help wanted: The person who has to fix the bug requires that someone from the team helps them with the bug fixing.

• Invalid: It isn’t a bug, so the issue must be deleted or filed.

• Priority: This bug needs to be fixed before the others.

• Question: The person who has to fix the bug doesn’t understand something from the bug report.

• WontFix: The person who has to fix the bug, won't fix it for whatever reason that has to be discussed with the person who reported the bug and/or the team.

• Assignees: Every bug has to be assigned to fix to someone. This someone can be assigned by the person who reports the bug, by the same person who will be fixing it, or by the QA manager.

• Label: Indicates miscellaneous important information about the bug.

• Projects: This property isn’t necessary, as we are going to work in one project.

• Milestone: The bug will be assigned to the sprint in which the bug is found.

*Type, priority and frequency parameters have sub-parameters that have to be marked with an "X" in the issue report.

A build will be made every saturday, and a QA test session will be made every sunday. For big tests the whole team will be testing the game for approximately 1 hour, for small ones, the one or two members of the team testing the game will be arround 30 to 45 minutes testing it. Every bug that is found by someone in the team will be reported in Github issues in the way that it is explained in the previous sections. After the QA testing session, the QA manager will be revising that every issue is well made, given the parameters explained in the previous sections. The bugs reported will be fixed and revised during the week.

These tests follow the same process as the internal QA tests (duration 30 - 45 min). External testers will most surely play the game differently than members from the team, so there needs to be external tests to find bugs that the members of the team can't find. The external testers will be proposed by any member from the team.

Quality Tests are made by external people of the team to ensure the game is as fun as intended. Testers have to be sincere people, preferably people not related to the team members. Testers will be proposed by any member of the group the weak before the Quality Test. The tester needs to be someone who doesn't play videogames casually. The team will decide if that person is adequate to test the game. In case that the team has conflict choosing a tester, the QA manager will be who has the last word. The tester will be contacted, and if he/she accepts to be tester, the tester and the test holder (can be anyone from the team) will specify a day and hour to perform the test.

How the test will go:

• Presentation (2 min)

• Pre game questions (5 min)

        -Which is their favourite genre.
        -Do they like/play Warcraft or any other RTS video game.
  

• Core playtest (20 min)

        -Thinking aloud method will be the one used (the tester speaks what they think while playing the game).
        -The tester is observed by the test holder.
        -The test holder will have minimum interaction with the tester.
        -Test holder takes notes.
  

• Post game questionary (10 min)

        -What the tester thinks abut the game in general.
        -What they would improve about the game.
        -What they would keep.
  

• Thanks and send-off (2 min)

After the Quality Test, the test holder will put together everything the tester said and present to the team how the playtesting went. Then, it will be decided if there should be some design change or not. If the team has a conflict regarding the change of something in the game, the head designer of the team will have the last word regarding this problem.

Starting every morning every week, and continuing through the week, the members of the team that have bugs to fix assigned to them, will be fixing them. Every time someone from the team fixes a bug, they will be commiting the code to github to the Bug-Fix Branch. After all bugs are fixed, the code lead will ensure that all the bug-fix branch pulls are commited into the Development Branch.

< Previous | Next >