| Article Index |
|---|
| Automated Software Testing |
| Page 2 |
| All Pages |
last few years the practice of testing has undergone more than superficial changes.The aim to automate the repetitive steps that a tester would take to exercise functions through the user interface of a system in order to verify its functionality.
On the downside, we observe problems when we employ these tools:
Scripting your manual tests this way takes far longer than just executing them manually.
The UI is one of the least stable interfaces of any system, so we can start automating quite late in the development phase.
Maintenance of the tests takes a significant amount of time.
Execution is slow, and sometimes cumbersome.
Tests become flaky.
Tests break for the wrong reasons.
Of course, we can argue that none of these problems is particularly bad, and the advantages of automation still outweigh the cost. This might well be true. We learned to accept some of these problems as 'the price of automation', whereas others are met by some common-sense workarounds:
It takes long to automate a test—Well, let's automate only tests that are important, and will be executed again and again in regression testing.
Execution might be slow, but it is still faster than manual testing.
Tests cannot break for the wrong reason—When they break we found a bug.
In the rest of this article we would summarize some experiences we might have had while trying to overcome these problems, not by working around them, but by eliminating their causes.
Most of these problems are rooted in the fact that we are just automating manual tests. By doing so we are not taking into account whether the added computational power, access to different interfaces, and faster execution speed should make us change the way we test systems.
Considering the fact that a system exposes different interfaces to the environment—e.g., the user-interface, an interface between front-end and back-end, an interface to a data-store, and interfaces to other systems—it is obvious that we need to look at each and every interface and test it. More than that we should not only take each interface into account but also avoid testing the functionality in too many different places.
Let's take the example of a store-administration system which allows you to add items to the store, see the current inventory, and remove items. One straightforward manual test case for adding an item would be to go to the 'Add' dialogue, enter a new item with quantity 1, and then go to the 'Display' dialogue to check that it is there. To automate this test case you would instrument exactly all the steps through the user-interface.
| < Prev | Next > |
|---|
