 we will go to the next session of embedded software testing, unit 3 static analysis, code reviews, and metrics today's class is about continuation of the static analysis and code reviews and these are lecture 4. So before that we will go through previous session what we have done with the foot click. so stack analysis is one of the important static analysis aspect so stack memory has to be allocated while building the embedded program and it cannot be underestimated as well as it cannot overflow so to measure that we need to do an analysis the measurements can be done in different ways so we need to have binary executable the map file so with the map file we can do offline analysis of the in terms of stack again it depends on the type of system that we are using and stack workflow is one of the issues we have in stack analysis so stack workflow will be related to a correction of data and machine exception and unpredictable program execution as after exception likewise so and we intended the core framework during execution of the program for different reasons the reasons could be a hardware would have failed such as memory interface or the processor etc software development error that means the programmer or the developer would have introduced a unbound memory as such errors in the program that will be to the software and unintended software behavior that means software has some issue currently it is becoming unintendedly so that is one of the reason memory corruption primary is not written properly and there is a single event upset due to which stack workflow would have happened so likewise we have different reasons for the stack workflow this needs to be analyzed so as per the ISA guidelines stack workflow need to be taken care such a way that the analysis is performed to different whether or not it is necessary to perform continuous stack monitoring that means it is part of the building program or not if continuous monitoring of the stack perform in real time when the program is run with a specified task allocated for it a tiny program or a tiny slice of time that can be used and the monitoring mechanism should be part of the requirements in the event that the monitor takes an workflow the expected behavior should be specified and visited accordingly so that is what the ISA guidelines stack workflow the next one is the coding standards this is a one of the important aspect that many people will not do or will not follow this should be done by the IV&V the independent validation verification team in order to check that the coding standards have been followed so where the coding standard is important is that there are high chances that that due to a misinterpretation or violation of the coding standards or rules a program can have bugs to avoid that there are different guidelines and resolutions so one of them have been highlighted here and it is recommended to use some words and tools such as Misrasee checker and Misrasee 2004 rules so there are different types of standards and guidelines that it recommends in terms of the complexity of the program a poor coding standard can worse can be worse than no standard so better to have a standard the common objectives of the coding standard is reliability,quantability,mentability,testability,reusability it should be extensible and readability that is very important so that the code is maintainable so sample rules so we had seen like we cannot have multiple footmen for the single line readability is lost and we cannot have a macros except the source control identifiers should have been provided with a descriptive or meaningful names and the function lines cannot be more than 200 lines difficult to maintain and the scope of the identifiers should be very clear such as declarations shall be declared in the smallest possible scope and typecast should be used only when required not always and the precedence is one of the important aspect of the programming the precedence rules have to be well controlled and increment and decrement operations should not be used within the sub-expressing so these are some of the rules that we have seen in the earlier class today we will see about continuation of the static analysis and code reviews okay so coding standards coding rules 4 of 10 this is one of the good guidelines given by Michael McDougall he recommends the 10 good rules if you follow definitely your program is matured and fans of bugs are very much avoided in terms of the trivial issues that could have been thrown in by the programmer of the coder okay what are those the power of 10 let us try to understand restrict to simple control flow constructs that means the control flow construct should be as simple as possible try to break a bigger complex programs into smaller constructs that is what it means the first rule is about do not use go-to-statements set jump wrong jump or recursion so recommended to avoid these things second rule these are called as golden rules by Michael McDougall so second rule is about give all loops a fixed upper bound definitely we need to have for loops but with a fixed bound where it is going to complete always going to end for example we have a for loop I is then 0 I plus plus we should not be completing here I should end with 10 or 100 whatever it is and better to avoid any expressions such as some constant value or something like that constant expression so this will definitely lead to a upper bound and upper bound used in the for loops or while loops the next golden rule do not use dynamic memory allocation after initialization so we know initialization is very important any variables or objects that are to be defined should be initialized using the initialized function once we have initialized a variable or memory or any program flow constructs we should not further work on the re-initialization of the memory especially that's what it talks about so better avoid this kind of an allocation that is how much memory is going to take during the program execution you fix it in the initialization and allocate accordingly so do not use dynamic memory allocation but dynamic memory allocation is a big chapter by itself in the embedded software systems some people are for having dynamic memory allocations because they don't know the behavior of the program so especially where they use a C++ code there is a free new and all that sort of a dynamic memory allocations are available but it is recommended to avoid that as much and especially after initialization if at all using the dynamic memory allocation don't use again that's what it means okay the next one limit functions to no more than 60 lines of text so we have seen 200 lines in the one of the guidelines but Michael McDowell says 60 lines is a maintainable code are a good enough number of lines for an embedded system function text here means an executable lines of code or executable object code it's also called as lines of code lines of code could be having executable plus commands what it means here is programs so better avoid more than 60 use minimally two assertions for every function of more than 10 lines so if a function is having more than 10 lines minimally two assertions have to be there that means every function should have two assertive statements minimum if it is more than 10 lines 6 to 1 declare data objects at the smallest possible level of scope that means if you have a innermost levels or the scope you are going to define within function within function circumference likewise better to declare if it is required to be used in the that level so use that within that level of scope any declaration of the data objects which is going to hold the data next one is check the return value of all non-wide functions you know void functions in non-wide function void for void functions will return nothing 0 depends on the system again it could be 0 non-wide functions will return any non-value so check the return value of all non-wide functions and check the validity of all functions so this is a golden rule very good should be applicable for any standards that means the parameters whatever we follow or we pass within the function parameter 1 parameter 2 so like this we have a declaration right parameter n is a declaration and here we have a return suppose return is some inter x x could be a better word some signal so it will suppose to return a signal and we need to check whether it is a right way it is getting done the value that it is going to return especially for where we have a return with some value that is nothing but non non-wide functions and also we need to check the validity of all function parameters that means parameter that we are going to pass and use within the function better to check whether it is rightly defined and used that is what it means so next one is limited use of pre-processor to file inclusion and simple macros it means pre-processor lines are there right like include and any macros etc so all this you avoid to use only for file inclusion includes for example we have a stereo IODH and any macro like I define debug could be true so simple macros like this and any inclusions file inclusions only use it is limited basically not more than this actually there are number of pre-process like while loop for loop if and all that so try to avoid have simple macros that is what he says so it is better maintainability and chances of bugs are less by having a simpler macros but complex programs may need but better document it and use it as per the need with the control of the developer or the programmer next one is limit the use of pointers so pointers is a very important aspect in the embedded systems which points to a memory where it is getting referenced when it is getting used so try to use as simple as pointers in terms of referencing it and try to use arrays variables and all that when it is absolutely necessary use it use no more than one level of the referencing per expression that means we have a referencing and de-referencing of pointers but it do not use more than one level for the de-referencing of the pointers so limited last one being compile with all warnings enabled in pedantic mode and use one or more modern static source code analysis that is what source code analysis we have seen we have studied like in terms of understand process for poly space or anything so use that and try to analyze whether any warnings any violation for there and in additions very very important to have the compiler throwing warnings or info or errors getting fixed that is very important so we need to have the compiler giving the warnings we cannot disable the function in compiler because warnings could lead to a catastrophic error or catastrophic issue because compiler won't care about that whatever the user asset that it will going to do it so better to take out all that warnings that is what it pedantic mode it means disable it and use one or more static analysis to analyze any of the code is there complexity of the program is how much and all that will be taken care so that is what is about the 10th rule so this is what classic coding rules that needs to be followed if this is followed appropriately definitely the chances of program being having errors are very very less that is what based on make a mental inputs is been taking care okay so that is the end of coding rules and code reviews now we will come to the embedded software program reviews inspection and process is very important part of the static analysis is one of the important topic for embedded software testing so we need to have a right method of reviews right inspection and process so that during the review we will bring out all the program or any of the elements of the embedded software system so very important to have reviews inspection and process so each development phase is a each development phase is a translation from previous phase we know that phase to phase and how you move between phases we will generate few work products right we have seen the entry and exit criteria so each exit criteria will result to move work product so we know that we have embedded systems developed in the phases each phase will produce the outputs or any products or by products from the review it could be any of the development phase and it is purely based on the translation of the transition from entry to exit so as a result of exit as an evidence we know that some product by product is being done or delivered so that is what it means this is transition need to be tested how we are going to test this transition is proper or not is called transition or phase transition the result of this there are several artifacts that is going to come up that needs to be tested tested in those are something like document or code or any of the analysis anything so all this need to be tested so test we will do with the help of review or inspection or walkthrough there are different type of reviews we will carry that one by one okay so we know that in early stage of the development cycle majority of all the defects about 50% of all the defects comes from the requirements or the specification function specification and a review process should prevent the defect migration that means the review process will prevent the defects at the earlier stage the cost of defect migration to the next stage is much higher bond finding defect in the phase where it was introduced at the next stage it can cost an order of magnitude more than and an order of magnitude more again and again at the stage after that so we know that every stage we pass on so the cost will go high as we get more issues so the cost is maximized if error is detected after the product is shipped to the customer and minimized if the detected if it is detected in the phase where it was introduced so better to trivialize the defect when it is introduced or when it is injected as soon as it is done and avoid or reduce as much when it is going to be shipped or when it is in the process of shipping to the customer okay so we know there are different phases of the life cycle in the embedded software system just repeat it could be a requirement specification function specification design specification code users guide that is a release then test plan specifications these are typical embedded software basis so we know that requirement specification phase the purpose of the requirement phase is to ensure that the users needs are properly understood before translating them into the design in the requirement specification the purpose code performance of the requirement deliverable or clearly defined acceptance testing is performed against the user requirements so all these artifacts needs to be reviewed the next one is a function specification the function design is the process function specification or design the process of translating user requirements into the set of interface specification or the function specification the function specification the scope characteristics and performance criteria of the system in terms of hardware and software that meet the user requirements are clearly defined so system testing is performed again so basically this requirement specification is user testing or a acceptor testing function specification against which we will test at the system level which is nothing but the system so definitely there are products or by products of these specifications that means to have a review or analysis the next is the design specification so the internet design is the process of operating the system requirements into the detail set of data structures data laws algorithms anything it could be so in design specification the most appropriate physical solution positioning against existing architecture and applications to meet the update system requirements are clearly specified component testing is performed against the architectural design or low level design is also common and the component testing is done with the help of the code also it will use the database with the help of low level design so next is the code code is the process coding is the process of translating the internal design or specification low level design into the specific set of code so what we are going to check in the code is are there any reference data reference errors data declaration issues computation issues comparison issues control flow errors algorithms calculations control flows then what else interface errors input output errors data flow data declaration references all these are part of the code and against check against that should be done when we do the review review of the intended code the next one is the users guide so basically every software product that is delivered to a customer comes from both the executable code and the user model so basically executable binary they are going to deliver and how to install and how to use the embedded software code on the target board has to be instructed properly to the user of the system that is nothing but the user manual it is also called as user code or which will be having the working sections how to use it so this documentation is known as important than its code so equally it is important like code because its quality is a significant factor in the success of the success or failure of the product from the point of view of the user if the manual says do something and the user follows this instructions and if doesn't work it doesn't really help that the code is in fact right that means there is some issue it is not being behaving what is the document so that is what the user document or the plan is required test plan we know what are the aspects of the test plan it has to have all the stakeholders and who is going to test what is the schedule what is the environment all this will be part of the test plan like tools cost and i mean the schedule how long is going to take what sort of a level of testing is going to become with the help of what tools likewise is going to have last one being the test specification or the test cases itself how test cases are strategized how is going to be designed all this will be there so that needs to be reviewed or inspected using a process that is what review has to do so these are the things that has to be taken care during the review process across the life cycle of the project so basically why it is required is each life cycle will produce some of the output the output could be one of these requirements function specification design code user guide test plan and test cases of course you can have more test reports execution reports failures passwords metrics etc so you will take each one when you go through the next sessions okay the next one is how much we can review so first one is what to review in the embedded system the next one is how much out of this we need to review i mean go to review all the thousand requirements i mean going to review all the program articles that are supportive information for the requirements likewise we are going to have so we need to have a careful sampling it is called as sampling basically suppose for example there is a requirement specification there is a function specification we are going to sample using this sampling criteria we should be defined during the plan plan of the testing or the development which will say some say supports 30% of the sampling it should be done that means there are thousand requirements 300 requirements have to be sampled to see that whether it is in place appropriately within the assigned or identified module where the specification is as per the standard likewise this is basically from independent perspective of course a developer's perspective whoever is going to develop has to do a 100% review is called as self review so self review has to be 100% and we have a peer review that also should be 100% that means peer review means person a's products will be reviewed by person b and person b's products will be reviewed by person so both of them are peers to have an independency they need to cross check against each outputs or the by products so all of this like business specification code code has to be reviewed users guide has to be reviewed in terms of sampling at the different level of course we have a quality quality team or the quality person who is going to review based on his criteria it could be 10% 20% it is again depending on the criticality of the program program is nothing but the entire development life cycle or criticality of the level of the software whether it is a more critical safety concerns or the security needs to be overcome all these factors in terms of the review selection and how much to review so that is what is very important for doing the what to review and have you have to review aspects okay coming to the review details like we have different types of reviews and different types of program inspections and different types of walkthroughs so what are those and why it is important why because not all testers of software applications read the code but the concept of studying program code as part of testing effort certainly is accepted because it is going to be emphasized as a one phase of program inspection walkthrough and reviews definitely we have to have a dedicated process for doing this then only the importance of the understanding the code and reviewing the code is going to exist so several factors may affect the likelihood that a given testing and even effort will improve people actually reading the program code the size or complexity of the application size of the development team the timeline of the application development all these matters and the background and the culture of the program team and the testing team all these are very important in identifying the review process walkthroughs all these are important factors so basically this is not a computerized or computer based testing of course we do some tools in terms of identifying the reviews walkthroughs and all that but this is not automated generally the reviews are not automated purely it is done by humans it is called human testing whatever you want to call it so no automation is done here automation is not done means for reviews there is no tool in terms of producing the review aspects but once we have the reviews we can have the metrics and category of errors and all that using the excel sheet or any tool like such as bugzilla or whatever it is so human testing it is basically called and inspection inspections and walkthroughs involve a team of people reading or visually inspecting a program with either method participants must conduct some preparatory work any method they can use it but we should read or we should visually inspect that is what inspection means and walkthrough also same thing the climax is a meeting of the minds at a participant contest then the objective of the meeting is to find errors but not find solutions to the error that is the test not debug the primary thing that walkthrough and inspection does is first they will go through the or they will inspect the program it could be a requirement it could be a code or be a execution anything as part of the artifact of the embedded system so it is very important to have process in terms of inspections on walkthroughs and basically at the end of walk we are going to meet all the reviewers whoever has done all the inspectors whoever has done at a participation conference the objective is to find the problem that's all and conclude whether the problem is rightly identified or or not rightly done but there is no solution that is going to be identified just the reporting of the errors that is being inspected or that is being reviewed that is what the aim of the next phase of the inspection or walkthrough so there are different methods for doing this that could be any analogy methods such as any standards following or any program process or we can have some criteria keyed in the computer based testing that means we can have a checklist identified in a tool or excel sheet and against checklist there will be tick mark and non tick mark the user will key in and will generate the report so that is about program inspections walkthroughs and reviews let us study about program walkthrough so basically this is referred from art of software testing what he says is in a walkthrough a group of developers with three or four being an optimal number it could be more depending on the complexity of the embedded system they will perform the review only one of the participants is the author of the program the majority of the people other than the author so one will have a author the other one others will be supporting him in terms of doing the review so they will do following the testing principles stating that an individual is usually ineffective in testing this or our own program so basically we do in a walkthrough a group of developers three or four depending on the complexity of the program one will be the author others will be the reviewers so that is what is going to happen so an inspection of our walkthrough is an important improvement over the older test checking usually developers used to check by self-review but this is an improvement that we have seen nowadays inspections and walkthroughs are more few basically again because people other than the program of programs author are involved so definitely it is going to be effective independent and unbiased review aspects will be taken up another advantage of walkthrough resulting in lower debugging that means error correction anything we need to do we do not have to spend much time the cost will be less and when there is an error phone it can be precisely located which part of the code this error is there so that is the advantage of this inspection in addition this process frequently exposes exposes a batch of errors or a group of issues allowing the errors to be corrected in one shot whereas instead of inspection if you do a computer based testing normally it exposes only a symptom of the error it will just throw the error it will not identify where the problem is so that is where the advantage of inspection so inspection continuing that a program inspection is a set of procedures and error detection techniques for group code reading basically it will be read in a group most discussions of code inspections focus on the procedure forms to be filled out and so on it means there is a checklist and review guidelines as per the inspection guidelines as per that the inspection process will be taken care here after a short summary of the program procedure we will focus on the actual error detection technique an inspection team usually consists of four people one of the four people this is basically this example is typical embedded software do not get bias or take this as a definite number it could be five six depending on the complexity and the intended program it could be less also so one of the four people plays the role of moderator the moderator is expected to be a competent programmer but he or she is not the author of the program basically he coordinates is the moderator and he need to be acquainted with the details of the program he knows whom to contact who is the stakeholder all this information the moderator will have so the duties of the moderator will include distributing materials for the people and schedule in the inspection and the inspection session and he should lead the session he should record all the errors that is formed in the session ensuring that the errors are subsequently corrected but also he has to ensure so that the errors that are going to be cleared or not will be communicated to the reviewers okay tools an error checklist for inspections data reference computation data reclamation comparison control flow all this will be part of the checklist against that the check of the program will be done so basically the moderator is like a quality control engineer the second team member is the programmer the remaining team members usually are the programs designers or he can be a different programmer and a test specialist also can be involved the moderator distributes the programs listening and design specification to be other participants well in advance before the meeting before the inspection session the participants are expected to familiarize themselves with the material prior to the session during the session basically couple of activities will occur the programmer narrates statement by statement the logic of the program so during the discourse other participants should raise questions and they should be pursued to determine whether errors exist or not it is likely that the programmer rather than the other team members will find many of the errors found during the narration that means they will raise the hand and raise the issues the simple act of reading allowed a program to an audience seem to be a remarkably effective error detection technique that is what one of the activity the second activity is the program is analyzed with respect to a checklist of historically common programming errors so two things will happen one is narration other one is analysis so narration he will narrate the code logic and all that so user will raise the doubts and it will be recorded the second one analysis will be done against the checklist such as whatever is listed here the user program has any errors in terms of data reference computation etc so all this will be recorded in the inspection and as a result of the inspection he will distribute the errors to the developer or the author of the program and the moderator has to ensure that those errors are getting fixed or justified or it is rejected or accepted by the implementer that is what he has to ensure okay that is what is program inspection so next one is the sorry peer reviews yes peer reviews this is also one of the important embedded system static analysis for review method so what are we going to do in the peer review and we will also study about peer review and the types of peer reviews so peer reviews review method wherein is the review method wherein the other equal programmers or testers involved for evaluation as I said earlier testers or programmers independently review each other artifacts that is what peer reviews about so there is again a checklist from guidelines same as that are used in the other review methods peers remain at same level as others that is why we are called as peers that means there are some 10 functions and 10 functions are getting developed by 10 people and for these 10 functions suppose another two people are developing test cases or test functions all are considered as peers and they can review across their artifacts so they are called as peers any improvement on the updates can also be thought of that means it is not just enough to do the peer review identifying the bugs or identifying the errors that program or the test has but it is also important to have an improvement in terms of optimizing automating and speed I will say improvement in terms of effectively effectiveness in terms of the output or the program how much it can be effectively done there could be a tedious method there could be a short method all this can be thought of that is what improvement can be expected in the peer reviews so gives an insight into the approach and methods at a higher level while one becomes peer reviewer that means it gives a holistic approach of what is been intended on to meet the peer reviewed artifact so that is what it means so peer review is a very important aspect so we will see the peer review process what are the peer review process and types of peer review process so there are three types of peer reviews that can be done offline peer review walkthrough peer review inspection peer review what are those okay offline peer review process is as per below the objective is the purpose of the offline review is to evaluate the deliverable work product to verify its completeness compliance and find defects the objectives objective is to remove defects defects from work products early and to minimize the rework that is what the offline peer review where peer reviewers will not do together but they will take offline off-hand and they'll come up with the reviews that is what the objective scope is offline review will be conducted for the following work products basically project receivables statement of work contracts whatever it could be and that is what the offline peer reviews are follow these one example what we have put and internal deliverables such a pmp project management plan basically so these are also can be offline review and as a result of offline review process we have a excellent deliverables like low level design code it could be different artifacts such as SRH function specification design documents such as LLD HLD test cases test plans test concepts test scripts test results selected service system components which are identified in the transition plan all these are part of the offline review process okay let us see the next ones of the offline peer review such as entry criteria how we are going to enter into the offline peer review we took example as project management how it's going to be offline peer review so review planning in pmp is available work product ready for review as for the category i mean for in pmp inputs product or process work item ready outputs updated work products after review that means review is considered as complete only when the review review done and verified updated offline review defect log the defect log will identify the reviews and against each defect log there is a status such as open close in progress defect log will have a status or to be rejected also so you should show one of the status the defect log finally to make sure that the review record is closed with all the individual defects are closed so when it is open that means the defects have been identified and if it is in progress means the purpose of the particular review is review it is in progress that is the under fix is not fixed it rejected means that defect identified is not accepted it is rejected so the exit criteria of the offline peer review process is reviewed and updated work products all defects are tracked to closure and required sign-offs are done by these stakeholders capture all efforts of the review process so means how much effort it has taken in terms of review process offline is getting captured next one is the walkthrough peer review process we are going to have a walkthrough of the artifacts here the process objective is the purpose of the peer review walkthrough is to evaluate the deliverable work product to ensure completeness compliance and time defects the objective is to renew defects and work products early and to minimize the rework scope is offline review to be conducted for the following work products basically statement of work contract documents anything is an example and internal deliverables such as project management plan external deliverables such as requirements hardware requirements function requirements board level requirements designer documents HLD LLD test cases test plans and walkthrough peer review process entry inputs output exit criteria it is same as same whatever we have seen in the offline review process here the artifacts are walkthrough with different team members or the peer reviewers and it is similar to the inspection and inspection peer review process what we do the purpose here is to walkthrough the walkthrough and evaluate the deliverable work product to ensure completeness compliance and time defects the objective is to remove defects from the products and minimize the rework scope is peer review inspection that should be connected on the work products such as project management plans srs high level design system requirements service system design any any of the work products of the embedded system is the example taken from one of the embedded system now process that is followed in the industry all external deliverables and the documents components which are critical in software development lifecycle should be subjected to the peer review inspection that means all the external deliverables should be inspection peer reviewed that is what the meaning of the project management project manager or the quality analyst phone call for a peer review inspection meeting in other circumstances also wherever it is necessary here also we have entry criteria inputs outputs exit criteria that has to be mentioned in the inspection peer review process process okay so that is the end of the review process and that is static analysis aspects in terms of the peer review and the static analysis sorry coding standards what we have followed through the last and today's slide the next two type of static analysis is the test matrix how are you going to produce the test matrix and what are the test matrix that are used for embedded software testing and how it is going to be used in terms of static analysis that is what the test matrix will bring it out quantification so basically test matrix will bring or it will quantify the various artifacts in terms of how much and what is the percentage what are the pass fails what are not applicable what is the burn down charts likewise we have several metrics basically the test matrix are getting quantified physics needs measurements of time mass etc thermodynamics needs measurements of temperature the size of the software is not obvious we need an objective measure of the software size it is not the metrics that is based on the size but it is objective measurement basically that is what is called as the quantification this is very important when we do the metrics accumulation that means when we collect the metrics we need to be definite about how we are going to collect the metrics metrics is not just the size how we can get it directly with the help of the tool how much size how much lines of code is there likewise so better we do a objective measurement of the software that is very important okay quantification based on structural metrics it is not the lines of code as I said it is structural metrics so that is what test matrix will bring it out attention is focused on control flow and data flow complexity we have seen that control flow and data flow the worst case execution or the control flow plot and the objectives its usage all this will be part of the metrics we are going to cover structural metrics are based on the properties of flow graph models of programs so that is what basically the structural metrics is talk about the software quantification we do not on the lines of code it is basically we need a motion of the size when comparing two testing strategies when we do a testing how we are going to test it so basically not based on these lines of code it is based on the complexity and the structure of the code so something like we may come up with a strategy such as a strategy a or strategy x needs some two tests per unit unit could be a piece of software so likewise we need to have a quantification so basically we need to be having questions before we develop the matrix in terms of quantification how we can test it or what is the strategy and when we can stop the test and how much we can find 20 bucks it is something like percentage or it could be some number say suppose we have 1000 lines of code and we as a tester based on the design requirements and all he will work out a strategy and he is expected to bring something so 10 percent of the lines of code suppose or maybe 2 percent 10 percent is too much so 2 percent is something like 20 lines of the code wrong the issue so something like how many bucks we can expect from the piece of software when it is tested so there is one of the test metrics so which testing technique is more effective are we testing hardly or smartly do we have a strong program or a weak test suit so this kind of questions we should have for collecting the various metrics while doing the tests so it is difficult to answer some of the questions satisfactorily but we need to have a matrix in progress so that we can discuss the aim of getting empirical laws in terms of size number of bucks number of test strategies number of expected number of tests required to find a bug testing techniques its effectiveness all this will be done with the test matrix it is a basically weightage so that is what we do when we do the test matrix it is basically weightage structural matrix quantification is all we have to take care when we do the test matrix so it is not we are going by the size of the software when we capture the test matrix it is going by the test strategy the structural aspects of the software the structural aspects could be control flow data flow and the complexity of the program likewise so importance of test matrix why we need test matrix matrix is used to improve the quality and productivity of products and services thus achieving basically test matrix with the help of test matrix we know how much we have improved over a period of the embedded software lifecycle or over a period of regression test or different types of tests how much bugs we are able to gather how much bugs we are going to fix what is the maturity of the products all these artifacts will be come up without the matrix we cannot satisfy the maturity of the products definitely we are going to report to the customer and we can have a customer satisfaction based on this matrix and it is easier to manage or easy for management to digest one number and drill down if it is required if there is a critical issues and how those critical issues are getting done is all based on the test matrix different matrix trend act as monitor when the process is going out of control that means when we do the testing we are come up with we are going to come up with a different matrix and the trend of that matrix will definitely give whether the program is going out of control or within the control we will study about this different matrix trend and all that there are different charts in the future sessions future sessions matrix basically provide improvement for current process that means when we follow the process it is going to continuously improve that is what the matrix is going to help so basically any process you take such as CMMI level 5 or any level 6 sigma etc they basically look for the improvement and minimization of the errors when we do a production when we do a process followed followed up when they are going to have a life cycle implemented so that is where the importance of test matrix is going to come up okay so we understand that the importance of course matrix how we are going to represent how we are going to present it so we will study that aspects in the next class objective of the test matrix and test matrix how is going to be depicted what is the burn down aspects of the test matrix how the trends are set making set etc in the next session