CROSS-REFERENCE TO RELATED APPLICATIONS AND PRIORITY
[001] The present application does not claim priority from any patent application.
TECHNICAL FIELD
[002] The present subject matter described herein, in general, relates to a method and a system for identifying relevant test cases for software testing.
BACKGROUND
[003] Software testing is one of an important phase in a software development life cycle (SDLC). It is mainly conducted to ensure smooth functioning of a software application or a software product or tool after its launch. As conventionally known that for conducting the software testing various test cases is used. Basically, the test cases are set of conditions or scenarios based on which different functionalities of the software application or the software product is tested. With each of these functionalities/methods, a number of test cases are associated, and therefore, the volume of these test cases grows exponentially with the number of the functionalities or the methods present in the software application or the software product.
[004] This exponential growth makes the software testing process complex and time consuming, because it is not be feasible to run all the test cases in a limited time period. Thus, it becomes a challenge to select only those test cases which are highly relevant for conducting the software testing in a limited time. According to an approach, the testers use to randomly select few test cases based on their knowledge and experience for conducting the test. In another well known approach, the association of the test cases with the methods is determined by traversing the flow of execution of the test cases. However, all these approaches fail to provide a desired outcome.
SUMMARY
[005] This summary is provided to introduce aspects related to systems and methods for identifying relevant test cases for software testing are further described below in the
3
detailed description. This summary is not intended to identify essential features of subject matter nor is it intended for use in determining or limiting the scope of the subject matter.
[006] In one implementation, a system for identifying relevant test cases for software testing is disclosed. The system comprises a processor and a memory coupled to the processor. The processor may execute a plurality of modules stored in the memory. The plurality of modules may comprise a receiving module, a computing module, a classifying module, an updating module, a generating module, and a determining module. The receiving module may receive an input matrix comprising a plurality of test cases and a plurality of methods associated to a software code. Further, each test case is associated with at least one method of the plurality of methods. The computing module may compute an occurrence percentage metric and a relevancy metric. The occurrence percentage metric may be computed corresponding to each method of the plurality of methods, and the occurrence percentage metric indicates a percentage of the plurality of test cases associated to each method. The relevancy metric may be computed corresponding to each test case of the plurality of test cases, and the relevancy metric indicates a number of methods associated to each test case. Further, the classifying module may classify each method of the plurality of methods into at least one of a first matrix and a second matrix based on a comparison of the occurrence percentage metric with a first predefined threshold. The first matrix comprises a first-set of methods and a corresponding first-set of test cases, and the second matrix comprises a second-set of methods and a corresponding second-set of test cases. Further, the updating module may update the second matrix by disassociating a subset of test cases, from the second-set of test cases in order to generate an updated second matrix, based on comparison of the relevancy metric of each of the second-set of test cases with a second predefined threshold. Further, the generating module may generate a final matrix by consolidating the first matrix and the updated second matrix. Further, the determining module may determine a list of relevant test cases to be considered for the testing of the software code based upon the consolidation of the first matrix and the updated second matrix.
[007] In another implementation, a method for identifying relevant test cases for software testing is disclosed. The method may comprise receiving, by a processor, an input matrix comprising a plurality of test cases and a plurality of methods associated to a software code. Further, each test case is associated with at least one method of the plurality of methods. The method may further comprise computing, by the processor, an occurrence percentage metric and a relevancy metric. The occurrence percentage metric may be
4
computed corresponding to each method of the plurality of methods, and the occurrence percentage metric indicates a percentage of the plurality of test cases associated to each method. The relevancy metric may be computed corresponding to each test case of the plurality of test cases, and the relevancy metric indicates a number of methods associated to each test case. Further, the method may comprise a step of classifying, by the processor, each method of the plurality of methods into at least one of a first matrix and a second matrix based on a comparison of the occurrence percentage metric with a first predefined threshold. The first matrix comprises a first-set of methods and a corresponding first-set of test cases, and the second matrix comprises a second-set of methods and a corresponding second-set of test cases. The method may further comprise a step of updating, by the processor, the second matrix by disassociating a subset of test cases, from the second-set of test cases in order to generate an updated second matrix, based on comparison of the relevancy metric of each of the second-set of test cases with a second predefined threshold. Further, the method may comprise a step of generating, by the processor, a final matrix by consolidating the first matrix and the updated second matrix. The method may further comprise a step of determining, by the processor, a list of relevant test cases to be considered for the testing of the software code based upon the consolidation of the first matrix and the updated second matrix.
[008] Yet in another implementation, a non-transitory computer readable medium embodying a program executable in a computing device for identifying relevant test cases for software testing is disclosed. The program may comprise a program code for receiving an input matrix comprising a plurality of test cases and a plurality of methods associated to a software code. Further, each test case is associated with at least one method of the plurality of methods. The program may further comprise a program code for computing an occurrence percentage metric and a relevancy metric. The occurrence percentage metric may be computed corresponding to each method of the plurality of methods, and the occurrence percentage metric indicates a percentage of the plurality of test cases associated to each method. Further, the relevancy metric may be computed corresponding to each test case of the plurality of test cases, and the relevancy metric indicates a number of methods associated to each test case. The program may further comprise a program code for classifying each method of the plurality of methods into at least one of a first matrix and a second matrix based on a comparison of the occurrence percentage metric with a first predefined threshold. The first matrix may comprise a first-set of methods and a corresponding first-set of test
5
cases, and the second matrix may comprise a second-set of methods and a corresponding second-set of test cases. Further, the program may comprise a program code for updating the second matrix by disassociating a subset of test cases, from the second-set of test cases in order to generate an updated second matrix, based on comparison of the relevancy metric of each of the second-set of test cases with a second predefined threshold. The program may further comprise a program code for generating a final matrix by consolidating the first matrix and the updated second matrix. Further, the program may comprise a program code for determining a list of relevant test cases to be considered for the testing of the software code based upon the consolidation of the first matrix and the updated second matrix.
BRIEF DESCRIPTION OF THE DRAWINGS
[009] The detailed description is described with reference to the accompanying figures. In the figures, the left-most digit(s) of a reference number identifies the figure in which the reference number first appears. The same numbers are used throughout the drawings to refer like features and components.
[0010] Figure 1 illustrates a network implementation of a system for identifying relevant test cases for software testing, in accordance with an embodiment of the present subject matter.
[0011] Figure 2 illustrates the system, in accordance with an embodiment of the present subject matter.
[0012] Figure 3A-3H illustrates detail explanation of working of the system, in accordance with an embodiment of the present subject matter.
[0013] Figure 4 illustrates a method for identifying relevant test cases for software testing, in accordance with an embodiment of the present subject matter.
DETAILED DESCRIPTION
[0014] Referring to Figure 1, a network implementation 100 of system 102 for identifying relevant test cases for software testing is illustrated, in accordance with an embodiment of the present subject matter. Although the present subject matter is explained considering that the system 102 is implemented for identifying the relevant test cases on a server, it may be understood that the system 102 may also be implemented in a variety of
6
computing systems, such as a laptop computer, a desktop computer, a notebook, a workstation, a mainframe computer, a server, a network server, a tablet, a mobile phone, and the like. In one embodiment, the system 102 may be implemented in a cloud-based environment. It will be understood that the system 102 may be accessed by multiple users through one or more user devices 104-1, 104-2, 104-3……104-N, collectively referred to as user 104 hereinafter, or applications residing on the user devices 104. Examples of the user devices 104 may include, but are not limited to, a portable computer, a personal digital assistant, a handheld device, and a workstation. The user devices 104 are communicatively coupled to the system 102 through a network 106.
[0015] In one implementation, the network 106 may be a wireless network, a wired network or a combination thereof. The network 106 can be implemented as one of the different types of networks, such as intranet, local area network (LAN), wide area network (WAN), the internet, and the like. The network 106 may either be a dedicated network or a shared network. The shared network represents an association of the different types of networks that use a variety of protocols, for example, Hypertext Transfer Protocol (HTTP), Transmission Control Protocol/Internet Protocol (TCP/IP), Wireless Application Protocol (WAP), and the like, to communicate with one another. Further, the network 106 may include a variety of network devices, including routers, bridges, servers, computing devices, storage devices, and the like.
[0016] Referring now to Figure 2, the system 102 is illustrated in accordance with an embodiment of the present subject matter. In one embodiment, the system 102 may include at least one processor 202, an input/output (I/O) interface 204, and a memory 206. The at least one processor 202 may be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, state machines, logic circuitries, and/or any devices that manipulate signals based on operational instructions. Among other capabilities, the at least one processor 202 is configured to fetch and execute computer-readable instructions or modules stored in the memory 206.
[0017] The I/O interface 204 may include a variety of software and hardware interfaces, for example, a web interface, a graphical user interface, and the like. The I/O interface 204 may allow the system 102 to interact with a user directly or through the user devices 104. Further, the I/O interface 204 may enable the system 102 to communicate with other computing devices, such as web servers and external data servers (not shown). The I/O interface 204 can facilitate multiple communications within a wide variety of networks and
7
protocol types, including wired networks, for example, LAN, cable, etc., and wireless networks, such as WLAN, cellular, or satellite. The I/O interface 204 may include one or more ports for connecting a number of devices to one another or to another server.
[0018] The memory 206 may include any computer-readable medium or computer program product known in the art including, for example, volatile memory, such as static random access memory (SRAM) and dynamic random access memory (DRAM), and/or non-volatile memory, such as read only memory (ROM), erasable programmable ROM, flash memories, hard disks, optical disks, a compact disks (CDs), digital versatile disc or digital video disc (DVDs) and magnetic tapes. The memory 206 may include modules 208 and data 226.
[0019] The modules 208 include routines, programs, objects, components, data structures, etc., which perform particular tasks or implement particular abstract data types. In one implementation, the modules 208 may include a receiving module 210, a computing module 212, a classifying module 214, an updating module 216, a generating module 218, a determining module 220, an identifying module 222, and other modules 224. The other modules 224 may include programs or coded instructions that supplement applications and functions of the system 102.
[0020] The data 226, amongst other things, serves as a repository for storing data processed, received, and generated by one or more of the modules 208. The data 226 may also include a matrix database 228, and other data 230. Further, each of the aforementioned modules is explained in detail in subsequent paragraphs of the specification.
[0021] Referring now to Figure 3A-3H illustrates detail explanation of working of the system, in accordance with an embodiment of the present subject matter. The present disclosure relates to identification of relevant test cases to be considered for testing a software code. Software testing is one of an important phase in a software development lifecycle. It is generally conducted to check various functionalities of a software program. To check the working of theses functionalities i.e., methods of the software program/software code, a number of test cases are used. With the increase in the number of methods present in the software program, volume of the test cases also increases. This creates a challenge for a software tester to test the software program in a limited time frame. In many cases, the software testers have to randomly choose the test cases, amongst the number of test cases
8
available, based on their experience and knowledge. However, this approach may not provide the desired outcome.
[0022] Thus, to address this concern, the present subject matter discloses a system 102 and method for identifying relevant test cases for the software testing. According to an embodiment of present disclosure, the identification of the relevant test cases is explained, with an example (figures 3A to 3H), in subsequent paragraphs of the specification.
[0023] In a first step, the receiving module 210 of the system 102 receives a plurality of test cases and a plurality of methods in a form of a matrix i.e., an input matrix, as shown in figure 3A. The plurality of test cases and the plurality of methods are associated with a software code to be tested. It can be seen in the figure 3A, that there are ten methods (M1 to M10) and ten test cases (T1 to T10). The input matrix also shows the association and disassociation of the test cases with each method using “Yes” and “No”, wherein “Yes” indicates the association and “No” indicates the disassociation. For an example, for the method M3, only three test cases are associated i.e., T1, T2, and T3. In another example, for the method M1, test cases T1-T8 are associated, whereas, test cases T9 and T10 are disassociated. Further, the input matrix received may be stored in matrix database 228 of the system 102.
[0024] Once the input matrix is received, the computing module 212 of the system 102 computes two metrics i.e., an occurrence percentage metric and a relevancy metric. The occurrence percentage metric is computed corresponding to each method of the plurality of methods by using the below formula:
Occurrence Percentage Metric (OPM) = (Number of test cases associated with a method / Total Number of Test cases) * 100
[0025] Thus, it can be observed from aforementioned formula that the occurrence percentage metric indicates a percentage of the plurality of test cases associated to each method. As shown in figure 3B, the OPM computed for method M1 is 80%, because eight test cases (T1-T8) out of the ten test cases (T1-T10) are associated with the method M1. Similarly, the OPM computed for the method M10 is 20%, because only two test cases (T1 and T10) out of the ten test cases (T1-T10) are associated with the method M10.
[0026] Further, on other hand, the relevancy metric is computed corresponding to each test case of the plurality of test cases by using the below formula:
Relevancy Metric = 1/ Number of Methods associated with a test case
9
[0027] Thus, the relevancy metric indicates a number of methods associated to each test case. Referring again to the figure 3B, it can be observed that that relevancy metric computed for the test case (T1) is 1/10 and for test case (T8) is 1/2. The purpose of computing these metrics is to correctly determine the significance of both, the methods and the test cases associated with the methods. There may be several utility methods (e.g. login method) which might be present in flow of every test case, and therefore, the system 102 may wrongly associate all the test cases with that utility method. Then, whenever the software testing is performed, all the wrongly associated test cases also get executed which eventually leads in wastage of time and effort. Thus, it is important to correctly identify and associate only relevant test cases with their respective methods, thereby eliminating unnecessary test cases while performing the software testing.
[0028] In the next step, the classifying module 214 of the system 102 classifies each of the plurality of methods into a first matrix and a second matrix based on comparison of the OPM of each method with a first predefined threshold. For example, considering the first predefined threshold as 50%, the methods whose OPM is less than or equal to 50% are classified in the first matrix (figure 3C), whereas, the methods whose OPM is more than 50% are classified in the second matrix (figure 3D). Now, the first matrix comprises only six methods M2, M3, M4, M5, M9 and M10 i.e., a first-set of methods and their corresponding first-set of test cases, as shown in figure 3C. On the other hand, the second matrix comprises only four methods M1, M6, M7, and M8 i.e., a second-set of methods and their corresponding second-set of test cases. In other words, it can be said that the methods having their OPM less than or equal to 50% are un-common methods (first matrix – Fig. 3C), whereas, the methods having their OPM more than 50% are common methods (second matrix – Fig. 3D).
[0029] Now, since methods are classified, the system 102 understands that the first-set of methods (i.e., uncommon methods) have more significance than the second-set of methods (i.e., common methods). The system 102 also understands that the association of test cases (i.e., first-set of test cases) with the first-set of methods is highly relevant than the association of the test cases (i.e., second-set of test cases) with the second-set of methods. Therefore, the system 102 revisits the second-set of methods in the second matrix for verifying relevancy of association of the second-set of test cases with the second-set of methods.
10
[0030] Thus, in next step, the updating module 216 of the system 102 updates the second matrix by disassociating a subset of test cases, from the second-set of test cases in order to generate an updated second matrix. The dissociation of the subset of test cases is done by comparing the relevancy metric of each of the second-set of test cases with a second predefined threshold. For example, considering the second predefined threshold as count 2, only two test cases having maximum relevancy metric value is retained in the updated second matrix, and thus, the remaining test cases gets disassociated. However, if two test cases have same relevancy metric value, then both the test cases will be considered. As can be seen from the updated second matrix (figure 3E), that for method M1, the test cases T1, T2, T3, T4, and T6 gets disassociated. Now, only the test cases T5, T7 and T8 are associated with the method M1 because they have maximum relevancy metric value (For T5, the relevancy metric is 1/3; For T7, the relevancy metric is 1/3; and For T8, the relevancy metric is 1/2). Similarly, for the method M6, only the test cases T9 and T10 are associated, and the rest of the previously associated test cases (i.e., T1, T2, T3, T4, and T6) get disassociated. Thus, in the updated second matrix, only the important/significant test cases get associated with the second-set of methods.
[0031] In next step, the generating module 218 of the system 102 generates a final matrix by consolidating the first matrix (Fig. 3C) and the updated second matrix (Fig. 3E). The final matrix generated is shown in figure 3F. From the final matrix, the determining module 220 of the system 102 determines a list of relevant test cases and their association with the plurality of methods. It can be clearly observed by comparing the final matrix (Fig. 3F) and the initial matrix (Fig. 3A), that only two test cases (T7 and T8) are determined to be relevant for the method M1. Thus, only the relevant test cases get associated with the plurality of methods.
[0032] However, based on the consolidation and aforementioned analysis, there may be one or more test case with which no method is associated. Thus, according to embodiments of present disclosure, the identifying module 222 of the system 102 identifies one or more orphan test cases in the final matrix having no method associated therewith. From the figure 3F, it can be observed that the test case (T6) has no method associated with it, and thus, T6 is identified as the orphan test case. However, this orphan test case may be a relevant test case for a particular method. Thus, according to embodiments of present disclosure, the determining module 220 of the system 102 determines a method associated with the orphan test case based OPM of the plurality of methods. The method M8 is
11
determined to be associated with the orphan test case (T6), since the method M8 has the minimum OPM i.e., 60%. In next step, the generating module 218 further generates a revised final matrix by associating the method M8 with the orphan test case (T6). The revised final matrix is shown in figure 3H. Further, the updating module 216 updates the list of relevant test cases based on the revised final matrix i.e., orphan test case (T6) is associated with the method M8 in the revised final matrix.
[0033] Referring now to Figure 4, the method of identifying relevant test cases for software testing is shown, in accordance with an embodiment of the present subject matter. The method 400 may be described in the general context of computer executable instructions. Generally, computer executable instructions can include routines, programs, objects, components, data structures, procedures, modules, functions, etc., that perform particular functions or implement particular abstract data types. The method 400 may also be practiced in a distributed computing environment where functions are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, computer executable instructions may be located in both local and remote computer storage media, including memory storage devices.
[0034] The order in which the method 400 is described is not intended to be construed as a limitation, and any number of the described method blocks can be combined in any order to implement the method 400 or alternate methods. Additionally, individual blocks may be deleted from the method 400 without departing from the spirit and scope of the subject matter described herein. Furthermore, the method can be implemented in any suitable hardware, software, firmware, or combination thereof. However, for ease of explanation, in the embodiments described below, the method 400 may be considered to be implemented in the above described system 102.
[0035] At block 402, an input matrix comprising a plurality of test cases and a plurality of methods associated to a software code may be received. Further, each test case is associated with at least one method of the plurality of methods.
[0036] At block 404, an occurrence percentage metric and a relevancy metric may be computed. The occurrence percentage metric may be computed corresponding to each method of the plurality of methods. The occurrence percentage metric indicates a percentage of the plurality of test cases associated to each method. Further, the relevancy metric may be
12
computed corresponding to each test case of the plurality of test cases. The relevancy metric indicates a number of methods associated to each test case.
[0037] At block 406, each method of the plurality of methods may be classified into at least one of a first matrix and a second matrix based on a comparison of the occurrence percentage metric with a first predefined threshold. The first matrix comprises a first-set of methods and a corresponding first-set of test cases. Further, the second matrix comprises a second-set of methods and a corresponding second-set of test cases.
[0038] At block 408, the second matrix may be updated by disassociating a subset of test cases, from the second-set of test cases in order to generate an updated second matrix, based on comparison of the relevancy metric of each of the second-set of test cases with a second predefined threshold.
[0039] At block 410, a final matrix may be generated by consolidating the first matrix and the updated second matrix.
[0040] At block 412, a list of relevant test cases may be determined to be considered for the testing of the software code based upon the consolidation of the first matrix and the updated second matrix.
[0041] Although implementations for methods and systems for identifying relevant test cases have been described in language specific to structural features and/or methods, it is to be understood that the appended claims are not necessarily limited to the specific features or methods described. Rather, the specific features and methods are disclosed as examples of implementations for identifying relevant test cases for software testing.

WE CLAIM:
1. A method for identifying relevant test cases for software testing, the method comprising:
receiving, by a processor, an input matrix comprising a plurality of test cases and a plurality of methods associated to a software code, wherein each test case is associated with at least one method of the plurality of methods;
computing, by the processor,
an occurrence percentage metric corresponding to each method of the plurality of methods, wherein the occurrence percentage metric indicates a percentage of the plurality of test cases associated to each method, and
a relevancy metric corresponding to each test case of the plurality of test cases, wherein the relevancy metric indicates a number of methods associated to each test case;
classifying, by the processor, each method of the plurality of methods into at least one of a first matrix and a second matrix based on a comparison of the occurrence percentage metric with a first predefined threshold, wherein
the first matrix comprises a first-set of methods and a corresponding first-set of test cases, and
the second matrix comprises a second-set of methods and a corresponding second-set of test cases;
updating, by the processor, the second matrix by disassociating a subset of test cases, from the second-set of test cases in order to generate an updated second matrix, based on comparison of the relevancy metric of each of the second-set of test cases with a second predefined threshold;
generating, by the processor, a final matrix by consolidating the first matrix and the updated second matrix; and
determining, by the processor, a list of relevant test cases to be considered for the testing of the software code based upon the consolidation of the first matrix and the updated second matrix.
2. The method of claim 1, wherein the occurrence percentage metric is computed based on a number of test cases associated with a method and the plurality of test cases.
14
3. The method of claim 1, wherein the relevancy metric is computed based on number of methods, of the plurality of methods, associated with a test case.
4. The method of claim 1 further comprising:
identifying, by the processor, one or more orphan test cases in the final matrix having no method associated therewith;
determining, by the processor, one or more methods associated with the one or more orphan test cases using the input matrix;
generating, by the processor, a revised final matrix by associating the one or more methods with the one or more orphan test cases; and
updating, by the processor, the list of relevant test cases based on the revised final matrix.
5. A system 102 for identifying relevant test cases for software testing, and wherein the system 102 comprises:
a processor 202;
a memory 206 coupled with the processor 202, wherein the processor 202 executes a plurality of modules 208 stored in the memory 206, and wherein the plurality of modules 208 comprises:
a receiving module 210 to receive an input matrix comprising a plurality of test cases and a plurality of methods associated to a software code, wherein each test case is associated with at least one method of the plurality of methods;
a computing module 212 to compute:
an occurrence percentage metric corresponding to each method of the plurality of methods, wherein the occurrence percentage metric indicates a percentage of the plurality of test cases associated to each method, and
a relevancy metric corresponding to each test case of the plurality of test cases, wherein the relevancy metric indicates a number of methods associated to each test case;
a classifying module 214 to classify each method of the plurality of methods into at least one of a first matrix and a second matrix based on a comparison of the occurrence percentage metric with a first predefined threshold, wherein
15
the first matrix comprises a first-set of methods and a corresponding first-set of test cases, and
the second matrix comprises a second-set of methods and a corresponding second-set of test cases;
an updating module 216 to update the second matrix by disassociating a subset of test cases, from the second-set of test cases in order to generate an updated second matrix, based on comparison of the relevancy metric of each of the second-set of test cases with a second predefined threshold;
a generating module 218 to generate a final matrix by consolidating the first matrix and the updated second matrix; and
a determining module 220 to determine a list of relevant test cases to be considered for the testing of the software code based upon the consolidation of the first matrix and the updated second matrix.
6. The system 102 of claim 5, wherein the occurrence percentage metric is computed based on a number of test cases associated with a method and the plurality of test cases.
7. The system 102 of claim 5, wherein the relevancy metric is computed based on number of methods, of the plurality of methods, associated with a test case.
8. The system 102 of claim 5 further comprises:
an identifying module 222 to identify one or more orphan test cases in the final matrix having no method associated therewith;
the determining module 220 to determine one or more methods associated with the one or more orphan test cases using the input matrix;
the generating module 218 to generate a revised final matrix by associating the one or more methods with the one or more orphan test cases; and
the updating module 216 to update the list of relevant test cases based on the revised final matrix.
9. A non-transitory computer readable medium embodying a program executable in a computing device for identifying relevant test cases for software testing, the program comprising:
16
a program code for receiving an input matrix comprising a plurality of test cases and a plurality of methods associated to a software code, wherein each test case is associated with at least one method of the plurality of methods;
a program code for computing
an occurrence percentage metric corresponding to each method of the plurality of methods, wherein the occurrence percentage metric indicates a percentage of the plurality of test cases associated to each method, and
a relevancy metric corresponding to each test case of the plurality of test cases, wherein the relevancy metric indicates a number of methods associated to each test case;
a program code for classifying each method of the plurality of methods into at least one of a first matrix and a second matrix based on a comparison of the occurrence percentage metric with a first predefined threshold, wherein
the first matrix comprises a first-set of methods and a corresponding first-set of test cases, and
the second matrix comprises a second-set of methods and a corresponding second-set of test cases;
a program code for updating the second matrix by disassociating a subset of test cases, from the second-set of test cases in order to generate an updated second matrix, based on comparison of the relevancy metric of each of the second-set of test cases with a second predefined threshold;
a program code for generating a final matrix by consolidating the first matrix and the updated second matrix; and
a program code for determining a list of relevant test cases to be considered for the testing of the software code based upon the consolidation of the first matrix and the updated second matrix.