Workspace
Problem
The most basic concept in Rainforest QA is a test. A test contains a collection of steps, actions (like Click, Type, and Hover) and targets (screenshots of UI elements such as buttons and fields) to be executed by Virtual Machines.
A test is created so they can be run – either on a schedule (hourly, daily, etc.) or in response to code changes (PRs).
Each time a test is run, they produce a result: a video replay of the test, broken up into steps. Results either pass successfully from start to finish, or failed.
And when you’re working in a team and managing many tests, logic follows that you’d need an overview – to see trends and remove bottlenecks.
Rainforest built a Dashboard to visualise those data.
Almost everybody skipped it and immediately went somewhere else.
This is a project to design a new start page that people actually want to use.
Design Process
We interviewed some of Rainforest QA’s most active customers and asked them about activites they spent the most time doing in the app.
Most of their answers were confident: test maintenance.
When results fail, they’d watch the replay video to determine the cause, and there were two problems that almost always happened:
- App bug: the test surfaced something wrong with their app
- Test needs refactor: the test is out of date with the latest functionality of their app
In this project, our team was lucky to have identified the problem quite clearly, and early on. It meant that I was able to get to the UI design fairly quickly.
Challenges
Getting to failed results involved multiple steps. Firstly, users had to go to the Test Organization page – skipping the Dashboard. Then, they either:
- Sort by Last Run (failed results will appear first), or
- Go to Filters and search for tests with failed results
The user’s job wasn’t finished after locating the culprit. They then needed to go into the result, watch the video replay, and either fix it on the spot, or categorise it to fix later.
These steps are indirect and slow.
Breakthrough
We could simply show a list of failed results, make it a new start page, and leave it at that. Doing this would’ve saved time and effort.
But we wanted to go further and provide an even more direct means of triage. We posed a challenge to Engineering: can we make the list itself actionable?
Up to this point, any Rainforest list item can only be selected to open another page. Now, we needed to make that list item work harder. It needed to contain sub-elements that are actionable in-context, without opening another page.
Minimum Viable Integration
We didn’t implement this design all at once. While our Engineers were figuring out how to make sub-elements actions a reality, we decided that we could show them first – a taste of what’s to come – and get feedback.
This was our first phase of the project implementation: showing multiple columns in the existing Test Organization page.
Result
On the second phase of the project, we launched Workspace. It’s now called ‘Failed Tests’, and we made it the new Rainforest QA start page.
From here, users can not only see a list of their failed results. They can also take action on them: categorise, assign and describe – all without leaving the page.