Which Software Development Life Cycle (SDLC) do you follow for your Ivanti HEAT Neurons Implementation Projects?

Back in the HEAT for Windows days the only SDLC methodologies that were on the HEAT radar and considered “the norm” were Waterfall and Iterative, and there was little to no discussion about SDLC.

In 2001 Agile entered the stage Lean followed soon thereafter in 2003, and in 2008 DevOps entered the stage. Depending on who you ask, the majority of software development is still Agile, some Lean, and DevOps is the latest contender.

Meanwhile, HEAT for ITSM emerged, was acquired by Ivanti, rebranded Ivanti Service Manager, and again rebranded to Ivanti Neurons for ITSM as part of another practice, the Shift-Left Methodology.

SDLC History

Iterative 1950s

Waterfall 1970

Spiral 1986

Agile 2001

Lean 2003

DevOps 2008

ivanti heat neurons - holy trinity - stg uat production tenants - ivanti service manager ITSM - Ivanti Asset Manager ITAM

Tenant Review – Holy Trinity

On-Premise (Self hosted) and Cloud Ivanti Neurons, Ivanti Service Manager (ITSM), and Ivanti Asset Manager (ITAM) customers have 3 tenants (environments) that I like to call the “Holy Trinity”.

STG – Stage Environment for Development and System Testing by the Ivanti Consultant / Administrator only

UAT User Acceptance Testing Environment for End User validation of business requirements by the UAT Test Team

PROD – Production Environment

Any configuration changes to Ivanti Neurons ITSM/ITAM should always follow the SDLC (System Development Life Cycle), that is development & system testing in Stage, then push to UAT for End User Acceptance Testing, and finally upon UAT Sign-Off push the changes to PRODUCTION.

Ivanti HEAT ISM UAT UserAcceptanceTesting Sample Test Data - Kifinti Solutions Consultant a19 Consulting

What Input Data is best for UAT?

While obvious to the most seasoned Quality Assurance Analysts and HEAT ISM Consultants, the gathering of UAT Sample Data can be confusing to some and is often poorly documented and executed.

Having the right sample data is key to successful User Acceptance Testing (UAT).

The worst thing you can do is test milli-vanilli and only make up input data without using real data. Using made-up sample data can be confusing to UAT Testers, difficult to follow, and lead to false test results.

UAT is all about validating business requirements and confirming that you can perform your day to day job functions. So why would you want to use some made up data? You don’t. You want to use real live actual data to verify that the new system or feature behaves exactly like your old system, whether HEAT Classic, another software system, Excel, manual forms, legacy application, and so on. In my 25+ years of Ivanti HEAT ISM Implementations I have not come across an implementation that didn’t have some sort of tracking tool or method, spreadsheet, or other artifact that can be used as sample data. Even handwritten logs could make up sample data, and I don’t remember the last time I have seen one of those.

Sample input data should be real data, from your existing system, whether it’s a database, excel sheet, paper forms, or another system or artifact. For example tickets from your old HEAT Classic system, Paper Forms from a manual system (Invoices, Logs, etc), if you’re going digital, or sample rows from an Excel sheet if that’s what you’re replacing. These are just some examples.

Tip: Create a “complete workflow” artifacts of examples from start to finish in the process. One of my clients recently added procurement workflows to the Ivanti HEAT System and created a PDF of sample data for the relevant process, from inception of the procurement request, approval, quote, shipment, receipt, asset tagging, stock administration, invoice, and payment. The artifact was through and included sample data from every step. Some digital, others print outs, and even handwritten notes on the invoices. All of which were important sample data for User Acceptance Testing. It was a one time effort by the Subject Matter Expert (SME) and was invaluable throughout UAT, Training, and overall for discussion purposes. Intangibles were positive user morale, adoption, and a clear understanding of UAT Testers as to what data to use and how the new system would benefit them relating back to how they were doing things before and how that was going to change in the new way of doing things. In other words, the sample data artifacts were valuable Training Knowledge and used for review and discussion purposes, and during ongoing UAT Status Calls and meetings.

Bottom line, use real data that represents the typical type of data to expect and the UAT Team members can relate to. Tip: Ask yourself if the data could be used for training purposes. If it can, then include it as an artifact for training documentation. If it can’t, then ask yourself if the sample data is a good representation of a typical day in the life of the end user.

Furthermore, keep in mind that when there are changes, upgrades, or issues, you will want to have sample UAT Test Data to fall back to.


What is UAT Testing?

  • The purpose of User Acceptance Testing (UAT) is to test use cases, that is specific day-to-day operations in the life of an end-user and their required tasks to perform their job function
  • UAT Testing differs from System Testing in that System Testing is focused on software functionality.   UAT Testing is focused on job function, that is day to day operations can be performed.  Therefor access to Ivanti Service Manager (powered by HEAT) is not needed to build UAT Test cases, in fact it is discouraged to use HEAT as your focus should be on building use cases about day to day operations, operating procedures, such as Logging an Incident, searching for customers, assigning 2nd level support, and so on.
  • Regression testing refers to testing of existing functionality to ensure that recent changes do not adversely affect existing features.  For example, when implementing Asset Management, the existing Incident functionality is tested to test use cases such as creating an incident, creating a task, updating incidents, closing tasks, incidents, etc. In addition to UAT Test Scripts, you will want to do a comparison of existing workspaces, existing functionality, and existing features, to ensure existing functionality has not been impacted.

If you’re looking for sample UAT Test Scripts, be sure to contact us!

PS: Be sure to also read my article at IT Chronicles: “Everything you know about UAT is WRONG!