Software testing can be used to demonstrate the presence of malfunctions, not to prove their absence (Dijkstra in Dahl et al. ). This famous affirmation is a synthesis of what should be the objectives of testing. We need to simply remind ourselves that from the activity of testing we can not draw absolute certainty about the correctness of a program.
Software testing is based on two main problems:
The first problem occurs when a developer produces for the first time a software or a part of it. It will need to be structured using reliable and systematic techniques such that, once executed, one will have a greater awareness of the reliability of the product.
The second problem is focused on reworking (Regression Test) or modification of the already generated code. Every time a developer makes or brings in a change to the code or to a functionality, there is always a chance that even a small tweak can have an unexpected impact on the general performance or the functionalities of the software.
These tests can be divided into two broad categories, White-Box Testing and Black-Box Testing. The first is also called “structural test” or structural verification (Non Functional Test) and is a particular type that is used to detect errors in one or more components present in the code. Through Test Automation Software (SonarQube or Rational Test Workbench) it is possible to set, according to defined quality policies of the company or the client, a Quality gate, which is built on a series of metrics (such as minimum percentage of comments, complexity of classes and functions, alignment to good programming practices, bugs, and duplicated code) which describe, for each packet or part of code analyzed, the quality, maintainability and reliability with which a company wants to offer a product or a System Integration Feature to the market.
The second type is represented by Black-Box Testing (Functional Test). These represent a very sophisticated macro test category, because with this activity comes into play, especially for the Graphical User Interface (GUI) test, a human component that derives from visual approval – the aesthetic of the product and a satisfaction related to the features developed and their general functioning. In relation to the GUI, it is generally advisable to not use am automatic type of software (available on the market but with functionality that is too unpredictable) but to invest in human resources, who through sensations and perceptions, can express their user experience of the product. This approach is sometimes much more indicated when looking at products such as Web portals for showcases sites or e-commerce, where the user without any technical expertise is preferred for the expression of opinions that can help, in a concrete way, to align the product software to customer needs (of course this discussion should only be considered after a good gathering of requirements).
The Functional Tests of code at the Feature level, unlike those on the GUI, must be considered as a system which, similar to a black box, is describable essentially in its external behavior, i.e. only for how it reacts in response (output) to a set of requests made to it (input), but whose inner workings are not visible or are unknown. For example, we can consider a Search Feature which returns a table with the data related to a query performed on a database. The Functional Test doesn’t need to know if the code is qualitatively correct at the presentation level (the browser HTML) or at the Server level for the Database request, but it should mainly focus on the input given, “Display a table with the Query specified”, and with the expected output, “a table with data compliant with the Query”. Obviously a very important thing for the Functional Tests is the conditional and functional coverage, i.e. the efficacy of the test is directly proportional to the number of cases applied above. Therefore to conclude, it will always be necessary to try to design the Test Cases in a way that guarantees a total coverage of all possible Input – Output of the system considered Matrix Test (IN/OUT).
The Application fields of the Automation Test can be varied and even heterogeneous, from Enterprise Service Management (ESM) to System Integration Services for Enterprise Asset Management (EAM) systems. Of course, it is necessary in all these cases to have an integrated and distributed enterprise management system which allows collaboration with the product. In particular for a Project KRIU EIRE in Omninecs, this management is handed off to a licensed software called JIRA, which allows through Quality Management plug-ins, a structured, distributed and agile management of Test Automation activities.
In conclusion it is useful to dwell on an area that is little taken into consideration but that is very important in Test Automation, as well as Versioning Software, and that is indispensable to the organizational goals of collaboration and releases. This activity is very significant and represents a good 10 % of the total activity of software development as it is generally a difficult organizational and mental obstacle for any developer.
The intention of this article was to point out the merits and impact of Test Automation on software production, highlighting that the more a methodical and well structured approach is imposed at the beginning the greater will be the benefits that an activity of First Release and subsequent Updates can have in terms of Software Quality (robustness, maintainability, reliability, compliance with the requirements). These benefits require an expensive effort that can at times range from 20% to 40% of all development activities and of course the higher the investment by a company in the area of test, the greater will be the gain at the level of image on the market and as a direct consequence increases in customers and resulting profits.