As technology consultants, we are usually focused on the next project coming down the pike, and we often forget to celebrate our successes. We have got a great track record of successful projects delivered by Scapa, which is quite something when you consider that only 31% of software projects are successful, and of these successful projects only 46% return high value. Success is defined as on time, budget and target.
We are often called in to solve problems caused by unsuccessful projects, or to solve problems that others cannot. And that was the case at a recent project for a European telco. They had a requirement to automate aspects of the BMC Remedy ITSM platform. We’ll talk about our approach to doing so successfully, and how that approach helped them to solve a completely separate problem. Two for the price of one!
After an initial proof of concept to showcase our technology in their environment, a detailed statement of work document was prepared with input from ourselves, the customer and a third-party organisation that was responsible for the function that we were working with. This document outlines the mutual goals and steps to achieve them were clearly defined.
Part of the document outlined the requirements that *we* would need as well. Our experience of operating in projects is often that some of the details for large scale automation are overlooked, so we specify things like sufficient access for test accounts, and prosaic things like appropriate software licensing is in place in the various environments that we target.
The project followed a typical enough approach, to begin with. We’ve written about our Expedite approach before, but essentially the approach allows results to begin to be gathered immediately. Our platform used multiple captures to get data sets for creating output and input dependencies, and dynamic parameter creation was utilised – given a large number of available parameters in even the most basic steps, this was a key efficiency.
This first phase uncovered multiple issues which were flagged for remediation. As tests were recorded, they were repeatable to drive out issues and importantly, to validate the remediations.
Furthermore, the same scripts could then be used for ongoing monitoring of end-users, and Reports are generated at the end of tests summarising timings from all individual timers and scenarios.
As this phase progressed a requirement emerged to add a single user to drive Selenium scripts that automate user interaction with Remedy through the browser, exercising the GUI, measure these timings and store any error or application messages. As this would be executed in tandem with the Scapa background load, and executed within the same environment as Scapa, it made logical sense to build this in Scapa.
A library of Selenium scripts was in situ, and these were quickly instrumented with Scapa function calls, allowing granular timings to be gathered. Background load is supplied by existing Scapa tests. Eventually, just one extra scenario was added to the test library – starting a Selenium script sequence that executed all of the available Selenium scripts sequentially. Background load was applied by the Scapa Remedy tests from the initial phase, and all timings were reported and gathered in an external dashboard, which offered a bird’s eye view into any issues.