The following is a brief overview of automated testing and why it contributes to higher quality software.  Automated testing can be broken down into two areas, unit testing and acceptance testing. 

Unit testing is the process of writing code to test the code itself.  They are written by the developers and give a current picture of how the code should work.  At a high level, this is achieved by writing code which calls the public interfaces of the units, usually classes that make up a software system.  Generally there is a test class per class in the system being tested.  These test classes are made up of functions which test the various functions of the class to be tested. 

The aim is to achieve a high level of coverage of the class being tested.   By coverage we mean the percentage of lines of code that are exercised by the tests.  Along with high coverage tests should be written to include scenarios which exercise the code with sufficiently realistic scenarios as to ensure the robustness of the code.

In a system without unit tests when a change to the system is required it can be difficult to ascertain the impact of that change on other parts of the system without very extensive manual testing.  With good quality unit tests providing high code coverage, developers can make changes with confidence that any adverse impacts on the system will be picked up by failing tests.  These failing tests can then be reviewed to determine what further action is required.  

This confidence in being able to make changes to the system also encourages refactoring.  As a system evolves, the code must be refactored to avoid code rot, or code becomes fragile or brittle.  For example as a system grows the patterns applied may not be best suited.  With high code coverage from unit tests developers can confidently refactor systems, leading to code bases which remain easy to adapt to changing requirements over the lifetime of the system.

There are challenges to unit testing particularly in larger systems with many dependencies. Methods for overcoming these challenges are well documented, such as writing your code with good separation of concerns using appropriate design patterns and the use of mock objects or fakes to test particular units of code independently of their particular dependencies.

Acceptance testing in general is testing to ensure the system matches the system as it was specified. In a waterfall methodology acceptance testing would be testing against the requirements set forth in the system specification.  In agile methodologies acceptance testing is testing based on the user stories included in the current release.  In either case acceptance testing will need to be repeated at various stages over the lifetime of a system with regression testing combined with new test scenarios as new features are implemented. 

Automating acceptance testing has obvious benefits in terms of savings in time and money by reducing repetitive manual testing.  The overall quality of system is also improved as building on a suite of acceptance tests allows for alternative scenarios to be tested which otherwise would not have been possible due to time or resource constraints.  For example tests can be included to simulate long running scenarios or scenarios involving large numbers of users.  The morale of testers is improved by reducing repetitive tasks and instead freeing them up to consider alternative test scenarios to be automated. 

The adoption of automated unit and acceptance testing greatly improves the quality of software systems and increases their potential lifetime by facilitating future changes.