 For joining the next session of embedded software testing unit 2 series, we are in the end of this second unit with the couple of sessions we will try to wrap it up and we are more focusing on the embedded software testing, the white box testing aspects and the technical we will study about the white box testing techniques in more details and in continuation of the earlier sessions. Today we will study about the branch condition testing, branch condition, combination testing, if possible modified condition testing and LC, SEJ and NCDC, okay. So before that we will just touch base on the previous session where we had gone through a table of a special coverage analysis or structural coverage types, basically this is what is used for structural coverage analysis, structural coverage analysis or SEA very important analysis method that they use it for industries like aerospace where the analysis need to be provided to the manufacturers that is like aerospace industries, manufacturers such as Boeing, Airbus, Bombay and Air etc. And we started the white box testing technique with a statement testing where we cover the statements that are in the code and we also learnt about software instrumentation which does the intrusive hooks in terms of print for the marks which are required within the code so that the coverage will be traced, it is like a tracing mechanism, it is called software instrumentation, since the code base is huge so we cannot afford to have it manually so there are a number of tools that are used for software instrumentation like vector cast, LDRA, RTRT etc. With the help of the instrumentation we run the unit testing statement coverage and the coverage will give in terms of the percentage, if the percentage is not 100% we will do a manual analysis of the gaps and the gaps could be in terms of decisions also so in that case what we do branch and decision coverage we will take care where the coverage is done with the help of total number of executions you have to make, total number of decisions it might be the way to because two times it has to be the decision box need to be analysed why because there are outcomes of the decision box that is the aim and box it could be true or it could be false. And in continuation of the white box testing we have gone through the data processing where the variables of the data objects are analysed in terms of the flow and every data that are used or the objects that are used will need to be analysed and tested here the data object types could be D, K, U used could be used in the calculation of the predicate so an object is defined when it is appearing in the data declaration or again any value it has been opened a file has been opened that is also called as an object and if the memory using a variable is allocated to be dynamically or using constants of a pair operation mechanisms. So this data object types are used for data flow testing where we will segregate the different types of data in different columns such as definition C use, P use, C use is a calculation purpose you can see X, Y, W and Z in this example code is used as a C use or calculation use whereas P use or the predicate use is Z and Y you can see if as a bracket within that Z is less than Y so it is a predicate value directly within the bracket so that is why it is called as P use. All this data will be observed and analysed in terms of data flow testing it should be tested against the intended functionality or the specification of the system under test. So if there are gaps between the parts in the statements and the branch or the decision the data flow will augment it in terms of strategies that can happen so each of this lines of code having the data objects will be analysed and using different values for example X and Y as per specification can take value between 0 to 10 we know that how we can provide the inputs from 0 to 10 with the help of equivalence class and boundary value analysis. Also we need to consider the if condition below so that it is satisfied it could take the path within the if or it could take the path within the else so all these gaps will be analysed in terms of data flow testing. And next is the branch condition testing which we will study today so okay what is the branch condition testing? Branch condition testing uses such model of the source code which points out the decisions and the individual Boolean operands we know Boolean operands such as less than greater than greater than equal to etc. So the decisions coming out of that are tested with the help of branch condition testing. A decision is a feasible statement which can transfer control to another statement depending upon the logic of the decision statement that means decision is having a logic having the Boolean operands and as a result of that the control can be transferred to different statements or a single statement depending on the logic that is being applied within the decision statement and the decision condition is a Boolean expression which is estimated to determine the result of a decision. So decision basically is a condition right so it will have the Boolean expression in terms of less than greater than equal to less than equal to or equal to etc. So that will decide basically the result of the decision whether to go into one control or one set of statements or it should take another set of statements. So basically these decisions are in loops and selections so loops you know it could be a while one sorry not while one while loop or for loops or do while likewise we have based on the language concepts we have different loops similarly selections in terms of cases we know that. So these decisions are implied within this type of statements we will see in more detail how branch condition testing is taken care okay. So in terms of branch condition testing test case design aspects how we need to have a test case design taken care. So before that okay so 100% condition coverage means that test data here the coverage is also same way what how we are going to do but 100% coverage here means that the data will ensure that every condition that is executed at least once during the testing condition coverage that will include also the branch condition. So don't get confused with the branch of decision condition here conditional coverage in terms of the Boolean operands and the expressions part of the decisions will be tested. And in terms of designing the branch condition testing test cases should be designed to excise individual Boolean operands values within decision condition for every test case these should be clarified before we do the design we should have any input to the component that is part of the decision condition for each decision estimated by the test case identification of the Boolean operand to be excise to be test case and its value expected result of the test case. So these three should be clear for the tester before he designs so all the Boolean operands within the decision condition will have to be excised operand values such as we can see an expression let us start with a formula probably it will be easy for I into 0 to I less than 50 I plus plus and A less than B and do this these things that may be multiple statements as well as a function block also would be called depending on the nature of the problem. So here we have a for loop this block will be executed how many times 0 to less than 50 means 50 times where the index is I so obviously the index will have an incrementer or the incrementer is already there based on the index certain conditions are used and you can see on the right hand side along with this it is very important to have this right hand side expression also to be satisfied or evaluated before the block is getting executed. So we know that statements in real statements we have a statement for it and we know that there is a block if A less than B we are going to do it and if true this will be done if false this will not be executed and now since we have A less than B all the condition branch condition we need to evaluate all the aspects of A as well as B in order to test the Boolean operands. So the Boolean operands it could be logical expressions such as etc. So basically the tester needs to understand what are the inputs to this block that needs to be taken care for each decision estimated by the test case identification of the Boolean operands to be excised by the test case. That means what are the actions that block is going to do for each of this Boolean operands expression in terms of inputs will be excised and also the value that it carries out in terms of the execution and of course what is expected of each conditions while it is getting executed so that is also very important to understand. So that is about branch condition testing and next one we have is slight modification in the branch condition, branch condition combination testing here what we do branch condition combination test in the search model of the source code which recognizes decisions and the individual Boolean operands within the decision conditions that means there could be decisions within the Boolean operands itself so that also will be excised. So whereas in case of branch condition alone what we do we take care of the decisions and the individual Boolean operands that is all here we take care of decisions and the individual Boolean operands within the decision conditions. So we have decisions, decisions also will have a lot of Boolean operations or expressions or operands part of the decisions that also will be excised, this will be a rigorous thing there. So that is why it is called as a branch condition combination testing, a decision is feasible statement which can transmit control to another statement we know that it depends on the logic of the decision statement that means how the logic is going to be derived based on that decision is feasible, a decision is called as a feasible statement. A decision condition is a Boolean expression which is estimated to define the result of a decision that means it is a condition basically Boolean expression condition which is estimated to define the result of a decision that means the Boolean expression will drive the values in such a way that the decision outcome will be known. Normal decisions are found in loops and selecting same as here we have a combination of Boolean operands within the decision conducting are tested with the help of this. So each of these Boolean operands need to be tested for the variables that it is taking care, so test case design how we are going to do for branch condition combination as per the test cases should be designed to exercise combinations of Boolean operand values within decision conditions for every test case these should be clarified the inputs to the component for every decision estimated by the test case identification of the combination of Boolean operands and their values the expected result of the test case. So it is similar to the branch condition testing but in addition we have a combination of the Boolean operands within the decisions all that need to be exercised, so that is the purpose of branch condition combination. The next one is about modified condition testing, so what is the modified condition testing? Modified condition testing uses such model of the source code which recognize decision outcomes and the individual Boolean operands within the decision conditions here additionally we have outcomes also important that means the output, so what sort of outputs the spec or the function that is expected, so based on the need of that we are going to test it. How we are going to test it is with the help of all the decisions that means decisions individual Boolean operands within the decision conditions and the outcomes of the result that is also a deciding factor for modified condition testing. So we are going to have all these possible combinations in terms of modified condition testing. Additionally it is a statement which can transmit control to another statement, it depends on the logic of the decision statement, again the logic is very important here based on how and what are the values that we are going to derive of the logic it is going to decide the output decision output as well as the Boolean operand within the decision conditions. So decision condition is a Boolean expression to define the result of a decision, normal decisions are found in loop since it is a loop, so at the end of the loop we expect some result and the result we want as per the specification and the result we want to achieve and done with the help of such values which can be driven within the Boolean expression part of the decision conditions that is how modified condition testing is taking place. Maybe we will touch base modified condition with decision coverage in detail with respect to the O1 and B process which is followed in the other space industry, test case design aspects, test cases should be designed to show that Boolean operands within the decision condition may be independently influenced the result of the decision. That means in to understand here suppose variable A and B are used to derive C, C is suppose there is a, so modified condition is such that independency need to be verified that means because of A I am going to get the result in C and because of B and keeping A as constant we are going to get the C as a part, so we have to pass all the, so like this we will have multiple conditions and Boolean expressions are in the number of variables and the logic but in all the cases we need to measure the independency this is very important, independency need to be verified, so that is what the modified condition is, suppose A is having some value, some value say 0 and sorry 1 let us say and B is equal to 0, so what will happen A and B will again become 0 which could result in something for some result 1 let us say. Here we have proven that when B has become 0 C the result of the operation will have an impact on the output, similarly when A is 0 B is any value 1, 2, 3 whatever it is but the impact is due to A because A ended with any of the value within the B will result in a known value, it could be result 1 or result 2 depending on whatever the expression it has, so A and B will drive independent, 1 will keep it as constant like B has said we will keep 1 next time 2, next time 3 sorry we will keep A as constant next time we will verify or vary the B in terms of 1, 2, 3 it is a call, so the independency for B is being verified, so that is all we are going to have, so the ultimate aim is to see that the independency is achieved because of one path or one inputs the decision condition is going to vary, so that is what it means, this case should be designed to show that Boolean operands within a decision condition may independently increase the result of the decision, it means that whatever I have put here is nothing but the Boolean expression having a Boolean operand as and, so we are going to verify the operands for its independency, for every test case this should be like same like we need to have a input what are the inputs that is going to drive for each decision estimated by the test case and the identification of the combination of Boolean operands, their values and the result of the decision, the expected result of the test case that also need to be understood before we do the modified condition, so that is about modified condition testing. The next one is linear code sequence engine, this generally we follow not with this name but indirectly through MCDC condition testing, modified condition testing, we will add it but certain specific industries or applications they prefer to have this, so this is a software analysis method basically, used to identify structural units in the code and the unit and the test, its primary use is with dynamic software analysis to help answer the question how much testing is enough, that means basically it will have an analysis of how much units tested in terms of dynamic software behavior or analysis, for dynamic software analysis is used to measure the quality and efficacy of software test data where the quantification is performed in terms of structural units of the code under test, that means based on the structural unit and its behavior or the functionality the dynamic software analysis is used, so it is used to measure the quality and efficacy of the software test data, when used to quantify the structural units exercised by a given set of test data, dynamic analysis is also referred to as a coverage analysis, so when we are done with the dynamic analysis we will also come up with the coverage analysis, so that is how this is done, basically to drive how much of the testing based on the test data is needed is what is being derived for the linear code sequence and the LCS is the testing, it is basically an LCS is the software code path fragment consisting of a sequence of code, that means a linear code sequence for the control flow jump and consists of the three items, basically a start of the linear sequence of executable segments, end of the sequence and target line to which the control flow is transferred at the end of the sequence, suppose we have function 1, 2 I am just mentioning with numbers like n is there, it is many number of function blocks or executable segments are there in the function, so what do we do with the LCS aj, basically how much I need to test for this block is what is going to tell, that is it is basically a code path, code path fragment like I may test 1, I may test 2, I may test some pi randomly n 20 may be n, so like this consisting of sequence of code is called linear code sequence, linear code sequence and jumping to the different linear code it is called as jump control flow jump basically, so what do we do, so we have a code path fragment consisting of sequence of code, linear code sequence followed by a control flow jump, so we start with this and then we will have a control program and basically the jump could be achieved with the following three types that is start, then end, we know that we need to have end for the function block and the target line, it means with the help of this target line how we have jumped to the end basically, it means the target line to which control flow is transferred at the end of the linear sequence, so with the help of this, this will be used actually, this is basically used where we have numerous functionalities having similar expected outputs and similar sort of inputs where we have few number of functions, so there it is useful, that is how they use it the LCSJ method okay, so in the continuation of this basically LCSJ method will have the ER, this is called as test effectiveness ratio, so what is test effectiveness ratio is that the good number of statements executed by total number of statements, number of control flow branches executed by total number of control flow branches, we have a number of LCSJ execution book or number of LCSJ, all together we can have a TER, that is effectiveness ratio that means how much of the code we have sequenced and jumped in terms of testing, so accordingly we will have this sort of testing, so coverage also we will take care of this, coverage analysis metrics are used to watch how much testing has been achieved, so the most basic metric is the proportion of statements, test effectiveness ratio 1, TER 1 is called as number of statements executed by total number of LCSJ, higher level coverage metrics can also be done, in particular the next level of TER 2 like control flow branches is similar to whatever addition or branches that we have seen before, divided by total number of control flow branches how much is there, so whether we are able to test it, whether we are able to do all these all these, so this TER 2 will give basically, with all the sequences whatever we have done, so TER 3 is number of LCSJ, total number of LCSJ, so these metrics are for pure hierarchy whereby when TER 3 is 100% has been achieved it follows that TER 2 should be 100% and TER 1 should be 100%, so aim is to have TER 3 as 100%, so that the number of LCSJs are up to the total number of LCSJs is become 100%, so this is a very traditionally old method, so both the TER 1 and 2 metrics were used in 70s and the third rates on the latest 70s, the requirement for achieving the TER 1 100% was the level of B1, used to be called as TERs when they define B1, TER 1, TER 2, TER 2 like this levels of testing based to mention, based on the safety and criticality of the embedded software, they will have a definitions of the embedded software levels, later they have added MCDC, modified condition decision code that we will study in the next slides, so it was added in 1992, higher levels of TER 3 100% has been mandated for many other projects including aerospace, telephony and banking, so where there is a mandate that TER 3 should be 100%, means this linear code sequence jump 100% mandatory, one practical problem of using TER 3 is that many LCSJs can never be executed due to the concentrated conditions they may contain, that means we know that we have different jumps within the sequence that is the start of the linear sequence of executable statement, end of the linear sequence and the target line to which control flow is transferred at the end of the linear sequence, so it is basically these three units may not be executed all the time, so it is subjective but it is mandatory. So here you see a sample of the C code and for white box testing of LCSJ, this is an example from Wikipedia and just use it here, we have a C code, having a library included here, this is library, this is we have a definitions of macros such as maximum columns, maximum count iterations as 750, then we have the main, here we are initializing a count equal to 0 and array totals of 26 and the value and local variable equal to 0, then we set the memory with totals, if there was a size of that integer, then we initialize count 0, then what it does is while the count is less than iterations, that means 150 times this block will be executed, value will be absolute of some random number, modulus, maximum columns, then totals array will be assigned with 1 and incremented, if the total of that particular value is greater than maximum count, it will assign the maximum count, then the count will get incremented, so that up to 750 times this will be executed, else this will not be assigned. So with the help of this example, so there is a LCSJ triple six called as I said start line, finish line, jump line, so there are 8 LCSJ numbers have been identified and start line is 10 for the first three, then we have the start line is 17 for the next three and 7th one is 25 and 8th one is 28, so based on this for loops, there are LCSJ numbers for that and total number of LCSJ are identified as 8, in the first one we will see start line is 10 they have used, then finish line is 17, that means suppose say 10th is a while after this they have used, 17th is the 28th line, suppose it is the last block, floor bracket, so between this whatever is going to happen, they consider as 1 LCSJ, similarly we have 10 and 21 and finish line is 17, jump line is 20, that means 10 and 17, so these are 10 let us say initialization and we have 17, 11, 12, 13, 14, 15, 16, 17 is the one and the jump line is 28, 18, 19, 20, last one, so likewise we are going to have start line, finish line and jump line, so they draw a tables for this, okay so that is about LCSJ, it is a quick understanding where they use the TES test effective measure ratio, with the help of LCSJ this they use the sequences, the linear sequence of executable when it starts and when it ends and the target line with the control floor is getting transferred and again, so that is how they are going to test it and you can see some of the table talks about the start and line same, you see which is same here, 28, 28 is same and so on, that is the last one written 0, it is same and jump line, the last but one, similarly we have 17, 17, jump line is 28, the last line it will come, if, sorry yes, so that is how these three aspects will be tested in the LCSJ type of white box testing, okay the last one being, I have added the purposefully this is because they use this type of testing in aerospace, so very important to understand, 178 testing, you say defense standards they use where the different levels of safety is being defined based on the decalitiy and safety level of the particular embedded software and the system, so for that type of system the defense needs to be managed, MCDC is called modified condition decision coverage testing, so let us quickly see what it is, so MCDC modified condition decision coverage testing, it is more used or applicable to space or aerospace or the defense and the process, to satisfy one of the key objectives of the defense and the B, also called as a truth table approach where logical expressions are being tested, so where we have maximum logical expression we use a truth table, so what is a truth table, we will study that in the next slide and then the example snapshot of B1 from B, I will just have a look into this, so basically the MCDC criteria announced the condition decision coverage, we know we have seen condition coverage decision coverage and condition combination decision coverage, this criteria it will enhance basically by requiring that each condition be shown to independently affect the outcome of the decision, same as the modified condition testing with the combinations, it is similar to that but with the stringent process they follow it, the independence requirement ensures that the effect of each condition is tested relative to other conditions, however achieving MCDC requires more thoughtful selection of the test cases, we need to have a truth table sort of approach but if you have a three variables we will end up with 15 type of combinations, we do not need to execute all of them, so that is why it is very important to select a good approach and select such inputs and suppose in general if n inputs are there, minimum of n plus 1 test cases for addition with those n inputs will need to be there, for example A or B we will have test cases, for example MCDC what we have independently as I said again n input A or B, suppose this is there then we will have some statements executed, so A can have true, we can have false, B also can have true, we also can have false, so what are the yes that we can do it, we show the independence, so the combinations could be T of FD and FF, so that the independence is done, we know that it is not required because it does not affect the independence and we have already tested when the A is considered as input true and A or B result in this true only, so to achieve the independence we need to have these combinations PF, FD and FF, this will provide the MCDC, you can add a true to also, this is subjective again depending on that, okay here you can see the decision comma MCDC testing what they used, so basically this is example snapshot of different processes and sections that it has, it draws a life cycle, D17B software life cycle it is called, this diagram is from one of the NASA document you can see the reference here and we have this many blocks, we have a planning it is spoken in the section 4, this D17B process as a different sections, against the each sections there is a checklist and each section we will identify different aspects of the MCDC coverage and the testing process, so we have planning in section 4, we have integral process which is the ring of evaluation, section 6 for integration management section 7, 4, 8, certification liaison 9, so this will be part of the planning that needs to be addressing, similarly the planning also we will take care of these blocks which is dotted here, the planning will especially about development aspects, so as part of the development we have requirements, section 5.1 decision, sorry design which is section 5.2 coding, it is all part of the section 5, so 1, 2, 3 sections are about definitions and other things, section 4 onwards the D17B has to be strictly followed for the embedded software development, if it is a D17B complied, examples like space and aerospace industries, so there are avionics subsystems, those subsystems need to implement based on the software level that D17B handles, so requirement design coding integration, these four sections are part of the development process that needs to be pointed out or supported with the help of planning which is in section 4, similarly the very important part is the integral process, which has four sections which will identify the verification process, configuration element process, qualifications, certification liaisons, so once we have this addressed that aspects of the domain system is called D17B compliant, further on the MCDC, the MCDC criteria enhances the condition decision coverage criteria by requiring that each condition be shown to independently affect the outcome of the decision, same as what we have studied in the molecular condition combination of testing, here with most engine D17B aspects will be addressed, the independence requirement ensures that the effect of each condition is tested related to the other conditions, means we have several combinations, so those combinations because once you have the code is executed and the piece of code which is responsible for some outcome will definitely needs to be tested and traced, so the rest of the other piece of the code will have to be constant, so the independence of this specific block will need to be ensured, how we are going to do is with the help of independence testing with the condition and the decision coverage that we have, however achieving MCDC requires some more platform selection of the test cases, as we will be discussed further in the property that is there in the D17B, you can have a look with the following link which talks in detail about MCDC, it is not a scope of this, we have embedded software testing because we are talking in general all these aspects, if further if you are interested may be in detail about MCDC for aerospace how they are addressed, so in general we know of N plus 1 test cases for a decision with N inputs, so example we have done ARB, so we have two false, false two and false false, this will provide the modified condition decision coverage or decisions with a large number of inputs where we have ARB, CDE, AR and all that, MCDC requires considerably more test cases than any of the coverage measures discussed above. We will take some examples, here you can see a logical AND gate where A, B, C inputs are being ANDed in this block and the result of this is there in B, so it is called a three input AND gate, that means there are three inputs A, B, C there is a AND gate here, you can see A, B, C is AND gate and D is the result, so this is how they represent the different gates, so that gate representation all part of the engineering curriculum where we have AR and all the stuff represented this way, these are all typically used in the requirements and against those requirements test cases will be written, so okay. So in this table whatever the number of minimum test for these three input AND gates are listed, how are they listed let us see, okay test case numbers there are about 1, 2, 3, 4 test cases are there, sorry three test case numbers have been specified, each of them considering one at a time, that means A as an input, B as an input, C as an input, also we need to have a D as an output as the fourth condition, so those many test cases need to be exercised, what are the tests that can have for this MCDC, first one A, B, C are provided as T that is true the output will be true, similarly A, B, C is provided as input as false and B as true to the output is same, output is false, similarly third one we modify B as a false and A as true, output D becomes false and in the fourth case the input C is provided with the input as F and the output is F, so basically the output is depending on the false conditions that can be driven either through this, this, this, so is it because of C only the false has come, how we are going to exercise by providing the input C, F, suppose if the D is providing false in any case, how are you going to test for A and B, so in that case C we need to test it as true and in the next test sequence we are going to put A as true and B as false likewise we are going to have a table, this table is called true table, that is why the MCDC approach is used for searcher expressions where we use and we have all the above, so these many tests we are going to have, one test will take 1, 2, 3, 4 values sorry the columns, first one takes all the consideration as true, second one all the considerations as different values the output is same in 2, 3, 4 whereas the output could be derived due to independence in either A, B, C, so that is how MCDC to be released on and the test cases are done. Let us take another example, here we will go through 3 input OR gate where A, B, C are fed into an OR gate and result of the OR gate is D, in the previous example we have D gate as sorry D as an output derived from the AND gate, so what are the test cases that we can draw, so we need to consider input A, input B, input C, in order to achieve output D what are the conditions that we need to exercise, so this is the table which talks about minimum test that we need to have, in the first test case we are going to have input A, B, C all are as false, the output will be false, in rest of the test cases we can see 2, 3, 4, the output is always true why because one of the input is true, right, so why it is called as a minimum we need to understand, we may have one more say suppose if what is the other combination we can have, do we have true, true, false, do we have false, true, so basically which is the denoting factor here not be false, right, the output is derived purely based on the, the output true is purely based on the fact that any of the input is true, so we need to derive any of the input, in the first case any can become A, the second case B, the case is C, so other cases like both cases A and B true does not matter because already we have seen the output as true, so this is the minimum number of tests, of course depending on the expression condition we can have more, but it is like a TDS relevant selection, but as far as the entity is concerned the independence in need to be shown, how we want to show independence is, for each of the input that is responsible or effective in terms of the output or to be driven, similarly we have seen any of the input in terms of false will result in the false as output, so does not matter true or false or all 3 are false always the result is false, the independence will be shown with the help of each of the inputs. So likewise we can have for XOR not comparators as inputs that is used in the logical expressions maybe you can take an exercise for XOR and not, so not is very simple you know that not of the A equals B, similarly A XOR B, you know the true table how to draw because logical expression you know, so you can write what are the minimum tests that are needed to test this expression the first one and the second one, so this is an exercise, so that is about NCDC the most important method that is you know the O incident B bicycle process, okay, so that is about NCDC I think we will continue the other aspects of testing in the next session, we will go through some of the words that we have added maybe what we can add today is NCDC, okay, D1 incident B, testing coverage and all are part of the study, same thing we have missed CSAO, then we have test is inputs, outputs and all you know, the trans condition testing, trans condition combination testing, Boolean operands, so what we do is we will add the more words today, if you have studied NCDC is not used, Boolean expression logic, okay so rest of the words like branch condition, vision data flow, timing analysis, analysis I think timing analysis, analysis, performance analysis, working on test, we will study in the future classes, NCDC we have seen, Boolean expression logic we have gone through, some of the recent sessions we had on OC statements, coverage, model based testing instrumentation stuff, I will not go through all the things but to have an understanding about the limits of the testing, we need to be aware of the knowledgeable of this type of testing. So let us study about a few of the glossary is referred from testing standards book, physical test case, detailed description of a test situation or logical test case, component specification and the expected results explicitly defined in concrete values, a level of detail is such that when the test is executed at a later stage it is done as efficient as per means we will have the complete steps in terms of values and all that, so physically we will lay it out in a descriptive manner, so that is nothing but physical test case, the environment, the environment normally they are not used but in the production and the testing plan, test plan, etc, the environment that interacts with an embedded system, precondition is a very important term, so it is an environmental and state condition before the component can be executed with a particular input value, that means without the preconditions, test following that precondition cannot be executed, preconditions have to be there in place. Rapid prototyping this is a development test level, okay test level where a simulated embedded system is tested while connected to the real environment, means rapid prototyping testing is a test level, the system embedded system is something that is tested which is connected to the real environment, it could be on a host, real time system, system where correctness of the system behavior depends on the exact moment when the output is reproduced, that means where the time is very hard, it is also called as hard real time system, real time systems basically deals with the behavior where the different events that are going to happen within the embedded system should be happening at the right time exact moment, for example real time embedded systems, we have X-ray machines where a user presses one button, so it should respond within certain time or that moment, so that sort of a systems we have in the embedded system implemented, regression testing is very important term as well, retesting of a previously tested test object following modification to ensure that all have not been introduced or uncovered as a result of the changes made, that means we have found some issues in our first or primary testing and that is been fixed either in the requirements or design or in the implementation and the same test without modifying need of test suit or test environment or test cases, we are going to test that piece of the fixed core and results we are going to achieve in terms of test being passed, result we know that actual result or expected result, actual result is what we get it on the system when it is subjected to a specific test, the expected result is what being expected which is put as part of the test case design, risk it is a chance of failure into damage that means while doing the testing, testing of the embedded systems it could based on the inputs or the robustness or the load that we have on the system, it could impact efficiency or the behavior of the embedded system and it could result in a damage, so risk is considered as a chance of failure multiplied by damage, risk reporting description of the extent to which the system meets the specified quality requirements and the risks associated with bringing a particular version into production including any available alternatives that means we have mitigation, how we can de-risk those aspects, all will be part of the risk reporting. So with that we will end this presentation and we will take up the white boxes some of the pending testing in the next session.