Create an account Home  ·  Topics  ·  Downloads  ·  Your Account  ·  Submit News  ·  Top 10  
· Home
· Content
· Feedback
· News
· Search
· Statistics
· Surveys
· Top
· Topics
· Web Links
· Your_Account


The five ITIL books can be obtained directly from the publisher's website:

Or as downloadable PDFs: HERE

Current Membership

Latest: ogalijid
New Today: 16
New Yesterday: 40
Overall: 231768

People Online:
Visitors: 140
Members: 2
Total: 142 .



Don't have an account yet? You can create one. As a registered user you have some advantages like theme manager, comments configuration and post comments with your name.

Related Resources

Service related resources
Service Level Agreement

How to set up
IT Change Management
Process Info-Graphic

NOTE: ITIL is a registered trademark of OGC. This portal is totally independent and is in no way related to them. See our Feedback Page for more information.


Select Interface Language:

Please contact us via the feedback page to discuss advertising rates.

The Itil Community Forum: Forums

ITIL :: View topic - Testing for Changes
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Testing for Changes

Post new topic   Reply to topic    ITIL Forum Index -> ITIL Discussion
View previous topic :: View next topic  
Author Message

PostPosted: Fri Feb 11, 2005 10:54 am    Post subject: Testing for Changes Reply with quote

Hi, Should All the changes -irrespective of any classification be tested before implementation.

Does ITIL suggests ways of Testing ?
Back to top

PostPosted: Mon Jul 04, 2005 8:52 pm    Post subject: Reply with quote

No, you don't need to test every change, but every change shoud be permitted by the CAB of the concerned service.
Back to top

Joined: Sep 20, 2004
Posts: 9
Location: switzerland

PostPosted: Mon Jul 04, 2005 9:39 pm    Post subject: Reply with quote

That's also my opinion.

... and ITIL does not suggest ways of testing. so far i know...
gruss nuker

Back to top
View user's profile Visit poster's website
Senior Itiler

Joined: May 27, 2005
Posts: 79
Location: Madrid-Spain

PostPosted: Wed Jul 13, 2005 7:28 pm    Post subject: Reply with quote


I do not agree ITIL says that all changes should be tested, urgent changes should approve by the EC (Emergency commitee not by the CAB)

And ITIL suggest that an Independent tester test all the changes

You can find more information in ITIL blue book Service Support->Change Management read 8.5.10 in this book about urgent changes

Hope it helps
Back to top
View user's profile Send e-mail

Joined: Sep 20, 2004
Posts: 9
Location: switzerland

PostPosted: Wed Jul 13, 2005 8:36 pm    Post subject: Reply with quote

We often have very similar changes. We call them Standard-Change. Our Standard-Changes don't need to be testet every time.

- create new user
- install SW on Client (SW existing in DSL)
- install new router

In case of emergency our "emergency commitee" ist acting like the CAB of the concerned service. So also urgent cases are passing the CAB.
gruss nuker

Back to top
View user's profile Visit poster's website
Senior Itiler

Joined: Mar 12, 2005
Posts: 255
Location: Melbourne, Australia

PostPosted: Wed Jul 13, 2005 8:52 pm    Post subject: Reply with quote

A little reflection and common sense can go some way to clarifying the appropriate controls placed on changes.

You mentioned classification - of course one option is to reflect the change control scope in the classification system you use for your RFCs.

So how do you get to where you can classify a 'change' appropriately?

First consider that every change is effectively 'tested' - it's a question of whether you are going to do the testing yourself in an environment set up for that purpose, or effectively get your users and customers to do the testing for you by making the change in the live environment. If that test fails, you will know about it. Very Happy So the risk to the business is a factor in establishing the scope of your formal testing. Obviously risk can be assessed a number of ways - but always in terms of potential service disruption or degradation.

So, for example, if you are swapping a component for which there is redundancy, if it fails the alternative component will do the job, and there will be no impact. Such a change should be controlled, but you could decide to install and see, rather than test first.

In other cases you may decide the risk is negligible if the change procedures exist and are followed.

In addition there will not be scope in your test environment to support a sweeping policy covering all changes - do you have two identical networks for example? - One for testing? Basic infrastructure changes will not always be 'tested' before making the change. No technician or engineer worth their pay would install something and walkaway without diagnostics - so 'testing' is simple a post-change health check.

Another case is swapping like for like in a simple break-fix situation: Replacing a monitor, or a blown switch, with an identical model. Does this require testing?

So I would say, not 'all' changes require testing. It would be prohibitive in terms of the cost of additional time and administrative overheads.

IMHO the question that follows from this: What changes should be tested? can only be answered by sufficient configuration management. You need to be able to bring the CIs that shouldn't be changed without testing under change control, and you can only do that effectively through status accounting - which is a key process in configuration management. Equally important is the identification and recording of the dependencies and relationships that collect CIs into systems (eg., Email) or technology domains (eg, the LAN), and then into service inputs.

When a CI is brought 'in scope' of the CMDB, one of the attributes of its entry record would indicate whether changes should be formally tested prior to being changed, and what constitutes a controlled change - ie. that a break-fix swap is allowed, but an upgrade, patch, or replacement must go through the CAB with a test plan.

Once you have a reasonable level of configuration management and status accounting in place you can apply another 'test' to deciding the appropriate level of change control (including testing). Ultimately it is CI's that are 'changed'. But a change to a specific CI may (or may not) propagate to effectively be a change to a system or service of which it is a component. Whether or not this 'propagation' occurs is another indicator of the appropriate scope of your change control.

This is very useful, because in the end it is about services to the business. One of the primary reasons for change control is to protect the business. If you can assess the scope of changes in terms of the risk to, and impact on the business, you will be in a position to set the boundaries that determine the level of control you bring those changes under.
Back to top
View user's profile Send e-mail AIM Address Yahoo Messenger
Display posts from previous:   
Post new topic   Reply to topic    ITIL Forum Index -> ITIL Discussion All times are GMT + 10 Hours
Page 1 of 1

Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

Powered by phpBB 2.0.8 © 2001 phpBB Group
phpBB port v2.1 based on Tom Nitzschner's phpbb2.0.6 upgraded to phpBB 2.0.4 standalone was developed and tested by:
ArtificialIntel, ChatServ, mikem,
sixonetonoffun and Paul Laudanski (aka Zhen-Xjell).

Version 2.1 by Nuke Cops 2003

Forums ©


Logos/trademarks property of respective owner. Comments property of poster. Rest 2004 Itil Community for Service Management & Foundation Certification. SV
Site source copyright (c)2003, and is Free Software under the GNU / GPL licence. All Rights Are Reserved.