 And then software testing unit 2, this will be the last session of unit 2 and we study about some of the white box testing techniques and understanding of testing aspects. In the previous session we studied about gray box testing which is nothing but a mix of white box as well as black box test where tester has the knowledge about internal details of the system as well as the system knowledge with the help of that and you will do the testing. This is actually very effective when it is coupled with error guessing where with the help of the system knowledge he will just work out of errors could come. This is particularly useful when we have a stable system working with a legacy code and there are certain changes or new functionality has been added to the removal system. Also we studied about test driver and test log which is very important part of the embedded software testing. Test driver is software which executes software in order to test it providing a framework for setting input parameters executing the unit and trading the output parameters. So basically test driver will invoke test which want to test it that is also a software piece with whatever the values that we want to provide as inputs and expect the outputs. Test hub is a replacement of the existing unit so this is used in place of the real input to facilitate the testing. So this is the framework that is being used for test hub and test driver this is called test bench or test bench basically so the unit is being used as a test driver and unit can be replaced with the help of a test hub. So test hub and drivers are part of the test bench and the unit will be subjected to test. Coming to the various aspects of the tools that are used in white box testing basically they use for coverage purposes and we have studied about commercial tools such as the vector cast for covering, for getting the reports of the coverage and we also went through LDRU which is from LDRU.com and IBM RTIT which has facility for doing the test hubs building the executable from the target and generating the reports. So we studied about logic and network which will help in recording the memory activity in a real time or on the ground and records the changes and the updates that are happening in the ML software. It basically captures the events that are happening and it is called a trace which is particularly useful for interrupt based applications where more inputs are there and the frequency of interrupts are more. Also we had a study about software performance analyzers, the performance could be from memory, timing and load, speed etc. So performance testing and tuning is very important aspect because that will drive the functionality and especially if the software has to be upgradable or maintainable so the performance has to be absolutely right then only we can do the rest of the testing. So this is very important aspect but sometimes in the industry this will be taken as a last priority but as per me this should be a topmost priority for doing the embedded software testing. Also there are various types of memory testing we do so especially they look for the memory usage, how the memory is being used in the embedded software system and there is a map file and the map file will be detailed in terms of how much stack, how much constants are using, what is the size of the RAM, what is the size of the flash etc. And for testing each of these memory parts within the embedded software basically the software itself will have a key and it will be keep on checking in every 6 to intervals or cycles of the system life and the reports will be generated or hooked with the external tool to get the data and that will be analyzed. So basically the RAM, the memory flash will be checked with the help of integrity test, integrity test could be working ones or pattern test, NEM also will be tested with the help of pattern test or working on test where the eSquare problems are used for fault or a common storage and the timing analysis we can do with the help of integrated development or normal with the help of debuggers we can analyze and various events that are happening with respect to time and as a black box so if you want to test it you may have to use ports if it is available within the embedded system and those ports can be scoped using the oscilloscope and oscilloscope will be analyzed with respect to the plotted graph of timing with respect to various events also the embedded system has registers with respect to time such as RTC, watchdog etc those will be used as well in terms of analyzing time. Also we went through the testing tools life cycle how the life cycle has the life cycle can be used with respect to the tools so we have a planning and control of the entire testing life cycle which has preparation, specification, completion. So preparation we have tools such as case tool, analyzer, complexity analyzer, first specification we have this case generation, first case sender top which has a lot of pattern scripts or access sheet programming from the requirements and also we have the execution in terms of test data generator, simulators, debuggers, whatever we have studied so far one of them or many of them could be used for execution purpose and we have the completion and reporting mechanism of the executed parts. For planning and control we use defect management and test management, accessibility etc with respect to the requirements you know testing. Defect management we have depending on the size of the project, the type of defect complexity and all that will be managed with the database and all that they will be used in order to get the report of the defects as well as the requirements disability and in terms of test scheduling and all that they use different types of tools such as MPP and test link, bug zilla, whatever it is can be used in addition to the scheduling. This will help test management and progression of the inmates of testing, test case preparation specification then with the help of case tool analyzer, complexity analyzer, test case generators for specification they use it, execution we have seen, stops and drivers, simulators, emulators, debuggers, static code, analyzers, performance analyzer, timing analyzers, code code analyzers are used, these are all basically used in white box testing as well as black box testing, okay. In today's session we will study more about the white box method how they are getting implemented and how they can be executed and in what way we can automate it, so basically test automation is a process or a test method or whatever testing aspects that can be applied for testing the embedded software. So basically test automation is used to minimize the time needed for test execution, so why we need test automation is we will keep on doing the embedded software testing again and again and similar requirements, similar set of applications, so we need to have a common framework and the common framework will drive the entire system to test and we will feed the values with respect to each test cases and that is why the test framework along with execution test automation is useful. So automation is very profitable in terms of time, money and quality but it needs a initial investment of time, one time once it is done the framework is available so it is very easier to maintain as well as run the test automatically, so very less human intervention is required in terms of testing and also it can be used to repeat the occurrences of test procedures that means so multiple test of similar procedures we do not need to do it manually we can do a batch processing batch automation it is also called as, so test automation will help in doing these things where multiple procedures are to be executed in a batch and some tests such as statistical usage also can be done with the test automation, testing and evolutionary algorithms are impossible without this automation that means there are certain things which are for repetitive nature so algorithms which keep changing we have a set of data and there are fixes and we may have to do regression, so we cannot afford to have a manual effort again and again spend on that so in that way it is very useful to have test automation. So basically in principle the execution of almost every test can be automatically depending on type of test in practice so only a small part of the test are automated in depending on the project again but the automation will be done most of the requirements where similar functionality or a group of functionality can be tested with various input or multiple test cases are being executed. So basically test automation is often used in different situations where tests that have to be repeated many times a basic test with a huge range of inputs are there the same steps have to be every time with different data very complicated or error-prone test that means we have a piece of software having more errors and all that and every time different errors are coming so it is better to automate it so that the minimal human intervention is used for that so this is very useful for complicated tests. But testing requires specialized equipment which will generate the appropriate input signals at your system and capture the output and analyze the output, analysis can be done manually or the tool itself can be used in terms of analyzing it, so continuation of test automation so we can have the control of test automation in respect to changes in the system design and requirements are common and are also threat to the usability of the automated test. So what will happen is we have test automation completely for the software and the requirements sometimes the changes or the fixes that could happen to the system or the tests that are going to be applied for the system so the consequences of those changes could be changes on test cases additional test cases are added with the different aspects, when different results checks are there and the framework has some impact in terms of modifying it, system interface has changed there is a change in functionality so signals have changed target platform is different from one build to another build there are different hardware bolts different version is being used then there is a possibility that automation may fail or collapse so control of the test automation is very important you should have scalability of the test automation also automation equipment or tools that are developed should be more generic than specific so that it is very maintainable and all the specified consequences of changes will have a less impact on modifying the test automation updates and regressions. So basically automated testing saves money and time and quality will be better because less human intervention is there depending on the system and the tools or the framework is stable once you make it it is expected to behave the same way so chance of injecting errors by the user is very less and several times that test can be reproducible so this is also very important reproducibility of the test execution, pass, fails etc is easier with the help of test automation. So this means that the automated test should be used for consecutive releases or in different stages of development that means the same sort of a automation should be able to use the different releases of the software build and the equipment sorry the embedded target could be so which also means that the automated test have to be designed to deal with these uncertainties due to change in the system these are some problems. So we will see how automation test can be implemented technically in a nutshell basically we will try to understand that and automation test basically being developed in house with the help of commercial tools basically that are available in the market and of course those tools have to be full proof and should be qualified especially in the industries of automotive and aerospace so very important because it has to be reliable and we need to produce the consistent results all the time. So then also we will study about how the process of introducing automation testing and similar development process such as requirement requirement and maintenance okay. So test automation techniques automated testing executing test using an automated test suit so there is a test suit that will be used which will be executed for testing the specific software base test suit everything necessary to execute a test by pushing just one button ideally there should be that actually test suit will be triggered and it will take care of all controlling picking the data signals and the driving values and getting the results analyzing it reporting as pass or fail is all part of the test suit then the test automation should be data driven an approach where physical test actions are separated from test data and the test data is the impulse for the test this should be data driven and this should be a framework in the end where a library of reusable models and as you see test types and drivers they should be reusable for many parts of the system so test types test drivers then common templates it is it could be a minimum sequences in specially I have seen lab view and simulink so very important the sequences the minimum templates they develop it and they can use it as a plug and play for wherever they want to use it in the complete automated testing system so there is a test suit test suit will use this framework for the need of that particular test so to maximize the maintainability and ease of use so some decisions design decisions are to be made to avoid a test suit from becoming where it is designed to be as independent as possible of changes so that the framework can be used so it is very important to have a test suit and the system connectivity and the tests that are having data driven also very important in terms of identifying the approach for the underneath framework so generically the framework is developed to avoid the huge dependency basically whereas the dependency is there will try to minimize as much as possible so that the framework is generic and the framework can be used across multiple functionality of the pieces of the software under the test so design for maintainability test data is stored in continuation of the test automation technique we have a test suit data driven framework then for maintainability purposes test data is stored outside the test suit the description of the test actions is separated from the technical implementation of these actions I will show you a diagram which is easy to understand with the help of that you can understand this description the process of how to handle an automated test is implemented independent of its environment and system under test this explains why any test suit needs several essential components that essential components could be a test data and the framework and the test actions inbuilt in the test suit the communication between the system under test and the test suit is implemented independent of the central process of the test suit we can see a example test and test automation environment how it is going to look like so it is just a depiction so it does not mean that the same thing is used in a nutshell the system that is going to be tested is here is the system and we have a repository of test cases so all the test cases will have a database spreadsheet whatever it is that will be picked by the automation tool it will pick up that and it will run on the system and it will generate the result basically this is the workflow where all the actions checks comparison all will be done with the help of this test automation tool and the data is stored outside all the data test cases those things so we know that the framework is part of this framework will pick up the test cases and it will apply the databases as the inputs and it will execute on a target here and as a result of that it will generate the report as a outcome of the test in a spreadsheet of excel sheet of X document or the logging whatever is required of course also it will use the facility for the entry cases of the embedded systems such as debuggers and all that everything can be automated with the help of the automation tool even the invoking of ID debuggers analyzers logic analyzers or scope also can be triggered with the help of this automation all this we need we know that so if you automate it will be easier for us to maintain and design the testing aspects so the testing is done this is particularly useful where we have a complex embedded software system so another variant of okay so test case are stored outside the test suite outside the test suite here they can store database in the spreadsheet here and this case means only test case the storage of the test case so if there is any additional test case we want to do we do not have to change anything on this side only you have to add the repository or delete or modify whatever it is so the test suite do not have to change so the test suite will always be same so another variant of this you can see in the next diagram where test actions and checks as part of the test automation tool will work like a machine and the framework is outside the framework is built little outside with more automation and the philosophy of test cases database sheet and all and said in the repository so the technical implementation of the test actions that are part of this are stored in the framework you can see the blocks these blocks can be a series of actions or the sequences so that is written from the user of the test suite so these are the test suite basically again the test suite will have a system trigger and specific test cases are picked up and the framework will drive what needs to be done so that is the difference between this and this one where we have the framework separated from the automation tool of course we can also call it as a independent automation tool this bundle is very important here where maximum automation is done the framework and the action specific tool this tool could be lab you test and or some link there are multiple tools available in the market so basically the technical implementation of certain test action can be rather complicated so this implementation should be hidden from the normal user we will talk about where it is available so only thing to know is which test actions are available so those actions are a part of the automation so automation will pick from the framework so if the functionality of the system and the test space is same but the technical implementation is changed of course we have different implementation all together on the embedded systems the framework will modify so we do not have to modify the automation so in that aspect will be useful so for example an additional interface is added or signals have changed in their characteristics etc but user can still use the same script if nothing has happened so in the previous example we have seen that test data and actions are combined in one test script whereas here we have separated out with the help of the framework so that is the next one is the test suite how it looks like the intricacies of the test suite basically it is also called in the book that is specified by the testing by Bart Workman and Abin notebook I am referring most of the pieces there because that is more relevant but I see you can refer this book online and the suite has several components in built so let us see how it flows so this is the basic what is it called now framework having different modules you can see it here and it has a flow there is a start there is a planner there is a reader the planner will pick up a particular test scenario from the test data storage that means we have a test data storage in terms of a database having signals its definitions involved and the cases also specifying the test scenario and that scenario will be picked up by the planner module and the next one will be reader for that particular scenario the particular test script will be read from the stored database or the contents and there is a translator, translator could be applying this into the understandable actions on to the target so the test actions are derived from the translator there is intermediate layer so the name is translator but it could be anything when it comes to the actual embedded software testing automation different names could be used so the actions could be initialization synchronization, auditory, reporting, checking and all that part of this framework having different modules and as a result of test actions we have the status report and the actions will be applied on the target system system under test and the status report will tell that for each of the script and the scenario what is the pass fail value or the what are the passes and where it has failed and also when we do the batch run we can get the progress report in terms of pass fail count it is called pass fail count, run down progress it is basically a chart of the entire test suit or the bundle of the test suit progress so that is how we use the test suit in terms of automation so this is about the test suit so where the framework and the automation is being combined in this diagram it is also called as a blueprint of the test suit okay in the next slide we see different actions or the activities how they are getting implemented the simple blocks as design of the test suit or the automation as this many blocks so we need to define the objects and we need to analyze test objects and analyzing the test approach this is the first fundamental thing that we do then with the help of this defined objects and analyze the test objects and the approach once you have finalized for each of the requirements of for the particular suit then we are going to start the test suit with the design so we start the design of the test suit then we will have the construction of the test suit with the scripts or whatever it is done we reach the completion stage so the major objective is to prepare an automated testing environment capable of meeting the test automation objectives in order to realize that this some activities are defined first is the preparation of a plan of action the purpose of being to show the activities people involved time estimation etc all this part of the first set of blocks the definition of the test automation objectives detailed analysis of test update and test approach are very much necessary for the design decisions the decisions are also have to be taken care what sort of an approach or any modifications are required common planning all this will be part of this also parallel activities also can be executed as necessary there could be similar functionalities where we do not need a separate approach but slight modification in the inputs that also can be planned so that it is very clear for the testers or the test development team to have what sort of an approach for different blocks of the underneath embedded system all this will be part of the implementation so that is about the test automation technique the next one is we will study about risk based testing so what is the risk based testing and why it is needed and some of the embedded systems they used as an important testing okay so basically so what we do in the risk based testing we will highlight or identify the importance of certain tests which has very key in the embedded software testing key tests and decisions any factors that are going to affect the outcome outcome of the entire embedded software testing so that the decision can be further taken in the proper test or continue the test or report it or if it is a major revoke of the embedded system so that it has to be completely fixed then this risk based testing is very useful so basically developing a risk based strategy is communication basically communicating to the stakeholders what is most important about the system for the product company or the organization what this means for testing of the system that means instead of telling we do testing everything so we will identify some of the key aspects of the testing and that could highlight some of the business objectives also for the system under test all this will be highlighted in this risk based testing for this there will be a strategy for those aspects of the test because there are a lot of factors that are involved in terms of resources resources could be people money time and infrastructure so that also we will highlight info could be cost and it could be human resource and schedule etc so if there is a major thing that needs to be taken care for this specific test all this will be strategized so those are strategizer under risk based testing the separate strategy that they will adopt for complex systems where certain functionalities have to be minimally working as a business objective so basically in a structured test approach this is very important and it contributes to a more manageable test process where it is must be set and decisions made about what is important and what is not is all being specified so important means what it is very subjective concept of course with a risk based the strategy evaluating the importance is about answering the question something like how high is the business risk if something is not okay in this test that means if something does not work while doing the testing so what is the impact of that what is the importance of being that has not okay so all answers for that will be part of the risk based testing and that should be communicate so we need to define that so basically risk is defined as the chance of failure occurred or occurring related to the damage expected when it does occur so what is the damage that is going to cause for that particular failure so if the system is of insufficient quality this may imply high damage to the product for instance it could cause loss of market share the company it can be obliged to call back millions of sold products you have seen there is a call back of for a small issue that they found near the break to replace that they have to call call back it is called as call back millions of cars so it is going to be a huge cost so those will be identified while doing the strategy of certain aspects so in that aspects the importance of those key elements will be identified that is called risk testing that will be under tests therefore the situation forms a risk for the organization whatever the hierarchy elements which are called as a risk so testing of those aspects will cover such risks by providing insight into the extent to which the system meets the quality demands so if certain areas or aspects of the system imply high risks for the product then more thorough testing is obviously a solution so thorough testing of that particular aspects are the important parts of the system is to be done those will be done from the quality standpoint of course the other way also is true where there is no risk is involved we may have to have a small piece of a test or if there is no test is required we do not have to do a test when there is no risk at all so how do we evaluate that no risk is involved or risk is involved or if it is important or not important so this risk based testing testing probably will answer that the attributes would be from the quality or the performance or the product outcome in terms of business of the case so usability and all that will be part of this risk based testing strategy and the subsystems also could be commander with the strategy we have a big system having subsystem 1 2 etc all this will be considered for failure attributes and the risks and the importance of that particular failures and how they do is the decomposition of the architecture the high level information system with the help of that they will arrive at the strategy decisions is specifically done in with the help of quality attributes such as ISO 9126 and DO also they applied so it is very important to have a decision making factors for so such important aspects of the system so that is what is called as risk based testing risk assessment has to be done for the identified risks so chance of failure into the damel is going to have is what is called as a risk and that will identify the particular test strategy for type of risks that are identified so identify locations of where the faults tend to occur such as complex components components with many interface signals etc so those need to be identified first and identification of what are the chance of failure and what is the cost of a damage so that will be arrived with the help of that risk will be assessed so it is called as assessment very important part of the risk based testing and identification could be on some of these things like complex components complex completely new components if the people are not knowledgeable or it is a new subsystem that has come to market and that is being used that is the risk and the component is getting changed again and again in the world or in the embedded system could be in the software it could be and that is also a risk components for which certain tools or techniques were employed for the first time and the components which were transferred from one develop to another developer during the development there is a chance that the new developer would have injected some failures components that were constructed under extreme time pressure it is a very important term because what happens in the embedded software development there is a chance that the last minute work will be more and due to delays in the inputs for the developer or the tester due to the high pressure and pressure and time to market the chances of injecting the failures are more and those components need to be identified as components or risk elements and here components means it is not the hardware component it is any piece of the embedded software system so components which had to be optimized more frequently than usual that means more optimization is required on those components that also can come under a risk components in which many defects were found earlier example previous release or during earlier reviews we saw that certain components are having high defects still that has a high risk components with many interfaces many signals are being used in that components that is also a risk element so the chance of failure is also greater for the inexperienced developers insufficient involvement of user representatives insufficient quality assurance during development insufficient quality of low level test new development tools and new development environment also is a risk large development teams where segregation is very difficult and interaction of different teams also is a risk development teams with a sub optional sub optimal communication example going to geographical spread that means we have seen embedded industries across geographically different locations such as in aerospace industry we develop the entire system example in Boeing which is done in Seattle USA whereas the development is done in a different location in India and fabrication and assembly is done in trauma so the development team or the testing team is completely disintegrated and interaction have to be done efficiently so as long as that is there the chance of failures are more due to which there could be slack in some of the coming from convincing the facts so there will be some hidden issues or errors that system can have components developed under political pressure with undissolved conflicts in the organization or shufflement in the team also could be a fact of risk basically so that is about the risk based data stream we come to the slide where how we can treat the risks that is a term called risk mitigation I think these all management aspects will not study in detail but at least for understanding sake we will try to work through risk mitigation and this contingency means we anticipate the risk and we will work out what best we can do in the contingency and this mitigation is if the risk occurs what would be our approach so it is part of the risk management so what are the options that are available so categorization is something like this so the required information for risk assessment is obtained from different sources and with the help of those sources we will arrive at different risk management options so we have a broader categorization and minimize loss or pay for loss so here again the complexity which matters based on that the risk options are derived so minimize loss is what is one category of treatment of the risk where the loss prevention and loss reduction and any threats we have will be done with the help of certain mitigation form so that will work out for the loss prevention and in loss reduction system engineering risk assessment program design reviews test analysis and fix well structured test and evaluation so all this will be part of the loss reduction so we have we are going to have a loss for certain failures how we can reduce it so these are all the aspects which can be treated for reducing the risk and as we progress towards embedded software testing we should try to reduce the risks that means loss of loss prevention and try to avoid threats that are there for the particular system there is only one path where we are going to minimize the loss and already the loss has occurred and the failures are there risk is realized then we have to pay for the loss so how are we going to re-risk it or treat it so risk retention cost and schedule results that means we have a reserved cost for that we are going to retain that risk and we are going to pay for it or we are going to transfer that risk so that somebody else can continue on so this is basically a management thing and if that is coming under warranty and all that as part of that this taken care so so this risks are very high element important thing in the embedded software testing as a management aspect that need to be mitigated and continued so that is about this is the testing and testing aspects and strategy and we have a couple of important things that is called formal and informal testing so what is the formal what is informal and the other aspect is dry run and formal run okay so these two are being used again and again in the software industry we try to understand what is formal what is formal if formal test design techniques have rules on how test cases must be derived documented or process oriented rules that will be documented reported on pros and so strictly we are going to follow that in formal test design technique and execution the advantage is that it minimizes the risk that the tester will forget something important because everything is based on a laid out process so different testers using the same formal test design technique should produce the same logical test that means we have a chain or the cycle that is well defined so user will follow that and you don't have to bother anything out of all so testers will use the same formal method or the design technique again and again for doing the test and producing the results the disadvantage is that the test cases can only be as good as the specification they are based on a poor system specification will be a poor test because you have already committed to doing the test and we don't have any second chance for revisiting the specification of the test design so the failures if it is going to happen it is going to happen and informal test is the younger one is a design technique that gives a general rules and leaves more than the testers that means informal test the tester has second chance of revisiting the technique and he can slightly modify or there is a scope for improvement there are hooks where he can adopt some changes or propose some changes there are what is that called templates where he can provide proposals to modify it and still there is a chance that he can include the product before the product is out for delivery so this places more emphasis on the testers creativity and that feeling about the possible weakness of the system that means the tester will have a full confidence of the embrace of the system it usually requires specific domain expertise as I said very much it is important to have a system knowledge of the domain here domain means that is not just about the product and the product line where it is being used the product could be used in certain aeronics subsystems or systems it could be used in Indian types could be used in weather forecast it could be used in breaking because breaking many many some small systems so that I will test what we are doing could be part of that underneath that and we have telecom we have gadgets such as home and a set of box whatever it could be so all this will be requiring to have a thorough knowledge of the domain of that particular embedded series where the product is being developed tested and deployed so informal test design techniques are less dependent on the quality of the test basis but have the disadvantage that they provide little insight into the coverage in relation to that space that means everything will be informal the coverage we cannot take the credit it is outcome simply because so whatever the tester has done in the informal testing is all intermediate ones it is not the chosen ones or the final ones so that is where it has a disadvantage but it is advised to have an informal test before we start the formal test the flow should be something like we begin with informal test identify all the get a good confidence on the entire system understand the domain apply the techniques optimally and anything that we want to do before we actually be formal test so they use it in the system industry formal and informal is the equivalent of that are being used in specific industry that is called trial and for formal one the informal one is called as a trial that is the first cut run of the primary test execution so basically it is a confidence and any revisit is required containing is required all will be done with the help of this trial is something like a informal or pre-formal run and there are different names that are used but generally in the ML industry we use it as trial and formal run we know it is same as whatever we have studied in the previous bullet formal run is the execution of test with evidences captured as it is going to be reported with the complete documentation so once we are done with this formal run that is what is going to matter in terms of reporting pass fail revisit whatever it is required so that is about the terminology used in the ML industry called formal and informal and trial and formal run so with that we come to an end of come to the end of a unit one so probably we will touch base what are the factors we visited so far in the next session so before concluding the class I will go through some of the class that we have we have for today test action part of a test case which defines the actions that must be performed on a test object test automation we have seen use of software to control the execution of test the comparison of actual test actual results the expected results setting up of test conditions and other test control and test reporting test basis all system recommendation used as the basis for designing test cases test bed software hardware is both that offers stimuli to a test object and records the output on that test case we know that it is set of inputs reconditions and expert code results designed for a particular objective or a requirement such as to excise a particular program path or to verify compliance with a specific requirement we know that requirement level we have a high level test for the block box testing we will have a test cases accordingly and for white box testing we will do the coverage and all that while doing the execution on the implementation of the code test infrastructure the environment in which the test is performed consisting of hardware systems of the test tools test tools procedures etc with the help of infrastructure we develop or build the environment it also has a automation aspects in all that test level we have seen earlier sessions a group of test activities that are organized and managed together the division can be made into high level then we have a test depth level indicates to what extent the dependencies between the decision point and test depth level n all dependencies of actions before the decision point and after n-1 decision point are verified by putting all possible combinations of n actions in that test path so that is about the glossary that we have to do so with this we come to the session and the units that you have completed unit 1 and unit 2 we will do a small recap of whatever the units and the sessions we have completed and we will take up the next unit that is static analysis inspection and the next session