Skip to main content

How OwlPay's QA Team Ensures Stable Operation of Complex SaaS Payment Products Amid Rapid Iterations Using Automated Testing Tool Cypress

Reliable software testing is key to providing dependable software products.

Within the OwlPay team, our Quality Assurance Engineers (QA) conduct rigorous testing to ensure the software functions correctly.

OwlPay is a payment solution product suitable for businesses of all sizes, offering B2B cross-border payment solutions.

Payment-type software products are extremely complex in operation. For example, OwlPay currently supports:

  • 4 types of domestic and international payment methods
  • Over 50 currencies
  • Services in up to 190 countries

With each new feature, QA must ensure existing functionalities work as intended. Traditional testing methods would be time-consuming and labor-intensive for this.

How does OwlPay's QA manage testing under such complex product functionalities, and align with the product engineering team's timeline for new feature releases?

The secret lies in the automated testing tool, Cypress.

This article will introduce three aspects of how OwlPay's QA team integrates Cypress and their collaboration with other roles.

These are:

  1. Tool choice: Why Cypress is chosen for automated testing
  2. Function verification: How does QA ensure OwlPay's frontend and backend functionalities operate normally
  3. Team Roles: How does the QA team collaborate with other roles in OwlPay

Topic 1: Tool choice: Why Cypress is chosen for automated testing​

Cypress Logo

Let's first understand Cypress and its impact on QA.

We will discuss:

  • What is Cypress
  • The advantages of using Cypress
  • How dees the OwlPay team collaborate after adopting Cypress

Key Point 1: What is Cypress​

Cypress is an automated testing tool.

It helps QAs avoid manual tests of system parts.But, Cypress isn't the first tool like this.OwlPay QA Leader - Cody shares:

Before, Selenium and Appium were used for Web and APP tests.

Selenium

But these tools had a big problem: they took a lot of time to install.

Setting them up was tricky.

Problems with 'versions' and 'environment variables' happened a lot. Without the right setup, these tools weren't easy to use.

Many QAs found the setup process too hard.

Cypress solves this issue by:

  1. Being easy to use after installation, as shown in Cypress's official guide.
  2. No need for separate browser tests, so it's easier for beginners.

Here's how to install and start Cypress, from their official site.

Key Point 2: The Advantages of Using Cypress​

Cypress has several key benefits for testing.

For example,

  • It supports interface tests and command-line operations.
  • It takes screenshots and records during tests.
  • Its UI operations are user-friendly.
  • It automatically waits for elements to show up.
  • ...

The "automatic waiting for elements" is really helpful.

In automated tests, QAs often wait for web page elements. With Cypress, you can set a wait time (like 3 seconds). You can also wait longer for certain elements.

This makes QAs' testing work much faster.

Key Point 3: Collaboration Post-Cypress Implementation​

Cypress's introduction also affected the collaboration process between QA and other roles in the product team.

Let's take End-to-end Test as an example.

End-to-end Test involves QA simulating user operations on the system interface. For example, "adding a new order" in OwlPay involves:

  1. Click Order on the sidebar
  2. Click the Add Order button
  3. Fill in Order Amount and Order UUID
  4. Click Submit

During End-to-end Testing, QAs use Cypress's syntax to locate specific web elements before triggering them.

Previously, QAs located elements based on web components' hierarchy.

For example, to click Submit, the original syntax was:

cy.get('.border > .ant-form-item-control > .ant-form-item-children > .ant-submit')

If the UI/UX Designer later changes the button's position, QAs need to rewrite Cypress's syntax.

However, if front-end engineers help name web component id, locating elements becomes much simpler.

For example, the syntax would be:

cy.get('#form_item_submit')

Regardless of how the UI/UX Designer updates the layout, the test content remains unchanged.

Topic 2: Function verification: How does QA ensure OwlPay's frontend and backend functionalities operate normally​

Knowing how QA applies Cypress, let's focus on QA's testing work.

Here we introduce two critical tasks of QA:

  • Develop a test plan
  • Enhancw test efficiency

Task 1: Developing a Test Plan (How does OwlPay QA formulate a test plan or strategy to ensure feature completeness?)​

Before each test, QA first develops a test plan to ensure the completeness of functional testing.

The test plan primarily includes three categories:

Category 1: Functional test​

Ensuring submitted content meets expectations.

Create test plans based on functional requirements and compare "test results" with "expected results".

Category 2: Integration test​

Integrate related functional tests to avoid conflicts.

Simulate a user operating the system from start to finish, also known as end-to-end Test.

Category 3: Regression test​

Ensuring existing functions work normally.

Verify that the current "bug fix" or "new feature" does not disrupt the existing system operations.

In terms of execution order:

  1. Functional test
  2. Integration test
  3. Regression test

The system must pass all three tests to be considered acceptable.

Task 2: Enhancing Test Efficiency​

QA's adoption of automated testing mainly improves the repetition of the above tests.

These actions include:

  • Critical processes: e.g., order payment
  • Time-consuming processes: e.g., filling security identity verification forms
  • Low-change processes: e.g., user login, user registration

Automated testing significantly reduces the time spent on manual operations.

Topic 3: Team Roles: How does the QA team collaborate with other roles in OwlPay​

Let's look at how the team works together.

In the OwlPay team, the main job of QA is to check that new and existing features work right.

Now, let's talk about how QA works with others in two cases: 'New Features' and 'Existing Features'.

Scenario 1: New features​

In this scenario, QA's main duty is to ensure new features work correctly before going live.

So, at which stage does QA perform this task? This brings us to OwlPay's product team's development process.

The team currently adopts Agile Development (Scrum).

As OwlPay doesn't have a PM, designers mainly handle product requirement reception.

After receiving requirements from the business unit, designers go through a series of planning and execution processes.

In sequence:

Step 1: Designers plan new features​

Designers propose new features regularly.

This meeting invites:

  • Frontend engineers
  • Backend engineers
  • Technical writers
  • Product owner

The team discusses UI and functionalities designed for this Sprint. (Only one representative from each team participates)

The designer's proposal must be confirmed by the team before entering the development process.

Step 2: Team jointly decides on development items​

Also known as the Sprint Planning Meeting in software terminology.

Designers explain the background and details of new features to everyone in the OwlPay product team.

QA, after learning about the new features, can then prepare the next testing plan.

Step 3: Team Daily Syncs Development Progress​

Also known as the Standup Meeting in software terminology.

Held every morning, each member of the product team briefly explains in 3 minutes:

  1. What they did yesterday
  2. What will they plan to do today
  3. What help do they need

QA can thus stay updated with the latest development status.

Step 4: Engineers deliver features for testing​

After developing new features locally, Frontend/Backend engineers deploy them to the test environment for QA testing.

In OwlPay, the product team uses Jira for project management and tracking tasks. When engineers mark a task as Done in Jira and choose Complete sprint, the system makes a record of new features made in this Sprint.

QA can read this ticket to understand the new features sent for testing.

OwlPay Release

Step 5: QA tests and verify features​

QA checks if the features developed by engineers, as per the designer's specifications in Figma, function correctly.

The acceptance logic is:

  • If it functions correctly, it passes the test
  • If there are anomalies, a Bug ticket is opened to track the engineer's rectification progress

Step 6: Engineers officially launch features​

Once all features of this Sprint are tested, QA notifies engineers to deploy the new features to the production environment.

This completes a development cycle.

Scenario 2: Existing features​

QA also needs to ensure that features in the production environment operate normally.

When QA, the product team, or external users discover system issues, QA follows the process below.

In sequence:

Step 1: Receiving and confirming issues​

QA first confirms the details of the issue, like where it occurred in the system environment and the steps leading to the problem.

Step 2: Discussing with Engineers to clarify the issue​

After understanding the issue, QA first notifies engineers and has a brief discussion.

Step 3: Opening a ticket​

Once QA has a preliminary understanding of the issue, the results of the discussion with engineers are recorded in a problem ticket.

Step 4: Assessing the urgency of the issue​

If the issue affects users' operations in the production environment, QA asks engineers for urgent rectification.

If not, the ticket is stored in the system for later prioritization.

Step 5: Team jointly decides fix order​

During the Sprint Meeting, the QA explains the details of the issue tickets in sequence.

After understanding the issue details, the team collectively discusses the impact range and prioritization of fixes.

Step 6. Engineers fix and deploy features for testing​

Frontend/Backend engineers complete bug fixes on their local machines and then deploy the features to the testing environment for QA testing.

Step 7. QA tests and verifies the features​

QA tests the features based on the descriptions in the issue tickets and verifies whether the engineers have correctly fixed them.

If the features are fixed correctly, they pass the test; if there are anomalies, the ticket is sent back to the engineers for further fixes.

Step 8. Engineers officially launch the features​

Once all features of the current Sprint have been tested, QA notifies the engineers to deploy the new features to the production environment.

Finally, how does QA ensure that test results are quickly communicated to other team members?​

OwlPay QA Leader-Cody says:

I include three main categories of content in the issue tickets:

【Test Environment】

  • Testing environment
  • Test accounts and permissions
  • UI design

【Test Scenarios】

  • Screenshots
  • Steps of operation
  • Test cases

【Test Methodology】

  • Test description
  • Testing methods

The more precise the information recorded in the tickets, the more it reduces the communication overhead with engineers.