Although there are several tools available today that enable the automation us user interface unit testing, they are not ready to use as the only testing procedure of any given application.
There are several issues that these tools fail to catch. Mainly, the work flow errors. Your application could pass the GUI testing framework with flying colors and yet, once your application is human-accessible, it fails colossally. This is because the slightest misinterpretation by the testing framework as to what the work flow should look like (work flow in this context is the sequence of user interface actions, not application logic). This is not to say that the user interface testing frameworks are not capable of fully automating the interface testing, it is a question of effort involved. A simple user interface validation test done by a human may take an hour to perform where designing a test may take much longer.
In the long run is it worth it? Maybe. If your application is user interface centric (some would argue that all applications be designed using the interface as a starting point), it might make sense. In this case, the user interface designers will most likely be designated to this task. They will not likely care about application work flow.
What if you are in a situation where the user interface takes a "back seat" to other "more important" tasks? Well, this is bound to happen. After all, a user interface with no application behind it isn't terribly useful. Perhaps what is needed here is two sets of use cases. One for the application, which is independent of how external actors interact with the system. And, one for the user interface that describes the interface cases in much detail while keeping the application cases vague.
No comments :
Post a Comment