 We'll communicate with the next session of embedded software testing and these are the exercises and questions, practical session of series of embedded software testing. Here we see more practical aspects of embedded software testing in terms of exercises, work through videos, tools, demonstrations. so if you have questions and i will ask you questions and i will post some questions for you and you can have some look understand and you can write back to me.damn and having understood the embedded software testing five units we know that different conversation and named different types of embedded systems can be tested in different నొలాచ్ంద్మాలినేఆట్నేనం మ్నేన్రింది నోట్చ్ప్య్చి నితి నిందా లారంవలా మికిస్ౚౌనకి ాబ్నాంద్ఠ్లెటి. బ్న్నిక్ ప్కిక్మథి నిందాచి. so we studied about all that in different units like fundamentals of testing, then testing methods, testing tools and offline testing, static analysis, coding stuff, code reviews, then we studied about integrating the software and testing the integration aspects, finally we studied about the test management in terms of how the entire process of testing can be managed, it could be defects or it could be artifacts under the test, so related to all these units, all these five units, so we will have at least one or two examples, demonstration, lab sessions, questions and answers pertaining to these units, accordingly we will progress on embedded software testing modules, okay, the first one being the first exercise it is on test case design, test scenarios and testing the embedded software, so we know that for doing the embedded software testing it is a part of the life cycle and the life cycle contains requirements, design, code and test and in order to test we definitely need to have a requirement document, okay, here is an example of SRS, so the first exercise is identify test cases and scenarios from a set of requirements with grouping test procedures, example to consider for this is the SRS of UI, so this is an example created for this embedded software testing, it is called UI, UI is the thing about the embedded instrument, embedded unit instrument which is a generic microcontroller instrument having certain features and functional codes and it interfaces externally with certain messages, it is general unit, so we will try to understand the exercise and try to lay out answers for this exercise, so our aim is to create test cases and scenarios from the set of requirements, okay, we will try to study the requirements, so what is the requirement, so this document is about requirement specification for embedded instrument, so this particular unit having about say 15 requirements and there are group of requirements, they are categorized into various features or functions, so the first group is about modes of operation, next set of requirements is on performance requirements, then next set of requirements is about communication, the next set is about watchdog, so likewise we have about 1, 2, 3, 4 set of requirements, this is general requirement whatever beginning, so we will try to do the testing of this, so as I said in one of the session to have a embedded instrument testing done appropriately to write the test cases approach and do the test design and create the scenarios and do the execution, the first and foremost thing that we need to have is the system, system is what the embedded software system, that system we need to have a clear understanding, so how we can have an understanding based on the system understanding document or system spec, here in this case we directly have the software requirements and in general I try to tell what the system is about, this system is an embedded instrument, so it works in different modes and it performs to some requirement like it is supposed to have certain messages, it is supposed to have certain actions for certain messages and it is supposed to work at certain speed and it should have certain limitation in the memory and how it can interface with the X mode mode is explained in the communication requirement and there is an additional unit called watchdog, so these are the top level elements of the embedded software system and how it works over the period in the embedded software world or in the embedded system is that it works in five modes, those are unit operational maintenance download and fail, so you can see this diagram this embedded system will be working in this one of the modes of operation when it is powered up until it is powered down or until it is used for different set of operations, so we have a start with the unit mode then it goes to operational mode then it can go to maintenance mode and it can start to operational mode and now maintenance mode it can further go to download mode, these are basic operations or basic modes of operations that this embedded unit instrument will work upon and you can see the arrow specifically created so that accordingly the flow will happen and from operational to unit there is no way to go back similarly from download to maintenance there is no way to go back, so there should be a requirement how we can go back to the unit mode, so these are closer all called state level, so that sort of a complexity or that level of detail let us try to see if we can detail feature session or let us try to keep it simplistic saying that my embedded system is having this many operations and this much requirements for this only I will try to write test case and understand how I can test it that is the aim of this exercise is basically called as one more thing is that at any point of time if during this 1, 2, 3, 4 modes of operation the unit can go to a mode called fail mode that means it is a failure during initialization it could fail during operational requirements or operational activities from fail or during maintenance and download operations it can go to a fail mode, so from the fail mode it will not go to any mode it will be stuck or it will never be up, so in order to restart probably user has to restart the system so that from fail mode it can recover from the unit mode and go to operational, so basically any embedded systems you take will have two flow mechanisms, two levels of flow mechanism one is initialization other one is operation one that is initialized it is good to operate or it is good to run, so in operational mode whatever the specific requirements of that embedded system or the specific business requirements of the business objective or the client based requirements it is supposed to work it will work, so those two basically are the prime elements but that is not sufficient in the embedded system because it is to take care of many other things like a failure, false, it should be maintainable, it should be downloadable always, so accordingly there are different operations or sub operations it will be attached, so let us try to keep it simple saying that this embedded instrument works in five modes of operation and those are a unit operation, maintenance and download and at any point of time it can go to failure mode, having said that so we have got a understanding on what this instrument does, so the first SRS or very first requirement, so basically requirements are identified with a tag called SRS software requirement specification, the first one is talking about in general five modes of operation, the next requirement we will try to understand it is basically under the category of modes of operation, so what are the modes that this instrument can go and where and all it can go to switch and backward, so you can see for each of that we have a separate requirement like maintenance mode what will happen, operation mode what will happen and in insulation mode what will happen and where it can go to failure mode, so it is very important to understand the requirement first, so let us try to understand to an extent what it is, of course you can go through this offline and try to understand and can elaborate more your understanding and when we are done with the test cases probably it will be a generic one or the basic ones which is enough to launch further to add more test cases and we have studied in one of the classes of progressments, partition equivalence and analysis type of test cases all this, so that can be elaborated further based on our expertise and when we dig more into the requirements, but generally we try to draw test cases for these set of requirements to start with, so SRS 2 says about the UI shall set mode to failure mode in the following cases or logic, so what it means is the unit will set the mode, so it different modes of operations are there right, so it will set the mode to failure mode under the following conditions, so this conditions can occur in any order or at any priority, that is why it is clearly told it is a R logic, R logic means this alone can happen or this and this both can happen or multiple of this can happen or first third fourth fifth anything can happen, any of this happens it will enter into failure mode, so we need to draw a test case for this, what are the some level requirements for this, so these are all about 1, 2, 3, 4, 5, 6, 7, 9 types of cases are there, each case will have its own requirement like, when the embedded instrument is in maintenance mode it will go to failure mode, when embedded instrument is in unit mode it will go to failure mode, when it is in operational mode it can go to failure mode right, when it is in download mode of course it will go to failure mode, so we know from this diagram that it can go to failure mode from either in it operational maintenance and download, so 4 levels of entering into failure mode is there, that is what is been explained here and further it could be different events, multiple events like in maintenance we have 1, 2, 3, 3 events are there which will be responsible for entering to failure mode, similarly we have 2 events in unit mode that can make it to the other mode, similarly we have operational mode as well, okay, the next requirement is about when the mode is in heat mode, if status is okay, let me explain any one requirement here, when mode is in maintenance mode, if there is a message received equal to CR1LF, sorry 01CRLF, do not bother about what is CR, try to understand the first one, when mode is in maintenance mode, if received message is equal to 01CRLF, when mode is in maintenance mode if received 0 to CRLF, so when it is in maintenance mode there are 2 events that can happen 01CRLF, 02CRLF, forget about what is CRLF and all, that is a message, so when the embedded unit instrument receives a message having the content 01LF, 01CRLF, it should go to failure mode understood, similarly we have another case in maintenance mode, when the embedded unit instrument is in maintenance mode, if the transmit message is not equal to CRLF, that means here we have received a message and if the transmitted message from the embedded unit instrument has not become CRLF, this CRLF, it will go to failure mode, similarly in the initialization if there is a error occurs or there is a error condition it will also go to failure mode okay, so like this we need to identify test cases, so definitely we have 9 test cases right, because we have 9 sub requirements 1, 2, 3, 4, 5, 6, 7, 8, 9, so 9 different test cases we have each test case we are going to provide an input as what, when it is maintenance mode then we have to transmit a 01CRLF externally, so that the unit receives 01CRLF and we expect a output as failure mode, so these 3 elements are required for testing this, likewise we have the next one, we should make sure that the embedded unit instrument is in maintenance mode and we receive a message as 01CRLF and we can expect a output as failure mode, similarly we have for everything the test cases are better and interestingly there is a R logic, R logic means what, multiples of this events can occur, so we should be able to test with multiple events, that is event 1, event 2, event 3 and in the next test case we can have event 1, 2, 3, 4 and in the next case we can have all event 1, 2, 3, 4, 9, so combinations of this events is also very important which is nothing but what we studied about is MCDC or the complete coverage of this requirement, so that we have covered this R logic, so that R of all this have been tested, R of 1, 2 also has been tested, it does not mean that we should test for everything, every R may not be required, it is just telling the R logic, that is what we do with the partition equivalence, we will take test with first R of first 2 may be in between one R condition we can test and in the last also we have we can test it and the last case having R for all this, the other important thing that we need to understand is whether is it viable to test it, why I am telling is we know that this instrument can go in the mode and that mode it will be there available, so is it possible for us to emulate all the mode at one instance it will not be true, so in that case we need to understand whether we will be able to do the inputs that can be triggered or not, if it is possible to trigger then we should be able to do this R logic, since it is not possible we will not be able to do it, so it is very important to understand the complete system logic and understand of the entire system, so that it is easy to write, so 9 test cases definitely we can do it and R logic definitely we can do for certain cases and R logic for the entire case may not be possible because we may not be able to emulate, there are how many conditions, maintenance is one, input is one, operation mode is one, download mode is one, so 4 modes which we will emulate at a time, is it possible, I do not think so, so we should limit our test cases according to the need of the system and though the test case is valid we should try to understand whether is it possible to test it, that is what is this requirement is about, okay, the next one SRS 3, when mode is in initialization mode, now we are coming to individual modes basically in terms of its power-up and other things, so when mode is in unit mode if status is no error state the UI shall set mode to official mode, we know that it will go to failure mode when the initialization becomes failure or there is a error in the initialization it will go to what failure, correct, so the opposite of this, so you may be having a negative place for this in this test case only, so it is also important I will tell you not to just have the positive values of 01 CRMF, we should be able to scramble like this one as CR something like CRLF10, so different type of SS we should be able to power, like this you can have it which is other than what is specified here, so that is a negative test case or other than the entire R operations something like that, so anyway we may not be able to have an answer what will happen if this is not an error state if the initialization is successful, so that is what this requirement is, when the mode is in unit mode if the status that means the operations of the initialization having no errors the instrument shall set the mode to operational mode that means it has moved to operational because the initialization is successful, if it is failure it will not go to failure that is what this requirement is about, so once you have understood this you need to go out there, so trigger the inputs with the failure case trigger input because it has been successful, two cases are done and any other case we are missing, okay let us try to understand this one, when mode is in unit mode if no error state is alive less than one second that means if initialization if it is stuck for more than a second but there is no failure that means error is not there, still it will go to failure that means what is understanding first case is initialization is happening and some failure has occurred in initialization and that will lead to failure mode and during initialization, initialization is complete it is successful it will go to operational mode, now the third case we have a initialization with no error, initialization is successful but it is not able to go to operational due to some issues or some other thing you can call it as an initialization failure but it is not an initialization failure because error set for that is no error, so still it is a failure it will again go to failure why because it is not able to go to operational it is certain time what is the time one second, so this is another case the typical embedded system requirement is from the one of the example embedded instrument that I have picked up from my experience and generally I try to put it so nothing intentional for any application or anything you can draw it to a different applications whatever it is it is one of the example okay, further understanding about this in it mode if the status is no error then you go to operational mode conditionally what are those conditions when the mode is in mode if status is no error state when mode is maintenance mode if received message is equal to 0 3 CRNL when mode is in maintenance mode if transfer to the transmitted message is equal to CRNL when mode is in the operational mode the next requirement if maintenance mode command state becomes equal to enable VHL set mode to maintenance mode then mode is in operational mode if maintenance status is enable when mode is in operational mode if maintenance enable status alive at least one second is all similar requirement but specific to different modes so these are the requirements we need to understand and try to understand the entire system is about operational requirement is the entire operations how different modes of operations are there any other things what we have missed probably the download mode of operations is not put here I think yes so under what conditions it will go to download okay it is here actually so download itself will go from maintenance why because it can go for only from maintenance there is a requirement here understand this requirement you try to draw few requirements some cases where it is clear for you when mode is in maintenance mode definitely if received message is equal to 0 4 CRNL the unit you shall set the mode that means it has accepted this message and it is good to go for download operation then continuation of the requirement actually okay I will tell that wait for one second to enter into perform download that means once it enters into download mode we should wait for one second to enter into download mode of activities and the sub conditions are when mode is in maintenance mode if received messages are equal to CRNL when mode is in maintenance mode we should wait once again so these two are sub level requirements for this entire requirement so this is how the requirement should be understood try to draw test cases okay the next set of requirement performance requirement the entire process of booting up till operational mode shall take not more than one second so you know what is boot so when the embedded system is powered on it will be booted means it will be powered up all the components all the peripherals are all the elements that are part of the embedded systems will be powered up and the time it requires to make it up and running till then whatever is going to happen it is nothing but booting the process is called booting process so here is the requirement the entire process of booting up till it becomes operational should not take more than one second actually speaking there are words actually which you should be careful shell should will may etc so each one has its own meaning basically I will try to probably explain one of the parts or it is one of the requirements understanding actually this not part of the embedded software testing but it is better to have an understanding on these words shell means compulsorily the requirements should be tested or the requirement should be implemented at that level you try to understand okay okay come back to performance requirements so these are all performance related of the embedded systems there are about three four or five requirements are there the first one the seventh one is the entire process of booting up till operational mode shall take not more than one second that means once you power on the system once it becomes operational the duration at which this is becoming operational should happen by less than one second there is a meaning so this is a bit challenging to understand first second thing is you may come up with lot of questions before you try to start asking how I can test it that is very important so we need to understand what is booting up process what is the operational mode when I can say that it is operational mode and what are the hooks or what is the strategy that I can apply to test this requirement so in general embedded systems we will have boot up identification operational identification again these are derived from the requirements so your first questions should be first and foremost questions should be on the these things like how I can identify whether it is booting how I can identify whether it is operation if these two are answered your above requirement is clear or the testing for the above requirement is clear the strategy for working out so probably this requirement at this level it is very generic so probably we can draw sub-level requirements I am just trying to put it actually because I not put the sub-level or is also called as derived requirement whatever you want to say so that can have something like the boot up identification the boot up process starts when there is a cycle at pin number 20 similarly there could be operational requirements one of the operational requirement we should be able to identify saying that it is operational so probably communication requirements we have so this will happen during operational requirement so what it says is the US shall communicate through can message the outside that means one of the interface requirements should be able to identify operational requirements so it is clear right now with these two which will be tested again next question is how we can test it so there are certain things like there is a one second that means we need to measure the time it is very clear correct so time how you can measure and to be measured how we can measure with the help of measuring instrument such as oscilloscope right okay to measure the duration how many hooks you need to because one at the start one at the required end basically it is called so one at the booting up identification time other one is at the operational mode so we have a pin number 20 the first one being pin 20 pin 20 we should have one hook up the second one should be interface hook up interface requirement as we can message can message basically we need to identify the can port is a hardware interface there we can put the oscilloscope or we can very well see the message analyzers are there such as canalizer or can scope etc any of this instrument can be used so there is a how we can measure now with this definitely pin 20 oscilloscope starts showing the wave basically and we record the time it is called a start time right similarly here we record the message receive time in the can because both are running at the same system we know that the time log or time this is called time log or time stamp of this so the net duration of this time stamp equal to message receive time minus start time so this is very clear this should not be or this should be less than one second so our requirement is tested so like this we should be able to test this requirements this is this will become a strategy a strategy got it so we identified it is case to measure this and make sure that at any point of time when you boot up it should not exceed the one second limit otherwise the requirement has failed so we should be having a questions in terms of how we can have identify the test hooks for testing this and what are the measuring items that we can have for this performance requirement similarly we have the next one called the processor workload for the first page so here there are different jargons embedded system that we have one is processor other one is workload it is also called as execution cycle and other one is worst case other one is percentage right so we need to first understand what process is used it could be any micro control if the micro controller suppose any power PC or free scale let us say power PC example MPC example 56 if it is used so we need to have a data sheet so we know that at what rate it is running that means at certain cycles of speed the processor is capable of executing right once we know that this is the execution suppose if it is a one hertz it is executing the instructions of the execution cycle at one second because we know that time equals 1 by f so f is a frequency t is a time so one hertz means one second similarly one megahertz is 1 into 10 to the power of 6 like this we are going to have the processor details first then workload that means how many instructions it can execute so if it is 10 megahertz equals 10 million cycles per second it can execute then worst case so worst case we have defined that means at max not more than this that means 10 million per second that is the worst case or you can say also equal worst case it can go to 10 millions per second generally it will not go that much but if the load load means the activities or the interactions or the operations that are happening within micro control of the processor is so high that the entire processor is completely loaded completely occupied you can see in windows and all that there is something called a taskbar task manager you can see the load here networking basically it can say a processor I would say performance let us go so here is one performance requirement for this processor whatever I have I hope we are able to see this here you can see the performance the CPU usage see this is a good bar right complete bar so currently as I speak so there is a audio recorded there is a typing world so many things are happening in the windows and at every instance there is a percentage that is getting changed right you can see 47 percent 54 percent 40 percent every instance it is showing accordingly it is graphing inside so this they have captured using the instruction cycle so how many instructions are getting used in the CPU this is a Intel based CPU so 43 percent similarly for this embedded instrument we cannot afford to have a more than 70 percent that means we should have a program or the entire embedded systems developed in such a way that will not be loading the application more than 70 percent that solved the understanding and there are other things like page file you say cache and solve others or I would say operating system related things it is not looking to that in details when you come across from the you will come to know about this so that is what the basic concept of workload of the processor and the percentage is 70 percent this is a formula we use for calculations just for understanding the question is how we can measure like we have task manager in both the embedded systems do we have any task manager we may not have so the requirement should be much clear and more detail such that workload how it can be tested that is what is called as testability testability of this requirement what is it it is I would say no none that means it cannot be tested at this seeing the requirement just like this so we may have to dig further into other requirements to understand what can be done what can be used which requirement I can correlate for that this testability can be applied so that is also important because there are multiple team working on different performance requirements some one person is working communication one person watch job one person they need to have a interaction such that each one is very clear of what they are doing as well as how others are doing their testing so it is very important to understand the system from that perspective usually in general what they do is they use the math file probably I will go through the math the entire execution of the process is divided into various tasks right and we know that each tasks what is the time is going to take so collection of all these tasks equal to the total time and where we can get the tasks you can get in the math file how we can generate the math form based on the linker linking on the target so collection of all this total time will be will become the total time of the all the tasks so again total time that is available based on this formula we are going to derive it so this is how we can write the test case for this particular one the next one is the memory similar to this we can use the math file for testing the memory like we know that there is a 1 MB of flash memory available and how much memory is been occupied by the embedded instrument it should not exceed 50% that means 500 what is the half of or the 50% of 1 MB equal to find it kb right so this is how we are going to measure this size where we can see the size it is based on the math file of a typical this is a typical embedded system I am trying to talk there could be different ways we can see or the actual L file linker file or the definition of the linker or to be as required or it is executable size is equal to size so that itself will tell you how much it is going to occupy the memory based on that we know that what is my total size of the instrument or the embedded system and how much is being occupied so if it is more than 500 kb that means this requirement has failed and if it is less than if it is more than 500 kb requirement has failed else requirement is pass this is how we are going to write the test case and do an analysis and arrive at the conclusion so basically these are something like the method that we use using analysis these methods are called as analysis especially for performance requirements are done with analysis analysis of memory analysis of math file linker and the memory and the data sheets and all this stuff will be part of the so other part of the memory is RAM that also should not be more than 50% so this also can be done with the help of the the contents that is defined in the linker and the corresponding math file that will tell how much memory this embedded unit has got produced another part is a stack you know what is stack so the stack memory should have a reserve of 50% the next type of requirement is about communication requirement okay you know what is communication it is communication between two elements of the embedded software it could be subsystems or it could be a system versus external world so in this case what is that we have let us try to understand the communication SRS-12 requirement is about the UI shall communicate through CAN message with outside interface that means this unit will interact with outside world with CAN message so this unit tested this is a very simpler requirement how you can test it you can inspect the CAN message whether it is coming out of the or analyze the coming out of the instrument that will prove that this requirement is satisfied that means embedded unit instrument is transmitting the message or communicating with the external world that is all the requirement so we will prove that there could be some tools required to analyze the CAN messages right what are the CAN messages that is all probably for the next set of requirements I will try to understand like whether it is a 0 2 CRLF we know that there are different modes of operations it will transmit ALIVE message you can see here so there is a ALIVE message which it will transmit and those ALIVE messages can be observed in the CAN at regular interval so there is a requirement saying that every one second the messages are analyzed correct so using a tool something like canalizer we can see that there is a message coming out of the embedded unit instrument so this is what we are going to prove so with that this case is written and inputs we know output we can expect and we can do the testing the next requirement we shall communicate its ALIVE status at least once exactly only it is there below so together we can test this requirement with the above one or while testing this this testing also can be taken care right so test cases switch off sorry let us start the switch on simpler one switch on the EUI wait for one second expect the CAN message or CAN what is that called ALIVE status every second next is switch on switch off the EUI equal to NO expect NO CAN ALIVE message so this is another case that is all very simple so two test cases we can draw out of this requirement this is about communication requirements but this is a simpler one I have put there could be more complicated ones where you need to combine as I said in the operational mode different requirements that is called as grouping grouping of the requirements here I have grouped both the requirements I have already 12 and 13 grouping of requirements or I would say grouping of test cases to address the multiple requirements so best and good thing that we can adopt is plainly you write the test cases first you take one by one write the test case for these write the test case for this assuming some other requirement then you group all of them under communication requirements that will become a perfect test strategy for communication requirements so that test strategy will have communication requirements related test cases that is how we can take care of that okay the next one is about watchdog requirements you know watchdog by now I mean it is part of the embedded systems that is an independent unit it could be an internal watchdog or external one its basic job is to make sure that the processor and the software that is working inside the software is alive and it is working all the time and if it is not working this watchdog will be a reset of that processor that is all it does so to do that it will have requirement in terms of at what rate it should reset at what rate it should monitor etc so that is why it is called as a watchdog it basically watches so if the embedded unit instrument is not alive it will try to reset and if it is alive it will not bark here that is why the name came as a dog actually so to satisfy the dog you need to make sure that you are alive and that alive should be monitored by the watchdog unit okay let us not go in deep into watchdog because I hope this explanation is enough for now okay let us try to understand two requirements that you can write the test cases easily okay the UI shall configure the internal watchdog to generate a reset to the microcontroller with threshold duration of 500 milliseconds so as I said so watchdog is should be configured right the configuration when it is done during the installation so the configuration of the watchdog should be done such that it is configured at 500 milliseconds the watchdog is configured for 500 milliseconds so when the microcontroller is reset if watchdog generate pulse duration of greater than 500 milliseconds so the watchdog unit internally will wait for 500 milliseconds and it will do a reset after the 500 it will generate a pulse basically okay the embedded instrument shall pulse the internal watchdog at least once every 500 milliseconds or less you know why because watchdog unit will know that the microcontroller threshold still it is making it happy that that next 500 milliseconds it can execute its operations and in between it is going to pulse watchdog so that there is no reset occurred and it is clear that the embedded unit instrument is working fine so when microcontroller operations are running continuously if watchdog generate pulse at least once every 500 milliseconds or less that means if microcontroller operations are running for a long time more than 500 seconds it will going to reset it and microcontroller's responsibility is to make sure that it should pulse the watchdog so that there is no reset occurring so that is what the meaning of the watchdog if the internal watchdog what I try to put it okay so that is what the understanding of the so it should be very clear about the system if it is a complex system definitely we need to have a generic idea then what are the modules that we are working for the embedded software testing that modules at least and surrounding modules we should be clear of how it is going to be operated what are the requirements and what are the references that I need to know for example in this case we need to have a reference of the embedded processor which processor I am using so which pin I need to go through and how I can use it what are the instruments that I need that is also very important to arrive at the strategy so it is very important to understand requirements first then based on that we can go through the we can write the test cases okay in the next session we will try to identify the test cases and try to understand the test cases and for these requirements we will write these scenarios and try to group the test cases for the functionality or the feature set of the requirement so exercise one is about understand the requirements ready test cases and scenarios from the set of requirement with grouping and example to consider is the SRS for the embedded instrument and extension of the this exercise is once we are done with the requirement understanding test cases writing we should be able to write the test case review checklist test review checklist is called for high level testing because we are doing the requirement because this checklist is very important I will try to open it these are rules for verification of test cases so what we do basically here is this checklist will make sure that our verification is strong and correct for the given requirements so that is what we try to do it and if there is no then we need to provide a comment if there is yes it is fine you are taken care of this checklist and if it is not applicable we need to provide a comment why it is not applicable so this also an exercise we need to fill up this column as well as this one so we will try to go through this in the next session of this exercise after that we will try to understand the traceability as the exercise tool and we have more exercises like exercise 3 for coverage tool using we are in the area we will try to understand the coverage tool then ADRA extension unit testing we will try to understand then the next class is about next exercise is about the code warrior that is another IDE integrated development the next one is about few lab sessions for the YouTube Google we will try to understand from various embedded projects how they are using it the last exercise set is being on the test case management and defect management using test clean can bug rule and the foremost of the last one is the static analysis using understand CEC process that tool will try to follow it so with that we will end today's session and we will continue the exercise 1 and 2 in the next session