News

By now, most people understand that manual testing is less ideal than automated testing, but have you ever really crunched the numbers?

Have no fear. In this article, we will show an easy method for calculating just how much additional money you are spending on manual testing, and help you determine how much money you can potentially save by getting automated testing up and running in your organization. We will also take a look at the deeper ROI implications and benefits of automating your ServiceNow testing correctly.


Our example organization performs two version upgrades each year. Based on their work load and their employee headcount, they are able to perform 1 build per month consisting of 600 test cases. They typically average 10 cases per hour and pay their QA testers $80,000 per year, which we rounded to $38.50 per hour. (Note – This number only accounts for salary, and does not factor in fully burdened costs, such as insurance, benefits, and so on.) Finally, the percentage of time that can be fully dedicated to testing is a little less than half of their duties; which we average to about 45%.

STEP 1: Calculating Time Investment for Each Test Plan

From here, we can calculate how many hours are required for each regression. For a typical company, it is likely that employees will be able to manually complete 10 test plans each hour.

At 600 Test Cases, that means the company will need 60 hours to execute the test plan from end to end. In other words, a team of 2 testers will take almost 4 FTE (Full-Time Equivalent) days for each full test plan execution.

STEP 2: Calculating Cost for Each Test Plan

Now that we have the time for each test plan, the salary expense, and the percentage needed to dedicate to testing, we can calculate the cost incurred each time that a test plan is run.

Over $5,000 to run a test is obviously a serious consideration, no matter how large your company is. With that in mind, it is no wonder some companies feel the need to only test once a month.

STEP 3: Calculating Savings

Finally, we can easily find the total yearly cost by multiplying the cost per test plan with the sum of the yearly upgrade and the yearly number of builds.

As you can see, a typical company could spend almost $72,000 to complete a process that could be automated instead. That number can easily increase with even minor variations. If they were working with 800 test cases instead of 600, the total cost per year would increase to over $95,000. Or, if the number of builds per year increased to 18 instead of 12, the total would be greater than $100,000 per year.

So, How Much Would The Same Work Cost with Automated Testing?

Scratching the Surface of ROI:

Other than the cost of the solution and the implementation, automated testing would reduce your expenses by the final number calculated by using the formula above. In other words, that is the calculation of how much time and effort you can save with Cerna Solutions’ CapIO – Automated Testing for ServiceNow.

In our first example, the company would save almost $72,000 that year, minus the cost of the solution and implementation. However, the next year, that savings increases even more as the initial costs no longer apply, leading to substantial long term savings for the organization.


Big Picture ROI:

The formula above only calculates what an organization had been able to do while still manual testing. In other words, based on their previously limited resources, this is the amount of quality assurance that the company can reasonably pay for to perform the minimal coverage for the status quo of manual testing. It does not calculate what the company would need to spend in order conduct the amount of testing that would sufficiently cover their development needs.

Let’s take a look at our formula set one more time, but now let’s imagine what it would cost for a company to test as much as they NEED TO, instead of how much they can AFFORD TO.

Based on our formula, if the same company wanted to test weekly instead of monthly, this would cost $277,182 more than it would with an automated solution.

That’s a significant number to consider, but in reality, testing weekly may not be satisfactory in an environment where development is done on a daily basis. If you subtract weekends and holidays, there are about 250 working days in the year. If you increase your total builds to 250 throughout the year, an automated testing solution could save you $1,293,516 every year based on our formula above.


Beyond ROI:

This calculation is only used to identify the basic costs of a company’s application testing operation. However, it does not show the additional savings that come from other key benefits of automated testing such as finding defects earlier in the development process and preventing defects from reaching production.

This is highlighted in the 1:10:100 rule of quality assurance, which states that fixing defects in development is possibly 100 times quicker and less expensive than fixing a defect in production. While the magnitude may vary for each company, it is indisputable that defects which are not fixed in the design or implementation phase are exponentially more of an issue to fix later in production. For companies that use manual testing, those high costs are impossible to avoid without a solution that is capable of testing the areas of the application that were unexpectedly affected by the initial development. In other words, if you don’t know to look for the defect in the first place, you are unlikely to find it until it reaches production.

The Takeaway

By utilizing an automated testing system, you are doing more than just saving money on automated testing, you are significantly increasing the value of your testing far beyond anything that could be possible with a manual solution. Our example company would need to spend over 1 million dollars to achieve the same results with a manual solution. Unfortunately for those companies, testing ServiceNow development only once a month would present a significant disadvantage to their operation and dramatically hinder the type of innovation and growth that a powerful platform like ServiceNow should be able to offer.


Getting Started with CapIO

CapIO by Cerna Solutions has allowed companies – much like the one in this example – to turn a week’s worth of testing into a short 45-minute process. As one of the first automated testing solutions available for ServiceNow, it allows users to hit the ground running with over 300 pre-built commands specifically for ServiceNow, as well as additional features such as an action recorder and test creation wizard, to allow for new tests to be built with little-to-no coding required. More importantly, CapIO allows for users to create tests without fear that they will break in future versions and upgrades, saving countless hours of coding and support necessary with other solutions. This not only saves you time and money, but allows you to focus on growing and innovating your ServiceNow practice to meet its full potential.

Click here to visit CernaLabs.com and learn more about CapIO – Automated Testing for ServiceNow®

Updated: Apr 1

I hosted a webinar back in July where we built a not-so-simple Service Portal widget from scratch. If you haven’t seen it, check it out here. For those of you looking for the code, your wish has been granted. I’ve posted below the HTML, Client Controller, Server Script, and CSS for the main widget and the embedded widget.

Since July I’ve also had a few thoughts about the widget we built, mainly around whether to use spModal or $uibModal for the modal dialogue. I’d like to share this first before spilling all the code.


Thoughts on modals in Service Portal

In the webinar, we relied on a modal dialogue for presenting the pet selection widget. I was torn between whether to use the Service Portal modal wrapper (spModal), or to use the bootstrap component itself ($uibModal). Though they both result in a similar experience for the user, it’s the experience for the developer that’s quite different.


spModal is very easy to use. There used to be some nice documentation for it on gitHub, but alas, it was removed in August, due to SN product documentation politics I’m guessing. ServiceNow, if you’re reading this, PLEASE BRING BACK THE SP GITHUB REPO!!! Anyway, spModal allowed us to easily open a modal dialogue and define it’s messages, buttons, etc. The drawback is that the more advanced options were limited.


For example, in the widget we built, we wanted a ‘submit’ button for each pet in our selection. However, the ‘buttonClicked()’ function we needed to trigger was not available to us in the spModal API. So, we had to use angular.element to do some DOM manipluation in the client controller to get the user experience we wanted; and DOM manipulation from the client controller is frowned upon in front-end dev. But I’m a rebel, Dottie. I did it anyway.


Our other option was to use the bootstrap UI modal component to define our modal window. The drawback here is slightly more complex code, and having to put my CSS in a global style sheet rather than in the widget’s CSS field. Furthermore, I’d have to write my HTML template in a script tag in the main widget, but I really wanted to demonstrate embedding a widget for the purpose of logically separating views and functions.


I could have gone either way, and I could go on for another few paragraphs about the differences, pros, and cons. But you didn’t come here for a lecture on modals. You want the code for the widgets…

Anyhow, I realized since July that I didn’t have to DOM manipulation via angular.element to call the modal’s ‘clickButton()’ function. From the embedded widget I have access to parent scopes, which means that ‘clickButton()’ as well as the buttons object live just two steps above in the hierarchy. Therefore, I can call ‘$scope.$parent.$parent.buttonClicked($scope.$parent.$parent.options.buttons[0])‘ from anywhere I want in my embedded widget HTML.

Voila! All the $uibModal functions and objects are available to me when using spModal. I’ve since done this in new widgets and it works like a charm!


Don’t miss our September webinar

Be sure to reserve your place for our September 7th webinar. It’s far less technical than the last portal webinar, but just as useful. Hope to see you there!

5 Essentials All Great Service Portals Have in Common

Portal Pet Adoption Widget

Here’s all the code from the widget webinar. Enjoy!


Main Widget HTML

<div ng-if="!data.currentPet">
 <button ng-click="c.onBrowsePets('lg')" class="adopt btn btn-primary">
 ${Need emotional support?}
 </button>
</div>

<!--House for the adopted pet to live in-->
<div class="pet-house-outer-container" ng-if="data.currentPet">
 <div class="pet-house-container">
 <div class="pet" style="background: url('{{data.currentPet.photo}}') center center;background-size: cover;"></div>
 <img class="pet-house" ng-src="pet-house.pngx" />
 <div class="pet-name">
 {{data.currentPet.name}}
 </div>
 <!--Link to browse pets-->
 <a class="settings" href="javascript:void(0)" ng-click="c.onBrowsePets('lg')">
 <i class="fa fa-cog"></i>
 </a>
 </div>
</div>

<div ng-if="!data.currentPet">
 <button ng-click="c.onBrowsePets('lg')" class="adopt btn btn-primary">
 ${Need emotional support?}
 </button>
</div>

<!--House for the adopted pet to live in-->
<div class="pet-house-outer-container" ng-if="data.currentPet">
 <div class="pet-house-container">
 <div class="pet" style="background: url('{{data.currentPet.photo}}') center center;background-size: cover;"></div>
 <img class="pet-house" ng-src="pet-house.pngx" />
 <div class="pet-name">
 {{data.currentPet.name}}
 </div>
 <!--Link to browse pets-->
 <a class="settings" href="javascript:void(0)" ng-click="c.onBrowsePets('lg')">
 <i class="fa fa-cog"></i>
 </a>
 </div>
</div>

Main Widget Client Controller

function (spModal) { 
 //Including spModal service
 var c = this;
 var shared = {}; //This is an empty array we can add to and share with the modal and embedded widget.
 c.onBrowsePets = function(size){
 //This function is called by a button in the HTML
 
 shared.currentPet = c.data.currentPet; //We store the currentPet data as an object in 'shared' so that it is available to the embedded widget.

spModal.open({
 //spModal.open will open a modal, and we'll pass it the following parameters
 size: size,
 title: 'Adopt a Portal Pet!',
 widget: '*******', //Insert sys_id of the embedded widget - "Pet Selection"
 buttons: [
 {label:'${Adopt}', primary: true}
 ],
 shared: shared //We make the 'shared' array available to modal's embedded widget
 }).then(function() {
 //This function is triggered by submitting/closing the modal.
 c.data.selectedPet = shared.selectedPet; //The selected pet is shared with this widget via the 'share' object
 c.server.update(); //Send the updated data object to the server script
 });

}
}

Main Widget Server Script

(function() {

//Check the Pet Adoption table to populate the currentPet object if there is an existing adopted pet
 var userPet = new GlideRecord('u_pet_adoptions');
 userPet.addQuery('u_user',gs.getUserID());
 userPet.query();
 if(userPet.next()) {
 data.currentPet = {
 //build the currentPet object
 name: userPet.u_pet.u_name.toString(),
 photo: userPet.u_pet.u_photo.getDisplayValue().toString(),
 id: userPet.sys_id.toString()
 }
}

Main Widget CSS

img.pet-house,
div.pet,
div.pet-name,
a.settings {
 position: absolute;
}
button.adopt {
 position: relative;
 padding: 10px 20px;
 margin-bottom: 20px;
 font-size: 1.5em;
 width: 100%;
}
div.pet-house-outer-container {
 position: relative;
 height: 220px;
}
div.pet-house-container {
 position: relative;
 width: 200px;
 text-align: center;
 z-index: 9;
 margin: 0 auto;
}
div.pet {
 height: 100px;
 width: 100px;
 top: 99px;
 left: 50px;
 background-size: cover;
}
img.pet-house {
 height: 200px;
 right: 0;
 z-index: 999;
}
div.pet-name {
 width: 100%;
 top: 65px;
 color: #fff;
 text-shadow: #414141 1px 1px;
 -webkit-transform: rotate(355deg);
 -moz-transform: rotate(355deg);
 -o-transform: rotate(355deg);
 -ms-transform: rotate(355deg);
 transform: rotate(355deg);
 z-index: 9999;
}
a.settings {
 top: 10px;
 right: 30px;
 color: #7B542B;
 font-size: 1.5em;
 z-index: 99999;
}

Embedded Widget HTML

<div class="row pets">
 <div class="col-sm-6 col-md-3 pet" ng-repeat="pet in data.pets">
 <div class="thumbnail" ng-class="{'selected' : c.widget.options.shared.currentPet.name == pet.name}">
 <img ng-src="{{pet.photo}}">
 <div class="caption">
 <h3>{{pet.name}}</h3>
 <p>{{pet.bio}}</p>
 <p>
 <button ng-click="c.selectPet(pet)" class="btn btn-primary" role="button">${Adopt} {{pet.name}}</button>
 </p>
 </div>
 </div>
 </div>
</div>

Embedded Widget Client Controller

function($timeout) {
 var c = this;
 var shared = c.widget.options.shared; //Get the shared object from the "My Pet" widget
 //Function that selects the pet when you click the Adopt button
 c.selectPet = function(pet) {
 shared.selectedPet = pet;

$timeout(function(){
 //The native 'close' binding from Bootstrap UI Modals is not accessible through the spModal service, therefore...
 //We use Angular Element within a $timeout function to simulate clicking the modal's submit button
 angular.element('[ng-click*="buttonClicked"]').triggerHandler('click'); 
 //The modal's native submit button has the ng-click attribute and calls the function "buttonClicked"
 //Therefore, we can target that attribute and click it
 });
 }
 //Disable the visibility of the default modal button
 angular.element('[ng-click*="buttonClicked"]').css({visibility:'hidden'});
}

Embedded Widget Server Script

(function() {
 //Use GlideRecord to build the list of adoptable pets, store them in the data.pets object
 data.pets=[];
 var petsGR = new GlideRecord('u_pets');
 petsGR.query();
 while(petsGR.next()) {
 data.pets.push({
 name: petsGR.u_name.toString(),
 photo: petsGR.u_photo.getDisplayValue().toString(),
 bio: petsGR.u_bio.toString(),
 id: petsGR.sys_id.toString()
 });
 }
})();

Embedded Widget CSS

.thumbnail.selected {
 box-shadow: 0 0 10px 5px #3071a9;
}
.pets {
 display: -ms-flex;
 display: -webkit-flex;
 display: flex;
 flex-wrap: wrap;
}
.pet {
 display: flex; 
}

Oh, and here’s the pet house png:



#portalwebinar #spModal #uibModal


ServiceNow’s Service Portal lets anyone create a clean and intuitive experience for their users. There are a few key factors that determine whether your company’s portal will engage users or frustrate them. Join Cerna Solutions for an in-depth look at 5 essential elements of a great Service Portal experience, and what you can do to ensure that your portal saves your company time, money, and headaches.

Presenter: Jeff Pierce

Start Now

Security & Risk Solutions
IT Solutions
Business Solutions
HR Solutions
Customer Solutions
CS 2020 LOGO - solutions tagline (white)

Email:    info@cernasolutions.com

Phone:  +1 844 804 6111 (US)

               +44 (20) 33254077 (UK)

  • White LinkedIn Icon
  • White YouTube Icon
  • White Twitter Icon
Company
Insight
Products
ServiceNow Services

© 2020 Cerna Solutions, Inc. All Rights Reserved. 2056 Palomar Airport Road Carlsbad, CA, 92011.