 who are coming to the next practical session of embedded software testing we studied in earlier session about how to create test cases from a embedded software requirement and we also learnt about the checklist that are required to do the embedded software verification and today we will try to understand the traceability between requirements to test case okay so for traceability you know that it should trace from the requirements to test case one level and from test case to requirements both the levels are important so that we have the coverage okay let us try to open the SRS document and we will also try to open a test specification okay now we have what we have to do is using an excel sheet we should create a traceability such that we are covering every aspects so now what are the inputs that we need for traceability as we said we need test cases we need requirements similarly other one so we will create upwards upward traceability and downward traceability okay in upward traceability we need test cases to requirements so number test case requirements let us do this way let us try to create few samples and try to identify those things what we have covered okay so now we will go by the test case so how many test cases we have we go through the test requirements we will come to know okay so we have SRS 2 TC 1 TC 2 TC like this we have about 10 so we will copy this we will paste it here next level we have next set of test case here next one is here why we are done similarly we have test cases for the next set of things so likewise we are going to make it next one is the requirements okay so this test cases what we have identified here all for requirement this right so we need to put that so we have about test case 1, 2, 10 for the first of the SRS 2 so these are all SRS 2 type of requirements so we have the next set of requirements SRS 3 okay next we have SRS 4 okay so by seeing this you know that it is from okay this is basically upward traceability other one we should try downward okay so in upward traceability we try to cover how many test cases are there so what will happen is at the end of this so we can put some formula in excel sheet to see that missing requirements so there are few requirements which are missed like SRS 1 we are not covered so what will happen is we will be able to identify what are the requirements that we have missed with this upward traceability right so those requirements we need to address by adding a new test case that is what this traceability will help basically so first one is this actually so what will happen is this requirement we know that this will go in different modes actually so we need to put the embedded instrument in operational so that we know operational type of requirements will cover both in it as power up so wherever we have test case for operational mode type of requirements say when modes go to operational mode is the one suppose this will cover SRS 1 also along with SRS 3 right so this is SRS 1 it is covering likewise we are going to have a coverage of missing requirements if still it is missed we are not able to trace some of the requirements then we need to do some sort of analysis what way I can cover it up whether I can do it with the existing test cases or should I do it separately so that way it is very important to have a traceability to have a coverage of all the requirements from the test case perspective okay the next one is downward traceability here what will happen is we start with requirements we go with test cases so what will happen is all the requirements first it will be listed basically suppose we have 10 requirements please remember that these SRS ideas are incremental but sometime what will happen is over a period this could have been deleted may not be there so assume that all the SRS have been brought up here and for each of the SRS we have a test case like in terms of test case idea see in the first one we have test case so we have test case 2 SRS is same like this we have 10 test cases for the same requirement so we know that from requirement how many test cases have been drawn okay now SRS 3 SRS 4 likewise we are going to list sheet out test cases so what will happen is there will be some test cases which would have missed for particular SRS so that we are going to tell that as missing test cases that means test cases we are not covered for certain requirements this way downward traceability will be achieved so with the help of this we are going to have upward and downward traceability we are going to create a complete report of how many requirements how many requirements are there in terms of missing all this will be part of the traceability that is what we do with traceability basically we will try to establish a traceability and identify the matrix for the develop the test scenarios for the set of requirements okay that is about traceability we studied about SRS and creating the test cases and we will check list we have seen the next x is that we have seen about the held area code coverage and the structural coverage held area unit test generation and management with held area unit at example demo event then we also studied about target debugging using code warrior there is a video we also went through and we will try to study a test link how it can be used and there is another tool called bugzilla similar to test link this also can be used what we do is there is a online test link session we will try to see that and login basically we need to create the demo project that the testing people have created through online you can do so but ideally in a project what will happen is this is a local server like a apache or something so with the help of that they will create all the connections with that local server and create the individual access with the user radio and all that so here is the page you can see we need to login to the test link and you know that the test link we can use to manage the test cases and requirements execution results and traceability complete report will be done only thing is first time we need to enter manually or we can import from requirement document such as word or doors so that option is also there once we are done with adding all those information what is required for test management we can generate the test report and similarly the bugzilla also can be used those are the steps that we require for test link okay here you can see the basic window of a test link it is a sample it is available online for an understanding of how it is used we can use this so for a test project we have users like admin tester and test manager etc quality people it's up to us how you want to define the different roles of the project so we can assign the user roles the existing ones or we can add a users if we are admin in terms of the test stakeholders basically you can see a example here there are number of users here it's up to you how you want to add them so the different roles have been created this also you can create who can do what is an example that they have created so there is admin tester leader and all that so based on the need of the project you can use it the roles who are all assigned that also you can do with this test designer let us say so these are the people who are having a test designer role okay so that they have access to have a test cases designed and added into this portal so that is about test project roles the next one is test plan roles similarly test plan also we can have it the example project that has been created and you can set the roles for doing the test plan so we have a test plan as well as test design test design is nothing but the test cases or test specification creation so here also we can find who is admin for this project just an example usually one admin will be there who will maintain adding the users deleting and maintaining the reports and all that like what we have seen in one of our theoretical sessions of software configuration management like CC role and all that similar to that it is okay so similarly we can have the different test