Testing strategies for Flash movies

During the development of your Flash movies, you might occasionally run into difficulties. This is usually because creating interesting movies and trying out new ideas always involves some experimentation on the part of the author. By testing your movies according to these simple guidelines, you can prevent problems from becoming obstacles.

Test early in development

When you begin a Flash project, plan to start testing the functionality of your movie early in the development process. This will help ensure that you discover any problems while they are still minor. Waiting to test can allow small problems to become larger ones, as you add subsequent features to your movie that depend on problematic functionality implemented earlier. By incorporating testing into your authoring process early, you'll find these problems and have the opportunity to fix them before adding additional features to your movie.

Test often during development

Testing should be an integral part of your Flash development process. Test the functionality of each small part of your movie as you add it rather than waiting until the movie's whole feature set is implemented.

Avoid building features that are interdependent without testing each one before adding the next. If you test this way, when problems arise you'll know that the most recently implemented feature is the most likely source of the problem. If you wait to test one feature until after the next feature is implemented, and one of those features exhibits a problem, you'll have a more complex set of possibilities to evaluate.

Save multiple versions of your movie as you progress. When difficulties arise, compare the current version to the last saved version to help locate the source of the problem.

Test on all target platforms

When you develop a Flash movie, you should spend some time defining who the audience for the movie will be. Part of this process is deciding what the minimum system requirements should be for the computers used by that audience.

Determine the slowest processor speed you want your movie to be able to play on and verify that the performance of your movie is acceptable on a processor of that speed. You should also determine if there is a range of configurations you will have to support (such as Windows NT and 2000, Macintosh) and test on enough of them so that you can infer success on all of them. Be sure to include parameters such as browser software, screen resolution, and memory in your testing.

This approach will help you find problems that are specific to an operating system or configuration, a class of problems entirely distinct from authoring errors.

Testing strategies

Use the following strategies to test your movies effectively:

Be sure to use the Control > Test Movie command. Testing in the Flash application is different from testing a SWF file. The Test Movie command simulates the true behavior of the SWF file.

If you run into a problem, try to isolate the problem in a new Flash file that incorporates only the problem feature or item. Make a list of the minimum steps required to reproduce the problem in a new file. This will usually shed light on the source of the problem in your actual movie. It will also reveal whether the problem is limited to one feature or caused by the interaction of two or more features in your movie.

Try to re-create the problem with different library media. Sometimes the source of a problem is within a specific media item used in your movie.

Try to re-create the problem on a different computer. This will help isolate problems with hardware configuration or with the Flash installation on a specific computer. If the problem exists only when the movie is posted to a server, determine whether the problem exists on only one server or all servers. Occasionally the server's MIME types may need to be edited to include the MIME types for Flash.

When using ActionScript, look for typos, missing punctuation, or inconsistent naming.

 

Best Practices…

While developing a product one comes across many situations in which a person needs to take decisions which might present all alternatives which seem wrong or all alternatives which seem
correct. In case of such tough decisions, one has to be guided by some best practices which can
help him to solve this problem if not present a readymade solution to the problem.

The best practices can categorized into broad categories:
1) 10 must haves for a Quality Engineer.
2) Four things which any professional or entrepreneur cannot afford to forget.

The best practices of a Quality Engineer ensure that quality of the final product is ensured.

1. Know the technology
In the area of software development, technology is changing rapidly. What is new trend today
may become obsolete tomorrow. In this fast changing world a tester should keep abreast with
the latest in the technology world. A Tester should know what technology is being used for
developing applications. He should know the supporting technology associated with OS. This
will make sure that the tester will find bugs at the early stage, thus reducing the price for the fixing of bugs. Also, studying the technology helps study the competitor better and thus helping your product to have a good standing in the market. Studying the technology would also help the Quality Engineer to understand the workflow and the product better.

2. Learn from past experiences
Before writing the test plan and the test cases, QE should try to scan data from past projects,
which are similar in nature. This may give them some better test cases, issues that were
identified in the end of the cycle, some areas that could be automated. If the application is extension of earlier project, high priority and severity bugs should be regressed for current version of application.

3. Ensure sufficient coverage of feature workflow
The key to success of the testing effort is that when a customer uses the product, he/she
should be able to seamlessly use it. This kind of seamless experience can only be ensured if the
common user workflows have been tested thoroughly. The challenge here is that different users
use different features and in fact might even use the same feature in a different way. Here is
where the role of sufficient coverage comes in.

Coverage can broadly be classified into two categories:
a) Coverage of different functionalities present in the software
The software performs a series of tasks. However the usage of these tasks may vary depending
on the requirement of the customer. Once the possible workflows have been identified, one needs to prioritize the workflows depending upon the number of users who would use the particular feature.

b) Coverage of the different routes while going through the workflow of the software
Common functionalities can be accomplished in many different ways in most software. E.g. in
order to copy a text in Microsoft Word application, one can use the keyboard shortcut Ctrl+C, or
right click on the selected text and select copy. One can also use the edit menu to do the same.
Each of these three routes is important because a user can copy text using any of these. As a
Tester, one needs to find all possible routes of accomplishing a task. After the routes have been
Identified, Quality Engineer needs to see how much probable are these in a real world scenario.
Also study of usage of this feature in comparison to other features needs to be done. As for our
example, we need to know how much common it is for the user to use the ‘copy’ feature in
comparison to other features like ‘find’, ‘replace’, ‘cut’ etc.

4. Make a matrix for hardware to be supported by application (and prioritize the hardware)
Many applications support different configurations of hardware. A proper matrix ensures that application is working on important configuration of hardware.

5. Assign two QEs (primary and secondary)
An application has multiple features. There should be two QE assigned to a feature. The
QE can be assigned as primary QE and secondary QE. Primary QE is responsible for creating
test plan, test cases, setting test environment, executing testing, reporting bug and regression of
bugs. Secondary QE can work as a back up. He can be involved for reviewing test plan and
script, helping primary QE in setting up testing environment, executing some part of test cases at different interval and in regression of bugs. This will help in getting control of bug myopia (blindness to a bug if working for a long time in testing a feature).

....... to be continued