User Acceptance Testing for development Process

[Keith]

We are struggling with finding a way to record User Acceptance Testing (UAT) for our change/development processes and would welcome feedback on how others are accomplishing this.

The Hornbill portal only allows a UAT to be triggered following the resolution of a request by clicking on the "It's Working" or "It's Still Broken" buttons. However, in our process we require an additional User Acceptance.

I am referring to the testing and acceptance of things like programming or configuration changes which require user testing in a test environment before moving to a production system.

I believe that a request should only be marked as resolved when the issue is fixed in the production environment. As such a user has no opportunity from within the portal with which they can confirm the changes are working in the test environment.

In our current process we create a User Testing task which we complete when we have written confirmation from the user that they are happy. However, our auditors will not accept that we complete the task on the users behalf.

We must have a way in the portal that the user con confirm User Acceptance at a testing stage prior to resolution of the request.

 

I have given thought to setting a request as resolved at the testing stage but this has a detrimental affect on being able to indicate the solution as now being in a production environment and we would also want to record user acceptance that the solution is also working in the production system.

 

If you are following a similar development process I would really welcome your input.

 

Regards

 

Keith

 

 

 

 

 

[Gerry]

Keith,

From an audit point of view, if you need to track and audit who does what in relation to your processes, would it not make sense for those users that are doing UAT to have access to the basic collaboration capabilities so they can be assigned and complete tasks.  This is how other organisations use the system, its exactly this type of use case the system was designed for, its a process automation tool. 

I think what you are seeking is for users to be given the "equivalent" of tasks functionality, but via the portal so they do not need to be a collaboration user on the system? Do I have that right?

Gerry

[Keith]

Hi Gerry,

Thanks for the response.

In honesty I hadn't considered that having a collaboration license might solve the problem. Essentially yes I am asking for this functionality in the portal, but that wasn't from a perspective of cost avoidance, though of course that is a consideration.

The main problem I see with your suggestion is one of potential confusion for the user. Normally we expect users to be using the portal and it may be that in a majority of requests this is fine. But if they are an SAP key User (we have hundreds of these) they "may" be required to carry out UAT on occasion. In other words, they may spend the majority of their time in the portal but on occasion they would have to login to the "live" collaboration environment to process any open activity. Am I correct in that thinking?

 

Regards

 

Keith

 

 

 

 

 

 

[Gerry]

Hi Keith,

Thats a good point and one I think I can answer.  First of all, a bit of background for the benefit of others who might read this also.  Hornbill has two portals that are fundamentally different, they are called "Customer" and "Service", the "Customer Portal" as the name suggests is for access by external customers (contacts in Hornbill speak), setting the customer aside, the remainder of this content relates to the "Service" portal which is what is of relevance. 

In the case of the "Service Portal" our platform includes the notion of a "basic user".  This type of user is in fact a collaboration user with very restricted system access designed to allow access to limited parts of the system in order to facilitate a self-service capability without the need to be a subscribed collaboration user.   However, it is possible for a full collaboration user to also log into the service portal simply because they are the same type of user account with more rights. 

"In honesty I hadn't considered that having a collaboration license might solve the problem. Essentially yes I am asking for this functionality in the portal, but that wasn't from a perspective of cost avoidance, though of course that is a consideration." 

I had not made that assumption, I was just checking to see if I was reading correctly what you are looking to achieve. The point about confusion is absolutely valid and I agree 100% with you that this would be a problem. Before I get onto that, lets talk a little bit about the BPM and Tasks on the Platform.

Although many of our customers see BPM as an integral part of our Service Management application, the reality is the SM application has been built on top of the BPM.  The BPM as a stand-alone feature is a very powerful business process automation and orchestration tool.  It is designed to support exactly the type of use case you have here.  If you need a structured, repeatable and auditable business process for compliance then the business process capabilities of Hornbill are every bit as good, if not better than the likes of dedicated tools like Oracle BPM, Tibco BPM, Bizagi BPM etc... Hornbill as a business process automation solution is actually a very cost-effective solution because with an application like SM to manage and initiate running processes, the cost of a collaboration user is just a few pounds/month compared with the other dedicated BPM solutions which can run $25 to $75/user/month.   If you have people that naturally fall outside of a typical SM user but still need to be in the process automation loop then I would urge you to think about Hornbill as a BPM tool first and foremost with SM built on top of that capability. 

So back to the Portal then.  We have already established that a collaboration user can log into the "service portal" with their collaboration user account and everything would work. You are highlighting a dichotomy we have had since we first implemented Service Manager on the platform.  We chose to create a portal because we felt that basic users would benefit from a consumer-like presentation, this was an alternative to giving basic users a limited functional experience in the normal user app.  The normal user application has been focused more towards power users rather than end users and the resultant evolution of the portal has created that gap. 

Your particular requirement can be solved in one of two ways. 

* We provide basic tasks functionality in the Service Portal to Collaboration users when they log in. This is probably the best short term solution as we could do this quickly for you if this is important.  
* We change our service portal strategy to replace the Service Portal with an alternative experience in the user app, providing a more consumer-like interface presented within  the user app while still providing the power user capabilities where needed.  This is probably the best long term solution as the above alternative leads to duplication of functionality and creating second-class citizens for some users. 

In either case your task users can avail of the Hornbill mobile app which is very geared for easy task viewing and completions. 

As I said before this has been an ongoing debate amongst our product teams internally and one that we need to bring to a close at some point. 

The other point you made is that of cost.  This does come up a lot, in particular in relation to Service Manager where the IT team sees some approvers as non-customers, don't want those people exposed to the power user interface and don't want to pay for collaboration subscriptions.  Our guiding principle for subscriptions and functional boarders comes from the basic premise (in the context of Service Manage) that if an individual is participating in the act of "providing service" then they should be licensed in some way, in the word of Hornbill this means they need to be a "platform" user (as opposed to a basic user or guest), we call these types of users Collaboration Users.  Conversely, if the person is only in receipt of service that is being provided then we consider these users a basic or contact user, and no subscription is required. 

For your requirement I would a suggest that most satisfactory approach would be to use Hornbill as your BPM tool. Your team (as they do today) are the power users who control and manage all of the requests and processes they manage, but all others that are orchestrated by, and participate in workflows would be Collaboration Users.  There is a cost involved that you have perhaps not budgeted for but I would encourage you to look at Hornbill as a BPM tool and not simply as an SM tool  in this context.  Any comparison to other BPM tools, or even task management tools we might otherwise integrate with would be quite a lot more expensive than simply using Hornbill Collaboration users and task management. 

I hope this gives you a perspective, will be very happy to discuss further with you. 

Gerry