I don't think they have any testing team per se. We, users, are the testers and we build their test scripts by submitting bugs/tickets... this allows them to avoid the analysis of their own written (buggy in most aspects) code. I can't see any other more plausible explanation than this.
I suspect that HW acceleration was implemented in an attempt to fix the slow downs and problems with the release of memory when towns are visited, or alternatively due to the increase of detail. Essentially shifting the processing from the back end, to the users. The problem with this is if the code is inherently buggy, then you a) don't fix anything and b) only compound the issue.
Flash being slow is usually the result of a poorly programmed animation, menu, etc and I've said this previously, but flash is very forgiving of REALLY atrocious code, and still have everything run well enough that it doesn't impede the content. It's also very easy to learn so pretty much anyone can do it and you don't have to be a complete uber app developer to do so.
Basically for large flash projects, slowness comes from two sources: Business priorities and app devs who check in slow code. Slow code is more common than normal due to Flash gotchas, but the largest reason they don't get fixed is tight deadlines and priorities. i.e. working on new content instead of getting the existing one 100% perfect.
Don't also forget it's been stated many times (by representatives of Inno) that this game is only 40% complete, not that it's an excuse for poorly thought out implementations or test cycles. I guess they would like to call this phase "UAT"
Additionally these learning curves come with maturity. On a personal note, the implementation of HW Acceleration was a bad move and all it has done is made an existing issue more prevalent, and for me I've switched it off (luckily there is an off button)