Feb 16, 2018 | Soumya Swaroop

Empathy in architectural decisions to empower users

Empathy in architectural decisions to empower users

Over the past year and a half, I’ve been part of the team developing Gauge — an open source, acceptance test automation tool. Working on a product made me think about "What’s essential to build a good product?"

When we think of empathising with our users, we end up wanting to build things to empower them.

In this post, I’ll talk about how we made crucial software architecture decisions based on what would empower our users.

We knew that Gauge has to be lightweight and highly customisable. Plug-in architectures are an attractive solution for teams seeking to build applications that are modular, customizable, and easily extensible.

Yes, Plugin architecture helps a product be extensible, but..

Engaging with the user community and recognising the right direction for an extensible design is crucial.

So, we engage with our user community to understand how to empower them better!

As expected, distribution of responsibility in executing tests of a suite has been the most important architectural decision of Gauge. To do this, we identified the key components of the product and their responsibilities.

Getting to the core of things

So, it all came down to

  • The Gauge Core
  • Language plugin
  • Reporting plugin
  • IDE plugin and others.
Trulli
Figure 1: Gauge architecture

The responsibilities of Gauge core became

  • Run tests for configured environment(s)
  • Validate specifications and provide diagnostics
  • Orchestrate the test execution
  • Broadcasts messages that the plugins use to perform custom actions.

The language plugin’s responsibilities were to

  • Author implementation in the given language
  • Respond to the request Gauge sends (validate, execute…).

The Reporting plugin is required to

  • Generate execution reports

The IDE plugins are responsible for

  • Giving a user interface to use Gauge features

Can I use user empathy to validate Architecture?

Sure, we had a nice design in place. And, we wanted to provide a way to help change the mindset of any team using Gauge from "Can I.." to "How can I.."?

But it would not be valuable to share it if it didn’t actually work. One of the ways we tried validating it is by answering the most common "How Can I?" questions form our users. Here are a few examples

The answer to most of these questions to the one posing it is "by writing a plugin" but for this post, I’ll highlight how the architecture sets out to answer these questions.

How can I create or choose my preferred reporting format?

We know that Gauge core is orchestrating and broadcasting messages. We built reporting as an independent plugin. So this way, it performs the required reporting-related actions by listening to these messages.

Trulli
Figure 2: independent processes talking to each other over TCP

So, the report format is independent of how the tests are executed (parallel, sequential). And any customisation is reusable for tests run in any supported language.

The reporting plugins we built usually listen to the event SuiteExecutionResult, that is broadcast almost at the end. So you can have the default reports generated in HTML-reports, XML-reports or write a custom reporting plugin. Here is how you can get a quick start to author a custom reporting plugin — Report-seed. This is in Java, a similar approach can be followed to write custom reporting plugins in other languages also.

How can I run tests in the language of my choice?

We designed Gauge core to broadcast Protobuf messages to the plugins mentioned in a project’s manifest file.

Protobuf is a language and platform neutral mechanism for structuring data.

Trulli
Figure 3: independent processes talking to each other over TCP on env GAUGE_INTERNAL_PORT

This not only enabled the registered plugins to execute tests in the language of choice but the runner was authored in the same too. So, we have Gauge-js authored in JavaScript to run tests written in JavaScript. Similarly Gauge-python is for Python.

All this, with Gauge-core authored in Golang! Read this if you’re interested in authoring a new language runner for Gauge.

How can I use it with an IDE of my choice?

We designed Gauge to have a language server protocol (LSP) implementation. This helps different IDEs LSP clients take advantage of it.

Trulli
Figure 4: LSP independent client server processes interacting with each other

So, we have gauge-vscode which is a plugin to Visual Studio Code. This article will not only help you understand the offered Gauge IDE features but also gives pointers on adding a new IDE support for Gauge.

Should I write a custom plugin for something like parallel execution?

Consider a product design that requires the users to write a plugin to run tests in parallel. This means, the tool (the execution and reporting) handles only sequential execution by default.

What if the user has to write a plugin to add parallel run support?

The user will have to now worry about

  • Consolidation of parallel run result
  • Parallel run report generation in default/customised formats
  • On CI, parallel and sequential options have to be explicitly handled on separate tasks of execution and reporting. Would this be as effective as it should have been in empowering its users?

We think not. In Gauge, such features are built in core.

All related tasks are handled by default. So, such architectural decision makes a feature (e.g:parallel run) readily and easily available to any user running tests in any language of choice!

What I’ve tried to say is that empathy is not just the prerogative of the Business Analysts, User Researchers, UI folks or the front-end.

Having users at the heart of everything also means putting their interests forward while making architectural decisions.

Empathy needs to seep into our very core! (forgive the pun) and that’s what is essential to build a good product.

Gauge is a free and open source test automation framework that takes the pain out of acceptance testing. Download it or read documentation to get started!

–