 ల్ స్డాండ ధస్ట్ మి మాఆకి మ౤ారించా. 1 of this unit policies so this is the last unit that is in the software testing test management and in this session we will talk about test management basically we have studied about we have studied about the various aspects of tests in terms of test strategy, integration testing, test cases, procedures, overwrite and examples and life cycle of tests, how we are going to achieve as part of the development life cycle of embedded software testing and as part of the test life cycle, test management is also an important aspect of the embedded software testing, so how are you going to achieve this test management and the other part of test management is called configuration management, so both of them will study in this way, so basically we will study about the test process, how the test process relates to the software life cycle or V model, we know that the test process basically relates to the V model because V model is not just for the embedded software development. it is also for the testing, so that V model takes care of testing, so we studied about the various V model life cycle like PM method, multiple V model, iterative V model and etc. so this is basically the relationship of the test process between the V model, that also we will try to study in what we have studied earlier and also we have designed a method, they use for test management, then test driven development also some sort of a development in terms of understanding, providing the test hooks, so that the development can be complete for the testability, we will also study about agile system development process, how we can manage for testing use, so that is about test management, also part of the test management, the configuration management also we will try to understand. so we know that configuration is one of the important item of the embedded software life cycle, so we need to configure the various aspects of the software life cycle artifacts, so those items what are those items, how are we going to control it, how are we going to version it, how are we going to change it or change management process, how are we going to apply and what are the tools that are used in the industry for configuration management. so these aspects we will study in the test management of this unit, now what is test management, so in similar terms test management mostly refers to the activity of managing the computer software, so basically it is an activity for managing the computer software testing, so that is what the test management does. and refers, so what is configuration management, so configuration management is a discipline for systematically controlling the changes in software and supporting documents, so basically it is a process or a systematic steps for controlling the changes in software, because software move always will leave with changes, test means always will leave with changes in test cases, scenarios, procedures, execution scripts or different builds we will test it, different environment, so all this it could be hardware, it could be a tool, it could be a software, so chain management or control configuration management can be applied on various aspects of the entire software life cycle of the test. basically because we are focusing on the tests, so what are the artifacts we use in the tests of an embedded software system, so that is what we do with the configuration management, so basically it is a discipline for systematically controlling the changes in software and supporting documents. so supporting documents could be test cases, test plan and it could be software requirements itself, a design document or a unit testing, whatever it is, so that is what we do with the configuration management. test management it deals with the managing the complete software testing process, how are you going to manage each of the process elements or the artifacts, so that is what is about test management. having understood the definition of configuration management, let us move on to configuration management elements, we start with configuration management, try to understand all the items of that, then try to go through test management, so what are the configuration management elements that are there in the configuration management process. so configuration management has identification of configuration, configuration control, configuration control applies to hardware, configuration control applies to software, it applies to documents, methods, tools, next configuration status accounting, so that is one of the element, then configuration audit. so basically these four are the basic elements of the configuration management process or the configuration management activity, so each one what are we going to do, we will study in later slides like identification of configuration items, configuration control how we can control hardware, software, it could be documents, methods, tools. then the next activity is configuration support of accounting, that means we are going to generate a report in terms of, so what are the configuration items available, used, applied and accounted for the embedded software configuration. and in the end how are we going to confirm it with the standards and all that, so that is the help of audit, this is also an important item when we do the configuration management. okay the next slide is about in general the configuration management process, it is also called as CM process, the CM process for both hardware and software, as I said it can be applied for both hardware and software, so it comprises five distinct disciplines as per the standard military HDB K61A and ANSI standards AES 649. so you can see the link, you can go through that and try to understand it in detail, but it is basically a process for both hardware and software configuration items having five disciplines, so what are those disciplines. these disciplines are carried out as policies and procedures for establishing baselines and performing a standard change management process, that means these disciplines are basically carried out as a policies, that means set of standards and procedures for establishing the baselines. so what is the base and the next slide and perform the standard change process, standard change management process, that means with the established process and standards we are going to carry out these disciplines. so those disciplines are CM planning and management, configuration management and configuration planning, configuration identification, configuration control, configuration status accounting, configuration verification and audit. basically whatever elements that we have said in the general configuration management, same disciplines have to be used, here you can see there are in general four configuration elements, identification of configuration item, configuration control, accounting and audit, here we have additional step in terms of planning. so planning is the first thing that we do right, so we do when we define the embedded software testing project or product, so we are going to have a plan, so that also should be carried out as a configuration process. so this is what the additional process they talk about in military standard and anti-standard, 6-1-A as well as 6-4-1, so we will try to study in detail about each of these five disciplines. the first one being the planning and management, so we know that why we need planning, each of them will try to understand, configuration management planning and management, so configuration management planning we need to have as part of the initial stage of the embedded software testing and we are going to manage the project or product entirely with the help of the planning document, basically it is a formal document, the document will have lot of things what we have studied in our earlier work units, understanding the environment, the test the G, the process, everything, the team can carry out for the embedded software testing activities, that is what we do with that. C& planning, okay, a formal document and plan to guide the C& program that includes items such as personal responsibilities and resources, training requirements, administrative requirements including the definition of procedures and tools, base planning process, configuration control and configuration status are counting, naming conventions, audits and reviews, subcontractors, vendors, C& requirements, so basically configuration management process, discipline has the first step as configuration management planning and management, so as part of the planning, test planning we will also have a configuration management planning. This planning can be a part of that or it is part of that process but the document can be part of that or it can be separated, so what we do basically is we produce a formal document for this planning and management and we will provide a guide or pointers which are having personal, that means resources, what is the team. Who are the resources doing which functionality, what are the resources doing white box, what are the resources working on the manual testing, what are the resources responsible for configuration control itself, what are the resources which will help in terms of administrative activities, all this will be identified. Then we have responsibilities and resources, resources could be hardware, software, personal, whatever it could be, all this will be part of the planning, then we will identify training, sometimes what will happen is the embedded software testing will lead to lot of training requirements like understanding some processor, understanding a tool or understanding a client specific system. So all this part of the training requirements that also will be identified in CM plan, then administrative meeting guidelines that means administrative tasks how to meet those things will also be provided. Then including a definition of procedures and tools, that means how are you going to define, how are you going to use that tools, where we can find out those, all this will be part of this, it is a master set basically the CM planning document. Then base planning process, so we will talk about base planning in the next session or next slides, base planning is a process where we are going to identify and approve some set of artifact and how are you going to arrive at, so that information will be there in the base plan. Then configuration control and configuration status accounting, how are you going to control, how are you going to deal with the changes, how are you going to have different versions, how are you going to have different revisions, there is a difference between revisions and versions, we will talk about that. Basically controlling that in terms of configuration and how are you going to report it or account for that each of the configuration control is what we are going to define the plan. Then each configuration items, how are you going to name it, so what is the naming condition we follow for questioning it or reasoning it, that also will be spoken in the planning. Audits and reviews, who is going to audit, how are you going to audit it, there are a lot of benefits with this plan because it complies to a lot of process, quality and all that. So basically we deal with audits and reviews for this purpose and if some embedded software subsystems or systems involve a subcontractor or vendor involvement, so what are those configuration requirements that they are going to have, what are the documents, how are you going to outsource them, how are you going to control the inputs or the deliverables from them, all this will be part of this planning. The next item will be configuration identification, this is also an important item, part of the CM process or CM elements or digital. It consists of setting and maintaining baselines, basically it identifies that define the system or subsystem architecture, its components and any developments at any point in time. That means it consists of setting and maintaining the baselines of the artifacts which basically define the system or subsystem components of system architecture or any test aspects or any intermediate developments or test designs at any point of the time, so it is basically controlled, it is a basis by which changes to any part of information system are identified. That means we need to have some item available somewhere right because that item is basically an artifact which will be used for continuous improvement or continuous development or continuous changes. So without that we cannot do anything, so that needs to be available in some sort of a shelf. See how are we going to have what is that called the daily routine something like file receipt, how are we going to maintain it? We are going to maintain that in a folder right or in a file, some receipt and that receipt if you want to take out and provide for claiming in our organization we are going to use that we are going to pull it and once we are claimed it we are going to pull it back right. So we are going to control it those files or those receipts or some items, another example I can keep you we are going to you are following in the daily life. For example you carry out some activities like you go to office with the intention that you are going to carry out some activities and you will follow a lot of process while doing that and you are going to control it right, so that control is nothing but in terms of process in software industries called configuration control. For example if personal control what you are going to do is you take the vehicle you check the fuel you fill it up and you take to office you park it and once your activities work is done you are going to unpack the vehicle come back to home and park in a defined place. So basically you are controlling it and something is going to change that means vehicle is disturbed or the vehicle that you travel has got some issues. So you are going to modify something what is that modification it could be a repair so how are you going to do it by defining what is existing first. So what is the vehicle correctly you are having it or currently you are having it and identify who can do it. So basically you are going to control it in terms of identifying those things that is what is nothing but identification. So here in the configuration management process it is called as configuration identification because basically you are going to configure those aspects of the embedded software system. So it consists of setting and maintaining baselines which define the system or subsystem architecture components and any developments at any point in time. It is a basis by which changes to any part of an information system are identified is important documented and later tracked through design development testing and final delivery. Any delivery cannot or will not happen without configuration process and those delivery will have definitely certain artifacts. Those artifacts are identified with the help of an identification process called CI or configuration identification it is very important. So CI incrementally establishes and maintains the definitive current basis for configuration status accounting because that has to be reported and accounted of a system and its configuration items throughout their life cycle until the project is closed or disposed. So life cycle could have development, production, deployment, operational support or it could be requirements, design, testing, coding and testing or finally delivery. So all this process life cycle will have some artifacts in terms of entry, exit or maintenance etc. All these artifacts have to be controlled that control will have an identification is nothing but a configuration identification. This is a very important aspect of CM process. Next one configuration control. So we have identified the configuration item sorry configuration identification with items what we have to configure it then we have to control it. So as I said we need to control the identified items in the embedded software life cycle. So that includes the evaluation of all chain requests and chain proposals and their subsequent approval or disapproval. So basically this is what is the control it. So we need to control what defect has happened to the vehicle our daily travel vehicle and what is the change we are going to have it. And that change whether it is within the budget or economically we can take care in some other workstation all this can be controlled. So that is what is nothing but the configuration control. So this includes chain request. So what is that configuration we are going to update it or what is the configuration that we are going to use it. It is basically because of either a problem or it could be changes. Changes could be due to problem or due to new feature. Is it? Yes. So these changes have to be proposed first from either customer or from us or developed or test and that needs to be approved. And if there is an approval then we are going to go ahead with the changes. If we are going to be approved we are going to reconfigure as the existing one. It is the process of controlling modifications to the systems to the design hardware software. So that is where the configuration control comes into picture. The next one is the configuration status accounting. This basically includes the process of recording and reporting configuration. It is also an important item. So we need to be base lining it or into the statusing it. So where are we in terms of configuration. Basically this process deals with recording and reporting the configured items and their descriptions. So how they are configured, what are the parts are available, what is it has etc. So example is hardware software for more etc. All this will have a short description. And all departures from the baseline during design and production. That means if there is an update or if there is delivery. So that will have a report. That is what we do with the configuration status accounting. In case of suspected items or suspected problems the verification of baseline configuration and upload modifications can be quickly written. That means if we have we doubt some issue is there in one of the item that we have delivered or updated. So if you see the baseline, the baseline will give a report of what is configured and what is delivered. So we can compare with that and any modifications that are quite approved or disapproved. We can easily check with that actually. So that is where the configuration status accounting is useful. The next one is the audit, configuration verification audit. So what we do with this is an independent review of hardware and software for the purpose of assessing compliance with established performance requirements, commercial and appropriate military standard and functional allocated and product baselines. That means we have defined in the plan about how my configuration is going to change, update, deliver etc. Against that whether am I doing the configuration baselines. That is what we do with the verification audit. So this will be done basically by independent people such as quality team. So the basically review and check against the established processes and the process are defined in the plan, configuration plan. Against that whether that configuration items are reported or baselines will be verified. Configuration audits verify the system and subsystem configuration documentation complies with their functional and physical performance characteristics before acceptance into the architectural baselines. So basically what we do is we will do audit that verifies the subsystem and system documentation. So we have a checklist sort of a thing. So against the checklist item we are going to verify what is been artifacted. So that is what we do with the configuration audit. Here is an example of top level configuration activity model is basically taken from Wikipedia. You can see whatever we have seen before configuration 5 basic disciplines elements is been nicely pipelined how they are going to be modeled. So you can see 1, 2, 3, 4 and the 5th one model and in the first one that is management and planning upon program or project initiation we are going to start this activity. So there is a communication in terms of stakeholders who are going to do and there is a time resources planning and all that is going to be set into this process and we require management support for conducting this activity and we will have training and guidance. We will identify resources and facilities all this will be part of the management and planning. So basically the input arrow comprises what are the parts that are going to be there as part of this and as a output of this it can go as a request for proposal or contract input. So somebody has asked you to do is they are going to come up with this output and if we are going to request a vendor or something we are going to request them with respect to request proposal. So details of RFP and all beyond scope of this basically we need to understand output will be there as part of the management planning this will be a document formal document that will be established that will be used across the lifecycle of the embedded software testing in terms of configuration management. So this is basically a same process the output of this. So upon management and planning of the CM or configuration management the next step will be we are going to identify the various artifacts of the lifecycle what is been told in the earlier session the configuration identification. So this will have logistics maintenance plan that means what are the artifacts that are going to be used in the entire project lifecycle and also it can take inputs from systems engineering requirements function analysis allocation synthesis all this will be part of the configuration identification. And any configuration control based on view that also can be identified as a CI. This planning document also can be definitely it is a CI. The next one is a configuration control once we have identified all the CI's we are going to have a configuration control why because we need to have the changes applied on this CI's. So those CI's will be controlled which are going to be identified as a change or which are going to be updated throughout the lifecycle of the embedded software testing. So contractual provisions, upload changes, changes in the identity and in dispositions in terms of documentation and entry and exit criteria all this will be part of the configuration control. The next model next process will be configuration status accounting. So which will take inputs from the different artifacts such as CI's and control outputs and is a status and configuration information as a output that will be produced as part of the accounting. This is basically a report. Once the report is ready this will be fed into the verification and audit. So as part of the process that we have laid out in the planning and we have CI's and we have control how we are going to do all this will be reported here in the accounting and against the planning against the guidelines this will be verified whether the same thing have been reported. So physical CI configuration item or CI is also called as a computer software configuration item. Test result manufacturing engineering tool documentation all this will be part of the input against that it will be identified. So this will basically give a confidence that the product is well controlled configured and tracked. So that is where the usefulness of this model. So this is basically a good process model. This is defined in the department of difference handbook will HDBK61 a configuration management guidance. Figure 4.1 in that book talks about this accurately model. Now we have gone through the various elements. Let us try to understand each of them may be in detail in the next lecture but at least we will try to define them. Configuration elements, configuration identification. Identification of configuration item. This could be a test case, test design or any requirements. Any of these artifacts which are in physical form or which are in software form or soft form or whatever the form it is there those need to be identified. Those are all called CI's. So each CI will have a label. So that label should be unique. That means we are going to identify a software such as division A. So there is a unique label for this, unique label for software build. So every CI, CI1, CI2, CI3 whatever you are going to have should have a unique because we should be able to differentiate between each of the CI. So that is why we need to have a label for the CI. A label usually consists of two parts. Its name including the title and number and a version. You can see title and its number and a version. So each label will identify a version basically. So the version could be 1.0, 2.0, 3.0, 3.3, etc. This can be a label and there is a difference between version and provision. Basically we will try to understand the future slides. So basically the label should identify the name of that particular CI and its revision or version. So and this should follow a process or it should follow a convention that is called naming and versioning conventions. This is a definite process of identifying naming and version that we need to follow. And also we are going to have identification of baselines. Once we have all the CI's available we are going to have one baseline such as baseline 5.0, for example 4.0. This can have software item XXX, hardware item YYY or software item 1, 2, 3. All this can be labeled under one identification baseline. So that is what we are going to have identification of the baseline under configuration identification. Next, configuration control. So configuration control basically have change control. As I said any artifacts we should be able to change. We should be able to change with a control. So the change could be because of multiple resistance. Maybe I can explain in detail in the future slides when we again will touch base these slides. The changes could be due to faults or issues. So these issues are resulted in modifications. The changes could be in terms of new features. Customer has told to add a different feature and some improved version, improved improvements it can be or it could be an environmental issue, hardware changes have happened. All this have to be basically controlled. So what we were using in the earlier one and what is going to be changed. This needs to be spoken about. That is all part of the chain control. And the next one is the baseline establishment. So each changes will identify one baseline. As I said in the configuration identification they are going to identify a set of changes. So we have a set of features having 10 features in one product and we have released it. And there is a customer demand saying that we add 2 more features. So we have added 2 more features comprising 12 features. So we have earlier released 10 features as one baseline and in the future version we have released as 12 features as next baseline. So this is what we are going to establish identified baseline. So this is what we do with the baseline establishment. This also has to be controlled very well. That is what we do with the configuration control. The next one is the version management. So what we do with the version management is also very important. Each changes suppose we have identified change in the future one. So this basically identifies change in software one, software two and software three. May be basically this one, two, three are something like modules. So each module has to have its own changes. So how we are going to control? So we are going to identify as software 1.1, software 2.1, software 3.3. It is already there is a revision or version available for 3.2 and we are going to update with the incremental changes. That will become another version called 3.3. So this whole bunch can be one version, something like a software version B. Because we have changed from A with a feature 1 added and impacting on these three modules. So this is called a version. It is also very important to understand. We need to control this version management because against these versions we are going to test it and release it and the same thing will be used by the customer. So we need to have a configuration control in terms of change control, baseline establishment and version management. Next one is the configuration status accounting. As I said we need to record what is being configured. We need to report information describing the configuration items and the status. That means the status could be baseline or say in progress or waiting for review. All this will be reported. So the status of the configuration can be as per depends on again how we are going to define for a particular embedded software product and it again depends on the kind of organization that we have and the kind of work instruction that is there for the process. The process could have for the configuration items such as create, update as draft, update as rework because when the draft is done it can go for a review or I would say or draft review and review rework and updated for final review and it could be updated for baseline. Something like this, different stages of configuration item can go through in the process. So every item will be going through the configuration process basically because we have identified the configuration identification elements and each element has to go through a different process such as create, review, rework and release. It could be baseline or release or complete. So these are the stages of the configuration items. All this will be for each of the configuration. This is one configuration I have put here. It can be for multiple CIS. All this have to be reported in terms of where are we in terms of configuration status. How much we have configured? What is available in the system? All this will be provided as part of the configuration status accordingly. So the information strategy could be what is there to whom it is addressed or to whom it is available that means draft is ready for whom who is doing the review, who is doing the rework and it is under the final review and who is going to be reviewing it and also we can have when we can have additional information like at what stage it is going to for the next update similarly we can have how information also how it is going to be done. All this will be part of the configuration status. Next one is configuration audit. This is the last element of the configuration management. So what we do with the audit is auditing of the product that is being configured. So we will see the standards and the procedures that is been established in the plan configuration management plan and again is that whether the configuration items are available they are going to audit it. This will be basically done by the quality team they are going to check for the maturity of the configuration items they are going to see the completeness of the configuration items whether it is complete or in progress or it is not complete and is going to check for the compliance with the requirements that means whatever the requirements that has per CI whether it is in compliance with that we are going to check it and integrity whether it is completely integrated and it is not partial or it is not fully available those things will be part of the integrity and check for the accuracy whether it is accurate in terms of what it is supposed to present. So all this will be done with the help of audit called configuration audit. The next one is that is the five elements of the configuration management elements next we have the configuration management and testing so if we talk about testing aspects how are you going to have a configuration management for testing whatever we spoke about there is in general configuration management this can be applied for software hardware tools and everything we will focus on testing aspects of the configuration management of course we have another term called SCM it is called software configuration management I think we have studied about a CM sorry SCM management maybe today or next session okay so what should be configured and managed what should be configuration managed all test documentation test that means we know that we have right from test planning test cases, procedures, scripts execution results logs, timestamps defects and fixed issues retested artifacts all this will be part of the documentation we are going to have it that should be configured and managed documents that the test documentation is based on that means what are documents input documents that we have pointed out all should be under configuration any references of course test environment this also should be configured because we are going to use a set of environment in terms of tools hardware or any software piece all this should be controlled because we cannot have an uncontrolled environment and the control how we are going to achieve is through the configuration so each element of the environment will be configured the product to be tested the product in terms of what product we are going to test it that also should be configured and why all this are required is traceability that means we are going to trace each of this artifact against certain baseline and certain release and certain commitment that testing has to take care for a particular activity that is what we do with the configuration management and testing aspects the next part what I said is the SCM software configuration management this also an important part of the configuration management so what is the software configuration management it deals basically with the software so as per the IEE software configuration the definition goes like this SCM is the process of identifying and defining the items in the system controlling the changes of these items throughout their life cycle recording and reporting the status very important and verifying the completeness and correctness of items so all this basically deals with the same thing whatever we have defined in terms of planning and management CI configuration identification configuration control status accounting and verification or the audit so that is what SCM talks about so SCM is the process of identification defining the items in the system configuration control of the changes of the change request that are going to happen for the entire life cycle of the software they can maybe add software life cycle okay and we need to record and report that is what status accounting process it does and the last one is with validate or verify the completeness and correctness of the items whatever we spoke about in the audit and configuration auditing the product configuration in terms of compliance to the requirements that is what we do with the software configuration management so we need SCM software configuration management so when changes in a product so when are we going to apply the software configuration is that we are going to have one baseline one set of items configured we are going to apply the process when there is a change change of what changes the products or the artifacts that have been used so why SCM is required when there is a change to control the changes it is not just enough to have the changes available so that they have a minimal effect on the cost schedule and quality because if you have well controlled changes and its impact on its updates it is easy to manage and once we have easier to manage aspects of the embedded software so the effect of that will be minimal and the effect is minimal on the cost duration of the schedule quality all these aspects will be taken care when we have a proper control of the changes and the SCM helps in development and implementation activities basically with the help of SCM we can do a development and change implementation easier SCM activities help in accomplishing software quality assurance activities which provide assurance that the software products conform to specified requirements to provide confidence that quality is being put into the software that means the quality team can do their audit verification against the standards and all that against the certain artifacts and those artifacts are well controlled and configured it is easier for them to accomplish that is what it means SCM tools definitely are going to be used for taking care of the SCM and that helps in tracking the changes made along with the user name who has changed this tool can identify what is the version what is the history if there is a 1,2,3,4 versions of particular software piece that has gone through lot of changes entire history of the changes can be tracked and can be seen that is what we can maintain it with the help of SCM tools the SCM has to be in place so this can be done on the every artifact of the embedded software testing artifacts that is what we use the software configuration management here is a flow of SCM activities so what are the SCM activities we know that there is a software configuration management planning it is called SCMP then we have a SCM software configuration management then we have status accounting basically control management sorry next step is status accounting then we have a release process then we have an audit all these are surrounding the configuration identification SCM activity basically this is the control box okay first one being SCM planning next one is software configuration software configuration control software configuration status accounting software configuration audit so we will try to study in detail about all this and we will try to study process example software configuration typically followed in an embedded software industry also we will try to understand what are the roles that admin of software configuration management does and we will also try to study about version components in the next class so to conclude we studied about the basic elements of configuration management configuration movement and what are the elements of the configuration management and how it is modeled and how it is controlled in terms of various phases of the configuration management and also we detailed about each of this configuration planning control identification status accounting and audit and also we studied about software configuration management we will try to study more about SCM in the next session thank you