New Tool Time – Introduction

I’ve previously written about how important I believe testing tools to be, especially ones written in-house to solve issues that only your organisation faces. It’s time to plan and develop a new one!

This series of posts will be a development diary for this new tool. Hopefully it will provide insight into the kind of problems you can solve with a little bit of programming knowledge and a deep desire to eliminate the tedious parts of being a tester.

All information in these articles are simplified or vague in order to be easily understood, and to not reveal private company information.
Woman writing a simple plan.

What’s the Problem?

The company I work for has a lot of clients that require very similar software solutions. These come in two parts:

  • A mobile application that end-users interact with
  • A back-end system that processes data for display in the mobile application (essentially a very complex API)

In the past this meant that each new client would require a bespoke mobile application, and potentially alterations to the back-end servers to cope with any specific demands they had for data processing.

Having so many bespoke applications made it difficult to add features, and to remember what applications were compatible with specific features.

The Development Solution

This issue was solved by creating a very complex white-labeling system. The majority of new applications that we produce are made by this build system. The system allows a massive amount of customisation to be done to an application, catering for the different needs of many clients. What features are available in each app is dictated by when it was last built, and whether the feature has been enabled for that app in the central administration panel.

This is great, especially for QA! We no longer need to remember the feature set for each app, we just need to test the possible configurations for any app that can be made by the white-labeling system.

What isn’t so great is how all of this works. The system itself is great, but it’s complex and difficult to understand for people unfamiliar with what they’re looking at. Configuration files are deep nests of YAML/JSON, which end up being incredibly difficult to read, especially for less technical testers.

Woman sat in the darkness looking sad about YAML files.

To make one field show up on the registration form of an app, a lot of data is required:

  • Its name for configuration purposes
  • For each language the application supports it requires
    • A display name
    • Help/guide text
    • Validation messages (each field can have many validation rules added to it)
  • Whether the field is required
  • What post-processing is done with the field, e.g. normalisation

When viewed in JSON/YAML a single field definition can take up the height of the entire screen. This can lead to testers not understanding where one field definition ends and another begins. It’s very easy to get lost in the file.

It’s also very difficult to find information about the configuration in general. Sometimes it’s useful to know a single piece of information about every field, like whether it’s required in order to complete the registration process. This information is very difficult to get from the configuration file, and it’s not feasible to have testers writing JSONPath queries for this kind of information. We don’t have time, and lots of us don’t know JSONPath.

Existing Test Solution

Our current solution for making this configuration file more readable by testers is a Java project that takes a configuration file and breaks it down into more easily read CSV files.

The problem with this is testers are expected to download the Java project, compile it, make alterations to the code so that it points at their configuration files, and have it process them.

This is far too much setup. We already have people struggling to get our development environment set up and solve issues with dependency management and all the fun things that come with having to compile a Java project. We’re wasting time having people set this stuff up, when that’s all they’ll ever need the environment for.

It’s also just too much messing around. This should be simple to do.

So among the lead and senior testers we’ve decided we need to do something to make the tool easier to use. It’s a known problem.

My quick-fix suggestion was to put a command line argument/flag library into the project, and have it take some simple inputs about where it’s going to read the configuration file from, and where it’s going to output the CSV files to. Then we would package it up as a standalone JAR (runnable Java archive) and distribute it to whoever might need it.

Even this simple idea was put on the back-burner as we have a lot of other automation/tooling tasks that need doing. I’m okay with this, I understand priorities.

Improved Test Solution

So I thought to myself “How do I make this interesting and fun, so that I feel like doing it as a weekend project in my own time?” The conclusion was a technology I started playing with a year or so ago, and then couldn’t think of a real project to use it on:


Electron is “web technologies as desktop applications”, meaning you can use HTML, CSS, and JavaScript to create cross-platform desktop applications!

I grew up using HTML and CSS to create websites for fun and profit, but my web skills are incredibly rusty. I’ve not written anything real in over a decade. People had just about got their heads around using DIVs for layout, and Internet Explorer 6 was still an ongoing concern the last time I did web stuff! I have a lot to catch up on, but I’m confident that I’ll be able to produce something reasonable in Electron, even if it doesn’t obey all of today’s web best practices.

My current plan is to expand the Java configuration viewer into something the Electron app will be able to use to do the heavy lifting in terms of data processing. This is for a couple of reasons:

  • Code for interpreting the configuration files already exists in Java, if we’re able to re-use that it will be a massive time saver
  • I’m a lot more familiar with Java than JavaScript, so at least for a proof of concept it would be good to avoid getting bogged down in having to learn enough JavaScript to process the data to a similar level
  • I’m lazy!

Obviously this plan could change if any serious issues are found. For example I’m unsure exactly how to interface with the Java code right now. It may end up being simpler to implement some limited configuration interpreting code in JavaScript.

First Steps

I’m going to start off by mocking up some configuration data (in a much simplified format) and implementing some very basic features based on that information:

  • Dragging and dropping of external files into the electron app – this will show that loading configuration files can be very simple and intuitive
  • Displaying all field data in a reasonable format – Something that’s easier to read than raw JSON, which will show that configurations can be read more easily
  • Some kind of filtering/searching so that fields can be displayed based on simple search criteria – starting with a filter to show only fields that are required for registration

I’m deliberately trying to not plan too far in advance at the moment. I want to implement some simple features and get a feel of where I want to take it from there. We’ll see how that goes! 🙂

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Blog at

Up ↑

%d bloggers like this: