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!
You must be logged in to post a comment.