 ఠార్కాస్పార్లునుకంంమునిర్. ప్మ్నుస్లినిస్గితరంవర్. ప్టర్ర్లు దకంత్మార్లుగిని. Today we study about change management, incident management, revision history, CM tools, few examples of configuration management tools, we will have a look, before that we will try to go through what we had studied in the previous session, we had gone through some of the activities of configuration management, in particular the SCM it is called software configuration management activities, so it involves a SCM planning, SCM sorry SC identification that is configuration identification, software configuration identification and the term called base lining and software configuration control, so basically what we do here is the life cycle changes we will manage, basically it is getting controlled, so there is a dedicated person for this who is called as admin or configuration controller basically, he can also be a member of a control board configuration control board it is called as, so they will basically decide on the changes and impacts what is the kind of modification either to accept, reject or to refer it all this they will decide, so this is an important aspect of SCM activity, next we have studied about software configuration status accounting, here basically what we do is we will get the complete information about the configuration of the entire project life cycle items, specifically the CIS or the configuration items, it maintains the information about the configuration documentation, configuration documentation basically we may have all the CIS folders, where is the location, what is the base line, what is the revision number, all the information about that it is there part of the configuration documentation, so this configuration documentation will be maintained inside the configuration status report, that status report is nothing but the activities called as software configuration status accounting, it also maintains the information about the products operational and maintenance documentation, how we are going to carry out, so what are the current information that is available, what are the documents affected by the changes and those changes whether what is the status of those, whether they got updated or any changes are in progress, all these status about the configuration each of the configuration identified identification elements will be maintained, and also it enables retrieval of information functioning train decisions and provides a source for configuration history of a product, like what is the history behind all these changes and its configuration details will be provided by this status accounting, and all the data collected during configuration status accounting is maintained in configuration status accounting report, so there is a frequency like bi-weekly or mm3 why this report will be generated, this report generation is also part of the configuration status accounting report, basically this collects for that particular month, whatever the configuration items, undergone changes, updates, impacts, all this information will be reported, configuration status accounting helps in establishing the configuration records for CIS, the next activity is went through the last one in the same activities, software configuration audit, so how the configuration accounting and CIS are getting maintained, so there is an independent audit conducted by few auditors, it can be from the same organization or independent team or outside or it could be from customer also, so there is a representative, so he will have his own checklist and guidelines against which he will go through and all these guidelines, standards, plans and procedures will be part of the plan, the plan is nothing but what we studied about is SCM planning, so plan will tell, so at what frequency what will be maintained, what are the CIS are all this, against that whether RPS being clearly maintained and tracked under the SCM activities are being audited, that is nothing but software configuration audit, so a software configuration audit performed independently to evaluate the conformance of software products and process to the standards, guidelines, plans and procedures, so there are basically two types of audits which we have studied, functional configuration audit and physical configuration audit, FCA is done, functional configuration audit is done to ensure that configuration item to audit is consistent with its specification and physical configuration audit is going to make sure that the design and reference documentation is consistent with the build software product, so whatever we spoke about forward structure, versions, refining all these activities, physically they are available in the configuration is part of the physical configuration audit, then we went through few example lifecycle CIS and the baseline, various baseline events that are going to happen for that particular CA, for example project environment is also can be CA, as in when it is identified in the project, suppose some new tool, new configuration data from customer or some technical documents arrived, that also will be part of the CA list and it has its own chain of approval and all that, based on that that is called as a baseline event and particular baseline event will identify that particular configuration identification item, then we went through the SCM phases which are nothing but initiation, planning, identification and closure, initiation basically we start the project, we do this, we appoint the CC, we appoint the chain control, configuration controller board, we also conduct CC training as part of the configuration controller and CCB, CC training basically takes care of all this project related configuration details, how it is going to be maintained, this will be general as well as specific to that particular project and the next one is the planning, so we do the identification of CL, we write the procedure and naming conventions, labeling mechanisms, versioning, review and baselines, all this will be part of the planning, then we will have the execution, so whatever the issues that we go through during the SCM or the audits we are going to correct it, that correction and changes are part of the execution, closure is upon the SCM closure, this is basically going to happen when we have the project getting identified as a closure and we will identify a closure meeting and during that meeting we will identify with our stakeholders what are things that are going to be returned, what are things that we are going to return the end of this, we are going to close the licenses or we are going to archive the files or the database or any repository elements and any materials that we need to return back to customer all this will be part of the SCM closure, so also we will introduce some of the example like objective scope what we are going to do for the SCM process, the process will establish the SCM environment and the SCM, we are going to review the final product baselines, raise CRPR, CRPR for modification of software lifecycle item, CRR is nothing but change request, PR is nothing but a problem report, change request could be an enhancement or new features, PR is nothing but a problem report, you do an issue or error in the existing element of the software this PR will be raised and PR has to get approved or rejected by the relevant stakeholders such as customers and the changes will be analyzed and the impact will be approved by the CCB, which is nothing but the configuration controller board, control board and this is a dedicated person for doing the SCM activities, so as I said who is called as the SCM or SCM admin who is also likely to call as CC, configuration controller to maintain and do a retention mechanism of all this data elements of the SDLC software development lifecycle by him, so basically status accounting with stack of CIs, delivered products when it was delivered, what are the changes, what are the change request, what are the approved request, all this and we went through configuration item versioning, this is a very important aspect, here we identify as draft version, baseline version, minor changes baseline and major changes baseline, so drafts will be usually in terms of fraction elements like 0.0, 0.2 etc, baselines will be 1, 2 in implements of the integers it will be done and any intermediate versions we are going to keep track of versioning 1.1, 1.2 etc, major changes or major major baselines will be done with the help of higher implements such as 1, 2.0, 3.0 or 10.0, 20.0 etc, this is depending on the project nature, obesity and the release mechanism. Next thing that we studied is about baseline, minimum baseline and intermediate baselines we are going to have it, this will be keep on happening during the project life cycle, so the project life cycle items will have a testing baseline, design baseline and server space form, all this will be part of the configuration item, also we studied about the work space how it is going to be maintained, this is a repository and that repository will be used for adding the files or taking out the files and updating it or adding again, this process is called check-in, check-out and the files are getting inspected or used by the verification team with the help of his workspace called verification workspace, so that is what we studied in the previous class, we go through the change management aspects in today's session, change management, so what is change, change means any update or request for changes that are going to happen on a specific item, that is something like a living document, that is something like a living code, that is something like a living deliverable, this is all part of the change and how are you going to manage it, how are you going to maintain it, this is all part of the change management, so we receive a request for change that is called a change request, first what we are going to do is we are going to document it and complete change, cycle change management will happen with the help of the below items, we analyze the impact of the particular change request, we are going to approve for the analysis what is that the impact is going to happen, how we are going to change that should be approved by the change request, approver those are nothing but project manager who is also can be part of CCB and minor changes of course of the project manager level it can become any major changes it has to go through the CCB, here major changes could be something like a major functionality or a feature or any optimization etc minor changes are something like minor comments fixing any documentation issues, documentation in the source code like enough comments are not there etc those kind of a it is called category two changes minor changes the major changes are called as category one, so likewise we are going to have the different types of changes, accordingly we are going to get it approved by different team, one is by the project manager or the project manager the other one is with the help of the board if it is a major change and that board can also have a customer involved, so making of changes we do you know element that element is already SCI we are going to check out or we are going to take it out from the configuration repository the repository will be maintained with different CM tools we will study about CM tools a lot of CM tools something like PVCS J8 or SVN, VSS there are number of tools also we have MKS etc, so visually these are some of the repository tools that are used in the embedded automotive aerospace industry and we need to have a review of the changes that are required and once we are done with the changes the review comments will have to be reworked once rework is done it is good for checking and we are going to check in with a new version number, so new version number we don't need to provide by ourselves the tool will take care by incrementing the next number that increment number how it's going to increment we are going to define during the configuration of the CM tool the configuration element tool finally we are going to have a change closure this will be through project manager updates to customer or his workbook whatever it could be that is what we follow in the change process part of the change management next incident management so what is an incident any significant unplanned event that occurs during testing or other event that requires subsequent investigation or resolution it means something has happened let us define about that something that something is going to cause during the testing or development basically we focus on testing because our presentation is about testing and that changes or that incident requires some investigation and some resolution without that attaining to that event we cannot proceed or there are certain blockages because of that event so that is nothing but an incident so that incident could be something like during testing it can happen or test case development it can happen test environment it can happen or test planning deviation it could happen while doing the execution we can get a incident so likewise it is up to the planning how we are going to define the incident or if an incident is unplanned that also can be called as an incident and under incident management that has to be taken care so something like differences in actual and expected results is nothing but an incident that means it is a failure possible causes software fault expected results incorrect test was not performed correctly so the most dangerous part is the third part is a true incident basically why because software tests or embedded software testing is supposed to be done by the dedicated testers and they are supposed to identify the faults of the develop the code and according to the requirement and the design or whatever it is they are supposed to take care of the identifying faults and the test approach or the test strategy cannot have an issue itself so that it is difficult to manage or control that incident also need to be taken care so the causes of an incident could be due to software issue or a test is failing or test is not done correctly or performed correctly and incident can be raised any code any documents or it could be any environment issue or anything that is part of the embedded software testing that is what is called as an incident next one is the incident management so once we have a incident occurred in the project so how we are going to manage is what is open incident management so first we need to identify and detect and record it what is the incident and complete details of that particular incident the occur of the event whether it is occurring again and again frequency so what is the surrounding conditions under which this incident is happening what are the preconditions during what execution this is failing so who is doing what is the response will be due to which this incident has happened likewise we have several identification and detection mechanisms that will be recorded once it is not going to analyze it is just going to capture the first step then we are going to have a quick analysis and classification we are going to prioritize suppose there are three four incidents that are occurred depending on the priority we are going to classify what sort of an incident it is and we are going to come up quickly with a quick analysis of that particular incident then once we are done with the analysis we are going to have a investigation detailed analysis so the second step is quick analysis next one is the detailed analysis okay so once we have done with the investigation the cause and the source of issue that is something like problem report with a possible solution also it will be part of that detailed analysis and action will be taken care next step called resolution and recovery so how are you going to recover the future incidents that is what recovery mechanism talks about and currently occurred incidents we have to be addressed with the resolution that we have and once we have the resolution available and the incident is no more we are going to have an incident closure and at any time it must be possible to see the current status of the reported incident so once we have the incident reported it will move into different states basically or different stages basically it is called the stages are again derived from the various actions that are going to be taken care on the address the incident so the incident is a new one we just open or reopen the incident is under incident resolution or incident is under wait stage or reject stage or fixed stage or the problem is fixed so the next stage is included to build once it is included it has to be verified whether that incident is resolved finally we are going to close it so all these stages can be seen in the mechanism of the lifecycle of that particular incident management so this is part of the incident management so that we know that what is the stage of the particular incident and this is about the statusing of the incident it has the stages of incident recorded and reported for example in terms of the incident is just new occurred the incident is accepted by the stakeholders and incident is assigned to the person who is going to resolve it the incident is in progress the incident could be on hold because there is no solution for that and temporarily it is working or the resolution is not yet complete or the resolution that has been done is not consistently working so we can make it as a on hold sort of a status or the stage then the incident is solved and it is closed so basically these are some of the incident stages that also can be used for incident management so at times what will happen in the embedded software this suddenly numerous issues or incidents are occur so definitely we are going to have a priority so priority is there but we are going to assign priority for each of the six the priority is basically decided based on the impact plus urgency of that impact impact as well as the timeline that is required to get resolved that particular incident that is what we do with the priority and accordingly all the incidents will have a priority and other things like escalation metrics escalation triggering mechanisms and incident please mind that incident could be test issue testing issue enormous suddenly from environment or some hardware has broken or crashed which we need to escalate to the higher management and higher management could resolve with an alternate mechanism or talk to customer whatever it could be so all this will be part of the incident management the escalation matrix it is called as in such cases so there are relevant stakeholders they take care of the incident management okay any report that we are going to have in terms of configuration chain management or incident management or software configuration element all this will have a heading called revision history is very important because it is part of the configuration so we need to identify or highlight that particular configuration what was done during the various revisions of that particular so here is an example that has to be there minimally in any of the artifacts it can be any design document requirement set of cases transparent document test environment index test procedures it could be test script or it could be software code anything should have a revision and the revision should have a minimum elements such as the below four or five columns so first one will have a revision number it will increment as and when we get into the new revisions and the date author who is responsible for that revision and who has approved or reviewed i put an example and what are the changes that has undergone during that revision like we have updates as per the new template there is some new template that is moved so that is going to have another revision because that revision will be mentioned as a new one likewise we are going to have a revision history another thing that we need to better compare you this month many people have seen it again depending on the type of customer you have european they follow with the sorry u s they follow with month day year europeans and Asian countries they have a very month and year so you have to be specific some countries i have seen year month is also format they use you can use a hyphen or slash or colon depending on the kind of customer so you need to take care of all these things very important so for example we are trying to send with the intention that may 5th we want to or may 20th you want to deliver something suppose you have mentioned something like 20 or may 5th may 10th let us say so you could have mentioned something like may 10th 2014 but the customer thinks that it is wrongly mentioned because it is not matching the format that u s people they follow similarly we cannot afford to have 05 102014 or our customers where we want to highlight 10th may so this is also very important so we need to take care of these things so we are interact with the customer in terms of clearly mentioning what is the revision that is taken care taken place in that particular configuration item so that needs to be spoken accurately is very important so the next one is we have studied about the configuration management incident management software configuration management having five phases sorry four phases and five stages five types of planning CI status statusing and audit all this have to be maintained through a repository that repository is nothing but a database or a physical location how are we going to maintain that physical location how are you going to address that so we use tools various tools are there which will take care of this configuration management that is what we study in cm tools all testware has to be stored in a proper way after quality checks the testware should be frozen you know what is testware all the artifacts of the testing element will be part of the testware once the artifacts are ready for some stage it has to be frozen to move for the next stage the next step is to make the testware configuration items and store them in a configuration management tool that means they are using a tool to configure it in the particular location or in the server in addition to the regular testware test cases and test documentation the description of the testing element tools used calibration reports and especially developed steps any drivers and simulators should be subject to configuration management all this any tools in documents generating environment even your wiring here wiring or the hardware changes or the hardware code how you may ask how it is going to be definitely that hardware will have a circuitry that circuit will be nothing but a diagram or the design so that design is part of the configuration item and any picture regarding that PCB or any parts something like discrete or unlogged switches or the quarters potential potential meters this also can be configured with the specific version and the vendor and other vehicles or if it is supplied by the customer that also should be configured all this will be part of the testware and you need to have a configuration management with the help of configuration management tool a configuration management tool provides the functionality to keep track of the configuration items and their changes so why it is important is need to have a track of which configuration we are using it and what are the changes that is going on currently what is getting used in the project which version of the piece of the tool we are using it so all this has to be maintained and that maintenance will be through the help of CM tool and examples of CM tools PVCS dimensions MKS SVN etc these are typically followed in embedded industry such as aerospace, telecom, automobiles there are various other tools here case and all that depending on these sort of customer and projects that is been outsourced or developed by that organization they will use it and sometimes it may happen such that the configuration tool that the offshore team uses could be different than what the customer has so it will be tricky to maintain both the versions or deliverables to the customer so we need to take care of such things when we do the project planning for the configuration management planning this will be in coordination with the customer similarly it is difficult if you use a different version of configuration tools as well this is also important across the geography that means we have a server one place we have a client at different place and both have a different versions of the tool that is been used we need to take care of the differences or we need to have the upgrade or downgrade of the particular tool so as to take care of these differences that is one important aspect of the configuration management so we will try to study a little about an example of a CM tool which is called as PVCS dimension it is a web based as well as standalone application both are there depending on the person and all those they will decide what should be used and what should be installed and this basically maintains all the recovery its configuration versions history checking checkout details adding new items all this will be part of the activity that activity can be taken for the PVCS dimensions tool you can see this has a menu of various options and is an example of a payroll this is a toolbar with that icon you can use it and basically the left hand side of this tool you can see the folder or the folder structure where the CIS or the configuration configurable items are available and we have the status of whatever the items that we have clicked or used will be available in the status bar and on the right hand side window you can see the project name and the project location working bench customer local whatever it is working on which version working on is something about the specific item which this particular window has opened that is a change request 18 or whatever it could be so any update to these elements or the configuration items that are going to be placed here definitely we will have some issue in terms of identifying it because of what or which I am going to use this tool which is nothing but it could be a change request or a problem before or it could be any failures that is resulting in using this tool for checking in checking out and all that exercises here you can see baselines and all the baselines are listed and each baseline can have a sub baselines you can see payroll applications payroll backups restore payroll calendar database huge repository this can be maintained if you have just a local C drive or D drive to maintain all you say that tomorrow I am going to maintain pre excel sheet and through my own local modifications it is very difficult in tedious if you do it for hundreds of people or hundreds of software artifacts or hundreds of components if it is one or two definitely we can maintain it and it is difficult as the configuration items pre excel and it is also important that we need to retain it in terms of retention why because the CIs are supposed to be maintained throughout the project as well as post project in terms of warranty maintenance whatever it could be or a reuse for the other projects exporting importing and all the stuff so definitely there is a need of configuration management tool in embedded software industry or the project it is a hundred percent manually to follow it without which the clients will not agree we need to have a planning for this so this is basically the key to have the related project specific items listed on the folders and each items will have intermediate versions or major versions or a baseline version all these have to be specific specified in the work instruction according to the one section the configuration we are going to configure the tool and it is going to take care throughout the project okay so that is about the configuration management or the chain management and incident management and the CM tools next we will come to the next part is called as test management so test management is nothing but testing the project and how we are going to manage it so how we are going to manage it planning of the test project is nothing but test management so we have test management in terms of various activities activity test plan planning and control test management itself test configuration management methodical support preparation phase specification phase implementation phase and completion phase so we are going to have a test management identifying all these artifacts in terms of planning of the various these items and we are going to identify the start date end date total management effort that is test management you can see the abbreviations of each of this PME is a test management MSC is a methodical methodological support TS is technical support these are basically the different activities for each of the test artifacts TCMS TCMS is the test configuration manager TST is a tester so which identifies the various efforts and it efforts during certain period so these are all will be part of the test management basically this will be part of the test project initiation and the planning so once we have done with this we are going to manage the entire project with the help of these artifacts we are going to track and the maintain it okay so test process we know a test management we have and we have the test processes which have its own bicycle model and we try to align the test process in terms of software V model so in our previous another session we studied about V model practical V model listed V model and all that so similarly test it is also a part of that V model and we take an example of this figure from that book from Bart Blokman and Edwin Motenboom in this figure you can see that multiple V development lifecycle where we have a modeled where we have depicted three V multiple development life cycle first one is being a modeling second one is the prototype third one is the final product prioritization in model we have design build in terms of development in prototype we have a design and build and in final product design and build each of this will have testing phase each of us all of these will have a testing phase so testing is also part of this V so that is how a test process is closely related with the software V model this is important why because we are going to have the testing done along with the test approach or the test scenarios how we are going to arrive at test approach or test scenarios or they are with the help of the various aspects of the development life cycle those aspects could be requirements design and the software build itself that is how the test process is very much closed and related to the V model of the project life cycle so basically the test process involves a lot of test activities there are many test design techniques that can be applied test levels test types that must be executed and the test related issues that require attention the multiple V model assists in structuring these activities and issues so by mapping this basically the test process into the multiple V model so it provides an insight into the when one can start activities and what is the time for best in terms of execution which test issues are most relevant at which stages the development process so army testing the complex situation of multiple V model is bit complex task suppose a design is very very tricky and we are not sure about the build is going to work the prototype so accordingly we are going to have the test process also bit complicated so how we are going to manage this the test manager needs an overall picture of the relevant test artifacts or the activities and issues so definitely a bigger picture and system knowledge is very important in terms of mitigating mitigating the complexity of the various tasks of course it depends on the particular project is very unique to each project but the general principles of structuring the test process always apply so next one being it is an extension of what we have seen in the previous multiple V model V development etc this is talking in detail in terms of how we have a different or multiple V model like model prototype final product has like model has a real mechanism and analysis low level requirements and we have simulation and we have a rare event testing, state transition testing, model checking all these are all aligned with the various lifecycle artifacts you can see in detail similarly for prototype we have low level requirements we have a list criteria on par with that we have a detailed design verification we have a system integration test this all we have seen right this multiple V models so it is same actually in terms of test process how it is related to software V model so we have a code review so for doing the code review we need to have code available and on par with that we are going to have testing also or the component testing and the component testing requires so instrumentation of the code and with that we are going to have the code coverage analysis also a part of the test process which is aligned to the V model that is what it talks about the final product also productization or production requirements will be there verification requirements also will be there it will be there it will be there requirements verification will be there accordingly we are going to have the product certification mechanism certification testing or acceptance testing system acceptance testing regression testing for multiple versions of the software with change in the software only more requirements or design modifications which is impacting the test so that is how it is allocated such a way that test process are aligned with the V model okay the next chapter is about testing designed by contract so what is designed by contract this is another aspect of testing which is part of the test management so test management has to define the kind of testing that is going to take care for certain things it is mostly applicable for objective components where class specification is on a client and the supplier something like color of the method we use so this is mostly applicable in object printed so there is a term called client and what is it called supplier so the methods will be there the methods are invoked by the calling function so the calling function is nothing but a client and the methods supplier which supplies the caller an approach that uses the documentation only to capture the design but also the also to entourage interaction among developers so basically through documentation on the models or any specification we are going to interact and with the help of that interaction we are covering the testing in design by contract each module has an interface specification that precisely describes what the module is supposed to do so that interface specification like ICD or interface control document will basically talks about what the module is supposed to interface and interact with the other sub modules or the main modules so may year 1997 suggest that design by contract helps ensure that modules interoperate correctly this specification called a contract there is to mention or name it as contract is not a project contract or something like that the name itself is contract so governs the governs how the module is to interact with other modules such specification cannot guarantee a module correctness but it forms a clear and consistent basis for testing and verification because we know that the interface what is supposed to be used across the entire system with the help of that specification so that will ease the V and V the contract covers mutual obligations the reconditions benefits the post conditions and consistency constants is called as invariants together these contract properties are called assertions testers care about how this contract is enforced so how it is going to be executed or improved in that system under test is what testers have to bother about so this is a standard on the process that will be moved testing the basically the use in the object oriented systems next we come to the other part of the embedded software testing called as agile testing agile testing scrum process it is called off I will not talk in detail about this but few slides we will try to go through understand what is an agile development process and what is that type of testing that is used in the industry okay so agile proponents believe that current software development process so the background behind this I will tell you in many of the industry they follow typically the process what we have laid out throughout this embedded software testing all these 30 public process whatever it could be in terms of formal planning design testing testing using various methods analogies analogies or any black box white box with a checklist guidelines and all these are all part of the standard courses that we follow but there are certain industries like semiconductor or SOCs or chip manufacturers they definitely have a process and all that stuff but as a part of sub process or what is that called short term to market or time to market when there is a duration is less so they think that this process is mostly useful or applicable so in that cases they use this so they believe that current software development process are too heavy weight or cumbersome existing one so too many things are to be done that are not directly related to software product being produced so eventually there are many things like sudden checklist guidelines for the sake of doing sometimes we do though it is a small piece of code we know that is not going to crash or is not going to fail in any case but we need to maintain because we are following the process for the entire thing does not matter how the big the complex how big the system is or how complex the system is or how small the unit is or what is the impact of that unit if it fails those things sometimes it is over burden sort of a thing so that is what the agile proponents they believe current software development is too rigid difficulty with incomplete or changing requirements short development cycles more active customer involvement needed CMM focus on process we know that CMM capability in terms of CMM level capability maturity model it is called up to five levels of maturity models are there like continuous improvement and all the stuff we also have a lean six sigma where we avoid waste and all that all this are getting followed or used actively but they believe that we can improve on that on certain things so better to use that so what is that called as agile process so agile process or methods are considered as lightweight process it is a people based rather than plan based here it is totally surrounding the process or the documentation or the checklist or the guidelines or the the underneath process basically all the activities or the methods that we use than plan than the people but in the agile method we basically will have a people based or the team based or the resource based rather than the process based or the plan based so lightweight process several agile methods are included existing it is called no single agile it is called as XP there is another thing scrum is the one model we have and extreme programming XP there is also one of the model that we have these are all basically agile methods a statement of values for the agile process see some individuals and interactions are taking the priority that is over process and tools working software over comprehensive documentation that is what the values in the agile process customer collaboration over contract negotiation basically the need of the customer and its customers client etc all that collaboratively looked into in terms of agile development and responding to change over following the plan so as we follow the plan we may have to adopt certain changes into the existing plan so we do not need to revisit again and all that following the plan with again another set of plan instead of that we can spend on this kind of change that we have for you than the plan so there are different agile methods are existing scrum is one extreme programming is another one adaptive software development ASD dynamic system development method DSDM like there are several methods that are being used scrum and extreme programming are most popular it is also called as rapid prototype development RAD and there is a website called agile alliance they basically do a research and try to promote this agile development www.agilealliance.org we can go through that talks about agile development process in particular we try to understand agile development scrum process scrum is an agile process that allows us to focus on delivering the highest business value in the shortest time so basically it is purely a commercial sort of a thing where time to market like highest business returns the shortest time that is going to be followed that is going to be used as a process that is what is called a scrum process it allows us to rapidly and repeatedly inspect actual working software every two weeks to one months this frequency is deferred so during that frequency it will be repeatedly inspected for the actual software or the working software the business sets the priorities our teams self-managed to determine the best way to deliver the highest priority features that means we have a prototype that has to be delivered to the customer on the customer approval they are going to have production and all that basically they use in the production and all this agile agile development scrum process every two weeks or at the basis anyone can see the real working software and decide to release it as is or continue to enhance for another intention that is what we do in the scrum process you can see a diagram of depicting this scrum process that whatever the frequency that we have spoken here we are going to have the artifacts or the developed items that are available so that is nothing but the sprint the sprint is basically a deck of various activities so that backlog tasks going to be expanded by the agile process and that is going to define 30 days framework and within that 30 days framework we are going to have another site like scrum meeting this scrum meeting will come up with different stakeholders in the team and they will speak about what is going to happen today what we are going to do tomorrow and all that and so we are going to come with an end product at the end of this scrum process on a cyclic way or the defined iterative way so now coming to the testing process we may think that testing is needed because it is so short 24 hours one week two week and all development itself consumes maximum time so various scope of testing of course testing can also follow sort of a quick scrum process or quick testing process it is called agile testing process so what are roles of tester in scrum actually there is no tester in formal scrum process so there is no definition of tester only it is part of the development team only so testing is carried out by the developer with unit testing so himself will identify some instrumentation try to stop or drive the various units that are being used in this scrum so testing coverage testing is carried out by product owner or the client basically the end client or the complete ownership whoever has yielded the coverage what piece of after is working what is how much of the functionality is being covered what are the requirements that is undergone likewise frequently testing by product owner each print that is a backlog of the various attacks testing acceptance criteria also will be defined so that is what we do a agile testing scrum process mechanism next type of testing that is called as test driven development so basically what we do here is test driven development we execute before we actually we do a development on the developed part and we optimize the development as we progress so as in when we do a small chunks of development on we try to test it so we basically test for the failure nature of the particular feature of the processes that we have used so test driven development means testing executed before actual development the complete development and refactoring performed to optimize development so again and again we will revisit this so we write a test that fails write just enough code and repeat it since what we are going to continuously do it since what is called as test driven development so basically it surrounds the testing aspects of the particular unit and accordingly we are going to have a development is what is called as test driven development test management and control so this is also an important thing test control so how are you going to have this test artifacts managed and controlled so what do what to do when things happen that affects the test plan so we may have to review the test plan something got affected something got changed so what are those reallocation of resources changes to the test schedule changes to the test environment changes to the entry exit criteria changes to the number of test situation changes to the test suite changes to the release date so these are some of the aspects that affects the test plan how are you going to do it that is all with the test control what we are going to do it so that is what is test management and control so for test management control also we will have several tools that is called as a test management tool as I said in one of my earlier session about this that is a test link and bugzilla I will try to go through that quickly in the next class we will try to study about test management tool defect management tool etc so that with that we will come to conclude we studied about test management agile less from test process test driven development agile development process test designed by contract and test process aligned to the software v-model so with that we will end the today's session