|
I can see where you'd think that some schools of thought would be more attracted to GUI test automation than others, but the fact is that I've seen GUI test automation used (and misused, and abused) pretty evenly across the board.
The distinction may be what folks with different perspectives want to use GUI test automation for. Consider the following uses of GUI-level automation organized by school of thought:
Analytical school uses for GUI automation:
- To confirm compliance with user interface specifications.
- To confirm the absence of broken links.
- To confirm that the UI appears identically across different browsers/platforms.
Factory school uses for GUI automation:
- To quantify test coverage.
- To detect unintentional changes in application.
- To validate functionality.
Quality school uses for GUI automation:
- To determine if a build or release is ready to enter the test phase.
- To provide a repeatable way to demonstrate issues.
- To ensure the same functionality is exercised in the same way with each release.
Context-driven uses for GUI automation:
- Any of the above that add value to the project.
- To reduce the time needed to perform testing support activities (like populating test data).
- To detect changes in the application that are easy to miss while focused on other aspects of the application (for instance, I am unlikely to notice that the sequence of data entry fields has changed if I'm focused on checking that the correct menu items are enabled).
The key to GUI automation is not what school of thought resonates best with you, but rather what value GUI automation can legitimately add to your project. I am not aware of any rational person that rejects the notion that GUI automation, when applied thoughtfully, can be a valuable part of the entire testing process. What most rational people reject is the notion that GUI automation can effectively replace a thoughtful human tester.
|
