Prototyping – build functional platform on ServiceNow

Prototyping is a development stage to enhance the development of your ServiceNow instance or any other piece of software with a visualization of a target feature, dashboard or entire system. Proved to do wonders in the automotive industry, it’s does the same in software development projects, where it helps to:

  • Define the business need that underlies your new development project (a new feature implementation),
  • Identify available fixes to the existing feature handicaps.

ServiceNow prototyping – when your feature needs it

ServiceNow features are a great example where prototyping comes in handy. Examples?

Case

Consider an organisation struggling to manage the process of recording time cards for employees. Their team is working from several locations on a number of different contracts or tasks. Historically, this business handled these on paper and manually.

Superficial improvements

As time and technology progressed, the company favored an Excel-based approach for collecting the data. The process required to calculate costs for the associated employee wages and/or customer invoices. Now a much more sophisticated solution is in place that integrates with the payroll system and CRM systems for invoicing.

The past process

The use of a technological solution doesn’t mean that the process is efficient and effective:

  1. The individual employees use excel to record the hours worked,
  2. A data analyst inputs this information into an application for assigning the hours to the relevant contract,
  3. Once complete, the finance department gets an email with the hours for the worker’s wages that require processing,
  4. They’re always waiting for the input, putting pressure on each department. There is too much room for human error and dependency on individual people. In addition, the excel sheets become incorrectly formatted and version control is often difficult to manage.

On the way to a new solution

The organisation wants to streamline and automate this process. After gathering the requirements and understanding the existing process, the project team starts to get a clearer picture of the AS IS and the TO BE processes. The gap in the middle is going to be the project for a new solution.

The challenge

The team seems to have an understanding of this gap and the requirements, but they don’t know exactly how the new solution should look like and how it will perform.

The solution – prototyping or PoC

A prototype or proof of concept (PoC) can be a suitable way to communicate this to a customer. By creating an interactive and clickable visualization of the system based on the the requirements, the project team can demonstrate how it can look like, how users interact with the interface etc.

This visualization means that the customer will find it much easier to provide feedback. The suggestions shared will be a recipe for a better end product.

Prototyping pros & cons in the ServiceNow environment

Prototyping is an additional stage to include in your delivery process and takes time and costs. However, this one is only a superficial cost, and as at the end of the day prototyping facilitates the development process, helps reduce the number of iterations, prevents nonfunctional delivery and poor user experience.

Yet, either in the ServiceNow environment or any other, prototypes don’t suit every project or business objectives. Here are pros and cons of using this tool.

PROS
  • Great for visualization,
  • Effective for finalizing UI design,
  • Useful if stakeholder’s requirements are ambiguous or vague,
  • Support brand-new concepts,
  • Smaller investment to test if an idea is worth an investment,
  • Demonstrates the solution possibilities.
CONS
  • Requires additional resources,
  • Its limited functionality could alter the perception of the finished solution,
  • Can increase expectations for the project delivery schedule (Users see something working after a few days, so they expect the implementation to follow the same pace),
  • The project team can focus too much on one aspect and miss the main objective, or the bigger picture.

Prototype ServiceNow features or not

Overall, prototyping is a useful stage to assist a project team during the design phase. It can be very effective for the agreement of the design elements. The added layer of visualization is perfect for showing users what they can expect from a new solution. However, it shouldn’t be automatically included for every project as it can absorb unnecessary time and budget.

If the requirements are functional and clearly understood, it’s useless to spend additional time on prototyping. One of the advantages of developing on a platform like ServiceNow, is the configuration and time spent producing a prototype isn’t wasted. This work can often be reused and just extended during the main project.

An Introduction to the Automatic Testing Framework in ServiceNow

Automated Testing Framework (ATF) has always been a key topic around ServiceNow testing, especially for those keen in Quality Assurance. One of those people is Zherald, SPOC’s Security and QA lead who has a passion for Testing and making sure systems are safe and working as expected.

Zherald’s Introduction to ServiceNow’s Automatic Testing Framework

The ATF is a solution that saves time and frustration. It allows previously built test scenarios to be used many times. Previously, the only real option for ServiceNow was to use a 3rd party solution. Many of which were very expensive. ServiceNow has solved this issue by introducing the Automated Testing Framework module, available since the Istanbul release. Since its introduction to the Now Platform, ATF has been greatly improved and now offers a lot of help for performing Automated Testing. It offers flexibility, especially for MSP’s as they are easily transferable from one instance to another; using XML update sets. From a Quality Assurance (QA) perspective, there are some huge benefits:

  • The possibility to create test suites, containing test cases that can be executed whenever they’re needed.
    Great Feature: Running and executing the suites in a scheduled job. This means you may schedule the time when you want the tests to run in the future.
  • Capturing screenshots when a defect is located. Very helpful to prove in which test case or element the test fails.

Assessing the Solution

We used the ATF for automating the testing for our internal tool Project Management Application, built on the Now Platform. The solution itself, as its name suggests, is used for project management and is utilised by various user groups – project managers, developers, testers, etc. The automation we have implemented is focused on the lifecycle of Agile Projects. This covers all components such as backlogs, sprints and stories. Another aspect we have managed to automate is the verification of forms. This applies to each project component and includes the presence of fields, their default values and attributes. Our test scenarios are divided into suites, each one covering the above-mentioned project component. Running an exemplary suite for the Sprint will trigger the following test to be executed:

  • Sprint lifecycle including every possible Sprint state change.
    • This scenario also verifies mandatory fields and button availability, as each may differ at various stages of Sprint lifecycle.
  • Availability of fields and their attributes on a new Sprint form.
    • Attributes include: mandatory fields, editability and default values.
  • Availability of UI actions on new Sprint form.

As the ATF in ServiceNow has been introduced quite recently, we encountered some issues and bugs. These were not critical issues that made it impossible to use ATF, but we are looking for them to be resolved in the next ServiceNow releases.

An Example

One issue was the inability to populate journal fields (Additional Comments or Work Notes) that can be mandatory while changing states of records. In the latest London release, users of the ATF now have the possibility to automate Service Portal and Service Catalogue testing. In our eyes, this is a huge step towards making the ATF an important part of the Testing Arsenal.

With these features (and others coming in the following releases for sure!) Customers can benefit in numerous ways:

  • Financially: well-designed automated tests are cheaper to maintain than using testers to perform manual tests Qualitatively: automated tests exclude the ‘human factor’ and potential mistakes or omissions related to the psychological state of the tester, their physical shape or even the weather outside
  • Personally: Testers released from long and tedious regression testing can engage in activities that automation will never do – creating standards, test plans and so on. I can’t wait to see what’s next with this application and ServiceNow testing.

ServiceNow project requirements – why gather them & how to do it well

The goal of gathering requirements for ServiceNow project, or any other software development project, is to review:

  1. What is done as of now, also known as “the as is”,
  2. The vision of where the system needs to be, also referred to as “the to be”.

The requirements constitute the area in between these 2, and specifies existing issues and/or areas for improvement. In the case of new projects and innovations, “the as is” will be a blank canvas.

The system should support people, processes and the very business. And your requirements should reflect these. Examples in the IT, can be Incident or Request Fulfillment; in HR, we can look to new hires, leaves etc.

How to define ServiceNow project requirements

1 of the issues is that requirements can sometimes be elusive. A stakeholder may want something, but isn’t able to define what it actually is or how it looks like. To succeed in their definition:

  • Expressions must be clear, eliminating ambiguity,
  • Statements must be precise, not too general,
  • Project vision must be common for all stakeholders.

That’s the foundation.

What do good requirements look like

  • Precise – not open to interpretation,
  • Complete – all the connected information is present. Answers to the questions ‘what next’ or ‘what if’ are vital to understand the full scope,
  • Atomic – aim for 1 actor, 1 task, 1 time per a requirement. The indicators that a particular requirement might require a split into next one(s) are 2 words “and” and “or”. It’s not always the case, but it’s always worth some investigation,
  • Traceable – each requirement has its author and justification why it’s needed.

Requirement collection process

An analyst can use various techniques and approaches to collect requirements:

  • 1 to 1 interviews,
  • Workshops,
  • Observation,
  • Prototyping,
  • Questionnaires.

Once the stakeholders have provided their input, it requires analysis and further validation to confirm it’s fully understood. At each stage, full understanding is the key to a successful project delivery. So ask questions until there is no doubt. These steps will help refine the deliverables for the project.

Why gather requirements

The collection of requirements is a cost, yet only provisionally. This cost allows you to optimize budget in the later stages of the ServiceNow project, turning into a saving tool. The analysis at the start of the project is most often less expensive than the replacement or repair of the issues arising if you don’t gather requirements beforehand.

Businesses often rush through this process. They don’t perceive it as a value added and almost never want to invest time and resources in the process before defining scope and setting up budget. The order should be different, starting from gathering requirements that allow to effectively manage both scope and budgets.

ServiceNow project retrospective

The aspects being subject to retrospective assessment of a ServiceNow (or any other) project are:

  • The success / failure to deliver benefits and its triggers,
  • How the system meet / didn’t meet the real business need,
  • The number of bugs to fix.

The requirements collection and definition process should be built into the project delivery plan. Plan for it carefully to make the most of this provisional cost and to turn it into a project gain. It’s as important stage for the delivery as the setup of budget, timeline and resources.

If you need any assistance in your ServiceNow project delivery, don’t hesitate.