How do you approach test planning for a new game project?

In reality test teams rarely plan the testing scope of a project upfront because the details, features and possibly even platforms aren't defined yet. Projects start with resourcing, defining how big a test team you will need and how they will be organised. Those are the team members that will be defining and executing the test plans. Most often, companies already have a test resourcing strategy for the use of embedded, publisher and outsource test teams throughout the life of a project. If the project is a stable franchise IP, resources can be planned to release day with relative confidence, but many projects start life as prototypes which may only require a few embedded QA members until the project is greenlit for pre-production.

Transform game development by embedding testing into your team's DNA from the start. Shifted-left, fun-focused development testing culture, enabling QA to deeply understand the product and relieve developers. Imagine QA collaborating closely with design and product teams, enriching early design documents with their unique insights. In action game development, QA’s feedback on mechanics from the outset is crucial. Incorporate automated testing early for greater agility at the MVP stage. Start with one specialised tester, scaling with the team, and later expanding to more typical quality control engineers. This approach not only elevates game quality but revolutionises the development process.

Don't rely on generative “AI” software for your test planning, and don't reach out to online community for free advice and so called best practices. Hire professionals instead, whether it's to handle test planning or to write articles.

Test planning for a new game project begins with a deep understanding of the game's design, mechanics, and objectives. This comprehension forms the foundation for identifying testing objectives, which may include ensuring smooth gameplay, detecting bugs, and verifying compatibility across platforms. With clear objectives in mind, the next step involves defining the scope of testing, considering factors such as platforms, game modes, and specific features to be tested. Once the scope is established, a detailed test plan is developed, outlining methodologies, timelines, resources, and responsibilities.

The entire scope and objective of the tests are related to the gameplay of the game to be tested. We start with the analysis: What tests does this gameplay require? What quality assurance approaches do these tests need?

We don't just consider the test techniques we want to use, but also the test levels, activities, areas and types. Confusingly, these are all called {something} testing. Test Levels: Define the scope of testing, often run in parallel.(Component test, integration test, system test, etc) Test Areas: Defines the focus of all functional and non-functional test areas. Many areas targeted in each activity and layer.(Performance testing, multiplayer testing, FTUE testing, etc) Test Activities: Disposable tasks that run within test levels and use a blend of test types.(Build verification test, a regression test, a test plan) Test Types: Defines the approaches taken in each activity.(Verification, failure, exploratory, scripted and variations of)

Think early of features which might require massive amount of test resources needed and is there possibility to reduce that - either by automation, additional debug tools, test levels etc. Especially for series of well established IP, as additional features and complexity is added with each release, this allows to move testers attention to newer and possibly more risky areas. Even for smaller teams, it allows to early prevent issues which might affect production along the way. Not everything needs to be invented as there are many tools available on the market, especially for commercial game engines such as Unreal Engine or Unity which might assist teams - not only QA there.

A test plan can be created based on any existing documentation about the game, of course, with only the documentation, your test plan may contain unnecessary things or missing important cases. A test plan based on documentation or GDD can be a great start to not begin empty-handed, but surely it will be altered after being put into practice. This process involves extrapolating potential scenarios from the documentation, understanding the game mechanics thoroughly, and anticipating user interactions to ensure comprehensive test coverage. Despite the initial framework provided by the documentation, the test plan will inevitably undergo revisions and refinements as it is put into practice

Having early established delivery dates to test allows teams to create a plan with timeframes for testing features. As all plans, it will change depending on risks and issues on the project, but it will help prioritizing tests and managing those risks. Having a delivery date allows to track is the project on time or not, and allows to early flag a risk of impacting test scope. In my experience, it first will reduce scope of tests by cutting lower priority tests and focusing on verification of the feature functionality. However, as issues rose it might even impact test team ability to re-test issues fixed by engineers, which might affect released product quality - keeping test schedule up to date and revisiting it often allows alleviate risk

After putting your test plan into action, you will have to add some changes. Approaching a final form, test plan can be sent to a designer or producer for a feedback session. It's always very important to incorporate any feedback into the test plan to ensure that it remains aligned with any requirements and objectives of the game. It's also important if possible to ask people not involved in the project to run the test plan, ensuring that your test plan has a easy as smooth approach

In the gaming industry, the synergy between Quality Assurance (QA) and development is often overlooked. A strong collaboration is essential, fostering communication for high-quality project delivery. QA and developers work in tandem, with QA not only identifying errors but also providing precise correction guidance. This efficient feedback cycle leads to continuous software improvement and robust end products, highlighting the interconnectedness of QA and development.

When I plan tests for a new game project, I keep it simple. First, I set clear goals and figure out what needs testing. Then, I make a plan with steps for testing everything thoroughly. I also talk with others involved to make sure we're all on the same page. It's all about being organized and communicating well!

Sempre que possível submeta seu plano de testes para análise do Producer, Designer ou Programador. Ter outras pessoas olhando seu plano de testes pode trazer diversos benefícios.

Always consider Exploratory Testing. Even though it cannot be fully scripted, it provides a broad scenario for finding unexpected bugs.