You might have been in software dev for 30 years in various roles (as have I, and still am), but it’s apparent from your ludicrous defence posts you still don’t understand the massive QA fail that happened.
Personally I’ve enjoyed it up to now as well, and can work around the issue in various ways.
That doesn’t excuse the massive dropping of the QA & testing ball in any way, shape, or form.
I’ve pretty much given them a pass on everything so far, even the terrain spikes and crashes, but this was totally avoidable, and because it’s core product functionality (aka the flight model), inexcusable.
This is not about “complaining”. It’s about process, or failure to follow basic QA process resulting in a -ve impact to core product functionality.
It’s a flight simulator, ergo you run a standard test suite (auto, manual, or combined) before you do a major release. You don’t decide to not test core product functionality because “it wasn’t on the official build list”. That, like your lame defence of it, is ludicrous. I will give them one point for admitting it though.
The only thing worse than this would have been an admission they did notice it and released it anyway instead of pulling the release because it was already late and there will be another release in a few weeks so, meh, let them deal with it. That would show a total disrespect for customers (not that failing to test doesn’t, but this would be another level of disrespect). You’d probably find a way to defend that too though I suspect.
There is no excuse for letting obvious bugs slip into production with core product functionality at this stage of the product’s life cycle. Bad PM, Bad QA. Test.Your.■■■■. Basic SW 101.
I agree with you completely about the QA-process. And I am sure that I am not the only simmer that works in the IT-business.
This was a nasty slip in their production factory. Of course nothing should be merged to a master branch until the complete test suite gives a green light. Someone at Asobo made an honest (human) error here. And under time-pressure the process (and many times QA) always suffers. And afterwards we slap our faces knowing very well where we went wrong and we promise to do better. And the next time: stakeholders again. It’s a constant struggle for the right balance. I am sure that you will know this from your own experience as well. This should not have happened and I am sure that they learned from this. But I am also sure that they will sometime in the future slip again. My hope is that they will have the necessary resources available by then to create the necessary hot fixes.
Don’t stoop to the level of this poster. Those of us with large-scale software development experience recognize valid observations and theories. Those that don’t are not going to be impressed by a list of roles they know nothing about.
ahhh This explains this. was flying the TBM today, First time in the SIM in 4 months. on the first flight i noticed i took off Very Very Early the plane took off, the rudders felt a little different. Then when i started the approach things got weird. soon as i put Flaps Full For landing, I Went Nose UP , No matter how hard i Pushed down. raised the flaps and could control it. but also landing once i managed to was very very difficult. I first thought to myself maybe this was some Kinda In Game failure. Because in the flight i flew through a storm, thought maybe something broke. But then tried again with just clear weather. Same thing. then ive tried the airbus and same thing. so yea whatever the update did. it ■■■■■■ something up
It’s not like it was their first mishap that has shown bad QA.
We had long discussions after that kind of thing happened with every bi-weekly update in last autumn which made them extend the time between updates.
I don’t blame the developer or the architect or some specific role. It seems like an organizational issue, all piling up to this kind of thing happening.
It is also an organizational topic about how quickly you can react on bugs. If you have a quick pipeline on rolling out a hotfix, releasing bugs isn’t as big of a deal. But if it takes you 2 or more weeks to roll out a hotfix (because of testing or other constraints) you better invest in QA to not roll out bugs in first place.
Working in the industry (aviation IT) myself for many years now, on complex non-critical systems I rather have a quick release cycle and risk a bug that I can fix in the matter of an hour since I know I can’t test everything beforehand.
Being prepared for hotfixes and practicing it is vital.
Generally speaking I don’t think a short release cycle is bad. We are delivering software in an agile model. The principle there is to deliver production ready software every sprint. That of course only works if you have a test driven development wherby testing is automated and test coverage is big. The modern software development world is moving to cotinous delivery of artefacts. Having said that, maybe this is not possible in the SIM Software world.
Yeah, and that’s a BIG reason for a beta programme where people can opt in to test out new releases before they get pushed to the public.
There’s so many people out there, willing to provide feedback and look out for bugs and everyone would benefit.
Asobo said they are working on it, hopefully we’ll get it sooner than later.
As for agile development and continuous delivery: Same here, including options to do canary releases and feature flags to allow verifying new features on selected groups of flights or users.
Organization and preparedness is key, not only in aviation. If you once have the tools established, you’ll never want to miss them.
After a rather long time away from MSFS, I finally got my hands around flying a variety of aircraft for some touch-and-goes. And holy moly. These airplanes … float. The A320 rotates at 50kts and lands flat at 110kts.
Agree. It has to do with organisation and mindset. Scrum methodology is very stringent in that regards. No hiding possible. Good developers are required and are empowered. If you have a proper definition of done for each story including the tests, you are already there from a QA perspective. However, still a lot organisations work with ancient models.
As a result of this thread, we are adressing a Hotfix today to solve the issue introduced at the last update.
Thank you once again for letting us know!
If you followed our workaround, make sure to read this post:
