White box testing – This testing is based on knowledge of the internal logic of an application’s code. Also known as Glass box Testing. Internal software and code working should be known for this type of testing. Tests are based on coverage of code statements, branches, paths, conditions.

Unit testing – Testing of individual software components or modules. Typically done by the programmer and not by testers, as it requires detailed knowledge of the internal program design and code. may require developing test driver modules or test harnesses.

Incremental integration testing – Bottom up approach for testing i.e continuous testing of an application as new functionality is added; Application functionality and modules should be independent enough to test separately. done by programmers or by testers.

Integration testing – Testing of integrated modules to verify combined functionality after integration. Modules are typically code modules, individual applications, client and server applications on a network, etc. This type of testing is especially relevant to client/server and distributed systems.

Functional testing – This type of testing ignores the internal parts and focus on the output is as per requirement or not. Black-box type testing geared to functional requirements of an application.

System testing – Entire system is tested as per the requirements. Black-box type testing that is based on overall requirements specifications, covers all combined parts of a system.

End-to-end testing – Similar to system testing, involves testing of a complete application environment in a situation that mimics real-world use, such as interacting with a database, using network communications, or interacting with other hardware, applications, or systems if appropriate.

Sanity testing – Testing to determine if a new software version is performing well enough to accept it for a major testing effort. If application is crashing for initial use then system is not stable enough for further testing and build or application is assigned to fix.

Regression testing – Testing the application as a whole for the modification in any module or functionality. Difficult to cover all the system in regression testing so typically automation tools are used for these testing types.

Acceptance testing -Normally this type of testing is done to verify if system meets the customer specified requirements. User or customer do this testing to determine whether to accept application.

Load testing – Its a performance testing to check system behavior under load. Testing an application under heavy loads, such as testing of a web site under a range of loads to determine at what point the system’s response time degrades or fails.

Stress testing – System is stressed beyond its specifications to check how and when it fails. Performed under heavy load like putting large number beyond storage capacity, complex database queries, continuous input to system or database load.

Performance testing – Term often used interchangeably with ’stress’ and ‘load’ testing. To check whether system meets performance requirements. Used different performance and load tools to do this.

Usability testing – User-friendliness check. Application flow is tested, Can new user understand the application easily, Proper help documented whenever user stuck at any point. Basically system navigation is checked in this testing.

Install/uninstall testing – Tested for full, partial, or upgrade install/uninstall processes on different operating systems under different hardware, software environment.

Recovery testing – Testing how well a system recovers from crashes, hardware failures, or other catastrophic problems.

Security testing – Can system be penetrated by any hacking way. Testing how well the system protects against unauthorized internal or external access. Checked if system, database is safe from external attacks.

Compatibility testing – Testing how well software performs in a particular hardware/software/operating system/network environment and different combination s of above.

Comparison testing – Comparison of product strengths and weaknesses with previous versions or other similar products.

Alpha testing – In house virtual user environment can be created for this type of testing. Testing is done at the end of development. Still minor design changes may be made as a result of such testing.

Beta testing – Testing typically done by end-users or others. Final testing before releasing application for commercial purpose.

ITIL is published in a series of books, each of which cover an IT management topic. The names ITIL and IT Infrastructure Library are registered trademarks of the United Kingdom’s Office of Government Commerce (OGC). ITIL gives a detailed description of a number of important IT practices with comprehensive checklists, tasks and procedures that can be tailored to any IT organization.

Definition

The Information Technology Infrastructure Library (ITIL) is a set of concepts and techniques for managing information technology (IT) infrastructure, development, and operations.

ITIL is also a series of documents that are used to aid the implementation of a lifecycle framework for IT Service Management. This customizable framework defines how Service Management is applied within an organization. It also aligned with the international standard, ISO 20000.

Overview

What is now called ITIL version 1, developed under the auspices of the CCTA, was titled “Government Information Technology Infrastructure Management Methodology” (GITMM) and over several years eventually expanded to 31 volumes in a project initially directed by Peter Skinner and John Stewart at the CCTA. The publications were retitled primarily as a result of the desire (by Roy Dibble of CCTA) that the publications be seen as guidance and not as a formal method and as a result of growing interest from outside of the UK Government.

IT Service Management as a concept is related but not equivalent to ITIL which, in Version 2, contained a subsection specifically entitled IT Service Management (ITSM).The combination of the Service Support and Service Delivery volumes are generally equivalent to the scope of the ISO/IEC 20000 standard (previously BS 15000).

The IT Infrastructure Library originated as a collection of books each covering a specific practice within IT Service Management. After the initial publication, the number of books quickly grew within ITIL v1 to over 30 volumes. In order to make ITIL more accessible (and affordable) to those wishing to explore it, one of the aims of ITIL v2 was to consolidate the publications into logical ‘sets’ that grouped related process guidelines into the different aspects of IT management, applications and services.

Below is the description of all eight ITIL version 2 books.

Service Delivery

• Service Level Management: Service Level Management is the process that forms the link between the IT organization and customers.

• Financial Management for IT Services: Financial Management for IT Services.

• Capacity Management: Capacity Management is the discipline that ensures IT infrastructure is provided at the right time in the right volume at the right price, and ensuring that IT is used in the most efficient manner.

• Availability Management: Availability is usually calculated based on a model involving the Availability Ratio and techniques such as Fault Tree Analysis, and includes the following elements:

· Serviceability – where a service is provided by a 3rd party organization, this is the expected availability of a component.

· Reliability – the time for which a component can be expected to perform under specific conditions without failure.

· Recoverability – the time it should take to restore a component back to its operational state after a failure.

· Maintainability – the ease with which a component can be maintained, which can be both remedial and preventative.

· Resilience – the ability to withstand failure.

· Security – the ability of components to withstand breaches of security.

• IT Service Continuity Management: Continuity management is the process by which plans are put in place and managed to ensure that IT Services can recover and continue should a serious incident occur. It is not just about reactive measures, but also about proactive measures – reducing the risk of a disaster in the first instance.

Service Support

• Incident Management: An ‘Incident’ is any event which is not part of the standard operation of the service and which causes, or may cause, an interruption or a reduction of the quality of the service. The objective of Incident Management is to restore normal operations as quickly as possible with the least possible impact on either the business or the user, at a cost-effective price.

• Problem Management: The objective of Problem Management is to minimize the impact of problems on the organization. Problem Management plays an important role in the detection and providing solutions to problems (work around & known errors) and prevents their reoccurrence.

• Configuration Management: Providing information on the IT infrastructure to all other processes and IT management. Enabling control of the infrastructure by monitoring and maintaining information on all the resources needed to deliver services.

• Change Management: Ensure that standardized methods and procedures are used for efficient and prompt handling of all changes, in order to minimize the impact of Change-related incidents upon service quality, and consequently to improve the day-to-day operations of the organization.

• Release Management: Implement changes to IT services taking a holistic (people, process, technology) view which considers all aspects of a change including planning, designing, building, testing, training, communications and deployment activities.

ICT Infrastructure Management

• ICT Design and Planning: ICT Design and Planning provides a framework and approach for the Strategic and Technical Design and Planning of ICT infrastructures. It includes the necessary combination of Business (and overall IS) strategy, with technical design and architecture.

• ICT Deployment Management: ICT Deployment provides a framework for the successful management of design, build; test and roll-out (deploy) projects within an overall ICT program. It includes many project management disciplines in common with PRINCE2, but has a broader focus to include the necessary integration of Release Management and both functional and non functional testing.

• ICT Operations Management: ICT Operations Management provides the day-to-day technical supervision of the ICT infrastructure. Often confused with the role of Incident Management from Service Support, Operations is more technical and is concerned not solely with Incidents reported by users, but with Events generated by or recorded by the Infrastructure. ICT Operations may often work closely alongside Incident Management and the Service Desk, which are not-necessarily technical in order to provide an ‘Operations Bridge’. Operations however should primarily work from documented processes and procedures and should be concerned with a number of specific sub-processes, such as: Output Management, Job Scheduling, Backup and Restore, Network Monitoring/Management, System Monitoring/Management, Database Monitoring/Management Storage Monitoring/Management.

• ICT Technical Support: ICT Technical Support is the specialist technical function for infrastructure within ICT. Primarily as a support to other processes, both in Infrastructure Management and Service Management, Technical Support provides a number of specialist functions: Research and Evaluation, Market Intelligence (particularly for Design and Planning and Capacity Management), Proof of Concept and Pilot engineering, specialist technical expertise (particularly to Operations and Problem Management), creation of documentation (perhaps for the Operational Documentation Library or Known Error Database).

Security Management

The ITIL-process Security Management describes the structured fitting of information security in the management organization. ITIL Security Management is based on the code of practice for information security management also known as ISO/IEC 17799.

A basic concept of the Security Management is the information security. The primary goal of information security is to guarantee safety of the information. Safety is to be protected against risks. Security is the means to be safe against risks. When protecting information it is the value of the information that has to be protected. These values are stipulated by the confidentiality, integrity and availability. Inferred aspects are privacy, anonymity and verifiability.

The Business Perspective

The Business Perspective is the name given to the collection of best practices that is suggested to address some of the issues often encountered in understanding and improving IT service provision, as a part of the entire business requirement for high IS quality management. These issues are:

• Business Continuity Management describes the responsibilities and opportunities available to the business manager to improve what is, in most organizations one of the key contributing services to business efficiency and effectiveness.

• Surviving Change. IT infrastructure changes can impact the manner in which business is conducted or the continuity of business operations. It is important that business managers take notice of these changes and ensure that steps are taken to safeguard the business from adverse side effects.

• Transformation of business practice through radical change helps to control IT and to integrate it with the business.

• Partnerships and outsourcing.

This volume is related to the topics of IT Governance and IT Portfolio Management.

Application Management

ITIL Application Management set encompasses a set of best practices proposed to improve the overall quality of IT software development and support through the life-cycle of software development projects, with particular attention to gathering and defining requirements that meet business objectives.

This volume is related to the topics of Software Engineering and IT Portfolio Management.

Software Asset Management

It deals with managing the software assets of the organization.

Planning to Implement Service Management

The ITIL discipline – Planning to Implement Service Management attempts to provide practitioners with a framework for the alignment of business needs and IT provision requirements. The processes and approaches incorporated within the guidelines suggest the development of a Continuous Service Improvement Program (CSIP) as the basis for implementing other ITIL disciplines as projects within a controlled, program of work. Planning to Implement Service Management is mainly focused on the Service Management processes, but also generically applicable to other ITIL disciplines.

One more book has been added as supplementary for small IT organizations.

ITIL Small-Scale Implementation

ITIL Small-Scale Implementation provides an approach to the implementation of the ITIL framework for those with smaller IT units or departments. It is primarily an auxiliary work, covering many of the same best practice guidelines as Planning To Implement Service Management, Service Support and Service Delivery but provides additional guidance on the combination of roles and responsibilities and avoiding conflict between ITIL priorities.

Formally: ISO 20000-1 (‘part 1′) “promotes the adoption of an integrated process approach to effectively deliver managed services to meet the business and customer requirements”. It comprises ten sections:

• Scope

• Terms & Definitions

• Planning and Implementing Service Management

• Requirements for a Management System

• Planning & Implementing New or Changed Services

• Service Delivery Process

• Relationship Processes

• Control Processes

• Resolution Processes

• Release Process

ISO 20000-2 (‘part 2′) is a ‘code of practice’, and describes the best practices for service management within the scope of ISO20000-1. It comprises the same sections as ‘part 1′ but excludes the ‘Requirements for a Management system’ as no requirements are imposed by ‘part 2′.

ISO 20000, like its BS 15000 predecessor, was originally developed to reflect best practice guidance contained within the ITIL (Information Technology Infrastructure Library) framework, although it equally supports other IT Service Management frameworks and approaches including Microsoft Operations Framework. It comprises two parts: a specification for IT Service Management and a code of practice for service management.

The standard was first published in December 2005.

• a set of procedures that cover all key processes in the business;

• monitoring processes to ensure they are effective;

• keeping adequate records;

• checking output for defects, with appropriate corrective action where necessary;

• regularly reviewing individual processes and the quality system itself for effectiveness; and

• facilitating continual improvement

A company or organization that has been independently audited and certified to be in conformance with ISO 9001 may publicly state that it is “ISO 9001 certified” or “ISO 9001 registered.” Certification to an ISO 9000 standard does not guarantee the compliance (and therefore the quality) of end products and services; rather, it certifies that consistent business processes are being applied.

The CMM has been used to assess the maturity levels of organization areas as diverse as software engineering, system engineering, project management, risk management, system acquisition, information technology (IT) or personnel management, against a scale of five key processes, namely: Initial, Repeatable, Defined, Managed and Optimized.CMM was developed by the Software Engineering Institute (SEI) at Carnegie Mellon University in Pittsburgh. It has been used extensively for avionics software and government projects around the world.

The Capability Maturity Model for Software (also known as the CMM and SW-CMM) has been retired, and CMMI (Capability Maturity Model Integration) replaces it. The SEI no longer maintains the SW-CMM model, its associated appraisal methods, or training materials, nor does the SEI offer SW-CMM training.

The statistical representation of Six Sigma describes quantitatively how a process is performing. To achieve Six Sigma, a process must not produce more than 3.4 defects per million opportunities. A Six Sigma defect is defined as anything outside of customer specifications. A Six Sigma opportunity is then the total quantity of chances for a defect. Process sigma can easily be calculated using a Six Sigma calculator.

Process management is the ensemble of activities of planning and monitoring the performance of a process. It is the application of knowledge, skills, tools, techniques and systems to define, visualize, measure, control, report and improve processes with the goal to meet customer requirements profitably.

ANSI Standard (ANSI/ASQC A3/1978)