I must admit I have no idea how the current Flex Alpha and Beta test programs operate. I do not know it the selection of the testers is done using a criteria, if they go thru performance evaluations, if they are managed actively or even it they are paid for their time.
At the Flex Dinner in Dayton it was announced that a more rapid release of updates was going to be a focus area for Flex. I believe it was mentioned that the target was to release a software upgrade once every few months.
WIth the recent 1.8 release it seems a large number of customer are having issues with the changes and additionally it appears from the community posts that the issues are in several functional areas.
I certainly like the idea of Flex releasing more rapid updates but I am thinking that any improvement in more rapid releases will be lost if the releases are issue prone such as it seem is the case with the recent 1.8 release. Not only does this leave a bad taste in the customers mouth but resources at Flex need to be deployed to fire fight and fix these issue and might end up effecting the timing of other functionality development efforts. Also, feedback from the user base might be delayed as people decide it is in their best interest to wait for others to load the updates and see if they work properly before doing so themselves.
Hence, my question. Does the Alpha and Beta testing process need to be more structured with specific criteria, test scripts, time and deliverable requirement in order to support the quicker release focus?
I am not really expecting an answer either agreeing or defending the process only pointing out the need for Flex management to critically look at the root causes of this recent failure and what can be done to improve the process to support the achievement of the goal of quicker releases.
Regards, John K3MA
At the Flex Dinner in Dayton it was announced that a more rapid release of updates was going to be a focus area for Flex. I believe it was mentioned that the target was to release a software upgrade once every few months.
WIth the recent 1.8 release it seems a large number of customer are having issues with the changes and additionally it appears from the community posts that the issues are in several functional areas.
I certainly like the idea of Flex releasing more rapid updates but I am thinking that any improvement in more rapid releases will be lost if the releases are issue prone such as it seem is the case with the recent 1.8 release. Not only does this leave a bad taste in the customers mouth but resources at Flex need to be deployed to fire fight and fix these issue and might end up effecting the timing of other functionality development efforts. Also, feedback from the user base might be delayed as people decide it is in their best interest to wait for others to load the updates and see if they work properly before doing so themselves.
Hence, my question. Does the Alpha and Beta testing process need to be more structured with specific criteria, test scripts, time and deliverable requirement in order to support the quicker release focus?
I am not really expecting an answer either agreeing or defending the process only pointing out the need for Flex management to critically look at the root causes of this recent failure and what can be done to improve the process to support the achievement of the goal of quicker releases.
Regards, John K3MA
Posted 2 years ago
Gerald - K5SDR, Employee
