Branching Out! - An Insight into QA with Early Access Games

We've been rethinking our testing process for Kerbal Space Program and we wanted to share these changes. So we've written a nice, chunky blog about it.

Software developers might already understand KSP uses an incremental waterfall methodology - Incremental Development Model. This means, we go through planning, development and testing phases for each update, which also includes an internal Alpha and Beta to make sure our game is as playable as possible with each update. It's an important part of our process and helps us make sure our players can always enjoy KSP, whether it's digging into new content for existing players or a new player joining in for the first time.

Branch Testing allows us to take this model and apply it to each feature and treat each feature as though it is the update itself. There's two key elements to discuss. First is "Branch Testing," which is where we have the ability to test each feature individually before they're all combined into a full-featured build. The second is our extra QA phase, which is going to take place before we integrate all new features into the build. Branch Testing is the largest and most important improvement and changes a fundamental part of our process. In the past, we'd implement all features onto a central build. This was a good method of testing but isolating each feature allows us to know exact changes and how certain issues are related to the changes. Testing becomes much more controlled, which is always a valuable addition to the process.

The image below is a simplified overview of our prior testing process.

Prior Testing Process

Branch QA Testing

Now, as soon as a new feature is ready for QA, we begin testing it. We grow familiar with the feature and have most major issues dealt with by the time the QA phase arrives and the new feature is integrated into the central QA branch. Additionally, we can test one new feature while our developers work on something else. We expect this to help streamline our process, particularly in testing. Now we can test as soon as a feature is ready and will have more knowledge and more control over what is changing between each build and branch.
This is still in the testing phases itself, so we're planning to continue with the normal QA and experimental phases. We don't want to rush this change in our process and hope to avoid any negative consequences so we remain as sure-footed as possible during all stages of development and testing.
Once we complete this change, it should be a major improvement to the testing process and its efficiency and organization, as well as development overall. Overall, I hope that this was an interesting insight into what we've been doing, specifically, to make everything run smoothly over here. I'll hopefully have more to write about in the future, especially more insights like this!
I leave you with the following video from 0.21 Update QA Testing:



Feel free to ask any questions that you have in the comments.