7. QA Plan
This is the Quality Assurance (QA) plan section where the tools, methods, testing and its parameters used during the project will be explained. We aim towards Fantasy Brawl to be a fun and solid game.
Github issues will be the main tool for bug reporting.
Pressing the “New issue” tab will bring you to the issue template. Everything about the bug should be described following the template. Labels can be added if needed.
The week before every external milestone all members of the team will have testing session. Just after every external milestone, an open external QA testing will be done, so external feedback will be gathered to aim for the next milestone. The external milestones are:
April 23rd/25th
- Vertical slice.
May 20th/21st
- Alpha.
June 3rd
- Gold.
Wednesday is the main day of QA. An internal testing session will be made with two or more members of the team including the QA manager. Also right before every internal objective accomplishment a short testing session will be prompted immediately. External testing sessions will be made after every milestone and the day will vary depending on availability.
Workflow used for QA testing.
Template for the bug reports.
Template description:
-
Title: description of the bug in few words.
-
Type: which type the bug is:
-Fatal: gamebreaking,unplayable.
-Unintended action: something is working not as intended.
-Aesthetic: minor aesthetic, Audio or graphical.
- Priority: indicate the priority of the bug among the rest.
-ASAP: The bug has to be fixed "As soon as possible".
-High: The bug has to be fixed in less than 2 days.
-Medium: The bug has to be fixed in less than a week.
-Low: The bug has to be fixed whenever there's no higher priority bugs.
- Frequency: indiate the frequency in which the bug occurs as if the game was played normally.
-Everytime: Cannot be avoided during playsession.
-High: Avoidable, but occurs very often.
-Regular: Rare to occur.
-Low: Hardly ever occurs:
-
Description: detailed description of the bug.
-
Reproduction: detailed description of the steps to reproduce the bug.
-
Expected behavior: detailed desription about what should happen.
-
Game version: current version of the game.
-
Additional Context: extra details or information (f.e. screenshots).
-
Suggested Assignees: team members suggestion for bug fix.
-
Assignees: assignated team members to fix the bug. Done by the QA manager, the bug reporter or the bug fixer itself.
-
Labels for bug reports.
- CheckFix: fix verification needed.
- Duplicate: the bug report is duplicated, already exists.
- Priority: higher priority than others.
- Fixed: fix verification successful.
- Help: the assignee requires help form other team members.
- Invalid: Not a bug, needs to be deleted.
- Question: more information needed about the bug.
- Wontfix: The bug won't be fixed, the reason has to be discussed and reasonable.
-
Projects: won't be used since there will only be one project.
-
Milestone: detail inside which milestone this bug is reported.
- Weekly QA testing sessions set on Wednesday will be made by two or more members including the QA manager. This sessions will have a duration of 30-40 minutes. The bugs found will be reported as explained before and the QA manager will check that the reports all well made.
- Full member testing sessions set a week before milestones will have a duration of 1 hour aprox. The bugs found will be reported and checked aswell.
The week after a milestone open testings will be done. External testers will play the game differently than the internal members. They may find bugs not found by the internal members. Testers can be proposed by the team members but also these test sessions will be announced via social media so anyone can join.
- A Google form will be used to gather the reports and opinions of those.
The week after a milestone a closed testing session will be done as well if possible. The tester/s will be selected by the team. The tester selection criteria will prioritize people that doesn't habitually play videogames. This session will be face-to-face. The date and place will be set according to the disponibility from the team/testers.
- The testing sessions will follow a similar pattern from the Google form .
- The thinking aloud technique will be used.
- Watching the reactions of the tester in real time will provide useful information aswell.
After both open and closed testing sessions all the suggestions will be put toghether and with the team their relevance will be discussed. Design changes will be made if there's an agreement or if the designer finds them necessary (him having the final word).