“Why don’t you use, it will solve all your problems!” The Job of QA is to test and test appropriately balancing the time for technical feedback and gameplay balance based on the development timeline of the game.Īnd before we get too far, the comment that I expect to get the most to this diary: Why is that? Well because in that scenario the bottleneck of quality would not be the QA but the developers on the other side of the bug fixes - it's their bandwidth that would then be the limiting factor. An infinite number of QA with an infinite budget and time could still not deliver a near perfect quality product. Paradox games are unique in their complexity of interlocking mechanics and systems that to test the full functionality of the game and all of its iterations for every change is impossible. Not everything can get tested, it's a sad fact. Even when things go perfectly, QA is still a race against time or more specifically a race of timeboxing: what is the most important thing to test now and what can be put aside to when there is either time or it is more complete - do we suspect another Market Rework is coming or are we at the final implementation at last? Broken builds, delays, reworks, and merge errors - these are an everyday occurrence in our profession. As we are at the end of the pipeline we must be the most adaptable members of the team. Though this is honestly a great introduction to what it's like to QA Victoria 3, or how it is to be a QA in general. We will eventually have an Audio Dev Diary (looks hopefully at Community) but for now you’ve all locked in here with me again about a subject I know all too well: how it is to QA Victoria 3. We’re not talking about Audio this week, we’re talking about Quality Assurance, otherwise just known as QA! Excuse the dust as we teardown and set up this new development diary a little earlier than planned.
0 Comments
Leave a Reply. |