Manual Testing vs. Automated Testing

Many testers that want to turn to test automation ask what should they learn first? Lots of people think they should start with coding. On the one hand, I believe that being able to code is an innate trait – some can and some can’t code. Therefore, it could be a good idea to find this out sooner than later. In my career as a programmer (more than 40 years!), I have met lots of people that desperately wanted to become programmers, but were hopeless cases. I really believe that a good tester is much better than a poor automator! On the other hand, I have seen countless examples of testers who turned to test automation that have never given a thought to designing ‘good’ test automation. Therefore, I decided to write down the various differences between manual vs. automated testing.

Manual tests can:

• Depend on each other if that makes it simpler for the tester (for instance, one test creates the data for the next test).
• Fail, but the tester can easily describe the results. Also, the tester can go on with testing the next test case even if the first test left the system in an invalid state.
• Take different times to perform specific actions, but a tester knows when to wait and when to go on.
• Perform on specific dates (testers can set and reset the date if needed).

Automated tests should:

• Be written as independent test cases, so that they don’t have to be executed together every time. This way, one can use the same test suites to run everything or, for instance, just the smoke tests or just the tests to the currently changed features.
• Clean up after failing so that the next test cases can execute normally.
• Test only one feature. This makes it easier to check the results, because eventual failures point to just one specific element. This is important since with automated tests, one can check the results only afterwards, so it’s important to understand what has been done.
• Write reports with the recipients in mind. For managers, it’s probably enough to show how many tests were executed and how many failed. However, for the developers that have to find and correct the eventual bugs, the information must be much more detailed. The test automation engineers themselves need to know where eventual problems turned up in order to correct the automation scripts.
• Reuse data whenever possible.
• Wait until some action in the System under Test (SUT) is finished, instead of immediately moving on and therefore losing synchronization (or worse – always waiting a fixed time that can be too much or too little).
• Perform date sensitive test cases.
• Be written in such a way that changing the testing tool doesn’t mean starting again from scratch.
• Be maintainable. This way, one doesn’t have to change a lot for every tiny change in the application under test. This means, for instance, that actions that are performed in many test cases are each written in a specific script that can be called when needed. This way, changes affect only one script and not the whole test ware.

These are my results. I’d love to hear your suggestions, what other differences are there in your opinion?