10. Configuration Management
How many times have you heard questions like what is the correct version of the software module that I have to continue its coding? Who can provide me with an accurate copy of the last year’s? Version four, one of the Expert Wave software package. What version of the design documents matches the version we are adapting to a new customer? What version of the software system is installed at ABC Industrial water changes have been introduced in the version installed at the ABC Industries site. Can we be sure that the version installed at ABC doesn’t include undocumented changes? The answers to such questions are within configuration management. The purpose of configuration management is to establish and maintain the integrity of the component or system, the software, and their relationships to one another through the project and the product lifecycle. Configuration management is keeping track of the different versions and iterations of the project’s artifacts or local products, such as documents, components and data.
To properly support testing, configuration management may involve ensuring the following all test items are uniquely identified, version controlled, tracked for changes, and related to each other. All items of testware are uniquely identified. Version controlled, tracked for changes related to each other and related to versions of the test items so that traceability can be maintained throughout the test process. All identified documents and software items are referenced unambiguously in the test documentation. During test planning, configuration management procedures and infrastructure like tools should be identified, documented and implemented. Notice here that we said that configuration management procedures and infrastructure should be implemented during test planning. Actually, we should have configuration management be ready to be used before the project starts. You will create different worker products during the test planning, test analysis, and test design. And you want everything to be included in the configuration management from day one.
11. Defect Management
Management ensures that defects are tracked from recognition to classification to correction to closure. It’s important that organizations document their defect management to process. Aside from the big words, defect management is simply the bug reporting tool that you are using. It’s a sort of database to store and track defects. This process must be agreed with all those participating in defect management, including designers, developers, testers and the product owners, depending on the organization defect logging and tracking very from very informal to very formal. I have seen companies use email systems to communicate defects and boy, how many problems have raised from this. Like a developer claims that he didn’t receive the email or the manager cannot know how many defects are currently orbit or fixed. It was a total miss. As we have mentioned before, some of the reports may turn out to describe false bostives. Remember, false bostiffs, false boss tips are defects but are not due to actual failures. For example, a test may fail when a network connection is broken or times out. This behavior does not result from a defect in the test object, but is an anomaly that needs to be investigated. Testers should attempt to minimize the number of false bosses reverted as defects.
There are many ways we can classify the defects, but we can only classify the defects if we put the right information in the defective board. Defects may be reported during coding, static analysis, reviews, dynamic testing or use of a software product. Defects may be reported for issues in code or working systems or in any type of documentation, including requirements, user stories and acceptance criteria, development documents, test documents, user manuals or installation guides. In order to have an effective and efficient defect management process, organizations may define standards for the attributes, classification and workflow of defects. Typical defect reports have the following objectives provide developers and other parties with information about any adverse event that occurred to enable them to identify specific effects, to isolate the problem with minimal the reducing test, and to correct the potential defects as needed or to otherwise resolve the problem.
Provide test managers a means of tracking the quality of the work product and the impact on the testing. For example, we can measure how many defects are orbit, how many defects per developer, how many defects per tester, how many high priority defects, how many defects per module and so on. And the last objective of defects reporting is provide ideas for development and testing process improvement. For example, for each defect the point of injection should be documented. For example, a defect in the requirement or in the code and subsequent to boss’s improvement can focus on that particular area to stop the same defect occurring again. To achieve these objectives, the defectory board has to be again very effective, to the point and very efficient. Not too many details and not too little details. I think of the defective board as an art. It should help any and all of its readers the developers, the managers, the customers, the new developer who just joined the team who has no idea how the software actually works and the tester who has to do regression testing using your defectory board few years later after releasing the software.
The report should be as helpful as possible to help the developer reduce the bug easily. Every step should be unambiguous and clear enough for anyone to understand. That’s why it’s highly recommended that the tester twice a bug or twice the Defect scenario a few times and on different configurations to make sure it will always be reducible. A defect report during dynamic testing typically includes an Identifier, a title and a short summary of the defect being reported, date of the defect report issuing, organization and author, identification of the test item, configuration item being used and environment the development lifecycle phase or phases in which the defect was observed. A description of the defect to enable reproduction and resolution, including plugs, database, DOMS screenshots or recordings if found during test execution expected and actual results scope or degree of impact severity of the defect on the intents of stakeholders urgency or priority to fix a state of the defect report. For example, orbin deferred, duplicate, waiting to be fixed, awaiting confirmation, testing the urban disclosed conclusions, recommendations and approvals. Global issues such as areas that may be affected by a change resulting from the defect.
A change history, such as the sequence of actions taken by project team members with respect to the defect, to isolate, repair and confirm it as fixed and last, references, including the test case that revealed the problem. Some of these details may be automatically included and or managed when using Defect management tools. For example, automatic assignment of Identifier assignment and update of the Defect report state during the workflow, and so on. Defects found during aesthetic testing by Tillery reviews will normally be documented in a different way, for example, in review meeting notes. An example of the content of a defective board can also be found in the ISO standard IEEE 20 911 Nine Three, which refers to and in this standard, defective boards are referred to as incident reboots.
Looking at an example of a defective board will make us understand it better. Summary Application crash on clicking the Save button while creating a new user bug ID 12345 and it’s usually automatically created module New Users menu Build Number Version number 5. 0. 1 and you will know more about the build number and version numbers in the configuration management video. Severity High where we have High, Medium, Low or we can boot one priority. Also High where we also have High, Medium, Low or one to three assigned to developer X reported by your name reported on today’s date status New Urban Active depending on the tool you are using. Environment Windows Ten SQL Server 2010 Steps to reproduce Log in into the application navigate to the user’s menu and select New User. Fill all the user information fields. Click on the Save button, see the error page exception, insert value error attached logs for more information and you can attach any logs related to the bug, if any. And also see the attached screenshot of the error page expected result on clicking Save button. It should be vomited to success message new user has been created successfully and attach application crash screenshot. Developers love screenshots. Thank you.
