Automation Testing Platform

AUTOMATION TESTING PLATFORM

QA Hub

Data Visualisation

QA Hub is a web testing platform that revolutionizes quality assurance by prioritizing excellence over mere task management. This comprehensive solution seamlessly integrates both manual and automated testing processes, enabling engineers to efficiently validate pages, scenarios, and outputs, ensuring optimal performance within predefined timeframes. The tool's seamless automation runs scripts in the backend, yielding instant results on an intuitive interface.

The platform distinguishes itself by featuring Jira ticket creation within the tool, streamlining issue resolutions and preventing delays in customer handoff. Detailed reports facilitate internal communication and showcase proactive testing methodologies to customers. This platform ensures a seamless transition to User Acceptance Testing (UAT), accelerating development cycles and elevating overall product quality. QA Hub offers a scalable solution, allowing users to track testing across projects, create templates for test scenarios, and effortlessly manage tasks without writing risks.

TEAM

QA, Product Manager,

Developers, Design Lead,

Product Designer (me)

DURATION

7 Months

LOCATION

Remote

RESPONSIBILITIES

Competitor Analysis, Information Architecture, Wireframing,

Visual Design, Testing

Process

Being a solo designer for this product I developed a Lean UX process that can deliver the optimum output for the short deadline to the initial launch and feature specific updates thereafter.

DECLARE ASSUMPTIONS

CREATE MVP

RUN EXPERIMENT

FEEDBACK & RESEARCH

Use Cases

A few use cases were defined based on product requirements from leadership and customer demands to establish clear goals in terms of deliverables.

01.

One platform for all tenants and its

locales

02.

Automate Test Scenarios

03.

Raise Tickets integrated with Jira

04.

Generate Reports for internal stakeholders as well as customers

05.

Monitor work distribution

Anchor 1

Tools

A few tools were used by the team's designers to establish an ecosystem of efficient and focus-driven task management.

DESIGN

Sketch and Figma

DOCUMENTATION

Confluence

COMMUNICATION

Slack and Zoom

PROJECT MANAGEMENT

Jira

Information Architecture

A structure was established and finalised with the product manager to mitigate uncertainty in product design and development.

Wireframes

After various iterations, a rough idea was prepared to comprehend user flows and navigation, while also considering the product's usability by different users.

Test Suites Overview

Test Runs Overview

Create Test Suite

Test Run Details

Test Suite Details

Test Runs Tickets

Product Brief

An overview of the product and its features that were set as the requirement, followed by updates in the product lifecycle

Test Repository

Test Suite

Test Scenario

Test Case

TEST SUITES

A set of Test Cases and their Scenarios created to run an entire suite at once and to validate the performance.

TEST SCENARIOS

Areas or features to test either functional or UI components.

TEST CASES

Details of a specific component and how a test needs to be performed (script).

TEST RUNS

Running a test either manually or automated from a suite with different test scenarios or from an existing compiled list.

Test Run

Design Overview and Iterations

The idea generation process, along with iterative considerations for a few pages and features in the design timeline, continued until the result was achieved.

MENU DESIGN

Primary Navigation

Since the inception of this project, there have been multiple discussions on the primary level of navigation. As the product evolved, more menu items were added to combat the application's complexity and to streamline the tasks performed by the user.

1

Initially, the team proposed a dashboard for the application accessible to only one user category i.e. leadership to monitor test results. This was kept on hold in terms of designing the content for the page until we concluded that the primary users of the application were QAs hence prioritising content according to them. These were later moved into metrics under Test Suites and Test Runs to find relevant test performance and data according to their status.

2

Test Suites, Test Runs and Reports were the only items frequently discussed and designed. Test Suite and Test Run being the primary goal of the application to successfully run a test and monitor, Reports was still in an experimental stage but the distinction between them was pretty unclear by iconography. As a designer, I dedicated my effort to constantly improving the internal pages but neglected the visibility of navigation which was later taken care of in the next versions as we re-evaluated the entire application every month.

2

Accessibility is a tool that was originally intended to be a stand-alone application but later after noticing the relation between web testing and accessibility, our product manager took a call to include it in this platform. It potentially benefits the Accessibility Specialist to locate and communicate with the respective team based on the issues rather than switching between 2 applications. This improves the collaboration between both parties.

1

2

3

Secondary Navigation

While I was working on this project the company introduced Experiences where its products were categorised under relevant Experience. Our product was one of the first to implement it. As this was introduced in the research phase it was easier to design the IA hence the menu and its navigation.

TEST SUITES

Filter

Soon after Experiences was introduced we proposed adding a filtering mechanism in the Test Suites page so that the user can filter content based on the product/team. The term 'Modules' was introduced to define a product category and this was named after discussing with the QA team to create a familiarity of nomenclature/lingo used in their work environment.

Actions

1

In the initial versions, actions were kept to a minimum in the entire application and the focus was more on creating a functional application which can be frequently tested and improved upon. For example, the first image shows the actions that can be taken when clicking on the kebab menu on a specific test suite. Downloading a script was only possible after going into the details page.

2

More features were introduced and allowed users to use the platform more efficiently. Sync reloads the entire suit to update the latest result generated after running a test. A real-time update at the click of a button.

1

2

3

4

3

All details or scripts of the suite can be downloaded and accessed from the Test Suite page instead of going into the details page which was much more tedious and confusing for first-time users as to navigating the function. At the same time, users already aware of the Test Suite can access files from the very first page.

4

After observing user behaviour from the user testing, a pattern was identified where the majority of the users copy and paste similar test details. This was performed as a common practice to create different test scenarios or add a minimum variation to the suite. This was further researched by conducting interviews with QA to validate and Clone Test Suite was added as a primary action.

Card Update

Based on all the changes discussed above, the Test Suite Card was updated for better visibility of categories under a module. Type of tests under it i.e. Automated or Manual as well as its Scenarios and Test Cases were viewed at a glance and actions were updated as per demand and product maturity.

The product was being experimented with a brand new style guide for internal products as seen on the left image but over time due to the decision kept on hold by leadership and for the product launch, we reverted to the company's brand guidelines.

Creation Steps

The creation of Test Suite evolved from step-by-step task completion in a modal to a full-page wizard. This was designed to take the users through a journey of creating a suite rather than them attempting to finish the task quickly. It eliminates the area constraint and enables adding complex UI elements to a dedicated page of the process. Reduces user strain by avoiding information overload and low risk of errors.

TEST RUNS

Inspiration

A wide variety of kanban boards were looked into for content hierarchy and card design. In our case, a lot of key information needs to be displayed on the card without making it look like an information overload so the challenge was to keep the UI as minimal. To do this we created iterations with no solid chip design and no bold emphasis on one element. Rather, a subtle difference in hierarchy between one and the other. All the design iterations adhered to the design system.

1

Line icons were used to avoid too much attention to show Test Scenario status with count

2

Last run was misleading in initial version as the calendar icon was unclear if its created on or last run on so instead text was incorporated for clear indication and to avoid the dilemma.

2

1

1

2

4

3

Layout

The overall look of the Test Runs page transformed as the product evolved inorder to accommodate more details that the users need to see and make better decisions. This page holds 70% of the actions that a QA needs to perform. From running a test to raising tickets.

1

This feature was provided on user demand after enquiring and observing their detailed test process. The collection of these reports becomes a means to track progress and communicate the results with internal stakeholders. Few are directly shown to the customers upon completing its framework (Manual or Automation) before handing it over to UAT.

2

More filters were incorporated for ease of use in filtering Test Scenarios based on the status of the result, type of test (manual or automation), and Test Scenarios as a Test Run is a compilation of Test Scenarios.

3

A Test Run is different from a Test Suite because it can be a combination of different Test Scenarios from different suites but running the whole suite provides an overall picture of the current status of a section of the page hence easier to communicate the result as a whole in case of a roadblock in moving the item to next test phase. Based on how a team and its project workflow function we introduced this button on each scenario for a holistic experience in the product.

4

A quick look into the Test Steps which is created in a Test Suite on how a test occurs. This has been provided to eliminate the need to validate them by going to the Test Suite page.

These design considerations and iterations are a few of the lot taken care of in the product design lifecycle which played a significant role in shaping the product until the end of my term in the organisation.