Download to read offline
Uploaded byDevGAMM Conference
QA For Indies / Tiberiu Cristea (tinyBuild)
The document is a presentation by Tiberiu Cristea, a QA lead at Tinybuild LLC, aimed at indie game developers seeking success through quality assurance (QA) processes. It covers the importance of early and integrated QA, various types of testing, and the use of tools for effective QA management. Key takeaways include the necessity of proper QA for game success, which involves planning and tailored approaches depending on the game's features and target platform.
More Related Content
Similar to QA For Indies / Tiberiu Cristea (tinyBuild)
QA For Indies / Tiberiu Cristea (tinyBuild)
- 1. QA FOR INDIES TiberiuCristea, PMP QA Lead, tinyBuild LLC
- 2. Nice to meetyou! ● I’m Tiberiu, from Romania ● I oversee QA for tinyBuild ● 15 years of XP in video game QA ● Today’s talk: QA for indie devs
- 3. Target Audience Indie devsin search of success ● Single dev who codes at night ● Team spread around time zones ● Small studio working on 1st title
- 4. In This Presentation ●Introduction to QA ● QA Tools & Testing In Agile ● Console QA ● Publishers
- 5.
- 6. What Is QA? ●QA ≠ Testing ● QA is an integrated process ● Start early, plan & act for quality ● Control deliverables (testing, or QC)
- 7. Quality vs Grade ●You can make a cheap, simplistic game, a AAA title, or anything in between. That’s grade. ● You can make a buggy or a bug-free game (or anything in-between). That’s quality.
- 8. QUALITY GRADE LOW GRADE LOW QUALITY HIGHGRADE LOW QUALITY HIGH GRADE HIGH QUALITY HIGH GRADE HIGH QUALITY
- 9. QA As AnOngoing Process ● The good news: You’re already doing QA. ● The bad news: You probably need to do better.
- 10. Types Of Testing- Functionality ● Is everything functional? Is the user experience enjoyable? ● Game Features / Systems / Loops ● Game design & common sense used as a basis
- 11. Types Of Testing- Compliance ● Employed when dealing with a gated platform ● Strict lists of requirements used as a basis ● Will the platform accept the game?
- 12. Types Of Testing- Localization ● Employed when the game has been localized ● (Non-)Native speakers look for linguistic issues
- 13. Types Of Testing- Other ● Performance testing ● Compatibility testing ● Age rating ● Online / load / live QA testing
- 14.
- 15. Test Cases -The Basic Test Units ● Usage scenarios ● With expected results ● Which are compared to actual results when test case is executed
- 16. Test Cases -Structure Actions: 1. Boot up the game. 2. Start a new single player campaign. 3. Progress until the end of level 6. Expected result(s): The intro cinematic for level 7 starts playing. Actual result(s): Level 7 starts without an intro cinematic. Test Case Status: FAILED Bug: DFKT-198
- 17. Test Cases -Generation ● Holistic approach to product ● Top-down breakdown of features ● Full coverage of each element
- 18. SUPER DUPER GAME 1.Single Player 2. Multiplayer 3. Level Editor 2.1. Maps 2.2. Game Modes 2.3. Character 2.1.1. Map #1 2.1.2. Map #2 2.1.3. Map #3 2.1.3.1. LD 2.1.3.2. Level Art 2.1.3.1.1. Map Boundaries 2.1.3.1.2. Interactive Objects 2.1.3.1.3. NPC Navmeshes
- 19. 2.1.3.1.1. Map Boundaries ●1st pass: 11-13.07; 2nd: 26-28.07 ● Resources: Alice, Bob, Charles ● SoW, acceptance criteria, dependencies etc.
- 20. Test Case ManagementSystems ● Nb. of TCs can easily balloon up ● Proper organization required ● Spreadsheets or TCM systems ● Good test cases > complex TCMS
- 21. Bug Trackers ● Bread& butter of testers ● Big or small, improvised or professional ● Good bug reports are essential
- 22. Test Automation InVideo Games ● Holy grail ● Difficult to do once prod starts ● Has to be planned in the beginning ● Not much it can achieve
- 23.
- 24. Testing In Agile ●Test early, test often ● Testers embedded in agile team ● Integrate expected results into DoD ● TCs derived from user stories ● Sprints offer testers visibility
- 25.
- 26. Testing On Consoles ●Whole new world ● First-party reqs. are strict ● Specialized testers recommended ● First-parties do not do QC for you
- 27. Peripherals Branding Localization Retail Mastering Age Rating Regions/ SKUs Legal Performance Voice Chat Matchmaking Parties & Invites Stores / IAPs Naming Conventions Achievements DLCs Online Subscriptions Back & Fwd. Compatibility Optimizations Cloud saves Suspend / Resume Cross-platform Metadata Parental Controls Patches
- 28. Testing Console Ports ●Original game is assumed tested ● Testing interaction between the game & console ● Making sure it’s not bursting at the seams
- 29.
- 30. Myths ● You needa publisher for proper QA ● Publishers can guarantee your game passes certification ● Proper QA is easy
- 31. QA - HowPublishers Do It ● Some do it all in house ● Others hire external QA ● All will set quality requirements for your milestones
- 32.
- 33. Takeaways ● QA iscrucial for the success of your game ● Proper QA is a complex thing which needs careful planning ● You can do it on your own if you know what you’re doing
- 34. Q & ASession Thank You! /tdcristea tiberiu.cristea@tinybuild.com
Editor's Notes
- #2 Hello, everyone and welcome to this talk.
- #3 My name is Tiberiu Cristea, I currently live in Bucharest, Romania and I work as a QA Lead for a publisher called tinyBuild. You might have heard about us or you might have played some of our games - if not, I encourage you to, because they’re definitely fun. Previously in my career I did QA for various European studios belonging to the Ubisoft Group. I have worked on the last three generations of consoles, but also on PCs, Macs, mobile devices. I tested or managed testing for all kinds of titles, anything from casual to blockbuster AAA games. This is my second DevGAMM, but it’s also my first time as a speaker an industry conference. I would like to thank the organizers for this opportunity. I hope everyone is enjoying DevGAMM and I also hope you will also learn something useful from this talk. So without further ado, let’s roll! As you’ve already noticed, the title of the talk is QA for Indies. We should probably describe the target audience first.
- #4 This talk is geared towards dev teams who are looking for their game to be the next viral indie hit. Your might be a team of one, spending your every spare second working hard on a game where you’re the designer, the coder, the graphics artist, the tester, while also performing any other role in between. Or yours might be a diverse team of let’s say 7 people, coalesced around a single vision, spread around continents and time zones, each of you with definite roles - although some of you might moonlight as testers when needed. Or you might be part of a small studio with a full-time, dedicated QA team, looking forward to the big release of a title which has been in the works for the past 3 years. Regardless of your background, what unites you - apart from a love of video games and a willingness to make it in the video game industry - is the need for proper QA. That’s right! You cannot release your game to the public without having strong, reliable quality assurance processes in place. And this is what I’m going to talk about next.
- #5 We’ll start with a short introduction to QA, demystifying some misconceptions while we’re at it. Then, we’ll talk about the tools you need to succeed. We’ll also cover the particularities of testing under agile methodologies of software development - which are particularly well suited for small teams. But we’ll also discuss the big elephant in the room, which is QA on video game consoles. If you make a successful game, sooner or later, you might want to port it to consoles - and that comes with its own can of worms in terms of QA. Lastly, we’ll discuss a little bit about the role of publishers in relation to QA. And at the end, we’ll have a Q & A session. Note down your questions as we go, and I’ll do my best to answer as many of them at the end of the talk.
- #6 So, in order to be able to discuss QA, let’s define it.
- #7 Or better said, let’s start with what QA is not. QA is not testing. While testing is part of QA, we need to look at QA as an integrated process. And the first clue lies within the name: Quality Assurance. Obviously, it has to do with Quality, but what about that Assurance part? In some other European languages, speakers might confuse Assurance with being certain about something. And as we all know, nothing in life is certain, other than death and taxes, as Benjamin Franklin famously put it. QA cannot ensure the quality of a piece of software. But - if properly done - it can provide a level of assurance, of confidence, that the final product is a quality product. To use a food analogy, think about a Michelin-starred chef using an expert, proven technique to cook an omelet using ingredients of the highest quality. What do you think the final product will look like? There’s a very high chance it will be a very delicious omelet which will also look absolutely mouth-watering. So the effort you put in and the quality of the ingredients you use will reflect in the quality of the final product. This is also true for software, and especially true for QA. QA does not exist in a vacuum - it’s a set of processes which need to be tailored to your game, to your roadmap, to your team, and to your milestones. This means it’s integrated: with the development process, with the project itself, with the actions and activity of your team. You need to start thinking about QA as early as possible, and plan for it. Planning for QA means planning for quality – this is absolutely essential. Once you have a plan, you can start testing. That is, you can start controlling the quality of the deliverables at various stages throughout your project. Based on the data you gather from this activity, you decide if changes in the product or in the quality assurance process itself are required. Hence, testing is often called QC, or quality control, but many people confuse it with QA. It’s important to keep in mind that QC is part of QA.
- #8 Now let’s discuss a bit about what is quality. How would you define a quality game? Is a game with raving reviews on Metacritic a quality game? Do critics decide the quality? Do users? Is a sales records-breaking game a quality game? Is quality decided by popularity? Is a AAA game a quality game? It costs a lot of money to make, so it should better be, right? But then again, can cheap games be quality games? To answer these questions, we need to understand the difference between two concepts: quality and grade. Simple games like Flappy Bird exist. Just like there’s a place for the latest Assassin’s Creed or the latest battle-royale hit, with room for anything else in between. This is called grade. What kind of grade are you targeting for your game? What are your game’s production values? Assigning a grade creates some expectations from your players. Surely any game in the AC franchise must have an engrossing story, right? Just like we’re expecting a game like Flappy Bird to be exactly what it is: mindless entertainment with lots of replayability and a codebase of a couple hundred lines. Gamers have an innate ability to understand grade in video games. They can tell grade from a mile away. But then, a game can be a buggy mess where features are missing or they’re partially working, stability is all over the place, performance sucks, and players are pulling hairs trying to get past the first level. That’s a low quality game, regardless of its grade. Yet, a game where you never crash, you never run into bugs, a game which runs smoothly on your integrated GPU but then also takes advantage of that beast of a video card in your PC, a game which never breaks your immersion because the UI has been thoroughly optimized for your input method - that, my friends, is a quality game. And it could be a simple match-3 game, a Formula 1 simulator, or a deep narrative big budget title which makes grown men shed tears – just like with grade, gamers will always know quality when they see it.
- #9 Here’s a nice, simplistic matrix which can be used to understand these two concepts. If a game falls in the lower left quadrant, it sucks. Even if it’s a low grade game, gamers always expect quality – and such a game does not deliver. A game also sucks if it falls within the upper left quadrant. In this case, it’s probably some big-budget title which was rushed out the door and now your players are creating viral memes out of the glitches they found while playing. You’re probably thinking about such titles right now. The right part of the graph is now self explanatory: these are all high quality games. They’re polished, thoroughly tested, and their developers have fixed even the minor bugs. Players are having a blast. They could be pushing a ball around, or forcing an avatar to jump in sync with catchy music. Or they could be cooperatively fighting bad guys or monsters in some dark, futuristic setting. It does not matter - what matters, is that these players are enjoying themselves. They’re entertained. Mission accomplished, I’d say.
- #10 Now, what can you do if you want to reap the benefits of proper QA? I have good news for you: if you’ve already started coding your first game, and you’re hard at work debugging lines of code, you’re already doing QA. You are already thinking about quality, about how memory usage could be optimized, about making your scripted events run every time they’re initiated. You’re chasing bugs around, even if you have no test team because it does not yet make sense to have one. You’re planning features in your head, you’re thinking about implementing them in a certain order, so that the small building block you’re working on will join some other pieces of code to make a whole later. And that whole has to behave in a certain, expected way, right? You’re already thinking about quality, but you might not even know it yet. The bad news? It’s probably, almost certainly not enough. There comes a point when you have to take a deep breath and think about quality in a structured, planned, continuous manner. And to do that, you need to first understand what kind of testing activities exist.
- #11 Functionality testing is the most common type of testing. And it’s also the first type of testing you do when start making a game. It’s also the most time consuming - almost disproportionately so. Functionality testing looks at the features in your game, at how they work, and at how they can go wrong once they’re executed. It requires a thorough understanding of the game’s design, and it’s not uncommon for functionality testers to find bugs in your game design requirements even before they have launched the game for the first time. It’s all about asking yourself questions such as: what could possibly go wrong? What happens if I do what the game expects me to do? What should happen if I do the opposite of what the game expects me to do? Are there any ways to do neither? Or the classic: what does this button do? Functional testing for example, can inspect 3D assets for bugs, outside the game, maybe in an editor. This is called testing at unit level. Later, they can look at how that 3D assets interact with other assets in the game world. That’s called integration testing. Let’s say you created a game where combat is 80% of what players are doing in game. Functional testers will thoroughly test the weapons, the damage models vs various enemies, the player character’s abilities, and so on. But they will also test if the day/night cycle triggers correctly, or if the weather system is random enough. And, of course, they will also tell you if your core gameplay loop has issues, or just whether it’s enjoyable or not. In the end, they eventually test the entire game as a whole, as a system of systems. Because as game systems interact with other systems - issues will definitely appear. All this activity is driven by two pillars: the game design, which decides how the game should behave and the common sense and experience of the tester You can have your test team read the game design codified in a huge document, or you can pass a tester over the controller and ask them to play Pong for the first time in their life. In both cases, they’ll have an understanding of how the game should behave.
- #12 Let’s discuss compliance testing. You might have chosen to release your game on a gated platform. There’s a gatekeeper company, such as Apple, Nintendo or Amazon which you need to get approval from before they’ll let you sell your game on their platform. It’s a private club and you must qualify for access. But that’s fine, since the potential reward is access to huge user-bases, and these platform owners want everyone to offer quality games to gamers, right? Well, yes and no. Of course they want to carry your game, so everyone involved makes more money. But you have to fulfil a huge list of requirements, some arcane, some which you simply might not understand. What if there were someone able to help you? Someone who knows what these requirements are and can tell you if you’re not fulfilling them? Fortunately, these people exist and are called compliance testers. By running a battery of specialized platform requirements test cases against your game, they can eventually tell you - with a high degree of confidence - whether the platform will or will not accept your game.
- #13 Another interesting area of testing is localization. In today’s global market, more and more developers choose to localize their games to reach wider audiences. But is the process over once you have received the translations from the localization house, got them through proofreading, and implemented them into the game? Unfortunately, not. Even the best translations can suddenly get cut off inside your game. You probably didn’t account for German having longer words than English on average when you designed the tooltips, right? Or the menu items? Or the UI elements and buttons? Or maybe you missed the fact that some cpecial characters are not correctly displayed. What a mess! But worry not: localization testing is here to help. By asking native or even non-native speakers to review your game, these issues can be found and reported as bugs. Native speakers can also highlight issues with the tone and consistency of the translations. They can also report grammatical or style issues which might otherwise go unnoticed. Create your game in a single language, and thoroughly review it for consistency and tone. If this language is not English, then make sure you’re getting a quality translation into English - as you will then probably use English as a source language for translations to other languages. Localization is a chain and it’s only as strong as its weakest link. Once you’ve integrated the translations into your game, it’s time for a couple of rounds of localization testing.
- #14 At any time during development, you might become concerned with the performance of your title. Depending on the platform, there might be few or lots of devices targeted by the game. Performance testing rounds, executed at carefully chosen milestones in your project, can provide extremely useful information and guide the development further. Ignore it at your own peril. Performance testing is usually done by functional testers, but it’s also a matter of device availability. Plan it well, and learn your lessons - and you won’t have issues. Compatibility testing is related to performance testing - but it’s not the same. Both require lots of devices to test on, but while performance testing looks at how your game performs under full load on various devices, compatibility testing tells you how your game runs at less common screen resolutions, or if the UI gets stretched on an ultrawide aspect ratio. It also tells you if a two year old smartphone correctly opens the store when players attempt to buy some virtual currency for your game. If you want your game to run properly on a various range of devices, you need compatibility testing. Both compatibility and performance testing are important and have their own place in the economy of QA. Another type of testing you might want to know about is age rating. Many first-parties require you to have your game rated by an age rating agency before they will allow it onto their platform. Age rating tests start with whatever rating you’re targeting, and then tell you if the game meets that rating, so you won’t have any surprises from the age rating boards. Of course, if your game relies heavily on online connections or is designed for a huge number of concurrent users - you might want to consider load testing, a.k.a. stress testing. But even if it’s a 4 player coop multiplayer game, you still need to test the networking, and make sure the experience does not significantly degrade under bad network conditions. Once your game has been released, you might want to keep an eye on post-launch issues with live QA testers. They can work closely with customer support and community management, helping them reproduce issues and report bugs. As you probably already know – if not, you will soon find out – Live environments and dev environments are never quite the same.
- #15 Now that we know what types of testing we might need, it’s time to understand the tools of the trade.
- #16 The most basic tool in the arsenal of a tester is a test case. A test case is a usage scenario expressed as a set of steps to perform. Once the steps are performed, there is an expected result. And that’s what a test case is. Simple enough, right? Once a test case has been executed, the actual result is compared with the expected result. If they’re the same, the test case has passed. If they’re different, the test case has failed and we most likely have a bug to report.
- #17 Here’s what a test case can look like. We have the set of steps to perform, the expected result, and the actual result, which - in this case - are different. Therefore, a bug report is created and the test case status is marked as failed.
- #18 Now you could ask yourself, how are test cases created? Is there a logic to it? It most certainly is. There are various ways to go about it, and the most common one is to look at the product as a whole, and then separate it into pieces. Then those pieces are separated into smaller component pieces, which are then further separated and so on. Keep doing this until there’s nothing left, or until it does not make sense to break something down further. It’s a top-down approach. Once you have all the pieces, you can start from the bottom up, making sure each piece is at the bottom is fully tested. Then you move up the branch, and keep testing until there’s nothing left. Let me exemplify this in the next slide.
- #19 Let’s say we have a game called SUPER DUPER GAME. You have planned for a single player component, a multiplayer one, and a level editor. These will pretty much be present in the main menu, as avenues for the player - who will decide what kind of experience they will have. Let’s take a look at multiplayer. What is multiplayer comprised of? Maybe this is a classic shooter game, where players confront each other in an arena. So we have maps. But we also have different rulesets for the players, which are the game modes - team deathmatch, free for all etc. And we also have a character component, because each player is able to customize their characters with classes, gear, cosmetics and so on. Looking at the maps, they’re obviously self contained. The third map, for example, has two things going on about it: level design, and level art. Without players, they’re just empty shells, waiting to be loaded and be played on. Level design establishes the map boundaries, how big it is, the general directions of player movement, where the bottlenecks are, and the general structure of big objects. It also has to do with placing points of interest, chiefly interactive objects and the stuff which will trigger when these objects are interacted with. Let’s say the map also has some neutral mobs patrolling around - the level designer is the one creating the navigation meshes for these mobs, deciding where they can and cannot go, what their reactions are and so on. The level artist is the one populating the map with smaller objects, dressing it up, placing textures, making it look much better, and optimizing the VRAM usage by monitoring the total number of polygons in the objects. You can see how we used branching to go down on one path, until it did not make sense to go down further. This is an example of a work breakdown structure, and the lowest element in each possible branch is called a work package.
- #20 Let’s look at an example of a work package. It can include information about when it’s supposed to be tested, how many times etc. It can list the necessary resource requirements, and the statement of work - which is actually a description of what needs to be done. In our case, it could be a list of test cases. It can include the acceptance criteria - for example, we can consider the work package done when all test cases have passed. If there’s a dependency; for example: testing cannot start until some other task is completed. In the end, after we decompose our entire game into work packages, we create and assign test cases to each, we schedule everything and only then we can start executing them. This top-down model makes everything accessible, visible, and forces testers to think about stuff which might otherwise be missed. Of course, there’s no need to create all of this before you start testing - and in agile frameworks, nobody spends time drawing the full tree - they might just look at a tiny little branch because the entire tree is not yet available, but the process is the same.
- #21 It’s easy to see how such an approach could result in thousands of test cases. Actually, it’s not uncommon to see such numbers, given the size and complexity of video games nowadays. If follows that we need some kind of logic, some kind of framework to organize all of this. Some use good old spreadsheets to keep track of everything. Does it work? You bet. Is it cumbersome? It certainly can be. This is where test case management systems come in - stuff like TestRail can bring various QoL improvements to both testers and test case designers. And it has certain advantages over Excel or Google Docs. But never forget the essential, which is that test case management systems are not a replacement for good test cases – they’re just a tool to manage them. A spreadsheet with well developed test cases is better than an advanced funky test suite full of bad test cases, or test cases which do not sufficiently cover the feature or the product. And one more thing: always set aside time for exploratory testing, as overly relying on test cases can result in tunnel vision, which can cause your QA team to miss things.
- #22 Bug trackers are databases where bugs get reported. It’s where the testers spend most of their time, besides the tested game itself. Bug trackers can range anywhere from spreadsheets and Trello boards, to professional bug tracking software such as Jira or Trac. Regardless of what you’re using, well written bug reports – just like good test cases, require some essential fields: summary, description, steps to reproduce, reproduction rate, expected result and so on. Now I won’t dwell on this – mostly because this is such a lengthy topic to discuss, I could just make an entire two hour separate presentation about it. So maybe some other time
- #23 I’m often enthusiastically told about automation and how magical it is. It’s true, with automation dev teams can reach new heights, and focus on what actually matters: creating an enjoyable experience for gamers. But automation is not something which you can just patch in and hope it will tremendously improve your QA processes. I’m more of a manual testing guy, but I know for sure that automation has to be integrated and planned for since the very beginning. You simply can’t “add it later”, especially if you’re well into production. Also, while automation works very well for desktop software, websites, or 2D mobile apps, it’s very difficult to apply to systemic 3D video games. Some big studios can afford to do it properly, with good results but it requires a strong vision, dedicated personnel (including scripters and automation testers) and full cooperation from the developers. If you’re a small shop, chances are you won’t be using automation a lot, unless you’re some code wizard or something.
- #24 Time to talk a bit about how to test in Agile. Many small teams work agile, as it makes a lot of sense. Testing in agile has some particularities which I would like to discuss next.
- #25 Just like “release early, release often” is an agile mantra, we can also extend this to testing in agile. Any agile team worth its salt will have someone who is mostly if not exclusively a tester. It’s good to have testers embedded right into the team, and to allow them the same freedom the other team members enjoy. After all, this is how agile works, right? The advantage of having testers as part of the team is that they have a particular way of looking at things which comes in handy when you’re working on features. Are you planning something new? Then why not listen to what your tester has to say? You might be surprised when they bring up some angles which you did not think about. Or you might hear the tester say “but how are we going to test that?” right when you present the team with a new user story - and they will be right. Whenever you’re planning something, and whenever you’re working on the definition of done, allow the tester to chime in and I promise you, your project and your clients will be much better off because of this. It’s a very good practice to actually integrate test cases straight into the DoD. Also, since we’re in agile, no huge design bible has been previously written. The product emerges as the team iterates on it. In this case user stories alongside common sense, of course, can serve as a basis for deriving test cases. Testers should work with designers to find flaws in user stories, even before implementation work actually starts. And last, but not least, working in sprints offers testers the visibility they need to do their work properly. This is another advantage of agile.
- #26 Remember when we discussed about compliance testing? Testing on consoles comes with its own set of headaches. Let’s dive in.
- #27 Consoles are a whole new world. The requirements are strict. You’re much better off using compliance specialists to test your game, and to top it off, even if the first parties will test your game, they will not do QA for you. They will, instead, try to make sure the game is at a minimum stabled and functional, and that it plays well with their platform. Getting certified does not necessarily mean your game will sell a lot, or that it’s even a good game, absolutely nothing like that. You can get a crappy game certified if you want, there are lots of examples out there :) But what first-parties absolutely hate is receiving games for certification where it’s clear the publisher or the developer has not made an honest effort to have the game tested before submission. They also hate it when, on resubmission, it’s clear that you have not made an honest effort to fix the issues they previously reported. If they find too many issues, they can stop testing at any time and reject your game outright. You need to thoroughly test the game to the best of your abilities before sending it for certification. And if bugs are found during certification, you absolutely need to try at least to have them fixed. The cert process is not a substitute for the actual thorough testing which the developer / publisher has to do on its own.
- #28 Here are just a handful of things you need to test before submitting your game to console certification. Your game probably hooks into certain optional features of platform, but in some other cases you are mandated to use such platform features. Especially if your game has multiplayer or sells additional content. You have to get your patches certified, too – and if you also plan to have a retail release you need to deal with mastering discs or cartridges.
- #29 Another particularity of console testing is that many indie games arriving on consoles are actually PC ports. This changes things a little bit, in that the original game has probably been functionally tested on its original platform, so the amount of functional bugs is usually reduced in a port. Of course the reverse is also true, in that if a bug is present on the original platform, it can easily migrate to the new platform. However, in the case of ports, testing should focus more on the interaction between the game itself and the platform it’s being ported to, making sure it’s not bursting at the seams, if I may use a figure of speech. A ported game finds itself in a new environment: it’s maybe using a controller for the first time, it runs on a fixed configuration, supports new overlays specific to each console, it’s plugged into a new achievement system, is probably forced to use the platform’s invite and matchmaking systems, while it also maybe needs to look good on a screen as small as the Nintendo Switch. By focusing on such specific areas, testing becomes much more efficient, as this is where most bugs lie in case of ports.
- #30 We are quickly reaching the end of this talk, and I’d like to discuss a bit about publishers.
- #31 Let’s demystify a couple more things: You need a publisher for proper QA: absolutely false. You can do it yourself, but it’s proportionally more difficult. Just like it’s possible to design a webapp using a simple text editor instead of a full-blown IDE. You can hire your own QA to do it in house, or order some external QA to do it for you. Second myth: publishers can guarantee your game passes certification - false. Nobody can guarantee this. We’re dealing with software here, and no software as complex as a video game is bug free. Also, no amount of QA can guarantee this either. And the last myth, which I believe you have already understood it’s false, is that proper QA is easy. Nothing could be further than the truth. You probably noticed I keep using the words “proper QA” – that’s because there is such a thing as QA done poorly. No matter the path you’re choosing for your team, someone will have to work very hard to ensure your game is a quality game. Plan ahead, plan and replan as many times as needed, and support your testers. Eventually, you’ll make it.
- #32 And just if you’re curious, here’s how publishers deal with QA: some do it all in house, they have huge test departments with highly skilled and specialized teams others rely on external QA, or a mix of internal and external QA but what is a given is that all publishers will set quality standards for the milestones you agree with them If you choose not to work with a publisher, that’s a completely valid choice. Not only you retain full control over your game, but you get a bigger sense of accomplishment when you eventually release your game and it’s a hit. Yet, you will make a grave mistake if you ignore QA or do not give it the proper place it deserves in your planning and vision.
- #33 So I’ve bored you enough, time to draw some final conclusions.
- #34 QA is crucial for the success of your game. Remember the discussion about grade vs quality. QA efforts funnel directly into the game’s quality. Proper QA is tricky to do, but it also requires lots of planning. Then, things need to be monitored and controlled during execution. Replan as needed. And finally, you can do it on your own, but only if you know what you’re doing. Sometimes, it makes sense to delegate QA to experts.
- #35 We have reached the end of this talk. Thank you for attending. I hope it was enjoyable for you and that you learned something new today. A Q & A session will now follow, but you can always reach me on LinkedIn or drop me an email if you want. I will be happy to answer your questions now.