Software Testing Social Network

GUI automated testing needs some experience, and I personally think that one year experience in a formal project should give you a good jump start in UI automation.

The following points are very important for automation of user interface testing:

1. Do not completely rely on the automation test tool’s record and play capability for GUI automation testing because that's too rigid and will not give you the flexibility. I recommend you to learn a high-level language to automate the user interface testing of the application. These programming languages often comes with the necessary APIs to automation the user actions such as mouse click, select and edit etc. In some tools such as QTP, Rational Functional tester you can use scripting language such as VBscript, Javascript to do the programming at the time of automation. In most of the big projects they use manual programming instead of simple record and play. So if you really want to learn automation then make sure you master one or two of such languages.

2. Do not automate the part of the GUI which is not stable yet or too buggy. This will lead to lots of rework when the application interfaces changes. Start with some more stable part of the application. Mainly before automation make sure you can actually run the manual testing on that part of the application without any big defect.

3. Try to avoid using text to recognize the controls in your application such as OK button but use some fixed control properties to discover it, such as the Control ID and so on. In this case, the generated code will be more stable and change in the text of the control by the development team will not affect you. Also there will be no localization issues.

4. Solve the synchronization problem. GUI Automation is mostly unstable because of synchronization problems. For example you can not click on a row while the screen is still loading. So you need to wait for certain times before you can make the next click. In your automation you need to take care of these kinds of wait times.

5. During the GUI automated testing certain windows object such as tool tip, Balloon etc can pop up. You need to think and handle all those exception scenarios and put some work around action in place. For example if a pop up comes the automation will close it and then proceed etc.

From my experience most of the GUI automation test problem comes from any of the above points so if you can handle them from the beginning then there will be less challenges in future.

User Interface testing guidelines are set of instructions that ensure that the product meet its planned/written specifications. And to achieve this goal a wide range of test cases is done. These test cases can become a real burden to the tester if they are not well equipped and experienced. When dealing with the UI testing the team has to focus on two major factors:

• the domain size
• the sequence

Dealing with the size issue can be illustrated easily.

User Interface can include from minor to several operations depending on the nature of the Interface, for example, a Command Line Interface has a few operations that need to be tested, whereas in GUI environment a smallest of all applications might have over 100's of possible operations that will be necessary for testing. The more program is large the more operations it can easily have.
The secondary problem to size is the problem of sequencing. There is some functionality within the system that may only be accomplished by following some of the complex sequence of User Interface events.
Let's say, when a user is opening a file he may have to click on the File Menu and then select the "Open" operation, then a dialog box will appear for the user to specify the name of the file he wishes to open, and then focus the program on the opened window. So it's obvious that increasing the number of operations (as described above) increases the sequencing problems accordingly. And when the tester has planned to create the test cases manually this will become a major issue for him.
So after a tester is well-prepared and ready to perform the test using a planner to generate the test cases will provide some specific advantages when the tester is manually generating the tests. Below are the solutions that a planning system generates to the planning problems that are quite beneficial to the tester:

Validity of plans is always there. That is to say, the output of the system can either be one of the two things, a valid & correct plan which uses the operators to attain the prestigious goal state or otherwise no plan at all. Now this is quite beneficial because plenty of time can be wasted if it was being done manually creating a test suite due to the invalid test cases that a manual tester though would work, and later they appeared that they didn't work.

A planning system has a keen attention to the ordering structure. Usually to test a particular function, test case must be complex thus needs to follow a path through the user interface where the operations are performed in a unique and/or specific order. If done manually, this can create issues and lead to errors and will become awfully difficult and time consuming.
And last but not least, a planning system is and has always been a goal oriented mechanism. That is to say, the tester is focusing the generation of the test suite on what actually is most important, testing functionality of the system.

So the bottom line is when manually doing all these test suites, the tester will be forced to focus more on how to test a function. But if tester is using a planning system then it will ease off some load on him.