June 6th, 2013, 18:39
If I may chime in, it sets a bad precedent that having to release a patch immediately (in this case within hours of the release for a rather glaring compass issue) is now normal.
Echoing Firekitten's sentiment "Information for reviews, forum topics, should be able to contain both positive and negative remarks, made in a civil manner for users to make their own informed decisions", the ability to communicate constructive criticism and highlight sometimes glaring faults is both completely appropriate and necessary. We likely all have definitions on what constitutes a "glaring" or "obvious" issue, and this is where some of the contention may be found. To me, the wet compass, in plain view front and center as a featureless object is a glaring issue. It was apparently recognized as such by Alabeo due to the speed of the update. I would define the reversed function of the prop rpm control the same way. Basically, for a plane of this level, the core systems, especially critical components, should be 100% on release if the beta-testing team is effective.
On that note, I would consider lesser issues, that can be fixed with a patch, to be things like minor FDE changes or minor fuel usage traits that may not line up with the real numbers, if we must subscribe to the theory that numerous followup patches soon after release is normal.
In short, I believe that there are some bugs that should be caught by a competent beta-testing team prior to release, regardless of the aircraft.
Effective testers should have an engineering mindset when they approach a product such as this. Either be familiar with the real aircraft or be familiar with something very similar. If not possible, find additional assistance from someone who is familiar with it or a similar aircraft. Have a good understanding of VFR and IFR principles and a general knowledge of the technical side of aviation.
Additionally, a competent development team, and testing team, should develop use cases, test plans, and test procedures using a testing checklist while analyzing the model. Document the functionality or concept, as well as the expected and actual result. These plans and procedures could be for the same functionality over differing environmental or system conditions for example.