Hacker News Reader

Comment by MetaWhirledPeas | Hacker News Reader

I know this wasn't really your topic, but you've stumbled upon a pet peeve of mine: Dedicated testers aren't primarily to blame for bugs, nor are they primarily to be credited for bug-free software. For one, everybody should test, not just dedicated testers. And two, buggy-ness is primarily a function of design and implementation. Testers can improve the product, but if the product is fundamentally buggy there's no amount of after-the-fact testing that will fix that.

View on HN

(disclaimer, ive worked on fortnite as an engineer) 100% this. There would much to say as to why this is the case on fortnite but Ill just say this: fortnite is so big that the development methodology and patterns used shows their limits. One of them being that the game design team decide the features and the engineers code. Instead the two deps should be collaborating to ellaborate solution that are both simple in terms of engineering and relevant for the customers. The best example of that is world of warcraft. Wow is extremely efficient in terms of engineering and yet super fun. What Im saying is that sometimes the engineering dep should prevent a feature from being coded, at least the way the designers see it. Or you end up with a pile of crappy code. I would even go further: the engineers should say first what is possible and whats not. Think ID software: Carmack decides whats running and then the designer try to make a game with that. Add collaboration to this core idea and you get WoW (disclaimer I have not worked on WoW but ID software touch is definitely there impersonated by John Cash).

On the flip side, some of the new ID games are nowhere _near_ as popular as the ones from Epic games, and WOW wound up dying by its own hand, to some extent.

The more time I spend working on startups and less at BigCos, the more I value the non-technical train of thought - unburdened by the implementation details. Sometimes those people are needed to push the envelope. Clearly, Fortnite is doing something right. At any rate, it's not a coincidence that most great companies have someone at the head that _mostly_ knows what's entailed by the dreams, but proceeds to dream nonetheless.

Yeah, ultimately how good the code is (or even how buggy the resulting product) is just a side-effect and not the main goal. Fortnite is making so much money that having to spend 2x as much on engineering because the code is a mess is business wise just not that big of a deal.

Somewhat (obviously to within reason) decoupling design decision from what would be easy/convenient for the developers to implement is often the right thing to do from a business point of view.

Is WoW dead? I know people who picked it back up after 10 years again

Agreed. Maybe one can do even better next time though.

I mostly agree with this, though I will say that in games it's usually producers and product managers that decide on the bug fix vs new features balance. It's not uncommon to ship a game with hundreds of "known shippable" bugs.

Yeah, you're right. But you'll notice there are some studios that never seem to achieve a bug-free state no matter how many patches they put out. And that's after months or years of free testing from the public. Testers fill up backlogs with bugs the same way the public fills up the Issues lists in GitHub. It doesn't matter how well you test and report if you don't have good enough development practices to fix them and keep them fixed.

I don't think you can generally claim that testers aren't to blame for bugs, nor that should they be credited for bug-free software.

Obviously dedicated testers can't fix bugs themselves, so cannot be to solely to blame for bugs. Similarly, it's possible to write bug-free software without a dedicated tester, so testers can't receive full credit for bug-free software.

However, a testers job is not to play a game haphazardly. Rather, the job of a tester is to develop a methodical way testing software that is under rapid development. This can mean creating test plans, understanding the most important user flows, understanding common failure scenarios, and even light automation. Games are hugely complex pieces of software. This large breadth means that the test workload is too big for the engineering team. Also, the systems underpinning a game are usually very tightly coupled, meaning that changes in one system can break things in a completely unrelated system. Having good testers is an integral part of delivering a bug-free experience in this type environment.

Reply on news.ycombinator.com