Improve QA and code segregation

The latest update to Space Engineers had several bugs in it that almost made me snap my keyboard in half, and even now, when I think about them, it is very hard for me not to get sarcastic and hurtful. As a professional software developer, I understand that coding is hard and sometimes you get bugs that really jerk you around and seem to exist "because reasons", but there's just no excuse for the kind of things I am seeing here.

You need to begin segregating code - that is, when you are trying to add a feature or fix a bug, you create a branch in source control. Once you think you have the fix, you test that branched code. You integrate it back into the code you release to the public if and only if it passes all the tests.

If you are already testing your code before releasing it, you need to step up these test. I used to be a tester, so here are some pointers:

1) Basic positive testing - does this code do the thing it was meant to do?

2) Basic negative testing - does this code avoid doing things it was NOT meant to do? (e.g. does a password field reject bad passwords)

3) Performance testing - how does this code perform under load? Does it negatively impact performance?

4) And this one is key - REGRESSION TESTING - DOES THIS CODE REACTIVATE OLD BUGS? DOES IT BREAK EXISTING FEATURES? DOES IT EXACERBATE EXISTING BUGS?

If you say "But, BC, we're already doing these things", then I say "Do. Them. Better."

There's a bug now that if a container's inventory list is long enough to require a scrollbar, you can't select anything that you would have to scroll down to see - when you click, you get the item above it in the last row that was visible without scrolling.

There's a bug now that if you try to transfer items from a container in the right-hand inventory list to a container in the left-hand inventory list by any means other than click-and-drag, the items actually go to whatever container was topmost in the left-hand list when you opened the inventory.

Both of these should have been caught with basic play-testing and the code should have been rolled back to a working version INSTANTLY. That obviously didn't happen, because here we are. You don't have to throw that code away; just. Don't. Inflict it. On. The Players.

There's also a bug that makes the Previous/Next Color/Material/Camera keys operate even when you are trying to use them to type text in the terminal - this could and should have been caught before release when someone from QA opened the terminal, selected a text field, and tried to use the keys that those functions were bound to. That's mid-level QA stuff, but c'mon - you guys are better than mid-level, right?

Finally, the new release makes an existing bug so much worse, and the symptoms are so specific (you are prevented from accessing the terminal of a grid only if you are also remote-controlling it) that I find it hard to believe someone wasn't trying to fix the bug, only to end up making it worse. If that's not the case, I apologize, but if it is, why did it escape into the wild?

As I said, I'm a developer, and I used to be tester, and having worked both of those roles for many years, seeing basic mistakes like this makes my blood boil over. Ironically, developing a game is not itself a game - people love this game and they pour their hopes and dreams and time and energy into it, and you cannot continue to play fast-and-loose with quality control like this; it alienates and hurts players and it diminishes your own reputation. A lot of friends of mine have given up on the game entirely, and when I see things like this, I get why they did it.

One simple fix: create a world. Lay out a path in this world starting from a spawn point. Along this path, set out every type of block in large and small size, along with several different super-basic game-play scenarios (e.g. remote-control a grid, rename an antenna, transfer inventory items). Before you integrate a branch of code into the release you will publish, load up the world, walk the path, and try the little scenarios. If anything breaks, this code branch is not ready for prime-time; keep it in-house until the problem has been solved.

This is big-brain time, guys; you need to step it up and treat your code, and by extension your players, like the professional company you are.