User Interface testing guidelines

Posted on Apr 11 2010 - 5:52pm by Raj

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.

About the Author

Leave A Response