Skip to main content

Service Test Models

Quality: The ability of a service or product to meet customer requirements and create value for that customer.  Perceived quality affects customer support more than any other element.  Products and services must attain a certain minimum level of quality.  No other components can make up for a significant shortfall on this one and the perceived loss of value this can create.

In business today, “Time to Value” has increasingly become one of the most significant measures an organization reviews and reports on.  Today’s ever more progressively shorter time scales for this cannot be met without being able to incorporate such practices as continuous delivery (CD), continuous integration (CI) and continuous deployment (CD), which all are dependent on our ability to do continuous testing. As many of you have certainly experienced, this need for speed continues to be a clear and present danger in our ability to create a high trust culture where testing and learning from failure is allowed and the time for this is appropriately built into the project lifecycle.

In order to meet this demand of higher release cadence, we can incorporate from the best practice discipline of Service Validation and Testing, the use of test models.  These test models will include a test plan, what is to be tested and test scripts that define how each element will be tested. This will ensure that testing will be executed consistently and in a repeatable way that is both effective and efficient. A vital concept is that we will be able to easily automate these test models which is a crucial component in being able to achieve CD, CI, CD.  Test scripts help to define the release test conditions and the expected results and test cycles.  Test models are well structured, so they provide traceability back to the stated requirements (from both a business and IT perspective).  They enable auditability through test execution, evaluation and reporting while ensuring test elements can be maintained and changed in a controlled and documented manner.

Some examples of service test models follow:
  • Service contract test model: Validates that the customer can use the service to deliver the appropriate value proposition.
  • Service contract test model: Validates that the service provider can deliver the service required and expected by the customer.
  • Service level test model: Ensures that the service provider can deliver the service level requirements, and the service level requirements can be met in the live environment.
  • Service test model: Ensures that the service provider is capable of delivering, operating and managing the new or changed service with the appropriate set of resources.

By engaging in the use of these models we can ensure that the IT staff requirements can be delivered before the actual deployment of the service.  In this way we can ensure that we have the right technological facilities in place and skills, knowledge and resources are available.  Supporting processes and resources are at the appropriate levels and that business and IT continuity has been considered.

By engaging in these best practices we can speed up our release cadence while continuing to ensure quality, reliability and agility in meeting today’s demands. 


Popular posts from this blog

What is the difference between Process Owner, Process Manager and Process Practitioner?

I was recently asked to clarify the roles of the Process Owner, Process Manager and Process Practitioner and wanted to share this with you.

Roles and Responsibilities:
Process Owner – this individual is “Accountable” for the process. They are the goto person and represent this process across the entire organization. They will ensure that the process is clearly defined, designed and documented. They will ensure that the process has a set of Policies for governance.Example: The process owner for Incident management will ensure that all of the activities to Identify, Record, Categorize, Investigate, … all the way to closing the incident are defined and documented with clearly defined roles, responsibilities, handoffs, and deliverables. An example of a policy in could be… “All Incidents must be logged”. Policies are rules that govern the process. Process Owner ensures that all Process activities, (what to do), Procedures (details on how to perform the activity) and the policies (r…

How Does ITIL Help in the Management of the SDLC?

I was recently asked how ITIL helps in the management of the SDLC (Software Development Lifecycle).  Simply put... SDLC is a Lifecycle approach to produce the software or the "product".  ITIL is a Lifecycle approach that focuses on the "service".
I’ll start by reviewing both SDLC and ITIL Lifecycles and then summarize:
SDLC  -  The intent of an SDLC process is to help produce a product that is cost-efficient, effective and of high quality. Once an application is created, the SDLC maps the proper deployment of the software into the live environment. The SDLC methodology usually contains the following stages: Analysis (requirements and design), construction, testing, release and maintenance.  The focus here is on the Software.  Most organizations will use an Agile or Waterfall approach to implement the software through the Software Development Lifecycle.
ITIL  -  is a best practice for IT service management (ITSM) that focuses on aligning IT services with the needs …

Incidents when a Defect is Involved

Question: We currently track defects in a separate system than our ticket management system. With that said, my question is does anyone have suggestions and/or best practices on how to handle incidents when a defect is involved? Should the incident be closed since the defect is being worked on in another defect tracking system if it is noted in the incident ticket? I am considering creating an incident statuses of 'closed-unresolved' so the incident can still be reported on in our ticket management system but know it is being worked on/tracked in the defect system. With defects, it is possible that we may never work on them because they are very low priority and the impact is low to the user. However, in some cases a defect is being worked on. Should we create a problem ticket instead?
Thanks, René W.

Answer: RenĂ©. In ITIL, the activity you are describing is handled by the Problem Management process. ITIL does not use the term “defect” but it does use the term “known error” to…