Industry
Software
Products
TestComplete
For more than two decades, Adobe Systems, Inc.award-winning technologies and software have redefined business, entertainment, and personal communications by setting new standards for producing and delivering content that engages people anywhere at anytime. Recently, Chris Walcott, Flash developer and quality assurance guru, took the time to tell us how TestComplete has helped them test and develop Flash MX 2004 and Flash 8.
Project: Flash MX 2004 and Flash 8
Before Flash MX 2004 shipped we knew that we were going to have some performance issues. After release, the reality hit home pretty hard once customer feedback started pouring in. There were several areas that we knew we had to address. Because there were other areas in the program that needed attention, we decided to do a “dot” release of the product. The development cycle was about 9 months and not the usual 18 that we do for a major release. Management assigned one dev and one qa engineer to work on performance. While we decided on what areas to focus on, we also began research on what tools we could use to facilitate the testing. The team already owned one license for Silk but it was already in use and we did not have the budget to buy more licenses. We found AutomatedQA’s TestComplete and decided to give it a trial and eventually bought 3 licenses.
Focus Areas
There were four areas that we wanted to use automation for:
- Application startup
- Test movie
- Publish movie
- General UI manipulation
These are areas where I wanted to perform a specific task many times and take samples of memory. We tracked memory usage, page faults, USER objects and GDI objects. We specifically needed to track memory leaks over time and TestComplete was instrumental in this test case.
The first three areas listed above were fairly straight forward to script. The UI manipulation script was a bit more challenging as is always the case in any automation scenario.
Flash already has built-in JSAPI scripting (javascript api) that allows fairly deep access to the authoring tool. However, I wanted something outside of the application to make the calls and record what was happening.
Lessons Learned
One thing that I discovered right away was that we needed to make sure the dev and qa engineer had identical equipment and configurations. On Flash 8 I worked with an engineer offsite and we did not have identical equipment which meant that anytime I had bad news to report, it was difficult for the dev engineer to exactly replicate my findings.
Keeping it simple is absolutely essential and not easy to do. Automating an application’s UI takes a lot of time and when things change, your scripts break. Good clean coding practices help a lot.