How to start with automated testing of projects

The initial test setup during initialisation of a project includes continual integration, static code analysis and unit tests.  The preparation of testing environment is a simple, standardized process that can be easily applied to most new and existing projects.

 Nowadays, there are many good quality open source tools where the required number of MD units can be set up.

Here are some of the tools:

• Continual integration: Cruise Control, Hudson,…
• Static code analysis: FindBugs, PMD, Jdepend,…
• Unit tests: TestNG, jMock, EasyMock, DbUnit, …

Smoke tests

Smoke tests represent another not very demanding way of increasing quality and starting project tests. They are based on a set of tests that verify a basic functionality of the system. They minimise problems with integration and enable time tracking of the start of some errors.  They maintain the product functional and enable a better perception of the product by developers, which increases the moral of the team.

Within this context it is important to carry out a daily build and follow up smoke tests. Microsoft uses smoke tests as their main testing strategy. Build is launched every night, followed by unit tests. Microsoft claims that smoke tests are financially the most efficient method to reveal defects, and Profinit, based on its experience, can vouch for that.

After the initial set up of testing environment for the project, the next step is to carry out smoke tests which are not demanding, neither in terms of time nor finances.  It is possible to implement the basic set of tests in MD units up to dozens of MD.

Static Code Analysis

Static code analysis can significantly help when testing applications as it draws attention to the problematic parts of the code which are more than likely wrong or do not correspond with good practice of software construction.

Static code analysis usually identifies problems connected with referencing non-initialized references as objects, and draws attention to potential spelling mistakes when using two similar variables.   Most tools include a database of typical errors which are made by programmers repeatedly and frequently (problems with synchronisation, with API Java SE etc.). By using suitable tools, the time necessary for examining the code is significantly shorter which is a standard part of QA at project or company level.

There are several good quality open source tools for static code analysis, e.g. FindBugs, PMD, lint4 etc. It is possible to use them separately, to integrate them into a development tool (such as Eclipse) or to integrate them into a build process (Ant).

Load testing

Load testing provides important information on border conditions of the system in terms of performance.  System failure can have major financial and marketing consequences. It is more important to know the boundaries of overload instead of knowing how the system behaves during overload.  Based on this information, it is possible to manage activities such as planning marketing campaigns (so that the system does not collapse) or investment into expanding system capacity.

Load testing can be implemented in several steps:

1. To declare present maximum load (input data)

2. To create testing scenarios for load testing (MD units up to dozen MD)

3. To use or implement the existing testing tool (dozen MD)

4. To carry out capacity testing, monitoring system response (MD units up to dozen MD)

5. To analyse impact and solutions - optimising the code and processes, strengthening hardware, increasing permeability of channels. 

Load testing can be implemented at a cost of dozen MD.  There are several open source tools that can be used.