Forum Discussion
@Trokey66 wrote:
@AOD_moose004I read an example of how hard it can be to QA software and the example was....
There is a bug with the '9' on a phone where it will not work.
However, it only manifests itself if the two previous presses are '0' and '1'.
As you would appreciate, you can't test every combination of button presses so missing this bug is not impossible.
Unless some one presses '019', the bug may never manifest itself and on the rare occasion that it may occur, if it isn't indeed to the previous button presses, identifying the actual issue could be very difficult if not impossible.
button press combination bugs can easily be checked via automation so that isn't the best example
*edit* in my opinion the best way to do a final QA check is to actually have a sufficiently long beta with the launch build and actually analyze results and pay attention to feedback and do it close enough to launch to use the expected launch build but early enough to actually give yourself time to fix it and if you don't have time, push back the launch *as nintendo is famous for doing* until it's done
@Psubond wrote:
@Trokey66 wrote:
@AOD_moose004I read an example of how hard it can be to QA software and the example was....
There is a bug with the '9' on a phone where it will not work.
However, it only manifests itself if the two previous presses are '0' and '1'.
As you would appreciate, you can't test every combination of button presses so missing this bug is not impossible.
Unless some one presses '019', the bug may never manifest itself and on the rare occasion that it may occur, if it isn't indeed to the previous button presses, identifying the actual issue could be very difficult if not impossible.button press combination bugs can easily be checked via automation so that isn't the best example
Actually it is a good example, because it is not just checking the combination, but also then searching why that combination breaks it (it could lead to another issue), getting to the exact line of code, fixing it, then verifying that it fixed it and not break anything else (which is very common in programming).
Either way, EA's response was a justified one. People have been critical that the company was off during the holidays and not working, this is at the same time when many of them have been off of work or school. The community of "vocal" battlefield players seem to enjoy finding every negative issue with the game or the company's responses. Many act like they are entitled to dictate how a game should be developed and if it is not to their exact demands it is a garbage game.
Was the launch good? No, but at the same time it wasn't as bad as some previous titles like BF3 and BF4, which by the way people use as "positive examples" of what a good Battlefield game is. Is the game good? Well this is totally subjective, in all the game is playable and to many enjoyable. Heck I will argue that for some of the people who trash the game, they have put in 100s of hours; if it was so bad why put in that time and spend countless hours continuing to trash the game on here? Instead people want to say the game is broken, not because the game doesn't work, but because it doesn't have the features they want. Personally I think it only allows you to judge if the game is enjoyable, not if it is broken or not. Which brings us full circle to DICE's response, because the "vocal community" has lashed out on DICE with irrational expectations along with bashing them for making changes in the game that are well within their right.
- Psubond4 years agoLegend@VBALL_MVP finding and fixing are two different things. button combo checks can be automated and if one doesn't pass testing it is logged and then a human investigates the failures
i don't care if they're off. i care that they couldn't be bothered to communicate. if you're in charge the big paycheck comes with some responsibilities such as taking a few min to communicate with the customers- 4 years ago
@Psubond wrote:
@VBALL_MVPfinding and fixing are two different things. button combo checks can be automated and if one doesn't pass testing it is logged and then a human investigates the failures
i don't care if they're off. i care that they couldn't be bothered to communicate. if you're in charge the big paycheck comes with some responsibilities such as taking a few min to communicate with the customersAnd automating it takes time to create a algorithm to do that portion, and just like the code you are testing needs to be checked. To automate something to check something one time, doesn't make much sense to put additional costs to do that. Also it assumes again that is the only issue.
The fact you don't care they are off is exactly why DICE has called the community "brutal". I mean I don't want to be bothered when I am off. So basically what you are saying, is "do what I want and expect, but I am exempt from all the same expectations".
- Kyosji4 years agoSeasoned Ace
Even after he deleted the tweet, his replacement tweet still sounded like we were the ones at fault for not understanding his message... :/