 సిర్రార్ల పనణరంది. వార్ న్లకి లా మ్సిందా, ట్న్టాకా. నిడిటాలి �緊 ప్లి ది మేనిడా. ఆమ్మంది మార్మనేమార్టి నిారికేటిలారికి. test management understanding what is test management means so it has configuration management and test management itself so you know in configuration we have configuration items and in test management test process how test process relates to the software we design the contract test development agile development process etc we can study about that and what is test management test management mostly what commonly you refers to the activity of managing the software testing process right from the test planning till the test execution and reporting we will study what it means in the next slides what is configuration management we know that any items that are to be controlled in terms of changing or delivering etc in terms of software testing and it includes also the supporting documents all these are all part of the configuration management the examples we have test cases performed any documents SRS all these all are part of the configuration management configuration management elements are configuration items configuration control configuration status accounting and configuration audit these are the four main elements of the configuration management activity okay the configuration control can have hardware software documents methods tools whatever it could be and we do status accounting in terms of accounting all the configuration items and audit will ensure that the it is we take compliance of what is been planned so in the general we had seen the definition of CM process as per the military standard HDBK 61A or ANSI standard so the disciplines are planning configuration identification configuration control status accounting and verification and audit and their details so we had studied about CM planning and management configuration identification control status accounting verification and audit and we have seen the model how it looks like the various blocks of or the elements of the configuration management configuration identification deals with the identification of configuration items labeling of the CIS it should be unique how it should be versioning and all that we will try to study in detail about software configuration management today and what are the naming and versioning conventions that are followed in industry identification of base lines so what is baseline and all that configuration control deals with the change control baseline establishment version management configuration status accounting recording and reporting information describing configuration items and their status so the information will have what are the configuration items to whom it is addressed when it was assigned how it is going to be moved to the next stage configuration audit basically does the auditing of the product configuration it is maturity completeness complex with requirements integrity accuracy and we have configuration management testing what should be configuration management all test documentation and test rates including tools and all that articles and the test environment the product to be tested why is to be configured and tested also the traceability part so that is where is important place in terms of all the documents that is to be traceable to one of the other documents part of the software lifecycle for the embedded software testing that is where we use configuration management elements so now coming to HCM software configuration management so HCM is the process of identifying and defining the items in this form controlling the changes of these items throughout the lifecycle recording and reporting the status of outcomes and change requests and verifying the completeness and correctness of items so why HCM when changes in a products that are being developed we need software configuration management to control the changes so that they have minimal effect on the cost, schedule and quality basically we need to control the changes so that minimally the impact is being maintained addressed it helps in development and change implementation activities HCM activities help in accomplishing software quality assurance HCM tools helps in tracking and changes made along with the respective name and as we have seen these are the HCM activities blocked in terms of planning control management status accounting lease processes auditing and identification okay now coming to today's session of test management and configuration management we will try to understand software configuration management activities so what are the things that are involved in HCM planning so HCM plan is a document basically which serves as a reference for the HCM process it defines the types of documents to be managed like the requirement specification documents design documents etc the kinds of documents which are subject to frequent changes are considered to get managed this plan all defends the document name scheme based on the customer suggestion or any consensus that are happening within the configuration item the plan suggests who will be taking the responsibilities of HCM procedures document defines the HCM record which is required to be maintained the same record basically identifies all the space of the changes and who is owning it who is responsible the plan also describes the HCM tools like clear case or dimensions etc VCCS dimensions video source safe SVN JIT there are lot of tools that are there in the industry so these tools are basically used for carrying out the HCM activities so the pros and cons of the tool also and the tool selection basis also are mentioned in the plan maintaining the HCM plan it is also called as HCMP is a document separately mentioned for that is also mentioned in the document so basically all these are involved in the HCM planning so to define the HCM process how should be carried out it identifies the types of documents to be managed like requirement specification design etc also the plan will specify about the document various documents throughout the software configuration should be moved the plan suggests who will be taking the responsibilities of HCM procedures planning defines the HCM record the plan also describes the HCM tools okay continuation of the same activities software configuration identification these steps deals in identifying the items to be controlled establishing identification schemes for the items and their versions and establishing the tools and techniques to be used in managing the control items establish the configuration baseline for each configuration items base learning basically base learning is a very important activity that involves manager agreement on the content of a configurable item by a configuration control board there is a board called CCB which involves so subject matter x-quad cm project management etc basically they define and they come to a conclusion that this item can be baseline baseline is a basically an event on which all the rest of the subsystems or the sub events are going to take place like requirement as baseline means that baseline will be used for testing that baseline can be used for component testing integration testing or system testing depending on the type of baseline that we have similarly we can have baselines for the test artifacts also like test cases so we have developed the test cases and we come to a conclusion saying that these test cases are enough to go ahead for the next stage of activities so we say that as a test cases frozen this frozen is nothing but the baseline define naming scheme to identify the software configuration items of each and every document that means naming scheme and identification of that configuration item is also an important aspect that also will be done in the same activities basically software configuration identification deals in identifying the items to be controlled establishing identification schemes for the items and directions and establishing the tools and techniques to be used in one of the control systems here we establish the configuration baseline for each of the configuration item base planning involves managerial agreement of the content of the configuration item and it is called as a baseline data and the naming scheme also can be provided very customer or if customer can also have some configuration so we may need to align with the this configuration basically is also an important thing that we need to understand aligning the artifacts with customer configuration you also know the important aspect because you will also have some sort of a test artifacts or development artifacts or any other items that he wants to control along with the lender or the contractor deliverable so suppose we are a developer sorry we are a contractor or we are a delivery team delivering to the customer then we may need to align to the configuration whatever the customer has or it is also possible that he may ask for some suggestion to have a configuration by ourselves so that we can control by ourselves that itself becomes an activity on its own so it is what we do with the SEM process in identifying the software configuration okay next one is after we identify the software identification of the documents we need to control it basically that is what is called as software configuration control so basically what we do here is managing the life cycle changes the life cycle changes could be any of the test cases procedures execution scripts any input documents any reporting events etc all this life cycle artifacts and its changes maintenance will have to be managed that is what we do with the configuration control process related to what changes to make the authority to approve the changes supporting the implementation of changes all this will be part of the software configuration control next one is the concept of formal deviation from the project requirements suppose the requirement is going to change deviation in some sort of a activity then we need to control that as well in terms of deviation process the process of identifying what changes to make involve the formal procedure for submitting the recording change request evaluating the cost and impact of a proposed change all the change request are recorded to change report this is a change report that will identify what changes have been done so whatever request against which the changes have been done and what is the conclusion who is the author who is responsible how it is controlled all this will be part of the change report and evaluation is done to determine the extent of modifications that would be necessary so basically along with the change request the change request will be evaluated to determine what is the modification or the change that is going to happen so the after the evaluation what will do there is a CCB change control board so basically it comprises both technical and non-technical people in terms of deciding whether the change is necessary and can go ahead for the next updates that will be decided decided in the CCB change control board so basically CCB evaluates the technical and managerial aspects of the change request and either they will accept or ask some changes in the updates that are required or they may defer it or they may reject it for the change request so CCB has the full authority to accept or the proposed changes the upload changes will be implemented using the SCM tools is it configuration control tool that will be used which provide version management capabilities so this changes have to be definitely controlled that is what we do with the software configuration control so throughout the life cycle of the test artifacts it is going to be many changes the managing the changes is covered in software configuration and coaster this step is concerned with covering the process related to what changes to make the authority to approve the changes supporting the implementation of changes all this will be controlled in addition to these activities it covers the concept of deviation from the project requirements the process of identifying what changes to make the formal procedure for submitting and recording change request and evaluating them evaluation also in terms of cost schedule what are the changes that proposed change is going to make and we may identify some resources we may identify tools to make the change what is the procedure we are going to follow any customer involvement also is required all will be decided this decision will be taken care by the SCB sorry CCB that is configuration control board and the source of change also will be identified during that CCB meeting a customer request it could be an enhancement it could be a solution for a bug or some kind of a optimization what are it could be all those changes have to be controlled and should be documented in a change request it is called SCR software changes request if it is a software change also called as SCR if it is a change request from a problem that is been identified before it is called as SPR or software problem report basically that identifies where is a bug what change of what kind of a changes what is the cost and all that will be information provided and based on that the CCB will meet and decide on the change request and in some projects these changes are communicated using a defect tracking tools such as bugzilla for a particular change a bug is opened all communications are done through that particular bug and relevant stakeholders should be communicated accordingly so that itself will become a SCR or the software change request that will be maintained within the tool and automatically it is going to get recorded who is owning that change and who is responsible who is doing the evaluation all this will be taken care so once an SCR is prepared or all the change requests are recorded and evaluation is done to determine the extent of modifications that would be necessary based on this information the CCB or the change configuration control board evaluates the technical and material aspects of the change request and either they accept modifier check or differ the change request CCB has the full authority to accept the project in some projects CCB members are part of the offshore team and in some CCB members are entirely from the customer side also it could be or it is a mix of both customer and the other side like the offshore team or a team or any relevant stakeholders test engineer or test lead anyone who is responsible so the approved changes will be implemented using the SCM tools which provide version management capabilities examples like CVS, VSS, SVN which basically provides the version control capabilities here version control capabilities are something like check-in, add, check-in, check-out these are possible these are the basic capabilities of the tools basically it helps in identify the elements which are going to be added which are going to be checked in which are going to be checked out which are going to be moving to a different stages always part of the SCM tool so detail of all these things are not scope of this embedded software testing but as a basic understanding we need to know that software configuration control will be done through the SCM tools SCM tools help in terms of adding an element checking in basically which will help in terms of creating a version and check out for modifying anything we need to check out the element we need to update it and we are going to check-in back so that it will be in the repository of the server and the check-in check-out can continue for different stakeholders in the review rework release and freeze all these stages can be done next one the software configuration status accounting so software configuration status accounting provides the means to record and report on configuration data it involves creating a knowledge base information necessary to manage configuration effectively its purpose is to provide the configuration information that is required to required for configuration management basically it has all the information necessary to manage the configuration item basically so it maintains the information about the configuration documentation it maintains the products configuration such as version number for changes than on a particular artifact it maintains information about the products operational and maintenance documentation of the documents affected by each change and their update status information about the CM process such as the status of change request all this will be part of the configuration status software configuration status accounting enables the trivial of information concerning changes in decisions and provides a source for configuration issue of a product and all of its configuration documentation all the data collected during configuration status accounting is maintained in configuration status accounting report SEAR it is also called as configuration status accounting helps in establishing and maintaining configuration records for the configuration items okay all this will be part of the project the project will have this information in terms of any of the configuration identification done on the different artifacts and how it is controlled who is maintaining it so where the documentation is about and status of each of these items will be part of the accounting this is an activity so in a frequency they will generate this report and that report will go into the next stage of the SEAR activities that is called audit so audit will be done by the audit who will ensure that each configuration item meets its requirements basically so based on the summary that we have seen in the status accounting the configuration audit auditor will audit the various artifacts that to make sure that each configuration item is meeting its requirements is part of that particular activity a software audit is an activity performed independently is very important this will be done outside the team usually QA can be involved or there is any independent body that is designated to take care of this audit activity basically they perform independently to evaluate the conformance of software products and processes to the standards, guidelines, plans and procedures so there are planned ways of controlling and identifying and bring the process of SEAM all these SEAM activities will be audited with the help of auditor software configuration audits help in identifying that configuration management task for a particular CI has successfully achieved all of the requirements specified in the configuration baselines so configuration baselines will be identified with the details in the configuration management plan all this against that will be verified actually and there are two types of audits that are done in I take an example of one of the industry that we follow those two types of audits are FCA functional configuration audit otherwise physical configuration audit so what are those functional configuration audit is done to ensure that a configuration item to audit its consistent with its specification so there is a requirement there is a specification we make sure that as per the specification it is consistently being followed and all the CAs are appropriately configured that is what we do with the functional configuration audit the next one is physical configuration audit so this is basically done to ensure that the design reference documentation is consistent with the builds of the product that means what are eventually going to build what are we are going to test what are we are going to deliver is consistent again and again with the changes with the configuration that we have in the configuration deposit that is what we physically verify against the references that we have in the documentation here we do with the consistent check with respect to the specification what we have basically what we do is we verify that software function and its performances they are really complied with the requirement and that impact of deviation if any are analyzed and controlled all this functionality in terms of how configuration is performed is all with the help of functional configuration audit in physical configuration audit we will check for the hierarchy physical representation naming all this will be are they ready in a complete stage or what is that being followed so that is about the same activities of software configuration audit so we have gone through software configuration identification software configuration control software configuration accounting and software configuration audit these four elements are the basic elements that are usually SCM activities and planning is of course part of the project management plan or we can have it as a separate SCM plan itself some industry like aerospace they have a separate plan and that is a deliverable this itself is a configuration item again so this is a mandatory to have industries like aerospace so we need to have a SCMP or software configuration management plan document okay now let us try to go through configuration for life cycle so what are the configurable items it could be in the embedded software life cycle and how they are going to be baseline so we know that baseline is an event where we are going to baseline particular artifact saying that artifact is ready to move for next stage or next event or it is available so that will be spoken in the configuration identified list basically okay so you can see two columns one is a CI list the various documents and artifacts on the right hand side you can see a baseline on which baseline event these items are called as baseline I picked up few examples for a more from a typical embedded industry okay we when we get a outsourced embedded software testing or embedded development it could be so what we do is we first get the proposal or the contract or the statement of work so all this will be configurable again because there could be a change right over a period so definitely the change control has to happen and those should be part of the CI okay so the event is on the seat from the customer we are going to have a request for proposal or RFP or we can get a statement of work from the customer so that is the baseline we are going to baseline and we have a proposal internally we develop a technical team and the manager and the proposal once we approve internally with the help of a senior management team we are going to save it as a baseline event so this proposal will be submitted to the customer okay the next the element of lifecycle is all customer supplied items the contract is awarded we are going to have a statement of work customer supplied any standards any coding rules specifications guidelines customer requirements any tools you can provide any board for example target board for testing any equipments etc all this are considered as imported items we will maybe try to touch base this import in the configurable items all this will be part of the CA and that is called as a baseline when we receive from the customer all planning documents that we have internally project management plan project testing plan all this will be approved by the senior management and we are going to have it called as a baseline then we have engineering outputs like requirement specification design etc this also should be approved stage by stage by the customer or senior management or project management if it is internal project or it is customer oriented project based on that this will be called as a baseline event and against the baseline event we are going to baseline the particular CA's or configuration items and any project specific templates this also can be a configuration items and this basically needs to be approved by the team so that the baseline can be created then we have the test environment or the project environment this will be identified as and when any project and approved by the project manager or the test manager and next one is the hardware tools test facilities used to validate the product it could be a test equipment test laptops any wiring bloop boards any target boards any emulators type of calls any flash programmers all this part of the hardware tools that directly affects the quality of the product all this will be controlled through CI list and that also needs to be approved by the project manager to make it as a baseline so that configuration items typically follow embedded software testing or embedded software lifecycle the next one is about SCM phases what are the software configuration management phases that are involved those are four phases initiation planning execution and closure this will go in a circular fashion that is why i have put simple arrow to identify at each end of the arrow planning sorry initiation planning execution and closure so what are we going to do initiation what are we going to do planning what we are going to do in execution and how are we going to close it so these are basic elements of the SCM initiation so what are we going to initiate we are going to initiate software configuration management by appointing a configuration controller basically he controls all the configurations and we are going to appoint CCB as i said configuration control board which could comprise i will try to put configuration controller it can also be called as an admin we can maintain all the artifacts under the configuration configuration configuration configuration control board which could comprise of a PM and CC it could be a TL a team member or test member it can also involve customer as well so basically these people will take a appointment in terms of CCB when we define the project plan or the test plan and for doing these activities we need training that is also called as configuration control training and there are various roles and response related that we have for each of the initiation activity so for example we have a project manager this responsibility would be SCM planning and we will do SCM activities monitoring after attacking and he is also a CCB member so what he does is he will also be equally responsible for taking the decisions for the changes next one is the configuration controller also called as a CC so he will basically provide inputs to PM for what SCM planning he will provide the work products are identified because we need to identify the configuration items and he should make sure that it is controlled means all the checking check out admin activities creating the folders locations all this will be taken care by the CCB for the configuration control for version control he will basically do the baseline he will do the best accounting as I said in earlier slide information about the baseline artifacts in the repository of the configuration control should be recorded all these are deliverables it could be or it could be CIS so basically he has still the individuals of the test member or the test engineer as a responsibility of controlling in terms of individual item like source file or test cases etc but overall the CC takes care of the complete control next is the CCB so this board basically comprising CC, PM test lead and it can involve customer and SM that is senior manager also so this board basically authorizes the CIS identification and project baseline and changes so these are some of the important activities and they should approve also because without approval they will not occur so those are some of the responsibilities of the project manager CC and CCB this will be initiated during the initiation phase of the CCB next one is the planning so planning what we do basically we will identify the project CI identification of project folder structure and access rights is very important thing CC is and who should read access no access who should change access all this part of permission will be granted or denied by the CC based on the project planning and identifying the criteria for baseline and re-baselining identifying the naming the conventions that are followed and identifying identification of change control mechanism how it is going to be changed preparation of CM audit plan as I said configuration items have to be audited for the status accounting and the plan against that that preparation will be planned frequency or duration of that all this will be part of the planning then this is also important to review and baseline of the CM planning will be part of the planning the next two SCM phases are execution and closure in execution what we do is any configuration management issue we are going to resolve SCM audits is also part of the SCM execution change management is also an execution maintenance maintenance list of import export items list like customer deliverables supply materials returnables after the project is over all this will be part of the execution which will take as an activity during the SCM and of course maintain the control library that repositories have to be regularly back up or archived that is what the maintenance means backup archive deletion basically there is a term called retention there is a retention period any project is supposed to have a retention period why because that may go for a call back or that may go for a rollover or that need to be maintained again triggered from the customer import or internal or any maintenance or warranty whatever is required till that period retention has to be taken care all this will be part of the execution that is defined in the SCM plan this is an important SCM phase lastly what we are going to do the SCM phase is the closure all the project activities are done we are going to have the SCM closure so return of materials as applicable we are going to return either to the customer or to the vendor if we have rented out any power supplies sort of a material we are going to return them and conduct closure meeting with identified stakeholders we need to conduct closure meetings of the project so what basically it does is it identifies any lessons or practices that we have done in the project document it and that also can be configured and closed once we have done all this we are going to archive the elements the CIS as needed we are going to create a backup and put a retention and safety plan in terms of where to keep what is the location and all that this will be part of the closure activities the next one is the SCM process example how is going to be defined and all that so simple way of doing objective we are going to define the objective of the SCM process to identify items for configuration to manage baseline to control changes and library of configurable items to monitor the status to perform reviews, audits and release process of configurable items throughout the range cycle of the project SCM process is covers the planning and execution of configuration management related activities including version control change management and release management this process is followed in all the parts of the project lifecycle as identified in the project management plan or the project plan this process applies to all configuration both on outcomes documents, software and hardware required by development proposal the process may also apply after delivery of the product you need to have this process so what are the SCM process tasks, example tasks establish the CM environment configuration management environment identify the CIS create, intermediate and final product baselines, raise CR, PR CR is change request, PR is a problem report the change request could be due to problem report also problem report is nothing but identifying a problem of the tested software or tested feature and reporting them to the relevant stakeholder it could be a development team it could be a customer or a vendor anyone basically it is part of the modification in this software lifecycle perform change analysis for the PR and approve or reject the changes is also an important process report status of software lifecycle items baselines PR should be relevant stakeholders and maintain the configuration environment records is also one of the process tasks okay so next the CM activities process from the admin perspective as I said admin could be a chain controller or dedicated chain control could be there admin can be performed most of the mid size projects admin and the chain controller will be same for the particular project identified so what he does is he does perform archival retrieval release activities he does the follow data retention mechanism for the SDLC data items as I said retention is an important thing need to retain the project lifecycle artifacts till the term or the guarantee or the project is maintained in the organization with relation to the customer perform load control of the software product manage software lifecycle environment and qualified tools that is also part of the admin as part of the CM activities next is the status accounting so what we do with the status accounting is that keep track of the current identification of CIS configuration of delivered product status of change request status of output changes all this to be reported in a report format that is what we do with the status accounting basically there is a frequency like bi-weekly or weekly depending on the project nature and the size and other aspects we are going to do the status accounting accordingly and the status accounting can also report some of the items like number of SCM issues basically this is done by the CC or the admin for that particular project what are the deliverables deliverables so they are the right deliverables accepted rejected by customer all this will be reported and effort spent on SCM activities by the CC and effort spent by team team not on development or testing by on the SCM check out all the regular activities in terms of configuration control and another important thing is change request its numbers accepted rejected on hold open close so all this sort of a information will be part of the change request status report can be done by the status accounting mechanism that is what we do with the status accounting next coming to the important item called version control so what is a version so anything that identifies one configuration item with a number or the name that process is called versioning so configuration item will be versioned the version number of CA is maintained in the following format in general I am talking about basically draft versions will have 0.01 0.02 or 0.2 or it can have something like A, B, C or alpha beta theta whatever it could be so basically it is identified with an example of 0.1, 0.2 till it becomes matured and complete it will be flowing like this so you may argue like after 0.9 what I will do you can easily go with 0.91 0.92 till it reaches 1.0 basically we call 1.0 as a baseline version and that 1.0 version could have multiple baselines in next version like 2.0 3.0 basically this is a major versioning this will be taken care with the higher number in the integer so what will happen with 1.0 changes are going to happen we can create as 1.1 or we can create as 1. A 1.0 A 1.0 B 1.2 etc it is up to the definition of the planning of the SCM how we are going to have this remember this has to be done during the planning and if any major minor changes and major changes are taken versioned that can be versioned with 1.1 1.2 any major changes it will be 2.0 3.0 and once the major changes are done we can make it as a baseline 10.0 something like this so this is what we do with the baseline so what do you mean by a baseline a baseline is defined as a milestone the development of software that is marked by the release of one or more configuration items and approval of these items is obtained through a formal review so everything has to be formal so we call it as a baseline version or a baseline for an item it is a milestone in the development or testing of the software that is marked by the release of one or more CIs very important in configuration items and it requires approval of those items which are going to be obtained through a review process as we have seen in our earlier session that review items have to be completed and closed upon which we are going to say that the product is matured and reviewed and complete and against that we are going to create a milestone by the name called as a baseline so minimum baselines we can have initial baseline, delivery baselines, other baselines and it could be intermediate baselines also and of course the kind of baselines we can create in terms of versioning is minor baselines major baselines but usually they have a minor baselines, major baselines initial baselines and delivery baselines and software delivery or the before the final delivery we can intermediate baselines which has SRS design testing baselines this will be part of the baseline activities so the next one is workspace management how and workspace is getting managed we know that baseline has to be created in a repository and that repository needs to be taken care by all the stakeholders right from the SCM process people test team, development team et cetera so definitely there is a need of the workspace the workspace is nothing but a place holder having identified and available items such as CIA items in the project the workspace management or going to manage in general this picture you can see there is a baseline repository something like a server and this server the files will be either put or taken out with the help of a process called checking into code and this will be done by individuals that is called individual workspace that will be there in the desktop and for testing and verification workspace we have a separate repository and separate files will be there and that will be again using the baseline repository all these life cycles have to go through the repository it is called baseline repository and it is part of the workspace management and this all will be taken care by the individual as well as the maintenance and the control of that will be done by the CC or the chain controller configuration controller storage retrieval is performed in the control model the format, the patient access control procedure like writes and all that backup and recovery procedure how are you going to backup and how are you going to recover suppose some file will recover we are going to recover it after we get an incident report from the individual or the users backup will be used for recovery all this will be defined in the workspace management okay so so that is what we have studied about different same activities process status accounting, version control, baseline and workspace management in the next class we will study about the change management incident management region history how it should be configuration management tools etc so with that we will control today's session of the configuration management