 so welcome to the next session of embedded software testing unit 4 so this will be the last lecture session of unit 4 on the software integration and we have a regression testing we will study about the software integration the considerations and other aspects the environments and followed by that we will discuss and study about the regression testing okay to recap on software integration we know that the integration can be done at system level software level and the hardware so it is called system integration test software software integration test hardware software integration test so to recap the integration test strategy is not just enough to have a component level testing but to have a adherence at the system level how the components interact at a module level when they are logically grouped we need to work out a strategy to integrate those components so there are different analogies like in terms of strategies as and when they are developed we can do or we can start with the top level modules will be lowest possible units so either way we use the steps and drivers test drivers it is called basically to make sure that the different stages of their development integration can be taken up so different strategies we had a comparison in terms of over time and the needness of the component drivers for the steps parallelism ability to test the particular parts ability to plan and control the sequences also we had gone through the advantages of top down and the bottom up so top down has advantages in terms of if major defects are more likely to top level modules then this is better whereas in bottom up at the lowest level possible device drivers or hardware dependent things are having issues better to do the bottom up testing so basically a look and feel of the system in terms of demonstrating what could be the architecture or what could be underneath the embedded systems can be well demonstrated in top down testing because we have more testing from the top post modules whereas in the bottom up testing we start with the lowest possible modules and when they are completed with the help of drivers because driver needs to call them so that is where we use the bottom up test strategy but we need to have that is why this is disadvantage because we do not know what also we need to use for creating a driver or we need to have our own drivers so that is why the disadvantage of bottom up whereas in top down testing we need to develop the stubs so there are a lot of small stubs that may be required so that is a disadvantage it may not be accurate there could be some errors while developing the stubs itself so it takes significant amount of effort and time in terms of developing the stubs so that is what we are going to do top down testing the other type of test called hybrid test which uses both top down as well as bottom up so this has been preferred in many of the industry aspects where larger systems are there and where a lot of subsystems are there having a small to moderate or moderate to complex high complex embedded systems or embedded subsystem so it is beneficial to have a hybrid test strategy which has a combination of both test stubs and test drivers that means it is like a middle out approach I mean both top down as well as bottom up sort of a mechanism so this approach basically factor based on the criticality and the cost that the system has so it is very subjective so based on that we can take a call in terms of using hybrid test strategy where to apply where to use what sort of a testing mechanism in terms of integration so another type of integration testing we had gone through is called centralized integration this is more appropriate here use kernel or OS because we cannot replace those part of the embedded system so surrounding that we are going to develop anything that is required so we cannot substitute or very difficult to substitute the stub so this kind of a approach is called centralized integration so surrounding the centralized part of the system is developed first and made ready for production there are other type of integration we have gone through quickly layer integration where different layer for you application layer lower layer and the device drivers of the hardware layer this is particularly useful which I think what you tell is that when we test a protocol such as a network protocol so better to have layered side of a testing so we know that OSI ISO model has transport network data layer physical layer these are the important elements of course we have application presentation and session layers top most of that this is presentation layer application layer as a top most then we have a transport network data and physical so likewise we can segregate it so something like a layered so we have a seven layer approach where protocols of networking applications use this OSI model used for network systems where protocol network protocol TCP AP FTP IP UP IP UDP all this sort of a protocol mechanisms we have a layered approach so in this case better to use a layer type of integration where we develop the integration test in terms of the other type of integration testing is client server integration we had studied about this where the server is stubbed when client is tested client is stubbed when server is being tested so it is like a collaborative mechanism in terms of client and server this is typically used where we have a database and huge application database oriented object based or object oriented systems we have my last type is a collaboration where we identify different collaboration models those models can be integrated together that is where collaboration integration can be done so those are the different types of integration that we have studied then we came to integration test environment how it looks like so basically it should have a mix of both unit level testing environment as well as system testing environment because we need to develop a driver with the help of integrated development environment that environment could be used for developing the system ambulance testing the system level identification similarly we use the lowest possible device drivers test drivers so those features also are needed so both sort of a environment is required for doing the integration testing so it is like an integration model which will comprise of which will be comprising of both unit level as well as system level environment basically we can use some of the test driver model which have been working and which are useful for integration to logically test the different models together additionally we may need tools like monitors to log and read the data traffic as I said in the protocol there will be a logger time stamp and all that to do that we need to have an appropriate additional tools such as monitors so in continuation of integration test environment so we know that software unit test and the software integration test test bed is created basically which is comparable to the test environment for the simulation model so we know that simulation simulation and actual hardware or target based testing are used so accordingly we are going to have a test environment so that is where we develop the integration test environment so basically prototype stage and production stage are different type of integration we can have so both the cases we need a test object having the executable version of the software unit or integrated software units need to be used so that is basically developed based basis of the design or generated from the simulation model so based on that those integration environment will develop so in continuation of this host based environment target based environment then host target a mix of that can be used as well in terms of developing the integration test environment also we had gone through a table from the book in terms of levels of simulation how it can be done and where it can be used what is the processor used host processor is enough for doing the experimental or host based integration testing whereas when we use the emulator we need to have a target actually the real target having the target processor used so actual hardware enters of memory or any transceivers or any communication devices we need to have a mechanism such as hardware in loop or hardware software in loop sort of a test environment for integration test specifically it is useful for hardware software integration not the software software integration software integration we can have the host based test environment for the target based environment we need to have hardware software target environment for doing the integration test so that is about the earlier session today we will study more on further integration test environment the below table is a depiction of a simulation level for hardware software integration test we can have sort of a simulation in hardware software integration where this table you can see the embedded software very different it can be on the experimental host some of the pieces of the embedded software can be experimented or run on the host so that is where the first test bed is going to be lying the next one could be on the real hardware which uses some of the software units software integrated in it in the first one also the software units will be used there is no hardware involved the last one being hardware software integration the complete environment and system environment having the embedded software so the various process that are being used for this three layers of simulation in the hardware software integration or see the first one we need a host based process such as x86 or 386 46 or code 2 i3 Intel based or AMD based etc the OS can be Windows Linux whatever it could be but the host the execution will be based on the processor host based processor and in this case the rest of the embedded systems will be formulated a plant you do not need to concentrate much because plant is something like where we are going to have it what is the unit called actually the second one will have a emulator because we are using the real target and we need to simulate the system itself completely with the help of this emulator and the last one we have the real target and the processor is real target there is no emulation of the target processor that is how we are going to have the layers of simulation level in terms of integration testing so this table provides an overview of the level of simulation of the hardware integration test the columns refer to the simulation area of the generic scheme of an embedded system so continuation of integration test there is a system integration test which is at very higher level of the integration test on top of hardware software or software software integration test so what we do here the test and armament for developing the system integration test is a test armament test and armament is very similar to that of the hardware software integration test after all the complete embedded system is also a piece of hardware software so it is not something different but it is as a whole the hardware software and the integrated models combined together something like a system test it is also can be called a system test but the emphasis or focus is on the integration of the various logical model of the embedded system or the embedded software one difference may be found in the fact that the prototype printed circuit board of the complete system is provided with its final input output and the power supply connectors the offering of stimuli and the monitoring of output signals possibly combined with the dynamic simulation will take place via these connectors so actually in the display something like a actual target board we are going to use and prototype of printed circuit board of the complete system will be provided as a pre-production testing where we use a actual input output and power supply connectors and we use the system integration test strategy for doing this developed board basically the pre-production board it is called a system integration test board what it will have basically is that I will try to draw one as a production as a pre-production we can call this as a pre-production board so what is the difference between this so what will happen is if there are going to be any bugs or any fixes are needed all those final stages of the work will be done on the pre-production board and to test that definitely we need a interfaces right like we need a debugger we need any of the test hooks in terms of ports all this intermediate stuff will be part of this pre-production board which is slightly a larger bone or actually larger than the actual production board both will have the same processor basically in both the cases what will happen is the additional circuitry that is required will be taken out so in this case what will happen is pre-production minus additional circuit will be removed in the production board so that it can be used purely for the deployment on to the target system or the field actually which will be delivered to the customer so that it will not revert back to the factory so this is the final production board so all the system test acceptance test all that will be done on the production board whereas in the integration stage we are going to use the pre-production board so that is where the difference is like the next one is another table you can see for system integration test this table basically depicts simulation level for system integration test you can see the last one being added here as a real target with the system integration and rest of the systems or prototype and actual plant is simulated so this table provides an overview of the level of simulation in the system integration test the columns refer to the simulation areas in the generic scheme of the embedded systems so in the earlier one we didn't have the system integration facility in terms of the actual target and there is no experimental system actual systems will be there so that is what we going to be prototyped so this will be used for system integration test something like a pre-production testing this is called as okay so let's move on to the next topic of the integration test so this is basically the use case derived or use case integration test so what we do here is you may be knowing about use cases basically this term is a derived term from the UML I think I will have an explanation about that UML perspective because we are not going to discuss much on the UML why because UML has its own deep study required but basically let's understand that unified modeling language which uses use cases class diagrams sequence diagrams etc so basically it is going to depict how the system looks like so something like a model we are going to have so from the user's perspective the cases that are going to be developed or the classes that are going to be developed are called use cases so definitely we know that use cases are being developed we have an input we what is the expected output all that are described in use cases so with the help of use cases we can develop the test cases and that use cases concept only on the higher level modules or the graphical group or the functionality or the features of the embedded software system so that is how we can derive the test cases from this use cases that is where it is called as integration from use cases perspective basically testing from use case which are further going to be broken down into test cases so basic difference is that use cases tell the story of how someone interacts with a software system or the observed behaviors that's what use case the user perspective does to achieve a goal could be accepting some value and computing something and resulting some other value or achieving some of the results that could be a functional block for that goal a good use case will describe the interactions that lead to either achieving or abandon abandoning the goal so basically the use case describes the interactions for achieving the goal or resulting the path whatever that goal is going to take for that functionality the use case will describe multiple paths that the user can follow within the use case so use cases can have different paths we know that as the flow of the program control level or data level goes and it subject to the complexity and the flow what that embedded system arrives similarly multiple path that use case can perceive so we will also can be used to draw the test cases so it is test case represent one set of inputs that exercise a single use case scenario that means use cases will have multiple scenarios so one test case for each scenario we are going to have so that is where test cases have been derived from the use cases let us see try to see more examples on this integration from use cases perspective integration from use case perspective system test cases how are going to write it many system many system tests are designed to simulate how a user interacts with the system to make sure that the system responds appropriately because system needs to be subjected to some sort of interaction and the response if we have defined your requirement by using goal driven use case that means we are going to achieve some goal with so many paths you can use the use cases as a framework for defining this test cases definitely this use cases are important and useful why because this framework on top of which we can draw a lot of test cases and there is a goal for this framework the framework is basically the use cases also called as goal driven use cases so how are we what are we going to come up with with the help of this goal driven use cases nothing but the system test cases the system tests should be created to test a single situation that means each test will try to test the individual scenario or the situation when using the approach of use cases and use case scenario to describe requirements a system test should test single use case scenario so what it is trying to say is each use case or every single use case scenario should have a test case in that way we are going to have system test cases covered addressing to the requirements so that is where the requirements are going to be tested from the use case perspective so the next one is how we are going to generate generating test cases from use cases use cases are based on the unified modeling language as I said UML is used and can be visually represented in use case diagrams I will not detail out the use case diagrams maybe an example I will try to see when we are going to have a practical class of a sample UML so use case diagrams basically will have users interacting with the system suppose I will try to draw a small listing so this is the functional block and we have a user user will be represented in a different way so basically this is a use case so what it does is it tries to interact with the system and it expects some output from the system so all these scenarios like we have one or two and some results like two and three and four whatever it could be other functional block all this help of use case diagram we can draw test cases test cases can cover from this this this this this likewise so that is how we are going to generate test cases for each of this part where use cases are being used with a user interfaces with the system and the expected output how the user pursues from that scenario and the use cases will have the below items you can see name and description of that use case flow of events that use case can take or different flow of that events how it is going to drive and any special requirements is going to cover because having the user perspective we may cover more functionality or more requirements or any specific requirements or special requirements that are also addressed when any preconditions that needs to be taken care for typically executing that use case and any post conditions in terms of the test cases have been executed we need to take care so all these aspects of use case to test case will have to be taken care so that is where we use the test cases generated from use cases basically whatever I try to draw that users it is also called as actors actors are nothing but the users which the users can be any subsystems or any humans or actual users so the lines whatever I try to draw communication between the actor and the use case in terms of the flow basically so use case diagrams will provide the bigger picture in terms of how the functional block is getting used or perceived and the same thing will be tested against that actually the next one is an example of generating a test case you can see a different parts in this use case flow basically so this diagram depicts a basic law of events and alternate flows of events per a use case so what is going to happen is the basic flow will be same the user going to use that functional block there is a output but to achieve that there could be a different flows alternate flow 1 2 3 4 different color sequences have been followed and these alternate flows can be derived into sub alternate flows as well so in this way in that way we can have the multiple flows as well so this multiple flows will have each one address by a different test cases is called flow of events and for each of each flow of events there is a test case and we need to apply all these items all these descriptive things all these pointers for addressing the use cases you can see there are different scenarios and scenario 1 could be a basic flow scenario 2 could be the alternate flow and scenario 3 could be alternate flow 1 alternate flow 2 scenario 4 could be alternate flow 1 2 3 you can see multiple scenarios so it can take this path basic flow alternate 1 2 and alternate 1 2 then alternate 3 it goes back and again it comes all 4 can be there likewise we can have multiple scenarios for each scenario 1 test case we are going to have it so once we identify these flows for in this example 5 flows are there we are going to generate the test cases so how we are going to generate the test cases is set of test inputs execution condition writing type use cases act as a product requirements for generate the test case this is this is where it is very important to understand that we have understood the requirements and we have written the grouped scenarios based on the use cases now it is a time for us to write the test cases and for test case writing we will not care about requirements and all on a major aspect but we care about the use cases so you can use cases become something like a product requirement those product requirements will have to be addressed for developing the test cases and executing them so this is what is the important thing so it involves basically three steps process for each use case generate a full set of use case scenarios for each scenario identify at least one test case and the conditions that will make it execute it can be more than one test case also subject to the feasibility of that particular use case if it requires a derived test case or more test cases nothing wrong in having more than one test case it should be executable those test cases that is where they are going to have a theoretical as well as practical procedures for these scenarios for each test case identify the data values with which it has to be tested so step one is to generate the scenario step two to two is to identify the test cases step three is identify the data values which is very important so once again I will repeat read the use case of textual description and identify each combination of main and alternate flows as you can see different scenarios you have to identify that and understand the scenarios and create the scenario matrix you can draw a table and identify the matrix it could be a partial matrix or full matrix for a partial scenario whatever it could be but the end goal is to make sure that all the use case scenarios are addressed with the test cases that is how we are going to draw the scenarios that is the first step second step once the full step of full set of scenarios have been identified the next step is identifying the test cases we can do this by analyzing the scenarios and reviewing the use case textual description as well so use cases will have a description as I said in one of the earlier section earlier this slide each use case will have a description and this description is being used as a textual input for developing the analyzing the scenario and taking the use cases or test cases from the use case so there should be at least one test case for each model but there will probably by more actually depends subjectively so the additional test cases are basically to cover all the possibilities in terms of boundary equivalence whatever we want to call it whatever we have studied earlier for dynamic testing in addition we may wish to add test cases in terms of analysis or anything that could make it cover for all the scenarios so that needs to be tabled out that is where what we do with the test cases identification process the third step will be identifying the data values for each of these tests because data values are very important once all of these test cases have been identified they should be reviewed basically understand and validate to ensure accuracy and to identify redundant or missing test cases anything is missing we need to do it then so once they are all understood reviewed approved the final step is to actually we have to substitute the practical values or the data values for the inputs and the expected outputs so without a test data test cases can't be implemented or executed right so they are just descriptions of condition scenarios and paths but actually the test data is going to identify the practicality of the testing so therefore it is necessary to identify actual values to be used in the final test so this also can be done with help of a test case matrix for each of the scenario okay so with this the generating test cases from use cases comes to an end so next topic in the integration or continuation of the integration testing is the continual integration testing or this called incremental testing or it is also called as mainly regression testing regression testing so what do you mean by regression testing it means re-learning test cases from existing test source to build confidence that software changes have no unintended side effects so why we need to have software changes why because when we have done that primary testing or first-time testing there are certain issues and bugs we found out on the embedded system of the software to overcome that we are fixed that software and the requirements are not changed test cases should not change so what has to change is the result and to achieve that we are going to have regression testing so regression testing means re-learning the test cases from the existing the test suits test suit is a set of test case test procedure on the test execution scripts on the test bed so basically while doing this we get a confidence that the software has got some changes but does not have any unintended side effects the ideal process would be to create an extensive test suit and run it after each and every change that means the test suit should be such a way that any changes in the system will not alter the execution process so we do not have to retouch or rework on that test suit again and again though the system is under the changes so changes means changes within the certain limit or the scope of the program that is where the regression testing is held out is a important type of testing it is not a type I would say it is a process which everybody will follow in the all the industries but some people do a automation for regression they have a dedicated team for regression they do batch automation script automation execution so that every version of the software they keep testing it independently that is where the regression testing is very important but whatever that you want to have it in regression testing the primary testing has to be solid on the accurate and clear so that the regression testing will be successful based on that so definition of a retesting based on standard 79251 it says that running a test more than once that means same test is getting repeated a simple definition so under definition is a retesting to a previously tested program following modification to ensure that faults have not been introduced or uncovered as a result of the changes made so we call it as retesting and regression testing retesting is just testing again regression testing is previously it has been tested some modifications have been done or the faults that was identified and we are going to re-execute or retest the same thing so that we are going to fix and those faults have been uncovered or changes have been fixed let us see in detail regression testing why it is important and different definitions and techniques that are used for regression testing maintenance testing would have heard it is same as regression testing what are the things that we are going to have for maintenance testing basically this is the one it is also called as one of the strategy for maintenance testing there are other aspects also in maintenance testing but the main aspect is that regression testing or retesting is done intended changes of system behavior must be tested but it is also possible that the system which used to work correctly in the previous release does not work in the new release as a side effect of the implemented changes this is called as regression so we know that incrementally there is some issue that it was working before but it is not working so what is the reason why because we found out the issue in X place and that issue is fixed so X place is working fine but while doing the testing of the X we also test why is it working fine and no changes on that but it is failing now so there is a side effect so all this will be brought out that is called as regression regression testing much of the test effort is dedicated to testing that previously it was currently first currently so basically what it is we make sure that the earlier working testing is being again probably so that is where the effort goes of course we know the fixes that we have done for the identified faults or errors in that we will work that is working but the emphasis the regression is that it is going to be changed against what was looking earlier again it should work the same way so the changes can in turn be itself not into a limited test focused only on the change alone or a complete test of the test of the function or component that has been changed a test of the coherence and interaction of the change component with adjacent form so the three types of changes that it is testing can take place that is on the direct point where a limited test focused only on the change alone means only the change you are going to that will see that in build we verify so it is going to be working but that may not be enough because the changes can be impacting the surrounding models so the second type of changes can be a complete test of the function entire function function has some small functions or substance pumps but that is not enough that does not mean that is enough to test only that interactive part or the interactive body of the function or the component but it is better to test the entire component that is what it means the second build the third one is why we do the testing of that particular component we need to check the coherence and interaction of other components and the other model which is having the interaction with the current one which is under test so that is where the regression testing is very much important so with every implementation of the change we know that the risk of regression is introduced regression testing is a standard element in the maintenance test project visually a specific set of test cases is maintained for this purpose generally they do a sample on the maintenance depending on the risks and the test budget available a choice has to be made to either execute the full regression test set or to make a selection of the most relevant test cases test tools can also be used effectively to support the execution of the regression test when the regression test is largely applicable selecting which regression test cases to skip is no longer necessary because the full regression test can be executed with limited effort basically that is why we do not need to skip so regression testing test strategy so what are test strategies that we can have it is basically depending on the number of changes so definitely regression testing can be carried out subject to how much changes there and what is the kind of change that is also important it is not that number of changes 10 numbers 20 numbers present matter even one change can also lead to a huge risk or regression so that is very important changes as basis for risk evaluation planning and progress tracking so the changes that have been there on the embedded software due to earlier fixes has to be evaluated planning and progress tracking also need to be taken care for the regression testing so it can be treated in the same way as your newly developed that means some of the functionality needs to be addressed for the regression testing such a way that functionality is being newly developed and we are going to test it first so the test strategy could be determining the changes the first part is implemented change request and corrected defects so what is been implemented what is been changed that we need to determine first second is determining the relative importance of the changes and regression that means we need to identify importance of the changes on the regression importance third one being selecting quality characteristics what are the quality aspects that we need to take care in terms of the checklist or this criteria all this have to be taken care fourth one being determining the relative importance of the quality characteristics is not just enough to identify or select the quality characteristics for that particular scenario it is also important to understand the relatedness of the quality aspects the next one is determining the relative importance per change and regression or quality so each changes what is the relative importance of the entire system to that particular change or the particular quality characteristics all this above steps need to be combined together to come to a conclusion that is called characteristics combination the sixth one being establishing the test techniques to be used this will become six okay so then we are going to establish the test technique for that identified changes that is what the steps that are involved for regression testing so what are the areas that regression testing of the taken care regression is due to fixing the fault side effects we need to check you know that we have found a field problem in terms of fault or error and that is fixed and we are going to do a regression test on the fixed part so we need to check the side effects of the fixed part also okay regression due to added new functionality so new version of the software has come so that doesn't mean that we need to have entire testing developed from the scratch so one into what we need to do is regression or incremental testing in terms of that particular added functionality or the new functionality regression due to a new platform that means the same software same testing will be carried out on a new platform this is very specifically important where we do a voting activity so especially OAS related things also operating systems are supposed to work same on different platforms it could be Intel it could be AMD or any other sort of a platform Linux you take for example Linux OS is supposed to work on different hardware platforms so how they are going to do is to with the regression test strategy regression can be due to new configuration or after the customization some changes some configuration there is no software change still but the environment or the configuration of the program or the software under test has changed and regression is required for the same regression and delivery planning so those are that is also one of the area that need to be taken care for regression testing so how we are going to deliver so as a what incremental on incremental all this will be part of the regression testing areas so the next part is regression testing automation so very important to have automation as we progress the different tests so any way the system in automotive and telecom, aerospace, consumer performance, industrial performance will take does not stop at one level of testing the product is going to be evolving again and again requirement is going to be updated modified change the faults are going to be fixed again and again with the different versions different similarities of software different softwares different portable platforms units and all definitely it's a high time for identifying the automation while planning the testing especially this is useful for regression testing where manual intervention is very minimum and not afford to have actually that is where the automation is very important and the test suits which are going to be developed for the automation purpose should be controlled under the configuration so we will try to study what is configuration management test management in the next class next session incident tracking of test cases where different incidents are going to be happening while developing test cases in terms of test approach test strategy bug fixes all this have to be tracked automation best in regression basically as I said automation is very much needed for the regression purpose because again and again people cannot afford to develop the test cases scripts modify and all that and execution especially so you can just use the script what he has used earlier modify according to the need whatever the place he needs do the execution batch execution whatever it is possible regression driven test automation means regression itself can drive test automation where as I said we can use the batch file execution multiple scripts execution as seen some batch execution goes for days where hundreds of problems of test inputs are taken there is a time for execution and all we used to keep the batches for overnight and we see the results next day analyze rerun again keep for days like that so this kind of a automation is very important for regression testing where human intervention is very less required and automation is also useful for incremental development where the development is going to be evolved again and again the next one regression testing test strategy matrix of the relative importance of changes and regression is basically a table analyzed based on how an and then schools can go for different sort of a importance for testing test strategy regression testing here they say as 10% but according to me it should be 2025% but it is in a relative example how they have given based on a particular industry you can see what are the changes for regression that are there in next column and the importance they have put it in the reference so all together 100% is what the test strategy they have try to put it the importance change request could be there 15% change request another one 10% change request 17% 10% defects are there some great defects are very important very less important and their importance 5% whereas defect 1242 is 15% relative importance defect 1243 is 5% importance these importance are subjective based on the type of defects or changes that are needed these defects also can lead to a change request the defects are also called as problem reports so likewise there are different types of categories changes and regression aspects so rest of them they have keeping as 40% including a regression so this is an example so let us see basic problems of regression test maintenance test suite we need to have a test suite which has to be maintained so that regression test can go smooth if i change a feature x how many test cases must be revised because they use feature x so some features are common like a common template or plug and play sort of a module and that I have used in multiple test cases and all that need to be revised just because I have changed the feature x so that is what is the maintenance issue for the regression test which test cases should be removed or replaced which test cases should be added so this also very important criteria for maintaining the test suite because test suite are used to use for regression testing then cost of the retesting how much is going to cost or need to do a retesting often proportional to product size not the chain size basically product size is 1000 if the changes is 1 or 2 it is not going to much cost whereas if the product size is from 10 or 20 and the change size is 1 or 2 definitely the ratio is more and the cost is very high so this also matters big problem if testing requires manual effort suppose we cannot have a automation for certain tests such as assembly level testing or manual analysis etc those kind of regression is very tough in terms of effort because the idea behind original testing the same idea has to be carried out and the people or the resources that are used has to be reproduced and the philosophy is going to be remaining through because the type of testing that it involves is a totally manual and it has to be repeated possible problem even for automated testing when the test suit and test execution time grows beyond the viewers so those are the basic problems of regression test okay so we will try to study more on selecting and prioritizing the regression test cases test case maintenance how are we going to build the build process for regression test and we will try to see an example of how regression testing is been processed in terms of build process in the next class so we will conclude on the regression testing next class and with that we will conclude the unit 4 which is the integration test and the regression test thank you