BHVR would benefit massively from engaging in/increasing their usage of automated testing practices

nivomi

This post starts out talking about a specific issue, but it's really more broad engineering-practices level advice, from someone with some OBHR and QA Engineer experience.

The last three patches have had an inaccessible totem spot:

• 5.7.0: On the reworked Haddonfield, a totem could spawn in a room which could be closed by mapgen and inaccessible to both survivors and killers.
• 5.7.1: On Midwich, a totem could spawn at the top of a staircase in a position inaccessible to killers. This space could also be entered by survivors, giving them a 'safe spot'.
• 5.7.2: On Midwich, in the above location which is now blocked off, a totem can spawn which is inaccessible to survivors and killers.

Overall, these types of issues have proven to be a recurring problem. Inaccessible totems, areas which can be accessed by survivors but not killers, areas where generator grab hitboxes don't work, or where picking up downed survivors is impossible... Dead by Daylight has, unfortunately, struggled with a number of issues which seem to just keep reappearing.

In my career of systems development, I've run into a lot of situations where a problem has occurred multiple times. This is all but universally a signal that you need to be testing for this problem proactively.

Of course, even if you build some kind of "test mode" which spawns every totem and highlights them for the QA team to try to path to, having a QA team load into every permutation of every randomized map with both survivors and killers and check every totem on every single patch just isn't feasible.

Enter the beautiful world of test automation. How did the small team behind The Witness ensure the whole game world was free of areas where you could get stuck, or areas where you should have been able to walk but couldn't, or areas where you shouldn't have been able to walk but could?

They automated it: https://caseymuratori.com/blog_0005

Now, of course, this is non-trivial - you have build the tests, and that takes serious work! This is why there's "QA Engineers" in addition to "QA Testers" - and you might even have to hire someone, or multiple someones, to fill this role. I know, that's a tough ask, but think about the benefits:

• Less playerbase frustration with repeated errors of a similar nature.
• Less time spent building, testing and deploying follow-up patches.
• QA testers can spend more of their time testing the stuff that can't be automated, which increases job satisfaction and overall productivity.
• If tests are deployed in a continuous integration environment, individual teams (map teams, asset teams, game-component programming teams) will have a method for reliably determining whether their changes break something - and they can fix it rapidly as well, rather than having to wait for QA - or the playerbase - to let them know there's a problem.
  • This enables more rapid iteration, while also giving teams the ability to experiment without having to fear breaking something which makes it into the live build.
  • Additionally, not having to worry about maybe breaking something reduces task interdependence and increases E-to-P expectancy (the belief that one's effort will result in performance). Having automatic, relatively fast and judgement-free machine feedback is a huge boon to employee morale. When someone doesn't know whether they're doing something wrong, they're going to be less happy than if they know they'll be told something is wrong and given the opportunity to correct it.

Hopefully this lays out the benefits in a way that at least makes the team consider whether automated testing approaches could be a benefit not just to Dead by Daylight itself, but also to BHVR as a business and group of employees.

If you have any questions or, well, anything, I'd be happy to provide as much of a response as I'm able.