On 10/8/2025 at 4:21 PM, LRBS said:

Many places suffer from this lack of quality control at ASOBO. 

Quality control on the entire of planet earth? thats not possible.

58 minutes ago, SayAgain said:

El control de calidad y las pruebas de regresión son costosos... lanzar la versión beta a usuarios es una buena opción si se tienen los recursos necesarios. Sin embargo, los usuarios beta (nosotros/nos/usted) no somos la mejor fuente para procedimientos de replicación de errores ni para reducir el problema a una operación muy específica que un ingeniero de software pueda replicar. No lo digo con maldad, pero los usuarios finales son pésimos testers beta... Es decir, no es su trabajo. Los equipos de control de calidad dedicados serán mucho más eficientes y eficaces en la detección, validación y replicación de errores. 

Desafortunadamente, obtener los recursos para grandes equipos de control de calidad es difícil; a menudo es el aspecto que se recorta en los proyectos de desarrollo (he estado pidiendo un equipo de control de calidad dedicado a los proyectos en los que trabajo, pero la financiación es insuficiente, incluso para una empresa de 26 000 empleados). No digo que este sea el caso de MS/Asobo, ya que los errores que he encontrado en MSFS 2024 hasta ahora han sido bastante menores (excepto el guardado de la configuración del controlador en la versión anterior y el nivel de detalle/eliminación de objetos que deberían permanecer visibles). Hay algunos diseños de interfaz de usuario que se implementaron para beneficiar a los usuarios de consola y no son tan fluidos como podrían ser para los usuarios de escritorio, pero funciona.  

Como se señaló, teniendo en cuenta la complejidad de este software, está funcionando bastante bien y me atrevería a decir que MS/Asobo tiene un equipo de control de calidad en su lugar.

It's not a question of the cost of quality equipment, it's a question of who presses the launch button, and it's clear that here the button is pressed by someone who is really only interested in money. 

Money is always important, but lately it seems that professional ethics towards customers have been completely lost in the industry. 

 

40 minutes ago, Aglos77 said:

It's not a question of the cost of quality equipment

Not sure I understand you, there is no "equipment" involved?  QA are human resources when it comes to testing software.  There is unit testing automation but that probably doesn't apply here with MSFS.

42 minutes ago, Aglos77 said:

but lately it seems that professional ethics towards customers have been completely lost in the industry

I don't believe it's "ethics".  It's mostly driven by what customers are willing to pay and the desire to sell NOW so as to beat the competition to the buying market.  I get where you are coming from, but are you willing to pay 3X more for software to reach a higher level of fewer bugs AND wait 2X longer for availability?  If you are willing to pay more and wait longer, the majority customers are not ... they want it now (or yesterday) for less $$$.  The driving factor for QA is really you, the paying customer ... the majority "accept" a certainly level of issues, there is a threshold, but MSFS 2024 isn't at that threshold.

It's not the number of bugs I'm referring too when I say poor quality control, it's the blatantly obvious ones that have been "missed" by the internal testing and regression team....if they even have one.

I think it's pretty clear and has been since the very first beta; the public are the regression testing team, which is not the way it should be especially from a company the size of MS.

15 minutes ago, MarcG said:

it's the blatantly obvious ones that have been "missed" by the internal testing and regression team....if they even have one.

How would you know that QC "missed" them vs. that they are still there for one of the other reasons I mentioned?

And - if they would have no QC, who would have raised 50k issues prior release? Do you have the slightest idea about the effort to raise and manage 50k issues?

7 minutes ago, fsiscool said:

How would you know that QC "missed" them vs. that they are still there for one of the other reasons I mentioned?

And - if they would have no QC, who would have raised 50k issues prior release? Do you have the slightest idea about the effort to raise and manage 50k issues?

 So why then is it that they allow these game breaking bugs to manifest and release with public builds? Then we have to wait weeks/months/if ever for a fix?

28 minutes ago, MarcG said:

So why then is it that they allow these game breaking bugs to manifest and release with public builds? Then we have to wait weeks/months/if ever for a fix?

I have provided a list of scenarios which result in fixes not making it into the release or being deferred. There are significant efforts going on to flag issues with a priority. Whether an issue is blatant obvious is only one criteria among a list of many others (like risk, effort, potential ripple down effects, compatibility considerations, ...). And the priority list is then worked down. Some will make the final cut, some not.

7 minutes ago, fsiscool said:

I have provided a list of scenarios which result in fixes not making it into the release or being deferred. There are significant efforts going on to flag issues with a priority. Whether an issue is blatant obvious is only one criteria among a list of many others (like risk, effort, potential ripple down effects, compatibility considerations, ...). And the priority list is then worked down. Some will make the final cut, some not.

Ok well let's agree to disagree on the level of quality control at Asobo/MS with relation to this series, you think it's fine, I don't 🙂

And the spread of misinformation continues....

1 hour ago, fsiscool said:

How would you know that QC "missed" them vs. that they are still there for one of the other reasons I mentioned?

And - if they would have no QC, who would have raised 50k issues prior release? Do you have the slightest idea about the effort to raise and manage 50k issues?

first of all, please stop making up numbers, @SeedyL chimed in to tell you that your 30K number was wrong and now you almost doubled it to 50,000

second of all I would wager a guess that like most software development the VAST majority of the bugs that are "known" bugs come from the development team themselves and are logged for future development as they go.  You don't necessarily fix something in real time as you go so there is a very high probability the largest number of known bugs especially those already logged are coming from development for tracking.   Hence the reason we question some innate fix that makes no sense but it does from a development timeline and potential overall chance of adverse impact...  

But don't let me de-rail the conversation, by page 8 it will be 100,000 bugs! 

 

2 hours ago, MarcG said:

Ok well let's agree to disagree on the level of quality control at Asobo/MS with relation to this series, you think it's fine, I don't 🙂

You can only judge how good MSFS runs on your desk. But you impossibly can know which team inside Asobo/MS you should blame for that. That's all I try to explain. If "QC" for you is just a diffuse synonym for the organization that causes the bugs on your desk, then I am 100% fine with you! Real QC is just something else then.

1 hour ago, psolk said:

But don't let me de-rail the conversation, by page 8 it will be 100,000 bugs! 

You should not make jokes if you didn't read what SeedyL said. I simply took the 50k (in total) from his post. You understand the difference between issues in total and open issues at release? The total number includes closed ones (but raised and managed by QC nevertheless, which is why they are highly relevant for the discussed topic).

 

Edited October 17, 2025Oct 17 by fsiscool

26 minutes ago, fsiscool said:

You should not make jokes if you didn't read what SeedyL said. I simply took the 50k (in total) from his post.

Which was very convenient for you but if you REALLY read it said 

  

22 hours ago, SeedyL said:

some were determined to be duplicates (i.e. multiple entries for the same bug or multiple issues that share a common root cause) and others were investigated and determined to not actually be valid bugs. The internet being what it is, people then started repeating that MSFS 2024 shipped with 30,000 known bugs, which isn't what Jorg said at all.

Which means those Duplicates, issues sharing root causes and those that were not valid bugs also comes out of the number of total issues as well not just those shipped at release... 

So there were never "really" 50,000 issues to begin with but now you are tossing that number around as your reference without referencing it accurately... 

30 minutes ago, fsiscool said:

You understand the difference between issues in total and open issues at release?

I understand that as well as the importance of reading to comprehend not just to use the information that's convenient for me to make my case.

Details Details... 

Can we take a moment to consider a figure like 30,000 bugs? How do you even begin to tackle a mountain like that? 

11 hours ago, psolk said:

 

Which means those Duplicates, issues sharing root causes and those that were not valid bugs also comes out of the number of total issues as well not just those shipped at release... 

So there were never "really" 50,000 issues to begin with but now you are tossing that number around as your reference without referencing it accurately... 

From QA perspective, there were 50k. Because duplicates and all these other categories need to be managed by them too. Which is why it is relevant here. You missed the relevant part of Seedy's post:

On 10/17/2025 at 12:51 AM, SeedyL said:

the QA team logged about 50,000 issues during the course of MSFS 2024's development

That sentence in very simple terms tells the story of a capable and efficient QA organization.

 

 

Edited October 18, 2025Oct 18 by fsiscool

10 hours ago, fsiscool said:

From QA perspective, there were 50k. Because duplicates and all these other categories need to be managed by them too. Which is why it is relevant here. You missed the relevant part of Seedy's post:

That sentence in very simple terms tells the story of a capable and efficient QA organization.

 

 

Coming in with so much sound logic and good sense is against the TOS of this thread!