Description: RELATED ART [0001] Embodiments of the present specification relate generally to the field of software testing and validation systems. More specifically, the present disclosure relates to a validation system and an associated method for intelligent software in loop (SIL) test case selection and execution. [0002] Present day automotive, medical, media, and broadcast devices, home appliances, and other such systems are generally software-defined systems that implement features, functions, and regulatory compliance primarily via software. To that end, such systems employ embedded firmware controlled by electronic control units (ECUs) using associated applications that are continually updated for optimal operation. These systems are extensively used in day-to-day life, thereby significantly affecting the quality of life and safety of end users. Therefore, such systems and associated ECUs need to be exhaustively tested and validated to identify any issues prior to product distribution to minimize any mishaps during product usage. [0003] Typically, ECUs with control software are validated using hardware in loop (HIL) simulation, which requires the target hardware to be available. Issues found at this late stage when the physical ECU has already been manufactured are often complex and incur more money, time, and effort to fix. Additionally, HIL test benches are very costly and limited in number. Therefore, only a limited number of test cases can be executed at a time in the available HIL test benches. In particular, sequential execution of test cases takes a lot of time when there are millions of test cases to be executed with a limited number of test benches. This, in turn, delays the start of production timeline. [0004] Alternatively, software-in-loop (SIL) testing is used whenever a change in software source code is made by a developer. However, the updated version of the software may not be available with the testers immediately for testing. Even if the tester receives information about the changes, the software files may need to be manually updated and re-flashed into the ECU. Additionally, the entire set of test cases may need to be re-executed for even minute changes in the software source code. One of the major drawbacks of manual testing, thus, is the delay with each iteration. The slower feedback loops result in slower changes that start accruing and delay the deployment cycle. [0005] Therefore, certain automated test case selection systems have been explored to optimize the testing and validation time. For example, Chinese patent application number CN102831055A describes a test case selection method based on a weighting attribute. Specifically, the Chinese patent application CN102831055A describes acquiring an execution profile, which is a function sequence called by a test case in an execution process; using a k-means clustering algorithm to cluster the execution profile, and using a strategy based on attribute weight to pick out the test case in each cluster for examination after the clustering, and selecting the test case which is most likely to fail. Specifically, the Chinese patent application CN102831055A describes selecting a test case with the largest suspicious value from clusters obtained using k-means clustering algorithm. The suspicious value of the test case appears to be calculated based on a pass/fail status of the test case. [0006] Additionally, the Chinese patent application CN102831055A describes using a fixed percentage of clusters, and selecting one test case per cluster that has the highest suspicious value. Accordingly, a fixed number of test cases will be selected for each execution regardless of a pass or fail ratio of the test cases or associated function weight. Consequently, several test cases of low relevancy may be selected for subsequent execution leading to inefficient testing that incurs significantly longer testing times and system resources. [0007] Therefore, there exists a need for a method and a system which overcomes the above-mentioned problems. In particular, it may be desirable to develop a system and method for automatically and intelligently identifying and executing impacted test cases early in the development life cycle, thereby reducing the cost of testing and time required for testing, and validation of ECUs and associated applications. BRIEF DESCRIPTION [0008] The present disclosure overcomes one or more shortcomings of the prior art and provides additional advantages discussed throughout the present disclosure. Additional features and advantages are realized through the techniques of the present disclosure. Other embodiments and aspects of the disclosure are described in detail herein and are considered a part of the claimed disclosure. [0009] In one non-limiting embodiment of the present disclosure, method for testing a source code of a product is disclosed. The method comprises identifying one or more changes made to one or more functions of the source code of the product by comparing a first set of codes related to the one or more functions in a first version of the source code with a second set of codes related to the one or more functions in a second version of the source code. Said method further discloses determining a function-weight for each of the one or more functions comprising the one or more identified changes. The function-weight of each of the one or more functions is determined based on a normalized change factor associated with a corresponding function, a weight assigned to each type of the one or more changes made in a code related to the corresponding function, and a total number of types of changes made to the code related to the corresponding function. Further, said method discloses comparing the function-weight of each of the one or more functions with a test case weight of each of a plurality of test cases associated with the one or more functions of the source code. Finally, said method discloses automatically testing, by the test case selection system, the source code based on the selected subset of test cases. [0010] In another non-limiting embodiment of the present disclosure, the normalized change factor associated with a corresponding function is determined based on a number of lines in the first set of codes and a number of lines in the second set of codes. [0011] In yet another non-limiting embodiment of the present disclosure, for automatically testing the source code, the method comprises generating a test result for each of the selected subset of test cases based on a corresponding testing, the test result for each of the selected subset of test cases is indicated as pass or fail and storing the generated test result in a test report database. [0012] In yet another non-limiting embodiment of the present disclosure, the method comprises determining a change in the test result of each of the plurality of test cases, wherein the change indicates a change in the test result as one or more of changing from pass to fail and changing from fail to pass, identifying a type of change in the code that caused the determined change in the test result, and updating a weight of the identified type of change in the code based on a frequency of change in one or more functions present in the second version of the source code, a frequency of change in one or more functions present in the first version of the source code, a weight previously assigned to the identified type of change, and a number of digits in the frequency of change in one or more functions present in the second version of the source code. [0013] In yet another non-limiting embodiment of the present disclosure, the method comprises determining the test case weight for each of the plurality of test cases of the source code, the test case weight for each of the plurality of test cases being determined based on a code coverage of a respective test case and a priority value assigned to the respective test case. [0014] In yet another non-limiting embodiment of the present disclosure, the method comprises determining a pass rate of each of the test cases based on a number of tests passed by the respective test case and updating the test case weight of the respective test case based on the pass rate of the respective test case, a code coverage of the respective test case, and a priority value assigned to the respective test case. [0015] In yet another non-limiting embodiment of the present disclosure, for identifying the one or more change in the one or more functions, the method comprises identifying at least a change in a logic, a line modification, a modification of a function call, a change in return data, or a change outside function. [0016] In yet another non-limiting embodiment of the present disclosure, a test system for testing a source code of a product is disclosed. The test system comprises a memory and a processor coupled to the memory. The processor is configured to identify one or more changes made to one or more functions of the source code of the product by comparison of a first set of codes related to the one or more functions in a first version of the source code with a second set of codes related to the one or more functions in a second version of the source code. The processor is further configured to determine a function-weight for each of the one or more functions comprising the one or more identified changes. The function-weight of each of the one or more functions is determined based on a normalized change factor associated with a corresponding function, a weight assigned to each type of the one or more changes made in a code related to the corresponding function, and a total number of types of changes made to the code related to the corresponding function. The processor is further configured to compare the function-weight of each of the one or more functions with a test case weight of each of a plurality of test cases associated with the one or more functions of the source code and select a subset of test cases from the plurality of test cases whose corresponding test case weights are greater than the function-weight of at least one of the one or more functions of the source code. The processor is finally configured to automatically test the source code based on the selected subset of test cases. [0017] In yet another non-limiting embodiment of the present disclosure, the processor is configured to identify at least a change in a logic, a line modification, a modification of a function call, a change in return data, or a change outside function to identify the one or more change in one or more functions. [0018] In yet another non-limiting embodiment of the present disclosure, the test system is implemented in at least one of an automotive, defense equipment, consumer electronics, mobile devices, cloud communication apparatus, networking device, electronic control unit, telecommunications network, industrial robot, Internet of Things (IoT) devices, media device, and medical system. [0019] The foregoing summary is illustrative only and is not intended to be, in any way, limiting. In addition to the illustrative aspects, embodiments, and features described above, further aspects, embodiments, and features will become apparent by reference to the drawings and the following detailed description. BRIEF DESCRIPTION OF DRAWINGS [0020] These and other features, aspects, and advantages of the claimed subject matter will become better understood when the following detailed description is read with reference to the accompanying drawings in which like characters represent like parts throughout the drawings, wherein: [0021] FIG. 1 shows an exemplary environment for testing a source code of a software-enabled system, in accordance with an embodiment of the present disclosure; [0022] FIG. 2 illustrates an exemplary system architecture for test case selection and testing, in accordance with an embodiment of the present disclosure; [0023] FIG. 3A shows an exemplary tree diagram indicating functions in a source code, in accordance with an embodiment of the present disclosure; [0024] FIG. 3B shows an exemplary tree diagram indicating changes made in the source code, in accordance with an embodiment of the present disclosure; [0025] FIG. 3C shows an exemplary tree diagram indicating change in interlinked function weight due to changes in the source code, in accordance with an embodiment of the present disclosure; [0026] FIG. 4 shows a block diagram of a system for testing a source code in an automotive application environment, in accordance with an embodiment of the present disclosure; and [0027] FIG. 5 shows a flow chart illustrating an exemplary method for testing a source code of a product, in accordance with an embodiment of the present disclosure. DETAILED DESCRIPTION [0028] The following description presents an exemplary testing and validation system and method for intelligent SIL test case selection and execution. Particularly, embodiments described herein disclose a system and a method for automatically and intelligently identifying and executing test cases impacted by the changes made to source code of an application or a product that controls one or more aspects of a software-based system. [0029] To that end, the present method includes identifying one or more changes made to one or more functions of the source code of a product, determining a function-weight for each of the functions comprising the identified changes, and comparing the function-weight of each of the functions with a test case weight of each of a plurality of test cases associated with the functions of the source code. The method further comprises selecting a subset of test cases from the plurality of test cases whose corresponding test case weights are greater than the function-weight of at least one of the functions of the source code and automatically testing the source code based on the selected subset of test cases. More specifically, the present method filters functions based on relevancy of change in corresponding code between two different versions of the source code files and a specified expression that accurately defines a relation between function weight and test case weight, thereby allowing for selection of fewer, but more relevant test cases. [0030] It may be noted that different embodiments of the present testing and validation system and method may be used in different application areas for optimizing testing and deployment timelines. For example, the present testing and validation system and method may be used in automotive industry to test and validate critical functioning of an advanced driver-assistance system (ADAS) that includes technologies to assist drivers with the safe operation of a vehicle. The ADAS is generally operated using sensors, ADAS controller, and actuators. The ADAS controller collects data about the environment using the sensors, implements perception, and tracks the sensor input data to implement various control algorithms like Autonomous Emergency Braking (AEB), Adaptive cruise control (ACC), and Battery Management System (BMS). Further, the ADAS uses the actuators to physically control the vehicle's acceleration, brake, and/or steering. The ADAS controller, normally implemented inside the ADAS electronic control unit (ECU), is a combination of software algorithms, for example, related to perception, tracking, and functional features (such as AEB and ACC). These algorithms may be implemented using thousands of source code files in [.]c, [.]h format. These thousands of source code files are subsequently tested using thousands to millions of test cases. [0031] Typically, ADAS application software source codes are updated every two weeks. However, a test engineer requires multiple months of time to review, identify, and execute relevant test cases to ensure safety and operational efficiency of the updated ADAS source codes when deployed within the automobile. For example, even a minor update to a tracking or perception algorithm modifies behaviour of ACC and/or AEB. Therefore, even for minor updates, the test engineer is required to spend a significant amount of time to ensure that the minor update does not adversely affect any of the other critical automotive functions as this may lead to fatal consequences. Hence, the test engineer often executes the entire test suite, which sometimes takes months of time, delaying the development cycle, and deployment of the updated ADAS functionality in actual vehicles. [0032] Hence, it is desirable to have a system and method for automatically and intelligently identifying and executing test cases impacted by such minor changes which occurs at regular intervals to ensure safety and operational efficiency, thereby reducing the cost and time required for testing and validation of ECUs. Accordingly, the embodiments described herein present an efficient method that allows for intelligent selection of test cases to adequately cover the risk affecting critical functions in the system and ensures that all test cases related to the most relevant and critical functions are covered, while reducing an amount of time needed to test and deploy any incremental or significant changes made to the source code. [0033] It may be noted that the present testing and validation system and method may similarly be used to test and validate associated features and functions in medical, media and broadcast devices, home appliances, and other software-defined systems. However, for clarity, an embodiment of the present testing and validation system and method is described subsequently with reference to FIGS. 1-5 in the context of an automotive test and validation system. [0034] FIG. 1 depicts an exemplary environment 100 for testing a source code of a product, in accordance with an embodiment of the present disclosure. In one non-limiting aspect, the product may include an application, software program/code, or an electronic control unit (ECU) implementing the software program/code. However, the product is not limited to above examples and any other product that may include a source code is well within the scope of the present disclosure. [0035] Further, in one embodiment, the exemplary environment 100 for testing the product source code may be implemented in media devices such as set top box, which is used for streaming digital content to televisions and other media devices. The set top box may include thousands of source codes for implementing various functions, for example, including operating system, hardware abstraction layer, security, payment tracking, signal strength boosting, and media management. These source codes interact with each other to provide a smooth and intuitive viewing experience to the end user. However, a minor change in a subset of source codes may affect many other source codes due to related function/API calls existing amongst them. Executing all the test cases such scenarios may consume months of time, during the course of which multiple similar software updates would have become due. [0036] Similarly, in an alternative embodiment, the exemplary environment 100 for testing the source code may be implemented in medical devices such as electronic defibrillators, automated infusion pumps, electronic blood pressure sensors, medical imaging equipment such as X-ray, ECG, EEG, MRI, CT, and ventilators. Here again, even minor changes in a subset of source codes may have significant implications to patient health and safety, and therefore, require quick yet thorough testing and validation before deploying the medical devices for use with actual patients. [0037] Accordingly, in an aspect of the present disclosure, the environment 100 may comprise a developer system 101, a test case generation system 103, a test case selection system 105, and a test case execution system 107 communicatively coupled with each other. In certain embodiments, the developer system 101, the test case generation system 103, the test case selection system 105, and the test case execution system 107 may include and may be implemented by suitable code on a processor-based system, such as a general-purpose or a special-purpose computer. Furthermore, these systems (101, 103, 105, 107), for example, may include one or more general-purpose processors, specialized processors, graphical processing units, microprocessors, programming logic arrays, field programming gate arrays, integrated circuits, systems on chips, and/or other suitable computing devices. [0038] The developer system 101 may be used for software development. Software development may comprise creating, designing, deploying and supporting software. The software may be system software to provide core functions such as operating systems, disk management, utilities, hardware management and other operational necessities. The software may be an application (application software or apps) to help users perform tasks. Office productivity suites, data management software, media players and security programs are examples. Applications also refer to web, cloud-based and mobile applications. In one non-limiting aspect, the software may be embedded system software that is used to control machines and devices such as electronic control units, telecommunications networks, cars, industrial robots, Internet of Things (IoT) devices, and medical systems. [0039] The developer system 101 may be configured to generate, create, or develop a source code suitable for above mentioned systems to run and function. The source code may comprise fundamental components, for example, in the form of functions, descriptions, definitions, calls, methods and other operational statements. The number of lines in the source code may vary based on the application or functionality of product for which source code is written. [0040] In one embodiment, the developer system 101 is communicatively coupled to the test case generation system 103 that is configured to receive the source code from the developer system 101. The test case generation system 103 may build test suites for detecting error in functionality or for verifying the functionality of the product. The test suite may comprise a plurality of relevant test cases for the source code bundled together. In one non-limiting aspect, the test cases may be manually defined by the developer of the system or application for finding bugs in a system or application. In another non-limiting aspect, the test case generation may be automated. The test cases may also be generated through a back-end data injection approach or a third-party tool. However, the test case generation technique or approach is not limited to the examples mentioned previously, and any other test case generation technique or approach is well within the scope of present disclosure. [0041] Further, the test case generation system 103 may be configured to share the generated test cases with the test case execution system 107, which executes the plurality of test cases generated to test the source code of a product for errors. The test case execution system 107 may initially execute all test cases generated by the test case generation system 103. However, the test case execution system 107 need not execute all test cases when one or more changes are made to the source code. Instead, the test case execution system 107 only executes the relevant test cases which are affected by the changes made to the source code. [0042] To that end, the test case execution system 107 is operatively coupled to the test case selection system 105 that intelligently selects one or more relevant test cases from a plurality of generated test cases. As previously noted, certain conventional test case selection approaches employ regression testing and test logs and select all test cases that may have failed and their related test cases for a subsequent testing. Regression testing is time and resource consuming as the testing is done with the aim of increasing code coverage, and hence the frequency of testing is very high even for small changes in code. Additionally, conventional testing may not consider the type and magnitude of changes made to the source code and a priority and weightage of the test cases or associated functions to identify the most relevant test cases for execution. [0043] In contrast, the present test case selection system 105 selects one or more relevant cases based at least on a function weight of functions which are affected by the code change and test case weight of the plurality of the test cases. For example, if a function undergoes a very small change and the test case related to the function has less weightage, then the test case is not given much priority for execution. Whereas, if there are major changes made to the source code in a particular iteration, the test cases related to the major changes are assigned higher priority. However, if a function undergoes a significant change and the test case related to the function has less weightage, then the test case is given low or moderate priority for execution based on the type and magnitude of change made to the source code. Thus, the weight assigned to the function indicates the importance of a function in the code. The function weight calculation and the test case weight calculation are discussed in detail in the following sections. Additionally, selection of suitable test cases for execution is also discussed in detail in the following sections with reference to FIG. 1. [0044] The present test case selection system 105 employs an intelligent mechanism, which selects the most relevant test cases based on the recent change in the source code, without mandating a need for training or testing of a huge historical data set. Thus, the test case selection system 105 efficiently reduces the cost of testing and time required for testing by selecting the relevant test cases. The test case selection system 105 also minimizes the computational power and the storage requirement which is used for storing test results log. [0045] FIG. 2 illustrates an exemplary system architecture 200 for test case selection and testing of a source code of a product, in accordance with an embodiment of the present disclosure. In one embodiment, the system architecture 200 includes a Code Integration/Code Development (CI/CD) pipeline 210, a test case execution system 220 and a test case selection system 230 in communication with each other. The test case selection system 230 may be similar to the test case selection system 105 and the test case execution system 220 may be similar to the test case execution system 107, as discussed with reference to FIG. 1. The system architecture 200 facilitates relevant test case selection and testing when one or more changes are made to the source code of a product. [0046] The CI/CD pipeline 210 may further comprise a developer system 211 that may make changes to the source code of an application/product to add new features, or update existing features based on a planned product development approach and/or feedback received from potential users and other stakeholders. The feedback may comprise a report of errors/bugs, a list of new features, and/or desired feature modifications. In one non-limiting aspect, the report may comprise list of modifications required to be made in the source code of the product for improvement. [0047] The CI/CD pipeline 210 may further comprise a source code management (SCM) unit 212 that is used to track modifications to a source code repository. The SCM unit 212 may be configured to review the changes made to the source code. The CI/CD pipeline 210 may also comprise an automation server 213 configured to fetch the code from the SCM unit 212 and build the code, for example, using a Cron job. Automation server 213 may help to save time by automatically scheduling and building code from SCM. However, the components discussed here are exemplary and any other building tool is well within the scope of the present disclosure. [0048] The CI/CD pipeline 210 may further comprise a dockerization unit 214 configured to package the application/source code in a Docker image to run in one or more containers. The packaging typically involves specifying everything needed to run the application in a Docker file and then using the file to build a specialized Docker image that can be shared to multiple machines. [0049] The CI/CD pipeline 210 may further comprise docker hub 215 configured to push the latest docker image to the test case execution system 220, for example, hosted on a cloud/server (not shown). The docker image may then be used to execute a plurality of test cases on the cloud/server. In one non-limiting aspect, the cloud/server may have virtual machines for executing the plurality of test cases parallelly. For example, the test case execution system 220 may comprise a plurality of virtual electronic control unit (vECU) instances 1, 2, 3, …, N. In one non-limiting aspect, the plurality of virtual electronic control unit instances 1, 2,3, …, N may be remotely present in the cloud. [0050] In one embodiment, the test case execution system 220 may be configured to receive the docker image file from the CI/CD pipeline 210. The test case execution system 220 may also receive the plurality of test cases from a tester or an associated test case scheduling platform that is operatively coupled to the test case execution system 220. In one non-limiting aspect, the plurality of test cases may be generated by a test case generation system and may or may not be customized by the tester manually. The test case execution system 220 may subsequently run or execute the plurality of test cases parallelly on the plurality of vECU instances. The results of the execution may be saved in the test case log 221. In one non-limiting aspect, the plurality of test cases received by the test case execution system 220 may be stored in the test case log 221. [0051] However, running/executing all the test cases even for a small change to a portion of the source code may lead to large execution time and increased cost of testing. Further, the test case execution system 220 may require a large amount of storage for keeping the log of all the test case result. In order to address the above-mentioned problem, the test case selection system 230 may be configured to intelligently select only the relevant test cases of the plurality of test cases which are affected by the one or more changes made to the source code of an application/product. [0052] To that end, the test case selection system 230 may include an identification unit 231, a determination unit 232, a comparison unit 233, a selection unit 234, and a weight modification unit 235 communicatively coupled to each other. The identification unit 231, the determination unit 232, the comparison unit 233, the selection unit 234, the weight modification unit 235 may comprise the necessary computing and storage components/circuitry for performing the functionality described herein. [0053] In one embodiment, the identification unit 231 may be configured to compare a first set of codes related to the one or more functions in a first version of the source code with a second set of codes related to the one or more functions in a second version of the source code to identify one or more changes made to the source code. The one or more changes may comprise a change in logic, a line modification, a modification of a function call, a change in return data, or a change outside function. The one or more changes are made to the first version of the source code to update the functionality of the product or to fix any issues in the functionality of the product. In an aspect, the comparison may involve function by function comparison or line by line comparison of the first set of codes related to the one or more functions in the first version of the source code with the second set of codes related to the one or more functions in a second version of the source code to identify changes in source code. [0054] Once the one or more changes made to the one or more functions are identified, the determination unit 232 may be configured to determine function weight (FW) for the one or more functions in which the one or more changes are identified. The function weight of a function may be calculated, for example, using the following equations (1) and (2): FW= (?X1?^(1/y1)+?X2?^(1/y2)+?X3?^(1/y3)+?+ ?Xn?^(1/yn))/n (1) X= (abs(V-v))/max??(v,V)? (2) [0055] In equations (1) and (2), FW represents the function weight; X1, X2, X3, … , Xn represent the normalized change factors; Y1, Y2, Y3, … , Yn represent the weights (Enum Weights) for each type of change, as mentioned in the following Table 1; v represents number of lines in previous first (old) version of source code; and V represents number of lines in the present second (new) version of source code. [0056] The following Table 1 provides exemplary Enum description and corresponding Enum weight information. As used herein, the term Enum is used to describe a key value type and the Enum weight is representative of a magnitude of change in the function. [0057] Table 1 – Enum Description and Weight Enum Description (Type of Change Description) Weight Line Addition Y1 Line Removal Y2 ... Yn Table 1 [0058] In one non-limiting aspect, the weights (Enum Weights) Y1, Y2, Y3, … , Yn for each type of change are predefined by the developer. The weights (Enum Weights) Y1, Y2, Y3, ..., Yn may be updated by the weight modification unit 235 while testing the source code when one or more changes are made to the source code. [0059] The function weight determination may be understood based on the below examples. E.g. (1): If 10 lines are added newly to a function having 13 lines of code. Assuming y1 = 0.43. X1 = (23-13)/23 = 0.434 and the FW = 0.434^(1/0.43) = 0.143 E.g. (2): If 10 lines are removed from a function having 13 lines of code. Assuming y2 = 0.5 X2 = (10)/13 = 0.769 and the FW = 0.769^(1/0.5) = 0.591 [0060] Considering the above-mentioned examples, where 10 lines are removed and 10 new lines are added to a function having 13 lines of code, the FW value is calculated by averaging both operation’s function weights using equation (1): FW = (X1^(1/Y1) + X2^(1/Y2)) / 2 FW value = (0.143 + 0.591) / 2 = 0.367 [0061] The determination unit 232 may also be configured to determine test case weight (TCW) for each of the plurality of test cases created/generated for testing the source code of the product. The determination unit 232 may also be configured to determine test case weight for a test case using the below equation: TCW= C^(P.r) (3) where, C is code coverage of a test case in the source code and C?{0,1}; P is priority or importance value assigned to a test case and P?{0,1}; r is the pass rate and r?{0,1}. Code Coverage (C)=(no. of lines executed in code for running the test case)/(total lines in the source code) (4) Priority value (P)=(Priority level assigned for the test case)/(total number of priority levels) (5) Pass Rate (r)=(no.of passes)/(total no.of execution) (6) [0062] The test case weight determination may be understood based on the below example: E.g. (1): C=0.45, Priority level =1, pass rate is initially take as 1, and the number of priority levels are 10 and 10 represents the least priority. Thus, the priority value (P) = 1/10= 0.1. TCW= 0.45^0.1=0.923 E.g. (2): C=0.9, Priority level =8, pass rate is initially take as 1, and the number of priority levels are 10 and 1 represents the highest priority. Thus, the priority value (P) = 8/10= 0.8. TCW= 0.9^0.8=0.92 [0063] Furthermore, in one non-limiting aspect, an addition of new function comes with addition of new test cases and their test case weights. [0064] The comparison unit 233 may be configured to compare the function-weight of each of the one or more functions (where changes are identified) with a test case weight of each of a plurality of test cases associated with the one or more functions of the source code. The selection unit 234 may be configured to select a subset of test cases from the plurality of test cases whose test case weight is greater than the function weight of the one or more functions. [0065] The selected subset of test cases may be then forwarded to the test case execution system 220 for testing the second version of source code for failure. The test case execution system 220 may be configured to execute the selected subset of test cases to generate test result for each of the selected subset of test cases. The generated test results may comprise a pass or fail result. The generated result may be stored in the test case log 221. Thus, the selective execution of the test cases facilitates reduction in time required for testing the source code of the product/application. Further, the selective execution of the test cases reduces the test log utilization and reduces the computational power required for execution of the test cases. In one non-limiting aspect of the present disclosure, the tested source code, after meeting the requirements, can then be passed to a HIL simulator support where the final source code can be executed to test its applicability. [0066] In certain embodiments, the weight modification unit 235 may determine a change in the test result of each of the plurality of test cases during the testing of the source code. If the test result changes from pass to fail or from fail to pass, the reason or the cause which leads to such change in test result is identified. The reason or the cause may be a particular type of change being made to the source code. In one non-limiting aspect, the reason or the cause for such change, for example, may include, a change in logic, a line modification, a modification of a function call, a change in return data, or a change outside function. [0067] In an aspect of the present disclosure, the weight modification unit 235 may update a weight of the identified type of change in the code based, for example, on the following equation (7): W_new= {(W_old+(2.N_new.W_old)/(?10?^n (N_new+N_old)); if N_new>N_old W_old-(2.N_new.W_old)/(?10?^n (N_new+N_old )); if N_new Function 3 … 0.42 2 Function 345- > Function 3 -> Function 1 … 0.66 3 Function 3 … 0.02 … … … … 100 Function 2 -> Function 1 … 0.26 Table 4 [0076] In one non-limiting example, the test cases that satisfy the following equation (8) may be selected: ?_(n=1)^N?F_(n )^T (1- F_n )(1-TCW)