I must say that Beta Testing can become a dangerous option for Add-on developers! Why? Because it’s a two-sided resource. Pick the team well and you’ll get fine release candidates, pick them wrong and you’ll get hundreds of patches for product correction instead of updates for the product’s features. I’ll give an example:
I beta tested several products in the past. I’m not saying the products I tested were any better than the others, but the assembled team tended to gather hardcore users and thorough explorers. We ended up, most of the times, with fine products which needed few updates, in many cases just small corrections, sometimes not even noticeable at first glance (for example the aeroSOFT Coast Guard, which, let me tell you, came up with some weird problems prior to launch, but we all decided to make the Release Version top notch. Did aeroSOFT pick their Beta testers carefully? Yes they did!).
On the other hand I’ve seen products being released with absurd (sometimes rude) errors. For example a recent released and expensive product from a known developer came up with a ridiculous error: When shutdown every power source, including batteries, you still get some lights on and warning sounds. My question came up immediately: Didn’t their Beta Team see this? Come on this is perhaps the first or second thing we check: Electrics and power supply!
But then another question came up: Did they have a Beta Team at all? If so, how experienced are they? Many developers have different criteria when picking the beta teams. But most of the times, picking someone with flight experience or specific aircraft knowledge, doesn’t exactly fit the needs. I know several cases of guys who teamed up with beta testing teams who knew nothing about the aircraft type, but where acknowledged for their criteria analysis and thorough critics.
I, for instance, tend to look out for a handful of reviewers of products who I know are methodical and honest in their evaluations. Once again, that doesn’t mean they are former pilots or flight engineers. So why does Beta Teams tend to be a bunch of friends of friends? We are a band of brothers for sure, but a team shouldn’t get picked randomly or with poor criteria with the danger of having a buggy final product with rude errors like the example I described above. Pick your knights carefully for the round table!
Joao P
Joao P is one of our favorite customers (you can find his own blog at helifreak.blogspot.com)
I addition to this point of view I present what I believe to be the best possible Beta Team:
), most of the times they aren’t familiar with technical terms like “Texture Bandwidth” or “FSUIPC”.
- Real life pilots. Not important if they are type rated for the aircraft type or if they operated to that specific airport. A lot of expertise comes from experienced pilots. Caution: Tend to be absent or get aggravated with “Aces” who think they are pilots…
- Developers and programmers. No one enjoys more the product than these fellows. However, most of the times they are absent from the Beta team, and it’s very rare to see them doing some flying and actually sharing the bugs they find. Caution: Hard to create a non-biased opinion. Their product is always flawless until proven otherwise.
- Newcomers. Weird, but newcomers tend to find the products failures faster than we do. Why? They are interested in details, while we sometimes miss them. They fly the product a lot. Caution, though, they tend to ask too many questions(
- Hardcore simmers. Long time experienced, not important if they have real flight experience (but it should be considered too), These are the guys who fly for a living… virtually. They make reviews, comments, and they also have strong client opinions. Caution: Tend to create useless discussions over fuel consumption or taxi light positions.
- The buddies. These are the “friends” and true “always there” customers. They will tell what no one else has the guts to say. Although they could fit in any of the above categories, we all know that it’s great to have an “insider” who can get a grip on the others and report directly to the developers. Caution: Tend to want to “Lead” the team (shouldn’t), uses too much expressions “I will report that to the devs” and others alike. Always wants a freebie from this.
This is a list based in my own experience. A team shouldn’t have absent or non-motivated members. They shouldn’t have a majority of any of the above but have at least one of the types in the same average. This will create multiple points of view and doesn’t give in to dominant opinions. And I believe opinions are what it’s all about!
Comment by Glideslope — September 14, 2006 @ 11:27 am
Comment by Zilbermanvt — November 15, 2007 @ 8:45 pm
http://www.dailydumb.com/forum/showthread.php?t=15163
Comment by Sem — March 10, 2008 @ 6:39 am
man paint pay later perfect flame gas grill white oak tree leading land types in hawaii signmakers and hangers local union 194
Comment by ellaelax-qh — February 6, 2009 @ 8:08 am
áåñïëàòíîå âèäåî ïîðíîãðàôèè áåñïëàòíî ñêà÷àòü ïîðíî êëèïû ãååâ dom2 ïîðíî new àíàë ïîðíî âèäåî áåñïëàòíî rus.club ïîðíî ÷óëêè
Comment by ellaelax-dd — February 17, 2009 @ 10:49 pm