Best Practices – UAT

When it comes to Ivanti Best Practices there is no better source than that of a seasoned Consultant with the voice of experience of years of Ivanti Professional Services, Ivanti Implementations, Upgrades, with Ivanti Service Manager (powered by HEAT IT Service Management) and Ivanti Asset Manager.

One of the most crucial steps in System Development Life Cycle (SDLC) is User Acceptance Testing (UAT), a type of system and business objective validation, performed by the end users, and business objective sign off by the project owner; not to be confused with System Testing which is performed by the Ivanti Developer and/or ISM Administrator

Many Ivanti Service Manager implementations fall short when it comes to proper UAT Testing, be it due to a lack of resources, time, or budget, but more often than not due to a shortcoming of proper UAT Action Plan, UAT Test Cases and Scripts and a lack of Best Practices, Strategy, Coordination, and Planning.

Today we shall focus on Ivanti Best Practices for UAT.

UAT Best Practices

• Daily Stand-Up Calls coordinated by the decision maker and UAT Test Lead with the UAT Test Team
  • Review of UAT Decision Tree
  • Review Test Results, questions, unexpected behaviour, workarounds, tester comments
  • Review Reference Data to-do list for PROD
  • Identify key areas for training (bullet points) 
  • Test Case Maintenance – identify new test cases or changes needed to existing test cases
  • Daily Email Summary to the ISM Consultant, bullet points, of areas that need to be addressed, identifying “show-stoppers” and “must-haves”, “questions”
    
• Scribe – Appoint a person to take meeting notes, and keep track of any “nice-to-haves”, “parking lot items”, “knowledge articles” needed.  Typically this function falls on the Knowledge Manager/Trainer.
  
• Weekly Calls with ISM Consultant to review the progress, test results, and discuss UAT remediation scope.
  
• Focus on Job Functions, not features, not enhancements, not future phases. 
  
• No Bug Hunts – The point of UAT is not to find bugs.  It’s to ensure day-to-day functions can be carried out and the steps for those job functions are documented for training purposes.   Any unexpected behaviour can be recorded in tester comments.
  
• Keep it Simple – Focus on test cases at hand.  If there are any issues, make sure to record the reference #, 1 or 2 screenshots, bullet point tester comments, no need for long novels with pages of screenshots.  

For more information and to reserve your a19 Consulting – Ivanti Best Practice System Implementation be sure to contact us!

Advertisement

Former Kifinti Solutions Consultant releases a19 UAT Test Scripts Module for Ivanti Best Practices System

Listen to my First Podcast Episode on this topic

Gregor, a former Kifinti Solutions Consultant, is without doubt a unique and distinctive authority in the Ivanti ITSM space with his consulting and development experience and extensive insight to best practices going back over 24 years with the HEAT and now Ivanti ISM/IAM products.

Gregor Anton
a19 Consulting
 
“Give me just 19 minutes of your time,
and I guarantee I will streamline your
Ivanti Service Manager implementation”

Providing HEAT Best Practices and now Ivanti Best Practices, since 1996, with his tested and true implementations and upgrades, Gregor now focuses on his company a19 Consulting which provides Ivanti Professional Services and Ivanti Best Practices.

Ivanti Best Practices

Developing, streamlining, best practices and latest solutions for fortune 500 companies and Frontrange Business Partners (Change Control, Avante Solutions, Kifinti Solutions) and Ivanti Business Partners (Kifinti Solutions, DDS IT), worldwide.

a19 UAT Test Scripts Module for Ivanti Service Manager (HEAT)

The a19 UAT Test Scripts module significantly improves your Ivanti Service Manager Implementation, Upgrades, and collaboration internally and with your Ivanti Consultant.

Gone are the days of using Excel for UAT Test Scripts, or worse, heading into darkness without UAT Test Scripts!

Long time Ivanti Consultants, Ivanti Business Partners, and Ivanti Customers alike only dream of having a simple UAT Test tool that cuts their implementation time and cost.

Lets face it, when you’re implementing Ivanti Service Manager, you want to focus on strategy and quick execution. Validation Testing is the #1 problem with most ISM Implementations, upgrades, customizations, and integrations due to a lack of UAT Test Scripts.

The #2 problem is a lack of process. With an average of over 100 test cases, you need a tool that redefines your Ivanti Service Manager Validation Process.

The #3 problem is collaboration. How do you keep your team’s morale up and focused on the key areas for testing when you don’t have a proper UAT Testing System that’s real-time, easy-to-use, and clearly defines key roles, responsibilities, and lets the Subject Matter Experts focus on their area of expertise when you don’t have a proper system?!

On top of that, you need precise, concise, timely, and relevant Test Cases and Results to make informed decision and identify actions needed, all while keeping a bird’s eye view with relevant dashboards, analytics, simplified ISM Change Control, and an executive summary.

“Give me just 19 minutes of your time,
and I guarantee I will streamline your
Ivanti Service Manager UAT Testing“

Gregor Anton | a19 Consulting

Contact Gregor at a19 Consulting

and take your UAT Testing to the next level!

Just see what others had to say! Click here to find out.

UAT Test Script Case Example

One of the biggest issues with writing UAT test cases, is knowing where to start and insisting on building your test script around the software. The fact is, you do not need access to Ivanti Service Manager (ISM, powered by HEAT IT Service Management) and it is actually encouraged not to use ISM at all when devising UAT Test Scripts.

Writing UAT Test Scripts for ISM HEAT is not unlike writing a letter to a long lost friend. At first you don’t know where to start, the first few words are tough to get out. But as you start writing, and you focus on the subject matter, the words turn into sentences, paragraphs, and pages.

Same goes for UAT Test Cases. Start simple, and remember, it’s about defining test cases for day-to-day job functions, not system testing of software, features, or functionality.

You should focus on:

• Test Script Case Subject | What are we validating?
• Test Script Case Details | Optional if you need to expand on the subject at hand
• Subject Matter Experts | Who is validating?
• Input Steps | What are the steps, think SOP, that testers need to take to carry out the test
• Input Data | Sample test data and supporting artifacts
• Expected Results | What is the expected output?

For example, if you were to write use cases for a kitchen, you would make a list of all the use cases (criteria if you will), such as Making Breakfast, Making Lunch, Coffee, Washing Dishes, etc. You don’t need to have a kitchen, and you don’t need to cook an omelette to document a use case for breakfast. All you need to do is visualize the steps, intended input, and expected results. High level, bullet form. Anything more becomes training documentation.

In this Use Case example, steps would be prepare ingredients, follow recipe, cook, season to taste, and eat. Input would be your ingredients, output is an omelette. The case steps may reference a combination of training materials (how to crack eggs, mix ingredients, recipe steps if you will) and standard operating procedures, aka SOPs (using the stove, properly food handling, storage, etc). Training materials and SOPs are important references, however separate from UAT Test Script Cases.

As you can see, UAT Test Cases should be simple, high level, and do not require ISM HEAT access, and shouldn’t be confused with Training Materials or SOPs. You should consult Subject Matter Experts (SMEs), the end users, to ensure you have covered all the possible scenarios. In this example, this would be the chef. In the real world this could be the Service Desk Manager, Service Desk Analyst Lead, Storage Techs for Asset Scanning and Storage Management, Procurement Lead for Accounting, Purchase Order related cases, and so on.

Last but not least, your focus should be on Test Case Scenarios, not features, functionality, or software. That’s System testing. We’re not testing the recipe or stove’s every button and dial. We are constructing high level use cases and scenarios, of day-to-day operations.

If you’re looking for sample ISM UAT Test Cases and Scripts from the a19 Consulting – Ivanti Best Practice System then be sure to contact us! We’ve been providing HEAT (now Ivanti Service Manager) Professional Services since 1996 and can help!

WHAT IS ISM BLACKOUT?

Blackout, is a point in time in the development process when a system becomes unavailable (off-line) by design. The term comes from Electricity “blackouts” when there is a complete electric shut down.

A best practice is to take the UAT system off-line when UAT is undergoing maintenance or configuration in preparation for End User Acceptance testing. This is to prevent any unauthorized access by end users that might want to start testing the system before it’s ready, which is never a good idea. After all, you don’t call the building inspector until you’re up to code, right? Leaving UAT available during configuration can be disastrous. Don’t make this rookie ISM mistake, you will thank me later!

ISM Blackout
UAT Best Practice Tip

Best Practice Tip – UAT Action Plan

One of the most crucial steps in System Development Life Cycle (SDLC) is User Acceptance Testing (UAT), a type of system and business objective validation, performed by the end users, and business objective sign off by the project owner; not to be confused with System Testing which is performed by the Ivanti Developer and/or ISM Administrator

Many Ivanti Service Manager implementations fall short when it comes to proper UAT Testing, be it due to a lack of resources, time, or budget, but more often than not due to a shortcoming of proper UAT Action Plan and UAT Test Cases and Scripts.

Today we will focus on a sample high level UAT Action plan:

• Refresh UAT with PROD (ISM Administrator)
• Push Asset Scanner Packages to UAT (ISM Consultant)
• Create UAT Test Cases/Scripts (ISM Administrator/Knowledge Manager; with assistance from ISM Consultant)
• Create Documentation for ISM Users (ISM Administrator/Knowledge Manager with assistance from ISM Consultant)
• Test Data Preparation (ISM Administrator)
• Test Run (ISM Administrator)
• UAT Run (ISM Administrator+ Storage Managers)
• Remediation (ISM Consultant)*
• UAT Run (ISM Administrator+ Storage Managers)*
  • Including Validation of Documentation and Knowledge Article Creation (ISM Administrator/Knowledge Manager)  
• Confirm Business Objectives – Sign Off (Project Owner)
• Schedule Push to PROD (ISM Consultant)
• Communication Plan (Core Team)
  • ISM Change Control Announcement
  • ISM Change Control Email with Documentation
    • Determine schedule
      • Before – for example 3 days before
      • At PROD Push
      • After – optional – follow up 
• PROD Push (ISM Consultant)
• Validate PROD Push (Core Team)
• PROD Emergency Support – 1 to 2 hours after push – (ISM Consultant)

If you’re looking for sample ISM UAT Test Cases and Scripts from the a19 Consulting – Ivanti Best Practice System then be sure to contact us!