 the next in the next lecture of testing this lecture 10 this is in continuation of embedded development life cycle and testing life cycle and different types of life cycle like V model multiple V model etc. so in earlier session we studied about real life cycle what are what are the entry and exit criteria that needs to be understood and what is the dependency how it is going to enter how it is going to group and we also studied about two types prototyping life cycle and formal life cycle and example prototype life cycle we studied just glance through the session what we had in the earlier class this is an example of prototype life cycle having entry and exit as a finalized prototype with the finalized SRS greedy source code testing aspects which is enough for going for the formal life cycle a formal life cycle we know that it is a v shape why because on the left hand side we have finalized requirements of specification then we have a design next to that then we have a coding then in parallel to that the various aspects of testing have been carried out specification is a high level testing but design is a integration so coding it is code or unit testing so that is what is called v-model as part of the exercise that we do testing of these levels produce the test result so that is a formal life cycle after we are done with the example after we are done with the prototyping so this is another way of depicting the v-model life cycle each life cycle elements have its own process like the process has to have to be having a objective scope entry inputs outputs and it is defined for each of the process that we follow life cycle and in our session we understood about each of this process items taking an example of test plan where we identify objective to prepare a test plan scope is the project preparing the acceptance testing then entry we do with a high level requirement specification project plan also is taken care then we have the inputs as a service project plan outputs as a baseline test plan and feasibility exit is the outcome of the testing what we do preparation is that this plan is outcome along with the test ability report also we went through consumer lifetime spot life cycle example and we defined a sample chart other the general entry and exit criteria for embedded software testing so testing life cycle we studied taking an example of automotive testing system requirements study test planning test execution and the defect movement which also involves a test automation package release package release then the test conclusion of a test program so each one these five phases have its own process each of them we studied about its objective scope and inputs outputs and exit will not go through in detail because of the console is in detail as it is applicable in the future this is taking an example of automotive process how they follow for testing the embedded software also we studied about some of the embedded software words we will touch with this again and again so that we are aware of this also we had a few questions as exercise so that is about a previous session now we will with that background we will go through the next session okay we know that we model life cycle how it is once we have laid out we model life cycle there is another variant of we model life cycle that is called multiple we model life cycle why this is required what is the importance of this okay so the essence of multiple we model life different physical versions of the same system of developed that means you take an example prototype we might have prototype 1 2 3 etc so it is a different versions or different feature wise products as a prototype we would have developed each one possessing the same required functionality that is the minimum functionality has to be there actually because the end product what we are going to develop is the same but there will be a multiple variants versions in terms of a physical outcome this means for instance of the complete functionality can be tested for the model as well as for the prototype and the final product on the other hand certain detailed technical properties cannot be tested very well on the model and must be tested on the prototype that means the end once we finalize the end model you may not be able to test some of the technical elements of that product so we may have to go for testing on the prototype itself for instance the impact of environmental conditions can be can best be tested on the final product but we do not have to do it or we may not be able to do the environmental condition completely so likewise we have a scale level or incremental way of having the model used testing the different physical versions of require this product requires specific techniques and specific testing on it we know that different products will have a different I mean deviated slightly on the aspect therefore a clear relation with the multiple V model and the various test environments so the system is developed as a sequence of systems development that become more real in the end so we have a subsystems it is called multiple physical versions it is called subsystems usually these are model prototype and final product could be anything what we develop so the multiple V model based on the well known model it is also called SPIL or RACU program is a development model that means though it is called as a what is that called life cycle elements requirement design coding testing all together it is called as a development model with the fundamental multiple model is based on the V model in principle so each of the product appears for us in complete V development cycle including design code test we have a different variants of the prototype developed as a multiple V cycle so that is why it is called as multiple V model this is typically used in production environment where they may not be able to conclude on the final end product or they might not have designed such a way that one go they will develop the final product what they do is they will first identify the basic V model in that again they will identify subsystem V models so all the subsystem V model comprise into multiple V model life cycle so this is a master plan sort of thing we will definitely study about a master plan maybe in the next session okay so this figure you can see how it looks like model V development life cycle we know that we have to read one V in the earlier session it could be for a model or it could be for a prototype or it is for a formal one so each one has a design source code development and build and testing design build test so you can see three V here three V models only a small one and the medium bigger one so it does not mean that it is same actually it can have a different aspects like we might have a detail design or low level algorithms and all the stuff taking care in the bigger one and the smaller one may not need it again depends on the what sort of a development we are going to adapt so basically the model or initial prototype will have a smaller V model life cycle whether the prototype will have to be so I have put yes that book is mentioned as yes why because there could be multiple prototypes having feature set features set one in the first prototype and first prototype having features set one second one having feature set two third one could be having feature set one plus some changes or you can call it as set three what could be having feature one two three partially etc so all this can be their part of the prototype so we can have multiple like this so I just drawn in between it can have multiple V models before we draw on the final product so that is the meaning of this multiple model life cycle again tell that it will be having multiple development life cycle defined for each of the variants like we have an initial prototype defined as a model off hand work feature set prototypes something like we users will develop a proof of concept application or the feature like features set one two three etc and accordingly we will have a life cycle all this together we will try a bigger V model that is as a final product or a formal V life cycle we can call so this also can be part of a usually this will be part of a last plan you can call this as a one single having multiple V so okay so in multiple V model life cycle we have a testing activities below which basically divide into three categories they are test techniques test levels and types and other issues test techniques test level and types and other issues so these three categories basically we divide the V model test activities each is then put in one or more Vs at the relevant stage of it that means basically we will identify all these categories then we will apply into each of this so that is how it is been done for it to strike so we will study about each of these three categories so you can see this table techniques test level types other issues is actually this whatever model V model multiple model and in the next slides I have later V models these are all basically derived from the testing methods of their book by Vart Kruppman and Edwin Nodboom because there are several techniques but this is a book that is being referred for this course embedded software testing here okay so test related activities and issues that need to be allocated throughout the development and testing life cycle what are those here development and testing development also can be having some of these tests because developers as a tester is very important for embedded software testing I will explain that in as a developer as a tester how it is techniques so what are the techniques that we have that should be considered for multiple model and these specific to multiple V model code coverage analysis control testing, fagin inspection, failure mode and effective analysis is also called as second fault injection fault analysis, formal verification, interface testing, model checking, location testing, random testing, rare event testing, simulation, state transition testing, statistical research testing these are the techniques that are used or can be considered it need not be all some of these based on its applicability and corresponding test level for types where they can be applied for example code coverage analysis can be applied for design verification control flow testing code review so there is a term called control flow or control flow and data flow so some of the very important items that we need to be knowing for embedded software testing in order to understand control flow is basically the controlling also or the way how the program is controlled the main software product is getting controlled in terms of the logic or flowing on the entire system data flow is where data how it is getting flowed on throughout the structure so fagin inspection it is a type of inspection method maybe I will we will discuss this some detail later for confirmation test we follow this FMEA for our design application fault injection where we have integration we inject signal errors or any data errors in terms of system and we do the integration similarly FTA fault this involves host problem here what we do is we do an analysis of the fault so what is the root cause of a particular fault so where it is going to hit that means if I inject an error where and all is going to impact this needs to be analyzed so against the requirement definitely requirement will take care of the fault recovery and fault detection and recovery mechanism all this will also affect test in terms of fault analysis formal verification model integration test interface testing field test then we have a model checking with regression test requirements verification software acceptances integration system integration unit test so these are some of the test levels or types so based on the type of product that we use these test levels types corresponding to the techniques we can use it and we have other issues as that category architecture design certification detail design design and build tools design and build simulator design and build stuffs I will explain about stuffs in electrical design and build tires design for testability this is one of the very important thing that now almost all industries they are following especially product part companies like Samsung in the design phase so they will identify the testability part that means whether this design can be tested so without that testability design is not complete or design will not have full proof mechanism so they need to have some sort of a design which will support or help testing that could be test hooks or it could be a test stuffs or drivers or test monitor whatever test and of course we have high level requirements, low level requirements, master test plan, we will touch base master test plan production requirements release criteria so this is the third category and so this is a complete master list of three categories this are need to be considered before we take up the multiple view model those techniques levels and other issues can fit into any of this I mean basically we need to draw a picture when we do the view model multiple view model planning all this have to be considered so that is the main thing about multiple view model so now we consider only the first one model multiple view model applicability for model that means what are this is an example out of this how much we can draw for the model so that is the thing but allocation is called allocation of test related issues of the model so low level requirements and verification detailed design specification design for testability so all this will be on the left hand side as I said the view model is and corresponding to these requirements we have a full criteria we have a integration model integration we have a conformance test we have a test these are the some of the selected techniques test level types and other issues so for this so what is the outcome like we have a simulation we have a very state transition testing model testing these are some of the activities similarly on the left hand side we do FMEA, FTA, conformance specification for infrastructure so this is falling outside the view on par with the model so this is the applicability how we are going to draw this master table okay another one is view model applicability for prototype what are the categories that we can use for prototyping view model here again outside the view we have a techniques in terms of FMEA, FTA, FTA, conformance specification within the view we have low level performance detailed design plus verification requirements design for testability then on the right hand side we have any test at the bottom host target based testing we have software integration software acceptance then we have hardware software integration then we have system integration then we have the package release on the right hand side so this can go for multiple testing based on the bug fix and all that through the help of regression testing and also we as a result of that we come up with the coverage analysis it means how much we are covered what is left out what is pay what is pass what is fail it is a code code analysis statistical usage testing so this on the right hand side is all about the techniques what we apply for this prototype this is an example of prototype view model when it comes under the multiple view model life cycle final product the formal product how we can apply the multiple view model product requirements that means end product requirements detailed design and because code and all we already taken care in the prototype so final product we leave with only the requirements and design and in terms of releasing or deploying the product to the customer we have at least criteria acceptance and all that certification is important especially the products are going to be fitted in terms of safety aspects that needs to be taken care certification like we have the ones and it will be from designated authority from Airbus or Boeing automatically we have others are on par with this certification process and in terms of the techniques statistical so this will be applied before we complete the view model this is allocation for final product or the formal product applicability so that is about multiple view model where we have initial prototype final product have been organized into multiple view models each one having design code test design code test finally we are going to have the final or the formal product and its applicability is that on a master list of techniques test level types and other issues okay the next one is nested multiple view model we have studied about view model we have studied about multiple view model then another term called nested multiple view model name itself tells the multiple models are nested basically definition is here when the view model at system level is combined with the multiple view model at component level it results in the so called nested multiple view model so the meaning is that system level we have a view model it is combined with multiple view model we have seen having prototype final and before prototype so once this is combined at the component level so we have defined the system level the component level is multiple models it is so called nested multiple view model so we have an example here you can see this is a multiple view model 1 multiple view model 2 n etc so component 1 component 2 component n this is nested under the one view model so this is an example of how one example of taking a component as a multiple view model at the component level so parallel development is also called as parallel development view model in continuation of that then nested multiple view model all test related activities and issues can be allocated to the correct level in the correct place that means whatever we identify testing activities it should be applied for the particular level the component 1 component 2 component 3 specific test will be applicable for the specific view whatever we have followed with the multiple view model so at the system level higher level test issues can be allocated the overall development cycle this is one more big 3.7 we have seen parallel development in terms of view model component 1 2 3 etc when it comes to nested multiple view model the system level best related activities can be allocated to the correct level for this actually you can see in the bottom little test plan legal requirements design and build tools emulators stuffs etc all this will be applied that means this is common same thing is going to be applied for view model 1 view model 2 view model 3 as an example 3 we can see that each view at the system level or component level is applicable three times you can see so high level test issues so in the multiple view model as an example is taken care here that means we have a master test plan safety plan we have at least applicable for all this as a bigger view model so when it comes to the individual view model this portion is taken care of in a nested model same thing is depicted in the similar way here because 3.6 the multiple view model components put together it comes to high level test the common line is basically so the multiple view model with the 3 sequential vesicles does not take into account the practice or functional decomposition of the system the development of such is from start to execution by an active design base where it is determined which components hardware or software are required to realize this and those components develop separately and finally integrated into a full system in fact the simple view model can be applied to this development process at a high level the left side of the view model hands the decomposition of the system into this component the middle part of the view model is for parallel development cycles what we have seen here for all the components the right side of the view model integration of the components so if we do this the left hand side of the view model hand the decomposition of the system into various components as we said high level requirements design low level design coding etc the middle part of the view model construction development cycles like we have a prototype 1,2,3 components parallel the left hand side we are going to have a validation or integration of all these aspects so this principle can be repeated for components that are too big or too complex to develop as one entity for such component an architectural design activity is carried out which components are required we need to have an architectural design so that will identify how many components are required to make the system work so this also could result in another view model within the view model we can another view model so that is why it is called multiple view model multiple view model is not only helpful when it has to be planned and executed for a completely but also in the case of your users of a kind product so in fact the development project for a product is about the new release of just a few components then the multiple view model and the full or the master plan the development of the complete product can help to identify the relevant activities so basically when we have a complex or bigger systems what we do is we go with the parallel development of different view cases and as I said on the left hand side we have divided basically into components we have divided the system into multiple components so the middle part we will identify the cycle for each of these components and the right hand side we will have the integration so on the left hand side of the article or master view model what we have decomposition into subsystems or the middle part we have the parallel development of each of the component for each of the on the other side we have the integration of all these subsystems so that is the significance of multiple view model in context with the listing so basically these are used in bigger or complex systems numerous features identified for numerous components so that is the significance of multiple view models applicability in terms of nested nature having understood these models different types and their activities categorized now we move into testing aspect irrespective of who or whatever the model we call so we know that host and target are available for both the testing as we have now taking into consideration how testing can be done by developers how testing can be done by independent testing and there are few principles so that we will go through in the end testing by developers so we know that systems are developed by larger teams sometimes divided into teams into multiple allocated subsystem teams or it could be physically separated we know that bigger systems or complex systems like our embedded systems or aerospace embedded systems are not developed at one side it will be geographically separated though they have an interconnection and all that the team the testing environment or the components or the lab and all that will be separated so the developed systems are large and complex but alone puts quality under pressure that means all should work in tandem make sure that they work for the quality and the end result that is for the product the demand for the quality is increasing in the competitive market of the user systems safety critical system so two aspects one is a competitive market because there are several developers available so we need to come up with a good quality also there is a safety aspects taken care so in order to avoid so at a later stage so better to do a testing little thoroughly in the starting stage or the beginning stage so beginning stage we know that there will not be any testing or formal testing though there are test plans and all that so the best way to do is testing done by developers so that is the background of why testing we need to have it with the developer so what are those the existence of an independent testing does not mean that testing during the development stage is less important that means it is equally important to have a testing done at a development time both teams have their own important role in the preparation of an end product with the desired quality it means they have their own whole testing team the independent testing whereas the developers as a tester have their own product should be having a high quality that is the desired goal an independent testing in general executes tests based on the requirements their purpose is to provide confidence that the system computes the requirements so they go by what you have specified what the product is supposed to do what you have documented what you have specified in the requirements they just go by that whereas in contrast to that testing at the unit level because they are very near to the input and they are the owners of the unit because they have developed because simply they own it and they are having the knowledge that means they know about the infrastructure of the company this knowledge is used again to test the integration of the different units the purpose of delivering the stable system so what they make sure is they develop the unit the piece of software and since they are knowledgeable they use the same test bench or the develop or debug environment to test it in terms of unit level or in terms of integration so to attest two things one is a quality so that there are no bugs creeped unknowingly second thing is the system that they developed should be stable so those two purposes are attained with the help of what we are testing at the early stage that is why we need to have a testing by developers the early stage of the development so continuation reasons why testing by developers is important early detected where defects are in general the cost of fixing defects is rising time we know that we have seen a chart where the cost arises we go deep into the product before we release the product we cannot afford to have bugs or issues at the end stage expensive high quality basic elements make it easier to establish a high quality that means the basic elements you put it right in the beginning only so the end product the whole product will come to an unfavorable system and this can't be solved practically by functional test that means you would have creeped some quality issues small small small into different elements in the beginning in the end it's very difficult to protect some of the bugs that were introduced because of the low quality during the development defects detected during post development stages are difficult to trace back to source as I said we cannot afford to have small small defects during the development stage so it is difficult to trace it back so better to identify in the beginning only defects detected during post development stages have to be corrected and this will lead to time consuming regression test that means we need to have a regression again and again the of excess that have been done on the product again need to be tested good testing during development stage has a positive thing for the total project time that means we have the components we have the productivity reliability etc done in the end stage because of the good testing we have done in the development stage the state testing of exception and possible equity level where exceptions can be I will tell about exception and interrupt some of the later stages because this is a new system development mode you may call it as an interrupt as a result of exception exceptions are somewhat unknown behavior of the system of certain conditions at the unit level or the source level basically the latest stage development may not be possible quickly to do it testing as well as fixing at the latest stage that is why we need to have some sort of testing done development of the product that means basically quality may not be or cannot be added to the product at the end by testing it should be built in right from the start taking the quality at every development stage very much necessary so how we can do is by testing testing is not pursued by many developers they are in task they are in development developers are seen ignoring the test aspects they will never care about testing aspects we need to have testing thinking testing the thoughts while doing the development so to keep the test effort for developers is a good practice it should be effective and efficient to do this integration development also will have integration studies are we can anyway we have seen some of the things we can go through that again sometime in the next sessions so essentially all activities have to be planned and should be controlled so that is the build from of testing by development testing at development stage okay now testing by independent testing we all know that the testing is an important aspect there needs to be testing plan testing procedure we have a test plan also so we will just go through that what are those testing by independent testing independent testing are mostly occupied with the high level test as I said they go by the high level test having requirements or specification are important these tests occur at the end of the development we know that development life cycle is getting closer the testing activity will start the test activities of these teams are the critical part of the development process that means it is very important element in the critical path it is an critical part it is an item that is under the critical path of the whole life cycle supporting activities activities have the objective of keeping the time for testing execution to a minimum it means whatever the support activities we need to have they have the objective of keeping the time for testing execution to a minimum that means when we are doing the development we identify test activities and planning so we do small test books and all that as a support we will have a predictable time how much it is needed for test execution atleast a minimum how much it is needed for each of the tests that is the idea behind supporting activities supporting activities are kept outside the critical path by executing the parallel with the development as I said support activities test books development and the strategies parallel development all taken care and separate activity supportively for development and the testing so this will not be a critical path but it is used while testing execution or actual testing is happening which is under the critical path formal life cycle for independent testing basically what are the formal life cycle items or phases for independent testing planning and control phase preparation phase we have a specification execution completion this is basically different phases that is being changed here these are all mapping to what we have discussed in earlier classes other way but in terms of formal life cycle for independent testing taking requirements as a input and doing the high level test they have to plan and control they have to prepare they have to specify they have to execute and complete it so these are the phases that are used for independent testing this is basically a formal what is described here because this involves including the test management and development lead also will be involved because he needs to know what works, what needs to fix so what is the test how it is getting passed or failed so most of the information needed by the testing for the product from outside the testing that means whatever the need for the product should be provided and the expectations as a testing sometimes the outcome of the test process is subject to an external audit that means there is a separate audit that is taken care against what is being specified so there is an audit team or the independent team who does audit on testing also is that important actually I think I can mention this independent activity to audit the adherence process again as to what is specified in plan or specification of the test aspects so any aspects of the life cycle it can happen on the test management audit can be done on the test management development and their activities quality etc. to get confused with audit and quality quality is a different thing audit is a different thing so these are some of the formal aspects that are used so that is about testing by purpose testing by independent team now we will move on to 10 principles of embedded software I think I will take up this in the next session as we are running out of this session so I will go through the words which we have done before so we model a couple of words I would like to add control flow data flow what we have is audit if anything is needed we can add it test harness test bed test bench 80 model based testing test drive test CD break points simulator simulator phase profile data sheet editor eyes in such a simulator static analysis then books reverse engineering we have life cycle interindexed criteria baseline prototyping stakeholder remodel control flow data flow audit we can do it I think we are taking care of all this remodel we have used so that is about some of the words why these words are going through each session is to have this in mind as a tester so that we will not forget this will be part in part of the embedded software testing that is why it is important to have this okay so we have a couple of questions what are the differences between remodel versus nested remodel multiple remodel so the total difference between a remodel multiple remodel and nested remodel what is the significance of nested remodel so why we need it so we have discussed about this please answer these questions so that is about this session next session next class very soft