Custom Search

Thursday, November 27, 2008

Configuration Management Activities

The view on configuration management in this book is process oriented. Therefore, the definition includes activity areas, which can be described in terms of process descriptions. The activity areas described in detail in the following paragraphs are identification, storage, change control, and status reporting.

Configuration management has many interactions with other development and support processes.

Metadata
All the activity areas in
configuration management share metadata for items placed under configuration management. Metadata is a database concept that means data about the data stored in the database. So metadata in this context describes the configuration items. Metadata for a configuration item may include its name, the name of the person who produced the item, the production date, and references to other related configuration items.
Change control uses metadata—for example, the trace information for a configuration item for which a change is suggested. Change control does not in itself contribute to metadata, because information produced during change control will be present only if a configuration item is affected by a suggested change. A configuration item can exist without change control information, but it can't exist without metadata.



Quality Assurance Process
Configuration management interacts with quality assurance, as illustrated by the item approval process that accompanies a configuration item from production to storage. The item approval, which may be a written quality record or verbal, is a product of quality assurance. Some see it as a product of configuration management, but it's actually the gateway from production to configuration management, provided by quality assurance.


Auditing
Auditing is included in some definitions of configuration management. An audit ensures that the product—the configuration item released for use—fulfills the requirements and is complete as delivered. This includes configuration management information, so that everything required is delivered in the expected versions and that the history of each item can be thoroughly accounted for. This activity area is not considered part of configuration management in this book. It's viewed as an activity area under general quality assurance, which partly concerns the products and partly the processes, rather than a configuration management activity area.
This may be a controversial point of view, but the idea of audits is a legacy from the Department of Defense origin of configuration management. Today there is a much broader understanding in the software industry of the importance of quality assurance and, therefore, also of configuration management.
Auditing uses configuration information extensively in the form of status reports, but it also uses quality assurance techniques and methods, such as reviewing and test. In practice, people involved in configuration management also carry out the audit.

Traditional Configuration Management

Traditionally Configuration Management has four elements:
Configuration Identification
Configuration Change Control (or Change Management)
Configuration Status
Accounting
Configuration Auditing (or Verification)

These terms and definitions change from standard to standard, but are essentially the same.


Configuration Identification is the process of identifying the attributes that define every aspect of the Configuration Item. The Configuration Item is a product (hardware and/or software) that has an end-
user purpose. These attributes are recorded in Configuration Documentation and baselined. Baselining an attribute forces formal Configuration Change Control processes to be effected in the event that these attributes are changed.

Configuration Change Control is a set of processes and approval stages required to change a Configuration Item's attributes and to rebaseline them.

Configuration Status Accounting is the ability to record and report on the Configuration Baselines associated with each Configuration Item at any moment of time.

Configuration Audits are broken into Functional Configuration
Audits and Physical Audits. These Configuration Audits occur either at delivery, or at the moment of effecting the change. The Functional Configuration Audit ensures that Functional and Performance attributes of the Configuration Item are achieved, while the Physical Configuration Audit ensures that the Configuration Item is installed in accordance with the requirements of its detailed design documentation.

Configuration Management is widely used by many
military organizations to manage the technical aspects of any complex systems, including the management of weapon systems, vehicles, and information systems. The discipline combines the the capability aspects that these systems provide an organization with the issues of management of change to these systems over time.
Apart from the military, CM is equally appropriate to a wide range of fields and industry and commercial sectors.

Diagramatically Representation


Configuration Management
is a complex Technical Management model that sits in the realm of Information Management. It focuses on establishing and maintaining consistency of a product’s performance, functional and physical attributes with its requirements, design and operational information throughout its life. For information assurance, CM can be defined as the management of security features and assurances through control of changes made to hardware, software, firmware, documentation, test, test fixtures, and test documentation throughout the life cycle of an information system.

The Meaning of Configuration Management

Software CM is a discipline for controlling the evolution of software systems.

Identification: an identification scheme is needed to reflect the structure of the product. This involves identifying the structure and kinds of components, making them unique and accessible in some form by giving each component a name, a version identification, and a configuration identification.

Control: controlling the release of a product and changes to it throughout the lifecycle by having controls in place that ensure consistent software via the creation of a baseline product.

Status
Accounting: recording and reporting the status of components and change requests, and gathering vital statistics about components in the product.

Audit and review: validating the completeness of a product and maintaining consistency among the components by ensuring that components are in an appropriate state throughout the entire project life cycle and that the product is a well-defined collection of components.


The definition includes terminology such as configuration item, baseline, release and version, etc. At a high level, most designers of CM systems incorporate functionality of varying degrees to support these aspects. But at the implementation level, from the
user's viewpoint, most CM systems have different functionality. Among the many reasons for these differences are: disparate hardware platforms, operating system, and programming languages. But an interesting reason is due to the different kinds of users of a CM system. This stems from the role the user plays in the organization. In particular, a manager, a software engineer developing an application, an application customer, and an environment builder tend to see CM differently. As a result, they may want differing (albeit complementary) functionality from their CM system. For example, to a manager the term "CM" conjures up the image of a Configuration Control Board. To a software engineer, the image of baselines arise. To a customer, versions of the application arise. And to the environment builder, mechanisms such as libraries and data compression arise. All these images obviously result in different requirements for a CM system and hence possibly different functionality.

What is Configuration Management

Configuration management (CM) is the detailed recording and updating of information that describes an enterprise's computer systems and networks, including all hardware and software components. Such information typically includes the versions and updates that have been applied to installed software packages and the locations and network addresses of hardware devices. Special configuration management software is available. When a system needs a hardware or software upgrade, a computer technician can accesses the configuration management program and database to see what is currently installed. The technician can then make a more informed decision about the upgrade needed.

An advantage of a configuration management
application is that the entire collection of systems can be reviewed to make sure any changes made to one system do not adversely affect any of the other systems

Configuration management is also used in
software development, where it is called Unified Configuration Management (UCM). Using UCM, developers can keep track of the source code, documentation, problems, changes requested, and changes made.

Writing Test Cases

What is a test case
There are many ways to write test cases. Overall, we can say a test case is a code fragment that programmatically checks that another code unit - a method - functions as expected. In order to make the testing process an efficient one, it is recommended to use a testing framework. There are two major
java testing framework.
JUnit is written by Eric Gamma of the GoF fame and Kent Beck. JUnit has long been un-unchallenged in the testing framework arena.
TestNG, written by Cedric Beust is a newer framework, which uses innovative concepts, much of which have been picked up by JUnit in the 4.x versions.
Using a framework to develop your test cases has a number of advantages, most important being that others will be able to understand test cases and easily write new ones and that most development
tools enable for automated and / or one click test case execution. Which of the frameworks you'll choose, that's a matter of personal preference. Both enable you to properly test your code, are equally well supported by Java development tools that matter and both are easy to use. In this article we'll address only JUnit test case development issues.

How to Write Test Cases with JUnit
If you're using a version earlier then JUnit 4, it is mandatory for your test case to inherit from the TestCase class, like in the following code example:public class ExampleTestCase extends TestCase {...}

JUnit Coding Conventions
A JUnit test case can contain multiple tests. Each test is implemented by a method. The declaration of a test method must comply to a set of conventions in order to help JUnit and associated tools to automate the discovery and execution of tests.

These conventions are:
the name of the method must begin with "test", like in "testCreateUser",
the return type of a test method must be null,
a test method must not throw any exception,
a test method must not have any parameter.
Suppose you need to test the following method: public
User createUser(String userName, String password1, String password2) throws PasswordDeosntMatchException { ... }.
A typical test case for this method could look like this:
public class CreateUserTestCase extends TestCase {public void testCreateUser() {v ...}public void testCreateUserFailPasswordDoesntMatch() {...}}


How to Write a Success Test With JUnit
Why write three tests for one single method, you may ask? Well, this will be better explained in the article that explains how to develop test cases. For now, let's just say that you must not only test that your method
works as expected under normal conditions, but also that it fails as expected when current environment configuration requires it.The first method will simply call the method then compare the returned object with the provided parameters if the user was properly created. To compare the result with reference values you should use the assert family of methods. Also, we must not forget to force the test to fail if the exception is thrown when it is not supposed to. Here is how you could implement "testCreateUser()":
public void testCreateUser() {try {User ret = instance.createUser("john", "pwd", "pwd");// use assertEquals to compare the name// of the returned User instance with the reference valueassertEquals(ret.getUserName(), "john");// use assertEquals to compare the pasword// of the returned User instance with the reference valueassertEquals(ret.getPassword(), "pwd");} catch (PasswordDeosntMatchException e) {// force the test to fail, because the exception was thrown// and it shouldn't havefail();}}
The assertEquals method will compare the two provided values and if they're not equal, it will generate an internal exception which will inform JUnit about the failure. Also, if PasswordDeosntMatchException is thrown - knowing that this should not happen with the set of parameters we have provided - the fail() method will have the same effect. In either case, JUnit will mark the test as failed and report it as such. You can pass a message to the assertEquals and fail methods. This message will be shown in the report when that particular assertion fails, helping developers to more easily identify errors. This feature can be particularly helpful if you maintain a large test base each with many assertion points.

Certification Preparation for HP Quality Center 9.2 - HP 0M15

Certification Preparation for HP Quality Center 9.2 - HP 0M15
Course Code : CTCMQC805 Source : CresTech Course Length : 2 days

Mercury Quality Center is a web-based test management tool that provides the methodology, structure, organization, and documentation for all phases of the application testing process. It Serves as a central repository for all your testing assets and provides a clear foundation for the entire testing process. It establishes seamless integration and smooth information flow from one stage of the testing process to the next. It supports the analysis of test data and coverage statistics, to provide a clear picture of an application’s accuracy and quality at each point in its lifecycle. Because it is completely web-enabled, it supports communication and collaboration among distributed testing teams.

Duration: 2.5 Days (20 Hours)

Course Objectives

This course teaches you to: Discuss the value of Test Management Understanding the Architecture of QC Understanding the Implementation of QC at different levels of Testing Life Cycle.

Prerequisites

Candidates should be well versed with the concepts of Manual Software Testing

Intended Audience

Quality assurance engineers, and new users of Quality Center who need to implement QC and/or executives who be will involved in any part of testing

Course Outline
Quality Center - Introduction
Need of Test-Management Tool
Module (TestDirector Project, Site Administration, Customization)
Domain/Project Fundamentals
How to Get Started
Site Administration
Creating Domain/project
Adding users to project
Creating Groups
Customization

Release and Cycle creation

Test Requirements
Example of a test requirement
Importance of tracing and tracking requirements
Reviewing and building a
requirements structure
Entering requirements manually
Test Cases Creation and management
Review of an existing test case
Parameters
Building a test case structure
Creating manual test cases
Requirements coverage
Test Sets and Test Execution
Creating folders and test sets
Defining test execution flow
Setting test set properties
Manual test execution
Logging defects during manual testing
Automated test execution
Adding test hosts
Running a test set
Setting run times
Defect Tracking
Reporting defects
Searching for similar defects
Using grid filters
Deleting defects
Reporting and Analysis
Analysis menu graphs and reports
Creating editable reports with the advanced Reporting

http://www.crestechsoftware.com