Thanks to automated tests you can identify potential problems and modify defects in the code in the early stages of software development.

When working on large projects with public administration and state institutions, you can certainly count on one thing: what is defined at the beginning of the project is subject to very small possibilities to change. This includes the budget that is available, the time frame in which it is necessary to complete the project and the number of defined functionalities. In order to successfully complete the project with defined parameters, it is necessary to develop a good plan from the beginning.

Such challenging, often multiyear projects, are the responsibility of teams made up of a large number.of people. On the back end side you need to ensure that business logic is functioning, and on the front end side that the user interface is working as intended. It is therefore essential to involve automated tests from the start of development of a software system, in order to be certain that the above-mentioned activities have been successfully completed.

Writing tests is not an easy job. If you are working for an institution that selects and imposes the technology in which you will develop the software, then this same technology can be a limiting factor for testing. On the other hand, when you are choosing the technological solution,  the dilemma is what is the optimal technology for the task ahead of you. Therefore, development teams that are doing development based on tests, when selecting technologies, they choose those that will make their writing and integration into software solution easier.

Before, or during writing automated tests, the practice is to use the manual tests. They can be informal, where the tester verifies whether the functionality is implemented in accordance with the documentation, or formal, where the test is conducted according to a pre-defined set of steps that simulate user behavior.The main disadvantage of these tests is that they focus on the verification of certain functionality, whereby the entire system image can be easy lost out of sight. Thus,,with manual testing , you can confirm that a particular piece of software is satisfactory, but also ovelook that disrupted functioning of other part of the system is caused by this change. This is especially true in situations when development team generalize one functionality in order to use it in several different modules. These situations are common.

Thanks to automated tests you can, on time and in the early stages of software development identify potential problems and  modify defects in the code.

The tests can be divided in n categories, and here we have listed those commonly used in the development:

• Unit Tests (unit)which are used for separate testing of each software component i.e. functionality independently from other parts of the system;
• Integration teststhat check whether the system components work together, as described in the specifications of systems and programs design. They test everything, from the user interface to the database and are used for simulation of the user;
• Functional testingchecks whether an integrated system actually performs the functions described in the specification of the requirement. During development, they are most commonly covered with integration tests;
• Performance testing are used for testing performance of software solution.

Practice has shown that two types of scenarios are needed for proper testing of a certain functionality, i.e. use case:

• Positive testwhich is the basic scenario of software usage. When the user complies with all the rules and enter all information in predicted way, the test checks whether the result is in line with expectations. One scenario can have dozens of business rules that must be met. Good practice is to test as many as possible number of cases, if not all business rules, in order to identify failures on time.
• Negative test represents alternative scenarios in which the basic assumption is that not all will go as expected.

Why is testing important?

Testing enables to, during the development and writing tests, identify problems in the architecture of the software solution, functional specification in timely manner, and so on. Also, if the writing of automated tests is complicated, it may indicate that the initial assumption, system setup or use case is too complicated and that it should be simplified.

Writing tests itself increases development and deployment time. How much development can be extended depends on the complexity of the system and the need for covering it with testing.

Better defining the scope of the necessary tests at the beginning of development will help developers to create high-quality tests and provide a better assessment of the time needed for their development. Good judgment and good use of time is affected by the number of tests conducted. Writing tests to satisfy their specific number is counterproductive practice. They must have a defined purpose, to be simple and make sense.

Why is it important to switch from manual to automated tests?

If every programmer wrote automated tests, checked and ran them on their local machine, they would be able to see the mistakes in their segment and correct them. Then their execution would be in relation to the development environment, which is almost never the same as the one on production, and the running of the tests would take a very long time, which extends the duration of the development. For this reason, the practice is to run the tests on servers created for Continuous Integration.

Continuous Integration (CI) concept usually works on a single machine and a single server, with a single central repository where the code of the application is kept.

When one developer changes part of the code, the server upgrades the application and creates executable file to conduct the tests on. After completing the verification, the server sends the information whether the test passed or failed, and a programmer who initiated the tests knows in real time whether he violated a test or a functionality and can immediately correct the error.The process of executing tests is repeated throughout the day, after each change in code, but also with the ability to create a plan for periodic execution of different types of tests. In order not to block the work, for long-running tests, plans for periodic execution are defined, while  short tests are run after each change.

CI also increases probability to detect the problem in the early stages of software development. This is particularly important for projects that need to develop thousands of functionalities and in which it is very difficult to find and correct the error after the application is put into production.

Automated testing enables getting information about the percentage of coverage with software tests, i.e. test coverage. The percentage of coverage is usually set by customers at the beginning of the project or already in the tender and it can vary for different types of a software system.

During creation of an executable file and running of tests, there are tools that give statistics on the coverage of each part of the system. In Saga we use Maven for such purposes as a tool for automated preparation of application executable file and Cobertura and JaCoCo plug-ins for monitoring statistics of tests coverage. A good practice is to set a lower percentage at the start of the project, which will increase later.

Adopting the practice of writing and running automated test builds a culture in which development team accepts the fact that they are important and supporting part of the entire process of software development.

Tests generally lead to a better design of application. Of particular importance is not to forget that a large number of users will work on application after deployment and commissioning to production, therefore it is also necessary to check the competotors’ work, i.e. whether in such circumstances the system works. In this way you can avoid inconsistency of data base in the application running

What after production?

Manual test running after releasing software into production is harder part of the testing process, and it must exist. Automated tests then come to the fore, because after changes in the code, by implementing them we know whether some part of the system is violated or not. At this stage regression tests are mainly used, which are used to check the system disturbance.

Defining how big the need for testing is, applications coverage and scheduled time that can be spent on the test development in the design phase of system architecture will greatly facilitate the work of development teams, but also give more accurate information to the client on time of the work completion and most often it leaves impression  on the client.

It is essential that everyone involved in the activities of test development, especially developers, accept the importance of their writing. This will, in the long run, make their job easier, increase the quality of code and their confidence in what they did, because the functional specification changes frequently, and therefore the code and tests are the only way to quickly determine whether the change that has been made works or is violating some part of the system. On the other hand, it gives to the client assurance that the desired software product is created with serious, dedicated and systematic work.