# Quality Properties of Execution Tracing, an Empirical Study
## 2 Related Works
analyse log library migration projects at Apache Software Foundation (ASF) and base their investigation on Jira ticket reports and git commit history [33]. They found that (1) 33 of 223 ASF projects underwent log library migration, (2) log library migration is not a trivial task as the median number of days to complete the migration at the 33 projects took 26 days, (3) flexibility (57%) and performance (37%) are the main driversfor the log library migrations performed, (4) log library migration is error-prone: more than 70% of the projects had post-migration bugs, on average 2 issues per project including missing dependencies, configuration, interactions between old and new libraries, (5) the performance improvement achieved by the log library migration is usually negligible [33]. [PERSON] et al. examines the possible ways for operators and administrators to elicit and understand the meaning, and impact of the log lines; moreover, to identify a solution for resolving them [34]. [PERSON] et al. found that log-related metrics, including log density, defined in their study can also be effective predictors for post-release defects [35]. The correlation measured between the defined log-related metrics and post-release defects are as strong as the correlation between the pre-release defects and the post-release defects, which is known to be the strongest predictor at present [35]. The reason of the high correlation can be explained by the attitude of the developers, who tend to add more logs to the code about which they have concerns [35]. Consequently, decreasing solely the number of log statements in a source file does not implicate improvement in the source code quality. [PERSON] et al. analysed all the software product quality models defined and published in the past 20 years; moreover, the investigation was extended to the application of such models including their tailoring [36]. The partial software product quality models were ruled out from the analysis, as these models give up the aim to define quality properties to cover the whole set of software product quality. On the other hand, quality models, which aim to consider each aspect of software product quality are designated in the present paper as _complete software product quality models_ even if completeness means an elusive target in a precise sense. The models identified in this manner were classified and assigned to software product quality model families to indicate whether a new software product quality model was born or merely enhancements of a previous model were published [36]. If the model published built on previous models but introduced new concepts, then it was regarded as a new software product quality model. This way, 23 software product quality model families were identified as Table 1 shows. None of the identified 23 software product quality model families handle logging quality adequately. Solely the SQUALE model [37] addresses the quality of execution tracing explicitly to assess whether log messages on three severity levels are traced: (1) errors, (2) warnings and (3) infos; however, having severity levels is only one possible aspect of execution tracing quality. In addition, the ISO/IEC 25010 standard family [21; 38] defines quality measure elements (QMEs) which use the word \"log\" in their naming but their meanings deviate from execution tracing or software logging. Furthermore, the quality model of ISO/IEC 25010 [21] standard family does not consider execution tracing but defines measures which show similarities or overlap with execution tracing quality to some extent even if they are different [38]: (1) user audit trail completeness (ID: SAc-1-G), (2) system log retention (ID: SAc-2-S), (3) system log completeness (ID: MAn-1-G), (4) diagnosis function effectiveness (ID: MAn-2-S), (5) diagnosis function sufficiency (ID: MAn-3-S).