I am Marc San José, student of the Bachelor’s Degree in Video Games by UPC at CITM. This content is generated for the second year’s subject Project II, under supervision of lecturer Ramon Santamaria.
QA means "Quality and Assurance", this doesn't mean if the game is good or not, this says if the things done are well done or not.
So, QA workflow is a step-by-step process on how to perform tasks that "ensure" the quality of the project from the beginning to the end of the task. The workflow can change during the development of the game, because there are different phases and they need to be tested in a different way.
To reduce errors and minimize bugs, different tools are used to help us carry out our work. The most common are templates that can be easily used by anyone because they are very intuitive. Also, the organization is very important since we have to be constantly in contact with our team and provide quality feedback so that we can polish every feature as much as possible.
Here it is the typical QA workflow to make sure everything is running well:
1. Requirements: All ideas need to be clearly written down in a format that everybody understands.
2. Test Strategy: The goal is to find ways to better test the software but it should make your shareholders and investors feel confident about the product you are about to release. Creating a quality testing strategy is crucial because, once in place, it will be difficult to change. Be sure to go over the requirements documentation once again and single out the most important aspects of the target software’s environment. The “environment” can be defined as a certain operating system or a mobile device.
3. Test Planning: The success of the software under test will depend on how well the tests were carried out. If you have all possible variations of platforms that your software will be used in, then your setup is ready to go.
4. Testing: When the build is out, you are ready to go hunting for bugs. Follow the software’s navigation path and become as familiar with the software as possible. This will help if you find a bug and you want to find it from the beginning, because you will remember what steps you have done to reach that point where the bug is.
5. Pre-release: In order to ensure the highest product quality, rigorously test the software for the following parameters:
- Scalability
- Performance
- Functionality
- Platform compatibility
In most cases, the QA process and procedures occur during a time crunch and there is usually not a lot of time reserved to provide feedback to other team members from the perspective of the end user, but such feedback is extremely important.
6. Release: The QA team is responsible for the release and it requires a very organized workflow. Do not start drafting the release document on the day of release, always plan all release activities beforehand. This release documents should include all of your expectation for the software and should include all requirements and their versions. Since every product is unique and has its own set of features, other quality assurance strategies will include some extra steps to make sure all of the features are tested.
The secure workflow consists on planning everything from the start, every process that we know we have to do is planed and it strictly needs to be done to ensure that no other process is affected. Usually it is used in big teams where the roles of each member are very defined, everyone knows what job they have to do, it is more focused on individuals rather than collective work. The traditional workflow is not prepared to make changes, everything has to go as how it was planned if not the project will be a fail.
The agile workflow is an adaptive method where modifications are used to build the project over what we already have been improving it constantly and giving it more features. This workflow is normally used on small teams and projects that doesn't last long and everything can be changed and tested easily. There are few roles and the team is very flexible in general and the work we do is always in contact with the client so we get feedback that will improve the overall quality of the project.
So, normally what it should happen with small projects is that initially the team starts with a secure workflow, with everything planned from the start, but at some point the team will use an agile workflow to solve some things.
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 week 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.
There are different ways to do the testing depending on what the team wants to test. For example, if the team wants to see if some things are useless in some level or some UI is missplaced or the game goal is the expected, they won't test them in the same way. So, the test will be adapted to the objective of the test, but all of them they will have questions that the tester will have to do before and after the test.
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.
This phase is planned to do when a build or release is going to be done. This has the objective of solving as much bugs as the team can and every possible implementation is stopped.
Everything has to accomplish the customer request and it is in this phase where the team will see if it is well done or not.
If this phase is during a lot, means that something is not working as it had to. So, with this phase the team has to spend enough time to solve the majority of bugs and the implementation lets the team solving in a properly way.
Here I put an example of a report of a bug an how it works:
- Bug: Brief description about what happens.
- Status: It tells if the bug has been fixed or it is still happening.
- Step by step: It says how to arrive to the bug.
- Expected behaviour: It is what it should happen.
- Type:
- A: Game breaking bug or bug that makes the game unplayable.
- B: Bug that makes the game less playable as intended.
- C: Aesthetic, graphical or audio bug.
- Priority:
- 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 urgent bugs.
- Version: The version of the build where the bug happens.
The sources used for the research of this project are the following ones: