The manipulation of ontologies in databases can represent gains in the recovery of strategic information in decision-making process within the software development organizations. The software testing processes are strategic elements to develop projects and to the quality of the final product. Thus, this study investigates strategies to promote data handling of testing processes that are generated from a testing ontology. For this, a knowledge database is structured in a dimensional model for Data Warehouse to support storage and processing of data to obtain strategic information that can facilitate decision making. Resumo. A manipulac¸a˜o de ontologias em bancos de dados pode representar ganhos na recuperac¸a˜o de informac¸o˜es estra´tegicas no processo de tomada de decisa˜o dentro das organizac¸o˜es de desenvolvimento de software. Os processos de teste de software sa˜o elementos estrate´gicos para a conduc¸a˜o de projetos de desenvolvimento e qualidade do produto final. Diante disso, este trabalho tem como objetivo investigar estrate´gias que possam promover a manipulac¸a˜o de dados de processos de teste que sa˜o gerados a partir de uma ontologia de teste de software. Para isso, estrutura-se uma base de conhecimento em um modelo dimensional de Data Warehouse que apoie o armazenamento e o processamento dos dados para obtenc¸a˜o de informac¸o˜es estrate´gicas que podem facilitar a tomada de decisa˜o.
With the exponential growth of data from several different sources of knowledge within an organization, it becomes necessary to provide automatized support for tasks of acquiring, processing, analyzing and disseminating knowledge. Organizations need to effectively manage the information generated in its production environment to promote the improvement of the processes used to generate knowledge and also support future decisions. Such data can provide important information for decision making, involving the identification and implementation of corrective actions.
One of the characteristics of software engineering projects is to deal with a great
deal of information that are generated and manipulated. People involved in the project
face problems, such as: organize in a systematic way the information generated through
the software process; reuse the knowledge generated from one project to another; loss
of intellectual capital of the organization due to better opportunities; and no knowledge
representation [
In the area of software development, testing is a critical factor in product quality,
and thus there is a greater concern with related research. Studies indicate that the quality
of the software product is strongly dependent on the quality of the processes that are
part of the project, especially the software testing process. However, finding relevant
information (knowledge) in these processes can be a difficult and complex task, and it is
related mainly to the lack of semantics associated with the large volume of information.
There is a need to represent knowledge, to make it affordable and manageable. In this
context, ontologies have been pointed out as an important way for representing knowledge
[
The manipulation of big ontologies with a high number of instances in the form
of text files has a number of disadvantages, such as processing and query
optimization [
Given the above context, this paper aims to investigate strategies that can promote the manipulation of data generated from large ontologies. For this, a knowledge base in a dimensional model for Data Warehouse is structured to support the storage and processing of data to obtain strategic information that can facilitate decision making. A software testing ontology is being developed to support this work and instances of this ontology is used as a data source for the structure created. Section 2 briefly discusses ontologies and storage structures. Section 3 presents the proposed structure to store ontology data. Section 4 presents conclusions and future directions to follow.
During the last decades, ontologies have been shown useful in the field of Computer
Science [
Literature provides several tools to store and manipulate content from an
ontology in a database and several strategies can be found [
The ontology used in this paper is in the context of the Ph.D. thesis of the first author
[
Given the complexity of the software testing domain, an ontology and its
subontologies were created and used. Currently the main ontology created has: Steps,
Techniques, Types, Artifacts and Environment. SABiO (Systematic Approach for Building
Ontologies) was adopted to develop the software testing ontology [
As the ontology is still under development it may suffer some changes. However, though in the initial phase, it is already capable of describing execution phase of the tests, and from this premise that DW will be created to store ontology data. This phase contains data related to dates, for example, date of test case execution, date of defect submission and date of defect correction.
Instances of the software test ontology were extracted from an actual project
developed at the (Technological Institute of Aeronautics - ITA) - (Project of Amazon
Integration and Cooperation for Modernization of Hydrological Monitoring - ICA-MMH B)
[
For converting the content of an ontology written in RDF into a DW architecture, we follow the process shown in Figure 1.
To enable reading the ontology in the Pentaho Data Integration tool it was
necessary to transform the RDF/OWL in a simple XML and export the data of the instances for
the DW model created. For this, we used the
From the simple XML Pentaho is used to extract, transform and load the data for DW using ETL (Extract Transform Load). The data is loaded in DW table of facts. Star model was chosen to create the DW. The model consists of table ft test execution which is the table of facts, and five dimensions, namely: (i) three dimensions of time: lk execution time contains the date of the test execution, lk submission time refers to the date of a defect submission, and lk last change time refers to the date of the last change made in the request to repair a bug; the lk team dimension contains information about the tester, such as the name of the tester and his or her level within the team; and ii) the lk project dimension contains information with respect to the project for which the test was performed. Figure 2 shows the Star model created with its respective tables.
In order to see the contribution of the methodology, some questions (that might be important for decision makers) were posed. The idea is whether the table of facts can, in fact, answer such questions in a satisfied manner and useful to decision makers or managers. Therefore, just as an example, the following questions were defined to exercise the table of facts and the different dimensions of the DW: 1. What is the average time between the report of a defect and the test run to check if the bug was repaired? To this question the result obtained was an average of 5.85 days. This information can be useful for the manager or responsible for project to analyze whether the time between a request and the execution of the tests are on schedule. 2. What is the percentage of tests executed per profile of the team? Figure 3(a) shows the results obtained for this question. Most tests were executed by team members with the position of tester, which is logical since the rest of the tests were executed by analysts and the main function of the analyst is to develop test plans and not to execute them. The result is consistent with the reality of a team of software testing. 3. How severe are the defects reported? Most defects reported have minimal severity and only 3% of the defects are of large severity. This suggests that the process of system development is a reasonable quality control (Figure 3(b)). 4. What is the relation between testing and defect solving? Most of the reported defects have been solved so far. Only 2% of the requests were reopened indicating a recurrence of an already reported defect, and only 1% of duplicate requests that are still under correction (Figure 3(c)). (a) Number of Executions by profile.
(b) Number of tests by defect severity.
(c) Number of tests by resolution of the defect.
This paper presented structuring and storing of ontology content in a DW model. We used a preliminary ontology of software testing process that is under development. The data analyzed refers to the test execution phase. The DW model created is expandable and may include other phases within the process of software testing.
The model facilitates queries and can also provide strategic information that can be used to improve the development process as well as for the process of software testing. The model can be enriched and provide more information that can be used in decision making. Some difficulties were encountered as lack of support for the Jena framework and real case studies with test procedures clearly defined.
Future directions include the automation of data entry in the ontology from other sources, model expansion to store data from other phases of the software testing process and integration with the software development process.
FAPESP and CNPq (PIBIC) for the financial support. ITA, Brazilian Water Agency (ANA), Brazilian Agency of Research and Projects Financing (FINEP) and the Casimiro Montenegro Filho Foundation (FCMF) for providing the data of Project FINEP 5206/06 for this work.