## 4 Discussion  
This section discusses the implications of software testing scope decision-making based on the cross-project and cross-language ML models induced using the cost-sensitive approach in a hypothetical scenario.  
The test manager has a budget of \(n_{t}\) software testers and \(n_{t}\) days available for software testing. Equation (28) gives the **available software testing budget in hours (B)**, considering a workday of \(8\,\mathrm{h/day}\),  
\[B=8\times n_{t}\times n_{d} \tag{28}\]  
In a comparative hypothetical situation, as presented in Figure 7, 8 software testers are available for a 17-day effort, resulting in B equal to 1088 h. The project's average effort to test a software module (E) was estimated to be 5 h. Thus, the available budget can afford to test around 218 modules on average. In Table 2, the closest MT value to 218 is 217, which corresponds to \(RC=2\); therefore, the ML model to be used to support the decision-making on software testing must be one that is trained with \(RC=2\).  
Figure 6: [MDM, MNDM, and UT] \(\times\) RC.  
When \(RC=2\), the average number of defective modules discovered by a software testing effort following the ML model corresponding scope is 116 (Figure 7([1])), according to Table 2. If the same software testing effort was performed in a same-size scope encompassing modules randomly selected, only 16 defective modules would be discovered (Figure 7([3])). That **equivalent number of defective modules discovered with random selection (DR)** is defined by Equation (29).  
\[DR=p_{TP}\times\text{MT}=7.4\%\times 217=16 \tag{29}\]  
Thus, using the same budget available, the effort would identify over seven times more defective modules when an ML model-based decision-making process is used rather than a random selection of modules, which is quite impressive (Figure 7([1]) \(\times\) Figure 7([3])). Moreover, a manager would need a **testing effort (\(TE_{Random}\))** of 7840 h (given by Equation (30)) to test 1568 software modules randomly picked to accomplish an equivalent performance in the number of defective modules discovered (Figure 7([1]) \(\times\) Figure 7([2])). In other words, the manager would need a software testing budget 7.2 times higher without using the ML model to select the modules to be tested for achieving the same accomplishments, which is quite impressive.  
\[TE_{Random}=\frac{TP}{p_{TP}}\times E=\frac{116}{7.4\%}\times 5=7840. \tag{30}\]  
Figure 7: Comparison of the value added by the proposed technique in a hypothetical scenario with four decisions regarding the software testing scoping and allocation of available software testing resources.  
Considering this hypothetical scenario, following the ML model recommendations, the software testing **productivity (Prod)** would be 9.4 h to find each defective module on average, given by Equation (31).  
\[\mathit{Prod}=\frac{\mathit{MT}}{\mathit{TP}}\times E=\frac{217}{116}\times 5=9.4. \tag{31}\]  
Thus, to reach the **equivalent result of the random selection (ER)** (16 defective modules), the software testing team informed by the ML model would need to test around 30 modules (Figure 7([3]) \(\times\) Figure 7([4])), according to Equation (32), which would require a total effort of only 30 \(\times\) 9.4 = 282 h,  
\[ER=\frac{\mathit{MT}}{\mathit{TP}}\times DR=\frac{217}{116}\times 16\approx 30 \tag{32}\]  
Those results demonstrate the power of using ML models to support decision-making on software testing scope definition and resource allocation, helping quality assurance efforts accomplish better results with the available resources or even using fewer resources.