Monday
We had a guest lecture from Georgia Mae Ayling, a QA analyst who has worked at EA and Rocksteady Games. She had a lot of insight into how QA works within the industry. QA = Quality assurance, which is the maintenance of a desired level of quality in a service or product. In the context of game development, some responsibilities could be:
- Build verification
- Finding and reporting bugs
- Documenting Process
- Writing, Maintaining and Running Test Cases
- Usability Testing
- Develop Testing Tools
- Verifying Bug Fixes
Several divisions function within the bracket of QA:
- Functional Testing
- Generalised QA Testing
- Playthrough testing
- Smoke Testing (verifying a build)
- Localisation Testing
- Fluent in multiple languages
- Anything on screen is localised to the language they are working in
- Checking the game culturally and linguistically makes sense
- Compliance Testing
- Making sure the games meet standards set by the platform (Steam, IOS, Android)
- Making sure the game hits the studio’s internal goals
- Complying with censorship
- Dev QA
- Supporting design and development teams with troubleshooting
- Connection between QA and other development teams
- Specialist Field Testing
- Art and Animation testers
- Game specific elements
- Audio
- SDET
- Software Development Engineer in Test
- Writes, develops and manages automated testing
Design Changes VS Bugs
| Design Issues (Usability Issues) | Bugs |
| Is it playable to someone who has never played the game before? Examples of issues: – Unclear Objectives – Narrative Issues – Confusing Visuals – Inconsistencies | A defect in your software. Examples of issues: – Crashes – Performance Issues – Cosmetic Issues – Functional Game Flow Issues – Certification / Compliance / Legal Issues |
| Testing for Design Changes tips | Testing for bugs |
| – Watch someone play the game – Don’t give any info – Take detailed notes – Ask questions | – Don’t play the game ‘normally’, try to play it in ways curious players might. Hit the wrong things, try to walk backwards etc. – Try to account for the multitude of ways people will play your game. |
The limits of testing your work:
- You know what you’ve made; difficult to pretend
- Giving yourself honest feedback is hard
- Scale of resources
When you test your work:
- Have set precursors for quality; what makes a good, better and great game/song/art piece
- Break it down into sections!
- Example: “Today, I’m going to try and break the: Features, Gameplay, Character, Environment.”
- Get feedback on your product, may reaffirm the decisions you made
For working with a QA team:
- Document your work clearly – the more clear, the better
- Test your work before you submit
- A QA team is very important to the dev cycle – be patient with them!
What can I and the Kinetic Panic team learn from this talk?
- Get feedback from people other than your team and yourself.
- Document your process so people can see why you made certain choices; sometimes people have to change their feedback when they know the process of why I did XYZ instead of ABC.
- Write down any loose/off-hand comments people say about your work (e.g. “The character is cute/cool”, “This part is hard!”); it could help you formulate what people think about your game.
Thursday
For the Thursday presentation, we had to talk about our role, what we’ve done so far, what went well, and the current challenges and help you might need. Here is what I said in my slides to explain my role and work:
