Jump to content

Can Our Next Patch Be An Actual "patch"? Please?


61 replies to this topic

#61 Noobzorz

    Member

  • PipPipPipPipPipPipPip
  • 929 posts
  • LocationToronto, ON

Posted 18 April 2013 - 06:33 AM

It would certainly help them reclaim the "if this is a beta why _____?" criticism.

#62 LiminalSpace

    Member

  • PipPip
  • 37 posts

Posted 18 April 2013 - 07:40 AM

View PostDivine Madcat, on 17 April 2013 - 07:29 PM, said:


Well, for what its worth, yes, when i complete a feature (not just one piece of code, but a full feature or bug fix), yes, we do run the test suite. I am sorry, but it is just good coding practice. There is no excuse to add new features and not make sure you haven't broken something. Furthermore, if you code base is logically done, testing the impact of your code should not be overly difficult (if your code works with say, the audio engine, logically you wouldn't need to run tests (as the developer) on the control systems per se).

Our test suites take hours to run, and we typically run them overnight, every night. And again, two points:
1) Until very recently, they didn't have any automated testing. They are adding it, so we'll see how things go in the future.
2) Many of the hardest bugs (the ones that are not easy to duplicate) are not ever caught by the test suite, because they only happen under very particular circumstances.

Quote

I will say, my industry (defense) is probably more picky than others; but i am still going back to my fundamentals taught to me in school. Good practices should be followed no matter what type of programming. And more so, when presenting product to your customer (again, if they are selling us mechs and other items, they are presenting a product, not just a beta), your product should have been thoroughly tested by QA (whom for this game, i cannot defend at all. Glaring, obvious bugs have made it to us, that never should have). These failures are more than just on the coders.. but sadly, it is all up to the coders to fix...

In my experience, the school fundamentals (good encapsulation, refactoring existing code to get the best architecture to suit the requirements, etc.) tend to go out the window quickly when business realities hit, unless you are in a situation where that stuff is critical, and the consequences for not doing so are large (such as contractual penalties, people's lives at stake, and so forth). That's not to say it's not done, just that it's secondary to shipping product.

Which glaring, obvious bugs shouldn't have made it out of QA? The chat backspace issue, sure, except that shipping whatever feature caused the bug may have been deemed more important than the bug. Maybe they have already slotted that in to fix during UI 2.0, or it may already be fixed with some other feature that is not ready for release yet. It's a beta, and there is a reason they are calling it such: they are releasing things to get them tested even though they may not be fully built out. Hence, phases of many of the features (HSR progressively, matchmaker progressively, etc.).





2 user(s) are reading this topic

0 members, 2 guests, 0 anonymous users